| Next revision | Previous revision |
| pgpfan:forward_secrecy [2020/05/27 19:11] – created b.walzer | pgpfan:forward_secrecy [2022/03/19 21:50] (current) – Redundant, poorly worded. b.walzer |
|---|
| ======Forward Secrecy====== | ======Forward Secrecy====== |
| |
| Someone gets access to your PGP private key(s). What to they get? | The PGP protocol is sometimes criticized because it lacks a feature called [[wp>Forward_secrecy|forward secrecy]]. Forward secrecy is intended to reduce or eliminate the effects of an attack that goes like this: |
| |
| - Access to any of your future incoming PGP protected email that they can see in transit. | * Some adversary records your encrypted messages and creates an archive of then without your knowledge or consent. |
| - Access to your archived email. | * Optionally the adversary can attempt to break the encryption on your messages. If they are successful then forward secrecy provides no value. |
| - Access to any of your past incoming PGP protected email that they recorded in transit. | * They then attack the place the secret key information is stored (usually an end device) to get the information required to decrypt their surreptitious archive of your encrypted messages. |
| | |
| [[wp>Forward_secrecy|Forward secrecy]] addresses the third issue. Some process is used to come up with a temporary key known only to you and your correspondent (e.g. [[wp>Diffie–Hellman key exchange]]). That key is used to encrypt the message. After the message is transferred and decrypted that temporary key is destroyed. That way any of your protected emails intercepted by someone will stay protected unless that someone figures out how to break the underlying crytographic algorithm(s). That is normally much harder than stealing your private key(s). | |
| |
| Real time forward secrecy requires a end to end, bidirectional communications channel to establish a temporary key. Email is inherently unidirectional and allows the email to be stored and forwarded. Old emails tend to be relatively valuable and are often archived. That makes forward secrecy pointless in practice. Whatever method is used to get the private keys could be used to get access to the archives. | So starting out we are talking about a two phase attack that requires access to an end point and significant preplanning. |
| |
| You can get the result of forward secrecy by using PGP with a bit of forethought. You and your correspondent(s) would create subkeys specifically for the discussion that is to be forgotten. Those keys would be used for that discussion for as long as could be considered prudent. That might be many years; sometimes the only requirement is that a discussion //can// be forgotten. Then you and your correspondent(s) delete the subkeys. That will also permanently remove access to any archived emails. wherever they ended up. A system that provided real time forward secrecy would need a separate archive system and thus would likely require some careful deletion if such an archive was kept. The PGP case allows a complete archive with no extra risk. This is a benefit of the PGP encrypt once scheme. | If we are talking about OpenPGP over email then creating an archive of your encrypted messages from monitoring the network is not really possible any more. Most email in transit is now separately encrypted on the network using TLS. The same situation exists for OpenPGP over XMPP. |
| | |
| | So a practical attack would involve the compromise of not just your end point but your email server as well. The attacker would have to first compromise your email server, wait to build up an archive of your messages and then compromise your end device to get the secret key material to decrypt their archive. It would make more sense for an attacker to go for your end device in the first place and end up with the same material, sooner. |
| | |
| | Email messages are normally kept indefinitely and that tends to be the default even on systems that provide forward secrecy. If the attacker gets your secret key material then they pretty much for sure are going to be able to get access to your archived messages at the same time. Very few people are willing to go without a message archive so forward secrecy is unlikely to help in most practical cases of messaging. |
| | |
| | Reduced to the essence: forward secrecy is where you delete the encryption key protecting some encrypted data to prevent that key from falling into the possession of an attacker that already has that encrypted data. There is nothing preventing any system from doing that, even something based on the OpenPGP standard. For a practical demonstration see: [[pgpfan:gpgburn|A Demonstration of Message Burning Through Encryption using GnuPG]]. |
| | |
| | Hardly anyone ever does forward secrecy with OpenPGP. Why not? It's easy to do in a technical sense and would not cause your correspondents to have to reverify your identity. |
| | |
| | In 2020 a company called Cellebrite announced that they had a specific Signal Messenger data interpretation facility that would be useful in the event that their forensic box broke into the smartphone that Signal was running on(([[https://web.archive.org/web/20201210150311/https://www.cellebrite.com/en/blog/cellebrites-new-solution-for-decrypting-the-signal-app/|Cellebrite’s New Solution for Decrypting the Signal App]])). This sort of attack could not reveal any messages archived off the network due to Signal's forward secrecy. Let's compare the end result to an encrypted email client running on the same phone using traditional passphrase protection: |
| | |
| | | ^ Signal ^ Encrypted Email ^ |
| | | Archived Network Messages | Protected | Protected | |
| | | Messages Saved on Phone | Revealed | Protected | |
| | |
| | So the encrypted email actually ends up providing a better result for the user. That is because it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging. It seems possible that people don't bother with forward secrecy for encrypted email because they perceive it to be secure enough already. Forward secrecy might not be worth the extra effort for that particular medium. |
| | |
| | In general the value of forward secrecy decreases as the protection of the secret key material increases. So it might be more important for situations like instant messaging where it is harder to protect the secret key material(([[em:emailvsim|Encrypted Email is More Secure than Encrypted Instant Messaging]])). It might be very important for situations where the same secret key material is used by many users. For example it might be very worthwhile for an attacker to archive encrypted traffic from a messaging service used by millions of users protected by a single TLS private key if that service does not have forward secrecy. |
| | |
| | [[pgpfan:index|PGP FAN index]]\\ |
| | [[em:index|Encrypted Messaging index]] |
| |
