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

[Valery Smyslov <[e-mail]>]

Hi John,

 

thank you for the comments, please see inline.

 

 

Hi Valery,

 

Some quick commments.

 

- If the G-IKEv2 engine is not trusted to access information inside the messages,

it should probably not be trusted to modify the keys. Chaning the keys would

get however is in control of the G-IKEv2 engine access to information

encrypted with the keys. (The G-IKEv2 can force key reuse as Natanael writes).

 

            G-IKEv2 engine is trusted to the extent that it will not voluntarily do any bad thing.

            There are basically two reasons to not expose keys in clear to the G-IKEv2 engine.

            First, despite the fact that we trust it, generally the engine may be more vulnerable

            to some side-channel attacks compared to crypto engine. For example,

            its memory may not be as protected as crypto engine's memory,

            there may be some electromagnetic emission issues, not existent 

in crypto engine which may be a specially designed HSM, and the like.

            Second, usually all the keys reside in crypto engine and never leave it in clear, only in wrapped (encrypted) form

            (I think that most crypto API don't even allow to export keys in clear, but I may be wrong).

 

            So, you can imagine the situation that we have two crypto engines -

            one on a Group Controller and the other on a Group Member and

            we want to transfer a key from the former to the latter.

            In this situation we usually wrap the key, transfer it (even via a protected channel)

            and unwrap on receiver. The idea was to use IKEv2 encryption transforms

            (which in many cases are in fact AEAD transforms these days) to also

            wrap/unwrap the keys, but since we know that the channel is protected,

            only use an encryption/decryption service of these transforms.

            

Maybe sending two UDP datagrams is the solution? Or sending less keys and use

a KDF to derive some of the keys?

 

            Sending multiple UDP datagrams is possible, but would complicate the protocol.

            Currently it is assumed that rekey is done with a single UDP datagram.

            Using KDF looks less desirable, it is assumed that all keys are independent

            and there is no correlation between them.

 

- I don't think "pure encryption algorithms" is a good term. Authenticated

encryption is "pure encryption" for IND-CCA confidentiality. I.e., confidentiality

against active attackers.

 

            It was an "ad hoc" term, I'm sure it is far from perfect.

 

- I think is it very good to have a discussion on IND-CPA encryption and APIs for that.

While AEAD has a standardized interface C = E(K, N, P, A) in RFC 5116, IND-CPA

encryption do not. The lack of IND-CPA encryption without message expansion and

the lack of a common API are problems. We discussed this in a paper we just

submitted to the NIST LWC workshop.

 

https://github.com/emanjon/Publications/blob/main/Proposals%20for%20Standardization%20of%20the%20Ascon%20Family.pdf

 

The DTLS 1.3 and QUIC specifications use AES-ECB which is secure in their case as the plaintext is a single block, but

I have met people believing that AES-ECB is now ok in general as DTLS and QUIC use it. It would have been easier if each AEAD algorithm had an IND-CPA mode. But people using IND-CPA when they should not are also a big problem…

 

            I understand.

 

How should a general interface for IND-CPA look like? Should it be

 

C = E(K, N, P)

 

or should it be a special case of the AEAD interface with a zero length tag and A = ""?

 

C = E(K, N, P, "")

 

            Or with a NULL (if we map this to C++)?

 

            C = E(K, N, P, NULL)

 

            Regards,

            Valery.

 

Cheers,

John

 

From: CFRG <[e-mail] <mailto:[e-mail]> > on behalf of Valery Smyslov <[e-mail] <mailto:[e-mail]> >
Date: Friday, 21 April 2023 at 09:44
To: 'Natanael' <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >, 'IPsecME WG' <[e-mail] <mailto:[e-mail]> >
Subject: Re: [CFRG] Use of AEAD algorithms as pure encryption algorithms

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/> 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> 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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-86146c33258534f8&q=1&e=1376b3f0-373e-43c7-a61f-75309f93706a&u=https%3A%2F%2Fgithub.com%2Faws%2Fs2n-tls%2Ftree%2Fmain%2Fscram> 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.