[OTR-dev] RSA signatures again

[Timo Sirainen]

On 24.8.2013, at 20.43, Ian Goldberg <ian at cypherpunks.ca> wrote:

> On Sat, Aug 24, 2013 at 06:04:06PM +0300, Timo Sirainen wrote:
>> On 24.8.2013, at 17.41, Ian Goldberg <ian at cypherpunks.ca> 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.