1

I am trying to use this ECDSA implementation in Haskell, if you look at line 15, you will see that the k value uses randomRIO which uses the global random number generator the getter of which uses the theStdGen which uses mkStdRNG which makes the seed by:

(current seconds on the wall clock) * 12345 + (current picoseconds on the wall clock) + (the number of picoseconds of CPU time used by the current program)

Is this good enough for signing data which is worth billions of US dollars?

Edwin Jose Palathinkal
  • 635
  • 5
  • 12
  • 1
    I wouldn't use random numbers, no matter from which CSPRNG, for `k` at all. IMO a hash of the private key and message is much safer. See [RFC6979 - Deterministic Usage of the Digital Signature Algorithm (DSA)](http://tools.ietf.org/html/rfc6979) for a full specification. – CodesInChaos Nov 09 '13 at 11:32
  • @CodesInChaos Written by Thomas Pornin, I feel safer already :) What do you think Codes, if I look at the implementation of the random number generator, I don't see any significant method of maintaining state (over 32 bits). And although I don't read Haskell normally, it could even be 30 bits. That I would not consider safe. – Maarten Bodewes Nov 09 '13 at 13:17
  • Randomness is *critical* for (EC)DSA. If there isn't enough entropy, you'll leak your private key when you sign anything. https://www.imperialviolet.org/2013/06/15/suddendeathentropy.html – ntoskrnl Nov 09 '13 at 15:27
  • @CodesInChaos Say I get the k using RFC6979, but what about the private key? Even RFC6979 says I should get the private key randomly, although it need only be done once. – Edwin Jose Palathinkal Nov 09 '13 at 15:30
  • Get the private key from a proper crypto PRNG. `CryptGenRandom` on windows and `/dev/urandom` on Linux. I don't use haskell so I don't know what high level wrapper to use. – CodesInChaos Nov 09 '13 at 15:41
  • Thanks. I trust /dev/urandom but I have issues with CryptGenRandom. I also want to program JCOP Java Cards in future, so I will have to hard code the private keys generated from a system outside. What are your opinion of random keystrokes and mouse clicks as a source of randomness, are they any good? – Edwin Jose Palathinkal Nov 09 '13 at 15:58
  • Random keystrokes and mouse clicks are not fit for your purpose. JCOP cards are perfectly capable of creating EC key pairs on card by the way - and if you want to use these cards for private keys with a higher level security, importing them from software does not make too much sense. You will probably need a protocol that allows updates of the private key anyway. – Maarten Bodewes Nov 09 '13 at 17:15

1 Answers1

1

In general, the answer would be no. If you are considering the use case the only real option is to use a FIPS or Common Criteria certified HSM. The FIPS and CC-evaluation must be of a recent date, and must be valid for ECDSA. Only an expert should be allowed create the key management protocol around it. Another expert should validate this protocol and the usability of the HSM. The choice of named parameters of ECDSA should be part of the protocol and should not be taken lightly.

Now for your Haskell RNG. You should not be using the current implementation as the random number generator certainly is not up to par. It may use insecure seeds (as you may already have found) and seems to keep insufficient state (anything that says, use Integers, why not, in the comments should not be trusted). I don't see any hash or HMAC being used to generate new random numbers or state either, so I don't see how this implementation generates secure random numbers at all.

A quick look on the internet has strengthened my suspicions:

http://tommd.wordpress.com/2010/09/02/a-better-foundation-for-random-values-in-haskell/

Notice the experimental tag at the time of writing:

http://hackage.haskell.org/package/crypto-random-api-0.2.0/docs/Crypto-Random-API.html

Now if you are really developing signing for something worth billions of dollars, please make yourself manager and hire an expert (& listen to the expert).

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263