> 384 bits [RSA key] for normal security, 512 bits for a medium security, 1024 bits for a strong security
Um, this doesn't sound up to date. 1024 bit RSA isn't considered safe for a long term key. In fact, public (SSL) CAs aren't allowed to issue 1024 bit RSA certificates anymore.
To get 80 bits of security, a level of security that is probably not acceptable against the global passive adversary, you need an RSA key larger than 1024 bits. 1024 bit RSA is believed to be crackable given a moderate financial investment, but hasn't publicly been cracked yet.
I wonder just how out-of-date those numbers are, since a 397-bit key was factored a little over twenty one years ago in less than 3 months[1]. On current hardware, this is probably less than a day.
Interesting post. As someone who thought GPG (more or less) encrypted messages with public keys and decrypted them with private ones, I enjoyed learning how the software actually works at a high level.
As an aside, I recently set up encrypted email for my Mac's desktop Mail client using the GPG Suite. I want to set up my friends with secure email, too, but none of us really use Mail; we prefer web mail. I haven't been able to find good browser plugins for GPG. (WebPG for Chrome looks promising except for a major bug that prevents messages from being sent; I reported this issue.)
Can anyone recommend good solutions for bringing GPG to Gmail in the browser? I want something that's easy enough my non-technical friends will be willing to use it for everyday conversations.
This is very cool. I just compiled the source and it seems to be exactly what I'm looking for. I get an "undefined is not a function" error, though, when I try to import a key or send a message. I'll hang in there and wait for fixes or maybe try to contribute myself. Seems like the best option available at the moment.
As a member of the E2E team, is it possible to provide some insight into the state of the project? Is there any kind of estimate as to when it might appear on the chrome store?
As vague as is may sound, once we feel it's ready. The development is active, but there is still a lot of work to make the project release-ready. You might help too - we started accepting external contributions recently and the project is covered by the bug bounty.
Very disappointed after tracking down[1] and doing:
alias rot13="tr '[A-Za-z]' '[N-ZA-Mn-za-m]'"
and still only getting gibberish out the other end of the pipe (lame pun intended). I thought you were talking about stuff like Xrrc lbhe ybirq bar cyrnfrq.
Thanks! So if I do make a signature using GPG, it might still silently sign just an MD5 digest, if I didn't (re-)configure it properly? That sounds scary...
Note that the MD5 hash appended to the plaintext is probably just an add hoc system to provide integrity protection[1] of the plaintext. The scenario is that Alice sends Bob an encrypted message without a signature and Eve selectively tampers with the plaintext (without being able to decrypt the message though). For example if you use the CTR block cipher mode[2] you can switch any bits of the plaintext (by switching the corresponding bits of the ciphertext). The MD5 hash of the message at the end supposedly adds enough structure so that such attack is impossible. This added security layer does not rely on collision resistance but on the avalanche effect[3].
Nowadays you would add a MAC[4] to the message or use an authenticated encryption scheme[5] instead of just an encryption mode to achieve message integrity. But PGP, like SSL, comes from the Bronze Age of cryptography and does not really adhere to modern best practices.
Thanks for the detailed answer. I see why MD5 is harmless here, now.
I still wonder why anyone does anything with MD5 anymore, especially in an application like GPG... if it is known to be weak... It makes the argument why it is still safe in this situation much more subtle and involved. From all the crypto gurus, we hear 'MD5 is unsafe, do not use it anymore!!' and then in PGP/GPG, MD5 is still used because, well apparently for historic reasons and because one can.
As a non-expert in these matters, this looks very odd. It seems to (needlessly) make matters more complicated and involved, more complex in terms of the necessary analysis, and on the other hand unnecessary complexity is (rightfully) despised by the same security people...
If they'd use SHA256 or similar, one could simply assume all of the properties of an unbroken cryptographic hashing function and throw out the MD5 code.
So in the end, the only valid excuse here would be history+inertia.
True, but inertia and backwards compatibility is hell of an opponent. IPv6 turned 10 years old recently and we are still far away from universal deployment. TLS 1.2 only got more traction once BEAST - a proof of concept for a paper that was published years earlier - made some waves. And with PGP you have the additional problem that there is no standard way to find out which changes to the bases protocol the client of the recipient supports.
If we could ignore inertia and backwards compatibility we could collectively switch to some TextSecure style messaging over Tor with key distribution via DANE for universal end to end encryption with meta data protection. Alas, that is not how our world works…
So if we have a pair of keys, can a message be decrypted with one key if encrypted by the other? And then we just designate 1 as public and the other as private?
RSA has this property, but the public and private keys are not chosen arbitrarily. The public key can easily be derived from the private key, but there is no obvious way to determine the private key from the public key.
Nitpick: in RSA implementations using the speed optimization of a small public exponent (sometimes even always the same small number, like 3 or 65537), the private exponent has to be derived from the public one. This derivation uses some secret information (the factors of the modulus), so not just anyone can do it. The standard private key file format includes the factors of the modulus to enable some speedups for private key operations; however, the math doesn't require this, and both public and private key operations could be done with just an exponent and a modulus. Someone with just a private exponent and modulus wouldn't be able to compute the matching public exponent, unless it were small and easy to guess.
Symmetric encryption key (Km in the article) get encrypted separately with Alice, Bob, Sam and Joe public keys and then all those encrypted keys get concatenated with the message.
This article mentions that asymmetric encryption is slow, but I think the more important reason you can't use RSA directly is that it can only encrypt a small message, smaller then the size of the key.
I don't know if these same considerations apply to elliptic curve asymmetric encryption.
Um, this doesn't sound up to date. 1024 bit RSA isn't considered safe for a long term key. In fact, public (SSL) CAs aren't allowed to issue 1024 bit RSA certificates anymore.