[cryptography] Asynchronous forward secrecy encryption

Trevor Perrin trevp at trevp.net
Wed Sep 18 13:56:03 EDT 2013

On Wed, Sep 18, 2013 at 10:22 AM, Michael Rogers
<michael at briarproject.org> wrote:
> Hash: SHA1
> On 18/09/13 17:27, Trevor Perrin wrote:
>> Hmm, I would've thought clocks are *less* reliable than storage on
>> most devices.
> That may be true, but this isn't a choice between relying on the clock
> or relying on storage. It's a choice between relying on both, or
> relying only on the clock.

Sorry, mis-send... I meant:

A quick glance at Briar makes it looks like it already uses local storage:

Neither endpoint can send more than 2^32 connections to the other
during a given rotation period. Each endpoint persistently stores the
highest connection number it has sent to the other during the current
rotation period, together with a sliding window of the highest
connection numbers it has received from the other during each of the
current retention periods. The persistent storage of these values is
vital, so BTP cannot be used by endpoint devices that lack writable
persistent storage (unless the devices never reboot).

But I don't know enough about the protocol to be giving advice, so I'll stop...

>> Certainly this has worse forward-secrecy than updating keys
>> per-message, as keys for old ciphertext are kept around for some
>> period.
> Yes, updating keys per-message would be preferable if we could assume
> an ongoing two-way exchange of messages. For OTR's instant messaging
> use case that's a reasonable assumption. For Briar's use case it's not.

The per-message symmetric-key update that Adam and I sketched doesn't
require a 2-way exchange of messages.  Even a one-way stream of
message would receive good forward secrecy.


More information about the cryptography mailing list