How PGP Works Under the Hood | Hacker News Reader

How PGP Works Under the Hood

marcomanzoni.me

129 pointsmarcomanzoni39 comments

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

Agreed. I thought 2048 bits was the minimum RSA key size.

I think I'll just stick with my 4096 bit key.

You are right.

It's very much not. 384 bit RSA is breakable. Here's a decent breakdown of key strengths in different settings:

http://www.keylength.com/en/3/

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.

[1] https://en.wikipedia.org/wiki/RSA_numbers#RSA-120

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.

Another option could be SMIME. If it's just for playing around, you can have fun setting up your own CA for your friends ;)

https://code.google.com/p/end-to-end/ is made by Google. It's not done yet, though. I've tried out the alpha and it seems very promising.

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.

Please file a bug report so that the issue can get fixed: https://code.google.com/p/end-to-end/issues/list

That's this bug: https://code.google.com/p/end-to-end/issues/detail?id=121 , it will get fixed after weekend.

Disclaimer: I'm a member of E2E team.

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.

Fair enough, thanks for the info.

Do people who encrypt their Gmail get targeted ads for MjJlNzE4ZTNlMTA2NWE0ZjBlODk5MTMyNDY2NGJiYjg3ODFkYmY0NDk4MzY0MTQ1ODZhNzM0NjVlOGQwOTI2ZA?

Google keeps the key, but only for advertising purposes...

the down-votes won't change my mind since this is their business model

I don't mind those targeted ads. What annoys me is the spam about enlarging my FkYmY0NDk4MzY0MTQ1ODZhNzM.

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.

[1] http://www.commandlinefu.com/commands/view/1792/rot13-using-...

you can try https://www.mailvelope.com/ even though they are not fully stable yet, their product seems very promising!

For non-technical friends you can use https://encrypt.to/

WebPG is pretty solid though not totally passive.

Does anyone know why P-/GPG is still using MD5?

It supports it for historical reasons but you should not use it. Here is the recommended configuration:

https://help.riseup.net/en/security/message-security/openpgp...

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.

[1] https://en.wikipedia.org/wiki/Information_security#Integrity

[2] https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

[3] https://en.wikipedia.org/wiki/Avalanche_effect

[4] https://en.wikipedia.org/wiki/Message_authentication_code

[5] https://en.wikipedia.org/wiki/Authenticated_encryption

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…

My firewall reports suspicious activity on this site.

It reports the 'virus' Sus/FBJack-A.

Still trying to find out exactly what that is...

Edit: http://www.sophos.com/en-us/threat-center/threat-analyses/su...

Seems safe: https://www.virustotal.com/en/url/c9c5514fd72fa2824a60ea0a67...

What firewall are you using?

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?

Yes, that's a pretty simple summary of how asymmetric cryptography works.

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: there is an obvious way but the idea is that it is very hard to do so.

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.

What about when Alice wants to send to Bob, Sam, and Joe? (But not outside observer James)

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.

Reply on news.ycombinator.com