Re: Less Leaky ECDSA signature generation (in master)
Alicja Kario via Gcrypt-devel <[email protected]> Thu, 27 Mar 2025 11:34:44 +0100
| Newsgroups | gmane.comp.encryption.gpg.libgcrypt.devel |
|---|---|
| Organization | Red Hat |
| Message-ID | <[email protected]> |
On Thursday, 27 March 2025 03:05:28 CET, Jacob Bachmeyer via Gcrypt-devel wrote: > On 3/26/25 19:06, NIIBE Yutaka via Gcrypt-devel wrote: > [...] For the first improvement, > I realized that runtime checks in ec_mod and its friends could be leaky, > because it depends on how small/big the value is. > Could these checks instead be improved to run in constant time? > > Since it is (or can be) precondition for those routines in the code of > libgcrypt, it can be removed. Since it could be leaky, it's good to be > removed. > Hypothetically, if those preconditions are violated, what could > go wrong? How badly does the math fall apart? Could an invalid > result potentially (partially) expose the signing key? > Removing runtime checks in this type of code makes me nervous. > Maybe it is just paranoia. All operations on a curve are performed on a ring. There's no mathematical reason to make sure that representations of smaller integers are stored in fewer bytes of memory and thus can skip some computations. Multiplying zeros together gives zero outputs, doesn't matter if they're implicit or explicit. The only possible problem is if the lower level code assumes that the most significant words are not zero, but that should be easy to check... -- Regards, Alicja Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic _______________________________________________ Gcrypt-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel