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

[Tim Prepscius]

On 7/22/13, Daniel McCarney <daniel at binaryparadox.net> wrote:
> 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]).
>

Yes.  I'm actually going to shutdown Mailiverse.  Or just make it a
test-bed.  Or not shut it down.  Whatever is best.

So, whoever runs the server can place more appropriate language.
Or I can I guess.


I think, once pgp-mime or a similar mechanism is incorporated into the
client, it will become very very difficult for the service to be
backdoor--ed.  Since all of the client code is human readable, and
"verifiable" from a common code base, any back door should be
detectable.

Once the pgp-mime mech is in place, the mail server encryption become secondary.

That is not to say that it couldn't be back-doored, but just that it
will become much more difficult to pull off in a reliable way.  Unless
of course the major browsers themselves have been back-doored.  Which
I hope not.


> 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.
>

Yes.

> 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?
>

Yes.

Password -> generates via 2 salts, standard PBE lots of iterations.
  Ke:
     is used to encrypt your private key.  Never transmitted anywhere.
  Kv
     Kv is used in the SRP scheme to verify your identity to 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?

It is sort of confusing.

I wanted to have a clear delineation between the encryption of the private key.
And the user authentication.

The whole process of user-retrieving-information-for-his-mail-box is:

1. User enters password P.

2. I use a public salt Sv in the usual PBE process to generate a Kv.

3. I take Kv and use SRP mathemagic to verify my identity to the
server, verify the server, and in the process open a secure
connection.

4. The server sends to me my "Previously-Encrypted-Key-Block."

5.  I use the original password P and generate the encryption key, Ke,
using a different salt Se.

6.  I take Ke and decrypt the "Previously-Encrypted-Key-Block" in
order to retrieve my private key and as well various "where things
are" information.

Ke is never sent anywhere.  Password P is never sent anywhere.


>
>>  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?

The seed *is* your private key.
The file name is a "secure random" long base 16 encoded.  I need to
check whether it is a long or X bytes.
HashSha256 (filename + seed) generates AES-256 key.


The cache file names look like this:
C_076a7dddefc7
C_0786686b405d
C_682fcd07223f
C_c1749ff92f3f
F_15cb0264ccf6
F_534e4b50b166
M_2ae154e1658e
M_5acdea852622
M_85334bd84cde
M_c47b7b5d89f5
M_d4722a5f1324

When I first went about making the keys for the caches it was doing a
totally independent key per cache file.
Where, basically I would secure random a new key, store that key in a
"parent" index file.

So I asked questions here:
http://marc.info/?l=botan-devel&m=135972508121986&w=1

Per Falko's advice, I used the scheme of "filename + secret key" as a
SHA-256 generator for a seed.
This could be changed back to a completely independent method if so
desired.  Or changed into something different.  Etc.

If you read entire thread you may wonder if I still have one instance
of an AES without an IV.  *All* AES encryption now uses NonNull
secure-random IV's.



When I post the iPhone code, it is easier to trace through than the
java-code.  Verify if what I think I am doing, is actually what I'm
doing.
(the java code needs to have all these callbacks so things can be off
loaded to a worker thread, makes for a confusing trace)  The iPhone is
much more sequential.


>
> 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?


This should be the next version.  I would like some help doing it.
And help picking the best way of doing it.

It should be *fairly trivial* (which probably translates to: not
trivial) to incorporate this feature.

I'm actually looking forward to this, because I think that with this
missing piece the core system will be complete.

>
>>  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?
>

No I have not.  I will research.

> 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
>