[cryptography] Asynchronous forward secrecy encryption

Trevor Perrin trevp at trevp.net
Wed Sep 18 12:27:18 EDT 2013

On Wed, Sep 18, 2013 at 7:35 AM, Michael Rogers
<michael at briarproject.org> wrote:
> Hash: SHA1
> On 18/09/13 08:12, Adam Back wrote:
>> 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.
> This is very close to the way we currently derive keys. We also derive
> a pseudo-random tag corresponding to each key, which is prepended to
> the encrypted data so the recipient can detect reordering (using a
> sliding window as in IPSec) and use the correct key.
> However, this approach is fragile because it requires persistent
> storage of a counter - if the app crashes after using a key but before
> persistently storing the updated counter, you can end up reusing a
> key. Unfortunately, since hard disks and operating systems lie about
> having persistently stored data, this can happen even if you store the
> counter and call fsync before using the key. So we're moving to a less
> fragile approach:
> * Rotate the shared secret periodically

Hmm, I would've thought clocks are *less* reliable than storage on most devices.

Certainly this has worse forward-secrecy than updating keys
per-message, as keys for old ciphertext are kept around for some


More information about the cryptography mailing list