On 23/04/13 14:21, Daniele Ricci wrote: > Clients will be using their OpenPGP keys to sign messages for one > another
I hope you don't mean context-free signatures on individual IMs similar to those in XEP-0027 <http://xmpp.org/extensions/xep-0027.html>? <body><signed signature="...">yeah I agree</signed></body> In typical IM usage ("conversational" and without context, unlike email which typically quotes relevant context), this makes you vulnerable to replay attacks (e.g. an attacker can send a previously-signed "yeah I agree" in response to something you didn't want to agree with) and message-dropping (an attacker can drop intermediate messages, and the recipient will never know that there was meant to be a message there). XTLS <https://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02> and OTR both address this, by authenticating on a per-conversation rather than per-message basis. I suggest thinking about your threat model - who is the attacker and what can they do? - before designing cryptographic protocols: otherwise, it's easy to end up with a system that has gained more complexity than actual security. > I thought it could be useful to use the same keys to > authenticate too - thus avoiding having two different keypairs (one > for authentication, one for encryption/signing). Conventional OpenPGP best-practice is to have one top-level keypair (public + private) for certification (signing keys) and optionally signing messages, a separate "subkey" for encryption, and optionally additional subkeys that can sign messages but cannot certify (sign keys). I'm led to believe that there are significant cryptographic advantages in doing this, although I don't understand the finer details. The "key ID" and "key fingerprint" that you see when doing keysigning are the ID of the certification keypair, which is the one that ties together the rest of the subkeys (by making a signed assertion that they belong to the same person). If you want identity based on OpenPGP, but authentication using X.509 (to take advantage of existing code), one way to do it is to have a machine-readable OpenPGP-signed assertion of the form "please assume that only I have access to the corresponding private key for the following self-signed X.509 cert: [...]". Something like that, or a subkey-based approach, would also have the advantage that an exploitable bug in your XMPP software would only result in disclosure of XMPP messages, and not a compromise of the OpenPGP key (and hence everything else it had been used for). S
