Hello, > However there is still one major blocker for my use of it. I still need an > algorithm for "HPKE-P256-SHA256-A256GCM" that used today, otherwise I cant > use the new standard when approved. While I dont think the format should > determine if the HPKE cipher suite is valid (HPKE should do that), or if the > algorithm strength is sufficient for the intended use (this is > sender/receiver policy), we are already past that. If we add another > "HPKE-X" algorithm or a way to handle adhoc combinations then it would work > for me. >
I still have the same problem. I have a valid HPKE cipher suite, use JOSE for communication, but the proposed standard does not have a way for me to use it because there is not a HPKE_X algorithm available. Can we add another entry for my existing algorithm? Or should I pan on adopting the RFC, except for the missing algorithm names? Regards, -matt > On Oct 11, 2025, at 7:04 AM, John Mattsson > <[email protected]> wrote: > > Ilari Liusvaara wrote: > > >The (pre-quantum) strengths of P-256 and AES-128 can not be directly > compared because scaling is different (P-256 has quadric scaling and > AES-128 has linear scaling). However, P-256 is clearly stronger of the > two. > > Yes, and the same is true for X25519, it is also (as far as we know) stronger > than AES-128 against classical attackers. Might be > > >Even worse would be trying to to match strengths of confidentiality > and authentication. See RFC9420 for an example of this going very > wrong. > > Agree. Typically, a better strategy is to go for simplicity and fewer options. > > The worst and dangerous matching I have seen in practice is people justifying > using random nonces and a fixed key with AES-GCM just because the security > against distinguishing attacks is low (< 128). This leads to much lower > practical security. With a nonce collision an attacker can recover two full > messages and compromise the integrity for the rest of the sessions. With a > distinguishing attack, the attacker can recover a negligible fraction of a > single bit of plaintext…. > https://eprint.iacr.org/2024/1111 > > Cheers, > John > > > > matching the strengths against passive attacks on confidentiality and the > > > > From: Ilari Liusvaara <[email protected]> > Date: Saturday, 11 October 2025 at 13:33 > To: [email protected] <[email protected]> > Subject: [jose] Re: I-D Action: draft-ietf-jose-hpke-encrypt-12.txt > > On Sat, Oct 11, 2025 at 12:31:57PM +0530, tirumal reddy wrote: > > > > For the P-256, the equivalent symmetric security level is 128 bits, it > > should be paired with the AES-128 algorithm for a matching security > > strength. > > The (pre-quantum) strengths of P-256 and AES-128 can not be directly > compared because scaling is different (P-256 has quadric scaling and > AES-128 has linear scaling). However, P-256 is clearly stronger of the > two. > > Even worse would be trying to to match strengths of confidentiality > and authentication. See RFC9420 for an example of this going very > wrong. > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ > jose mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
