The biggest problem with these types of apps is that taking a screenshot or copying the MSG is all it takes to destroy any encryption you might have had.
They are fun apps to write and think about though.
Show HN: Send secure, self destructing messages
31–37 of 37 posts
Re: Show HN: Send secure, self destructing messages
#32unbreakable? "military-grade RSA encryption"? The keys have 6.2 bits of entropy!
Here's the code on github which explains the above claim:
https://github.com/Dirktheman/rsa-codeigniter-library/blob/m...
I count about 570 different primes there, so ~9.1 bits of entropy, but yeah. This is utterly trivial to brute force, with or without the given table of fixed primes, as it's very very easy to factor primes of this size. This is like 24-bit RSA.
"The advanced RSA-encryption will take a supercomputer thousands of years to break!"
s/years/nanoseconds/
BTW, I fell into a similar trap with ~125-bit RSA, which can also be broken in seconds: http://www.a1k0n.net/2009/03/31/hacker-challenge.html
Re: Show HN: Send secure, self destructing messages
#33* 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,…
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 do…
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.
Re: Show HN: Send secure, self destructing messages
#34Clickable: http://www.cycret.com Back in high school I was an absolute numbskull when it came to math, or exact sciences in general. It wasn’t until I picked up programming that the most basic fundamentals of math sinked in. I’m a lot more advanced now, but I still learn new stuff every day. To get out of my comfort zone, I picked up a book called ‘The Code Book’ by Simon Singh a couple of months ago. The reviews on…
"Should you invent something that can be used for both good and [evil]?"
Don't worry about this. Literally every invention since fire falls into this category.
(Edited for content.)
Re: Show HN: Send secure, self destructing messages
#35Re: Show HN: Send secure, self destructing messages
#36Earlier quoted context omitted.
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 do…
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 ran…
Why /dev/urandom instead of /dev/random, unless /dev/random isn't fast enough? Wouldn't /dev/random be more secure?
Re: Show HN: Send secure, self destructing messages
#37Earlier quoted context omitted.
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 ran…
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.