Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday November 08 2015, @02:06PM   Printer-friendly
from the Wbuaal-qbrf-abg-rira-haqrefgnaq-EBG13 dept.

This paper presents the results of a laboratory study involving Mailvelope, a modern PGP client that integrates tightly with existing webmail providers. In our study, we brought in pairs of participants and had them attempt to use Mailvelope to communicate with each other. Our results shown that more than a decade and a half after "Why Johnny Can't Encrypt," modern PGP tools are still unusable for the masses. We finish with a discussion of pain points encountered using Mailvelope, and discuss what might be done to address them in future PGP systems.

The PDF of the study can be found here.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by frojack on Sunday November 08 2015, @04:53PM

    by frojack (1554) on Sunday November 08 2015, @04:53PM (#260397) Journal

    No, that's NOT safe. (Please tell me you were joking!).

    Even with https your mail sits on servers unencrypted.

    When I send encrypted mail to joe@merchant.org I HAVE TO KNOW joe's public key. (My mail client will run out to the key-servers and fetch it for me, - seamlessly. Then and only then can the message be encrypted using joe's public key, and my private key. Joe can only decrypt the mail by using his private key, and my public key.

    Encryption must be done client side, for both sender and recipient. Decryption in the cloud just means your private key is pre-compromised because you uploaded it to the cloud. Don't ever do that. That is less than useless. Its harmful. Don't ever go there.

    --
    No, you are mistaken. I've always had this sig.
    Starting Score:    1  point
    Moderation   +3  
       Insightful=2, Interesting=1, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by tangomargarine on Sunday November 08 2015, @05:56PM

    by tangomargarine (667) on Sunday November 08 2015, @05:56PM (#260418)

    I'm not sure GP was talking about uploading the private key. Can't both parties post their public key somewhere and the system is still secure as long as the private keys stay private?

    If you do the decryption server-side, yes ew.

    --
    "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
    • (Score: 2) by frojack on Sunday November 08 2015, @06:51PM

      by frojack (1554) on Sunday November 08 2015, @06:51PM (#260437) Journal

      I'm pretty sure the GP has no idea about how it works and wasn't even aware there was a private key.

      Public keys are sent to key-servers, which replicate them around the world. 20 minutes after you publish your public key to one key server all the others have it. You can also attach them to the message. Distributing your public key is another thing that the Enigmail client takes care of.

      The upshot is the suggestion of loading all mail to a website that can decode it for the recipient is a non-starter. (Politest term I can think of).

      If the cloud can decrypt your mail, its hopelessly compromised.
      If the Cloud Can't decrypt your mail, there is no reason to have the cloud.

      This article was about Mailvelope, which is a browser extension to handle the decryption/encryption tasks. It wasn't a full blown mail package.
      It isn't the only such package out there that attempts to add encryption to web mail via browser plugins. Even google released a similar extension for chrome.

      In general, in-browser decryption/encryption is considered a bad idea, because browsers are so easily hacked. Still, a lot of people use browsers to read mail, and any opensource browser plugin is probably a good idea: As long as it does work.

      --
      No, you are mistaken. I've always had this sig.
      • (Score: 0) by Anonymous Coward on Monday November 09 2015, @10:38AM

        by Anonymous Coward on Monday November 09 2015, @10:38AM (#260717)

        If the Cloud Can't decrypt your mail, there is no reason to have the cloud.

        Not true.

        • Sending data from one computer to another only works if both computers are switched on at the same time. The "cloud" (that is, the server in between; publicly accessible servers are much older that even the word "cloud") basically acts as a computer that normally is always-on.
        • Depending on the implementation and the number of people using the server, having a server in between can also hide which message is sent from whom to whom. All that can be seen from outside is that there were a bunch of people connecting to the server, while with a direct connection, anyone sitting in between can clearly see that there was a connection from the sender to the receiver.
        • (Score: 2) by frojack on Monday November 09 2015, @07:12PM

          by frojack (1554) on Monday November 09 2015, @07:12PM (#260862) Journal

          If the Cloud Can't decrypt your mail, there is no reason to have the cloud.

          Not true.

          Well, yes. clearly I meant there is no reason to have "the cloud" involved in email storage and retrieval as proposed by the GP.
          And no, the cloud can't hide who email is sent from and to, because that is all revealed to the each smtp mail server in the chain.

          Thank you Captain Pedantic.

          --
          No, you are mistaken. I've always had this sig.
    • (Score: 2) by JoeMerchant on Monday November 09 2015, @04:07AM

      by JoeMerchant (3937) on Monday November 09 2015, @04:07AM (#260646)

      [QUOTE]I'm not sure GP was talking about uploading the private key.[/QUOTE]

      Yeah, that would be more like GMail today... no, I mean keeping private keys private, and if someone wants to run the decryption software native on their own machine (in a RAM based "burner VM", if you're into such things), then rock on, that's an option.

      What I'm talking about for compatibility with the world is just this:

      Alice wants to send Bob an encrypted e-mail, but Bob is clueless.

      Alice sends Bob a "welcome to webcrypt" link which prompts Bob to make a key pair (with a web-app that runs local on his machine to store his private key), and Bob's public key is sent to Alice. Bob is also prompted to select a passphrase which can be used to secure his private key on the web server so Bob can access his private key securely from multiple devices, you know how Bob loves his phone...

      Alice now sends Bob the "secure" e-mail, which includes a link for clueless Bob to click on to load the decoder software from the web. Bob inputs his passphrase, and software running on Bob's device decrypts his private key using the passphrase, then decrypts the e-mail Alice sent him using his private key. Bob's phone self-destructs 10 seconds later (only in the movies.)

      Bob replies to Alice, and his reply is encrypted on his device using Alice's public key, before transmission to the SMTP server.

      Alice, being the paranoid of the bunch, receives Bob's e-mail on an encrypted, RAM based VM that uses biometric plus passphrase to unlock her private key which is used to decrypt Bob's e-mail using a native app in the VM that is verified in-tact via an md5sum she has engraved inside her wedding band (the VM image is kept on a micro USB drive that hangs from her Pandora bracelet).

      It can work, but Bob just doesn't care and will whine about having to type in a pass phrase.

      --
      🌻🌻 [google.com]
      • (Score: 2) by tangomargarine on Monday November 09 2015, @04:23AM

        by tangomargarine (667) on Monday November 09 2015, @04:23AM (#260650)

        Bob's public key is sent to Alice. Bob is also prompted to select a passphrase which can be used to secure his private key on the web server so Bob can access his private key securely from multiple devices, you know how Bob loves his phone...

        Alice now sends Bob the "secure" e-mail, which includes a link for clueless Bob to click on to load the decoder software from the web.

        I'm skeptical whether the passphrase would be secure, though. Wouldn't it just be stored on the server? In which case the hosting company could presumably trivially decrypt his private key and then the whole game is over as soon as the gubmint requests the users' keys (and of course the companies never say no). Unless if the passphrase was hashed or something...but then if the server can't decrypt the passphrase, it can't use it to retrieve the private key anyway.

        Bottom line, if they have your private key, you should assume that they'll give it up the first time somebody demands it.

        --
        "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
        • (Score: 0) by Anonymous Coward on Monday November 09 2015, @10:46AM

          by Anonymous Coward on Monday November 09 2015, @10:46AM (#260718)

          I'm skeptical whether the passphrase would be secure, though. Wouldn't it just be stored on the server?

          That would be a crappy implementation.

          The passphrase basically acts as a key to encrypt the actual private key.

          What storing the private key on a server of course means is that for anyone having access to the data on the server, the strength of the key is effectively reduced to the strength of the passphrase.

        • (Score: 2) by JoeMerchant on Monday November 09 2015, @01:32PM

          by JoeMerchant (3937) on Monday November 09 2015, @01:32PM (#260753)

          The passphrase is as secure as Bob makes it, but you know how Bob is a whiner about long passphrase requirements.

          The passphrase is used to scramble Bob's private key before it goes to the server, and unscramble it when it rains back on him from the cloud. Bob's scrambled private key is known to an attacker, but such attacker would have to guess passphrases and try the resulting private keys on sample messages to determine if they have guessed correctly or not. If we can keep Bob secure from dictionary attacks and get his key length up around 12 characters from a 50+ alphabet size, 2x10^20 codes take a while to plough through.

          Bottom line, like Apple these days, they won't have the private key.

          --
          🌻🌻 [google.com]
          • (Score: 0) by Anonymous Coward on Monday November 09 2015, @04:33PM

            by Anonymous Coward on Monday November 09 2015, @04:33PM (#260813)

            People are horrible at choosing passphrases.

            They over-estimate the entropy they are using.

            Search for "Brainwallet" for examples with money on the line.

  • (Score: 0) by Anonymous Coward on Sunday November 08 2015, @08:54PM

    by Anonymous Coward on Sunday November 08 2015, @08:54PM (#260498)

    Then and only then can the message be encrypted using joe's public key, and my private key

    Not trying to be pedantic here, I'm no GPG expert, so I may have misunderstood something, but isn't it that the message is encrypted using joe's public key and signed using your private key? i.e. your private key plays no role in the encryption part.