29 ms·

The PGP Problem

• tptacek 7y ago
  Really, all I did here was combine posts from Matthew Green, Filippo Valsorda, and George Tankersley into one post, and then talk to my partner LVH about it. So blame them. (also 'pvg, who said i should write this, and it's been nagging at me ever since)
  • bellinom 7y ago
    I've followed and enjoyed your commentary on PGP and cryptography in general, so I thought I'd post it. Any idea when Fillipo's `age` will be done, or how to follow its development, other than the Google doc?
    • tptacek 7y ago
      Filippo should get to work! The design part of age is the hard part; the actual programming is, I think? maybe one of the easier problems in cryptography (encrypt a single file with modern primitives). I am a little bit giving Filippo shit here but one concern I have about talking "age" up is that I'm at the same time talking the problem of encrypting a file up more than it needs to be, so that people have the impression we'd have to wait, like, 5 years to finally see something do what operating systems should have been doing themselves all this time.
  • DuskStar 7y ago
    What are your thoughts on Keybase as a secure Slack replacement?
    • corin_ 7y ago
      Personally, I love Keybase and it is my #1 choice for communicating with a few people, but bugs are far too frequent for me to consider it for a business. It's getting better, but not close being business ready imo.
      • lucb1e 7y ago
        I've been using Wire on iOS, web, desktop (electron), and Android, and Keybase on Android and desktop (cli). Both are not great but Keybase is definitely the more buggy. Wire on Android, on the other hand, is also quite unusable due to its battery drainage. And both are pretty much unusable on desktop: Keybase is a CLI (not even a TUI) and Wire is Electron. I'd prefer a TUI over Electron but it's not even a TUI, so I guess Wire wins this round. Keybase also doesn't have a web client, which is why I have experience with the command line client. I think that says enough in and of itself. What I'm trying to say is, definitely also try Wire as it's similar but slightly better. I also haven't figured out how to verify someone over Keybase, so it's basically unauthenticated or opportunistic encryption. By comparison, Wire is considered secure enough by my company after doing a pentest on it, which says quite something (most customer's stuff we would run from if we were thinking of using it), and we use it as our main communication platform within the company.
        • DuskStar 7y ago
          > Keybase is a CLI Keybase has a relatively functional electron app on Mac and PC that I've used, and presumably also Linux. > I also haven't figured out how to verify someone over Keybase Isn't the goal with Keybase to see "this person is accountiknow on Github" and do verification that way?
          • lucb1e 7y ago
            > Keybase has a relatively functional electron app Oh, then I am mistaken, thank you for correcting me and sorry for talking nonsense. > Isn't the goal with Keybase to see "this person is accountiknow on Github" and do verification that way? Yes, but that doesn't help me because my chat account is not cryptographically tied to my Keybase account. So let's say I sign this statement that I am lucb1e on Github as well as on HN as well as on Keybase. You know and can verify that I have all these identities nicely tied to my PGP key. The person who controls those identities clearly also controls the PGP key. Now comes chat. You start a chat with me, and... magic? I don't know, but there is no verification code that I can use to check that I am really talking to lucb1e on Keybase; nothing that ties it to a PGP key; nothing that ties it to the HN user. My device might be encrypting the data for an entirely different key (whose private part is known either by Keybase or some other (W)MitM ((Wo)Man in the Middle)) and there is no way to check as far as I have been able to find.
  • pgeorgi 7y ago
    The elephant in the room is "what to do about email", and a significant part of the issues are related to the "encrypt email" use case: part of the metadata leakage, no forward secrecy, ... The closest advice to this in the article would be "use Signal" which has various issues of its own, unrelated to crypto: it has Signal Foundation as a SPOF and its ID mechanism is outright wonky, as phone numbers are IDs that are location bound, hard to manage multiple for a person, hard to manage multiple persons per ID, hard to roll over. To me that seems to be a much bigger issue than "encrypting files for purposes that aren't {all regular purposes}".
  • book-mind 7y ago
    Is it wrong to use openssl to encrypt files? 0. (Only once) generate key pair id_rsa.pub.pem, id_rsa.pem 1. Generate random key openssl rand -base64 32 > key.bin 2. Encrypt key openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc 3. Encrypt file using key openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin -- other side -- 4. Decrypt key openssl rsautl -decrypt -inkey id_rsa.pem -in key.bin.enc -out key.bin 5. Decrypt file openssl enc -d -aes-256-cbc -in SECRET_FILE.enc -out SECRET_FILE -pass file:./key.bin
    • tptacek 7y ago
      To start with, none of that encryption is authenticated.
      • book-mind 7y ago
        So if I understand you correctly (Noob here), Alice would need to sign the pair (key.enc, file.enc) to authenticate that those files originated from her. Without that, Bob could potentially receive any pair of (key,file), which would just decrypt into garbage data. BTW, variations on that sequence appear all over the internet when searching for "openssl encrypt file with public key"...
        • tptacek 7y ago
          No, the problem is that the AES encryption step uses bare AES-CBC. An attacker can flip bits in the ciphertext to make targeted changes to the plaintext. What you want is an authenticated encryption mode, but I don't know that the OpenSSL cli supports any of them.
        • jcranmer 7y ago
          This is one of the problems with cryptography: with a little knowledge, you can end up making yourself completely insecure while believing yourself to be very secure. People generally imagine that "encrypt this block of data" is a simple primitive that does everything you want it to. But naive encryption doesn't work like that. In the worst case, where you use ECB for the block cipher [1], you end up with the ECB penguin: https://blog.filippo.io/the-ecb-penguin/ https://blog.filippo.io/the-ecb-penguin/. Your secure crypto becomes a pretty trivial Caesar cipher, just on a larger alphabet. Other modes (such as the CBC mode you used) aren't so bad, but if you have some hint of the structure of the underlying data, you can start perturbing the ciphertext to manipulate the encrypted data. The modern solution to that problem is "authenticated encryption," which means that you add in an additional guarantee that the ciphertext hasn't been tampered with. Even then, there is still room for doing things incorrectly (padding is a real pain!). [1] This is so bad it shouldn't ever be an option in any tool.
  • pvg 7y ago
    This is great, thanks for writing it! Brings to mind the words of renowned Victorian lifehacker Jerome K. Jerome: “I can't sit still and see another man slaving and working. I want to get up and superintend, and walk round with my hands in my pockets, and tell him what to do. It is my energetic nature. I can't help it.”
• tedunangst 7y ago
  I am a combination of honored and terrified that signify is the leading example for how to sign packages. The original goals were a bit more modest, mostly focused only on our needs. But that's probably what's most appealing about it.
  • tptacek 7y ago
    I think you should get comfortable with that, because all the opinions I've collected seem to be converging on it as the answer; Frank Denis Frank-Denis-i-fying it seems to have cinched it. Until quantum computers break conventional cryptography, it would be downright weird to see someone design a new system with anything else.
• luizfelberti 7y ago
  The missing answer in there is how to avoid PGP/GnuPG for commit signing. I've asked about this in another similar thread[0] but didn't get a hopeful answer. Everytime I look at git's documentation GPG seems very entrenched in there, to a point that for things that matter I'd use signify on the side. Is there a better way? [0] https://news.ycombinator.com/item?id=20379501 https://news.ycombinator.com/item?id=20379501
  • paulddraper 7y ago
    Signing tags (or somewhat less usefully, commits) can be done the same way packages are signed. It might not be directly integrated with git, but it wouldn't be hard to make a good workflow. The article mentions Signify/Minisign. [1] [1] https://jedisct1.github.io/minisign/ https://jedisct1.github.io/minisign/ as an PGP alternatie.
    • gocartStatue 7y ago
      > It might not be directly integrated with git That's the problem I see. I have signingkey in .gitconfig, together with [commit] gpgsign = true. This way, set & forget, all my commits are signed (it's my employer requirement, probably some "compliance" stuff). You can see it right away nicely displayed as "Verified" on github. I didn't know about GPG-s supposedly weak security until now, but always considered it not very convenient to use.
      • paulddraper 7y ago
        Ah, well if your employer mandates PGP signatures on every commit, that's that. FWIW, the creator of git argues that signing of every commit is essentially pointless. [1] I agree. [1] http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
  • srl 7y ago
    It seems pretty clear that, with the current tools available, there is no way to do this (at least with git). There's nothing in principle difficult about it, just that (say) git+signify hasn't been implemented. I'm getting the strong sense (see also my toplevel comment, and maybe someone will correct me and/or put me in my place) that there's an enormous disconnect between the open source + unix + hobbyist + CLI development communities, and the crypto community. The former set has almost no idea what the state of art in crypto is, and the latter (somewhat justifiably) has bigger fish to fry, like trying to make it so that non-command-line-using journalists have functional encryption that they can use. I think this is a sociological problem, not a technical "using command-line tools makes Doing Crypto Right impossible".
