DSA and SHA-256 (It works! Or does it?! :))

[Werner Koch]

On Wed, 13 Jan 2010 17:32:31 +1300, Sam Vilain wrote:

> That being said, I see in the source eg g10/sign.c that this case is
> well described already.  I can't find the exact source line where this
> truncation happens, but I assume it does somewhere.

gnupg/g10/sesskey.c:encode_md_value():

   size_t qbytes = gcry_mpi_get_nbits (pk?pk->pkey[1]:sk->skey[1]);

   [... check qbytes ... ]

   qbytes/=8;

   if (gcry_mpi_scan (&frame, GCRYMPI_FMT_USG,
                      gcry_md_read (md, hash_algo), qbytes, &qbytes))
        BUG();
   
gcry_mpi_scan does the truncation.


> What is in that subpacket?  Pulling it apart (using
> Crypt::OpenPGP::Message), I can see that r is
> 563842300114387388457394839662831482428878447936 and s is
> 377105405312767191687013088546003017320679158753 - definitely both <160 bit.

FWIW, you may use gpg --debug 2 --list-packets to show the MPIs.

> 1. is gpg doing the correct, FIPS-186-3 thing of throwing away the lower
> bits?

Yes.

Libgcrypt does not enforce this because FIPS-186-2 does not seem to
require it.  Libgcrypt is currently in NIST's evaluation queue but the
project was started far prior to June 2009 when -3 was released.

> 2. is this safe?

We hope so.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.