yet another tiny feature: deterministic ECDSA

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 11.04.2013 21:59, Christian Grothoff wrote:

> On 04/11/2013 09:54 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 11.04.2013 21:37, Christian Grothoff wrote:
>>
>>> Hi!
>>>
>>> I don't know if I mentioned this one yet.   When I call 'gcry_pk_sign' for ECDSA signing,
>>> libgcrypt generates (as per ECDSA requirements) a random 'k' value each time.  'k' must
>>> be random as an adversary must not be able to determine 'k', and two signatures must not
>>> share the same 'k' to avoid exposing the private key.
>>>
>>> However, in our use, it happens that the same private key is used to sign the same
>>> private data more than once.  Thus, it would be great if we could in that case generate
>>> exactly the same signature over the same data by using the same 'k' value.
>>>
>>> I can (safely) construct a pseudo-random seed/k-value that will be unique (and only
>>> known to those that know the private key anyway), but the current gcry_pk_sign API
>>> does not yet allow me to pass it.
>>>
>>
>> This is something which is very tricky to get right and exposes the
>> whole system if it isn't. I think the library shouldn't export such
>> primitives at all. Why isn't storing the signature appropriate for your
>> case?
> 
> Because different peers create the signature independent of each other.  The private
> key is actually the hash of a password / keyword in this case.  And yes, I understand
> how dangerous this is in the wrong hands ;-).
> 

Sounds like you're trying to design a new protocol with pieces not
really meant to be used this way. Why not just use a standard protocol?
There are loads of standard protocols for nearly every possible use.

> Happy hacking!
> 
> Christian
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130412/8f25a931/attachment.sig>