• techslave 7y ago
  at first i thought, oh boy a rant from someone that can’t see past a pretty GUI ... but actually he gets it. well worth your time to read.
• elagost 7y ago
  With the rapid churn of various chat clients it's hard to get something to stick, and I attempted to settle on XMPP+OMEMO (or OTR), since it's a protocol, not an "app" (eww). Not a single person I know still uses XMPP, and it's easier to just tell people "Download Signal". However, that requires a phone number, and is useless on a desktop if your phone's off. Despite being Free Software, it's fairly locked down. Secure communication with most people is nigh impossible these days, because nobody wants to not use SMS. There has to be a better solution, and despite email+PGP's flaws, it's the only system I've seen that's stood the test of time. There are pretty good plugins for Mail.app (macOS) and Outlook (Windows), and if you use Linux you probably can deal with gpg. We use it at work for email, and pretty much everyone can work with it at any level of technical expertise. Anyone else have any solutions that have worked in their circles, including non-technical family members?
  • cyphar 7y ago
    Matrix works, and has fairly easy-to-use clients (and I've switched a few non-technical folks without too much trouble). It's also an open protocol, not just an app. The main criticism (and I'm preemptively responding to tptacek here) is that they haven't yet made E2EE the default (though this should happen in a few weeks now that cross-signing appears to be done). I also think the key backup system should be much better explained -- there is a usability bug open for it and I've posted some suggestions.
    • tptacek 7y ago
      Use Matrix if you want to contribute to Matrix or are an enthusiast about what Matrix is trying to do. But don't use it as a secure messenger, or tell at-risk people to use it. It may someday be a serious option for secure messaging, but it is not that today. I'm not a Matrix hater, but I think Matrix's cheering section gets the project in trouble, since their answers about privacy and security are demonstrably worse than those of other secure messengers. All Matrix is trying to do is build a modern, generalized IRC with optional built-in encryption, which is a project congenial and relevant to my own interests (my only funded startup tried to do the same thing!). That's great, as long as you're not trying to get people to use it to hide things from governments.
• cyphar 7y ago
  I would suggest using restic over TarSnap for encrypted backups -- it gives you more flexibility with where your backups will be stored since TarSnap is pretty integrated with Colin Percival's online service and is also unfortunately not free software. But it's also an as-simple-as-possible cryptosystem. Filippo did a quick lookthrough and said that it seemed sane from a crypto perspective[1]. [1]: https://blog.filippo.io/restic-cryptography/ https://blog.filippo.io/restic-cryptography/
  • tptacek 7y ago
    Restic is also fine.
  • JoshTriplett 7y ago
    I'm using Restic, and it mostly works. Unfortunately, it uses an absurd amount of memory, proportional to the size of your backup store. So, don't use it to back up a small VPS. If you do, "export GOGC=20" can help a little, but it'll still use a lot of memory.
  • always4getpass 7y ago
    Any opinions about rclone? It seems to be fine for my mediocre backup needs
    • cyphar 7y ago
      rclone is fine (in fact I use rclone with restic to synchronise my restic backup repository on BackBlaze B2) but it doesn't encrypt or deduplicate your backups -- it's just a synchronisation tool like rsync.
      • always4getpass 7y ago
        What about its 'crypt' encryption backend? Afaik it uses scrypt which was designed for tarsnap
        • cyphar 7y ago
• eadmund 7y ago
  Magic Wormhole is neat, but the happy path is to use a third-party rendezvous server, which is susceptible to traffic analysis (I also wish that the codes had more than 16 bits of entropy, but that is part cargo-culting on my part). Signal is also vulnerable to server-side traffic analysis, and is strangely keen on both demanding a selector (a phone number) for identity and on trusting Intel's 'secure' enclave (I strongly suspect that it's suborned). One thing I do like about PGP is that it has been around awhile: I can still decrypt my old files & verify old signatures just fine, something I don't trust the flavour of the month to do. I think that rather than a Swiss Army knife tool & protocol like PGP, we should have a suite of tools built around a common core, probably NaCL. That way we can have compatibility when we need it, but also aren't cramming square pegs into round holes. Finally, the Web of Trust was a bright, shiny idea — and wrong. But Trust on First Use is also pretty bad, as is the CA ecosystem. We need something else, something decentralised and also secure — and I don't think that's impossible. I've had a few ideas, but they haven't panned out. Maybe someday.
  • lvh 7y ago
    Re: magic-wormhole's 16 bits: I don't think you should be worried about that, because SPAKE2 will give you proof positive if the attacker attempts to guess. Are you saying 2*-16 success isn't good enough?
    • tptacek 7y ago
      Isn't the code length also selectable?
      • lvh 7y ago
        Yep, the default python implementation lets you pick a code and generate a code with more than 2 words. I'm just cautious in telling people to twiddle knobs that don't need twiddling :-) But you can absolutely go up to 2^-64 or whatever if that makes you happy!
    • eadmund 7y ago
      > Are you saying 2-16 success isn't good enough? I really don't think it is, because it might be worthwhile for a particular sort of attacker, say one who runs the default rendezvous server: observe global activity, attempt to MitM every connexion for 30 seconds, then write up a spurious blog post about a 'network issue' or 'bug' or whatever which caused a brief outage. N:2^16 is okay* against targeted attacks, mostly (hence my 'cargo-culting' comment), but with a large enough N … The nice thing about 1:2^128 is that you just don't have to care.
• lvh 7y ago
  I did some "OpenPGP Best Practices" work for a client recently. They don't have a choice, because a third party requires it. The goal was to make sure it was as safe as possible. One thing that struck me is that I have a simplified mental model for the PGP crypto, and reality is way weirder than that. The blog post says it's CFB, and in a sense that's right, but it's the weirdest bizarro variant of CFB you've ever seen. In CFB mode, for the first block, you take an IV, encrypt it, XOR it with plaintext. Second block: you encrypt the first ciphertext block, encrypt that, XOR with second plaintext block, and so on. It feels sorta halfway between CBC and CTR. Here's the process in OpenPGP, straight from the spec because I can't repeat this without being convinced I'm having a stroke: 1. The feedback register (FR) is set to the IV, which is all zeros. 2. FR is encrypted to produce FRE (FR Encrypted). This is the encryption of an all-zero value. 3. FRE is xored with the first BS octets of random data prefixed to the plaintext to produce C[1] through C[BS], the first BS octets of ciphertext. 4. FR is loaded with C[1] through C[BS]. 5. FR is encrypted to produce FRE, the encryption of the first BS octets of ciphertext. 6. The left two octets of FRE get xored with the next two octets of data that were prefixed to the plaintext. This produces C[BS+1] and C[BS+2], the next two octets of ciphertext. 7. (The resynchronization step) FR is loaded with C[3] through C[BS+2]. 8. FRE is xored with the first BS octets of the given plaintext, now that we have finished encrypting the BS+2 octets of prefixed data. This produces C[BS+3] through C[BS+(BS+2)], the next BS octets of ciphertext. 9. FR is encrypted to produce FRE. 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an 8-octet block). 11. FR is encrypted to produce FRE. 12. FRE is xored with the next BS octets of plaintext, to produce the next BS octets of ciphertext. These are loaded into FR, and the process is repeated until the plaintext is used up. Yeah so CFB except your IV isn't your IV and randomly do something with two bytes as... an... authenticator? And then everything after that is off by two? This isn't the only case where OpenPGP isn't just old, it's old and bizarre. I don't have a high opinion of PGP to begin with, but even my mental model is too charitable. (Disclaimer: I'm a Latacora partner, didn't write this blog post but did contribute indirectly to it.)
  • matthewdgreen 7y ago
    I think this is called Plumb CFB. It was invented by Colin Plumb back in the day. I first saw it in their FDE products which didn’t have a good IV generation process (kind of acting like a replacement for XTS or a wide block cipher) and no, I don’t know what it’s for.
