Re: [IPsec] [CFRG] Use of AEAD algorithms as pure encryption algorithms

[Valery Smyslov <[e-mail]>]

Hi Natanael,

 

thank you for your response, please see inline.

 

Den tors 20 apr. 2023 09:42Valery Smyslov < <mailto:[e-mail]> [e-mail]> skrev:

Hi,

I have a question to the crypto community regarding the use of AEAD algorithms as pure
encryption algorithms. The use case is as follows.

In G-IKEv2 (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/) we have a situation
where keys are transferred inside the G-IKEv2 message. The message itself is encrypted and
integrity protected. In addition, each of individual keys inside this message is encrypted too
with a different key(s) (it can be the same key for all encrypted keys or different key for each encrypted key,
but in any case these keys are different from the key protecting the message).
The reason for this construction is to prevent the G-IKEv2 engine which forms and parses 
messages from accessing any sensitive information inside the messages.

The algorithm for protecting the message itself and individual keys inside the message is the same - 
it is one of IKEv2 Encryption transforms 
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5
The reason for this is to simplify implementations - the algorithm for protecting the message will be 
supported anyway, so there seems to be no reason to negotiate another one.
In many cases this algorithm will be an AEAD algorithm (like AES-GCM).

The problem is that there may be quite a lot of encrypted keys inside a single message,
and since G-IKEv2 operates over UDP (and over multicast!), the size of the message matters - 
large messages will be fragmented by IP level and due to known issues with firewalls
might not get through, so we want to make the message small. And for each protected key 
the authentication tags would consume almost the same space, as the encrypted content.

So, the design is that even when using an AEAD algorithm, the individual
keys inside the protected message are only encrypted and their authentication tags produced by the AEAD algorithm,
are not transmitted. On a receiving side it must be possible to decrypt keys without performing an integrity check.
Note, that the message itself is encrypted and integrity protected, so we are sure that all message content, 
including all encrypted keys, is not altered.

My questions to the crypto community:
1. Is it generally OK to use AEAD algorithms as pure ciphers.
2. Do existing APIs to AEAD algorithms allow to decrypt an encrypted blob without checking its integrity.

Regards,
Valery.

 

1: No, in the general case. It's not a good idea. But there's options (see below).

 

Especially given that many common AEAD ciphers are built on stream ciphers they are trivially malleable if you don't check the authentication, so if an adversary knows a single plaintext block they can modify it to decrypt to anything they wish. You get none of the guarantees they're intended to give if you don't use them as intended.

 

          Yes, I’m aware of this.

 

In the context of your example this allows the adversary to eg. resend old keys, possibly forcing key reuse elsewhere.

 

          No, it is not possible in my use case. The message, which contains encrypted keys, is always

          encrypted and authenticated using the same AEAD algorithm, and G-IKEv2 provides replay protection,

          so no external adversary can either see or manipulate the keys.

 

*Even if* the individual keys have their own layer of authenticated encryption inside the encrypted stream, the authentication should bind to the session to prevent replays and more.

 

          As I’ve already said, replays are not possible. And there is a binding of these keys to a session too.

 

2: I think most APIs prevent it - in addition some algorithms makes it impossible, intentionally. See SCRAM;

 

https://github.com/aws/s2n-tls/tree/main/scram

 

          Thank you for the pointer.

 

You do have other options. If you prepend a signed/authenticated Merkle Tree hash which cover the set of encrypted keys then they can be individually verified against the Merkle root without decrypting the entire message. This signature can then also bind the key bundle to the session. The size overhead can be some kilobytes. If this is worth it depends on what you mean with "quite a lot of keys". Several hundreds or more? Could be worth doing. Just some dozen? Not really.

 

          Well, let me be more specific. G-IKEv2 operates over UDP, so the message size should be less than path MTU to avoid IP fragmentation.

          In most cases it is 1500 bytes, but can be smaller, say 576 bytes. There are some other stuff in the message besides keys,

          so it is generally about from 300 to 1250 bytes are available for keys. To exclude a user from the group using LKH algorithm (RFC 2627)

          we have to send as many keys, as the height of the key tree, which is determined by the group size. Let us assume 

          that we limit group size to say 16M users (really big value), then we have to send 24 keys. If we assume that the  size of each key is 256 bits

          (32 bytes) and it must be accompanied with some metadata (key ID etc.) which is 8 bytes and IV (say 8 bytes), then the size of each individual

          encrypted key is no less than 48 bytes. Which makes it barely fit in our optimistic case (with PMTU 1500).

          If we add an authentication tag to each key (16 bytes for AES-GCM), then that many keys won’t fit in any case.

          We should either decrease the size of the keys or limit the group size or complicate protocol to split these messages into many.

 

          Regards,

          Valery.