Bug in tomcrypt's ECDSA implementation?

[Sergejs Belajevs]

Hi!

I am reading the "Cryptography for developers" by Tom St. Denis and looking through the Tomcrypt's code. On page 398 of the book, there is a description of Elliptic Curve Signature algorithm. It seems that step 5 ("Truncate H to the leftmost ceil(log2n) bits. For instance, with P-192, truncate H to 192 bits") is missed from the code. Comparing the results of signature with other libraries (bouncycastle.org for example) also shows differences.

Am I missing something, or this is really a bug in the Tomcrypt code?

--

Thanks,

Sergejs

[rudolfs.k...@gmail.com]

This is somewhat discussed in TomCrypt documentation:
(found at https://libtomcrypt-cug.googlecode.com/files/crypt.pdf)

8.8 ECC Keysizes With ECC if you try to sign a hash that is bigger than your ECC key you can run into problems. The math will still work, and in effect the signature will still work. With ECC keys the strength of the signature is limited by the size of the hash, or the size of they key, whichever is smaller. For example, if you sign with SHA256 and an ECC-192 key, you in effect have 96–bits of security. The library will not warn you if you make this mistake, so it is important to check yourself before using the signatures.

Though I still consider this as a bug, since the signature will not be valid according to ECDSA specs, only TomCrypt can validate it.

Thanks,

Rudolfs

[tstde...@gmail.com]

Technically the higher order bits are supposed to be trimmed (iirc per X9.62).  The way LTC does it is not compliant but it's not really a security issue.  

It should be fixed per X9.62 though...

Tom