From wk at gnupg.org Tue Jun 2 10:55:24 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Jun 2009 10:55:24 +0200 Subject: format of encrypted data in sexpr In-Reply-To: <20090528204230.GA6488@varese> (Orm Finnendahl's message of "Thu, 28 May 2009 22:42:30 +0200") References: <20090528204230.GA6488@varese> Message-ID: <87ab4r816r.fsf@wheatstone.g10code.de> On Thu, 28 May 2009 22:42, o.finnendahl at mh-freiburg.de said: > The gcry_sexp_sprint function below sometimes returns a hex string > (enclosed with hashmarks) and sometimes a string (enclosed in double > quotes) in some random order for reasons not immediately obvious to > me. That is just a human readable format which uses a heuristic to decide how to print it out. See libgcrypt/src/sexp.c:suitable_encoding . For machine based parsing it is way easier to use the canonical S-expression format; see http://people.csail.mit.edu/rivest/sexp.html for details on S-expressions. > gcry_sexp_sprint (decr, GCRYSEXP_FMT_ADVANCED, Use GCRYSEXP_FMT_CANON . gnupg/common/sexp-parse.h has fucntions to parse a canonical encoded S-expression. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bradh at frogmouth.net Mon Jun 8 03:13:36 2009 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 8 Jun 2009 11:13:36 +1000 Subject: [patch] Make cipher benchmark tests easier to read Message-ID: <200906081113.37374.bradh@frogmouth.net> Hi, Currently the benchmark code lays things out like this (best viewed in a fixed width font, without wrapping...) ECB CBC CFB OFB CTR STREAM --------------- --------------- --------------- --------------- --------------- --------------- 3DES 70ms 70ms 70ms 70ms 80ms 70ms 70ms 70ms 110ms 110ms CAST5 30ms 30ms 30ms 30ms 30ms 30ms 30ms 30ms 70ms 70ms BLOWFISH 20ms 30ms 30ms 30ms 30ms 30ms 20ms 20ms 70ms 70ms AES 30ms 30ms 20ms 30ms 20ms 20ms 30ms 30ms 60ms 70ms AES192 30ms 40ms 20ms 30ms 30ms 20ms 40ms 30ms 70ms 70ms AES256 40ms 40ms 30ms 30ms 30ms 30ms 30ms 40ms 70ms 80ms TWOFISH 10ms 20ms 20ms 20ms 20ms 20ms 20ms 20ms 50ms 60ms ARCFOUR 10ms 10ms DES 40ms 30ms 40ms 40ms 40ms 30ms 40ms 40ms 80ms 80ms TWOFISH128 10ms 20ms 20ms 20ms 20ms 20ms 20ms 20ms 50ms 60ms SERPENT128 30ms 20ms 30ms 30ms 30ms 30ms 30ms 30ms 60ms 70ms SERPENT192 30ms 20ms 30ms 30ms 30ms 30ms 30ms 30ms 70ms 60ms SERPENT256 30ms 30ms 30ms 30ms 30ms 30ms 20ms 40ms 60ms 70ms RFC2268_40 30ms 20ms 30ms 20ms 30ms 30ms 30ms 30ms 70ms 70ms SEED 30ms 20ms 30ms 30ms 30ms 30ms 20ms 30ms 70ms 60ms CAMELLIA128 60ms 50ms 60ms 50ms 60ms 50ms 60ms 60ms 90ms 90ms CAMELLIA192 60ms 60ms 60ms 60ms 60ms 60ms 60ms 60ms 100ms 90ms CAMELLIA256 60ms 60ms 60ms 60ms 60ms 60ms 60ms 60ms 100ms 90ms I think that is a bit hard to read - it would be better if the mode label was centred over the encrypt and decrypt time columns, like: ECB CBC CFB OFB CTR STREAM --------------- --------------- --------------- --------------- --------------- --------------- 3DES 70ms 70ms 70ms 70ms 70ms 70ms 70ms 70ms 110ms 110ms CAST5 30ms 30ms 30ms 30ms 30ms 30ms 30ms 30ms 70ms 70ms BLOWFISH 30ms 20ms 30ms 30ms 30ms 30ms 30ms 20ms 70ms 70ms AES 30ms 30ms 20ms 30ms 20ms 20ms 30ms 30ms 60ms 70ms AES192 30ms 40ms 20ms 40ms 20ms 30ms 30ms 30ms 70ms 70ms AES256 40ms 40ms 30ms 30ms 30ms 30ms 40ms 30ms 80ms 70ms TWOFISH 20ms 20ms 20ms 20ms 10ms 20ms 20ms 20ms 60ms 50ms ARCFOUR 20ms 10ms DES 30ms 40ms 40ms 40ms 40ms 30ms 40ms 40ms 80ms 80ms TWOFISH128 20ms 20ms 20ms 20ms 20ms 10ms 20ms 20ms 60ms 60ms SERPENT128 20ms 30ms 30ms 30ms 30ms 20ms 30ms 30ms 70ms 70ms SERPENT192 30ms 20ms 30ms 30ms 30ms 30ms 30ms 30ms 60ms 70ms SERPENT256 30ms 20ms 30ms 30ms 30ms 30ms 30ms 30ms 70ms 60ms RFC2268_40 30ms 20ms 30ms 30ms 30ms 20ms 30ms 30ms 70ms 70ms SEED 30ms 30ms 30ms 20ms 30ms 30ms 30ms 30ms 60ms 70ms CAMELLIA128 50ms 50ms 60ms 60ms 50ms 60ms 50ms 60ms 90ms 100ms CAMELLIA192 50ms 60ms 60ms 60ms 60ms 60ms 60ms 60ms 100ms 90ms CAMELLIA256 60ms 60ms 60ms 60ms 60ms 60ms 60ms 60ms 100ms 90ms Trivial patch is attached. I considered adding some code that would automatically line it up, but that seemed excessively complicated for this. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: benchmark-prettify-2009-06-08.patch Type: text/x-diff Size: 889 bytes Desc: not available URL: From wk at gnupg.org Mon Jun 8 09:02:07 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Jun 2009 09:02:07 +0200 Subject: [patch] Make cipher benchmark tests easier to read In-Reply-To: <200906081113.37374.bradh@frogmouth.net> (Brad Hards's message of "Mon, 8 Jun 2009 11:13:36 +1000") References: <200906081113.37374.bradh@frogmouth.net> Message-ID: <87ab4j9pjk.fsf@wheatstone.g10code.de> On Mon, 8 Jun 2009 03:13, bradh at frogmouth.net said: > I think that is a bit hard to read - it would be better if > the mode label was centred over the encrypt and decrypt > time columns, like: Thanks. I changed my working copy. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bradh at frogmouth.net Mon Jun 8 13:00:25 2009 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 8 Jun 2009 21:00:25 +1000 Subject: [patch] Add tests for NIST CAVP hash tests Message-ID: <200906082100.25887.bradh@frogmouth.net> Hi, The attached patch adds a test generator (in python) that uses the NIST CAVP Secure Hash Standard (SHA1, SHA2) test cases. The tests are 2.7M (zipped) and look like Len = 48 Msg = e47571e5022e MD = 8ce051181f0ed5e9d0c498f6bc4caf448d20deb5 Len = 56 Msg = 3e1b28839fb758 MD = 67da53837d89e03bf652ef09c369a3415937cfd3 The generated test is 9.7M, which I think is too large to put into svn. So I've added some buildsystem support and the generator script so the really dedicated user can run the tests if required. I've also added a short README to explain it. This change also reworks basic.c to extract some shared code, and the buildsystem changes cover that. Thoughts? Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: cavp-hashtests-2009-06-08.patch Type: text/x-diff Size: 13649 bytes Desc: not available URL: From wk at gnupg.org Mon Jun 8 19:30:02 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Jun 2009 19:30:02 +0200 Subject: [patch] Add tests for NIST CAVP hash tests In-Reply-To: <200906082100.25887.bradh@frogmouth.net> (Brad Hards's message of "Mon, 8 Jun 2009 21:00:25 +1000") References: <200906082100.25887.bradh@frogmouth.net> Message-ID: <878wk23a79.fsf@wheatstone.g10code.de> On Mon, 8 Jun 2009 13:00, bradh at frogmouth.net said: > The attached patch adds a test generator (in python) that uses the NIST CAVP > Secure Hash Standard (SHA1, SHA2) test cases. The tests are 2.7M (zipped) and Hmmm, did you missed that we have a full CAVS test suite in Libgcrypt? Libgcrypt 1.4.4 actually passed the entire test suite (hash, cipher pubkey random). If you look at the NIST database you will find an entry for Libgcrypt. The driver script tests/cavs_test.sh has instructions on how to run the test. As input you need the REQ files and it will generate and zip the RSP files. The interface between the script and libgcrypt is tests/fipsdrv.c . A script to generate the input data and another one to check the response might be useful, however we can also use a fixed set of files and put them on ftp.gnupg.org. I can check whether the set I use can be made public. What is missing is the code to check the response. BTW, I'd like to avoid yet another script language because we already have AWK (which is POSIX) and Perl. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bradh at frogmouth.net Tue Jun 9 11:45:39 2009 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 9 Jun 2009 19:45:39 +1000 Subject: [patch] Add tests for NIST CAVP hash tests In-Reply-To: <878wk23a79.fsf@wheatstone.g10code.de> References: <200906082100.25887.bradh@frogmouth.net> <878wk23a79.fsf@wheatstone.g10code.de> Message-ID: <200906091945.40464.bradh@frogmouth.net> On Tuesday 09 June 2009 03:30:02 am Werner Koch wrote: > On Mon, 8 Jun 2009 13:00, bradh at frogmouth.net said: > > The attached patch adds a test generator (in python) that uses the NIST > > CAVP Secure Hash Standard (SHA1, SHA2) test cases. The tests are 2.7M > > (zipped) and > > Hmmm, did you missed that we have a full CAVS test suite in Libgcrypt? No. > The driver script tests/cavs_test.sh has instructions on how to run the > test. As input you need the REQ files and it will generate and zip the > RSP files. The interface between the script and libgcrypt is > tests/fipsdrv.c . I see these activities as complementary. The tests/cavs_test.sh (and associated driver code) are for running a CAVS test (i.e. producing a .resp from a .req). The python code I submitted is when you don't have such a .req. It checks the samples provided by NIST. > A script to generate the input data and another one to check > the response might be useful, however we can also use a fixed set of > files and put them on ftp.gnupg.org. I can check whether the set I use > can be made public. What is missing is the code to check the response. I agree, except you don't need to provide them on ftp.gnupg.org - they are already available from NIST. The generator script makes an application that creates a set of requests and responses - I just encode them in C structures rather than have to write them out and parse them back in. > BTW, I'd like to avoid yet another script language because we already > have AWK (which is POSIX) and Perl. I can appreciate that. Unfortunately I don't know either :-( If I had a set of test vectors to use (e.g. if you could share the test vectors from NIST CST that you got, even if they aren't made totally public) perhaps I could rewrite the test driver. That could also eliminate the need for unpacking the tests in the correct directory structure, and also the need for the zip utility. Note that the goal here isn't really hashing. That was just something I did to de-risk a possible future implementation (where I don't have tests or implementation) - GCM. Brad Brad From simon at josefsson.org Tue Jun 16 10:47:12 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Jun 2009 10:47:12 +0200 Subject: Use of libgcrypt in libc? Message-ID: <878wjsimzz.fsf@mocca.josefsson.org> Hi! I have noticed this work in libc to use NSS for crypto: http://sourceware.org/git/?p=glibc.git;a=commit;h=ff886b82a2b65758950bdb4687cf5a1238f697a1 I wanted to look into providing a patch to use libgcrypt. The patch is relatively straight forward to produce, but I have run into a problem with libgcrypt initialization. I have read http://www.gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html and it suggests to recommend solution is that applications initialize libgcrypt, which I don't see how it would work in glibc. If libc initialize libgcrypt without secure memory, it seems that potentially applications may end up with libgcrypt in that mode too, which appears sub-optimal. Is it possible to use libgcrypt safely in libc? How? /Simon From ueno at unixuser.org Tue Jun 30 05:53:21 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 30 Jun 2009 12:53:21 +0900 Subject: [PATCH] OAEP support Message-ID: <87iqiecr7y.fsf@broken.deisui.org> Hi, The attached patch adds OAEP padding support to libgcrypt. Here are some notes: - Before encryption/decryption, it reads necessary parameters from `flags'. For example, (data (flags oaep hash sha1 label "test") (value #11223344556677889900AA#)) for encryption and, (enc-data (flags oaep hash sha1 label "test") ...) for decryption. - After decryption, it stores the decoded value as a `decoded' token instead of `value', unlike other encodings (`raw' and `pkcs1'). This is for backward compatibility. For example, (decoded #11223344556677889900AA#) -------------- next part -------------- A non-text attachment was scrubbed... Name: oaep.diff Type: text/x-diff Size: 24992 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From wk at gnupg.org Tue Jun 30 12:34:09 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2009 12:34:09 +0200 Subject: [PATCH] OAEP support In-Reply-To: <87iqiecr7y.fsf@broken.deisui.org> (Daiki Ueno's message of "Tue, 30 Jun 2009 12:53:21 +0900") References: <87iqiecr7y.fsf@broken.deisui.org> Message-ID: <87zlbqc8ny.fsf@wheatstone.g10code.de> On Tue, 30 Jun 2009 05:53, ueno at unixuser.org said: > The attached patch adds OAEP padding support to libgcrypt. Thanks. > - Before encryption/decryption, it reads necessary parameters from > `flags'. For example, > > (data > (flags oaep hash sha1 label "test") > (value #11223344556677889900AA#)) I would like to keep the flags list a real flags list without parameters. Would anything speak against: (data (flags oaep) (hash sha1) (label "test") (value #11223344556677889900AA#)) I can do this change if you agree. > - After decryption, it stores the decoded value as a `decoded' token > instead of `value', unlike other encodings (`raw' and `pkcs1'). This > is for backward compatibility. For example, > > (decoded #11223344556677889900AA#) That is so that the caller can easily see whether OAEP has been used and that the code needs to be adjusted, right? I'll look closer at the patch in the next days. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Jun 30 12:41:48 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2009 12:41:48 +0200 Subject: Use of libgcrypt in libc? In-Reply-To: <878wjsimzz.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 16 Jun 2009 10:47:12 +0200") References: <878wjsimzz.fsf@mocca.josefsson.org> Message-ID: <87vdmec8b7.fsf@wheatstone.g10code.de> On Tue, 16 Jun 2009 10:47, simon at josefsson.org said: > and it suggests to recommend solution is that applications initialize > libgcrypt, which I don't see how it would work in glibc. We would need to address a couple of problems. Of course glibc could do the initialization but only in a standard way without too much secure memory or with disabled secure memory. That would lead to problems with applications requiring a different memory allocator and definitely with FIPS mode. The best solution I can think about are a modified memory allocator in glibc to allow setting flags on allocated memory blocks. With such a feature custom handlers could be invoked from the standard free or malloc and do whatever they want (i.e clear out that memory or mlock it). Not an easy change though. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.