On Thu, 23 Oct 2025 at 01:08, Matt Chanda <[email protected]>
wrote:

> 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 raised a PR
https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/75 to
address it.

Cheers,
-Tiru


> 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 <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]
> To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> jose mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to