SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
SoylentNews
posted by
martyb
on Sunday November 08 2015, @02:06PM
from the Wbuaal-qbrf-abg-rira-haqrefgnaq-EBG13 dept.
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.
This discussion has been archived.
No new comments can be posted.
Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client
|
Log In/Create an Account
| Top
| 69 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
The last time I saw him he was walking down Lover's Lane holding his own hand.
-- Fred Allen
(Score: 2) by JoeMerchant on Monday November 09 2015, @04:07AM
[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
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
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
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
People are horrible at choosing passphrases.
They over-estimate the entropy they are using.
Search for "Brainwallet" for examples with money on the line.