Re: [CFRG] [EXTERNAL] Re: Streamlined NTRU Prime: sntrup761

[Peter C <[e-mail]>]

Simon,

> My goal is to document how sntrup761x25519-sha512
> is implemented by several SSH implementations, so that
> goal makes aligning these documents a non-starter.  

That is what I had assumed.  However, the draft explicitly says "we offer this document for other protocols that desire to use an established hybrid key exchange method" so there is a clear intention for the hybrid construction to be used elsewhere, not just in ssh. 

> I struggle to see how SHA512(SS-SNTRUP761||SS-X25519)
> is weaker than using either of SS-SNTRUP761 or SS-X25519
> directly in any practically relevant way though.

There was a discussion about the relevance of IND-CCA security in the draft-ounsworth-cfrg-kem-combiners thread.   I think the main point is that it fundamentally depends on how the KEM is going to be used.  If you are specifying a general purpose KEM where you don't know in advance what will be needed, aiming for IND-CCA security is the safest option. 

As a concrete example, consider HPKE.  RFC 9180 requires that the KEM is (at least) IND-CCA secure so that the desired security goals for HPKE are met.  It is (probably) acceptable to use sntrup761 by itself, but it wouldn't be acceptable to use the sntrup761+x25519 hybrid construction for exactly the same reason why it wouldn't be acceptable to use X25519 without the DHKEM conversion.

If you decided to use the sntrup761+x25519 hybrid construction anyway, this could have unexpected consequences for any protocol that relied on HPKE.  It would, for example, break the suggested anti-replay mechanism in draft-ietf-ohai-ohttp.

Peter

Peter Campbell
Industry Liaison and International Standards
[e-mail]