• btilly 7y ago
  And as for how PGP gets used in practice, https://xkcd.com/1181/ https://xkcd.com/1181/ did a good job of demonstrating how useless that is. Seriously, I'm a developer. I have never once felt motivated to verify a PGP signature. Of anything.
• srl 7y ago
  First, thanks enormously for writing this -- and for all the other recent articles that have appeared here the vein of "PGP is as bad as it is unpleasant to use". It's a point I didn't really appreciate (at least as much as I (sh/c)ould have) and I'm sure I'm not alone. It seems that the state of package distribution for many distributions is poor, security-wise. (OpenBSD, to nobody's surprise, is an exception.) For instance, archlinux (I'm loyal) signs packages with PGP[1] and, for source-built packages, encourages integrity checks with MD5. My recollection is that, about 5 years ago, MD5 was supposed to be replaced with SHAxxx. Am I misinterpreting this? Is this actually Perfectly Okay for what a distro is trying to accomplish with package distribution? (I'm particularly suspicious of the source-built package system, which consists of a bunch of files saying "download this tarball and compiler. MD5 of the tarball should be xyz." I'm pretty confident that's not okay.) Okay, now moving from package distribution to messaging, and again looking at the state of my favorite system. How am I supposed to message securely? The best nix messaging tools are all based around email. Even when I can get the PGP or S/MIME or whatever toolset to work (let's face it, that's at least 45 minutes down the drain), it's clear that I'm not in good shape security-wise. I should use signal, apparently. Great. Just a few problems: (1) no archlinux signal package, (2) I'm guessing I can't use it from the terminal, and (3) most severely, it seems signal has incomplete desktop support. In particular, I need to first set up signal on my phone. Well, let's face facts: I have a cheap phone from a hard-to-trust hardware vendor, and I think there's a >5% chance it's running some sort of spyware. (The last phone I had genuinely did have malware: there were ads showing in the file manager, among other bizarre behaviors.) So in order to use signal on my desktop, I need to buy a new phone? That's even worse, usability-wise, than PGP. Is... is it really this bad? I'm getting the sense that the desktop linux community has completely dropped the ball on this one. (And perhaps more generally desktop mac/windows... I wouldn't know.) [1] Perhaps not so bad, since the keyring is distributed with the system -- but how was the original download verified? Options are: PGP, MD5, SHA1, with the choice left up to the user. That can't be right.
  • cyphar 7y ago
    Arch Linux's pacman is not a good example of a secure package distribution system (especially not the AUR, where you are downloading all the bits from the internet and building them yourself as your own user or even sometimes as root). They didn't do any package signing or verification at all until (shockingly) recently -- less than 10 years ago IIRC. I am a huge fan of Arch's philosophy but am definitely not a fan of the design of their package distribution system. If you look at systems like Debian-derivatives or RPM-based distros (openSUSE/SLES, and Fedora/CentOS/RHEL) the cryptosystems are far better designed. In the particular case of openSUSE, the AUR-equivalent (home: projects on OBS) are all signed using per-user keys that are not managed by users -- eliminating almost all of the problems with that system. Yeah, you still have to trust the package maintainer to be sure what they're doing, but that should be expected. I believe the same is true for Fedora's COPR. [Disclaimer: I work for SUSE and contribute to openSUSE.]
• roamingnomadic 7y ago
  Is this blog post satire? or an ad of sorts for some vaporware? The talking alts either use PGP or a botnet. (signal uses PGP with a CA type of thing, so much for "stop using pgp") and whatsapp is owned by facebook. tarsnap as I understand requires that I lock in to a service to secure my backups. F- that. Someone already talked about wormhole. And how is essentially forking pgp with 'age' really going to solve things? Wow thanks another forked app! :^) It would be easier to just make a wrapper for gnupg that sets the settings for everything the author is talking about. (well most of the things the user is talking about) Wouldn't it be easier to just inform maintainers of the package to change the default standards of packages like gnupg? Has the author even attempted to change some of these things? Don't get me wrong, I get where the author is coming from. Uinx philosophy should be followed... but certain systems can not be compartmentalized they have to unfortunately interact with other another. If you for example encrypt data without signing it, how would you know that someone isn't trying to poison ciphertext to extract data leakage or worse yet, they already found a way to decrypt your data and manipulating sensitive data? An encryption program by DESIGN should also have a method to sign data.
  • lvh 7y ago
    > (signal uses PGP with a CA type of thing, so much for "stop using pgp") I legitimately have no idea what this means. > And how is essentially forking pgp with 'age' really going to solve things? Wow thanks another forked app! :^) A big part of the criticism we've gotten when we tell people "PGP bad" is that we're not providing alternatives. age is one of those alternatives, for one of those use cases. > It would be easier to just make a wrapper for gnupg that sets the settings for everything the author is talking about. (well most of the things the user is talking about) > Wouldn't it be easier to just inform maintainers of the package to change the default standards of packages like gnupg? Has the author even attempted to change some of these things? As we mentioned repeatedly in the blog post: no, the PGP format is fundamentally broken, it is not a matter of "just fixing it". > If you for example encrypt data without signing it, how would you know that someone isn't trying to poison ciphertext to extract data leakage or worse yet, they already found a way to decrypt your data and manipulating sensitive data? I think you're making an argument against unauthenticated encryption here. That's true! You should not have unauthenticated encryption, the way PGP makes it easy for you to have. age is not unauthenticated encryption, so the criticism does not apply.
• viraptor 7y ago
  Another use case I don't know a replacement for is offline team+deployment secrets. Requirements: - you need team members to read/write the secrets - you need the deployment service to read the secrets Without using an online system managing the secrets via ACLs + auth, I don't know how to replace PGP here.
  • lvh 7y ago
    what's wrong with an online system managing the secrets? KMS is great, and makes it easy to separate decrypt from encrypt permissions. (KMS is not the only option! I'm just trying to eke out why you think that's valuable. For example, I think age, mentioned in the blog post, is a direct replacement?)
    • viraptor 7y ago
      It has to be online. And reliable. And you can run into rate-limiting. And you have to be online. And services using it need extra network configuration to allow access. And if you can't narrow it down to a single ip/block you have a service with full network access just to reach out to a KMS.
      • lvh 7y ago
        KMS historical downtime is pretty great, rate limits have been bumped quite a bit to the point where I seriously doubt you're hitting them for secrets management, I'm not sure you can do a lot of useful things with most secrets while you're offline, KMS has a VPC endpoint and an Internet endpoint, so you can do both variants of the tight network scoping you want. (And, again, age once that's around :-))
    • wbl 7y ago
      How do you turn on the online system?
      • lvh 7y ago
        KMS is a service, it’s already on.
• ekianjo 7y ago
  So the recommendation here is just to use Chat clients to communicate and forget about Email? Well that is hardly a good solution.
  • lvh 7y ago
    Yes! E-mail is fundamentally terribly positioned to do secure messaging. You can use e-mail, or you can have cryptography that works and have people use it, but you can't do both.
    • frutiger 7y ago
      > E-mail is fundamentally terribly positioned to do secure messaging E-mail is fundamentally a way to send a sequence of bytes somewhere (untrusted) so they can be picked up later by someone (trusted). That’s also literally what Signal is built on so I think you’re overstating the difference.
      • lvh 7y ago
        Secure messaging is much more complex, but here’s a simple example of how that’s not true: TCP is bidirectional and email is one message, fire and forget. That immediately affects your ability to have forward and backward secrecy.
        • frutiger 7y ago
          I do not think the OSI model is very useful but you seem to, so let me put it this way: E-mail is bidirectional too just at layer 4 instead of layer 3 (I hope I remembered my layers right!) E-mail is store-and-forward just like TCP is; how do you think an IP router works? TCP is fully duplex; a tx doesn’t wait behind an rx, exactly like an e-mail reply not waiting behind an e-mail receive. The only difference is that a router will typically use volatile memory to store messages before they are sent but e-mail will typically use disk. If your security model relies on this difference then your security model is broken. It’s worth noting that Signal does NOT rely on this difference. It relies on participants being mostly online to permit frequent rekeys and not having to retain old keys indefinitely.
