Jack Grigg writes:
> As the paper states at the top of page 4, X-Wing includes the recipient's
> X25519 public key "as a measure of security against multi-target attacks,
> similarly to what is done in the ML-KEM design".
Thanks for the data. Assuming arguendo that this matters (as in my first
message), the basic risk to consider is that people end up mixing
* a combiner that doesn't hash the post-quantum KEM public key
because it expects the KEM to do that and
* a KEM that doesn't hash the public key because it expects the
combiner to do that,
so that KEM's public key doesn't end up getting hashed at all.
Given the basic goal of helping auditors, I think we should settle on
principles of (1) always using double encryption, (2) having as few
combiners as possible, and (3) having the combiner responsible for
hashing public keys and ciphertexts along with the shared secrets.
Rationale for assigning responsibility to the combiner rather than to
the underlying KEM: (1) KEM designs and analyses are already hard, with
breaks often taking years to appear---see the graph on slide 11 of
https://cr.yp.to/talks/2024.01.11/slides-djb-20240111-pqcrypto-4x3.pdf
for the timeline of breaks so far of round-1 NIST submissions---and
adding more goals makes it harder. (2) KEM designs typically focus on
IND-CCA2. Properties beyond IND-CCA2 might be achieved as experiments or
accidents, but treating those as stable commitments is unjustified and
unsafe. (3) We know how to convincingly analyze a combiner as a separate
module, as in https://eprint.iacr.org/2018/024, starting purely from
IND-CCA2 assumptions on KEMs. (4) The arguments for multiple KEMs are
stronger than the arguments for multiple combiners. Having just one
combiner, and thus just one universal review of whether ciphertexts and
public keys are adequately hashed, seems more feasible than having just
one KEM.
---D. J. Bernstein
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
