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 <[email protected] <mailto:[email protected]> > on behalf of
Valery Smyslov <[email protected] <mailto:[email protected]> >
Date: Friday, 21 April 2023 at 09:44
To: 'Natanael' <[email protected] <mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>
>, 'IPsecME WG' <[email protected] <mailto:[email protected]> >
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:[email protected]>
[email protected]> 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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
