5 ms·

@tedu writes: > There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to

by atmosx 11y ago

@tedu writes: > There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again. This argument doesn't hold ground. If "technical people" can not setup a new GnuPG key in 20 minutes, they are obviously not "technical" in this context. I'm 100% sure OpenBSD is absolutely NOT fit for people who find GnuPG confusing enough to avoid usage. > Or as Prof. Green put it, "Can someone who built GnuPG 2.1.1 on Debian/Ubuntu give me a hint on which libgpg-error you used?" If he doesn't which libgpg-error to use, I doubt I'm going to pick the right one. I can, here: $ pkg info|grep libgpg-error libgpg-error-1.19_1 Common error values for all GnuPG components Given that this is @tedu, I'm sure I missed the point/joke. The only real argument here is that it's at least 10 times easier to write code than to read another mans code. So I give him that... Which one is more secure, GPG or signify remains to be seen.

pstrateman 11y ago
He's written a tool that solves one problem using one set of algorithms and a very simple format in a few thousand lines of c. It almost certainly contains fewer bugs than gnupg.
- sliverstorm 11y ago
  Do one thing, and do it well
  - RexRollman 11y ago
    Praise be Unix.
brynet 11y ago
GnuPG is complicated, the gpg(1) man page is quite extensive compared to signify. I imagine very few people have set up PGP without the help of a search engine. $ man gpg | pr | grep Page | awk '{print $6}' | tail -1 58 $ man signify | pr | grep Page | awk '{print $6}' | tail -1 2
- jrcii 11y ago
  I'm surprised that there seems to be a consensus here that using the GPG command line tool is complicated when the HN community regularly discusses, for example, time complexity of algorithms.
  - pstrateman 11y ago
    Using gnupg unfortunately requires a fairly complete understanding of the specific Web of Trust model used. On top of that the interface is atrocious, go find someone with an image in their pubkey and try to display it from the command line. Good luck.
    - nickpsecurity 11y ago
      You actually just need a reliable way to get information from them once plus a good cheat sheet (see above comment) on GPG. So, you both use cut and paste to (a) generate keys, (b) add keys, (c) send messages and (d) receive messages. Exchanging the key file is the only step that requires slight thought and there's a dozen ways to do that. I still don't use or fully understand the web of trust model as I haven't studied it in ages. I do use GPG every night with the right person on the other end, though. Still don't know anything else about it. Don't want to, either.
      - elsjaako 11y ago
        But then a friend tries to be more secure and sends something using --throw-keyids or --hidden-recipient. He tells me I should use --try-all-secrets, but adding that to enigmail doesn't work. I still don't know why. I'm trying to do this with some friends, and we keep on running into problems like that. Everything turns out to be easy to solve, but only if you know exactly how it works.
        nickpsecurity 11y ago
        You'd have to be an idiot to read those command names and try them. Whereas "gen-key," "import," "export," "-e," and "-d" have obvious, low-risk usage. More so if you cross-reference against the docs. Nice strawman, though.
