The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools


pgpfan:tpp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
pgpfan:tpp [2020/11/29 22:41] – Yet another Signal ref b.walzerpgpfan:tpp [2023/12/19 13:21] (current) – How unlikely? b.walzer
Line 1: Line 1:
- ======The PGP Problem: A Critique======+======The PGP Problem: A Critique====== 
 + 
 +You can read the [[https://articles.59.ca/doku.php?id=pgpfan:tpp&rev=1632837969|revision of this article before the general rewrite]] but you should read this one instead. It is better.
  
 The anti-PGP rant in question can be found here: The anti-PGP rant in question can be found here:
Line 5: Line 7:
   * [[https://latacora.micro.blog/2019/07/16/the-pgp-problem.html|The PGP Problem]]   * [[https://latacora.micro.blog/2019/07/16/the-pgp-problem.html|The PGP Problem]]
  
-I only use Signal Messenger as a counter example in the following because the author of the rant uses it as an example of something that they think could be used as a replacement for encrypted email. I currently consider Signal Messenger one of the best in its class (2020).+This is a pretty good rant. I feel like I am attacking a work of art with an axe here, but the rant promotes misconceptions that need to be addressed. 
 + 
 +I only use Signal Messenger as a counter example in the following because the author of the rant uses it as an example of something that they think could be used as a replacement for encrypted email. I currently consider Signal Messenger one of the best in its class (2021). 
 + 
 +>//The PGP Problem// 
 + 
 +>Fortunately, if you’re not morbidly curious, there’s a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography. 
 + 
 +The entire rant is basically about how OpenPGP is old and therefore bad and how new things, sometimes only vaguely defined, are good. So let's address this first. 
 + 
 +If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument. You would be unlikely to demand a newer design. Normally old designs that have stood the test of time are valued. Cryptography is based on mathematical/logical principles. Such principles don't age out on any sort of a schedule and are valued in some cases for thousands of years. 
 + 
 +So the rant is contending something that goes against conventional expectations. Normally that would require some evidence and/or a good argument. The rant provides neither. 
 + 
 +>“PGP” can mean a bunch of things, from the OpenPGP standard to its reference implementation in GnuPG. We use the term “PGP” to cover all of these things. 
 + 
 +Leaving out the context can make a rant flow better but quietly switching back and forth between fundamentally different issues of specification and implementation does not at all improve the chances of proper understanding. 
 + 
 +>//Absurd Complexity//
  
 >For reasons none of us here in the future understand, PGP has a packet-based structure. >For reasons none of us here in the future understand, PGP has a packet-based structure.
  
-That is because a long term standard must be extensible. Thus the fields can not be fixed and it must be possible to add new types.+long term standard must be extensible. Thus the fields can not be fixed and it must be possible to add new types. Here is the structure of an OpenPGP packet: 
 + 
 +    |tag|length|data| 
 + 
 +Explicitly defining the length at the start of the packet makes the result resistant to things like length extension/truncation attacks. The simplicity of this data structure makes the result resistant to attacks on message syntax.
  
 >There are at least 8 different ways of encoding the length of a packet, depending on whether you’re using “new” or “old” format packets. >There are at least 8 different ways of encoding the length of a packet, depending on whether you’re using “new” or “old” format packets.
  
-This is true in a narrow technical sense but is misleading.  Both old and new formats are variable length. The old format has a 2 bit field to indicate the number of bytes used for length. The new format uses a simple length extension based on the bit patterns of the first byte. This is a common technique. UTF-8 does the same sort of thing but no one is claiming that there are 6 (4) different UTF-8 representations.+This is true in a narrow technical sense but is misleading.  Both old and new formats are variable length. The old format has a 2 bit field to indicate the number of bytes used for length. The new format uses a simple length extension based on the bit patterns of the first byte. This is a common technique. UTF-8 
 +does the same sort of thing but no one is claiming that there are 6 (4) different UTF-8 representations.
  
 >The “new format” packets have variable-length lengths, like BER (try to write a PGP implementation and you may wish for the sweet release of ASN.1). >The “new format” packets have variable-length lengths, like BER (try to write a PGP implementation and you may wish for the sweet release of ASN.1).
  
-The [[https://tools.ietf.org/html/rfc4880#section-4.2.2|OpenPGP standard]] provides explicit cases for each extent of the length header (there are only 4). All you have to do is directly transcribe these cases into case statement and you are done. There is no real thinking required. The standard even goes further and provides examples. +For part of my working life I had to implement low level protocols from specifications of various kinds. If I had of encountered the OpenPGP packet structure I would have considered implementing to be a relatively good time. The reader is invited to experience the overwhelming complexity of the OpenPGP packet structure. It is defined in [[https://datatracker.ietf.org/doc/html/rfc4880#section-4|section 4 of RFC-4880]]. The definition is all of 4 pages long. It includes code examples for each case of the length extension and complete list of possible tags.
- +
-Since this is from the public key section of the PGP published standard it might be interesting to compare with the same sort of thing from the Signal Protocol ... and we immediately discover that there is no such thing. No published standard and no user access to Signal identity information outside the program.+
  
 >The most recent keyserver attack happened because GnuPG accidentally went quadratic in parsing keys, which also follow this deranged format. >The most recent keyserver attack happened because GnuPG accidentally went quadratic in parsing keys, which also follow this deranged format.
  
-It was actually about adding keys and it was not accidental. GnuPG undoubtedly did things the way they did for simplicity. That's a common theme in the PGP ecosystem.+This had nothing to do with the parsing of the packet format and it was not accidental. GnuPG undoubtedly did things the way they did for simplicity. That's a common theme in the security focused OpenPGP ecosystem. To make the attack practical the attacker had to add tens of thousands of signatures to the target key. Some had over a hundred thousand signatures added.
  
 >The actual system doesn’t get simpler. >The actual system doesn’t get simpler.
  
 Compared to what working public key based public key system? OpenPGP as a protocol is relatively [[pgpfan:minimalist|simple]]. Compared to what working public key based public key system? OpenPGP as a protocol is relatively [[pgpfan:minimalist|simple]].
 +
 +>//Mired In Backwards Compatibility//
  
 >If you’re lucky, your local GnuPG defaults to 2048-bit RSA, ... >If you’re lucky, your local GnuPG defaults to 2048-bit RSA, ...
  
-Which is [[pgpfan:2048|wild overkill]], but I don't think that the writer meant to imply that. RSA with 2048 bit keys is a perfectly reasonable and conservative default.+Which is [[pgpfan:2048|wild overkill]], but I don't think that the writer meant to imply that. RSA with 2048 bit keys is a perfectly reasonable and conservative default, particularly for an offline capable, stateless protocol like OpenPGP.
  
 >... the 64-bit-block CAST5 cipher in CFB, ... >... the 64-bit-block CAST5 cipher in CFB, ...
  
-Here are the symmetrical ciphers GnuPG version 2.2.12 accepts ordered from highest preference to lowest preference:+Here are the symmetrical ciphers GnuPG version 2.2.12 specifies by default, ordered from highest preference to lowest preference:
  
 <file> <file>
Line 41: Line 66:
 </file> </file>
  
-CAST5 isn't even in the list, much less a default of some sort.+CAST5 isn't even in the list, much less a default of some sort. CAST5 remains unbroken and would be quite suitable for use in a length limited, offline, stateless medium like email. CAST5 actually serves as an example of how old encryption methods can still be completely usable. CFB ([[pgpfan:cipherfeedback|Cipher Feed Back]]) is actually sort of awesome.
  
->PGP begs users to keep a practically-forever root key tied to their identity.+>...that mixing compression and encryption is dangerous...
  
-Most people prefer to keep their identity indefinitely. That is whysay, the Signal protocol also has a "practically-forever root key tied to their identity"It is inherent to the problem.+This comes from an attack on an onlinestateful encryption protocol that involved information leakage due to compressionThis sort of attack is not applicable to the sort of offline, stateless systems that OpenPGP is used for. See: [[pgpfan:oracle|Oracle Attack Immunity]].
  
->The PGP cheering section will immediately reply “that’s why you keep keys on a Yubikey”.+Mixing apples and oranges in this way is common. The rant fails to make this distinction in more than one place.
  
-That particular cheering section might eventually get around to that, but they first would mention the use of subkeys. By default GnuPG generates a key for signing (identity) and a separate subkey for encryption. So in practice you are no worse off than with, say, Signal just as long as you are willing and able to mark an encryption key as compromised before generating a new one.+>//Obnoxious UX//
  
-Subkeys are a fairly fundamental PGP concept...+Here we are clearly talking about implementations...
  
->...they needed to authenticate ciphertext, and that PGP’s signatures weren’t accomplishing that.+>>There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGPTwo hours later, they were never seen or heard from again.
  
-PGP's signatures are cryptographically strong and are indeed intended to both prove that a particular entity sent message and that message was delivered as sent. They work very well in practice and are normally used.+There have been several encrypted messaging usability studies conducted over the years. They tend to use OpenPGP implementations rather than the encrypted messenger of the week for obvious reasons. They are //usability// studies. They are deliberately designed to be as difficult as possible (you hide all the documentation) in order to get results. If you wanted to compare the usability of a particular PGP supporting client to other clients you would have to make different study.
  
->PGP does mediocre job of signing things, a relatively poor job of encrypting them with passwords, and a pretty bad job of encrypting them with public keysPGP is not an especially good way to securely transfer fileIt’s a clunky way to sign packages. It’s not great at protecting backups. It’s downright dangerous way to converse in secure messages.+In usability study involving Signal(([[https://www.ndss-symposium.org/wp-content/uploads/2018/03/09-when-signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure-mobile-messaging.pdf|When SIGNAL hits the Fan: 
 +On the Usability and Security of State-of-the-Art 
 +Secure Mobile Messaging]]))21 out of 28 computer science students failed to establish and maintain secure end to end encrypted connectionThe usability of end to end encrypted messaging //is// serious issueWe should not kid ourselves into thinking it is solved issue.
  
-I don't know what to make of this. These are all things that PGP does well in a simple straightforward way. Perhaps this is meant as an expression of the authors feelings...+>//Long-Term Secrets//
  
->Secure messaging wants crypto that is different from secure backups or package signing.+>PGP begs users to keep a practically-forever root key tied to their identity.
  
-I can't really say anything here because there is nothing to support the contentionFrom here on will skip over such bland statements with no context.+Most people prefer to keep their identity indefinitely. That is why, say, the Signal protocol also has a "practically-forever root key tied to their 
 +identity". It is inherent to the problem. I think the author might of been making an obtuse reference to forward secrecy and got a bit lost along the way.
  
->Weve learned lot since Steve Urkel graced the airwaves during ABC’s TGIF...+>The PGP cheering section will immediately reply “thats why you keep keys on Yubikey”.
  
-Then the author goes on for while about how all the PGP things are bad because they are old. This seems to be a key theme hereOld is badNew is better.+... which would be a reasonable point. An air gapped system such as a Yubikey does significantly reduce the chance of key compromise, both the "practically-forever root key tied to their identity" and the encryption key actually related to the forward secrecy issueA user would prefer not to have //any// keys compromisedAn offline encryption scheme enables the practical use of a portable air gapped system. Such a thing would not be practical with an online instant messaging scheme such as Signal MessengerSee: [[em:emailvsim]]
  
->We’ve understood authenticated encryption for 2 decades, and PGP is old enough to buy me drinks; enough excuses. +>//Broken Authentication//
- +
-But apparently the author does not understand why [[pgpfan:authenticated|authenticated encryption]] is not used or even required for the things that PGP is normally used for. Attacking the proceeding contention would normally be required before bringing up the authenticated encryption issue. This suggests that the author has no real idea of how PGP works, but still thought it was a good idea to create a rant about it. +
- +
->>There was a PGP usability study conducted a few years ago where a group of technical people were placed in a room with a computer and asked to set up PGP. Two hours later, they were never seen or heard from again.+
  
-There have been several encrypted messaging usability studies conducted over the yearsThey tend to use PGP rather than the encrypted messenger of the week for obvious reasons. They are //usability// studies. They are deliberately designed to be as difficult as possible (you hide all the documentationin order to get resultsIf you wanted to compare the usability of a particular PGP supporting client to other clients you would have to make a different study.+This section is based on a misconceptionA stateless, offline capable system such as OpenPGP does not require the sort of authenticated encryption meant here and the [[pgpfan:mdc|Modification Detection Code]] (MDCis not some sort of poor substitute for such an authenticated encryption schemeFor the details see the [[pgpfan:authenticated|Authenticated Encryption]] article.
  
 >The PGP MDC can be stripped off messages –– it was encoded in such a way that you can simply chop off the last 22 bytes of the ciphertext to do that. >The PGP MDC can be stripped off messages –– it was encoded in such a way that you can simply chop off the last 22 bytes of the ciphertext to do that.
  
-This is trueIt just means that missing [[pgpfan:mdc|MDC]] is considered invalid.+Well, sure, you could do thatAn implementation would probably just stop with some sort of end of file/message/packet error. You obviously wouldn't end up with valid MDC check so this is an odd thing to suggest.
  
 >To retain backwards compatibility with insecure older messages, PGP introduced a new packet type to signal that the MDC needs to be validated; if you use the wrong type, the MDC doesn’t get checked. >To retain backwards compatibility with insecure older messages, PGP introduced a new packet type to signal that the MDC needs to be validated; if you use the wrong type, the MDC doesn’t get checked.
  
-That's just a different way to say that MDCs can be stripped.+An application that required the MDC would obviously not accept an entirely absent MDC.
  
 >Even if you do, the new SEIP packet format is close enough to the insecure SE format that you can potentially trick readers into downgrading; ... >Even if you do, the new SEIP packet format is close enough to the insecure SE format that you can potentially trick readers into downgrading; ...
  
-... and that is the third time the fact that MDCs can be stripped is mentioned, in the same paragraphThis rant tends to repeat the same point over and over again, but this is a bit exceptionalQuite excessive when talking about a feature that is not normally used in PGP. +We have a problem hereThe juxtaposition of the non sequitur about chopping off the last 22 bytes makes it seem that that is all that is required to downgrade the MDCSome digging reveals that this is actually quite difficult and has very low chance of success(1 out of 32768)((Discussion:[[https://github.com/google/end-to-end/issues/161|No warning on decrypting Tag 9 (no integrity protection) packets]], Exploit code:[[https://gist.github.com/coruus/85dea6eb82897044f65d]])). We can be charitable here and assume that the author simply did not do any research but this is very misleading.
- +
-The author mentions that the MDC can be stripped in another portion of the rant for a total of four times.+
  
 >Trevor Perrin worked the SEIP out to 16 whole bits of security. >Trevor Perrin worked the SEIP out to 16 whole bits of security.
  
-If you read the linked mailing list thread you will discover that this statement is quite misleading. Trevor Perrin was discussing an attack on MDC which at one point required guessing with only a one in 2^16 (65536) chance of getting the guess rightIn the end he concluded [[https://mailarchive.ietf.org/arch/msg/openpgp/IGk9eq5QkSsXGLIa7Z9P1Qhd_Qg/|"There's a lot of caveats to this attack, so it's probably not +This was wrong, but it was not Trevor Perrin's error. It turned out that the specification was wrong. Trevor Perrin was insightful enough to notice that the system described in the specification was vulnerable to this particular attackThe specification was corrected to what the implementations were actually doing and the vulnerability went away. This discussion was from the IETF OpenPGP standard mailing list(([[https://mailarchive.ietf.org/arch/msg/openpgp/UYEBC7hnZNbMoNWrfz9zJQb_FUk/|The ITEF OpenPGP discussion thread about the security properties of the MDC.]])). If any actual MDC weaknesses had come from the discussion then they would have been resolved at that time. There is no reason to think that there is anything wrong with the MDC. This discussion was part of the process intended to ensure that the MDC is secure.
-anything to seriously worry about:"]].+
  
 >And, finally, even if everything goes right, the reference PGP implementation will (wait for it) release unauthenticated plaintext to callers, even if the MDC doesn’t match. >And, finally, even if everything goes right, the reference PGP implementation will (wait for it) release unauthenticated plaintext to callers, even if the MDC doesn’t match.
  
-There is no such "reference PGP implementation". OpenPGP takes the form of an [[https://tools.ietf.org/html/rfc4880|IETF published standard]].+There is no such "reference PGP implementation". OpenPGP takes the form of an [[https://tools.ietf.org/html/rfc4880|IETF published standard]]. The Signal Protocol has no such associated standard. It appears you are supposed to read the high level overview and then transliterate the Java implementation. 
 + 
 +>//Incoherent Identity// 
 + 
 +>Other people organize “key signing parties”. 
 + 
 +Alas, this is something that doesn't really happen anymore. A key signing party is a good way to give people an intuitive grasp of cryptographic identities; something that would be valuable to the user of, say, Signal Messenger.
  
 >Ordinary people will trust anything that looks like a PGP key no matter where it came from ... >Ordinary people will trust anything that looks like a PGP key no matter where it came from ...
  
-In the same way that "ordinary people" will never bother to check their key fingerprints when using other systems. They will also ignore warnings that those fingerprints have changed. The problem is logically the same and PGP is no worse off here. PGP in a sense is better here in that it forces the user to comprehend the existence of a key in a way where it is intuitively obvious that it is important to know where that key came from.+In the same way that "ordinary people" will never bother to check their key fingerprints when using other systems. They will also ignore warnings that those fingerprints have changed. The problem is logically the same and OpenPGP is no worse off here (see the proceeding comment about the Signal Messenger usability study). PGP in a sense is better here in that it forces the user to comprehend the existence of a key in a way where it is intuitively obvious that it is important to know where that key came from
 + 
 +>//Leaks Metadata// 
 + 
 +>Messages are (in normal usage) linked directly to key identifiers, ... 
 + 
 +It is important to note that this linkage is only to the recipient of the message. Normally in a messaging system the recipient has to be provided to allow the message to be routed to the destination. If someone were to come up with a system that made the recipient anonymous it would be little extra work to omit this linkage. Such usage is explicitly supported under the OpenPGP standard.
  
 >Further, a rather large fraction of PGP users make use of keyservers, ... >Further, a rather large fraction of PGP users make use of keyservers, ...
  
-They do? A PGP keyserver links an email address (and a key fingerprint) to a PGP identity. That identity might not be linked to a physical identity at all. If you did not want this linkage then you would have no reason to use a keyserver.+They do? A PGP keyserver links an email address to a PGP identity. That identity might not be linked to a physical identity at all. 
 +If you did not want this linkage then you would have no reason to use a keyserver
 + 
 +>//No Forward Secrecy// 
 + 
 +Reduced to the essence; forward secrecy is where you delete the encryption key protecting some encrypted data to prevent that key from falling into the possession of an attacker that already has that encrypted data. There is nothing preventing any system from doing that, even something based on the OpenPGP standard. For a practical demonstration see: [[pgpfan:gpgburn|A Demonstration of Message Burning Through Encryption using GnuPG]].
  
 >Forward secrecy means that if you lose your key to an attacker today, they still can’t go back and read yesterday’s messages; ... >Forward secrecy means that if you lose your key to an attacker today, they still can’t go back and read yesterday’s messages; ...
  
-Unless those messages are archived, which is normally the case with email and tends to be the default on other systems (e.g. Signal Messenger). If they get your private key then they pretty much for sure get your archived messages. Very few people are willing to go without a message archive so [[pgpfan:forward_secrecy|forward secrecy]] is unlikely to help in most cases.+Unless those messages are archived, which is normally the case with email and tends to be the default on other systems (e.g. Signal Messenger). If they get your private key then they pretty much for sure get your archived messages. Very few people are willing to go without a message archive so forward secrecy is unlikely to help in most practical cases of messaging.
  
 >In modern cryptography engineering, we assume our adversary is recording everything, into infinite storage. PGP’s claimed adversaries include world governments, many of whom are certainly doing exactly that. >In modern cryptography engineering, we assume our adversary is recording everything, into infinite storage. PGP’s claimed adversaries include world governments, many of whom are certainly doing exactly that.
  
-Almost all email in transit (>90%) is protected by [[pgpfan:starttls|SMTP STARTTLS]] these days. So in practice those world governments don't have access to your PGP messages recorded off the wire any more.+Almost all email in transit (>90%) is protected by [[pgpfan:starttls|SMTP STARTTLS]] these days. So in practice those world governments don't have access to your PGP messages recorded off the wire anymore.
  
->If weve learned 3 important things about cryptography design in the last 20 yearsat least 2 of them are that negotiation and compatibility are evil.+>Its theoretically possible to achieve a facsimile of forward secrecy using the tools PGP provides. Of coursepretty much nobody does this.
  
-Then it is fortunate that [[pgpfan:downgrade|PGP does not do negotiation]]. It can't. PGP supports asynchronous store and forward applications. It works over one way channel. Your cipher, digest, and compression preferences come along with your public key They are signed and so are protected by the base cryptographic system. An adversary would have to break the cryptography to modify your preferences.+The interesting question here is: why notIt's easy to do in technical sense and would not cause your correspondents to have to reverify your identity.
  
-I do not agree that compatibility is a bad thing. PGP is actually a good example of how to deal with backwards compatibility in a good way.+In 2020 a company called Cellebrite announced that they had a specific Signal Messenger data interpretation facility that would be useful in the event that their forensic box broke into the smartphone that Signal was running on(([[https://web.archive.org/web/20201210150311/https://www.cellebrite.com/en/blog/cellebrites-new-solution-for-decrypting-the-signal-app/|Cellebrite’s New Solution for Decrypting the Signal App]])). This sort of attack can not reveal any messages archived off the network due to Signal's forward secrecy. Let's compare the end result to an encrypted email client running on the same phone using traditional passphrase protection: 
 + 
 +|                           ^ Signal    ^ Encrypted Email  ^ 
 +| Archived Network Messages | Protected | Protected        | 
 +| Messages Saved on Phone   | Revealed  | Protected        | 
 + 
 +So the encrypted email actually ends up providing a better result for the user. That is because it is possible to lock up the secret key material more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging. It seems possible that people don't bother with forward secrecy for email because they perceive it to be secure enough already. Forward secrecy might not be worth the extra effort for that particular medium. 
 + 
 +Please see the [[pgpfan:forward_secrecy|forward secrecy]] article for a somewhat more extensive discussion. 
 + 
 +>//Clumsy Keys// 
 + 
 +This section compares apples to oranges to kumquats. Categorizing the different things here would be so tedious that I will just give up and admit defeat. Let's move on. 
 + 
 +>//Negotiation// 
 + 
 +I am reasonably certain that this section is based on a misapprehension. An offline stateless protocol like OpenPGP is not susceptible to downgrade attacks in the ways that online stateful protocols are. Negotiation is simply not possible for a medium that involves generating an encrypted/signed message/file and just sending it somewhere. See: [[pgpfan:downgrade|Downgrade Attack Immunity]] 
 + 
 +I do not agree that compatibility is a bad thing. OpenPGP is actually a good example of how to deal with backwards compatibility in a good way
 + 
 +>//Janky Code// 
 + 
 +I have not been involved with the GnuPG source code enough to venture some sort of opinion on its quality. Presumably the author of the rant has. The GnuPG project treats side channel attacks as faults and fixes them as a matter of policy. As a result researchers will take the time to find them and submit them.
  
 >The 2018 Efail vulnerability was a result of it releasing unauthenticated plaintext to callers. >The 2018 Efail vulnerability was a result of it releasing unauthenticated plaintext to callers.
  
-Sort of weird example. [[pgpfan:efail|EFAIL]] turned out to be kind of a media hoax against PGP and it had nothing to do with "releasing unauthenticated plaintext to callers".+This is proposal for a fix for [[pgpfan:efail|EFAIL]]. The idea is that the cryptographic code would blow up with an error if it suspected modification. Not only is this not the only possible approach, it is not a particularly good one. It would force all the email client maintainers to have to deal with whole new class of error. It would prevent reasonable approaches such as displaying the email with warning/explanation in an environment safer than, say, a leaky HTML interpreter with external network connections available. In general, the result of adopting the proposal would be fairly bad in terms of user experience. 
 + 
 +Since the EFAIL topic is now on the table, I can't help but bring up some related points. The much beleaguered OpenPGP modification detection code (MDC) reliably detected the EFAIL attack. The researchers were not able to overcome it. The also disparaged OpenPGP cipher feed back (CFB) caused those same researchers considerable trouble. 
 + 
 +>GnuPG is also effectively the reference implementation for PGPand also the basis for most other tools that integrate PGP cryptography. It isn’t going anywhere. To rely on PGP is to rely on GPG. 
 + 
 +The popular Thunderbird email client switched from GnuPG to RNP. Is RNP "effectively the reference implementation for PGP" now? I count 20 different OpenPGP implementations on the OpenPGP.org developer page(([[https://www.openpgp.org/software/developer/|OpenPGP Developer Libraries/Tools]])). Heck there are at least two active Rust implementations available right now(([[https://sequoia-pgp.org/|Sequoia-PGP]], [[https://github.com/rpgp|rpgp]])) 
 + 
 +>//Encrypting Email//
  
->Encrypting Email 
-> 
 >Don’t. >Don’t.
  
 Comment not required here. Comment not required here.
  
-[[pgpfan:index|PGP FAN index]]+[[pgpfan:index|PGP FAN index]]\\ 
 +[[em:index|Encrypted Messaging index]]
  
pgpfan/tpp.1606689708.txt.gz · Last modified: 2020/11/29 22:41 by b.walzer