From wk at gnupg.org Fri Apr 5 12:30:10 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Apr 2013 12:30:10 +0200 Subject: scrypt KDF support for libgcrypt In-Reply-To: <514C4794.6020001@in.tum.de> (Christian Grothoff's message of "Fri, 22 Mar 2013 12:59:16 +0100") References: <514C4794.6020001@in.tum.de> Message-ID: <87hajlb77x.fsf@vigenere.g10code.de> On Fri, 22 Mar 2013 12:59, grothoff at in.tum.de said: > I've hacked up an implementation of scrypt for libgcrypt based on > Simon's scrypt implementation in nettle. The code compiles on my It is now available in master. Note that I changed the value of GCRY_KDF_SCRYPT to help with the regression test. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Apr 5 18:32:55 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Apr 2013 18:32:55 +0200 Subject: q not derived from d in gcry_pk_sign In-Reply-To: <514C2223.2070106@in.tum.de> (Christian Grothoff's message of "Fri, 22 Mar 2013 10:19:31 +0100") References: <514C2223.2070106@in.tum.de> Message-ID: <878v4xaqfc.fsf@vigenere.g10code.de> On Fri, 22 Mar 2013 10:19, grothoff at in.tum.de said: > gcry_sexp_build (&spriv, &erroff, > "(private-key(ecc(curve \"NIST P-256\")(d %m)))", > d); > gcry_pk_sign (&result, data, spriv); > > to create a signature; this fails, as in 'sexp_elements_extract_ecc' the > 'q' value is not found (as it is neither in the curve nor explicitly in > the S-expression); however, q can of course be calculated as q = dg Actually for signing Q is not required at all. Thus we can do without it. I just pushed a change to master. There is new test case in tests/pubkey.c:check_ecc_sample_key . Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From shreeduth.awasthi at gmail.com Wed Apr 10 21:44:32 2013 From: shreeduth.awasthi at gmail.com (SHREE DUTH AWASTHI) Date: Thu, 11 Apr 2013 01:14:32 +0530 Subject: Initialization of secure memory ( Problem might be with libgcrypto ) Message-ID: Dear All, Please find few minutes from your time and guide us with some pointers if possible. The issue is similar to http://lists.gnupg.org/pipermail/gcrypt-devel/2008-December/001420.html ( Please see GDB output ) We are facing a libvirtd crash when we are trying to connect to qemu by default TLS transport. i.e libvirt crash when trying to inquiry libvirt version using curl with TLS # virsh -c qemu+tls://localhost/system version error: authentication failed: TLS handshake failed A TLS packet with unexpected length was received. error: failed to connect to the hypervisor I used my own CA and certificates (generated using http://libvirt.org/remote.html#Remote_libvirtd_configuration on Redhat PC) on both Kontron PC and our Board (with patched libvirt). Libvirtd.conf was modified so that libvirt is listening all IPs using default IP (so that it was possible to use same certificates on all machines) These directories and files created and used. /etc/pki/CA/cacert.pem /etc/pki/libvirt/private/serverkey.pem /etc/pki/libvirt/servercert.pem /etc/pki/libvirt/private/clientkey.pem /etc/pki/libvirt/clientcert.pem TLS connection worked fine with Kontron PC # virsh -c qemu+tls://localhost/system version Compiled against library: libvir 0.9.5 Using library: libvir 0.9.5 Using API: QEMU 0.9.5 Running hypervisor: QEMU 0.12.1 But libvirt crashed on our Board (using libvirt 0.10.2, gnutls-2.10.5-1_WR4.3.x86_64 and libudev-161-4 rpms ) # virsh -c qemu+tls://localhost/system version error: authentication failed: TLS handshake failed A TLS packet with unexpected length was received. error: failed to connect to the hypervisor GDB: Breakpoint 3, 0x00007f555bb07410 in gnutls_handshake () from /usr/lib64/libgnutls.so.26 (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x00007f555a096005 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007f555a096005 in raise () from /lib64/libc.so.6 #1 0x00007f555a098e40 in abort () from /lib64/libc.so.6 #2 0x00007f555b87fdc5 in _gcry_logv (level=50, fmt=0x7f555b8c6170 "*operation is not possible without initialized secure memory*\n", arg_ptr=0x7fff546e1130) at misc.c:136 #3 0x00007f555b8803d5 in _gcry_log_bug (fmt=0x48e0
) at misc.c:220 #4 0x00007f555b885697 in _gcry_secmem_malloc_internal (size=) at secmem.c:497 #5 0x00007f555b88579c in _gcry_secmem_malloc (size=136) at secmem.c:522 #6 0x00007f555b880a65 in do_malloc (n=18656, flags=, mem=0x7fff546e1290) at global.c:553 #7 0x00007f555b880aa9 in _gcry_malloc_secure (n=18656) at global.c:592 #8 0x00007f555b880b19 in _gcry_xmalloc_secure (n=136) at global.c:746 #9 0x00007f555b8c35df in _gcry_mpi_alloc_limb_space (nlimbs=17, secure=18656) at mpiutil.c:92 #10 0x00007f555b8c365f in _gcry_mpi_alloc_secure (nlimbs=17) at mpiutil.c:75 #11 0x00007f555b8b025a in secret (output=0x17cfa20, input=0x17d0480, skey=0x6) at rsa.c:365 #12 0x00007f555b8b045a in _gcry_rsa_sign (algo=, resarr=0x17d0660, data=0x17d0480, skey=) at rsa.c:608 #13 0x00007f555b88c1ef in pubkey_sign (r_sig=0x7fff546e1488, s_hash=, s_skey=) at pubkey.c:692 #14 _gcry_pk_sign (r_sig=0x7fff546e1488, s_hash=, s_skey=) at pubkey.c:1807 ---Type to continue, or q to quit--- #15 0x00007f555bb29d8c in ?? () from /usr/lib64/libgnutls.so.26 #16 0x00007f555bb15e7a in ?? () from /usr/lib64/libgnutls.so.26 #17 0x00007f555bb1ddd6 in ?? () from /usr/lib64/libgnutls.so.26 #18 0x00007f555bb1e67f in ?? () from /usr/lib64/libgnutls.so.26 #19 0x00007f555bb1edaf in ?? () from /usr/lib64/libgnutls.so.26 #20 0x00007f555bb0af85 in ?? () from /usr/lib64/libgnutls.so.26 #21 0x00007f555bb06c55 in ?? () from /usr/lib64/libgnutls.so.26 #22 0x00007f555bb07437 in gnutls_handshake () from /usr/lib64/libgnutls.so.26 #23 0x00007f555c8a961b in virNetTLSSessionHandshake () from /usr/lib64/libvirt.so.0 #24 0x00007f555c89ea2b in virNetServerClientInit () from /usr/lib64/libvirt.so.0 #25 0x00007f555c89c821 in ?? () from /usr/lib64/libvirt.so.0 #26 0x00007f555c8a012a in ?? () from /usr/lib64/libvirt.so.0 #27 0x00007f555c79fbf5 in virEventPollRunOnce () from /usr/lib64/libvirt.so.0 #28 0x00007f555c79e825 in virEventRunDefaultImpl () from /usr/lib64/libvirt.so.0 #29 0x00007f555c89c20d in virNetServerRun () from /usr/lib64/libvirt.so.0 #30 0x000000000040c830 in ?? () Please let us know if it is a known problem. If not, I will raise a new bug for the same. Thanking you in anticipation. Thanks and Regards, Shree Duth Awasthi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shreeduth.awasthi at gmail.com Thu Apr 11 12:38:11 2013 From: shreeduth.awasthi at gmail.com (SHREE DUTH AWASTHI) Date: Thu, 11 Apr 2013 12:38:11 +0200 Subject: Initialization of secure memory ( Problem might be with libgcrypto ) Message-ID: Dear All, Please find few minutes from your time and guide us with some pointers if possible. The issue is similar to http://lists.gnupg.org/pipermail/gcrypt-devel/2008-December/001420.html ( Please see GDB output ) We are facing a libvirtd crash when we are trying to connect to qemu by default TLS transport. i.e libvirt crash when trying to inquiry libvirt version using curl with TLS # virsh -c qemu+tls://localhost/system version error: authentication failed: TLS handshake failed A TLS packet with unexpected length was received. error: failed to connect to the hypervisor I used my own CA and certificates (generated using http://libvirt.org/remote.html#Remote_libvirtd_configuration on Redhat PC) on both Kontron PC and our Board (with patched libvirt). Libvirtd.conf was modified so that libvirt is listening all IPs using default IP (so that it was possible to use same certificates on all machines) These directories and files created and used. /etc/pki/CA/cacert.pem /etc/pki/libvirt/private/serverkey.pem /etc/pki/libvirt/servercert.pem /etc/pki/libvirt/private/clientkey.pem /etc/pki/libvirt/clientcert.pem TLS connection worked fine with Kontron PC # virsh -c qemu+tls://localhost/system version Compiled against library: libvir 0.9.5 Using library: libvir 0.9.5 Using API: QEMU 0.9.5 Running hypervisor: QEMU 0.12.1 But libvirt crashed on our Board (using libvirt 0.10.2, gnutls-2.10.5-1_WR4.3.x86_64 and libudev-161-4 rpms, libgcrypt-1.4.0-3_WR4.3.x86_64 ) # virsh -c qemu+tls://localhost/system version error: authentication failed: TLS handshake failed A TLS packet with unexpected length was received. error: failed to connect to the hypervisor GDB: Breakpoint 3, 0x00007f555bb07410 in gnutls_handshake () from /usr/lib64/libgnutls.so.26 (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x00007f555a096005 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007f555a096005 in raise () from /lib64/libc.so.6 #1 0x00007f555a098e40 in abort () from /lib64/libc.so.6 #2 0x00007f555b87fdc5 in _gcry_logv (level=50, fmt=0x7f555b8c6170 "*operation is not possible without initialized secure memory*\n", arg_ptr=0x7fff546e1130) at misc.c:136 #3 0x00007f555b8803d5 in _gcry_log_bug (fmt=0x48e0
) at misc.c:220 #4 0x00007f555b885697 in _gcry_secmem_malloc_internal (size=) at secmem.c:497 #5 0x00007f555b88579c in _gcry_secmem_malloc (size=136) at secmem.c:522 #6 0x00007f555b880a65 in do_malloc (n=18656, flags=, mem=0x7fff546e1290) at global.c:553 #7 0x00007f555b880aa9 in _gcry_malloc_secure (n=18656) at global.c:592 #8 0x00007f555b880b19 in _gcry_xmalloc_secure (n=136) at global.c:746 #9 0x00007f555b8c35df in _gcry_mpi_alloc_limb_space (nlimbs=17, secure=18656) at mpiutil.c:92 #10 0x00007f555b8c365f in _gcry_mpi_alloc_secure (nlimbs=17) at mpiutil.c:75 #11 0x00007f555b8b025a in secret (output=0x17cfa20, input=0x17d0480, skey=0x6) at rsa.c:365 #12 0x00007f555b8b045a in _gcry_rsa_sign (algo=, resarr=0x17d0660, data=0x17d0480, skey=) at rsa.c:608 #13 0x00007f555b88c1ef in pubkey_sign (r_sig=0x7fff546e1488, s_hash=, s_skey=) at pubkey.c:692 #14 _gcry_pk_sign (r_sig=0x7fff546e1488, s_hash=, s_skey=) at pubkey.c:1807 ---Type to continue, or q to quit--- #15 0x00007f555bb29d8c in ?? () from /usr/lib64/libgnutls.so.26 #16 0x00007f555bb15e7a in ?? () from /usr/lib64/libgnutls.so.26 #17 0x00007f555bb1ddd6 in ?? () from /usr/lib64/libgnutls.so.26 #18 0x00007f555bb1e67f in ?? () from /usr/lib64/libgnutls.so.26 #19 0x00007f555bb1edaf in ?? () from /usr/lib64/libgnutls.so.26 #20 0x00007f555bb0af85 in ?? () from /usr/lib64/libgnutls.so.26 #21 0x00007f555bb06c55 in ?? () from /usr/lib64/libgnutls.so.26 #22 0x00007f555bb07437 in gnutls_handshake () from /usr/lib64/libgnutls.so.26 #23 0x00007f555c8a961b in virNetTLSSessionHandshake () from /usr/lib64/libvirt.so.0 #24 0x00007f555c89ea2b in virNetServerClientInit () from /usr/lib64/libvirt.so.0 #25 0x00007f555c89c821 in ?? () from /usr/lib64/libvirt.so.0 #26 0x00007f555c8a012a in ?? () from /usr/lib64/libvirt.so.0 #27 0x00007f555c79fbf5 in virEventPollRunOnce () from /usr/lib64/libvirt.so.0 #28 0x00007f555c79e825 in virEventRunDefaultImpl () from /usr/lib64/libvirt.so.0 #29 0x00007f555c89c20d in virNetServerRun () from /usr/lib64/libvirt.so.0 #30 0x000000000040c830 in ?? () Please let us know if it is a known problem. If not, I will raise a new bug for the same. Thanking you in anticipation. Thanks and Regards, Shree Duth Awasthi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Apr 11 13:57:39 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Apr 2013 13:57:39 +0200 Subject: Initialization of secure memory ( Problem might be with libgcrypto ) In-Reply-To: (SHREE DUTH AWASTHI's message of "Thu, 11 Apr 2013 01:14:32 +0530") References: Message-ID: <87a9p546vg.fsf@vigenere.g10code.de> On Wed, 10 Apr 2013 21:44, shreeduth.awasthi at gmail.com said: > # virsh -c qemu+tls://localhost/system version > error: authentication failed: TLS handshake failed A TLS packet with > unexpected length was received. > error: failed to connect to the hypervisor You should ask the maintainer of virsh for help. This list is about libgcrypt. It seems that virsh does not make proper use of libgcrypt or gnutls. In fact, Libgcrypt tells you what has been done wrong. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Apr 11 20:41:26 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Apr 2013 20:41:26 +0200 Subject: requesting another ECC function... In-Reply-To: <514AFF9B.6010408@in.tum.de> (Christian Grothoff's message of "Thu, 21 Mar 2013 13:39:55 +0100") References: <514AFF9B.6010408@in.tum.de> Message-ID: <871uag52qx.fsf@vigenere.g10code.de> On Thu, 21 Mar 2013 13:39, grothoff at in.tum.de said: > I can manipulate 'Q' freely) to an S-expression. So what I need is > something like a function "gcry_sexp_from_ec_context", to be used as > follows: Here we go: Instead of > if (0 != (rc = gcry_sexp_from_ec_context (&pk_sexpr, ctx))) > { > LOG_GCRY (GNUNET_ERROR_TYPE_ERROR, "gcry_sexp_from_context", rc); > gcry_ctx_release (ctx); > gcry_sexp_release (data); > gcry_sexp_release (sig_sexpr); > return GNUNET_SYSERR; > } use this: if (0 != (rc = gcry_pubkey_get_sexp (&pk_sexpr, GCRY_PK_GET_PUBKEY, ctx))) { LOG_GCRY (GNUNET_ERROR_TYPE_ERROR, "gcry_pubkey_get_sexp", rc); gcry_ctx_release (ctx); gcry_sexp_release (data); gcry_sexp_release (sig_sexpr); return GNUNET_SYSERR; } Instead of GCRY_PK_GET_PUBKEY you might simply use 0, but that would return the private key if D is available in the contetx. Thus better request the public key explicit. Note that there are a few new error code, thus a gpg_strerror would return "unknown error code". If in doubt look at the number: #define GPG_ERR_NO_CRYPT_CTX 191 #define GPG_ERR_WRONG_CRYPT_CTX 192 #define GPG_ERR_BAD_CRYPT_CTX 193 #define GPG_ERR_CRYPT_CTX_CONFLICT 194 #define GPG_ERR_BROKEN_PUBKEY 195 #define GPG_ERR_BROKEN_SECKEY 196 You also need libgpg-error 1.11 now. Check out tests/t-mpi-point.c if you need examples. > Also, I noticed that there is point_get_affine, but no point_set_affine. > As creating an MPI with value "1" is inconvenient, it might be nice > (also for symmetry) to have a gcry_point_set_affine (x,y) API as well. I'll look at this later. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From grothoff at in.tum.de Thu Apr 11 21:27:50 2013 From: grothoff at in.tum.de (Christian Grothoff) Date: Thu, 11 Apr 2013 21:27:50 +0200 Subject: requesting another ECC function... In-Reply-To: <871uag52qx.fsf@vigenere.g10code.de> References: <514AFF9B.6010408@in.tum.de> <871uag52qx.fsf@vigenere.g10code.de> Message-ID: <51670EB6.3010909@in.tum.de> On 04/11/2013 08:41 PM, Werner Koch wrote: > On Thu, 21 Mar 2013 13:39, grothoff at in.tum.de said: > >> I can manipulate 'Q' freely) to an S-expression. So what I need is >> something like a function "gcry_sexp_from_ec_context", to be used as >> follows: > > Here we go: Instead of > >> if (0 != (rc = gcry_sexp_from_ec_context (&pk_sexpr, ctx))) >> { >> LOG_GCRY (GNUNET_ERROR_TYPE_ERROR, "gcry_sexp_from_context", rc); >> gcry_ctx_release (ctx); >> gcry_sexp_release (data); >> gcry_sexp_release (sig_sexpr); >> return GNUNET_SYSERR; >> } > > use this: > > if (0 != (rc = gcry_pubkey_get_sexp (&pk_sexpr, GCRY_PK_GET_PUBKEY, ctx))) > { > LOG_GCRY (GNUNET_ERROR_TYPE_ERROR, "gcry_pubkey_get_sexp", rc); > gcry_ctx_release (ctx); > gcry_sexp_release (data); > gcry_sexp_release (sig_sexpr); > return GNUNET_SYSERR; > } Almost there. This gives me an sexp of the form "(public-key(ecc(...))", but for gcry_pk_verify that corresponds to ECDH as a "(public-key(ecdsa(...))" is needed (I get a "not implemented" for gcry_pk_sign if I put 'ecc' instead of 'ecdsa'; the ECC code internally picks between ECDSA and ECDH depending on the form of the s-expression). So instead of just "GCRY_PK_GET_PUBKEY", we'll need "GCRY_PK_GET_ECDSA_PUBKEY" or "GCRY_PK_GET_ECDH_PUBKEY", as otherwise the "wrong" ECC module is selected. Happy hacking! Christian From christian at grothoff.org Thu Apr 11 21:37:13 2013 From: christian at grothoff.org (Christian Grothoff) Date: Thu, 11 Apr 2013 21:37:13 +0200 Subject: yet another tiny feature: deterministic ECDSA Message-ID: <516710E9.6090800@grothoff.org> Hi! I don't know if I mentioned this one yet. When I call 'gcry_pk_sign' for ECDSA signing, libgcrypt generates (as per ECDSA requirements) a random 'k' value each time. 'k' must be random as an adversary must not be able to determine 'k', and two signatures must not share the same 'k' to avoid exposing the private key. However, in our use, it happens that the same private key is used to sign the same private data more than once. Thus, it would be great if we could in that case generate exactly the same signature over the same data by using the same 'k' value. I can (safely) construct a pseudo-random seed/k-value that will be unique (and only known to those that know the private key anyway), but the current gcry_pk_sign API does not yet allow me to pass it. My suggestion is that we expand the S-expression with the data to sign. Right now, I pass a "(data(flags raw)(value ...))" input there; allowing me to pass an additional optional argument "(data(flags raw)(value ...)(k ...))" to achieve deterministic signature generation would be perfect. (This is not urgent, the ECDH/ECDSA issue is the important one for me right now). Happy hacking! Christian From christian at grothoff.org Thu Apr 11 21:59:17 2013 From: christian at grothoff.org (Christian Grothoff) Date: Thu, 11 Apr 2013 21:59:17 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <516714EB.1050408@gmail.com> References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> Message-ID: <51671615.7020308@grothoff.org> On 04/11/2013 09:54 PM, Vladimir '?-coder/phcoder' Serbinenko wrote: > On 11.04.2013 21:37, Christian Grothoff wrote: > >> Hi! >> >> I don't know if I mentioned this one yet. When I call 'gcry_pk_sign' for ECDSA signing, >> libgcrypt generates (as per ECDSA requirements) a random 'k' value each time. 'k' must >> be random as an adversary must not be able to determine 'k', and two signatures must not >> share the same 'k' to avoid exposing the private key. >> >> However, in our use, it happens that the same private key is used to sign the same >> private data more than once. Thus, it would be great if we could in that case generate >> exactly the same signature over the same data by using the same 'k' value. >> >> I can (safely) construct a pseudo-random seed/k-value that will be unique (and only >> known to those that know the private key anyway), but the current gcry_pk_sign API >> does not yet allow me to pass it. >> > > This is something which is very tricky to get right and exposes the > whole system if it isn't. I think the library shouldn't export such > primitives at all. Why isn't storing the signature appropriate for your > case? Because different peers create the signature independent of each other. The private key is actually the hash of a password / keyword in this case. And yes, I understand how dangerous this is in the wrong hands ;-). Happy hacking! Christian From phcoder at gmail.com Thu Apr 11 21:54:19 2013 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Thu, 11 Apr 2013 21:54:19 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <516710E9.6090800@grothoff.org> References: <516710E9.6090800@grothoff.org> Message-ID: <516714EB.1050408@gmail.com> On 11.04.2013 21:37, Christian Grothoff wrote: > Hi! > > I don't know if I mentioned this one yet. When I call 'gcry_pk_sign' for ECDSA signing, > libgcrypt generates (as per ECDSA requirements) a random 'k' value each time. 'k' must > be random as an adversary must not be able to determine 'k', and two signatures must not > share the same 'k' to avoid exposing the private key. > > However, in our use, it happens that the same private key is used to sign the same > private data more than once. Thus, it would be great if we could in that case generate > exactly the same signature over the same data by using the same 'k' value. > > I can (safely) construct a pseudo-random seed/k-value that will be unique (and only > known to those that know the private key anyway), but the current gcry_pk_sign API > does not yet allow me to pass it. > This is something which is very tricky to get right and exposes the whole system if it isn't. I think the library shouldn't export such primitives at all. Why isn't storing the signature appropriate for your case? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 294 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Apr 12 00:20:22 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Apr 2013 00:20:22 +0200 Subject: requesting another ECC function... In-Reply-To: <51670EB6.3010909@in.tum.de> (Christian Grothoff's message of "Thu, 11 Apr 2013 21:27:50 +0200") References: <514AFF9B.6010408@in.tum.de> <871uag52qx.fsf@vigenere.g10code.de> <51670EB6.3010909@in.tum.de> Message-ID: <8761zs3e1l.fsf@vigenere.g10code.de> On Thu, 11 Apr 2013 21:27, grothoff at in.tum.de said: > Almost there. This gives me an sexp of the form "(public-key(ecc(...))", > but for gcry_pk_verify that corresponds to ECDH as a "(public-key(ecdsa(...))" > is needed (I get a "not implemented" for gcry_pk_sign if I put 'ecc' instead of 'ecdsa'; Can you please try this patch. It may work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-hack-to-allow-using-an-ecc-key-for-ecdsa-or-ecdh.patch Type: text/x-diff Size: 5548 bytes Desc: not available URL: From phcoder at gmail.com Fri Apr 12 00:48:41 2013 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Fri, 12 Apr 2013 00:48:41 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <51671615.7020308@grothoff.org> References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> Message-ID: <51673DC9.7000703@gmail.com> On 11.04.2013 21:59, Christian Grothoff wrote: > On 04/11/2013 09:54 PM, Vladimir '?-coder/phcoder' Serbinenko wrote: >> On 11.04.2013 21:37, Christian Grothoff wrote: >> >>> Hi! >>> >>> I don't know if I mentioned this one yet. When I call 'gcry_pk_sign' for ECDSA signing, >>> libgcrypt generates (as per ECDSA requirements) a random 'k' value each time. 'k' must >>> be random as an adversary must not be able to determine 'k', and two signatures must not >>> share the same 'k' to avoid exposing the private key. >>> >>> However, in our use, it happens that the same private key is used to sign the same >>> private data more than once. Thus, it would be great if we could in that case generate >>> exactly the same signature over the same data by using the same 'k' value. >>> >>> I can (safely) construct a pseudo-random seed/k-value that will be unique (and only >>> known to those that know the private key anyway), but the current gcry_pk_sign API >>> does not yet allow me to pass it. >>> >> >> This is something which is very tricky to get right and exposes the >> whole system if it isn't. I think the library shouldn't export such >> primitives at all. Why isn't storing the signature appropriate for your >> case? > > Because different peers create the signature independent of each other. The private > key is actually the hash of a password / keyword in this case. And yes, I understand > how dangerous this is in the wrong hands ;-). > Sounds like you're trying to design a new protocol with pieces not really meant to be used this way. Why not just use a standard protocol? There are loads of standard protocols for nearly every possible use. > Happy hacking! > > Christian > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 294 bytes Desc: OpenPGP digital signature URL: From christian at grothoff.org Fri Apr 12 09:38:04 2013 From: christian at grothoff.org (Christian Grothoff) Date: Fri, 12 Apr 2013 09:38:04 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <51673DC9.7000703@gmail.com> References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> <51673DC9.7000703@gmail.com> Message-ID: <5167B9DC.5000302@grothoff.org> On 04/12/2013 12:48 AM, Vladimir '?-coder/phcoder' Serbinenko wrote: > Sounds like you're trying to design a new protocol with pieces not > really meant to be used this way. Let's say I'm certainly stretching common use. > Why not just use a standard protocol? There are loads of standard > protocols for nearly every possible use. But not for what we're doing. If you want to read up on the details, see https://gnunet.org/bugs/view.php?id=2564 -Christian From shreeduth.awasthi at gmail.com Fri Apr 12 11:08:09 2013 From: shreeduth.awasthi at gmail.com (SHREE DUTH AWASTHI) Date: Fri, 12 Apr 2013 11:08:09 +0200 Subject: Initialization of secure memory ( Problem might be with libgcrypto ) In-Reply-To: <87a9p546vg.fsf@vigenere.g10code.de> References: <87a9p546vg.fsf@vigenere.g10code.de> Message-ID: Hello Werner, Thanks a lot for your time. But I still doubt that the problem is with libcrypto (1.4.0.3) seeing the below log _gcry_log_bug (fmt=0x48e0
) Can you please eloborate your observation. Thanking you in anticipation. Thanks and Regards, Shree Duth Awasthi On Thu, Apr 11, 2013 at 1:57 PM, Werner Koch wrote: > On Wed, 10 Apr 2013 21:44, shreeduth.awasthi at gmail.com said: > > > # virsh -c qemu+tls://localhost/system version > > error: authentication failed: TLS handshake failed A TLS packet with > > unexpected length was received. > > error: failed to connect to the hypervisor > > You should ask the maintainer of virsh for help. This list is about > libgcrypt. It seems that virsh does not make proper use of libgcrypt or > gnutls. In fact, Libgcrypt tells you what has been done wrong. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phcoder at gmail.com Fri Apr 12 13:06:01 2013 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Fri, 12 Apr 2013 13:06:01 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <5167B9DC.5000302@grothoff.org> References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> <51673DC9.7000703@gmail.com> <5167B9DC.5000302@grothoff.org> Message-ID: <5167EA99.5090802@gmail.com> On 12.04.2013 09:38, Christian Grothoff wrote: > On 04/12/2013 12:48 AM, Vladimir '?-coder/phcoder' Serbinenko wrote: >> Sounds like you're trying to design a new protocol with pieces not >> really meant to be used this way. > Let's say I'm certainly stretching common use. >> Why not just use a standard protocol? There are loads of standard >> protocols for nearly every possible use. > But not for what we're doing. If you want to read up on the > details, see https://gnunet.org/bugs/view.php?id=2564 > It sounds like you just need salted hash or HMAC if I understand the algorithm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 294 bytes Desc: OpenPGP digital signature URL: From christian at grothoff.org Fri Apr 12 13:13:20 2013 From: christian at grothoff.org (Christian Grothoff) Date: Fri, 12 Apr 2013 13:13:20 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <5167EA99.5090802@gmail.com> References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> <51673DC9.7000703@gmail.com> <5167B9DC.5000302@grothoff.org> <5167EA99.5090802@gmail.com> Message-ID: <5167EC50.5000207@grothoff.org> On 04/12/2013 01:06 PM, Vladimir '?-coder/phcoder' Serbinenko wrote: >>> Why not just use a standard protocol? There are loads of standard >>> protocols for nearly every possible use. >> But not for what we're doing. If you want to read up on the >> details, see https://gnunet.org/bugs/view.php?id=2564 >> > It sounds like you just need salted hash or HMAC if I understand the > algorithm > > No, that's insufficient as the encrypted message must be verifiable for intermediaries that do not have access to the key, so public key crypto is required. Christian From phcoder at gmail.com Fri Apr 12 13:58:50 2013 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Fri, 12 Apr 2013 13:58:50 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <5167EC50.5000207@grothoff.org> References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> <51673DC9.7000703@gmail.com> <5167B9DC.5000302@grothoff.org> <5167EA99.5090802@gmail.com> <5167EC50.5000207@grothoff.org> Message-ID: <5167F6FA.9090401@gmail.com> On 12.04.2013 13:13, Christian Grothoff wrote: > On 04/12/2013 01:06 PM, Vladimir '?-coder/phcoder' Serbinenko wrote: >>>> Why not just use a standard protocol? There are loads of standard >>>> protocols for nearly every possible use. >>> But not for what we're doing. If you want to read up on the >>> details, see https://gnunet.org/bugs/view.php?id=2564 >>> >> It sounds like you just need salted hash or HMAC if I understand the >> algorithm >> >> > No, that's insufficient as the encrypted message must be verifiable for > intermediaries that do > not have access to the key, so public key crypto is required. > Then sign in top of it. Thing is any non-randomness in DSA parameters, no matter how small, is exploitable > Christian > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 294 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Apr 12 13:55:21 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 12 Apr 2013 13:55:21 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <5167B9DC.5000302@grothoff.org> (Christian Grothoff's message of "Fri, 12 Apr 2013 09:38:04 +0200") References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> <51673DC9.7000703@gmail.com> <5167B9DC.5000302@grothoff.org> Message-ID: <87obdk0xqu.fsf@vigenere.g10code.de> On Fri, 12 Apr 2013 09:38, christian at grothoff.org said: > But not for what we're doing. If you want to read up on the > details, see https://gnunet.org/bugs/view.php?id=2564 What is your plan if you have to use a K which leads to either R or S being 0? ECDSA loops until it finds a suitable K. Agreed, this is a rare event but you better need to have a plan. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at grothoff.org Fri Apr 12 15:18:25 2013 From: christian at grothoff.org (Christian Grothoff) Date: Fri, 12 Apr 2013 15:18:25 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <5167F6FA.9090401@gmail.com> References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> <51673DC9.7000703@gmail.com> <5167B9DC.5000302@grothoff.org> <5167EA99.5090802@gmail.com> <5167EC50.5000207@grothoff.org> <5167F6FA.9090401@gmail.com> Message-ID: <516809A1.2070402@grothoff.org> On 04/12/2013 01:58 PM, Vladimir '?-coder/phcoder' Serbinenko wrote: >> No, that's insufficient as the encrypted message must be verifiable for >> intermediaries that do >> not have access to the key, so public key crypto is required. >> > Then sign in top of it. Thing is any non-randomness in DSA parameters, > no matter how small, is exploitable I believe a 'k' value derived via cryptographic hash (of data that the adversary does not have) function will be sufficiently random. After all, the *secret* 'd' is derived by the same method in our application. Signing on top of it doesn't help, as I want identical binary output --- if two users share the same file (or file meta data in this case), the resulting data in the database should also be identical so that I can detect duplicates. -Christian From christian at grothoff.org Fri Apr 12 15:24:45 2013 From: christian at grothoff.org (Christian Grothoff) Date: Fri, 12 Apr 2013 15:24:45 +0200 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> <51673DC9.7000703@gmail.com> <5167B9DC.5000302@grothoff.org> <87obdk0xqu.fsf@vigenere.g10code.de> Message-ID: <51680B1D.1090901@grothoff.org> On 04/12/2013 01:55 PM, Werner Koch wrote: > On Fri, 12 Apr 2013 09:38, christian at grothoff.org said: > >> But not for what we're doing. If you want to read up on the >> details, see https://gnunet.org/bugs/view.php?id=2564 > What is your plan if you have to use a K which leads to either R or S > being 0? ECDSA loops until it finds a suitable K. Agreed, this is a > rare event but you better need to have a plan. Well, I considered it rare enough to not care (if we fail in 1:2^256, that's fine by me), but this has already been answered: On 04/12/2013 03:16 PM, Tom Ritter wrote: > > There is a method to do deterministic DSA safely (as far as anyone > knows), that's been looked at some: > http://tools.ietf.org/html/draft-pornin-deterministic-dsa-01 > > -tom > Using this method would be fine by me as well; I can supply 'h1' (the H(m)) instead of the exact 'k' value. What I care about is having an option to achieve determinism. Also, as in our case 'm' itself is encrypted before being signed, I'd like to do the hashing myself as using h1 = H(E(m)) will give the adversary (who doesn't know 'm') more information about 'k' than simply using h1 = H(m). Happy hacking! Christian From tom at ritter.vg Fri Apr 12 15:16:18 2013 From: tom at ritter.vg (Tom Ritter) Date: Fri, 12 Apr 2013 09:16:18 -0400 Subject: yet another tiny feature: deterministic ECDSA In-Reply-To: <87obdk0xqu.fsf@vigenere.g10code.de> References: <516710E9.6090800@grothoff.org> <516714EB.1050408@gmail.com> <51671615.7020308@grothoff.org> <51673DC9.7000703@gmail.com> <5167B9DC.5000302@grothoff.org> <87obdk0xqu.fsf@vigenere.g10code.de> Message-ID: There is a method to do deterministic DSA safely (as far as anyone knows), that's been looked at some: http://tools.ietf.org/html/draft-pornin-deterministic-dsa-01 -tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Apr 15 11:58:55 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Apr 2013 11:58:55 +0200 Subject: requesting another ECC function... In-Reply-To: <514AFF9B.6010408@in.tum.de> (Christian Grothoff's message of "Thu, 21 Mar 2013 13:39:55 +0100") References: <514AFF9B.6010408@in.tum.de> Message-ID: <87wqs4xggw.fsf@vigenere.g10code.de> On Thu, 21 Mar 2013 13:39, grothoff at in.tum.de said: > Also, I noticed that there is point_get_affine, but no point_set_affine. > As creating an MPI with value "1" is inconvenient, it might be nice > (also for symmetry) to have a gcry_point_set_affine (x,y) API as well. You may now use gcry_mpi_ec_set_point (point, x, y, GCRYMPI_CONST_ONE); to gain the same effect. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Apr 18 15:28:51 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Apr 2013 15:28:51 +0200 Subject: broken sed in 1.5.1 cipher/Makefile.am In-Reply-To: (Andreas Metzler's message of "Thu, 21 Mar 2013 20:11:54 +0100") References: Message-ID: <87k3o0ufvw.fsf@vigenere.g10code.de> On Thu, 21 Mar 2013 20:11, ametzler at downhill.at.eu.org said: > Hello, > > 1.5.1 has this change compared to 1.5.0: > -o_flag_munging = sed -e 's/-O[2-9s]*/-O1/g' > +o_flag_munging = sed -e 's/-O([2-9s]|fast)*/-O1/g' > > I think the changed line should read > > +o_flag_munging = sed -e 's/-O([2-9s]*|fast)/-O1/g' I think the right fix is: -o_flag_munging = sed -e 's/-O([2-9s]|fast)*/-O1/g' +o_flag_munging = sed -e 's/-O\([2-9s][2-9s]*\)/-O1/' -e 's/-Ofast/-O1/g' The previous fix and your fix matches on the parenthesis which is not want we want. The original code didn't worked either because it transforms an -O1 into -O11. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Apr 18 17:38:56 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 18 Apr 2013 17:38:56 +0200 Subject: Libgcrypt 1.5.2 released Message-ID: <87y5cfu9v3.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.5.2. This is a maintenance release for the stable branch. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.5.2: * Added support for IDEA. * Made the Padlock code work again (regression since 1.5.0). * Fixed alignment problems for Serpent. * Fixed two bugs in ECC computations. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2.tar.bz2 (1.5M) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2.tar.gz (1.8M) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.2.tar.gz.sig Alternativley you may upgrade version 1.5.1 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.1-1.5.2.diff.bz2 (12k) The SHA-1 checksums are: c9998383532ba3e8bcaf690f2f0d65e814b48d2f libgcrypt-1.5.2.tar.bz2 fb54bfea3e276a366009c5a6296eb83cf5e7c14b libgcrypt-1.5.2.tar.gz 086ac76cf91987f66666872cc7d5d5d33c68967e libgcrypt-1.5.1-1.5.2.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] See http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From wk at gnupg.org Fri Apr 19 18:12:11 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 19 Apr 2013 18:12:11 +0200 Subject: Wrong use of -export-symbols in src/Makefile.am In-Reply-To: <514B22E6.108@gmail.com> (LRN's message of "Thu, 21 Mar 2013 19:10:30 +0400") References: <5149E1C6.2060106@gmail.com> <8738vpvwxs.fsf@vigenere.g10code.de> <514AEEF3.6090609@gmail.com> <87li9gvmtp.fsf@vigenere.g10code.de> <514B22E6.108@gmail.com> Message-ID: <87mwsuqz38.fsf@vigenere.g10code.de> On Thu, 21 Mar 2013 16:10, lrn1986 at gmail.com said: > libgcrypt does not require porting (which is good!). It only has some > small hiccups in the buildsystem: .def file EXPORTS placement, libdir > creation, and fig2dev detection - that's all. I just posted a patch to gpg4win-devel which might solve the problem. In any case a fix needs to be send upstream so that the next libtoolize won't destroy our fixed version. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-libtool-to-correctly-detect-.def-files.patch Type: text/x-diff Size: 4909 bytes Desc: not available URL: