[cryptography] Asynchronous forward secrecy encryption

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


-----BEGIN PGP SIGNED MESSAGE-----
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! :-)

Cheers,
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJSOg7cAAoJEBEET9GfxSfMZuAH/jQhZXDNMs0LszDoAE72SNaO
et+uwRk1m8wnChhU1WCuQ8Cmc//tJxcdly9BfzqUafs7q4dj1pl7YEoRI152bs9J
mFcF/Z7oF5/ueZ6m/deuR8e9Lf2oGgIvP8K87/E/DRQFGKR/As7rGs7Or9lchpey
m7OFztfP0BB+uRkHrC7vfdgWqPOQeDnuHa1pItA+zXLqRloze4pPSpuHhvc2EGz2
JqckFQ4b0GRKFdHReYv/S46TO/g96qLjz+wNu9QUw9oAUiSHcuhQcJ7FX0dEXm77
mk78jRRBpaEjLCF03Zt+wcFSHJ30/GSqtdKyYnuJ2OfjMpkF6Ym3odWfzKtoYw4=
=I+Be
-----END PGP SIGNATURE-----


More information about the cryptography mailing list