I'm working on an application that involves signing a 32 byte random number generated by the OS. Assuming the RNG works as intended, is it safe to sign the random number itself rather than a hash of the random number?

I'm asking because time is an issue and -if possible- I would like to avoid the few ms it takes to do the hashing.


  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$ – SEJPM Apr 15 '19 at 20:26

Yes, but you probably need to use a cryptographically secure RNG from your OS. Otherwise the input to the signature generation function may be mathematically linked, and the security of the system is not guaranteed. It is of course wise to use a 256 or higher curve, otherwise the security provided by the random number may be lowered.

Besides compressing the input, the hash is used to generate pseudo-random input to the signature generation function. It removes any mathematical links between the input values as cryptographic hash functions are one-way. However, using a small enough, random / independent values should already meet these requirements.

Random number generation by the OS is likely to be significantly slower than performing a single hash over a single block of input.

In that sense you could think of using 128 bit numbers instead of 256 bits and perform full ECDSA on that. You could also think of using deterministic ECDSA as specified in RFC 6979. These changes may well have a larger impact than removing the relatively fast hash from ECDSA. And you'd still be standard-compliant to boot; all of the security requirements on ECDSA would still be met.

| improve this answer | |
  • $\begingroup$ In modern Linux kernels, the output of /dev/urandom and getrandom(2) comes from ChaCha20 applied on an entropy pool, which is faster than computing a hash. It was redesigned to be faster than using hashing algorithms, while still being a CSPRNG. $\endgroup$ – A. Hersean Apr 15 '19 at 15:14
  • $\begingroup$ Interesting. Of course, you'd still have the OS calling overhead, the initiation of the platform RNG and the advance of e.g. hardware accelerated SHA-256 to take into account, but it could be that the RNG is now faster than the hash for sure on Linux. In the end this will come down to platform specifics. $\endgroup$ – Maarten Bodewes Apr 15 '19 at 15:59
  • $\begingroup$ Thanks for the quick response and the excellent explanation! $\endgroup$ – monkeyPunchingRobots Apr 15 '19 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.