On 24.8.2013, at 20.43, Ian Goldberg <[email protected]> wrote: > On Sat, Aug 24, 2013 at 06:04:06PM +0300, Timo Sirainen wrote: >> On 24.8.2013, at 17.41, Ian Goldberg <[email protected]> wrote: >> >>>>>>> I was planning to use libotr for a project where I'd need both >>>> "normal" asymmetric encryption (RSA probably) and OTR-like encryption. >>>> The problem is that I was hoping to use a single public key for both >>>> uses, but OTR uses only DSA and I can't do encryption with it. My next >>>> thought was to modify libotr to support RSA signatures as well, but >>>> since I'm not really a crypto expert I thought I'd ask here first if >>>> that's even a good idea? Would it be as simple as changing the >>>> DSA-specific code to RSA or are there some deeper problems to solve as >>>> well? >>>>>> >>>>>> At least it seems to work.. >>> >>> Wait: you're trying to use the same key for signing messages in OTR and >>> for decrypting messages in another protocol? This is an *extremely* bad >>> idea cryptographically. Or do I misunderstand? >> >> I understood that the DSA public key in OTR are only used to identify the >> sender during AKE, not sign the actual messages. So if that is replaced by >> RSA public key, which is also used for encrypting messages in external >> protocol, is that a bad idea? (The OTR communication isn't encrypted or >> signed in that protocol.) >> >> My other idea was to use RSA key for the external protocol and keep using >> DSA for OTR. Then always distribute the DSA public key with the RSA public >> key. Maybe also sign the DSA key with the RSA key or vice versa. But I don't >> see how that's different from just using the same RSA key also in OTR? > > There are two problems. The first is that using the same key in two > different protocols can lead to vunerabilities that don't occur if each > protocol has independent keys. While unlikely, it makes crypto-folk > nervous. > > The bigger issue, though, that that you should never use the same key > for both signing and decryption. This was a mistake that PGP 2.x made, > that was corrected in later versions. (It's also a mistake *many* > textbooks still make!) If for no other reason, you really want > decryption keys to be short lived, but signing keys to be long lived. > But you can also end up with funny oracle-type attacks that again make > the crypto-folk nervous. > > So what I'd suggest is distributing both the RSA and DSA pubkeys, > signing the RSA pubkey with the DSA privkey (but *not* the other way > around), and then regularly changing the RSA key and re-signing and > re-distributing.
Thanks, I'll switch to doing that. So feel free to ignore the RSA patch I sent. Although it could probably be used as an easier base for adding another signature algorithm, since it makes it clear where the DSA-specific code paths are and how to do them differently. _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