• stubish 7y ago
  The PGP problem isn't going away until there is a stable alternative. Under 'The Answer' there are several different, domain specific tools, with their different features and UIs and limitations. And the general case (encrypting files, or really that should be 'encrypting data'), "this really is a problem". If I want to replace my use of GnuPG on production with the things on that list, I need to write my own encrypt/decrypt wrappers using libsodium and hope that future travellers can locate the tool or documentation so they can decrypt the data. So I stick with the only standard, GnuPG, despite acknowledging its problems.
  • tptacek 7y ago
    What specific problem are you trying to solve with PGP? If it's "encrypting files", why are you encrypting those files? What's the end goal? I acknowledge that there are cases that boil down to "encrypt a file", but believe they are a lot narrower than people assume they are.
    • stubish 7y ago
      We encrypt files: - For offsite backups (disaster recovery), mirroring object stores and filesystems to cheap cloud storage. - For encrypting secrets needed for maintaining IT systems (eg. all those shared passwords we never seem to be able to get rid of) - For encrypting sensitive documentation for transfer (email attachment, shared via filesystem, shared via HTTP, shared via pastebin even) Despite the awful UI, GnuPG does all of that in a standard way. We have tested disaster recovery with no more instructions than 'the files are in this S3 bucket'. And the same tool is also useful for other tasks too: - public key distribution (needs care to do it securely, but functional) - commit signing, signed tags - package signing (per Debian) We could use custom or multiple tools for all this, but a single tool to learn is a big advantage. I think all use cases boil down to 'encrypt and/or sign a file' for one of the stages. In the article, 'talking to people', 'sending files', 'encrypting backups' are all really just 'encrypt/sign a file' followed by transmission. And some sort of keyring management is needed for usability. A tool that can pull keys from a repository and encrypt and/or sign a file to a standard format could be used to build all sorts of higher level tools. I imagine it would be quite possible to build this on top of libsodium, and if it gained mindshare, replace uses of GnuPG.
• interfixus 7y ago
  > If you’d like empirical data of your own to back this up, here’s an experiment you can run: find an immigration lawyer and talk them through the process of getting Signal working on their phone. You probably don’t suddenly smell burning toast Well, currently extricating myself from the Signal mess, I really am expecting my smoke alarm to go off any minute. On intallation a couple of years back, the Signal app desparately wanted to curate my sms traffic, but forgot to inform me it would be holding my message history hostage. Forgot to inform me it would kill my instance, should I ever have the audacity to try setting up on a second phone unit. Forgot to inform me that yes, there is a desktop client, but it is useless Electron crap. Forgot to inform me it would be livestreaming my usage to everyone on my contact list - when I installed, when I reinstalled or changed devices, or when I mistook an ambigous list-feature for a personal book-keeping thing. The last item didn't happen to me, but to an acquaintance who thus had a somewhat embarrassing list of contact spilled out into the open. Not to mention the whole phone number based ID disaster, and the lack of any web interface. Sorry, but I'm out. Fully aware of serious concerns about the crypto and the privacy, but for UI, consistently well designed client apps, data export, and lack of nasty surprises, I have seen nothing to rival Telegram. Which may help explain why that seems to be where everyone is heading.
• Sniffnoy 7y ago
  So what do I use for encrypted messaging that can, like, replace email, then? Nobody seems to have provided any sort of satisfactory answer to this question. To be clear, an answer this has to not just be a secure way of sending messages, it also has to replicate the social affordances of email. E.g., things distinguishing how email is used from how text-messaging is used: 1. Email is potentially long-form. I sit down and type it from my computer. Text-messaging is always short, although possibly it's a series of short messages. A series of short emails, by contrast, is an annoyance; it's something you try to avoid sending (even though you inevitably do when it turns out you got something wrong). Similarly, you don't typically hold rapid-fire conversations over email. 2. On that point, email says, you don't need to read this immediately. I expect a text message will be probably be read in a few minutes, and probably replied to later that day (if there's no particular urgency). I expect an email will be probably read in a few hours, and probably replied to in a few days (if there's no particular urgency). 3. It's OK to cold-email people. To text someone you need their phone number; it's for people you know. By contrast, email addresses are things that people frequently make public specifically so that strangers can contact them. So what am I supposed to do for secure messaging that replicates that? The best answer I've gotten for this so far -- other than PGP which is apparently bad -- is "install Signal on your computer in addition to your phone and just use it as if it's email". That's... not really a satisfactory answer. Like, I expect a multi-page Signal message talking about everything I've been up to for the past month to annoy its recipient, who is likely reading it on their phone, not their computer. And I can't send someone a Signal message about a paper they wrote that I have some comments on, not unless they're going to put their fricking phone number on their website. So what do I do here? The secure email replacement just doesn't seem to be here yet.
  • lvh 7y ago
    Do you feel like PGP is a good way to cold email people in practice? (I'm not trying to put words in your mouth, but that sounds like what you're saying.)
    • Sniffnoy 7y ago
      Good question. Not sure. Although I don't see why I wouldn't, if they have a PGP key listed? (I guess there is some question over whether the listed key is actually them?) But my point is that, well, email is a good way to do that, and Signal isn't, so I'm going to use email rather than Signal. Honestly, I wouldn't focus on (3), because as I see it, if you can replicate the feel of email, things like (1)-(2), so that it can replace email in contexts without (3), then (3) will just come naturally as it slowly replaces email. Edit: All this is assuming it isn't tied to a phone number or something similar, of course!
• spullara 7y ago
  Identity is an unsolved problem. Even outside of digital use cases.
• tzs 7y ago
  While waiting for "age" to get written, can I use libsodium for file encryption?
  • jedisct1 7y ago
    https://download.libsodium.org/doc/secret-key_cryptography/secretstream https://download.libsodium.org/doc/secret-key_cryptography/s... Battle-tested by ransomware already (sigh).
• mstump 7y ago
  I was an engineer at PGP from 2004-2011 and ended up running the server team as lead engineer. I wouldn't disagree with most of the points brought up by the author, both the code base and standard has accreted over time and it's incredibly complex. There were only a couple of people on the team that really understood all the facets of either the OpenPGP or SMIME/x509 standards. It's made worse in that it was a hack on top of another system that had accreted over time (email) and that system was never intended to be secure. We had massive database of malformed or non-compliant emails from every email client since the beginning of time. The sub-packets that the author mentions were primarily used for dealing with forwarded chains of encrypted email messages where each previous message had it's own embedded mime-encoded encrypted/signed messages and attachments. The problem is that no-one else has gone through the process of establishing a community/standard that's capable of replacing it. Each system has built their own inoperable walled garden that doesn't work with anyone else, and none of them have a user base large enough to make encryption easy and pervasive. My own secret hope is that Apple is forced to open iMessage as a part of an anti-trust action and that acts as a catalyst for interoperability.
  • floatingatoll 7y ago
    Forcing iMessage to open will immediately result in MITM iMessage proxies that users can use to store iMessages that are meant to auto-delete, so that they can violate the wishes of the other party. These do not exist today because Apple binds iMessage to your hardware and bans your entire device when anyone is found to be operating such a service, either for themselves or others. Do you want open source clients that can be altered to ignore all privacy criteria — or do you want closed-source clients that make a good faith effort to adhere to auto-deletion protocols? Pick one. There is no middle ground.
    • olliej 7y ago
      iMessage doesn't have any kind of auto deleted messages - it's a feature that messages are persistent across all your devices.
      • 7y ago
