ippsGFpECSignDSA requires user-supplied nonce

[J08nY]

The changes to make ECDSA require the user to supply the nonce are a step backwards. Repeating nonces or even slight nonce bias are huge issues in ECDSA and can lead to quite easy private key recover. See for example the Minerva or the TPM-Scan papers.

Providing such API is dangerous. Making it so that is the only API to make ECDSA signatures is a sure recipe for disaster.

[rcao8]

Thank you for posting the topic. We will further investing it and back to update here.

[ElenaTyuleneva]

Hello @J08nY !

Here are some details regarding the issue you've described:

The behavior of the recommended ippsGFpEC* API was not fundamentally changed compared with the deprecated and removed ippsECCP* API:

deprecated ippsECCP*	recommended ippsGFpEC*
... // generate and set ephemeral key pair, eph key will be stored in the signature's context pCtxS ippsECCPGenKeyPair(ephPrivate, ephPublic, pCtxS, ippsPRNGen, pRand); ippsECCPSetKeyPair(ephPrivate, ephPublic, ippFalse, pCtxS); // Compute signature ippsECCPSignDSA(msg, regPrivate, signX, signY, pCtxS); ...	... // generate ephemeral key ippsGFpECPrivateKey(ephPrivate, pCtx, ippsPRNGen, pRand); // Compute signature ippsGFpECSignDSA(msg, regPrivate, ephPrivate, signX, signY, pCtx, buffer); ...

In both cases, a nonce is managed by a developer who integrates the Intel Cryptography Primitive library in their applications.

I agree that reusing the nonce is dangerous, so the library has a mechanism to prevent such accidental errors: both functions(ippsECCPSignDSA, ippsGFpECSignDSA) set ephemeral private keys to zero inside them and by clearing the ephemeral keys within the library, we prevent the same key from being accidentally repeated several times.

Please let me know if you have any other questions.

[paveldyakov]

Hi @J08nY, could you please let us know if your question has been addressed?
We would be glad to help you more

[J08nY]

Hello @J08nY !

Here are some details regarding the issue you've described:

The behavior of the recommended ippsGFpEC* API was not fundamentally changed compared with the deprecated and removed ippsECCP* API:

I see, thanks for pointing out the changes. I was quite surprised seeing the API requiring me to supply the nonce when I was doing an upgrade of our codebase to it so I forgot it was that way before just with different functions.

In both cases, a nonce is managed by a developer who integrates the Intel Cryptography Primitive library in their applications.

I still think this is dangerous. Such low level API is usually unnecessary. I could see a use case where the developer wants to use some concrete RNG for the nonce or for example may want to use deterministic nonces as per RFC6979. However, both of those could be satisfied with having an API that requires an RNG instance and allows one to choose to do deterministic signatures when the RNG is not provided for example. Just my two cents, having seen ECDSA nonce issues in lots of places

I agree that reusing the nonce is dangerous, so the library has a mechanism to prevent such accidental errors: both functions(ippsECCPSignDSA, ippsGFpECSignDSA) set ephemeral private keys to zero inside them and by clearing the ephemeral keys within the library, we prevent the same key from being accidentally repeated several times.

This is nice, but do not underestimate a determined developer, they may just see this as a weird quirk of the API and will bypass it by duplicating the nonce beforehand.

[ValeZAA]

This is nice, but do not underestimate a determined developer, they may just see this as a weird quirk of the API and will bypass it by duplicating the nonce beforehand.

What is more optimal new API or old API that does not allow this vulnarabilty? If there is some new check in new API against this this is slower.

[ElenaTyuleneva]

I still think this is dangerous. Such low level API is usually unnecessary. I could see a use case where the developer wants to use some concrete RNG for the nonce or for example may want to use deterministic nonces as per RFC6979. However, both of those could be satisfied with having an API that requires an RNG instance and allows one to choose to do deterministic signatures when the RNG is not provided for example. Just my two cents, having seen ECDSA nonce issues in lots of places

@J08nY , thanks for the suggestion! Our team will consider extending the API to include the possibility of using a pointer to an RNG object and recommending it as a preferred mechanism for nonce handling.