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 [2022/01/07 16:13] – Better FS article, something for the key comparison. b.walzerpgpfan:tpp [2024/05/02 13:39] (current) – We have a reference now b.walzer
Line 17: Line 17:
 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. 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.+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. 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.
Line 37: Line 37:
 >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 +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
-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. 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).
  
-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 of 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 a complete list of possible tags.+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 a complete list of possible tags.
  
 >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.
Line 104: Line 103:
 >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 true. It just means that a missing MDC is considered invalid. Many authenticated encryption schemes are removable and depend on the same convention.+Well, sure, you could do that. An implementation would probably just stop with some sort of end of file/message/packet error. You obviously wouldn't end up with a 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 implication of the fact 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; ...
  
-Which would mean that the MDC was not mandatory where required. Yet another implication of the fact that MDCs can be stripped. +We have a problem here. The 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 MDC. Some digging reveals that this is actually quite difficult and has a very low chance of success(1 out of 65536)((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]])). This still leaves the message damaged enough that most implementations will simply blow up with an error. These ideas about the MDC seem to have come from a particularly hard to follow section of the EFAIL paper(([[pgpfan:legends|Misleading Legends Caused by EFAIL]])).
- +
-The author again mentions that the MDC can be stripped in another portion of the rant. This is being highlighted here in support of the suggestion that the actual arguments have been expanded as much as possible. This might suggest that there were not that many arguments available for this rant.+
  
 >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 right. In 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 attack. The 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.
Line 168: Line 164:
 | Messages Saved on Phone   | Revealed  | 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 encryption key 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.+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. Please see the [[pgpfan:forward_secrecy|forward secrecy]] article for a somewhat more extensive discussion.
pgpfan/tpp.1641571992.txt.gz · Last modified: 2022/01/07 16:13 by b.walzer