Re: [Cfrg] My thoughts on randomized signature generation

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 <watsonbladd@gmail.com> wrote:

> 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
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>