[cryptography] Asynchronous forward secrecy encryption
iang at iang.org
Sat Sep 28 07:36:45 EDT 2013
On 26/09/13 23:08 PM, zooko wrote:
> Let me just mention that this conversation is AWESOME. I only wish the folks
> over at Perry's Crypto List (http://www.metzdowd.com/pipermail/cryptography/)
> knew that we were having such a great conversation over here.
> 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 ?
> Another defense against this is to generate the IV from the plaintext, possibly
> from the plaintext in addition to other stuff. There are three things that you
> might want to throw into your IV generator: 1. the plaintext, 2. a persistent
> secret key used only for this purpose and known only to this client, 3. a
> random nonce read from the operating system.
> I would suggest including 1 and 2 but not 3.
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.
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.
(I know there is a lot of disrespect about the MAC-then-Encrypt ordering
but I think it is more to do with certain trickinesses than a wholesale
ban. I haven't read up on it tho. I recall when I was looking many
moons ago the consensus was that the problems found were easily fixed.
> This *could* be seen as an alternative to the defense you described:
>> In the new design, the temporary keys are still derived deterministically from the shared secret, but the IVs and ephemeral keys are random.
> Or it could be used as an added, redundant defense. I guess if it is an added,
> redundant defense then this is the same as including the random nonce -- number
> 3 from the list above.
Which would mean that the nonce and the IV plaintext hash/HMAC would
need to be distro'd ?
And the sequence number?
Leaving the time to be guessed and retried +/- n quanta. That's the
reason I don't like using the time. It might be OK if the two parties
are in live comms, but this is specifically a situation where the
requirements say nothing nice about the time.
I guess I would go back to first principles and ask why we're doing this.
More information about the cryptography