[cryptography] Asynchronous forward secrecy encryption

Adam Back adam at cypherspace.org
Wed Sep 18 03:12:00 EDT 2013

Thats a good approach but note it does assume your messages are delivered in
the same order they are sent (even though they are delivered
asynchronously).  That is generally the case but does not have to be -
neither email nor UDP for example guarantee that.  

Maybe you would want to include an authenticated sequence number so the
recipient can detect gaps and out of order messages, though that does create
an attack where the attacker can delete a message, and cause the recipient
to keep messages.

Or better the actual key used could be derived to fix that.  eg
k_{i+1}=H(k_i) delete k_i; but also sk_i=H(1||k_i) then use sk_i values.  In
that way you can keep keys for a gap with no security implication other than
the missing/delayed message security.  Other messages that come afterwards
would be unaffected.


On Tue, Sep 17, 2013 at 04:14:09PM -0700, Trevor Perrin wrote:
>On Tue, Sep 17, 2013 at 2:01 PM, Michael Rogers
><michael at briarproject.org> wrote:
>> Hash: SHA1
>> Hi Marco,
>> This is a problem we're working on as part of the Briar project. Our
>> approach is pretty simple: establish a shared secret when you first
>> communicate, periodically run that secret through a one-way function
>> to get a new shared secret, and destroy the old one.
>Why not have separate symmetric keys for each direction of
>communication (Alice -> Bob, Bob->Alice).
>Then whenever a party encrypts or decrypts a message, they can update
>the corresponding key right away, instead of having to wait.
>(Or look at OTR's use of updating Diffie-Hellmans).

More information about the cryptography mailing list