• terom 7y ago
  > Encrypting Files > This really is a problem. If you’re/not/ [...] then there’s no one good tool that does this now. Filippo Valsorda is working on “age” for these use cases, and I’m super optimistic about it, but it’s not there yet. I've been (ab)using ansible-vault for this. It's apparently[1] now using reasonable primitives (PBKDF2+AES-CTR+HMAC-SHA256), but not necessarily the latest and bestest ones: https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/parsing/vault/__init__.py#L1108 https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/p... The implemention is sub-optimal though, with some silly issues that haven't been fixed like https://github.com/ansible/ansible/issues/12121 https://github.com/ansible/ansible/issues/12121 [1] http://toroid.org/ansible-vault-strange-crypto http://toroid.org/ansible-vault-strange-crypto
  • fanf2 7y ago
    I have some notes on why I (and some of my colleagues) use gpg instead of Ansible vault: https://dotat.at/prog/regpg/doc/rationale.html https://dotat.at/prog/regpg/doc/rationale.html I would dearly like a replacement for gpg in this context; `age` by Filippo Valsorda and Ben Cartwright-Cox looks like it will be nice, though I would like it to be easier to audit the recipients of encrypted files. Note that this kind of auditing relies on an information leak that cryptographers usually try to suppress...
• jeroenhd 7y ago
  Whent talking about alternatives, Signal and WhatsApp get mentioned because they're easy to use. They are. Signal is pretty secure. WhatsApp probably is as well but we can't be sure. That is, until it isn't anymore. WhatsApp already has a key extraction protocol built right in for its Web interface. Signal has a web (Electron) interface as well, and a shitty one at that, where the messages also get decrypted. For WhatsApp, this means you're one line of code away from Facebook extracting your private keys. Signal is different, in that they're not a for profit company. However, they've shown in the past that they are under no circumstances willing to allow support of any unofficial client or federate with another. In fact, they've taken steps against alternative clients on the past, making it clear that only their client is allowed to use the signal system. The moment the signal servers go out, Signal becomes unusable. This also leaves signal in the same position as WhatsApp, where we are dependent on one person compiling the app and publishing it on whatever app store you prefer. If signal has any Australian contributors and their code review fails sufficiently this means you're basically toast the moment the Australian government gets annoyed at a particular signal user enough. Very few real alternatives to PGP exist. PGP is not just a message encryption format, it's a _federated_ message encryption format. There are very few actual federated message standards that come close to the features PGP supports. There's S/MIME, but that's only available after paying an expensive company for it to be of any use because it's validated as a normal TLS certificate and the free vert providers don't do S/MIME. If all of these "real cryptographers" disagreeing with PGP's design would design a new system that can be used the same way PGP is used, I'm sure we'd see that getting some good usage figures quite quickly. But all alternatives seem to focus on either signing OR encrypting OR the latest secure messaging app instead of a PGP replacement.
  • AmericanChopper 7y ago
    I think the real problem is that nobody has ever created a decent PKI, and I doubt a sufficiently secure PKI is even possible. CAs require you to trust people that aren’t supposed to be party to the communication (trust both not to be hostile, and not to be insecure themselves). All other forms of PKI offer entirely impractical authentication mechanisms. With signal and the like, your options are 1) Verify keys by being in the same room as the other party before communication, and after every key rotation 2) Just hope that the keys are genuine... The only thing that you can trust is that the party you’re communicating with is one of potentially many holders of the correct key.
• mikorym 7y ago
  First of all, if you are signing something and want to prove that you are the author, then PGP will allow you to do that. If you want to encrypt something and prove you are the author, PGP will still allow you to do that. Does the author mean that PGP is bad for email specifically? Excel has many of the mentioned properties, such as backwards compatibility and inefficiency, but it gets the job done and you bet it will pay your bills. It feels to me like these posts are like the 80:20 problem, but rather with 99:1 and it's all about that 1%. I understand that software developers should use libsodium. But I'll sign the words "U R A >on" right now in GPG and wait for you to break my key and sign "U R 1 2" with my private key...
  • Natanael_L 7y ago
    With "Johnny you're fired", it's clear that many clients don't correctly validate PGP signatures
    • mikorym 7y ago
      So my question is this: is PGP itself to blame or are people basically saying, "Don't use PGP unless you know what you are doing." I don't really know what concrete advice the article gives for me personally. (The only thing I take away from this is to learn libsodium as well, rather than not using PGP.)
  • lunchables 7y ago
    Yeah, most (all) of these arguments seem silly. The primary argument not to use it in emails because someone MIGHT improperly quote your email in a reply and then NOT encrypt their response? Well someone might screenshot your Signal app, or have malware on their phone, or a million other things. It seems like such an absurd corner case to me. For my use case I don't have any concerns about using GPG. I encrypt files with it, and if anyone wants to put up any money that they can access my files, let me know what escrow service you want to use.
    • riking 7y ago
      Not because it "MIGHT" happen, because it does happen.
• trabant00 7y ago
  The problem with the alternatives is they are product specific and baked into that product. I need a tool that is a separate layer that I can pipe into whatever product I want, be it files, email, chat, etc. Managing one set of identities is hard enough thank you very much and I also want to be able to switch the communication medium as needed. I use gnupg a lot and I'm certainly not very happy with it but I guess it's the same as with democracy: the worst system except for the all the others.
  • Natanael_L 7y ago
    The problem with this is that a tool that is too generic is itself dangerous, because it creates cross protocol attacks and confusion attacks like in https://efail.de https://efail.de for PGP email. I think that a better approach is to bind identities from multiple purpose built cryptographic protocols.
    • trabant00 7y ago
      If you blame gpg for efail you can blame anything really for a virus on one of the endpoints of any form of encryption. Next you will hold rensponsible tech for social engineering and mandate users should not know their own secrets because that causes vulnerabilities in protocols :p
      • Natanael_L 7y ago
        By that logic we shouldn't recommend cars with high safety ratings, because we can always train users to drive motorized unicycles at 200 MPH. Clearly there's no fault with the unicycle regardless of how many people crash, it behaved as specified. Except the specification is trash.
        • trabant00 7y ago
          Except cars with 5 star rating exist but a better solution than PGP doesn't.
• jmspring 7y ago
  Long story short - signed / encrypted emails are hard. SMIME doesn’t really exist any more. Sending secure email is hard.
