[Cryptography] AES GCM insecure vs OCB1/OCB3 ??

Phillip Hallam-Baker phill at hallambaker.com
Thu Feb 11 12:16:25 EST 2021


So I am into the closing stages here writing up a small presentation layer
with some surprises for the wannabe censor.

Why not make every host a potential onion routing node at the packet level,
thought I. This approach also has some interesting leverage in protecting
against quantum cryptanalysis.

Consider the case in which Alice establishes a video chat with Bob. Since
both people are using mobile clients with varying IP addresses, this must
entail use of a presence server for discovery at some point. So our
protocol is going to involve a conversation like:

Alice->Presence: Where is Bob? I wanna talk
Presence -> Alice: Bob can be reached through a wide cone NAT on {IP, port}

Only of course we would want all this to be authenticated and we want a
four corner model on this to provide protection against abuse.

So after we have factored all of the necessary authentication etc. and
Kerberos ticketing for performance, what we end up with is a two layer
security model:

Application layer (Mesh chat): Using Alice and Bob's public/private device
keys
Presentation layer (transport): Using kerberized tickets mediated by the
Mesh Service Providers for Alice and Bob.

And the reason I am not using TLS for the presentation layer is that it
doesn't ratchet and ephemeral keys replace the keys established in the
master key agreement rather than both being used to drive a key
derivation function. (Could the NSA have jiggered it? Of course)

Since Alice and Bob both have the benefit of a shared secret established in
both contexts, my plan is to fuse these by means of the KDF. What this will
provide is 'graceful degradation' in the case that quantum cryptanalysis
becomes possible before resistant algorithms.


But anyways, here is my problem. The initial draft of the spec had a fresh
nonce for every packet which was used to derive a new key and a new IV for
each packet. Problem being of course that this is likely to be rather
inefficient.

If we follow the ideology of AEAD encryption being better, maybe we should
just rely on the IV being different for every packet?

Well no, not when GCM turns AES into a stream cipher. If I can get 2^48
packets, I can start decrypting some. This seems like playing a shell game
in which a really strong cipher got bartered down to a weak one. 2^48
packets is a lot of data but it is well below the 2^128 work factor I am
designing to.


So I see two possible options here:

1) Cheap means of rotating the key on every use.
2) Use KDF
3) Move to OCB3 which is not a stream cipher.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210211/837a8240/attachment.htm>


More information about the cryptography mailing list