pgpfan:repudiability
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
pgpfan:repudiability [2020/06/11 01:10] – index b.walzer | pgpfan:repudiability [2021/01/08 23:34] – Pretty much complete rewrite b.walzer | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ======Repudiability====== | + | ======Deniability====== |
- | Repudiability | + | Deniability |
- | If you send a signed and encrypted PGP message to someone then these two entities can gain knowledge | + | When you use public key cryptography to encrypt |
- | - The person you sent it to. | + | Deniability is intended |
- | - Someone who manages | + | |
- | Repudiability is intended to prevent those entities from causing you problems due to that knowledge by breaking or weakening the connection between the message and your cryptographic identity. Your cryptographic identity is normally based on some data that it is expected that only you have access to. In the case of PGP that data is your private key which is required to generate the signature. For this to potentially matter, your signed message would have to be linked to your cryptographic identity. | + | =====Applicability===== |
- | + | ||
- | In a PGP context that would involve at least one of: | + | |
- | + | ||
- | - Direct access to your private key. | + | |
- | - Someone who " | + | |
- | - Some sort of more complicated argument involving the PGP web of trust. | + | |
- | + | ||
- | The first instance is the most definite. It also implies that both you and your correspondent have been compromised. The others provide no definite cryptographic proof of identity. | + | |
In the event that someone can come up with a tie between you and your cryptographic identity then this is what they will face when attempting to link it to your physical identity: | In the event that someone can come up with a tie between you and your cryptographic identity then this is what they will face when attempting to link it to your physical identity: | ||
Line 22: | Line 13: | ||
- Very few people understand cryptographic signatures well enough to even believe that such a thing is possible. | - Very few people understand cryptographic signatures well enough to even believe that such a thing is possible. | ||
- There is no cultural context for the application of cryptographic signatures. | - There is no cultural context for the application of cryptographic signatures. | ||
- | | + | |
- | For something like a court case if it is email then the normal | + | As an example; email evidence used in something like a court case would follow |
In a personal communications situation the people involved will know each other. If the reporter is part of the group then it would come down to how the others felt about you and them. If it was an outsider then the report would be treated as an unsubstantiated rumour. A technical proof would be ignored as redundant. | In a personal communications situation the people involved will know each other. If the reporter is part of the group then it would come down to how the others felt about you and them. If it was an outsider then the report would be treated as an unsubstantiated rumour. A technical proof would be ignored as redundant. | ||
- | Note that a PGP user has complete control over how much their cryptographic identity is linked | + | Ironically the very existence of a deniability feature draws attention |
+ | |||
+ | ====Trusted Correspondent==== | ||
+ | |||
+ | Far and away the most common case is where you can trust the one you are messaging | ||
+ | |||
+ | Here we need to make a distinction between | ||
+ | |||
+ | ====Untrusted Correspondent==== | ||
+ | |||
+ | This could be considered the true "off the record" | ||
+ | |||
+ | - Not connecting their identity | ||
+ | - Not signing their messages at all. | ||
+ | |||
+ | ... rather than having to try to weaken | ||
+ | |||
+ | It is not really certain that deniability is even completely possible in this case. The cryptographic signature has still proven whatever it can prove. Whatever indication that the system has given your correspondent | ||
=====Forgeability===== | =====Forgeability===== | ||
- | Forgeability is a part of repudiability. The idea is to make things | + | The method |
+ | |||
+ | The fundamental problem here is that the mere possibility of forging a message | ||
- | The fundamental problem with the concept | + | In practice you would have to at least imply that your message was a forgery created by someone using a complicated and obscure technical process. This has obvious ethical issues and is unlikely to work, either in the court of public opinion or a court of law. Most media is relatively easy to forge but false claims of such forgery are quite rare which suggests that such claims don't tend to work out. Fabricated evidence of a forgery could work, but the risk is much higher. |
- | **The mere possibility of forging | + | Consider the case where a corpus of encrypted email is publicly leaked but it is not possible to decrypt that email at that time. Should it then become possible to decrypt the email later then it can be shown that the email existed before it was possible for anyone to forge it. Forgeability is thus negated. An entity that is saving encrypted messages |
- | In practice you would have to falsely accuse someone | + | There is a potential problem |
- | It is much better and safer to just claim that the problematic statement | + | In the same way, using a system that is deliberately designed to allow you to say something then deny having said it might also cause extra suspicion. The concept is quite easy to understand, as opposed to the stuff about public key based signatures. |
- | A system that supports forgeability will have the ability | + | Consider |
- | In a PGP context you could claim someone had gained access to your private key. That argument might actually have some force in a case where someone' | + | ====Forgeability Light==== |
- | Most media is relatively easy to forge. But yet false claims of such forgery are quite rare which suggests | + | Instead of releasing the information required |
- | Repudiability is one of those things that seems like a good idea in theory. In practice it has very little value. It is unlikely that the feature is worth the extra complexity it would take to implement it. | + | =====Conclusion===== |
- | [[pgpfan: | + | Forgeability as used for deniability would rarely be applicable. The most likely instance where it would be relevant would be in the case of a compromised endpoint. In that situation you have a plausible way to claim a forgery and thus denyabliliy becomes redundant. |
+ | Deniablity is one of those things that seems like a good idea in theory. In practice it has very little value. It is unlikely that the feature is worth the extra risk of the complexity it would take to implement it. | ||
pgpfan/repudiability.txt · Last modified: 2021/06/05 01:10 by b.walzer