Differences

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

--- pgpfan:authenticated [2021/12/15 23:51] – Made this more effective to better support other articles b.walzer
+++ pgpfan:authenticated [2023/02/28 16:46] (current) – new point b.walzer
@@ Line 3: / Line 3: @@
 It is sometimes said OpenPGP does not support a feature called [[wp>authenticated encryption]] (AE).
-AE is often seen in the case of stateful connected protocols. First a shared secret key is negotiated:
+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:
 {{auth_stateful_keys.svg}}
-The authorization is usually established by applying a 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 party.
+The authentication is usually established by applying a 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 party. This shared secret key inherits the authentication from the cryptographic signatures.
 The entities can then send messages encrypted with the shared key over the connection indefinitely:
@@ Line 13: / Line 13: @@
 {{auth_stateful_ae.svg}}
-The authenticated encryption ensures that these messages are from the other entity and were not modified in transit. Authenticated encryption preserves the authenticity established by the cryptographic signatures.
+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.
 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:
@@ Line 19: / Line 19: @@
 {{auth_stateless.svg}}
-Offline applications are by nature stateless with no reverse channel available. A message or file is created and sent off or stored to some sort of media. So there is no concept or possibility of an ongoing connection. It 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.
+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 connection. It 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.
+Suppose we decided we wanted to do things in the more complicated connection oriented way anyway. Since 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 complexity. So, again, OpenPGP is doing things in the optimal way.
 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 that. If 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 place. AE as most people understand it is pointless for messaging/file encryption when there is no authentication to begin with.
@@ Line 25: / Line 27: @@
 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 transit. For 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.
-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 MDC. Most 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 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.
+By the way, the OpenPGP method that invokes the use of AE is symmetrical encryption. This is where the same key is used to encrypt something as well as to decrypt it. In practice this mode is only used to encrypt files that are not going to be moved anywhere. As 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 key. So OpenPGP actually //has// authenticated encryption but it doesn't matter much that it does.
+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 MDC. Most 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.
 Summing up, OpenPGP does not require authenticated encryption for the normal case. For unauthenticated material OpenPGP provides the MDC which is specifically designed for that case.