Re: [CFRG] Google's (current) Threat model for Post-Quantum Cryptography

[Orie Steele <[e-mail]>]

Sophie,

Thank you and your co-authors for this thoughtful post.

The recommendation to use hybrid signatures for software signing, is noted
to have a "relatively relaxed timeline."

I imagine HSM support for hybrids takes a long time to develop, and in the
meantime CMS and COSE will be seen as incompatible with these
recommendations.

I agree that it would be simple to "sign twice and concatenate, verify with
&&" ...  that sounds like a generic combiner strategy to me : )

... We've got some slides for the PQUIP session at IETF 119 to help think
about this.

Making a recommendation to use hybrids, without offering a shared building
block is inviting an alternative interpretation... If that alternative view
gets burned into hardware... I think that would be unfortunate, if it were
so easily avoided... Is this an imagined risk, or a real one?

I also agree with Stephen, that CFRG consensus could save working groups a
lot of time.

I see two ways that time could be saved:

1. CFRG chills out wrt hybrid signatures, and everyone hears the message
and gets the time back.
2. CFRG recommends one or two experimental hybrid signatures, built on a
simple combiner like the one you mentioned.

People who's paranoia prevents them from ever chilling out can implement
these signatures, and provide feedback on the process... and since there is
a limited number of them, CFRG has done its best to limit the timeloss /
damage.

Perhaps smaller PQ signatures emerge in the next few years, and make it
through NIST's process, and we're confident enough to deploy them without
using hybrids.

Thanks again.

OS

On Tue, Mar 12, 2024 at 6:08 PM Sophie Schmieg <[e-mail]> wrote:

> The hybrid recommendations are somewhat intentionally kept vague in order
> to not add yet another hybridization scheme by accident :)
> The unfortunate reality we have to deal with is that we have to use P256
> for compliance purposes in some scenarios, but among hybrids X-Wing is
> currently looking the strongest and is using X25519. I would much prefer
> having a single clear scheme that we could recommend there.
> I do think there is some urgency on the KEM hybridization, because I fear
> that we will see an explosion of different hybrid schemes once the NIST
> standards are out, unless there is a clear go-to choice.
> In a way this is in my opinion an extension of the mess we have with key
> derivation functions in general, where every protocol does their own
> similar but incompatible thing. The worst offender there is ECIES, where it
> took us an embarrassingly long time to finally standardize HPKE.
>
> For signature hybrids, I honestly think just using the simple "sign twice
> and concatenate, verify with &&" hybrid scheme is good enough to eventually
> win even in absence of a standard.
> But yeah, I think in general signatures are far more experimental at this
> point in time, many use cases will require more of an exploratory
> approach, which definitely makes getting the hybrid right on first try less
> of an urgent problem.
>
> On Tue, Mar 12, 2024 at 3:24 PM Stephen Farrell <[e-mail]>
> wrote:
>
>>
>>
>> On 12/03/2024 22:04, Orie Steele wrote:
>> >> Our current recommendation is to use either Dilithium3 (FIPS 204,
>> ML-DSA)
>> > in hybrid with ECDSA/EdDSA/RSA, or SPHINCS+ (FIPS 205, SLH-DSA) for this
>> > use case.
>> >
>> > I fear how many different variants of these we may see in protocols
>> without
>> > some baseline guidance from CFRG.
>>
>> I prefer the bits saying to mostly not worry about signatures
>> for now and chill out a bit wrt those. (yeah, my interpretation:-)
>>
>> If we did pay attention to that (and we should) I think it takes
>> away most of the problem with hyrbid combnbatorics.
>>
>> I'd love it if cfrg had consensus on something like that as I
>> think it'd save a bunch of IETF WGs a bunch of time over the
>> next couple of years.
>>
>> Cheers,
>> S.
>>
>> _______________________________________________
>> CFRG mailing list
>> [e-mail]
>> https://mailman.irtf.org/mailman/listinfo/cfrg
>>
>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto |
> [e-mail]
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>