The Call of the Open Sidewalk

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

User Tools

Site Tools

pgpfan:legends

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:legends [2024/03/13 18:35] – Yet another try at a clear argument. b.walzerpgpfan:legends [2024/06/02 14:33] (current) – Signature stuff relevant to sec 5.2. b.walzer
Line 73: Line 73:
  
 So if you want to, say, prevent EFAIL, then if you want to support messages without modification detection you will have to take an approach that does not depend on such detection. For example, you could take into account the modification detection provided by a signature. It makes no difference to the implementation if the format was originally modification detecting and someone changed it along the way. The implications are the same. So in a very real sense, the fact that it might be possible to transmogrify a message with modification detection to one without is irrelevant to the discussion of security in the OpenPGP case. So if you want to, say, prevent EFAIL, then if you want to support messages without modification detection you will have to take an approach that does not depend on such detection. For example, you could take into account the modification detection provided by a signature. It makes no difference to the implementation if the format was originally modification detecting and someone changed it along the way. The implications are the same. So in a very real sense, the fact that it might be possible to transmogrify a message with modification detection to one without is irrelevant to the discussion of security in the OpenPGP case.
 +
 +Amazon might send you a toaster instead of a replacement lock. That doesn't mean that your front door has a potential vulnerability. Amazon would have to send you something that actually provided a lock function before we could claim that there might be a vulnerability.
  
 =====A Legend From the EFAIL Publicity Page===== =====A Legend From the EFAIL Publicity Page=====
Line 91: Line 93:
  
 Someone who did not dig through the actual EFAIL paper for the reference would end up with the impression that OpenPGP signatures were not effective against EFAIL class attacks and were generally weak. That is simply wrong. Someone who did not dig through the actual EFAIL paper for the reference would end up with the impression that OpenPGP signatures were not effective against EFAIL class attacks and were generally weak. That is simply wrong.
 +
 +This possible misapprehension is very relevant here. If you accept that OpenPGP signatures are ineffective against EFAIL then you would think that the modification detection provided by the block cipher mode was the last chance to resolve EFAIL. As a result the discussion in section 5.2 would seen to be very important and relevant. Otherwise, if you knew that signatures were effective against EFAIL, things would be more nuanced. You would realize that all EFAIL attack messages would show up as unsigned (anonymous) and encrypted. Unsigned but encrypted messages are troublesome in more ways than just EFAIL. So you might consider solving the larger, more general, issue instead, possibly basing your solution completely on the protection provided by signatures. At that point the discussion in section 5.2 would become irrelevant.
 +
 +In fairness, it should be mentioned that the question of S/MIME signatures vs EFAIL is also somewhat nuanced. S/MIME provides two types of signatures. One "inside the envelope" and one "on the outside of the envelope". The proposed weakness is based on the outside signature. Presumably an implementation using signatures against EFAIL would only use the inside signatures. So there might be an argument here, should someone go to the trouble to develop it.
 +
  
 ---- ----
pgpfan/legends.1710354902.txt.gz · Last modified: 2024/03/13 18:35 by b.walzer