6 ms·

Crypto problems you actually need to solve

118 points by geal 11y ago

JoachimSchipper 11y ago
This is good, but getting "well-known" solutions actually used in practice is a very hard, and worthwhile problem. (This is not just "PGP needs a better UI"; it's also "how do I get embedded/IoT developers to use half-decent crypto", "bringing TLS into the 21st century", etc.)
- exelius 11y ago
  This is exactly the infrastructure problem the author was referring to. And the big problem here is that infrastructure is neither a high-margin business model nor particularly interesting to build -- while being just as difficult on the business side as starting a new social network in 2015.
nailer 11y ago
> "Making email and PGP easier to use is not only a UX issue." Yes, but UX is still the biggest issue. By all means develop next gen crypto tech: but first, make what we have now usable by people who aren't Unix people. I would pay money for binaries of an Open Source GnuPG for OS X which wasn't awful to use. Not in a tarball, not assuming I want to use the command line, on gnupg.org (with the angry SHA1 certificate warning fixed), not linked to from there for 'people who want GUIs'.
- hedgehog 11y ago
  The problem runs deeper than UX in plugins for mail clients. Offline key exchange is inconvenient enough that it prevents GPG from being used as encrypted-by-default mail. Identity and key management is really the underlying issue, something in the spirit of CONIKS might be good enough to build a working system though. As OP points out even then you have issues with multi-device support.
  - Programmatic 11y ago
    > Offline key exchange is inconvenient enough that it prevents GPG from being used as encrypted-by-default mail. I would love to simply sync users' keys between their devices and encrypt opportunistically like OTR does. Offline key exchange would only be necessary for verification purposes at that point. I see user key management as the harder problem than exchange.
  - nailer 11y ago
    > The problem runs deeper than UX in plugins for mail clients. UX runs deeper than software interfaces. > Identity and key management is really the underlying issue Yes, that's a UX issue. So: - Get GPG key from Facebook (which has them as part of the standard profile today) - Say to person: you should contact this person by a means you trust and confirm this is their key (since we don't trust anyone by default). - Once they click OK, they can now send messages to that person. Nothing stopping other mainstream sites from adding GPG, it's jus that FB is the only one I know of. Obviously GitHub doesn't count since most people aren't software developers.
    - zbyte64 11y ago
      Which brings us back to trusting a 3rd party to not tamper with the key exchange...
      - nailer 11y ago
        Well yeah, that's why I addressed it in the post you're replying to. Offline key confirmation is still the best bet for most people, it's just that people don't use it because they don't use crypto because crypto tools are awful.
  - deleted 11y ago
    [deleted]
  - digi_owl 11y ago
    While offline exchange is needed for proper security, for casual snoopers having a the clients generate the pair, embed the public in every outgoing, grab publics from incoming, and encrypt by default for outgoing from that point on, would be a major step up from the status quo.
- aroch 11y ago
  That's what GPGTools is for (formally MacGPG): https://gpgtools.org/opensource.html https://gpgtools.org/opensource.html (You can build and use your own gpg binaries if you're concerned about their modifications)
  - nailer 11y ago
    GPGTools is precisely the awful state of current of affairs I'm talking about. - GPGTools isn't sure what's called. GPGTools? OK where do I download GPGTools? There's no button to do that. What's GPGSuite? Do I want that instead? Installed, there's nothing called either Applications/GPGTools or Applications/GPG Suite. - Its app is called 'GPG keychain' or similar. Nobody outside crypto folk care know what a keychain or, not should knowledge of a keychain app be required to send someone a message encrypted with their public key - The apps main focus is key management, and it's really poor at that. There's no way to discover people's GPG keys AFAICT - It's a plugin for Apple Mail and a command line app. Most people using Macs don't use either of those. And it's not promoted as a Mac mail plugin, which means most people will be disappointed when they use it. - It seems to choke on common GPG output with some chars. That output is probably not encoded correctly, that shouldn't matter. Be liberal in what you accept.
    - aroch 11y ago
      1) If installing something is enough of a hurdle that you can't complete it, then no amount of simplification beyond bundling is going to solve that 2) Everyone and their mother understand that keychains hold keys. You have to get to a key somehow, the onboarding process is a simple wizard. Again, if you can't follow prompts to enter an email, enter a password, and wiggle your mouse around; no amount of simplification is going to solve the problem. 3) You use the search for key button... 4) I'd argue that the vast majority of Mac users, especially the ones that are not technically inclined enough to use GPG on cli but want to, use the built in Mail.app. 5) gpg seems to have a slew of text encoding gotchas, I'm not sure how those can be fixed without a lot of core dev effort
      - oceanofsolaris 11y ago
