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

[Natanael <[e-mail]>]

Den tors 20 apr. 2023 09:42Valery Smyslov <[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.

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

*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.

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

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.

>