FullyFunctional 11y ago
I have the misfortune of having encrypted some files in the past with PGP. At the time, the default algorithm appeared to be IDEA which was removed since for patent reasons. Find the old sources and getting it to built is not trivial. These days I'm leaning towards bundling encrypted files along with the C code that encrypted it and that works better if the latter is small and self-contained.
- vbezhenar 11y ago
  That's a very interesting concept of a cross-platform self-unpacking archive. Unfortunately it requires the C compiler binary which is missing on the Windows platform out of the box. Perhaps some kind of tiny C compiler or interpreter windows binary might be bundled along for 99% compatibility.
  - derefr 11y ago
    I know that the RAR format, for one, effectively embeds the compensating decompression program for whatever it did into the archive, in the form of some bytecode for a VM with an ABI that has been stable since RAR was created. So RAR has actually been a bunch of different algorithms over time, but unrar(1) doesn't need to care; it just runs the embedded program in its VM. (Most exciting fact: this means that older versions of the program can decompress archives created by newer versions, using algorithms that didn't exist at the time the older version shipped!) It would definitely be possible to do the equivalent for encryption. The main problem† being that while compression algorithms get outmoded, encryption algorithms break. This is true of all encryption, but it's especially scary when you can just scan a disk and signature-identify crackable files by the embedded algorithm. So, if you were going to do something like this, you'd probably want a higher-level abstraction than "self-describing encrypted file"; maybe something more like a "self-describing encrypted mutable volume." Mutable so that it would (hopefully) get an update() operation called on it at least every so often (even if just from a fsck-during-mount), letting it start a background process to change out an old-and-broken backing-store encryption algorithm for a new-and-trusted one (think of how bcrypt handles strength changes.) --- † There's also the performance problem: if you have a stable ABI, and it was frozen 20 years ago, how would you ever do something like elliptic-curve operations efficiently? Heck, doesn't using a frozen ABI mean you couldn't make use of a modern processor's native instructions for RSA ciphering et al? The answer to this, I think, is VM-runtime instruction-level pattern-recognition ala urbit's "jets". The new version of the encryption program would prepend a program for the stable ABI, that tells the old version how to (inefficiently) implement elliptic-curve decryption in terms of things it understands. However, running this program against a new version of the decryption VM would recognize the signature/pattern of "what elliptic-curve decryption instructions encoded in [this VM]'s ABI" looks like, and execute a native procedure with the same preconditions and postconditions as that instruction-sequence instead. Sort of like typehints for a JIT, but where the instruction-sequences themselves are the hints, since they have canonical forms.
