Subject: [Cfrg] My thoughts on randomized signature generation

From: Watson Ladd <[email-masked]>
Date: Tue, 5 May 2020 08:35:56 -0400

Dear participants,

I apologize for the long delay between the virtual meeting and this
email. I'm writing to expand upon my opposition at the mike to
distinguishing between interoperable signatures based on the method of
generation.

My opposition is rooted in the following facts: the signature
generation method doesn't introduce any incompatibility with existing
verfiers, and the existing installed verifiers expect the already
allocated codepoints. A new system using randomized generation that
doesn't use the existing codepoints will thus be incompatible. It
would of course be possible to avoid this, and the right way is simply
to use the existing codepoints rather then implement the less secure
generation method.

Sincerely,
Watson Ladd

---

From: Sofía Celi <[email-masked]>
Date: Fri, 8 May 2020 09:32:10 -0500

Hi, Watson and list,

Thanks so much for sending this.

I agree with Watson on the problems that this will introduce, and that
this have to be taken into account carefully.

I'll also like to raise some doubts around introducing this for RFC8032.
That RFC specifies already certain security recommendations for
side-channel leaks and as well as randomness considerations in what
seems to concern the RFC. The RFC seems also to concern only about the
algorithm itself, and just expects the private key to be
cryptographically secure random data, following RFC4086. I haven't
correctly reviewed RFC4086, but maybe this can be the place to correctly
define the requirements for randomness, specifically for IoT deployments.

Apologies if this wasn't the place to send this, but I found no other place.

Thanks!

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places
FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 May 2020 13:38:17 -0400

I agree with Watson's conclusion but for the opposite reason.

If you follow the MtGox saga you will know that a particular malleability
attack was claimed as the reason for the disappearance of the funds.

The use of deterministic signatures sets up similar opportunities for
attack. While I have not identified a specific exploit, I don't see the
need. It is clear that this is an area where the construction of the
signature algorithm invites the relying party to rely on a property of the
signature that is not actually guaranteed by the algorithm itself.

That is just bad practice.

The only circumstance in which I would want to be able to distinguish these
specific cases is if I had bought a HSM and wanted to verify it was
generating k in a principled fashion. There is a genuine problem that
arises from having HSMs act non deterministically. As Moti Yung pointed
out, your RSA keygen can be encrypting the random seed used to generate a
key pair and using the public key itself as the side channel.

So I support adding a non deterministic mode of signature generation.
Recognizing the fact that once you do that, there is no way to prohibit
online/offline signing and pregenerating values of k.

On Tue, May 5, 2020 at 8:36 AM Watson Ladd <[email-masked]> wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 May 2020 13:44:13 -0400

> define the requirements for randomness, specifically for IoT deployments.

Correctly stated, the requirement is for unguessability, not randomness.

That it is random is a necessary but not sufficient condition. It is the
unguessable part that is hard.

One approach that I think lends itself very well is to make use of a KDF
over a device specific secret with the salt input including a counter
value. But for robustness, I would also want a value depending on the key
pair, the purported date time, etc. etc.

At the end of the day, if the attacker knows the initial internal state of
the device and all the communications between the device and the outside
world, they are going to be able to emulate that device.