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

Yes, ideally if FIPS 203 does what NIST says they intend, regarding the key
seed, then all of this is moot. Currently the draft as written allows the
LEAK binding of PK and CT and is weak enough to mitigate. If they change it
correctly, all of this is moot and I'll be very glad 🤞🤞🤞

On Fri, Apr 12, 2024, 9:35 AM Sophie Schmieg <sschmieg@google.com> wrote:

> 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
>
>