[guardian-dev] releasing an encrypted mail system code base

Daniel McCarney daniel at binaryparadox.net
Mon Jul 22 11:02:18 EDT 2013


Hi Tim,

First off, I'm really happy to see someone working in this space. I think there
is a real need. There's a tremendous lack of innovation in the usable/secure e-mail
space. Great work :-)

I haven't had too much time to look at your architecture but I did skim the materials
you have up so far. I have a few questions you might be able to address:

In the FAQ[1]

> If a government or law enforcement agency asks Mailiverse for my e-mail will you
> give it to them?
>
> Yes. Mailiverse will give them any information as required by law. But it
> doesn't matter. Here is why:
> Mailiverse's authentication scheme is setup in a way that Mailiverse cannot read
> your mail. Nor can anybody else.

This statement should probably be toned down. There is no way to ensure to
clients that the crypto code your server delivers to be run client-side hasn't
been backdoored or otherwise modified (either by an attacker with access to your
server or at the behest of law enforcement ala Hushmail[2]).

Whether or not that's acceptable depends largely on your threat model. The
convenience of client-side JS crypto might outweigh the additional security of
a browser plugin or stand-alone client code.

The technical description[3] should probably be fleshed out a little bit more
(but it sounds like you're in the process of providing more documentation). I'm
a little bit confused about the role of the "VerificationKey", is this only used
for SRP auth with the server?

> Login
> The javascript client logs into our server using SRP. (SRP provides protection from MIM attacks.)
>
> Use password to generate VerificationKey and CryptoKey [PKDF2-HMAC-SHA256,#iter=131072,kl=256,public salts]
> Use the VerificationKey as the password for SRP authentication

The wording here makes it sound like the PAKE w/ SRP is performed prior to key
generation, but that the VerificationKey is the password used during PAKE. Why do
you use a keypair derived from a password as the input to a password-authenticated
key exchange protocol. Why not use a more appropriate exchange given you have a 
keypair? Am I confused?

>  These cache files are encrypted (AES-CBC-256-EmbedIV) with an AES key,
>  generated from a combination of a secret seed and the file name. 

How is the seed generated? How is the cache file named?

Are you addressing interoperability at all? I.e. it sounds like my Mailiverse
email would be encrypted (and perhaps signed?) if I mailed another Mailiverse
user, but I'm not clear on what happens if I email a Gmail user. Is there any
support/plan to interoperate with PGP/GPG using my Mailverse keypair?

>  When mail is received by our server, whether internally or externally, the server 
>  looks up the client's RSA PublicKey, encrypts (RSA-AES-CBC-256-EmbedIV) the mail 
>  and writes it to the user's store. 

Have you considered using an authenticated AES mode? CCM or GCM perhaps?

Again, just some very initial thoughts/questions. Looking forward to seeing 
where this project goes! :-)

- Daniel

[1] https://mailiverse.com/learnmore.html
[2] http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/
[3] https://mailiverse.com/technical.html

On 07/22, Tim Prepscius wrote:
> I said in the original post that I would give an update on Sunday.
> It's Monday ;-)
> 
> 
> At this point all of the java/gwt/web code has been added to the repository.
> 
> This coming week I will add the cpp and apache-james code.  Hopefully
> as well build-scripts and deploy-scripts.
> 
> ..
> 
> Next week I will test that I've put code in the right places, attempt
> to create an "installation script" to setup the entire system.
> 
> And start writing a brain dump of how everything works.
> 
> 
> -tim
> 
> 
> On 7/15/13, Nathan of Guardian <nathan at guardianproject.info> wrote:
> > On 07/14/2013 01:53 PM, Tim Prepscius wrote:
> >> I am notifying this mailing list for two reasons:
> >
> > Thanks for notifying us, Tim. We appreciate the massive amount of effort
> > you have put into this, and will do what we can to have the right people
> > take a look at it.
> >
> > +n
> > _______________________________________________
> > Guardian-dev mailing list
> >
> > Post: Guardian-dev at lists.mayfirst.org
> > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> >
> > To Unsubscribe
> >         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
> >         Or visit:
> > https://lists.mayfirst.org/mailman/options/guardian-dev/timprepscius%40gmail.com
> >
> > You are subscribed as: timprepscius at gmail.com
> >
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/daniel%40binaryparadox.net
> 
> You are subscribed as: daniel at binaryparadox.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130722/8aec8634/attachment.pgp>


More information about the Guardian-dev mailing list