• taeric 7y ago
  I don't understand why the use of Yubikeys for a non-exportable key isn't valid for folks that care about security. I mean, I get that not everyone will use it. The vast majority won't. However, the vast majority don't care about security at this level. So... what is the actual criticism? If you care about security, use the keys, right? That feels no different from "use some other product."
  • dchest 7y ago
    The only thing in this world more complicated than setting up GPG is setting up GPG with Yubikey. The fact that I have `fix-gpg` script to restart gpg-agent somewhere in $PATH that I run when for some reason it can't find my YubiKey tells me that it's not a viable solution for 99% of people. PS. Actual command from GPG: > help ... sex change card holder's sex ...
    • dewyatt 7y ago
      This is more an issue with GnuPG though, not OpenPGP. Also, you may want to try using an actual OpenPGP Card (https://www.floss-shop.de/en/security-privacy/smartcards/13/openpgp-smart-card-v3.3 https://www.floss-shop.de/en/security-privacy/smartcards/13/...). (You can get a small one inside a USB token too)
    • taeric 7y ago
      On older machines, I agree. On recent installs, it just worked. Getting it to work with my phone is slightly dumber. But still not super hard.
  • lvh 7y ago
    Sure. We do that for eg SSH. I don’t think it’s a great idea for our standard audience (startups) to implement.
    • taeric 7y ago
      I'm not sure what you mean. :(
• maufl 7y ago
  I use my PGP key (with a Yubikey) for two things, the pass password manager and as an SSH authentication key. Is there a replacement for those two use cases where I can store my private key on a hardware token?
  • mongol 7y ago
    Given that you have set this up, and that both of these usecases are for your own use only, I wonder if there is any reason to change. Most criticism in the article is about the complexity on a larger scale.
  • tptacek 7y ago
    I use the GPG compatibility goo to get an SSH key out of my Yubikey 5 and that's fine, it's fine, go ahead and do that.
• upofadown 7y ago
  So the suggested solution for more secure email is just to give up on the concept of email entirely? Anything that does not do perfect forward secrecy is just pointless so there is no point in trying to keep significant discussions to refer to later. We are expected to return to a sort of virtual pre-writing stage. This is not really helpful. For all its shortcomings, PGP is pretty much all we have. If used in a straightforward way it actually can protect email from nation state level actors for a significant time. That's gotta count for something.
  • swalladge 7y ago
    I know right - they are all recommending Signal, Wire, WhatsApp, etc., but these aren't alternatives. They are all centralized, controlled by a single entity even if the underlying protocols are open. And you're right, they are instant messaging - ie. alternatives to Messenger, Hangouts, etc. We need a modern email replacement that is decentralized, federated, et al. Something that keeps all the modern cryptographers happy, while facilitating the same kind of long form conversations and federated self-hostability that email provides. I think Matrix is getting there, but even that is still focused on instant messaging.
    • Natanael_L 7y ago
      As I've mentioned in another thread, I think we're more likely to get there via the route of E2EE documents collaboration tools. Something that cleanly breaks away from the email model, and adds enough value to make the switch worth the effort.
• acqq 7y ago
  PGP has issues, but for many use scenarios there is effectively no ready alternative at the moment. Until there is, whoever already uses or knows how to use GPG is still better off using GPG than not using anything. Signal is especially not a good replacement for anybody who doesn't want to have "secure" communication connected to his (or any) phone number and to the central server. The major issue with GPG is that in some (many?) cases a user could believe to be more protected by using it than the user is. But the same can be said for other technologies. And the article rightly notes that the GPG defaults are often bad. The right question to ask first is always: https://www.usenix.org/system/files/1401_08-12_mickens.pdf https://www.usenix.org/system/files/1401_08-12_mickens.pdf Are you "dealing with Mossad or not-Mossad"? (Also worth noting is that somehow Edward Snowden managed to "deal with" NSA and still remain out of prison. At least he knew from the start the answer to the question.) Still, anybody who wants to replace PGP in some PGP use-case should provide a really good alternative for that use-case. As of right now, there isn't any better for even such a simple need as encrypting a file. Let's discuss it once we have that one, at least. And even then, we'll need to be able to open our old files, meaning we'll still need GPG for that.
• mongol 7y ago
  The pass password manager uses PGP, what would be a better design?
  • eikenberry 7y ago
    Nothing at present, but the article did talk about work being done on a project that will be able to work as a direct replacement for pgp in this use case. Near the end, look for the mention of 'age'.
  • tptacek 7y ago
    Pass is an interesting case, because of how it's implemented. The easy, obvious answer would be "a version of pass that uses libsodium (or Jason's own crypto library) instead of pgp", but there's no command line for those tools, and the only other command line widely available for cryptography is OpenSSL's, which is horrible.
• belorn 7y ago
  Telling people to treat email as insecure and thus not use it for anything serious is terrible bad advice. I am reminded of BGP (Border Gateway Protocol). Anyone who has even glanced at the RFC of BGP could write an essay of the horrible mess of compatibility, extensions, non-standard design of BGP. It also lack any security consideration. The problem is that it is the core infrastructure of the Internet. Defining something as insecure with the implied statement that we should treat it as insecure is unhelpful advice in regard to critical infrastructure. People are going to use it, continue to use it for the unforeseeable future, and continue to treat it as secure. Imperfect security tools will be applied on top, imperfectly, but it will see continued used as long as it is the best tools we have in the circumstances. Email and BGP and a lot of other core infrastructure that is hopelessly insecure will continue to be used with the assumption that they can be made to be secure, until an actually replacement is made and people start to transition over (like how ipv6 is replacing ipv4 and we are going to deprecate ipv4 if you take a very long term view of it).
  • tptacek 7y ago
    People that use email to convey sensitive messages will be putting themselves and others at risk, whether or not they use PGP, for the indefinite future. That's a simple statement of fact. I understand that you don't like that fact --- nobody does! --- but it remains true no matter how angry it makes you.
    • belorn 7y ago
      I would say that people that use any critical infrastructure not designed with security in mind is putting themselves and others at risk if they convey sensitive information. This is why plain text protocols should be considered insecure. It would be great if we could replace the whole Internet with modern technology rather than relying on ancient systems like BGP and email.
      • tptacek 7y ago
        How do you write this after writing that previous comment, which says that what I just wrote is "terrible bad advice"?
• classics2 7y ago
  Poorly thought out and argued.
• foolfoolz 7y ago
  i work with a manufacturer that’s a multi billion dollar behemoth and they move at the slowest possible pace. every decision takes weeks, a hundred emails, 20 phone calls, and 10 pdfs. we needed to add encryption to data we exchanged. they said PGP and gave me a pgp key. i encrypted a test file and gave my key back. within 20 mins we had an answer and moved on. this easiest part of anything we have ever integrated with them
• giomasce 7y ago
  As usual, all articles of this OpenPGP-is-bad kind keep failing acknowledging OpenPGP's most important feature: it has a way (clumsy as much as you wish, but existing) to attach identities to keys, and to verify them. I have a rather well connected OpenPGP key, and that means that anyone can verify the signed emails claiming to be from me are actually from me, even if we never met. Of course you can mention XKCD and people saying they will never check a signature, but that's their problem, not mine. If do not bother to check your keys, any encrypting/signing system is untrustworthy. If you have a lot of keys, each for any of your crypto applications, and no way to cryptographically tie them to an identity, you will eventually mess them up, especially if they have to be deployed on more than one machine. I am perfectly fine with saying that GnuPG uses old algorithms, or that different applications should use different keys, algorithms or techniques. But, please, when designing such systems keep in mind that you want to check where your keys come from and which identity they are attached to. And TTBOMK only OpenPGP is currently able to do that. To me it would be great if all crypto applications done in the right way would have a way to tie their keys to the OpenPGP web of trust, in the same way Monkeysphere tried to do for SSL and SSH keys.
• sparkling 7y ago
  So what should we use for public/private asymmetric encryption then?
• progx 7y ago
  Messenger are not easier than email, only when 2 ore more communicate on one topic. But with email you communicate with one or more people about many topcis. To archieve the same structure in a messenger, you must create several discussions. So messenger are not the holy grail of communication, that is why people still use email. We need an email user interface with open messenger protocols under the hood for secure communication and usability. None of the current messenger offer that.
  • jobigoud 7y ago
    Good point, private channels are the new discussions. But they tend to never die so over the years we end up with a cluttered channel list.
  • goffi 7y ago
    For a proof of concept, I've made a couple of years ago a "gateway" which was launching a local IMAP server in my XMPP client. This way you could use any MUA you like while taking profit of XMPP infrastructure (JID — XMPP identifier — are similar to email addresses) and its encryption (OMEMO can be used with that for instance). In other words, you could send messages from Thunderbird (or Gajim) to KMail by using only XMPP protocol (and thanks to IMAP Push, you got notifications immediately).
• chmike 7y ago
  So, how I sign git commits if I don't want to use PGP (GPG) ?
• Whatitat90 7y ago
  The post is well-written and summarizes I think most major pain-points with PGP. Comparison of all these tools to GnuPG is valid and it clearly shows not only implementation problems but design ones as well in gpg. What I fear is future riddled with all these incompatible tools. Even if they're written by brilliant engineers and cryptographers they are not standards (e.g. IETF standards). Why is that important? For example rewriting libsignal from scratch (for example to publish it under permissive licenses) can be problematic [0]. [0]: https://news.ycombinator.com/item?id=12056673 https://news.ycombinator.com/item?id=12056673