nickpsecurity 11y ago
You made a good point: OpenBSD is way more complicated than GPG. I set up GPG with one command I got off the Internet. I also got a cheat sheet giving common commands I need for common scenarios. These people weren't just barely technical: they were unable to use Google as well. I'm dismissing the study as having little value. Need a new one with people who can follow steps they find on Google. If they fail, the author's point would stand. One more thing they forgot to mention: GPG is apparently so secure that Snowden leaks show that NSA hates running into it and even uses it internally. Biggest endorsement one can get. I'd replace the interface for sure, though, where users would never see it.
kragen 11y ago
The paper is full of jokes like this. It’s clear, though, that GPG is much larger than we would like our TCB to be, and that it does have serious usability problems, some of which are inherent to its trust model and therefore cannot be papered over by GPG frontends. (They don't, however, stop you from using it to authenticate upgrades, as Debian and Ubuntu do.)

by atmosx 11y ago

pstrateman 11y ago

He's written a tool that solves one problem using one set of algorithms and a very simple format in a few thousand lines of c. It almost certainly contains fewer bugs than gnupg.

sliverstorm 11y ago
Do one thing, and do it well
- RexRollman 11y ago
  Praise be Unix.

brynet 11y ago

GnuPG is complicated, the gpg(1) man page is quite extensive compared to signify. I imagine very few people have set up PGP without the help of a search engine. $ man gpg | pr | grep Page | awk '{print $6}' | tail -1 58 $ man signify | pr | grep Page | awk '{print $6}' | tail -1 2

jrcii 11y ago
I'm surprised that there seems to be a consensus here that using the GPG command line tool is complicated when the HN community regularly discusses, for example, time complexity of algorithms.
- pstrateman 11y ago
  Using gnupg unfortunately requires a fairly complete understanding of the specific Web of Trust model used. On top of that the interface is atrocious, go find someone with an image in their pubkey and try to display it from the command line. Good luck.
  - nickpsecurity 11y ago
    You actually just need a reliable way to get information from them once plus a good cheat sheet (see above comment) on GPG. So, you both use cut and paste to (a) generate keys, (b) add keys, (c) send messages and (d) receive messages. Exchanging the key file is the only step that requires slight thought and there's a dozen ways to do that. I still don't use or fully understand the web of trust model as I haven't studied it in ages. I do use GPG every night with the right person on the other end, though. Still don't know anything else about it. Don't want to, either.
    - elsjaako 11y ago
      But then a friend tries to be more secure and sends something using --throw-keyids or --hidden-recipient. He tells me I should use --try-all-secrets, but adding that to enigmail doesn't work. I still don't know why. I'm trying to do this with some friends, and we keep on running into problems like that. Everything turns out to be easy to solve, but only if you know exactly how it works.
      - nickpsecurity 11y ago
        You'd have to be an idiot to read those command names and try them. Whereas "gen-key," "import," "export," "-e," and "-d" have obvious, low-risk usage. More so if you cross-reference against the docs. Nice strawman, though.

FullyFunctional 11y ago

I have the misfortune of having encrypted some files in the past with PGP. At the time, the default algorithm appeared to be IDEA which was removed since for patent reasons. Find the old sources and getting it to built is not trivial. These days I'm leaning towards bundling encrypted files along with the C code that encrypted it and that works better if the latter is small and self-contained.

vbezhenar 11y ago
That's a very interesting concept of a cross-platform self-unpacking archive. Unfortunately it requires the C compiler binary which is missing on the Windows platform out of the box. Perhaps some kind of tiny C compiler or interpreter windows binary might be bundled along for 99% compatibility.
- derefr 11y ago
  I know that the RAR format, for one, effectively embeds the compensating decompression program for whatever it did into the archive, in the form of some bytecode for a VM with an ABI that has been stable since RAR was created. So RAR has actually been a bunch of different algorithms over time, but unrar(1) doesn't need to care; it just runs the embedded program in its VM. (Most exciting fact: this means that older versions of the program can decompress archives created by newer versions, using algorithms that didn't exist at the time the older version shipped!) It would definitely be possible to do the equivalent for encryption. The main problem† being that while compression algorithms get outmoded, encryption algorithms break. This is true of all encryption, but it's especially scary when you can just scan a disk and signature-identify crackable files by the embedded algorithm. So, if you were going to do something like this, you'd probably want a higher-level abstraction than "self-describing encrypted file"; maybe something more like a "self-describing encrypted mutable volume." Mutable so that it would (hopefully) get an update() operation called on it at least every so often (even if just from a fsck-during-mount), letting it start a background process to change out an old-and-broken backing-store encryption algorithm for a new-and-trusted one (think of how bcrypt handles strength changes.) --- † There's also the performance problem: if you have a stable ABI, and it was frozen 20 years ago, how would you ever do something like elliptic-curve operations efficiently? Heck, doesn't using a frozen ABI mean you couldn't make use of a modern processor's native instructions for RSA ciphering et al? The answer to this, I think, is VM-runtime instruction-level pattern-recognition ala urbit's "jets". The new version of the encryption program would prepend a program for the stable ABI, that tells the old version how to (inefficiently) implement elliptic-curve decryption in terms of things it understands. However, running this program against a new version of the decryption VM would recognize the signature/pattern of "what elliptic-curve decryption instructions encoded in [this VM]'s ABI" looks like, and execute a native procedure with the same preconditions and postconditions as that instruction-sequence instead. Sort of like typehints for a JIT, but where the instruction-sequences themselves are the hints, since they have canonical forms.

nickpsecurity 11y ago

You made a good point: OpenBSD is way more complicated than GPG. I set up GPG with one command I got off the Internet. I also got a cheat sheet giving common commands I need for common scenarios. These people weren't just barely technical: they were unable to use Google as well. I'm dismissing the study as having little value. Need a new one with people who can follow steps they find on Google. If they fail, the author's point would stand. One more thing they forgot to mention: GPG is apparently so secure that Snowden leaks show that NSA hates running into it and even uses it internally. Biggest endorsement one can get. I'd replace the interface for sure, though, where users would never see it.

kragen 11y ago

The paper is full of jokes like this. It’s clear, though, that GPG is much larger than we would like our TCB to be, and that it does have serious usability problems, some of which are inherent to its trust model and therefore cannot be papered over by GPG frontends. (They don't, however, stop you from using it to authenticate upgrades, as Debian and Ubuntu do.)