From cvs at cvs.gnupg.org  Mon Sep  1 11:40:22 2014
From: cvs at cvs.gnupg.org (by Werner Koch)
Date: Mon, 01 Sep 2014 11:40:22 +0200
Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-110-g708a3a7
Message-ID: <E1XOO3v-0001q0-5i@lists.gnupg.org>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The GNU crypto library".

The branch, master has been updated
       via  708a3a72cc0608ed4a38ff78d8843c1b46ebf633 (commit)
      from  db3c0286bf159568aa315d15f9708fe2de02b022 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 708a3a72cc0608ed4a38ff78d8843c1b46ebf633
Author: Werner Koch <wk at gnupg.org>
Date:   Mon Sep 1 11:40:31 2014 +0200

    Add DCO entries for Andrei Scherer and Stefan Mueller.
    
    --

diff --git a/AUTHORS b/AUTHORS
index 2c92998..860dea2 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -136,6 +136,9 @@ phcoder at gmail.com
 Authors with a DCO
 ==================
 
+Andrei Scherer <andsch at inbox.com>
+2014-0822:BF7CEF794F9.000003F0andsch at inbox.com:
+
 Christian Aistleitner <christian at quelltextlich.at>
 2013-02-26:20130226110144.GA12678 at quelltextlich.at:
 
@@ -163,6 +166,9 @@ Rafa?l Carr? <funman at videolan.org>
 Sergey V. <sftp.mtuci at gmail.com>
 2013-11-07:2066221.5IYa7Yq760 at darkstar:
 
+Stephan Mueller <smueller at chronox.de>
+2014-08-22:2008899.25OeoelVVA at myon.chronox.de:
+
 Tom?? Mr?z <tm at t8m.info>
 2012-04-16:1334571250.5056.52.camel at vespa.frost.loc:
 

-----------------------------------------------------------------------

Summary of changes:
 AUTHORS |    6 ++++++
 1 file changed, 6 insertions(+)


hooks/post-receive
-- 
The GNU crypto library
http://git.gnupg.org


_______________________________________________
Gnupg-commits mailing list
Gnupg-commits at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-commits

From dbaryshkov at gmail.com  Mon Sep  1 14:23:54 2014
From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov)
Date: Mon, 1 Sep 2014 16:23:54 +0400
Subject: Cipher FIPS flag enforcement
In-Reply-To: <87lhqc1ucz.fsf@vigenere.g10code.de>
References: <1926944.R0LCOrcss8@tauon>
	<87lhqc1ucz.fsf@vigenere.g10code.de>
Message-ID: <CALT56yMRh5YMUFeEc+bkcabd0D=fSPbDHzz-8o60LF25Kmu0EQ@mail.gmail.com>

On Mon, Aug 25, 2014 at 7:06 PM, Werner Koch <wk at gnupg.org> wrote:
> On Mon, 25 Aug 2014 12:37, smueller at chronox.de said:
>
>> The random/ code still contains such logic. But all other fips flag
>> enforcement code is gone.
>
> That was due to the major revamp of the code.  I did not care about
> keeping the FIPS functionality.  I was anyway not able to check the
> functionality and thus I concluded that those companies planning to sell
> FIPS stuff should contact me or send a proper patch which I can apply
> without spending a lot of unpaid time.

Should we just drop that part of the code?



-- 
With best wishes
Dmitry


From jussi.kivilinna at iki.fi  Mon Sep  1 17:47:26 2014
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Mon, 01 Sep 2014 18:47:26 +0300
Subject: [PATCH 1/1] Improved whirlpool hash performance
In-Reply-To: <0BE490E19CE.00000F69andsch@inbox.com>
References: <0BE490E19CE.00000F69andsch@inbox.com>
Message-ID: <5404950E.50509@iki.fi>

On 28/08/14 21:02, And Sch wrote:
> * cipher/whirlpool.c (whirlpool_transform, sbox, added macro): Added macro and rearranged round function to alternate between reading to and writing from different state and key variables. Two whirlpool_context_t variables removed, two were replaced, the sizes of state and key doubled, so overall the burn stack stays the same. buffer_to_block and block_xor were combined into one operation. The sbox was converted to one large table, because it is faster than many small tables.

Changelog lines should be maximum of 72 characters in length.

> --
> 
> Benchmark on different systems:
> 
<snip>
> ---
> 
> diff -ruNp libgcrypt-1.6.2/cipher/whirlpool.c libgcrypt-1.6.3/cipher/whirlpool.c
> --- libgcrypt-1.6.2/cipher/whirlpool.c	2014-08-21 07:50:39.000000000 -0500
> +++ libgcrypt-1.6.3/cipher/whirlpool.c	2014-08-28 12:47:04.917824140 -0500

Are these patches against the latest development branch?

