|
|
Line 9: |
Line 9: |
| # [http://en.wikipedia.org/wiki/Deniable_encryption#Malleable_encryption Malleable encryption] | | # [http://en.wikipedia.org/wiki/Deniable_encryption#Malleable_encryption Malleable encryption] |
|
| |
|
|
| |
| = Compatibility of Security Properties with XMPP Features =
| |
| == One-to-One Chat ==
| |
|
| |
| == Multi-User Chat ==
| |
|
| |
| == Multiple resources ==
| |
| Using multiple resources almost certainly contradicts having forward secrecy:
| |
| * Forward secrecy uses short-lived (decryption) keys that are negotiated between two endpoints (clients)
| |
| * Multiple resources must use the same decryption key to be able to decrypt messages originally sent to the other resource after a spontaneous resource switch
| |
| * Multiple resources must use the same signing key to avoid multiple authentications between the same partners using different resources
| |
| Either the resources would have to exchange their key material frequently (themselves retaining the forward secrecy) or share a long-living signing key that is used for authentication.
| |
|
| |
| Of course, this assumes that you only have to authenticate the user/JID once and not for every resource. If you are willing to authenticate every resource of your communication partner separately, the problem is reduced to that of a Multi-User Chat.
| |
|
| |
|
| = Proposals = | | = Proposals = |