Re: [RFC PATCH 10/12] sha256: add an SHA-256 implementation using libgcrypt
On Wed, Aug 29, 2018 at 10:53:01AM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Aug 29 2018, brian m. carlson wrote: > > > Generally, one gets better performance out of cryptographic routines > > written in assembly than C, and this is also true for SHA-256 > > It makes sense to have a libgcrypt implementation... > > > In addition, most Linux distributions cannot distribute Git linked > > against OpenSSL for licensing reasons. > > ...but I'm curious to know what licensing reasons these are, e.g. Debian > who's usually the most strict about these things distributes git linked > to OpenSSL: On my Debian system, that's linked to libgnutls. The reason is section 3 of the GPLv2 (emphasis mine): 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form **under the terms of Sections 1 and 2 above** provided that you also do one of the following: [provide source somehow] The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. **However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.** Basically, you can only distribute binary versions of Git under the terms of the GPLv2, and you have to distribute source for the entire thing under those terms. OpenSSL is licensed incompatibly with the GPLv2, so you can't legally comply with that part, but if you use the system OpenSSL and don't distribute that OpenSSL with Git, you're exempt. This is called the system library exception. Debian (and Red Hat, and every other Linux distro) ships Git and OpenSSL side by side on the same mirrors, and hence "that component [OpenSSL] accompanies the executable." Consequently, they can't take advantage of the exception, and must link it to a GPLv2 compatible library. Debian uses GnuTLS for libcurl, and Red Hat uses NSS. A more comprehensive explanation of the whole thing is here: https://people.gnome.org/~markmc/openssl-and-the-gpl.html -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Re: [RFC PATCH 10/12] sha256: add an SHA-256 implementation using libgcrypt
On Wed, Aug 29 2018, brian m. carlson wrote: > Generally, one gets better performance out of cryptographic routines > written in assembly than C, and this is also true for SHA-256 It makes sense to have a libgcrypt implementation... > In addition, most Linux distributions cannot distribute Git linked > against OpenSSL for licensing reasons. ...but I'm curious to know what licensing reasons these are, e.g. Debian who's usually the most strict about these things distributes git linked to OpenSSL: $ dpkg -S /usr/lib/git-core/git-imap-send; apt policy git 2>/dev/null|grep -F '***'; ldd -r /usr/lib/git-core/git-imap-send|grep ssl; uname -m git: /usr/lib/git-core/git-imap-send *** 1:2.19.0~rc1+next.20180828-1 1001 libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x7fd3cc8bb000) x86_64 $ dpkg -S /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 libssl1.0.2:amd64: /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 $ apt show libssl1.0.2 2>&1 |grep ssl Package: libssl1.0.2 Source: openssl1.0 Maintainer: Debian OpenSSL Team Homepage: https://www.openssl.org
[RFC PATCH 10/12] sha256: add an SHA-256 implementation using libgcrypt
Generally, one gets better performance out of cryptographic routines
written in assembly than C, and this is also true for SHA-256. In
addition, most Linux distributions cannot distribute Git linked against
OpenSSL for licensing reasons.
Most systems with GnuPG will also have libgcrypt, since it is a
dependency of GnuPG. libgcrypt is also faster than the SHA1DC
implementation for messages of a few KiB and larger. It is licensed
under the LGPL 2.1, which is compatible with the GPL.
Add an implementation of SHA-256 that uses libgcrypt.
Signed-off-by: brian m. carlson
---
Makefile| 13 +++--
hash.h | 4
sha256/gcrypt.h | 30 ++
3 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 sha256/gcrypt.h
diff --git a/Makefile b/Makefile
index 624d852e79..86867af083 100644
--- a/Makefile
+++ b/Makefile
@@ -179,6 +179,10 @@ all::
# in one call to the platform's SHA1_Update(). e.g. APPLE_COMMON_CRYPTO
# wants 'SHA1_MAX_BLOCK_SIZE=1024L*1024L*1024L' defined.
#
+# Define BLK_SHA256 to use the built-in SHA-256 routines.
+#
+# Define GCRYPT_SHA256 to use the SHA-256 routines in libgcrypt.
+#
# Define NEEDS_CRYPTO_WITH_SSL if you need -lcrypto when using -lssl (Darwin).
#
# Define NEEDS_SSL_WITH_CRYPTO if you need -lssl when using -lcrypto (Darwin).
@@ -1624,8 +1628,13 @@ endif
endif
endif
-LIB_OBJS += sha256/block/sha256.o
-BASIC_CFLAGS += -DSHA256_BLK
+ifdef GCRYPT_SHA256
+ BASIC_CFLAGS += -DSHA256_GCRYPT
+ EXTLIBS += -lgcrypt
+else
+ LIB_OBJS += sha256/block/sha256.o
+ BASIC_CFLAGS += -DSHA256_BLK
+endif
ifdef SHA1_MAX_BLOCK_SIZE
LIB_OBJS += compat/sha1-chunked.o
diff --git a/hash.h b/hash.h
index 88d18896d7..9df562f2f6 100644
--- a/hash.h
+++ b/hash.h
@@ -15,7 +15,11 @@
#include "block-sha1/sha1.h"
#endif
+#if defined(SHA256_GCRYPT)
+#include "sha256/gcrypt.h"
+#else
#include "sha256/block/sha256.h"
+#endif
#ifndef platform_SHA_CTX
/*
diff --git a/sha256/gcrypt.h b/sha256/gcrypt.h
new file mode 100644
index 00..09bd8bb200
--- /dev/null
+++ b/sha256/gcrypt.h
@@ -0,0 +1,30 @@
+#ifndef SHA256_GCRYPT_H
+#define SHA256_GCRYPT_H
+
+#include
+
+#define SHA256_DIGEST_SIZE 32
+
+typedef gcry_md_hd_t gcrypt_SHA256_CTX;
+
+inline void gcrypt_SHA256_Init(gcrypt_SHA256_CTX *ctx)
+{
+ gcry_md_open(ctx, GCRY_MD_SHA256, 0);
+}
+
+inline void gcrypt_SHA256_Update(gcrypt_SHA256_CTX *ctx, const void *data,
size_t len)
+{
+ gcry_md_write(*ctx, data, len);
+}
+
+inline void gcrypt_SHA256_Final(unsigned char *digest, gcrypt_SHA256_CTX *ctx)
+{
+ memcpy(digest, gcry_md_read(*ctx, GCRY_MD_SHA256), SHA256_DIGEST_SIZE);
+}
+
+#define platform_SHA256_CTX gcrypt_SHA256_CTX
+#define platform_SHA256_Init gcrypt_SHA256_Init
+#define platform_SHA256_Update gcrypt_SHA256_Update
+#define platform_SHA256_Final gcrypt_SHA256_Final
+
+#endif
