From dkg at fifthhorseman.net Fri Nov 6 05:31:23 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 05 Nov 2009 23:31:23 -0500 Subject: what is gcry_md_reset()'s relationship with HMAC? Message-ID: <4AF3A69B.2000908@fifthhorseman.net> hey folks-- from reading the gcrypt source, it looks to me like gcry_md_reset() does actually re-initializes the digest with the first part of the macpads structure, but it doesn't wipe the pads out. But the documentation for gcry_md_reset() doesn't mention setkey() at all -- it implies that it's the same as a close() followed by an open(), which would actually result in the wiping of the macpads themselves. (i.e. another gcry_md_setkey() would need to be invoked). Any explanation of this? Can the documentation be updated to be clearer? (i'm afraid i don't understand the md_write() of the inner padding for HMAC-enabled MDs at all, but that's probably because i don't correctly understand the HMAC context itself yet -- pointers welcome!) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Fri Nov 6 16:03:18 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 06 Nov 2009 16:03:18 +0100 Subject: missing entries in libgcrypt NEWS Message-ID: <87eiobwv9l.fsf@mocca.josefsson.org> I just noticed that the NEWS file (even in latest svn) is missing many entries from stable follow-on releases (e.g., 1.2.4), which makes it harder to search for when some new features were added. /Simon From dkg at fifthhorseman.net Mon Nov 9 23:44:26 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 09 Nov 2009 17:44:26 -0500 Subject: what is gcry_md_reset()'s relationship with HMAC? In-Reply-To: <4AF3A69B.2000908@fifthhorseman.net> References: <4AF3A69B.2000908@fifthhorseman.net> Message-ID: <4AF89B4A.8090404@fifthhorseman.net> On 11/05/2009 11:31 PM, Daniel Kahn Gillmor wrote: > from reading the gcrypt source, it looks to me like gcry_md_reset() does > actually re-initializes the digest with the first part of the macpads > structure, but it doesn't wipe the pads out. > > But the documentation for gcry_md_reset() doesn't mention setkey() at > all -- it implies that it's the same as a close() followed by an open(), > which would actually result in the wiping of the macpads themselves. > (i.e. another gcry_md_setkey() would need to be invoked). after some tests, it seems clear that gcry_md_reset() does not reset the HMAC keys. I think this is the Right Thing to do, but the documentation does not appear to describe this properly -- it seems to be different from a close() followed by an open(). maybe the docs should be updated? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Nov 10 23:24:43 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Nov 2009 17:24:43 -0500 Subject: gcrypt docs about SHA512 need simple fix Message-ID: <4AF9E82B.9030006@fifthhorseman.net> hey gcrypt folks-- this looks like a copy-paste error: Index: gcrypt.texi =================================================================== --- gcrypt.texi (revision 1406) +++ gcrypt.texi (working copy) @@ -3470,7 +3470,7 @@ See FIPS 180-2 for the specification. @item GCRY_MD_SHA512 -This is the SHA-384 algorithm which yields a message digest of 64 bytes. +This is the SHA-512 algorithm which yields a message digest of 64 bytes. See FIPS 180-2 for the specification. @item GCRY_MD_CRC32 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Nov 11 08:43:14 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Nov 2009 02:43:14 -0500 Subject: tiger test vectors unusual? Message-ID: <4AFA6B12.5040907@fifthhorseman.net> in tests/basic.c, it looks like the following two test vectors are displayed for the tiger192 digest: { GCRY_MD_TIGER, "", "\x24\xF0\x13\x0C\x63\xAC\x93\x32\x16\x16\x6E\x76" "\xB1\xBB\x92\x5F\xF3\x73\xDE\x2D\x49\x58\x4E\x7A" }, { GCRY_MD_TIGER, "abc", "\xF2\x58\xC1\xE8\x84\x14\xAB\x2A\x52\x7A\xB5\x41" "\xFF\xC5\xB8\xBF\x93\x5F\x7B\x95\x1C\x13\x29\x51" }, however the test vectors i could find on the net don't seem to agree that these are the correct values: http://www.cs.technion.ac.il/~biham/Reports/Tiger/test-vectors-nessie-format.dat suggests: Set 1, vector# 0: message="" (empty string) hash=3293AC630C13F0245F92BBB1766E16167A4E58492DDE73F3 Set 1, vector# 2: message="abc" hash=2AAB1484E8C158F2BFB8C5FF41B57A525129131C957B5F93 CPAN's Digest::Tiger contains the same two values in its test suite as the nessie test vectors, as do the test vectors at: http://common-lisp.net/project/clbuild/mirror/ironclad/test-vectors/tiger.testvec the test vectors in http://www.hotpixel.net/TigerNET102.zip also agree with these other implementations (and disagree with gcrypt), as do the test vectors in http://org.rodage.com/pub/java/security/TigerTest.java and the wider consensus '' test vector is again corroborated here: http://www.febooti.com/products/filetweak/members/hash-and-crc/test-vectors/ I've yet to find another Tiger implementation with the same test vectors as gcrypt's test vectors. Is gcrypt's implementation of Tiger trying to implement a different algorithm than these other implementations or is there a bug somewhere? Or have i misunderstood something? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Nov 13 08:58:41 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Nov 2009 02:58:41 -0500 Subject: docs for gcry_mpi_aprint should indicate how to release buffer Message-ID: <4AFD11B1.5030109@fifthhorseman.net> hey folks-- more gcrypt documentation nit-picking: the docs for gcrypt_mpi_aprint() say: > Convert the MPI a into an external representation described by format > (see above) and store it in a newly allocated buffer which address will > be stored in the variable buffer points to. The number of bytes stored > in this buffer will be stored in the variable nbytes points to, unless > nbytes is NULL. I'd assume that buffer must later be released by the caller with gcry_free(), but the docs don't say so explicitly. perhaps they should? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun Nov 15 20:14:22 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 15 Nov 2009 14:14:22 -0500 Subject: GCRYMPI_FMT_SSH documentation touchup Message-ID: <4B00530E.8040704@fifthhorseman.net> hey folks-- the documentation about the GCRYMPI_FMT_SSH doesn't explicitly say what the header is. if it's a length header (i believe it is), the attached patch should touch up the documentation. thanks, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: mpi-ssh-format-doc-touchup.patch Type: text/x-diff Size: 451 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Nov 19 21:58:54 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Nov 2009 15:58:54 -0500 Subject: more gcrypt documentation updates Message-ID: <4B05B18E.8040405@fifthhorseman.net> hey gcrypt folks-- i noticed that the following three functions aren't documented in gcrypt.texi: gcry_cipher_get_algo_blklen gcry_cipher_get_algo_keylen gcry_cipher_test_algo The attached patch should add documentation for them. Thanks, --dkg PS this is the third simple documentation patch i've submitted to gcrypt on this mailing list. While i doubt that any of these patches are seriously objectionable, none of them have been applied to svn that i can see, and i've gotten no feedback here. if i'm doing something wrong, or i should be submitting these patches elsewhere, please let me know. -------------- next part -------------- A non-text attachment was scrubbed... Name: document-cipher-info-functions.patch Type: text/x-diff Size: 1050 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Nov 19 22:32:11 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Nov 2009 16:32:11 -0500 Subject: another minor gcrypt documentation patch Message-ID: <4B05B95B.3000307@fifthhorseman.net> it looks like the documentation for gcry_cipher_encrypt says "or" where it means "of". the attached patch should restore the intended meaning. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-encrypt-doc.patch Type: text/x-diff Size: 753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun Nov 29 05:33:43 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 28 Nov 2009 23:33:43 -0500 Subject: should HMAC digests require secure memory? Message-ID: <4B11F9A7.7000104@fifthhorseman.net> Hi gcrypt folks-- it looks to me like cipher/md.c:487 effectively requires secure memory for HMAC-enabled digest objects, whether or not GCRY_MD_FLAG_SECURE was set. This is a surprising behavior, since (at least in versions before 1.4.3), it can lead to an "Ohhhh jeeee: operation is not possible without initialized secure memory" error message, followed by the process being aborted. Since version 1.4.3 (according to NEWS) this appears to be worked around by auto-allocating 32K secure memory if the library isn't otherwise initialized. I note that in the older gcrypt versions vulnerable to this failure, an explicit call to gcry_control(GCRYCTL_DISABLE_SECMEM) before creating the HMAC-enabled will avoid the failure. I wonder if modern libraries are still subject to this failure if they're run by users unable to allocate secure memory (and thus the default allocation of 32K of secmem would fail). i don't have such a system handy to try. Why are ctx->maxpads allocated securely, even if GCRY_MD_FLAG_SECURE is not set? It seems to me like this should be normalized in one of the following ways: 0) documentation for gcry_md_open should note that secure memory is used when GCRY_MD_FLAG_HMAC is used, regardless of GCRY_MD_FLAG_SECURE. 1) allocation of ctx->maxpads in md_open() should allocate secure or normal memory based on the "secure" argument to that function. Are there other ways this behavior could be made less surprising? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun Nov 29 06:13:45 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 29 Nov 2009 00:13:45 -0500 Subject: which MPI calculations allow the output argument to be identical to the the input arguments? Message-ID: <4B120309.1000103@fifthhorseman.net> Hi GCrypt folks-- The patch below adjusts a comment about MPI arithmetic to make more sense (it doesn't mean anything to suggest that an unsigned long might be the same as an MPI object, right?) Is there a general agreement that gcrypt MPI calculation functions allow their target value (w) to be the same as any of their other arguments? are there certain calculation operations where that does not hold? This would be useful information to include in the header of the Calculations section of gcrypt.texi. --dkg Index: mpi-add.c =================================================================== --- mpi-add.c (revision 1406) +++ mpi-add.c (working copy) @@ -33,7 +33,7 @@ /**************** * Add the unsigned integer V to the mpi-integer U and store the - * result in W. U and V may be the same. + * result in W. U and W may be the same. */ void gcry_mpi_add_ui(gcry_mpi_t w, gcry_mpi_t u, unsigned long v ) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: