7 ms·

PGP Marks 30th Anniversary

185 points by throw0101a 5y ago

tptacek 5y ago
It was on this day in 1991 that Pretty Good Privacy was uploaded to the Internet [... then...] a number of volunteer engineers came forward and we made many improvements. In September 1992 we released PGP 2.0 in ten foreign languages Fun fact: "We made many improvements" is doing an interesting lift in this paragraph, since PGP 1.0 shipped with a cipher of Zimmerman's own design, Bass-O-Matic, which lived up to its name in part by being demolished by Eli Biham over a lunch. PGP 2.0 introduced IDEA, and, I believe, the first (for the era) cryptographically credible version of PGP; a more fitting anniversary to celebrate, perhaps. (We've learned quite about about how to engineer cryptography in the ensuing 29 years, and PGP hasn't kept up --- can't, really; so on the 30th anniversary of Bass-Free PGP, we might fittingly celebrate by finally giving PGP a well-earned retirement.)
- schoen 5y ago
  More about this story: https://crypto.stackexchange.com/questions/61948/what-was-the-bassomatic-cipher-and-what-made-it-so-weak https://crypto.stackexchange.com/questions/61948/what-was-th... I just downloaded the source code for PGP 1.0 and found BASSLIB.C. 1988! It's interesting to note that the Bass-O-Matic design apparently came from a Navy contractor (Charlie Merritt). It seems possible that Merritt and the Navy both thought this design was secure; maybe they didn't have clearances to learn others' opinions about it, and only used it for unclassified communications.
- greenyoda 5y ago
  What do you recommend as a replacement for PGP? (I'm looking for stand-alone software I can use to encrypt files on storage media, not an encrypted e-mail service.)
  - tptacek 5y ago
    The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs. For package signing: use something in the signify/minisign family. To encrypt a network transport, use WireGuard. To protect a web transaction on the wire, TLS 1.3. For transferring files: use Magic Wormhole. For backups: use something like Tarsnap or restic. For messaging: use something that does Signal Protocol. To protect files at rest, use encrypted DMGs (or your OS's equivalent, like encrypted loop mounts). To encrypt individual files --- a niche ask --- use Filippo's ungooglable "age".
    - greenyoda 5y ago
      Thanks! Link to "age", for those who are interested: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
      - upofadown 5y ago
        Last I looked "age" did not have any sort of recovery utility. It isn't even clear that such a utility is possible (the protocol is poorly documented). A single bit error at the start of the file causes the loss of the entire file. So be careful using it for any sort of thing that might ever require the sort of recovery that bzip2 or lzip provides (gzip has a third party recovery utility). OpenPGP has excellent recovery properties out of the box BTW...
        tptacek 5y ago
        I want to be sure I'm reading this correctly. Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Any error you accept is malleability conceded to an attacker. Are you complaining that age isn't malleable enough?
        upofadown 5y ago
        >Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Yes, this is an excellent example of where this behaviour is suboptimal. We should not cargo cult authenticated encryption. It has its place but this isn't it. > Any error you accept is malleability conceded to an attacker. Sure, but malleability that has a close to zero chance of being a problem. We are talking about static encryption here. You only get one chance at malleability and the user immediately knows something has gone wrong: gpg: WARNING: encrypted message has been manipulated! >Are you complaining that age isn't malleable enough? Merely pointing out that for the most common use case age is objectively worse than GPG.
  - intc 5y ago
    I think PGP is fine for encrypting some files. But you should take into consideration that when you encrypt a file it's very likely that some (or all) of the plain text is left behind on the block device. Using full disk encryption (LUKS for example) will give additional protection (so one can't read plain text fragments from the device when it's not "open").
  - makach 5y ago
    I don’t understand why people want to replace PGP. Of course we can improve the technology but the fact is that security is hard and requires interplay between the humans, processes and technology to work. It’s not enough to rely on just one of those pillars. There is an illusion in the world of IT that we can solve everything with technology. Maybe the reason why people don’t want or like PGP is because it needs strong human processes to work properly and keep its integrity, and that breaks the illusion that you can easily solve everything with tech. Happy birthday PGP!
    - tptacek 5y ago
      It's funny that you could make literally the same argument about C, especially since so much of the PGP ecosystem relies directly and entirely on software built in C.
    - tialaramex 5y ago
      > Maybe the reason why people don’t want or like PGP is because it needs strong human processes to work properly and keep its integrity, and that breaks the illusion that you can easily solve everything with tech. What you've got here is pretty much the mirror of the argument you've dismissed a paragraph earlier. Now you're desperate to rely on humans instead. This makes me think about Snowpiercer, for two reasons. One is that Snowpiercer has this ludicrous conceit about replacing unavailable engine components with humans but the other is that we've really been here with the actual railway trains in the nineteenth century. There was a pattern. One of these new-fangled railway trains crashes, often killing many people, the company directs public blame toward the driver, who will be portrayed as incompetent, drunk or worse and so fully responsible for the accident. Nothing changes, rinse, repeat. How was this cycle broken? We did not find some species of super-human train driver, instead we invented technology such as the Absolute Block system, Interlocking railway signals, the Dead Man's Handle. Even apparently trivial technologies like the Driver's Reminder Appliance (it's just a switch!) are still technology. PGP isn't very good technology. Like one of those early mechanical signals that might seem to indicate "clear" but it's actually just weighed down by snow and frozen in place so that it can't indicate "danger" instead, the way forward isn't "We need to rely on super-humans to compensate for the short-comings of the technology" but "We need a technology that sucks less so the humans don't need to be super-human to succeed".
  - darkr 5y ago
    The other points in this thread recommending modern, context-specific cryptography tools are very valid, however if you're set on PGP; Sequoia[1] is a new(ish) OpenPGP library written from the ground up in Rust. 1: https://sequoia-pgp.org/ https://sequoia-pgp.org/
    - tptacek 5y ago
      Sequoia is fine work, and running less C code is a good thing, so if you have to use PGP (sorry) then use Sequoia. But note that the PGP ecosystem is hopelessly mired in GPG, and the problems go beyond C code --- Sequoia, for instance, is (AFAIK) the first popular implementation of AEAD crypto for GPG, but AEAD doesn't interoperate with GPG.
- scruffyherder 5y ago
  https://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/pgp/?cvsroot=pgp;only_with_tag=pgp10 https://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/pgp/... I still use PGP 1.0 as all of the scanners that check for stuff can't recognize any of it, and it slides through. It's more of payload thing
waynesonfire 5y ago
such a great tool. It's not a serious security product unless you support PGP.
- schoen 5y ago
  I'm a huge fan of Phil and his work, and plan to send him a note of thanks, but I think your second sentiment is out-of-date now. Even if we avoid other controversies like Thomas Ptacek's views about the inappropriateness of the e-mail encryption threat model, PGP doesn't support forward secrecy and so it's at least not suitable for instant messaging or TLS (as well as not being integrated into their protocols!). A serious security product could support encryption that's more relevant to whatever it is that that product does.
  - techwizrd 5y ago
    Not all use cases require perfect forward secrecy, so I think PGP can still be useful for some applications (and I tend to enjoy using PGP). I agree however with your point that serious security products do not need to support PGP specifically.
  - Avamander 5y ago
    Given that e-mail is not going anywhere in the next few decades, having a way to encrypt it to at least some extent is valuable.
  - lmm 5y ago
    I've never seen a realistic threat model where Signal-style forward secrecy actually helps. Suppose a repressive regime captured one dissident can see a bunch of messages between them and other people, but theoretically some crypto nerd might have been able to forge those messages if the dissident has been carefully publishing the material they're supposed to publish and the cryptographer decided to run the forgery toolkit on them and then somehow inject the forged messages onto the arrested guy's device. Do you think that's going to stop the regime from pulling in all the apparent recipients of those messages?
    - 5y ago
phone8675309 5y ago
I wonder how much of the rest of the article will be drowned out by the conclusion: > It's not only personal freedom at stake. It's national security. The reckless deployment of Huawei 5G infrastructure across Europe has created easy opportunities for Chinese SIGINT. End-to-end encryption products are essential for European national security, to counter a hostile SIGINT environment controlled by China. We must push back hard in policy space to preserve the right to end-to-end encryption.
dale_glass 5y ago
It's very unfortunate PGP/GPG hasn't kept up with the times. Today it has two significant issues: 1. The needed trust model has changed significantly. 2. It's not reusable enough. 1. The original PGP mostly dealt with direct person-to-person relationships. Alice and Bob needed to safely communicate. Perhaps Bob could vouch for Carol. But that was the intended model: closely related groups, with maybe a person trusted to act as an introducer. Today our needs are different, and we need to securely communicate with people we never met, or to verify their signatures. Any Linux system contains thousands of packages, which were worked on by many thousands of developers, one may need to communicate with securely at some point. Eg, I want to verify the GPG signature on the Tor browser, but I never met anyone on the team, and how do I know who knows the team? My personal network actually extends very far. I did the FOSDEM key signing party several times, so my theoretical reach is enormous. But it can only be achived by hacking around GPG's trust model. I need to figure out by hand a path between me and Tor, download the keys, and manually tell GPG I trust each key's signature. This isn't convenient, user friendly, not as safe as it could be. 2. GPG is unfortunately stuck in the "Unix Philosophy" era, where you're supposed to just invoke the binary and parse its text output. I believe this crippled GPG's adoption, because it's slow. GPG has to do the whole startup, reading its key databases and so on every single time. Back when GPG support was introduced into KMail many years ago this added a very noticeable delay to viewing any signed message. And it's sadly still the case. The world badly needs a GPG library, that allows one to skip those startup costs, and to avoid the whole intended model of ~/.gnupg and just let a program do things like interpret in-memory data for any conceivable purpose. This is still badly lacking.
- globular-toast 5y ago
  I think you're wrong on point 1. PGP was always very much about communicating with people you don't know. Otherwise you'd just use symmetric encryption. Web of trust is still the best way we have to do that. Newer applications like signal etc are what require each pair of correspondents to exchange keys and "complete the graph". The difference with more "modern" technologies is just that they let you implicitly trust keys more easily. Web browsers just have you trust hundreds of CAs without even making you aware of them. Verifying keys on messaging apps is unknown and not understood by the vast majority of users.
aborsy 5y ago
Happy birthday day PGP!
stratosgear 5y ago
This brings back memories. I was an international student from Greece at the University of San Francisco, that fall, and I was present at a CS presentation that took place at the time (I'm not sure if it was Phill or not, but definitely one of the original authors). At the end of the presentation there was a pile of floppies that you could get a copy of the software. I got one along with my other classmates. Unfortunately, I was approached a couple of days later and asked to return the floppy back. My status as an international student did not allow me to have a copy ( arms, munitions export rules, whatever). I felt really upset about it, since I was the only one asked to give my floppy back. I might still have a copy of the floppy in a box in the attic somewhere.
- JshWright 5y ago
  > I'm not sure if it was Phill or not One "l" (it's the "z" at the end of "Zimmermann" that's doubled).
  - dane-pgp 5y ago
    > it's the "z" at the end of "Zimmermann" that's doubled Actually it's the "n" at the beginning of "Zimmermann" that is doubled.
    - JshWright 5y ago
      Oh man... I got to work w/ prz for several years (which is why the "two n's" thing stands out in my memory, since it's a common typo). And yet somehow, I still managed to screw that up...
    - GekkePrutser 5y ago
      Actually, the "m" in the middle of "Zimmermann" is also doubled! :)
  - brnt 5y ago
    My name ends in 'man', but Germans _always_ write it with two n's. I should never have taken a job for a German company...
mratsim 5y ago
Please let PGP retire as a pioneer now and not as a laggard tomorrow. - https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html - https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/ https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-crypt... - https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...
- gspr 5y ago
  Well, then there needs to be a widely adopted, standardized alternative.
- dane-pgp 5y ago
  If we're sharing obligatory links, then a detailed critique of "The PGP Problem" is: https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp It's true, though, that much work is needed to bring PGP up to the levels expected of modern crypto tools. Hopefully some of that will happen as a result of the work happening in the IETF: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-03.html https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-re... and due to technology built around it, such as: https://delta.chat/en/ https://delta.chat/en/ https://autocrypt.org/ https://autocrypt.org/
  - atoponce 5y ago
    > https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp Some rebuttals to that critique outline that the author doesn't fully understand the arguments Thomas Ptacek laid out, and may have a simplified understanding of PGP: https://lobste.rs/s/tyaze3 https://lobste.rs/s/tyaze3 and https://redd.it/negkdl https://redd.it/negkdl
gjvc 5y ago
I learned to program C from the PGP source code. Thank you Phil!

185 points by throw0101a 5y ago

It was on this day in 1991 that Pretty Good Privacy was uploaded to the Internet [... then...] a number of volunteer engineers came forward and we made many improvements. In September 1992 we released PGP 2.0 in ten foreign languages Fun fact: "We made many improvements" is doing an interesting lift in this paragraph, since PGP 1.0 shipped with a cipher of Zimmerman's own design, Bass-O-Matic, which lived up to its name in part by being demolished by Eli Biham over a lunch. PGP 2.0 introduced IDEA, and, I believe, the first (for the era) cryptographically credible version of PGP; a more fitting anniversary to celebrate, perhaps. (We've learned quite about about how to engineer cryptography in the ensuing 29 years, and PGP hasn't kept up --- can't, really; so on the 30th anniversary of Bass-Free PGP, we might fittingly celebrate by finally giving PGP a well-earned retirement.)

schoen 5y ago
More about this story: https://crypto.stackexchange.com/questions/61948/what-was-the-bassomatic-cipher-and-what-made-it-so-weak https://crypto.stackexchange.com/questions/61948/what-was-th... I just downloaded the source code for PGP 1.0 and found BASSLIB.C. 1988! It's interesting to note that the Bass-O-Matic design apparently came from a Navy contractor (Charlie Merritt). It seems possible that Merritt and the Navy both thought this design was secure; maybe they didn't have clearances to learn others' opinions about it, and only used it for unclassified communications.
greenyoda 5y ago
What do you recommend as a replacement for PGP? (I'm looking for stand-alone software I can use to encrypt files on storage media, not an encrypted e-mail service.)
- tptacek 5y ago
  The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs. For package signing: use something in the signify/minisign family. To encrypt a network transport, use WireGuard. To protect a web transaction on the wire, TLS 1.3. For transferring files: use Magic Wormhole. For backups: use something like Tarsnap or restic. For messaging: use something that does Signal Protocol. To protect files at rest, use encrypted DMGs (or your OS's equivalent, like encrypted loop mounts). To encrypt individual files --- a niche ask --- use Filippo's ungooglable "age".
  - greenyoda 5y ago
    Thanks! Link to "age", for those who are interested: https://github.com/FiloSottile/age https://github.com/FiloSottile/age
    - upofadown 5y ago
      Last I looked "age" did not have any sort of recovery utility. It isn't even clear that such a utility is possible (the protocol is poorly documented). A single bit error at the start of the file causes the loss of the entire file. So be careful using it for any sort of thing that might ever require the sort of recovery that bzip2 or lzip provides (gzip has a third party recovery utility). OpenPGP has excellent recovery properties out of the box BTW...
      - tptacek 5y ago
        I want to be sure I'm reading this correctly. Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Any error you accept is malleability conceded to an attacker. Are you complaining that age isn't malleable enough?
        upofadown 5y ago
        >Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Yes, this is an excellent example of where this behaviour is suboptimal. We should not cargo cult authenticated encryption. It has its place but this isn't it. > Any error you accept is malleability conceded to an attacker. Sure, but malleability that has a close to zero chance of being a problem. We are talking about static encryption here. You only get one chance at malleability and the user immediately knows something has gone wrong: gpg: WARNING: encrypted message has been manipulated! >Are you complaining that age isn't malleable enough? Merely pointing out that for the most common use case age is objectively worse than GPG.
- intc 5y ago
  I think PGP is fine for encrypting some files. But you should take into consideration that when you encrypt a file it's very likely that some (or all) of the plain text is left behind on the block device. Using full disk encryption (LUKS for example) will give additional protection (so one can't read plain text fragments from the device when it's not "open").
- makach 5y ago
  I don’t understand why people want to replace PGP. Of course we can improve the technology but the fact is that security is hard and requires interplay between the humans, processes and technology to work. It’s not enough to rely on just one of those pillars. There is an illusion in the world of IT that we can solve everything with technology. Maybe the reason why people don’t want or like PGP is because it needs strong human processes to work properly and keep its integrity, and that breaks the illusion that you can easily solve everything with tech. Happy birthday PGP!
  - tptacek 5y ago
    It's funny that you could make literally the same argument about C, especially since so much of the PGP ecosystem relies directly and entirely on software built in C.
  - tialaramex 5y ago
    > Maybe the reason why people don’t want or like PGP is because it needs strong human processes to work properly and keep its integrity, and that breaks the illusion that you can easily solve everything with tech. What you've got here is pretty much the mirror of the argument you've dismissed a paragraph earlier. Now you're desperate to rely on humans instead. This makes me think about Snowpiercer, for two reasons. One is that Snowpiercer has this ludicrous conceit about replacing unavailable engine components with humans but the other is that we've really been here with the actual railway trains in the nineteenth century. There was a pattern. One of these new-fangled railway trains crashes, often killing many people, the company directs public blame toward the driver, who will be portrayed as incompetent, drunk or worse and so fully responsible for the accident. Nothing changes, rinse, repeat. How was this cycle broken? We did not find some species of super-human train driver, instead we invented technology such as the Absolute Block system, Interlocking railway signals, the Dead Man's Handle. Even apparently trivial technologies like the Driver's Reminder Appliance (it's just a switch!) are still technology. PGP isn't very good technology. Like one of those early mechanical signals that might seem to indicate "clear" but it's actually just weighed down by snow and frozen in place so that it can't indicate "danger" instead, the way forward isn't "We need to rely on super-humans to compensate for the short-comings of the technology" but "We need a technology that sucks less so the humans don't need to be super-human to succeed".
- darkr 5y ago
  The other points in this thread recommending modern, context-specific cryptography tools are very valid, however if you're set on PGP; Sequoia[1] is a new(ish) OpenPGP library written from the ground up in Rust. 1: https://sequoia-pgp.org/ https://sequoia-pgp.org/
  - tptacek 5y ago
    Sequoia is fine work, and running less C code is a good thing, so if you have to use PGP (sorry) then use Sequoia. But note that the PGP ecosystem is hopelessly mired in GPG, and the problems go beyond C code --- Sequoia, for instance, is (AFAIK) the first popular implementation of AEAD crypto for GPG, but AEAD doesn't interoperate with GPG.
scruffyherder 5y ago
https://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/pgp/?cvsroot=pgp;only_with_tag=pgp10 https://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/pgp/... I still use PGP 1.0 as all of the scanners that check for stuff can't recognize any of it, and it slides through. It's more of payload thing

waynesonfire 5y ago

such a great tool. It's not a serious security product unless you support PGP.

schoen 5y ago
I'm a huge fan of Phil and his work, and plan to send him a note of thanks, but I think your second sentiment is out-of-date now. Even if we avoid other controversies like Thomas Ptacek's views about the inappropriateness of the e-mail encryption threat model, PGP doesn't support forward secrecy and so it's at least not suitable for instant messaging or TLS (as well as not being integrated into their protocols!). A serious security product could support encryption that's more relevant to whatever it is that that product does.
- techwizrd 5y ago
  Not all use cases require perfect forward secrecy, so I think PGP can still be useful for some applications (and I tend to enjoy using PGP). I agree however with your point that serious security products do not need to support PGP specifically.
- Avamander 5y ago
  Given that e-mail is not going anywhere in the next few decades, having a way to encrypt it to at least some extent is valuable.
- lmm 5y ago
  I've never seen a realistic threat model where Signal-style forward secrecy actually helps. Suppose a repressive regime captured one dissident can see a bunch of messages between them and other people, but theoretically some crypto nerd might have been able to forge those messages if the dissident has been carefully publishing the material they're supposed to publish and the cryptographer decided to run the forgery toolkit on them and then somehow inject the forged messages onto the arrested guy's device. Do you think that's going to stop the regime from pulling in all the apparent recipients of those messages?
  - 5y ago

phone8675309 5y ago

I wonder how much of the rest of the article will be drowned out by the conclusion: > It's not only personal freedom at stake. It's national security. The reckless deployment of Huawei 5G infrastructure across Europe has created easy opportunities for Chinese SIGINT. End-to-end encryption products are essential for European national security, to counter a hostile SIGINT environment controlled by China. We must push back hard in policy space to preserve the right to end-to-end encryption.

dale_glass 5y ago

It's very unfortunate PGP/GPG hasn't kept up with the times. Today it has two significant issues: 1. The needed trust model has changed significantly. 2. It's not reusable enough. 1. The original PGP mostly dealt with direct person-to-person relationships. Alice and Bob needed to safely communicate. Perhaps Bob could vouch for Carol. But that was the intended model: closely related groups, with maybe a person trusted to act as an introducer. Today our needs are different, and we need to securely communicate with people we never met, or to verify their signatures. Any Linux system contains thousands of packages, which were worked on by many thousands of developers, one may need to communicate with securely at some point. Eg, I want to verify the GPG signature on the Tor browser, but I never met anyone on the team, and how do I know who knows the team? My personal network actually extends very far. I did the FOSDEM key signing party several times, so my theoretical reach is enormous. But it can only be achived by hacking around GPG's trust model. I need to figure out by hand a path between me and Tor, download the keys, and manually tell GPG I trust each key's signature. This isn't convenient, user friendly, not as safe as it could be. 2. GPG is unfortunately stuck in the "Unix Philosophy" era, where you're supposed to just invoke the binary and parse its text output. I believe this crippled GPG's adoption, because it's slow. GPG has to do the whole startup, reading its key databases and so on every single time. Back when GPG support was introduced into KMail many years ago this added a very noticeable delay to viewing any signed message. And it's sadly still the case. The world badly needs a GPG library, that allows one to skip those startup costs, and to avoid the whole intended model of ~/.gnupg and just let a program do things like interpret in-memory data for any conceivable purpose. This is still badly lacking.

globular-toast 5y ago
I think you're wrong on point 1. PGP was always very much about communicating with people you don't know. Otherwise you'd just use symmetric encryption. Web of trust is still the best way we have to do that. Newer applications like signal etc are what require each pair of correspondents to exchange keys and "complete the graph". The difference with more "modern" technologies is just that they let you implicitly trust keys more easily. Web browsers just have you trust hundreds of CAs without even making you aware of them. Verifying keys on messaging apps is unknown and not understood by the vast majority of users.

aborsy 5y ago

Happy birthday day PGP!

stratosgear 5y ago

This brings back memories. I was an international student from Greece at the University of San Francisco, that fall, and I was present at a CS presentation that took place at the time (I'm not sure if it was Phill or not, but definitely one of the original authors). At the end of the presentation there was a pile of floppies that you could get a copy of the software. I got one along with my other classmates. Unfortunately, I was approached a couple of days later and asked to return the floppy back. My status as an international student did not allow me to have a copy ( arms, munitions export rules, whatever). I felt really upset about it, since I was the only one asked to give my floppy back. I might still have a copy of the floppy in a box in the attic somewhere.

JshWright 5y ago
> I'm not sure if it was Phill or not One "l" (it's the "z" at the end of "Zimmermann" that's doubled).
- dane-pgp 5y ago
  > it's the "z" at the end of "Zimmermann" that's doubled Actually it's the "n" at the beginning of "Zimmermann" that is doubled.
  - JshWright 5y ago
    Oh man... I got to work w/ prz for several years (which is why the "two n's" thing stands out in my memory, since it's a common typo). And yet somehow, I still managed to screw that up...
  - GekkePrutser 5y ago
    Actually, the "m" in the middle of "Zimmermann" is also doubled! :)
- brnt 5y ago
  My name ends in 'man', but Germans _always_ write it with two n's. I should never have taken a job for a German company...

mratsim 5y ago

Please let PGP retire as a pioneer now and not as a laggard tomorrow. - https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html - https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/ https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-crypt... - https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...

gspr 5y ago
Well, then there needs to be a widely adopted, standardized alternative.
dane-pgp 5y ago
If we're sharing obligatory links, then a detailed critique of "The PGP Problem" is: https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp It's true, though, that much work is needed to bring PGP up to the levels expected of modern crypto tools. Hopefully some of that will happen as a result of the work happening in the IETF: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-03.html https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-re... and due to technology built around it, such as: https://delta.chat/en/ https://delta.chat/en/ https://autocrypt.org/ https://autocrypt.org/
- atoponce 5y ago
  > https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp Some rebuttals to that critique outline that the author doesn't fully understand the arguments Thomas Ptacek laid out, and may have a simplified understanding of PGP: https://lobste.rs/s/tyaze3 https://lobste.rs/s/tyaze3 and https://redd.it/negkdl https://redd.it/negkdl

gjvc 5y ago

I learned to program C from the PGP source code. Thank you Phil!