[cryptography] Asynchronous forward secrecy encryption

Michael Rogers michael at briarproject.org
Wed Sep 18 16:36:44 EDT 2013

Hash: SHA1

On 18/09/13 18:56, Trevor Perrin wrote:
> 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). """

Yup, that's the fragile current design I mentioned. :-) The new design
still depends on persistent storage, but it avoids the risk of key
reuse if the persistent storage is unreliable.

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

No, it's always good to get people's views on the design - thanks!

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

Ah, sorry, I was thinking of OTR's per-message update rather than
yours! The method you and Adam suggested would be suitable for our use
case, and much more elegant than what we're using now, except that it
requires a plaintext sequence number.

We've tried to avoid plaintext fields in BTP to make it harder to
design filter rules to detect or block the protocol. So we rely on the
pseudo-random tag to tell the recipient (a) which sender the message
comes from, (b) which rotation period the sender was in when the
message was sent, and (c) the sequence number.

The recipient precalculates a limited number of tags in a sliding
window, which allows a limited amount of message loss or reordering -
but if too many messages are lost, the sender's sequence number will
move beyond the recipient's window, and they'll have to wait until the
next rotation period to resynchronise (the sequence number is reset at
the start of each rotation period).

This is all rather clunky, and I'd love to find a better way to do it,
but so far I haven't been able to work out how. Suggestions welcome! :-)


Version: GnuPG v1.4.10 (GNU/Linux)


More information about the cryptography mailing list