Re: [Pqc] [lamps] [EXTERNAL] Re: CMS Kyber: include PK and CT in the KDF?

The binding situation of ML-KEM are actually quite good: As long as the
private key is not mal-formed, it is robust against any misbinding (it is
MAL-BIND-K-CT and MAL-BIND-K-PK if the attacker has to give a seed that
produces the private key). In other words, the only misbinding properties
it has require the protocol to involve revealing a private key or accepting
private keys from third parties. I consider that to be very strong
misbinding guarantees. Compare and contrast with RSA-KEM or ECIES without
hashed in ephemeral public keys, neither of which have HON-BIND-K-CT, and
in the case of RSA-KEM not even HON-BIND-K-PK (ECIES without hashing public
keys does not have MAL-BIND-K-PK).

I do think just using the shared secret of ML-KEM is fine in almost all
protocols, and protocols using KEMs that are not currently secure against
misbinding will even get an upgrade.

On Fri, Apr 12, 2024 at 8:34 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org> wrote:
>     > I still would like to see an analysis of whether the PK is always
> available
>     > at decryption time. I would like to hear from smartcard, HSM, IoT,
> TPM type
>     > people about whether it's fair to assume that the CMS / JOSE / COSE
> / etc
>     > layer of a decryption routine will have access to the public key at
>     > decryption time, or whether that will force some folks into awkward
>
> It's not an argument that one sees at all levels of API today, but I think
> it
> could be added.
>
>     > re-architecturing exercises. For example, if someone has a TPM
> architecture
>     > where only the wrapped private key is stored locally (cause why
> would you
>     > ever need to encrypt for yourself?), then I could see that being an
> annoying
>     > architecture change to also keep the public key. On the other hand,
> ML-KEM
>     > is greenfield, so maybe it's ok to say "When ML-KEM; your private
> key object
>     > MUST contain the public key".
>
> +1
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>

-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschmieg@google.com