On Mon, Feb 11, 2008 at 07:31:43AM -0600, Kevin Hilton wrote: > On Feb 10, 2008 10:53 PM, Kevin Hilton <[EMAIL PROTECTED]> wrote: > > >You could use SHA-512 with > > >it if you liked, but the hash would be truncated to 256 bits. > > > > Interesting. Are the higher or lower bits truncated? > > > > >We follow the advice in FIPS 180-3: > > > > > > L = 1024, N = 160 > > > L = 2048, N = 224 > > > L = 3072, N = 256 > > > > Ok. So back to the ever asking defaults question, so why when I > > produce a 3072 bit DSA signing key, why isnt my first digest hash > > preference or choice SHA-256? Here is what I am getting: > > > > pub 3072D/0053175A created: 2007-11-14 expires: never usage: SC > > trust: unknown validity: unknown > > sub 4096g/51BFA0E0 created: 2007-11-14 expires: never usage: E > > [ unknown] (1). ----------------------------------------------------- > > > > Command> showpref > > [ unknown] (1). ----------------------------------------------------- > > Cipher: AES256, AES192, AES, CAST5, 3DES > > Digest: SHA1, SHA256, RIPEMD160 > > Compression: ZLIB, BZIP2, ZIP, Uncompressed > > Features: MDC, Keyserver no-modify > > > > It would seem in fact that my digest preferences should only be SHA256 > > or SHA512 based on the information provided! SHA1 or RIPEMD160 > > shouldn't even be listed here, correct? > > > > My reason for asking these questions is in regards to a documentation > Im trying to compose for a user's group. Obviously I'm very much a > novice in both the mathematics beyonds GnuPG but in also its > implementation. Its clear to me you are following both the FIPS and > OpenGPG RFC 8440 in implementing the program, however the truncation > of longer hash products, along with attempting to predict which hash > the program based on the output available will actually use is very > troubling and extremely difficult to document given all the nuances of > the program, particularly in relation to DSA keys. Given the above > example (just one example), where a 3072 DSA key actually uses either > a SHA256 or SHA512 bit hash (truncated to 256 bits), despite what is > listed when showprefs is displayed -- How do you actually document > this scenario?
First of all, leave out 'showpref' from your documentation of this question as it has nothing at all to do with hash choice when you make a signature. It's only relevant for other people making signatures and sending them to you. That leaves the question of which hashes are usable for a given DSA key. The answer is that all DSA keys contain a number called the 'q' value. That value specifies how large the hash must be when making signatures with that key. There are a few differences, but the main difference between DSA1 and DSA2 is that DSA1 keys have q=160 and it cannot change. This is why DSA1 keys need SHA-1 or RIPEMD160 as their hash: they are both 160-bit hashes, to match q=160. DSA2 keys can have different q values. In DSA2, you can use whatever hash you like as long as it is equal to, or greater than your q size. > Are RSA signing keys subject to some of the same nuances as DSA keys? > Practically could a 1024 bit RSA key be used with a 512 hash? Yes. It's silly, as the hash is vastly stronger than the key, but it's legal, and GPG can do it. > Again its all very confusing to me -- math aside and practical > considerations why you wouldn't want to mix and match key types and > hash lengths. Again Robert Hansen has wisely suggested use the > defaults -- I'm understanding this more and more -- however when I see > showpref statements that would suggest SHA-1 is the default hash, when > in actuality with larger DSA keys it is not, I get rather frustrated. Robert is quite right about the defaults. There are some very complex issues here and GPG is a very configurable program. It's excellent that people spend the time to understand the issues, but I find that most people who spend the time to learn the issues also use the defaults :) Daxvid _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