AdmiralAsshat 11y ago
FWIW, UX plays a big part in controlling adoption. Apps like OpenSignal/TextSecure for encrypted communications make the whole process about as painless as possible. I downloaded TextSecure for Android and registered my number. I made my girlfriend download OpenSignal for iOS and register her number. I opened the app and saw her on my contacts (TextSecure will tell you which of your phone contacts already appear to have the app installed) and sent her a message. Boom. We're done. All of the tedious key-exchanges and whatnot were completely behind the scenes and we never had to deal with it directly. Those options are still there, and if I ever migrate to a new phone we'll probably have to do some kind of new exchange, but otherwise the "fun" of trying to manually exchange PGP keys was completely behind the scenes.
- devit 11y ago
  Ouch, isn't that totally insecure? Whatever place TextSecure is getting the key from could have replaced your girlfriend key with something else and be MITMing all the traffic. The proper way to do this would be to have your girlfriend's phone display a QR code with her public key and have you scan it with your phone camera, or using NFC to transfer the public key if available.
  - lorenzhs 11y ago
    You can verify fingerprints (manually or via QR code, example screenshot: https://info.securityinabox.org/sbox/screen/textsecure-en-1/045.png https://info.securityinabox.org/sbox/screen/textsecure-en-1/... ) if you're concerned about MITM. You will be warned and need to manually accept the new key if a person's key changes. Your "proper way" requires people to actually meet before they can begin a conversation, which greatly limits usability (you couldn't even test the app without a friend sitting next to you - who would keep an app they can't even try out on their phone?).
    - devit 11y ago
      Yes, using a central server should be possible, but the application should ask you whether your friend is with you and if you say yes, it should use the QR code/NFC method instead (which also has the advantage of working with people you just met and haven't otherwise added to your contacts yet). If you say no, it should clearly delineate how an attack could take place and advise you on how likely it is.
marcosdumay 11y ago
I'd be glad if people stopped asking for PFS in email. Email can not have PFS. If you actually implements PFS over email, it becomes instant messaging. Yes, you can cargo cult the PFS algorithms over the email infrastructure, but if you save the temporary key, it's not PFS anymore, and guess what, if you want to save your message to reading later, you'll have to save the temporary key too.
- devit 11y ago
  Isn't it enough to automatically change the public key used to encrypt messages sent to you periodically, signing the updates with your own master key? (where the master key is only to be used for signing, not decryption) When you change the public encryption key, you decrypt all messages received under the old key, re-encrypt with a local key, and destroy the private decryption key. This way, someone getting your private encryption key cannot decrypt intercepted ciphertext he got before your last key change. Obviously it requires to change PGP to get a new signed encryption key every time (unless there's some extension that already does it?)
- JoachimSchipper 11y ago
  You'll be interested in TextSecure's Axolotl for asynchronous messaging - if you have a concept of a "conversation", you definitely can design your crypto to prevent decrypting "prior" messages.
- mtgx 11y ago
  Adam Langley's Pond protocol for anonymous email uses the Axolotl ratchet with PFS. https://pond.imperialviolet.org/ https://pond.imperialviolet.org/
  - marcosdumay 11y ago
    > Pond messages are asynchronous, but are not a record; they expire automatically a week after they are received. That's not email. Ok, that's less "instant" than most instant messaging system. But it has the same trade-off. It has a bigger time window when messages can be decrypted, and messages last for longer. If you give-up on reading your email latter, yes, you can have some kind of forward secrecy.
mrbiber 11y ago
I'd be very excited to see more Free Software instant messaging applications support OMEMO (http://conversations.im/omemo/ http://conversations.im/omemo/). It's basically TextSecure's Axolotl protocol with a few slight modifications. As such, it support multi-party OTR-like PFS and multiple devices. In contrast to TextSecure, Conversations (the first client to implement it) allows you to use it without having to install Google Play Services and makes it usable on a decentralized infrastructure (XMPP). If it became standard for Open Source messaging clients (whatever transport they use) to have Omemo built in and use it opportunistically, we might actually have a chance to provide usable crypto to the masses.
- geal 11y ago
  does it provide ordering and transcript verification, even in case of partition and resume? I know that XMPP is meant to handle that kind of stuff reliably, but a multiparty OTR or Axolotl ratchet should make sure that even if the transport is compromised, you can detect any message drop or tampering.
- zokier 11y ago
  Does OMEMO support synchronizing conversations between multiple devices? Being able to jump seamlessly between laptop/phone/desktop is musthave for me, last time I checked that stuff was very much unfinished in XMPP (I think the relevant XEPs were "carbons" and "MAM")
  - mrbiber 11y ago
    In principle, this should work - I haven't tried it, but in Conversations, the fingerprints of my other connected devices show up and I can say that they belong to me. In any case, there are no desktop clients yet that support OMEMO. Conversations and Jitsi support Message Carbons though (together with a compatible XMPP service, such as yax.im) very well. On the console, there is profanity that also supports it.
Eridrus 11y ago
Personally I'm hoping Google/Yahoo's End-To-End encryption tech goes somewhere. I really liked the idea behind the use of a gossip protocol to let everyone know what keys they had seen for a given user so that active attacks are not necessarily completely prevented, but are noticed.

118 points by geal 11y ago

This is good, but getting "well-known" solutions actually used in practice is a very hard, and worthwhile problem. (This is not just "PGP needs a better UI"; it's also "how do I get embedded/IoT developers to use half-decent crypto", "bringing TLS into the 21st century", etc.)

exelius 11y ago
This is exactly the infrastructure problem the author was referring to. And the big problem here is that infrastructure is neither a high-margin business model nor particularly interesting to build -- while being just as difficult on the business side as starting a new social network in 2015.

nailer 11y ago

> "Making email and PGP easier to use is not only a UX issue." Yes, but UX is still the biggest issue. By all means develop next gen crypto tech: but first, make what we have now usable by people who aren't Unix people. I would pay money for binaries of an Open Source GnuPG for OS X which wasn't awful to use. Not in a tarball, not assuming I want to use the command line, on gnupg.org (with the angry SHA1 certificate warning fixed), not linked to from there for 'people who want GUIs'.

hedgehog 11y ago
The problem runs deeper than UX in plugins for mail clients. Offline key exchange is inconvenient enough that it prevents GPG from being used as encrypted-by-default mail. Identity and key management is really the underlying issue, something in the spirit of CONIKS might be good enough to build a working system though. As OP points out even then you have issues with multi-device support.
- Programmatic 11y ago
  > Offline key exchange is inconvenient enough that it prevents GPG from being used as encrypted-by-default mail. I would love to simply sync users' keys between their devices and encrypt opportunistically like OTR does. Offline key exchange would only be necessary for verification purposes at that point. I see user key management as the harder problem than exchange.
- nailer 11y ago
  > The problem runs deeper than UX in plugins for mail clients. UX runs deeper than software interfaces. > Identity and key management is really the underlying issue Yes, that's a UX issue. So: - Get GPG key from Facebook (which has them as part of the standard profile today) - Say to person: you should contact this person by a means you trust and confirm this is their key (since we don't trust anyone by default). - Once they click OK, they can now send messages to that person. Nothing stopping other mainstream sites from adding GPG, it's jus that FB is the only one I know of. Obviously GitHub doesn't count since most people aren't software developers.
  - zbyte64 11y ago
    Which brings us back to trusting a 3rd party to not tamper with the key exchange...
    - nailer 11y ago
      Well yeah, that's why I addressed it in the post you're replying to. Offline key confirmation is still the best bet for most people, it's just that people don't use it because they don't use crypto because crypto tools are awful.
- deleted 11y ago
  [deleted]
- digi_owl 11y ago
  While offline exchange is needed for proper security, for casual snoopers having a the clients generate the pair, embed the public in every outgoing, grab publics from incoming, and encrypt by default for outgoing from that point on, would be a major step up from the status quo.
aroch 11y ago
That's what GPGTools is for (formally MacGPG): https://gpgtools.org/opensource.html https://gpgtools.org/opensource.html (You can build and use your own gpg binaries if you're concerned about their modifications)
- nailer 11y ago
  GPGTools is precisely the awful state of current of affairs I'm talking about. - GPGTools isn't sure what's called. GPGTools? OK where do I download GPGTools? There's no button to do that. What's GPGSuite? Do I want that instead? Installed, there's nothing called either Applications/GPGTools or Applications/GPG Suite. - Its app is called 'GPG keychain' or similar. Nobody outside crypto folk care know what a keychain or, not should knowledge of a keychain app be required to send someone a message encrypted with their public key - The apps main focus is key management, and it's really poor at that. There's no way to discover people's GPG keys AFAICT - It's a plugin for Apple Mail and a command line app. Most people using Macs don't use either of those. And it's not promoted as a Mac mail plugin, which means most people will be disappointed when they use it. - It seems to choke on common GPG output with some chars. That output is probably not encoded correctly, that shouldn't matter. Be liberal in what you accept.
  - aroch 11y ago
    1) If installing something is enough of a hurdle that you can't complete it, then no amount of simplification beyond bundling is going to solve that 2) Everyone and their mother understand that keychains hold keys. You have to get to a key somehow, the onboarding process is a simple wizard. Again, if you can't follow prompts to enter an email, enter a password, and wiggle your mouse around; no amount of simplification is going to solve the problem. 3) You use the search for key button... 4) I'd argue that the vast majority of Mac users, especially the ones that are not technically inclined enough to use GPG on cli but want to, use the built in Mail.app. 5) gpg seems to have a slew of text encoding gotchas, I'm not sure how those can be fixed without a lot of core dev effort
    - oceanofsolaris 11y ago

