[cryptography] Asynchronous forward secrecy encryption

Michael Rogers michael at briarproject.org
Sun Sep 29 12:22:17 EDT 2013

Hash: SHA1

On 28/09/13 12:36, ianG wrote:
>> On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote:
>>> The key reuse issue isn't related to the choice between
>>> time-based and message-based updates. It's caused by keys and
>>> IVs in the current design being derived deterministically from
>>> the shared secret and the sequence number. If an endpoint
>>> crashes and restarts, it may reuse a key and IV with new
>>> plaintext. Not good.
> Either the whole session has to be renegotiated then, or you need a
> way to inject fresh randomness post-crash.  It's not good to rely
> on counters or RNGs in those circumstances.  Time ?

I'm assuming that if a crash occurs, we can get fresh randomness (e.g.
from the OS) after restarting. Is that not a safe assumption?

I'd prefer not to rely on time, as the rotation periods for
high-latency transports are necessarily long (we don't want to rotate
keys while a message is in transit), so after crashing and restarting
we may have to wait a long time until the next rotation period starts.

> I'm assuming the IV is shared in the enciphered message, as
> otherwise it is unknowable to the recipient if it has 1. in it.

Yes - the format is (random IV || ciphertext || MAC), where the MAC is
calculated over the IV and ciphertext. (If using an authenticated
encryption mode instead of a separate MAC, the IV is included in the
additional authenticated data.)

> It seems we're getting closer to MAC-then-Encrypt.  That is, take a
> HMAC of the plaintext (uses 1, 2).  Use that as (part of?) the IV.
> Encrypt. Deliver the IV + ciphertext.

To be honest I don't see a reason to use any function of the plaintext
as an IV - I'd prefer the IV to simply be a fresh random value,
unrelated to the plaintext, unless there's a reason to doubt that we
can generate such a value.

> I guess I would go back to first principles and ask why we're doing
> this.

Yes, great idea. Here are the requirements as I see them:

1. Protocol obfuscation: Nobody except the intended recipient should
be able to distinguish any part of an encrypted message from random bits

2. Unlinkability: Nobody except the intended recipient should be able
to tell whether two encrypted messages have the same sender or
recipient (except by observing who sends and receives them, of course)

3. Asynchrony: Messages should be deliverable via high-latency
transports such as migrating geese

4. Forward secrecy: Encrypted messages should eventually become
undecipherable by their senders and recipients

5. Error tolerance: None of the above properties should be lost if
messages are lost or reordered in transit

And of course the standard requirements of confidentiality, integrity
and authenticity.


Version: GnuPG v1.4.10 (GNU/Linux)


More information about the cryptography mailing list