From bradh at frogmouth.net Thu Apr 1 13:15:57 2010 From: bradh at frogmouth.net (Brad Hards) Date: Thu, 1 Apr 2010 22:15:57 +1100 Subject: [patch] Fix a couple of manual typos Message-ID: <201004012215.57587.bradh@frogmouth.net> "library" had a typo in a couple of places Please apply. Brad Index: gcrypt.texi =================================================================== --- gcrypt.texi (revision 1425) +++ gcrypt.texi (working copy) @@ -748,7 +748,7 @@ do this basic intialization is by calling gcry_check_version. @item GCRYCTL_INITIALIZATION_FINISHED; Arguments: none -This command tells the libray that the application has finished the +This command tells the library that the application has finished the intialization. @item GCRYCTL_INITIALIZATION_FINISHED_P; Arguments: none @@ -5464,7 +5464,7 @@ context is saved in the context and another block is generated to be returned to the caller. Each block is compared against the saved block and then stored in the context. If a duplicated block is -detected an error is signaled and the libray is put into the +detected an error is signaled and the library is put into the ``Fatal-Error'' state. (@code{random/@/random-fips.c:@/x931_aes_driver}) From bradh at frogmouth.net Sun Apr 4 04:07:01 2010 From: bradh at frogmouth.net (Brad Hards) Date: Sun, 4 Apr 2010 12:07:01 +1000 Subject: [patch] Fix typos in tests Message-ID: <201004041207.01638.bradh@frogmouth.net> While working on something else, I noted a few typos in the tests. Patch to fix is attached. Please apply. aeswrap.c | 12 ++++++------ basic.c | 20 ++++++++++---------- hmac.c | 6 +++--- 3 files changed, 19 insertions(+), 19 deletions(-) Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: grcy-typos-2010-04-04.patch Type: text/x-patch Size: 5637 bytes Desc: not available URL: From bradh at frogmouth.net Sun Apr 4 11:42:09 2010 From: bradh at frogmouth.net (Brad Hards) Date: Sun, 4 Apr 2010 19:42:09 +1000 Subject: Thoughts on implementing GCM Message-ID: <201004041942.10348.bradh@frogmouth.net> Hi, I've started looking (again) at NIST 800-38D (Galois Counter Mode). I have a couple of implementation questions that I'd appreciate some feedback on. There would appear to be several ways to implement an AEAD, including a whole new API (i.e. a peer to the existing cipher, md, etc). However I think it should be possible to implement it within the existing cipher code with a couple of additional functions - one that adds the additional authenticated data (A) and one that retrieves the authentication tag (T). Thoughts on this approach? I think I may also need to extend struct gcry_cipher_handle. I'd like to store the hash subkey (H) - not far enough into the implementation to know if I need anything else. Would a union re-using the ctr[MAX_BLOCKSIZE] space be preferred, or should I just add new elements? Thanks for your time. Brad From wk at gnupg.org Tue Apr 6 10:59:31 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Apr 2010 10:59:31 +0200 Subject: Thoughts on implementing GCM In-Reply-To: <201004041942.10348.bradh@frogmouth.net> (Brad Hards's message of "Sun, 4 Apr 2010 19:42:09 +1000") References: <201004041942.10348.bradh@frogmouth.net> Message-ID: <877holrm6k.fsf@vigenere.g10code.de> On Sun, 4 Apr 2010 11:42, bradh at frogmouth.net said: > new API (i.e. a peer to the existing cipher, md, etc). However I think it > should be possible to implement it within the existing cipher code with a > couple of additional functions - one that adds the additional authenticated > data (A) and one that retrieves the authentication tag (T). Thoughts on this > approach? That is how I would do it. > I think I may also need to extend struct gcry_cipher_handle. I'd like to store > the hash subkey (H) - not far enough into the implementation to know if I need > anything else. Would a union re-using the ctr[MAX_BLOCKSIZE] space be > preferred, or should I just add new elements? For easier readability I think it might be better to add new elements. Merging them with unused elements can be done at any time later. Please don't change gcry_cipher_spec_t but change cipher_extra_spec_t instead - if you need to do that at all. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bradh at frogmouth.net Sun Apr 11 02:18:01 2010 From: bradh at frogmouth.net (Brad Hards) Date: Sun, 11 Apr 2010 10:18:01 +1000 Subject: [patch] Minor test code (basic --verbose) update Message-ID: <201004111018.01878.bradh@frogmouth.net> Hi, Currently when running basic --verbose, the output looks like: [bradh-dev at repens tests]$ ./basic --verbose Starting Cipher checks. checking BLOWFISH [4] checking DES [302] checking 3DES [2] checking CAST5 [3] checking AES [7] checking AES192 [8] checking AES256 [9] (some more ciphers listed here) checking `ARCFOUR' Completed Cipher checks. Starting AES128 CBC CTS checks. checking encryption for length 17 checking decryption for length 17 checking encryption for length 31 checking decryption for length 31 checking encryption for length 32 checking decryption for length 32 checking encryption for length 47 checking decryption for length 47 checking encryption for length 48 checking decryption for length 48 checking encryption for length 64 checking decryption for length 64 Completed AES128 CBC CTS checks. Starting CBC MAC checks. checking CBC MAC for AES [7] checking CBC MAC for 3DES [2] checking CBC MAC for DES [302] Completed CBC MAC checks. Starting CTR cipher checks. checking CTR mode for AES [7] checking CTR mode for AES192 [8] checking CTR mode for AES256 [9] Completed CTR cipher checks. Starting hash checks. and so on. The "problem" is that we're not outputting anything about OFB or CFB tests. Attached is a minor patch that groups the various "cipher mode" checks, and adds some verbosity for OFB and CFB. Please apply. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-verbose-output-for-cipher-modes.patch Type: text/x-patch Size: 5694 bytes Desc: not available URL: From bradh at frogmouth.net Sun Apr 11 12:26:02 2010 From: bradh at frogmouth.net (Brad Hards) Date: Sun, 11 Apr 2010 20:26:02 +1000 Subject: [patch] spelling fixes Message-ID: <201004112026.02654.bradh@frogmouth.net> The attached patch fixes a few spelling issues, almost all in comments. Please apply. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: spelling-fixes-2010-04-11.patch Type: text/x-patch Size: 27500 bytes Desc: not available URL: From wk at gnupg.org Mon Apr 12 21:23:44 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Apr 2010 21:23:44 +0200 Subject: [patch] Minor test code (basic --verbose) update In-Reply-To: <201004111018.01878.bradh@frogmouth.net> (Brad Hards's message of "Sun, 11 Apr 2010 10:18:01 +1000") References: <201004111018.01878.bradh@frogmouth.net> Message-ID: <87sk70mq4f.fsf@vigenere.g10code.de> On Sun, 11 Apr 2010 02:18, bradh at frogmouth.net said: > Attached is a minor patch that groups the various "cipher mode" checks, and > adds some verbosity for OFB and CFB. > > Please apply. Done. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Apr 12 21:24:59 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Apr 2010 21:24:59 +0200 Subject: [patch] spelling fixes In-Reply-To: <201004112026.02654.bradh@frogmouth.net> (Brad Hards's message of "Sun, 11 Apr 2010 20:26:02 +1000") References: <201004112026.02654.bradh@frogmouth.net> Message-ID: <87ochomq2c.fsf@vigenere.g10code.de> On Sun, 11 Apr 2010 12:26, bradh at frogmouth.net said: > Please apply. Done. Except for -online: gcrypt.html gcrypt.pdf gcrypt.info +online: gcrypt.html gcrypt.pdf The "online" target is intended only for the maintainer and thus we can assume that all special tools are available. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bradh at frogmouth.net Mon Apr 12 22:33:55 2010 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 13 Apr 2010 06:33:55 +1000 Subject: [patch] spelling fixes In-Reply-To: <87ochomq2c.fsf@vigenere.g10code.de> References: <201004112026.02654.bradh@frogmouth.net> <87ochomq2c.fsf@vigenere.g10code.de> Message-ID: <201004130633.55415.bradh@frogmouth.net> On Tuesday 13 April 2010 05:24:59 am Werner Koch wrote: > On Sun, 11 Apr 2010 12:26, bradh at frogmouth.net said: > > Please apply. > > Done. Except for > > -online: gcrypt.html gcrypt.pdf gcrypt.info > +online: gcrypt.html gcrypt.pdf Oops. That wasn't meant to be in there. I have a buggy makeinfo (segfaults), and so disabled that locally. My apologies. Brad From hyc at highlandsun.com Fri Apr 16 18:11:39 2010 From: hyc at highlandsun.com (Howard Chu) Date: Fri, 16 Apr 2010 09:11:39 -0700 Subject: bug tracker? arcfour problem Message-ID: <4BC88C3B.9020004@highlandsun.com> I looked all over this page http://directory.fsf.org/project/libgcrypt/ and www.gnupg.org and didn't find a relevant link, so my apologies if this is the wrong place. I've adapted rtmpdump's librtmp to use either OpenSSL or gcrypt/gnutls for its crypto support and initially it seemed that everything was fine. However, when built with gnutls/gcrypt, I see problems in the resulting data that generally only crop up after ~51MB or more has been transferred in a single rtmpe session. It kind of implies there's a problem with the arcfour cipher, but I frankly can't imagine what kind of bug could exist in such a simple cipher code, which only manifests after so much data has been successfully transferred. Has anyone else ever reported this kind of issue? Running on an Ubuntu 10 (Lucid) beta x86-64, gcrypt 1.4.4, gnutls 2.8.5. The relevant code can be obtained from http://rtmpdump.mplayerhq.hu.