[messaging] Reduce identity key exposure in Pond

[Jeff Burdges]

Sure.

Adam wants to authenticate message delivery with single use tokens.  A token consists of a public-private key pairs (y,x) along with a proof HMAC(k, y) that the public key y was issued.  

At present, Pond users have two long term public-private key pairs :
- all your contacts know both public keys, while 
- the server identifies your mailbox with your "identity key", but the server does not know your other key. 

It’s slightly undesirable that your contacts know the public identity key that identifies your mailbox on the server.  

Instead, the delivery token could hide the identity key the server wants.  A token scheme achieving this is :

Alice gives (z,x) to Bob where :
- id_a is Alice’s public identity key,
- z’' is the tuple (nonce,id,y),
- z’ is z’’ signed by Alice's private identity key,
- z is z' encrypted to the server’s private key. 
Bob can send Alice a message by signing the message using x and prepending z.
The sever decrypts z to obtain id_a and y, verifies the tuple z'' using id_a, and verifies the message using y. 

Does this complexity buy us anything? 
- Your contacts cannot accidentally reveal your identity key. 
- It’s safer to give away a delivery token when introducing two contacts. 
- A server must be more thoroughly compromised to gain any traffic information. 
- A hardened server becomes a less attractive target. 

Does it cost us anything? 
- Afaik any token scheme admits a bizarre attack where Eve gains access to Alice’s pond, and instead of MITMing her connections, merely sends Bob a bad token so the connection fails in the future.  If tokens contain hidden identity keys, then Eve can learn her trick worked without also hacking the pond server.  Afaik not a serious issue.  

Best,
Jeff



On 30 Mar 2015, at 20:17, Trevor Perrin <trevp at trevp.net> wrote:

> On Fri, Mar 27, 2015 at 6:46 PM, Jeff Burdges <burdges at gmail.com> wrote:
>> 
>> Pond clients are identified to the server by a Curve25519 key pair called the identify key, stored in client.identityPublic and client.identity.
>> 
>> At present, your contacts all know your identity key, stored in Contact.theirIdentityPublic.  An adversary who both hacks the pond server and compromises any of your contacts thus learns when you receive messages, when you collect messages, and message sizes.  I suppose the group signature scheme necessitated this, but..
> 
> Hi Jeff,
> 
> I'm not following - your Pond mailbox server already learns "when you
> receive messages, [and] when you collect messages".  Delivery tokens
> control whether the server accepts a mail for your inbox, but I don't
> see how they affect the server's knowledge of when mails arrive in
> that inbox, or when they're retrieved.
> 
> I also had trouble following below, I don't have the details of Pond's
> key management fresh in mind, so a slower explanation with more
> background would help.
> 
> 
>> Pond will eventually replace the group signature scheme for delivery authentication with an HMAC token based scheme :
>> https://moderncrypto.org/mail-archive/messaging/2014/000409.html
>> 
>> At that point, there is no need to expose this identity key to your contacts any longer.
>> 
>> Instead, clients could hide identityPublic inside the tokens they give to their contacts.  I expect this necessitates a larger token than merely {x, HMAC(k, y)} because the server must know k to efficiently locate the mailbox.  Clients could however encrypt the z ++ client.identityPublic to the server identity key returned by parseServer(..) where z is HMAC(k, y), y++HMAC(k,y), or even just y, eliminating the need to communicate y elsewhere.
>> 
>> At present, newRatchet does use contact.theirIdentityPublic but it could easily be modified to use a key derived from theirPub using extra25519.PrivateKeyToCurve25519(..) and extra25519.PublicKeyToCurve25519(..).
> 
> Trevor