Daniel Kahn Gillmor dkg@fifthhorseman.net writes:

I'm also interested in making some OpenPGP tools, and exploring the range of crypto primitive toolkits to use. nettle seems like an obvious choice, but i won't be able to test those certs with it.

You may want to look at the (unfinished) openpgp code in Nettle, when I worked on it the first objective was to be able to generate key packets.

so: not a great or urgent reason, but it'd be nice to be able to use nettle as a basis for tools that implement higher-level specs.

I guess it shouldn't be too difficult to implement SHA512 (and -384) if one uses uint64_t and doesn't care too much about performance on 32-bit machines.

...

Adding support for new hashes there is easy, as soon as people have agreed on which object id to use.

what do you mean by object id?

RSA signatures using pkcs#1 uses a magic string to identify the used hash, and this string is prepended to the hash value, formally to construct a DER-encoded ASN.1 DigestInfo (but one doesn't have to care about the structure of the magic string). E.g., for sha-1, I have (in pkcs1-rsa-sha1.c):

static const uint8_t sha1_prefix[] = { /* 15 octets prefix, 20 octets hash, total 35 */ 0x30, 33, /* SEQUENCE */ 0x30, 9, /* SEQUENCE */ 0x06, 5, /* OBJECT IDENTIFIER */ 0x2b, 0x0e, 0x03, 0x02, 0x1a, 0x05, 0, /* NULL */ 0x04, 20 /* OCTET STRING */ /* Here comes the raw hash value */ };

So one has to figure out the corresponding string to use for sha-512 and sha-384 (none is specified in fips180-2.pdf, so one has to look in some other spec).

...

Agree! I'm not sure how to fix it, maybe it's sufficient to add "multipart/signed" to mailman's pass_mime_types?

i don't know, but that sounds like a reasonable thing to try. let me know if you want me to test it.

I changed the mailman configuration, but not sure things work. I signed my previous message (and I'm signing this one too), and it got throuh to the list, but the message/signature pair was corrupted somehow when I received it (I use gnupg and the builtin pgp support built in emacs-23.1, Gnus-v5.13).

Regards, /Niels

Daniel Kahn Gillmor dkg@fifthhorseman.net writes:

sweet, i'll take a look. fwiw, i think that kind of higher-level work belongs in a separate library, so that the crypto primitives are available independently.

Right, anything large belongs elsewhere, but I think it would be useful to at least have tools for converting keys to and from openpgp format.

i do care about performance on 32-bit machines, but i care about having the functionality available more ;) optimization can come later if we want.

I just checked in an implementation of SHA 512. Basically copy and paste of the SHA 256 code, with larger datatypes and different constants...

A lot of minor things left, like HMAC and RSA using SHA 512, but I might add that shortly. And SHA 384, which is almost the same thing (is anybody using that?).

And then both the SHA256 code and the SHA512 internals should be reorganized slightly with a compression function in a separate file, just like for MD5 and SHA1, to aid later assembler hacks.

If you or anybody else have additional test vectors for SHA 512 or HMAC-SHA-512 or RSA signatures with SHA 512, I'd like to add them. Currently, I have only two test cases, extracted from the FIPS 180-2 spec.

The object IDs for the higer-level hashes are specified here:

http://tools.ietf.org/html/rfc3447#page-43

Noted, thanks for looking it up for me.

Regards, /Niels

Daniel Kahn Gillmor dkg@fifthhorseman.net writes:

i'm not using SHA 384 myself, but it seems worth handling for the sake of completeness (most protocol i've seen that supports SHA512 also supports SHA384).

When looking at the test vectors you provided, I noticed SHA-224 (specified in the update http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf and also RFC 3874). Is this also important, are there any protocols or application that specify it's use? It's defined in terms of SHA256 in the same way as SHA384 is defined in terms of SHA512. To me, the SHA-2 family seems to have more members than are really useful.

I put a set of test cases in t/08-digest.t of perl's Crypt::GCrypt, if you're interested.

Thanks, I'll add those that are missing in Nettle's current testsuite. Still missing are independent test vectors for RSA signatures.

Regards, /Niels

Daniel Kahn Gillmor dkg@fifthhorseman.net writes:

OpenPGP defines sha-224 as part of its suite of message digests, so i think supporting it would be good. If you're concerned about size of the compiled library,

I don't think the impact on the object size is that big; without measuring, I think the compression function (which is partially unrolled) is by far the largest piece of sha256 and sha512, and that function is reused for sha224 and sha384, respectively.

I think the bloat is more of a concern in the source code and the documentation, with a large number small and almost identical functions. I'll think about ways to reduce code duplication, in partcular for the rsa signing functions, now when we have a such a large number of hash functions to support.

(Using sha224 and sha384 for RSA signatures seems quite point-less to me; one saves 32 resp 128 bits in the hash digest, which is then padded to the RSA size, which should be at least 1024 bits anyway. So one truncates the hash without gaining anything in either computation time or signature size. Is there anybody who recommends those combinations, and if so, why?).

Regards, /Niels