[cryptography] Asynchronous forward secrecy encryption

Adam Back adam at cypherspace.org
Fri Sep 20 05:19:58 EDT 2013

Depending on what you're using this protocol for you maybe should try to
make it so that an attacker cannot tell that two messages are for the same
recipient, nor which message comes before another even with access to long
term keys of one or both parties after the fact.  (Forward-anonymity

Otherwise it may not be safe for use via remailers (when the exit is to a
public drop box like alt.anonymous.messages).  And being able to prove who
sent which message to who after the fact is not good either, if that can be
distinguished with access to either parties long term keys (missing


On Thu, Sep 19, 2013 at 09:20:04PM +0100, Michael Rogers wrote:
>Hash: SHA1
>On 19/09/13 08:04, Trevor Perrin wrote:
>> I'd have to see a writeup to have real comments.  But to address
>> the issue of "fragility":
>> It seems you're worried about per-message key updates because in
>> the (infrequent?) case that a sender's write to storage fails, an
>> old key would be reused for the next message.
>> What happens in that case?  You mentioned random IVs, so I assume
>> the only problem is that the recipient can't decrypt it (as she's
>> already deleted the old key on receipt of the previous message).
>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.

More information about the cryptography mailing list