From gniibe at fsij.org Tue Feb 1 07:47:52 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 01 Feb 2011 15:47:52 +0900 Subject: Gnuk version 0.9 Message-ID: <4D47AC98.3040407@fsij.org> Gnuk version 0.9 is out. Gnuk is a software for USB Token which follows OpenPGP card protocol version 2. It runs on STM32 processor. Highlights are: * New board support: STBee (512KB flash ROM) * Card Holder Certificate support * Experimental PIN-pad modification for unblocking pass phrase Note that GnuPG is not yet ready for latter two. Card Holder Certificate is a problematic, since Gnuk uses extended APDU and GnuPG doesn't yet fully ready for extended APDU. As an experiment, I created my certificate signing request by gpgsm --gen-key and put it on CAcert.org. The size of my certificate is 1328 byte. This is larger for some buffer of GnuPG. For example, we have buffer of size 1024 in the function handle_transmit scd/pcsc-wrapper.c. Possibly, we have other places to be fixed. I will report this issue by another e-mail. You can download Gnuk from: http://www.gniibe.org/oitoite/gnuk/ Please visit at http://www.fsij.org/gnuk/ for Gnuk news. -- From wk at gnupg.org Wed Feb 2 16:33:58 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Feb 2011 16:33:58 +0100 Subject: ECC code now in Libgcrypt master Message-ID: <87vd12jvrt.fsf@vigenere.g10code.de> Hi, now that GnuPG has successfully imported sample keys and processed ECC messages, it was time to merge the ECC changes back into Libgcrypt master. There are two new functions. If you plan to build the GnuPG ECC-INTEGRATION-2-1 branch, you should install this Libgcrypt version before configuring GnuPG. It is not anymore sufficient to use LD_LIBRARY_PATH to use switch at runtime to an ECC enabled version of Libgcrypt. Without those functions import and export of secret keys won't work. The rest of the code should still work. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bjk at luxsci.net Thu Feb 3 02:36:23 2011 From: bjk at luxsci.net (Ben Kibbey) Date: Wed, 2 Feb 2011 20:36:23 -0500 Subject: [PATCH] assuan_socket_connect_fd(). In-Reply-To: <1296696983-26945-1-git-send-email-bjk@luxsci.net> References: <1296696983-26945-1-git-send-email-bjk@luxsci.net> Message-ID: <201102030137.p131b42h029452@rs91.luxsci.com> --- src/assuan-socket-connect.c | 98 ++++++++++++++++++++++++++++--------------- src/assuan.h.in | 4 ++ src/libassuan.def | 1 + src/libassuan.vers | 1 + 4 files changed, 70 insertions(+), 34 deletions(-) diff --git a/src/assuan-socket-connect.c b/src/assuan-socket-connect.c index 609813d..1fdba6c 100644 --- a/src/assuan-socket-connect.c +++ b/src/assuan-socket-connect.c @@ -97,6 +97,69 @@ parse_portno (const char *str, uint16_t *r_port) } +static gpg_error_t +_assuan_connect_finalize(assuan_context_t ctx, int fd, unsigned int flags) +{ + gpg_error_t err; + + ctx->engine.release = _assuan_client_release; + ctx->engine.readfnc = _assuan_simple_read; + ctx->engine.writefnc = _assuan_simple_write; + ctx->engine.sendfd = NULL; + ctx->engine.receivefd = NULL; + ctx->finish_handler = _assuan_client_finish; + ctx->inbound.fd = fd; + ctx->outbound.fd = fd; + ctx->max_accepts = -1; + + if (flags & ASSUAN_SOCKET_CONNECT_FDPASSING) + _assuan_init_uds_io (ctx); + + /* initial handshake */ + { + assuan_response_t response; + int off; + + err = _assuan_read_from_server (ctx, &response, &off, 0); + if (err) + TRACE1 (ctx, ASSUAN_LOG_SYSIO, "assuan_socket_connect", ctx, + "can't connect to server: %s\n", gpg_strerror (err)); + else if (response != ASSUAN_RESPONSE_OK) + { + char *sname = _assuan_encode_c_string (ctx, ctx->inbound.line); + if (sname) + { + TRACE1 (ctx, ASSUAN_LOG_SYSIO, "assuan_socket_connect", ctx, + "can't connect to server: %s", sname); + _assuan_free (ctx, sname); + } + err = _assuan_error (ctx, GPG_ERR_ASS_CONNECT_FAILED); + } + } + + return err; +} + + +/* Attach an existing connected file descriptor FD to an allocated handle CTX + * and initialize the connection. + */ +gpg_error_t +assuan_socket_connect_fd (assuan_context_t ctx, int fd, unsigned int flags) +{ + gpg_error_t err; + + if (!ctx || fd < 0) + return GPG_ERR_INV_ARG; + + err = _assuan_connect_finalize(ctx, fd, flags); + + if (err) + _assuan_reset (ctx); + + return err; +} + /* Make a connection to the Unix domain socket NAME and return a new Assuan context in CTX. SERVER_PID is currently not used but may @@ -268,41 +331,8 @@ assuan_socket_connect (assuan_context_t ctx, const char *name, return _assuan_error (ctx, GPG_ERR_ASS_CONNECT_FAILED); } - ctx->engine.release = _assuan_client_release; - ctx->engine.readfnc = _assuan_simple_read; - ctx->engine.writefnc = _assuan_simple_write; - ctx->engine.sendfd = NULL; - ctx->engine.receivefd = NULL; - ctx->finish_handler = _assuan_client_finish; - ctx->inbound.fd = fd; - ctx->outbound.fd = fd; - ctx->max_accepts = -1; + err = _assuan_connect_finalize(ctx, fd, flags); - if (flags & ASSUAN_SOCKET_CONNECT_FDPASSING) - _assuan_init_uds_io (ctx); - - /* initial handshake */ - { - assuan_response_t response; - int off; - - err = _assuan_read_from_server (ctx, &response, &off, 0); - if (err) - TRACE1 (ctx, ASSUAN_LOG_SYSIO, "assuan_socket_connect", ctx, - "can't connect to server: %s\n", gpg_strerror (err)); - else if (response != ASSUAN_RESPONSE_OK) - { - char *sname = _assuan_encode_c_string (ctx, ctx->inbound.line); - if (sname) - { - TRACE1 (ctx, ASSUAN_LOG_SYSIO, "assuan_socket_connect", ctx, - "can't connect to server: %s", sname); - _assuan_free (ctx, sname); - } - err = _assuan_error (ctx, GPG_ERR_ASS_CONNECT_FAILED); - } - } - if (err) _assuan_reset (ctx); diff --git a/src/assuan.h.in b/src/assuan.h.in index 018d5a1..e686c5a 100644 --- a/src/assuan.h.in +++ b/src/assuan.h.in @@ -356,6 +356,10 @@ gpg_error_t assuan_pipe_connect (assuan_context_t ctx, gpg_error_t assuan_socket_connect (assuan_context_t ctx, const char *name, pid_t server_pid, unsigned int flags); +/*-- assuan-socket-connect.c --*/ +gpg_error_t assuan_socket_connect_fd (assuan_context_t ctx, int fd, + unsigned int flags); + /*-- context.c --*/ pid_t assuan_get_pid (assuan_context_t ctx); struct _assuan_peercred diff --git a/src/libassuan.def b/src/libassuan.def index a2e7b61..b2ddc25 100644 --- a/src/libassuan.def +++ b/src/libassuan.def @@ -103,6 +103,7 @@ EXPORTS _assuan_w32ce_finish_pipe @82 __assuan_socket @83 __assuan_connect @84 + assuan_socket_connect_fd @85 ; END diff --git a/src/libassuan.vers b/src/libassuan.vers index b14a940..b179828 100644 --- a/src/libassuan.vers +++ b/src/libassuan.vers @@ -24,6 +24,7 @@ LIBASSUAN_1.1 { global: __assuan_socket; __assuan_connect; + assuan_socket_connect_fd; }; LIBASSUAN_1.0 { -- 1.7.2.3 From bjk at luxsci.net Thu Feb 3 02:36:22 2011 From: bjk at luxsci.net (Ben Kibbey) Date: Wed, 2 Feb 2011 20:36:22 -0500 Subject: [PATCH] assuan_socket_connect_fd(). Message-ID: <201102030137.p131b43h029439@rs91.luxsci.com> Attaches an existing connected file descriptor to an allocated assuan_context_t. I have an app that uses libssh2 to connect to a remote server over an SSH channel that executes a proxy to the server unix domain socket. The server and client use the assuan protocol. Since the connection needs to be done via SSH client hooks are needed for socket read and write operations and the assuan context doesnt need to be connected by using the other assuan functions. It only needs the protocol handshake done. Attached is a patch to do this. Thanks! From wk at gnupg.org Thu Feb 3 17:54:41 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Feb 2011 17:54:41 +0100 Subject: ECC code now in GnuPG master In-Reply-To: <87vd12jvrt.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 02 Feb 2011 16:33:58 +0100") References: <87vd12jvrt.fsf@vigenere.g10code.de> Message-ID: <87zkqdhxda.fsf@vigenere.g10code.de> Hi, after some cleanup Andrey's ECC code has been merged into GnuPG master (aka 2.1). The latest commit also adds an extended algorithm selection menu, which shows up like this: $ ~/b/gnupg/g10/gpg2 --expert --gen-key Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECDSA and ECDH (10) ECDSA (sign only) (11) ECDSA (set your own capabilities) Note that the --expert option is required to allow the generation of ECC keys. When using the addkey sub-command of --edit-key, the list shows up like this: gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECDSA (sign only) (11) ECDSA (set your own capabilities) (12) ECDH (encrypt only) Not ethat there are likely a couple of bugs left. A quick test shows that 521 bit encryption keys can't be generated. Please note that this ECC support is really new and shall not be used to create production quality keys. A code audit is required and we also need to do compliance testing with other implementations. Remember to build and install the latest Libgcrypt master before configuring GnuPG. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From calestyo at scientia.net Thu Feb 3 19:27:43 2011 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Thu, 03 Feb 2011 19:27:43 +0100 Subject: ECC code now in GnuPG master In-Reply-To: <87zkqdhxda.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> Message-ID: <1296757663.3271.26.camel@fermat.scientia.net> Hey... Very nice :) On Thu, 2011-02-03 at 17:54 +0100, Werner Koch wrote: > after some cleanup Andrey's ECC code has been merged into GnuPG master > (aka 2.1). The latest commit also adds an extended algorithm selection > menu, which shows up like this: So this is now already the "main" 2.1 tree or a copy of that one? Do we have already any expectations when the ID goes RFC? > Not ethat there are likely a couple of bugs left. A quick test shows > that 521 bit encryption keys can't be generated. What's the suggested keysizes,... and which are supported by gpg? > Please note that this ECC support is really new and shall not be used to > create production quality keys. A code audit is required and we also > need to do compliance testing with other implementations. Is there already an audit planned? Who will do it? And are there any other implementations having ECC? Is there a list of things which may not work (if any)? E.g. things like, can you sign RSA/DSA keys with an ECC key, etc. pp. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5677 bytes Desc: not available URL: From dshaw at jabberwocky.com Thu Feb 3 20:13:55 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 3 Feb 2011 14:13:55 -0500 Subject: ECC code now in GnuPG master In-Reply-To: <87zkqdhxda.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> Message-ID: <3619D52D-9EF5-405D-8779-4F9EEE8794B6@jabberwocky.com> On Feb 3, 2011, at 11:54 AM, Werner Koch wrote: > Hi, > > after some cleanup Andrey's ECC code has been merged into GnuPG master > (aka 2.1). This is excellent! I'm very pleased to see it merged in. Congratulations to everyone involved. David From wk at gnupg.org Thu Feb 3 21:16:16 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Feb 2011 21:16:16 +0100 Subject: ECC code now in GnuPG master In-Reply-To: <1296757663.3271.26.camel@fermat.scientia.net> (Christoph Anton Mitterer's message of "Thu, 03 Feb 2011 19:27:43 +0100") References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <1296757663.3271.26.camel@fermat.scientia.net> Message-ID: <87pqr8j2lr.fsf@vigenere.g10code.de> On Thu, 3 Feb 2011 19:27, calestyo at scientia.net said: > So this is now already the "main" 2.1 tree or a copy of that one? master; currently known as 2.1/ > Do we have already any expectations when the ID goes RFC? No idea. However the (former) WG already accepted this draft. I guess it is up to Andrey to proceed with the RFC process. > What's the suggested keysizes,... and which are supported by gpg? The default is 256, which uses the NIST P-256 curve. Other supported curves are NIST P-384 and NIST P-521. We could also add other curves as long as an OID is available and a user interface is written. However, I believe that proliferation of curves is a bad idea. In contrast to RSA key sizes, the application needs to know the curve parameters as they are not part of the key. > Is there already an audit planned? Who will do it? I will for sure look over the code again but I was more thinking of an independent audit. > And are there any other implementations having ECC? AFAICR, Andrey once wrote the support for the PGP SDK; I have no information what happened to it at Symantec. > Is there a list of things which may not work (if any)? > E.g. things like, can you sign RSA/DSA keys with an ECC key, etc. pp. It is part of OpenPGP and there are no restrictions except for the key capabilities; i.e. like Elgamal you can't use ECDH for the primary key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From calestyo at scientia.net Thu Feb 3 21:33:34 2011 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Thu, 03 Feb 2011 21:33:34 +0100 Subject: ECC code now in GnuPG master In-Reply-To: <87pqr8j2lr.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <1296757663.3271.26.camel@fermat.scientia.net> <87pqr8j2lr.fsf@vigenere.g10code.de> Message-ID: <1296765214.3271.36.camel@fermat.scientia.net> On Thu, 2011-02-03 at 21:16 +0100, Werner Koch wrote: > > Is there already an audit planned? Who will do it? > > I will for sure look over the code again but I was more thinking of an > independent audit. The more the better =) Anyway,... nice to see that things are moving forward with respect to ecc.... Next thing is hopefully: cat rfc4880.txt | sed s/sha-1/somethingBetter/ ;) Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5677 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 3 22:16:21 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Feb 2011 22:16:21 +0100 Subject: ECC code now in GnuPG master In-Reply-To: <3619D52D-9EF5-405D-8779-4F9EEE8794B6@jabberwocky.com> (David Shaw's message of "Thu, 3 Feb 2011 14:13:55 -0500") References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <3619D52D-9EF5-405D-8779-4F9EEE8794B6@jabberwocky.com> Message-ID: <87ei7oiztm.fsf@vigenere.g10code.de> On Thu, 3 Feb 2011 20:13, dshaw at jabberwocky.com said: > This is excellent! I'm very pleased to see it merged in. Congratulations to everyone involved. It turned out that in the end the required changes were not that big. With that in mind I am toying with the idea of a GnuPG 1.5 to replace 1.4 with only one change: Replace the internal crypto code by Libgcrypt. This has the advantage that we can take advantage of Libgcrypt improvements automatically and don't need to backport delicate code. The disadvantage is of course the extra dependency. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cstras at ameslab.gov Thu Feb 3 21:20:10 2011 From: cstras at ameslab.gov (Chris Strasburg) Date: Thu, 03 Feb 2011 14:20:10 -0600 Subject: Append option for detached signatures: Message-ID: <4D4B0DFA.5040806@ameslab.gov> Hi all, I'm new to this list, but have been using (and promoting) GPG for a few years now. A few people at our laboratory are interested in electronic document signing and forms routing (e.g. multiple people signing a document in order, after verifying preceding signatures), and I've been pushing to use GPG for this task. One piece which would streamline this process for us would be the ability to detach-sign *and* append said signature to the detached file in a single step. I implemented the changes below (against the 2.0.17 source), to give an idea of what we are looking for. I wasn't trying to make this robust or directly implementable, but I am interested in feedback on whether this is the right approach to take. I'm happy to spend some time putting a real update together if it makes sense to do that. If anyone has suggestions, either toward something that could be officially included, or a different approach altogether, that would be really helpful! Thanks, Chris === diff -Naur gnupg-2.0.17/common/iobuf.c gnupg-2.0.17-detachappend/common/iobuf.c --- gnupg-2.0.17/common/iobuf.c 2011-01-09 16:06:15.000000000 -0600 +++ gnupg-2.0.17-detachappend/common/iobuf.c 2011-02-03 14:05:00.000000000 -0600 @@ -325,6 +325,11 @@ return INVALID_FP; oflag = O_WRONLY | O_CREAT | O_TRUNC; } + else if ( strchr (mode, 'a') ) { // Open as append file + if(fd_cache_invalidate (fname)) + return INVALID_FP; + oflag = O_WRONLY | O_CREAT | O_APPEND; + } else { oflag = O_RDONLY; @@ -1440,7 +1445,6 @@ * cannot be used for stdout. * Note: This is not used. */ -#if 0 /* not used */ iobuf_t iobuf_append (const char *fname) { @@ -1454,10 +1458,10 @@ else if (!(fp = my_fopen (fname, "ab"))) return NULL; a = iobuf_alloc (2, IOBUF_BUFFER_SIZE); - fcx = m_alloc (sizeof *fcx + strlen (fname)); + fcx = xmalloc (sizeof *fcx + strlen (fname)); fcx->fp = fp; strcpy (fcx->fname, fname); - a->real_fname = m_strdup (fname); + a->real_fname = xstrdup (fname); a->filter = file_filter; a->filter_ov = fcx; file_filter (fcx, IOBUFCTRL_DESC, NULL, (byte *) & a->desc, &len); @@ -1468,7 +1472,6 @@ return a; } -#endif iobuf_t iobuf_openrw (const char *fname) diff -Naur gnupg-2.0.17/g10/main.h gnupg-2.0.17-detachappend/g10/main.h --- gnupg-2.0.17/g10/main.h 2011-01-09 16:06:16.000000000 -0600 +++ gnupg-2.0.17-detachappend/g10/main.h 2011-02-03 13:50:14.000000000 -0600 @@ -242,6 +242,7 @@ /*-- openfile.c --*/ int overwrite_filep( const char *fname ); +int append_filep( const char *fname ); char *make_outfile_name( const char *iname ); char *ask_outfile_name( const char *name, size_t namelen ); int open_outfile( const char *iname, int mode, iobuf_t *a ); diff -Naur gnupg-2.0.17/g10/openfile.c gnupg-2.0.17-detachappend/g10/openfile.c --- gnupg-2.0.17/g10/openfile.c 2011-01-09 16:06:16.000000000 -0600 +++ gnupg-2.0.17-detachappend/g10/openfile.c 2011-02-03 13:50:14.000000000 -0600 @@ -95,6 +95,44 @@ return 0; } +/**************** + * Check whether FNAME exists and ask if it's okay to append to the + * existing one. + * Returns: 2: it's okay to append or the file does not exist + * 0: Do not append + */ +int +append_filep( const char *fname ) +{ + if( iobuf_is_pipe_filename (fname) ) + return 0; /* Cannot append to stdout */ + + if( access( fname, F_OK ) ) + return 2; /* does not exist; same as create */ + +#ifndef HAVE_DOSISH_SYSTEM + if ( !strcmp ( fname, "/dev/null" ) ) + return 2; /* does not do any harm */ +#endif +#ifdef HAVE_W32_SYSTEM + if ( !strcmp ( fname, "nul" ) ) + return 2; +#endif + + if( opt.answer_yes ) + return 2; + if( opt.answer_no || opt.batch ) + return 0; /* do not append */ + + tty_printf(_("File `%s' exists. "), fname); + if( cpr_enabled () ) + tty_printf ("\n"); + if( cpr_get_answer_is_yes("openfile.append.okay", + _("Append to file? (y/N) ")) ) + return 2; + return 0; +} + /**************** * Strip known extensions from iname and return a newly allocated @@ -183,6 +221,7 @@ open_outfile( const char *iname, int mode, IOBUF *a ) { int rc = 0; + int modify; *a = NULL; if( iobuf_is_pipe_filename (iname) && !opt.outfile ) { @@ -247,7 +286,8 @@ } rc = 0; - while( !overwrite_filep (name) ) + modify = 0; // Remember answer to append/overwrite + while( !( ((mode == 2) && (modify = append_filep(name))) || (modify = overwrite_filep (name)))) { char *tmp = ask_outfile_name (NULL, 0); if ( !tmp || !*tmp ) @@ -267,12 +307,14 @@ *a = NULL; errno = EPERM; } + else if (modify == 2) + *a = iobuf_append( name ); else *a = iobuf_create( name ); if( !*a ) { rc = gpg_error_from_syserror (); - log_error(_("can't create `%s': %s\n"), name, strerror(errno) ); + log_error(_("can't create/append `%s': %s\n"), name, strerror(errno) ); } else if( opt.verbose ) log_info(_("writing to `%s'\n"), name ); -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From calestyo at scientia.net Thu Feb 3 22:28:00 2011 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Thu, 03 Feb 2011 22:28:00 +0100 Subject: ECC code now in GnuPG master In-Reply-To: <87ei7oiztm.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <3619D52D-9EF5-405D-8779-4F9EEE8794B6@jabberwocky.com> <87ei7oiztm.fsf@vigenere.g10code.de> Message-ID: <1296768480.3271.39.camel@fermat.scientia.net> On Thu, 2011-02-03 at 22:16 +0100, Werner Koch wrote: > With that in mind I am toying with the idea of a GnuPG 1.5 to replace > 1.4 with only one change Isn't it then a small step to ultimately drop the 1.x branch,... and suggest people that don't like the dependencies to just compile gpg2 statically? Perhaps allowing to drop the need for gpg-agent or so. Are there any major platforms left where gpg builds, but gpg2 not? Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5677 bytes Desc: not available URL: From John at enigmail.net Thu Feb 3 21:57:09 2011 From: John at enigmail.net (John Clizbe) Date: Thu, 03 Feb 2011 14:57:09 -0600 Subject: ECC code now in GnuPG master In-Reply-To: <87zkqdhxda.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> Message-ID: <4D4B16A5.8070701@enigmail.net> Werner Koch wrote: > Hi, > > after some cleanup Andrey's ECC code has been merged into GnuPG master > (aka 2.1). Excellent! Congratulations to all involved for the hard work. Are there plans to refactor the ECC code for inclusion into the 1.4 series? -- John P. Clizbe Inet: John (a) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 889 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Feb 3 23:30:38 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 03 Feb 2011 17:30:38 -0500 Subject: ECC code now in GnuPG master In-Reply-To: <87ei7oiztm.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <3619D52D-9EF5-405D-8779-4F9EEE8794B6@jabberwocky.com> <87ei7oiztm.fsf@vigenere.g10code.de> Message-ID: <4D4B2C8E.5070108@fifthhorseman.net> On 02/03/2011 04:16 PM, Werner Koch wrote: > With that in mind I am toying with the idea of a GnuPG 1.5 to replace > 1.4 with only one change: Replace the internal crypto code by Libgcrypt. > This has the advantage that we can take advantage of Libgcrypt > improvements automatically and don't need to backport delicate code. > The disadvantage is of course the extra dependency. I quite like this idea. fwiw, debian just moved gcrypt from /usr/lib into /lib, so that it can be used as a dependency for critical code during boot (and during recovery when /usr isn't mounted. So i'm not concerned about the extra dependency for debian, anyway. I also want to add my voice to the chorus of folks saying "good work!" I'm happy to see this get merged. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Feb 3 23:38:04 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 3 Feb 2011 17:38:04 -0500 Subject: ECC code now in GnuPG master In-Reply-To: <87ei7oiztm.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <3619D52D-9EF5-405D-8779-4F9EEE8794B6@jabberwocky.com> <87ei7oiztm.fsf@vigenere.g10code.de> Message-ID: <07C37464-95E8-471D-A0DA-7064BB0D25F5@jabberwocky.com> On Feb 3, 2011, at 4:16 PM, Werner Koch wrote: > On Thu, 3 Feb 2011 20:13, dshaw at jabberwocky.com said: > >> This is excellent! I'm very pleased to see it merged in. Congratulations to everyone involved. > > It turned out that in the end the required changes were not that big. > > With that in mind I am toying with the idea of a GnuPG 1.5 to replace > 1.4 with only one change: Replace the internal crypto code by Libgcrypt. > This has the advantage that we can take advantage of Libgcrypt > improvements automatically and don't need to backport delicate code. > The disadvantage is of course the extra dependency. I like this idea, but since we're talking about adding an extra dependency anyway, I wonder if it might be a better direction, rather than add libgcrypt to GnuPG 1.4, to instead make a "mini" version of GnuPG 2.x for server use (leaving out the non-OpenPGP stuff, the agent, etc). A long while ago, you and I talked about that sort of compile-time possibility. David From sergi at calcurco.cat Thu Feb 3 22:53:28 2011 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Thu, 3 Feb 2011 22:53:28 +0100 Subject: playing with ecc in batch mode Message-ID: Hi, I have a problem with the pinentry when I try to use the gpg2 (ecc git version), even doing it as batch mode a pientry window is launched. Also I have tried with '--passphrase' parameter, the '--passphrase-file', and the batch command 'Passphrase'. Without success, always the popup. This is _not_for_production proposals. I have an script that I used for test the ecc patch for the 1.4 branch and I like to adapt it to this fantastic and expected code for the 2.1 branch, but I cannot make it work. With a command line: /home/serguei/usr/bin/gpg2 --no-permission-warning --homedir $HOME/src/GnuPG/git/ecc.checks/rings --passphrase-file=testpassph --quiet --batch --no-tty --gen-key With the next batch commands: Key-Type: 19 Key-Length: 256 Key-Usage: sign Subkey-Type: 18 Subkey-Length: 256 Subkey-Usage: encrypt Name-Real: "alpha.256" Name-Comment: ECC test key Name-Email: alpha at 256.ecc Expire-Date: 2 %commit Can someone help me to know where I made a mistake? Thanks /Sergi. From avi.wiki at gmail.com Thu Feb 3 23:46:37 2011 From: avi.wiki at gmail.com (Avi) Date: Thu, 3 Feb 2011 17:46:37 -0500 Subject: ECC code now in GnuPG master Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 That is great news, Werner. Now, for those of us who are absolutely incapable of compiling code, let alone knowing what gcc is and linking libraries, AND who live in the evil Windows empire, will a binary ever be released that contains ECC support? In a similar vein, for those of us who like the small size and independence of the 1.x trunk (I keep an minimal installation of GnuPG, GPGShell, and my keyrings on a truecrypt encrypted folder on my usb stick), are there plans for ECC to be brought into the 1.X trunk, or will n00bz like me have to hope that someone compiles a stand-alone version of 2.1 for our use? Thank you, - --Avi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) - GPGshell v3.77 Comment: Most recent key: Click show in box @ http://is.gd/4xJrs iJgEAREKAEAFAk1LMD85GGh0dHA6Ly9wZ3AubmljLmFkLmpwL3Brcy9sb29rdXA/ b3A9Z2V0JnNlYXJjaD0weEY4MEUyOUY5AAoJEA1isBn4Din5DfMBAI0xH/51olFL 6qDY6DDEvlE57tWradQacAQsxsx4xXUYAPwNDOKF9yXXtIo7XIG1djnwCahRDrkt lk5Bz4HOoJi2Qw== =33/j -----END PGP SIGNATURE----- ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From smujohnson at gmail.com Fri Feb 4 03:46:07 2011 From: smujohnson at gmail.com (smu johnson) Date: Thu, 3 Feb 2011 18:46:07 -0800 Subject: ECC code now in GnuPG master In-Reply-To: References: Message-ID: Glad you asked, I'm sort of in the same boat. I am a win32 kinda-guy and hate compiling stuff bigger than a hello world program. I just use the installers with GnuPG v1.xx.x stuff, and this new v2 branch sounds pretty cool. On Thu, Feb 3, 2011 at 2:46 PM, Avi wrote: > That is great news, Werner. Now, for those of us who are > absolutely incapable of compiling code, let alone knowing what > gcc is and linking libraries, AND who live in the evil Windows > empire, will a binary ever be released that contains ECC > support? In a similar vein, for those of us who like the small > size and independence of the 1.x trunk (I keep an minimal > installation of GnuPG, GPGShell, and my keyrings on a truecrypt > encrypted folder on my usb stick), are there plans for ECC to be > brought into the 1.X trunk, or will n00bz like me have to hope > that someone compiles a stand-alone version of 2.1 for our use? > > Thank you, > > - --Avi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Feb 4 06:36:51 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Feb 2011 06:36:51 +0100 Subject: ECC code now in GnuPG master In-Reply-To: <07C37464-95E8-471D-A0DA-7064BB0D25F5@jabberwocky.com> (David Shaw's message of "Thu, 3 Feb 2011 17:38:04 -0500") References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <3619D52D-9EF5-405D-8779-4F9EEE8794B6@jabberwocky.com> <87ei7oiztm.fsf@vigenere.g10code.de> <07C37464-95E8-471D-A0DA-7064BB0D25F5@jabberwocky.com> Message-ID: <87vd10gy30.fsf@vigenere.g10code.de> On Thu, 3 Feb 2011 23:38, dshaw at jabberwocky.com said: > than add libgcrypt to GnuPG 1.4, to instead make a "mini" version of > GnuPG 2.x for server use (leaving out the non-OpenPGP stuff, the > agent, etc). A long while ago, you and I talked about that sort of > compile-time possibility. I can't remember the details of the discussion anymore. The major hurdle is that we need to write a new agent which does not assume to run in an interactive environment. The functionality of the agent (secret key operation) is obviously required. We may link such new agent code into gpg proper, much like we do with the smartcard code in 1.4. Another, simpler, option would be to keep the agent but make it loop back to gpg to ask for the passphrase. Recall that the agent is now reliable started on demand on a per GNUPGHOME base. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 4 06:50:58 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Feb 2011 06:50:58 +0100 Subject: playing with ecc in batch mode In-Reply-To: ("Sergi Blanch i =?utf-8?Q?Torn=C3=A9=22's?= message of "Thu, 3 Feb 2011 22:53:28 +0100") References: Message-ID: <87r5bogxfh.fsf@vigenere.g10code.de> On Thu, 3 Feb 2011 22:53, sergi at calcurco.cat said: > Also I have tried with '--passphrase' parameter, the > '--passphrase-file', and the batch command 'Passphrase'. Without > success, always the popup. You can't use that. The regression tests use this to seed the passphrase cache: gpg-preset-passphrase --preset -P def 50B2D4FA4122C212611048BC5FC31BD44393626E You also need to use the --allow-preset-passphrase in gpg-agent.conf. Obviously it does not work while generating keys. Another, more flexible way, is to write your own pinentry which loops back to your test script. gpg passes the envvar PINENTRY_USER_DATA all the way up to the pinentry; this can be used to convey a context. For testing we have the %no-protection batch parameter: $GPG --quiet --batch --gen-key < References: <4D2E5E41.4030602@fsij.org> <4D2E86BB.3020602@fsij.org> <4D2EA201.3090200@fsij.org> <4D2FAD0F.9070500@fsij.org> <4D33E69F.5050202@fsij.org> <4D368A84.4070208@fsij.org> Message-ID: <4D4B9C17.5060601@fsij.org> Yes, the patch series is still on going. Here is the part 6, adding support of resetting PIN. It seems for me that CCID protocol doesn't assume that the command PUT_DATA will be issued by PC_to_RDR_Secure message. So, this code doesn't support setting the reset code by keypad (even if it would be possible). 2011-02-04 NIIBE Yutaka * iso7816.c (iso7816_reset_retry_counter_kp): Remove NEWCHV and NEWCHVLEN arguments. Just call apdu_keypad_modify. (iso7816_reset_retry_counter_with_rc_kp): New. (iso7816_reset_retry_counter): Call apdu_send_simple. * app-openpgp.c (do_change_pin): With resetcode, call iso7816_reset_retry_counter_with_rc_kp. With reset_mode, Call iso7816_reset_retry_counter_kp. --- scd/app-openpgp.c | 86 ++++++++++++++++++++++++++++++++--------------------- scd/iso7816.c | 37 +++++++++++++--------- scd/iso7816.h | 4 +- 3 files changed, 76 insertions(+), 51 deletions(-) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 18c56f2..547ba15 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2035,22 +2035,27 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, goto leave; } - rc = pincb (pincb_arg, - _("||Please enter the Reset Code for the card"), - &resetcode); - if (rc) - { - log_info (_("PIN callback returned error: %s\n"), - gpg_strerror (rc)); - goto leave; - } - if (strlen (resetcode) < minlen) - { - log_info (_("Reset Code is too short; minimum length is %d\n"), - minlen); - rc = gpg_error (GPG_ERR_BAD_PIN); - goto leave; - } + if (use_keypad) + resetcode = ""; /* Non NULL */ + else + { + rc = pincb (pincb_arg, + _("||Please enter the Reset Code for the card"), + &resetcode); + if (rc) + { + log_info (_("PIN callback returned error: %s\n"), + gpg_strerror (rc)); + goto leave; + } + if (strlen (resetcode) < minlen) + { + log_info (_("Reset Code is too short; minimum length is %d\n"), + minlen); + rc = gpg_error (GPG_ERR_BAD_PIN); + goto leave; + } + } } else { @@ -2064,7 +2069,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, else app->did_chv1 = app->did_chv2 = 0; - if (!use_keypad) + if (!use_keypad || set_resetcode) { /* TRANSLATORS: Do not translate the "|*|" prefixes but keep it at the start of the string. We need this elsewhere @@ -2083,19 +2088,27 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, if (resetcode) { - char *buffer; - - buffer = xtrymalloc (strlen (resetcode) + strlen (pinvalue) + 1); - if (!buffer) - rc = gpg_error_from_syserror (); + if (use_keypad) + { + resetcode = NULL; + rc = iso7816_reset_retry_counter_with_rc_kp (app->slot, 0x81, &pininfo); + } else - { - strcpy (stpcpy (buffer, resetcode), pinvalue); - rc = iso7816_reset_retry_counter_with_rc (app->slot, 0x81, - buffer, strlen (buffer)); - wipememory (buffer, strlen (buffer)); - xfree (buffer); - } + { + char *buffer; + + buffer = xtrymalloc (strlen (resetcode) + strlen (pinvalue) + 1); + if (!buffer) + rc = gpg_error_from_syserror (); + else + { + strcpy (stpcpy (buffer, resetcode), pinvalue); + rc = iso7816_reset_retry_counter_with_rc (app->slot, 0x81, + buffer, strlen (buffer)); + wipememory (buffer, strlen (buffer)); + xfree (buffer); + } + } } else if (set_resetcode) { @@ -2110,11 +2123,16 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, } else if (reset_mode) { - rc = iso7816_reset_retry_counter (app->slot, 0x81, - pinvalue, strlen (pinvalue)); - if (!rc && !app->app_local->extcap.is_v2) - rc = iso7816_reset_retry_counter (app->slot, 0x82, - pinvalue, strlen (pinvalue)); + if (use_keypad) + rc = iso7816_reset_retry_counter_kp (app->slot, 0x81, &pininfo); + else + { + rc = iso7816_reset_retry_counter (app->slot, 0x81, + pinvalue, strlen (pinvalue)); + if (!rc && !app->app_local->extcap.is_v2) + rc = iso7816_reset_retry_counter (app->slot, 0x82, + pinvalue, strlen (pinvalue)); + } } else if (!app->app_local->extcap.is_v2) { diff --git a/scd/iso7816.c b/scd/iso7816.c index 117de04..25266a0 100644 --- a/scd/iso7816.c +++ b/scd/iso7816.c @@ -353,30 +353,30 @@ iso7816_change_reference_data (int slot, int chvno, gpg_error_t iso7816_reset_retry_counter_kp (int slot, int chvno, - const char *newchv, size_t newchvlen, iso7816_pininfo_t *pininfo) { int sw; - if (!newchv || !newchvlen ) - return gpg_error (GPG_ERR_INV_VALUE); - - /* FIXME: The keypad mode has not yet been tested. */ - if (pininfo && pininfo->mode) - sw = apdu_send_simple_kp (slot, 0x00, CMD_RESET_RETRY_COUNTER, - 2, chvno, newchvlen, newchv, - pininfo->mode, - pininfo->minlen, - pininfo->maxlen, + sw = apdu_keypad_modify (slot, 0x00, CMD_RESET_RETRY_COUNTER, 2, chvno, + pininfo->mode, pininfo->minlen, pininfo->maxlen, pininfo->padlen); - else - sw = apdu_send_simple (slot, 0, 0x00, CMD_RESET_RETRY_COUNTER, - 2, chvno, newchvlen, newchv); return map_sw (sw); } gpg_error_t +iso7816_reset_retry_counter_with_rc_kp (int slot, int chvno, + iso7816_pininfo_t *pininfo) +{ + int sw; + + sw = apdu_keypad_modify (slot, 0x00, CMD_RESET_RETRY_COUNTER, 0, chvno, + pininfo->mode, pininfo->minlen, pininfo->maxlen, + pininfo->padlen); + return map_sw (sw); +} + +gpg_error_t iso7816_reset_retry_counter_with_rc (int slot, int chvno, const char *data, size_t datalen) { @@ -395,7 +395,14 @@ gpg_error_t iso7816_reset_retry_counter (int slot, int chvno, const char *newchv, size_t newchvlen) { - return iso7816_reset_retry_counter_kp (slot, chvno, newchv, newchvlen, NULL); + int sw; + + if (!newchv || !newchvlen ) + return gpg_error (GPG_ERR_INV_VALUE); + + sw = apdu_send_simple (slot, 0, 0x00, CMD_RESET_RETRY_COUNTER, + 2, chvno, newchvlen, newchv); + return map_sw (sw); } diff --git a/scd/iso7816.h b/scd/iso7816.h index 6d52702..cac2ca0 100644 --- a/scd/iso7816.h +++ b/scd/iso7816.h @@ -72,12 +72,12 @@ gpg_error_t iso7816_change_reference_data_kp (int slot, int chvno, gpg_error_t iso7816_reset_retry_counter (int slot, int chvno, const char *newchv, size_t newchvlen); gpg_error_t iso7816_reset_retry_counter_kp (int slot, int chvno, - const char *newchv, - size_t newchvlen, iso7816_pininfo_t *pininfo); gpg_error_t iso7816_reset_retry_counter_with_rc (int slot, int chvno, const char *data, size_t datalen); +gpg_error_t iso7816_reset_retry_counter_with_rc_kp (int slot, int chvno, + iso7816_pininfo_t *pininfo); gpg_error_t iso7816_get_data (int slot, int extended_mode, int tag, unsigned char **result, size_t *resultlen); gpg_error_t iso7816_put_data (int slot, int extended_mode, int tag, -- 1.7.2.3 From sergi at calcurco.cat Fri Feb 4 09:55:33 2011 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Fri, 4 Feb 2011 09:55:33 +0100 Subject: ECC code now in GnuPG master In-Reply-To: <87pqr8j2lr.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <1296757663.3271.26.camel@fermat.scientia.net> <87pqr8j2lr.fsf@vigenere.g10code.de> Message-ID: On Thu, Feb 3, 2011 at 9:16 PM, Werner Koch wrote: > On Thu, ?3 Feb 2011 19:27, calestyo at scientia.net said: >> What's the suggested keysizes,... and which are supported by gpg? > > The default is 256, which uses the NIST P-256 curve. ?Other supported > curves are NIST P-384 and NIST P-521. ?We could also add other curves as > long as an OID is available and a user interface is written. ?However, I > believe that proliferation of curves is a bad idea. ?In contrast to RSA > key sizes, the application needs to know the curve parameters as they > are not part of the key. IMHO, the proliferation of curves is a feature of the ecc. The X9.62-1998 (section 5.1) evaluates as a security risk the multiple users sharing of the same elliptic curve domain parameters. An probably they has not thinking that this can be three curves for all the users. With ecc you have the feature to change the cyclic subgroup (change 'a', 'b') without increase the size of the base field. Over prime finite fields the unique option you have is to increase the size of 'p'. I understand the bigger issue that this proliferation can make. But, step by step, some day this is a feature that will be need. Cryptography programming must be like satellite navigation programming, the cost of a mistake is huge! /Sergi. From squalyl at gmail.com Fri Feb 4 11:45:18 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Fri, 4 Feb 2011 11:45:18 +0100 Subject: ECC code now in GnuPG master In-Reply-To: References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <1296757663.3271.26.camel@fermat.scientia.net> <87pqr8j2lr.fsf@vigenere.g10code.de> Message-ID: the proliferation of curves is a barrier to interoperability, specially with smart cards. apart from that ECC is a very nice PK scheme. Sebastien On Fri, Feb 4, 2011 at 9:55 AM, Sergi Blanch i Torn? wrote: > On Thu, Feb 3, 2011 at 9:16 PM, Werner Koch wrote: >> On Thu, ?3 Feb 2011 19:27, calestyo at scientia.net said: >>> What's the suggested keysizes,... and which are supported by gpg? >> >> The default is 256, which uses the NIST P-256 curve. ?Other supported >> curves are NIST P-384 and NIST P-521. ?We could also add other curves as >> long as an OID is available and a user interface is written. ?However, I >> believe that proliferation of curves is a bad idea. ?In contrast to RSA >> key sizes, the application needs to know the curve parameters as they >> are not part of the key. > > IMHO, the proliferation of curves is a feature of the ecc. The > X9.62-1998 (section 5.1) evaluates as a security risk the multiple > users sharing of the same elliptic curve domain parameters. An > probably they has not thinking that this can be three curves for all > the users. > > With ecc you have the feature to change the cyclic subgroup (change > 'a', 'b') without increase the size of the base field. Over prime > finite fields the unique option you have is to increase the size of > 'p'. > > I understand the bigger issue that this proliferation can make. But, > step by step, some day this is a feature that will be need. > Cryptography programming must be like satellite navigation > programming, the cost of a mistake is huge! > > /Sergi. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From sergi at calcurco.cat Fri Feb 4 13:20:30 2011 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Fri, 4 Feb 2011 13:20:30 +0100 Subject: ECC code now in GnuPG master In-Reply-To: References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <1296757663.3271.26.camel@fermat.scientia.net> <87pqr8j2lr.fsf@vigenere.g10code.de> Message-ID: I understand this, but I feel it as a barrier to surpass. The mathematical methods to operate ec points in libgcrypt, has been programmed in the generic way that the P1363 says. They should work with other curves, and they had not problem with the brainpool curves. Not tomorrow, neither the day after, but I think is good to have on mind the possibility to work on the direction to have this elliptic curve feature available. Specially for the smart cards, due to an attack to an specific elliptic curve can be aborted changing the curve without affect the design of the card for one length to a bigger one. Also, against side channel attack, it's proposed to use isogenies to avoid zero-value points. And this means that the implementation must work fine with more curves than a few selected. /Sergi. On Fri, Feb 4, 2011 at 11:45 AM, S?bastien Lorquet wrote: > the proliferation of curves is a barrier to interoperability, > specially with smart cards. > > apart from that ECC is a very nice PK scheme. > > Sebastien > > On Fri, Feb 4, 2011 at 9:55 AM, Sergi Blanch i Torn? wrote: >> On Thu, Feb 3, 2011 at 9:16 PM, Werner Koch wrote: >>> On Thu, ?3 Feb 2011 19:27, calestyo at scientia.net said: >>>> What's the suggested keysizes,... and which are supported by gpg? >>> >>> The default is 256, which uses the NIST P-256 curve. ?Other supported >>> curves are NIST P-384 and NIST P-521. ?We could also add other curves as >>> long as an OID is available and a user interface is written. ?However, I >>> believe that proliferation of curves is a bad idea. ?In contrast to RSA >>> key sizes, the application needs to know the curve parameters as they >>> are not part of the key. >> >> IMHO, the proliferation of curves is a feature of the ecc. The >> X9.62-1998 (section 5.1) evaluates as a security risk the multiple >> users sharing of the same elliptic curve domain parameters. An >> probably they has not thinking that this can be three curves for all >> the users. >> >> With ecc you have the feature to change the cyclic subgroup (change >> 'a', 'b') without increase the size of the base field. Over prime >> finite fields the unique option you have is to increase the size of >> 'p'. >> >> I understand the bigger issue that this proliferation can make. But, >> step by step, some day this is a feature that will be need. >> Cryptography programming must be like satellite navigation >> programming, the cost of a mistake is huge! >> >> /Sergi. >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel >> > From wk at gnupg.org Fri Feb 4 16:32:26 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Feb 2011 16:32:26 +0100 Subject: ECC code now in GnuPG master In-Reply-To: (=?utf-8?Q?=22S=C3=A9bastien?= Lorquet"'s message of "Fri, 4 Feb 2011 11:45:18 +0100") References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> <1296757663.3271.26.camel@fermat.scientia.net> <87pqr8j2lr.fsf@vigenere.g10code.de> Message-ID: <877hdfg6id.fsf@vigenere.g10code.de> On Fri, 4 Feb 2011 11:45, squalyl at gmail.com said: > the proliferation of curves is a barrier to interoperability, Right. It doesn't help if everyone uses custom curves but most won't be able to encrypt messages to that key. There is also the question of parameter validation. I guess we will add a few more curves if there is a real demand for it, but this should be limited to what is really needed. Frankly, I was one of those who favored an OID approach instead of just a simple number to describe the curve. This is the OpenPGP feature which allows us to extend ECC. It is more like all the algorithm ids we have, we need to limit them and add a new algorithm only for a real (political) reason, like Camellia. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Fri Feb 4 17:07:15 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 4 Feb 2011 16:07:15 +0000 Subject: ECC code now in GnuPG master In-Reply-To: <87zkqdhxda.fsf@vigenere.g10code.de> References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> Message-ID: On Thu, Feb 3, 2011 at 4:54 PM, Werner Koch wrote: > Hi, > > after some cleanup Andrey's ECC code has been merged into GnuPG master > (aka 2.1). ?The latest commit also adds an extended algorithm selection > menu, which shows up like this: > > ?$ ~/b/gnupg/g10/gpg2 --expert --gen-key > ?Please select what kind of key you want: > ? ? (1) RSA and RSA (default) > ? ? (2) DSA and Elgamal > ? ? (3) DSA (sign only) > ? ? (4) RSA (sign only) > ? ? (7) DSA (set your own capabilities) > ? ? (8) RSA (set your own capabilities) > ? ? (9) ECDSA and ECDH > ? ?(10) ECDSA (sign only) > ? ?(11) ECDSA (set your own capabilities) Will you also be adding EC support to the batch generation system? Best wishes, Nicholas From sergi at calcurco.cat Sat Feb 5 19:27:40 2011 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Sat, 5 Feb 2011 19:27:40 +0100 Subject: playing with ecc in batch mode In-Reply-To: <87r5bogxfh.fsf@vigenere.g10code.de> References: <87r5bogxfh.fsf@vigenere.g10code.de> Message-ID: Ok, it works. I have been able to create many keys with the ecc schema with lengths of 256 and 384 and check for encrypt/decrypt, sign/verify, list, fingerprinting, import/export. Except for the known issue in 521, I test the basics without passphrase. I'll do the silly pinentry to test with pass. Many thanks. /Sergi. On Fri, Feb 4, 2011 at 6:50 AM, Werner Koch wrote: > On Thu, ?3 Feb 2011 22:53, sergi at calcurco.cat said: > >> Also I have tried with '--passphrase' parameter, the >> '--passphrase-file', and the batch command 'Passphrase'. Without >> success, always the popup. > > You can't use that. ?The regression tests use this to seed the > passphrase cache: > > ?gpg-preset-passphrase --preset -P def 50B2D4FA4122C212611048BC5FC31BD44393626E > > You also need to use the --allow-preset-passphrase in gpg-agent.conf. > Obviously it does not work while generating keys. > > Another, more flexible way, is to write your own pinentry which loops > back to your test script. ?gpg passes the envvar PINENTRY_USER_DATA all > the way up to the pinentry; this can be used to convey a context. > > For testing we have the %no-protection batch parameter: > > ?$GPG --quiet --batch --gen-key < ?Key-Type: DSA > ?Key-Length: 1024 > ?Subkey-Type: ELG > ?Subkey-Length: 1024 > ?Name-Real: Harry H. > ?Name-Comment: test key > ?Name-Email: hh@@ddorf.de > ?Expire-Date: 1 > ?%no-protection > ?%transient-key > ?%commit > ?EOF > > > Salam-Shalom, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > > From wk at gnupg.org Sun Feb 6 13:09:33 2011 From: wk at gnupg.org (Werner Koch) Date: Sun, 06 Feb 2011 13:09:33 +0100 Subject: ECC code now in GnuPG master In-Reply-To: (Nicholas Cole's message of "Fri, 4 Feb 2011 16:07:15 +0000") References: <87vd12jvrt.fsf@vigenere.g10code.de> <87zkqdhxda.fsf@vigenere.g10code.de> Message-ID: <87lj1te54y.fsf@vigenere.g10code.de> On Fri, 4 Feb 2011 17:07, nicholas.cole at gmail.com said: > Will you also be adding EC support to the batch generation system? Is already availabale. Let me know if there is a problem. I need to add a couple of regression tests; which also requires the batch interface. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Feb 7 14:41:38 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Feb 2011 14:41:38 +0100 Subject: playing with ecc in batch mode In-Reply-To: ("Sergi Blanch i =?utf-8?Q?Torn=C3=A9=22's?= message of "Sat, 5 Feb 2011 19:27:40 +0100") References: <87r5bogxfh.fsf@vigenere.g10code.de> Message-ID: <87ei7kc67h.fsf@vigenere.g10code.de> On Sat, 5 Feb 2011 19:27, sergi at calcurco.cat said: > Except for the known issue in 521, I test the basics without ECC 521 does now also work. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mbodbg at gmx.net Tue Feb 8 14:55:20 2011 From: mbodbg at gmx.net (mbo) Date: Tue, 8 Feb 2011 14:55:20 +0100 Subject: ERROR: _gpgme_io_set_close_notify: error: Invalid argument Message-ID: <5EB56C65-A588-4074-9A92-6C6D5F6A260A@gmx.net> Hello NG, we are accesing gpgme in a python script for decrypting emails. To reproduce the error we are facing, we are using the following python script: import gpgme ctx=gpgme.Context() ctx.get_key(?B9F2747A?) If we run this python script direcly in the command line, everything works fine. If we call the python script within freeswitch (www.freeswitch.org) using the mod_python module, we receive the following debug output, when the environment variable GPGME_DEBUG is set to ?9:/tmp?: ... gpgme_op_keylist_start: enter: ctx=0x7fcd8c2078c0, pattern=B9F2747A, secret_only=0 GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_pipe: enter: filedes=0x7fcd8c1e5bc8, inherit_idx=1 (GPGME uses it for reading) GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_pipe: leave: read=0x1a5, write=0x1a6 GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_set_close_notify: enter: fd=0x1a5, close_handler=0x7fcd84074420/0x7fcd8c1e5ba0 GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_set_close_notify: error: Invalid argument GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_close: enter: fd=0x1a5 GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_close: leave: result=0 GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_close: enter: fd=0x1a6 GPGME 2011-02-07 21:40:58 <0x3b06> _gpgme_io_close: leave: result=0 GPGME 2011-02-07 21:40:58 <0x3b06> gpgme_op_keylist_start: error: General error GPGME 2011-02-07 21:40:58 <0x3b06> gpgme_release: call: ctx=0x7fcd8c2078c0 GPGME 2011-02-07 21:40:58 <0x3b06> gpgme_get_key: error: General error ... Full trace can be seen here: http://pastebin.freeswitch.org/15285 Here are the versions we are using: Debian 5.5, Kernel 2.6.26-2-amd64 #1 SMP Tue Jan 25 05:59:43 UTC 2011 x86_64 GNU/Linux FreeSWITCH Version 1.0.head (git-2ec2a9b 2011-02-04 09-40-04 -0600) gpgme-1.3.0 libassuan-2.0.1 libgpg-error-1.10 pygpgme-0.1+bzr20090820 We have a second testserver here, with exacly the same os and packages installed where we do not have this error. We also checked all file permissions of the involved modules, they have also exacly the same on both servers. Does anyone know what might cause the error? Thanks! Markus From gniibe at fsij.org Thu Feb 10 06:11:03 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 10 Feb 2011 14:11:03 +0900 Subject: Gnuk version 0.10 Message-ID: <4D537367.6040400@fsij.org> Gnuk version 0.10 is out. Gnuk is a software for USB Token which follows OpenPGP card protocol version 2. It runs on STM32 processor. Highlight is: * The executable can be installed to multiple devices So far, users of Gnuk should have not shared single executable among multiple devices because the executable includes random bits (or fixed serial number). Now, random_bits and fixed serial number are configured *after* compilation, we can install single executable image to multiple devices. Note that we need to configure random_bits for each device. Well, Gnuk is ready for mass production, so to say. :-) -- From alphazo at gmail.com Thu Feb 10 22:08:08 2011 From: alphazo at gmail.com (Alphazo) Date: Thu, 10 Feb 2011 22:08:08 +0100 Subject: Error when generating ECC keys Message-ID: I have compiled and installed gpg2 and libgcrypt from git but I get an error when generating ECC keys: # gpg2 --version gpg (GnuPG) 2.1.0-gitcfbb576 libgcrypt 1.5.0-git4f04851 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA Cipher: 3DES, CAST5, BLOWFISH, AES128, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Here is what I get when I use gen-key: # gpg2 --expert --gen-key --debug 15 gpg: reading options from `/home/alpha/.gnupg/gpg.conf' gpg: enabled debug flags: packet mpi cipher filter Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECDSA and ECDH (10) ECDSA (sign only) (11) ECDSA (set your own capabilities) Your selection? 9 ECDSA keys may be between 256 and 521 bits long. What keysize do you want? (256) Requested keysize is 256 bits ECDH keys may be between 256 and 521 bits long. What keysize do you want for the subkey? (256) Requested keysize is 256 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: ecc man Email address: Comment: You selected this USER-ID: "ecc man" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: Fatal: out of core while allocating 17591649173513 bytes -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Fri Feb 11 12:13:53 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 11 Feb 2011 12:13:53 +0100 Subject: ERROR: _gpgme_io_set_close_notify: error: Invalid argument In-Reply-To: <5EB56C65-A588-4074-9A92-6C6D5F6A260A@gmx.net> References: <5EB56C65-A588-4074-9A92-6C6D5F6A260A@gmx.net> Message-ID: <201102111213.57260.bernhard@intevation.de> Am Dienstag, 8. Februar 2011 14:55:20 schrieb mbo: > we are accesing ?gpgme in a python script for decrypting emails. To > reproduce the error we are facing, we are using the following python > script: > > import gpgme > ctx=gpgme.Context() > ctx.get_key(?B9F2747A?) > pygpgme-0.1+bzr20090820 You know that gpgme_check_version() necessary for initialisation according to gpgme 1.1.6 docs. You could check if pygpgme does this. (pyme, the other python package did not. You could try it.) To find out about the differences, you could try to save all environment variables in the two runs and compare them. Also compare all packages and maybe ldd outputs. Looks like a question for the pygpgme people, also. -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mbodbg at gmx.net Fri Feb 11 13:46:05 2011 From: mbodbg at gmx.net (mbo) Date: Fri, 11 Feb 2011 13:46:05 +0100 Subject: ERROR: _gpgme_io_set_close_notify: error: Invalid argument In-Reply-To: <201102111213.57260.bernhard@intevation.de> References: <5EB56C65-A588-4074-9A92-6C6D5F6A260A@gmx.net> <201102111213.57260.bernhard@intevation.de> Message-ID: <82CB22D9-5773-49CA-A47B-78D8F3203CA4@gmx.net> Hello Bernhard, thanks for the hint, but gpgme_check_version() is called inside pygpgme (https://code.launchpad.net/pygpgme). If I call the script directly, it runs without any problem. The problem only occurs when I start the script from freeswitch/mod_python which implements the python C API. Environment variables and lld outputs are the same on both systems. In my opinion it looks like a threading issue, but I can't find any differences to the other system where everything works. Best Regards Markus Am 11.02.2011 um 12:13 schrieb Bernhard Reiter: > Am Dienstag, 8. Februar 2011 14:55:20 schrieb mbo: >> we are accesing gpgme in a python script for decrypting emails. To >> reproduce the error we are facing, we are using the following python >> script: >> >> import gpgme >> ctx=gpgme.Context() >> ctx.get_key(?B9F2747A?) > >> pygpgme-0.1+bzr20090820 > > You know that gpgme_check_version() necessary for initialisation according to > gpgme 1.1.6 docs. You could check if pygpgme does this. > (pyme, the other python package did not. You could try it.) > > To find out about the differences, you could try to save all environment > variables in the two runs and compare them. Also compare all packages and > maybe ldd outputs. > > Looks like a question for the pygpgme people, also. > > -- > Managing Director - Owner: www.intevation.net (Free Software Company) > Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From openpgp at brainhub.org Mon Feb 14 01:41:06 2011 From: openpgp at brainhub.org (Andrey Jivsov) Date: Sun, 13 Feb 2011 16:41:06 -0800 Subject: Error when generating ECC keys In-Reply-To: References: Message-ID: <4D587A22.4040009@brainhub.org> I was able to generate an ECC key with a build from "master". You need to be careful to make sure that you are running *your* version of libgcrypt, gpg-agent, and gpg2. One suggestion I have is to uninstall any gpg package (such as RPM-based binaries on Fedora) you might have, then install all the binaries you build into a designated directory (e.g./usr/local/gpg2ecc) and set up the binary search path (in LD_LIBRARY_PATH) to point to this directory only. Here are the general instructions that worked for me: http://code.google.com/p/gnupg-ecc/wiki/HowToBuildGnuPG On 02/10/2011 01:08 PM, Alphazo wrote: > I have compiled and installed gpg2 and libgcrypt from git but I get an > error when generating ECC keys: > > # gpg2 --version > gpg (GnuPG) 2.1.0-gitcfbb576 > libgcrypt 1.5.0-git4f04851 > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: ~/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA > Cipher: 3DES, CAST5, BLOWFISH, AES128, AES192, AES256, TWOFISH, > CAMELLIA128, > CAMELLIA192, CAMELLIA256 > Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > Here is what I get when I use gen-key: > > # gpg2 --expert --gen-key --debug 15 > gpg: reading options from `/home/alpha/.gnupg/gpg.conf' > gpg: enabled debug flags: packet mpi cipher filter > Please select what kind of key you want: > (1) RSA and RSA (default) > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) > (7) DSA (set your own capabilities) > (8) RSA (set your own capabilities) > (9) ECDSA and ECDH > (10) ECDSA (sign only) > (11) ECDSA (set your own capabilities) > Your selection? 9 > ECDSA keys may be between 256 and 521 bits long. > What keysize do you want? (256) > Requested keysize is 256 bits > ECDH keys may be between 256 and 521 bits long. > What keysize do you want for the subkey? (256) > Requested keysize is 256 bits > Please specify how long the key should be valid. > 0 = key does not expire > = key expires in n days > w = key expires in n weeks > m = key expires in n months > y = key expires in n years > Key is valid for? (0) > Key does not expire at all > Is this correct? (y/N) y > > GnuPG needs to construct a user ID to identify your key. > > Real name: ecc man > Email address: > Comment: > You selected this USER-ID: > "ecc man" > > Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o > We need to generate a lot of random bytes. It is a good idea to perform > some other action (type on the keyboard, move the mouse, utilize the > disks) during the prime generation; this gives the random number > generator a better chance to gain enough entropy. > gpg: Fatal: out of core while allocating 17591649173513 bytes > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From squalyl at gmail.com Thu Feb 17 17:41:11 2011 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Thu, 17 Feb 2011 17:41:11 +0100 Subject: Future problems with OpenGPG card and ECC Message-ID: Hi, Do anyone know how an opengpg card implemented in javacard is supposed to work with ECC? The opengpg card spec v2.0 states: > The hash value (ECDSA) or the DigestInfo is delivered in the data field of the command. With RSA, there are no problems. A Cipher object with algorithm ALG_RSA_PKCS1 can be used. The input to the RSA exponentiation is the digest info, the output is the signature. However, with ECC, this scheme is not available. The Cipher class does NOT provides means to use ECC for ciphering. There is no ALG_EC_PKCS1 ciphering algorithm. We only get a Signature object, with, e.g. algorithm ALG_ECDSA_SHA. This combines a SHA-1 digest with an ECC signature. So we cannot provide the hash value in the command data field. We can only provide the hash input data, and the card computes the sha-1 of this input onboard before doing ECDSA calculations. As a consequence, we need a change the spec, in order to supply the whole data to be digested to the card. I propose this wording: > The data to be hashed (ECDSA) or the DigestInfo is delivered in the data field of the command. And I hope this input data is not too long. Any thougths? Sebastien Lorquet -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgo at grant-olson.net Thu Feb 17 20:02:49 2011 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 17 Feb 2011 14:02:49 -0500 Subject: Future problems with OpenGPG card and ECC In-Reply-To: References: Message-ID: <4D5D70D9.6040905@grant-olson.net> On 2/17/11 11:41 AM, S?bastien Lorquet wrote: > Hi, > > Do anyone know how an opengpg card implemented in javacard is supposed > to work with ECC? > > The opengpg card spec v2.0 states: > >> The hash value (ECDSA) or the DigestInfo is delivered in the data > field of the command. > Section 2.1 of the spec basically says that only RSA is supported. And from 7.2.9 "In this version of the OpenPGP application ECDSA decryption is not defined and will be added in a later version." Etc. So including ECC would indeed require a new version of the spec. I didn't know about the javacard implementation until just now, but I think another big problem is that the ZietControl cards seem to only support a ECC-167. That curve isn't set to be included with the new OpenPGP spec. And if I do the math right, and that's comparable to an 80-something bit symmetric key, then it probably shouldn't be included. -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 570 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Feb 17 20:43:00 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Feb 2011 20:43:00 +0100 Subject: Future problems with OpenGPG card and ECC In-Reply-To: <4D5D70D9.6040905@grant-olson.net> (Grant Olson's message of "Thu, 17 Feb 2011 14:02:49 -0500") References: <4D5D70D9.6040905@grant-olson.net> Message-ID: <87mxlu5tx7.fsf@vigenere.g10code.de> On Thu, 17 Feb 2011 20:02, kgo at grant-olson.net said: > I didn't know about the javacard implementation until just now, but I > think another big problem is that the ZietControl cards seem to only > support a ECC-167. That curve isn't set to be included with the new I heard that they also support GF(p) but is seems that only the brainpool curves are in the ROM and the NIST curves must be explicitly defined. Time to do our own chip OS. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Feb 21 17:27:31 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Feb 2011 17:27:31 +0100 Subject: Libgcrypt 1.5.0-beta1 released Message-ID: <87oc652w0c.fsf@vigenere.g10code.de> Hi, to help with testing the new ECC code in GnuPG, I just uploaded a beta version of libgcrypt 1.5: ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.5.0-beta1.tar.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.5.0-beta1.tar.bz2.sig Changes are: * Support for WindowsCE. * Support ECDH. * gcry_sexp_build does now support opaque MPIs with "%m". * New functions gcry_pk_get_curve and gcry_pk_get_param to map ECC parameters to a curve name and to retrieve parameter values. * gcry_mpi_cmp applied to opaque values has a defined semantic now. * Uses the Intel AES-NI instructions if available. * The use of the deprecated Alternative Public Key Interface (gcry_ac_*) will now print compile time warnings. * The module register subsystem has been deprecated. This subsystem is not flexible enough and would always require ABI changes to extend the internal interfaces. It will eventually be removed. Please contact us on the gcrypt-devel mailing list to discuss whether you really need this feature or how it can be replaced by an internal plugin mechanism. * New variants of the TIGER algorithm. [also in 1.4.6] * New cipher algorithm mode for AES-WRAP. [also in 1.4.6] * Fixed minor memory leak in DSA key generation. [also in 1.4.5] * No more switching to FIPS mode if /proc/version is not readable. [also in 1.4.5] * Fixed sigill during Padlock detection on old CPUs. [also in 1.4.5] * Fixed a hang on some W2000 machines. [also in 1.4.5] * Boosted SHA-512 performance by 30% on ia32 boxes and gcc 4.3; SHA-256 went up by 25%. [also in 1.4.5] * Interface changes relative to the 1.4.2 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_PK_ECDH NEW. gcry_pk_get_curve NEW. gcry_pk_get_param NEW. GCRYCTL_DISABLE_HWF NEW. GCRY_CIPHER_MODE_AESWRAP NEW. [also in 1.4.6] GCRY_MD_TIGER1 NEW. [also in 1.4.6] GCRY_MD_TIGER2 NEW. [also in 1.4.6] Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From adodao at hotmail.de Wed Feb 23 13:46:44 2011 From: adodao at hotmail.de (Ado Dao) Date: Wed, 23 Feb 2011 12:46:44 +0000 Subject: =?windows-1256?Q?gpgsm_does?= =?windows-1256?Q?_not_work_?= =?windows-1256?Q?with_LDAP_?= =?windows-1256?Q?Server_(LD?= =?windows-1256?Q?APv3)_for_?= =?windows-1256?Q?X.509_cert?= =?windows-1256?Q?ificates_a?= =?windows-1256?Q?nd_CRLs=FE?= Message-ID: gpgsm use dirmngr for get x.509 certificate or CRLs. dirmngr works only with LDAPv2 server. Some servers do not accept LDAPv2 binds, so the connection does not work with dirmngr. Is there a solution? Thanks Ado -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Fri Feb 25 15:59:31 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 25 Feb 2011 15:59:31 +0100 Subject: gpgsm does not work with LDAP Server (LDAPv3) for X.509 certificates and =?utf-8?q?CRLs=E2=80=8F?= In-Reply-To: References: Message-ID: <201102251559.31537.bernhard@intevation.de> Am Mittwoch, 23. Februar 2011 13:46:44 schrieb Ado Dao: > gpgsm use dirmngr for get x.509 certificate or CRLs. dirmngr works only > with LDAPv2 server. > ?Some > ?servers do not accept LDAPv2 > ?binds, so the > connection does not work with dirmngr. > > ?Is > ? > there a solution? Which version of gpgsm and dirmngr did you try in particular? (Including the platform and used ldap library.) -- Managing Director - Owner: www.intevation.net (Free Software Company) Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From adodao at hotmail.de Fri Feb 25 17:01:19 2011 From: adodao at hotmail.de (Ado Dao) Date: Fri, 25 Feb 2011 16:01:19 +0000 Subject: =?windows-1256?Q?RE:_gpgsm_?= =?windows-1256?Q?does_not_w?= =?windows-1256?Q?ork_with_L?= =?windows-1256?Q?DAP_Server?= =?windows-1256?Q?_(LDAPv3)_?= =?windows-1256?Q?for_X.509_?= =?windows-1256?Q?certificat?= =?windows-1256?Q?es_and_CRL?= =?windows-1256?Q?s=FE?= In-Reply-To: <201102251559.31537.bernhard@intevation.de> References: , <201102251559.31537.bernhard@intevation.de> Message-ID: >> gpgsm use dirmngr for get x.509 certificate or CRLs. dirmngr works only >> with LDAPv2 server. >> Some >> servers do not accept LDAPv2 >> binds, so the >> connection does not work with dirmngr. >> >> Is >> >> there a solution? > Which version of gpgsm and dirmngr did you try in particular? > (Including the platform and used ldap library.) I have Ubuntu 9.04 with kernel version 2.6.28-19. gpgsm (GnuPG) -> 2.0.9 dirmngr-client (dirmngr) -> 1.0.2 I tested with "dirmngr-client --lookup " command Regards Ado -------------- next part -------------- An HTML attachment was scrubbed... URL: