Hacker News Reader

Comment by tptacek | Hacker News Reader

* mt_rand() isn't a CSPRNG and you can't use it to generate crypto parameters.

* You're using a table of very small primes to generate the RSA modulus.

* Real cryptosystems very rarely ever encrypt directly with RSA, and it's dangerous to do so. RSA is used to wrap a symmetric key, or to sign messages during key agreement.

* Given that the raw plaintext of these secret messages is running through the server anyways, you might as well get rid of the RSA and just use SQL "DELETE FROM" as your safeguard.

I understand why one would write an app like this: because it's fun. And that's fine! Just cast it as a game, not as a tool for people in oppressive countries who could be tortured for using something like this.

View on HN

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 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.

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

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...

Why /dev/urandom instead of /dev/random, unless /dev/random isn't fast enough? Wouldn't /dev/random be more secure?

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.

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

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.

Reply on news.ycombinator.com