We just included a Cryptographically Secure Pseudo-Random Number Generator ( #CSPRNG ) into our #OpenSource #SynCrypto unit.
We just included a Cryptographically Secure Pseudo-Random Number Generator ( #CSPRNG ) into our #OpenSource #SynCrypto unit.
The TAESPRN #Delphi class would use real system entropy to generate a sequence of pseudorandom bytes, using #AES -256, so returning highly unpredictable content.
It was designed as a trusted source of randomness, e.g. for key/nonce/IV/salt/challenge generation, on Windows and Linux.
Any feedback is welcome, since the more eyes on #crypto material, the better…
http://blog.synopse.info/post/AES-CSPRNG
The TAESPRN #Delphi class would use real system entropy to generate a sequence of pseudorandom bytes, using #AES -256, so returning highly unpredictable content.
It was designed as a trusted source of randomness, e.g. for key/nonce/IV/salt/challenge generation, on Windows and Linux.
Any feedback is welcome, since the more eyes on #crypto material, the better…
http://blog.synopse.info/post/AES-CSPRNG
AFAIK CryptGenRandom in modern Windows versions is based on AES pseudorandom generator itself; the article linked is outdated. BTW the next TForge release will include ChaCha20-based secure PRG.
ReplyDeleteWhy did you decide to apply a key derivation algorithm to the entropy obtained from OS? Just wondering :).
I was recently looking into SHA3, I would guess the Keccak 'sponge' formula would fit in nicely here instead of PBKDF2-HMAC-SHA256, but I'm not an expert.
ReplyDeleteSergey Kasandrov There is almost no info about CryptGenRandom internals since Vista. Microsoft stated that "weaknesses have been fixed since XP SP3", but we do not know which cypher is used. AFAIR it is was RC4 + SHA1, but there is no official statement about what was changed since Vista. Anyway, I won't trust such a black box to be used directly as PRNG. This is why I wrote a CSPRNG based on AES-256 on top of it. Now I'm sure it is safe to use its output (unless AES-256 is broken, but it was not reported as such).
ReplyDeleteSergey Kasandrov About PBKDF2, it was to avoid any brute force attack to guess the private key, if entropy returned by the OS is low. A few rounds is able to make any brute force search much harder. This is for sure the paranoid part of this implementation. But it would not hurt, I guess.
ReplyDeleteHMAC improves statistical properties of low-entropy keys; HMAC-based key derivation algorithms also protect (to some extent) against table-based attacks on low-entropy keys. I never seen SHA3/Keccak being used for that purpose, and don't recommend to experiment.
ReplyDeleteIf you don't trust OS as an entropy source, the best you can do is to ask user for an entropy data and "xor" the user-provided data with the OS-provided data. "Xor"ring two sources of entropy never makes the output worse, even if one of the sources is deterministic.
Sergey Kasandrov XORing the values returned by the OS with the high-resolution timestamp is in fact what our implementation does, before running PBKDF2-HMAC. This is very poor, but better than nothing. The main safety of this implementation is based on PBKDF2-HMAC and AES features, not on the source of entropy itself.
ReplyDeleteA. Bouchez I've seen the crypto PRG's used in OpenSSL and LibreSSL, they are not so paranoid as yours :). AFAIR they just rely on OS as a source of entropy, and use the entropy provided by OS as a key material directly.
ReplyDeleteWhy not use the approach used by Linux, have an entropy-pool based on HD (if spinning,not SSD) delays, keyboard, mouse, network timings in nanoseconds (which is where the TSC comes in :)
ReplyDelete/Sub
ReplyDeleteJohan Bontes This exactly what our class does, from OS calls.
ReplyDeleteA. Bouchez see https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx :
ReplyDelete"To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then combined with both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is used to seed the pseudorandom number generator (PRNG). In Windows Vista with Service Pack 1 (SP1) and later, an implementation of the AES counter-mode based PRNG specified in NIST Special Publication 800-90 is used. In Windows Vista, Windows Storage Server 2003, and Windows XP, the PRNG specified in Federal Information Processing Standard (FIPS) 186-2 is used."
Sergey Kasandrov I missed this info. Thanks for pointing it out. But AES with how many bits? What is the reseeding period? A dedicated CSPRNG in the library allows consistent security among all versions of the OS.
ReplyDeleteSergey Kasandrov
ReplyDeleteThe problem is you can't trust MS to do a good job on this. AES looks secure enough and can be validated, but whether these proprietary 'random' sources are really random or whether they are crippled is unknowable. Best not to take chances.
Some reference links: https://eprint.iacr.org/2013/338.pdf and https://www.schneier.com/blog/archives/2013/10/insecurities_in.html#c1909001
ReplyDeleteI've found https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J refreshing... ;)
/.
ReplyDelete"It would use AES-NI or Padlock hardware acceleration, if available." - hopefully there would be a way to bail out of using those functions. Because if to talk about trusting, hem Microsoft is no worse than Intel and VIA
ReplyDeleteArioch The
ReplyDeleteyou can trust the hardware AES et al functions, because you can verify these against software. But I would never trust a black box random generator
Johan Bontes see... those instruction might work okay with most of the tests until some pre-set conditions are met. When Chinese set their backdoors into intel server chipsets - everything is possible now, bluepill demo, remember...
ReplyDeleteArioch The Yes, I've read some paranoid plots about this, like having the CPU storing the keys in some hidden space, then let the keys be sent using low-level hidden code directly from your Ethernet controller to government servers... ;)
ReplyDeleteFor a random generator, I would not mind having the keys sent, if they are here to generate nonce and salt. It would just fill government servers for nothing...
But sounds to me over-complicated... A system-wide backdoor should be easier to setup and use, especially in a closed source OS...
Of course, you can disable AES-NI in SynCrypto: just exclude the cfAESNI flag from the global CpuFeatures variable defined in SynCommons.pas.
> especially in a closed source OS
ReplyDeletethere is no point to be paranoid about closed-source OS and at the same time be trustful about closed-source chip
> Of course, you can disable AES-NI
...and PadLock. I guess that to be added to dpcumentation about this class