• Leace 7y ago
  > there’s a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography SSL was designed in 1994 but it has been properly maintained and today no-one argues that TLS should be replaced by noise/strobe etc. OpenPGP's problem no 1. is that there are no parties using it on a wider scale and interested in improving it.
  • akerl_ 7y ago
    I’d argue for replacing TLS if it were plausible to replace TLS for mainstream users. HTTPS is a dumpster-fire for a lot of the same reasons PGP is. For example, the fact that there’s a grab bag of different ciphers, compression options, and other toggles makes properly picking settings an exercise in copy-pasting from a site you trust or guessing and then running an SSL Labs test until it comes back green. If you miss something, congrats, somebody can MITM and trick your users into downgrading. Things like this are why the most notable features of TLS 1.3 are the things it removed, more so than what was added.
    • Perceptes 7y ago
      I guess one difference here is that often major implementations of HTTPS make the best choices (like operating systems, major browsers, major web server software, etc.), whereas with something like PGP, everyone is using GPG which has only one implementation which is known to be terrible.
  • tptacek 7y ago
    SSL 2.0 was overhauled (by cryptographic experts) to create TLS, and, after something like 10 years of effort, support for SSL 2.0 was scourged off the Internet. And still, we had the DROWN attack a couple years ago, which manages to exploit cross-protocol attacks between SSL 2.0 and TLS on different servers. In the last few years, we got TLS 1.3, which again made significant, breaking changes with the previous versions of the protocol (such as getting rid of the RSA handshake), and presumably over the next 10 years we'll be shedding support for all previous versions of TLS. That's what didn't happen with PGP.
• Leace 7y ago
  > Long term keys are almost never what you want. If you keep using a key, it eventually gets exposed. You want the blast radius of a compromise to be as small as possible, and, just as importantly, you don’t want users to hesitate even for a moment at the thought of rolling a new key if there’s any concern at all about the safety of their current key. Interestingly some protocols such as roughtime use the same tactic as OpenPGP: one long-term identity key that can be kept offline and rotation of online (short-term) keys signed by the long-term key. Details here: https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md#certificates https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL...
  • lvh 7y ago
    If you squint enough, that’s how CAs work too.
• bennofs 7y ago
  I understand that there are better tools for encryption, but is there anything that replaces the identity management of PGP? Having a standard format for sharing identities is necessary in my opinion. If I have a friend (with whom I already exchanged keys) refer me to some third friend, it would be nice if he can just send me the identity. Sending me the signal fingerprint isn't a solution for two reasons: - I don't want to be manually comparing hashes in 2019 - it locks me into signal, I wont be able to verify a git commit from that person as an example Is there a system that solves this? Keybase is trying but also builds on PGP, we can use S/MIME which relies on CAs but is not better than PGP. Anything else?
  • louis-paul 7y ago
    Keybase builds a lot on top of saltpack, which works like a saner PGP: https://saltpack.org https://saltpack.org The underlying cryptography is NaCl, which is referenced in the original post.
    • cpach 7y ago
      I don’t get it. How does Saltpack solve the issue of identity management?
      • louis-paul 7y ago
        saltpack does not solve identity management itself, it is merely the cryptography and the physical format. Keybase, however, is all about identity: https://keybase.io https://keybase.io.
  • mike_hearn 7y ago
    The CA system is strictly better than PGP for identity management in every respect. People often think it must be the opposite but this is essentially emotional reasoning: the Web of Trust feels decentralised, social, "webby" un"corporate", free, etc. All things that appeal to hobbyist geeks with socialist or libertarian leanings, who see encryption primarily through the activist lens of fighting governments / existing social power structures. But there's nothing secure about the WoT. As the post points out, the entire thing is theatre. Effectively the WoT converts every PGP user into a certificate authority, but they can't hope to even begin to match the competence of even not very competent WebTrust audited CAs. Basic things all CAs are required to do, like use hardware security modules, don't apply in the WoT, where users routinely do unsafe things like use their private key from laptops that run all kinds of random software pulled from the net, or carry their private keys through airports, or accept an email "From" header as a proof of identity. I wrote about this a long time ago here: https://blog.plan99.net/why-you-think-the-pki-sucks-b64cf5912aa7 https://blog.plan99.net/why-you-think-the-pki-sucks-b64cf591...
• mirimir 7y ago
  FYI, Robert J. Hansen's comment in gnupg-users@gnupg.org.[0] 0) https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062384.html https://lists.gnupg.org/pipermail/gnupg-users/2019-July/0623...
  • tptacek 7y ago
    I don't understand how these represent "mistakes", let alone "serious mistakes". But I'm glad he liked it.
    • mirimir 7y ago
      It's over my head, but I thought that a reference would be useful. Given that the mail list thread references HN.
      • tptacek 7y ago
        Oh, no, sorry, I'm glad you posted this; I wouldn't have known where to look. Thank you!
• ajsnigrutin 7y ago
  But.. it's the only thing we have. Until some "pgp alternative" for signing and encrypting emails comes along, and is adopted by "most" email clients, it's the best thing we've got, even if it's "bad".
• swalladge 7y ago
  Something I'm curious about - if GPG uses such old/not-recommended encryption standards, is it still secure in the sense that if I gpg encryption something and post it online, a three letter agency will be still unable to decrypt it?
  • lvh 7y ago
    There are two ways that breaks: - your key won’t be private forever but future compromise does mean past disclosure - on long enough timescales if said TLAs can mount offline attacks against it. So, maybe? But it’s definitely the safest way to do it, most of GPGs problems are unforced interaction errors.
• tialaramex 7y ago
  There's a few places where this engages in goalpost shifting that seems less than helpful even though I end up agreeing with the general thrust. Let's focus on one: > Put a Signal number on your security page to receive bug bounty reports, not a PGP key. We can reasonably assume in 2019 that this "security page" is from an HTTPS web site, so it's reasonably safe against tampering, but a "Signal number" is just a phone number, something bad guys can definitely intercept if it's worth money to them, whereas a PGP key is just a public key and so you can't "intercept" it at all. Now, Signal doesn't pretend this can't happen. It isn't a vulnerability in Signal, it's just a mistaken use case, this is not what Signal is for, go ask Moxie, "Hey Moxie, should I be giving out Signal numbers to secure tip-offs from random people so that nobody can intercept them?". [ Somebody might think "Aha, they meant a _Safety number_ not a Signal number, that fixes everything right?". Bzzt. Signal's Safety Numbers are per-conversation, you can upload one to a web page if you want, and I can even think of really marginal scenarios where that's useful, but it doesn't provide a way to replace PGP's public keys ] Somebody _could_ build a tool like Signal that had a persistent global public identity you can publish like a PGP key, but that is not what Signal is today.
  • Leace 7y ago
    > persistent global public identity Certificate Transparency could be reused/abused to host it. If, for example, you issued a cert for name <key>.contact.example.com and the tooling would check CT logs this could be a very powerful directory of contacts. Using CT monitors you could see if/when someone tampers with your domain name contact keys. Mozilla is planning something similar for signing software: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
    • Natanael_L 7y ago
      This is basically the keybase.io log system. Although they too rely on PGP currently
      • Leace 7y ago
        Minus the network of independent logs as from what I remember only keybase.io runs their own log system. Although they do timestamp their Merkle tree roots into Bitcoin.
• Anonymous4C54D6 7y ago
  Hi Thomas et al.! Good write-up and with several software suggestions that I didn't know. Excellent! I think one thing you are missing is an "alternative" for the identity problem. I somewhat agree that all long-term keys are a problem but how do we build an identity out of a bunch of keys for different systems, covering privacy concerns, with some sort of key transparency to detect attacks, ... I think this would be a very interesting post from you guys that I would love to read. ;)
• jedisct1 7y ago
  PGP was a game changer when it was introduced and the idea of a chain of trust was neat. Unfortunately, its implementations are difficult to use, it was never directly supported by operating systems or major applications, and its crypto agility makes it impossible to write minimal implementations. I wrote and use Piknik for small files transfer (especially with the Visual Studio extension), Encpipe for file encryption and Minisign to sign software. What they have in common is that they are very simple to use, because they only do one thing, with very little parameters to choose from. The main reason for having written these in the first place was that PGP is too complicated to use, not that it couldn't have done the job.
  • philips 7y ago
    Has there been any effort to integrate minisign into git?
    • jedisct1 7y ago
      None that I know of, but it's never too late :)
