The Call of the Open Sidewalk

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

User Tools

Site Tools


pgpfan:authenticated

Differences

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

Link to this comparison view

Next revision
Previous revision
pgpfan:authenticated [2020/09/01 17:59] – created b.walzerpgpfan:authenticated [2023/02/28 16:46] (current) – new point b.walzer
Line 1: Line 1:
 ======Authenticated Encryption====== ======Authenticated Encryption======
  
-PGP is sometimes criticized because it does not support a feature called [[wp>authenticated encryption]](AE). PGP is very flexible and is used in many contexts so I can not say that AE would not be valuable in all those cases. This is about why it is not that valuable in the typical messaging case.+It is sometimes said OpenPGP does not support a feature called [[wp>authenticated encryption]] (AE).
  
-PGP uses a type of encryption with a property that a professional cryptographer might refer to as [[wp>Malleability_(cryptography)|malleability]]. This causes two potential issues.+AE is often seen in the case of stateful connected protocols such as [[wp>Transport_Layer_Security|TLS]]. Typically a shared secret key is first negotiated: 
  
-The first and normally the most significant issue associated with malleability is that it might be possible to learn the contents of an encrypted message. This involves a process of repeated tests where the encrypted data is submitted in different ways and the results are used to refine the guesses. This sort of attack is called an oracle attack. [[pgpfan:oracle|PGP messaging is not generally susceptible to oracle attacks]] so the most serious risk is negated.+{{auth_stateful_keys.svg}}
  
-The second issue is that message might be changed in some way that might mislead the recipientAE would allow the recipient to detect such changes.+The authentication is usually established by applying cryptographic signature to the components involved in the negotiation. At the end of this process each end of the connection has a copy of a shared secret key that the entities involved can be sure has not somehow been shared with a third partyThis shared secret key inherits the authentication from the cryptographic signatures.
  
-PGP currently uses [[pgpfan:signatures]] to detect message changes. If you receive a message and the signature checks OK then you know two things:+The entities can then send messages encrypted with the shared key over the connection indefinitely:
  
-  * The message was created by the entity that signed it. +{{auth_stateful_ae.svg}}
-  * The message was not modified after it was created.+
  
-Signatures are conceptually simple and straightforward.+The authenticated encryption ensures that these messages are from the other entity and were not modified in transit. By using the authenticated shared secret key, the authenticated encryption can preserve the authenticity established by the cryptographic signatures.
  
-Here are the possibilities when we add AE on top of signatures:+Now we switch to the case of a protocol suitable for offline applications such as encrypted email or stored files. Here is how this is normally done using OpenPGP:
  
-|                       ^ Valid AE           ^ Invalid AE           ^ +{{auth_stateless.svg}}
-^ Valid Signature       | AE redundant       | impossible           | +
-^ Invalid Signature     | message as sent    | message modified     | +
-^ Missing Signature     | message as sent    | message modified     |+
  
-So AE only adds value in the case of an invalid or missing signatureIn other words; the case of anonymous messages.+Offline applications are by nature stateless with no reverse channel available. A message is created and sent off over a network. A file is created and stored to some sort of media. So there is no concept or possibility of an ongoing connectionIt is simplest to just cryptographically sign the content directly so this is how OpenPGP does it. As a result, OpenPGP does not need any sort of AE when used in the usual way.
  
-An anonymous message can come from anywhere and be sent by anyone. If that person is up to no good and is hoping to mislead you or attack your end point they can just do thatIf there is a requirement for AE they will just produce valid AE. There is no need to modify a message when they are creating the message in the first placeAE is only valuable in messaging when you can link it to a particular identity. PGP already has signatures for that.+Suppose we decided we wanted to do things in the more complicated connection oriented way anywaySince we would be authenticating the connection, not the message/document/file, that would mean that the recipients of our message/document/file would be able to trivially forge our signature. Fixing this would involve more extra complexity on top of the existing extra complexitySo, again, OpenPGP is doing things in the optimal way
  
