Hacker News new | ask | show | jobs
by Kikawala 793 days ago
If you haven't already, this is probably a good time to switch to EdDSA keys. EdDSA signatures don't require RNG nor modular math unlike ECSDA signatures.
3 comments

EdDSA signatures are specified to use deterministic nonce generation, so you're correct that they do not require randomness. But they certainly do require modular arithmetic in order to implement the elliptic curve operations!
Despite being fairly old, many systems still don't support eddsa. As an example, the reference browser/ca spec doesn't allow it: https://cabforum.org/working-groups/server/baseline-requirem.... Last I tried, even let's encrypt won't grant an ed25519 cert despite it being in tls 1.3 (2018?).
> Last I tried, even let's encrypt won't grant an ed25519 cert despite it being in tls 1.3 (2018?).

Talk to the CA/Browser Forum. §6.1.5 Keys Sizes:

> For RSA key pairs the CA SHALL:

> * Ensure that the modulus size, when encoded, is at least 2048 bits, and;

> * Ensure that the modulus size, in bits, is evenly divisible by 8.

> For ECDSA key pairs, the CA SHALL:

> * Ensure that the key represents a valid point on the NIST P-256, NIST P-384 or NIST P-521 elliptic curve.

> No other algorithms or key sizes are permitted.

* https://cabforum.org/uploads/CA-Browser-Forum-TLS-BRs-v2.0.2...

* https://cabforum.org/working-groups/server/baseline-requirem...

Ed25519 (and Ed448) was only 'recently' approved by NIST FIPS 186-5 in February 2023.

Then make your own CA.
I don’t think RNG or modular math were really the culprits here. PuTTY’s k value generation is deterministic and the biasing was caused by a mismatch of integer sizes and the resulting leading zeros. The offending operation is named mod, so that’s related to modular arithmetic, but the modulo (521 bits) was bigger than the SHA512 output (512 bits) from deterministic k generation. I linked earlier to a post where I break this down at the source code level.