Subject: Re: [Cfrg] Deterministic signatures, revisit?

From: denis bider <[email-masked]>
Date: Mon, 9 Oct 2017 23:01:33 -0500

Aren't the devices that are most susceptible to fault injection also least
likely to implement a secure PRNG? My understanding is that these might be
embedded devices, which often use PRNG based on a seed that's a simple
timestamp, or even a hardcoded seed.

Deterministic signatures have the property of being deterministic, i.e.
there's a 1-to-1 mapping between { message, key } and { signature }. This
makes the signing process idempotent, which could be useful in distributed
systems. The deterministic property might also be welcome in forensics.

Is it not cost-effective, or safe, to add mitigations such as the device
verifying the signature, or the results of intermediate steps, before
releasing the signature?

If such mitigations are not viable, is injecting randomness into the
signing process effective, if the devices most susceptible to fault
injection are also likely to implement insecure PRNG?

----- Original Message -----
From: Tony Arcieri
Sent: Monday, October 9, 2017 12:30
To: Dan Brown
Cc: Cfrg
Subject: Re: [Cfrg] Deterministic signatures, revisit?

This certainly keeps coming up. Beyond those papers see the previous "Side
channel attack and Edwards curves" thread on this list:

https://mailarchive.ietf.org/arch/msg/cfrg/V1JXfnf05uE88huYaQVKi7iZ6mY

I think it's definitely a problem that needs to be addressed. I've seen
various proposals to do so as well, i.e. synthesizing "r" as a combination
of a random nonce and the message, so that fault attacks would, at the very
least, require an RNG failure as opposed to always being possible, due to
repeated "r" values for the same message. This should retain the extant
defense against RNG failures in general as we saw with ECDSA "k" values,
since it would still include hashing the message as part of the calculation.

--
Tony Arcieri

_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg