Differences

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

--- pgpfan:tpp [2022/05/13 16:21] – More relevant to the issue. b.walzer
+++ pgpfan:tpp [2022/05/29 00:35] – I implicitly agreed with a incorrect statement. I need to fix that. b.walzer
@@ Line 103: / 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.
-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 end with some sort of end of file/message error. You obviously wouldn't end up with a valid MDC check.
 >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; ...
-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((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 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.