The Call of the Open Sidewalk

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

User Tools

Site Tools

pgpfan:pgpauth

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:pgpauth [2025/10/10 21:46] – [The Why of PGP Authentication] Confusing and beside the point. b.walzerpgpfan:pgpauth [2025/10/10 22:01] (current) – [The PGP OCFB-MDC Encryption Mode] What sort of implementations? b.walzer
Line 17: Line 17:
 You send things on the Internet by breaking your data into a bunch of individual packets and sending them off. Each packet is treated separately and has an individual adventure. They can take different paths and might not even get to the destination in the correct order. So you would have to apply authentication to each individual packet. This sort of network is referred to as "connection-less". You send things on the Internet by breaking your data into a bunch of individual packets and sending them off. Each packet is treated separately and has an individual adventure. They can take different paths and might not even get to the destination in the correct order. So you would have to apply authentication to each individual packet. This sort of network is referred to as "connection-less".
  
-We could just apply a cryptographic signature to each packet. That would work but is a poor idea for more than one reason...+We could just apply a cryptographic signature to each packet. That would work but is a poor idea for more than one reason:
  
-The signatures are large. For example, a RSA signature could be 256 bytes long (2048 bit key). Even if we anticipate the future, a signature based on an elliptic curve scheme would be at least 64 bytes long. The packets are small. They are only 1500 bytes or less. The signatures would represent significant overhead. The 1500 byte limit is a hard limit. Adding a signature would significantly reduce the maximum amount of data that could be sent in the packet. So applying authentication would cause an awkward problem for the networking system.+  * The signatures are large. For example, a RSA signature could be 256 bytes long (2048 bit key). Even if we anticipate the future, a signature based on an elliptic curve scheme would be at least 64 bytes long. The packets are small. They are only 1500 bytes or less. The signatures would represent significant overhead. The 1500 byte limit is a hard limit. Adding a signature would significantly reduce the maximum amount of data that could be sent in the packet. So applying authentication would cause an awkward problem for the networking system.
  
-The signatures are slow. Signing and then verifying the signature on each and every (small) packet would create a significant processing requirement.+  * The signatures are slow. Signing and then verifying the signature on each and every (small) packet would create a significant processing requirement.
  
 So we wonder if things might be less difficult on a connection oriented network. Well, the world wide web (which is what we are primarily targeting) runs on top of the [[wp>Transmission_Control_Protocol|Transmission Control Protocol]] (TCP) which adds a connection oriented protocol on top of the connection-less Internet. With TCP we have a definite start of a connection, a middle part and an end. So here is what we do: So we wonder if things might be less difficult on a connection oriented network. Well, the world wide web (which is what we are primarily targeting) runs on top of the [[wp>Transmission_Control_Protocol|Transmission Control Protocol]] (TCP) which adds a connection oriented protocol on top of the connection-less Internet. With TCP we have a definite start of a connection, a middle part and an end. So here is what we do:
Line 77: Line 77:
 =====The PGP OCFB Encryption Mode===== =====The PGP OCFB Encryption Mode=====
  
-The very existence of this mode seems to confuse people((The PGP OCFB mode is contained in the OpenPGP Symmetrical Encryption Data packet (SED).)). It is a mode with, you guessed it, no integrity check. It is pure encryption. We should have a pretty good idea at this point about why it exists. Since PGP authentication is done directly on the data there is simply no need for anything else. An encryption mode that provided an integrity check feature would be redundant and would cause inefficiency.+This is an encryption mode with no integrity check((The PGP OCFB mode is contained in the OpenPGP Symmetrical Encryption Data packet (SED).)). It is pure encryption. We should have a pretty good idea at this point why it exists. Since PGP authentication is done directly on the data there is simply no need for an integrity check. An encryption mode that provided an integrity check feature would be redundant and would cause inefficiency. 
 + 
 +The very existence of this mode seems to confuse people...
  
 =====The PGP OCFB-MDC Encryption Mode===== =====The PGP OCFB-MDC Encryption Mode=====
  
-So there is a PGP encryption mode //with// an integrity check((The PGP OCFB-MDC mode is contained in the OpenPGP Symmetrical Encryption Integrity Protected Data packet (SEIPD).)). For those of us who know how PGP authentication works the existence of //this// mode is confusing.+So... This is awkward... 
 + 
 +OCFB-MDC is a PGP encryption mode //with// an integrity check((The PGP OCFB-MDC mode is contained in the OpenPGP Symmetrical Encryption Integrity Protected Data packet (SEIPD).)). For those of us who know how PGP authentication works the existence of //this// mode is confusing.
  
 People were happily and securely using the OCFB encryption mode with PGP authentication for many years. The OCFB-MDC mode came along later. People were happily and securely using the OCFB encryption mode with PGP authentication for many years. The OCFB-MDC mode came along later.
  
-A valid OCFB-MDC integrity check insures:+A valid OCFB-MDC integrity check ensures:
  
   - The file/message has not been modified.   - The file/message has not been modified.
Line 93: Line 97:
 So why does the OCFB-MDC encryption mode exist at all? It's specifically for the case of anonymous (unsigned, unauthenticated) files/messages. We won't know where the file/message came from, but at least we know it wasn't tampered with. It's better than nothing. So why does the OCFB-MDC encryption mode exist at all? It's specifically for the case of anonymous (unsigned, unauthenticated) files/messages. We won't know where the file/message came from, but at least we know it wasn't tampered with. It's better than nothing.
  
-In practice almost all implementations will emit OCFB-MDC encrypted messages even if the file/message is signed. That makes it so that schemes that depend on the integrity check will always have it available without consideration of the authentication status of the message. The resulting inefficiency is apparently considered an acceptable cost. Those implementations that do not require the integrity check can simply just ignore it.+In practice almost all PGP implementations will emit OCFB-MDC encrypted messages even if the file/message is signed. That makes it so that schemes that depend on the integrity check will always have it available without consideration of the authentication status of the message. The resulting inefficiency is apparently considered an acceptable cost. Those implementations that do not require the integrity check can simply just ignore it.
  
 When working with PGP, it is important to clearly understand the difference between authentication and the integrity check. The integrity check is limited and often full authentication is required or more desirable. When working with PGP, it is important to clearly understand the difference between authentication and the integrity check. The integrity check is limited and often full authentication is required or more desirable.
  
pgpfan/pgpauth.1760132795.txt.gz · Last modified: by b.walzer