4 ms·

So, back to the drawing board for version 2 which will include: - A better way to create better random numbers (a static noise sniffing Arduino comes to mind)

So, back to the drawing board for version 2 which will include: - A better way to create better random numbers (a static noise sniffing Arduino comes to mind) - Incorporating http://primes.utm.edu/lists/small/1000.txt http://primes.utm.edu/lists/small/1000.txt instead of the current primes - SSL Any hints on a good way to encrypt the message itself instead of RSA? And yes, it was created just for fun and as a learning experience for myself. I agree that it does look too serious for what it really is, will definitely change that. On a side note, I'm genuinely honored and humbled that you took the time to look at my project and provide feedback! Matasano is absolutely killing it in the security field! EDIT: First thing tomorrow morning (it's midnight here) I'll restyle the site to make it clear that it's just a game, not something you can bet your life on.

tptacek 14y ago
Just read random bytes from /dev/urandom. Smart people have already taken the time to work out how to give your platform fast random number generation. Don't use a table of primes for p and q. Look at BN_generate_prime_ex() in OpenSSL for a simple sieve algorithm. Your RSA key size is a function of the product of p and q; they should be bignums. Incorporate an AES library. Generate AES keys by reading 128 bits of random bytes from /dev/urandom. Generate a 64 bit random number the same way, then encrypt the message in CTR mode using that 64 bit number as the nonce; you'll need a new one for every message. After encrypting with AES to generate a ciphertext, run the ciphertext through HMAC-SHA2 and append that hash to the end of the ciphertext. Encrypt the keys & the nonce with RSA and append that to the message. The receiver verifies the HMAC hash before it attempts to decrypt the AES-CTR encrypted message. This is advice given under the assumption that you're doing this to learn stuff. Again: strongly advise you make a game out of this instead of trying to supply secure messaging to people. If you wanted to do this for real, read instead: http://cr.yp.to/highspeed/coolnacl-20120725.pdf http://cr.yp.to/highspeed/coolnacl-20120725.pdf
- dirktheman 14y ago
  Thanks again, it's these kind of comments that make HN shine. First thing I'll do is a restyle to make sure people don't bet their lives on the site. After that, it seems I've some extensive reading to do...
- cheese1756 14y ago
  Why /dev/urandom instead of /dev/random, unless /dev/random isn't fast enough? Wouldn't /dev/random be more secure?
  - tptacek 14y ago
    On some systems, random(4) can block, and urandom(4) can't. Blocking can harm program correctness. The security difference on systems where random(4) behaves differently from urandom(4) is marginal. I don't think this is a point worth sweating over, given that most systems use things like Mersenne Twister and LCG algorithms for their randomness.
vhf 14y ago
Regarding primes, you'd be better off with this kind of list : http://primes.utm.edu/lists/small/small.html#50 http://primes.utm.edu/lists/small/small.html#50 than with the 1k smallest ones.
tzs 14y ago
I recommend that you take the Applied Cryptography course from Udacity. It is an excellent, fun, well taught practical course that will cover most of the things you asked about above.

tptacek 14y ago

Just read random bytes from /dev/urandom. Smart people have already taken the time to work out how to give your platform fast random number generation. Don't use a table of primes for p and q. Look at BN_generate_prime_ex() in OpenSSL for a simple sieve algorithm. Your RSA key size is a function of the product of p and q; they should be bignums. Incorporate an AES library. Generate AES keys by reading 128 bits of random bytes from /dev/urandom. Generate a 64 bit random number the same way, then encrypt the message in CTR mode using that 64 bit number as the nonce; you'll need a new one for every message. After encrypting with AES to generate a ciphertext, run the ciphertext through HMAC-SHA2 and append that hash to the end of the ciphertext. Encrypt the keys & the nonce with RSA and append that to the message. The receiver verifies the HMAC hash before it attempts to decrypt the AES-CTR encrypted message. This is advice given under the assumption that you're doing this to learn stuff. Again: strongly advise you make a game out of this instead of trying to supply secure messaging to people. If you wanted to do this for real, read instead: http://cr.yp.to/highspeed/coolnacl-20120725.pdf http://cr.yp.to/highspeed/coolnacl-20120725.pdf

dirktheman 14y ago
Thanks again, it's these kind of comments that make HN shine. First thing I'll do is a restyle to make sure people don't bet their lives on the site. After that, it seems I've some extensive reading to do...
cheese1756 14y ago
Why /dev/urandom instead of /dev/random, unless /dev/random isn't fast enough? Wouldn't /dev/random be more secure?
- tptacek 14y ago
  On some systems, random(4) can block, and urandom(4) can't. Blocking can harm program correctness. The security difference on systems where random(4) behaves differently from urandom(4) is marginal. I don't think this is a point worth sweating over, given that most systems use things like Mersenne Twister and LCG algorithms for their randomness.

vhf 14y ago

Regarding primes, you'd be better off with this kind of list : http://primes.utm.edu/lists/small/small.html#50 http://primes.utm.edu/lists/small/small.html#50 than with the 1k smallest ones.

tzs 14y ago

I recommend that you take the Applied Cryptography course from Udacity. It is an excellent, fun, well taught practical course that will cover most of the things you asked about above.