-... and what are you going to tell the user when the AE goes wrong? You can't just ignore the whole thing like you can do in other applicationsThe user sees they have an email and attempts to view it. That's when the AE failsWhat would the error message be that would allow the user to make good decision going forward? What if the user wants to see it even though it is wrong? They deserve the chance to figure out //what// went wrong, particularly if they are under some sort of attack.+OpenPGP supporting systems are sometimes called on to support the case of unsigned (anonymous) messages/files. An anonymous message/file can come from anywhere and be sent by anyone. If that person is up to no good and is hoping to mislead you or attack your end point they can just do thatIf there is a requirement for AE they will just produce valid AE. There is no need to modify message when they are creating the message in the first place. AE as most people understand it is pointless for messaging/file encryption when there is no authentication to begin with.
  
-There have been some attacks against the malleability of PGP encryption over the yearsThey lack the possibility of practical application.+Even if authentication is not possible in the anonymous message/file case it is still possible to check for integrity. In other words; you can determine if the message/file was modified in transitFor this purpose OpenPGP provides the [[pgpfan:mdc|modification detection code]] (MDC). Since there is no authenticated shared key available in this case the MDC can be a simple but effective checksum that only depends on the encrypted data.
  
-One attack(([[https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf|Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels]])) against inherently insecure content (HTML email) uses malleability to trigger leakage of an encrypted email. The attack requires knowledge of the first 11 bytes of the pre-encrypted message. It would cause the signature to fail and would result in an anonymous message. Use of the attack would immediately be noticed by the recipientThere were much easier and much more reliable ways found to trigger this leakage than malleability.+By the way, the OpenPGP method that invokes the use of AE is symmetrical encryptionThis is where the same key is used to encrypt something as well as to decrypt itIn practice this mode is only used to encrypt files that are not going to be moved anywhereAs a result interoperability is unimportant and an interoperability standard like OpenPGP is also less important. It turns out though, that the MDC works as AE in this case. The content and the MDC is encrypted with the symmetrical key and as a result authenticates the content on the basis of that keySo OpenPGP actually //has// authenticated encryption but it doesn't matter much that it does 
  
-The researchers noted that email clients handled the failure of the PGP [[pgpfan:mdc|MDC]] integrity check caused by the attack very inconsistentlyThis fact tends to support my previous comments about the user interface problem created by adding a AE check to PGP. An MDC failure is the same type of failure as an AE failure and would have to be treated in the same way.+There is a sort of philosophical issue here as well. OpenPGP is a definition of a message format. It can't directly specify how things are implemented. Most AE schemes are some sort of encryption with an integrity check bundled in. How bundled the check is would get lost in a mere message format. OpenPGP already defines an integrity check in the form of the [[pgpfan:mdc|modification detection code]] (MDC). So a proposed AE scheme for OpenPGP is really just a proposal for an integrity check different than the MDC and there isn't anything wrong with the MDCMost AE schemes do not include any sort of intrinsic protection against modification like the [[pgpfan:cipherfeedback|cipher feedback]] embodied by OpenPGP. So it is possible that [[pgpfan:no_new_ae|adding a more popular AE mode to OpenPGP would actually make things worse]], due to the extra complexity and the loss of intrinsic modification protection.
  
-Another attack(([[https://www.schneier.com/academic/paperfiles/paper-chotext.pdf|A Chosen Ciphertext Attack Against Several E-Mail Encryption Protocols]])) uses malleability to enhance [[wp>Social_engineering_(security)|social engineering]]. An encrypted message is modified to make it look like a bunch of random junk. Then the recipient is tricked somehow into decrypting the anonymous message (the signature would fail) and sending it back to the attacker. The attacker would undo the modification and get back a decrypted message.+Summing up, OpenPGP does not require authenticated encryption for the normal caseFor unauthenticated material OpenPGP provides the MDC which is specifically designed for that case.
  
-The idea of adding some form of authenticated encryption to PGP is not entirely without merit but the absence of it is in no way any sort of a crisis, particularly in the case of messaging...+[[pgpfan:index|PGP FAN index]]\\ 
 +[[em:index|Encrypted Messaging index]]\\ 
 +[[:start|Home]]
  
pgpfan/authenticated.1598983142.txt.gz · Last modified: 2020/09/01 17:59 by b.walzer