Random Numbers

[mar]

What I'm working on is a very simple text editor with a password feature to use to store the many passwords you end up with if you are active on the internet. I'm an encryption noob, what advantage would a crypto-secure RNG give, just harder to decrypt?

Best
Dan H.

I'd suggest this:
- generate 16-byte salt using good PRNG, store this along with data each time you encrypt a file
- salt is appended to password when generating IV
- use several iterations (nesting) of crypto-secure hash function to generate IV (sha-1, ...) => first hash pwd + salt, then the output and so on
- use 256-bit AES symmetric block cipher to encrypt data itself
- I would also append random garbage generated using PRNG to pad data at the end of file to match AES block size
- and don't forget to clear password plaintext in memory after (de/en)cryption (the same applies to actual text before your app exits!)

I probably wouldn't bother with password verification - just let the users with wrong password decode garbage
EDIT: if you restrict the text editor to use only plain ANSI characters (msbit clear), you can use this to validate the password: if any of the decoded characters has msbit set, the password entered was invalid

one last thing: maybe let the user verify password by typing it twice so that typos are avoided

[Dan Honeycutt]

What I'm working on is a very simple text editor with a password feature to use to store the many passwords you end up with if you are active on the internet. I'm an encryption noob, what advantage would a crypto-secure RNG give, just harder to decrypt?

Best
Dan H.

I'd suggest this:
- generate 16-byte salt using good PRNG, store this along with data each time you encrypt a file
- salt is appended to password when generating IV
- use several iterations (nesting) of crypto-secure hash function to generate IV (sha-1, ...) => first hash pwd + salt, then the output and so on
- use 256-bit AES symmetric block cipher to encrypt data itself
- I would also append random garbage generated using PRNG to pad data at the end of file to match AES block size
- and don't forget to clear password plaintext in memory after (de/en)cryption (the same applies to actual text before your app exits!)

I probably wouldn't bother with password verification - just let the users with wrong password decode garbage
EDIT: if you restrict the text editor to use only plain ANSI characters (msbit clear), you can use this to validate the password: if any of the decoded characters has msbit set, the password entered was invalid

one last thing: maybe let the user verify password by typing it twice so that typos are avoided

Thanks Martin and others who gave suggestions. Very helpful and much appreciated.

Best
Dan H.

[Ras]

I was in need of a random number generator for the opening book moves of the CT800 (and, optionally, the eval noise). Since I have an onboard ADC anyway for monitoring the battery voltage (deep discharge prevention), I am using this for the randomness, too. So I have a measurement every 10 ms.

The least significant bit of the ADC measurement is shifted into the RNG seed value, and the RNG is re-seeded before every game. It is also being shifted into the least significant bit of the current RNG state, which works as a simple LCG. But with the additional noise of the ADC every 10 ms, that should even be of cryptographic strength.

If you want actual randomness, you need some physical source of thermal noise. On a PC, using the ADC of the sound card might be an option if you extract the least significant bit.