> @@ -87,6 +87,17 @@ typedef struct {
>    for (i = 0; i < 8; i++) \
>      block_dst[i] ^= block_src[i];
>  
> +/* XOR lookup boxes with index SRC [(SHIFT + n) & 7] >> x. */
> +#define WHIRLPOOL_XOR(src, shift) \
> +	C[((unsigned int)(src[ (shift)         ] >> 56)       )          ] ^ \
> +	C[((unsigned int)(src[((shift) + 7) & 7] >> 48) & 0xff) +  256   ] ^ \
> +	C[((unsigned int)(src[((shift) + 6) & 7] >> 40) & 0xff) + (256*2)] ^ \
> +	C[((unsigned int)(src[((shift) + 5) & 7] >> 32) & 0xff) + (256*3)] ^ \
> +	C[((unsigned int)(src[((shift) + 4) & 7] >> 24) & 0xff) + (256*4)] ^ \
> +	C[((unsigned int)(src[((shift) + 3) & 7] >> 16) & 0xff) + (256*5)] ^ \
> +	C[((unsigned int)(src[((shift) + 2) & 7] >>  8) & 0xff) + (256*6)] ^ \
> +	C[((unsigned int)(src[((shift) + 1) & 7]      ) & 0xff) + (256*7)] \
> +
>  ?
>  
>  /* Round constants.  */
> @@ -107,7 +118,7 @@ static const u64 rc[R] =
>  ?
>  
>  /* Main lookup boxes.  */
> -static const u64 C0[256] =
> +static const u64 C[8*256] =

Maybe make this 'static const u64 C[8][256] instead?  Macro above would be slightly clearer

>    {
>      U64_C (0x18186018c07830d8), U64_C (0x23238c2305af4626),
>      U64_C (0xc6c63fc67ef991b8), U64_C (0xe8e887e8136fcdfb),
> @@ -237,10 +248,7 @@ static const u64 C0[256] =
<snip>
> -  block_xor (context->hash_state, data_block, i);
> -  block_xor (context->hash_state, state, i);
> +  block_xor (context->hash_state, state[0], i);
>  
>    return /*burn_stack*/ 4 * sizeof(whirlpool_block_t) + 2 * sizeof(int) +
>                          4 * sizeof(void*);
> 
> ____________________________________________________________
> FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
> Visit http://www.inbox.com/photosharing to find out more!
> 

Please check settings in your email application. It's currently mangling these patches so that they do not apply without some extra work.

-Jussi



From wk at gnupg.org  Mon Sep  1 18:06:48 2014
From: wk at gnupg.org (Werner Koch)
Date: Mon, 01 Sep 2014 18:06:48 +0200
Subject: Cipher FIPS flag enforcement
In-Reply-To: <CALT56yMRh5YMUFeEc+bkcabd0D=fSPbDHzz-8o60LF25Kmu0EQ@mail.gmail.com>
 (Dmitry Eremin-Solenikov's message of "Mon, 1 Sep 2014 16:23:54
 +0400")
References: <1926944.R0LCOrcss8@tauon> <87lhqc1ucz.fsf@vigenere.g10code.de>
 <CALT56yMRh5YMUFeEc+bkcabd0D=fSPbDHzz-8o60LF25Kmu0EQ@mail.gmail.com>
Message-ID: <874mwrnx47.fsf@vigenere.g10code.de>

On Mon,  1 Sep 2014 14:23, dbaryshkov at gmail.com said:

> Should we just drop that part of the code?

Better add a comment that the fips flag is currently not used.  Removing
it does not save a single byte.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From jussi.kivilinna at iki.fi  Mon Sep  1 18:15:03 2014
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Mon, 01 Sep 2014 19:15:03 +0300
Subject: [PATCH 1/1] whirlpool hash amd64 assembly
In-Reply-To: <1745308C116.00000937andsch@inbox.com>
References: <1745308C116.00000937andsch@inbox.com>
Message-ID: <54049B87.2070001@iki.fi>

On 29/08/14 18:45, And Sch wrote:
<snip>
> 
> That is more than twice as fast as the original on the Atom system.
> 
> I tried to find a way to use macros to sort out parts of the loop, but any change in the order of the instructions slows it down a lot. There are also only 7 registers available at one time in most parts of the loop, so that makes macros and rearrangements even more difficult.
> 
> I used a little endian version of the last patch I posted and gcc -funroll-loops to generate this assembly. I've looked through it and tried to organize it as best I can. Suggestions on how to clean it up further would be helpful.
> 

I don't agree that this is good method for creating assembly implementations. As I see it, the main point with assembly implementations is that you can do optimizations that compiler has no way of finding. For example, you could load indexes to rax/rbx/rcx/rdx registers that allow extracting not only first index byte but also second byte with just one instruction. Or, use XMM registers to store the key[] and state[] arrays instead of stack.

Well, I ended up making such implementation, which I've attached. On Intel i5-4570 (3.6 Ghz turbo), I get:

> tests/bench-slope --cpu-mhz 3600 hash whirlpool
Hash:
                |  nanosecs/byte   mebibytes/sec   cycles/byte
 WHIRLPOOL      |      4.28 ns/B     222.7 MiB/s     15.42 c/B

-Jussi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01-whirl-amd64-asm.patch
Type: text/x-patch
Size: 15806 bytes
Desc: not available
URL: </pipermail/attachments/20140901/b0af8943/attachment-0001.bin>

From cvs at cvs.gnupg.org  Tue Sep  2 09:26:20 2014
From: cvs at cvs.gnupg.org (by Werner Koch)
Date: Tue, 02 Sep 2014 09:26:20 +0200
Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-111-g5eec04a
Message-ID: <E1XOiRk-0002Gn-Ic@lists.gnupg.org>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The GNU crypto library".

The branch, master has been updated
       via  5eec04a43e6c562e956353449be931dd43dfe1cc (commit)
      from  708a3a72cc0608ed4a38ff78d8843c1b46ebf633 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 5eec04a43e6c562e956353449be931dd43dfe1cc
Author: Werner Koch <wk at gnupg.org>
Date:   Tue Sep 2 09:25:20 2014 +0200

    asm: Allow building x86 and amd64 using old compilers.
    
    * src/hwf-x86.c (get_xgetbv): Build only if AVX support is enabled.
    --
    
    Old as(1) versions do not support the xgetvb instruction.  Thus build
    this function only if asm support has been requested.
    
    GnuPG-bug-id: 1708

diff --git a/src/hwf-x86.c b/src/hwf-x86.c
index 0591b4f..7ee246d 100644
--- a/src/hwf-x86.c
+++ b/src/hwf-x86.c
@@ -96,6 +96,7 @@ get_cpuid(unsigned int in, unsigned int *eax, unsigned int *ebx,
     *edx = regs[3];
 }
 
+#if defined(ENABLE_AVX_SUPPORT) || defined(ENABLE_AVX2_SUPPORT)
 static unsigned int
 get_xgetbv(void)
 {
@@ -109,6 +110,7 @@ get_xgetbv(void)
 
   return t_eax;
 }
+#endif /* ENABLE_AVX_SUPPORT || ENABLE_AVX2_SUPPORT */
 
 #endif /* i386 && GNUC */
 
@@ -145,6 +147,7 @@ get_cpuid(unsigned int in, unsigned int *eax, unsigned int *ebx,
     *edx = regs[3];
 }
 
+#if defined(ENABLE_AVX_SUPPORT) || defined(ENABLE_AVX2_SUPPORT)
 static unsigned int
 get_xgetbv(void)
 {
@@ -158,6 +161,7 @@ get_xgetbv(void)
 
   return t_eax;
 }
+#endif /* ENABLE_AVX_SUPPORT || ENABLE_AVX2_SUPPORT */
 
 #endif /* x86-64 && GNUC */
 

-----------------------------------------------------------------------

Summary of changes:
 src/hwf-x86.c |    4 ++++
 1 file changed, 4 insertions(+)


hooks/post-receive
-- 
The GNU crypto library
http://git.gnupg.org


_______________________________________________
Gnupg-commits mailing list
Gnupg-commits at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-commits



From jussi.kivilinna at iki.fi  Tue Sep  2 17:06:28 2014
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Tue, 02 Sep 2014 18:06:28 +0300
Subject: [PATCH 1/1] whirlpool hash amd64 assembly
In-Reply-To: <41DADDB9FE1.00000B3Eandsch@inbox.com>
References: <1745308c116.00000937andsch@inbox.com>
 <41DADDB9FE1.00000B3Eandsch@inbox.com>
Message-ID: <5405DCF4.80504@iki.fi>

On 02/09/14 04:02, And Sch wrote:
> That is very impressive. The goal is accomplished then, I just wanted a faster whirlpool hash in gnupg. I'm no good with assembly, so I have no hope of doing better than the compiler. You may want to title the assembly as sse-amd64 now.
> 
> Thanks

Did you have change to run the implementation on Atom? I'd be very interested to know how's the performance there.

-Jussi

ps. Please keep mailing-list in CC.

> 
>> -----Original Message-----
>> From: jussi.kivilinna at iki.fi
>> Sent: Mon, 01 Sep 2014 19:15:03 +0300
>> To: gcrypt-devel at gnupg.org
>> Subject: Re: [PATCH 1/1] whirlpool hash amd64 assembly
>>
>> On 29/08/14 18:45, And Sch wrote:
>> <snip>
>>>
>>> That is more than twice as fast as the original on the Atom system.
>>>
>>> I tried to find a way to use macros to sort out parts of the loop, but
>>> any change in the order of the instructions slows it down a lot. There
>>> are also only 7 registers available at one time in most parts of the
>>> loop, so that makes macros and rearrangements even more difficult.
>>>
>>> I used a little endian version of the last patch I posted and gcc
>>> -funroll-loops to generate this assembly. I've looked through it and
>>> tried to organize it as best I can. Suggestions on how to clean it up
>>> further would be helpful.
>>>
>>
>> I don't agree that this is good method for creating assembly
>> implementations. As I see it, the main point with assembly
>> implementations is that you can do optimizations that compiler has no way
>> of finding. For example, you could load indexes to rax/rbx/rcx/rdx
>> registers that allow extracting not only first index byte but also second
>> byte with just one instruction. Or, use XMM registers to store the key[]
>> and state[] arrays instead of stack.
>>
>> Well, I ended up making such implementation, which I've attached. On
>> Intel i5-4570 (3.6 Ghz turbo), I get:
>>
>>> tests/bench-slope --cpu-mhz 3600 hash whirlpool
>> Hash:
>>                 |  nanosecs/byte   mebibytes/sec   cycles/byte
>>  WHIRLPOOL      |      4.28 ns/B     222.7 MiB/s     15.42 c/B
>>
>> -Jussi
>>
>> _______________________________________________
>> Gcrypt-devel mailing list
>> Gcrypt-devel at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 
> ____________________________________________________________
> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
> Check it out at http://www.inbox.com/earth
> 
> 
> 



From cvs at cvs.gnupg.org  Tue Sep  2 19:42:18 2014
From: cvs at cvs.gnupg.org (by Jussi Kivilinna)
Date: Tue, 02 Sep 2014 19:42:18 +0200
Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-112-g8a2a328
Message-ID: <E1XOs3q-0000IN-Hj@lists.gnupg.org>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The GNU crypto library".

The branch, master has been updated
       via  8a2a328742012a7c528dd007437185e4584c1e48 (commit)
      from  5eec04a43e6c562e956353449be931dd43dfe1cc (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 8a2a328742012a7c528dd007437185e4584c1e48
Author: Jussi Kivilinna <jussi.kivilinna at iki.fi>
Date:   Tue Sep 2 20:40:07 2014 +0300

    Add new Poly1305 MAC test vectors
    
    * tests/basic.c (check_mac): Add new test vectors for Poly1305 MAC.
    --
    
    Patch adds new test vectors for Poly1305 MAC from Internet Draft
    draft-irtf-cfrg-chacha20-poly1305-01.
    
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>

diff --git a/tests/basic.c b/tests/basic.c
index 6d70cfd..e406db4 100644
--- a/tests/basic.c
+++ b/tests/basic.c
@@ -6008,6 +6008,72 @@ check_mac (void)
         "\xf3\x47\x7e\x7c\xd9\x54\x17\xaf\x89\xa6\xb8\x79\x4c\x31\x0c\xf0",
         NULL,
         0, 32 },
+      /* draft-irtf-cfrg-chacha20-poly1305-01 */
+      /* TV#5 */
+      { GCRY_MAC_POLY1305,
+        "\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF",
+        "\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        NULL,
+        16, 32 },
+      /* TV#6 */
+      { GCRY_MAC_POLY1305,
+        "\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
+        "\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF",
+        "\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        NULL,
+        16, 32 },
+      /* TV#7 */
+      { GCRY_MAC_POLY1305,
+        "\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF"
+        "\xF0\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF"
+        "\x11\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        NULL,
+        48, 32 },
+      /* TV#8 */
+      { GCRY_MAC_POLY1305,
+        "\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF"
+        "\xFB\xFE\xFE\xFE\xFE\xFE\xFE\xFE\xFE\xFE\xFE\xFE\xFE\xFE\xFE\xFE"
+        "\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01",
+        "\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        NULL,
+        48, 32 },
+      /* TV#9 */
+      { GCRY_MAC_POLY1305,
+        "\xFD\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF",
+        "\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\xFA\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF",
+        NULL,
+        16, 32 },
+      /* TV#10 */
+      { GCRY_MAC_POLY1305,
+        "\xE3\x35\x94\xD7\x50\x5E\x43\xB9\x00\x00\x00\x00\x00\x00\x00\x00"
+        "\x33\x94\xD7\x50\x5E\x43\x79\xCD\x01\x00\x00\x00\x00\x00\x00\x00"
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
+        "\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x01\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00"
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x14\x00\x00\x00\x00\x00\x00\x00\x55\x00\x00\x00\x00\x00\x00\x00",
+        NULL,
+        64, 32 },
+      /* TV#11 */
+      { GCRY_MAC_POLY1305,
+        "\xE3\x35\x94\xD7\x50\x5E\x43\xB9\x00\x00\x00\x00\x00\x00\x00\x00"
+        "\x33\x94\xD7\x50\x5E\x43\x79\xCD\x01\x00\x00\x00\x00\x00\x00\x00"
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x01\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00"
+        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        "\x13\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00",
+        NULL,
+        48, 32 },
       /* from http://cr.yp.to/mac/poly1305-20050329.pdf */
       { GCRY_MAC_POLY1305,
         "\xf3\xf6",

-----------------------------------------------------------------------

Summary of changes:
 tests/basic.c |   66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)


hooks/post-receive
-- 
The GNU crypto library
http://git.gnupg.org


_______________________________________________
Gnupg-commits mailing list
Gnupg-commits at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-commits



From cvs at cvs.gnupg.org  Wed Sep  3 08:54:32 2014
From: cvs at cvs.gnupg.org (by Werner Koch)
Date: Wed, 03 Sep 2014 08:54:32 +0200
Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-113-g8b960a8
Message-ID: <E1XP4QV-0004DL-OR@lists.gnupg.org>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The GNU crypto library".

The branch, master has been updated
       via  8b960a807d168000d2690897a7634bd384ac1346 (commit)
      from  8a2a328742012a7c528dd007437185e4584c1e48 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 8b960a807d168000d2690897a7634bd384ac1346
Author: Werner Koch <wk at gnupg.org>
Date:   Wed Sep 3 08:53:43 2014 +0200

    Add a constant for a forthcoming new RNG.
    
    * src/gcrypt.h.in (GCRYCTL_DRBG_REINIT): New constant.

diff --git a/src/gcrypt.h.in b/src/gcrypt.h.in
index 9d64b22..65d9ef6 100644
--- a/src/gcrypt.h.in
+++ b/src/gcrypt.h.in
@@ -330,7 +330,8 @@ enum gcry_ctl_cmds
     GCRYCTL_CLOSE_RANDOM_DEVICE = 70,
     GCRYCTL_INACTIVATE_FIPS_FLAG = 71,
     GCRYCTL_REACTIVATE_FIPS_FLAG = 72,
-    GCRYCTL_SET_SBOX = 73
+    GCRYCTL_SET_SBOX = 73,
+    GCRYCTL_DRBG_REINIT = 74
   };
 
 /* Perform various operations defined by CMD. */

-----------------------------------------------------------------------

Summary of changes:
 src/gcrypt.h.in |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
The GNU crypto library
http://git.gnupg.org


_______________________________________________
Gnupg-commits mailing list
Gnupg-commits at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-commits



From andsch at inbox.com  Wed Sep  3 17:54:35 2014
From: andsch at inbox.com (And Sch)
Date: Wed, 3 Sep 2014 07:54:35 -0800
Subject: [PATCH 1/1] whirlpool hash amd64 assembly
In-Reply-To: <5405DCF4.80504@iki.fi>
References: <1745308c116.00000937andsch@inbox.com>
 <41daddb9fe1.00000b3eandsch@inbox.com>
Message-ID: <563708CCD5C.00001395andsch@inbox.com>

Sorry, I hit the wrong button when replying. Here are benchmarks on the Atom system:

Intel(R) Atom(TM) CPU N570   @ 1.66GHz

original, no patches:
Hash:
                |  nanosecs/byte   mebibytes/sec   cycles/byte
 WHIRLPOOL      |     63.40 ns/B     15.04 MiB/s         - c/B

my C only optimization:
Hash:
                |  nanosecs/byte   mebibytes/sec   cycles/byte
 WHIRLPOOL      |     46.21 ns/B     20.64 MiB/s         - c/B

my edited GCC x64 assembly:
Hash:
                |  nanosecs/byte   mebibytes/sec   cycles/byte
 WHIRLPOOL      |     29.29 ns/B     32.56 MiB/s         - c/B

the SSE assembly by Jussi Kivilinna:
Hash:
                |  nanosecs/byte   mebibytes/sec   cycles/byte
 WHIRLPOOL      |     41.19 ns/B     23.15 MiB/s         - c/B

It is weird that the SSE assembly is much faster than the non-SSE on the i5, but unexpectedly slower on the Atom system. The bswap does not explain the difference because I also tested an SSE version with bswap removed with same results.

-Andrei
> -----Original Message-----
> From: jussi.kivilinna at iki.fi
> Sent: Tue, 02 Sep 2014 18:06:28 +0300
> To: andsch at inbox.com
> Subject: Re: [PATCH 1/1] whirlpool hash amd64 assembly
> 
> On 02/09/14 04:02, And Sch wrote:
>> That is very impressive. The goal is accomplished then, I just wanted a
>> faster whirlpool hash in gnupg. I'm no good with assembly, so I have no
>> hope of doing better than the compiler. You may want to title the
>> assembly as sse-amd64 now.
>> 
>> Thanks
> 
> Did you have change to run the implementation on Atom? I'd be very
> interested to know how's the performance there.
> 
> -Jussi
> 
> ps. Please keep mailing-list in CC.
> 
>> 
>>> -----Original Message-----
>>> From: jussi.kivilinna at iki.fi
>>> Sent: Mon, 01 Sep 2014 19:15:03 +0300
>>> To: gcrypt-devel at gnupg.org
>>> Subject: Re: [PATCH 1/1] whirlpool hash amd64 assembly
>>> 
>>> On 29/08/14 18:45, And Sch wrote:
>>> <snip>
>>>> 
>>>> That is more than twice as fast as the original on the Atom system.
>>>> 
>>>> I tried to find a way to use macros to sort out parts of the loop, but
>>>> any change in the order of the instructions slows it down a lot. There
>>>> are also only 7 registers available at one time in most parts of the
>>>> loop, so that makes macros and rearrangements even more difficult.
>>>> 
>>>> I used a little endian version of the last patch I posted and gcc
>>>> -funroll-loops to generate this assembly. I've looked through it and
>>>> tried to organize it as best I can. Suggestions on how to clean it up
>>>> further would be helpful.
>>>> 
>>> 
>>> I don't agree that this is good method for creating assembly
>>> implementations. As I see it, the main point with assembly
>>> implementations is that you can do optimizations that compiler has no
>>> way
>>> of finding. For example, you could load indexes to rax/rbx/rcx/rdx
>>> registers that allow extracting not only first index byte but also
>>> second
>>> byte with just one instruction. Or, use XMM registers to store the
>>> key[]
>>> and state[] arrays instead of stack.
>>> 
>>> Well, I ended up making such implementation, which I've attached. On
>>> Intel i5-4570 (3.6 Ghz turbo), I get:
>>> 
>>>> tests/bench-slope --cpu-mhz 3600 hash whirlpool
>>> Hash:
>>>                 |  nanosecs/byte   mebibytes/sec   cycles/byte
>>>  WHIRLPOOL      |      4.28 ns/B     222.7 MiB/s     15.42 c/B
>>> 
>>> -Jussi
>>> 
>>> _______________________________________________
>>> Gcrypt-devel mailing list
>>> Gcrypt-devel at gnupg.org
>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>> 
>> ____________________________________________________________
>> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
>> Check it out at http://www.inbox.com/earth
>> 
>> 
>>

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!




From jussi.kivilinna at iki.fi  Wed Sep  3 18:41:18 2014
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Wed, 03 Sep 2014 19:41:18 +0300
Subject: [PATCH 1/1] whirlpool hash amd64 assembly
In-Reply-To: <563708CCD5C.00001395andsch@inbox.com>
References: <1745308c116.00000937andsch@inbox.com>
 <41daddb9fe1.00000b3eandsch@inbox.com> <563708CCD5C.00001395andsch@inbox.com>
Message-ID: <540744AE.2000701@iki.fi>

On 03/09/14 18:54, And Sch wrote:
> Sorry, I hit the wrong button when replying. Here are benchmarks on the Atom system:
> 
> Intel(R) Atom(TM) CPU N570   @ 1.66GHz
> 
> original, no patches:
> Hash:
>                 |  nanosecs/byte   mebibytes/sec   cycles/byte
>  WHIRLPOOL      |     63.40 ns/B     15.04 MiB/s         - c/B
> 
> my C only optimization:
> Hash:
>                 |  nanosecs/byte   mebibytes/sec   cycles/byte
>  WHIRLPOOL      |     46.21 ns/B     20.64 MiB/s         - c/B
> 
> my edited GCC x64 assembly:
> Hash:
>                 |  nanosecs/byte   mebibytes/sec   cycles/byte
>  WHIRLPOOL      |     29.29 ns/B     32.56 MiB/s         - c/B
> 
> the SSE assembly by Jussi Kivilinna:
> Hash:
>                 |  nanosecs/byte   mebibytes/sec   cycles/byte
>  WHIRLPOOL      |     41.19 ns/B     23.15 MiB/s         - c/B
> 
> It is weird that the SSE assembly is much faster than the non-SSE on the i5, but unexpectedly slower on the Atom system. The bswap does not explain the difference because I also tested an SSE version with bswap removed with same results.
> 

Well, not totally unexpected to me :)

Problem is that (old) Atoms are in-order, unlike any other current x86 CPU which are out-of-order. So extra work would be required for Atom by tweaking instruction ordering by hand, and maybe making RI4 another RTx for byte indexes, and so on. And that work might or might not reduce performance on Core processors. But since I don't have 64-bit capable Atom I can't really do that tweaking *.

-Jussi

* (and since latest Atoms have gained limited out-of-order scheduling, optimizing for old in-order does not seem time-spent-well.) (and I haven't seen Intel contributing Atom optimized implementations to open source projects.)

> -Andrei
>> -----Original Message-----
>> From: jussi.kivilinna at iki.fi
>> Sent: Tue, 02 Sep 2014 18:06:28 +0300
>> To: andsch at inbox.com
>> Subject: Re: [PATCH 1/1] whirlpool hash amd64 assembly
>>
>> On 02/09/14 04:02, And Sch wrote:
>>> That is very impressive. The goal is accomplished then, I just wanted a
>>> faster whirlpool hash in gnupg. I'm no good with assembly, so I have no
>>> hope of doing better than the compiler. You may want to title the
>>> assembly as sse-amd64 now.
>>>
>>> Thanks
>>
>> Did you have change to run the implementation on Atom? I'd be very
>> interested to know how's the performance there.
>>
>> -Jussi
>>
>> ps. Please keep mailing-list in CC.
>>
>>>
>>>> -----Original Message-----
>>>> From: jussi.kivilinna at iki.fi
>>>> Sent: Mon, 01 Sep 2014 19:15:03 +0300
>>>> To: gcrypt-devel at gnupg.org
>>>> Subject: Re: [PATCH 1/1] whirlpool hash amd64 assembly
>>>>
>>>> On 29/08/14 18:45, And Sch wrote:
>>>> <snip>
>>>>>
>>>>> That is more than twice as fast as the original on the Atom system.
>>>>>
>>>>> I tried to find a way to use macros to sort out parts of the loop, but
>>>>> any change in the order of the instructions slows it down a lot. There
>>>>> are also only 7 registers available at one time in most parts of the
>>>>> loop, so that makes macros and rearrangements even more difficult.
>>>>>
>>>>> I used a little endian version of the last patch I posted and gcc
>>>>> -funroll-loops to generate this assembly. I've looked through it and
>>>>> tried to organize it as best I can. Suggestions on how to clean it up
>>>>> further would be helpful.
>>>>>
>>>>
>>>> I don't agree that this is good method for creating assembly
>>>> implementations. As I see it, the main point with assembly
>>>> implementations is that you can do optimizations that compiler has no
>>>> way
>>>> of finding. For example, you could load indexes to rax/rbx/rcx/rdx
>>>> registers that allow extracting not only first index byte but also
>>>> second
>>>> byte with just one instruction. Or, use XMM registers to store the
>>>> key[]
>>>> and state[] arrays instead of stack.
>>>>
>>>> Well, I ended up making such implementation, which I've attached. On
>>>> Intel i5-4570 (3.6 Ghz turbo), I get:
>>>>
>>>>> tests/bench-slope --cpu-mhz 3600 hash whirlpool
>>>> Hash:
>>>>                 |  nanosecs/byte   mebibytes/sec   cycles/byte
>>>>  WHIRLPOOL      |      4.28 ns/B     222.7 MiB/s     15.42 c/B
>>>>
>>>> -Jussi
>>>>
>>>> _______________________________________________
>>>> Gcrypt-devel mailing list
>>>> Gcrypt-devel at gnupg.org
>>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>>>
>>> ____________________________________________________________
>>> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
>>> Check it out at http://www.inbox.com/earth
>>>
>>>
>>>
> 
> ____________________________________________________________
> FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
> Visit http://www.inbox.com/photosharing to find out more!
> 
> 
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 



From dbaryshkov at gmail.com  Fri Sep  5 00:14:22 2014
From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov)
Date: Fri, 5 Sep 2014 02:14:22 +0400
Subject: Libgcrypt and libgmp
Message-ID: <CALT56yOY+S7QnMAMataoyEvzLht4O_NQxFA=4xrnmD=Gv91J3A@mail.gmail.com>

Hello,

I was looking on how to improve the performance of public key
implementation in libgcrypt.
One of ideas was to check if using libgmp can improve the situation.
Nowdays GMP is
dual-licensed under GPLv2+ or LGPLv3+. As far as I understand, this
licensing is compatible
with libgcrypt LGPLv2.1+.

Surprisingly even replacing several asm-coded functions resulted in
nearly 20-25% speed
increase (according to tests/benchmark pubkey). Do such patches have a
chance to be
reviewed & accepted, or it is a waste of time, as you would prefer to
keep libgcrypt
independent of libgmp. I'm not changing the gcry_mpi_t internals, or
removing secure
allocation/reallocation, only replacing the computational code.

Before:
Algorithm         generate 1000*priv 1000*public
------------------------------------------------
RSA 1024 bit          10ms     770ms        40ms
RSA 2048 bit         320ms    4850ms       130ms
RSA 3072 bit        1460ms   13640ms       220ms
RSA 4096 bit        1690ms   31830ms       390ms
ELG 1024 bit             -    1360ms      1190ms
ELG 2048 bit             -    4840ms      5260ms
ELG 3072 bit             -   10050ms     11400ms
DSA 1024/160             -     560ms       690ms
DSA 2048/224             -    2060ms      2860ms
DSA 3072/256             -    4220ms      5890ms
ECDSA 192 bit          0ms    1270ms      2170ms
ECDSA 224 bit         10ms    2060ms      3800ms
ECDSA 256 bit          0ms    1800ms      3200ms
ECDSA 384 bit         20ms    3770ms      6830ms
ECDSA 521 bit         30ms    8990ms     16490ms
EdDSA Ed25519          0ms    4010ms      5650ms
GOST  256 bit         10ms    1730ms      3270ms
GOST  512 bit         30ms    8030ms     15250ms

After:
Algorithm         generate 1000*priv 1000*public
------------------------------------------------
RSA 1024 bit          10ms     550ms        30ms
RSA 2048 bit         100ms    3270ms        80ms
RSA 3072 bit         120ms    8980ms       150ms
RSA 4096 bit         850ms   21110ms       250ms
ELG 1024 bit             -    1020ms       850ms
ELG 2048 bit             -    3400ms      3530ms
ELG 3072 bit             -    6960ms      7850ms
DSA 1024/160             -     380ms       470ms
DSA 2048/224             -    1390ms      1850ms
DSA 3072/256             -    2870ms      4030ms
ECDSA 192 bit          0ms    1200ms      2100ms
ECDSA 224 bit         10ms    1860ms      3470ms
ECDSA 256 bit         10ms    1730ms      3070ms
ECDSA 384 bit         10ms    3150ms      5800ms
ECDSA 521 bit         30ms    6880ms     13090ms
EdDSA Ed25519         10ms    3550ms      5110ms
GOST  256 bit          0ms    1680ms      3200ms
GOST  512 bit         20ms    6400ms     12590ms


-- 
With best wishes
Dmitry


From chris at chatsecure.org  Fri Sep  5 01:02:54 2014
From: chris at chatsecure.org (Chris Ballinger)
Date: Thu, 4 Sep 2014 16:02:54 -0700
Subject: Libgcrypt and libgmp
In-Reply-To: <CALT56yOY+S7QnMAMataoyEvzLht4O_NQxFA=4xrnmD=Gv91J3A@mail.gmail.com>
References: <CALT56yOY+S7QnMAMataoyEvzLht4O_NQxFA=4xrnmD=Gv91J3A@mail.gmail.com>
Message-ID: <CAG7SQq5e+OhXADh1070Ux1-R_bj3X8R1TwShmpPb1AMFQEb9rA@mail.gmail.com>

Some projects might only be able to use LGPLv2.1+ code (and not
LGPLv3-only), or have a desire to minimize their external dependencies, so
if this is merged perhaps it would be best provided as a configure switch
like --enable-gmp or similar.


On Thu, Sep 4, 2014 at 3:14 PM, Dmitry Eremin-Solenikov <
dbaryshkov at gmail.com> wrote:

> Hello,
>
> I was looking on how to improve the performance of public key
> implementation in libgcrypt.
> One of ideas was to check if using libgmp can improve the situation.
> Nowdays GMP is
> dual-licensed under GPLv2+ or LGPLv3+. As far as I understand, this
> licensing is compatible
> with libgcrypt LGPLv2.1+.
>
> Surprisingly even replacing several asm-coded functions resulted in
> nearly 20-25% speed
> increase (according to tests/benchmark pubkey). Do such patches have a
> chance to be
> reviewed & accepted, or it is a waste of time, as you would prefer to
> keep libgcrypt
> independent of libgmp. I'm not changing the gcry_mpi_t internals, or
> removing secure
> allocation/reallocation, only replacing the computational code.
>
> Before:
> Algorithm         generate 1000*priv 1000*public
> ------------------------------------------------
> RSA 1024 bit          10ms     770ms        40ms
> RSA 2048 bit         320ms    4850ms       130ms
> RSA 3072 bit        1460ms   13640ms       220ms
> RSA 4096 bit        1690ms   31830ms       390ms
> ELG 1024 bit             -    1360ms      1190ms
> ELG 2048 bit             -    4840ms      5260ms
> ELG 3072 bit             -   10050ms     11400ms
> DSA 1024/160             -     560ms       690ms
> DSA 2048/224             -    2060ms      2860ms
> DSA 3072/256             -    4220ms      5890ms
> ECDSA 192 bit          0ms    1270ms      2170ms
> ECDSA 224 bit         10ms    2060ms      3800ms
> ECDSA 256 bit          0ms    1800ms      3200ms
> ECDSA 384 bit         20ms    3770ms      6830ms
> ECDSA 521 bit         30ms    8990ms     16490ms
> EdDSA Ed25519          0ms    4010ms      5650ms
> GOST  256 bit         10ms    1730ms      3270ms
> GOST  512 bit         30ms    8030ms     15250ms
>
> After:
> Algorithm         generate 1000*priv 1000*public
> ------------------------------------------------
> RSA 1024 bit          10ms     550ms        30ms
> RSA 2048 bit         100ms    3270ms        80ms
> RSA 3072 bit         120ms    8980ms       150ms
> RSA 4096 bit         850ms   21110ms       250ms
> ELG 1024 bit             -    1020ms       850ms
> ELG 2048 bit             -    3400ms      3530ms
> ELG 3072 bit             -    6960ms      7850ms
> DSA 1024/160             -     380ms       470ms
> DSA 2048/224             -    1390ms      1850ms
> DSA 3072/256             -    2870ms      4030ms
> ECDSA 192 bit          0ms    1200ms      2100ms
> ECDSA 224 bit         10ms    1860ms      3470ms
> ECDSA 256 bit         10ms    1730ms      3070ms
> ECDSA 384 bit         10ms    3150ms      5800ms
> ECDSA 521 bit         30ms    6880ms     13090ms
> EdDSA Ed25519         10ms    3550ms      5110ms
> GOST  256 bit          0ms    1680ms      3200ms
> GOST  512 bit         20ms    6400ms     12590ms
>
>
> --
> With best wishes
> Dmitry
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140904/d384e843/attachment.html>

From wk at gnupg.org  Mon Sep  8 20:30:44 2014
From: wk at gnupg.org (Werner Koch)
Date: Mon, 08 Sep 2014 20:30:44 +0200
Subject: Libgcrypt and libgmp
In-Reply-To: <CALT56yOY+S7QnMAMataoyEvzLht4O_NQxFA=4xrnmD=Gv91J3A@mail.gmail.com>
 (Dmitry Eremin-Solenikov's message of "Fri, 5 Sep 2014 02:14:22
 +0400")
References: <CALT56yOY+S7QnMAMataoyEvzLht4O_NQxFA=4xrnmD=Gv91J3A@mail.gmail.com>
Message-ID: <87ioky7ynf.fsf@vigenere.g10code.de>

On Fri,  5 Sep 2014 00:14, dbaryshkov at gmail.com said:

> dual-licensed under GPLv2+ or LGPLv3+. As far as I understand, this
> licensing is compatible
> with libgcrypt LGPLv2.1+.

Nevertheless I like to stick to LGPLv2.1+.

> Surprisingly even replacing several asm-coded functions resulted in
> nearly 20-25% speed
> increase (according to tests/benchmark pubkey). Do such patches have a
> chance to be

That obviously depends on on the architecture.  We have quite new code
for amd64.

Libgcrypt (formerly GnuPG) are based on GMP version 2 which is 20 years
old.  Back then there was no public development and the later
improvements with GMP 3 never made it to Libgcrypt because the build
system of GMP was heavily changed and nobody volunteered to convert that
to the Libgcrypt system.  Might have also been a linceses issue - I
can't remember.

> reviewed & accepted, or it is a waste of time, as you would prefer to
> keep libgcrypt
> independent of libgmp. I'm not changing the gcry_mpi_t internals, or

Thanks for the offer.  However, I do not want to have a dependency on
another library.  Further, forthcoming improvements will likely be all
in the ECC area and optimization is curve dependent.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From simon at josefsson.org  Tue Sep  9 00:03:12 2014
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 09 Sep 2014 00:03:12 +0200
Subject: Libgcrypt and libgmp
In-Reply-To: <87ioky7ynf.fsf@vigenere.g10code.de> (Werner Koch's message of
 "Mon, 08 Sep 2014 20:30:44 +0200")
References: <CALT56yOY+S7QnMAMataoyEvzLht4O_NQxFA=4xrnmD=Gv91J3A@mail.gmail.com>
 <87ioky7ynf.fsf@vigenere.g10code.de>
Message-ID: <87fvg1n527.fsf@latte.josefsson.org>

Wasn't another reason for not using GMP directly in libgcrypt that it
isn't written in a side-channel free way?  So calling GMP functions with
the key as parameter may leak the key in a time side channel?  Not sure
if my recollection is correct here, though.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20140909/8d238aa7/attachment.sig>

From wk at gnupg.org  Tue Sep  9 08:58:11 2014
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Sep 2014 08:58:11 +0200
Subject: Libgcrypt and libgmp
In-Reply-To: <87fvg1n527.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Tue, 09 Sep 2014 00:03:12 +0200")
References: <CALT56yOY+S7QnMAMataoyEvzLht4O_NQxFA=4xrnmD=Gv91J3A@mail.gmail.com>
 <87ioky7ynf.fsf@vigenere.g10code.de>
 <87fvg1n527.fsf@latte.josefsson.org>
Message-ID: <87mwa9701o.fsf@vigenere.g10code.de>

On Tue,  9 Sep 2014 00:03, simon at josefsson.org said:
> Wasn't another reason for not using GMP directly in libgcrypt that it
> isn't written in a side-channel free way?  So calling GMP functions with

Back then side-channel attacks on general purpose computers were not a
hot topic.  The main concern back in 1997 was the problem that sensitive
material could end up in the swap space.  Thus the mlock-ed heap and
that major change of allocating data on the heap and not on the stack.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From chris at chatsecure.org  Thu Sep 18 02:42:28 2014
From: chris at chatsecure.org (Chris Ballinger)
Date: Wed, 17 Sep 2014 17:42:28 -0700
Subject: gen-posix-lock-obj for iOS
Message-ID: <CAG7SQq6yKBmdy9UEfJyAnbJ94N3QxkmbVD5ZPd6iM=b7wyCZ-w@mail.gmail.com>

I had trouble compiling libgpg-error 1.15 for iOS and needed to apply a
patch, but I read that it was already committed upstream.

When cross-compiling for arm-apple-darwin and aarch64-apple-darwin I also
needed to generate these files, so here they are. I made a little iOS
utility to help people generate them in case Apple adds any more
architectures in the future:
https://github.com/chrisballinger/gen-posix-lock-obj-iOS

Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140917/5d9726c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lock-obj-pub.aarch64-apple-darwin.h
Type: text/x-chdr
Size: 554 bytes
Desc: not available
URL: </pipermail/attachments/20140917/5d9726c6/attachment-0002.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lock-obj-pub.arm-apple-darwin.h
Type: text/x-chdr
Size: 504 bytes
Desc: not available
URL: </pipermail/attachments/20140917/5d9726c6/attachment-0003.h>

From wk at gnupg.org  Thu Sep 18 12:42:04 2014
From: wk at gnupg.org (Werner Koch)
Date: Thu, 18 Sep 2014 12:42:04 +0200
Subject: gen-posix-lock-obj for iOS
In-Reply-To: <CAG7SQq6yKBmdy9UEfJyAnbJ94N3QxkmbVD5ZPd6iM=b7wyCZ-w@mail.gmail.com>
 (Chris Ballinger's message of "Wed, 17 Sep 2014 17:42:28 -0700")
References: <CAG7SQq6yKBmdy9UEfJyAnbJ94N3QxkmbVD5ZPd6iM=b7wyCZ-w@mail.gmail.com>
Message-ID: <87bnqdb477.fsf@vigenere.g10code.de>

On Thu, 18 Sep 2014 02:42, chris at chatsecure.org said:

> When cross-compiling for arm-apple-darwin and aarch64-apple-darwin I also
> needed to generate these files, so here they are. I made a little iOS

Thanks.  The will go into the next release - probably today.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From chris at chatsecure.org  Thu Sep 18 20:01:49 2014
From: chris at chatsecure.org (Chris Ballinger)
Date: Thu, 18 Sep 2014 11:01:49 -0700
Subject: gen-posix-lock-obj for iOS
In-Reply-To: <87bnqdb477.fsf@vigenere.g10code.de>
References: <CAG7SQq6yKBmdy9UEfJyAnbJ94N3QxkmbVD5ZPd6iM=b7wyCZ-w@mail.gmail.com>
 <87bnqdb477.fsf@vigenere.g10code.de>
Message-ID: <CAG7SQq5fmnwkxA7sqLfpQ7SRfBD55ttMPXavvx-XzQSxo=C5sA@mail.gmail.com>

Great! Could you briefly explain why these are needed in the first place?
All I can gather is that it's needed for some very low level threading
stuff.

Another note, when compiling for all of these architectures I "lipo" the
libraries together, but choose only one of the header files, so usually I
am building other code against the i386 version of the header. Perhaps it
would be best to concatenate the architecture-specific code into the single
header file with #ifdefs based on architecture?

On Thu, Sep 18, 2014 at 3:42 AM, Werner Koch <wk at gnupg.org> wrote:

> On Thu, 18 Sep 2014 02:42, chris at chatsecure.org said:
>
> > When cross-compiling for arm-apple-darwin and aarch64-apple-darwin I also
> > needed to generate these files, so here they are. I made a little iOS
>
> Thanks.  The will go into the next release - probably today.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140918/dea3fc67/attachment.html>

From wk at gnupg.org  Fri Sep 19 17:04:22 2014
From: wk at gnupg.org (Werner Koch)
Date: Fri, 19 Sep 2014 17:04:22 +0200
Subject: gen-posix-lock-obj for iOS
In-Reply-To: <CAG7SQq5fmnwkxA7sqLfpQ7SRfBD55ttMPXavvx-XzQSxo=C5sA@mail.gmail.com>
 (Chris Ballinger's message of "Thu, 18 Sep 2014 11:01:49 -0700")
References: <CAG7SQq6yKBmdy9UEfJyAnbJ94N3QxkmbVD5ZPd6iM=b7wyCZ-w@mail.gmail.com>
 <87bnqdb477.fsf@vigenere.g10code.de>
 <CAG7SQq5fmnwkxA7sqLfpQ7SRfBD55ttMPXavvx-XzQSxo=C5sA@mail.gmail.com>
Message-ID: <877g0z1wjt.fsf@vigenere.g10code.de>

On Thu, 18 Sep 2014 20:01, chris at chatsecure.org said:
> Great! Could you briefly explain why these are needed in the first place?
> All I can gather is that it's needed for some very low level threading

This is for the portable mutex API.  To avoid extra dependencies for
single threaded applications it is useful to avoid build time
dependencies to pthread.h and, if possible, runtime dependencies on
libpthread.  This information hiding method will also enable us to
change the concrete mutex implementation while keeping a stable API and
ABI.

> Another note, when compiling for all of these architectures I "lipo" the
> libraries together, but choose only one of the header files, so usually I

This is about these fat binaries, right?  I have no experience myself
withit but I know that you need to use some build tricks.

> am building other code against the i386 version of the header. Perhaps it
> would be best to concatenate the architecture-specific code into the single
> header file with #ifdefs based on architecture?

I don't like that.  The whole cpp based detection is not as robust as
the configure based one.  Right, it may happen that you use a wrong
header file but then something is wrong with your toolchain setup
anyway.  The autoconf macros we use actually detect a wrong use and
print a warning if you use a header for a different cpu-vendor-os.  We
can only do a warning because there are many aliases for the same
system.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From chris at chatsecure.org  Mon Sep 22 22:00:04 2014
From: chris at chatsecure.org (Chris Ballinger)
Date: Mon, 22 Sep 2014 13:00:04 -0700
Subject: gen-posix-lock-obj for iOS
In-Reply-To: <877g0z1wjt.fsf@vigenere.g10code.de>
References: <CAG7SQq6yKBmdy9UEfJyAnbJ94N3QxkmbVD5ZPd6iM=b7wyCZ-w@mail.gmail.com>
 <87bnqdb477.fsf@vigenere.g10code.de>
 <CAG7SQq5fmnwkxA7sqLfpQ7SRfBD55ttMPXavvx-XzQSxo=C5sA@mail.gmail.com>
 <877g0z1wjt.fsf@vigenere.g10code.de>
Message-ID: <CAG7SQq4+4X4u08uxJ2j-7bTmH1WNd66zYY7kiPQToFLFg4mDDA@mail.gmail.com>

>
> I don't like that.  The whole cpp based detection is not as robust as
> the configure based one.  Right, it may happen that you use a wrong
> header file but then something is wrong with your toolchain setup
> anyway.  The autoconf macros we use actually detect a wrong use and
> print a warning if you use a header for a different cpu-vendor-os.  We
> can only do a warning because there are many aliases for the same
> system.


The problem with that method, is I can't do that when integrating with
Xcode. I have to choose a single set of headers to use for all of the
architectures (i386, x86_64, armv7, armv7s, arm64 / aarch64). Apple does a
lot of #ifdef magic for their own system headers to workaround this issue.

If possible I'd like to avoid anything actually using these
architecture-specific options because I cannot guarantee that the correct
headers will be used, no matter how much I massage the toolchain. Is this
new API used heavily by libgcrypt or is it unused when compiling with
pthreads support?


On Fri, Sep 19, 2014 at 8:04 AM, Werner Koch <wk at gnupg.org> wrote:

> On Thu, 18 Sep 2014 20:01, chris at chatsecure.org said:
> > Great! Could you briefly explain why these are needed in the first place?
> > All I can gather is that it's needed for some very low level threading
>
> This is for the portable mutex API.  To avoid extra dependencies for
> single threaded applications it is useful to avoid build time
> dependencies to pthread.h and, if possible, runtime dependencies on
> libpthread.  This information hiding method will also enable us to
> change the concrete mutex implementation while keeping a stable API and
> ABI.
>
> > Another note, when compiling for all of these architectures I "lipo" the
> > libraries together, but choose only one of the header files, so usually I
>
> This is about these fat binaries, right?  I have no experience myself
> withit but I know that you need to use some build tricks.
>
> > am building other code against the i386 version of the header. Perhaps it
> > would be best to concatenate the architecture-specific code into the
> single
> > header file with #ifdefs based on architecture?
>
> I don't like that.  The whole cpp based detection is not as robust as
> the configure based one.  Right, it may happen that you use a wrong
> header file but then something is wrong with your toolchain setup
> anyway.  The autoconf macros we use actually detect a wrong use and
> print a warning if you use a header for a different cpu-vendor-os.  We
> can only do a warning because there are many aliases for the same
> system.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140922/831611cb/attachment.html>

From wk at gnupg.org  Tue Sep 23 17:23:42 2014
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 Sep 2014 17:23:42 +0200
Subject: gen-posix-lock-obj for iOS
In-Reply-To: <CAG7SQq4+4X4u08uxJ2j-7bTmH1WNd66zYY7kiPQToFLFg4mDDA@mail.gmail.com>
 (Chris Ballinger's message of "Mon, 22 Sep 2014 13:00:04 -0700")
References: <CAG7SQq6yKBmdy9UEfJyAnbJ94N3QxkmbVD5ZPd6iM=b7wyCZ-w@mail.gmail.com>
 <87bnqdb477.fsf@vigenere.g10code.de>
 <CAG7SQq5fmnwkxA7sqLfpQ7SRfBD55ttMPXavvx-XzQSxo=C5sA@mail.gmail.com>
 <877g0z1wjt.fsf@vigenere.g10code.de>
 <CAG7SQq4+4X4u08uxJ2j-7bTmH1WNd66zYY7kiPQToFLFg4mDDA@mail.gmail.com>
Message-ID: <87mw9qqs1t.fsf@vigenere.g10code.de>

On Mon, 22 Sep 2014 22:00, chris at chatsecure.org said:

> The problem with that method, is I can't do that when integrating with
> Xcode. I have to choose a single set of headers to use for all of the
> architectures (i386, x86_64, armv7, armv7s, arm64 / aarch64). Apple does a
> lot of #ifdef magic for their own system headers to workaround this issue.

I do not understand why it is a problem to install external libraries
(e.g. libgpg-error, libgcrypt, gpgme) into system specific directories.
You can always use -I and -L to tell the compiler where to look for
header and libraries first.  In fact the gpg-error-config script as well
as other config scripts and pkg-config templates help to keep track of
those options.

If you really don't like it, you hack around it by writing your own
ligpg-error.h wrapper like

  #if defined(__x64_64__)
  # include "/usr/local/foo/x64_64/libgpg-error.h"
  #elif ...

and make sure that /usr/local/foo/x64_64/ is never passed as -I options.
But for libs you would need to adjust the linker scripts (in case the
OSX ld(1) uses such a thing).

> If possible I'd like to avoid anything actually using these
> architecture-specific options because I cannot guarantee that the correct

Actually this has been used for years.  For example gcrypt.h has a
system specific socklen_t and sys/select header.  gpgme.h uses system
specifics types for ssize_t and off_t.  The system specific parts in
gpg-error.h are just more noticeable.

Merging them all into one header is something Apple can do because they
control the environment and do not need to be portable to anything else.
However, we have already seen how fragile this is if you look at the
stdint.h problem.

With the dozens of different architectures and OSes we support, the
header files won't be maintainable.  We do the configure runtime testing
to figure out the parameters of unknown operating systems and thus are
able to build and run software on systems we have never seen before.
Doing all that configure magic in an installed header file is simply not
possible.

> headers will be used, no matter how much I massage the toolchain. Is this
> new API used heavily by libgcrypt or is it unused when compiling with
> pthreads support?

It is currently being used by GnuPG 2.1 but the next libgcrypt version
will also take advantage of it.  Some more shared code will be moved to
libgpg-error in the future.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From chris at chatsecure.org  Tue Sep 23 22:48:27 2014
From: chris at chatsecure.org (Chris Ballinger)
Date: Tue, 23 Sep 2014 13:48:27 -0700
Subject: gen-posix-lock-obj for iOS
In-Reply-To: <87mw9qqs1t.fsf@vigenere.g10code.de>
References: <CAG7SQq6yKBmdy9UEfJyAnbJ94N3QxkmbVD5ZPd6iM=b7wyCZ-w@mail.gmail.com>
 <87bnqdb477.fsf@vigenere.g10code.de>
 <CAG7SQq5fmnwkxA7sqLfpQ7SRfBD55ttMPXavvx-XzQSxo=C5sA@mail.gmail.com>
 <877g0z1wjt.fsf@vigenere.g10code.de>
 <CAG7SQq4+4X4u08uxJ2j-7bTmH1WNd66zYY7kiPQToFLFg4mDDA@mail.gmail.com>
 <87mw9qqs1t.fsf@vigenere.g10code.de>
Message-ID: <CAG7SQq6R7SWQVYFWdeYP9HMmDj22UfMDJ7P16jPBQVgLEmMesA@mail.gmail.com>

It just seems strange to me to move so much functionality into a "small
library that defines common error values for all GnuPG components".

This change drastically complicates my build, and I fear that if someone
else unaware of this change accidentally includes the wrong headers (e.g.
i386 on x86_64) this could potentially lead to unexpected security problems.

Here is the current set of scripts I use for building libgpg-error,
libgcrypt, and libotr:

* https://github.com/ChatSecure/OTRKit/blob/master/build-libgpg-error.sh
* https://github.com/ChatSecure/OTRKit/blob/master/build-libgcrypt.sh
* https://github.com/ChatSecure/OTRKit/blob/master/build-libotr.sh

As you can see towards the end of the script, after each architecture is
built, it copies a single version of the headers for that library to a
"dependencies" folder that contains the "fat" versions of the libraries.

I will need to rework these scripts to keep the headers in their
architecture-specific folder and ensure that libgcrypt isn't using
libgpg-error headers for the wrong arch.

Perhaps instead of throwing up a warning during configure if you detect the
wrong arch, throw a full error? I'm not familiar with what exactly these
values are used for, and the security consequences if the wrong values are
used on the wrong platform.

If these values are platform-specific and can only be generated at runtime
on the target architecture, why not just generate them at runtime instead
of during the configure phase?


On Tue, Sep 23, 2014 at 8:23 AM, Werner Koch <wk at gnupg.org> wrote:

> On Mon, 22 Sep 2014 22:00, chris at chatsecure.org said:
>
> > The problem with that method, is I can't do that when integrating with
> > Xcode. I have to choose a single set of headers to use for all of the
> > architectures (i386, x86_64, armv7, armv7s, arm64 / aarch64). Apple does
> a
> > lot of #ifdef magic for their own system headers to workaround this
> issue.
>
> I do not understand why it is a problem to install external libraries
> (e.g. libgpg-error, libgcrypt, gpgme) into system specific directories.
> You can always use -I and -L to tell the compiler where to look for
> header and libraries first.  In fact the gpg-error-config script as well
> as other config scripts and pkg-config templates help to keep track of
> those options.
>
> If you really don't like it, you hack around it by writing your own
> ligpg-error.h wrapper like
>
>   #if defined(__x64_64__)
>   # include "/usr/local/foo/x64_64/libgpg-error.h"
>   #elif ...
>
> and make sure that /usr/local/foo/x64_64/ is never passed as -I options.
> But for libs you would need to adjust the linker scripts (in case the
> OSX ld(1) uses such a thing).
>
> > If possible I'd like to avoid anything actually using these
> > architecture-specific options because I cannot guarantee that the correct
>
> Actually this has been used for years.  For example gcrypt.h has a
> system specific socklen_t and sys/select header.  gpgme.h uses system
> specifics types for ssize_t and off_t.  The system specific parts in
> gpg-error.h are just more noticeable.
>
> Merging them all into one header is something Apple can do because they
> control the environment and do not need to be portable to anything else.
> However, we have already seen how fragile this is if you look at the
> stdint.h problem.
>
> With the dozens of different architectures and OSes we support, the
> header files won't be maintainable.  We do the configure runtime testing
> to figure out the parameters of unknown operating systems and thus are
> able to build and run software on systems we have never seen before.
> Doing all that configure magic in an installed header file is simply not
> possible.
>
> > headers will be used, no matter how much I massage the toolchain. Is this
> > new API used heavily by libgcrypt or is it unused when compiling with
> > pthreads support?
>
> It is currently being used by GnuPG 2.1 but the next libgcrypt version
> will also take advantage of it.  Some more shared code will be moved to
> libgpg-error in the future.
>
>
> Shalom-Salam,
>
>    Werner
>
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140923/70ac31b7/attachment-0001.html>

From cvs at cvs.gnupg.org  Tue Sep 30 12:40:02 2014
From: cvs at cvs.gnupg.org (by Werner Koch)
Date: Tue, 30 Sep 2014 12:40:02 +0200
Subject: [git] GCRYPT - branch, master, updated. libgcrypt-1.6.0-114-g51dae8c
Message-ID: <E1XYund-0002PD-Lc@lists.gnupg.org>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The GNU crypto library".

The branch, master has been updated
       via  51dae8c8c4b63bb5e1685cbd8722e35342524737 (commit)
      from  8b960a807d168000d2690897a7634bd384ac1346 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 51dae8c8c4b63bb5e1685cbd8722e35342524737
Author: Werner Koch <wk at gnupg.org>
Date:   Mon Sep 29 17:34:28 2014 +0200

    mac: Fix gcry_mac_close to allow for a NULL handle.
    
    * cipher/mac.c (_gcry_mac_close): Check for NULL.
    --
    
    We always allow this for easier cleanup.  actually the docs already
    tell that this is allowed.

diff --git a/cipher/mac.c b/cipher/mac.c
index 30117b9..e5131ed 100644
--- a/cipher/mac.c
+++ b/cipher/mac.c
@@ -336,7 +336,8 @@ _gcry_mac_open (gcry_mac_hd_t * h, int algo, unsigned int flags,
 void
 _gcry_mac_close (gcry_mac_hd_t hd)
 {
-  mac_close (hd);
+  if (hd)
+    mac_close (hd);
 }
 
 

-----------------------------------------------------------------------

Summary of changes:
 cipher/mac.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
The GNU crypto library
http://git.gnupg.org


_______________________________________________
Gnupg-commits mailing list
Gnupg-commits at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-commits