From stefanxe at gmx.net Sat Jan 2 18:21:54 2010 From: stefanxe at gmx.net (Stefan Xenon) Date: Sat, 02 Jan 2010 18:21:54 +0100 Subject: problems with scute In-Reply-To: <4B3BD91F.3080307@ruhr-uni-bochum.de> References: <4B393D13.3050608@gmx.net> <4B3BD91F.3080307@ruhr-uni-bochum.de> Message-ID: <4B3F80B2.5080101@gmx.net> Am 30.12.2009 23:50, schrieb Marcus Brinkmann: > Try "gpgsm --gen-key" which has the same functionality as the script. When executing "gpgsm --gen-key" I choose option three as described in the scute documentation: >--- Bitte w?hlen Sie, welche Art von Schl?ssel Sie m?chten: (1) RSA (2) Vorhandener Schl?ssel (3) Vorhandener Schl?ssel auf der Karte Ihre Auswahl? 3 Not yet supported; use the gpgsm-gencert.sh script instead >--- Hmm, Does it really has the same functionality as the script? Regards Stefan From wk at gnupg.org Sat Jan 2 18:46:57 2010 From: wk at gnupg.org (Werner Koch) Date: Sat, 02 Jan 2010 18:46:57 +0100 Subject: problems with scute In-Reply-To: <4B3F80B2.5080101@gmx.net> References: <4B393D13.3050608@gmx.net> <4B3BD91F.3080307@ruhr-uni-bochum.de> <4B3F80B2.5080101@gmx.net> Message-ID: <87eim82ycu.fsf@vigenere.g10code.de> > (3) Vorhandener Schl?ssel auf der Karte > Ihre Auswahl? 3 > Not yet supported; use the gpgsm-gencert.sh script instead > >--- > > Hmm, Does it really has the same functionality as the script? Depends on your version. It is implemented since 2.0.13. The version in Gpg4win 2.0.1 does not include it, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stefanxe at gmx.net Sun Jan 3 03:44:23 2010 From: stefanxe at gmx.net (Stefan Xenon) Date: Sun, 03 Jan 2010 03:44:23 +0100 Subject: key generation failed on card In-Reply-To: <4B3CFB98.4030909@gmx.net> References: <4B3CFB98.4030909@gmx.net> Message-ID: <4B400487.2050100@gmx.net> I found the cause for this problem by myself: gpg-agent was not running. As mentioned before it seems that I have to start gpg-agent manually each time. Therefore I use the following solution: http://www.linuxquestions.org/questions/linux-security-4/gpg-gpg-agent-cant-connect-to-root.gnupgs.gpg-agent-611843/ Am 31.12.2009 20:29, schrieb Stefan Xenon: > I compiled GnuPG 2.0.14 on Ubuntu 9.10 (using libgcrypt 1.4.4). When > generating a key on an OpenPGP card v2 it fails right after entering > "generate" and tells me "IPC Schreibfehler" (IPC write error). From marcus.brinkmann at ruhr-uni-bochum.de Fri Jan 8 02:44:50 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 8 Jan 2010 02:44:50 +0100 Subject: [Announce] libassuan 2.0.0 released Message-ID: <4B468E12.7050500@ruhr-uni-bochum.de> Hi, libassuan 2.0.0 is a new branch of libassuan development. It provides a shared library which is a dependency of of the upcoming versions of GPGME, GnupG 2.1.x and others. Note that this version of libassuan is incompatible with previous versions of libassuan, and can not be installed side-by-side with libassuan 1.0.x. ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.0.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.0.tar.bz2.sig The sha1sums of these files are: b03c586a4eefdfc0bb1ec65ecf958b9890d429f7 libassuan-2.0.0.tar.bz2 6880f16b5e3af442b457a86637caa6411b73b677 libassuan-2.0.0.tar.bz2.sig Because this is the first version of libassuan providing a shared library, a lot of effort was spent into making the API/ABI of libassuan extensible and future-proof. Please see below, the file NEWS and the file doc/README.apichanges for details. Noteworthy changes in version 2.0.0 (2009-01-08) ------------------------------------------------ * Now using libtool and builds a DSO. * Lots of interface cleanups. See below for details of the most important changes. Here is a quick note on how to upgrade: For each invocation of the connect or server functions, allocate a context with assuan_new and use that. Instead of assuan_disconnect or assuan_deinit_server, call assuan_release. Use assuan_set_gpg_err_source instead of assuan_set_assuan_err_source. If you use assuan_pipe_connect with NAME of NULL, you have to provide a non-NULL ARGV argument and check that against "server" or "client" to determine which end you got after fork(). If you use the assuan sock interface, you must call assuan_sock_init after setting global context defaults. Add a NULL as the last arg to assuan_register_command. * Pth support has changed. This now follows the same style as libgcrypt by setting system hook callbacks. * Interface changes relative to the 1.0.5 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _ASSUAN_ONLY_GPG_ERRORS REMOVED assuan_set_assuan_err_source REMOVED: Use assuan_set_gpg_err_source. assuan_set_gpg_err_source NEW assuan_get_gpg_err_source NEW assuan_strerror REMOVED ASSUAN_* Error values removed. assuan_error_t REMOVED AssuanError REMOVED assuan_init_connected_socket_server REMOVED assuan_pipe_connect2 REMOVED AssuanCommand REMOVED assuan_flag_t CHANGED: From enum to unsigned int. ASSUAN_CONTENT REMOVED assuan_disconnect REMOVED: Use assuan_release. assuan_deinit_server REMOVED: Use assuan_release. assuan_get_malloc_hooks NEW assuan_set_log_cb NEW assuan_get_log_cb NEW assuan_new_ext NEW assuan_new NEW assuan_release NEW assuan_init_socket_server CHANGED: Take ctx arg instead of pointer to ctx. CHANGED: As assuan_init_socket_server_ext was. assuan_init_socket_server_ext REMOVED assuan_socket_connect CHANGED: Take ctx arg instead of pointer to ctx. CHANGED: Is what assuan_socket_connect_ext was. assuan_socket_connect_ext REMOVED assuan_pipe_connect CHANGED: Take ctx arg instead of pointer to ctx. If NAME is NULL, ARGV will contain fork result. CHANGED: Is now what assuan_pipe_connect_ext was. CHANGED: Child fds are now assuan_fd_t. assuan_pipe_connect_ext REMOVED assuan_init_pipe_server CHANGED: Take ctx arg instead of pointer to ctx. CHANGED: Swallows fds (are closed at end). CHANGED: Take assuan_fd_t. assuan_fdopen NEW assuan_set_io_hooks REMOVED: Use assuan_system_hooks interface. assuan_io_hooks_t REMOVED: Use assuan_system_hooks interface. assuan_io_monitor_t CHANGED: Add a hook data argument. assuan_get_command_name NEW assuan_msghdr_t NEW ASSUAN_INVALID_PID NEW ASSUAN_NO_FIXSIGNALS NEW ASSUAN_SYSTEM_HOOKS_VERSION NEW assuan_system_hooks_t NEW assuan_set_system_hooks NEW assuan_ctx_set_system_hooks NEW ASSUAN_SYSTEM_PTH_IMPL NEW ASSUAN_SYSTEM_PTH_DECL NEW ASSUAN_SYSTEM_PTH NEW assuan_sock_init NEW assuan_sock_deinit NEW assuan_handler_t NEW assuan_register_command CHANGED: Add arg HELP_STRING. assuan_register_bye_notify CHANGED: Handler gets line and returns err now. assuan_register_reset_notify CHANGED: Handler gets line and returns err now. assuan_register_cancel_notify CHANGED: Handler gets line and returns err now. assuan_register_input_notify CHANGED: Handler returns error now. assuan_register_output_notify CHANGED: Handler returns error now. assuan_process_next CHANGED: New DONE argument instead EOF return. ASSUAN_PIPE_CONNECT_FDPASSING NEW ASSUAN_PIPE_CONNECT_DETACHED NEW ASSUAN_SOCKET_SERVER_FDPASSING NEW ASSUAN_SOCKET_SERVER_ACCEPTED NEW ASSUAN_SOCKET_CONNECT_FDPASSING NEW assuan_peercred_t NEW assuan_get_peercred CHANGED: Return assuan_peercred_t. assuan_client_read_response NEW assuan_client_parse_response NEW assuan_fd_from_posix_fd NEW ASSUAN_SPAWN_DETACHED NEW ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Mon Jan 11 12:22:54 2010 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 11 Jan 2010 12:22:54 +0100 Subject: [Announce] GPGME 1.3.0 released Message-ID: <4B4B0A0E.6010105@ruhr-uni-bochum.de> Hi, We are pleased to announce version 1.3.0 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 1.2 MB/870 KB compressed) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.0.tar.gz ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.0.tar.bz2 The following files are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.0.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.0.tar.bz2.sig It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel at gnupg.org The sha1sum checksums for this distibution are 0db69082abfbbbaf86c3ab0906f5137de900da73 gpgme-1.3.0.tar.bz2 5365180827aa67dede556594587ee770536021a2 gpgme-1.3.0.tar.bz2.sig c7d17b6451fb7770bee696a3fe359c7f6c1be12a gpgme-1.3.0.tar.gz 573a099bf996b03d0c91796a6a403133fab7798a gpgme-1.3.0.tar.sig Noteworthy changes in version 1.3.0 (2010-01-11) ------------------------------------------------ * GPGME does not come with an internal libassuan version anymore. The external libassuan 1.1.0 release or later is required. For application programmers on systems that can resolve inter-library dependencies at runtime, this is a transparent change. * New engine GPGME_PROTOCOL_G13 to support the new g13 tool. * New engine GPGME_PROTOCOL_UISERVER to support UI Servers. * New API to change the passpgrase of a key. * Interface changes relative to the 1.2.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GPGME_STATUS_INV_SGNR NEW. GPGME_STATUS_NO_SGNR NEW. GPGME_PROTOCOL_G13 NEW. gpgme_op_g13_mount NEW. gpgme_g13_result_t NEW. GPGME_PK_ECDSA NEW. GPGME_PK_ECDH NEW. gpgme_op_passwd_start NEW. gpgme_op_passwd NEW. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marcus Brinkmann mb at g10code.de -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Mon Jan 11 20:00:32 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Jan 2010 20:00:32 +0100 Subject: [admin] Test Message-ID: <87k4vozctr.fsf@vigenere.g10code.de> Hi! There are some complaints about messages not being delivered. Thus this quick test mail. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sam at vilain.net Wed Jan 13 05:32:31 2010 From: sam at vilain.net (Sam Vilain) Date: Wed, 13 Jan 2010 17:32:31 +1300 Subject: DSA and SHA-256 (It works! Or does it?! :)) Message-ID: <4B4D4CDF.2010902@vilain.net> I notice in FIPS-186-3, it specifies that the 'leftmost' N bits of the Hash output function are to be used. However, in the source I see this: /* s = (kinv * ( hash + x * r)) mod q */ tmp = mpi_alloc( mpi_get_nlimbs(skey->p) ); mpi_mul( tmp, skey->x, r ); mpi_add( tmp, tmp, hash ); mpi_mulm( s , kinv, tmp, skey->q ); This approach makes more sense to me; all of the bits in the hash output will influence the output value of r and s. But the standard says no, throw away those low bits. This seems wrong; for instance assuming you are using SHA-256 and DSA - a combination which the gnupg I'm using (Lenny's 1.4.9) will quite happily let me configure - then instead of using an 80-round 160-bit cipher, you're using 160 bits of a 64-round 256-bit cipher. I may be entirely wrong about this but that smells very bad to me. That being said, I see in the source eg g10/sign.c that this case is well described already. I can't find the exact source line where this truncation happens, but I assume it does somewhere. So what happened when I specified to use SHA-256 and re-signed my key using gpg --expert --edit-key KEYID? After all, it seems to have worked; :public key packet: version 4, algo 17, created 1102842997, expires 0 pkey[0]: [1024 bits] pkey[1]: [160 bits] pkey[2]: [1023 bits] pkey[3]: [1022 bits] :user ID packet: "Sam Vilain " :signature packet: algo 17, keyid FC06408866B25843 version 4, created 1263337421, md5len 0, sigclass 0x13 digest algo 8, begin of digest 9e bf hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3) hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11) hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) hashed subpkt 2 len 4 (sig created 2010-01-12) hashed subpkt 25 len 1 (primary user ID) subpkt 16 len 8 (issuer key ID FC06408866B25843) data: [159 bits] data: [159 bits] I haven't got --enable-dsa2 set in my .gnupg/gpg.conf What is in that subpacket? Pulling it apart (using Crypt::OpenPGP::Message), I can see that r is 563842300114387388457394839662831482428878447936 and s is 377105405312767191687013088546003017320679158753 - definitely both <160 bit. I've just tried to reproduce what's going on, but I didn't manage to get Crypt::DSA to bend to my whim just yet. The whole key is here: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEG8DHURBACJ1uLqJ6ZMfz6Qz/bPDy6jNGFJTHOPrbseh8nBKmHjXW6fJiM3 sC8Y+c1E1tqcrahG57Y+XPVEX6sMbb7XLeLCfruUV6NpXeUvC1GDKTUJFAsdyB8z W4FH6hepb9zZ3GZ/7bIN6VsanUEPJ8IprRzPpeB29XD3cF6gKuhccHkjtwCgz0N/ JTUbOvr2XOx9ccZWchXOLTED/0cA7hXjLvZNQABBH8RQrveTdVIZJXuVG2BCXAdZ jRCphfJDGntkTznogEx67Q1KWfZx9/PdY/pUepcGHBeyOjkrhKORY5tw3ZXcUzvV UGczOHFcK3hL+FW4V7DDjcfZJlqzWQf5O54BfdkuV3ongnft0Rr15MpeVKL6fmC7 hT5LA/45I24pSBkO9jgoVA2aGvpyBwt2S5BsPbdVuawMeCJ6YJ6sJyMYONjqh7L3 GvnI44hXJ07Yo5F7n8XXYvXPCYu2OQOUvsXmUsrQSUYahlLY/eITCP33FeTt8EDX yGAZMrxTsEEaub3xsd4c9SwH3w7sl1JAfrhtn0AxkKaUbzNYl7QoU2FtIFZpbGFp biAoQ1BBTiBhdXRob3IpIDxzYW12QGNwYW4ub3JnPohhBBMRCAAhBQJLTPdnAhsD BQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEPwGQIhmslhDztEAoMQ/F7SJlgcZ SpeQdk2bPQKcKs2BAJ975KAl1LHBfsaSJyJqV4gpEM6arLQbU2FtIFZpbGFpbiA8 c2FtQHZpbGFpbi5uZXQ+iGQEExEIACQCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgEC F4AFAktM/80CGQEACgkQ/AZAiGayWEOevwCfYsOQLFkHUzfq/EWk7diBp4c/ZUAA n0IN/cAGNmAVjjicDQcRx6vGiTPhtCdTYW0gVmlsYWluIDxzYW0udmlsYWluQGNh dGFseXN0Lm5ldC5uej6IYQQTEQgAIQUCS0z3ZwIbAwULCQgHAwUVCgkICwUWAgMB AAIeAQIXgAAKCRD8BkCIZrJYQ/gcAKCd0uLxlwEsMiNBT6tws/L1WCRE4QCeIic+ sSXeCKtX6pHDT5Ke6bN5hG+0J1NhbSBWaWxhaW4gKG11Z3d1bXApIDxzYW12QHV0 c2wuZ2VuLm56PohhBBMRCAAhBQJLTPdnAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4B AheAAAoJEPwGQIhmslhDlAwAn2MZMvhwAc6qSsePK0t2iXKPVSYGAJ9st/46fUAu WIIjJhV93gANWnIjd7kBDQRBvAyEEAQAi7Ik8iXYjBKgmlBq2Jp7WUkHR4i7ZuyT rJNamhh6pRjhEQHNpRENExnuEunBbrxJlUwyhGmqj4FzI9yGwtBMBCx0xyOXTqf5 AcENJmOC/W6+rN5FbleOP9PLb26MjFOjbWmG2AJeFDlh3XM3oxN2ZGyP5DcdAd7P 1p+OlvHvaP8AAwcD/3Iu8t/6D7b1pz1SouSVmFli0phAxZnuu5QKLXBC4/c+Vzqg nmA7WPBHk/N9wTUAMvhVAGdxbzmyr6QITU1zYYWVWzqf62dZ66R/RP2ZHwIwpNfJ tG/5VwNSLaavuW81KwDr/djsaWQUNrypOAODcjCyXJLyA+psdlfD7on1DENRiEkE GBECAAkCGwwFAkWm0W4ACgkQ/AZAiGayWENKBwCguIZ2Cr473BEBp00+fPtxzKqo FLIAn34sQHoLgFz5gLuXMgjZEJ1yhne6 =+UwW -----END PGP PUBLIC KEY BLOCK----- So my questions are; 1. is gpg doing the correct, FIPS-186-3 thing of throwing away the lower bits? 2. is this safe? Cheers, Sam From wk at gnupg.org Wed Jan 13 10:27:12 2010 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Jan 2010 10:27:12 +0100 Subject: DSA and SHA-256 (It works! Or does it?! :)) In-Reply-To: <4B4D4CDF.2010902@vilain.net> References: <4B4D4CDF.2010902@vilain.net> Message-ID: <877hrmz767.fsf@vigenere.g10code.de> On Wed, 13 Jan 2010 17:32:31 +1300, Sam Vilain wrote: > That being said, I see in the source eg g10/sign.c that this case is > well described already. I can't find the exact source line where this > truncation happens, but I assume it does somewhere. gnupg/g10/sesskey.c:encode_md_value(): size_t qbytes = gcry_mpi_get_nbits (pk?pk->pkey[1]:sk->skey[1]); [... check qbytes ... ] qbytes/=8; if (gcry_mpi_scan (&frame, GCRYMPI_FMT_USG, gcry_md_read (md, hash_algo), qbytes, &qbytes)) BUG(); gcry_mpi_scan does the truncation. > What is in that subpacket? Pulling it apart (using > Crypt::OpenPGP::Message), I can see that r is > 563842300114387388457394839662831482428878447936 and s is > 377105405312767191687013088546003017320679158753 - definitely both <160 bit. FWIW, you may use gpg --debug 2 --list-packets to show the MPIs. > 1. is gpg doing the correct, FIPS-186-3 thing of throwing away the lower > bits? Yes. Libgcrypt does not enforce this because FIPS-186-2 does not seem to require it. Libgcrypt is currently in NIST's evaluation queue but the project was started far prior to June 2009 when -3 was released. > 2. is this safe? We hope so. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed Jan 13 11:18:57 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 13 Jan 2010 11:18:57 +0100 Subject: gnupg2 packaging, how to start gnupg-agent in X11 (Re: key generation failed on card) In-Reply-To: <4B400487.2050100@gmx.net> References: <4B3CFB98.4030909@gmx.net> <4B400487.2050100@gmx.net> Message-ID: <201001131119.01033.bernhard@intevation.de> Am Sonntag, 3. Januar 2010 03:44:23 schrieb Stefan Xenon: > I found the cause for this problem by myself: gpg-agent was not running. > As mentioned before it seems that I have to start gpg-agent manually > each time. If you were logged in via an X11 session, this sounds like an Ubuntu packaging issue. > Therefore I use the following solution: > http://www.linuxquestions.org/questions/linux-security-4/gpg-gpg-agent-cant >-connect-to-root.gnupgs.gpg-agent-611843/ We (as in Kolab-Konsortium) use the following solution for Debian packages (which we also submit upstream): Maintainer: Kolab-Konsortium Packager Source: gnupg2 Version: 2.0.13-0kk1 dpkg -L gnupg-agent | grep session /etc/X11/Xsession.d/90gpg-agent Our packages (no promisses) can be found here: http://files.kolab.org/apt/releases/dists/lenny/ For development purposes we also run a continous build system for some gnupg packages at http://saegewerk.wald.intevation.org/gnugp2-etch/index.html > Am 31.12.2009 20:29, schrieb Stefan Xenon: > > I compiled GnuPG 2.0.14 on Ubuntu 9.10 (using libgcrypt 1.4.4). When > > generating a key on an OpenPGP card v2 it fails right after entering > > "generate" and tells me "IPC Schreibfehler" (IPC write error). :::::::::::::: /etc/X11/Xsession.d/90gpg-agent :::::::::::::: : ${GNUPGHOME=$HOME/.gnupg} GPGAGENT=/usr/bin/gpg-agent PID_FILE="$GNUPGHOME/gpg-agent-info-$(hostname)" if test -x $GPGAGENT && { test -z "$GPG_AGENT_INFO" || ! $GPGAGENT 2>/dev/null; }; then if [ -r "$PID_FILE" ]; then . "$PID_FILE" fi # Invoking gpg-agent with no arguments exits successfully if the agent # is already running as pointed by $GPG_AGENT_INFO if ! $GPGAGENT 2>/dev/null; then STARTUP="$GPGAGENT --daemon --sh --write-env-file=$PID_FILE $STARTUP" fi fi -: Datei oder Verzeichnis nicht gefunden -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.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 sam at vilain.net Wed Jan 13 22:58:50 2010 From: sam at vilain.net (Sam Vilain) Date: Thu, 14 Jan 2010 10:58:50 +1300 Subject: [spf:guess] Re: DSA and SHA-256 (It works! Or does it?! :)) In-Reply-To: <877hrmz767.fsf@vigenere.g10code.de> References: <4B4D4CDF.2010902@vilain.net> <877hrmz767.fsf@vigenere.g10code.de> Message-ID: <4B4E421A.9070509@vilain.net> Werner Koch wrote: >> 1. is gpg doing the correct, FIPS-186-3 thing of throwing away the lower >> bits? >> > > Yes. > > Libgcrypt does not enforce this because FIPS-186-2 does not seem to > require it. Libgcrypt is currently in NIST's evaluation queue but the > project was started far prior to June 2009 when -3 was released. > Right. Is there an official test suite for that? Might see if I can't update Crypt::OpenPGP ... nice library, very accessible being in a HLL and even fast when you're using it with the C PARI. Of course most people are moving towards GPGME but still nice if it was up to date. >> 2. is this safe? >> > > We hope so. > See, this is why I worry, from Wang (2005)? Our attack naturally is applied to SHA-0 and all reduced variants of SHA-1. For SHA-0, the attack is so effective that we are able to find real collisions of the full SHA-0 with less than 2^39 hash operations [16]. We also implemented the attack on SHA-1 reduced to 58 steps and found real collisions with less than 2^33 hash operations. In a way, the 58-step SHA-1 serve as a simpler variant of the full 80-step SHA-1 which help us to verify the effectiveness of our new techniques. Furthermore, our analysis shows that the collision complexity of SHA-1 reduced to 70 steps is less than 2^50 hash operations. Because SHA-256 has fewer rounds than SHA-1, from my very na?ve grasp of the subject, it seems like it could be easier to find a collision by throwing those bits away, than by using SHA-1. Taking the approach of not shortening the hash output, but taking it modulus a very large prime would seem to lose that information rather than folding it back into the output via the 'mod q' at the end, where all the extra high bits will have a very profound and non-linear impact on the output values. I guess the thing would be to take one of those round/bit grids in the SHA attack papers, and show which bits through the rounds are "ignorable", and whether this allows more round tunneling. Of course I'm so far out of my depth I'll have to make decompression stops on my way out of this thread. Sam *1 "Finding collisions *in the *full SHA*-*1* " X Wang, YL Yin, H Yu - Lecture Notes in Computer Science, 2005 - Springer From lists at lina.inka.de Wed Jan 13 23:36:44 2010 From: lists at lina.inka.de (Bernd Eckenfels) Date: Wed, 13 Jan 2010 23:36:44 +0100 Subject: [spf:guess] Re: DSA and SHA-256 (It works! Or does it?! :)) In-Reply-To: <4B4E421A.9070509@vilain.net> References: <4B4D4CDF.2010902@vilain.net> <877hrmz767.fsf@vigenere.g10code.de> <4B4E421A.9070509@vilain.net> Message-ID: <20100113223644.GA13454@lina.inka.de> On Thu, Jan 14, 2010 at 10:58:50AM +1300, Sam Vilain wrote: > Because SHA-256 has fewer rounds than SHA-1, from my very na?ve grasp of > the subject, it seems like it could be easier to find a collision by > throwing those bits away, than by using SHA-1. Taking the approach of > not shortening the hash output, but taking it modulus a very large prime > would seem to lose that information rather than folding it back into the > output via the 'mod q' at the end, where all the extra high bits will > have a very profound and non-linear impact on the output values. I think the idea in cutting a hash is, that if the hash is strong, each bit is equally influenced, and there is no need to fold it (especilly when the folding is not something strong like XOR-ing). If the hash is not strong and does violate the principle that each changed input bit does not influence 50% of the hash bits, then it is too weak and the folding cannot strengthen the result. I am kind of trusting NIST they thought about it. Greetings Bernd From wk at gnupg.org Thu Jan 14 09:01:51 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Jan 2010 09:01:51 +0100 Subject: [spf:guess] Re: DSA and SHA-256 (It works! Or does it?! :)) In-Reply-To: <4B4E421A.9070509@vilain.net> (Sam Vilain's message of "Thu, 14 Jan 2010 10:58:50 +1300") References: <4B4D4CDF.2010902@vilain.net> <877hrmz767.fsf@vigenere.g10code.de> <4B4E421A.9070509@vilain.net> Message-ID: <878wc16ro0.fsf@vigenere.g10code.de> On Wed, 13 Jan 2010 22:58, sam at vilain.net said: > Right. Is there an official test suite for that? Might see if I can't You mean for OpenPGP: No. However we did tests between PGP and GnuPG thus we are quite confident that the GnuPG implementation is correct. For algorithm testing the NIST has the CAVS program; see http://csrc.nist.gov/groups/STM/cavp/ . > Because SHA-256 has fewer rounds than SHA-1, from my very na?ve grasp of > the subject, it seems like it could be easier to find a collision by > throwing those bits away, than by using SHA-1. Taking the approach of Things are much more complicate and in particular the SHA-2 suite wemt through many years of internal developemnt at, well, the NSA. Those guys know a bit about hash functions - at that time more than any researcher in the open community. > not shortening the hash output, but taking it modulus a very large prime > would seem to lose that information rather than folding it back into the > output via the 'mod q' at the end, where all the extra high bits will > have a very profound and non-linear impact on the output values. In my layman's view that is very unlikely. It somehow reminds me of that Enigma fix 75 years ago which actually helped to break it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at unixuser.org Mon Jan 18 11:28:11 2010 From: ueno at unixuser.org (Daiki Ueno) Date: Mon, 18 Jan 2010 19:28:11 +0900 Subject: [Announce] GPGME 1.3.0 released In-Reply-To: <4B4B0A0E.6010105@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "11 Jan 2010 12:22:54 +0100") References: <4B4B0A0E.6010105@ruhr-uni-bochum.de> Message-ID: <87wrzfzozo.fsf@broken.deisui.org> Hi, "Marcus Brinkmann" writes: > We are pleased to announce version 1.3.0 of GnuPG Made Easy, Thanks for the new release! I'm now trying to catch up the API changes for the Ruby binding. By the way, I noticed that the download page still points to gpgme-1.1.8.tar.bz2: http://www.gnupg.org/download/index.en.html#gpgme How about updating the link to 1.3.0 if it is a stable release? Regards, -- Daiki Ueno From wk at gnupg.org Mon Jan 18 14:19:03 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Jan 2010 14:19:03 +0100 Subject: [Announce] GPGME 1.3.0 released In-Reply-To: <87wrzfzozo.fsf@broken.deisui.org> (Daiki Ueno's message of "Mon, 18 Jan 2010 19:28:11 +0900") References: <4B4B0A0E.6010105@ruhr-uni-bochum.de> <87wrzfzozo.fsf@broken.deisui.org> Message-ID: <87aawb4kl4.fsf@vigenere.g10code.de> On Mon, 18 Jan 2010 11:28, ueno at unixuser.org said: > How about updating the link to 1.3.0 if it is a stable release? 1.3.0 requires libassuan 2.0 - this is a quite new version of the library and will get you in trouble if you want to build gnupg 2.0 and otehr current software. Only one developer version of libation may be installed on one system at a time without getting into some configuration problems. Thus I think it is okay not to announce 1.3.0 to widely. That plan is to make gnupg 2.0.15 depend on libassuan-2 and with that change we can go ahead and change all systems to depend on libassuan-2. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at unixuser.org Tue Jan 19 12:41:30 2010 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 19 Jan 2010 20:41:30 +0900 Subject: [Announce] GPGME 1.3.0 released In-Reply-To: <87aawb4kl4.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 18 Jan 2010 14:19:03 +0100") References: <4B4B0A0E.6010105@ruhr-uni-bochum.de> <87wrzfzozo.fsf@broken.deisui.org> <87aawb4kl4.fsf@vigenere.g10code.de> Message-ID: <87vdeyuxsl.fsf@broken.deisui.org> Werner Koch writes: > On Mon, 18 Jan 2010 11:28, ueno at unixuser.org said: > >> How about updating the link to 1.3.0 if it is a stable release? > > 1.3.0 requires libassuan 2.0 - this is a quite new version of the > library and will get you in trouble if you want to build gnupg 2.0 and > otehr current software. Only one developer version of libation may be > installed on one system at a time without getting into some > configuration problems. > > Thus I think it is okay not to announce 1.3.0 to widely. Ah, I see, thanks for the info. Then, is 1.2.0 the latest version of GPGME which depends on libassuan-1 (the webpage refers to 1.1.8 though)? Anyway, I'm going to play with libassuan-2 and the bleeding edge GnuPG family. It should be fun :-) Regards, -- Daiki Ueno From wk at gnupg.org Tue Jan 19 13:34:20 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Jan 2010 13:34:20 +0100 Subject: [Announce] GPGME 1.3.0 released In-Reply-To: <87vdeyuxsl.fsf@broken.deisui.org> (Daiki Ueno's message of "Tue, 19 Jan 2010 20:41:30 +0900") References: <4B4B0A0E.6010105@ruhr-uni-bochum.de> <87wrzfzozo.fsf@broken.deisui.org> <87aawb4kl4.fsf@vigenere.g10code.de> <87vdeyuxsl.fsf@broken.deisui.org> Message-ID: <877hre2rzn.fsf@vigenere.g10code.de> On Tue, 19 Jan 2010 12:41, ueno at unixuser.org said: > Ah, I see, thanks for the info. Then, is 1.2.0 the latest version of > GPGME which depends on libassuan-1 (the webpage refers to 1.1.8 though)? Yeah, that should be udpated. Marcus: Please remember to update swdb.wml in the web CVS after a release. > Anyway, I'm going to play with libassuan-2 and the bleeding edge GnuPG > family. It should be fun :-) For sure. The gpg part is more or less broken right now. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Fri Jan 22 15:13:47 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 22 Jan 2010 15:13:47 +0100 Subject: [Announce] GPGME 1.3.0 released In-Reply-To: <87aawb4kl4.fsf@vigenere.g10code.de> References: <4B4B0A0E.6010105@ruhr-uni-bochum.de> <87wrzfzozo.fsf@broken.deisui.org> <87aawb4kl4.fsf@vigenere.g10code.de> Message-ID: <201001221513.48334.bernhard@intevation.de> Am Montag, 18. Januar 2010 14:19:03 schrieb Werner Koch: > Thus I think it is okay not to announce 1.3.0 to widely. On the other hand, if you announce it properly, and place the warning in the announcement more people might see the warning and to the right thing because they know about what not to do. So I would be in favor of telling the story. Just my 2 cents, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.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 robbat2 at gentoo.org Tue Jan 26 00:18:33 2010 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Mon, 25 Jan 2010 23:18:33 +0000 Subject: OpenPGP sig notations - IANA registry vs. seen-in-the-wild Message-ID: <20100125231832.GB30531@orbis-terrarum.net> The RFC's describe the creation of a registry, but the most I can find is an empty one: http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-6 === 10.2.2.1. Signature Notation Data Subpackets ... Notations contain a user space that is completely unmanaged and an IETF space. === 1. Are there ANY IETF-registered notations? 2. I'm also looking for seen-in-the-wild notations, esp. common ones. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2 at gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 From dkg at fifthhorseman.net Tue Jan 26 06:00:15 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 26 Jan 2010 00:00:15 -0500 Subject: OpenPGP sig notations - IANA registry vs. seen-in-the-wild In-Reply-To: <20100125231832.GB30531@orbis-terrarum.net> References: <20100125231832.GB30531@orbis-terrarum.net> Message-ID: <4B5E76DF.8000400@fifthhorseman.net> On 01/25/2010 06:18 PM, Robin H. Johnson wrote: > The RFC's describe the creation of a registry, but the most I can find > is an empty one: > http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-6 > > === > 10.2.2.1. Signature Notation Data Subpackets > ... Notations contain a user space that is completely unmanaged and an IETF space. > === > > 1. Are there ANY IETF-registered notations? > 2. I'm also looking for seen-in-the-wild notations, esp. common ones. does it count as seen-in-the-wild if i'm doing it myself? I use lsigreason at notations.openpgp.fifthhorseman.net for non-exportable certifications that i make to keep a human-readable record of, say, e-mail continuity without having actually done full identity checks. These are good questions, and i'm interested in hearing what anyone else has encountered. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Tue Jan 26 06:28:36 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 26 Jan 2010 00:28:36 -0500 Subject: OpenPGP sig notations - IANA registry vs. seen-in-the-wild In-Reply-To: <20100125231832.GB30531@orbis-terrarum.net> References: <20100125231832.GB30531@orbis-terrarum.net> Message-ID: <70F61636-11A7-46BE-A7E3-4458F007D0AC@jabberwocky.com> On Jan 25, 2010, at 6:18 PM, Robin H. Johnson wrote: > The RFC's describe the creation of a registry, but the most I can find > is an empty one: > http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-6 > > === > 10.2.2.1. Signature Notation Data Subpackets > ... Notations contain a user space that is completely unmanaged and an IETF space. > === > > 1. Are there ANY IETF-registered notations? No. > 2. I'm also looking for seen-in-the-wild notations, esp. common ones. There are a whole bunch of "COMMENT" out there, which would be an illegal notation (not registered with IANA, and does not contain a '@'). Legal ones include preferred-email-encoding at pgp.com and pka-address at gnupg.org. I'm sure there are others. David From wk at gnupg.org Tue Jan 26 15:36:06 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Jan 2010 15:36:06 +0100 Subject: Passphrase problem in gpgsm 2.0.14 Message-ID: <874om9vsq1.fsf@vigenere.g10code.de> Hi! While preparing a new release of Gpg4win we found a regression in GnuPG 2.0.14. The problem is due to this change: * New and changed passphrases are now created with an iteration count requiring about 100ms of CPU work. I don't know how it slipped through my tests, but somehow it happend. The bug occurs in all cases where gpg-agent creates a new protected key or changes the protection. For example: - You import a new private key with GPGSM from a PKCSC#12 file. - You change the passphrase of a X.509 key (gpgsm --passwd) - You create or import a new on-disk Secure Shell key. It does not affect keys or passphrases related to GPG (OpenPGP keys). The bug is that the new iteration count is not encoded in the file. Instead the old constant value of 65536 (encoded as 96) is written to the file. If you now try to use the key and enter the passphrase, gpg-agent uses the wrong iteration count from the file (65536) and thus can't unprotect the key. A patch against 2.0.14 is attached. It is possible to fixup the wrong iteration counts but before I add such a feature, I would like to know whether this is really needed. - If you imported a p12 file you may simply re-import that file after deleting the old file. To find the respective file with the private key, you use this command gpgsm --dump-cert KEYID | grep keygrip: The hex-string you see is the basename of private key. For example: $ gpgsm --dump-cert 0x036A1456 | grep keygrip: keygrip: 25268070E915E1E3DCCBD9EBEF18BCEF9B0AB289 $ ls -l private-keys-v1.d/25268070E915E1E3DCCBD9EBEF18BCEF9B0AB289.key You better delete this file before importing the p12 file again: $ rm private-keys-v1.d/25268070E915E1E3DCCBD9EBEF18BCEF9B0AB289.key - If you changed the passphrase and you have a backup of the private key, it will be easier to use the backup. - If you did not changed the passphrase, you don't have any problem. - If there is no other way to restore it, please complain and I will write a tool to fixup the mess. I am sorry for the possible trouble. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.0.14-encode-s2k.patch Type: text/x-patch Size: 1384 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From keisuke.inoue at mizuho-ir.co.jp Thu Jan 28 05:00:20 2010 From: keisuke.inoue at mizuho-ir.co.jp (keisuke.inoue at mizuho-ir.co.jp) Date: Thu, 28 Jan 2010 13:00:20 +0900 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant Message-ID: Dear GnuPG developers My name is Keisuke Inoue, a member of Mizuho Information & Research Institute, Inc. It is a company in Japan. I am a software engineer, and now I and my co-workers are engaging a project, to develop a software based on GnuPG2 (version 2.0.12), and obtain the JCMVP certification. JCMVP stands for "Japan Cryptographic Module Validation Program", and it certifies that the program is compliant with ISO/IEC 19790. We hope our product will be merged into the original GnuPG2, to make it a program that can be used widely, including governmental organizations. For that purpose, we are adding implementation of the following functionalities: - RSAES-OAEP (PKCS#1 v2.1) - RSASSA-PSS (PKCS#1 v2.1) - Hash_DRBG (NIST SP800-90) Mr. Naritoshi Yoshinaga, the manager of our project, has contacted Mr. Koch when we started this project and got a positive reply. In the near future we will release our project product, so I post this mail to get feedbacks from mailing list members too. I will report about our project again, by posting mails to this mailing list. Sincerely, Keisuke Inoue From simon at josefsson.org Thu Jan 28 14:06:18 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 28 Jan 2010 14:06:18 +0100 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: (keisuke inoue's message of "Thu, 28 Jan 2010 13:00:20 +0900") References: Message-ID: <87aavybcqd.fsf@mocca.josefsson.org> keisuke.inoue at mizuho-ir.co.jp writes: > - RSAES-OAEP (PKCS#1 v2.1) > - RSASSA-PSS (PKCS#1 v2.1) Are you implementing this in GnuPG or libgcrypt? It would be useful to have this in libgcrypt, to be able to use it for X.509 and TLS in GnuTLS. Thanks, /Simon From keisuke.inoue at mizuho-ir.co.jp Fri Jan 29 02:38:30 2010 From: keisuke.inoue at mizuho-ir.co.jp (keisuke.inoue at mizuho-ir.co.jp) Date: Fri, 29 Jan 2010 10:38:30 +0900 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: <87aavybcqd.fsf@mocca.josefsson.org> Message-ID: Dear Simon Simon Josefsson wrote on 2010/01/28 22:06:18: > keisuke.inoue at mizuho-ir.co.jp writes: > > > - RSAES-OAEP (PKCS#1 v2.1) > > - RSASSA-PSS (PKCS#1 v2.1) > > Are you implementing this in GnuPG or libgcrypt? It would be useful to > have this in libgcrypt, to be able to use it for X.509 and TLS in > GnuTLS. Hello. Thank you for your interest in our project. We implemented these functions in GnuPG, because in original gnupg 2.0.12, EMSA-PKCS-v1_5 encoding was implemented in gnupg ( do_encode_md() in g10/seskey.c ), not libgcrypt. Maybe it was possible to move EMSA-PKCS-v1_5 encoding implementation into libgcrypt, add EMSA-PSS-Encode, EME-OAEP-Encode into libgcrypt, but we didn't chose that strategy. The reason is that if we choose that strategy, we would have to modify so many files, and it will be difficult to merge our modifications into original gnupg 2.0.x. Sincerely, Keisuke Inoue From wk at gnupg.org Fri Jan 29 10:33:04 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jan 2010 10:33:04 +0100 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: (keisuke inoue's message of "Fri, 29 Jan 2010 10:38:30 +0900") References: Message-ID: <87636luugf.fsf@vigenere.g10code.de> On Fri, 29 Jan 2010 02:38, keisuke.inoue at mizuho-ir.co.jp said: > We implemented these functions in GnuPG, because in original > gnupg 2.0.12, EMSA-PKCS-v1_5 encoding was implemented in gnupg > ( do_encode_md() in g10/seskey.c ), not libgcrypt. The reasons for that we added the pkcsc#1 encoding only later to libgcrypt and never bothered to remove the code in GnuPG. It will be done in 2.1, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 29 10:42:30 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jan 2010 10:42:30 +0100 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: <87aavybcqd.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 28 Jan 2010 14:06:18 +0100") References: <87aavybcqd.fsf@mocca.josefsson.org> Message-ID: <871vh9uu0p.fsf@vigenere.g10code.de> On Thu, 28 Jan 2010 14:06, simon at josefsson.org said: > Are you implementing this in GnuPG or libgcrypt? It would be useful to > have this in libgcrypt, to be able to use it for X.509 and TLS in > GnuTLS. What I forgot to mention. We do have OAEP patches available; I just missed to apply them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Fri Jan 29 10:56:23 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Jan 2010 10:56:23 +0100 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: <871vh9uu0p.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 29 Jan 2010 10:42:30 +0100") References: <87aavybcqd.fsf@mocca.josefsson.org> <871vh9uu0p.fsf@vigenere.g10code.de> Message-ID: <87hbq56xq0.fsf@mocca.josefsson.org> Werner Koch writes: > On Thu, 28 Jan 2010 14:06, simon at josefsson.org said: > >> Are you implementing this in GnuPG or libgcrypt? It would be useful to >> have this in libgcrypt, to be able to use it for X.509 and TLS in >> GnuTLS. > > What I forgot to mention. We do have OAEP patches available; I just > missed to apply them. It would be nice to get them into libgcrypt -- I don't recall any OAEP TLS ciphersuites, but it will help to have libgcrypt be ready once they do appear so people won't have to upgrade libgcrypt too. On the other hand, maybe TLS will just skip OAEP and do PSS. Or neither... /Simon From ueno at unixuser.org Fri Jan 29 13:01:05 2010 From: ueno at unixuser.org (Daiki Ueno) Date: Fri, 29 Jan 2010 21:01:05 +0900 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: <871vh9uu0p.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 29 Jan 2010 10:42:30 +0100") References: <87aavybcqd.fsf@mocca.josefsson.org> <871vh9uu0p.fsf@vigenere.g10code.de> Message-ID: <87vdelp1by.fsf@broken.deisui.org> Werner Koch writes: >> Are you implementing this in GnuPG or libgcrypt? It would be useful to >> have this in libgcrypt, to be able to use it for X.509 and TLS in >> GnuTLS. > > What I forgot to mention. We do have OAEP patches available; I just > missed to apply them. Perhaps one of the patches was written by me - but I don't mind which version (my patch or Inoue-san's patch or another) will be adopted to the future version of GnuPG or libgcrypt. However, I have a question about PSS. According to the Appendix D of PKCS#1 (RFC3447), the University of California claims the patent for PSS. What do you think about this? Regards, -- Daiki Ueno From simon at josefsson.org Fri Jan 29 13:21:47 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Jan 2010 13:21:47 +0100 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: <87vdelp1by.fsf@broken.deisui.org> (Daiki Ueno's message of "Fri, 29 Jan 2010 21:01:05 +0900") References: <87aavybcqd.fsf@mocca.josefsson.org> <871vh9uu0p.fsf@vigenere.g10code.de> <87vdelp1by.fsf@broken.deisui.org> Message-ID: <87fx5p5cf8.fsf@mocca.josefsson.org> Daiki Ueno writes: > However, I have a question about PSS. According to the Appendix D of > PKCS#1 (RFC3447), the University of California claims the patent for > PSS. What do you think about this? Interesting, I hadn't noticed that. I'll defer to Werner on this, but personally I think it makes sense for FSF to look into this from a legal point of view. Btw, IETF's patent disclosure page did not indicate this issue, so I have filed a third-party notification about it. /Simon From wk at gnupg.org Fri Jan 29 13:48:44 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jan 2010 13:48:44 +0100 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: <87fx5p5cf8.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 29 Jan 2010 13:21:47 +0100") References: <87aavybcqd.fsf@mocca.josefsson.org> <871vh9uu0p.fsf@vigenere.g10code.de> <87vdelp1by.fsf@broken.deisui.org> <87fx5p5cf8.fsf@mocca.josefsson.org> Message-ID: <87pr4tt6tv.fsf@vigenere.g10code.de> On Fri, 29 Jan 2010 13:21, simon at josefsson.org said: > Interesting, I hadn't noticed that. I'll defer to Werner on this, but > personally I think it makes sense for FSF to look into this from a legal Actually one of the reasons we avoided OAEP in the past were rumors of patent claims. I can't remember the details. We now have ECDSA in Libcrypt because it seems to be an innocent implementaion. However, out of patent fears Redhat does not include the ECDSA in there distribution. Definitely something we should investigate. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From keisuke.inoue at mizuho-ir.co.jp Fri Jan 29 14:08:21 2010 From: keisuke.inoue at mizuho-ir.co.jp (keisuke.inoue at mizuho-ir.co.jp) Date: Fri, 29 Jan 2010 22:08:21 +0900 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: <87pr4tt6tv.fsf@vigenere.g10code.de> Message-ID: gnupg-devel-bounces at gnupg.org wrote on 2010/01/29 21:48:44: > On Fri, 29 Jan 2010 13:21, simon at josefsson.org said: > > > Interesting, I hadn't noticed that. I'll defer to Werner on this, but > > personally I think it makes sense for FSF to look into this from a legal > > Actually one of the reasons we avoided OAEP in the past were rumors of > patent claims. I can't remember the details. > > We now have ECDSA in Libcrypt because it seems to be an innocent > implementaion. However, out of patent fears Redhat does not include the > ECDSA in there distribution. > > Definitely something we should investigate. I found a web page related to this issue. http://grouper.ieee.org/groups/1363/P1363/letters/UC.html Reading this page, I think the University of California will be welcome if we contact them, because implemention of RSA-PSS in GnuPG will surely be a contribution for "widespread use of the highest quality mechanisms for cryptography and computer security". I'm not sure which is the adequate organization to contact them, GnuPG developer community, or FSF (as Mr. Simon refered) though... Keisuke Inoue From bernhard at intevation.de Fri Jan 29 17:18:33 2010 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 29 Jan 2010 17:18:33 +0100 Subject: Passphrase problem in gpgsm 2.0.14 In-Reply-To: <874om9vsq1.fsf@vigenere.g10code.de> References: <874om9vsq1.fsf@vigenere.g10code.de> Message-ID: <201001291718.38928.bernhard@intevation.de> Am Dienstag, 26. Januar 2010 15:36:06 schrieb Werner Koch: > A patch against 2.0.14 is attached. The signature on the email was broken for me (and for Marcus), this is for the email received via the email list. Werner, I suggest to also send around a .asc for the patch or send me the original email from your outbox so I can see if this is a Mailman issue. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.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 simon at josefsson.org Fri Jan 29 17:46:48 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 29 Jan 2010 17:46:48 +0100 Subject: About a project to make gnupg2 ISO/IEC 19790 compliant In-Reply-To: <87fx5p5cf8.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 29 Jan 2010 13:21:47 +0100") References: <87aavybcqd.fsf@mocca.josefsson.org> <871vh9uu0p.fsf@vigenere.g10code.de> <87vdelp1by.fsf@broken.deisui.org> <87fx5p5cf8.fsf@mocca.josefsson.org> Message-ID: <87hbq4270n.fsf@mocca.josefsson.org> Simon Josefsson writes: > Btw, IETF's patent disclosure page did not indicate this issue, so I > have filed a third-party notification about it. FWIW, it has now been posted at: https://datatracker.ietf.org/ipr/1255/ /Simon From rose-indorf at gmx.de Sat Jan 30 01:40:34 2010 From: rose-indorf at gmx.de (Sebastian Rose-Indorf) Date: Sat, 30 Jan 2010 01:40:34 +0100 Subject: GnuPG 1.4.10: Key generation failed: Timestamp conflict Message-ID: Hello list, I'am using GnuPG 1.4.10 with a modified ECC module (original: http://www.calcurco.cat/eccGnuPG/). Now, I have tried to generate a ECC key pair: gpg --gen-key. At the end - after choice the passphrae -, however, I get the following error: "Schl?sselerzeugung fehlgeschlagen: Zeitangaben differieren" (Key generation failed: Timestamp conflict). What does this error message mean and how can I overcome the problem? Regards! seb.