• davidcollantes 7y ago
  With PGP I can encrypt/decrypt/sign files, and text. It is widely available in every platform. The day a single tool comes around that does that, better, I will switch.
• teythoon 7y ago
  We over at Sequoia-PGP, which gets a honorable mention by the OP, are not merely trying to create a new OpenPGP implementation, but to rethink the whole ecosystem. For some of our thoughts on the recent certificate flooding problems, see https://sequoia-pgp.org/blog/2019/07/08/certificate-flooding-sks-gnupg-issues-the-sequoia-project/ https://sequoia-pgp.org/blog/2019/07/08/certificate-flooding...
  • lucb1e 7y ago
    The homepage has some meaningless marketing bullet points about the greatness of pgp itself. Where would I find the ways in which you rethink the whole ecosystem? It seems like Sequoia is just a library, not even a client. Wondering how this could change pgp by much if at all.
• danielrangel 7y ago
  My minisign implementation in rust compatible with signify and minisign keys https://crates.io/crates/rsign https://crates.io/crates/rsign
  • jedisct1 7y ago
    And based on your implementation: https://crates.io/search?q=rsign2 https://crates.io/search?q=rsign2
• CloudBuddy 7y ago
  Use ccrypt instead. It is very reliable. https://github.com/Scott-Kaplan/Client-Side-Encrypted-Backups https://github.com/Scott-Kaplan/Client-Side-Encrypted-Backup...
• eudora 7y ago
  Pretty shocking, thanks for such a detailed analysis
  • lucb1e 7y ago
    It's a large number of minor points. Nothing shocking, no huge issues, and of course nothing we didn't already know. The crypto is good, if you manage it well it stands up to the NSA as far as we know... Sure, it has flaws that make it hard to use in general, and hard to use securely (no long term keys, for example, would make me less paranoid about my private key), but it's still fine despite having huge backwards compatibility. The author is overly dramatic about it in order to make a point, to hopefully get people looking for alternatives, so that a good one might take it from pgp in the future (and continues to suggest whatsapp and signal, like, really? That's your replacement for pgp?).
    • pvg 7y ago
      The crypto is good It's not. This is detailed in the piece. What do you think it gets wrong? That's your replacement for pgp? One of the key points is that by now we know PGP is a bad idea conceptually. There can't be a replacement for PGP. This is a bit like asking what what's to replace mummification now that we know it doesn't really grant access to the afterlife.
• fipar 7y ago
  So, as a technical person (I can write and debug software, deploy it to production, etc.) but only an end-user when it comes to cryptography: What are the biggest weakenesses of using PGP for local file encryption? My use case is I have a 'vault' of secrets that I store in a gpg-encrypted org file, with a key binding in emacs to let me easily decrypt this 'vault'. The encryption is done with gnupg's symmetric encryption, i.e., just me typing a passphrase, not using my private key. This encrypted file resides in a Filevault-encrypted drive, and is backed up to a an encrypted TimeMachine backup. It never leaves my local drive or the external USB drive I use for backups (at least not that I know of). What are my biggest risks here? I did not get much info from the article on this use case other than "perhaps wait for age". I understand I could be using an encrypted volume that I mount on demand, which I already do for other use cases, but that would get rid of the convenience of having this "vault" available to me just one emacs shortcut away. I'm willing to give that up if the risks are big enough but I'm kindly asking the knowledgeable HN audience for advice to see what I'm doing is really that bad.
  • yitosda 7y ago
    There's nothing wrong with this. Public/Private keys are for sharing secrets and proving identity. Assuming you are using a sane cipher and mode, your risks boil down to any of a myriad of methods of stealing/bruteforcing your key or grabbing the unencrypted file.
    • fipar 7y ago
      Thanks!
• thepangolino 7y ago
  PGP has one big problem: Lack of a proper email infrastructure. And by "email infrastructure", I mean proper support by most email clients contact apps. The most basic use case seem to have never been addressed. You receive an email with a public key attached. Clicking on it should automatically open your contact app and ask if you want to add it to your contact's details. It should also be synchronizable with cardDAV or any other protocol of your choosing.
• summitto 7y ago
  Until a better solution is brought forward, my team implemented a PGP packet library to make everyone's lives a little bit easier: https://github.com/summitto/pgp-packet-library https://github.com/summitto/pgp-packet-library Using our library you can generate PGP keys using any key derivation mechanism for a large variety of key types! When using it right, this will greatly improve how you can generate and back up your keys!
  • lvh 7y ago
    Does this improve on gpg2 —list-packets for practical debugging/auditing of extant GPG setups, or is just useful for people who want to do alchemy on top of the OpenPGP packet format?
    • summitto 7y ago
      It just parses the packets with a relatively easy API, for those which want to do alchemy or which want to build tools for practical debugging/auditing purposes in C++ instead of using shell commands.
• lucb1e 7y ago
  For backups, I would recommend Restic. The author mentions Tarsnap, and if you don't want to back up five terabytes that is probably great, but after a few gigabytes it's just not economical for private persons. If you're on hacker news (i.e. the 'engineer' the author was talking about), odds are that storing a hard drive connected to a raspberry pi at your parents' and using Restic as client is an extremely cheap way of backing up many terabytes securely.
  • criddell 7y ago
    For Windows users that were wondering, Restic doesn't back up files that are opened exclusively. VSS support on Windows is an open issue: https://github.com/restic/restic/issues/340 https://github.com/restic/restic/issues/340
  • wbl 7y ago
    I have a few gigabytes on tarsnap for pennies a day.
    • lucb1e 7y ago
      Hence "after a few gigabytes".
• dewyatt 7y ago
  > Every well-known bad cryptosystem eventually sprouts an RFC extension that supports curves or AEAD, so that its proponents can claim on message boards that they support modern cryptography. I'm being attacked! :P
• verytrivial 7y ago
  I read these advice columns like "You should stop using hand saws because we now have electric saws which are better in every way that I care about." Great! You use them then. I'll keep using crufty old hand saws wherever I want, you use and proselytize your electric saws and we can get on with our lives. I have my own networks and threat models and my own evaluation functions for these. Hand saws are pretty good.
  • tptacek 7y ago
    If your threat models have you using PGP, your threat models are badly engineered.
    • verytrivial 7y ago
      That's pithy. I have used PGP sign (via an air gap) release tarballs on a public server for clients that have individually verified my org's public key. It made sense in this context and everyone already had the tools. My point is we have our own contexts.
      • tptacek 7y ago
        If you used signify/minisign to do the same thing, your workflow would be simpler, your keys shorter, and your entire stack more secure. Since clients are individually verifying your key, none of PGP's identity goo is even ostensibly winning you anything. Your context isn't the issue.
• hiq 7y ago
  Glad to see wormhole listed here, I hadn't seen it recommended by security experts before. Is there also a similar consensus about Syncthing and whether it is secure enough for long-term file-sharing?
• w8rbt 7y ago
  Stop parroting these criticisms of OpenPGP without offering concrete, working replacements that are widely adopted and have open standards. Some kid recently tried to have OpenPGP support deprecated from Golang's crypto-x package. And that's fine, but do not pull stunts like this without offering a concrete, working and widely adopted replacement. Otherwise, they are just that, publicity stunts with a lot of sound and fury but no solution. That's not helpful to anyone. A more mature thing to do would be to suggest deprecation in 3 to 5 years and offer a plan of how to get there with other specific tools (some of which do not exist today).
  • lvh 7y ago
    I was going to say something about how the article does mention several alternatives, some of which far more widely deployed than OpenPGP. But first: hold up. "Some kid"? You mean Filippo Valsorda? Google's Go Crypto person? The same person who is writing the replacement for that one use case?
• 0xCMP 7y ago
  They mention encrypted volumes for offline backups and storing files which must be encrypted. For cross platform I'm guessing VeraCrypt is the recommended software now right?
• tebruno99 7y ago
  So far there has been a lot of hate on Hacker News about PGP. I'm sure most of it is true, maybe we shouldn't use PGP. However, every single one of these that offers suggestions cops out at end about encrypted files leave people with.. PGP.