Can I get away with generating 512-bit k (and d) for ECDSA based on P-521?

Question

I've been implementing a hobbyist cryptography library, and I'm at the part where elliptic-curve cryptography is being implemented. I've already implemented and tested ECDSA with P-256 and P-384, where static and ephemeral private keys are 256-bit and 384-bit each, so far so good.

What's bothering me is P-521. I'm planning to generate 512-bit static ($d$) and ephemeral keys ($k$) to ease implementation, since most hash functions (excluding XOFs) have at most 512-bit output (I'm not using hash functions to generate the keys directly, I'm just allocating stack space according to the output length of typical hash functions).

If I do this, the resulting signature component $s$ may have some kind of bias, but since the product of $d \cdot k^{-1}$ will overflow $n$, I'm having the pseudo-belief that this is not too serious a problem.

So I ask 2 related question:

Q1: can I get away with generating 512-bit static and ephemeral keys for ECDSA over P-521 and not harm security?

Q2: for general case, given a prime modulus $n$, an adversary is given $s = k \cdot r + d \pmod n$ and $r$, where $d$ is static and $r$ is deterministically randomly computed from $k$; both $k$ and $d$ have less than $\lceil {\log_2{n} \over 4} \rceil$ of top bits chopped off; can the adversary obtain any part of $d$ or $k$?

Answer 1

Don't do this!

Biases in ECDSA nonces across multiple signatures will leak the signing key over time. See for example the paper Biased Nonce Sense: Lattice Attacks against Weak ECDSA Signatures in Cryptocurrencies by Breiner and Heninger.

The general Q2 is known as the hidden number problem and it is indeed this problem that is solved in the paper when multiple $r$ and $s$ are provided.

Answer 2

No! Even generating a 520-bit $k$ is likely an exploitable vulnerability.

A 2020 result on the topic is LadderLeak: Breaking ECDSA With Less Than One Bit Of Nonce Leakage. §5 discusses the cost estimate for the attack: it's not really feasible for a single-bit bias beyond P256, but larger biases allow cheaper attacks, and attacks only get better with time.

Use deterministic ECDSA unless you have a good reason to use randomized ECDSA. Deterministic ECDSA can use HMAC_DRBG as a black box: you just have to instantiate HMAC_DRBG with the requisite parameters. An advantage of this being a deterministic algorithm is that if your known-answer tests give the expected results, you have a fairly high amount of confidence that you've implemented it correctly. Most systems that do signatures have a RNG anyway, and HMAC_DRBG is a pretty good DRBG (not the fastest, but relatively easy to implement and FIPS-compliant).

If you use randomized ECDSA, I recommend implementing it by doing deterministic ECDSA and feeding extra randomness into HMAC_DRBG. This way, if you do the randomness part wrong, it will at worst degrade to deterministic ECDSA, without any risk of leaking the nonce. There are two reasons why you might prefer randomized ECDSA: if it's a security objective that an adversary can't tell whether two signatures produced separately happen to be for the same message (an uncommon security objective), or because it can make some side channels or fault injection weaknesses harder to exploit (on the flip side, it can also make some weaknesses easier to exploit).