What's the current status of development of hedged ECDSA and EdDSA?

In the IETF Draft Deterministic ECDSA and EdDSA Signatures with Additional Randomness, methods had been specified to seed RNG deterministically with external input, to securely obtain a nonce for use in signing formula. The external input is variable to mitigate certain side-channel that may occur with fully deterministic signing.

However, the draft seem to have expired, with several security-related issue outstanding. I'm interested in implementing the said draft, but before that, I need to be certain that what it specify is something stable.

So what's the current status of that draft? I tried to follow the link to mailing list, but to no avail.

This is an interim answer. The technical aspects are meant as outsider comment and may be reposted to the CFRG mailing list when I subscribe to it.

Bureaucracy Aspect

Although the draft is expired, the document is still in "Active RG Document" state. All? IETF drafts have maximum 6 months. Those merit further developent will see state change throughout its life.

The "Active RG Document" is defined as:

This document has been adopted by the RG and is being actively developed

Where RG stands for "research group". (CFRG being the one we're discussing here).

Technical Aspect

The updates the draft prescribed for EdDSA isn't intricate. From my experience implementing the draft, I find these issues for ECDSA.

Problem 1

The draft treats the HMAC calls as white box interaction across the boundary of HMAC-DRBG. The original intent of RFC6979 is to be able to reuse existing PRNG implementation un-modified, and the draft changed that.

Specifically, if the random nonce Z is variable length, then one of the following happens:

• the implementation make hosted calls to allocate memory for the seed material.

• the implementation penetrate the PRNG boundary and make individual calls to stream nonce and private key into the HMAC working context.

Those who has read NIST-SP-800-90Ar1 will know how serious NIST is about DRBG boundary.

Luckily for now, Z is specified to be fixed-length. And I've experimented with a 3rd approach,

• hash Z and construct seed material buffer in a statically-sized stack buffer.

Problem 2

The draft recommends KMAC when ECDSA is instantiated with SHAKE. But with one important detail missing:

• When generating output, do we use KMAC as a XOF, or fixed-length hash and call KMAC repeatedly?

And I ask this not to solicit answer, but to inspire to think, with Keccak, are we really satisfied with any of the NIST-SP-800-90Ar1 DRBGs? NIST had suggested the possibility of a permutation-based PRNG in the last few slides in one of their presentations, shoudn't we push harder and request for one be specified? possibly after another public contest?

Put up or shut up

For those interested in how the draft work in practice, I've implemented it in a branch of my spare-time project.