[prev in list] [next in list] [prev in thread] [next in thread]
List: gnupg-devel
Subject: Re: DSA and SHA-256 (It works! Or does it?! :))
From: Werner Koch <wk () gnupg ! org>
Date: 2010-01-13 9:27:12
Message-ID: 877hrmz767.fsf () vigenere ! g10code ! de
[Download RAW message or body]
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.
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic