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). Maybe sending two UDP datagrams is the solution? Or sending less keys and use a KDF to derive some of the keys? - 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. - 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… 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, "") Cheers, John From: CFRG <cfrg-boun...@irtf.org> on behalf of Valery Smyslov <smyslov.i...@gmail.com> Date: Friday, 21 April 2023 at 09:44 To: 'Natanael' <natanae...@gmail.com> Cc: c...@ietf.org <c...@ietf.org>, 'IPsecME WG' <ipsec@ietf.org> 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 <smyslov.i...@gmail.com<mailto:smyslov.i...@gmail.com>> 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<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> 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.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
