Practical Public Key Cryptography

https://hackaday.com/2017/10/18/practical-public-key-cryptography/

by rbanffy • 9 years ago

153 35 9 years ago

nimbius• 9 years ago

This is a great article for beginners but I must take issue with the fact that gpg 2.1 has been released for a year now and this article still recommends non-elliptic keys. When will we switch?

dogcow2• 9 years ago

A lot (all?) PGP-enabled smart cards (that I'm aware of) only work with RSA keys.

Diti• 9 years ago

Is it definitely proven that elliptic curves are safer to use?

sgtcodfish• 9 years ago

You can get the same amount of "bits" of security with EC as you can with RSA for sure if you choose the right parameters. There are also EC implementations (Ed25519 being an excellent example) which are incredibly simple which makes them easier to audit and reason about.

Also the simplicity allows us to implement some EC crypto in constant time, so there are no timing side channels.

The main reason not to use EC would be spottier hardware support (cards, keys, etc) and potentially less software support in the wild (people could be stuck on old versions of GPG for example).

jlgaddis• 9 years ago

Some of us have reservations about using, for example, NIST curves.

s14ve• 9 years ago

I think there should be keybase mentioned.

Its probably the only pgp with potential to become used by mainstream users.

wybiral2• 9 years ago

Agreed. I know how to use other tools, and even to work with cryptographic primitives myself. But Keybase makes this stuff really convenient.

dogcow2• 9 years ago

Was also wondering why this wasn't mentioned in the article.

craftyguy• 9 years ago

Isn't that proprietary & unfederated? If so, I'd rather not encourage/depend on yet another island service.

equalunique• 9 years ago

Agreed. Lack of federation is a huge turn off.

Maybe something like Keybase.io, but on the SAFE Network, would be ideal.

nickik• 9 years ago

Keybase really has practically nothing to do with PGP anymore except that it still serves as a directory.

gregmac• 9 years ago

If you haven't seen it, there's a pretty neat video that outlines how public-key cryptography works using paint colors [1]. It's focused on Diffie-Hellman key exchange, but it's a great intro for beginners to be able to visualize the concepts, and I think helps provide some context before jumping right into the GPG command line.

[1] https://www.youtube.com/watch?v=YEBfamv-_do&t=2m25s

WhoBeI• 9 years ago

Their 8 part series on cryptography is also very good.

https://www.youtube.com/watch?v=lICOtR078Gw&list=PLB4D701646...

helloasdfasdf• 9 years ago

The colour analogy is a bit off, despite being a good way to get the basis of the protocol across.

The problem is with what he explains as a one-way function: https://s3.amazonaws.com/static.kaytor.ca/screenshots/incorr...

While it's true that it's not possible to derive the input colours given only the output, in the case of DH both the output and the yellow (common) colour is available to Eve, which makes it trivial to reverse the other input.

The actual property a one-way function needs to be suitable for DH is to remain hard to reverse when both the output and one of the inputs is known.

AdmiralAsshat• 9 years ago

This is a "beginners" article, and it's still too damn complicated for most people. I don't think I could send this article to my family, for instance, or even try to explain it to them without their eyes glazing over.

I'm not sure if the solution is to "hide" the confusing bits in the way that Signal/Enigmail/Mailvelope does, or if we need to scrap the whole concept and try again.

earthboundkid• 9 years ago

Why would the solution not be hiding the complexity? TLS "hides" the complexity. It works fine, and it's ubiquitous.

The "solution" to E2E encrypted email has been known for two decades: there should be a system for publicly announcing public keys and privately sharing private keys between trusted devices. It's not rocket science: see Telegram, Signal, Whatsapp, iMessage, etc.

But what those service have that email does not is a commercial incentive to make it all work seamlessly. Email is stuck with a system of half-implemented RFCs and patches for a system designed in the 80s with zero security considerations.

I feel like the only way we're ever going to make progress is if regulators require it. Have the EU mandate that email services with more than 10m customers need to have transparent E2E. Gmail, Outlook, and Yahoo will figure it out about three months after that law is passed.

wybiral2• 9 years ago

To me, if a program is letting me focus on the task at hand and is hiding everything else then that program is doing things correctly.

Someone who wants to send a secure message doesn't care how the program works as long as they can trust that it holds up its end of the bargain.

RasputinsBro4• 9 years ago

Could someone explain to me the lore that email can't be make secure? It seems to me that all the steps described on this article could be automated behind the scenes by a good local email client.

tptacek5• 9 years ago

* Email defaults and fails open to plaintext. Modern secure messengers only transmit securely. Even modern secure websites take pains, including extensions that had to be made to the HTTP protocol, to prevent traffic from being sent unencrypted. No such mechanism exists in email.

* Email reveals large amounts of metadata, including message content (which is what a Subject: line is), which is a characteristic shared by no secure messaging system. The graph of who talks to who and when is immensely important, and the best secure messengers (Signal, in particular) go through trouble to obscure it.

* Modern secure messengers are forward-secure, so that a compromised key doesn't allow attackers to retroactively decrypt old messages. Since messaging traffic between selected peers is almost always low-volume, any reasonable threat model assumes every piece of ciphertext exchanged between peers has been archived by adversaries. With PGP, a key compromise at any point in time reveals the contents of every one of those messages. The best secure messaging systems are not only forward secure but also have a notion of "future secrecy" allowing them to recover from ephemeral key loss.

* Email clients are inhospitable to cryptography; in particular, many of key features of clients (like search) rely on having a local archive of plaintext. The UX in email clients begs users for catastrophic failure, like accidentally top-posting a reply to an encrypted messages with an unencrypted message.

All four of these problems are, in isolation, total dealbreakers for serious secure messaging.

SMTP email is janky and outmoded and it's a little amazing that we all use it as much as we do; it's long overdue for a replacement. If you need to communicate securely with someone else, you should do so with a secure messenger like Signal, not with PGP and email.

RasputinsBro4• 9 years ago

So why is it that people like Assange and Snowden, whose lives arguably depend on these matters, choose PGP over anything else?

I'm no expert in security, but my intuition is that the likelihood that my signed ubuntu plus gpg leak secrets is significantly lower than my who-knows-what-the-hell-its-doing android with signal, right? You gotta agree with this at least.

sliken2• 9 years ago

I agree, email sucks. However it seems like a reasonable goal to improve it.

Signal started out with SMS, which was quickly abandoned. Your target would basically get a SMS message saying something like "someone is sending you an encrypted message, please install signal to read it".

Seems like a imap proxy could do similar. Use a DHT to track who has a public key. Send anyone who doesn't a "please install this plugin/proxy/whatever to read this message". Have a signal like autogeneration of keys tied to an email address instead of signal's phone number.

Could even have a service like <username>@whisper.com to allow people to use their favorite email client (like thunderbird) to send/receive email and leak less metadata. The imap proxy would use a signal like transport for anything matching @whisper.com.

I seem to recall a project like this mentioned, even a thunderbird plugin or some such.

Not as secure as signal, but better than today's default.

sholladay• 9 years ago

It is not practical until my non-programmer neighbor can use it. Or my uncle. Or my friends. The people I communicate with most frequently, whose privacy is most important to me.

Practical Public Key Cryptography

Related Stories