13:00:38 <evilaliv3> #startmeeting
13:00:38 <MeetBot> Meeting started Mon May 11 13:00:38 2015 UTC.  The chair is evilaliv3. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:38 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:00:47 <evilaliv3> hi all! :)
13:01:08 <evilaliv3> i've just opened the pad for the daily scrum meeting
13:01:11 <evilaliv3> http://piratepad.net/2MeU0fEPl7
13:02:04 <evilaliv3> please fill it so that we we can share on what are we currently working and see if there is something we can help eachother
13:29:04 <evilaliv3> ok me and vcn have filled our daily schedule
14:19:38 <hellais> y0
14:42:02 <evilaliv3> yo hellais !
14:46:46 <evilaliv3> i've not already discussed with you but only with vcn, and naif but i'm evaluating a slightly different solution for the key of the whistleblower
14:47:45 <evilaliv3> given the fact that for receivers we will currently continue to adopt an husmail like model, for the first release of this end2end implementation i would suggest to go for that model also for the whistleblower
14:47:53 <evilaliv3> this has two main advantages:
14:48:21 <evilaliv3> 1) less code do be audited as the solution will be the same
14:48:40 <evilaliv3> 2) less possibility for bugs due to some more code reuse
14:49:20 <evilaliv3> 3) third and really more important the passphrase generation and the RSA key generation will have th possibility to be runned in parallel instead than sequencial one to the other
14:50:44 <evilaliv3> this third seems to reduce of ~50% the key generation on whistleblower side on a powerful PC like mine, and i expect more on a les powerful one. i'm developing few test to show this and clarify the reasons behind this desin choice
14:51:14 <evilaliv3> what do you think? given that the receiver side is handled with an husmail like model the security will be exactly the same
14:51:58 <evilaliv3> and in the future we will evaluate to reintroduce your concept giving more time to OpenPGP to integrate the solution for the deterministi key generation
16:22:27 <hellais> evilaliv3: if you think it's easier to implement then sure.
16:22:40 <hellais> Though please let's stop calling this the hushmail approach, because it really isn't
16:23:02 <hellais> it has VERY different security properties and threat model than what hushmail was doing
16:46:59 <evilaliv3> k :)
16:47:30 <evilaliv3> it was simply to clarify that the key is on the server even if encrypted in a more secure manner
19:06:29 <hellais> but the key to the encrypted key is not given to the server like in the hushmail case
10:45:32 <GL-Github-Bot> [13GlobaLeaks] 15evilaliv3 pushed 1 new commit to 06devel: 02https://github.com/globaleaks/GlobaLeaks/commit/12465f298a149198a9e013ab2261dc8ca11ee02f
10:45:32 <GL-Github-Bot> 13GlobaLeaks/06devel 1412465f2 15evilaliv3: Add protractor test for granting tor2web permissions
12:53:41 <evilaliv3> #endmeeting