[OTR-dev] DSA, RSA, ECDSA, etc

Jacob Appelbaum jacob at appelbaum.net
Mon Sep 24 16:07:29 EDT 2012

Hans-Christoph Steiner:
> On 09/24/2012 02:59 PM, Gregory Maxwell wrote:
>> On Mon, Sep 24, 2012 at 2:49 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
>> [snip]
>>> But what is the right way to ensure that k has some safety without being
>>> weaker by being predictable? I imagine a lot of OTR conversations start
>>> with pretty well known plaintext such as "hi" or "hello" or some
>>> variant. So a hash or a MAC over that message as part of k isn't really
>>> well, unpredictable
>> ed25519 (a ECDSA like algorithm for signing over a particular curve)
>> solves this elegantly
>> by using r=SHA512(data_being_signed || secret_stored_with_dsa_privkey).
>> If the same privkey signs the same message twice you just get the same
>> signature, and
>> obviously don't leak anything by having two copies of the same thing.
>> if SHA512 is a good
>> pseudo-random oracle then the random number is good. (And putting the
>> secret at the end
>> probably reduces some concerns with extension attacks against
>> Merkle-Damgard hash
>> functions like sha512).
> Outside of the crypto reasons, I think that ECDSA is very nice for
> things like SMS and mobile messaging since its a lot smaller.  So ECDSA
> support in libotr would be a lot more interesting to me than RSA.  Plus,
> it sounds like TextSecure is already pretty close to OTR with ECDSA, so
> there is a working prototype to hammer on and find out what breaks in
> the real world.

I agree - ECDSA would be a good addition.

> I'll leave the RNG and k tricks to the pros :)

Heh - my thoughts exactly. :(

All the best,

More information about the OTR-dev mailing list