AdmiralAsshat 11y ago

FWIW, UX plays a big part in controlling adoption. Apps like OpenSignal/TextSecure for encrypted communications make the whole process about as painless as possible. I downloaded TextSecure for Android and registered my number. I made my girlfriend download OpenSignal for iOS and register her number. I opened the app and saw her on my contacts (TextSecure will tell you which of your phone contacts already appear to have the app installed) and sent her a message. Boom. We're done. All of the tedious key-exchanges and whatnot were completely behind the scenes and we never had to deal with it directly. Those options are still there, and if I ever migrate to a new phone we'll probably have to do some kind of new exchange, but otherwise the "fun" of trying to manually exchange PGP keys was completely behind the scenes.

devit 11y ago
Ouch, isn't that totally insecure? Whatever place TextSecure is getting the key from could have replaced your girlfriend key with something else and be MITMing all the traffic. The proper way to do this would be to have your girlfriend's phone display a QR code with her public key and have you scan it with your phone camera, or using NFC to transfer the public key if available.
- lorenzhs 11y ago
  You can verify fingerprints (manually or via QR code, example screenshot: https://info.securityinabox.org/sbox/screen/textsecure-en-1/045.png https://info.securityinabox.org/sbox/screen/textsecure-en-1/... ) if you're concerned about MITM. You will be warned and need to manually accept the new key if a person's key changes. Your "proper way" requires people to actually meet before they can begin a conversation, which greatly limits usability (you couldn't even test the app without a friend sitting next to you - who would keep an app they can't even try out on their phone?).
  - devit 11y ago
    Yes, using a central server should be possible, but the application should ask you whether your friend is with you and if you say yes, it should use the QR code/NFC method instead (which also has the advantage of working with people you just met and haven't otherwise added to your contacts yet). If you say no, it should clearly delineate how an attack could take place and advise you on how likely it is.

marcosdumay 11y ago

I'd be glad if people stopped asking for PFS in email. Email can not have PFS. If you actually implements PFS over email, it becomes instant messaging. Yes, you can cargo cult the PFS algorithms over the email infrastructure, but if you save the temporary key, it's not PFS anymore, and guess what, if you want to save your message to reading later, you'll have to save the temporary key too.

devit 11y ago
Isn't it enough to automatically change the public key used to encrypt messages sent to you periodically, signing the updates with your own master key? (where the master key is only to be used for signing, not decryption) When you change the public encryption key, you decrypt all messages received under the old key, re-encrypt with a local key, and destroy the private decryption key. This way, someone getting your private encryption key cannot decrypt intercepted ciphertext he got before your last key change. Obviously it requires to change PGP to get a new signed encryption key every time (unless there's some extension that already does it?)
JoachimSchipper 11y ago
You'll be interested in TextSecure's Axolotl for asynchronous messaging - if you have a concept of a "conversation", you definitely can design your crypto to prevent decrypting "prior" messages.
mtgx 11y ago
Adam Langley's Pond protocol for anonymous email uses the Axolotl ratchet with PFS. https://pond.imperialviolet.org/ https://pond.imperialviolet.org/
- marcosdumay 11y ago
  > Pond messages are asynchronous, but are not a record; they expire automatically a week after they are received. That's not email. Ok, that's less "instant" than most instant messaging system. But it has the same trade-off. It has a bigger time window when messages can be decrypted, and messages last for longer. If you give-up on reading your email latter, yes, you can have some kind of forward secrecy.

mrbiber 11y ago

I'd be very excited to see more Free Software instant messaging applications support OMEMO (http://conversations.im/omemo/ http://conversations.im/omemo/). It's basically TextSecure's Axolotl protocol with a few slight modifications. As such, it support multi-party OTR-like PFS and multiple devices. In contrast to TextSecure, Conversations (the first client to implement it) allows you to use it without having to install Google Play Services and makes it usable on a decentralized infrastructure (XMPP). If it became standard for Open Source messaging clients (whatever transport they use) to have Omemo built in and use it opportunistically, we might actually have a chance to provide usable crypto to the masses.

geal 11y ago
does it provide ordering and transcript verification, even in case of partition and resume? I know that XMPP is meant to handle that kind of stuff reliably, but a multiparty OTR or Axolotl ratchet should make sure that even if the transport is compromised, you can detect any message drop or tampering.
zokier 11y ago
Does OMEMO support synchronizing conversations between multiple devices? Being able to jump seamlessly between laptop/phone/desktop is musthave for me, last time I checked that stuff was very much unfinished in XMPP (I think the relevant XEPs were "carbons" and "MAM")
- mrbiber 11y ago
  In principle, this should work - I haven't tried it, but in Conversations, the fingerprints of my other connected devices show up and I can say that they belong to me. In any case, there are no desktop clients yet that support OMEMO. Conversations and Jitsi support Message Carbons though (together with a compatible XMPP service, such as yax.im) very well. On the console, there is profanity that also supports it.

Eridrus 11y ago

Personally I'm hoping Google/Yahoo's End-To-End encryption tech goes somewhere. I really liked the idea behind the use of a gossip protocol to let everyone know what keys they had seen for a given user so that active attacks are not necessarily completely prevented, but are noticed.