if Decaps fails, return a decrypt_error?

[dconnolly]

We should align -hybrid-design to do the same

[dconnolly]

Would we even be able to detect this with reasonable probability? Seems like no

[dconnolly]

There was a push to change the parsing logic for ML-KEM public keys to never fail, by silently reducing, without changing the hash of the public key. I am not sure if NIST ended up adopting that change for their final standard (I hope they did, I think it's the best way to handle this problem), which would mean that any appropriately sized binary string is a valid ML-KEM public key. For ciphertexts, this property is already the case, due to the compression that is applied in ML-KEM. If NIST incorporated this change, there would be no way for the ML-KEM based key agreement to fail explicitly, any failure would result in an implicit rejection.
In the end, this seems to be the same as with elliptic curves as is as well, point-not-on-curve checks can result in an explicit rejection of a keyshare (for the curves where it can occur), and manipulation of the keyshare (by an attacker or some accidental bit flip that somehow was not caught) would result in an implicit rejection here as well, with server and client computing a different shared secret. The only new possible error path I see is due to random decryption failure of a KEM, but given the cryptographically low chance, I'm not certain if this failure needs special handling in any case, and shouldn't be treated the same as a corrupted key share. After all, they are so unlikely that "cosmic rays flipped all the right bits for QUIC error correction to not notice" is far more likely to result in a decryption error, so treating it the same as a decryption failure due to a corrupted ciphertext seems fine to me.

https://mailarchive.ietf.org/arch/msg/tls/eYUG4DDkfoaGeMAkZHVGGeqcVq0/

[dconnolly]

Decided with no