From bem@cmc.net Tue May 2 22:17:12 2000 From: bem@cmc.net (brian moore) Date: Tue, 2 May 2000 15:17:12 -0700 Subject: general compatibility with PGP... Message-ID: <20000502151712.K31948@cmc.net> This seems to fail: -------- This is a test file for GPG/PGP/OpenPGP compatibility. This line ends with a tab for no good reason: Thanks for the test. This file ends with a blank line. -------- The above file, once signed (with gpg --sign -a -t testfile, which is what the docs imply is the 'pgp compatibility hack'), will not verify with PGP5, and PGP5 will also strip the last blank line. Who is right on the reading of 'text mode' on this? Or should there be a '--broken-text-mode' flag to appease PGP5? It's sort of annoying since Network Solutions likes sending forms with lines ending in tabs and spaces (I dunno -why-, they just do!) and I have to be sure I do a ':%s/[ ^I]\+$//' before signing stuff and ensure I have an extra blank line at the end. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From nittka@esem.com Thu May 4 07:37:03 2000 From: nittka@esem.com (Oliver Nittka) Date: 04 May 2000 09:37:03 +0200 Subject: [mailing-lists.reiserfs] (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Message-ID: --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit this may become very important for all open-source-projects, so i'll forward it to this list. -- oly -- Oliver Nittka | nittka@esem.com ESEM Grünau GmbH & Co. KG | http://www.esem.com Dornierstraße 6 | phone: +49 7544 9583-25 88677 Markdorf / Germany | fax: +49 7544 9583-60 --=-=-= Content-Type: message/rfc822; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit From: Xuan Baldauf Subject: (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Date: Thu, 04 May 2000 00:23:53 +0200 Message-ID: <3910A6F9.705A11A7@exmail.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------AC179D27851ED6C2526ACC47" To: reiserfs@devlinux.com Mailing-List: contact reiserfs-help@devlinux.com; run by ezmlm This is a multi-part message in MIME format. --------------AC179D27851ED6C2526ACC47 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I'm sorry for spamming the majority of not german list readers, but for those who are, this might be very important: The European Union plans to accept software patents. SWPats will slow down open source development, because large software companies can afford patenting algorithms which are easy and obvious, along with others which are complicated and advanced. If ever a clever (kernel) hacker finds an algorithm for a specific problem, there will be a good chance that this algorithm is a patent infringement. For their economic interest, large software companies will sue (kernel) hackers, and because large software companies have much more money, (kernel) hackers will give up, and open-source development will handicapped, probably at large scale, because nobody wants to be sued only to be a good (kernel) hacker. The most prominent example is "the GIF patent", the gd library ( http://www.boutell.com/gd/ ) was forced to give up GIF support. If you are against this scarious development, which is already possible in the USA, but not in Europe, and if you are german, read the following. Thanks for reading although being offtopic. Xuân. --------------AC179D27851ED6C2526ACC47 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Disposition: inline Return-Path: Received: from localhost (root@localhost [127.0.0.1]) by router.abc (8.8.8/8.8.8) with ESMTP id XAA22039 for ; Wed, 3 May 2000 23:48:57 +0200 Delivered-To: exmail-de-kW@exmail.de Received: from pop1.exmail.de by localhost with POP3 (fetchmail-5.1.0) for root@localhost (single-drop); Wed, 03 May 2000 23:48:58 +0200 (CEST) Received: (qmail 8455 invoked by uid 409); 3 May 2000 21:48:27 -0000 Delivered-To: medium-net-kW@medium.net Received: (qmail 8452 invoked from network); 3 May 2000 21:48:26 -0000 Received: from robin.camelot.de (HELO mail.camelot.de) (root@195.30.224.3) by plato.exmail.de with SMTP; 3 May 2000 21:48:26 -0000 Received: from robin.camelot.de (daemon@robin.camelot.de [195.30.224.3]) by mail.camelot.de (8.9.3/8.9.3) with ESMTP id XAA39885; Wed, 3 May 2000 23:47:55 +0200 (CEST) Received: from localhost (daemon@localhost) by robin.camelot.de (8.9.3/8.9.3) with SMTP id XAA39877; Wed, 3 May 2000 23:47:55 +0200 (CEST) Received: by robin.camelot.de (CameloT blkmail v1.12); Wed, 3 May 2000 23:47:53 +0200 Received: from robin.camelot.de (majordom@robin.camelot.de [195.30.224.3]) by mail.camelot.de (8.9.3/8.9.3) with ESMTP id XAA39834 for ; Wed, 3 May 2000 23:47:52 +0200 (CEST) Received: (from majordom@localhost) by robin.camelot.de (8.9.3/8.9.3) id XAA39829 for a2e-de-ffii.outgoing; Wed, 3 May 2000 23:47:52 +0200 (CEST) Date: Wed, 3 May 2000 21:44:56 +0000 (/etc/localtime) From: PILCH Hartmut X-Sender: phm@wtao97.oas.a2e.de To: FFII-Nachrichten Subject: BMWi-Konferenz: So koennen Sie helfen Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.camelot.de id XAA39826 Sender: owner-a2e-de-ffii@camelot.de X-Mozilla-Status2: 00000000 Bitte weiterverbreiten! lynx -dump http://swpat.ffii.org/penmi/bmwi-20000518/ ---------------------------------------- Die wirtschaftlichen Auswirkungen der Software-Patentierung Das Bundeswirtschaftsministerium hält am 18. Mai 2000 in Berlin eine öffentliche Tagung ab, auf der die wirtschaftlichen Auswirkungen der Patentierbarkeit von Logikalien untersucht werden sollen. Der Förderverein für eine Freie Informationelle Infrastruktur und die [6]Förderer seiner [7]Softwarepatent-Arbeitsgruppe sind eingeladen. Wir werden uns an in dieser [8]Konferenz aktiv beteiligen. Der FFII wird gegen die Ausdehnung des Europäischen Patentwesens in immer industriefernere Sphären argumentieren. Diese Konferenz ist eine seltene Chance. Sie muss ein Erfolg für all diejenigen werden, die von informatischem Monopolismus nichts gutes zu erwarten haben. Sie können auf verschiedenerlei Weise dazu beitragen. Was Sie tun können * An der Konferenz teilnehmen Die Konferenz ist öffentlich, aber die Teilnehmer sollten sich vorher anmelden und beim Veranstalter eine kurzes Positionspapier abgeben. Setzen Sie sich dazu mit uns in Verbindung. Wir haben in Berlin auch ein paar Hotelbetten reserviert. * Weitere Teilnehmer werben Dies ist eine erste und vielleicht letzte Gelegenheit für Programmierer und Firmen, sich über schicksalsentscheidende Entwicklungen kundig zu machen und darauf einzuwirken. Bitte sprechen Sie Firmen und Personen in Ihrem Einflussbereich an. Bringen Sie sie u.U. in Kontakt mit uns, damit wir bei der Abfassung von Positionspapieren helfen und bei der Vorbereitung der Konferenz zusammenarbeiten können. * Dokumention zusammenstellen helfen Der FFII stellt eine [15]Dokumentation (gedruckt und auf CD) zusammen. Wir müssen viele Verlagshäuser um Kopiererlaubnis bitten und manche wichtigen Texte sind von nicht-digitalen Datenträgern her zu erfassen. Diese Arbeit wird von der Intevation GmbH im Auftrag des FFII über ein [16]öffentlich zugängliches Forum geleistet. Ihre Teilnahme ist sehr willkommen. Der FFII ist dank seiner Förderer in der glücklichen Lage, für geleistete Arbeit Entschädigungen auf Stundenbasis zahlen zu können. Hintergrund der Konferenz Die Europäischen Patentorganisationen und die EU-Kommission beseitigen derzeit alle gesetzlichen Hürden, die bisher noch der Patentierung von Logikalien (Software) im Wege stehen. Es ist das erste Mal, dass eine Regierungsorganisation in Europa die Frage nach den Auswirkungen dieser Veränderungen auf die Wirtschaft und das Gemeinwohl stellt. Die Bundesregierung ist Vertragsstaat des Europäischen Patentabkommens und muss als solche alle Änderungen dieses Abkommens genehmigen. Verweigert sie ihre Zustimmung, so werden "Programme für Datenverarbeitungsanlagen" weiterhin auf der Liste der Ausnahmen von der Patentierbarkeit in §52 EPÜ bleiben. Andernfalls wird der Weg für die volle Durchsetzung von Logikalienpatenten in Europa und Deutschland noch dieses Jahr frei. Der FFII befürchtet, dass Logikalienpatentierbarkeit zu proprietären Standards (d.h. Blockierung von Kompatibilität durch private Besitzansprüche) führt, Monopoltendenzen stärkt, die Erneuerungskräfte hemmt und insbesondere kleine und mittlere Softwarefirmen gefährdet. In wenigen Monaten könnte eine lange angestaute Lawine von Drohbriefen und Patentprozessen über uns hereinbrechen, und Sie werden vielleicht sich daran gewöhnen müssen, einen Patentanwalt aufzusuchen, bevor Sie ihre Programm-Quelltexte im Netz veröffentlichen. Es wird dann sicherlich zu spät sein, irgendetwas dagegen zu tun. Handeln wir also jetzt. Machen wir die Berliner Konferenz zu einem großen Erfolg. Unterzeichner Markus Fleck Joerg Freudenberger Hartmut Pilch Bernhard Reiter Arnim Rupp _________________________________________________________________ http://swpat.ffii.org/penmi/bmwi-20000518/indexde.html 2000-05-03 PILCH Hartmut Verweise 6. http://swpat.ffii.org/sarji/ 7. http://swpat.ffii.org/ag/ 8. http://www.sicherheit-im-internet.de/news/news.php3?id=125 15. http://swpat.ffii.org/links/doku/ 16. http://ffii.org/mailman/listinfo/swpatdoku/ --------------AC179D27851ED6C2526ACC47-- --=-=-=-- From Klaus Singvogel Tue May 9 15:35:46 2000 From: Klaus Singvogel (Klaus Singvogel) Date: Tue, 9 May 2000 17:35:46 +0200 Subject: Patch: FAQ Message-ID: <20000509173546.A15460@Caldera.DE> Even the patch for the FAQ describes it now correct, I can't decrypt such a GnuPG generated message with PGP V2.6.3ii I'll investigate it and tell you more AFAIK more. Regards, Klaus. --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 @@ -123,7 +123,7 @@ supported by GnuPG because it is patented, but if you have a modified version of PGP you can try this: - gpg --rfc1991 --cipher-algo 3des ... + gpg --rfc1991 --cipher-algo idea ... Please don't pipe the data to encrypt to gpg but give it as a filename; other wise, pgp 2 will not be able to handle it. From wk@gnupg.org Tue May 9 17:29:22 2000 From: wk@gnupg.org (Werner Koch) Date: Tue, 9 May 2000 19:29:22 +0200 Subject: Patch: FAQ In-Reply-To: <20000509173546.A15460@Caldera.DE>; from ks@caldera.de on Tue, May 09, 2000 at 05:35:46PM +0200 References: <20000509173546.A15460@Caldera.DE> Message-ID: <20000509192922.C4283@djebel.gnupg.de> On Tue, 9 May 2000, Klaus Singvogel wrote: > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > @@ -123,7 +123,7 @@ > supported by GnuPG because it is patented, but if you have a modified > version of PGP you can try this: > > - gpg --rfc1991 --cipher-algo 3des ... > + gpg --rfc1991 --cipher-algo idea ... Watch out for the "...modified version of PGP .." - I assume that this is will be a 3DES one ;-). The GNU project does not support patented algorithms and therefore you won't read IDEA in it :-). Yes, I know that there are some countries where there is no valid patent on IDEA. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From Klaus Singvogel Wed May 10 09:57:09 2000 From: Klaus Singvogel (Klaus Singvogel) Date: Wed, 10 May 2000 11:57:09 +0200 Subject: Patch: FAQ In-Reply-To: <20000509192922.C4283@djebel.gnupg.de>; from wk@gnupg.org on Tue, May 09, 2000 at 07:29:22PM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> Message-ID: <20000510115709.A30043@Caldera.DE> On Tue, May 09, 2000 at 07:29:22PM +0200, Werner Koch wrote: > On Tue, 9 May 2000, Klaus Singvogel wrote: > > > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > > @@ -123,7 +123,7 @@ > > supported by GnuPG because it is patented, but if you have a modified > > version of PGP you can try this: > > > > - gpg --rfc1991 --cipher-algo 3des ... > > + gpg --rfc1991 --cipher-algo idea ... > > Watch out for the "...modified version of PGP .." - I assume that this > is will be a 3DES one ;-). The GNU project does not support patented > algorithms and therefore you won't read IDEA in it :-). Yes, I know > that there are some countries where there is no valid patent on IDEA. Sorry, but the FAQ speaks at this point of encryption for pgp 2.x Yes, you have to have a modified version GnuPG, but you have to use the (patented) idea algorithmen as cipher algorithmen too (and not 3des). Thats what I correct in the FAQ. I know, you can use 3des to make GnuPG encrypted messages readable for pgp 5.x or 6.x users. But that's not the point the FAQ speaks here of. Another point: I build a modified version of GnuPG: I built the idea/rsa modules, added the "load-extension idea" "load-extension rsa" lines to my .gnupg/options, and check with "strace" if the modules where used/opened (they were :-) But still I can't encrypt a message with GnuPG 1.0.1 (rsa 1.10 and idea 1.11) for a pgp-2.6.3ii user (myself). I get the error message Error: Decrypted plaintext is corrupted. If I look into the source-code I see that the error comes from the idea decryption. I currently investigate this. My current assumption is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does decryption in CBC mode. But I'm not sure, since I don't understand the idea.c completly yet. I'll tell you more, if I find the error. Regards, Klaus. -- .-. | Klaus Singvogel oo| | Caldera (Deutschland) GmbH, Naegelsbachstr. 49c, 91052 Erlangen /`'\ | email: ks@caldera.de internet: http://www.caldera.de (\_;/) | phone: ++49 9131 7192-300 fax: ++49 9131 7192-399 From az096@freenet.toronto.on.ca Wed May 10 12:13:13 2000 From: az096@freenet.toronto.on.ca (Robert Guerra) Date: Wed, 10 May 2000 08:13:13 -0400 Subject: Fwd:ANNOUNCEMENT: PGP Desktop Security 7.0 Message-ID: I'm sending this along in case people on here may have not seen it before. on first reading it looks like pgp (from NAI) is slowly morphing into a larger and larger beast. I hope that the folks from NAI follow the openpgp specs as they should so the new client can be as compatible as possible with gnupg. time will tell.. regards robert --- begin forwarded text Date: Tue, 09 May 2000 10:43:33 -0700 From: Will Price Subject: [PGP-USERS] ANNOUNCEMENT: PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today, we officially announced PGP Desktop Security 7.0. Here is the press release: http://biz.yahoo.com/prnews/000509/nv_neta_pg_1.html The beta program (which is already almost completely filled, so please don't ask) will begin this month and you should see the final version in early Q3. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 165 Alpha) iQA/AwUBORhOH6y7FkvPc+xMEQKvDwCguLKbVGyrUeevvP9hNGtem9ZKaGAAn2+B O8b6AFDrrbVt8A53oxED6IEy =OBdf -----END PGP SIGNATURE----- ..................................................................... Unsubscribe: Automated Help/Info: List Homepage: List Admin (human): Please do not send administrative commands to the list address! Thanks. --- end forwarded text -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From wk@gnupg.org Wed May 10 14:24:13 2000 From: wk@gnupg.org (Werner Koch) Date: Wed, 10 May 2000 16:24:13 +0200 Subject: Patch: FAQ In-Reply-To: <20000510115709.A30043@Caldera.DE>; from ks@caldera.de on Wed, May 10, 2000 at 11:57:09AM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> <20000510115709.A30043@Caldera.DE> Message-ID: <20000510162413.L7032@djebel.gnupg.de> On Wed, 10 May 2000, Klaus Singvogel wrote: > use the (patented) idea algorithmen as cipher algorithmen too (and > not 3des). Thats what I correct in the FAQ. If you look at the PGP 2 data formats (e.g. rfc1991) you will notice that there is indeed an algorithm indetifier and therefore it is possible to replace IDEA by 3DES (or better CAST5 which uses the same keysize and can be done very easily). Please read the GPL before _distributing_ GnuPG together with a module which implements a patented algorithm; doing so might vilolate the GPL. > If I look into the source-code I see that the error comes from the > idea decryption. I currently investigate this. My current assumption > is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does > decryption in CBC mode. But I'm not sure, since I don't understand Nope. The cipher modules are the low level encryption. The chaining is done in cipher/cipher.c and the same for all symmetric ciphers. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Wed May 10 20:08:08 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 10 May 2000 21:08:08 +0100 Subject: Solaris random device Message-ID: <20000510210808.A9104@tehran.nmrc.ucc.ie> Hi all, I just subscribed here, because the problem I'm facing now is probably not appropriate for -users ... After openssh failed when I upgraded to Solaris 8, I was looking for an alternative to egd and found Andreas Maier's random device for Solaris (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with openssl/openssh. I can generate keys, make connections, no problem. I'm now trying to use the random device with gpg, but it doesn't work. $ ./configure --prefix=$HOME --disable-nls --enable-static-rnd=linux (don't now if --enable-static-rnd=linux necessary - it doesn't make a difference if I leave this out) ... checking for random device... yes checking for linux/random.h... no checking for random device ioctl... no ... $ make check ... gpg (GnuPG) 1.0.1e Copyright (C) 2000 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: . Supported algorithms: Cipher: 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160, TIGER PASS: version.test PASS: mds.test PASS: decrypt.test PASS: decrypt-dsa.test and there it seems to hang. I'm attaching truss to the running copy of gpg and get ... poll(0xFFBED588, 1, 3000) Err#6 ENXIO write(2, " s e l e c t ( ) e r r".., 16) = 16 write(2, " N o s u c h d e v i".., 25) = 25 write(2, "\n", 1) = 1 [repeats over and over] Any suggestions? Is it possible that the current code is too Linux/BSD specific? Thanks. From Nils@infosun.fmi.uni-passau.de Thu May 11 07:53:28 2000 From: Nils@infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Thu, 11 May 2000 09:53:28 +0200 (MEST) Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie> References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> >>>"LH" == Lars Hecking writes: LH> After openssh failed when I upgraded to Solaris 8, I was looking for an LH> alternative to egd and found Andreas Maier's random device for Solaris LH> (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with LH> openssl/openssh. I can generate keys, make connections, no problem. I don't know about Andi Maier's device, but egd has been updated to work with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several weeks by now. Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From wk@gnupg.org Thu May 11 08:41:04 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 10:41:04 +0200 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511104104.A7032@djebel.gnupg.de> On Wed, 10 May 2000, Lars Hecking wrote: > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. IIRC, gpg checks that it is a character device - maybe the Solaris /dev/random is implemented as another type of device. (Patches are welcome) Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From listmaster@gnupg.org Thu May 11 09:19:14 2000 From: listmaster@gnupg.org (Lord of the Lists) Date: Thu, 11 May 2000 11:19:14 +0200 Subject: external keystore option? Message-ID: <20000511111914.I7032@djebel.gnupg.de> ----- Forwarded message from "Mikolaj J. Habryn" ----- Date: Thu, 11 May 2000 10:58:59 +0200 From: "Mikolaj J. Habryn" To: gnupg-devel@gnupg.org Subject: external keystore option? X-Diagnostic: Mail coming from a daemon, ignored Are there any plans for or opinions on the possibility of separating out the sensitive key management operations in gnupg (along the lines of ssh-agent for ssh)? I had a dig through the archives (a while ago), and recall seeing the subject come up once, but with no definitive resolution. I would like to see such functionality in gnupg; there are certain situations (such as Debian package creation) where a flexible policy engine would save a fair bit of passphrase retyping. My reason for asking is not purely academic; I recently published keymgr, an application designed to serve this purpose, whose only real claims to fame at present are a pretense to modularity and enough functionality to allow one to keep one's ssh keys on a Java ring. I've cobbled together enough code fragments to probably allow it to fake the desired effect by using a wrapper for gpg along with --passphrase-fd option (and obviously tracking passphrases in keymgr), but it's something of a suboptimal solution. m. ----- End forwarded message ----- -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From wk@gnupg.org Thu May 11 09:42:44 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 11:42:44 +0200 Subject: external keystore option? In-Reply-To: <20000511111914.I7032@djebel.gnupg.de>; from listmaster@gnupg.org on Thu, May 11, 2000 at 11:19:14AM +0200 References: <20000511111914.I7032@djebel.gnupg.de> Message-ID: <20000511114244.M7032@djebel.gnupg.de> On Thu, 11 May 2000, Lord of the Lists wrote: > ----- Forwarded message from "Mikolaj J. Habryn" ----- > Are there any plans for or opinions on the possibility of separating > out the sensitive key management operations in gnupg (along the lines > of ssh-agent for ssh)? I had a dig through the archives (a while ago), > and recall seeing the subject come up once, but with no definitive > resolution. This is scheduled for 1.1 but due to all the remaining work on 1.0 it will take some more time to start with it. I'd would very much appreciate help for GnuPG from volunteers who can sign an copyright assignment for the FSF. Without that legal paper I have to review all the pacthes and look at the idea only :-( > My reason for asking is not purely academic; I recently published > keymgr, an application designed to serve this purpose, whose only real > claims to fame at present are a pretense to modularity and enough > functionality to allow one to keep one's ssh keys on a Java ring. BTW, Brian Warner did some experiments with a PalmPilot and sent me the outline for a protocol to be used between the decryption/signing engine on some device and gpg. However, I have not yet found the time to work on it and franky I can't find it right now in my mail archives :-( Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Thu May 11 09:47:43 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 10:47:43 +0100 Subject: Solaris random device In-Reply-To: <20000511104104.A7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 10:41:04AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511104104.A7032@djebel.gnupg.de> Message-ID: <20000511104743.A10797@tehran.nmrc.ucc.ie> Werner Koch writes: > On Wed, 10 May 2000, Lars Hecking wrote: > > > alternative to egd and found Andreas Maier's random device for Solaris > > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > > openssl/openssh. I can generate keys, make connections, no problem. > > IIRC, gpg checks that it is a character device - maybe the Solaris > /dev/random is implemented as another type of device. $ cd /devices/pseudo $ ll r* crw-r--r-- 1 root sys 65, 0 May 10 01:21 random@0:random crw-r--r-- 1 root sys 65, 1 May 10 01:21 random@0:urandom $ From dichro-gnupg-devel@rcpt.to Thu May 11 10:11:14 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 11 May 2000 20:11:14 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 11:42:44 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> I'd would very much appreciate help for GnuPG from volunteers WK> who can sign an copyright assignment for the FSF. Without WK> that legal paper I have to review all the pacthes and look at WK> the idea only :-( This won't be a problem, but I'll save it for if and when I come up with something worthwhile to contribute. WK> BTW, Brian Warner did some experiments with a PalmPilot and WK> sent me the outline for a protocol to be used between the WK> decryption/signing engine on some device and gpg. However, I WK> have not yet found the time to work on it and franky I can't WK> find it right now in my mail archives :-( Hmm, okay. Failing that, my intent was to gin up a simple text based protocol to run over Unix sockets, with operations like DECRYPT ( list of valid keys ) cyphertext I presume here that gpg will know what keys can decrypt a message (by fingerprint? id? full public key? How are they identified in the message?), but won't know which ones are available. ENCRYPT key plaintext Which does the obvious thing. Would this cover the gamut of what gpg does with private keys? I am also presuming that the keystore would acquire the keys by means outside this protocol. m. From wk@gnupg.org Thu May 11 10:50:53 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 12:50:53 +0200 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:11:14PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: <20000511125053.O7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm, okay. Failing that, my intent was to gin up a simple text based > protocol to run over Unix sockets, with operations like Okay. > DECRYPT ( list of valid keys ) cyphertext > > I presume here that gpg will know what keys can decrypt a message > (by fingerprint? id? full public key? How are they identified in the > message?), but won't know which ones are available. The needed key is identified by the 64 bit KeyID. There is an option for a wildcard KeyID in which case gpg tries each available secret key in turn. > ENCRYPT key plaintext > > Which does the obvious thing. Would this cover the gamut of what gpg > does with private keys? I am also presuming that the keystore would You don't need the secret key for encryption - I guess you are thinking of signing a message. Such an agent should take care of all operations where the secret key is involved and leve all other crypto operations to normal program. The goal of such a agent should be to better protect the secret key. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From bofh@eris.phys.uni.torun.pl Thu May 11 11:55:37 2000 From: bofh@eris.phys.uni.torun.pl (Janusz A. Urbanowicz) Date: Thu, 11 May 2000 13:55:37 +0200 (CEST) Subject: external keystore option? In-Reply-To: <20000511114244.M7032@djebel.gnupg.de> from Werner Koch at "May 11, 2000 11:42:44 am" Message-ID: Werner Koch wrote/napisa³[a]: > On Thu, 11 May 2000, Lord of the Lists wrote: > > My reason for asking is not purely academic; I recently published > > keymgr, an application designed to serve this purpose, whose only real > > claims to fame at present are a pretense to modularity and enough > > functionality to allow one to keep one's ssh keys on a Java ring. > > BTW, Brian Warner did some experiments with a PalmPilot and sent me > the outline for a protocol to be used between the decryption/signing > engine on some device and gpg. However, I have not yet found the time > to work on it and franky I can't find it right now in my mail archives :-( I'd be very interested in it (as a fresh owner of brand-new Palm Vx) and also in paricipating. I've already thought of implementing something along the lines of using Palm as crypto token/engine working over IRDA/serial link. alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From dichro-gnupg-devel@rcpt.to Thu May 11 10:59:57 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 11 May 2000 20:59:57 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 12:50:53 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> The needed key is identified by the 64 bit KeyID. There is an WK> option for a wildcard KeyID in which case gpg tries each WK> available secret key in turn. Hmm. How can one tell if one has found the right key? Magic in the plaintext? WK> You don't need the secret key for encryption - I guess you are WK> thinking of signing a message. Yep, or things like signing keys. I presume that in both cases (and any others?), gpg builds some kind of value which needs to be encrypted with the secret key and returned (?). I guess the question boils down to - are there any operations that gpg performs with a secret key that can't be transformed into an encryption/decryption with some independent munging of data formats on either side of it? m. From wk@gnupg.org Thu May 11 12:08:10 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 14:08:10 +0200 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:59:57PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: <20000511140810.R7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm. How can one tell if one has found the right key? Magic in the > plaintext? Quite simple: Without the correct key you get only garbled plaintext - this is easy to detect because the plaintext (actually the encrypted session key) has some special format and a checksum. > Yep, or things like signing keys. I presume that in both cases (and All signing operations. > secret key that can't be transformed into an encryption/decryption A secret key is only needed for this: a) decryption b) signing Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From apommer@cosy.sbg.ac.at Thu May 11 13:04:11 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Thu, 11 May 2000 15:04:11 +0200 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511150411.H32456@cosy.sbg.ac.at> On May 10, Lars Hecking wrote: [..] > After openssh failed when I upgraded to Solaris 8, I was looking for an > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. [...] > poll(0xFFBED588, 1, 3000) Err#6 ENXIO > write(2, " s e l e c t ( ) e r r".., 16) = 16 > write(2, " N o s u c h d e v i".., 25) = 25 > write(2, "\n", 1) = 1 > [repeats over and over] > > Any suggestions? Is it possible that the current code is too Linux/BSD > specific? the problem occurs in rndlinux.c gather_random() at the select() in line 128: if( !(rc=select(fd+1, &rfds, NULL, NULL, &tv)) ) { this select() translates into poll(), which can be seen in the truss-dump above. However, in the source of Andis random device one can read: * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE [..] * -) /dev/random and /dev/urandom are the same (no blocking). * -) No ioctls, no poll. * * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE That seems to be the answer. One possible solution would be to skip the select() if the fact is known that the device does not block. Another one would be to improve the random device (remember, still V0.1), to provide a dummy-poll which succeeds every time. HTH Andreas From wk@gnupg.org Thu May 11 14:19:02 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 16:19:02 +0200 Subject: Solaris random device In-Reply-To: <20000511150411.H32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 03:04:11PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> Message-ID: <20000511161902.Y7032@djebel.gnupg.de> On Thu, 11 May 2000, Andreas Pommer wrote: > That seems to be the answer. One possible solution would be to skip the > select() if the fact is known that the device does not block. We can't do that because we should be somewhat sure about how much entropy we got. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Thu May 11 14:05:40 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 15:05:40 +0100 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511150540.A12177@tehran.nmrc.ucc.ie> Werner Koch writes: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. As the author has invited comments and suggestions, I have forwarded Andreas P's reply. From lhecking@nmrc.ucc.ie Thu May 11 15:18:07 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 16:18:07 +0100 Subject: Solaris random device In-Reply-To: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de>; from Nils@infosun.fmi.uni-passau.de on Thu, May 11, 2000 at 09:53:28AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> Message-ID: <20000511161807.A12368@tehran.nmrc.ucc.ie> > I don't know about Andi Maier's device, but egd has been updated to work > with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by > ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't > annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several > weeks by now. Unfortunately, I am totally unable to ftp to ftp.lothar.com. Anon login is ok, but anything beyond that times out. From apommer@cosy.sbg.ac.at Thu May 11 17:01:00 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Thu, 11 May 2000 19:01:00 +0200 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511190100.N32456@cosy.sbg.ac.at> On May 11, Werner Koch wrote: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. So we used to other option and now there is an improved version of the sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ It now cooperates with gpg - at least the 'make check' does not fail or hang. Andreas From lhecking@nmrc.ucc.ie Fri May 12 22:14:04 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Fri, 12 May 2000 23:14:04 +0100 Subject: Solaris random device In-Reply-To: <20000511190100.N32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 07:01:00PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> Message-ID: <20000512231404.A10088@tehran.nmrc.ucc.ie> > So we used to other option and now there is an improved version of the > sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ > It now cooperates with gpg - at least the 'make check' does not fail or hang. Yep. Works fine now on both Solaris 7 and 8. But still, I'd like to hear some good arguments for using this device at all. I am basically unclued about crypto, but I understand that a "good" random source is instrumental. From a user perspective, is the Solaris device appropriate? Is there a danger of creating weakly encrypted files with it? Thanks a lot for being so helpful, guys, I really appreciate it! (Ok with me if you want to move this discussion over to -users) From dichro-gnupg-devel@rcpt.to Sat May 13 07:03:29 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 13 May 2000 17:03:29 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 14:08:10 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: How does the following sound? Trying to trace operation flows through the code is a little confusing, so I'm probably way off base :( There appear to be two basic parts to this - firstly, gnupg needs to find out what keys are available, and secondly, it needs to use them. Using them appears to be the province of cipher/pubkey.c. Let's assume that gnupg has found out what keys the agent has, and is now trying to perform some kind of operation with them. My first thought was to somehow overload pubkey_table so that it would have two entries for each algorithm - one as is, and one which references functions which communicate with the agent for operations. This would require minor changes to all the functions that walk pubkey_table to not bomb if the first algorithm match fails, and also hook into the dynamic module loading code to add the duplicate agent entry for each loaded module, which could be messy. Alternatively, we can assume that when gnupg is fed the agent's keys, it will receive something bogus for the secret key. When it tries to do something useful with it, it will bomb with a recognizable error (G10ERR_BAD_MPI spring to mind). We could change all the wrapper functions to note this error and repeat the request to the agent to see if it will do any better. I couldn't find any way of changing the functions called on a key by key basis, only algorithm by algorithm. Did I miss anything? g10/ringedit.c appears to be a good place to start teaching gnupg about the agent. One could define a new keyring type (rt_AGENT), and hook it appropriately in the following functions. I'm basically looking to see where rt_GDBM is special cased, and trying to work out what the corresponding operations would be for an agent. o add_keyblock_resource - simple enough, establish a connection to the agent, cache the socket fd. o search - seemingly simple, but there's some questions in my mind. The rt_GDBM case generates a fingerprint from the public key in the packet passed as an argument to the function, and uses that as a key. But... there's some functions, like find_keyblock_bysk, that (judging from the name) might not have a public key as part of the request. Why is it safe for rt_GDBM to assume that it will be there? A comment later in the code suggests that the search interface is used preparatory to doing modifications to the keystore - is it /only/ used for this? ie, assuming that gnupg isn't going to have control over the agent, can implementing the search operation be skipped? The second part of this question is where does the public key initially come from, if not search? Which ties in to... o enum_keyblocks - am I correct in guessing that this is the interface used for populating gnupg's idea of what keys are available for it to use? I'm getting a little bit lost in all the various packet types, but here's the idea floating uppermost in my mind: If enum_keyblocks is indeed what is called as the first contact with a keystore, can I get away with simply populating the KBNODE(?) with a full public key and a bogus secret key (assuming the second option for using the key that I mentioned above)? This would mean that for all uses of this key that don't directly use the secret key, enum_keyblocks would already have all of the required data to handle them. Sorry if this is as confused as I am :) m. From apommer@cosy.sbg.ac.at Sat May 13 08:59:24 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Sat, 13 May 2000 10:59:24 +0200 Subject: Solaris random device In-Reply-To: <20000512231404.A10088@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Fri, May 12, 2000 at 11:14:04PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> Message-ID: <20000513105924.S32456@cosy.sbg.ac.at> On May 12, Lars Hecking wrote: [..] > But still, I'd like to hear some good arguments for using this device > at all. I am basically unclued about crypto, but I understand that a > "good" random source is instrumental. From a user perspective, is the > Solaris device appropriate? Is there a danger of creating weakly encrypted > files with it? Currently it is more similar to the linux /dev/urandom , less to /dev/random. At every call to the device some entropy is added (from a high resolution timer, and sometimes process id) and subsequently mangled by some hash algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. The solaris kstat interface provides access to a large number of kernel counters which can be used for that purpose. However, the "good" ones have to be determined. > Thanks a lot for being so helpful, guys, I really appreciate it! > (Ok with me if you want to move this discussion over to -users) I didn't subscribe to users, maybe I should ... Andreas From Enzo Michelangeli" <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> Message-ID: <00f101bfbcd5$f327f000$16006598@asiainter.net> ----- Original Message ----- From: "Andreas Pommer" To: Sent: Saturday, May 13, 2000 16:59 Subject: Re: Solaris random device [...] > Currently it is more similar to the linux /dev/urandom , less to /dev/random. > At every call to the device some entropy is added (from a high resolution > timer, and sometimes process id) and subsequently mangled by some hash > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > The solaris kstat interface provides access to a large number of kernel > counters which can be used for that purpose. However, the "good" ones > have to be determined. Why? Just toss everything into the pool: the total entropy cannot be reduced by adding low-entropy data. The more, the merrier. Cheers -- Enzo From dichro-gnupg-devel@rcpt.to Tue May 16 09:31:06 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 16 May 2000 19:31:06 +1000 Subject: external keystore option? In-Reply-To: "Mikolaj J. Habryn"'s message of "13 May 2000 17:03:29 +1000" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: --=-=-= >>>>> "MJH" == Mikolaj J Habryn writes: MJH> A comment later in the code suggests that the search MJH> interface is used preparatory to doing modifications to the MJH> keystore - is it /only/ used for this? To answer my own question, this does indeed appear to be the case. I've attached a patch which implements some basic agent support for gnupg. Using this and a modified keymgr, I've managed to sign/verify, and encrypt/decrypt a file using the ssh key I keep on my Java iButton. This is how I get my kicks. Observations. The exercise was a little bit gruesome. The keys that originate with the agent are marked with an is_protected of 23, and check_secret_key adjusted to not try to checksum them. In addition, the pubkey_decrypt and pubkey_sign methods look to see if the secret MPI fields are NULL, and redirect the query to the agent if so. This is suboptimal, but by the time we hit those queries, we've lost all the other information about the key. Just FYI. m. --=-=-= Content-Disposition: attachment; filename=gnupg-diff Content-Description: agent diff for gnupg diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/cipher/pubkey.c gnupg-work/cipher/pubkey.c --- gnupg-1.0.1-orig/cipher/pubkey.c Fri Jul 23 22:02:52 1999 +++ gnupg-work/cipher/pubkey.c Tue May 16 18:51:47 2000 @@ -492,6 +492,9 @@ log_mpidump(" data:", data[i] ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, result, *data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { @@ -526,6 +529,9 @@ log_mpidump(" data:", data ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, resarr, data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/Makefile.am gnupg-work/g10/Makefile.am --- gnupg-1.0.1-orig/g10/Makefile.am Sun Oct 10 03:23:41 1999 +++ gnupg-work/g10/Makefile.am Tue May 16 15:58:39 2000 @@ -57,6 +57,7 @@ keylist.c \ sig-check.c \ signal.c \ + agent.c \ helptext.c gpg_SOURCES = g10.c \ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.c gnupg-work/g10/agent.c --- gnupg-1.0.1-orig/g10/agent.c Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.c Tue May 16 19:00:55 2000 @@ -0,0 +1,214 @@ +#include +#include +#ifndef UNIX_PATH_MAX +#define UNIX_PATH_MAX 63 +#endif +#include +#include +#include +#include +#include + +#include "config.h" +#include "keydb.h" +#include "errors.h" +#include "packet.h" + +static int agent_socket; + +static unsigned char *hextable = NULL; + +int agent_connect(char *path) { + struct sockaddr_un sun; + + sun.sun_family = AF_LOCAL; + strncpy(sun.sun_path, path, UNIX_PATH_MAX - 1); + + agent_socket = socket(PF_LOCAL, SOCK_STREAM, 0); + if(agent_socket < 0) + return G10ERR_NETWORK; + if(connect(agent_socket, &sun, sizeof(sun))) + return G10ERR_OPEN_FILE; + return 0; +} + +int agent_read(void *buf, int len) { + return read(agent_socket, buf, len); +} + +int agent_write(void *buf, int len) { + return write(agent_socket, buf, len); +} + +int agent_enum(KBPOS *kbpos, KBNODE *ret_root) { + char buf[600], *ptr, *end; + int len = 0, i, algo; + PKT_public_key *p; + PKT_secret_key *s; + PKT_user_id *u; + PACKET *t; + + snprintf(buf, 599, "ENUMERATE %ld\r\n", kbpos->offset++); + if(agent_write(buf, strlen(buf)) != strlen(buf)) + return G10ERR_NETWORK; + do { + int ret; + + ret = agent_read(buf + len, 600 - len); + if(ret < 0) + return G10ERR_NETWORK; + len += ret; + if(len < 2) + continue; + if(buf[len - 1] == '\n' && + buf[len - 2] == '\r') + break; + } while(len < 600); + if(len == 2) + return -1; + ptr = memchr(buf, ' ', len); + if(!ptr) + return G10ERR_BAD_PUBKEY; + *ptr++ = 0; + len -= ptr - buf; + algo = string_to_pubkey_algo(buf); + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_BAD_PUBKEY; + *end++ = 0; + len -= end - ptr; + ptr = end; + p = m_alloc_clear(sizeof(*p)); + s = m_alloc_clear(sizeof(*s)); + p->pubkey_algo = algo; + s->pubkey_algo = algo; + for(i = 0; i < pubkey_get_npkey(algo); i++) { + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_NETWORK; /* leaking MPIs! */ + *end++ = 0; + len -= end - ptr; + p->pkey[i] = mpi_alloc(0); + mpi_fromstr(p->pkey[i], ptr); + s->skey[i] = mpi_copy(p->pkey[i]); + ptr = end; + } + s->is_protected = 23; + + end = memchr(ptr, '\r', len); + *end = 0; + u = m_alloc_clear(sizeof(*u) + strlen(ptr)); + u->len = strlen(ptr); + strcpy(u->name, ptr); + + t = m_alloc_clear(sizeof(*t)); + if(kbpos->secret) { + t->pkttype = PKT_SECRET_KEY; + t->pkt.secret_key = s; + } else { + t->pkttype = PKT_PUBLIC_KEY; + t->pkt.public_key = p; + } + *ret_root = new_kbnode(t); + + t = m_alloc_clear(sizeof(*t)); + t->pkttype = PKT_USER_ID; + t->pkt.user_id = u; + add_kbnode(*ret_root, new_kbnode(t)); + + return 0; +} + +unsigned char kmsl_nybble_char(unsigned char c) { + switch(c) { + case 0: + return '0'; + case 1: + return '1'; + case 2: + return '2'; + case 3: + return '3'; + case 4: + return '4'; + case 5: + return '5'; + case 6: + return '6'; + case 7: + return '7'; + case 8: + return '8'; + case 9: + return '9'; + case 0xa: + return 'a'; + case 0xb: + return 'b'; + case 0xc: + return 'c'; + case 0xd: + return 'd'; + case 0xe: + return 'e'; + case 0xf: + return 'f'; + default: + return 0xff; + } +} + +void kmsl_genhextable() { + int i; + + hextable = malloc(512); + for(i = 0; i < 256; i++) { + hextable[i * 2] = kmsl_nybble_char(i >> 4); + hextable[i * 2 + 1] = kmsl_nybble_char(i & 0xf); + } +} + +unsigned char *kmsl_byte_str(unsigned char c) { + if(!hextable) + kmsl_genhextable(); + return hextable + 2 * c; +} + +void agent_write_mpi(MPI m) { + int len, j, textlen; + unsigned char *text, *buf = mpi_get_buffer(m, &len, NULL); + + agent_write("0x", 2); + textlen = len * 2; + text = alloca(textlen); + for(j = 0; j < len; j++) + memcpy(text + j * 2, kmsl_byte_str(buf[j]), 2); + agent_write(text, textlen); + free(buf); +} + +int agent_process(int algo, MPI *ret, MPI data, MPI *skey) { + char *end, buf[2000], *alg = pubkey_algo_to_string(algo); + int i, r; + + agent_write("PROCESS ", 8); + agent_write(alg, strlen(alg)); + agent_write(" ", 1); + for(i = 0; i < pubkey_get_npkey(algo); i++) { + agent_write_mpi(skey[i]); + agent_write(" ", 1); + } + agent_write_mpi(data); + agent_write("\r\n", 2); + r = agent_read(buf, 2000); + end = memchr(buf, '\r', r - 1); + if(*(end + 1) != '\n') + return G10ERR_NETWORK; /* laziness */ + *end = 0; + r -= 2; + if(!r) + return G10ERR_UNEXPECTED; + *ret = mpi_alloc(0); + mpi_fromstr(*ret, buf); + return 0; +} diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.h gnupg-work/g10/agent.h --- gnupg-1.0.1-orig/g10/agent.h Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.h Tue May 16 17:35:37 2000 @@ -0,0 +1,11 @@ +#ifdef WITH_AGENT + +#include "keydb.h" + +int agent_connect(char *); +int agent_read(void *, int); +int agent_write(void *, int); +int agent_enum(KBPOS *, KBNODE *); +int agent_process(int, MPI *, MPI, MPI *); + +#endif /* WITH_AGENT */ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/keydb.h gnupg-work/g10/keydb.h --- gnupg-1.0.1-orig/g10/keydb.h Fri Nov 12 23:49:28 1999 +++ gnupg-work/g10/keydb.h Fri May 12 14:18:09 2000 @@ -58,7 +58,10 @@ enum resource_type { rt_UNKNOWN = 0, rt_RING = 1, - rt_GDBM = 2 + rt_GDBM = 2, +#ifdef WITH_AGENT + rt_AGENT = 3, +#endif }; diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/ringedit.c gnupg-work/g10/ringedit.c --- gnupg-1.0.1-orig/g10/ringedit.c Fri Dec 3 03:30:31 1999 +++ gnupg-work/g10/ringedit.c Tue May 16 16:04:41 2000 @@ -61,7 +61,7 @@ #include "options.h" #include "main.h" #include "i18n.h" - +#include "agent.h" @@ -102,7 +102,6 @@ static int do_gdbm_enum( KBPOS *kbpos, KBNODE *ret_root ); #endif - static RESTBL * check_pos( KBPOS *kbpos ) { @@ -215,6 +214,12 @@ rt = rt_GDBM; resname += 11; } +#ifdef WITH_AGENT + else if(strlen(resname) > 12 && !strncmp(resname, "gnupg-agent:", 12)) { + rt = rt_AGENT; + resname += 12; + } +#endif /* WITH_AGENT */ #ifndef HAVE_DRIVE_LETTERS else if( strchr( resname, ':' ) ) { log_error("%s: invalid URL\n", url ); @@ -343,6 +348,23 @@ break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + { + if(strlen(resname) == 4 && !strncmp(resname, "$ENV", 4)) { + if(!getenv("GNUPG_AGENT")) { + rc = G10ERR_GENERAL; /* how do I make this a silent error? */ + goto leave; + } + rc = agent_connect(getenv("GNUPG_AGENT")); + } else { + rc = agent_connect(filename); + } + if(rc) + goto leave; + } + break; +#endif /* WITH_AGENT */ default: log_error("%s: unsupported resource type\n", url ); rc = G10ERR_GENERAL; @@ -760,6 +782,11 @@ kbpos->offset = 0; break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + kbpos->offset = 0; + break; +#endif default: BUG(); } kbpos->pkt = NULL; @@ -779,6 +806,11 @@ rc = do_gdbm_enum( kbpos, ret_root ); break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + rc = agent_enum(kbpos, ret_root); + break; +#endif default: BUG(); } @@ -803,6 +835,9 @@ kbpos->fp = NULL; } break; +#ifdef WITH_AGENT + case rt_AGENT: +#endif case rt_GDBM: break; case rt_UNKNOWN: @@ -1826,3 +1861,4 @@ } #endif /*HAVE_LIBGDBM*/ + diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/seckey-cert.c gnupg-work/g10/seckey-cert.c --- gnupg-1.0.1-orig/g10/seckey-cert.c Mon Jul 12 22:57:49 1999 +++ gnupg-work/g10/seckey-cert.c Tue May 16 19:01:01 2000 @@ -43,6 +43,8 @@ int i, res; unsigned nbytes; + if(sk->is_protected == 23) + return 0; if( sk->is_protected ) { /* remove the protection */ DEK *dek = NULL; u32 keyid[4]; /* 4! because we need two of them */ --=-=-=-- From bofh@eris.phys.uni.torun.pl Thu May 18 14:12:14 2000 From: bofh@eris.phys.uni.torun.pl (Janusz A. Urbanowicz) Date: Thu, 18 May 2000 16:12:14 +0200 (CEST) Subject: GnuPG with Netscape Messenger? In-Reply-To: <20000518101453.C13517@djebel.gnupg.de> from Werner Koch at "May 18, 2000 10:14:53 am" Message-ID: Werner Koch wrote/napisa³[a]: > On Wed, 17 May 2000, Paul Gallagher wrote: > > > I'm wondering if anyone has found a way to use GnuPG when using Netscape > > Messenger. Any ideas? > > No way. > > I started to do a workaround based on a local proxy used as smarthost > and pop3 host for netscape (you can enter localhost:1234 to connect to > an smtp daemon running on port 1234). This tool should do all the > crypto stuff and has to popup a window to ask for passphrases and > to select the recipient's key. > You can always use premail for sending (on *ix systems). Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From ls@Gambit.Msk.SU Fri May 19 13:26:03 2000 From: ls@Gambit.Msk.SU (Sergei Laskavy) Date: Fri, 19 May 2000 17:26:03 +0400 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" Message-ID: <20000519172603.C9570@Peru.gambit.msk.su> I hope you will be happy to repeat this: (0) I use $ gpg --version gpg (GnuPG) 1.0.1 Copyright (C) 1999 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Cipher: IDEA, 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160 $ cat ~/.gnupg/options charset koi8-r escape-from-lines force-v3-sigs honor-http-proxy keyserver blackhole.pca.dfn.de lock-once no-greeting quiet load-extension idea load-extension rsa (1) Here is the test message: -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have just uploaded mutt-1.1.12 to ftp://ftp.mutt.org/pub/mutt/devel/. =20 This is a check-point release to summarize the few changes since 1.1.11. For 1.2, I'm mainly waiting for Brendan's pending changes to the IMAP code. Season's greetings, tlr --=20 http://www.guug.de/~roessler/ -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOQH0otImKUTOasbBAQEr3wf9GOPFRB12s7Hs+XOEwQaPhiJpFPkQ5vlh S/MYOZ4UzNMhYVpqlASAQeHk2lQFP/aQscFo0ltv7cTUmHmNgPBP/1MnkuFVMXo+ M4wb69qKJytxbDurpgHES2Y/WasPGKM6Vt2sjWNCA7UsBsorg86wCdl/fwe7pCz5 kc4emPbMBo2Kw9WI3GPP3lf3XNQKi82SfA6ilAKVOjHvhOb1odoGoCQBis8P8D11 r6FoaAQsi50vsMaUVFWET4udqNCtNfDLAZFjN0iGLL436Y9jHe95+Kjuf2+Q+MXZ 9TUyjPfboB+PzyIfPgdjl56UFFsiqUM104AWXhmdGj5XWO0pjZdVFQ== =OVlh -----END PGP SIGNATURE----- (2) Here is the public key (it's also on keyservers): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.1 (SunOS) mQENAzSgEssAAAEIAMgjiiDIe0zOqjJ2TcsWXW9DYTFzyHPSYJTBHjivb0Vekmra x+M/r6U+AWM1Bf92fGWx7cMn4oYkkaMnO8LQrBXKC8IcnwrJitvh1O0xCnIqWi1E b2JOUlxRJuVYrBNgm0OxlKBCxCmKs4yvZsJ3ykClkUJmSmBV9qDpRUJqxGzyzJ97 C36mbWV/LBKamhFcuDyAmPLZPYWwijaqixXDBuC5ouEPPUmFDgkN5F2533U/imej LSEVOMIthr1qH++wx1g50imHnmKjrtwSn4zA/f++9nl5YyOP1DwZKTu+91JEJPTH aDSnKzWRk/t7lx2JfblDjxYQlziz0iYpRM5qxsEABRG0IlRob21hcyBSb2Vzc2xl ciA8cm9lc3NsZXJAZ3V1Zy5kZT6JARUDBRI38b4/CdxwOTnzf10BAW1aB/9p2gpa ggQjcB/A3kpSEPAhc+U1jP4AVFx3BIdj/yceArIdi/j87CMN5tdHMkktC9ym5/qJ wCWn5YRnl7nF8hT1tLICmO+t/vbo4X0U7kykGVNhbHNMsMpHfBT9S88BkJno1s2D GTTN1gVloDwa4aSbqW1ltRCSSZFoSwigJUQCNYU/e7HOdYe+F+kybXZPvA9L5rg7 zW1vsp0vTLglFpmjLCgaEIIFgp297eW8wmXo/IKuWAO+kNccI6Y4JCJ8+kJfqSgw y7xpvBnuyFu/8/UHcw+wL+uUMRHzrlAibPqy3k3ZwUDOkJeLL9GJaMH+KbzlNzTS tIR1Q6188D/7Hj7piQCVAwUTNyHtwAui8ZR0SloRAQGiugQAqEAoo07fFF1RFgWP J1SVmlJDLy0O2H9hkB6KJAMtds3ga9Ku5exJZfgDz1W839yM0ntgprPHmLtlVp3f ZrLwlUjcr4IXmY45myX6I1xa+TiHEQh61U1fOPzYYR9o+3acyEZE/5uEd0ve66y7 iROHZtoPyvg8uudEHA1wd9l/TwaJARUDBRA4IDMZC+VzVzZkFFkBAUpfCACAJOPE da058VbTx721fDrNxCQu6Fk5LbbP3VTutWasWgit/s1Wnr32SptVRXqsjYp5BFwV Ug0JC8rGBfB1yAG9lXJaHrGoDuqdDKbdpZRFE8UtLnVktfW51p4ZcfuQb3DVKx3Z SVIhVrKaQUt50tWpAme+6jQTjotsO3lGtuFHyhXa/3nXQG3evmagSpAmb7Uu3b/m NSy1YLNf1h6jaJZvYKjchcgE0WE7jEJ2tBFoMd1GgSRij4WN7XLkOLPpGMma/a/A 6DNyD+/UTsZbb27pQNW32KNcA4EN8Zu1npzgNcNYd7NqScjcf0wiXkqZFNHr1XSO c8/IEsxp8v+wuhikiQCrAwUQNLu+OBKt/zYZlwkHAQEyugSwpalGr4euJUpkobI/ WvrnGAqXZRj++1/IEof7x+Jl2TnOjrMLZflgCwy0E2ZaBQpQxEcAwsNfFW/i+zGg 6+ctwN9J7SxEnN2TnUNBT2l5foRx7fIVNi3AXoOd6b8xmvad/FG83utrCxUpvWnW ZMY4C6rZKCgjXtRpd9pSwU8X3QAmI8p3dfWdLxAoZxgzJZVPlewwVRwpiQCVAwUT Nx0OJRRPLUVPVwujAQHHgQP+NF0YAIL3kl+q2sa9YCUXNgCQ+mTvZb3Zzu/q3u8+ ixTowui8bLBTFY3+yIx6IzEHATcoUPCthYwnvfX4BqWNWgDFN+eWaNrZpNEfZVkW Bs6Sd0/R4AcERUcoyp48pnH77E/XS4O4b9VlFYiQV9CX+er6VD5f0ERuNiTaD9pQ Ec+JARUDBRA3JupwLHrik2A/LQEBAf9IB/9Tx58nqBfmTok8VdUQj7bZPksOTlAK WG/f8RD5johFz/OxIey3+K1agiLA+Acr8agfQMAvfxNliJIFGcVgkyYlr/zr4aRh 6e+KEjPGuYgV607be1hPm7xmjNzJklXV0ouKgFqB6kNy+FOdG2OWXrzMQO/Dbwh6 /ofToNoOdsit9mQ5HxUuq2f0TmrjVwoBQqj/QxzA1mS/KgCdsPlEF6v9BsoXyxF3 0Wbj+h+nAU3EdOWgOTexmhcpmOvKx5bW766mB+zAdpj9c33xAMU9lt6bIIcD3cxJ fs7s9ZhWlczoarpUwU+BoKE0dMfvs6cf6NPcTrODqvCUAJwYCR42KZdZiQC1AwUT NKATSj4lAO9ZMjjhAQFvHgT+Ol0myw6jILx78keIEDdJy/fxdK6T56XUYX8nNez3 Ibm300bT63yvEnD3U6pgN+sEyzuLxP/L07Jk2E3OHJHLXJpLHWQlebW3ey9EEaYV xjClSFrmidc0Jd5nMAFmssJ9AHuENKvO096yHTMvH3MYIjYJ1HfyDUnIVDwFL8KF 4fwQezrtMwWzt8WSjWEbGmXZXW7kZ1lBnL8f6eYvCigFYYkAlQMFEzSvti9Dr0FE 3QjdbQEBPdYD/3zZLNh9rPPQ4pZ/0HfQr88BBrjIdKIXuEaZbkfiohuKf44RqOdt k832Mmb2yrp6i8IN8UHPPTpM7xfvmab2Rk21SxRZJ0IsbXzYVSP1oxdE3lIOyVlB vtn1FXEU9JuGD8N9dM994Yirg/2EfjpPJ7SdRMIdtrFAzagJvAvmdk7iiQCVAwUQ NO2N7knh/jPvZzKNAQFdlgQAlGd9mSgxjv6Id8FZ3lMhU0RzKvHNFRof985lkyJt R/01qAJZbCxeJB2y5diLw6qZaVw6+hCqgP5Bbw8PPtKr7i/OvAXBPgoU5Ume4J2A EsavEmavAJ90Zph0WK2BzqCQd1EP5M2jqdBATDunL67rJ5bk0l7y/KwgM5NhyCmY FNmJAJUDBRA0xeJJTFllIALEMQkBAdTfA/42FNAByvEHM9pRkK4qftVDSnIIZeRP uIfV+mO4FcNE9h/oH3nBSOUGn7NqsjwJuj4daZ2tmWfH41D8oQjPVqdM4fd0csYk FZLI0qu1wTd8MxEJsHoh5qIU8M6ywL5pIflhOP1wGf6omqBh2VZuhYY6m0775Lih A0c/DLokymQ6C4kAlQMFEDccqjNMo00siEncPQEByDcD/3cUDPeFBlzq5SSKANRA emT0HoW+aoUO+bRavqOzwCuYNhkSNx7yukACFc8fu13vlBpHL39RLJC6zT+8rto1 MH3SLnJNJj7FH8NZUQDffwXXea3eydNCx0T9fVu0QBndPvyib6K3oVD/Z6yirbo+ pNZnn6U8aOrEXf18IizhhBdxiQCVAwUQNvYNv1H8PGQHafT1AQGBrgQAhWdZ9ws2 EIh8LJEAb53FHcjonandcJ7HDgLo3GpWnhIvhcc+YKQluW/8lS92bsjY3tVRfDYe Y80NjEODDgn+CEcOu9LqssGj4CwuU7b58tBdSIV1v7CSX9cTM9+0r0qGU7ql7Lpn zBqhx36UXqOK6vfU0cWrHLkPUNlms2a96LeJALADBRA3TTnyVmSU4zFmVdUBAZlh BNEBfEm35/lKlMV3hlFMT/K7ZhddrptYh+vCGhJNSO48KD+6foES7zgAH8k1j1Wh A2b4oVG7X4x5T603UqGDFpaycddqxGc7Bs7E0aAVygEkoJQ6c8AjSkyy/lRnGZ1G ln7vPNM8TokQJQRKfkm/tPpE1jneaU/j102We0jg2ULyJQOLB73acI/v5O4p1d1F +W5S3XySxxDcbOWJjYkAlQIFEDUZVnh4YVpjdyds6QEBU2sEAKjJkcCiOqnyh7I7 O1PIVbEWumltWd5CXDT2MwMXX5vOGex//qERDNDqR4w1ksPj3NVOkSaVFQMjw2Ys zBFFHma45LZPSxv2UGxjII8qPPgPmkllLyhHCGrDRY+IZ0Wax+HFfJe3g6xYYgCl ojNVd1chV9eduNZLxdvhV4YKVSHMiQEVAwUQN1PmOH4v6i2JDAmBAQEP3Qf5AYd0 ytzQB36MJHx+jHismpNsJEGj/rQ8PxeWnic9GkcgBi97wflQaldonFlvoeNFyIwS MTLs2vZTeCRLMxc1LFnwurx8/2oks9xp63733Rqs9DonnkDQR04YWLkw4djTaEDc /GWHCyYiPj11G/12b09ywf4nPd32K8AVoIQAPQy5P4GRhesQTvWTl1yXLEVWjv6g PLJUo3l1BrIKm+GMdnlBqTGpswPtkxeUqp8mjYdwnmm5ajX/qkxe1UE/t5V74169 uTL1+DjEl3CT+rVR6UtEc2qM3Zg2PTzgjmrFfHeUdXv1QBfRJlhmtPQtRX4csDFP fX0sO5n5PZpYcYlzC4kBFQMFEDTFOAt+8FjoQyMUJQEBjpIH/3Uwc8cMr8RAie00 9a7536V2x2miBAoTAjsb5ui91geM4ssXgilUgB/sBW/bV6cZA67Q7YYSollFSKPb LhmoZUEvkf+cS6cdojUbq2p2pd7Djq3ZSYNTRbIKo8KWBLSfSuDsxdu0oVdW3DO2 5TMzkauxNnqMegWjLSRCMRigdQYYmZKrA9tY6hD63c6eLt2DAWuF+pepwo5N6jm7 yGHWAW0ihhqv+NHlIc3JExxxzDYeTjC4Yb5dfHpYG7ETbsMZCQ77Ru1isbcA557/ kgSwKPUt0LAMgVj9atG4OIezjwPubEV/SxvcRnjEKsQOQe7WriLcPjeELlMvakBc nDS7NtqJARUDBRA29l83fvTWwzbkE20BAc0HB/sGlryh+m+UJR5TjI7cMf13UnFh vL88TIRLGxVwsOYoKixiU1hPecGFWcXsnYue6Hduvb9EiBdn3GQcKQAda0TtCXoJ 6gmph8xx7cGqSGd1ldh1nkWbGsCt82HcK7XQ0qF/zUTuRwxi7F30YI5ZBYBLOVsn dB7rMm4ObkHH0nskMMMfZ1VcsT5ndvKL2RvevRaleXob14erDDsEmqKzPMRpyTKO CAMnK5k86P8uK+8hg39rLSQodPKzxvtyJNEDt3iizQ+Ac1nlPIeO/pN7CnqJwu5T codS9bVe9A39gIqhbCp8zYjKD+uU+8tOGYthuU2FvgDaB0NU+pzSaw2X2se6iQCV AwUTNK/OIokABLrCbuiRAQGsdAQAxOh0ipz4H80XifbWjh+W721oIwXGjBl/n/e/ UJh7cqzqZxo+I/vR3O0wCfnkeQ94ihe24eamvEvwvWbpRmnfqozp2Fuo9JcazgML j0eDmqZCe0XJEi4t3WdIavy59XskuzPaM8AepRKULStKup22o5jgvOnK6/2KcYmx oKULfeCJARUDBRA1EBSciVPDw6koVP0BAQkvB/wN1M5oadLBjOIgm34y1qtxnkvF ZuPIJIWVVX+3Fz2FwZ84OIqVtNGxjKAOkyFG371+wEXc7xZZ9owSCO2edVTCC2wL 2mDFostS7G4aTDWvXMx0lWTTc8V2RZTOQ8bGJDo+6HgFNg4gV/03MpPqB413yVas XseES/yCt+haLnk85mO8KVSGP7DAdwJn5tLx3GKHZE3Qh9XTJ0j4V/9uG8ohf94T O63s0V/3ZAMUK8GaP4kiC5d4ZEN+4DyHw6xjYTmrRp3tvXKJrUHaSnCXaS7Obr2C DO5LyRi07qMrkHAxjmDMdJYHyS9SEPqphx+/1TyYZQx1edrlLiY31YSFEpH+iQCi AwUSN/G+HpFeTizbCJMJAQFzUgRmN7+0sKxmW7m5MBaB2dHnOpoya6Kxzbp3oghW 8cX4+DOI4zukBDWvEnnreCnbl4dFoTr38+GoG336NozKhKvx5kvSqBzL6XpzXrT6 OTg/b2NGiFpSR0QKNJtNSUUwGwSVDa1Yqqn0FMmFGAeI08p+VeMXLpwjDWXsvRYr 9S+fVY+jDNeFRv7yOUFOZTstiQCVAwUQN29YLpznb919i1kZAQEDSQP/bbq6SB16 jS7IjIcUHHvhHZ3aXmFkx55kcKPnBZrzPOAN9R6jFDS1wu0ejxVPNp6iGzODq2tz UPv5HJfWufxMaxHpnHQ6J5+EwpLQwWj2PrSQg6idNA4W/0eFLi0SOlFj8JAXt69j fkl/K4R/kiNPVL2FVWQMCOLtYVxTbkf6XxqJARUDBRA28ZJ5nnPrCk1Y7lEBATqQ B/sGsKnPF45GKF7Yu/3dNwQD38g5Qpj8+7ddPcjME7tmkD8BHFR6o6bDtv7zWeEF uxg+XjAxg4dPSHrAXdKZ5SDHqJO7+GbZP/eP7zoGw4V1GVnCz0e0v2WXUfe56oFu oO/4XRrbsWhAtYPGeYi9BO/XRDIjDmjvFvjitjwIgxzUb/t6DqPMHchRpK1MOTWs bvUOb8Dz2U8YusH/G5puw2AemLyeXx6erZJm385bcAzgoP+tp4fA6SjSlQs9FD7J Y4goyBv534fluGGHth+nuIB2jn+zHOkcUgAgOJPSGmZSsSxXKQxfL1Xr1SdNbT16 i2VOIu7MWkceillxJUMIHE7ziQCVAwUQNMZ9G7Btxkr72ChhAQFIuwQAigFlRtsE jhtOXv9+Ot2gqKbqfj2TkOTCpr4HRlFGDzkIkbBZsp8q2Af5ZiQ7/h/g1asqbvzK J6XTWQo6K0U9iiasWYpXlUlrlVhMjm3hUrGLaMglGcnURemVHhhfS3S/4aggJqW6 Dt5U10txXrAdKfegU0+HEJ5L6WuKaulDxViJARUDBRM02HCwvqaOf4UxMn8BAfIb B/4omzocwa8eHPZgsuwq9pkU69qtJmndgxAxzSivSfd8UV3rVKquxIfPWTJuBuug EleQlskVASKiQVKubgSpP7VcyHimzgPt9w/RKLDpDAGAzZh6r9PX3BxdKxaig2Ny eiCmLYv7oZG6nOFa1xaPYmjxVDOwT39kZE36O2Boe5rW2Jj+GG/Iwxt4iGToXyZW Gz7uXP/Ar3O+kjQzgg14ieFkyOQYuI1Br/9ZCMIFwjHXfQsXRYP+ftTLi9DYfTXh G0bP+bc1FdiRLjM4IHYJ9ydl2p/1TL01ZO6eb9DB+a9esjXfb//frYCRFNPKoV/A b4TgVWYqAJlLczLEwfBkbkZgiQDVAwUSN/G+Xb+Ot2lXSNSVAQFEaAX9FQjXrDRc /FqkeiBNievdgVt03Lrm2XYkKnnvh059M7i+S/tVW7ly3sifvM1J4X2hvT9jbhb0 lD0gISXz85n7pHMpf4cxJpTnMefRBKFoDA2AYLUHL8Rq+VOKkdPM8pCgySU69Ssu ZPrK7kOByWiU8VeekL1+7236QrstzE+P8ePygXb6hrQZXzgClVq9DfVu3r5BRagU za/CDfuECEoRrdCPNOTOcC2PbdJjtLQIAm8m+llYXkd0Ij3zhB1HAISwiD8DBRA0 3w93xiLu3cOF4DcRAoYMAJ9AxHy1WoKMNp5BtD7bJVPiWmXXjwCfcaeh4TirEQLm aMT+TdecW0Nv1E2JARUDBRA0oBMs0iYpRM5qxsEBAUT8CACbuZBD0zuWHTuqTvEY MIuO/VJL0f+op9IwpMjD2W8EzXa5XEq4WoCdff9YzSZUT/T6Sy2ZcercLgthJRcr gQowZAQvn3UDnbF7OpPv3cblapmb2lvIDhJESco/I1R08kZN905bFmkcF1sNXsjf 6B+K2N2BSizbE2aS8xIJ+tuRDGeS1Gsai1e+impbGbVQiO4lUQlAOZeJPQ7IOtED yEHUjWw1FsOq/x9GNZMMxIqN/BagsqpA7eHJ76fsMQN1f0kh3oepaN3lZ7xqoSGE MIpf/eCzawGwlrEA3aROCjr33+hHzimIj8rtuxKUAo0jvNs8Wg3V3mXW/QgWhW1y hfLAiQCVAgUQNK/96fE8+WC3TbWNAQF40QP9Fq0LhANCSh1cQFqxIbCtzgyEm0ZL Ujx0fFE9onyE0/Jnuh+3fvRGde0UxzEfrTqf3Z+1hxYDtnuxcRUTlVSFRJfvO3g9 b+fcw08BG8hLpexQ1Jl27rEQEnxu3kyxtw+WkxDw/JMzf0bPG7rz4Rp2UbwOvFCY 1mLh+fsl4QvdnGCJAJUDBRA0sj2j9e+XfZ71UOEBAT9VBACeGQsN4aabBhcJlQIV XO9MlDY5ioWgRgAS/WCLgXf5FNvT5hVKv/WNHoe4VLQjJQE17MocrU8MpYxkoXBk JgNLfMl+hp7wACHXvn9m5MTJFJuRx3uuuyNi5Tyjhtovpn6MUn3nSxLID/F2XMMo Vfhu0Pz0V+DHMa2kVl1U/Xa+wQ== =jubg -----END PGP PUBLIC KEY BLOCK----- (3) Start gnupg by $ gpg < /path/to/saved/pgp-message gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK ^C gpg: some signal caught ... exiting -- Thank you! From wk@gnupg.org Fri May 19 14:38:46 2000 From: wk@gnupg.org (Werner Koch) Date: Fri, 19 May 2000 16:38:46 +0200 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su>; from ls@Gambit.Msk.SU on Fri, May 19, 2000 at 05:26:03PM +0400 References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: <20000519163846.M14819@djebel.gnupg.de> Hi, iirc, this has been fixed in 1.0.1f - can someone please test against this version. tia, Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From offby1@blarg.net Fri May 19 21:12:55 2000 From: offby1@blarg.net (Eric Hanchrow) Date: 19 May 2000 14:12:55 -0700 Subject: How to deal with old RSA keys In-Reply-To: Dr Lyman Hazelton's message of "Fri, 19 May 2000 13:45:14" References: <3.0.3.32.20000519134514.0099abc0@mail> Message-ID: <8766saz1k8.fsf@potato.hanchrow.org> >>>>> "Lyman" == Lyman Hazelton writes: Lyman> But I have an old RSA key that's been kicking around for a Lyman> long time and I didn't have a die-date on it. I still want Lyman> to be able to get messages written to me with this key. Is Lyman> there a module that I can add to gnupg that will allow me Lyman> to do this? Not everyone is switching to gpg and I still Lyman> need to hear from them in private. This should really be a FAQ. If you're using Debian GNU/Linux, then all you need to do is install the packages `gpg-rsaref' and `gpg-idea'. Then add these lines to ~/.gnupg/options: load-extension rsa load-extension idea -- PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5 C8BD 6337 0041 C01C 5276 From sroberts@uniserve.com Fri May 19 00:03:57 2000 From: sroberts@uniserve.com (Sam Roberts) Date: Thu, 18 May 2000 20:03:57 -0400 Subject: Solaris random device In-Reply-To: <00f101bfbcd5$f327f000$16006598@asiainter.net>; from em@who.net on Sat, May 13, 2000 at 08:22:18PM +0800 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> <00f101bfbcd5$f327f000$16006598@asiainter.net> Message-ID: <20000518200357.B471@localhost> On Sat, May 13, 2000 at 08:22:18PM +0800, Enzo Michelangeli wrote: > ----- Original Message ----- > From: "Andreas Pommer" > To: > Sent: Saturday, May 13, 2000 16:59 > Subject: Re: Solaris random device > > [...] > > Currently it is more similar to the linux /dev/urandom , less to > /dev/random. > > At every call to the device some entropy is added (from a high resolution > > timer, and sometimes process id) and subsequently mangled by some hash > > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > > The solaris kstat interface provides access to a large number of kernel > > counters which can be used for that purpose. However, the "good" ones > > have to be determined. > > Why? Just toss everything into the pool: the total entropy cannot be reduced > by adding low-entropy data. The more, the merrier. Yes, but the implementation of /dev/random so that it blocks until sufficient entropy is available, requires an estimate of randomness of input. Some statistical checks are done to estimate this, but when data is put into the pool it is identified as adding to the estimate of bits of entropy in the pool, or not. GnuPG, for one, attempts to select() until as much entropy as it wants is available. This entropy estimation seems important, though fairly fuzzily defined. Sam -- Sam Roberts, sroberts at uniserve dot com, www.emyr.net/Sam From tyketto@wizard.com Sat May 20 08:42:38 2000 From: tyketto@wizard.com (A Guy Called Tyketto) Date: Sat, 20 May 2000 01:42:38 -0700 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519163846.M14819@djebel.gnupg.de>; from wk@gnupg.org on Fri, May 19, 2000 at 04:38:46PM +0200 References: <20000519172603.C9570@Peru.gambit.msk.su> <20000519163846.M14819@djebel.gnupg.de> Message-ID: <20000520014238.A30251@wizard.com> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 19, 2000 at 04:38:46PM +0200, Werner Koch wrote: > Hi, >=20 > iirc, this has been fixed in 1.0.1f - can someone please test against > this version. >=20 > tia, >=20 > Werner Has this been released/uploaded yet? I'm not seeing it, at=20 ftp.gnupg.org:/pub/gcrypt/devel. 1.0.1e is still the latest and greatest=20 there. If it's located at another place, please let me know. :) BL. --=20 Brad Littlejohn | Email: tyketto@wizard.com Unix Systems Administrator, | tyketto@ozemail.com.au Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5Jk/+yBkZmuMZ8L8RAnkaAJ9Ksu1gNeCOn2Fk1ePmWsRgoNQvOQCZAZmM xnVmuHNaxcePKFhNNH1DwaM= =t6Ko -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From hideki@allcity.net Sat May 20 23:31:18 2000 From: hideki@allcity.net (Hideki Saito) Date: Sat, 20 May 2000 16:31:18 -0700 Subject: Windows version of entropy.dll problem Message-ID: <200005202329.QAA19377@server-1.visp.net> I have one bug report (among with fix) in entropy.dll which is distributed in GNU Privacy Guard for Microsoft Windows which is in the download page. It is that in certain circumstances; most visible in Windows 2000, it crashs when it is executed to generate keys, it crashs. This problem is solved after I compiled entropy.dll from sourcecode using Microsoft Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll Thank you. -- Hideki Saito mailto:hideki@allcity.net From hideki@allcity.net Sat May 20 23:41:15 2000 From: hideki@allcity.net (Hideki Saito) Date: Sat, 20 May 2000 16:41:15 -0700 Subject: CC Request Message-ID: <200005202339.QAA20452@server-1.visp.net> Sorry for bother about this with separate mail, but please CC me if you have questions or comments about entropy.dll, since I'm not subscribed to the list. (is there anyway I can subscribe to it?) Thank you. -- Hideki Saito mailto:hideki@allcity.net From wk@gnupg.org Sun May 21 17:22:36 2000 From: wk@gnupg.org (Werner Koch) Date: Sun, 21 May 2000 19:22:36 +0200 Subject: Windows version of entropy.dll problem In-Reply-To: <200005202329.QAA19377@server-1.visp.net>; from hideki@allcity.net on Sat, May 20, 2000 at 04:31:18PM -0700 References: <200005202329.QAA19377@server-1.visp.net> Message-ID: <20000521192236.D3283@djebel.gnupg.de> On Sat, 20 May 2000, Hideki Saito wrote: > It is that in certain circumstances; most visible in Windows 2000, it > crashs when it is executed to generate keys, it crashs. This problem > is solved after I compiled entropy.dll from sourcecode using Microsoft > Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll I am in the process of reqriting it without the need for DLL. I hope to commit the changes on Thursday or Friday. However a lot of new testing will be required then. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From rguerra@yahoo.com Sun May 21 17:54:59 2000 From: rguerra@yahoo.com (Robert Guerra) Date: Sun, 21 May 2000 13:54:59 -0400 Subject: GNUPG & AES Candidates In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> References: <200005202329.QAA19377@server-1.visp.net> <20000521192236.D3283@djebel.gnupg.de> Message-ID: Werner: I'm forwarding you a message I recently posted on the pgp-user's mailing list (http://www.cryptorights.org/pgp-users) . I'm curious to know if you are considering adding any additional AES candidates to gnupg. regards robert Date: Sat, 20 May 2000 22:45:31 -0400 From: Robert Guerra Subject: Re: [PGP-USERS] PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org Tom: At 8:49 PM -0400 2000/5/20, Tom McCune wrote: >I found the following at: >http://www.pgp.com/asp_set/products/tns/pgp70_reqts.asp > >>Cryptographic Algorithms Supported >> >> Public key algorithms: Diffie-Hellman/DSS, RSA >> with up to 4096-bit key lengths nothing new here unless 4096 applies to RSA as well. >> >> Symmetric algorithms: CAST (128-bit), 3DES >> (168-bit), IDEA (128-bit), Twofish (256-bit) twofish is new...but it hasn't won the AES competition. Can the Rijndael cipher be added too? I believe that the other AES finalists should also be included. It would make good sense to at least keep the others in mind in case Twofish doesn't win. After all, it would be nice if PGP v.7 could have the AES winning candidate. For what it's worth.. At our Toronto May cypherpunks meeting, it was mentioned at that the Rijndael cipher was well looked upon, and a favorite of many at the april AES conference. As it's invented by a group in Belgium it will be interesting to see how it plays politically in the selections process. After all can the americans seriously consider to accept and deploy something made outside the USA (NIH - not invented here, not good) >> >Any other news that can be shared on related changes would be appreciated. Some references: Video Report of The May cypherpunks meeting in Toronto (Canada) http://www.epress.ca/privacy AES Round two AES Round two analysis AES Second Round Implementation Experience The block cipher Rijndael -- -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From Nils@infosun.fmi.uni-passau.de Thu May 25 14:02:03 2000 From: Nils@infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Thu, 25 May 2000 16:02:03 +0200 (MEST) Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: <14637.12891.65451.656522@skrjabin.fmi.uni-passau.de> Hi all, we've had quite some discussions on this list about the various random "gizmos" available on Solaris 2. I'd like to summarize the possibilities and then make a suggestion. The need for entropy is not a domain of GnuPG alone; OpenSSH needs it as well, and there may be others coming (BTW, I've heard rumours that the OpenSSH folks are considering to use gpg keys instead of their own user-level public keys. Does anyone know more details?). There are currently three options that I am aware of: ======================================================================= 1. Entropy Gathering Daemon (EGD) Available from http://www.lothar.com/tech/crypto/, latest release is 0.8. This is a perl script running as a daemon, providing an entropy source through a pipe. EGD is supported by both, GnuPG and OpenSSH by means of a configure option. The latest release even works on Solaris 8. It works very well, the only drawback being its speed: if you need a lot of entropy (generating keys, multi-user platform), egd might be a bottleneck. 2. /dev/random as provided by Sun package SUNWski This software was developed by Sun as part of the unbundled product Sun Webserver 2.0 on the Solaris Easy Access Server 3.0 CD. This product was supported for Solaris 2.6 and 7, but not 8 (because Sun is now using Apache or Netscape's web server). However, the SUNWski package still works fine on Solaris 8, provides entropy much faster than egd (it's a daemon written in C) and was reviewed to provide high quality entropy: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=95618127814224&w=2 SUNWski's /dev/random is natively supported by OpenSSH, but in order to use it with GnuPG, you have to apply the following patch. That's because SUNWski provides /dev/random as a pipe, and not as a character device. The patch is relative to the current CVS snapshot of GnuPG. As SUNWski provides only /dev/random, the patch assumes a link from /dev/urandom to /dev/random. diff rndlinux.c.orig rndlinux.c 86c86,92 < if( !S_ISCHR(sb.st_mode) ) --- > if( !strcmp(PRINTABLE_OS_NAME, "SunOS")) { > /* Solaris 2 Easy Access Server -- SUNWski */ > if( !S_ISFIFO(sb.st_mode) ) > g10_log_fatal("invalid random device!\n" ); > }else{ > /* Linux , xBSD*/ > if( !S_ISCHR(sb.st_mode) ) 87a94 > } diff configure.in configure.in.orig 447,458c447,448 < [case "${target}" in < *-solaris*) < if test -p "$NAME_OF_DEV_RANDOM" && test -p "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < *) < if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < esac]) --- > [if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then > ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; fi]) You would then use the random device type "linux". However, this patch breaks the use of the 3rd option. 3. /dev/random and /dev/urandom by Andreas Maier This is a new port of the Linux kernel random driver to Solaris 2 as a kernel module (what Sun should have done in the first place!) from http://www.cosy.sbg.ac.at/~andi/. It's very new, therefore hasn't been reviewed regarding it's entropy quality. As this is a clone from the Linux port, both are character devices. Therefore, the GnuPG sources don't have to be patched at all. You just select "linux" as the random gatherer. I've tested it on Solaris 8. I didn't recompile OpenSSH for this, but a quick look at the sources suggest that it should work there as well. Unlike GnuPG, OpenSSH only tests for existence and readability of /dev/random, but not whether it's a pipe or a character device. Being a kernel module, it should be pretty fast (didn't try). Personally, I would like to have the source reviewed by someone who knows about entropy gatherers before I'd use it in a production system. ======================================================================= Proposal I'd like to see GnuPG being a bit more flexible on this issue and therefore avoiding the need to patch it. I think that taking the OpenSSH approach (testing for existence and readability of /dev/random and /dev/urandom, being still happy if the latter doesn't exist, and don't test the type of the device; suggest the use of egd if the devices don't exist) should be OK for GnuPG as well. The naming of these random gatheres as being "linux" is a bit unfortunate, but that's just cosmetics :-) Any comments? Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From sam@cogent.ca Thu May 25 14:25:37 2000 From: sam@cogent.ca (Sam Roberts) Date: Thu, 25 May 2000 10:25:37 -0400 (edt) Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: Previously, you (Nils Ellmenreich) wrote: > Proposal > > I'd like to see GnuPG being a bit more flexible on this issue and > therefore avoiding the need to patch it. I think that taking the OpenSSH > approach (testing for existence and readability of /dev/random and > /dev/urandom, being still happy if the latter doesn't exist, and don't > test the type of the device; suggest the use of egd if the devices don't > exist) should be OK for GnuPG as well. The naming of these random > gatheres as being "linux" is a bit unfortunate, but that's just > cosmetics :-) > > Any comments? I'd like to second this proposal, particularly about not forcing /dev/random to be a character device. I ported Linux's random to QNX4 and Nto, and I took the approach of making them look like character devices so gpg would recognize them. I don't really think they are, any term control ops on them would fail, a named pipe or a QNX named device would have been more natural. The term linux will be increasingly a misnomer, I believe the *BSDs have a /dev/random as well, for instance. Sam -- Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca) "News is very popular among its readers." - RFC 977 (NNTP) From koch@hsp.de Thu May 25 15:37:26 2000 From: koch@hsp.de (Walter Koch) Date: Thu, 25 May 2000 17:37:26 +0200 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su> References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: Moin, am / On Fri, 19 May 2000 17:26:03 +0400, schrieb Sergei Laskavy wrote: >$ gpg < /path/to/saved/pgp-message >gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 >gpg: Good signature from "Thomas Roessler " >gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK tested it with gpg (GnuPG) 1.0.1f-snap2000-05-25 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: Warning: using insecure memory! gpg: Signature made Sat Apr 22 20:51:14 2000 CEST using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " The NOTE: is completly gone! Gruss, Walter -- Walter Koch Hochdahl am Neandertal http://www.hsp.de/~koch/ qrv:db0iz-9 walter@1409.org ham:dg9ep@db0me koch@hsp.de From bem@cmc.net Thu May 25 21:39:15 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 14:39:15 -0700 Subject: Clearsigning (again) Message-ID: <20000525143915.B24700@cmc.net> I know there is very little in the RFC regarding clearsigning and that PGP-MIME is better. But Network Solutions wants clearsigned (and so do many Usenet readers since multipart MIME is evil on Usenet), so I need it to work properly. >From the fine man page: -t, --textmode Use canonical text mode. If -t (but not --textmode) is used together with armoring and signing, this enables clearsigned messages. This kludge is needed for PGP compatibility; normally you would use --sign or --clearsign to selected the type of the signature. But this doesn't wholly work. [thorin:~] 2:10:46pm 193 % echo foo | gpg -t --armor --sign You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 foo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5LZbaN3/OJIgyK1ERAm/3AJ99ETFfFOvIS+necd4awNO5S255EACghazh p9oyByxGr6xctlsQTU7C4zk= =myQV -----END PGP SIGNATURE----- The problem is that with PGP, the same sort of thing will have an empty line after the 'foo'. PGP5 will verify the above, but it will be missing the end of line: [thorin:~] 2:12:53pm 200 % ls -l foo -rw------- 1 bem bem 3 May 25 14:12 foo [thorin:~] 2:12:56pm 201 % od -x foo 0000000 6f66 006f 0000003 The trailing newline placed there by 'echo foo' (which emits 4 characters) is gone. Again, I realize that RFC2440 isn't clear at all about 'clearsigned' messages but I believe interoperability is important. How does the above behave with PGP6? If it behaves as PGP5 does, then I think gnupg needs to change. The relevant wording in 2440 I see is: The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. That seems to imply "insert an extra newline here when signing and discard it when you verify". There is also a problem in lines ending with TAB (which, alas, I know because NSI seems to send forms with TABs at the end of the line for reasons known only to them): [thorin:~] 2:15:13pm 211 % echo "foo " > foo # that's a tab [thorin:~] 2:15:14pm 212 % gpg -t --armor --sign foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 2:15:25pm 213 % pgpv foo.asc Opening file "foo" type text. BAD signature made 2000-05-25 21:15 GMT by key: 1024 bits, Key ID 88322B51, Created 1998-10-17 "brian moore " "brian moore " "brian moore " This seems to be contrary to RFC2440: Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Spaces at the end of the line -are- ignored correctly. But tabs are not. If there's consensus that these two things need fixing, I'll submit a patch, but so far I've had no response to these even being problems. :( Again, both of these are needed to work with Network Solutions, which is why it's annoying me. If I manually ":%s/^I$//", and insert a blank line at the end of my forms, yes, I can then submit them to NSI and have them verify, but that seems goofy. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem@cmc.net Thu May 25 22:08:29 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 15:08:29 -0700 Subject: Clearsigning (again) In-Reply-To: <20000525143915.B24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 02:39:15PM -0700 References: <20000525143915.B24700@cmc.net> Message-ID: <20000525150829.C24700@cmc.net> On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > This seems to be contrary to RFC2440: > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > any line is ignored when the cleartext signature is calculated. > > Spaces at the end of the line -are- ignored correctly. But tabs are > not. Ah, oddly enough I can make it do this -- but I have to specify '--rfc1991' to do it. It still strips the \n at the end, and I'm not sure why the --rfc1991 is needed, since RFC2440 requires it as well... -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem@cmc.net Thu May 25 22:36:45 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 15:36:45 -0700 Subject: Clearsigning (again) In-Reply-To: <20000525150829.C24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:08:29PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> Message-ID: <20000525153645.D24700@cmc.net> On Thu, May 25, 2000 at 03:08:29PM -0700, brian moore wrote: > On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > > > This seems to be contrary to RFC2440: > > > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > > any line is ignored when the cleartext signature is calculated. > > > > Spaces at the end of the line -are- ignored correctly. But tabs are > > not. > > Ah, oddly enough I can make it do this -- but I have to specify > '--rfc1991' to do it. > > It still strips the \n at the end, and I'm not sure why the --rfc1991 is > needed, since RFC2440 requires it as well... Continuing to follow up to myself... :) I see why. It's a bug of PGP5. If I manually strip the tab in the clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not recognizing that it should ignore trailing tabs on input. (And this isn't documented in the 'Implementation Notes' in 2440 with the other PGP5 bugs... Can someone on the IETF committee see that it makes it into future revisions? :)) But the dropping-the-trailing-newline doesn't require PGP5, so I'm still convinced this is solely a gnupg problem: [thorin:~] 3:34:15pm 288 % echo foo > foo [thorin:~] 3:34:20pm 289 % md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo [thorin:~] 3:34:27pm 290 % gpg -sat foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 3:34:44pm 291 % gpg foo.asc File `foo' exists. Overwrite (y/N)? y gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 gpg: Good signature from "brian moore " gpg: aka "brian moore " gpg: aka "brian moore " [thorin:~] 3:34:52pm 292 % md5sum foo 2145971cf82058b108229a3a2e3bff35 foo I still don't think gnupg should do that. :) -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From gqueri@mail.dotcom.fr Thu May 25 23:51:33 2000 From: gqueri@mail.dotcom.fr (Gael Queri) Date: Fri, 26 May 2000 01:51:33 +0200 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:36:23PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526015133.A308@baoule.ath.cx> Hello brian, sorry to interrupt your conversation with yourself :) On Thu, May 25, 2000 at 03:36:23PM -0700, brian moore wrote: > (...) > But the dropping-the-trailing-newline doesn't require PGP5, so I'm still > convinced this is solely a gnupg problem: > > [thorin:~] 3:34:15pm 288 % echo foo > foo > [thorin:~] 3:34:20pm 289 % md5sum foo > d3b07384d113edec49eaa6238ad5ff00 foo > [thorin:~] 3:34:27pm 290 % gpg -sat foo > > You need a passphrase to unlock the secret key for > user: "brian moore " > 1024-bit DSA key, ID 88322B51, created 1998-10-17 > > [thorin:~] 3:34:44pm 291 % gpg foo.asc > File `foo' exists. Overwrite (y/N)? y > gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 > gpg: Good signature from "brian moore " > gpg: aka "brian moore " > gpg: aka "brian moore " > [thorin:~] 3:34:52pm 292 % md5sum foo > 2145971cf82058b108229a3a2e3bff35 foo > > I still don't think gnupg should do that. :) It seems to be fixed in gnupg 1.0.1e, so you were at least not the only one to think that :-) gael@baoule:~$ echo foo > foo gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo gael@baoule:~$ gpg -sat foo gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! You need a passphrase to unlock the secret key for user: "Gael Queri " 1024-bit DSA key, ID 3E18F9CE, created 1997-09-01 gael@baoule:~$ gpg foo.asc gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! File `foo' exists. Overwrite (y/N)? y gpg: Signature made Fri May 26 01:38:48 2000 CEST using DSA key ID 3E18F9CE gpg: Good signature from "Gael Queri " gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo Regards, gael From sen_ml@eccosys.com Fri May 26 03:09:38 2000 From: sen_ml@eccosys.com (sen_ml@eccosys.com) Date: Fri, 26 May 2000 12:09:38 +0900 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net> References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526120938J.1001@eccosys.com> From: brian moore Subject: Re: Clearsigning (again) Date: Thu, 25 May 2000 15:36:45 -0700 Message-ID: <20000525153645.D24700@cmc.net> ... > Continuing to follow up to myself... :) > > I see why. It's a bug of PGP5. If I manually strip the tab in the > clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not > recognizing that it should ignore trailing tabs on input. (And this > isn't documented in the 'Implementation Notes' in 2440 with the other > PGP5 bugs... Can someone on the IETF committee see that it makes it into > future revisions? :)) information about the openpgp working group mailing list can be found at: http://www.imc.org/ietf-openpgp/ you could post the suggestion there. From rabbi@quickie.net Sat May 27 00:33:46 2000 From: rabbi@quickie.net (L. Sassaman) Date: Fri, 26 May 2000 17:33:46 -0700 (PDT) Subject: Subkeys In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get an "Unusable public key algorithm" error when I try to encrypt to keys that have additional encryption subkeys. Can we work through this so that GnuPG handles v4 keys with multiple subkeys in the same manner that PGP does? - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LxfxPYrxsgmsCmoRAvQ+AJ9GeC6rsYWb7HxeXnEVsCRYx9eVxgCgwqXl r3pOieMkJByCafQgUfydTiQ= =Hxpe -----END PGP SIGNATURE----- From bem@cmc.net Tue May 2 22:17:12 2000 From: bem@cmc.net (brian moore) Date: Tue, 2 May 2000 15:17:12 -0700 Subject: general compatibility with PGP... Message-ID: <20000502151712.K31948@cmc.net> This seems to fail: -------- This is a test file for GPG/PGP/OpenPGP compatibility. This line ends with a tab for no good reason: Thanks for the test. This file ends with a blank line. -------- The above file, once signed (with gpg --sign -a -t testfile, which is what the docs imply is the 'pgp compatibility hack'), will not verify with PGP5, and PGP5 will also strip the last blank line. Who is right on the reading of 'text mode' on this? Or should there be a '--broken-text-mode' flag to appease PGP5? It's sort of annoying since Network Solutions likes sending forms with lines ending in tabs and spaces (I dunno -why-, they just do!) and I have to be sure I do a ':%s/[ ^I]\+$//' before signing stuff and ensure I have an extra blank line at the end. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From nittka@esem.com Thu May 4 07:37:03 2000 From: nittka@esem.com (Oliver Nittka) Date: 04 May 2000 09:37:03 +0200 Subject: [mailing-lists.reiserfs] (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Message-ID: --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit this may become very important for all open-source-projects, so i'll forward it to this list. -- oly -- Oliver Nittka | nittka@esem.com ESEM Grünau GmbH & Co. KG | http://www.esem.com Dornierstraße 6 | phone: +49 7544 9583-25 88677 Markdorf / Germany | fax: +49 7544 9583-60 --=-=-= Content-Type: message/rfc822; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit From: Xuan Baldauf Subject: (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Date: Thu, 04 May 2000 00:23:53 +0200 Message-ID: <3910A6F9.705A11A7@exmail.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------AC179D27851ED6C2526ACC47" To: reiserfs@devlinux.com Mailing-List: contact reiserfs-help@devlinux.com; run by ezmlm This is a multi-part message in MIME format. --------------AC179D27851ED6C2526ACC47 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I'm sorry for spamming the majority of not german list readers, but for those who are, this might be very important: The European Union plans to accept software patents. SWPats will slow down open source development, because large software companies can afford patenting algorithms which are easy and obvious, along with others which are complicated and advanced. If ever a clever (kernel) hacker finds an algorithm for a specific problem, there will be a good chance that this algorithm is a patent infringement. For their economic interest, large software companies will sue (kernel) hackers, and because large software companies have much more money, (kernel) hackers will give up, and open-source development will handicapped, probably at large scale, because nobody wants to be sued only to be a good (kernel) hacker. The most prominent example is "the GIF patent", the gd library ( http://www.boutell.com/gd/ ) was forced to give up GIF support. If you are against this scarious development, which is already possible in the USA, but not in Europe, and if you are german, read the following. Thanks for reading although being offtopic. Xuân. --------------AC179D27851ED6C2526ACC47 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Disposition: inline Return-Path: Received: from localhost (root@localhost [127.0.0.1]) by router.abc (8.8.8/8.8.8) with ESMTP id XAA22039 for ; Wed, 3 May 2000 23:48:57 +0200 Delivered-To: exmail-de-kW@exmail.de Received: from pop1.exmail.de by localhost with POP3 (fetchmail-5.1.0) for root@localhost (single-drop); Wed, 03 May 2000 23:48:58 +0200 (CEST) Received: (qmail 8455 invoked by uid 409); 3 May 2000 21:48:27 -0000 Delivered-To: medium-net-kW@medium.net Received: (qmail 8452 invoked from network); 3 May 2000 21:48:26 -0000 Received: from robin.camelot.de (HELO mail.camelot.de) (root@195.30.224.3) by plato.exmail.de with SMTP; 3 May 2000 21:48:26 -0000 Received: from robin.camelot.de (daemon@robin.camelot.de [195.30.224.3]) by mail.camelot.de (8.9.3/8.9.3) with ESMTP id XAA39885; Wed, 3 May 2000 23:47:55 +0200 (CEST) Received: from localhost (daemon@localhost) by robin.camelot.de (8.9.3/8.9.3) with SMTP id XAA39877; Wed, 3 May 2000 23:47:55 +0200 (CEST) Received: by robin.camelot.de (CameloT blkmail v1.12); Wed, 3 May 2000 23:47:53 +0200 Received: from robin.camelot.de (majordom@robin.camelot.de [195.30.224.3]) by mail.camelot.de (8.9.3/8.9.3) with ESMTP id XAA39834 for ; Wed, 3 May 2000 23:47:52 +0200 (CEST) Received: (from majordom@localhost) by robin.camelot.de (8.9.3/8.9.3) id XAA39829 for a2e-de-ffii.outgoing; Wed, 3 May 2000 23:47:52 +0200 (CEST) Date: Wed, 3 May 2000 21:44:56 +0000 (/etc/localtime) From: PILCH Hartmut X-Sender: phm@wtao97.oas.a2e.de To: FFII-Nachrichten Subject: BMWi-Konferenz: So koennen Sie helfen Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.camelot.de id XAA39826 Sender: owner-a2e-de-ffii@camelot.de X-Mozilla-Status2: 00000000 Bitte weiterverbreiten! lynx -dump http://swpat.ffii.org/penmi/bmwi-20000518/ ---------------------------------------- Die wirtschaftlichen Auswirkungen der Software-Patentierung Das Bundeswirtschaftsministerium hält am 18. Mai 2000 in Berlin eine öffentliche Tagung ab, auf der die wirtschaftlichen Auswirkungen der Patentierbarkeit von Logikalien untersucht werden sollen. Der Förderverein für eine Freie Informationelle Infrastruktur und die [6]Förderer seiner [7]Softwarepatent-Arbeitsgruppe sind eingeladen. Wir werden uns an in dieser [8]Konferenz aktiv beteiligen. Der FFII wird gegen die Ausdehnung des Europäischen Patentwesens in immer industriefernere Sphären argumentieren. Diese Konferenz ist eine seltene Chance. Sie muss ein Erfolg für all diejenigen werden, die von informatischem Monopolismus nichts gutes zu erwarten haben. Sie können auf verschiedenerlei Weise dazu beitragen. Was Sie tun können * An der Konferenz teilnehmen Die Konferenz ist öffentlich, aber die Teilnehmer sollten sich vorher anmelden und beim Veranstalter eine kurzes Positionspapier abgeben. Setzen Sie sich dazu mit uns in Verbindung. Wir haben in Berlin auch ein paar Hotelbetten reserviert. * Weitere Teilnehmer werben Dies ist eine erste und vielleicht letzte Gelegenheit für Programmierer und Firmen, sich über schicksalsentscheidende Entwicklungen kundig zu machen und darauf einzuwirken. Bitte sprechen Sie Firmen und Personen in Ihrem Einflussbereich an. Bringen Sie sie u.U. in Kontakt mit uns, damit wir bei der Abfassung von Positionspapieren helfen und bei der Vorbereitung der Konferenz zusammenarbeiten können. * Dokumention zusammenstellen helfen Der FFII stellt eine [15]Dokumentation (gedruckt und auf CD) zusammen. Wir müssen viele Verlagshäuser um Kopiererlaubnis bitten und manche wichtigen Texte sind von nicht-digitalen Datenträgern her zu erfassen. Diese Arbeit wird von der Intevation GmbH im Auftrag des FFII über ein [16]öffentlich zugängliches Forum geleistet. Ihre Teilnahme ist sehr willkommen. Der FFII ist dank seiner Förderer in der glücklichen Lage, für geleistete Arbeit Entschädigungen auf Stundenbasis zahlen zu können. Hintergrund der Konferenz Die Europäischen Patentorganisationen und die EU-Kommission beseitigen derzeit alle gesetzlichen Hürden, die bisher noch der Patentierung von Logikalien (Software) im Wege stehen. Es ist das erste Mal, dass eine Regierungsorganisation in Europa die Frage nach den Auswirkungen dieser Veränderungen auf die Wirtschaft und das Gemeinwohl stellt. Die Bundesregierung ist Vertragsstaat des Europäischen Patentabkommens und muss als solche alle Änderungen dieses Abkommens genehmigen. Verweigert sie ihre Zustimmung, so werden "Programme für Datenverarbeitungsanlagen" weiterhin auf der Liste der Ausnahmen von der Patentierbarkeit in §52 EPÜ bleiben. Andernfalls wird der Weg für die volle Durchsetzung von Logikalienpatenten in Europa und Deutschland noch dieses Jahr frei. Der FFII befürchtet, dass Logikalienpatentierbarkeit zu proprietären Standards (d.h. Blockierung von Kompatibilität durch private Besitzansprüche) führt, Monopoltendenzen stärkt, die Erneuerungskräfte hemmt und insbesondere kleine und mittlere Softwarefirmen gefährdet. In wenigen Monaten könnte eine lange angestaute Lawine von Drohbriefen und Patentprozessen über uns hereinbrechen, und Sie werden vielleicht sich daran gewöhnen müssen, einen Patentanwalt aufzusuchen, bevor Sie ihre Programm-Quelltexte im Netz veröffentlichen. Es wird dann sicherlich zu spät sein, irgendetwas dagegen zu tun. Handeln wir also jetzt. Machen wir die Berliner Konferenz zu einem großen Erfolg. Unterzeichner Markus Fleck Joerg Freudenberger Hartmut Pilch Bernhard Reiter Arnim Rupp _________________________________________________________________ http://swpat.ffii.org/penmi/bmwi-20000518/indexde.html 2000-05-03 PILCH Hartmut Verweise 6. http://swpat.ffii.org/sarji/ 7. http://swpat.ffii.org/ag/ 8. http://www.sicherheit-im-internet.de/news/news.php3?id=125 15. http://swpat.ffii.org/links/doku/ 16. http://ffii.org/mailman/listinfo/swpatdoku/ --------------AC179D27851ED6C2526ACC47-- --=-=-=-- From Klaus Singvogel Tue May 9 15:35:46 2000 From: Klaus Singvogel (Klaus Singvogel) Date: Tue, 9 May 2000 17:35:46 +0200 Subject: Patch: FAQ Message-ID: <20000509173546.A15460@Caldera.DE> Even the patch for the FAQ describes it now correct, I can't decrypt such a GnuPG generated message with PGP V2.6.3ii I'll investigate it and tell you more AFAIK more. Regards, Klaus. --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 @@ -123,7 +123,7 @@ supported by GnuPG because it is patented, but if you have a modified version of PGP you can try this: - gpg --rfc1991 --cipher-algo 3des ... + gpg --rfc1991 --cipher-algo idea ... Please don't pipe the data to encrypt to gpg but give it as a filename; other wise, pgp 2 will not be able to handle it. From wk@gnupg.org Tue May 9 17:29:22 2000 From: wk@gnupg.org (Werner Koch) Date: Tue, 9 May 2000 19:29:22 +0200 Subject: Patch: FAQ In-Reply-To: <20000509173546.A15460@Caldera.DE>; from ks@caldera.de on Tue, May 09, 2000 at 05:35:46PM +0200 References: <20000509173546.A15460@Caldera.DE> Message-ID: <20000509192922.C4283@djebel.gnupg.de> On Tue, 9 May 2000, Klaus Singvogel wrote: > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > @@ -123,7 +123,7 @@ > supported by GnuPG because it is patented, but if you have a modified > version of PGP you can try this: > > - gpg --rfc1991 --cipher-algo 3des ... > + gpg --rfc1991 --cipher-algo idea ... Watch out for the "...modified version of PGP .." - I assume that this is will be a 3DES one ;-). The GNU project does not support patented algorithms and therefore you won't read IDEA in it :-). Yes, I know that there are some countries where there is no valid patent on IDEA. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From Klaus Singvogel Wed May 10 09:57:09 2000 From: Klaus Singvogel (Klaus Singvogel) Date: Wed, 10 May 2000 11:57:09 +0200 Subject: Patch: FAQ In-Reply-To: <20000509192922.C4283@djebel.gnupg.de>; from wk@gnupg.org on Tue, May 09, 2000 at 07:29:22PM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> Message-ID: <20000510115709.A30043@Caldera.DE> On Tue, May 09, 2000 at 07:29:22PM +0200, Werner Koch wrote: > On Tue, 9 May 2000, Klaus Singvogel wrote: > > > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > > @@ -123,7 +123,7 @@ > > supported by GnuPG because it is patented, but if you have a modified > > version of PGP you can try this: > > > > - gpg --rfc1991 --cipher-algo 3des ... > > + gpg --rfc1991 --cipher-algo idea ... > > Watch out for the "...modified version of PGP .." - I assume that this > is will be a 3DES one ;-). The GNU project does not support patented > algorithms and therefore you won't read IDEA in it :-). Yes, I know > that there are some countries where there is no valid patent on IDEA. Sorry, but the FAQ speaks at this point of encryption for pgp 2.x Yes, you have to have a modified version GnuPG, but you have to use the (patented) idea algorithmen as cipher algorithmen too (and not 3des). Thats what I correct in the FAQ. I know, you can use 3des to make GnuPG encrypted messages readable for pgp 5.x or 6.x users. But that's not the point the FAQ speaks here of. Another point: I build a modified version of GnuPG: I built the idea/rsa modules, added the "load-extension idea" "load-extension rsa" lines to my .gnupg/options, and check with "strace" if the modules where used/opened (they were :-) But still I can't encrypt a message with GnuPG 1.0.1 (rsa 1.10 and idea 1.11) for a pgp-2.6.3ii user (myself). I get the error message Error: Decrypted plaintext is corrupted. If I look into the source-code I see that the error comes from the idea decryption. I currently investigate this. My current assumption is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does decryption in CBC mode. But I'm not sure, since I don't understand the idea.c completly yet. I'll tell you more, if I find the error. Regards, Klaus. -- .-. | Klaus Singvogel oo| | Caldera (Deutschland) GmbH, Naegelsbachstr. 49c, 91052 Erlangen /`'\ | email: ks@caldera.de internet: http://www.caldera.de (\_;/) | phone: ++49 9131 7192-300 fax: ++49 9131 7192-399 From az096@freenet.toronto.on.ca Wed May 10 12:13:13 2000 From: az096@freenet.toronto.on.ca (Robert Guerra) Date: Wed, 10 May 2000 08:13:13 -0400 Subject: Fwd:ANNOUNCEMENT: PGP Desktop Security 7.0 Message-ID: I'm sending this along in case people on here may have not seen it before. on first reading it looks like pgp (from NAI) is slowly morphing into a larger and larger beast. I hope that the folks from NAI follow the openpgp specs as they should so the new client can be as compatible as possible with gnupg. time will tell.. regards robert --- begin forwarded text Date: Tue, 09 May 2000 10:43:33 -0700 From: Will Price Subject: [PGP-USERS] ANNOUNCEMENT: PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today, we officially announced PGP Desktop Security 7.0. Here is the press release: http://biz.yahoo.com/prnews/000509/nv_neta_pg_1.html The beta program (which is already almost completely filled, so please don't ask) will begin this month and you should see the final version in early Q3. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 165 Alpha) iQA/AwUBORhOH6y7FkvPc+xMEQKvDwCguLKbVGyrUeevvP9hNGtem9ZKaGAAn2+B O8b6AFDrrbVt8A53oxED6IEy =OBdf -----END PGP SIGNATURE----- ..................................................................... Unsubscribe: Automated Help/Info: List Homepage: List Admin (human): Please do not send administrative commands to the list address! Thanks. --- end forwarded text -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From wk@gnupg.org Wed May 10 14:24:13 2000 From: wk@gnupg.org (Werner Koch) Date: Wed, 10 May 2000 16:24:13 +0200 Subject: Patch: FAQ In-Reply-To: <20000510115709.A30043@Caldera.DE>; from ks@caldera.de on Wed, May 10, 2000 at 11:57:09AM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> <20000510115709.A30043@Caldera.DE> Message-ID: <20000510162413.L7032@djebel.gnupg.de> On Wed, 10 May 2000, Klaus Singvogel wrote: > use the (patented) idea algorithmen as cipher algorithmen too (and > not 3des). Thats what I correct in the FAQ. If you look at the PGP 2 data formats (e.g. rfc1991) you will notice that there is indeed an algorithm indetifier and therefore it is possible to replace IDEA by 3DES (or better CAST5 which uses the same keysize and can be done very easily). Please read the GPL before _distributing_ GnuPG together with a module which implements a patented algorithm; doing so might vilolate the GPL. > If I look into the source-code I see that the error comes from the > idea decryption. I currently investigate this. My current assumption > is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does > decryption in CBC mode. But I'm not sure, since I don't understand Nope. The cipher modules are the low level encryption. The chaining is done in cipher/cipher.c and the same for all symmetric ciphers. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Wed May 10 20:08:08 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 10 May 2000 21:08:08 +0100 Subject: Solaris random device Message-ID: <20000510210808.A9104@tehran.nmrc.ucc.ie> Hi all, I just subscribed here, because the problem I'm facing now is probably not appropriate for -users ... After openssh failed when I upgraded to Solaris 8, I was looking for an alternative to egd and found Andreas Maier's random device for Solaris (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with openssl/openssh. I can generate keys, make connections, no problem. I'm now trying to use the random device with gpg, but it doesn't work. $ ./configure --prefix=$HOME --disable-nls --enable-static-rnd=linux (don't now if --enable-static-rnd=linux necessary - it doesn't make a difference if I leave this out) ... checking for random device... yes checking for linux/random.h... no checking for random device ioctl... no ... $ make check ... gpg (GnuPG) 1.0.1e Copyright (C) 2000 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: . Supported algorithms: Cipher: 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160, TIGER PASS: version.test PASS: mds.test PASS: decrypt.test PASS: decrypt-dsa.test and there it seems to hang. I'm attaching truss to the running copy of gpg and get ... poll(0xFFBED588, 1, 3000) Err#6 ENXIO write(2, " s e l e c t ( ) e r r".., 16) = 16 write(2, " N o s u c h d e v i".., 25) = 25 write(2, "\n", 1) = 1 [repeats over and over] Any suggestions? Is it possible that the current code is too Linux/BSD specific? Thanks. From Nils@infosun.fmi.uni-passau.de Thu May 11 07:53:28 2000 From: Nils@infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Thu, 11 May 2000 09:53:28 +0200 (MEST) Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie> References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> >>>"LH" == Lars Hecking writes: LH> After openssh failed when I upgraded to Solaris 8, I was looking for an LH> alternative to egd and found Andreas Maier's random device for Solaris LH> (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with LH> openssl/openssh. I can generate keys, make connections, no problem. I don't know about Andi Maier's device, but egd has been updated to work with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several weeks by now. Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From wk@gnupg.org Thu May 11 08:41:04 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 10:41:04 +0200 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511104104.A7032@djebel.gnupg.de> On Wed, 10 May 2000, Lars Hecking wrote: > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. IIRC, gpg checks that it is a character device - maybe the Solaris /dev/random is implemented as another type of device. (Patches are welcome) Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From listmaster@gnupg.org Thu May 11 09:19:14 2000 From: listmaster@gnupg.org (Lord of the Lists) Date: Thu, 11 May 2000 11:19:14 +0200 Subject: external keystore option? Message-ID: <20000511111914.I7032@djebel.gnupg.de> ----- Forwarded message from "Mikolaj J. Habryn" ----- Date: Thu, 11 May 2000 10:58:59 +0200 From: "Mikolaj J. Habryn" To: gnupg-devel@gnupg.org Subject: external keystore option? X-Diagnostic: Mail coming from a daemon, ignored Are there any plans for or opinions on the possibility of separating out the sensitive key management operations in gnupg (along the lines of ssh-agent for ssh)? I had a dig through the archives (a while ago), and recall seeing the subject come up once, but with no definitive resolution. I would like to see such functionality in gnupg; there are certain situations (such as Debian package creation) where a flexible policy engine would save a fair bit of passphrase retyping. My reason for asking is not purely academic; I recently published keymgr, an application designed to serve this purpose, whose only real claims to fame at present are a pretense to modularity and enough functionality to allow one to keep one's ssh keys on a Java ring. I've cobbled together enough code fragments to probably allow it to fake the desired effect by using a wrapper for gpg along with --passphrase-fd option (and obviously tracking passphrases in keymgr), but it's something of a suboptimal solution. m. ----- End forwarded message ----- -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From wk@gnupg.org Thu May 11 09:42:44 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 11:42:44 +0200 Subject: external keystore option? In-Reply-To: <20000511111914.I7032@djebel.gnupg.de>; from listmaster@gnupg.org on Thu, May 11, 2000 at 11:19:14AM +0200 References: <20000511111914.I7032@djebel.gnupg.de> Message-ID: <20000511114244.M7032@djebel.gnupg.de> On Thu, 11 May 2000, Lord of the Lists wrote: > ----- Forwarded message from "Mikolaj J. Habryn" ----- > Are there any plans for or opinions on the possibility of separating > out the sensitive key management operations in gnupg (along the lines > of ssh-agent for ssh)? I had a dig through the archives (a while ago), > and recall seeing the subject come up once, but with no definitive > resolution. This is scheduled for 1.1 but due to all the remaining work on 1.0 it will take some more time to start with it. I'd would very much appreciate help for GnuPG from volunteers who can sign an copyright assignment for the FSF. Without that legal paper I have to review all the pacthes and look at the idea only :-( > My reason for asking is not purely academic; I recently published > keymgr, an application designed to serve this purpose, whose only real > claims to fame at present are a pretense to modularity and enough > functionality to allow one to keep one's ssh keys on a Java ring. BTW, Brian Warner did some experiments with a PalmPilot and sent me the outline for a protocol to be used between the decryption/signing engine on some device and gpg. However, I have not yet found the time to work on it and franky I can't find it right now in my mail archives :-( Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Thu May 11 09:47:43 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 10:47:43 +0100 Subject: Solaris random device In-Reply-To: <20000511104104.A7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 10:41:04AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511104104.A7032@djebel.gnupg.de> Message-ID: <20000511104743.A10797@tehran.nmrc.ucc.ie> Werner Koch writes: > On Wed, 10 May 2000, Lars Hecking wrote: > > > alternative to egd and found Andreas Maier's random device for Solaris > > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > > openssl/openssh. I can generate keys, make connections, no problem. > > IIRC, gpg checks that it is a character device - maybe the Solaris > /dev/random is implemented as another type of device. $ cd /devices/pseudo $ ll r* crw-r--r-- 1 root sys 65, 0 May 10 01:21 random@0:random crw-r--r-- 1 root sys 65, 1 May 10 01:21 random@0:urandom $ From dichro-gnupg-devel@rcpt.to Thu May 11 10:11:14 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 11 May 2000 20:11:14 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 11:42:44 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> I'd would very much appreciate help for GnuPG from volunteers WK> who can sign an copyright assignment for the FSF. Without WK> that legal paper I have to review all the pacthes and look at WK> the idea only :-( This won't be a problem, but I'll save it for if and when I come up with something worthwhile to contribute. WK> BTW, Brian Warner did some experiments with a PalmPilot and WK> sent me the outline for a protocol to be used between the WK> decryption/signing engine on some device and gpg. However, I WK> have not yet found the time to work on it and franky I can't WK> find it right now in my mail archives :-( Hmm, okay. Failing that, my intent was to gin up a simple text based protocol to run over Unix sockets, with operations like DECRYPT ( list of valid keys ) cyphertext I presume here that gpg will know what keys can decrypt a message (by fingerprint? id? full public key? How are they identified in the message?), but won't know which ones are available. ENCRYPT key plaintext Which does the obvious thing. Would this cover the gamut of what gpg does with private keys? I am also presuming that the keystore would acquire the keys by means outside this protocol. m. From wk@gnupg.org Thu May 11 10:50:53 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 12:50:53 +0200 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:11:14PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: <20000511125053.O7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm, okay. Failing that, my intent was to gin up a simple text based > protocol to run over Unix sockets, with operations like Okay. > DECRYPT ( list of valid keys ) cyphertext > > I presume here that gpg will know what keys can decrypt a message > (by fingerprint? id? full public key? How are they identified in the > message?), but won't know which ones are available. The needed key is identified by the 64 bit KeyID. There is an option for a wildcard KeyID in which case gpg tries each available secret key in turn. > ENCRYPT key plaintext > > Which does the obvious thing. Would this cover the gamut of what gpg > does with private keys? I am also presuming that the keystore would You don't need the secret key for encryption - I guess you are thinking of signing a message. Such an agent should take care of all operations where the secret key is involved and leve all other crypto operations to normal program. The goal of such a agent should be to better protect the secret key. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From bofh@eris.phys.uni.torun.pl Thu May 11 11:55:37 2000 From: bofh@eris.phys.uni.torun.pl (Janusz A. Urbanowicz) Date: Thu, 11 May 2000 13:55:37 +0200 (CEST) Subject: external keystore option? In-Reply-To: <20000511114244.M7032@djebel.gnupg.de> from Werner Koch at "May 11, 2000 11:42:44 am" Message-ID: Werner Koch wrote/napisa³[a]: > On Thu, 11 May 2000, Lord of the Lists wrote: > > My reason for asking is not purely academic; I recently published > > keymgr, an application designed to serve this purpose, whose only real > > claims to fame at present are a pretense to modularity and enough > > functionality to allow one to keep one's ssh keys on a Java ring. > > BTW, Brian Warner did some experiments with a PalmPilot and sent me > the outline for a protocol to be used between the decryption/signing > engine on some device and gpg. However, I have not yet found the time > to work on it and franky I can't find it right now in my mail archives :-( I'd be very interested in it (as a fresh owner of brand-new Palm Vx) and also in paricipating. I've already thought of implementing something along the lines of using Palm as crypto token/engine working over IRDA/serial link. alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From dichro-gnupg-devel@rcpt.to Thu May 11 10:59:57 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 11 May 2000 20:59:57 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 12:50:53 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> The needed key is identified by the 64 bit KeyID. There is an WK> option for a wildcard KeyID in which case gpg tries each WK> available secret key in turn. Hmm. How can one tell if one has found the right key? Magic in the plaintext? WK> You don't need the secret key for encryption - I guess you are WK> thinking of signing a message. Yep, or things like signing keys. I presume that in both cases (and any others?), gpg builds some kind of value which needs to be encrypted with the secret key and returned (?). I guess the question boils down to - are there any operations that gpg performs with a secret key that can't be transformed into an encryption/decryption with some independent munging of data formats on either side of it? m. From wk@gnupg.org Thu May 11 12:08:10 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 14:08:10 +0200 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:59:57PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: <20000511140810.R7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm. How can one tell if one has found the right key? Magic in the > plaintext? Quite simple: Without the correct key you get only garbled plaintext - this is easy to detect because the plaintext (actually the encrypted session key) has some special format and a checksum. > Yep, or things like signing keys. I presume that in both cases (and All signing operations. > secret key that can't be transformed into an encryption/decryption A secret key is only needed for this: a) decryption b) signing Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From apommer@cosy.sbg.ac.at Thu May 11 13:04:11 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Thu, 11 May 2000 15:04:11 +0200 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511150411.H32456@cosy.sbg.ac.at> On May 10, Lars Hecking wrote: [..] > After openssh failed when I upgraded to Solaris 8, I was looking for an > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. [...] > poll(0xFFBED588, 1, 3000) Err#6 ENXIO > write(2, " s e l e c t ( ) e r r".., 16) = 16 > write(2, " N o s u c h d e v i".., 25) = 25 > write(2, "\n", 1) = 1 > [repeats over and over] > > Any suggestions? Is it possible that the current code is too Linux/BSD > specific? the problem occurs in rndlinux.c gather_random() at the select() in line 128: if( !(rc=select(fd+1, &rfds, NULL, NULL, &tv)) ) { this select() translates into poll(), which can be seen in the truss-dump above. However, in the source of Andis random device one can read: * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE [..] * -) /dev/random and /dev/urandom are the same (no blocking). * -) No ioctls, no poll. * * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE That seems to be the answer. One possible solution would be to skip the select() if the fact is known that the device does not block. Another one would be to improve the random device (remember, still V0.1), to provide a dummy-poll which succeeds every time. HTH Andreas From wk@gnupg.org Thu May 11 14:19:02 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 16:19:02 +0200 Subject: Solaris random device In-Reply-To: <20000511150411.H32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 03:04:11PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> Message-ID: <20000511161902.Y7032@djebel.gnupg.de> On Thu, 11 May 2000, Andreas Pommer wrote: > That seems to be the answer. One possible solution would be to skip the > select() if the fact is known that the device does not block. We can't do that because we should be somewhat sure about how much entropy we got. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Thu May 11 14:05:40 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 15:05:40 +0100 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511150540.A12177@tehran.nmrc.ucc.ie> Werner Koch writes: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. As the author has invited comments and suggestions, I have forwarded Andreas P's reply. From lhecking@nmrc.ucc.ie Thu May 11 15:18:07 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 16:18:07 +0100 Subject: Solaris random device In-Reply-To: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de>; from Nils@infosun.fmi.uni-passau.de on Thu, May 11, 2000 at 09:53:28AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> Message-ID: <20000511161807.A12368@tehran.nmrc.ucc.ie> > I don't know about Andi Maier's device, but egd has been updated to work > with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by > ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't > annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several > weeks by now. Unfortunately, I am totally unable to ftp to ftp.lothar.com. Anon login is ok, but anything beyond that times out. From apommer@cosy.sbg.ac.at Thu May 11 17:01:00 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Thu, 11 May 2000 19:01:00 +0200 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511190100.N32456@cosy.sbg.ac.at> On May 11, Werner Koch wrote: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. So we used to other option and now there is an improved version of the sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ It now cooperates with gpg - at least the 'make check' does not fail or hang. Andreas From lhecking@nmrc.ucc.ie Fri May 12 22:14:04 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Fri, 12 May 2000 23:14:04 +0100 Subject: Solaris random device In-Reply-To: <20000511190100.N32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 07:01:00PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> Message-ID: <20000512231404.A10088@tehran.nmrc.ucc.ie> > So we used to other option and now there is an improved version of the > sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ > It now cooperates with gpg - at least the 'make check' does not fail or hang. Yep. Works fine now on both Solaris 7 and 8. But still, I'd like to hear some good arguments for using this device at all. I am basically unclued about crypto, but I understand that a "good" random source is instrumental. From a user perspective, is the Solaris device appropriate? Is there a danger of creating weakly encrypted files with it? Thanks a lot for being so helpful, guys, I really appreciate it! (Ok with me if you want to move this discussion over to -users) From dichro-gnupg-devel@rcpt.to Sat May 13 07:03:29 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 13 May 2000 17:03:29 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 14:08:10 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: How does the following sound? Trying to trace operation flows through the code is a little confusing, so I'm probably way off base :( There appear to be two basic parts to this - firstly, gnupg needs to find out what keys are available, and secondly, it needs to use them. Using them appears to be the province of cipher/pubkey.c. Let's assume that gnupg has found out what keys the agent has, and is now trying to perform some kind of operation with them. My first thought was to somehow overload pubkey_table so that it would have two entries for each algorithm - one as is, and one which references functions which communicate with the agent for operations. This would require minor changes to all the functions that walk pubkey_table to not bomb if the first algorithm match fails, and also hook into the dynamic module loading code to add the duplicate agent entry for each loaded module, which could be messy. Alternatively, we can assume that when gnupg is fed the agent's keys, it will receive something bogus for the secret key. When it tries to do something useful with it, it will bomb with a recognizable error (G10ERR_BAD_MPI spring to mind). We could change all the wrapper functions to note this error and repeat the request to the agent to see if it will do any better. I couldn't find any way of changing the functions called on a key by key basis, only algorithm by algorithm. Did I miss anything? g10/ringedit.c appears to be a good place to start teaching gnupg about the agent. One could define a new keyring type (rt_AGENT), and hook it appropriately in the following functions. I'm basically looking to see where rt_GDBM is special cased, and trying to work out what the corresponding operations would be for an agent. o add_keyblock_resource - simple enough, establish a connection to the agent, cache the socket fd. o search - seemingly simple, but there's some questions in my mind. The rt_GDBM case generates a fingerprint from the public key in the packet passed as an argument to the function, and uses that as a key. But... there's some functions, like find_keyblock_bysk, that (judging from the name) might not have a public key as part of the request. Why is it safe for rt_GDBM to assume that it will be there? A comment later in the code suggests that the search interface is used preparatory to doing modifications to the keystore - is it /only/ used for this? ie, assuming that gnupg isn't going to have control over the agent, can implementing the search operation be skipped? The second part of this question is where does the public key initially come from, if not search? Which ties in to... o enum_keyblocks - am I correct in guessing that this is the interface used for populating gnupg's idea of what keys are available for it to use? I'm getting a little bit lost in all the various packet types, but here's the idea floating uppermost in my mind: If enum_keyblocks is indeed what is called as the first contact with a keystore, can I get away with simply populating the KBNODE(?) with a full public key and a bogus secret key (assuming the second option for using the key that I mentioned above)? This would mean that for all uses of this key that don't directly use the secret key, enum_keyblocks would already have all of the required data to handle them. Sorry if this is as confused as I am :) m. From apommer@cosy.sbg.ac.at Sat May 13 08:59:24 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Sat, 13 May 2000 10:59:24 +0200 Subject: Solaris random device In-Reply-To: <20000512231404.A10088@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Fri, May 12, 2000 at 11:14:04PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> Message-ID: <20000513105924.S32456@cosy.sbg.ac.at> On May 12, Lars Hecking wrote: [..] > But still, I'd like to hear some good arguments for using this device > at all. I am basically unclued about crypto, but I understand that a > "good" random source is instrumental. From a user perspective, is the > Solaris device appropriate? Is there a danger of creating weakly encrypted > files with it? Currently it is more similar to the linux /dev/urandom , less to /dev/random. At every call to the device some entropy is added (from a high resolution timer, and sometimes process id) and subsequently mangled by some hash algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. The solaris kstat interface provides access to a large number of kernel counters which can be used for that purpose. However, the "good" ones have to be determined. > Thanks a lot for being so helpful, guys, I really appreciate it! > (Ok with me if you want to move this discussion over to -users) I didn't subscribe to users, maybe I should ... Andreas From Enzo Michelangeli" <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> Message-ID: <00f101bfbcd5$f327f000$16006598@asiainter.net> ----- Original Message ----- From: "Andreas Pommer" To: Sent: Saturday, May 13, 2000 16:59 Subject: Re: Solaris random device [...] > Currently it is more similar to the linux /dev/urandom , less to /dev/random. > At every call to the device some entropy is added (from a high resolution > timer, and sometimes process id) and subsequently mangled by some hash > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > The solaris kstat interface provides access to a large number of kernel > counters which can be used for that purpose. However, the "good" ones > have to be determined. Why? Just toss everything into the pool: the total entropy cannot be reduced by adding low-entropy data. The more, the merrier. Cheers -- Enzo From dichro-gnupg-devel@rcpt.to Tue May 16 09:31:06 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 16 May 2000 19:31:06 +1000 Subject: external keystore option? In-Reply-To: "Mikolaj J. Habryn"'s message of "13 May 2000 17:03:29 +1000" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: --=-=-= >>>>> "MJH" == Mikolaj J Habryn writes: MJH> A comment later in the code suggests that the search MJH> interface is used preparatory to doing modifications to the MJH> keystore - is it /only/ used for this? To answer my own question, this does indeed appear to be the case. I've attached a patch which implements some basic agent support for gnupg. Using this and a modified keymgr, I've managed to sign/verify, and encrypt/decrypt a file using the ssh key I keep on my Java iButton. This is how I get my kicks. Observations. The exercise was a little bit gruesome. The keys that originate with the agent are marked with an is_protected of 23, and check_secret_key adjusted to not try to checksum them. In addition, the pubkey_decrypt and pubkey_sign methods look to see if the secret MPI fields are NULL, and redirect the query to the agent if so. This is suboptimal, but by the time we hit those queries, we've lost all the other information about the key. Just FYI. m. --=-=-= Content-Disposition: attachment; filename=gnupg-diff Content-Description: agent diff for gnupg diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/cipher/pubkey.c gnupg-work/cipher/pubkey.c --- gnupg-1.0.1-orig/cipher/pubkey.c Fri Jul 23 22:02:52 1999 +++ gnupg-work/cipher/pubkey.c Tue May 16 18:51:47 2000 @@ -492,6 +492,9 @@ log_mpidump(" data:", data[i] ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, result, *data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { @@ -526,6 +529,9 @@ log_mpidump(" data:", data ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, resarr, data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/Makefile.am gnupg-work/g10/Makefile.am --- gnupg-1.0.1-orig/g10/Makefile.am Sun Oct 10 03:23:41 1999 +++ gnupg-work/g10/Makefile.am Tue May 16 15:58:39 2000 @@ -57,6 +57,7 @@ keylist.c \ sig-check.c \ signal.c \ + agent.c \ helptext.c gpg_SOURCES = g10.c \ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.c gnupg-work/g10/agent.c --- gnupg-1.0.1-orig/g10/agent.c Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.c Tue May 16 19:00:55 2000 @@ -0,0 +1,214 @@ +#include +#include +#ifndef UNIX_PATH_MAX +#define UNIX_PATH_MAX 63 +#endif +#include +#include +#include +#include +#include + +#include "config.h" +#include "keydb.h" +#include "errors.h" +#include "packet.h" + +static int agent_socket; + +static unsigned char *hextable = NULL; + +int agent_connect(char *path) { + struct sockaddr_un sun; + + sun.sun_family = AF_LOCAL; + strncpy(sun.sun_path, path, UNIX_PATH_MAX - 1); + + agent_socket = socket(PF_LOCAL, SOCK_STREAM, 0); + if(agent_socket < 0) + return G10ERR_NETWORK; + if(connect(agent_socket, &sun, sizeof(sun))) + return G10ERR_OPEN_FILE; + return 0; +} + +int agent_read(void *buf, int len) { + return read(agent_socket, buf, len); +} + +int agent_write(void *buf, int len) { + return write(agent_socket, buf, len); +} + +int agent_enum(KBPOS *kbpos, KBNODE *ret_root) { + char buf[600], *ptr, *end; + int len = 0, i, algo; + PKT_public_key *p; + PKT_secret_key *s; + PKT_user_id *u; + PACKET *t; + + snprintf(buf, 599, "ENUMERATE %ld\r\n", kbpos->offset++); + if(agent_write(buf, strlen(buf)) != strlen(buf)) + return G10ERR_NETWORK; + do { + int ret; + + ret = agent_read(buf + len, 600 - len); + if(ret < 0) + return G10ERR_NETWORK; + len += ret; + if(len < 2) + continue; + if(buf[len - 1] == '\n' && + buf[len - 2] == '\r') + break; + } while(len < 600); + if(len == 2) + return -1; + ptr = memchr(buf, ' ', len); + if(!ptr) + return G10ERR_BAD_PUBKEY; + *ptr++ = 0; + len -= ptr - buf; + algo = string_to_pubkey_algo(buf); + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_BAD_PUBKEY; + *end++ = 0; + len -= end - ptr; + ptr = end; + p = m_alloc_clear(sizeof(*p)); + s = m_alloc_clear(sizeof(*s)); + p->pubkey_algo = algo; + s->pubkey_algo = algo; + for(i = 0; i < pubkey_get_npkey(algo); i++) { + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_NETWORK; /* leaking MPIs! */ + *end++ = 0; + len -= end - ptr; + p->pkey[i] = mpi_alloc(0); + mpi_fromstr(p->pkey[i], ptr); + s->skey[i] = mpi_copy(p->pkey[i]); + ptr = end; + } + s->is_protected = 23; + + end = memchr(ptr, '\r', len); + *end = 0; + u = m_alloc_clear(sizeof(*u) + strlen(ptr)); + u->len = strlen(ptr); + strcpy(u->name, ptr); + + t = m_alloc_clear(sizeof(*t)); + if(kbpos->secret) { + t->pkttype = PKT_SECRET_KEY; + t->pkt.secret_key = s; + } else { + t->pkttype = PKT_PUBLIC_KEY; + t->pkt.public_key = p; + } + *ret_root = new_kbnode(t); + + t = m_alloc_clear(sizeof(*t)); + t->pkttype = PKT_USER_ID; + t->pkt.user_id = u; + add_kbnode(*ret_root, new_kbnode(t)); + + return 0; +} + +unsigned char kmsl_nybble_char(unsigned char c) { + switch(c) { + case 0: + return '0'; + case 1: + return '1'; + case 2: + return '2'; + case 3: + return '3'; + case 4: + return '4'; + case 5: + return '5'; + case 6: + return '6'; + case 7: + return '7'; + case 8: + return '8'; + case 9: + return '9'; + case 0xa: + return 'a'; + case 0xb: + return 'b'; + case 0xc: + return 'c'; + case 0xd: + return 'd'; + case 0xe: + return 'e'; + case 0xf: + return 'f'; + default: + return 0xff; + } +} + +void kmsl_genhextable() { + int i; + + hextable = malloc(512); + for(i = 0; i < 256; i++) { + hextable[i * 2] = kmsl_nybble_char(i >> 4); + hextable[i * 2 + 1] = kmsl_nybble_char(i & 0xf); + } +} + +unsigned char *kmsl_byte_str(unsigned char c) { + if(!hextable) + kmsl_genhextable(); + return hextable + 2 * c; +} + +void agent_write_mpi(MPI m) { + int len, j, textlen; + unsigned char *text, *buf = mpi_get_buffer(m, &len, NULL); + + agent_write("0x", 2); + textlen = len * 2; + text = alloca(textlen); + for(j = 0; j < len; j++) + memcpy(text + j * 2, kmsl_byte_str(buf[j]), 2); + agent_write(text, textlen); + free(buf); +} + +int agent_process(int algo, MPI *ret, MPI data, MPI *skey) { + char *end, buf[2000], *alg = pubkey_algo_to_string(algo); + int i, r; + + agent_write("PROCESS ", 8); + agent_write(alg, strlen(alg)); + agent_write(" ", 1); + for(i = 0; i < pubkey_get_npkey(algo); i++) { + agent_write_mpi(skey[i]); + agent_write(" ", 1); + } + agent_write_mpi(data); + agent_write("\r\n", 2); + r = agent_read(buf, 2000); + end = memchr(buf, '\r', r - 1); + if(*(end + 1) != '\n') + return G10ERR_NETWORK; /* laziness */ + *end = 0; + r -= 2; + if(!r) + return G10ERR_UNEXPECTED; + *ret = mpi_alloc(0); + mpi_fromstr(*ret, buf); + return 0; +} diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.h gnupg-work/g10/agent.h --- gnupg-1.0.1-orig/g10/agent.h Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.h Tue May 16 17:35:37 2000 @@ -0,0 +1,11 @@ +#ifdef WITH_AGENT + +#include "keydb.h" + +int agent_connect(char *); +int agent_read(void *, int); +int agent_write(void *, int); +int agent_enum(KBPOS *, KBNODE *); +int agent_process(int, MPI *, MPI, MPI *); + +#endif /* WITH_AGENT */ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/keydb.h gnupg-work/g10/keydb.h --- gnupg-1.0.1-orig/g10/keydb.h Fri Nov 12 23:49:28 1999 +++ gnupg-work/g10/keydb.h Fri May 12 14:18:09 2000 @@ -58,7 +58,10 @@ enum resource_type { rt_UNKNOWN = 0, rt_RING = 1, - rt_GDBM = 2 + rt_GDBM = 2, +#ifdef WITH_AGENT + rt_AGENT = 3, +#endif }; diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/ringedit.c gnupg-work/g10/ringedit.c --- gnupg-1.0.1-orig/g10/ringedit.c Fri Dec 3 03:30:31 1999 +++ gnupg-work/g10/ringedit.c Tue May 16 16:04:41 2000 @@ -61,7 +61,7 @@ #include "options.h" #include "main.h" #include "i18n.h" - +#include "agent.h" @@ -102,7 +102,6 @@ static int do_gdbm_enum( KBPOS *kbpos, KBNODE *ret_root ); #endif - static RESTBL * check_pos( KBPOS *kbpos ) { @@ -215,6 +214,12 @@ rt = rt_GDBM; resname += 11; } +#ifdef WITH_AGENT + else if(strlen(resname) > 12 && !strncmp(resname, "gnupg-agent:", 12)) { + rt = rt_AGENT; + resname += 12; + } +#endif /* WITH_AGENT */ #ifndef HAVE_DRIVE_LETTERS else if( strchr( resname, ':' ) ) { log_error("%s: invalid URL\n", url ); @@ -343,6 +348,23 @@ break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + { + if(strlen(resname) == 4 && !strncmp(resname, "$ENV", 4)) { + if(!getenv("GNUPG_AGENT")) { + rc = G10ERR_GENERAL; /* how do I make this a silent error? */ + goto leave; + } + rc = agent_connect(getenv("GNUPG_AGENT")); + } else { + rc = agent_connect(filename); + } + if(rc) + goto leave; + } + break; +#endif /* WITH_AGENT */ default: log_error("%s: unsupported resource type\n", url ); rc = G10ERR_GENERAL; @@ -760,6 +782,11 @@ kbpos->offset = 0; break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + kbpos->offset = 0; + break; +#endif default: BUG(); } kbpos->pkt = NULL; @@ -779,6 +806,11 @@ rc = do_gdbm_enum( kbpos, ret_root ); break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + rc = agent_enum(kbpos, ret_root); + break; +#endif default: BUG(); } @@ -803,6 +835,9 @@ kbpos->fp = NULL; } break; +#ifdef WITH_AGENT + case rt_AGENT: +#endif case rt_GDBM: break; case rt_UNKNOWN: @@ -1826,3 +1861,4 @@ } #endif /*HAVE_LIBGDBM*/ + diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/seckey-cert.c gnupg-work/g10/seckey-cert.c --- gnupg-1.0.1-orig/g10/seckey-cert.c Mon Jul 12 22:57:49 1999 +++ gnupg-work/g10/seckey-cert.c Tue May 16 19:01:01 2000 @@ -43,6 +43,8 @@ int i, res; unsigned nbytes; + if(sk->is_protected == 23) + return 0; if( sk->is_protected ) { /* remove the protection */ DEK *dek = NULL; u32 keyid[4]; /* 4! because we need two of them */ --=-=-=-- From bofh@eris.phys.uni.torun.pl Thu May 18 14:12:14 2000 From: bofh@eris.phys.uni.torun.pl (Janusz A. Urbanowicz) Date: Thu, 18 May 2000 16:12:14 +0200 (CEST) Subject: GnuPG with Netscape Messenger? In-Reply-To: <20000518101453.C13517@djebel.gnupg.de> from Werner Koch at "May 18, 2000 10:14:53 am" Message-ID: Werner Koch wrote/napisa³[a]: > On Wed, 17 May 2000, Paul Gallagher wrote: > > > I'm wondering if anyone has found a way to use GnuPG when using Netscape > > Messenger. Any ideas? > > No way. > > I started to do a workaround based on a local proxy used as smarthost > and pop3 host for netscape (you can enter localhost:1234 to connect to > an smtp daemon running on port 1234). This tool should do all the > crypto stuff and has to popup a window to ask for passphrases and > to select the recipient's key. > You can always use premail for sending (on *ix systems). Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From ls@Gambit.Msk.SU Fri May 19 13:26:03 2000 From: ls@Gambit.Msk.SU (Sergei Laskavy) Date: Fri, 19 May 2000 17:26:03 +0400 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" Message-ID: <20000519172603.C9570@Peru.gambit.msk.su> I hope you will be happy to repeat this: (0) I use $ gpg --version gpg (GnuPG) 1.0.1 Copyright (C) 1999 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Cipher: IDEA, 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160 $ cat ~/.gnupg/options charset koi8-r escape-from-lines force-v3-sigs honor-http-proxy keyserver blackhole.pca.dfn.de lock-once no-greeting quiet load-extension idea load-extension rsa (1) Here is the test message: -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have just uploaded mutt-1.1.12 to ftp://ftp.mutt.org/pub/mutt/devel/. =20 This is a check-point release to summarize the few changes since 1.1.11. For 1.2, I'm mainly waiting for Brendan's pending changes to the IMAP code. Season's greetings, tlr --=20 http://www.guug.de/~roessler/ -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOQH0otImKUTOasbBAQEr3wf9GOPFRB12s7Hs+XOEwQaPhiJpFPkQ5vlh S/MYOZ4UzNMhYVpqlASAQeHk2lQFP/aQscFo0ltv7cTUmHmNgPBP/1MnkuFVMXo+ M4wb69qKJytxbDurpgHES2Y/WasPGKM6Vt2sjWNCA7UsBsorg86wCdl/fwe7pCz5 kc4emPbMBo2Kw9WI3GPP3lf3XNQKi82SfA6ilAKVOjHvhOb1odoGoCQBis8P8D11 r6FoaAQsi50vsMaUVFWET4udqNCtNfDLAZFjN0iGLL436Y9jHe95+Kjuf2+Q+MXZ 9TUyjPfboB+PzyIfPgdjl56UFFsiqUM104AWXhmdGj5XWO0pjZdVFQ== =OVlh -----END PGP SIGNATURE----- (2) Here is the public key (it's also on keyservers): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.1 (SunOS) mQENAzSgEssAAAEIAMgjiiDIe0zOqjJ2TcsWXW9DYTFzyHPSYJTBHjivb0Vekmra x+M/r6U+AWM1Bf92fGWx7cMn4oYkkaMnO8LQrBXKC8IcnwrJitvh1O0xCnIqWi1E b2JOUlxRJuVYrBNgm0OxlKBCxCmKs4yvZsJ3ykClkUJmSmBV9qDpRUJqxGzyzJ97 C36mbWV/LBKamhFcuDyAmPLZPYWwijaqixXDBuC5ouEPPUmFDgkN5F2533U/imej LSEVOMIthr1qH++wx1g50imHnmKjrtwSn4zA/f++9nl5YyOP1DwZKTu+91JEJPTH aDSnKzWRk/t7lx2JfblDjxYQlziz0iYpRM5qxsEABRG0IlRob21hcyBSb2Vzc2xl ciA8cm9lc3NsZXJAZ3V1Zy5kZT6JARUDBRI38b4/CdxwOTnzf10BAW1aB/9p2gpa ggQjcB/A3kpSEPAhc+U1jP4AVFx3BIdj/yceArIdi/j87CMN5tdHMkktC9ym5/qJ wCWn5YRnl7nF8hT1tLICmO+t/vbo4X0U7kykGVNhbHNMsMpHfBT9S88BkJno1s2D GTTN1gVloDwa4aSbqW1ltRCSSZFoSwigJUQCNYU/e7HOdYe+F+kybXZPvA9L5rg7 zW1vsp0vTLglFpmjLCgaEIIFgp297eW8wmXo/IKuWAO+kNccI6Y4JCJ8+kJfqSgw y7xpvBnuyFu/8/UHcw+wL+uUMRHzrlAibPqy3k3ZwUDOkJeLL9GJaMH+KbzlNzTS tIR1Q6188D/7Hj7piQCVAwUTNyHtwAui8ZR0SloRAQGiugQAqEAoo07fFF1RFgWP J1SVmlJDLy0O2H9hkB6KJAMtds3ga9Ku5exJZfgDz1W839yM0ntgprPHmLtlVp3f ZrLwlUjcr4IXmY45myX6I1xa+TiHEQh61U1fOPzYYR9o+3acyEZE/5uEd0ve66y7 iROHZtoPyvg8uudEHA1wd9l/TwaJARUDBRA4IDMZC+VzVzZkFFkBAUpfCACAJOPE da058VbTx721fDrNxCQu6Fk5LbbP3VTutWasWgit/s1Wnr32SptVRXqsjYp5BFwV Ug0JC8rGBfB1yAG9lXJaHrGoDuqdDKbdpZRFE8UtLnVktfW51p4ZcfuQb3DVKx3Z SVIhVrKaQUt50tWpAme+6jQTjotsO3lGtuFHyhXa/3nXQG3evmagSpAmb7Uu3b/m NSy1YLNf1h6jaJZvYKjchcgE0WE7jEJ2tBFoMd1GgSRij4WN7XLkOLPpGMma/a/A 6DNyD+/UTsZbb27pQNW32KNcA4EN8Zu1npzgNcNYd7NqScjcf0wiXkqZFNHr1XSO c8/IEsxp8v+wuhikiQCrAwUQNLu+OBKt/zYZlwkHAQEyugSwpalGr4euJUpkobI/ WvrnGAqXZRj++1/IEof7x+Jl2TnOjrMLZflgCwy0E2ZaBQpQxEcAwsNfFW/i+zGg 6+ctwN9J7SxEnN2TnUNBT2l5foRx7fIVNi3AXoOd6b8xmvad/FG83utrCxUpvWnW ZMY4C6rZKCgjXtRpd9pSwU8X3QAmI8p3dfWdLxAoZxgzJZVPlewwVRwpiQCVAwUT Nx0OJRRPLUVPVwujAQHHgQP+NF0YAIL3kl+q2sa9YCUXNgCQ+mTvZb3Zzu/q3u8+ ixTowui8bLBTFY3+yIx6IzEHATcoUPCthYwnvfX4BqWNWgDFN+eWaNrZpNEfZVkW Bs6Sd0/R4AcERUcoyp48pnH77E/XS4O4b9VlFYiQV9CX+er6VD5f0ERuNiTaD9pQ Ec+JARUDBRA3JupwLHrik2A/LQEBAf9IB/9Tx58nqBfmTok8VdUQj7bZPksOTlAK WG/f8RD5johFz/OxIey3+K1agiLA+Acr8agfQMAvfxNliJIFGcVgkyYlr/zr4aRh 6e+KEjPGuYgV607be1hPm7xmjNzJklXV0ouKgFqB6kNy+FOdG2OWXrzMQO/Dbwh6 /ofToNoOdsit9mQ5HxUuq2f0TmrjVwoBQqj/QxzA1mS/KgCdsPlEF6v9BsoXyxF3 0Wbj+h+nAU3EdOWgOTexmhcpmOvKx5bW766mB+zAdpj9c33xAMU9lt6bIIcD3cxJ fs7s9ZhWlczoarpUwU+BoKE0dMfvs6cf6NPcTrODqvCUAJwYCR42KZdZiQC1AwUT NKATSj4lAO9ZMjjhAQFvHgT+Ol0myw6jILx78keIEDdJy/fxdK6T56XUYX8nNez3 Ibm300bT63yvEnD3U6pgN+sEyzuLxP/L07Jk2E3OHJHLXJpLHWQlebW3ey9EEaYV xjClSFrmidc0Jd5nMAFmssJ9AHuENKvO096yHTMvH3MYIjYJ1HfyDUnIVDwFL8KF 4fwQezrtMwWzt8WSjWEbGmXZXW7kZ1lBnL8f6eYvCigFYYkAlQMFEzSvti9Dr0FE 3QjdbQEBPdYD/3zZLNh9rPPQ4pZ/0HfQr88BBrjIdKIXuEaZbkfiohuKf44RqOdt k832Mmb2yrp6i8IN8UHPPTpM7xfvmab2Rk21SxRZJ0IsbXzYVSP1oxdE3lIOyVlB vtn1FXEU9JuGD8N9dM994Yirg/2EfjpPJ7SdRMIdtrFAzagJvAvmdk7iiQCVAwUQ NO2N7knh/jPvZzKNAQFdlgQAlGd9mSgxjv6Id8FZ3lMhU0RzKvHNFRof985lkyJt R/01qAJZbCxeJB2y5diLw6qZaVw6+hCqgP5Bbw8PPtKr7i/OvAXBPgoU5Ume4J2A EsavEmavAJ90Zph0WK2BzqCQd1EP5M2jqdBATDunL67rJ5bk0l7y/KwgM5NhyCmY FNmJAJUDBRA0xeJJTFllIALEMQkBAdTfA/42FNAByvEHM9pRkK4qftVDSnIIZeRP uIfV+mO4FcNE9h/oH3nBSOUGn7NqsjwJuj4daZ2tmWfH41D8oQjPVqdM4fd0csYk FZLI0qu1wTd8MxEJsHoh5qIU8M6ywL5pIflhOP1wGf6omqBh2VZuhYY6m0775Lih A0c/DLokymQ6C4kAlQMFEDccqjNMo00siEncPQEByDcD/3cUDPeFBlzq5SSKANRA emT0HoW+aoUO+bRavqOzwCuYNhkSNx7yukACFc8fu13vlBpHL39RLJC6zT+8rto1 MH3SLnJNJj7FH8NZUQDffwXXea3eydNCx0T9fVu0QBndPvyib6K3oVD/Z6yirbo+ pNZnn6U8aOrEXf18IizhhBdxiQCVAwUQNvYNv1H8PGQHafT1AQGBrgQAhWdZ9ws2 EIh8LJEAb53FHcjonandcJ7HDgLo3GpWnhIvhcc+YKQluW/8lS92bsjY3tVRfDYe Y80NjEODDgn+CEcOu9LqssGj4CwuU7b58tBdSIV1v7CSX9cTM9+0r0qGU7ql7Lpn zBqhx36UXqOK6vfU0cWrHLkPUNlms2a96LeJALADBRA3TTnyVmSU4zFmVdUBAZlh BNEBfEm35/lKlMV3hlFMT/K7ZhddrptYh+vCGhJNSO48KD+6foES7zgAH8k1j1Wh A2b4oVG7X4x5T603UqGDFpaycddqxGc7Bs7E0aAVygEkoJQ6c8AjSkyy/lRnGZ1G ln7vPNM8TokQJQRKfkm/tPpE1jneaU/j102We0jg2ULyJQOLB73acI/v5O4p1d1F +W5S3XySxxDcbOWJjYkAlQIFEDUZVnh4YVpjdyds6QEBU2sEAKjJkcCiOqnyh7I7 O1PIVbEWumltWd5CXDT2MwMXX5vOGex//qERDNDqR4w1ksPj3NVOkSaVFQMjw2Ys zBFFHma45LZPSxv2UGxjII8qPPgPmkllLyhHCGrDRY+IZ0Wax+HFfJe3g6xYYgCl ojNVd1chV9eduNZLxdvhV4YKVSHMiQEVAwUQN1PmOH4v6i2JDAmBAQEP3Qf5AYd0 ytzQB36MJHx+jHismpNsJEGj/rQ8PxeWnic9GkcgBi97wflQaldonFlvoeNFyIwS MTLs2vZTeCRLMxc1LFnwurx8/2oks9xp63733Rqs9DonnkDQR04YWLkw4djTaEDc /GWHCyYiPj11G/12b09ywf4nPd32K8AVoIQAPQy5P4GRhesQTvWTl1yXLEVWjv6g PLJUo3l1BrIKm+GMdnlBqTGpswPtkxeUqp8mjYdwnmm5ajX/qkxe1UE/t5V74169 uTL1+DjEl3CT+rVR6UtEc2qM3Zg2PTzgjmrFfHeUdXv1QBfRJlhmtPQtRX4csDFP fX0sO5n5PZpYcYlzC4kBFQMFEDTFOAt+8FjoQyMUJQEBjpIH/3Uwc8cMr8RAie00 9a7536V2x2miBAoTAjsb5ui91geM4ssXgilUgB/sBW/bV6cZA67Q7YYSollFSKPb LhmoZUEvkf+cS6cdojUbq2p2pd7Djq3ZSYNTRbIKo8KWBLSfSuDsxdu0oVdW3DO2 5TMzkauxNnqMegWjLSRCMRigdQYYmZKrA9tY6hD63c6eLt2DAWuF+pepwo5N6jm7 yGHWAW0ihhqv+NHlIc3JExxxzDYeTjC4Yb5dfHpYG7ETbsMZCQ77Ru1isbcA557/ kgSwKPUt0LAMgVj9atG4OIezjwPubEV/SxvcRnjEKsQOQe7WriLcPjeELlMvakBc nDS7NtqJARUDBRA29l83fvTWwzbkE20BAc0HB/sGlryh+m+UJR5TjI7cMf13UnFh vL88TIRLGxVwsOYoKixiU1hPecGFWcXsnYue6Hduvb9EiBdn3GQcKQAda0TtCXoJ 6gmph8xx7cGqSGd1ldh1nkWbGsCt82HcK7XQ0qF/zUTuRwxi7F30YI5ZBYBLOVsn dB7rMm4ObkHH0nskMMMfZ1VcsT5ndvKL2RvevRaleXob14erDDsEmqKzPMRpyTKO CAMnK5k86P8uK+8hg39rLSQodPKzxvtyJNEDt3iizQ+Ac1nlPIeO/pN7CnqJwu5T codS9bVe9A39gIqhbCp8zYjKD+uU+8tOGYthuU2FvgDaB0NU+pzSaw2X2se6iQCV AwUTNK/OIokABLrCbuiRAQGsdAQAxOh0ipz4H80XifbWjh+W721oIwXGjBl/n/e/ UJh7cqzqZxo+I/vR3O0wCfnkeQ94ihe24eamvEvwvWbpRmnfqozp2Fuo9JcazgML j0eDmqZCe0XJEi4t3WdIavy59XskuzPaM8AepRKULStKup22o5jgvOnK6/2KcYmx oKULfeCJARUDBRA1EBSciVPDw6koVP0BAQkvB/wN1M5oadLBjOIgm34y1qtxnkvF ZuPIJIWVVX+3Fz2FwZ84OIqVtNGxjKAOkyFG371+wEXc7xZZ9owSCO2edVTCC2wL 2mDFostS7G4aTDWvXMx0lWTTc8V2RZTOQ8bGJDo+6HgFNg4gV/03MpPqB413yVas XseES/yCt+haLnk85mO8KVSGP7DAdwJn5tLx3GKHZE3Qh9XTJ0j4V/9uG8ohf94T O63s0V/3ZAMUK8GaP4kiC5d4ZEN+4DyHw6xjYTmrRp3tvXKJrUHaSnCXaS7Obr2C DO5LyRi07qMrkHAxjmDMdJYHyS9SEPqphx+/1TyYZQx1edrlLiY31YSFEpH+iQCi AwUSN/G+HpFeTizbCJMJAQFzUgRmN7+0sKxmW7m5MBaB2dHnOpoya6Kxzbp3oghW 8cX4+DOI4zukBDWvEnnreCnbl4dFoTr38+GoG336NozKhKvx5kvSqBzL6XpzXrT6 OTg/b2NGiFpSR0QKNJtNSUUwGwSVDa1Yqqn0FMmFGAeI08p+VeMXLpwjDWXsvRYr 9S+fVY+jDNeFRv7yOUFOZTstiQCVAwUQN29YLpznb919i1kZAQEDSQP/bbq6SB16 jS7IjIcUHHvhHZ3aXmFkx55kcKPnBZrzPOAN9R6jFDS1wu0ejxVPNp6iGzODq2tz UPv5HJfWufxMaxHpnHQ6J5+EwpLQwWj2PrSQg6idNA4W/0eFLi0SOlFj8JAXt69j fkl/K4R/kiNPVL2FVWQMCOLtYVxTbkf6XxqJARUDBRA28ZJ5nnPrCk1Y7lEBATqQ B/sGsKnPF45GKF7Yu/3dNwQD38g5Qpj8+7ddPcjME7tmkD8BHFR6o6bDtv7zWeEF uxg+XjAxg4dPSHrAXdKZ5SDHqJO7+GbZP/eP7zoGw4V1GVnCz0e0v2WXUfe56oFu oO/4XRrbsWhAtYPGeYi9BO/XRDIjDmjvFvjitjwIgxzUb/t6DqPMHchRpK1MOTWs bvUOb8Dz2U8YusH/G5puw2AemLyeXx6erZJm385bcAzgoP+tp4fA6SjSlQs9FD7J Y4goyBv534fluGGHth+nuIB2jn+zHOkcUgAgOJPSGmZSsSxXKQxfL1Xr1SdNbT16 i2VOIu7MWkceillxJUMIHE7ziQCVAwUQNMZ9G7Btxkr72ChhAQFIuwQAigFlRtsE jhtOXv9+Ot2gqKbqfj2TkOTCpr4HRlFGDzkIkbBZsp8q2Af5ZiQ7/h/g1asqbvzK J6XTWQo6K0U9iiasWYpXlUlrlVhMjm3hUrGLaMglGcnURemVHhhfS3S/4aggJqW6 Dt5U10txXrAdKfegU0+HEJ5L6WuKaulDxViJARUDBRM02HCwvqaOf4UxMn8BAfIb B/4omzocwa8eHPZgsuwq9pkU69qtJmndgxAxzSivSfd8UV3rVKquxIfPWTJuBuug EleQlskVASKiQVKubgSpP7VcyHimzgPt9w/RKLDpDAGAzZh6r9PX3BxdKxaig2Ny eiCmLYv7oZG6nOFa1xaPYmjxVDOwT39kZE36O2Boe5rW2Jj+GG/Iwxt4iGToXyZW Gz7uXP/Ar3O+kjQzgg14ieFkyOQYuI1Br/9ZCMIFwjHXfQsXRYP+ftTLi9DYfTXh G0bP+bc1FdiRLjM4IHYJ9ydl2p/1TL01ZO6eb9DB+a9esjXfb//frYCRFNPKoV/A b4TgVWYqAJlLczLEwfBkbkZgiQDVAwUSN/G+Xb+Ot2lXSNSVAQFEaAX9FQjXrDRc /FqkeiBNievdgVt03Lrm2XYkKnnvh059M7i+S/tVW7ly3sifvM1J4X2hvT9jbhb0 lD0gISXz85n7pHMpf4cxJpTnMefRBKFoDA2AYLUHL8Rq+VOKkdPM8pCgySU69Ssu ZPrK7kOByWiU8VeekL1+7236QrstzE+P8ePygXb6hrQZXzgClVq9DfVu3r5BRagU za/CDfuECEoRrdCPNOTOcC2PbdJjtLQIAm8m+llYXkd0Ij3zhB1HAISwiD8DBRA0 3w93xiLu3cOF4DcRAoYMAJ9AxHy1WoKMNp5BtD7bJVPiWmXXjwCfcaeh4TirEQLm aMT+TdecW0Nv1E2JARUDBRA0oBMs0iYpRM5qxsEBAUT8CACbuZBD0zuWHTuqTvEY MIuO/VJL0f+op9IwpMjD2W8EzXa5XEq4WoCdff9YzSZUT/T6Sy2ZcercLgthJRcr gQowZAQvn3UDnbF7OpPv3cblapmb2lvIDhJESco/I1R08kZN905bFmkcF1sNXsjf 6B+K2N2BSizbE2aS8xIJ+tuRDGeS1Gsai1e+impbGbVQiO4lUQlAOZeJPQ7IOtED yEHUjWw1FsOq/x9GNZMMxIqN/BagsqpA7eHJ76fsMQN1f0kh3oepaN3lZ7xqoSGE MIpf/eCzawGwlrEA3aROCjr33+hHzimIj8rtuxKUAo0jvNs8Wg3V3mXW/QgWhW1y hfLAiQCVAgUQNK/96fE8+WC3TbWNAQF40QP9Fq0LhANCSh1cQFqxIbCtzgyEm0ZL Ujx0fFE9onyE0/Jnuh+3fvRGde0UxzEfrTqf3Z+1hxYDtnuxcRUTlVSFRJfvO3g9 b+fcw08BG8hLpexQ1Jl27rEQEnxu3kyxtw+WkxDw/JMzf0bPG7rz4Rp2UbwOvFCY 1mLh+fsl4QvdnGCJAJUDBRA0sj2j9e+XfZ71UOEBAT9VBACeGQsN4aabBhcJlQIV XO9MlDY5ioWgRgAS/WCLgXf5FNvT5hVKv/WNHoe4VLQjJQE17MocrU8MpYxkoXBk JgNLfMl+hp7wACHXvn9m5MTJFJuRx3uuuyNi5Tyjhtovpn6MUn3nSxLID/F2XMMo Vfhu0Pz0V+DHMa2kVl1U/Xa+wQ== =jubg -----END PGP PUBLIC KEY BLOCK----- (3) Start gnupg by $ gpg < /path/to/saved/pgp-message gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK ^C gpg: some signal caught ... exiting -- Thank you! From wk@gnupg.org Fri May 19 14:38:46 2000 From: wk@gnupg.org (Werner Koch) Date: Fri, 19 May 2000 16:38:46 +0200 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su>; from ls@Gambit.Msk.SU on Fri, May 19, 2000 at 05:26:03PM +0400 References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: <20000519163846.M14819@djebel.gnupg.de> Hi, iirc, this has been fixed in 1.0.1f - can someone please test against this version. tia, Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From offby1@blarg.net Fri May 19 21:12:55 2000 From: offby1@blarg.net (Eric Hanchrow) Date: 19 May 2000 14:12:55 -0700 Subject: How to deal with old RSA keys In-Reply-To: Dr Lyman Hazelton's message of "Fri, 19 May 2000 13:45:14" References: <3.0.3.32.20000519134514.0099abc0@mail> Message-ID: <8766saz1k8.fsf@potato.hanchrow.org> >>>>> "Lyman" == Lyman Hazelton writes: Lyman> But I have an old RSA key that's been kicking around for a Lyman> long time and I didn't have a die-date on it. I still want Lyman> to be able to get messages written to me with this key. Is Lyman> there a module that I can add to gnupg that will allow me Lyman> to do this? Not everyone is switching to gpg and I still Lyman> need to hear from them in private. This should really be a FAQ. If you're using Debian GNU/Linux, then all you need to do is install the packages `gpg-rsaref' and `gpg-idea'. Then add these lines to ~/.gnupg/options: load-extension rsa load-extension idea -- PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5 C8BD 6337 0041 C01C 5276 From sroberts@uniserve.com Fri May 19 00:03:57 2000 From: sroberts@uniserve.com (Sam Roberts) Date: Thu, 18 May 2000 20:03:57 -0400 Subject: Solaris random device In-Reply-To: <00f101bfbcd5$f327f000$16006598@asiainter.net>; from em@who.net on Sat, May 13, 2000 at 08:22:18PM +0800 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> <00f101bfbcd5$f327f000$16006598@asiainter.net> Message-ID: <20000518200357.B471@localhost> On Sat, May 13, 2000 at 08:22:18PM +0800, Enzo Michelangeli wrote: > ----- Original Message ----- > From: "Andreas Pommer" > To: > Sent: Saturday, May 13, 2000 16:59 > Subject: Re: Solaris random device > > [...] > > Currently it is more similar to the linux /dev/urandom , less to > /dev/random. > > At every call to the device some entropy is added (from a high resolution > > timer, and sometimes process id) and subsequently mangled by some hash > > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > > The solaris kstat interface provides access to a large number of kernel > > counters which can be used for that purpose. However, the "good" ones > > have to be determined. > > Why? Just toss everything into the pool: the total entropy cannot be reduced > by adding low-entropy data. The more, the merrier. Yes, but the implementation of /dev/random so that it blocks until sufficient entropy is available, requires an estimate of randomness of input. Some statistical checks are done to estimate this, but when data is put into the pool it is identified as adding to the estimate of bits of entropy in the pool, or not. GnuPG, for one, attempts to select() until as much entropy as it wants is available. This entropy estimation seems important, though fairly fuzzily defined. Sam -- Sam Roberts, sroberts at uniserve dot com, www.emyr.net/Sam From tyketto@wizard.com Sat May 20 08:42:38 2000 From: tyketto@wizard.com (A Guy Called Tyketto) Date: Sat, 20 May 2000 01:42:38 -0700 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519163846.M14819@djebel.gnupg.de>; from wk@gnupg.org on Fri, May 19, 2000 at 04:38:46PM +0200 References: <20000519172603.C9570@Peru.gambit.msk.su> <20000519163846.M14819@djebel.gnupg.de> Message-ID: <20000520014238.A30251@wizard.com> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 19, 2000 at 04:38:46PM +0200, Werner Koch wrote: > Hi, >=20 > iirc, this has been fixed in 1.0.1f - can someone please test against > this version. >=20 > tia, >=20 > Werner Has this been released/uploaded yet? I'm not seeing it, at=20 ftp.gnupg.org:/pub/gcrypt/devel. 1.0.1e is still the latest and greatest=20 there. If it's located at another place, please let me know. :) BL. --=20 Brad Littlejohn | Email: tyketto@wizard.com Unix Systems Administrator, | tyketto@ozemail.com.au Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5Jk/+yBkZmuMZ8L8RAnkaAJ9Ksu1gNeCOn2Fk1ePmWsRgoNQvOQCZAZmM xnVmuHNaxcePKFhNNH1DwaM= =t6Ko -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From hideki@allcity.net Sat May 20 23:31:18 2000 From: hideki@allcity.net (Hideki Saito) Date: Sat, 20 May 2000 16:31:18 -0700 Subject: Windows version of entropy.dll problem Message-ID: <200005202329.QAA19377@server-1.visp.net> I have one bug report (among with fix) in entropy.dll which is distributed in GNU Privacy Guard for Microsoft Windows which is in the download page. It is that in certain circumstances; most visible in Windows 2000, it crashs when it is executed to generate keys, it crashs. This problem is solved after I compiled entropy.dll from sourcecode using Microsoft Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll Thank you. -- Hideki Saito mailto:hideki@allcity.net From hideki@allcity.net Sat May 20 23:41:15 2000 From: hideki@allcity.net (Hideki Saito) Date: Sat, 20 May 2000 16:41:15 -0700 Subject: CC Request Message-ID: <200005202339.QAA20452@server-1.visp.net> Sorry for bother about this with separate mail, but please CC me if you have questions or comments about entropy.dll, since I'm not subscribed to the list. (is there anyway I can subscribe to it?) Thank you. -- Hideki Saito mailto:hideki@allcity.net From wk@gnupg.org Sun May 21 17:22:36 2000 From: wk@gnupg.org (Werner Koch) Date: Sun, 21 May 2000 19:22:36 +0200 Subject: Windows version of entropy.dll problem In-Reply-To: <200005202329.QAA19377@server-1.visp.net>; from hideki@allcity.net on Sat, May 20, 2000 at 04:31:18PM -0700 References: <200005202329.QAA19377@server-1.visp.net> Message-ID: <20000521192236.D3283@djebel.gnupg.de> On Sat, 20 May 2000, Hideki Saito wrote: > It is that in certain circumstances; most visible in Windows 2000, it > crashs when it is executed to generate keys, it crashs. This problem > is solved after I compiled entropy.dll from sourcecode using Microsoft > Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll I am in the process of reqriting it without the need for DLL. I hope to commit the changes on Thursday or Friday. However a lot of new testing will be required then. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From rguerra@yahoo.com Sun May 21 17:54:59 2000 From: rguerra@yahoo.com (Robert Guerra) Date: Sun, 21 May 2000 13:54:59 -0400 Subject: GNUPG & AES Candidates In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> References: <200005202329.QAA19377@server-1.visp.net> <20000521192236.D3283@djebel.gnupg.de> Message-ID: Werner: I'm forwarding you a message I recently posted on the pgp-user's mailing list (http://www.cryptorights.org/pgp-users) . I'm curious to know if you are considering adding any additional AES candidates to gnupg. regards robert Date: Sat, 20 May 2000 22:45:31 -0400 From: Robert Guerra Subject: Re: [PGP-USERS] PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org Tom: At 8:49 PM -0400 2000/5/20, Tom McCune wrote: >I found the following at: >http://www.pgp.com/asp_set/products/tns/pgp70_reqts.asp > >>Cryptographic Algorithms Supported >> >> Public key algorithms: Diffie-Hellman/DSS, RSA >> with up to 4096-bit key lengths nothing new here unless 4096 applies to RSA as well. >> >> Symmetric algorithms: CAST (128-bit), 3DES >> (168-bit), IDEA (128-bit), Twofish (256-bit) twofish is new...but it hasn't won the AES competition. Can the Rijndael cipher be added too? I believe that the other AES finalists should also be included. It would make good sense to at least keep the others in mind in case Twofish doesn't win. After all, it would be nice if PGP v.7 could have the AES winning candidate. For what it's worth.. At our Toronto May cypherpunks meeting, it was mentioned at that the Rijndael cipher was well looked upon, and a favorite of many at the april AES conference. As it's invented by a group in Belgium it will be interesting to see how it plays politically in the selections process. After all can the americans seriously consider to accept and deploy something made outside the USA (NIH - not invented here, not good) >> >Any other news that can be shared on related changes would be appreciated. Some references: Video Report of The May cypherpunks meeting in Toronto (Canada) http://www.epress.ca/privacy AES Round two AES Round two analysis AES Second Round Implementation Experience The block cipher Rijndael -- -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From Nils@infosun.fmi.uni-passau.de Thu May 25 14:02:03 2000 From: Nils@infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Thu, 25 May 2000 16:02:03 +0200 (MEST) Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: <14637.12891.65451.656522@skrjabin.fmi.uni-passau.de> Hi all, we've had quite some discussions on this list about the various random "gizmos" available on Solaris 2. I'd like to summarize the possibilities and then make a suggestion. The need for entropy is not a domain of GnuPG alone; OpenSSH needs it as well, and there may be others coming (BTW, I've heard rumours that the OpenSSH folks are considering to use gpg keys instead of their own user-level public keys. Does anyone know more details?). There are currently three options that I am aware of: ======================================================================= 1. Entropy Gathering Daemon (EGD) Available from http://www.lothar.com/tech/crypto/, latest release is 0.8. This is a perl script running as a daemon, providing an entropy source through a pipe. EGD is supported by both, GnuPG and OpenSSH by means of a configure option. The latest release even works on Solaris 8. It works very well, the only drawback being its speed: if you need a lot of entropy (generating keys, multi-user platform), egd might be a bottleneck. 2. /dev/random as provided by Sun package SUNWski This software was developed by Sun as part of the unbundled product Sun Webserver 2.0 on the Solaris Easy Access Server 3.0 CD. This product was supported for Solaris 2.6 and 7, but not 8 (because Sun is now using Apache or Netscape's web server). However, the SUNWski package still works fine on Solaris 8, provides entropy much faster than egd (it's a daemon written in C) and was reviewed to provide high quality entropy: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=95618127814224&w=2 SUNWski's /dev/random is natively supported by OpenSSH, but in order to use it with GnuPG, you have to apply the following patch. That's because SUNWski provides /dev/random as a pipe, and not as a character device. The patch is relative to the current CVS snapshot of GnuPG. As SUNWski provides only /dev/random, the patch assumes a link from /dev/urandom to /dev/random. diff rndlinux.c.orig rndlinux.c 86c86,92 < if( !S_ISCHR(sb.st_mode) ) --- > if( !strcmp(PRINTABLE_OS_NAME, "SunOS")) { > /* Solaris 2 Easy Access Server -- SUNWski */ > if( !S_ISFIFO(sb.st_mode) ) > g10_log_fatal("invalid random device!\n" ); > }else{ > /* Linux , xBSD*/ > if( !S_ISCHR(sb.st_mode) ) 87a94 > } diff configure.in configure.in.orig 447,458c447,448 < [case "${target}" in < *-solaris*) < if test -p "$NAME_OF_DEV_RANDOM" && test -p "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < *) < if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < esac]) --- > [if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then > ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; fi]) You would then use the random device type "linux". However, this patch breaks the use of the 3rd option. 3. /dev/random and /dev/urandom by Andreas Maier This is a new port of the Linux kernel random driver to Solaris 2 as a kernel module (what Sun should have done in the first place!) from http://www.cosy.sbg.ac.at/~andi/. It's very new, therefore hasn't been reviewed regarding it's entropy quality. As this is a clone from the Linux port, both are character devices. Therefore, the GnuPG sources don't have to be patched at all. You just select "linux" as the random gatherer. I've tested it on Solaris 8. I didn't recompile OpenSSH for this, but a quick look at the sources suggest that it should work there as well. Unlike GnuPG, OpenSSH only tests for existence and readability of /dev/random, but not whether it's a pipe or a character device. Being a kernel module, it should be pretty fast (didn't try). Personally, I would like to have the source reviewed by someone who knows about entropy gatherers before I'd use it in a production system. ======================================================================= Proposal I'd like to see GnuPG being a bit more flexible on this issue and therefore avoiding the need to patch it. I think that taking the OpenSSH approach (testing for existence and readability of /dev/random and /dev/urandom, being still happy if the latter doesn't exist, and don't test the type of the device; suggest the use of egd if the devices don't exist) should be OK for GnuPG as well. The naming of these random gatheres as being "linux" is a bit unfortunate, but that's just cosmetics :-) Any comments? Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From sam@cogent.ca Thu May 25 14:25:37 2000 From: sam@cogent.ca (Sam Roberts) Date: Thu, 25 May 2000 10:25:37 -0400 (edt) Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: Previously, you (Nils Ellmenreich) wrote: > Proposal > > I'd like to see GnuPG being a bit more flexible on this issue and > therefore avoiding the need to patch it. I think that taking the OpenSSH > approach (testing for existence and readability of /dev/random and > /dev/urandom, being still happy if the latter doesn't exist, and don't > test the type of the device; suggest the use of egd if the devices don't > exist) should be OK for GnuPG as well. The naming of these random > gatheres as being "linux" is a bit unfortunate, but that's just > cosmetics :-) > > Any comments? I'd like to second this proposal, particularly about not forcing /dev/random to be a character device. I ported Linux's random to QNX4 and Nto, and I took the approach of making them look like character devices so gpg would recognize them. I don't really think they are, any term control ops on them would fail, a named pipe or a QNX named device would have been more natural. The term linux will be increasingly a misnomer, I believe the *BSDs have a /dev/random as well, for instance. Sam -- Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca) "News is very popular among its readers." - RFC 977 (NNTP) From koch@hsp.de Thu May 25 15:37:26 2000 From: koch@hsp.de (Walter Koch) Date: Thu, 25 May 2000 17:37:26 +0200 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su> References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: Moin, am / On Fri, 19 May 2000 17:26:03 +0400, schrieb Sergei Laskavy wrote: >$ gpg < /path/to/saved/pgp-message >gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 >gpg: Good signature from "Thomas Roessler " >gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK tested it with gpg (GnuPG) 1.0.1f-snap2000-05-25 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: Warning: using insecure memory! gpg: Signature made Sat Apr 22 20:51:14 2000 CEST using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " The NOTE: is completly gone! Gruss, Walter -- Walter Koch Hochdahl am Neandertal http://www.hsp.de/~koch/ qrv:db0iz-9 walter@1409.org ham:dg9ep@db0me koch@hsp.de From bem@cmc.net Thu May 25 21:39:15 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 14:39:15 -0700 Subject: Clearsigning (again) Message-ID: <20000525143915.B24700@cmc.net> I know there is very little in the RFC regarding clearsigning and that PGP-MIME is better. But Network Solutions wants clearsigned (and so do many Usenet readers since multipart MIME is evil on Usenet), so I need it to work properly. >From the fine man page: -t, --textmode Use canonical text mode. If -t (but not --textmode) is used together with armoring and signing, this enables clearsigned messages. This kludge is needed for PGP compatibility; normally you would use --sign or --clearsign to selected the type of the signature. But this doesn't wholly work. [thorin:~] 2:10:46pm 193 % echo foo | gpg -t --armor --sign You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 foo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5LZbaN3/OJIgyK1ERAm/3AJ99ETFfFOvIS+necd4awNO5S255EACghazh p9oyByxGr6xctlsQTU7C4zk= =myQV -----END PGP SIGNATURE----- The problem is that with PGP, the same sort of thing will have an empty line after the 'foo'. PGP5 will verify the above, but it will be missing the end of line: [thorin:~] 2:12:53pm 200 % ls -l foo -rw------- 1 bem bem 3 May 25 14:12 foo [thorin:~] 2:12:56pm 201 % od -x foo 0000000 6f66 006f 0000003 The trailing newline placed there by 'echo foo' (which emits 4 characters) is gone. Again, I realize that RFC2440 isn't clear at all about 'clearsigned' messages but I believe interoperability is important. How does the above behave with PGP6? If it behaves as PGP5 does, then I think gnupg needs to change. The relevant wording in 2440 I see is: The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. That seems to imply "insert an extra newline here when signing and discard it when you verify". There is also a problem in lines ending with TAB (which, alas, I know because NSI seems to send forms with TABs at the end of the line for reasons known only to them): [thorin:~] 2:15:13pm 211 % echo "foo " > foo # that's a tab [thorin:~] 2:15:14pm 212 % gpg -t --armor --sign foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 2:15:25pm 213 % pgpv foo.asc Opening file "foo" type text. BAD signature made 2000-05-25 21:15 GMT by key: 1024 bits, Key ID 88322B51, Created 1998-10-17 "brian moore " "brian moore " "brian moore " This seems to be contrary to RFC2440: Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Spaces at the end of the line -are- ignored correctly. But tabs are not. If there's consensus that these two things need fixing, I'll submit a patch, but so far I've had no response to these even being problems. :( Again, both of these are needed to work with Network Solutions, which is why it's annoying me. If I manually ":%s/^I$//", and insert a blank line at the end of my forms, yes, I can then submit them to NSI and have them verify, but that seems goofy. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem@cmc.net Thu May 25 22:08:29 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 15:08:29 -0700 Subject: Clearsigning (again) In-Reply-To: <20000525143915.B24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 02:39:15PM -0700 References: <20000525143915.B24700@cmc.net> Message-ID: <20000525150829.C24700@cmc.net> On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > This seems to be contrary to RFC2440: > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > any line is ignored when the cleartext signature is calculated. > > Spaces at the end of the line -are- ignored correctly. But tabs are > not. Ah, oddly enough I can make it do this -- but I have to specify '--rfc1991' to do it. It still strips the \n at the end, and I'm not sure why the --rfc1991 is needed, since RFC2440 requires it as well... -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem@cmc.net Thu May 25 22:36:45 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 15:36:45 -0700 Subject: Clearsigning (again) In-Reply-To: <20000525150829.C24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:08:29PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> Message-ID: <20000525153645.D24700@cmc.net> On Thu, May 25, 2000 at 03:08:29PM -0700, brian moore wrote: > On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > > > This seems to be contrary to RFC2440: > > > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > > any line is ignored when the cleartext signature is calculated. > > > > Spaces at the end of the line -are- ignored correctly. But tabs are > > not. > > Ah, oddly enough I can make it do this -- but I have to specify > '--rfc1991' to do it. > > It still strips the \n at the end, and I'm not sure why the --rfc1991 is > needed, since RFC2440 requires it as well... Continuing to follow up to myself... :) I see why. It's a bug of PGP5. If I manually strip the tab in the clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not recognizing that it should ignore trailing tabs on input. (And this isn't documented in the 'Implementation Notes' in 2440 with the other PGP5 bugs... Can someone on the IETF committee see that it makes it into future revisions? :)) But the dropping-the-trailing-newline doesn't require PGP5, so I'm still convinced this is solely a gnupg problem: [thorin:~] 3:34:15pm 288 % echo foo > foo [thorin:~] 3:34:20pm 289 % md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo [thorin:~] 3:34:27pm 290 % gpg -sat foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 3:34:44pm 291 % gpg foo.asc File `foo' exists. Overwrite (y/N)? y gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 gpg: Good signature from "brian moore " gpg: aka "brian moore " gpg: aka "brian moore " [thorin:~] 3:34:52pm 292 % md5sum foo 2145971cf82058b108229a3a2e3bff35 foo I still don't think gnupg should do that. :) -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From gqueri@mail.dotcom.fr Thu May 25 23:51:33 2000 From: gqueri@mail.dotcom.fr (Gael Queri) Date: Fri, 26 May 2000 01:51:33 +0200 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:36:23PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526015133.A308@baoule.ath.cx> Hello brian, sorry to interrupt your conversation with yourself :) On Thu, May 25, 2000 at 03:36:23PM -0700, brian moore wrote: > (...) > But the dropping-the-trailing-newline doesn't require PGP5, so I'm still > convinced this is solely a gnupg problem: > > [thorin:~] 3:34:15pm 288 % echo foo > foo > [thorin:~] 3:34:20pm 289 % md5sum foo > d3b07384d113edec49eaa6238ad5ff00 foo > [thorin:~] 3:34:27pm 290 % gpg -sat foo > > You need a passphrase to unlock the secret key for > user: "brian moore " > 1024-bit DSA key, ID 88322B51, created 1998-10-17 > > [thorin:~] 3:34:44pm 291 % gpg foo.asc > File `foo' exists. Overwrite (y/N)? y > gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 > gpg: Good signature from "brian moore " > gpg: aka "brian moore " > gpg: aka "brian moore " > [thorin:~] 3:34:52pm 292 % md5sum foo > 2145971cf82058b108229a3a2e3bff35 foo > > I still don't think gnupg should do that. :) It seems to be fixed in gnupg 1.0.1e, so you were at least not the only one to think that :-) gael@baoule:~$ echo foo > foo gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo gael@baoule:~$ gpg -sat foo gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! You need a passphrase to unlock the secret key for user: "Gael Queri " 1024-bit DSA key, ID 3E18F9CE, created 1997-09-01 gael@baoule:~$ gpg foo.asc gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! File `foo' exists. Overwrite (y/N)? y gpg: Signature made Fri May 26 01:38:48 2000 CEST using DSA key ID 3E18F9CE gpg: Good signature from "Gael Queri " gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo Regards, gael From sen_ml@eccosys.com Fri May 26 03:09:38 2000 From: sen_ml@eccosys.com (sen_ml@eccosys.com) Date: Fri, 26 May 2000 12:09:38 +0900 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net> References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526120938J.1001@eccosys.com> From: brian moore Subject: Re: Clearsigning (again) Date: Thu, 25 May 2000 15:36:45 -0700 Message-ID: <20000525153645.D24700@cmc.net> ... > Continuing to follow up to myself... :) > > I see why. It's a bug of PGP5. If I manually strip the tab in the > clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not > recognizing that it should ignore trailing tabs on input. (And this > isn't documented in the 'Implementation Notes' in 2440 with the other > PGP5 bugs... Can someone on the IETF committee see that it makes it into > future revisions? :)) information about the openpgp working group mailing list can be found at: http://www.imc.org/ietf-openpgp/ you could post the suggestion there. From rabbi@quickie.net Sat May 27 00:33:46 2000 From: rabbi@quickie.net (L. Sassaman) Date: Fri, 26 May 2000 17:33:46 -0700 (PDT) Subject: Subkeys In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get an "Unusable public key algorithm" error when I try to encrypt to keys that have additional encryption subkeys. Can we work through this so that GnuPG handles v4 keys with multiple subkeys in the same manner that PGP does? - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LxfxPYrxsgmsCmoRAvQ+AJ9GeC6rsYWb7HxeXnEVsCRYx9eVxgCgwqXl r3pOieMkJByCafQgUfydTiQ= =Hxpe -----END PGP SIGNATURE----- From bem@cmc.net Tue May 2 23:17:12 2000 From: bem@cmc.net (brian moore) Date: Tue, 2 May 2000 15:17:12 -0700 Subject: general compatibility with PGP... Message-ID: <20000502151712.K31948@cmc.net> This seems to fail: -------- This is a test file for GPG/PGP/OpenPGP compatibility. This line ends with a tab for no good reason: Thanks for the test. This file ends with a blank line. -------- The above file, once signed (with gpg --sign -a -t testfile, which is what the docs imply is the 'pgp compatibility hack'), will not verify with PGP5, and PGP5 will also strip the last blank line. Who is right on the reading of 'text mode' on this? Or should there be a '--broken-text-mode' flag to appease PGP5? It's sort of annoying since Network Solutions likes sending forms with lines ending in tabs and spaces (I dunno -why-, they just do!) and I have to be sure I do a ':%s/[ ^I]\+$//' before signing stuff and ensure I have an extra blank line at the end. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From nittka@esem.com Thu May 4 08:37:03 2000 From: nittka@esem.com (Oliver Nittka) Date: 04 May 2000 09:37:03 +0200 Subject: [mailing-lists.reiserfs] (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Message-ID: --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit this may become very important for all open-source-projects, so i'll forward it to this list. -- oly -- Oliver Nittka | nittka@esem.com ESEM Grünau GmbH & Co. KG | http://www.esem.com Dornierstraße 6 | phone: +49 7544 9583-25 88677 Markdorf / Germany | fax: +49 7544 9583-60 --=-=-= Content-Type: message/rfc822; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit From: Xuan Baldauf Subject: (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Date: Thu, 04 May 2000 00:23:53 +0200 Message-ID: <3910A6F9.705A11A7@exmail.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------AC179D27851ED6C2526ACC47" To: reiserfs@devlinux.com Mailing-List: contact reiserfs-help@devlinux.com; run by ezmlm This is a multi-part message in MIME format. --------------AC179D27851ED6C2526ACC47 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I'm sorry for spamming the majority of not german list readers, but for those who are, this might be very important: The European Union plans to accept software patents. SWPats will slow down open source development, because large software companies can afford patenting algorithms which are easy and obvious, along with others which are complicated and advanced. If ever a clever (kernel) hacker finds an algorithm for a specific problem, there will be a good chance that this algorithm is a patent infringement. For their economic interest, large software companies will sue (kernel) hackers, and because large software companies have much more money, (kernel) hackers will give up, and open-source development will handicapped, probably at large scale, because nobody wants to be sued only to be a good (kernel) hacker. The most prominent example is "the GIF patent", the gd library ( http://www.boutell.com/gd/ ) was forced to give up GIF support. If you are against this scarious development, which is already possible in the USA, but not in Europe, and if you are german, read the following. Thanks for reading although being offtopic. Xuân. --------------AC179D27851ED6C2526ACC47 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Disposition: inline Return-Path: Received: from localhost (root@localhost [127.0.0.1]) by router.abc (8.8.8/8.8.8) with ESMTP id XAA22039 for ; Wed, 3 May 2000 23:48:57 +0200 Delivered-To: exmail-de-kW@exmail.de Received: from pop1.exmail.de by localhost with POP3 (fetchmail-5.1.0) for root@localhost (single-drop); Wed, 03 May 2000 23:48:58 +0200 (CEST) Received: (qmail 8455 invoked by uid 409); 3 May 2000 21:48:27 -0000 Delivered-To: medium-net-kW@medium.net Received: (qmail 8452 invoked from network); 3 May 2000 21:48:26 -0000 Received: from robin.camelot.de (HELO mail.camelot.de) (root@195.30.224.3) by plato.exmail.de with SMTP; 3 May 2000 21:48:26 -0000 Received: from robin.camelot.de (daemon@robin.camelot.de [195.30.224.3]) by mail.camelot.de (8.9.3/8.9.3) with ESMTP id XAA39885; Wed, 3 May 2000 23:47:55 +0200 (CEST) Received: from localhost (daemon@localhost) by robin.camelot.de (8.9.3/8.9.3) with SMTP id XAA39877; Wed, 3 May 2000 23:47:55 +0200 (CEST) Received: by robin.camelot.de (CameloT blkmail v1.12); Wed, 3 May 2000 23:47:53 +0200 Received: from robin.camelot.de (majordom@robin.camelot.de [195.30.224.3]) by mail.camelot.de (8.9.3/8.9.3) with ESMTP id XAA39834 for ; Wed, 3 May 2000 23:47:52 +0200 (CEST) Received: (from majordom@localhost) by robin.camelot.de (8.9.3/8.9.3) id XAA39829 for a2e-de-ffii.outgoing; Wed, 3 May 2000 23:47:52 +0200 (CEST) Date: Wed, 3 May 2000 21:44:56 +0000 (/etc/localtime) From: PILCH Hartmut X-Sender: phm@wtao97.oas.a2e.de To: FFII-Nachrichten Subject: BMWi-Konferenz: So koennen Sie helfen Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.camelot.de id XAA39826 Sender: owner-a2e-de-ffii@camelot.de X-Mozilla-Status2: 00000000 Bitte weiterverbreiten! lynx -dump http://swpat.ffii.org/penmi/bmwi-20000518/ ---------------------------------------- Die wirtschaftlichen Auswirkungen der Software-Patentierung Das Bundeswirtschaftsministerium hält am 18. Mai 2000 in Berlin eine öffentliche Tagung ab, auf der die wirtschaftlichen Auswirkungen der Patentierbarkeit von Logikalien untersucht werden sollen. Der Förderverein für eine Freie Informationelle Infrastruktur und die [6]Förderer seiner [7]Softwarepatent-Arbeitsgruppe sind eingeladen. Wir werden uns an in dieser [8]Konferenz aktiv beteiligen. Der FFII wird gegen die Ausdehnung des Europäischen Patentwesens in immer industriefernere Sphären argumentieren. Diese Konferenz ist eine seltene Chance. Sie muss ein Erfolg für all diejenigen werden, die von informatischem Monopolismus nichts gutes zu erwarten haben. Sie können auf verschiedenerlei Weise dazu beitragen. Was Sie tun können * An der Konferenz teilnehmen Die Konferenz ist öffentlich, aber die Teilnehmer sollten sich vorher anmelden und beim Veranstalter eine kurzes Positionspapier abgeben. Setzen Sie sich dazu mit uns in Verbindung. Wir haben in Berlin auch ein paar Hotelbetten reserviert. * Weitere Teilnehmer werben Dies ist eine erste und vielleicht letzte Gelegenheit für Programmierer und Firmen, sich über schicksalsentscheidende Entwicklungen kundig zu machen und darauf einzuwirken. Bitte sprechen Sie Firmen und Personen in Ihrem Einflussbereich an. Bringen Sie sie u.U. in Kontakt mit uns, damit wir bei der Abfassung von Positionspapieren helfen und bei der Vorbereitung der Konferenz zusammenarbeiten können. * Dokumention zusammenstellen helfen Der FFII stellt eine [15]Dokumentation (gedruckt und auf CD) zusammen. Wir müssen viele Verlagshäuser um Kopiererlaubnis bitten und manche wichtigen Texte sind von nicht-digitalen Datenträgern her zu erfassen. Diese Arbeit wird von der Intevation GmbH im Auftrag des FFII über ein [16]öffentlich zugängliches Forum geleistet. Ihre Teilnahme ist sehr willkommen. Der FFII ist dank seiner Förderer in der glücklichen Lage, für geleistete Arbeit Entschädigungen auf Stundenbasis zahlen zu können. Hintergrund der Konferenz Die Europäischen Patentorganisationen und die EU-Kommission beseitigen derzeit alle gesetzlichen Hürden, die bisher noch der Patentierung von Logikalien (Software) im Wege stehen. Es ist das erste Mal, dass eine Regierungsorganisation in Europa die Frage nach den Auswirkungen dieser Veränderungen auf die Wirtschaft und das Gemeinwohl stellt. Die Bundesregierung ist Vertragsstaat des Europäischen Patentabkommens und muss als solche alle Änderungen dieses Abkommens genehmigen. Verweigert sie ihre Zustimmung, so werden "Programme für Datenverarbeitungsanlagen" weiterhin auf der Liste der Ausnahmen von der Patentierbarkeit in §52 EPÜ bleiben. Andernfalls wird der Weg für die volle Durchsetzung von Logikalienpatenten in Europa und Deutschland noch dieses Jahr frei. Der FFII befürchtet, dass Logikalienpatentierbarkeit zu proprietären Standards (d.h. Blockierung von Kompatibilität durch private Besitzansprüche) führt, Monopoltendenzen stärkt, die Erneuerungskräfte hemmt und insbesondere kleine und mittlere Softwarefirmen gefährdet. In wenigen Monaten könnte eine lange angestaute Lawine von Drohbriefen und Patentprozessen über uns hereinbrechen, und Sie werden vielleicht sich daran gewöhnen müssen, einen Patentanwalt aufzusuchen, bevor Sie ihre Programm-Quelltexte im Netz veröffentlichen. Es wird dann sicherlich zu spät sein, irgendetwas dagegen zu tun. Handeln wir also jetzt. Machen wir die Berliner Konferenz zu einem großen Erfolg. Unterzeichner Markus Fleck Joerg Freudenberger Hartmut Pilch Bernhard Reiter Arnim Rupp _________________________________________________________________ http://swpat.ffii.org/penmi/bmwi-20000518/indexde.html 2000-05-03 PILCH Hartmut Verweise 6. http://swpat.ffii.org/sarji/ 7. http://swpat.ffii.org/ag/ 8. http://www.sicherheit-im-internet.de/news/news.php3?id=125 15. http://swpat.ffii.org/links/doku/ 16. http://ffii.org/mailman/listinfo/swpatdoku/ --------------AC179D27851ED6C2526ACC47-- --=-=-=-- From Klaus Singvogel Tue May 9 16:35:46 2000 From: Klaus Singvogel (Klaus Singvogel) Date: Tue, 9 May 2000 17:35:46 +0200 Subject: Patch: FAQ Message-ID: <20000509173546.A15460@Caldera.DE> Even the patch for the FAQ describes it now correct, I can't decrypt such a GnuPG generated message with PGP V2.6.3ii I'll investigate it and tell you more AFAIK more. Regards, Klaus. --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 @@ -123,7 +123,7 @@ supported by GnuPG because it is patented, but if you have a modified version of PGP you can try this: - gpg --rfc1991 --cipher-algo 3des ... + gpg --rfc1991 --cipher-algo idea ... Please don't pipe the data to encrypt to gpg but give it as a filename; other wise, pgp 2 will not be able to handle it. From wk@gnupg.org Tue May 9 18:29:22 2000 From: wk@gnupg.org (Werner Koch) Date: Tue, 9 May 2000 19:29:22 +0200 Subject: Patch: FAQ In-Reply-To: <20000509173546.A15460@Caldera.DE>; from ks@caldera.de on Tue, May 09, 2000 at 05:35:46PM +0200 References: <20000509173546.A15460@Caldera.DE> Message-ID: <20000509192922.C4283@djebel.gnupg.de> On Tue, 9 May 2000, Klaus Singvogel wrote: > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > @@ -123,7 +123,7 @@ > supported by GnuPG because it is patented, but if you have a modified > version of PGP you can try this: > > - gpg --rfc1991 --cipher-algo 3des ... > + gpg --rfc1991 --cipher-algo idea ... Watch out for the "...modified version of PGP .." - I assume that this is will be a 3DES one ;-). The GNU project does not support patented algorithms and therefore you won't read IDEA in it :-). Yes, I know that there are some countries where there is no valid patent on IDEA. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From Klaus Singvogel Wed May 10 10:57:09 2000 From: Klaus Singvogel (Klaus Singvogel) Date: Wed, 10 May 2000 11:57:09 +0200 Subject: Patch: FAQ In-Reply-To: <20000509192922.C4283@djebel.gnupg.de>; from wk@gnupg.org on Tue, May 09, 2000 at 07:29:22PM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> Message-ID: <20000510115709.A30043@Caldera.DE> On Tue, May 09, 2000 at 07:29:22PM +0200, Werner Koch wrote: > On Tue, 9 May 2000, Klaus Singvogel wrote: > > > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > > @@ -123,7 +123,7 @@ > > supported by GnuPG because it is patented, but if you have a modified > > version of PGP you can try this: > > > > - gpg --rfc1991 --cipher-algo 3des ... > > + gpg --rfc1991 --cipher-algo idea ... > > Watch out for the "...modified version of PGP .." - I assume that this > is will be a 3DES one ;-). The GNU project does not support patented > algorithms and therefore you won't read IDEA in it :-). Yes, I know > that there are some countries where there is no valid patent on IDEA. Sorry, but the FAQ speaks at this point of encryption for pgp 2.x Yes, you have to have a modified version GnuPG, but you have to use the (patented) idea algorithmen as cipher algorithmen too (and not 3des). Thats what I correct in the FAQ. I know, you can use 3des to make GnuPG encrypted messages readable for pgp 5.x or 6.x users. But that's not the point the FAQ speaks here of. Another point: I build a modified version of GnuPG: I built the idea/rsa modules, added the "load-extension idea" "load-extension rsa" lines to my .gnupg/options, and check with "strace" if the modules where used/opened (they were :-) But still I can't encrypt a message with GnuPG 1.0.1 (rsa 1.10 and idea 1.11) for a pgp-2.6.3ii user (myself). I get the error message Error: Decrypted plaintext is corrupted. If I look into the source-code I see that the error comes from the idea decryption. I currently investigate this. My current assumption is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does decryption in CBC mode. But I'm not sure, since I don't understand the idea.c completly yet. I'll tell you more, if I find the error. Regards, Klaus. -- .-. | Klaus Singvogel oo| | Caldera (Deutschland) GmbH, Naegelsbachstr. 49c, 91052 Erlangen /`'\ | email: ks@caldera.de internet: http://www.caldera.de (\_;/) | phone: ++49 9131 7192-300 fax: ++49 9131 7192-399 From az096@freenet.toronto.on.ca Wed May 10 13:13:13 2000 From: az096@freenet.toronto.on.ca (Robert Guerra) Date: Wed, 10 May 2000 08:13:13 -0400 Subject: Fwd:ANNOUNCEMENT: PGP Desktop Security 7.0 Message-ID: I'm sending this along in case people on here may have not seen it before. on first reading it looks like pgp (from NAI) is slowly morphing into a larger and larger beast. I hope that the folks from NAI follow the openpgp specs as they should so the new client can be as compatible as possible with gnupg. time will tell.. regards robert --- begin forwarded text Date: Tue, 09 May 2000 10:43:33 -0700 From: Will Price Subject: [PGP-USERS] ANNOUNCEMENT: PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today, we officially announced PGP Desktop Security 7.0. Here is the press release: http://biz.yahoo.com/prnews/000509/nv_neta_pg_1.html The beta program (which is already almost completely filled, so please don't ask) will begin this month and you should see the final version in early Q3. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 165 Alpha) iQA/AwUBORhOH6y7FkvPc+xMEQKvDwCguLKbVGyrUeevvP9hNGtem9ZKaGAAn2+B O8b6AFDrrbVt8A53oxED6IEy =OBdf -----END PGP SIGNATURE----- ..................................................................... Unsubscribe: Automated Help/Info: List Homepage: List Admin (human): Please do not send administrative commands to the list address! Thanks. --- end forwarded text -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From wk@gnupg.org Wed May 10 15:24:13 2000 From: wk@gnupg.org (Werner Koch) Date: Wed, 10 May 2000 16:24:13 +0200 Subject: Patch: FAQ In-Reply-To: <20000510115709.A30043@Caldera.DE>; from ks@caldera.de on Wed, May 10, 2000 at 11:57:09AM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> <20000510115709.A30043@Caldera.DE> Message-ID: <20000510162413.L7032@djebel.gnupg.de> On Wed, 10 May 2000, Klaus Singvogel wrote: > use the (patented) idea algorithmen as cipher algorithmen too (and > not 3des). Thats what I correct in the FAQ. If you look at the PGP 2 data formats (e.g. rfc1991) you will notice that there is indeed an algorithm indetifier and therefore it is possible to replace IDEA by 3DES (or better CAST5 which uses the same keysize and can be done very easily). Please read the GPL before _distributing_ GnuPG together with a module which implements a patented algorithm; doing so might vilolate the GPL. > If I look into the source-code I see that the error comes from the > idea decryption. I currently investigate this. My current assumption > is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does > decryption in CBC mode. But I'm not sure, since I don't understand Nope. The cipher modules are the low level encryption. The chaining is done in cipher/cipher.c and the same for all symmetric ciphers. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Wed May 10 21:08:08 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 10 May 2000 21:08:08 +0100 Subject: Solaris random device Message-ID: <20000510210808.A9104@tehran.nmrc.ucc.ie> Hi all, I just subscribed here, because the problem I'm facing now is probably not appropriate for -users ... After openssh failed when I upgraded to Solaris 8, I was looking for an alternative to egd and found Andreas Maier's random device for Solaris (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with openssl/openssh. I can generate keys, make connections, no problem. I'm now trying to use the random device with gpg, but it doesn't work. $ ./configure --prefix=$HOME --disable-nls --enable-static-rnd=linux (don't now if --enable-static-rnd=linux necessary - it doesn't make a difference if I leave this out) ... checking for random device... yes checking for linux/random.h... no checking for random device ioctl... no ... $ make check ... gpg (GnuPG) 1.0.1e Copyright (C) 2000 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: . Supported algorithms: Cipher: 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160, TIGER PASS: version.test PASS: mds.test PASS: decrypt.test PASS: decrypt-dsa.test and there it seems to hang. I'm attaching truss to the running copy of gpg and get ... poll(0xFFBED588, 1, 3000) Err#6 ENXIO write(2, " s e l e c t ( ) e r r".., 16) = 16 write(2, " N o s u c h d e v i".., 25) = 25 write(2, "\n", 1) = 1 [repeats over and over] Any suggestions? Is it possible that the current code is too Linux/BSD specific? Thanks. From Nils@infosun.fmi.uni-passau.de Thu May 11 08:53:28 2000 From: Nils@infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Thu, 11 May 2000 09:53:28 +0200 (MEST) Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie> References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> >>>"LH" == Lars Hecking writes: LH> After openssh failed when I upgraded to Solaris 8, I was looking for an LH> alternative to egd and found Andreas Maier's random device for Solaris LH> (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with LH> openssl/openssh. I can generate keys, make connections, no problem. I don't know about Andi Maier's device, but egd has been updated to work with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several weeks by now. Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From wk@gnupg.org Thu May 11 09:41:04 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 10:41:04 +0200 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511104104.A7032@djebel.gnupg.de> On Wed, 10 May 2000, Lars Hecking wrote: > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. IIRC, gpg checks that it is a character device - maybe the Solaris /dev/random is implemented as another type of device. (Patches are welcome) Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From listmaster@gnupg.org Thu May 11 10:19:14 2000 From: listmaster@gnupg.org (Lord of the Lists) Date: Thu, 11 May 2000 11:19:14 +0200 Subject: external keystore option? Message-ID: <20000511111914.I7032@djebel.gnupg.de> ----- Forwarded message from "Mikolaj J. Habryn" ----- Date: Thu, 11 May 2000 10:58:59 +0200 From: "Mikolaj J. Habryn" To: gnupg-devel@gnupg.org Subject: external keystore option? X-Diagnostic: Mail coming from a daemon, ignored Are there any plans for or opinions on the possibility of separating out the sensitive key management operations in gnupg (along the lines of ssh-agent for ssh)? I had a dig through the archives (a while ago), and recall seeing the subject come up once, but with no definitive resolution. I would like to see such functionality in gnupg; there are certain situations (such as Debian package creation) where a flexible policy engine would save a fair bit of passphrase retyping. My reason for asking is not purely academic; I recently published keymgr, an application designed to serve this purpose, whose only real claims to fame at present are a pretense to modularity and enough functionality to allow one to keep one's ssh keys on a Java ring. I've cobbled together enough code fragments to probably allow it to fake the desired effect by using a wrapper for gpg along with --passphrase-fd option (and obviously tracking passphrases in keymgr), but it's something of a suboptimal solution. m. ----- End forwarded message ----- -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From wk@gnupg.org Thu May 11 10:42:44 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 11:42:44 +0200 Subject: external keystore option? In-Reply-To: <20000511111914.I7032@djebel.gnupg.de>; from listmaster@gnupg.org on Thu, May 11, 2000 at 11:19:14AM +0200 References: <20000511111914.I7032@djebel.gnupg.de> Message-ID: <20000511114244.M7032@djebel.gnupg.de> On Thu, 11 May 2000, Lord of the Lists wrote: > ----- Forwarded message from "Mikolaj J. Habryn" ----- > Are there any plans for or opinions on the possibility of separating > out the sensitive key management operations in gnupg (along the lines > of ssh-agent for ssh)? I had a dig through the archives (a while ago), > and recall seeing the subject come up once, but with no definitive > resolution. This is scheduled for 1.1 but due to all the remaining work on 1.0 it will take some more time to start with it. I'd would very much appreciate help for GnuPG from volunteers who can sign an copyright assignment for the FSF. Without that legal paper I have to review all the pacthes and look at the idea only :-( > My reason for asking is not purely academic; I recently published > keymgr, an application designed to serve this purpose, whose only real > claims to fame at present are a pretense to modularity and enough > functionality to allow one to keep one's ssh keys on a Java ring. BTW, Brian Warner did some experiments with a PalmPilot and sent me the outline for a protocol to be used between the decryption/signing engine on some device and gpg. However, I have not yet found the time to work on it and franky I can't find it right now in my mail archives :-( Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Thu May 11 10:47:43 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 10:47:43 +0100 Subject: Solaris random device In-Reply-To: <20000511104104.A7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 10:41:04AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511104104.A7032@djebel.gnupg.de> Message-ID: <20000511104743.A10797@tehran.nmrc.ucc.ie> Werner Koch writes: > On Wed, 10 May 2000, Lars Hecking wrote: > > > alternative to egd and found Andreas Maier's random device for Solaris > > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > > openssl/openssh. I can generate keys, make connections, no problem. > > IIRC, gpg checks that it is a character device - maybe the Solaris > /dev/random is implemented as another type of device. $ cd /devices/pseudo $ ll r* crw-r--r-- 1 root sys 65, 0 May 10 01:21 random@0:random crw-r--r-- 1 root sys 65, 1 May 10 01:21 random@0:urandom $ From dichro-gnupg-devel@rcpt.to Thu May 11 11:11:14 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 11 May 2000 20:11:14 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 11:42:44 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> I'd would very much appreciate help for GnuPG from volunteers WK> who can sign an copyright assignment for the FSF. Without WK> that legal paper I have to review all the pacthes and look at WK> the idea only :-( This won't be a problem, but I'll save it for if and when I come up with something worthwhile to contribute. WK> BTW, Brian Warner did some experiments with a PalmPilot and WK> sent me the outline for a protocol to be used between the WK> decryption/signing engine on some device and gpg. However, I WK> have not yet found the time to work on it and franky I can't WK> find it right now in my mail archives :-( Hmm, okay. Failing that, my intent was to gin up a simple text based protocol to run over Unix sockets, with operations like DECRYPT ( list of valid keys ) cyphertext I presume here that gpg will know what keys can decrypt a message (by fingerprint? id? full public key? How are they identified in the message?), but won't know which ones are available. ENCRYPT key plaintext Which does the obvious thing. Would this cover the gamut of what gpg does with private keys? I am also presuming that the keystore would acquire the keys by means outside this protocol. m. From wk@gnupg.org Thu May 11 11:50:53 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 12:50:53 +0200 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:11:14PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: <20000511125053.O7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm, okay. Failing that, my intent was to gin up a simple text based > protocol to run over Unix sockets, with operations like Okay. > DECRYPT ( list of valid keys ) cyphertext > > I presume here that gpg will know what keys can decrypt a message > (by fingerprint? id? full public key? How are they identified in the > message?), but won't know which ones are available. The needed key is identified by the 64 bit KeyID. There is an option for a wildcard KeyID in which case gpg tries each available secret key in turn. > ENCRYPT key plaintext > > Which does the obvious thing. Would this cover the gamut of what gpg > does with private keys? I am also presuming that the keystore would You don't need the secret key for encryption - I guess you are thinking of signing a message. Such an agent should take care of all operations where the secret key is involved and leve all other crypto operations to normal program. The goal of such a agent should be to better protect the secret key. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From bofh@eris.phys.uni.torun.pl Thu May 11 12:55:37 2000 From: bofh@eris.phys.uni.torun.pl (Janusz A. Urbanowicz) Date: Thu, 11 May 2000 13:55:37 +0200 (CEST) Subject: external keystore option? In-Reply-To: <20000511114244.M7032@djebel.gnupg.de> from Werner Koch at "May 11, 2000 11:42:44 am" Message-ID: Werner Koch wrote/napisa³[a]: > On Thu, 11 May 2000, Lord of the Lists wrote: > > My reason for asking is not purely academic; I recently published > > keymgr, an application designed to serve this purpose, whose only real > > claims to fame at present are a pretense to modularity and enough > > functionality to allow one to keep one's ssh keys on a Java ring. > > BTW, Brian Warner did some experiments with a PalmPilot and sent me > the outline for a protocol to be used between the decryption/signing > engine on some device and gpg. However, I have not yet found the time > to work on it and franky I can't find it right now in my mail archives :-( I'd be very interested in it (as a fresh owner of brand-new Palm Vx) and also in paricipating. I've already thought of implementing something along the lines of using Palm as crypto token/engine working over IRDA/serial link. alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From dichro-gnupg-devel@rcpt.to Thu May 11 11:59:57 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 11 May 2000 20:59:57 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 12:50:53 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> The needed key is identified by the 64 bit KeyID. There is an WK> option for a wildcard KeyID in which case gpg tries each WK> available secret key in turn. Hmm. How can one tell if one has found the right key? Magic in the plaintext? WK> You don't need the secret key for encryption - I guess you are WK> thinking of signing a message. Yep, or things like signing keys. I presume that in both cases (and any others?), gpg builds some kind of value which needs to be encrypted with the secret key and returned (?). I guess the question boils down to - are there any operations that gpg performs with a secret key that can't be transformed into an encryption/decryption with some independent munging of data formats on either side of it? m. From wk@gnupg.org Thu May 11 13:08:10 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 14:08:10 +0200 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:59:57PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: <20000511140810.R7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm. How can one tell if one has found the right key? Magic in the > plaintext? Quite simple: Without the correct key you get only garbled plaintext - this is easy to detect because the plaintext (actually the encrypted session key) has some special format and a checksum. > Yep, or things like signing keys. I presume that in both cases (and All signing operations. > secret key that can't be transformed into an encryption/decryption A secret key is only needed for this: a) decryption b) signing Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From apommer@cosy.sbg.ac.at Thu May 11 14:04:11 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Thu, 11 May 2000 15:04:11 +0200 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511150411.H32456@cosy.sbg.ac.at> On May 10, Lars Hecking wrote: [..] > After openssh failed when I upgraded to Solaris 8, I was looking for an > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. [...] > poll(0xFFBED588, 1, 3000) Err#6 ENXIO > write(2, " s e l e c t ( ) e r r".., 16) = 16 > write(2, " N o s u c h d e v i".., 25) = 25 > write(2, "\n", 1) = 1 > [repeats over and over] > > Any suggestions? Is it possible that the current code is too Linux/BSD > specific? the problem occurs in rndlinux.c gather_random() at the select() in line 128: if( !(rc=select(fd+1, &rfds, NULL, NULL, &tv)) ) { this select() translates into poll(), which can be seen in the truss-dump above. However, in the source of Andis random device one can read: * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE [..] * -) /dev/random and /dev/urandom are the same (no blocking). * -) No ioctls, no poll. * * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE That seems to be the answer. One possible solution would be to skip the select() if the fact is known that the device does not block. Another one would be to improve the random device (remember, still V0.1), to provide a dummy-poll which succeeds every time. HTH Andreas From wk@gnupg.org Thu May 11 15:19:02 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 16:19:02 +0200 Subject: Solaris random device In-Reply-To: <20000511150411.H32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 03:04:11PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> Message-ID: <20000511161902.Y7032@djebel.gnupg.de> On Thu, 11 May 2000, Andreas Pommer wrote: > That seems to be the answer. One possible solution would be to skip the > select() if the fact is known that the device does not block. We can't do that because we should be somewhat sure about how much entropy we got. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Thu May 11 15:05:40 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 15:05:40 +0100 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511150540.A12177@tehran.nmrc.ucc.ie> Werner Koch writes: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. As the author has invited comments and suggestions, I have forwarded Andreas P's reply. From lhecking@nmrc.ucc.ie Thu May 11 16:18:07 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 16:18:07 +0100 Subject: Solaris random device In-Reply-To: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de>; from Nils@infosun.fmi.uni-passau.de on Thu, May 11, 2000 at 09:53:28AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> Message-ID: <20000511161807.A12368@tehran.nmrc.ucc.ie> > I don't know about Andi Maier's device, but egd has been updated to work > with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by > ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't > annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several > weeks by now. Unfortunately, I am totally unable to ftp to ftp.lothar.com. Anon login is ok, but anything beyond that times out. From apommer@cosy.sbg.ac.at Thu May 11 18:01:00 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Thu, 11 May 2000 19:01:00 +0200 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511190100.N32456@cosy.sbg.ac.at> On May 11, Werner Koch wrote: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. So we used to other option and now there is an improved version of the sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ It now cooperates with gpg - at least the 'make check' does not fail or hang. Andreas From lhecking@nmrc.ucc.ie Fri May 12 23:14:04 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Fri, 12 May 2000 23:14:04 +0100 Subject: Solaris random device In-Reply-To: <20000511190100.N32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 07:01:00PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> Message-ID: <20000512231404.A10088@tehran.nmrc.ucc.ie> > So we used to other option and now there is an improved version of the > sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ > It now cooperates with gpg - at least the 'make check' does not fail or hang. Yep. Works fine now on both Solaris 7 and 8. But still, I'd like to hear some good arguments for using this device at all. I am basically unclued about crypto, but I understand that a "good" random source is instrumental. From a user perspective, is the Solaris device appropriate? Is there a danger of creating weakly encrypted files with it? Thanks a lot for being so helpful, guys, I really appreciate it! (Ok with me if you want to move this discussion over to -users) From dichro-gnupg-devel@rcpt.to Sat May 13 08:03:29 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 13 May 2000 17:03:29 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 14:08:10 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: How does the following sound? Trying to trace operation flows through the code is a little confusing, so I'm probably way off base :( There appear to be two basic parts to this - firstly, gnupg needs to find out what keys are available, and secondly, it needs to use them. Using them appears to be the province of cipher/pubkey.c. Let's assume that gnupg has found out what keys the agent has, and is now trying to perform some kind of operation with them. My first thought was to somehow overload pubkey_table so that it would have two entries for each algorithm - one as is, and one which references functions which communicate with the agent for operations. This would require minor changes to all the functions that walk pubkey_table to not bomb if the first algorithm match fails, and also hook into the dynamic module loading code to add the duplicate agent entry for each loaded module, which could be messy. Alternatively, we can assume that when gnupg is fed the agent's keys, it will receive something bogus for the secret key. When it tries to do something useful with it, it will bomb with a recognizable error (G10ERR_BAD_MPI spring to mind). We could change all the wrapper functions to note this error and repeat the request to the agent to see if it will do any better. I couldn't find any way of changing the functions called on a key by key basis, only algorithm by algorithm. Did I miss anything? g10/ringedit.c appears to be a good place to start teaching gnupg about the agent. One could define a new keyring type (rt_AGENT), and hook it appropriately in the following functions. I'm basically looking to see where rt_GDBM is special cased, and trying to work out what the corresponding operations would be for an agent. o add_keyblock_resource - simple enough, establish a connection to the agent, cache the socket fd. o search - seemingly simple, but there's some questions in my mind. The rt_GDBM case generates a fingerprint from the public key in the packet passed as an argument to the function, and uses that as a key. But... there's some functions, like find_keyblock_bysk, that (judging from the name) might not have a public key as part of the request. Why is it safe for rt_GDBM to assume that it will be there? A comment later in the code suggests that the search interface is used preparatory to doing modifications to the keystore - is it /only/ used for this? ie, assuming that gnupg isn't going to have control over the agent, can implementing the search operation be skipped? The second part of this question is where does the public key initially come from, if not search? Which ties in to... o enum_keyblocks - am I correct in guessing that this is the interface used for populating gnupg's idea of what keys are available for it to use? I'm getting a little bit lost in all the various packet types, but here's the idea floating uppermost in my mind: If enum_keyblocks is indeed what is called as the first contact with a keystore, can I get away with simply populating the KBNODE(?) with a full public key and a bogus secret key (assuming the second option for using the key that I mentioned above)? This would mean that for all uses of this key that don't directly use the secret key, enum_keyblocks would already have all of the required data to handle them. Sorry if this is as confused as I am :) m. From apommer@cosy.sbg.ac.at Sat May 13 09:59:24 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Sat, 13 May 2000 10:59:24 +0200 Subject: Solaris random device In-Reply-To: <20000512231404.A10088@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Fri, May 12, 2000 at 11:14:04PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> Message-ID: <20000513105924.S32456@cosy.sbg.ac.at> On May 12, Lars Hecking wrote: [..] > But still, I'd like to hear some good arguments for using this device > at all. I am basically unclued about crypto, but I understand that a > "good" random source is instrumental. From a user perspective, is the > Solaris device appropriate? Is there a danger of creating weakly encrypted > files with it? Currently it is more similar to the linux /dev/urandom , less to /dev/random. At every call to the device some entropy is added (from a high resolution timer, and sometimes process id) and subsequently mangled by some hash algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. The solaris kstat interface provides access to a large number of kernel counters which can be used for that purpose. However, the "good" ones have to be determined. > Thanks a lot for being so helpful, guys, I really appreciate it! > (Ok with me if you want to move this discussion over to -users) I didn't subscribe to users, maybe I should ... Andreas From Enzo Michelangeli" <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> Message-ID: <00f101bfbcd5$f327f000$16006598@asiainter.net> ----- Original Message ----- From: "Andreas Pommer" To: Sent: Saturday, May 13, 2000 16:59 Subject: Re: Solaris random device [...] > Currently it is more similar to the linux /dev/urandom , less to /dev/random. > At every call to the device some entropy is added (from a high resolution > timer, and sometimes process id) and subsequently mangled by some hash > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > The solaris kstat interface provides access to a large number of kernel > counters which can be used for that purpose. However, the "good" ones > have to be determined. Why? Just toss everything into the pool: the total entropy cannot be reduced by adding low-entropy data. The more, the merrier. Cheers -- Enzo From dichro-gnupg-devel@rcpt.to Tue May 16 10:31:06 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 16 May 2000 19:31:06 +1000 Subject: external keystore option? In-Reply-To: "Mikolaj J. Habryn"'s message of "13 May 2000 17:03:29 +1000" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: --=-=-= >>>>> "MJH" == Mikolaj J Habryn writes: MJH> A comment later in the code suggests that the search MJH> interface is used preparatory to doing modifications to the MJH> keystore - is it /only/ used for this? To answer my own question, this does indeed appear to be the case. I've attached a patch which implements some basic agent support for gnupg. Using this and a modified keymgr, I've managed to sign/verify, and encrypt/decrypt a file using the ssh key I keep on my Java iButton. This is how I get my kicks. Observations. The exercise was a little bit gruesome. The keys that originate with the agent are marked with an is_protected of 23, and check_secret_key adjusted to not try to checksum them. In addition, the pubkey_decrypt and pubkey_sign methods look to see if the secret MPI fields are NULL, and redirect the query to the agent if so. This is suboptimal, but by the time we hit those queries, we've lost all the other information about the key. Just FYI. m. --=-=-= Content-Disposition: attachment; filename=gnupg-diff Content-Description: agent diff for gnupg diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/cipher/pubkey.c gnupg-work/cipher/pubkey.c --- gnupg-1.0.1-orig/cipher/pubkey.c Fri Jul 23 22:02:52 1999 +++ gnupg-work/cipher/pubkey.c Tue May 16 18:51:47 2000 @@ -492,6 +492,9 @@ log_mpidump(" data:", data[i] ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, result, *data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { @@ -526,6 +529,9 @@ log_mpidump(" data:", data ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, resarr, data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/Makefile.am gnupg-work/g10/Makefile.am --- gnupg-1.0.1-orig/g10/Makefile.am Sun Oct 10 03:23:41 1999 +++ gnupg-work/g10/Makefile.am Tue May 16 15:58:39 2000 @@ -57,6 +57,7 @@ keylist.c \ sig-check.c \ signal.c \ + agent.c \ helptext.c gpg_SOURCES = g10.c \ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.c gnupg-work/g10/agent.c --- gnupg-1.0.1-orig/g10/agent.c Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.c Tue May 16 19:00:55 2000 @@ -0,0 +1,214 @@ +#include +#include +#ifndef UNIX_PATH_MAX +#define UNIX_PATH_MAX 63 +#endif +#include +#include +#include +#include +#include + +#include "config.h" +#include "keydb.h" +#include "errors.h" +#include "packet.h" + +static int agent_socket; + +static unsigned char *hextable = NULL; + +int agent_connect(char *path) { + struct sockaddr_un sun; + + sun.sun_family = AF_LOCAL; + strncpy(sun.sun_path, path, UNIX_PATH_MAX - 1); + + agent_socket = socket(PF_LOCAL, SOCK_STREAM, 0); + if(agent_socket < 0) + return G10ERR_NETWORK; + if(connect(agent_socket, &sun, sizeof(sun))) + return G10ERR_OPEN_FILE; + return 0; +} + +int agent_read(void *buf, int len) { + return read(agent_socket, buf, len); +} + +int agent_write(void *buf, int len) { + return write(agent_socket, buf, len); +} + +int agent_enum(KBPOS *kbpos, KBNODE *ret_root) { + char buf[600], *ptr, *end; + int len = 0, i, algo; + PKT_public_key *p; + PKT_secret_key *s; + PKT_user_id *u; + PACKET *t; + + snprintf(buf, 599, "ENUMERATE %ld\r\n", kbpos->offset++); + if(agent_write(buf, strlen(buf)) != strlen(buf)) + return G10ERR_NETWORK; + do { + int ret; + + ret = agent_read(buf + len, 600 - len); + if(ret < 0) + return G10ERR_NETWORK; + len += ret; + if(len < 2) + continue; + if(buf[len - 1] == '\n' && + buf[len - 2] == '\r') + break; + } while(len < 600); + if(len == 2) + return -1; + ptr = memchr(buf, ' ', len); + if(!ptr) + return G10ERR_BAD_PUBKEY; + *ptr++ = 0; + len -= ptr - buf; + algo = string_to_pubkey_algo(buf); + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_BAD_PUBKEY; + *end++ = 0; + len -= end - ptr; + ptr = end; + p = m_alloc_clear(sizeof(*p)); + s = m_alloc_clear(sizeof(*s)); + p->pubkey_algo = algo; + s->pubkey_algo = algo; + for(i = 0; i < pubkey_get_npkey(algo); i++) { + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_NETWORK; /* leaking MPIs! */ + *end++ = 0; + len -= end - ptr; + p->pkey[i] = mpi_alloc(0); + mpi_fromstr(p->pkey[i], ptr); + s->skey[i] = mpi_copy(p->pkey[i]); + ptr = end; + } + s->is_protected = 23; + + end = memchr(ptr, '\r', len); + *end = 0; + u = m_alloc_clear(sizeof(*u) + strlen(ptr)); + u->len = strlen(ptr); + strcpy(u->name, ptr); + + t = m_alloc_clear(sizeof(*t)); + if(kbpos->secret) { + t->pkttype = PKT_SECRET_KEY; + t->pkt.secret_key = s; + } else { + t->pkttype = PKT_PUBLIC_KEY; + t->pkt.public_key = p; + } + *ret_root = new_kbnode(t); + + t = m_alloc_clear(sizeof(*t)); + t->pkttype = PKT_USER_ID; + t->pkt.user_id = u; + add_kbnode(*ret_root, new_kbnode(t)); + + return 0; +} + +unsigned char kmsl_nybble_char(unsigned char c) { + switch(c) { + case 0: + return '0'; + case 1: + return '1'; + case 2: + return '2'; + case 3: + return '3'; + case 4: + return '4'; + case 5: + return '5'; + case 6: + return '6'; + case 7: + return '7'; + case 8: + return '8'; + case 9: + return '9'; + case 0xa: + return 'a'; + case 0xb: + return 'b'; + case 0xc: + return 'c'; + case 0xd: + return 'd'; + case 0xe: + return 'e'; + case 0xf: + return 'f'; + default: + return 0xff; + } +} + +void kmsl_genhextable() { + int i; + + hextable = malloc(512); + for(i = 0; i < 256; i++) { + hextable[i * 2] = kmsl_nybble_char(i >> 4); + hextable[i * 2 + 1] = kmsl_nybble_char(i & 0xf); + } +} + +unsigned char *kmsl_byte_str(unsigned char c) { + if(!hextable) + kmsl_genhextable(); + return hextable + 2 * c; +} + +void agent_write_mpi(MPI m) { + int len, j, textlen; + unsigned char *text, *buf = mpi_get_buffer(m, &len, NULL); + + agent_write("0x", 2); + textlen = len * 2; + text = alloca(textlen); + for(j = 0; j < len; j++) + memcpy(text + j * 2, kmsl_byte_str(buf[j]), 2); + agent_write(text, textlen); + free(buf); +} + +int agent_process(int algo, MPI *ret, MPI data, MPI *skey) { + char *end, buf[2000], *alg = pubkey_algo_to_string(algo); + int i, r; + + agent_write("PROCESS ", 8); + agent_write(alg, strlen(alg)); + agent_write(" ", 1); + for(i = 0; i < pubkey_get_npkey(algo); i++) { + agent_write_mpi(skey[i]); + agent_write(" ", 1); + } + agent_write_mpi(data); + agent_write("\r\n", 2); + r = agent_read(buf, 2000); + end = memchr(buf, '\r', r - 1); + if(*(end + 1) != '\n') + return G10ERR_NETWORK; /* laziness */ + *end = 0; + r -= 2; + if(!r) + return G10ERR_UNEXPECTED; + *ret = mpi_alloc(0); + mpi_fromstr(*ret, buf); + return 0; +} diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.h gnupg-work/g10/agent.h --- gnupg-1.0.1-orig/g10/agent.h Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.h Tue May 16 17:35:37 2000 @@ -0,0 +1,11 @@ +#ifdef WITH_AGENT + +#include "keydb.h" + +int agent_connect(char *); +int agent_read(void *, int); +int agent_write(void *, int); +int agent_enum(KBPOS *, KBNODE *); +int agent_process(int, MPI *, MPI, MPI *); + +#endif /* WITH_AGENT */ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/keydb.h gnupg-work/g10/keydb.h --- gnupg-1.0.1-orig/g10/keydb.h Fri Nov 12 23:49:28 1999 +++ gnupg-work/g10/keydb.h Fri May 12 14:18:09 2000 @@ -58,7 +58,10 @@ enum resource_type { rt_UNKNOWN = 0, rt_RING = 1, - rt_GDBM = 2 + rt_GDBM = 2, +#ifdef WITH_AGENT + rt_AGENT = 3, +#endif }; diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/ringedit.c gnupg-work/g10/ringedit.c --- gnupg-1.0.1-orig/g10/ringedit.c Fri Dec 3 03:30:31 1999 +++ gnupg-work/g10/ringedit.c Tue May 16 16:04:41 2000 @@ -61,7 +61,7 @@ #include "options.h" #include "main.h" #include "i18n.h" - +#include "agent.h" @@ -102,7 +102,6 @@ static int do_gdbm_enum( KBPOS *kbpos, KBNODE *ret_root ); #endif - static RESTBL * check_pos( KBPOS *kbpos ) { @@ -215,6 +214,12 @@ rt = rt_GDBM; resname += 11; } +#ifdef WITH_AGENT + else if(strlen(resname) > 12 && !strncmp(resname, "gnupg-agent:", 12)) { + rt = rt_AGENT; + resname += 12; + } +#endif /* WITH_AGENT */ #ifndef HAVE_DRIVE_LETTERS else if( strchr( resname, ':' ) ) { log_error("%s: invalid URL\n", url ); @@ -343,6 +348,23 @@ break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + { + if(strlen(resname) == 4 && !strncmp(resname, "$ENV", 4)) { + if(!getenv("GNUPG_AGENT")) { + rc = G10ERR_GENERAL; /* how do I make this a silent error? */ + goto leave; + } + rc = agent_connect(getenv("GNUPG_AGENT")); + } else { + rc = agent_connect(filename); + } + if(rc) + goto leave; + } + break; +#endif /* WITH_AGENT */ default: log_error("%s: unsupported resource type\n", url ); rc = G10ERR_GENERAL; @@ -760,6 +782,11 @@ kbpos->offset = 0; break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + kbpos->offset = 0; + break; +#endif default: BUG(); } kbpos->pkt = NULL; @@ -779,6 +806,11 @@ rc = do_gdbm_enum( kbpos, ret_root ); break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + rc = agent_enum(kbpos, ret_root); + break; +#endif default: BUG(); } @@ -803,6 +835,9 @@ kbpos->fp = NULL; } break; +#ifdef WITH_AGENT + case rt_AGENT: +#endif case rt_GDBM: break; case rt_UNKNOWN: @@ -1826,3 +1861,4 @@ } #endif /*HAVE_LIBGDBM*/ + diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/seckey-cert.c gnupg-work/g10/seckey-cert.c --- gnupg-1.0.1-orig/g10/seckey-cert.c Mon Jul 12 22:57:49 1999 +++ gnupg-work/g10/seckey-cert.c Tue May 16 19:01:01 2000 @@ -43,6 +43,8 @@ int i, res; unsigned nbytes; + if(sk->is_protected == 23) + return 0; if( sk->is_protected ) { /* remove the protection */ DEK *dek = NULL; u32 keyid[4]; /* 4! because we need two of them */ --=-=-=-- From bofh@eris.phys.uni.torun.pl Thu May 18 15:12:14 2000 From: bofh@eris.phys.uni.torun.pl (Janusz A. Urbanowicz) Date: Thu, 18 May 2000 16:12:14 +0200 (CEST) Subject: GnuPG with Netscape Messenger? In-Reply-To: <20000518101453.C13517@djebel.gnupg.de> from Werner Koch at "May 18, 2000 10:14:53 am" Message-ID: Werner Koch wrote/napisa³[a]: > On Wed, 17 May 2000, Paul Gallagher wrote: > > > I'm wondering if anyone has found a way to use GnuPG when using Netscape > > Messenger. Any ideas? > > No way. > > I started to do a workaround based on a local proxy used as smarthost > and pop3 host for netscape (you can enter localhost:1234 to connect to > an smtp daemon running on port 1234). This tool should do all the > crypto stuff and has to popup a window to ask for passphrases and > to select the recipient's key. > You can always use premail for sending (on *ix systems). Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From ls@Gambit.Msk.SU Fri May 19 14:26:03 2000 From: ls@Gambit.Msk.SU (Sergei Laskavy) Date: Fri, 19 May 2000 17:26:03 +0400 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" Message-ID: <20000519172603.C9570@Peru.gambit.msk.su> I hope you will be happy to repeat this: (0) I use $ gpg --version gpg (GnuPG) 1.0.1 Copyright (C) 1999 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Cipher: IDEA, 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160 $ cat ~/.gnupg/options charset koi8-r escape-from-lines force-v3-sigs honor-http-proxy keyserver blackhole.pca.dfn.de lock-once no-greeting quiet load-extension idea load-extension rsa (1) Here is the test message: -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have just uploaded mutt-1.1.12 to ftp://ftp.mutt.org/pub/mutt/devel/. =20 This is a check-point release to summarize the few changes since 1.1.11. For 1.2, I'm mainly waiting for Brendan's pending changes to the IMAP code. Season's greetings, tlr --=20 http://www.guug.de/~roessler/ -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOQH0otImKUTOasbBAQEr3wf9GOPFRB12s7Hs+XOEwQaPhiJpFPkQ5vlh S/MYOZ4UzNMhYVpqlASAQeHk2lQFP/aQscFo0ltv7cTUmHmNgPBP/1MnkuFVMXo+ M4wb69qKJytxbDurpgHES2Y/WasPGKM6Vt2sjWNCA7UsBsorg86wCdl/fwe7pCz5 kc4emPbMBo2Kw9WI3GPP3lf3XNQKi82SfA6ilAKVOjHvhOb1odoGoCQBis8P8D11 r6FoaAQsi50vsMaUVFWET4udqNCtNfDLAZFjN0iGLL436Y9jHe95+Kjuf2+Q+MXZ 9TUyjPfboB+PzyIfPgdjl56UFFsiqUM104AWXhmdGj5XWO0pjZdVFQ== =OVlh -----END PGP SIGNATURE----- (2) Here is the public key (it's also on keyservers): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.1 (SunOS) mQENAzSgEssAAAEIAMgjiiDIe0zOqjJ2TcsWXW9DYTFzyHPSYJTBHjivb0Vekmra x+M/r6U+AWM1Bf92fGWx7cMn4oYkkaMnO8LQrBXKC8IcnwrJitvh1O0xCnIqWi1E b2JOUlxRJuVYrBNgm0OxlKBCxCmKs4yvZsJ3ykClkUJmSmBV9qDpRUJqxGzyzJ97 C36mbWV/LBKamhFcuDyAmPLZPYWwijaqixXDBuC5ouEPPUmFDgkN5F2533U/imej LSEVOMIthr1qH++wx1g50imHnmKjrtwSn4zA/f++9nl5YyOP1DwZKTu+91JEJPTH aDSnKzWRk/t7lx2JfblDjxYQlziz0iYpRM5qxsEABRG0IlRob21hcyBSb2Vzc2xl ciA8cm9lc3NsZXJAZ3V1Zy5kZT6JARUDBRI38b4/CdxwOTnzf10BAW1aB/9p2gpa ggQjcB/A3kpSEPAhc+U1jP4AVFx3BIdj/yceArIdi/j87CMN5tdHMkktC9ym5/qJ wCWn5YRnl7nF8hT1tLICmO+t/vbo4X0U7kykGVNhbHNMsMpHfBT9S88BkJno1s2D GTTN1gVloDwa4aSbqW1ltRCSSZFoSwigJUQCNYU/e7HOdYe+F+kybXZPvA9L5rg7 zW1vsp0vTLglFpmjLCgaEIIFgp297eW8wmXo/IKuWAO+kNccI6Y4JCJ8+kJfqSgw y7xpvBnuyFu/8/UHcw+wL+uUMRHzrlAibPqy3k3ZwUDOkJeLL9GJaMH+KbzlNzTS tIR1Q6188D/7Hj7piQCVAwUTNyHtwAui8ZR0SloRAQGiugQAqEAoo07fFF1RFgWP J1SVmlJDLy0O2H9hkB6KJAMtds3ga9Ku5exJZfgDz1W839yM0ntgprPHmLtlVp3f ZrLwlUjcr4IXmY45myX6I1xa+TiHEQh61U1fOPzYYR9o+3acyEZE/5uEd0ve66y7 iROHZtoPyvg8uudEHA1wd9l/TwaJARUDBRA4IDMZC+VzVzZkFFkBAUpfCACAJOPE da058VbTx721fDrNxCQu6Fk5LbbP3VTutWasWgit/s1Wnr32SptVRXqsjYp5BFwV Ug0JC8rGBfB1yAG9lXJaHrGoDuqdDKbdpZRFE8UtLnVktfW51p4ZcfuQb3DVKx3Z SVIhVrKaQUt50tWpAme+6jQTjotsO3lGtuFHyhXa/3nXQG3evmagSpAmb7Uu3b/m NSy1YLNf1h6jaJZvYKjchcgE0WE7jEJ2tBFoMd1GgSRij4WN7XLkOLPpGMma/a/A 6DNyD+/UTsZbb27pQNW32KNcA4EN8Zu1npzgNcNYd7NqScjcf0wiXkqZFNHr1XSO c8/IEsxp8v+wuhikiQCrAwUQNLu+OBKt/zYZlwkHAQEyugSwpalGr4euJUpkobI/ WvrnGAqXZRj++1/IEof7x+Jl2TnOjrMLZflgCwy0E2ZaBQpQxEcAwsNfFW/i+zGg 6+ctwN9J7SxEnN2TnUNBT2l5foRx7fIVNi3AXoOd6b8xmvad/FG83utrCxUpvWnW ZMY4C6rZKCgjXtRpd9pSwU8X3QAmI8p3dfWdLxAoZxgzJZVPlewwVRwpiQCVAwUT Nx0OJRRPLUVPVwujAQHHgQP+NF0YAIL3kl+q2sa9YCUXNgCQ+mTvZb3Zzu/q3u8+ ixTowui8bLBTFY3+yIx6IzEHATcoUPCthYwnvfX4BqWNWgDFN+eWaNrZpNEfZVkW Bs6Sd0/R4AcERUcoyp48pnH77E/XS4O4b9VlFYiQV9CX+er6VD5f0ERuNiTaD9pQ Ec+JARUDBRA3JupwLHrik2A/LQEBAf9IB/9Tx58nqBfmTok8VdUQj7bZPksOTlAK WG/f8RD5johFz/OxIey3+K1agiLA+Acr8agfQMAvfxNliJIFGcVgkyYlr/zr4aRh 6e+KEjPGuYgV607be1hPm7xmjNzJklXV0ouKgFqB6kNy+FOdG2OWXrzMQO/Dbwh6 /ofToNoOdsit9mQ5HxUuq2f0TmrjVwoBQqj/QxzA1mS/KgCdsPlEF6v9BsoXyxF3 0Wbj+h+nAU3EdOWgOTexmhcpmOvKx5bW766mB+zAdpj9c33xAMU9lt6bIIcD3cxJ fs7s9ZhWlczoarpUwU+BoKE0dMfvs6cf6NPcTrODqvCUAJwYCR42KZdZiQC1AwUT NKATSj4lAO9ZMjjhAQFvHgT+Ol0myw6jILx78keIEDdJy/fxdK6T56XUYX8nNez3 Ibm300bT63yvEnD3U6pgN+sEyzuLxP/L07Jk2E3OHJHLXJpLHWQlebW3ey9EEaYV xjClSFrmidc0Jd5nMAFmssJ9AHuENKvO096yHTMvH3MYIjYJ1HfyDUnIVDwFL8KF 4fwQezrtMwWzt8WSjWEbGmXZXW7kZ1lBnL8f6eYvCigFYYkAlQMFEzSvti9Dr0FE 3QjdbQEBPdYD/3zZLNh9rPPQ4pZ/0HfQr88BBrjIdKIXuEaZbkfiohuKf44RqOdt k832Mmb2yrp6i8IN8UHPPTpM7xfvmab2Rk21SxRZJ0IsbXzYVSP1oxdE3lIOyVlB vtn1FXEU9JuGD8N9dM994Yirg/2EfjpPJ7SdRMIdtrFAzagJvAvmdk7iiQCVAwUQ NO2N7knh/jPvZzKNAQFdlgQAlGd9mSgxjv6Id8FZ3lMhU0RzKvHNFRof985lkyJt R/01qAJZbCxeJB2y5diLw6qZaVw6+hCqgP5Bbw8PPtKr7i/OvAXBPgoU5Ume4J2A EsavEmavAJ90Zph0WK2BzqCQd1EP5M2jqdBATDunL67rJ5bk0l7y/KwgM5NhyCmY FNmJAJUDBRA0xeJJTFllIALEMQkBAdTfA/42FNAByvEHM9pRkK4qftVDSnIIZeRP uIfV+mO4FcNE9h/oH3nBSOUGn7NqsjwJuj4daZ2tmWfH41D8oQjPVqdM4fd0csYk FZLI0qu1wTd8MxEJsHoh5qIU8M6ywL5pIflhOP1wGf6omqBh2VZuhYY6m0775Lih A0c/DLokymQ6C4kAlQMFEDccqjNMo00siEncPQEByDcD/3cUDPeFBlzq5SSKANRA emT0HoW+aoUO+bRavqOzwCuYNhkSNx7yukACFc8fu13vlBpHL39RLJC6zT+8rto1 MH3SLnJNJj7FH8NZUQDffwXXea3eydNCx0T9fVu0QBndPvyib6K3oVD/Z6yirbo+ pNZnn6U8aOrEXf18IizhhBdxiQCVAwUQNvYNv1H8PGQHafT1AQGBrgQAhWdZ9ws2 EIh8LJEAb53FHcjonandcJ7HDgLo3GpWnhIvhcc+YKQluW/8lS92bsjY3tVRfDYe Y80NjEODDgn+CEcOu9LqssGj4CwuU7b58tBdSIV1v7CSX9cTM9+0r0qGU7ql7Lpn zBqhx36UXqOK6vfU0cWrHLkPUNlms2a96LeJALADBRA3TTnyVmSU4zFmVdUBAZlh BNEBfEm35/lKlMV3hlFMT/K7ZhddrptYh+vCGhJNSO48KD+6foES7zgAH8k1j1Wh A2b4oVG7X4x5T603UqGDFpaycddqxGc7Bs7E0aAVygEkoJQ6c8AjSkyy/lRnGZ1G ln7vPNM8TokQJQRKfkm/tPpE1jneaU/j102We0jg2ULyJQOLB73acI/v5O4p1d1F +W5S3XySxxDcbOWJjYkAlQIFEDUZVnh4YVpjdyds6QEBU2sEAKjJkcCiOqnyh7I7 O1PIVbEWumltWd5CXDT2MwMXX5vOGex//qERDNDqR4w1ksPj3NVOkSaVFQMjw2Ys zBFFHma45LZPSxv2UGxjII8qPPgPmkllLyhHCGrDRY+IZ0Wax+HFfJe3g6xYYgCl ojNVd1chV9eduNZLxdvhV4YKVSHMiQEVAwUQN1PmOH4v6i2JDAmBAQEP3Qf5AYd0 ytzQB36MJHx+jHismpNsJEGj/rQ8PxeWnic9GkcgBi97wflQaldonFlvoeNFyIwS MTLs2vZTeCRLMxc1LFnwurx8/2oks9xp63733Rqs9DonnkDQR04YWLkw4djTaEDc /GWHCyYiPj11G/12b09ywf4nPd32K8AVoIQAPQy5P4GRhesQTvWTl1yXLEVWjv6g PLJUo3l1BrIKm+GMdnlBqTGpswPtkxeUqp8mjYdwnmm5ajX/qkxe1UE/t5V74169 uTL1+DjEl3CT+rVR6UtEc2qM3Zg2PTzgjmrFfHeUdXv1QBfRJlhmtPQtRX4csDFP fX0sO5n5PZpYcYlzC4kBFQMFEDTFOAt+8FjoQyMUJQEBjpIH/3Uwc8cMr8RAie00 9a7536V2x2miBAoTAjsb5ui91geM4ssXgilUgB/sBW/bV6cZA67Q7YYSollFSKPb LhmoZUEvkf+cS6cdojUbq2p2pd7Djq3ZSYNTRbIKo8KWBLSfSuDsxdu0oVdW3DO2 5TMzkauxNnqMegWjLSRCMRigdQYYmZKrA9tY6hD63c6eLt2DAWuF+pepwo5N6jm7 yGHWAW0ihhqv+NHlIc3JExxxzDYeTjC4Yb5dfHpYG7ETbsMZCQ77Ru1isbcA557/ kgSwKPUt0LAMgVj9atG4OIezjwPubEV/SxvcRnjEKsQOQe7WriLcPjeELlMvakBc nDS7NtqJARUDBRA29l83fvTWwzbkE20BAc0HB/sGlryh+m+UJR5TjI7cMf13UnFh vL88TIRLGxVwsOYoKixiU1hPecGFWcXsnYue6Hduvb9EiBdn3GQcKQAda0TtCXoJ 6gmph8xx7cGqSGd1ldh1nkWbGsCt82HcK7XQ0qF/zUTuRwxi7F30YI5ZBYBLOVsn dB7rMm4ObkHH0nskMMMfZ1VcsT5ndvKL2RvevRaleXob14erDDsEmqKzPMRpyTKO CAMnK5k86P8uK+8hg39rLSQodPKzxvtyJNEDt3iizQ+Ac1nlPIeO/pN7CnqJwu5T codS9bVe9A39gIqhbCp8zYjKD+uU+8tOGYthuU2FvgDaB0NU+pzSaw2X2se6iQCV AwUTNK/OIokABLrCbuiRAQGsdAQAxOh0ipz4H80XifbWjh+W721oIwXGjBl/n/e/ UJh7cqzqZxo+I/vR3O0wCfnkeQ94ihe24eamvEvwvWbpRmnfqozp2Fuo9JcazgML j0eDmqZCe0XJEi4t3WdIavy59XskuzPaM8AepRKULStKup22o5jgvOnK6/2KcYmx oKULfeCJARUDBRA1EBSciVPDw6koVP0BAQkvB/wN1M5oadLBjOIgm34y1qtxnkvF ZuPIJIWVVX+3Fz2FwZ84OIqVtNGxjKAOkyFG371+wEXc7xZZ9owSCO2edVTCC2wL 2mDFostS7G4aTDWvXMx0lWTTc8V2RZTOQ8bGJDo+6HgFNg4gV/03MpPqB413yVas XseES/yCt+haLnk85mO8KVSGP7DAdwJn5tLx3GKHZE3Qh9XTJ0j4V/9uG8ohf94T O63s0V/3ZAMUK8GaP4kiC5d4ZEN+4DyHw6xjYTmrRp3tvXKJrUHaSnCXaS7Obr2C DO5LyRi07qMrkHAxjmDMdJYHyS9SEPqphx+/1TyYZQx1edrlLiY31YSFEpH+iQCi AwUSN/G+HpFeTizbCJMJAQFzUgRmN7+0sKxmW7m5MBaB2dHnOpoya6Kxzbp3oghW 8cX4+DOI4zukBDWvEnnreCnbl4dFoTr38+GoG336NozKhKvx5kvSqBzL6XpzXrT6 OTg/b2NGiFpSR0QKNJtNSUUwGwSVDa1Yqqn0FMmFGAeI08p+VeMXLpwjDWXsvRYr 9S+fVY+jDNeFRv7yOUFOZTstiQCVAwUQN29YLpznb919i1kZAQEDSQP/bbq6SB16 jS7IjIcUHHvhHZ3aXmFkx55kcKPnBZrzPOAN9R6jFDS1wu0ejxVPNp6iGzODq2tz UPv5HJfWufxMaxHpnHQ6J5+EwpLQwWj2PrSQg6idNA4W/0eFLi0SOlFj8JAXt69j fkl/K4R/kiNPVL2FVWQMCOLtYVxTbkf6XxqJARUDBRA28ZJ5nnPrCk1Y7lEBATqQ B/sGsKnPF45GKF7Yu/3dNwQD38g5Qpj8+7ddPcjME7tmkD8BHFR6o6bDtv7zWeEF uxg+XjAxg4dPSHrAXdKZ5SDHqJO7+GbZP/eP7zoGw4V1GVnCz0e0v2WXUfe56oFu oO/4XRrbsWhAtYPGeYi9BO/XRDIjDmjvFvjitjwIgxzUb/t6DqPMHchRpK1MOTWs bvUOb8Dz2U8YusH/G5puw2AemLyeXx6erZJm385bcAzgoP+tp4fA6SjSlQs9FD7J Y4goyBv534fluGGHth+nuIB2jn+zHOkcUgAgOJPSGmZSsSxXKQxfL1Xr1SdNbT16 i2VOIu7MWkceillxJUMIHE7ziQCVAwUQNMZ9G7Btxkr72ChhAQFIuwQAigFlRtsE jhtOXv9+Ot2gqKbqfj2TkOTCpr4HRlFGDzkIkbBZsp8q2Af5ZiQ7/h/g1asqbvzK J6XTWQo6K0U9iiasWYpXlUlrlVhMjm3hUrGLaMglGcnURemVHhhfS3S/4aggJqW6 Dt5U10txXrAdKfegU0+HEJ5L6WuKaulDxViJARUDBRM02HCwvqaOf4UxMn8BAfIb B/4omzocwa8eHPZgsuwq9pkU69qtJmndgxAxzSivSfd8UV3rVKquxIfPWTJuBuug EleQlskVASKiQVKubgSpP7VcyHimzgPt9w/RKLDpDAGAzZh6r9PX3BxdKxaig2Ny eiCmLYv7oZG6nOFa1xaPYmjxVDOwT39kZE36O2Boe5rW2Jj+GG/Iwxt4iGToXyZW Gz7uXP/Ar3O+kjQzgg14ieFkyOQYuI1Br/9ZCMIFwjHXfQsXRYP+ftTLi9DYfTXh G0bP+bc1FdiRLjM4IHYJ9ydl2p/1TL01ZO6eb9DB+a9esjXfb//frYCRFNPKoV/A b4TgVWYqAJlLczLEwfBkbkZgiQDVAwUSN/G+Xb+Ot2lXSNSVAQFEaAX9FQjXrDRc /FqkeiBNievdgVt03Lrm2XYkKnnvh059M7i+S/tVW7ly3sifvM1J4X2hvT9jbhb0 lD0gISXz85n7pHMpf4cxJpTnMefRBKFoDA2AYLUHL8Rq+VOKkdPM8pCgySU69Ssu ZPrK7kOByWiU8VeekL1+7236QrstzE+P8ePygXb6hrQZXzgClVq9DfVu3r5BRagU za/CDfuECEoRrdCPNOTOcC2PbdJjtLQIAm8m+llYXkd0Ij3zhB1HAISwiD8DBRA0 3w93xiLu3cOF4DcRAoYMAJ9AxHy1WoKMNp5BtD7bJVPiWmXXjwCfcaeh4TirEQLm aMT+TdecW0Nv1E2JARUDBRA0oBMs0iYpRM5qxsEBAUT8CACbuZBD0zuWHTuqTvEY MIuO/VJL0f+op9IwpMjD2W8EzXa5XEq4WoCdff9YzSZUT/T6Sy2ZcercLgthJRcr gQowZAQvn3UDnbF7OpPv3cblapmb2lvIDhJESco/I1R08kZN905bFmkcF1sNXsjf 6B+K2N2BSizbE2aS8xIJ+tuRDGeS1Gsai1e+impbGbVQiO4lUQlAOZeJPQ7IOtED yEHUjWw1FsOq/x9GNZMMxIqN/BagsqpA7eHJ76fsMQN1f0kh3oepaN3lZ7xqoSGE MIpf/eCzawGwlrEA3aROCjr33+hHzimIj8rtuxKUAo0jvNs8Wg3V3mXW/QgWhW1y hfLAiQCVAgUQNK/96fE8+WC3TbWNAQF40QP9Fq0LhANCSh1cQFqxIbCtzgyEm0ZL Ujx0fFE9onyE0/Jnuh+3fvRGde0UxzEfrTqf3Z+1hxYDtnuxcRUTlVSFRJfvO3g9 b+fcw08BG8hLpexQ1Jl27rEQEnxu3kyxtw+WkxDw/JMzf0bPG7rz4Rp2UbwOvFCY 1mLh+fsl4QvdnGCJAJUDBRA0sj2j9e+XfZ71UOEBAT9VBACeGQsN4aabBhcJlQIV XO9MlDY5ioWgRgAS/WCLgXf5FNvT5hVKv/WNHoe4VLQjJQE17MocrU8MpYxkoXBk JgNLfMl+hp7wACHXvn9m5MTJFJuRx3uuuyNi5Tyjhtovpn6MUn3nSxLID/F2XMMo Vfhu0Pz0V+DHMa2kVl1U/Xa+wQ== =jubg -----END PGP PUBLIC KEY BLOCK----- (3) Start gnupg by $ gpg < /path/to/saved/pgp-message gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK ^C gpg: some signal caught ... exiting -- Thank you! From wk@gnupg.org Fri May 19 15:38:46 2000 From: wk@gnupg.org (Werner Koch) Date: Fri, 19 May 2000 16:38:46 +0200 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su>; from ls@Gambit.Msk.SU on Fri, May 19, 2000 at 05:26:03PM +0400 References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: <20000519163846.M14819@djebel.gnupg.de> Hi, iirc, this has been fixed in 1.0.1f - can someone please test against this version. tia, Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From offby1@blarg.net Fri May 19 22:12:55 2000 From: offby1@blarg.net (Eric Hanchrow) Date: 19 May 2000 14:12:55 -0700 Subject: How to deal with old RSA keys In-Reply-To: Dr Lyman Hazelton's message of "Fri, 19 May 2000 13:45:14" References: <3.0.3.32.20000519134514.0099abc0@mail> Message-ID: <8766saz1k8.fsf@potato.hanchrow.org> >>>>> "Lyman" == Lyman Hazelton writes: Lyman> But I have an old RSA key that's been kicking around for a Lyman> long time and I didn't have a die-date on it. I still want Lyman> to be able to get messages written to me with this key. Is Lyman> there a module that I can add to gnupg that will allow me Lyman> to do this? Not everyone is switching to gpg and I still Lyman> need to hear from them in private. This should really be a FAQ. If you're using Debian GNU/Linux, then all you need to do is install the packages `gpg-rsaref' and `gpg-idea'. Then add these lines to ~/.gnupg/options: load-extension rsa load-extension idea -- PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5 C8BD 6337 0041 C01C 5276 From sroberts@uniserve.com Fri May 19 01:03:57 2000 From: sroberts@uniserve.com (Sam Roberts) Date: Thu, 18 May 2000 20:03:57 -0400 Subject: Solaris random device In-Reply-To: <00f101bfbcd5$f327f000$16006598@asiainter.net>; from em@who.net on Sat, May 13, 2000 at 08:22:18PM +0800 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> <00f101bfbcd5$f327f000$16006598@asiainter.net> Message-ID: <20000518200357.B471@localhost> On Sat, May 13, 2000 at 08:22:18PM +0800, Enzo Michelangeli wrote: > ----- Original Message ----- > From: "Andreas Pommer" > To: > Sent: Saturday, May 13, 2000 16:59 > Subject: Re: Solaris random device > > [...] > > Currently it is more similar to the linux /dev/urandom , less to > /dev/random. > > At every call to the device some entropy is added (from a high resolution > > timer, and sometimes process id) and subsequently mangled by some hash > > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > > The solaris kstat interface provides access to a large number of kernel > > counters which can be used for that purpose. However, the "good" ones > > have to be determined. > > Why? Just toss everything into the pool: the total entropy cannot be reduced > by adding low-entropy data. The more, the merrier. Yes, but the implementation of /dev/random so that it blocks until sufficient entropy is available, requires an estimate of randomness of input. Some statistical checks are done to estimate this, but when data is put into the pool it is identified as adding to the estimate of bits of entropy in the pool, or not. GnuPG, for one, attempts to select() until as much entropy as it wants is available. This entropy estimation seems important, though fairly fuzzily defined. Sam -- Sam Roberts, sroberts at uniserve dot com, www.emyr.net/Sam From tyketto@wizard.com Sat May 20 09:42:38 2000 From: tyketto@wizard.com (A Guy Called Tyketto) Date: Sat, 20 May 2000 01:42:38 -0700 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519163846.M14819@djebel.gnupg.de>; from wk@gnupg.org on Fri, May 19, 2000 at 04:38:46PM +0200 References: <20000519172603.C9570@Peru.gambit.msk.su> <20000519163846.M14819@djebel.gnupg.de> Message-ID: <20000520014238.A30251@wizard.com> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 19, 2000 at 04:38:46PM +0200, Werner Koch wrote: > Hi, >=20 > iirc, this has been fixed in 1.0.1f - can someone please test against > this version. >=20 > tia, >=20 > Werner Has this been released/uploaded yet? I'm not seeing it, at=20 ftp.gnupg.org:/pub/gcrypt/devel. 1.0.1e is still the latest and greatest=20 there. If it's located at another place, please let me know. :) BL. --=20 Brad Littlejohn | Email: tyketto@wizard.com Unix Systems Administrator, | tyketto@ozemail.com.au Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5Jk/+yBkZmuMZ8L8RAnkaAJ9Ksu1gNeCOn2Fk1ePmWsRgoNQvOQCZAZmM xnVmuHNaxcePKFhNNH1DwaM= =t6Ko -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From hideki@allcity.net Sun May 21 00:31:18 2000 From: hideki@allcity.net (Hideki Saito) Date: Sat, 20 May 2000 16:31:18 -0700 Subject: Windows version of entropy.dll problem Message-ID: <200005202329.QAA19377@server-1.visp.net> I have one bug report (among with fix) in entropy.dll which is distributed in GNU Privacy Guard for Microsoft Windows which is in the download page. It is that in certain circumstances; most visible in Windows 2000, it crashs when it is executed to generate keys, it crashs. This problem is solved after I compiled entropy.dll from sourcecode using Microsoft Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll Thank you. -- Hideki Saito mailto:hideki@allcity.net From hideki@allcity.net Sun May 21 00:41:15 2000 From: hideki@allcity.net (Hideki Saito) Date: Sat, 20 May 2000 16:41:15 -0700 Subject: CC Request Message-ID: <200005202339.QAA20452@server-1.visp.net> Sorry for bother about this with separate mail, but please CC me if you have questions or comments about entropy.dll, since I'm not subscribed to the list. (is there anyway I can subscribe to it?) Thank you. -- Hideki Saito mailto:hideki@allcity.net From wk@gnupg.org Sun May 21 18:22:36 2000 From: wk@gnupg.org (Werner Koch) Date: Sun, 21 May 2000 19:22:36 +0200 Subject: Windows version of entropy.dll problem In-Reply-To: <200005202329.QAA19377@server-1.visp.net>; from hideki@allcity.net on Sat, May 20, 2000 at 04:31:18PM -0700 References: <200005202329.QAA19377@server-1.visp.net> Message-ID: <20000521192236.D3283@djebel.gnupg.de> On Sat, 20 May 2000, Hideki Saito wrote: > It is that in certain circumstances; most visible in Windows 2000, it > crashs when it is executed to generate keys, it crashs. This problem > is solved after I compiled entropy.dll from sourcecode using Microsoft > Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll I am in the process of reqriting it without the need for DLL. I hope to commit the changes on Thursday or Friday. However a lot of new testing will be required then. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From rguerra@yahoo.com Sun May 21 18:54:59 2000 From: rguerra@yahoo.com (Robert Guerra) Date: Sun, 21 May 2000 13:54:59 -0400 Subject: GNUPG & AES Candidates In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> References: <200005202329.QAA19377@server-1.visp.net> <20000521192236.D3283@djebel.gnupg.de> Message-ID: Werner: I'm forwarding you a message I recently posted on the pgp-user's mailing list (http://www.cryptorights.org/pgp-users) . I'm curious to know if you are considering adding any additional AES candidates to gnupg. regards robert Date: Sat, 20 May 2000 22:45:31 -0400 From: Robert Guerra Subject: Re: [PGP-USERS] PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org Tom: At 8:49 PM -0400 2000/5/20, Tom McCune wrote: >I found the following at: >http://www.pgp.com/asp_set/products/tns/pgp70_reqts.asp > >>Cryptographic Algorithms Supported >> >> Public key algorithms: Diffie-Hellman/DSS, RSA >> with up to 4096-bit key lengths nothing new here unless 4096 applies to RSA as well. >> >> Symmetric algorithms: CAST (128-bit), 3DES >> (168-bit), IDEA (128-bit), Twofish (256-bit) twofish is new...but it hasn't won the AES competition. Can the Rijndael cipher be added too? I believe that the other AES finalists should also be included. It would make good sense to at least keep the others in mind in case Twofish doesn't win. After all, it would be nice if PGP v.7 could have the AES winning candidate. For what it's worth.. At our Toronto May cypherpunks meeting, it was mentioned at that the Rijndael cipher was well looked upon, and a favorite of many at the april AES conference. As it's invented by a group in Belgium it will be interesting to see how it plays politically in the selections process. After all can the americans seriously consider to accept and deploy something made outside the USA (NIH - not invented here, not good) >> >Any other news that can be shared on related changes would be appreciated. Some references: Video Report of The May cypherpunks meeting in Toronto (Canada) http://www.epress.ca/privacy AES Round two AES Round two analysis AES Second Round Implementation Experience The block cipher Rijndael -- -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From Nils@infosun.fmi.uni-passau.de Thu May 25 15:02:03 2000 From: Nils@infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Thu, 25 May 2000 16:02:03 +0200 (MEST) Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: <14637.12891.65451.656522@skrjabin.fmi.uni-passau.de> Hi all, we've had quite some discussions on this list about the various random "gizmos" available on Solaris 2. I'd like to summarize the possibilities and then make a suggestion. The need for entropy is not a domain of GnuPG alone; OpenSSH needs it as well, and there may be others coming (BTW, I've heard rumours that the OpenSSH folks are considering to use gpg keys instead of their own user-level public keys. Does anyone know more details?). There are currently three options that I am aware of: ======================================================================= 1. Entropy Gathering Daemon (EGD) Available from http://www.lothar.com/tech/crypto/, latest release is 0.8. This is a perl script running as a daemon, providing an entropy source through a pipe. EGD is supported by both, GnuPG and OpenSSH by means of a configure option. The latest release even works on Solaris 8. It works very well, the only drawback being its speed: if you need a lot of entropy (generating keys, multi-user platform), egd might be a bottleneck. 2. /dev/random as provided by Sun package SUNWski This software was developed by Sun as part of the unbundled product Sun Webserver 2.0 on the Solaris Easy Access Server 3.0 CD. This product was supported for Solaris 2.6 and 7, but not 8 (because Sun is now using Apache or Netscape's web server). However, the SUNWski package still works fine on Solaris 8, provides entropy much faster than egd (it's a daemon written in C) and was reviewed to provide high quality entropy: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=95618127814224&w=2 SUNWski's /dev/random is natively supported by OpenSSH, but in order to use it with GnuPG, you have to apply the following patch. That's because SUNWski provides /dev/random as a pipe, and not as a character device. The patch is relative to the current CVS snapshot of GnuPG. As SUNWski provides only /dev/random, the patch assumes a link from /dev/urandom to /dev/random. diff rndlinux.c.orig rndlinux.c 86c86,92 < if( !S_ISCHR(sb.st_mode) ) --- > if( !strcmp(PRINTABLE_OS_NAME, "SunOS")) { > /* Solaris 2 Easy Access Server -- SUNWski */ > if( !S_ISFIFO(sb.st_mode) ) > g10_log_fatal("invalid random device!\n" ); > }else{ > /* Linux , xBSD*/ > if( !S_ISCHR(sb.st_mode) ) 87a94 > } diff configure.in configure.in.orig 447,458c447,448 < [case "${target}" in < *-solaris*) < if test -p "$NAME_OF_DEV_RANDOM" && test -p "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < *) < if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < esac]) --- > [if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then > ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; fi]) You would then use the random device type "linux". However, this patch breaks the use of the 3rd option. 3. /dev/random and /dev/urandom by Andreas Maier This is a new port of the Linux kernel random driver to Solaris 2 as a kernel module (what Sun should have done in the first place!) from http://www.cosy.sbg.ac.at/~andi/. It's very new, therefore hasn't been reviewed regarding it's entropy quality. As this is a clone from the Linux port, both are character devices. Therefore, the GnuPG sources don't have to be patched at all. You just select "linux" as the random gatherer. I've tested it on Solaris 8. I didn't recompile OpenSSH for this, but a quick look at the sources suggest that it should work there as well. Unlike GnuPG, OpenSSH only tests for existence and readability of /dev/random, but not whether it's a pipe or a character device. Being a kernel module, it should be pretty fast (didn't try). Personally, I would like to have the source reviewed by someone who knows about entropy gatherers before I'd use it in a production system. ======================================================================= Proposal I'd like to see GnuPG being a bit more flexible on this issue and therefore avoiding the need to patch it. I think that taking the OpenSSH approach (testing for existence and readability of /dev/random and /dev/urandom, being still happy if the latter doesn't exist, and don't test the type of the device; suggest the use of egd if the devices don't exist) should be OK for GnuPG as well. The naming of these random gatheres as being "linux" is a bit unfortunate, but that's just cosmetics :-) Any comments? Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From sam@cogent.ca Thu May 25 15:25:37 2000 From: sam@cogent.ca (Sam Roberts) Date: Thu, 25 May 2000 10:25:37 -0400 (edt) Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: Previously, you (Nils Ellmenreich) wrote: > Proposal > > I'd like to see GnuPG being a bit more flexible on this issue and > therefore avoiding the need to patch it. I think that taking the OpenSSH > approach (testing for existence and readability of /dev/random and > /dev/urandom, being still happy if the latter doesn't exist, and don't > test the type of the device; suggest the use of egd if the devices don't > exist) should be OK for GnuPG as well. The naming of these random > gatheres as being "linux" is a bit unfortunate, but that's just > cosmetics :-) > > Any comments? I'd like to second this proposal, particularly about not forcing /dev/random to be a character device. I ported Linux's random to QNX4 and Nto, and I took the approach of making them look like character devices so gpg would recognize them. I don't really think they are, any term control ops on them would fail, a named pipe or a QNX named device would have been more natural. The term linux will be increasingly a misnomer, I believe the *BSDs have a /dev/random as well, for instance. Sam -- Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca) "News is very popular among its readers." - RFC 977 (NNTP) From koch@hsp.de Thu May 25 16:37:26 2000 From: koch@hsp.de (Walter Koch) Date: Thu, 25 May 2000 17:37:26 +0200 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su> References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: Moin, am / On Fri, 19 May 2000 17:26:03 +0400, schrieb Sergei Laskavy wrote: >$ gpg < /path/to/saved/pgp-message >gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 >gpg: Good signature from "Thomas Roessler " >gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK tested it with gpg (GnuPG) 1.0.1f-snap2000-05-25 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: Warning: using insecure memory! gpg: Signature made Sat Apr 22 20:51:14 2000 CEST using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " The NOTE: is completly gone! Gruss, Walter -- Walter Koch Hochdahl am Neandertal http://www.hsp.de/~koch/ qrv:db0iz-9 walter@1409.org ham:dg9ep@db0me koch@hsp.de From bem@cmc.net Thu May 25 22:39:15 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 14:39:15 -0700 Subject: Clearsigning (again) Message-ID: <20000525143915.B24700@cmc.net> I know there is very little in the RFC regarding clearsigning and that PGP-MIME is better. But Network Solutions wants clearsigned (and so do many Usenet readers since multipart MIME is evil on Usenet), so I need it to work properly. >From the fine man page: -t, --textmode Use canonical text mode. If -t (but not --textmode) is used together with armoring and signing, this enables clearsigned messages. This kludge is needed for PGP compatibility; normally you would use --sign or --clearsign to selected the type of the signature. But this doesn't wholly work. [thorin:~] 2:10:46pm 193 % echo foo | gpg -t --armor --sign You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 foo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5LZbaN3/OJIgyK1ERAm/3AJ99ETFfFOvIS+necd4awNO5S255EACghazh p9oyByxGr6xctlsQTU7C4zk= =myQV -----END PGP SIGNATURE----- The problem is that with PGP, the same sort of thing will have an empty line after the 'foo'. PGP5 will verify the above, but it will be missing the end of line: [thorin:~] 2:12:53pm 200 % ls -l foo -rw------- 1 bem bem 3 May 25 14:12 foo [thorin:~] 2:12:56pm 201 % od -x foo 0000000 6f66 006f 0000003 The trailing newline placed there by 'echo foo' (which emits 4 characters) is gone. Again, I realize that RFC2440 isn't clear at all about 'clearsigned' messages but I believe interoperability is important. How does the above behave with PGP6? If it behaves as PGP5 does, then I think gnupg needs to change. The relevant wording in 2440 I see is: The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. That seems to imply "insert an extra newline here when signing and discard it when you verify". There is also a problem in lines ending with TAB (which, alas, I know because NSI seems to send forms with TABs at the end of the line for reasons known only to them): [thorin:~] 2:15:13pm 211 % echo "foo " > foo # that's a tab [thorin:~] 2:15:14pm 212 % gpg -t --armor --sign foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 2:15:25pm 213 % pgpv foo.asc Opening file "foo" type text. BAD signature made 2000-05-25 21:15 GMT by key: 1024 bits, Key ID 88322B51, Created 1998-10-17 "brian moore " "brian moore " "brian moore " This seems to be contrary to RFC2440: Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Spaces at the end of the line -are- ignored correctly. But tabs are not. If there's consensus that these two things need fixing, I'll submit a patch, but so far I've had no response to these even being problems. :( Again, both of these are needed to work with Network Solutions, which is why it's annoying me. If I manually ":%s/^I$//", and insert a blank line at the end of my forms, yes, I can then submit them to NSI and have them verify, but that seems goofy. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem@cmc.net Thu May 25 23:08:29 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 15:08:29 -0700 Subject: Clearsigning (again) In-Reply-To: <20000525143915.B24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 02:39:15PM -0700 References: <20000525143915.B24700@cmc.net> Message-ID: <20000525150829.C24700@cmc.net> On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > This seems to be contrary to RFC2440: > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > any line is ignored when the cleartext signature is calculated. > > Spaces at the end of the line -are- ignored correctly. But tabs are > not. Ah, oddly enough I can make it do this -- but I have to specify '--rfc1991' to do it. It still strips the \n at the end, and I'm not sure why the --rfc1991 is needed, since RFC2440 requires it as well... -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem@cmc.net Thu May 25 23:36:45 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 15:36:45 -0700 Subject: Clearsigning (again) In-Reply-To: <20000525150829.C24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:08:29PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> Message-ID: <20000525153645.D24700@cmc.net> On Thu, May 25, 2000 at 03:08:29PM -0700, brian moore wrote: > On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > > > This seems to be contrary to RFC2440: > > > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > > any line is ignored when the cleartext signature is calculated. > > > > Spaces at the end of the line -are- ignored correctly. But tabs are > > not. > > Ah, oddly enough I can make it do this -- but I have to specify > '--rfc1991' to do it. > > It still strips the \n at the end, and I'm not sure why the --rfc1991 is > needed, since RFC2440 requires it as well... Continuing to follow up to myself... :) I see why. It's a bug of PGP5. If I manually strip the tab in the clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not recognizing that it should ignore trailing tabs on input. (And this isn't documented in the 'Implementation Notes' in 2440 with the other PGP5 bugs... Can someone on the IETF committee see that it makes it into future revisions? :)) But the dropping-the-trailing-newline doesn't require PGP5, so I'm still convinced this is solely a gnupg problem: [thorin:~] 3:34:15pm 288 % echo foo > foo [thorin:~] 3:34:20pm 289 % md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo [thorin:~] 3:34:27pm 290 % gpg -sat foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 3:34:44pm 291 % gpg foo.asc File `foo' exists. Overwrite (y/N)? y gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 gpg: Good signature from "brian moore " gpg: aka "brian moore " gpg: aka "brian moore " [thorin:~] 3:34:52pm 292 % md5sum foo 2145971cf82058b108229a3a2e3bff35 foo I still don't think gnupg should do that. :) -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From gqueri@mail.dotcom.fr Fri May 26 00:51:33 2000 From: gqueri@mail.dotcom.fr (Gael Queri) Date: Fri, 26 May 2000 01:51:33 +0200 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:36:23PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526015133.A308@baoule.ath.cx> Hello brian, sorry to interrupt your conversation with yourself :) On Thu, May 25, 2000 at 03:36:23PM -0700, brian moore wrote: > (...) > But the dropping-the-trailing-newline doesn't require PGP5, so I'm still > convinced this is solely a gnupg problem: > > [thorin:~] 3:34:15pm 288 % echo foo > foo > [thorin:~] 3:34:20pm 289 % md5sum foo > d3b07384d113edec49eaa6238ad5ff00 foo > [thorin:~] 3:34:27pm 290 % gpg -sat foo > > You need a passphrase to unlock the secret key for > user: "brian moore " > 1024-bit DSA key, ID 88322B51, created 1998-10-17 > > [thorin:~] 3:34:44pm 291 % gpg foo.asc > File `foo' exists. Overwrite (y/N)? y > gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 > gpg: Good signature from "brian moore " > gpg: aka "brian moore " > gpg: aka "brian moore " > [thorin:~] 3:34:52pm 292 % md5sum foo > 2145971cf82058b108229a3a2e3bff35 foo > > I still don't think gnupg should do that. :) It seems to be fixed in gnupg 1.0.1e, so you were at least not the only one to think that :-) gael@baoule:~$ echo foo > foo gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo gael@baoule:~$ gpg -sat foo gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! You need a passphrase to unlock the secret key for user: "Gael Queri " 1024-bit DSA key, ID 3E18F9CE, created 1997-09-01 gael@baoule:~$ gpg foo.asc gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! File `foo' exists. Overwrite (y/N)? y gpg: Signature made Fri May 26 01:38:48 2000 CEST using DSA key ID 3E18F9CE gpg: Good signature from "Gael Queri " gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo Regards, gael From sen_ml@eccosys.com Fri May 26 04:09:38 2000 From: sen_ml@eccosys.com (sen_ml@eccosys.com) Date: Fri, 26 May 2000 12:09:38 +0900 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net> References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526120938J.1001@eccosys.com> From: brian moore Subject: Re: Clearsigning (again) Date: Thu, 25 May 2000 15:36:45 -0700 Message-ID: <20000525153645.D24700@cmc.net> ... > Continuing to follow up to myself... :) > > I see why. It's a bug of PGP5. If I manually strip the tab in the > clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not > recognizing that it should ignore trailing tabs on input. (And this > isn't documented in the 'Implementation Notes' in 2440 with the other > PGP5 bugs... Can someone on the IETF committee see that it makes it into > future revisions? :)) information about the openpgp working group mailing list can be found at: http://www.imc.org/ietf-openpgp/ you could post the suggestion there. From rabbi@quickie.net Sat May 27 01:33:46 2000 From: rabbi@quickie.net (L. Sassaman) Date: Fri, 26 May 2000 17:33:46 -0700 (PDT) Subject: Subkeys In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get an "Unusable public key algorithm" error when I try to encrypt to keys that have additional encryption subkeys. Can we work through this so that GnuPG handles v4 keys with multiple subkeys in the same manner that PGP does? - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LxfxPYrxsgmsCmoRAvQ+AJ9GeC6rsYWb7HxeXnEVsCRYx9eVxgCgwqXl r3pOieMkJByCafQgUfydTiQ= =Hxpe -----END PGP SIGNATURE----- From bem@cmc.net Tue May 2 23:17:12 2000 From: bem@cmc.net (brian moore) Date: Tue, 2 May 2000 15:17:12 -0700 Subject: general compatibility with PGP... Message-ID: <20000502151712.K31948@cmc.net> This seems to fail: -------- This is a test file for GPG/PGP/OpenPGP compatibility. This line ends with a tab for no good reason: Thanks for the test. This file ends with a blank line. -------- The above file, once signed (with gpg --sign -a -t testfile, which is what the docs imply is the 'pgp compatibility hack'), will not verify with PGP5, and PGP5 will also strip the last blank line. Who is right on the reading of 'text mode' on this? Or should there be a '--broken-text-mode' flag to appease PGP5? It's sort of annoying since Network Solutions likes sending forms with lines ending in tabs and spaces (I dunno -why-, they just do!) and I have to be sure I do a ':%s/[ ^I]\+$//' before signing stuff and ensure I have an extra blank line at the end. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From nittka@esem.com Thu May 4 08:37:03 2000 From: nittka@esem.com (Oliver Nittka) Date: 04 May 2000 09:37:03 +0200 Subject: [mailing-lists.reiserfs] (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Message-ID: --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit this may become very important for all open-source-projects, so i'll forward it to this list. -- oly -- Oliver Nittka | nittka@esem.com ESEM Grünau GmbH & Co. KG | http://www.esem.com Dornierstraße 6 | phone: +49 7544 9583-25 88677 Markdorf / Germany | fax: +49 7544 9583-60 --=-=-= Content-Type: message/rfc822; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit From: Xuan Baldauf Subject: (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Date: Thu, 04 May 2000 00:23:53 +0200 Message-ID: <3910A6F9.705A11A7@exmail.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------AC179D27851ED6C2526ACC47" To: reiserfs@devlinux.com Mailing-List: contact reiserfs-help@devlinux.com; run by ezmlm This is a multi-part message in MIME format. --------------AC179D27851ED6C2526ACC47 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I'm sorry for spamming the majority of not german list readers, but for those who are, this might be very important: The European Union plans to accept software patents. SWPats will slow down open source development, because large software companies can afford patenting algorithms which are easy and obvious, along with others which are complicated and advanced. If ever a clever (kernel) hacker finds an algorithm for a specific problem, there will be a good chance that this algorithm is a patent infringement. For their economic interest, large software companies will sue (kernel) hackers, and because large software companies have much more money, (kernel) hackers will give up, and open-source development will handicapped, probably at large scale, because nobody wants to be sued only to be a good (kernel) hacker. The most prominent example is "the GIF patent", the gd library ( http://www.boutell.com/gd/ ) was forced to give up GIF support. If you are against this scarious development, which is already possible in the USA, but not in Europe, and if you are german, read the following. Thanks for reading although being offtopic. Xuân. --------------AC179D27851ED6C2526ACC47 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Disposition: inline Return-Path: Received: from localhost (root@localhost [127.0.0.1]) by router.abc (8.8.8/8.8.8) with ESMTP id XAA22039 for ; Wed, 3 May 2000 23:48:57 +0200 Delivered-To: exmail-de-kW@exmail.de Received: from pop1.exmail.de by localhost with POP3 (fetchmail-5.1.0) for root@localhost (single-drop); Wed, 03 May 2000 23:48:58 +0200 (CEST) Received: (qmail 8455 invoked by uid 409); 3 May 2000 21:48:27 -0000 Delivered-To: medium-net-kW@medium.net Received: (qmail 8452 invoked from network); 3 May 2000 21:48:26 -0000 Received: from robin.camelot.de (HELO mail.camelot.de) (root@195.30.224.3) by plato.exmail.de with SMTP; 3 May 2000 21:48:26 -0000 Received: from robin.camelot.de (daemon@robin.camelot.de [195.30.224.3]) by mail.camelot.de (8.9.3/8.9.3) with ESMTP id XAA39885; Wed, 3 May 2000 23:47:55 +0200 (CEST) Received: from localhost (daemon@localhost) by robin.camelot.de (8.9.3/8.9.3) with SMTP id XAA39877; Wed, 3 May 2000 23:47:55 +0200 (CEST) Received: by robin.camelot.de (CameloT blkmail v1.12); Wed, 3 May 2000 23:47:53 +0200 Received: from robin.camelot.de (majordom@robin.camelot.de [195.30.224.3]) by mail.camelot.de (8.9.3/8.9.3) with ESMTP id XAA39834 for ; Wed, 3 May 2000 23:47:52 +0200 (CEST) Received: (from majordom@localhost) by robin.camelot.de (8.9.3/8.9.3) id XAA39829 for a2e-de-ffii.outgoing; Wed, 3 May 2000 23:47:52 +0200 (CEST) Date: Wed, 3 May 2000 21:44:56 +0000 (/etc/localtime) From: PILCH Hartmut X-Sender: phm@wtao97.oas.a2e.de To: FFII-Nachrichten Subject: BMWi-Konferenz: So koennen Sie helfen Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.camelot.de id XAA39826 Sender: owner-a2e-de-ffii@camelot.de X-Mozilla-Status2: 00000000 Bitte weiterverbreiten! lynx -dump http://swpat.ffii.org/penmi/bmwi-20000518/ ---------------------------------------- Die wirtschaftlichen Auswirkungen der Software-Patentierung Das Bundeswirtschaftsministerium hält am 18. Mai 2000 in Berlin eine öffentliche Tagung ab, auf der die wirtschaftlichen Auswirkungen der Patentierbarkeit von Logikalien untersucht werden sollen. Der Förderverein für eine Freie Informationelle Infrastruktur und die [6]Förderer seiner [7]Softwarepatent-Arbeitsgruppe sind eingeladen. Wir werden uns an in dieser [8]Konferenz aktiv beteiligen. Der FFII wird gegen die Ausdehnung des Europäischen Patentwesens in immer industriefernere Sphären argumentieren. Diese Konferenz ist eine seltene Chance. Sie muss ein Erfolg für all diejenigen werden, die von informatischem Monopolismus nichts gutes zu erwarten haben. Sie können auf verschiedenerlei Weise dazu beitragen. Was Sie tun können * An der Konferenz teilnehmen Die Konferenz ist öffentlich, aber die Teilnehmer sollten sich vorher anmelden und beim Veranstalter eine kurzes Positionspapier abgeben. Setzen Sie sich dazu mit uns in Verbindung. Wir haben in Berlin auch ein paar Hotelbetten reserviert. * Weitere Teilnehmer werben Dies ist eine erste und vielleicht letzte Gelegenheit für Programmierer und Firmen, sich über schicksalsentscheidende Entwicklungen kundig zu machen und darauf einzuwirken. Bitte sprechen Sie Firmen und Personen in Ihrem Einflussbereich an. Bringen Sie sie u.U. in Kontakt mit uns, damit wir bei der Abfassung von Positionspapieren helfen und bei der Vorbereitung der Konferenz zusammenarbeiten können. * Dokumention zusammenstellen helfen Der FFII stellt eine [15]Dokumentation (gedruckt und auf CD) zusammen. Wir müssen viele Verlagshäuser um Kopiererlaubnis bitten und manche wichtigen Texte sind von nicht-digitalen Datenträgern her zu erfassen. Diese Arbeit wird von der Intevation GmbH im Auftrag des FFII über ein [16]öffentlich zugängliches Forum geleistet. Ihre Teilnahme ist sehr willkommen. Der FFII ist dank seiner Förderer in der glücklichen Lage, für geleistete Arbeit Entschädigungen auf Stundenbasis zahlen zu können. Hintergrund der Konferenz Die Europäischen Patentorganisationen und die EU-Kommission beseitigen derzeit alle gesetzlichen Hürden, die bisher noch der Patentierung von Logikalien (Software) im Wege stehen. Es ist das erste Mal, dass eine Regierungsorganisation in Europa die Frage nach den Auswirkungen dieser Veränderungen auf die Wirtschaft und das Gemeinwohl stellt. Die Bundesregierung ist Vertragsstaat des Europäischen Patentabkommens und muss als solche alle Änderungen dieses Abkommens genehmigen. Verweigert sie ihre Zustimmung, so werden "Programme für Datenverarbeitungsanlagen" weiterhin auf der Liste der Ausnahmen von der Patentierbarkeit in §52 EPÜ bleiben. Andernfalls wird der Weg für die volle Durchsetzung von Logikalienpatenten in Europa und Deutschland noch dieses Jahr frei. Der FFII befürchtet, dass Logikalienpatentierbarkeit zu proprietären Standards (d.h. Blockierung von Kompatibilität durch private Besitzansprüche) führt, Monopoltendenzen stärkt, die Erneuerungskräfte hemmt und insbesondere kleine und mittlere Softwarefirmen gefährdet. In wenigen Monaten könnte eine lange angestaute Lawine von Drohbriefen und Patentprozessen über uns hereinbrechen, und Sie werden vielleicht sich daran gewöhnen müssen, einen Patentanwalt aufzusuchen, bevor Sie ihre Programm-Quelltexte im Netz veröffentlichen. Es wird dann sicherlich zu spät sein, irgendetwas dagegen zu tun. Handeln wir also jetzt. Machen wir die Berliner Konferenz zu einem großen Erfolg. Unterzeichner Markus Fleck Joerg Freudenberger Hartmut Pilch Bernhard Reiter Arnim Rupp _________________________________________________________________ http://swpat.ffii.org/penmi/bmwi-20000518/indexde.html 2000-05-03 PILCH Hartmut Verweise 6. http://swpat.ffii.org/sarji/ 7. http://swpat.ffii.org/ag/ 8. http://www.sicherheit-im-internet.de/news/news.php3?id=125 15. http://swpat.ffii.org/links/doku/ 16. http://ffii.org/mailman/listinfo/swpatdoku/ --------------AC179D27851ED6C2526ACC47-- --=-=-=-- From Klaus Singvogel Tue May 9 16:35:46 2000 From: Klaus Singvogel (Klaus Singvogel) Date: Tue, 9 May 2000 17:35:46 +0200 Subject: Patch: FAQ Message-ID: <20000509173546.A15460@Caldera.DE> Even the patch for the FAQ describes it now correct, I can't decrypt such a GnuPG generated message with PGP V2.6.3ii I'll investigate it and tell you more AFAIK more. Regards, Klaus. --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 @@ -123,7 +123,7 @@ supported by GnuPG because it is patented, but if you have a modified version of PGP you can try this: - gpg --rfc1991 --cipher-algo 3des ... + gpg --rfc1991 --cipher-algo idea ... Please don't pipe the data to encrypt to gpg but give it as a filename; other wise, pgp 2 will not be able to handle it. From wk@gnupg.org Tue May 9 18:29:22 2000 From: wk@gnupg.org (Werner Koch) Date: Tue, 9 May 2000 19:29:22 +0200 Subject: Patch: FAQ In-Reply-To: <20000509173546.A15460@Caldera.DE>; from ks@caldera.de on Tue, May 09, 2000 at 05:35:46PM +0200 References: <20000509173546.A15460@Caldera.DE> Message-ID: <20000509192922.C4283@djebel.gnupg.de> On Tue, 9 May 2000, Klaus Singvogel wrote: > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > @@ -123,7 +123,7 @@ > supported by GnuPG because it is patented, but if you have a modified > version of PGP you can try this: > > - gpg --rfc1991 --cipher-algo 3des ... > + gpg --rfc1991 --cipher-algo idea ... Watch out for the "...modified version of PGP .." - I assume that this is will be a 3DES one ;-). The GNU project does not support patented algorithms and therefore you won't read IDEA in it :-). Yes, I know that there are some countries where there is no valid patent on IDEA. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From Klaus Singvogel Wed May 10 10:57:09 2000 From: Klaus Singvogel (Klaus Singvogel) Date: Wed, 10 May 2000 11:57:09 +0200 Subject: Patch: FAQ In-Reply-To: <20000509192922.C4283@djebel.gnupg.de>; from wk@gnupg.org on Tue, May 09, 2000 at 07:29:22PM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> Message-ID: <20000510115709.A30043@Caldera.DE> On Tue, May 09, 2000 at 07:29:22PM +0200, Werner Koch wrote: > On Tue, 9 May 2000, Klaus Singvogel wrote: > > > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > > @@ -123,7 +123,7 @@ > > supported by GnuPG because it is patented, but if you have a modified > > version of PGP you can try this: > > > > - gpg --rfc1991 --cipher-algo 3des ... > > + gpg --rfc1991 --cipher-algo idea ... > > Watch out for the "...modified version of PGP .." - I assume that this > is will be a 3DES one ;-). The GNU project does not support patented > algorithms and therefore you won't read IDEA in it :-). Yes, I know > that there are some countries where there is no valid patent on IDEA. Sorry, but the FAQ speaks at this point of encryption for pgp 2.x Yes, you have to have a modified version GnuPG, but you have to use the (patented) idea algorithmen as cipher algorithmen too (and not 3des). Thats what I correct in the FAQ. I know, you can use 3des to make GnuPG encrypted messages readable for pgp 5.x or 6.x users. But that's not the point the FAQ speaks here of. Another point: I build a modified version of GnuPG: I built the idea/rsa modules, added the "load-extension idea" "load-extension rsa" lines to my .gnupg/options, and check with "strace" if the modules where used/opened (they were :-) But still I can't encrypt a message with GnuPG 1.0.1 (rsa 1.10 and idea 1.11) for a pgp-2.6.3ii user (myself). I get the error message Error: Decrypted plaintext is corrupted. If I look into the source-code I see that the error comes from the idea decryption. I currently investigate this. My current assumption is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does decryption in CBC mode. But I'm not sure, since I don't understand the idea.c completly yet. I'll tell you more, if I find the error. Regards, Klaus. -- .-. | Klaus Singvogel oo| | Caldera (Deutschland) GmbH, Naegelsbachstr. 49c, 91052 Erlangen /`'\ | email: ks@caldera.de internet: http://www.caldera.de (\_;/) | phone: ++49 9131 7192-300 fax: ++49 9131 7192-399 From az096@freenet.toronto.on.ca Wed May 10 13:13:13 2000 From: az096@freenet.toronto.on.ca (Robert Guerra) Date: Wed, 10 May 2000 08:13:13 -0400 Subject: Fwd:ANNOUNCEMENT: PGP Desktop Security 7.0 Message-ID: I'm sending this along in case people on here may have not seen it before. on first reading it looks like pgp (from NAI) is slowly morphing into a larger and larger beast. I hope that the folks from NAI follow the openpgp specs as they should so the new client can be as compatible as possible with gnupg. time will tell.. regards robert --- begin forwarded text Date: Tue, 09 May 2000 10:43:33 -0700 From: Will Price Subject: [PGP-USERS] ANNOUNCEMENT: PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today, we officially announced PGP Desktop Security 7.0. Here is the press release: http://biz.yahoo.com/prnews/000509/nv_neta_pg_1.html The beta program (which is already almost completely filled, so please don't ask) will begin this month and you should see the final version in early Q3. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 165 Alpha) iQA/AwUBORhOH6y7FkvPc+xMEQKvDwCguLKbVGyrUeevvP9hNGtem9ZKaGAAn2+B O8b6AFDrrbVt8A53oxED6IEy =OBdf -----END PGP SIGNATURE----- ..................................................................... Unsubscribe: Automated Help/Info: List Homepage: List Admin (human): Please do not send administrative commands to the list address! Thanks. --- end forwarded text -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From wk@gnupg.org Wed May 10 15:24:13 2000 From: wk@gnupg.org (Werner Koch) Date: Wed, 10 May 2000 16:24:13 +0200 Subject: Patch: FAQ In-Reply-To: <20000510115709.A30043@Caldera.DE>; from ks@caldera.de on Wed, May 10, 2000 at 11:57:09AM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> <20000510115709.A30043@Caldera.DE> Message-ID: <20000510162413.L7032@djebel.gnupg.de> On Wed, 10 May 2000, Klaus Singvogel wrote: > use the (patented) idea algorithmen as cipher algorithmen too (and > not 3des). Thats what I correct in the FAQ. If you look at the PGP 2 data formats (e.g. rfc1991) you will notice that there is indeed an algorithm indetifier and therefore it is possible to replace IDEA by 3DES (or better CAST5 which uses the same keysize and can be done very easily). Please read the GPL before _distributing_ GnuPG together with a module which implements a patented algorithm; doing so might vilolate the GPL. > If I look into the source-code I see that the error comes from the > idea decryption. I currently investigate this. My current assumption > is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does > decryption in CBC mode. But I'm not sure, since I don't understand Nope. The cipher modules are the low level encryption. The chaining is done in cipher/cipher.c and the same for all symmetric ciphers. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Wed May 10 21:08:08 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Wed, 10 May 2000 21:08:08 +0100 Subject: Solaris random device Message-ID: <20000510210808.A9104@tehran.nmrc.ucc.ie> Hi all, I just subscribed here, because the problem I'm facing now is probably not appropriate for -users ... After openssh failed when I upgraded to Solaris 8, I was looking for an alternative to egd and found Andreas Maier's random device for Solaris (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with openssl/openssh. I can generate keys, make connections, no problem. I'm now trying to use the random device with gpg, but it doesn't work. $ ./configure --prefix=$HOME --disable-nls --enable-static-rnd=linux (don't now if --enable-static-rnd=linux necessary - it doesn't make a difference if I leave this out) ... checking for random device... yes checking for linux/random.h... no checking for random device ioctl... no ... $ make check ... gpg (GnuPG) 1.0.1e Copyright (C) 2000 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: . Supported algorithms: Cipher: 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160, TIGER PASS: version.test PASS: mds.test PASS: decrypt.test PASS: decrypt-dsa.test and there it seems to hang. I'm attaching truss to the running copy of gpg and get ... poll(0xFFBED588, 1, 3000) Err#6 ENXIO write(2, " s e l e c t ( ) e r r".., 16) = 16 write(2, " N o s u c h d e v i".., 25) = 25 write(2, "\n", 1) = 1 [repeats over and over] Any suggestions? Is it possible that the current code is too Linux/BSD specific? Thanks. From Nils@infosun.fmi.uni-passau.de Thu May 11 08:53:28 2000 From: Nils@infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Thu, 11 May 2000 09:53:28 +0200 (MEST) Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie> References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> >>>"LH" == Lars Hecking writes: LH> After openssh failed when I upgraded to Solaris 8, I was looking for an LH> alternative to egd and found Andreas Maier's random device for Solaris LH> (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with LH> openssl/openssh. I can generate keys, make connections, no problem. I don't know about Andi Maier's device, but egd has been updated to work with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several weeks by now. Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From wk@gnupg.org Thu May 11 09:41:04 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 10:41:04 +0200 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511104104.A7032@djebel.gnupg.de> On Wed, 10 May 2000, Lars Hecking wrote: > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. IIRC, gpg checks that it is a character device - maybe the Solaris /dev/random is implemented as another type of device. (Patches are welcome) Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From listmaster@gnupg.org Thu May 11 10:19:14 2000 From: listmaster@gnupg.org (Lord of the Lists) Date: Thu, 11 May 2000 11:19:14 +0200 Subject: external keystore option? Message-ID: <20000511111914.I7032@djebel.gnupg.de> ----- Forwarded message from "Mikolaj J. Habryn" ----- Date: Thu, 11 May 2000 10:58:59 +0200 From: "Mikolaj J. Habryn" To: gnupg-devel@gnupg.org Subject: external keystore option? X-Diagnostic: Mail coming from a daemon, ignored Are there any plans for or opinions on the possibility of separating out the sensitive key management operations in gnupg (along the lines of ssh-agent for ssh)? I had a dig through the archives (a while ago), and recall seeing the subject come up once, but with no definitive resolution. I would like to see such functionality in gnupg; there are certain situations (such as Debian package creation) where a flexible policy engine would save a fair bit of passphrase retyping. My reason for asking is not purely academic; I recently published keymgr, an application designed to serve this purpose, whose only real claims to fame at present are a pretense to modularity and enough functionality to allow one to keep one's ssh keys on a Java ring. I've cobbled together enough code fragments to probably allow it to fake the desired effect by using a wrapper for gpg along with --passphrase-fd option (and obviously tracking passphrases in keymgr), but it's something of a suboptimal solution. m. ----- End forwarded message ----- -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From wk@gnupg.org Thu May 11 10:42:44 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 11:42:44 +0200 Subject: external keystore option? In-Reply-To: <20000511111914.I7032@djebel.gnupg.de>; from listmaster@gnupg.org on Thu, May 11, 2000 at 11:19:14AM +0200 References: <20000511111914.I7032@djebel.gnupg.de> Message-ID: <20000511114244.M7032@djebel.gnupg.de> On Thu, 11 May 2000, Lord of the Lists wrote: > ----- Forwarded message from "Mikolaj J. Habryn" ----- > Are there any plans for or opinions on the possibility of separating > out the sensitive key management operations in gnupg (along the lines > of ssh-agent for ssh)? I had a dig through the archives (a while ago), > and recall seeing the subject come up once, but with no definitive > resolution. This is scheduled for 1.1 but due to all the remaining work on 1.0 it will take some more time to start with it. I'd would very much appreciate help for GnuPG from volunteers who can sign an copyright assignment for the FSF. Without that legal paper I have to review all the pacthes and look at the idea only :-( > My reason for asking is not purely academic; I recently published > keymgr, an application designed to serve this purpose, whose only real > claims to fame at present are a pretense to modularity and enough > functionality to allow one to keep one's ssh keys on a Java ring. BTW, Brian Warner did some experiments with a PalmPilot and sent me the outline for a protocol to be used between the decryption/signing engine on some device and gpg. However, I have not yet found the time to work on it and franky I can't find it right now in my mail archives :-( Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Thu May 11 10:47:43 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 10:47:43 +0100 Subject: Solaris random device In-Reply-To: <20000511104104.A7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 10:41:04AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511104104.A7032@djebel.gnupg.de> Message-ID: <20000511104743.A10797@tehran.nmrc.ucc.ie> Werner Koch writes: > On Wed, 10 May 2000, Lars Hecking wrote: > > > alternative to egd and found Andreas Maier's random device for Solaris > > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > > openssl/openssh. I can generate keys, make connections, no problem. > > IIRC, gpg checks that it is a character device - maybe the Solaris > /dev/random is implemented as another type of device. $ cd /devices/pseudo $ ll r* crw-r--r-- 1 root sys 65, 0 May 10 01:21 random@0:random crw-r--r-- 1 root sys 65, 1 May 10 01:21 random@0:urandom $ From dichro-gnupg-devel@rcpt.to Thu May 11 11:11:14 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 11 May 2000 20:11:14 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 11:42:44 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> I'd would very much appreciate help for GnuPG from volunteers WK> who can sign an copyright assignment for the FSF. Without WK> that legal paper I have to review all the pacthes and look at WK> the idea only :-( This won't be a problem, but I'll save it for if and when I come up with something worthwhile to contribute. WK> BTW, Brian Warner did some experiments with a PalmPilot and WK> sent me the outline for a protocol to be used between the WK> decryption/signing engine on some device and gpg. However, I WK> have not yet found the time to work on it and franky I can't WK> find it right now in my mail archives :-( Hmm, okay. Failing that, my intent was to gin up a simple text based protocol to run over Unix sockets, with operations like DECRYPT ( list of valid keys ) cyphertext I presume here that gpg will know what keys can decrypt a message (by fingerprint? id? full public key? How are they identified in the message?), but won't know which ones are available. ENCRYPT key plaintext Which does the obvious thing. Would this cover the gamut of what gpg does with private keys? I am also presuming that the keystore would acquire the keys by means outside this protocol. m. From wk@gnupg.org Thu May 11 11:50:53 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 12:50:53 +0200 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:11:14PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: <20000511125053.O7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm, okay. Failing that, my intent was to gin up a simple text based > protocol to run over Unix sockets, with operations like Okay. > DECRYPT ( list of valid keys ) cyphertext > > I presume here that gpg will know what keys can decrypt a message > (by fingerprint? id? full public key? How are they identified in the > message?), but won't know which ones are available. The needed key is identified by the 64 bit KeyID. There is an option for a wildcard KeyID in which case gpg tries each available secret key in turn. > ENCRYPT key plaintext > > Which does the obvious thing. Would this cover the gamut of what gpg > does with private keys? I am also presuming that the keystore would You don't need the secret key for encryption - I guess you are thinking of signing a message. Such an agent should take care of all operations where the secret key is involved and leve all other crypto operations to normal program. The goal of such a agent should be to better protect the secret key. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From bofh@eris.phys.uni.torun.pl Thu May 11 12:55:37 2000 From: bofh@eris.phys.uni.torun.pl (Janusz A. Urbanowicz) Date: Thu, 11 May 2000 13:55:37 +0200 (CEST) Subject: external keystore option? In-Reply-To: <20000511114244.M7032@djebel.gnupg.de> from Werner Koch at "May 11, 2000 11:42:44 am" Message-ID: Werner Koch wrote/napisa³[a]: > On Thu, 11 May 2000, Lord of the Lists wrote: > > My reason for asking is not purely academic; I recently published > > keymgr, an application designed to serve this purpose, whose only real > > claims to fame at present are a pretense to modularity and enough > > functionality to allow one to keep one's ssh keys on a Java ring. > > BTW, Brian Warner did some experiments with a PalmPilot and sent me > the outline for a protocol to be used between the decryption/signing > engine on some device and gpg. However, I have not yet found the time > to work on it and franky I can't find it right now in my mail archives :-( I'd be very interested in it (as a fresh owner of brand-new Palm Vx) and also in paricipating. I've already thought of implementing something along the lines of using Palm as crypto token/engine working over IRDA/serial link. alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From dichro-gnupg-devel@rcpt.to Thu May 11 11:59:57 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 11 May 2000 20:59:57 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 12:50:53 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> The needed key is identified by the 64 bit KeyID. There is an WK> option for a wildcard KeyID in which case gpg tries each WK> available secret key in turn. Hmm. How can one tell if one has found the right key? Magic in the plaintext? WK> You don't need the secret key for encryption - I guess you are WK> thinking of signing a message. Yep, or things like signing keys. I presume that in both cases (and any others?), gpg builds some kind of value which needs to be encrypted with the secret key and returned (?). I guess the question boils down to - are there any operations that gpg performs with a secret key that can't be transformed into an encryption/decryption with some independent munging of data formats on either side of it? m. From wk@gnupg.org Thu May 11 13:08:10 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 14:08:10 +0200 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:59:57PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: <20000511140810.R7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm. How can one tell if one has found the right key? Magic in the > plaintext? Quite simple: Without the correct key you get only garbled plaintext - this is easy to detect because the plaintext (actually the encrypted session key) has some special format and a checksum. > Yep, or things like signing keys. I presume that in both cases (and All signing operations. > secret key that can't be transformed into an encryption/decryption A secret key is only needed for this: a) decryption b) signing Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From apommer@cosy.sbg.ac.at Thu May 11 14:04:11 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Thu, 11 May 2000 15:04:11 +0200 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511150411.H32456@cosy.sbg.ac.at> On May 10, Lars Hecking wrote: [..] > After openssh failed when I upgraded to Solaris 8, I was looking for an > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. [...] > poll(0xFFBED588, 1, 3000) Err#6 ENXIO > write(2, " s e l e c t ( ) e r r".., 16) = 16 > write(2, " N o s u c h d e v i".., 25) = 25 > write(2, "\n", 1) = 1 > [repeats over and over] > > Any suggestions? Is it possible that the current code is too Linux/BSD > specific? the problem occurs in rndlinux.c gather_random() at the select() in line 128: if( !(rc=select(fd+1, &rfds, NULL, NULL, &tv)) ) { this select() translates into poll(), which can be seen in the truss-dump above. However, in the source of Andis random device one can read: * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE [..] * -) /dev/random and /dev/urandom are the same (no blocking). * -) No ioctls, no poll. * * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE That seems to be the answer. One possible solution would be to skip the select() if the fact is known that the device does not block. Another one would be to improve the random device (remember, still V0.1), to provide a dummy-poll which succeeds every time. HTH Andreas From wk@gnupg.org Thu May 11 15:19:02 2000 From: wk@gnupg.org (Werner Koch) Date: Thu, 11 May 2000 16:19:02 +0200 Subject: Solaris random device In-Reply-To: <20000511150411.H32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 03:04:11PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> Message-ID: <20000511161902.Y7032@djebel.gnupg.de> On Thu, 11 May 2000, Andreas Pommer wrote: > That seems to be the answer. One possible solution would be to skip the > select() if the fact is known that the device does not block. We can't do that because we should be somewhat sure about how much entropy we got. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking@nmrc.ucc.ie Thu May 11 15:05:40 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 15:05:40 +0100 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511150540.A12177@tehran.nmrc.ucc.ie> Werner Koch writes: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. As the author has invited comments and suggestions, I have forwarded Andreas P's reply. From lhecking@nmrc.ucc.ie Thu May 11 16:18:07 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Thu, 11 May 2000 16:18:07 +0100 Subject: Solaris random device In-Reply-To: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de>; from Nils@infosun.fmi.uni-passau.de on Thu, May 11, 2000 at 09:53:28AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> Message-ID: <20000511161807.A12368@tehran.nmrc.ucc.ie> > I don't know about Andi Maier's device, but egd has been updated to work > with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by > ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't > annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several > weeks by now. Unfortunately, I am totally unable to ftp to ftp.lothar.com. Anon login is ok, but anything beyond that times out. From apommer@cosy.sbg.ac.at Thu May 11 18:01:00 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Thu, 11 May 2000 19:01:00 +0200 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511190100.N32456@cosy.sbg.ac.at> On May 11, Werner Koch wrote: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. So we used to other option and now there is an improved version of the sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ It now cooperates with gpg - at least the 'make check' does not fail or hang. Andreas From lhecking@nmrc.ucc.ie Fri May 12 23:14:04 2000 From: lhecking@nmrc.ucc.ie (Lars Hecking) Date: Fri, 12 May 2000 23:14:04 +0100 Subject: Solaris random device In-Reply-To: <20000511190100.N32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 07:01:00PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> Message-ID: <20000512231404.A10088@tehran.nmrc.ucc.ie> > So we used to other option and now there is an improved version of the > sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ > It now cooperates with gpg - at least the 'make check' does not fail or hang. Yep. Works fine now on both Solaris 7 and 8. But still, I'd like to hear some good arguments for using this device at all. I am basically unclued about crypto, but I understand that a "good" random source is instrumental. From a user perspective, is the Solaris device appropriate? Is there a danger of creating weakly encrypted files with it? Thanks a lot for being so helpful, guys, I really appreciate it! (Ok with me if you want to move this discussion over to -users) From dichro-gnupg-devel@rcpt.to Sat May 13 08:03:29 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 13 May 2000 17:03:29 +1000 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 14:08:10 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: How does the following sound? Trying to trace operation flows through the code is a little confusing, so I'm probably way off base :( There appear to be two basic parts to this - firstly, gnupg needs to find out what keys are available, and secondly, it needs to use them. Using them appears to be the province of cipher/pubkey.c. Let's assume that gnupg has found out what keys the agent has, and is now trying to perform some kind of operation with them. My first thought was to somehow overload pubkey_table so that it would have two entries for each algorithm - one as is, and one which references functions which communicate with the agent for operations. This would require minor changes to all the functions that walk pubkey_table to not bomb if the first algorithm match fails, and also hook into the dynamic module loading code to add the duplicate agent entry for each loaded module, which could be messy. Alternatively, we can assume that when gnupg is fed the agent's keys, it will receive something bogus for the secret key. When it tries to do something useful with it, it will bomb with a recognizable error (G10ERR_BAD_MPI spring to mind). We could change all the wrapper functions to note this error and repeat the request to the agent to see if it will do any better. I couldn't find any way of changing the functions called on a key by key basis, only algorithm by algorithm. Did I miss anything? g10/ringedit.c appears to be a good place to start teaching gnupg about the agent. One could define a new keyring type (rt_AGENT), and hook it appropriately in the following functions. I'm basically looking to see where rt_GDBM is special cased, and trying to work out what the corresponding operations would be for an agent. o add_keyblock_resource - simple enough, establish a connection to the agent, cache the socket fd. o search - seemingly simple, but there's some questions in my mind. The rt_GDBM case generates a fingerprint from the public key in the packet passed as an argument to the function, and uses that as a key. But... there's some functions, like find_keyblock_bysk, that (judging from the name) might not have a public key as part of the request. Why is it safe for rt_GDBM to assume that it will be there? A comment later in the code suggests that the search interface is used preparatory to doing modifications to the keystore - is it /only/ used for this? ie, assuming that gnupg isn't going to have control over the agent, can implementing the search operation be skipped? The second part of this question is where does the public key initially come from, if not search? Which ties in to... o enum_keyblocks - am I correct in guessing that this is the interface used for populating gnupg's idea of what keys are available for it to use? I'm getting a little bit lost in all the various packet types, but here's the idea floating uppermost in my mind: If enum_keyblocks is indeed what is called as the first contact with a keystore, can I get away with simply populating the KBNODE(?) with a full public key and a bogus secret key (assuming the second option for using the key that I mentioned above)? This would mean that for all uses of this key that don't directly use the secret key, enum_keyblocks would already have all of the required data to handle them. Sorry if this is as confused as I am :) m. From apommer@cosy.sbg.ac.at Sat May 13 09:59:24 2000 From: apommer@cosy.sbg.ac.at (Andreas Pommer) Date: Sat, 13 May 2000 10:59:24 +0200 Subject: Solaris random device In-Reply-To: <20000512231404.A10088@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Fri, May 12, 2000 at 11:14:04PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> Message-ID: <20000513105924.S32456@cosy.sbg.ac.at> On May 12, Lars Hecking wrote: [..] > But still, I'd like to hear some good arguments for using this device > at all. I am basically unclued about crypto, but I understand that a > "good" random source is instrumental. From a user perspective, is the > Solaris device appropriate? Is there a danger of creating weakly encrypted > files with it? Currently it is more similar to the linux /dev/urandom , less to /dev/random. At every call to the device some entropy is added (from a high resolution timer, and sometimes process id) and subsequently mangled by some hash algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. The solaris kstat interface provides access to a large number of kernel counters which can be used for that purpose. However, the "good" ones have to be determined. > Thanks a lot for being so helpful, guys, I really appreciate it! > (Ok with me if you want to move this discussion over to -users) I didn't subscribe to users, maybe I should ... Andreas From Enzo Michelangeli" <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> Message-ID: <00f101bfbcd5$f327f000$16006598@asiainter.net> ----- Original Message ----- From: "Andreas Pommer" To: Sent: Saturday, May 13, 2000 16:59 Subject: Re: Solaris random device [...] > Currently it is more similar to the linux /dev/urandom , less to /dev/random. > At every call to the device some entropy is added (from a high resolution > timer, and sometimes process id) and subsequently mangled by some hash > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > The solaris kstat interface provides access to a large number of kernel > counters which can be used for that purpose. However, the "good" ones > have to be determined. Why? Just toss everything into the pool: the total entropy cannot be reduced by adding low-entropy data. The more, the merrier. Cheers -- Enzo From dichro-gnupg-devel@rcpt.to Tue May 16 10:31:06 2000 From: dichro-gnupg-devel@rcpt.to (Mikolaj J. Habryn) Date: 16 May 2000 19:31:06 +1000 Subject: external keystore option? In-Reply-To: "Mikolaj J. Habryn"'s message of "13 May 2000 17:03:29 +1000" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: --=-=-= >>>>> "MJH" == Mikolaj J Habryn writes: MJH> A comment later in the code suggests that the search MJH> interface is used preparatory to doing modifications to the MJH> keystore - is it /only/ used for this? To answer my own question, this does indeed appear to be the case. I've attached a patch which implements some basic agent support for gnupg. Using this and a modified keymgr, I've managed to sign/verify, and encrypt/decrypt a file using the ssh key I keep on my Java iButton. This is how I get my kicks. Observations. The exercise was a little bit gruesome. The keys that originate with the agent are marked with an is_protected of 23, and check_secret_key adjusted to not try to checksum them. In addition, the pubkey_decrypt and pubkey_sign methods look to see if the secret MPI fields are NULL, and redirect the query to the agent if so. This is suboptimal, but by the time we hit those queries, we've lost all the other information about the key. Just FYI. m. --=-=-= Content-Disposition: attachment; filename=gnupg-diff Content-Description: agent diff for gnupg diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/cipher/pubkey.c gnupg-work/cipher/pubkey.c --- gnupg-1.0.1-orig/cipher/pubkey.c Fri Jul 23 22:02:52 1999 +++ gnupg-work/cipher/pubkey.c Tue May 16 18:51:47 2000 @@ -492,6 +492,9 @@ log_mpidump(" data:", data[i] ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, result, *data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { @@ -526,6 +529,9 @@ log_mpidump(" data:", data ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, resarr, data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/Makefile.am gnupg-work/g10/Makefile.am --- gnupg-1.0.1-orig/g10/Makefile.am Sun Oct 10 03:23:41 1999 +++ gnupg-work/g10/Makefile.am Tue May 16 15:58:39 2000 @@ -57,6 +57,7 @@ keylist.c \ sig-check.c \ signal.c \ + agent.c \ helptext.c gpg_SOURCES = g10.c \ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.c gnupg-work/g10/agent.c --- gnupg-1.0.1-orig/g10/agent.c Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.c Tue May 16 19:00:55 2000 @@ -0,0 +1,214 @@ +#include +#include +#ifndef UNIX_PATH_MAX +#define UNIX_PATH_MAX 63 +#endif +#include +#include +#include +#include +#include + +#include "config.h" +#include "keydb.h" +#include "errors.h" +#include "packet.h" + +static int agent_socket; + +static unsigned char *hextable = NULL; + +int agent_connect(char *path) { + struct sockaddr_un sun; + + sun.sun_family = AF_LOCAL; + strncpy(sun.sun_path, path, UNIX_PATH_MAX - 1); + + agent_socket = socket(PF_LOCAL, SOCK_STREAM, 0); + if(agent_socket < 0) + return G10ERR_NETWORK; + if(connect(agent_socket, &sun, sizeof(sun))) + return G10ERR_OPEN_FILE; + return 0; +} + +int agent_read(void *buf, int len) { + return read(agent_socket, buf, len); +} + +int agent_write(void *buf, int len) { + return write(agent_socket, buf, len); +} + +int agent_enum(KBPOS *kbpos, KBNODE *ret_root) { + char buf[600], *ptr, *end; + int len = 0, i, algo; + PKT_public_key *p; + PKT_secret_key *s; + PKT_user_id *u; + PACKET *t; + + snprintf(buf, 599, "ENUMERATE %ld\r\n", kbpos->offset++); + if(agent_write(buf, strlen(buf)) != strlen(buf)) + return G10ERR_NETWORK; + do { + int ret; + + ret = agent_read(buf + len, 600 - len); + if(ret < 0) + return G10ERR_NETWORK; + len += ret; + if(len < 2) + continue; + if(buf[len - 1] == '\n' && + buf[len - 2] == '\r') + break; + } while(len < 600); + if(len == 2) + return -1; + ptr = memchr(buf, ' ', len); + if(!ptr) + return G10ERR_BAD_PUBKEY; + *ptr++ = 0; + len -= ptr - buf; + algo = string_to_pubkey_algo(buf); + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_BAD_PUBKEY; + *end++ = 0; + len -= end - ptr; + ptr = end; + p = m_alloc_clear(sizeof(*p)); + s = m_alloc_clear(sizeof(*s)); + p->pubkey_algo = algo; + s->pubkey_algo = algo; + for(i = 0; i < pubkey_get_npkey(algo); i++) { + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_NETWORK; /* leaking MPIs! */ + *end++ = 0; + len -= end - ptr; + p->pkey[i] = mpi_alloc(0); + mpi_fromstr(p->pkey[i], ptr); + s->skey[i] = mpi_copy(p->pkey[i]); + ptr = end; + } + s->is_protected = 23; + + end = memchr(ptr, '\r', len); + *end = 0; + u = m_alloc_clear(sizeof(*u) + strlen(ptr)); + u->len = strlen(ptr); + strcpy(u->name, ptr); + + t = m_alloc_clear(sizeof(*t)); + if(kbpos->secret) { + t->pkttype = PKT_SECRET_KEY; + t->pkt.secret_key = s; + } else { + t->pkttype = PKT_PUBLIC_KEY; + t->pkt.public_key = p; + } + *ret_root = new_kbnode(t); + + t = m_alloc_clear(sizeof(*t)); + t->pkttype = PKT_USER_ID; + t->pkt.user_id = u; + add_kbnode(*ret_root, new_kbnode(t)); + + return 0; +} + +unsigned char kmsl_nybble_char(unsigned char c) { + switch(c) { + case 0: + return '0'; + case 1: + return '1'; + case 2: + return '2'; + case 3: + return '3'; + case 4: + return '4'; + case 5: + return '5'; + case 6: + return '6'; + case 7: + return '7'; + case 8: + return '8'; + case 9: + return '9'; + case 0xa: + return 'a'; + case 0xb: + return 'b'; + case 0xc: + return 'c'; + case 0xd: + return 'd'; + case 0xe: + return 'e'; + case 0xf: + return 'f'; + default: + return 0xff; + } +} + +void kmsl_genhextable() { + int i; + + hextable = malloc(512); + for(i = 0; i < 256; i++) { + hextable[i * 2] = kmsl_nybble_char(i >> 4); + hextable[i * 2 + 1] = kmsl_nybble_char(i & 0xf); + } +} + +unsigned char *kmsl_byte_str(unsigned char c) { + if(!hextable) + kmsl_genhextable(); + return hextable + 2 * c; +} + +void agent_write_mpi(MPI m) { + int len, j, textlen; + unsigned char *text, *buf = mpi_get_buffer(m, &len, NULL); + + agent_write("0x", 2); + textlen = len * 2; + text = alloca(textlen); + for(j = 0; j < len; j++) + memcpy(text + j * 2, kmsl_byte_str(buf[j]), 2); + agent_write(text, textlen); + free(buf); +} + +int agent_process(int algo, MPI *ret, MPI data, MPI *skey) { + char *end, buf[2000], *alg = pubkey_algo_to_string(algo); + int i, r; + + agent_write("PROCESS ", 8); + agent_write(alg, strlen(alg)); + agent_write(" ", 1); + for(i = 0; i < pubkey_get_npkey(algo); i++) { + agent_write_mpi(skey[i]); + agent_write(" ", 1); + } + agent_write_mpi(data); + agent_write("\r\n", 2); + r = agent_read(buf, 2000); + end = memchr(buf, '\r', r - 1); + if(*(end + 1) != '\n') + return G10ERR_NETWORK; /* laziness */ + *end = 0; + r -= 2; + if(!r) + return G10ERR_UNEXPECTED; + *ret = mpi_alloc(0); + mpi_fromstr(*ret, buf); + return 0; +} diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.h gnupg-work/g10/agent.h --- gnupg-1.0.1-orig/g10/agent.h Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.h Tue May 16 17:35:37 2000 @@ -0,0 +1,11 @@ +#ifdef WITH_AGENT + +#include "keydb.h" + +int agent_connect(char *); +int agent_read(void *, int); +int agent_write(void *, int); +int agent_enum(KBPOS *, KBNODE *); +int agent_process(int, MPI *, MPI, MPI *); + +#endif /* WITH_AGENT */ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/keydb.h gnupg-work/g10/keydb.h --- gnupg-1.0.1-orig/g10/keydb.h Fri Nov 12 23:49:28 1999 +++ gnupg-work/g10/keydb.h Fri May 12 14:18:09 2000 @@ -58,7 +58,10 @@ enum resource_type { rt_UNKNOWN = 0, rt_RING = 1, - rt_GDBM = 2 + rt_GDBM = 2, +#ifdef WITH_AGENT + rt_AGENT = 3, +#endif }; diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/ringedit.c gnupg-work/g10/ringedit.c --- gnupg-1.0.1-orig/g10/ringedit.c Fri Dec 3 03:30:31 1999 +++ gnupg-work/g10/ringedit.c Tue May 16 16:04:41 2000 @@ -61,7 +61,7 @@ #include "options.h" #include "main.h" #include "i18n.h" - +#include "agent.h" @@ -102,7 +102,6 @@ static int do_gdbm_enum( KBPOS *kbpos, KBNODE *ret_root ); #endif - static RESTBL * check_pos( KBPOS *kbpos ) { @@ -215,6 +214,12 @@ rt = rt_GDBM; resname += 11; } +#ifdef WITH_AGENT + else if(strlen(resname) > 12 && !strncmp(resname, "gnupg-agent:", 12)) { + rt = rt_AGENT; + resname += 12; + } +#endif /* WITH_AGENT */ #ifndef HAVE_DRIVE_LETTERS else if( strchr( resname, ':' ) ) { log_error("%s: invalid URL\n", url ); @@ -343,6 +348,23 @@ break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + { + if(strlen(resname) == 4 && !strncmp(resname, "$ENV", 4)) { + if(!getenv("GNUPG_AGENT")) { + rc = G10ERR_GENERAL; /* how do I make this a silent error? */ + goto leave; + } + rc = agent_connect(getenv("GNUPG_AGENT")); + } else { + rc = agent_connect(filename); + } + if(rc) + goto leave; + } + break; +#endif /* WITH_AGENT */ default: log_error("%s: unsupported resource type\n", url ); rc = G10ERR_GENERAL; @@ -760,6 +782,11 @@ kbpos->offset = 0; break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + kbpos->offset = 0; + break; +#endif default: BUG(); } kbpos->pkt = NULL; @@ -779,6 +806,11 @@ rc = do_gdbm_enum( kbpos, ret_root ); break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + rc = agent_enum(kbpos, ret_root); + break; +#endif default: BUG(); } @@ -803,6 +835,9 @@ kbpos->fp = NULL; } break; +#ifdef WITH_AGENT + case rt_AGENT: +#endif case rt_GDBM: break; case rt_UNKNOWN: @@ -1826,3 +1861,4 @@ } #endif /*HAVE_LIBGDBM*/ + diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/seckey-cert.c gnupg-work/g10/seckey-cert.c --- gnupg-1.0.1-orig/g10/seckey-cert.c Mon Jul 12 22:57:49 1999 +++ gnupg-work/g10/seckey-cert.c Tue May 16 19:01:01 2000 @@ -43,6 +43,8 @@ int i, res; unsigned nbytes; + if(sk->is_protected == 23) + return 0; if( sk->is_protected ) { /* remove the protection */ DEK *dek = NULL; u32 keyid[4]; /* 4! because we need two of them */ --=-=-=-- From bofh@eris.phys.uni.torun.pl Thu May 18 15:12:14 2000 From: bofh@eris.phys.uni.torun.pl (Janusz A. Urbanowicz) Date: Thu, 18 May 2000 16:12:14 +0200 (CEST) Subject: GnuPG with Netscape Messenger? In-Reply-To: <20000518101453.C13517@djebel.gnupg.de> from Werner Koch at "May 18, 2000 10:14:53 am" Message-ID: Werner Koch wrote/napisa³[a]: > On Wed, 17 May 2000, Paul Gallagher wrote: > > > I'm wondering if anyone has found a way to use GnuPG when using Netscape > > Messenger. Any ideas? > > No way. > > I started to do a workaround based on a local proxy used as smarthost > and pop3 host for netscape (you can enter localhost:1234 to connect to > an smtp daemon running on port 1234). This tool should do all the > crypto stuff and has to popup a window to ask for passphrases and > to select the recipient's key. > You can always use premail for sending (on *ix systems). Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From ls@Gambit.Msk.SU Fri May 19 14:26:03 2000 From: ls@Gambit.Msk.SU (Sergei Laskavy) Date: Fri, 19 May 2000 17:26:03 +0400 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" Message-ID: <20000519172603.C9570@Peru.gambit.msk.su> I hope you will be happy to repeat this: (0) I use $ gpg --version gpg (GnuPG) 1.0.1 Copyright (C) 1999 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Cipher: IDEA, 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160 $ cat ~/.gnupg/options charset koi8-r escape-from-lines force-v3-sigs honor-http-proxy keyserver blackhole.pca.dfn.de lock-once no-greeting quiet load-extension idea load-extension rsa (1) Here is the test message: -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have just uploaded mutt-1.1.12 to ftp://ftp.mutt.org/pub/mutt/devel/. =20 This is a check-point release to summarize the few changes since 1.1.11. For 1.2, I'm mainly waiting for Brendan's pending changes to the IMAP code. Season's greetings, tlr --=20 http://www.guug.de/~roessler/ -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOQH0otImKUTOasbBAQEr3wf9GOPFRB12s7Hs+XOEwQaPhiJpFPkQ5vlh S/MYOZ4UzNMhYVpqlASAQeHk2lQFP/aQscFo0ltv7cTUmHmNgPBP/1MnkuFVMXo+ M4wb69qKJytxbDurpgHES2Y/WasPGKM6Vt2sjWNCA7UsBsorg86wCdl/fwe7pCz5 kc4emPbMBo2Kw9WI3GPP3lf3XNQKi82SfA6ilAKVOjHvhOb1odoGoCQBis8P8D11 r6FoaAQsi50vsMaUVFWET4udqNCtNfDLAZFjN0iGLL436Y9jHe95+Kjuf2+Q+MXZ 9TUyjPfboB+PzyIfPgdjl56UFFsiqUM104AWXhmdGj5XWO0pjZdVFQ== =OVlh -----END PGP SIGNATURE----- (2) Here is the public key (it's also on keyservers): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.1 (SunOS) mQENAzSgEssAAAEIAMgjiiDIe0zOqjJ2TcsWXW9DYTFzyHPSYJTBHjivb0Vekmra x+M/r6U+AWM1Bf92fGWx7cMn4oYkkaMnO8LQrBXKC8IcnwrJitvh1O0xCnIqWi1E b2JOUlxRJuVYrBNgm0OxlKBCxCmKs4yvZsJ3ykClkUJmSmBV9qDpRUJqxGzyzJ97 C36mbWV/LBKamhFcuDyAmPLZPYWwijaqixXDBuC5ouEPPUmFDgkN5F2533U/imej LSEVOMIthr1qH++wx1g50imHnmKjrtwSn4zA/f++9nl5YyOP1DwZKTu+91JEJPTH aDSnKzWRk/t7lx2JfblDjxYQlziz0iYpRM5qxsEABRG0IlRob21hcyBSb2Vzc2xl ciA8cm9lc3NsZXJAZ3V1Zy5kZT6JARUDBRI38b4/CdxwOTnzf10BAW1aB/9p2gpa ggQjcB/A3kpSEPAhc+U1jP4AVFx3BIdj/yceArIdi/j87CMN5tdHMkktC9ym5/qJ wCWn5YRnl7nF8hT1tLICmO+t/vbo4X0U7kykGVNhbHNMsMpHfBT9S88BkJno1s2D GTTN1gVloDwa4aSbqW1ltRCSSZFoSwigJUQCNYU/e7HOdYe+F+kybXZPvA9L5rg7 zW1vsp0vTLglFpmjLCgaEIIFgp297eW8wmXo/IKuWAO+kNccI6Y4JCJ8+kJfqSgw y7xpvBnuyFu/8/UHcw+wL+uUMRHzrlAibPqy3k3ZwUDOkJeLL9GJaMH+KbzlNzTS tIR1Q6188D/7Hj7piQCVAwUTNyHtwAui8ZR0SloRAQGiugQAqEAoo07fFF1RFgWP J1SVmlJDLy0O2H9hkB6KJAMtds3ga9Ku5exJZfgDz1W839yM0ntgprPHmLtlVp3f ZrLwlUjcr4IXmY45myX6I1xa+TiHEQh61U1fOPzYYR9o+3acyEZE/5uEd0ve66y7 iROHZtoPyvg8uudEHA1wd9l/TwaJARUDBRA4IDMZC+VzVzZkFFkBAUpfCACAJOPE da058VbTx721fDrNxCQu6Fk5LbbP3VTutWasWgit/s1Wnr32SptVRXqsjYp5BFwV Ug0JC8rGBfB1yAG9lXJaHrGoDuqdDKbdpZRFE8UtLnVktfW51p4ZcfuQb3DVKx3Z SVIhVrKaQUt50tWpAme+6jQTjotsO3lGtuFHyhXa/3nXQG3evmagSpAmb7Uu3b/m NSy1YLNf1h6jaJZvYKjchcgE0WE7jEJ2tBFoMd1GgSRij4WN7XLkOLPpGMma/a/A 6DNyD+/UTsZbb27pQNW32KNcA4EN8Zu1npzgNcNYd7NqScjcf0wiXkqZFNHr1XSO c8/IEsxp8v+wuhikiQCrAwUQNLu+OBKt/zYZlwkHAQEyugSwpalGr4euJUpkobI/ WvrnGAqXZRj++1/IEof7x+Jl2TnOjrMLZflgCwy0E2ZaBQpQxEcAwsNfFW/i+zGg 6+ctwN9J7SxEnN2TnUNBT2l5foRx7fIVNi3AXoOd6b8xmvad/FG83utrCxUpvWnW ZMY4C6rZKCgjXtRpd9pSwU8X3QAmI8p3dfWdLxAoZxgzJZVPlewwVRwpiQCVAwUT Nx0OJRRPLUVPVwujAQHHgQP+NF0YAIL3kl+q2sa9YCUXNgCQ+mTvZb3Zzu/q3u8+ ixTowui8bLBTFY3+yIx6IzEHATcoUPCthYwnvfX4BqWNWgDFN+eWaNrZpNEfZVkW Bs6Sd0/R4AcERUcoyp48pnH77E/XS4O4b9VlFYiQV9CX+er6VD5f0ERuNiTaD9pQ Ec+JARUDBRA3JupwLHrik2A/LQEBAf9IB/9Tx58nqBfmTok8VdUQj7bZPksOTlAK WG/f8RD5johFz/OxIey3+K1agiLA+Acr8agfQMAvfxNliJIFGcVgkyYlr/zr4aRh 6e+KEjPGuYgV607be1hPm7xmjNzJklXV0ouKgFqB6kNy+FOdG2OWXrzMQO/Dbwh6 /ofToNoOdsit9mQ5HxUuq2f0TmrjVwoBQqj/QxzA1mS/KgCdsPlEF6v9BsoXyxF3 0Wbj+h+nAU3EdOWgOTexmhcpmOvKx5bW766mB+zAdpj9c33xAMU9lt6bIIcD3cxJ fs7s9ZhWlczoarpUwU+BoKE0dMfvs6cf6NPcTrODqvCUAJwYCR42KZdZiQC1AwUT NKATSj4lAO9ZMjjhAQFvHgT+Ol0myw6jILx78keIEDdJy/fxdK6T56XUYX8nNez3 Ibm300bT63yvEnD3U6pgN+sEyzuLxP/L07Jk2E3OHJHLXJpLHWQlebW3ey9EEaYV xjClSFrmidc0Jd5nMAFmssJ9AHuENKvO096yHTMvH3MYIjYJ1HfyDUnIVDwFL8KF 4fwQezrtMwWzt8WSjWEbGmXZXW7kZ1lBnL8f6eYvCigFYYkAlQMFEzSvti9Dr0FE 3QjdbQEBPdYD/3zZLNh9rPPQ4pZ/0HfQr88BBrjIdKIXuEaZbkfiohuKf44RqOdt k832Mmb2yrp6i8IN8UHPPTpM7xfvmab2Rk21SxRZJ0IsbXzYVSP1oxdE3lIOyVlB vtn1FXEU9JuGD8N9dM994Yirg/2EfjpPJ7SdRMIdtrFAzagJvAvmdk7iiQCVAwUQ NO2N7knh/jPvZzKNAQFdlgQAlGd9mSgxjv6Id8FZ3lMhU0RzKvHNFRof985lkyJt R/01qAJZbCxeJB2y5diLw6qZaVw6+hCqgP5Bbw8PPtKr7i/OvAXBPgoU5Ume4J2A EsavEmavAJ90Zph0WK2BzqCQd1EP5M2jqdBATDunL67rJ5bk0l7y/KwgM5NhyCmY FNmJAJUDBRA0xeJJTFllIALEMQkBAdTfA/42FNAByvEHM9pRkK4qftVDSnIIZeRP uIfV+mO4FcNE9h/oH3nBSOUGn7NqsjwJuj4daZ2tmWfH41D8oQjPVqdM4fd0csYk FZLI0qu1wTd8MxEJsHoh5qIU8M6ywL5pIflhOP1wGf6omqBh2VZuhYY6m0775Lih A0c/DLokymQ6C4kAlQMFEDccqjNMo00siEncPQEByDcD/3cUDPeFBlzq5SSKANRA emT0HoW+aoUO+bRavqOzwCuYNhkSNx7yukACFc8fu13vlBpHL39RLJC6zT+8rto1 MH3SLnJNJj7FH8NZUQDffwXXea3eydNCx0T9fVu0QBndPvyib6K3oVD/Z6yirbo+ pNZnn6U8aOrEXf18IizhhBdxiQCVAwUQNvYNv1H8PGQHafT1AQGBrgQAhWdZ9ws2 EIh8LJEAb53FHcjonandcJ7HDgLo3GpWnhIvhcc+YKQluW/8lS92bsjY3tVRfDYe Y80NjEODDgn+CEcOu9LqssGj4CwuU7b58tBdSIV1v7CSX9cTM9+0r0qGU7ql7Lpn zBqhx36UXqOK6vfU0cWrHLkPUNlms2a96LeJALADBRA3TTnyVmSU4zFmVdUBAZlh BNEBfEm35/lKlMV3hlFMT/K7ZhddrptYh+vCGhJNSO48KD+6foES7zgAH8k1j1Wh A2b4oVG7X4x5T603UqGDFpaycddqxGc7Bs7E0aAVygEkoJQ6c8AjSkyy/lRnGZ1G ln7vPNM8TokQJQRKfkm/tPpE1jneaU/j102We0jg2ULyJQOLB73acI/v5O4p1d1F +W5S3XySxxDcbOWJjYkAlQIFEDUZVnh4YVpjdyds6QEBU2sEAKjJkcCiOqnyh7I7 O1PIVbEWumltWd5CXDT2MwMXX5vOGex//qERDNDqR4w1ksPj3NVOkSaVFQMjw2Ys zBFFHma45LZPSxv2UGxjII8qPPgPmkllLyhHCGrDRY+IZ0Wax+HFfJe3g6xYYgCl ojNVd1chV9eduNZLxdvhV4YKVSHMiQEVAwUQN1PmOH4v6i2JDAmBAQEP3Qf5AYd0 ytzQB36MJHx+jHismpNsJEGj/rQ8PxeWnic9GkcgBi97wflQaldonFlvoeNFyIwS MTLs2vZTeCRLMxc1LFnwurx8/2oks9xp63733Rqs9DonnkDQR04YWLkw4djTaEDc /GWHCyYiPj11G/12b09ywf4nPd32K8AVoIQAPQy5P4GRhesQTvWTl1yXLEVWjv6g PLJUo3l1BrIKm+GMdnlBqTGpswPtkxeUqp8mjYdwnmm5ajX/qkxe1UE/t5V74169 uTL1+DjEl3CT+rVR6UtEc2qM3Zg2PTzgjmrFfHeUdXv1QBfRJlhmtPQtRX4csDFP fX0sO5n5PZpYcYlzC4kBFQMFEDTFOAt+8FjoQyMUJQEBjpIH/3Uwc8cMr8RAie00 9a7536V2x2miBAoTAjsb5ui91geM4ssXgilUgB/sBW/bV6cZA67Q7YYSollFSKPb LhmoZUEvkf+cS6cdojUbq2p2pd7Djq3ZSYNTRbIKo8KWBLSfSuDsxdu0oVdW3DO2 5TMzkauxNnqMegWjLSRCMRigdQYYmZKrA9tY6hD63c6eLt2DAWuF+pepwo5N6jm7 yGHWAW0ihhqv+NHlIc3JExxxzDYeTjC4Yb5dfHpYG7ETbsMZCQ77Ru1isbcA557/ kgSwKPUt0LAMgVj9atG4OIezjwPubEV/SxvcRnjEKsQOQe7WriLcPjeELlMvakBc nDS7NtqJARUDBRA29l83fvTWwzbkE20BAc0HB/sGlryh+m+UJR5TjI7cMf13UnFh vL88TIRLGxVwsOYoKixiU1hPecGFWcXsnYue6Hduvb9EiBdn3GQcKQAda0TtCXoJ 6gmph8xx7cGqSGd1ldh1nkWbGsCt82HcK7XQ0qF/zUTuRwxi7F30YI5ZBYBLOVsn dB7rMm4ObkHH0nskMMMfZ1VcsT5ndvKL2RvevRaleXob14erDDsEmqKzPMRpyTKO CAMnK5k86P8uK+8hg39rLSQodPKzxvtyJNEDt3iizQ+Ac1nlPIeO/pN7CnqJwu5T codS9bVe9A39gIqhbCp8zYjKD+uU+8tOGYthuU2FvgDaB0NU+pzSaw2X2se6iQCV AwUTNK/OIokABLrCbuiRAQGsdAQAxOh0ipz4H80XifbWjh+W721oIwXGjBl/n/e/ UJh7cqzqZxo+I/vR3O0wCfnkeQ94ihe24eamvEvwvWbpRmnfqozp2Fuo9JcazgML j0eDmqZCe0XJEi4t3WdIavy59XskuzPaM8AepRKULStKup22o5jgvOnK6/2KcYmx oKULfeCJARUDBRA1EBSciVPDw6koVP0BAQkvB/wN1M5oadLBjOIgm34y1qtxnkvF ZuPIJIWVVX+3Fz2FwZ84OIqVtNGxjKAOkyFG371+wEXc7xZZ9owSCO2edVTCC2wL 2mDFostS7G4aTDWvXMx0lWTTc8V2RZTOQ8bGJDo+6HgFNg4gV/03MpPqB413yVas XseES/yCt+haLnk85mO8KVSGP7DAdwJn5tLx3GKHZE3Qh9XTJ0j4V/9uG8ohf94T O63s0V/3ZAMUK8GaP4kiC5d4ZEN+4DyHw6xjYTmrRp3tvXKJrUHaSnCXaS7Obr2C DO5LyRi07qMrkHAxjmDMdJYHyS9SEPqphx+/1TyYZQx1edrlLiY31YSFEpH+iQCi AwUSN/G+HpFeTizbCJMJAQFzUgRmN7+0sKxmW7m5MBaB2dHnOpoya6Kxzbp3oghW 8cX4+DOI4zukBDWvEnnreCnbl4dFoTr38+GoG336NozKhKvx5kvSqBzL6XpzXrT6 OTg/b2NGiFpSR0QKNJtNSUUwGwSVDa1Yqqn0FMmFGAeI08p+VeMXLpwjDWXsvRYr 9S+fVY+jDNeFRv7yOUFOZTstiQCVAwUQN29YLpznb919i1kZAQEDSQP/bbq6SB16 jS7IjIcUHHvhHZ3aXmFkx55kcKPnBZrzPOAN9R6jFDS1wu0ejxVPNp6iGzODq2tz UPv5HJfWufxMaxHpnHQ6J5+EwpLQwWj2PrSQg6idNA4W/0eFLi0SOlFj8JAXt69j fkl/K4R/kiNPVL2FVWQMCOLtYVxTbkf6XxqJARUDBRA28ZJ5nnPrCk1Y7lEBATqQ B/sGsKnPF45GKF7Yu/3dNwQD38g5Qpj8+7ddPcjME7tmkD8BHFR6o6bDtv7zWeEF uxg+XjAxg4dPSHrAXdKZ5SDHqJO7+GbZP/eP7zoGw4V1GVnCz0e0v2WXUfe56oFu oO/4XRrbsWhAtYPGeYi9BO/XRDIjDmjvFvjitjwIgxzUb/t6DqPMHchRpK1MOTWs bvUOb8Dz2U8YusH/G5puw2AemLyeXx6erZJm385bcAzgoP+tp4fA6SjSlQs9FD7J Y4goyBv534fluGGHth+nuIB2jn+zHOkcUgAgOJPSGmZSsSxXKQxfL1Xr1SdNbT16 i2VOIu7MWkceillxJUMIHE7ziQCVAwUQNMZ9G7Btxkr72ChhAQFIuwQAigFlRtsE jhtOXv9+Ot2gqKbqfj2TkOTCpr4HRlFGDzkIkbBZsp8q2Af5ZiQ7/h/g1asqbvzK J6XTWQo6K0U9iiasWYpXlUlrlVhMjm3hUrGLaMglGcnURemVHhhfS3S/4aggJqW6 Dt5U10txXrAdKfegU0+HEJ5L6WuKaulDxViJARUDBRM02HCwvqaOf4UxMn8BAfIb B/4omzocwa8eHPZgsuwq9pkU69qtJmndgxAxzSivSfd8UV3rVKquxIfPWTJuBuug EleQlskVASKiQVKubgSpP7VcyHimzgPt9w/RKLDpDAGAzZh6r9PX3BxdKxaig2Ny eiCmLYv7oZG6nOFa1xaPYmjxVDOwT39kZE36O2Boe5rW2Jj+GG/Iwxt4iGToXyZW Gz7uXP/Ar3O+kjQzgg14ieFkyOQYuI1Br/9ZCMIFwjHXfQsXRYP+ftTLi9DYfTXh G0bP+bc1FdiRLjM4IHYJ9ydl2p/1TL01ZO6eb9DB+a9esjXfb//frYCRFNPKoV/A b4TgVWYqAJlLczLEwfBkbkZgiQDVAwUSN/G+Xb+Ot2lXSNSVAQFEaAX9FQjXrDRc /FqkeiBNievdgVt03Lrm2XYkKnnvh059M7i+S/tVW7ly3sifvM1J4X2hvT9jbhb0 lD0gISXz85n7pHMpf4cxJpTnMefRBKFoDA2AYLUHL8Rq+VOKkdPM8pCgySU69Ssu ZPrK7kOByWiU8VeekL1+7236QrstzE+P8ePygXb6hrQZXzgClVq9DfVu3r5BRagU za/CDfuECEoRrdCPNOTOcC2PbdJjtLQIAm8m+llYXkd0Ij3zhB1HAISwiD8DBRA0 3w93xiLu3cOF4DcRAoYMAJ9AxHy1WoKMNp5BtD7bJVPiWmXXjwCfcaeh4TirEQLm aMT+TdecW0Nv1E2JARUDBRA0oBMs0iYpRM5qxsEBAUT8CACbuZBD0zuWHTuqTvEY MIuO/VJL0f+op9IwpMjD2W8EzXa5XEq4WoCdff9YzSZUT/T6Sy2ZcercLgthJRcr gQowZAQvn3UDnbF7OpPv3cblapmb2lvIDhJESco/I1R08kZN905bFmkcF1sNXsjf 6B+K2N2BSizbE2aS8xIJ+tuRDGeS1Gsai1e+impbGbVQiO4lUQlAOZeJPQ7IOtED yEHUjWw1FsOq/x9GNZMMxIqN/BagsqpA7eHJ76fsMQN1f0kh3oepaN3lZ7xqoSGE MIpf/eCzawGwlrEA3aROCjr33+hHzimIj8rtuxKUAo0jvNs8Wg3V3mXW/QgWhW1y hfLAiQCVAgUQNK/96fE8+WC3TbWNAQF40QP9Fq0LhANCSh1cQFqxIbCtzgyEm0ZL Ujx0fFE9onyE0/Jnuh+3fvRGde0UxzEfrTqf3Z+1hxYDtnuxcRUTlVSFRJfvO3g9 b+fcw08BG8hLpexQ1Jl27rEQEnxu3kyxtw+WkxDw/JMzf0bPG7rz4Rp2UbwOvFCY 1mLh+fsl4QvdnGCJAJUDBRA0sj2j9e+XfZ71UOEBAT9VBACeGQsN4aabBhcJlQIV XO9MlDY5ioWgRgAS/WCLgXf5FNvT5hVKv/WNHoe4VLQjJQE17MocrU8MpYxkoXBk JgNLfMl+hp7wACHXvn9m5MTJFJuRx3uuuyNi5Tyjhtovpn6MUn3nSxLID/F2XMMo Vfhu0Pz0V+DHMa2kVl1U/Xa+wQ== =jubg -----END PGP PUBLIC KEY BLOCK----- (3) Start gnupg by $ gpg < /path/to/saved/pgp-message gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK ^C gpg: some signal caught ... exiting -- Thank you! From wk@gnupg.org Fri May 19 15:38:46 2000 From: wk@gnupg.org (Werner Koch) Date: Fri, 19 May 2000 16:38:46 +0200 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su>; from ls@Gambit.Msk.SU on Fri, May 19, 2000 at 05:26:03PM +0400 References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: <20000519163846.M14819@djebel.gnupg.de> Hi, iirc, this has been fixed in 1.0.1f - can someone please test against this version. tia, Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From offby1@blarg.net Fri May 19 22:12:55 2000 From: offby1@blarg.net (Eric Hanchrow) Date: 19 May 2000 14:12:55 -0700 Subject: How to deal with old RSA keys In-Reply-To: Dr Lyman Hazelton's message of "Fri, 19 May 2000 13:45:14" References: <3.0.3.32.20000519134514.0099abc0@mail> Message-ID: <8766saz1k8.fsf@potato.hanchrow.org> >>>>> "Lyman" == Lyman Hazelton writes: Lyman> But I have an old RSA key that's been kicking around for a Lyman> long time and I didn't have a die-date on it. I still want Lyman> to be able to get messages written to me with this key. Is Lyman> there a module that I can add to gnupg that will allow me Lyman> to do this? Not everyone is switching to gpg and I still Lyman> need to hear from them in private. This should really be a FAQ. If you're using Debian GNU/Linux, then all you need to do is install the packages `gpg-rsaref' and `gpg-idea'. Then add these lines to ~/.gnupg/options: load-extension rsa load-extension idea -- PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5 C8BD 6337 0041 C01C 5276 From sroberts@uniserve.com Fri May 19 01:03:57 2000 From: sroberts@uniserve.com (Sam Roberts) Date: Thu, 18 May 2000 20:03:57 -0400 Subject: Solaris random device In-Reply-To: <00f101bfbcd5$f327f000$16006598@asiainter.net>; from em@who.net on Sat, May 13, 2000 at 08:22:18PM +0800 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> <00f101bfbcd5$f327f000$16006598@asiainter.net> Message-ID: <20000518200357.B471@localhost> On Sat, May 13, 2000 at 08:22:18PM +0800, Enzo Michelangeli wrote: > ----- Original Message ----- > From: "Andreas Pommer" > To: > Sent: Saturday, May 13, 2000 16:59 > Subject: Re: Solaris random device > > [...] > > Currently it is more similar to the linux /dev/urandom , less to > /dev/random. > > At every call to the device some entropy is added (from a high resolution > > timer, and sometimes process id) and subsequently mangled by some hash > > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > > The solaris kstat interface provides access to a large number of kernel > > counters which can be used for that purpose. However, the "good" ones > > have to be determined. > > Why? Just toss everything into the pool: the total entropy cannot be reduced > by adding low-entropy data. The more, the merrier. Yes, but the implementation of /dev/random so that it blocks until sufficient entropy is available, requires an estimate of randomness of input. Some statistical checks are done to estimate this, but when data is put into the pool it is identified as adding to the estimate of bits of entropy in the pool, or not. GnuPG, for one, attempts to select() until as much entropy as it wants is available. This entropy estimation seems important, though fairly fuzzily defined. Sam -- Sam Roberts, sroberts at uniserve dot com, www.emyr.net/Sam From tyketto@wizard.com Sat May 20 09:42:38 2000 From: tyketto@wizard.com (A Guy Called Tyketto) Date: Sat, 20 May 2000 01:42:38 -0700 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519163846.M14819@djebel.gnupg.de>; from wk@gnupg.org on Fri, May 19, 2000 at 04:38:46PM +0200 References: <20000519172603.C9570@Peru.gambit.msk.su> <20000519163846.M14819@djebel.gnupg.de> Message-ID: <20000520014238.A30251@wizard.com> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 19, 2000 at 04:38:46PM +0200, Werner Koch wrote: > Hi, >=20 > iirc, this has been fixed in 1.0.1f - can someone please test against > this version. >=20 > tia, >=20 > Werner Has this been released/uploaded yet? I'm not seeing it, at=20 ftp.gnupg.org:/pub/gcrypt/devel. 1.0.1e is still the latest and greatest=20 there. If it's located at another place, please let me know. :) BL. --=20 Brad Littlejohn | Email: tyketto@wizard.com Unix Systems Administrator, | tyketto@ozemail.com.au Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5Jk/+yBkZmuMZ8L8RAnkaAJ9Ksu1gNeCOn2Fk1ePmWsRgoNQvOQCZAZmM xnVmuHNaxcePKFhNNH1DwaM= =t6Ko -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From hideki@allcity.net Sun May 21 00:31:18 2000 From: hideki@allcity.net (Hideki Saito) Date: Sat, 20 May 2000 16:31:18 -0700 Subject: Windows version of entropy.dll problem Message-ID: <200005202329.QAA19377@server-1.visp.net> I have one bug report (among with fix) in entropy.dll which is distributed in GNU Privacy Guard for Microsoft Windows which is in the download page. It is that in certain circumstances; most visible in Windows 2000, it crashs when it is executed to generate keys, it crashs. This problem is solved after I compiled entropy.dll from sourcecode using Microsoft Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll Thank you. -- Hideki Saito mailto:hideki@allcity.net From hideki@allcity.net Sun May 21 00:41:15 2000 From: hideki@allcity.net (Hideki Saito) Date: Sat, 20 May 2000 16:41:15 -0700 Subject: CC Request Message-ID: <200005202339.QAA20452@server-1.visp.net> Sorry for bother about this with separate mail, but please CC me if you have questions or comments about entropy.dll, since I'm not subscribed to the list. (is there anyway I can subscribe to it?) Thank you. -- Hideki Saito mailto:hideki@allcity.net From wk@gnupg.org Sun May 21 18:22:36 2000 From: wk@gnupg.org (Werner Koch) Date: Sun, 21 May 2000 19:22:36 +0200 Subject: Windows version of entropy.dll problem In-Reply-To: <200005202329.QAA19377@server-1.visp.net>; from hideki@allcity.net on Sat, May 20, 2000 at 04:31:18PM -0700 References: <200005202329.QAA19377@server-1.visp.net> Message-ID: <20000521192236.D3283@djebel.gnupg.de> On Sat, 20 May 2000, Hideki Saito wrote: > It is that in certain circumstances; most visible in Windows 2000, it > crashs when it is executed to generate keys, it crashs. This problem > is solved after I compiled entropy.dll from sourcecode using Microsoft > Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll I am in the process of reqriting it without the need for DLL. I hope to commit the changes on Thursday or Friday. However a lot of new testing will be required then. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From rguerra@yahoo.com Sun May 21 18:54:59 2000 From: rguerra@yahoo.com (Robert Guerra) Date: Sun, 21 May 2000 13:54:59 -0400 Subject: GNUPG & AES Candidates In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> References: <200005202329.QAA19377@server-1.visp.net> <20000521192236.D3283@djebel.gnupg.de> Message-ID: Werner: I'm forwarding you a message I recently posted on the pgp-user's mailing list (http://www.cryptorights.org/pgp-users) . I'm curious to know if you are considering adding any additional AES candidates to gnupg. regards robert Date: Sat, 20 May 2000 22:45:31 -0400 From: Robert Guerra Subject: Re: [PGP-USERS] PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org Tom: At 8:49 PM -0400 2000/5/20, Tom McCune wrote: >I found the following at: >http://www.pgp.com/asp_set/products/tns/pgp70_reqts.asp > >>Cryptographic Algorithms Supported >> >> Public key algorithms: Diffie-Hellman/DSS, RSA >> with up to 4096-bit key lengths nothing new here unless 4096 applies to RSA as well. >> >> Symmetric algorithms: CAST (128-bit), 3DES >> (168-bit), IDEA (128-bit), Twofish (256-bit) twofish is new...but it hasn't won the AES competition. Can the Rijndael cipher be added too? I believe that the other AES finalists should also be included. It would make good sense to at least keep the others in mind in case Twofish doesn't win. After all, it would be nice if PGP v.7 could have the AES winning candidate. For what it's worth.. At our Toronto May cypherpunks meeting, it was mentioned at that the Rijndael cipher was well looked upon, and a favorite of many at the april AES conference. As it's invented by a group in Belgium it will be interesting to see how it plays politically in the selections process. After all can the americans seriously consider to accept and deploy something made outside the USA (NIH - not invented here, not good) >> >Any other news that can be shared on related changes would be appreciated. Some references: Video Report of The May cypherpunks meeting in Toronto (Canada) http://www.epress.ca/privacy AES Round two AES Round two analysis AES Second Round Implementation Experience The block cipher Rijndael -- -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From Nils@infosun.fmi.uni-passau.de Thu May 25 15:02:03 2000 From: Nils@infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Thu, 25 May 2000 16:02:03 +0200 (MEST) Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: <14637.12891.65451.656522@skrjabin.fmi.uni-passau.de> Hi all, we've had quite some discussions on this list about the various random "gizmos" available on Solaris 2. I'd like to summarize the possibilities and then make a suggestion. The need for entropy is not a domain of GnuPG alone; OpenSSH needs it as well, and there may be others coming (BTW, I've heard rumours that the OpenSSH folks are considering to use gpg keys instead of their own user-level public keys. Does anyone know more details?). There are currently three options that I am aware of: ======================================================================= 1. Entropy Gathering Daemon (EGD) Available from http://www.lothar.com/tech/crypto/, latest release is 0.8. This is a perl script running as a daemon, providing an entropy source through a pipe. EGD is supported by both, GnuPG and OpenSSH by means of a configure option. The latest release even works on Solaris 8. It works very well, the only drawback being its speed: if you need a lot of entropy (generating keys, multi-user platform), egd might be a bottleneck. 2. /dev/random as provided by Sun package SUNWski This software was developed by Sun as part of the unbundled product Sun Webserver 2.0 on the Solaris Easy Access Server 3.0 CD. This product was supported for Solaris 2.6 and 7, but not 8 (because Sun is now using Apache or Netscape's web server). However, the SUNWski package still works fine on Solaris 8, provides entropy much faster than egd (it's a daemon written in C) and was reviewed to provide high quality entropy: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=95618127814224&w=2 SUNWski's /dev/random is natively supported by OpenSSH, but in order to use it with GnuPG, you have to apply the following patch. That's because SUNWski provides /dev/random as a pipe, and not as a character device. The patch is relative to the current CVS snapshot of GnuPG. As SUNWski provides only /dev/random, the patch assumes a link from /dev/urandom to /dev/random. diff rndlinux.c.orig rndlinux.c 86c86,92 < if( !S_ISCHR(sb.st_mode) ) --- > if( !strcmp(PRINTABLE_OS_NAME, "SunOS")) { > /* Solaris 2 Easy Access Server -- SUNWski */ > if( !S_ISFIFO(sb.st_mode) ) > g10_log_fatal("invalid random device!\n" ); > }else{ > /* Linux , xBSD*/ > if( !S_ISCHR(sb.st_mode) ) 87a94 > } diff configure.in configure.in.orig 447,458c447,448 < [case "${target}" in < *-solaris*) < if test -p "$NAME_OF_DEV_RANDOM" && test -p "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < *) < if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < esac]) --- > [if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then > ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; fi]) You would then use the random device type "linux". However, this patch breaks the use of the 3rd option. 3. /dev/random and /dev/urandom by Andreas Maier This is a new port of the Linux kernel random driver to Solaris 2 as a kernel module (what Sun should have done in the first place!) from http://www.cosy.sbg.ac.at/~andi/. It's very new, therefore hasn't been reviewed regarding it's entropy quality. As this is a clone from the Linux port, both are character devices. Therefore, the GnuPG sources don't have to be patched at all. You just select "linux" as the random gatherer. I've tested it on Solaris 8. I didn't recompile OpenSSH for this, but a quick look at the sources suggest that it should work there as well. Unlike GnuPG, OpenSSH only tests for existence and readability of /dev/random, but not whether it's a pipe or a character device. Being a kernel module, it should be pretty fast (didn't try). Personally, I would like to have the source reviewed by someone who knows about entropy gatherers before I'd use it in a production system. ======================================================================= Proposal I'd like to see GnuPG being a bit more flexible on this issue and therefore avoiding the need to patch it. I think that taking the OpenSSH approach (testing for existence and readability of /dev/random and /dev/urandom, being still happy if the latter doesn't exist, and don't test the type of the device; suggest the use of egd if the devices don't exist) should be OK for GnuPG as well. The naming of these random gatheres as being "linux" is a bit unfortunate, but that's just cosmetics :-) Any comments? Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From sam@cogent.ca Thu May 25 15:25:37 2000 From: sam@cogent.ca (Sam Roberts) Date: Thu, 25 May 2000 10:25:37 -0400 (edt) Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: Previously, you (Nils Ellmenreich) wrote: > Proposal > > I'd like to see GnuPG being a bit more flexible on this issue and > therefore avoiding the need to patch it. I think that taking the OpenSSH > approach (testing for existence and readability of /dev/random and > /dev/urandom, being still happy if the latter doesn't exist, and don't > test the type of the device; suggest the use of egd if the devices don't > exist) should be OK for GnuPG as well. The naming of these random > gatheres as being "linux" is a bit unfortunate, but that's just > cosmetics :-) > > Any comments? I'd like to second this proposal, particularly about not forcing /dev/random to be a character device. I ported Linux's random to QNX4 and Nto, and I took the approach of making them look like character devices so gpg would recognize them. I don't really think they are, any term control ops on them would fail, a named pipe or a QNX named device would have been more natural. The term linux will be increasingly a misnomer, I believe the *BSDs have a /dev/random as well, for instance. Sam -- Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca) "News is very popular among its readers." - RFC 977 (NNTP) From koch@hsp.de Thu May 25 16:37:26 2000 From: koch@hsp.de (Walter Koch) Date: Thu, 25 May 2000 17:37:26 +0200 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su> References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: Moin, am / On Fri, 19 May 2000 17:26:03 +0400, schrieb Sergei Laskavy wrote: >$ gpg < /path/to/saved/pgp-message >gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 >gpg: Good signature from "Thomas Roessler " >gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK tested it with gpg (GnuPG) 1.0.1f-snap2000-05-25 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: Warning: using insecure memory! gpg: Signature made Sat Apr 22 20:51:14 2000 CEST using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " The NOTE: is completly gone! Gruss, Walter -- Walter Koch Hochdahl am Neandertal http://www.hsp.de/~koch/ qrv:db0iz-9 walter@1409.org ham:dg9ep@db0me koch@hsp.de From bem@cmc.net Thu May 25 22:39:15 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 14:39:15 -0700 Subject: Clearsigning (again) Message-ID: <20000525143915.B24700@cmc.net> I know there is very little in the RFC regarding clearsigning and that PGP-MIME is better. But Network Solutions wants clearsigned (and so do many Usenet readers since multipart MIME is evil on Usenet), so I need it to work properly. >From the fine man page: -t, --textmode Use canonical text mode. If -t (but not --textmode) is used together with armoring and signing, this enables clearsigned messages. This kludge is needed for PGP compatibility; normally you would use --sign or --clearsign to selected the type of the signature. But this doesn't wholly work. [thorin:~] 2:10:46pm 193 % echo foo | gpg -t --armor --sign You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 foo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5LZbaN3/OJIgyK1ERAm/3AJ99ETFfFOvIS+necd4awNO5S255EACghazh p9oyByxGr6xctlsQTU7C4zk= =myQV -----END PGP SIGNATURE----- The problem is that with PGP, the same sort of thing will have an empty line after the 'foo'. PGP5 will verify the above, but it will be missing the end of line: [thorin:~] 2:12:53pm 200 % ls -l foo -rw------- 1 bem bem 3 May 25 14:12 foo [thorin:~] 2:12:56pm 201 % od -x foo 0000000 6f66 006f 0000003 The trailing newline placed there by 'echo foo' (which emits 4 characters) is gone. Again, I realize that RFC2440 isn't clear at all about 'clearsigned' messages but I believe interoperability is important. How does the above behave with PGP6? If it behaves as PGP5 does, then I think gnupg needs to change. The relevant wording in 2440 I see is: The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. That seems to imply "insert an extra newline here when signing and discard it when you verify". There is also a problem in lines ending with TAB (which, alas, I know because NSI seems to send forms with TABs at the end of the line for reasons known only to them): [thorin:~] 2:15:13pm 211 % echo "foo " > foo # that's a tab [thorin:~] 2:15:14pm 212 % gpg -t --armor --sign foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 2:15:25pm 213 % pgpv foo.asc Opening file "foo" type text. BAD signature made 2000-05-25 21:15 GMT by key: 1024 bits, Key ID 88322B51, Created 1998-10-17 "brian moore " "brian moore " "brian moore " This seems to be contrary to RFC2440: Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Spaces at the end of the line -are- ignored correctly. But tabs are not. If there's consensus that these two things need fixing, I'll submit a patch, but so far I've had no response to these even being problems. :( Again, both of these are needed to work with Network Solutions, which is why it's annoying me. If I manually ":%s/^I$//", and insert a blank line at the end of my forms, yes, I can then submit them to NSI and have them verify, but that seems goofy. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem@cmc.net Thu May 25 23:08:29 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 15:08:29 -0700 Subject: Clearsigning (again) In-Reply-To: <20000525143915.B24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 02:39:15PM -0700 References: <20000525143915.B24700@cmc.net> Message-ID: <20000525150829.C24700@cmc.net> On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > This seems to be contrary to RFC2440: > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > any line is ignored when the cleartext signature is calculated. > > Spaces at the end of the line -are- ignored correctly. But tabs are > not. Ah, oddly enough I can make it do this -- but I have to specify '--rfc1991' to do it. It still strips the \n at the end, and I'm not sure why the --rfc1991 is needed, since RFC2440 requires it as well... -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem@cmc.net Thu May 25 23:36:45 2000 From: bem@cmc.net (brian moore) Date: Thu, 25 May 2000 15:36:45 -0700 Subject: Clearsigning (again) In-Reply-To: <20000525150829.C24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:08:29PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> Message-ID: <20000525153645.D24700@cmc.net> On Thu, May 25, 2000 at 03:08:29PM -0700, brian moore wrote: > On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > > > This seems to be contrary to RFC2440: > > > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > > any line is ignored when the cleartext signature is calculated. > > > > Spaces at the end of the line -are- ignored correctly. But tabs are > > not. > > Ah, oddly enough I can make it do this -- but I have to specify > '--rfc1991' to do it. > > It still strips the \n at the end, and I'm not sure why the --rfc1991 is > needed, since RFC2440 requires it as well... Continuing to follow up to myself... :) I see why. It's a bug of PGP5. If I manually strip the tab in the clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not recognizing that it should ignore trailing tabs on input. (And this isn't documented in the 'Implementation Notes' in 2440 with the other PGP5 bugs... Can someone on the IETF committee see that it makes it into future revisions? :)) But the dropping-the-trailing-newline doesn't require PGP5, so I'm still convinced this is solely a gnupg problem: [thorin:~] 3:34:15pm 288 % echo foo > foo [thorin:~] 3:34:20pm 289 % md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo [thorin:~] 3:34:27pm 290 % gpg -sat foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 3:34:44pm 291 % gpg foo.asc File `foo' exists. Overwrite (y/N)? y gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 gpg: Good signature from "brian moore " gpg: aka "brian moore " gpg: aka "brian moore " [thorin:~] 3:34:52pm 292 % md5sum foo 2145971cf82058b108229a3a2e3bff35 foo I still don't think gnupg should do that. :) -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From gqueri@mail.dotcom.fr Fri May 26 00:51:33 2000 From: gqueri@mail.dotcom.fr (Gael Queri) Date: Fri, 26 May 2000 01:51:33 +0200 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:36:23PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526015133.A308@baoule.ath.cx> Hello brian, sorry to interrupt your conversation with yourself :) On Thu, May 25, 2000 at 03:36:23PM -0700, brian moore wrote: > (...) > But the dropping-the-trailing-newline doesn't require PGP5, so I'm still > convinced this is solely a gnupg problem: > > [thorin:~] 3:34:15pm 288 % echo foo > foo > [thorin:~] 3:34:20pm 289 % md5sum foo > d3b07384d113edec49eaa6238ad5ff00 foo > [thorin:~] 3:34:27pm 290 % gpg -sat foo > > You need a passphrase to unlock the secret key for > user: "brian moore " > 1024-bit DSA key, ID 88322B51, created 1998-10-17 > > [thorin:~] 3:34:44pm 291 % gpg foo.asc > File `foo' exists. Overwrite (y/N)? y > gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 > gpg: Good signature from "brian moore " > gpg: aka "brian moore " > gpg: aka "brian moore " > [thorin:~] 3:34:52pm 292 % md5sum foo > 2145971cf82058b108229a3a2e3bff35 foo > > I still don't think gnupg should do that. :) It seems to be fixed in gnupg 1.0.1e, so you were at least not the only one to think that :-) gael@baoule:~$ echo foo > foo gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo gael@baoule:~$ gpg -sat foo gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! You need a passphrase to unlock the secret key for user: "Gael Queri " 1024-bit DSA key, ID 3E18F9CE, created 1997-09-01 gael@baoule:~$ gpg foo.asc gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! File `foo' exists. Overwrite (y/N)? y gpg: Signature made Fri May 26 01:38:48 2000 CEST using DSA key ID 3E18F9CE gpg: Good signature from "Gael Queri " gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo Regards, gael From sen_ml@eccosys.com Fri May 26 04:09:38 2000 From: sen_ml@eccosys.com (sen_ml@eccosys.com) Date: Fri, 26 May 2000 12:09:38 +0900 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net> References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526120938J.1001@eccosys.com> From: brian moore Subject: Re: Clearsigning (again) Date: Thu, 25 May 2000 15:36:45 -0700 Message-ID: <20000525153645.D24700@cmc.net> ... > Continuing to follow up to myself... :) > > I see why. It's a bug of PGP5. If I manually strip the tab in the > clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not > recognizing that it should ignore trailing tabs on input. (And this > isn't documented in the 'Implementation Notes' in 2440 with the other > PGP5 bugs... Can someone on the IETF committee see that it makes it into > future revisions? :)) information about the openpgp working group mailing list can be found at: http://www.imc.org/ietf-openpgp/ you could post the suggestion there. From rabbi@quickie.net Sat May 27 01:33:46 2000 From: rabbi@quickie.net (L. Sassaman) Date: Fri, 26 May 2000 17:33:46 -0700 (PDT) Subject: Subkeys In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get an "Unusable public key algorithm" error when I try to encrypt to keys that have additional encryption subkeys. Can we work through this so that GnuPG handles v4 keys with multiple subkeys in the same manner that PGP does? - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LxfxPYrxsgmsCmoRAvQ+AJ9GeC6rsYWb7HxeXnEVsCRYx9eVxgCgwqXl r3pOieMkJByCafQgUfydTiQ= =Hxpe -----END PGP SIGNATURE----- From bem at cmc.net Tue May 2 16:17:12 2000 From: bem at cmc.net (brian moore) Date: Tue Oct 7 21:26:22 2003 Subject: general compatibility with PGP... Message-ID: <20000502151712.K31948@cmc.net> This seems to fail: -------- This is a test file for GPG/PGP/OpenPGP compatibility. This line ends with a tab for no good reason: Thanks for the test. This file ends with a blank line. -------- The above file, once signed (with gpg --sign -a -t testfile, which is what the docs imply is the 'pgp compatibility hack'), will not verify with PGP5, and PGP5 will also strip the last blank line. Who is right on the reading of 'text mode' on this? Or should there be a '--broken-text-mode' flag to appease PGP5? It's sort of annoying since Network Solutions likes sending forms with lines ending in tabs and spaces (I dunno -why-, they just do!) and I have to be sure I do a ':%s/[ ^I]\+$//' before signing stuff and ensure I have an extra blank line at the end. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From nittka at esem.com Thu May 4 10:37:03 2000 From: nittka at esem.com (Oliver Nittka) Date: Tue Oct 7 21:26:23 2003 Subject: [mailing-lists.reiserfs] (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Message-ID: this may become very important for all open-source-projects, so i'll forward it to this list. -- oly -- Oliver Nittka | nittka@esem.com ESEM Gr?nau GmbH & Co. KG | http://www.esem.com Dornierstra?e 6 | phone: +49 7544 9583-25 88677 Markdorf / Germany | fax: +49 7544 9583-60 -------------- next part -------------- An embedded message was scrubbed... From: Xuan Baldauf Subject: (reiserfs) Spam: For german list readers: SW-Patents: BMWi-Konferenz: So koennen Sie helfen Date: Thu, 04 May 2000 00:23:53 +0200 Size: 8804 Url: /pipermail/attachments/20000504/d9cf69d9/attachment.eml From ks at caldera.de Tue May 9 18:35:46 2000 From: ks at caldera.de (Klaus Singvogel) Date: Tue Oct 7 21:26:23 2003 Subject: Patch: FAQ Message-ID: <20000509173546.A15460@Caldera.DE> Even the patch for the FAQ describes it now correct, I can't decrypt such a GnuPG generated message with PGP V2.6.3ii I'll investigate it and tell you more AFAIK more. Regards, Klaus. --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 @@ -123,7 +123,7 @@ supported by GnuPG because it is patented, but if you have a modified version of PGP you can try this: - gpg --rfc1991 --cipher-algo 3des ... + gpg --rfc1991 --cipher-algo idea ... Please don't pipe the data to encrypt to gpg but give it as a filename; other wise, pgp 2 will not be able to handle it. From wk at gnupg.org Tue May 9 20:29:22 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:23 2003 Subject: Patch: FAQ In-Reply-To: <20000509173546.A15460@Caldera.DE>; from ks@caldera.de on Tue, May 09, 2000 at 05:35:46PM +0200 References: <20000509173546.A15460@Caldera.DE> Message-ID: <20000509192922.C4283@djebel.gnupg.de> On Tue, 9 May 2000, Klaus Singvogel wrote: > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > @@ -123,7 +123,7 @@ > supported by GnuPG because it is patented, but if you have a modified > version of PGP you can try this: > > - gpg --rfc1991 --cipher-algo 3des ... > + gpg --rfc1991 --cipher-algo idea ... Watch out for the "...modified version of PGP .." - I assume that this is will be a 3DES one ;-). The GNU project does not support patented algorithms and therefore you won't read IDEA in it :-). Yes, I know that there are some countries where there is no valid patent on IDEA. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From ks at caldera.de Wed May 10 12:57:09 2000 From: ks at caldera.de (Klaus Singvogel) Date: Tue Oct 7 21:26:23 2003 Subject: Patch: FAQ In-Reply-To: <20000509192922.C4283@djebel.gnupg.de>; from wk@gnupg.org on Tue, May 09, 2000 at 07:29:22PM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> Message-ID: <20000510115709.A30043@Caldera.DE> On Tue, May 09, 2000 at 07:29:22PM +0200, Werner Koch wrote: > On Tue, 9 May 2000, Klaus Singvogel wrote: > > > --- gnupg-1.0.1/doc/FAQ.orig Sat Dec 4 12:29:59 1999 > > +++ gnupg-1.0.1/doc/FAQ Tue May 9 17:31:38 2000 > > @@ -123,7 +123,7 @@ > > supported by GnuPG because it is patented, but if you have a modified > > version of PGP you can try this: > > > > - gpg --rfc1991 --cipher-algo 3des ... > > + gpg --rfc1991 --cipher-algo idea ... > > Watch out for the "...modified version of PGP .." - I assume that this > is will be a 3DES one ;-). The GNU project does not support patented > algorithms and therefore you won't read IDEA in it :-). Yes, I know > that there are some countries where there is no valid patent on IDEA. Sorry, but the FAQ speaks at this point of encryption for pgp 2.x Yes, you have to have a modified version GnuPG, but you have to use the (patented) idea algorithmen as cipher algorithmen too (and not 3des). Thats what I correct in the FAQ. I know, you can use 3des to make GnuPG encrypted messages readable for pgp 5.x or 6.x users. But that's not the point the FAQ speaks here of. Another point: I build a modified version of GnuPG: I built the idea/rsa modules, added the "load-extension idea" "load-extension rsa" lines to my .gnupg/options, and check with "strace" if the modules where used/opened (they were :-) But still I can't encrypt a message with GnuPG 1.0.1 (rsa 1.10 and idea 1.11) for a pgp-2.6.3ii user (myself). I get the error message Error: Decrypted plaintext is corrupted. If I look into the source-code I see that the error comes from the idea decryption. I currently investigate this. My current assumption is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does decryption in CBC mode. But I'm not sure, since I don't understand the idea.c completly yet. I'll tell you more, if I find the error. Regards, Klaus. -- .-. | Klaus Singvogel oo| | Caldera (Deutschland) GmbH, Naegelsbachstr. 49c, 91052 Erlangen /`'\ | email: ks@caldera.de internet: http://www.caldera.de (\_;/) | phone: ++49 9131 7192-300 fax: ++49 9131 7192-399 From az096 at freenet.toronto.on.ca Wed May 10 09:13:13 2000 From: az096 at freenet.toronto.on.ca (Robert Guerra) Date: Tue Oct 7 21:26:23 2003 Subject: Fwd:ANNOUNCEMENT: PGP Desktop Security 7.0 Message-ID: I'm sending this along in case people on here may have not seen it before. on first reading it looks like pgp (from NAI) is slowly morphing into a larger and larger beast. I hope that the folks from NAI follow the openpgp specs as they should so the new client can be as compatible as possible with gnupg. time will tell.. regards robert --- begin forwarded text Date: Tue, 09 May 2000 10:43:33 -0700 From: Will Price Subject: [PGP-USERS] ANNOUNCEMENT: PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today, we officially announced PGP Desktop Security 7.0. Here is the press release: http://biz.yahoo.com/prnews/000509/nv_neta_pg_1.html The beta program (which is already almost completely filled, so please don't ask) will begin this month and you should see the final version in early Q3. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 165 Alpha) iQA/AwUBORhOH6y7FkvPc+xMEQKvDwCguLKbVGyrUeevvP9hNGtem9ZKaGAAn2+B O8b6AFDrrbVt8A53oxED6IEy =OBdf -----END PGP SIGNATURE----- ..................................................................... Unsubscribe: Automated Help/Info: List Homepage: List Admin (human): Please do not send administrative commands to the list address! Thanks. --- end forwarded text -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From wk at gnupg.org Wed May 10 17:24:13 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:23 2003 Subject: Patch: FAQ In-Reply-To: <20000510115709.A30043@Caldera.DE>; from ks@caldera.de on Wed, May 10, 2000 at 11:57:09AM +0200 References: <20000509173546.A15460@Caldera.DE> <20000509192922.C4283@djebel.gnupg.de> <20000510115709.A30043@Caldera.DE> Message-ID: <20000510162413.L7032@djebel.gnupg.de> On Wed, 10 May 2000, Klaus Singvogel wrote: > use the (patented) idea algorithmen as cipher algorithmen too (and > not 3des). Thats what I correct in the FAQ. If you look at the PGP 2 data formats (e.g. rfc1991) you will notice that there is indeed an algorithm indetifier and therefore it is possible to replace IDEA by 3DES (or better CAST5 which uses the same keysize and can be done very easily). Please read the GPL before _distributing_ GnuPG together with a module which implements a patented algorithm; doing so might vilolate the GPL. > If I look into the source-code I see that the error comes from the > idea decryption. I currently investigate this. My current assumption > is, that GnuPG does idea encryption in ECB mode, but pgp 2.x does > decryption in CBC mode. But I'm not sure, since I don't understand Nope. The cipher modules are the low level encryption. The chaining is done in cipher/cipher.c and the same for all symmetric ciphers. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking at nmrc.ucc.ie Wed May 10 22:08:08 2000 From: lhecking at nmrc.ucc.ie (Lars Hecking) Date: Tue Oct 7 21:26:23 2003 Subject: Solaris random device Message-ID: <20000510210808.A9104@tehran.nmrc.ucc.ie> Hi all, I just subscribed here, because the problem I'm facing now is probably not appropriate for -users ... After openssh failed when I upgraded to Solaris 8, I was looking for an alternative to egd and found Andreas Maier's random device for Solaris (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with openssl/openssh. I can generate keys, make connections, no problem. I'm now trying to use the random device with gpg, but it doesn't work. $ ./configure --prefix=$HOME --disable-nls --enable-static-rnd=linux (don't now if --enable-static-rnd=linux necessary - it doesn't make a difference if I leave this out) ... checking for random device... yes checking for linux/random.h... no checking for random device ioctl... no ... $ make check ... gpg (GnuPG) 1.0.1e Copyright (C) 2000 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: . Supported algorithms: Cipher: 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160, TIGER PASS: version.test PASS: mds.test PASS: decrypt.test PASS: decrypt-dsa.test and there it seems to hang. I'm attaching truss to the running copy of gpg and get ... poll(0xFFBED588, 1, 3000) Err#6 ENXIO write(2, " s e l e c t ( ) e r r".., 16) = 16 write(2, " N o s u c h d e v i".., 25) = 25 write(2, "\n", 1) = 1 [repeats over and over] Any suggestions? Is it possible that the current code is too Linux/BSD specific? Thanks. From Nils at infosun.fmi.uni-passau.de Thu May 11 10:53:28 2000 From: Nils at infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Tue Oct 7 21:26:23 2003 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie> References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> >>>"LH" == Lars Hecking writes: LH> After openssh failed when I upgraded to Solaris 8, I was looking for an LH> alternative to egd and found Andreas Maier's random device for Solaris LH> (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with LH> openssl/openssh. I can generate keys, make connections, no problem. I don't know about Andi Maier's device, but egd has been updated to work with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several weeks by now. Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From wk at gnupg.org Thu May 11 11:41:04 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:23 2003 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511104104.A7032@djebel.gnupg.de> On Wed, 10 May 2000, Lars Hecking wrote: > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. IIRC, gpg checks that it is a character device - maybe the Solaris /dev/random is implemented as another type of device. (Patches are welcome) Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From listmaster at gnupg.org Thu May 11 12:19:14 2000 From: listmaster at gnupg.org (Lord of the Lists) Date: Tue Oct 7 21:26:23 2003 Subject: external keystore option? Message-ID: <20000511111914.I7032@djebel.gnupg.de> ----- Forwarded message from "Mikolaj J. Habryn" ----- Date: Thu, 11 May 2000 10:58:59 +0200 From: "Mikolaj J. Habryn" To: gnupg-devel@gnupg.org Subject: external keystore option? X-Diagnostic: Mail coming from a daemon, ignored Are there any plans for or opinions on the possibility of separating out the sensitive key management operations in gnupg (along the lines of ssh-agent for ssh)? I had a dig through the archives (a while ago), and recall seeing the subject come up once, but with no definitive resolution. I would like to see such functionality in gnupg; there are certain situations (such as Debian package creation) where a flexible policy engine would save a fair bit of passphrase retyping. My reason for asking is not purely academic; I recently published keymgr, an application designed to serve this purpose, whose only real claims to fame at present are a pretense to modularity and enough functionality to allow one to keep one's ssh keys on a Java ring. I've cobbled together enough code fragments to probably allow it to fake the desired effect by using a wrapper for gpg along with --passphrase-fd option (and obviously tracking passphrases in keymgr), but it's something of a suboptimal solution. m. ----- End forwarded message ----- -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From wk at gnupg.org Thu May 11 12:42:44 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:23 2003 Subject: external keystore option? In-Reply-To: <20000511111914.I7032@djebel.gnupg.de>; from listmaster@gnupg.org on Thu, May 11, 2000 at 11:19:14AM +0200 References: <20000511111914.I7032@djebel.gnupg.de> Message-ID: <20000511114244.M7032@djebel.gnupg.de> On Thu, 11 May 2000, Lord of the Lists wrote: > ----- Forwarded message from "Mikolaj J. Habryn" ----- > Are there any plans for or opinions on the possibility of separating > out the sensitive key management operations in gnupg (along the lines > of ssh-agent for ssh)? I had a dig through the archives (a while ago), > and recall seeing the subject come up once, but with no definitive > resolution. This is scheduled for 1.1 but due to all the remaining work on 1.0 it will take some more time to start with it. I'd would very much appreciate help for GnuPG from volunteers who can sign an copyright assignment for the FSF. Without that legal paper I have to review all the pacthes and look at the idea only :-( > My reason for asking is not purely academic; I recently published > keymgr, an application designed to serve this purpose, whose only real > claims to fame at present are a pretense to modularity and enough > functionality to allow one to keep one's ssh keys on a Java ring. BTW, Brian Warner did some experiments with a PalmPilot and sent me the outline for a protocol to be used between the decryption/signing engine on some device and gpg. However, I have not yet found the time to work on it and franky I can't find it right now in my mail archives :-( Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking at nmrc.ucc.ie Thu May 11 11:47:43 2000 From: lhecking at nmrc.ucc.ie (Lars Hecking) Date: Tue Oct 7 21:26:23 2003 Subject: Solaris random device In-Reply-To: <20000511104104.A7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 10:41:04AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511104104.A7032@djebel.gnupg.de> Message-ID: <20000511104743.A10797@tehran.nmrc.ucc.ie> Werner Koch writes: > On Wed, 10 May 2000, Lars Hecking wrote: > > > alternative to egd and found Andreas Maier's random device for Solaris > > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > > openssl/openssh. I can generate keys, make connections, no problem. > > IIRC, gpg checks that it is a character device - maybe the Solaris > /dev/random is implemented as another type of device. $ cd /devices/pseudo $ ll r* crw-r--r-- 1 root sys 65, 0 May 10 01:21 random@0:random crw-r--r-- 1 root sys 65, 1 May 10 01:21 random@0:urandom $ From dichro-gnupg-devel at rcpt.to Thu May 11 21:11:14 2000 From: dichro-gnupg-devel at rcpt.to (Mikolaj J. Habryn) Date: Tue Oct 7 21:26:23 2003 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 11:42:44 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> I'd would very much appreciate help for GnuPG from volunteers WK> who can sign an copyright assignment for the FSF. Without WK> that legal paper I have to review all the pacthes and look at WK> the idea only :-( This won't be a problem, but I'll save it for if and when I come up with something worthwhile to contribute. WK> BTW, Brian Warner did some experiments with a PalmPilot and WK> sent me the outline for a protocol to be used between the WK> decryption/signing engine on some device and gpg. However, I WK> have not yet found the time to work on it and franky I can't WK> find it right now in my mail archives :-( Hmm, okay. Failing that, my intent was to gin up a simple text based protocol to run over Unix sockets, with operations like DECRYPT ( list of valid keys ) cyphertext I presume here that gpg will know what keys can decrypt a message (by fingerprint? id? full public key? How are they identified in the message?), but won't know which ones are available. ENCRYPT key plaintext Which does the obvious thing. Would this cover the gamut of what gpg does with private keys? I am also presuming that the keystore would acquire the keys by means outside this protocol. m. From wk at gnupg.org Thu May 11 13:50:53 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:23 2003 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:11:14PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> Message-ID: <20000511125053.O7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm, okay. Failing that, my intent was to gin up a simple text based > protocol to run over Unix sockets, with operations like Okay. > DECRYPT ( list of valid keys ) cyphertext > > I presume here that gpg will know what keys can decrypt a message > (by fingerprint? id? full public key? How are they identified in the > message?), but won't know which ones are available. The needed key is identified by the 64 bit KeyID. There is an option for a wildcard KeyID in which case gpg tries each available secret key in turn. > ENCRYPT key plaintext > > Which does the obvious thing. Would this cover the gamut of what gpg > does with private keys? I am also presuming that the keystore would You don't need the secret key for encryption - I guess you are thinking of signing a message. Such an agent should take care of all operations where the secret key is involved and leve all other crypto operations to normal program. The goal of such a agent should be to better protect the secret key. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From alex at bofh.torun.pl Thu May 11 14:55:37 2000 From: alex at bofh.torun.pl (Janusz A. Urbanowicz) Date: Tue Oct 7 21:26:24 2003 Subject: external keystore option? In-Reply-To: <20000511114244.M7032@djebel.gnupg.de> from Werner Koch at "May 11, 2000 11:42:44 am" Message-ID: Werner Koch wrote/napisa?[a]: > On Thu, 11 May 2000, Lord of the Lists wrote: > > My reason for asking is not purely academic; I recently published > > keymgr, an application designed to serve this purpose, whose only real > > claims to fame at present are a pretense to modularity and enough > > functionality to allow one to keep one's ssh keys on a Java ring. > > BTW, Brian Warner did some experiments with a PalmPilot and sent me > the outline for a protocol to be used between the decryption/signing > engine on some device and gpg. However, I have not yet found the time > to work on it and franky I can't find it right now in my mail archives :-( I'd be very interested in it (as a fresh owner of brand-new Palm Vx) and also in paricipating. I've already thought of implementing something along the lines of using Palm as crypto token/engine working over IRDA/serial link. alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy daj? biednym chleb, nazywaj? mnie ?wi?tym. Gdy pytam, dlaczego biedni nie maj? chleba, nazywaj? mnie komunist?. - abp. Helder Camara From dichro-gnupg-devel at rcpt.to Thu May 11 21:59:57 2000 From: dichro-gnupg-devel at rcpt.to (Mikolaj J. Habryn) Date: Tue Oct 7 21:26:24 2003 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 12:50:53 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> The needed key is identified by the 64 bit KeyID. There is an WK> option for a wildcard KeyID in which case gpg tries each WK> available secret key in turn. Hmm. How can one tell if one has found the right key? Magic in the plaintext? WK> You don't need the secret key for encryption - I guess you are WK> thinking of signing a message. Yep, or things like signing keys. I presume that in both cases (and any others?), gpg builds some kind of value which needs to be encrypted with the secret key and returned (?). I guess the question boils down to - are there any operations that gpg performs with a secret key that can't be transformed into an encryption/decryption with some independent munging of data formats on either side of it? m. From wk at gnupg.org Thu May 11 15:08:10 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:24 2003 Subject: external keystore option? In-Reply-To: ; from dichro-gnupg-devel@rcpt.to on Thu, May 11, 2000 at 08:59:57PM +1000 References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> Message-ID: <20000511140810.R7032@djebel.gnupg.de> On Thu, 11 May 2000, Mikolaj J. Habryn wrote: > Hmm. How can one tell if one has found the right key? Magic in the > plaintext? Quite simple: Without the correct key you get only garbled plaintext - this is easy to detect because the plaintext (actually the encrypted session key) has some special format and a checksum. > Yep, or things like signing keys. I presume that in both cases (and All signing operations. > secret key that can't be transformed into an encryption/decryption A secret key is only needed for this: a) decryption b) signing Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From apommer at cosy.sbg.ac.at Thu May 11 16:04:11 2000 From: apommer at cosy.sbg.ac.at (Andreas Pommer) Date: Tue Oct 7 21:26:24 2003 Subject: Solaris random device In-Reply-To: <20000510210808.A9104@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Wed, May 10, 2000 at 09:08:08PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> Message-ID: <20000511150411.H32456@cosy.sbg.ac.at> On May 10, Lars Hecking wrote: [..] > After openssh failed when I upgraded to Solaris 8, I was looking for an > alternative to egd and found Andreas Maier's random device for Solaris > (http://www.cosy.sbg.ac.at/~andi/). It seems to work quite nicely with > openssl/openssh. I can generate keys, make connections, no problem. [...] > poll(0xFFBED588, 1, 3000) Err#6 ENXIO > write(2, " s e l e c t ( ) e r r".., 16) = 16 > write(2, " N o s u c h d e v i".., 25) = 25 > write(2, "\n", 1) = 1 > [repeats over and over] > > Any suggestions? Is it possible that the current code is too Linux/BSD > specific? the problem occurs in rndlinux.c gather_random() at the select() in line 128: if( !(rc=select(fd+1, &rfds, NULL, NULL, &tv)) ) { this select() translates into poll(), which can be seen in the truss-dump above. However, in the source of Andis random device one can read: * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE [..] * -) /dev/random and /dev/urandom are the same (no blocking). * -) No ioctls, no poll. * * NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE That seems to be the answer. One possible solution would be to skip the select() if the fact is known that the device does not block. Another one would be to improve the random device (remember, still V0.1), to provide a dummy-poll which succeeds every time. HTH Andreas From wk at gnupg.org Thu May 11 17:19:02 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:24 2003 Subject: Solaris random device In-Reply-To: <20000511150411.H32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 03:04:11PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> Message-ID: <20000511161902.Y7032@djebel.gnupg.de> On Thu, 11 May 2000, Andreas Pommer wrote: > That seems to be the answer. One possible solution would be to skip the > select() if the fact is known that the device does not block. We can't do that because we should be somewhat sure about how much entropy we got. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From lhecking at nmrc.ucc.ie Thu May 11 16:05:40 2000 From: lhecking at nmrc.ucc.ie (Lars Hecking) Date: Tue Oct 7 21:26:24 2003 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511150540.A12177@tehran.nmrc.ucc.ie> Werner Koch writes: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. As the author has invited comments and suggestions, I have forwarded Andreas P's reply. From lhecking at nmrc.ucc.ie Thu May 11 17:18:07 2000 From: lhecking at nmrc.ucc.ie (Lars Hecking) Date: Tue Oct 7 21:26:24 2003 Subject: Solaris random device In-Reply-To: <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de>; from Nils@infosun.fmi.uni-passau.de on Thu, May 11, 2000 at 09:53:28AM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <14618.26360.465855.70816@skrjabin.fmi.uni-passau.de> Message-ID: <20000511161807.A12368@tehran.nmrc.ucc.ie> > I don't know about Andi Maier's device, but egd has been updated to work > with Solaris 8. Get the egd-0.7 distribution and replace egd.pl by > ftp://ftp.lothar.com/linux/egd.pl.1.46 Unfortunately, Brian didn't > annnounce that fix. Egd 1.46 works fine on my Solaris 8 host for several > weeks by now. Unfortunately, I am totally unable to ftp to ftp.lothar.com. Anon login is ok, but anything beyond that times out. From apommer at cosy.sbg.ac.at Thu May 11 20:01:00 2000 From: apommer at cosy.sbg.ac.at (Andreas Pommer) Date: Tue Oct 7 21:26:24 2003 Subject: Solaris random device In-Reply-To: <20000511161902.Y7032@djebel.gnupg.de>; from wk@gnupg.org on Thu, May 11, 2000 at 04:19:02PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> Message-ID: <20000511190100.N32456@cosy.sbg.ac.at> On May 11, Werner Koch wrote: > On Thu, 11 May 2000, Andreas Pommer wrote: > > > That seems to be the answer. One possible solution would be to skip the > > select() if the fact is known that the device does not block. > > We can't do that because we should be somewhat sure about how much > entropy we got. So we used to other option and now there is an improved version of the sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ It now cooperates with gpg - at least the 'make check' does not fail or hang. Andreas From lhecking at nmrc.ucc.ie Sat May 13 00:14:04 2000 From: lhecking at nmrc.ucc.ie (Lars Hecking) Date: Tue Oct 7 21:26:24 2003 Subject: Solaris random device In-Reply-To: <20000511190100.N32456@cosy.sbg.ac.at>; from apommer@cosy.sbg.ac.at on Thu, May 11, 2000 at 07:01:00PM +0200 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> Message-ID: <20000512231404.A10088@tehran.nmrc.ucc.ie> > So we used to other option and now there is an improved version of the > sun /dev/random code available at http://www.cosy.sbg.ac.at/~andi/ > It now cooperates with gpg - at least the 'make check' does not fail or hang. Yep. Works fine now on both Solaris 7 and 8. But still, I'd like to hear some good arguments for using this device at all. I am basically unclued about crypto, but I understand that a "good" random source is instrumental. From a user perspective, is the Solaris device appropriate? Is there a danger of creating weakly encrypted files with it? Thanks a lot for being so helpful, guys, I really appreciate it! (Ok with me if you want to move this discussion over to -users) From dichro-gnupg-devel at rcpt.to Sat May 13 18:03:29 2000 From: dichro-gnupg-devel at rcpt.to (Mikolaj J. Habryn) Date: Tue Oct 7 21:26:24 2003 Subject: external keystore option? In-Reply-To: Werner Koch's message of "Thu, 11 May 2000 14:08:10 +0200" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: How does the following sound? Trying to trace operation flows through the code is a little confusing, so I'm probably way off base :( There appear to be two basic parts to this - firstly, gnupg needs to find out what keys are available, and secondly, it needs to use them. Using them appears to be the province of cipher/pubkey.c. Let's assume that gnupg has found out what keys the agent has, and is now trying to perform some kind of operation with them. My first thought was to somehow overload pubkey_table so that it would have two entries for each algorithm - one as is, and one which references functions which communicate with the agent for operations. This would require minor changes to all the functions that walk pubkey_table to not bomb if the first algorithm match fails, and also hook into the dynamic module loading code to add the duplicate agent entry for each loaded module, which could be messy. Alternatively, we can assume that when gnupg is fed the agent's keys, it will receive something bogus for the secret key. When it tries to do something useful with it, it will bomb with a recognizable error (G10ERR_BAD_MPI spring to mind). We could change all the wrapper functions to note this error and repeat the request to the agent to see if it will do any better. I couldn't find any way of changing the functions called on a key by key basis, only algorithm by algorithm. Did I miss anything? g10/ringedit.c appears to be a good place to start teaching gnupg about the agent. One could define a new keyring type (rt_AGENT), and hook it appropriately in the following functions. I'm basically looking to see where rt_GDBM is special cased, and trying to work out what the corresponding operations would be for an agent. o add_keyblock_resource - simple enough, establish a connection to the agent, cache the socket fd. o search - seemingly simple, but there's some questions in my mind. The rt_GDBM case generates a fingerprint from the public key in the packet passed as an argument to the function, and uses that as a key. But... there's some functions, like find_keyblock_bysk, that (judging from the name) might not have a public key as part of the request. Why is it safe for rt_GDBM to assume that it will be there? A comment later in the code suggests that the search interface is used preparatory to doing modifications to the keystore - is it /only/ used for this? ie, assuming that gnupg isn't going to have control over the agent, can implementing the search operation be skipped? The second part of this question is where does the public key initially come from, if not search? Which ties in to... o enum_keyblocks - am I correct in guessing that this is the interface used for populating gnupg's idea of what keys are available for it to use? I'm getting a little bit lost in all the various packet types, but here's the idea floating uppermost in my mind: If enum_keyblocks is indeed what is called as the first contact with a keystore, can I get away with simply populating the KBNODE(?) with a full public key and a bogus secret key (assuming the second option for using the key that I mentioned above)? This would mean that for all uses of this key that don't directly use the secret key, enum_keyblocks would already have all of the required data to handle them. Sorry if this is as confused as I am :) m. From apommer at cosy.sbg.ac.at Sat May 13 11:59:24 2000 From: apommer at cosy.sbg.ac.at (Andreas Pommer) Date: Tue Oct 7 21:26:24 2003 Subject: Solaris random device In-Reply-To: <20000512231404.A10088@tehran.nmrc.ucc.ie>; from lhecking@nmrc.ucc.ie on Fri, May 12, 2000 at 11:14:04PM +0100 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> Message-ID: <20000513105924.S32456@cosy.sbg.ac.at> On May 12, Lars Hecking wrote: [..] > But still, I'd like to hear some good arguments for using this device > at all. I am basically unclued about crypto, but I understand that a > "good" random source is instrumental. From a user perspective, is the > Solaris device appropriate? Is there a danger of creating weakly encrypted > files with it? Currently it is more similar to the linux /dev/urandom , less to /dev/random. At every call to the device some entropy is added (from a high resolution timer, and sometimes process id) and subsequently mangled by some hash algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. The solaris kstat interface provides access to a large number of kernel counters which can be used for that purpose. However, the "good" ones have to be determined. > Thanks a lot for being so helpful, guys, I really appreciate it! > (Ok with me if you want to move this discussion over to -users) I didn't subscribe to users, maybe I should ... Andreas From em at who.net Sat May 13 21:22:18 2000 From: em at who.net (Enzo Michelangeli) Date: Tue Oct 7 21:26:24 2003 Subject: Solaris random device References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> Message-ID: <00f101bfbcd5$f327f000$16006598@asiainter.net> ----- Original Message ----- From: "Andreas Pommer" To: Sent: Saturday, May 13, 2000 16:59 Subject: Re: Solaris random device [...] > Currently it is more similar to the linux /dev/urandom , less to /dev/random. > At every call to the device some entropy is added (from a high resolution > timer, and sometimes process id) and subsequently mangled by some hash > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > The solaris kstat interface provides access to a large number of kernel > counters which can be used for that purpose. However, the "good" ones > have to be determined. Why? Just toss everything into the pool: the total entropy cannot be reduced by adding low-entropy data. The more, the merrier. Cheers -- Enzo From dichro-gnupg-devel at rcpt.to Tue May 16 20:31:06 2000 From: dichro-gnupg-devel at rcpt.to (Mikolaj J. Habryn) Date: Tue Oct 7 21:26:24 2003 Subject: external keystore option? In-Reply-To: "Mikolaj J. Habryn"'s message of "13 May 2000 17:03:29 +1000" References: <20000511111914.I7032@djebel.gnupg.de> <20000511114244.M7032@djebel.gnupg.de> <20000511125053.O7032@djebel.gnupg.de> <20000511140810.R7032@djebel.gnupg.de> Message-ID: >>>>> "MJH" == Mikolaj J Habryn writes: MJH> A comment later in the code suggests that the search MJH> interface is used preparatory to doing modifications to the MJH> keystore - is it /only/ used for this? To answer my own question, this does indeed appear to be the case. I've attached a patch which implements some basic agent support for gnupg. Using this and a modified keymgr, I've managed to sign/verify, and encrypt/decrypt a file using the ssh key I keep on my Java iButton. This is how I get my kicks. Observations. The exercise was a little bit gruesome. The keys that originate with the agent are marked with an is_protected of 23, and check_secret_key adjusted to not try to checksum them. In addition, the pubkey_decrypt and pubkey_sign methods look to see if the secret MPI fields are NULL, and redirect the query to the agent if so. This is suboptimal, but by the time we hit those queries, we've lost all the other information about the key. Just FYI. m. -------------- next part -------------- diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/cipher/pubkey.c gnupg-work/cipher/pubkey.c --- gnupg-1.0.1-orig/cipher/pubkey.c Fri Jul 23 22:02:52 1999 +++ gnupg-work/cipher/pubkey.c Tue May 16 18:51:47 2000 @@ -492,6 +492,9 @@ log_mpidump(" data:", data[i] ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, result, *data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { @@ -526,6 +529,9 @@ log_mpidump(" data:", data ); } + if(!skey[pubkey_get_npkey(algo)]) + return agent_process(algo, resarr, data, skey); + else do { for(i=0; pubkey_table[i].name; i++ ) if( pubkey_table[i].algo == algo ) { diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/Makefile.am gnupg-work/g10/Makefile.am --- gnupg-1.0.1-orig/g10/Makefile.am Sun Oct 10 03:23:41 1999 +++ gnupg-work/g10/Makefile.am Tue May 16 15:58:39 2000 @@ -57,6 +57,7 @@ keylist.c \ sig-check.c \ signal.c \ + agent.c \ helptext.c gpg_SOURCES = g10.c \ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.c gnupg-work/g10/agent.c --- gnupg-1.0.1-orig/g10/agent.c Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.c Tue May 16 19:00:55 2000 @@ -0,0 +1,214 @@ +#include +#include +#ifndef UNIX_PATH_MAX +#define UNIX_PATH_MAX 63 +#endif +#include +#include +#include +#include +#include + +#include "config.h" +#include "keydb.h" +#include "errors.h" +#include "packet.h" + +static int agent_socket; + +static unsigned char *hextable = NULL; + +int agent_connect(char *path) { + struct sockaddr_un sun; + + sun.sun_family = AF_LOCAL; + strncpy(sun.sun_path, path, UNIX_PATH_MAX - 1); + + agent_socket = socket(PF_LOCAL, SOCK_STREAM, 0); + if(agent_socket < 0) + return G10ERR_NETWORK; + if(connect(agent_socket, &sun, sizeof(sun))) + return G10ERR_OPEN_FILE; + return 0; +} + +int agent_read(void *buf, int len) { + return read(agent_socket, buf, len); +} + +int agent_write(void *buf, int len) { + return write(agent_socket, buf, len); +} + +int agent_enum(KBPOS *kbpos, KBNODE *ret_root) { + char buf[600], *ptr, *end; + int len = 0, i, algo; + PKT_public_key *p; + PKT_secret_key *s; + PKT_user_id *u; + PACKET *t; + + snprintf(buf, 599, "ENUMERATE %ld\r\n", kbpos->offset++); + if(agent_write(buf, strlen(buf)) != strlen(buf)) + return G10ERR_NETWORK; + do { + int ret; + + ret = agent_read(buf + len, 600 - len); + if(ret < 0) + return G10ERR_NETWORK; + len += ret; + if(len < 2) + continue; + if(buf[len - 1] == '\n' && + buf[len - 2] == '\r') + break; + } while(len < 600); + if(len == 2) + return -1; + ptr = memchr(buf, ' ', len); + if(!ptr) + return G10ERR_BAD_PUBKEY; + *ptr++ = 0; + len -= ptr - buf; + algo = string_to_pubkey_algo(buf); + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_BAD_PUBKEY; + *end++ = 0; + len -= end - ptr; + ptr = end; + p = m_alloc_clear(sizeof(*p)); + s = m_alloc_clear(sizeof(*s)); + p->pubkey_algo = algo; + s->pubkey_algo = algo; + for(i = 0; i < pubkey_get_npkey(algo); i++) { + end = memchr(ptr, ' ', len); + if(!end) + return G10ERR_NETWORK; /* leaking MPIs! */ + *end++ = 0; + len -= end - ptr; + p->pkey[i] = mpi_alloc(0); + mpi_fromstr(p->pkey[i], ptr); + s->skey[i] = mpi_copy(p->pkey[i]); + ptr = end; + } + s->is_protected = 23; + + end = memchr(ptr, '\r', len); + *end = 0; + u = m_alloc_clear(sizeof(*u) + strlen(ptr)); + u->len = strlen(ptr); + strcpy(u->name, ptr); + + t = m_alloc_clear(sizeof(*t)); + if(kbpos->secret) { + t->pkttype = PKT_SECRET_KEY; + t->pkt.secret_key = s; + } else { + t->pkttype = PKT_PUBLIC_KEY; + t->pkt.public_key = p; + } + *ret_root = new_kbnode(t); + + t = m_alloc_clear(sizeof(*t)); + t->pkttype = PKT_USER_ID; + t->pkt.user_id = u; + add_kbnode(*ret_root, new_kbnode(t)); + + return 0; +} + +unsigned char kmsl_nybble_char(unsigned char c) { + switch(c) { + case 0: + return '0'; + case 1: + return '1'; + case 2: + return '2'; + case 3: + return '3'; + case 4: + return '4'; + case 5: + return '5'; + case 6: + return '6'; + case 7: + return '7'; + case 8: + return '8'; + case 9: + return '9'; + case 0xa: + return 'a'; + case 0xb: + return 'b'; + case 0xc: + return 'c'; + case 0xd: + return 'd'; + case 0xe: + return 'e'; + case 0xf: + return 'f'; + default: + return 0xff; + } +} + +void kmsl_genhextable() { + int i; + + hextable = malloc(512); + for(i = 0; i < 256; i++) { + hextable[i * 2] = kmsl_nybble_char(i >> 4); + hextable[i * 2 + 1] = kmsl_nybble_char(i & 0xf); + } +} + +unsigned char *kmsl_byte_str(unsigned char c) { + if(!hextable) + kmsl_genhextable(); + return hextable + 2 * c; +} + +void agent_write_mpi(MPI m) { + int len, j, textlen; + unsigned char *text, *buf = mpi_get_buffer(m, &len, NULL); + + agent_write("0x", 2); + textlen = len * 2; + text = alloca(textlen); + for(j = 0; j < len; j++) + memcpy(text + j * 2, kmsl_byte_str(buf[j]), 2); + agent_write(text, textlen); + free(buf); +} + +int agent_process(int algo, MPI *ret, MPI data, MPI *skey) { + char *end, buf[2000], *alg = pubkey_algo_to_string(algo); + int i, r; + + agent_write("PROCESS ", 8); + agent_write(alg, strlen(alg)); + agent_write(" ", 1); + for(i = 0; i < pubkey_get_npkey(algo); i++) { + agent_write_mpi(skey[i]); + agent_write(" ", 1); + } + agent_write_mpi(data); + agent_write("\r\n", 2); + r = agent_read(buf, 2000); + end = memchr(buf, '\r', r - 1); + if(*(end + 1) != '\n') + return G10ERR_NETWORK; /* laziness */ + *end = 0; + r -= 2; + if(!r) + return G10ERR_UNEXPECTED; + *ret = mpi_alloc(0); + mpi_fromstr(*ret, buf); + return 0; +} diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/agent.h gnupg-work/g10/agent.h --- gnupg-1.0.1-orig/g10/agent.h Thu Jan 1 10:00:00 1970 +++ gnupg-work/g10/agent.h Tue May 16 17:35:37 2000 @@ -0,0 +1,11 @@ +#ifdef WITH_AGENT + +#include "keydb.h" + +int agent_connect(char *); +int agent_read(void *, int); +int agent_write(void *, int); +int agent_enum(KBPOS *, KBNODE *); +int agent_process(int, MPI *, MPI, MPI *); + +#endif /* WITH_AGENT */ diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/keydb.h gnupg-work/g10/keydb.h --- gnupg-1.0.1-orig/g10/keydb.h Fri Nov 12 23:49:28 1999 +++ gnupg-work/g10/keydb.h Fri May 12 14:18:09 2000 @@ -58,7 +58,10 @@ enum resource_type { rt_UNKNOWN = 0, rt_RING = 1, - rt_GDBM = 2 + rt_GDBM = 2, +#ifdef WITH_AGENT + rt_AGENT = 3, +#endif }; diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/ringedit.c gnupg-work/g10/ringedit.c --- gnupg-1.0.1-orig/g10/ringedit.c Fri Dec 3 03:30:31 1999 +++ gnupg-work/g10/ringedit.c Tue May 16 16:04:41 2000 @@ -61,7 +61,7 @@ #include "options.h" #include "main.h" #include "i18n.h" - +#include "agent.h" @@ -102,7 +102,6 @@ static int do_gdbm_enum( KBPOS *kbpos, KBNODE *ret_root ); #endif - static RESTBL * check_pos( KBPOS *kbpos ) { @@ -215,6 +214,12 @@ rt = rt_GDBM; resname += 11; } +#ifdef WITH_AGENT + else if(strlen(resname) > 12 && !strncmp(resname, "gnupg-agent:", 12)) { + rt = rt_AGENT; + resname += 12; + } +#endif /* WITH_AGENT */ #ifndef HAVE_DRIVE_LETTERS else if( strchr( resname, ':' ) ) { log_error("%s: invalid URL\n", url ); @@ -343,6 +348,23 @@ break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + { + if(strlen(resname) == 4 && !strncmp(resname, "$ENV", 4)) { + if(!getenv("GNUPG_AGENT")) { + rc = G10ERR_GENERAL; /* how do I make this a silent error? */ + goto leave; + } + rc = agent_connect(getenv("GNUPG_AGENT")); + } else { + rc = agent_connect(filename); + } + if(rc) + goto leave; + } + break; +#endif /* WITH_AGENT */ default: log_error("%s: unsupported resource type\n", url ); rc = G10ERR_GENERAL; @@ -760,6 +782,11 @@ kbpos->offset = 0; break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + kbpos->offset = 0; + break; +#endif default: BUG(); } kbpos->pkt = NULL; @@ -779,6 +806,11 @@ rc = do_gdbm_enum( kbpos, ret_root ); break; #endif +#ifdef WITH_AGENT + case rt_AGENT: + rc = agent_enum(kbpos, ret_root); + break; +#endif default: BUG(); } @@ -803,6 +835,9 @@ kbpos->fp = NULL; } break; +#ifdef WITH_AGENT + case rt_AGENT: +#endif case rt_GDBM: break; case rt_UNKNOWN: @@ -1826,3 +1861,4 @@ } #endif /*HAVE_LIBGDBM*/ + diff --exclude *.orig --exclude TAGS --exclude *.in --exclude *~ -Nru gnupg-1.0.1-orig/g10/seckey-cert.c gnupg-work/g10/seckey-cert.c --- gnupg-1.0.1-orig/g10/seckey-cert.c Mon Jul 12 22:57:49 1999 +++ gnupg-work/g10/seckey-cert.c Tue May 16 19:01:01 2000 @@ -43,6 +43,8 @@ int i, res; unsigned nbytes; + if(sk->is_protected == 23) + return 0; if( sk->is_protected ) { /* remove the protection */ DEK *dek = NULL; u32 keyid[4]; /* 4! because we need two of them */ From alex at bofh.torun.pl Thu May 18 17:12:14 2000 From: alex at bofh.torun.pl (Janusz A. Urbanowicz) Date: Tue Oct 7 21:26:25 2003 Subject: GnuPG with Netscape Messenger? In-Reply-To: <20000518101453.C13517@djebel.gnupg.de> from Werner Koch at "May 18, 2000 10:14:53 am" Message-ID: Werner Koch wrote/napisa?[a]: > On Wed, 17 May 2000, Paul Gallagher wrote: > > > I'm wondering if anyone has found a way to use GnuPG when using Netscape > > Messenger. Any ideas? > > No way. > > I started to do a workaround based on a local proxy used as smarthost > and pop3 host for netscape (you can enter localhost:1234 to connect to > an smtp daemon running on port 1234). This tool should do all the > crypto stuff and has to popup a window to ask for passphrases and > to select the recipient's key. > You can always use premail for sending (on *ix systems). Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy daj? biednym chleb, nazywaj? mnie ?wi?tym. Gdy pytam, dlaczego biedni nie maj? chleba, nazywaj? mnie komunist?. - abp. Helder Camara From ls at Gambit.Msk.SU Fri May 19 18:26:03 2000 From: ls at Gambit.Msk.SU (Sergei Laskavy) Date: Tue Oct 7 21:26:25 2003 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" Message-ID: <20000519172603.C9570@Peru.gambit.msk.su> I hope you will be happy to repeat this: (0) I use $ gpg --version gpg (GnuPG) 1.0.1 Copyright (C) 1999 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Cipher: IDEA, 3DES, CAST5, BLOWFISH, TWOFISH Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160 $ cat ~/.gnupg/options charset koi8-r escape-from-lines force-v3-sigs honor-http-proxy keyserver blackhole.pca.dfn.de lock-once no-greeting quiet load-extension idea load-extension rsa (1) Here is the test message: -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have just uploaded mutt-1.1.12 to ftp://ftp.mutt.org/pub/mutt/devel/. =20 This is a check-point release to summarize the few changes since 1.1.11. For 1.2, I'm mainly waiting for Brendan's pending changes to the IMAP code. Season's greetings, tlr --=20 http://www.guug.de/~roessler/ -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOQH0otImKUTOasbBAQEr3wf9GOPFRB12s7Hs+XOEwQaPhiJpFPkQ5vlh S/MYOZ4UzNMhYVpqlASAQeHk2lQFP/aQscFo0ltv7cTUmHmNgPBP/1MnkuFVMXo+ M4wb69qKJytxbDurpgHES2Y/WasPGKM6Vt2sjWNCA7UsBsorg86wCdl/fwe7pCz5 kc4emPbMBo2Kw9WI3GPP3lf3XNQKi82SfA6ilAKVOjHvhOb1odoGoCQBis8P8D11 r6FoaAQsi50vsMaUVFWET4udqNCtNfDLAZFjN0iGLL436Y9jHe95+Kjuf2+Q+MXZ 9TUyjPfboB+PzyIfPgdjl56UFFsiqUM104AWXhmdGj5XWO0pjZdVFQ== =OVlh -----END PGP SIGNATURE----- (2) Here is the public key (it's also on keyservers): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.1 (SunOS) mQENAzSgEssAAAEIAMgjiiDIe0zOqjJ2TcsWXW9DYTFzyHPSYJTBHjivb0Vekmra x+M/r6U+AWM1Bf92fGWx7cMn4oYkkaMnO8LQrBXKC8IcnwrJitvh1O0xCnIqWi1E b2JOUlxRJuVYrBNgm0OxlKBCxCmKs4yvZsJ3ykClkUJmSmBV9qDpRUJqxGzyzJ97 C36mbWV/LBKamhFcuDyAmPLZPYWwijaqixXDBuC5ouEPPUmFDgkN5F2533U/imej LSEVOMIthr1qH++wx1g50imHnmKjrtwSn4zA/f++9nl5YyOP1DwZKTu+91JEJPTH aDSnKzWRk/t7lx2JfblDjxYQlziz0iYpRM5qxsEABRG0IlRob21hcyBSb2Vzc2xl ciA8cm9lc3NsZXJAZ3V1Zy5kZT6JARUDBRI38b4/CdxwOTnzf10BAW1aB/9p2gpa ggQjcB/A3kpSEPAhc+U1jP4AVFx3BIdj/yceArIdi/j87CMN5tdHMkktC9ym5/qJ wCWn5YRnl7nF8hT1tLICmO+t/vbo4X0U7kykGVNhbHNMsMpHfBT9S88BkJno1s2D GTTN1gVloDwa4aSbqW1ltRCSSZFoSwigJUQCNYU/e7HOdYe+F+kybXZPvA9L5rg7 zW1vsp0vTLglFpmjLCgaEIIFgp297eW8wmXo/IKuWAO+kNccI6Y4JCJ8+kJfqSgw y7xpvBnuyFu/8/UHcw+wL+uUMRHzrlAibPqy3k3ZwUDOkJeLL9GJaMH+KbzlNzTS tIR1Q6188D/7Hj7piQCVAwUTNyHtwAui8ZR0SloRAQGiugQAqEAoo07fFF1RFgWP J1SVmlJDLy0O2H9hkB6KJAMtds3ga9Ku5exJZfgDz1W839yM0ntgprPHmLtlVp3f ZrLwlUjcr4IXmY45myX6I1xa+TiHEQh61U1fOPzYYR9o+3acyEZE/5uEd0ve66y7 iROHZtoPyvg8uudEHA1wd9l/TwaJARUDBRA4IDMZC+VzVzZkFFkBAUpfCACAJOPE da058VbTx721fDrNxCQu6Fk5LbbP3VTutWasWgit/s1Wnr32SptVRXqsjYp5BFwV Ug0JC8rGBfB1yAG9lXJaHrGoDuqdDKbdpZRFE8UtLnVktfW51p4ZcfuQb3DVKx3Z SVIhVrKaQUt50tWpAme+6jQTjotsO3lGtuFHyhXa/3nXQG3evmagSpAmb7Uu3b/m NSy1YLNf1h6jaJZvYKjchcgE0WE7jEJ2tBFoMd1GgSRij4WN7XLkOLPpGMma/a/A 6DNyD+/UTsZbb27pQNW32KNcA4EN8Zu1npzgNcNYd7NqScjcf0wiXkqZFNHr1XSO c8/IEsxp8v+wuhikiQCrAwUQNLu+OBKt/zYZlwkHAQEyugSwpalGr4euJUpkobI/ WvrnGAqXZRj++1/IEof7x+Jl2TnOjrMLZflgCwy0E2ZaBQpQxEcAwsNfFW/i+zGg 6+ctwN9J7SxEnN2TnUNBT2l5foRx7fIVNi3AXoOd6b8xmvad/FG83utrCxUpvWnW ZMY4C6rZKCgjXtRpd9pSwU8X3QAmI8p3dfWdLxAoZxgzJZVPlewwVRwpiQCVAwUT Nx0OJRRPLUVPVwujAQHHgQP+NF0YAIL3kl+q2sa9YCUXNgCQ+mTvZb3Zzu/q3u8+ ixTowui8bLBTFY3+yIx6IzEHATcoUPCthYwnvfX4BqWNWgDFN+eWaNrZpNEfZVkW Bs6Sd0/R4AcERUcoyp48pnH77E/XS4O4b9VlFYiQV9CX+er6VD5f0ERuNiTaD9pQ Ec+JARUDBRA3JupwLHrik2A/LQEBAf9IB/9Tx58nqBfmTok8VdUQj7bZPksOTlAK WG/f8RD5johFz/OxIey3+K1agiLA+Acr8agfQMAvfxNliJIFGcVgkyYlr/zr4aRh 6e+KEjPGuYgV607be1hPm7xmjNzJklXV0ouKgFqB6kNy+FOdG2OWXrzMQO/Dbwh6 /ofToNoOdsit9mQ5HxUuq2f0TmrjVwoBQqj/QxzA1mS/KgCdsPlEF6v9BsoXyxF3 0Wbj+h+nAU3EdOWgOTexmhcpmOvKx5bW766mB+zAdpj9c33xAMU9lt6bIIcD3cxJ fs7s9ZhWlczoarpUwU+BoKE0dMfvs6cf6NPcTrODqvCUAJwYCR42KZdZiQC1AwUT NKATSj4lAO9ZMjjhAQFvHgT+Ol0myw6jILx78keIEDdJy/fxdK6T56XUYX8nNez3 Ibm300bT63yvEnD3U6pgN+sEyzuLxP/L07Jk2E3OHJHLXJpLHWQlebW3ey9EEaYV xjClSFrmidc0Jd5nMAFmssJ9AHuENKvO096yHTMvH3MYIjYJ1HfyDUnIVDwFL8KF 4fwQezrtMwWzt8WSjWEbGmXZXW7kZ1lBnL8f6eYvCigFYYkAlQMFEzSvti9Dr0FE 3QjdbQEBPdYD/3zZLNh9rPPQ4pZ/0HfQr88BBrjIdKIXuEaZbkfiohuKf44RqOdt k832Mmb2yrp6i8IN8UHPPTpM7xfvmab2Rk21SxRZJ0IsbXzYVSP1oxdE3lIOyVlB vtn1FXEU9JuGD8N9dM994Yirg/2EfjpPJ7SdRMIdtrFAzagJvAvmdk7iiQCVAwUQ NO2N7knh/jPvZzKNAQFdlgQAlGd9mSgxjv6Id8FZ3lMhU0RzKvHNFRof985lkyJt R/01qAJZbCxeJB2y5diLw6qZaVw6+hCqgP5Bbw8PPtKr7i/OvAXBPgoU5Ume4J2A EsavEmavAJ90Zph0WK2BzqCQd1EP5M2jqdBATDunL67rJ5bk0l7y/KwgM5NhyCmY FNmJAJUDBRA0xeJJTFllIALEMQkBAdTfA/42FNAByvEHM9pRkK4qftVDSnIIZeRP uIfV+mO4FcNE9h/oH3nBSOUGn7NqsjwJuj4daZ2tmWfH41D8oQjPVqdM4fd0csYk FZLI0qu1wTd8MxEJsHoh5qIU8M6ywL5pIflhOP1wGf6omqBh2VZuhYY6m0775Lih A0c/DLokymQ6C4kAlQMFEDccqjNMo00siEncPQEByDcD/3cUDPeFBlzq5SSKANRA emT0HoW+aoUO+bRavqOzwCuYNhkSNx7yukACFc8fu13vlBpHL39RLJC6zT+8rto1 MH3SLnJNJj7FH8NZUQDffwXXea3eydNCx0T9fVu0QBndPvyib6K3oVD/Z6yirbo+ pNZnn6U8aOrEXf18IizhhBdxiQCVAwUQNvYNv1H8PGQHafT1AQGBrgQAhWdZ9ws2 EIh8LJEAb53FHcjonandcJ7HDgLo3GpWnhIvhcc+YKQluW/8lS92bsjY3tVRfDYe Y80NjEODDgn+CEcOu9LqssGj4CwuU7b58tBdSIV1v7CSX9cTM9+0r0qGU7ql7Lpn zBqhx36UXqOK6vfU0cWrHLkPUNlms2a96LeJALADBRA3TTnyVmSU4zFmVdUBAZlh BNEBfEm35/lKlMV3hlFMT/K7ZhddrptYh+vCGhJNSO48KD+6foES7zgAH8k1j1Wh A2b4oVG7X4x5T603UqGDFpaycddqxGc7Bs7E0aAVygEkoJQ6c8AjSkyy/lRnGZ1G ln7vPNM8TokQJQRKfkm/tPpE1jneaU/j102We0jg2ULyJQOLB73acI/v5O4p1d1F +W5S3XySxxDcbOWJjYkAlQIFEDUZVnh4YVpjdyds6QEBU2sEAKjJkcCiOqnyh7I7 O1PIVbEWumltWd5CXDT2MwMXX5vOGex//qERDNDqR4w1ksPj3NVOkSaVFQMjw2Ys zBFFHma45LZPSxv2UGxjII8qPPgPmkllLyhHCGrDRY+IZ0Wax+HFfJe3g6xYYgCl ojNVd1chV9eduNZLxdvhV4YKVSHMiQEVAwUQN1PmOH4v6i2JDAmBAQEP3Qf5AYd0 ytzQB36MJHx+jHismpNsJEGj/rQ8PxeWnic9GkcgBi97wflQaldonFlvoeNFyIwS MTLs2vZTeCRLMxc1LFnwurx8/2oks9xp63733Rqs9DonnkDQR04YWLkw4djTaEDc /GWHCyYiPj11G/12b09ywf4nPd32K8AVoIQAPQy5P4GRhesQTvWTl1yXLEVWjv6g PLJUo3l1BrIKm+GMdnlBqTGpswPtkxeUqp8mjYdwnmm5ajX/qkxe1UE/t5V74169 uTL1+DjEl3CT+rVR6UtEc2qM3Zg2PTzgjmrFfHeUdXv1QBfRJlhmtPQtRX4csDFP fX0sO5n5PZpYcYlzC4kBFQMFEDTFOAt+8FjoQyMUJQEBjpIH/3Uwc8cMr8RAie00 9a7536V2x2miBAoTAjsb5ui91geM4ssXgilUgB/sBW/bV6cZA67Q7YYSollFSKPb LhmoZUEvkf+cS6cdojUbq2p2pd7Djq3ZSYNTRbIKo8KWBLSfSuDsxdu0oVdW3DO2 5TMzkauxNnqMegWjLSRCMRigdQYYmZKrA9tY6hD63c6eLt2DAWuF+pepwo5N6jm7 yGHWAW0ihhqv+NHlIc3JExxxzDYeTjC4Yb5dfHpYG7ETbsMZCQ77Ru1isbcA557/ kgSwKPUt0LAMgVj9atG4OIezjwPubEV/SxvcRnjEKsQOQe7WriLcPjeELlMvakBc nDS7NtqJARUDBRA29l83fvTWwzbkE20BAc0HB/sGlryh+m+UJR5TjI7cMf13UnFh vL88TIRLGxVwsOYoKixiU1hPecGFWcXsnYue6Hduvb9EiBdn3GQcKQAda0TtCXoJ 6gmph8xx7cGqSGd1ldh1nkWbGsCt82HcK7XQ0qF/zUTuRwxi7F30YI5ZBYBLOVsn dB7rMm4ObkHH0nskMMMfZ1VcsT5ndvKL2RvevRaleXob14erDDsEmqKzPMRpyTKO CAMnK5k86P8uK+8hg39rLSQodPKzxvtyJNEDt3iizQ+Ac1nlPIeO/pN7CnqJwu5T codS9bVe9A39gIqhbCp8zYjKD+uU+8tOGYthuU2FvgDaB0NU+pzSaw2X2se6iQCV AwUTNK/OIokABLrCbuiRAQGsdAQAxOh0ipz4H80XifbWjh+W721oIwXGjBl/n/e/ UJh7cqzqZxo+I/vR3O0wCfnkeQ94ihe24eamvEvwvWbpRmnfqozp2Fuo9JcazgML j0eDmqZCe0XJEi4t3WdIavy59XskuzPaM8AepRKULStKup22o5jgvOnK6/2KcYmx oKULfeCJARUDBRA1EBSciVPDw6koVP0BAQkvB/wN1M5oadLBjOIgm34y1qtxnkvF ZuPIJIWVVX+3Fz2FwZ84OIqVtNGxjKAOkyFG371+wEXc7xZZ9owSCO2edVTCC2wL 2mDFostS7G4aTDWvXMx0lWTTc8V2RZTOQ8bGJDo+6HgFNg4gV/03MpPqB413yVas XseES/yCt+haLnk85mO8KVSGP7DAdwJn5tLx3GKHZE3Qh9XTJ0j4V/9uG8ohf94T O63s0V/3ZAMUK8GaP4kiC5d4ZEN+4DyHw6xjYTmrRp3tvXKJrUHaSnCXaS7Obr2C DO5LyRi07qMrkHAxjmDMdJYHyS9SEPqphx+/1TyYZQx1edrlLiY31YSFEpH+iQCi AwUSN/G+HpFeTizbCJMJAQFzUgRmN7+0sKxmW7m5MBaB2dHnOpoya6Kxzbp3oghW 8cX4+DOI4zukBDWvEnnreCnbl4dFoTr38+GoG336NozKhKvx5kvSqBzL6XpzXrT6 OTg/b2NGiFpSR0QKNJtNSUUwGwSVDa1Yqqn0FMmFGAeI08p+VeMXLpwjDWXsvRYr 9S+fVY+jDNeFRv7yOUFOZTstiQCVAwUQN29YLpznb919i1kZAQEDSQP/bbq6SB16 jS7IjIcUHHvhHZ3aXmFkx55kcKPnBZrzPOAN9R6jFDS1wu0ejxVPNp6iGzODq2tz UPv5HJfWufxMaxHpnHQ6J5+EwpLQwWj2PrSQg6idNA4W/0eFLi0SOlFj8JAXt69j fkl/K4R/kiNPVL2FVWQMCOLtYVxTbkf6XxqJARUDBRA28ZJ5nnPrCk1Y7lEBATqQ B/sGsKnPF45GKF7Yu/3dNwQD38g5Qpj8+7ddPcjME7tmkD8BHFR6o6bDtv7zWeEF uxg+XjAxg4dPSHrAXdKZ5SDHqJO7+GbZP/eP7zoGw4V1GVnCz0e0v2WXUfe56oFu oO/4XRrbsWhAtYPGeYi9BO/XRDIjDmjvFvjitjwIgxzUb/t6DqPMHchRpK1MOTWs bvUOb8Dz2U8YusH/G5puw2AemLyeXx6erZJm385bcAzgoP+tp4fA6SjSlQs9FD7J Y4goyBv534fluGGHth+nuIB2jn+zHOkcUgAgOJPSGmZSsSxXKQxfL1Xr1SdNbT16 i2VOIu7MWkceillxJUMIHE7ziQCVAwUQNMZ9G7Btxkr72ChhAQFIuwQAigFlRtsE jhtOXv9+Ot2gqKbqfj2TkOTCpr4HRlFGDzkIkbBZsp8q2Af5ZiQ7/h/g1asqbvzK J6XTWQo6K0U9iiasWYpXlUlrlVhMjm3hUrGLaMglGcnURemVHhhfS3S/4aggJqW6 Dt5U10txXrAdKfegU0+HEJ5L6WuKaulDxViJARUDBRM02HCwvqaOf4UxMn8BAfIb B/4omzocwa8eHPZgsuwq9pkU69qtJmndgxAxzSivSfd8UV3rVKquxIfPWTJuBuug EleQlskVASKiQVKubgSpP7VcyHimzgPt9w/RKLDpDAGAzZh6r9PX3BxdKxaig2Ny eiCmLYv7oZG6nOFa1xaPYmjxVDOwT39kZE36O2Boe5rW2Jj+GG/Iwxt4iGToXyZW Gz7uXP/Ar3O+kjQzgg14ieFkyOQYuI1Br/9ZCMIFwjHXfQsXRYP+ftTLi9DYfTXh G0bP+bc1FdiRLjM4IHYJ9ydl2p/1TL01ZO6eb9DB+a9esjXfb//frYCRFNPKoV/A b4TgVWYqAJlLczLEwfBkbkZgiQDVAwUSN/G+Xb+Ot2lXSNSVAQFEaAX9FQjXrDRc /FqkeiBNievdgVt03Lrm2XYkKnnvh059M7i+S/tVW7ly3sifvM1J4X2hvT9jbhb0 lD0gISXz85n7pHMpf4cxJpTnMefRBKFoDA2AYLUHL8Rq+VOKkdPM8pCgySU69Ssu ZPrK7kOByWiU8VeekL1+7236QrstzE+P8ePygXb6hrQZXzgClVq9DfVu3r5BRagU za/CDfuECEoRrdCPNOTOcC2PbdJjtLQIAm8m+llYXkd0Ij3zhB1HAISwiD8DBRA0 3w93xiLu3cOF4DcRAoYMAJ9AxHy1WoKMNp5BtD7bJVPiWmXXjwCfcaeh4TirEQLm aMT+TdecW0Nv1E2JARUDBRA0oBMs0iYpRM5qxsEBAUT8CACbuZBD0zuWHTuqTvEY MIuO/VJL0f+op9IwpMjD2W8EzXa5XEq4WoCdff9YzSZUT/T6Sy2ZcercLgthJRcr gQowZAQvn3UDnbF7OpPv3cblapmb2lvIDhJESco/I1R08kZN905bFmkcF1sNXsjf 6B+K2N2BSizbE2aS8xIJ+tuRDGeS1Gsai1e+impbGbVQiO4lUQlAOZeJPQ7IOtED yEHUjWw1FsOq/x9GNZMMxIqN/BagsqpA7eHJ76fsMQN1f0kh3oepaN3lZ7xqoSGE MIpf/eCzawGwlrEA3aROCjr33+hHzimIj8rtuxKUAo0jvNs8Wg3V3mXW/QgWhW1y hfLAiQCVAgUQNK/96fE8+WC3TbWNAQF40QP9Fq0LhANCSh1cQFqxIbCtzgyEm0ZL Ujx0fFE9onyE0/Jnuh+3fvRGde0UxzEfrTqf3Z+1hxYDtnuxcRUTlVSFRJfvO3g9 b+fcw08BG8hLpexQ1Jl27rEQEnxu3kyxtw+WkxDw/JMzf0bPG7rz4Rp2UbwOvFCY 1mLh+fsl4QvdnGCJAJUDBRA0sj2j9e+XfZ71UOEBAT9VBACeGQsN4aabBhcJlQIV XO9MlDY5ioWgRgAS/WCLgXf5FNvT5hVKv/WNHoe4VLQjJQE17MocrU8MpYxkoXBk JgNLfMl+hp7wACHXvn9m5MTJFJuRx3uuuyNi5Tyjhtovpn6MUn3nSxLID/F2XMMo Vfhu0Pz0V+DHMa2kVl1U/Xa+wQ== =jubg -----END PGP PUBLIC KEY BLOCK----- (3) Start gnupg by $ gpg < /path/to/saved/pgp-message gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK ^C gpg: some signal caught ... exiting -- Thank you! From wk at gnupg.org Fri May 19 17:38:46 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:25 2003 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su>; from ls@Gambit.Msk.SU on Fri, May 19, 2000 at 05:26:03PM +0400 References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: <20000519163846.M14819@djebel.gnupg.de> Hi, iirc, this has been fixed in 1.0.1f - can someone please test against this version. tia, Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From offby1 at blarg.net Fri May 19 15:12:55 2000 From: offby1 at blarg.net (Eric Hanchrow) Date: Tue Oct 7 21:26:25 2003 Subject: How to deal with old RSA keys In-Reply-To: Dr Lyman Hazelton's message of "Fri, 19 May 2000 13:45:14" References: <3.0.3.32.20000519134514.0099abc0@mail> Message-ID: <8766saz1k8.fsf@potato.hanchrow.org> >>>>> "Lyman" == Lyman Hazelton writes: Lyman> But I have an old RSA key that's been kicking around for a Lyman> long time and I didn't have a die-date on it. I still want Lyman> to be able to get messages written to me with this key. Is Lyman> there a module that I can add to gnupg that will allow me Lyman> to do this? Not everyone is switching to gpg and I still Lyman> need to hear from them in private. This should really be a FAQ. If you're using Debian GNU/Linux, then all you need to do is install the packages `gpg-rsaref' and `gpg-idea'. Then add these lines to ~/.gnupg/options: load-extension rsa load-extension idea -- PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5 C8BD 6337 0041 C01C 5276 From sroberts at uniserve.com Thu May 18 21:03:57 2000 From: sroberts at uniserve.com (Sam Roberts) Date: Tue Oct 7 21:26:25 2003 Subject: Solaris random device In-Reply-To: <00f101bfbcd5$f327f000$16006598@asiainter.net>; from em@who.net on Sat, May 13, 2000 at 08:22:18PM +0800 References: <20000510210808.A9104@tehran.nmrc.ucc.ie> <20000511150411.H32456@cosy.sbg.ac.at> <20000511161902.Y7032@djebel.gnupg.de> <20000511190100.N32456@cosy.sbg.ac.at> <20000512231404.A10088@tehran.nmrc.ucc.ie> <20000513105924.S32456@cosy.sbg.ac.at> <00f101bfbcd5$f327f000$16006598@asiainter.net> Message-ID: <20000518200357.B471@localhost> On Sat, May 13, 2000 at 08:22:18PM +0800, Enzo Michelangeli wrote: > ----- Original Message ----- > From: "Andreas Pommer" > To: > Sent: Saturday, May 13, 2000 16:59 > Subject: Re: Solaris random device > > [...] > > Currently it is more similar to the linux /dev/urandom , less to > /dev/random. > > At every call to the device some entropy is added (from a high resolution > > timer, and sometimes process id) and subsequently mangled by some hash > > algorithms (IIRC SHA?). Still todo: More entropy sources have to be added. > > The solaris kstat interface provides access to a large number of kernel > > counters which can be used for that purpose. However, the "good" ones > > have to be determined. > > Why? Just toss everything into the pool: the total entropy cannot be reduced > by adding low-entropy data. The more, the merrier. Yes, but the implementation of /dev/random so that it blocks until sufficient entropy is available, requires an estimate of randomness of input. Some statistical checks are done to estimate this, but when data is put into the pool it is identified as adding to the estimate of bits of entropy in the pool, or not. GnuPG, for one, attempts to select() until as much entropy as it wants is available. This entropy estimation seems important, though fairly fuzzily defined. Sam -- Sam Roberts, sroberts at uniserve dot com, www.emyr.net/Sam From tyketto at wizard.com Sat May 20 02:42:38 2000 From: tyketto at wizard.com (A Guy Called Tyketto) Date: Tue Oct 7 21:26:25 2003 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519163846.M14819@djebel.gnupg.de>; from wk@gnupg.org on Fri, May 19, 2000 at 04:38:46PM +0200 References: <20000519172603.C9570@Peru.gambit.msk.su> <20000519163846.M14819@djebel.gnupg.de> Message-ID: <20000520014238.A30251@wizard.com> On Fri, May 19, 2000 at 04:38:46PM +0200, Werner Koch wrote: > Hi, > > iirc, this has been fixed in 1.0.1f - can someone please test against > this version. > > tia, > > Werner Has this been released/uploaded yet? I'm not seeing it, at ftp.gnupg.org:/pub/gcrypt/devel. 1.0.1e is still the latest and greatest there. If it's located at another place, please let me know. :) BL. -- Brad Littlejohn | Email: tyketto@wizard.com Unix Systems Administrator, | tyketto@ozemail.com.au Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 241 bytes Desc: not available Url : /pipermail/attachments/20000520/c3ab8314/attachment.bin From hideki at allcity.net Sat May 20 17:31:18 2000 From: hideki at allcity.net (Hideki Saito) Date: Tue Oct 7 21:26:25 2003 Subject: Windows version of entropy.dll problem Message-ID: <200005202329.QAA19377@server-1.visp.net> I have one bug report (among with fix) in entropy.dll which is distributed in GNU Privacy Guard for Microsoft Windows which is in the download page. It is that in certain circumstances; most visible in Windows 2000, it crashs when it is executed to generate keys, it crashs. This problem is solved after I compiled entropy.dll from sourcecode using Microsoft Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll Thank you. -- Hideki Saito mailto:hideki@allcity.net From hideki at allcity.net Sat May 20 17:41:15 2000 From: hideki at allcity.net (Hideki Saito) Date: Tue Oct 7 21:26:25 2003 Subject: CC Request Message-ID: <200005202339.QAA20452@server-1.visp.net> Sorry for bother about this with separate mail, but please CC me if you have questions or comments about entropy.dll, since I'm not subscribed to the list. (is there anyway I can subscribe to it?) Thank you. -- Hideki Saito mailto:hideki@allcity.net From wk at gnupg.org Sun May 21 20:22:36 2000 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:26:25 2003 Subject: Windows version of entropy.dll problem In-Reply-To: <200005202329.QAA19377@server-1.visp.net>; from hideki@allcity.net on Sat, May 20, 2000 at 04:31:18PM -0700 References: <200005202329.QAA19377@server-1.visp.net> Message-ID: <20000521192236.D3283@djebel.gnupg.de> On Sat, 20 May 2000, Hideki Saito wrote: > It is that in certain circumstances; most visible in Windows 2000, it > crashs when it is executed to generate keys, it crashs. This problem > is solved after I compiled entropy.dll from sourcecode using Microsoft > Visual C++ 6.0. It is in http://www.anime.net/~sasami/entropy.dll I am in the process of reqriting it without the need for DLL. I hope to commit the changes on Thursday or Friday. However a lot of new testing will be required then. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From rguerra at yahoo.com Sun May 21 14:54:59 2000 From: rguerra at yahoo.com (Robert Guerra) Date: Tue Oct 7 21:26:25 2003 Subject: GNUPG & AES Candidates In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> References: <200005202329.QAA19377@server-1.visp.net> <20000521192236.D3283@djebel.gnupg.de> Message-ID: Werner: I'm forwarding you a message I recently posted on the pgp-user's mailing list (http://www.cryptorights.org/pgp-users) . I'm curious to know if you are considering adding any additional AES candidates to gnupg. regards robert Date: Sat, 20 May 2000 22:45:31 -0400 From: Robert Guerra Subject: Re: [PGP-USERS] PGP Desktop Security 7.0 To: pgp-users@cryptorights.org Reply-to: pgp-users@cryptorights.org Tom: At 8:49 PM -0400 2000/5/20, Tom McCune wrote: >I found the following at: >http://www.pgp.com/asp_set/products/tns/pgp70_reqts.asp > >>Cryptographic Algorithms Supported >> >> Public key algorithms: Diffie-Hellman/DSS, RSA >> with up to 4096-bit key lengths nothing new here unless 4096 applies to RSA as well. >> >> Symmetric algorithms: CAST (128-bit), 3DES >> (168-bit), IDEA (128-bit), Twofish (256-bit) twofish is new...but it hasn't won the AES competition. Can the Rijndael cipher be added too? I believe that the other AES finalists should also be included. It would make good sense to at least keep the others in mind in case Twofish doesn't win. After all, it would be nice if PGP v.7 could have the AES winning candidate. For what it's worth.. At our Toronto May cypherpunks meeting, it was mentioned at that the Rijndael cipher was well looked upon, and a favorite of many at the april AES conference. As it's invented by a group in Belgium it will be interesting to see how it plays politically in the selections process. After all can the americans seriously consider to accept and deploy something made outside the USA (NIH - not invented here, not good) >> >Any other news that can be shared on related changes would be appreciated. Some references: Video Report of The May cypherpunks meeting in Toronto (Canada) http://www.epress.ca/privacy AES Round two AES Round two analysis AES Second Round Implementation Experience The block cipher Rijndael -- -- Robert Guerra , Fax: +1(303) 484-0302 WWW Page PGPKeys From Nils at infosun.fmi.uni-passau.de Thu May 25 17:02:03 2000 From: Nils at infosun.fmi.uni-passau.de (Nils Ellmenreich) Date: Tue Oct 7 21:26:25 2003 Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: <14637.12891.65451.656522@skrjabin.fmi.uni-passau.de> Hi all, we've had quite some discussions on this list about the various random "gizmos" available on Solaris 2. I'd like to summarize the possibilities and then make a suggestion. The need for entropy is not a domain of GnuPG alone; OpenSSH needs it as well, and there may be others coming (BTW, I've heard rumours that the OpenSSH folks are considering to use gpg keys instead of their own user-level public keys. Does anyone know more details?). There are currently three options that I am aware of: ======================================================================= 1. Entropy Gathering Daemon (EGD) Available from http://www.lothar.com/tech/crypto/, latest release is 0.8. This is a perl script running as a daemon, providing an entropy source through a pipe. EGD is supported by both, GnuPG and OpenSSH by means of a configure option. The latest release even works on Solaris 8. It works very well, the only drawback being its speed: if you need a lot of entropy (generating keys, multi-user platform), egd might be a bottleneck. 2. /dev/random as provided by Sun package SUNWski This software was developed by Sun as part of the unbundled product Sun Webserver 2.0 on the Solaris Easy Access Server 3.0 CD. This product was supported for Solaris 2.6 and 7, but not 8 (because Sun is now using Apache or Netscape's web server). However, the SUNWski package still works fine on Solaris 8, provides entropy much faster than egd (it's a daemon written in C) and was reviewed to provide high quality entropy: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=95618127814224&w=2 SUNWski's /dev/random is natively supported by OpenSSH, but in order to use it with GnuPG, you have to apply the following patch. That's because SUNWski provides /dev/random as a pipe, and not as a character device. The patch is relative to the current CVS snapshot of GnuPG. As SUNWski provides only /dev/random, the patch assumes a link from /dev/urandom to /dev/random. diff rndlinux.c.orig rndlinux.c 86c86,92 < if( !S_ISCHR(sb.st_mode) ) --- > if( !strcmp(PRINTABLE_OS_NAME, "SunOS")) { > /* Solaris 2 Easy Access Server -- SUNWski */ > if( !S_ISFIFO(sb.st_mode) ) > g10_log_fatal("invalid random device!\n" ); > }else{ > /* Linux , xBSD*/ > if( !S_ISCHR(sb.st_mode) ) 87a94 > } diff configure.in configure.in.orig 447,458c447,448 < [case "${target}" in < *-solaris*) < if test -p "$NAME_OF_DEV_RANDOM" && test -p "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < *) < if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then < ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; < fi < ;; < esac]) --- > [if test -c "$NAME_OF_DEV_RANDOM" && test -c "$NAME_OF_DEV_URANDOM" ; then > ac_cv_have_dev_random=yes; else ac_cv_have_dev_random=no; fi]) You would then use the random device type "linux". However, this patch breaks the use of the 3rd option. 3. /dev/random and /dev/urandom by Andreas Maier This is a new port of the Linux kernel random driver to Solaris 2 as a kernel module (what Sun should have done in the first place!) from http://www.cosy.sbg.ac.at/~andi/. It's very new, therefore hasn't been reviewed regarding it's entropy quality. As this is a clone from the Linux port, both are character devices. Therefore, the GnuPG sources don't have to be patched at all. You just select "linux" as the random gatherer. I've tested it on Solaris 8. I didn't recompile OpenSSH for this, but a quick look at the sources suggest that it should work there as well. Unlike GnuPG, OpenSSH only tests for existence and readability of /dev/random, but not whether it's a pipe or a character device. Being a kernel module, it should be pretty fast (didn't try). Personally, I would like to have the source reviewed by someone who knows about entropy gatherers before I'd use it in a production system. ======================================================================= Proposal I'd like to see GnuPG being a bit more flexible on this issue and therefore avoiding the need to patch it. I think that taking the OpenSSH approach (testing for existence and readability of /dev/random and /dev/urandom, being still happy if the latter doesn't exist, and don't test the type of the device; suggest the use of egd if the devices don't exist) should be OK for GnuPG as well. The naming of these random gatheres as being "linux" is a bit unfortunate, but that's just cosmetics :-) Any comments? Cheers, Nils -- Nils Ellmenreich - Fak. fuer Math./Informatik - Please use gpg - Nils @ http://www.fmi.uni-passau.de/~nils - Univ. Passau - Uni-Passau.DE From sam at cogent.ca Thu May 25 11:25:37 2000 From: sam at cogent.ca (Sam Roberts) Date: Tue Oct 7 21:26:25 2003 Subject: SUMMARY of Solaris random gatherer options (long) Message-ID: Previously, you (Nils Ellmenreich) wrote: > Proposal > > I'd like to see GnuPG being a bit more flexible on this issue and > therefore avoiding the need to patch it. I think that taking the OpenSSH > approach (testing for existence and readability of /dev/random and > /dev/urandom, being still happy if the latter doesn't exist, and don't > test the type of the device; suggest the use of egd if the devices don't > exist) should be OK for GnuPG as well. The naming of these random > gatheres as being "linux" is a bit unfortunate, but that's just > cosmetics :-) > > Any comments? I'd like to second this proposal, particularly about not forcing /dev/random to be a character device. I ported Linux's random to QNX4 and Nto, and I took the approach of making them look like character devices so gpg would recognize them. I don't really think they are, any term control ops on them would fail, a named pipe or a QNX named device would have been more natural. The term linux will be increasingly a misnomer, I believe the *BSDs have a /dev/random as well, for instance. Sam -- Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca) "News is very popular among its readers." - RFC 977 (NNTP) From koch at hsp.de Thu May 25 18:37:26 2000 From: koch at hsp.de (Walter Koch) Date: Tue Oct 7 21:26:26 2003 Subject: gpg 1.0.1 loops forever with "gpg: NOTE: signature key expired" In-Reply-To: <20000519172603.C9570@Peru.gambit.msk.su> References: <20000519172603.C9570@Peru.gambit.msk.su> Message-ID: Moin, am / On Fri, 19 May 2000 17:26:03 +0400, schrieb Sergei Laskavy wrote: >$ gpg < /path/to/saved/pgp-message >gpg: Signature made Sat Apr 22 22:51:14 2000 MSD using RSA key ID CE6AC6C1 >gpg: Good signature from "Thomas Roessler " >gpg: NOTE: signature key expired Wed Feb 09 17:11:31 2000 MSK tested it with gpg (GnuPG) 1.0.1f-snap2000-05-25 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: Warning: using insecure memory! gpg: Signature made Sat Apr 22 20:51:14 2000 CEST using RSA key ID CE6AC6C1 gpg: Good signature from "Thomas Roessler " The NOTE: is completly gone! Gruss, Walter -- Walter Koch Hochdahl am Neandertal http://www.hsp.de/~koch/ qrv:db0iz-9 walter@1409.org ham:dg9ep@db0me koch@hsp.de From bem at cmc.net Thu May 25 15:39:15 2000 From: bem at cmc.net (brian moore) Date: Tue Oct 7 21:26:26 2003 Subject: Clearsigning (again) Message-ID: <20000525143915.B24700@cmc.net> I know there is very little in the RFC regarding clearsigning and that PGP-MIME is better. But Network Solutions wants clearsigned (and so do many Usenet readers since multipart MIME is evil on Usenet), so I need it to work properly. >From the fine man page: -t, --textmode Use canonical text mode. If -t (but not --textmode) is used together with armoring and signing, this enables clearsigned messages. This kludge is needed for PGP compatibility; normally you would use --sign or --clearsign to selected the type of the signature. But this doesn't wholly work. [thorin:~] 2:10:46pm 193 % echo foo | gpg -t --armor --sign You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 foo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5LZbaN3/OJIgyK1ERAm/3AJ99ETFfFOvIS+necd4awNO5S255EACghazh p9oyByxGr6xctlsQTU7C4zk= =myQV -----END PGP SIGNATURE----- The problem is that with PGP, the same sort of thing will have an empty line after the 'foo'. PGP5 will verify the above, but it will be missing the end of line: [thorin:~] 2:12:53pm 200 % ls -l foo -rw------- 1 bem bem 3 May 25 14:12 foo [thorin:~] 2:12:56pm 201 % od -x foo 0000000 6f66 006f 0000003 The trailing newline placed there by 'echo foo' (which emits 4 characters) is gone. Again, I realize that RFC2440 isn't clear at all about 'clearsigned' messages but I believe interoperability is important. How does the above behave with PGP6? If it behaves as PGP5 does, then I think gnupg needs to change. The relevant wording in 2440 I see is: The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. That seems to imply "insert an extra newline here when signing and discard it when you verify". There is also a problem in lines ending with TAB (which, alas, I know because NSI seems to send forms with TABs at the end of the line for reasons known only to them): [thorin:~] 2:15:13pm 211 % echo "foo " > foo # that's a tab [thorin:~] 2:15:14pm 212 % gpg -t --armor --sign foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 2:15:25pm 213 % pgpv foo.asc Opening file "foo" type text. BAD signature made 2000-05-25 21:15 GMT by key: 1024 bits, Key ID 88322B51, Created 1998-10-17 "brian moore " "brian moore " "brian moore " This seems to be contrary to RFC2440: Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Spaces at the end of the line -are- ignored correctly. But tabs are not. If there's consensus that these two things need fixing, I'll submit a patch, but so far I've had no response to these even being problems. :( Again, both of these are needed to work with Network Solutions, which is why it's annoying me. If I manually ":%s/^I$//", and insert a blank line at the end of my forms, yes, I can then submit them to NSI and have them verify, but that seems goofy. -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem at cmc.net Thu May 25 16:08:29 2000 From: bem at cmc.net (brian moore) Date: Tue Oct 7 21:26:26 2003 Subject: Clearsigning (again) In-Reply-To: <20000525143915.B24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 02:39:15PM -0700 References: <20000525143915.B24700@cmc.net> Message-ID: <20000525150829.C24700@cmc.net> On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > This seems to be contrary to RFC2440: > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > any line is ignored when the cleartext signature is calculated. > > Spaces at the end of the line -are- ignored correctly. But tabs are > not. Ah, oddly enough I can make it do this -- but I have to specify '--rfc1991' to do it. It still strips the \n at the end, and I'm not sure why the --rfc1991 is needed, since RFC2440 requires it as well... -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From bem at cmc.net Thu May 25 16:36:45 2000 From: bem at cmc.net (brian moore) Date: Tue Oct 7 21:26:26 2003 Subject: Clearsigning (again) In-Reply-To: <20000525150829.C24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:08:29PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> Message-ID: <20000525153645.D24700@cmc.net> On Thu, May 25, 2000 at 03:08:29PM -0700, brian moore wrote: > On Thu, May 25, 2000 at 02:39:15PM -0700, brian moore wrote: > > > > This seems to be contrary to RFC2440: > > > > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > > any line is ignored when the cleartext signature is calculated. > > > > Spaces at the end of the line -are- ignored correctly. But tabs are > > not. > > Ah, oddly enough I can make it do this -- but I have to specify > '--rfc1991' to do it. > > It still strips the \n at the end, and I'm not sure why the --rfc1991 is > needed, since RFC2440 requires it as well... Continuing to follow up to myself... :) I see why. It's a bug of PGP5. If I manually strip the tab in the clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not recognizing that it should ignore trailing tabs on input. (And this isn't documented in the 'Implementation Notes' in 2440 with the other PGP5 bugs... Can someone on the IETF committee see that it makes it into future revisions? :)) But the dropping-the-trailing-newline doesn't require PGP5, so I'm still convinced this is solely a gnupg problem: [thorin:~] 3:34:15pm 288 % echo foo > foo [thorin:~] 3:34:20pm 289 % md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo [thorin:~] 3:34:27pm 290 % gpg -sat foo You need a passphrase to unlock the secret key for user: "brian moore " 1024-bit DSA key, ID 88322B51, created 1998-10-17 [thorin:~] 3:34:44pm 291 % gpg foo.asc File `foo' exists. Overwrite (y/N)? y gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 gpg: Good signature from "brian moore " gpg: aka "brian moore " gpg: aka "brian moore " [thorin:~] 3:34:52pm 292 % md5sum foo 2145971cf82058b108229a3a2e3bff35 foo I still don't think gnupg should do that. :) -- Brian Moore | Of course vi is God's editor. Sysadmin, C/Perl Hacker | If He used Emacs, He'd still be waiting Usenet Vandal | for it to load on the seventh day. Netscum, Bane of Elves. From gqueri at mail.dotcom.fr Fri May 26 02:51:33 2000 From: gqueri at mail.dotcom.fr (Gael Queri) Date: Tue Oct 7 21:26:26 2003 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net>; from bem@cmc.net on Thu, May 25, 2000 at 03:36:23PM -0700 References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526015133.A308@baoule.ath.cx> Hello brian, sorry to interrupt your conversation with yourself :) On Thu, May 25, 2000 at 03:36:23PM -0700, brian moore wrote: > (...) > But the dropping-the-trailing-newline doesn't require PGP5, so I'm still > convinced this is solely a gnupg problem: > > [thorin:~] 3:34:15pm 288 % echo foo > foo > [thorin:~] 3:34:20pm 289 % md5sum foo > d3b07384d113edec49eaa6238ad5ff00 foo > [thorin:~] 3:34:27pm 290 % gpg -sat foo > > You need a passphrase to unlock the secret key for > user: "brian moore " > 1024-bit DSA key, ID 88322B51, created 1998-10-17 > > [thorin:~] 3:34:44pm 291 % gpg foo.asc > File `foo' exists. Overwrite (y/N)? y > gpg: Signature made Thu May 25 15:34:44 2000 PDT using DSA key ID 88322B51 > gpg: Good signature from "brian moore " > gpg: aka "brian moore " > gpg: aka "brian moore " > [thorin:~] 3:34:52pm 292 % md5sum foo > 2145971cf82058b108229a3a2e3bff35 foo > > I still don't think gnupg should do that. :) It seems to be fixed in gnupg 1.0.1e, so you were at least not the only one to think that :-) gael@baoule:~$ echo foo > foo gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo gael@baoule:~$ gpg -sat foo gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! You need a passphrase to unlock the secret key for user: "Gael Queri " 1024-bit DSA key, ID 3E18F9CE, created 1997-09-01 gael@baoule:~$ gpg foo.asc gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! File `foo' exists. Overwrite (y/N)? y gpg: Signature made Fri May 26 01:38:48 2000 CEST using DSA key ID 3E18F9CE gpg: Good signature from "Gael Queri " gael@baoule:~$ md5sum foo d3b07384d113edec49eaa6238ad5ff00 foo Regards, gael From sen_ml at eccosys.com Fri May 26 13:09:38 2000 From: sen_ml at eccosys.com (sen_ml@eccosys.com) Date: Tue Oct 7 21:26:26 2003 Subject: Clearsigning (again) In-Reply-To: <20000525153645.D24700@cmc.net> References: <20000525143915.B24700@cmc.net> <20000525150829.C24700@cmc.net> <20000525153645.D24700@cmc.net> Message-ID: <20000526120938J.1001@eccosys.com> From: brian moore Subject: Re: Clearsigning (again) Date: Thu, 25 May 2000 15:36:45 -0700 Message-ID: <20000525153645.D24700@cmc.net> ... > Continuing to follow up to myself... :) > > I see why. It's a bug of PGP5. If I manually strip the tab in the > clearsigned stuff, pgpv will then gladly verify it, so PGP5 is not > recognizing that it should ignore trailing tabs on input. (And this > isn't documented in the 'Implementation Notes' in 2440 with the other > PGP5 bugs... Can someone on the IETF committee see that it makes it into > future revisions? :)) information about the openpgp working group mailing list can be found at: http://www.imc.org/ietf-openpgp/ you could post the suggestion there. From rabbi at quickie.net Fri May 26 18:33:46 2000 From: rabbi at quickie.net (L. Sassaman) Date: Tue Oct 7 21:26:26 2003 Subject: Subkeys In-Reply-To: <20000521192236.D3283@djebel.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get an "Unusable public key algorithm" error when I try to encrypt to keys that have additional encryption subkeys. Can we work through this so that GnuPG handles v4 keys with multiple subkeys in the same manner that PGP does? - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LxfxPYrxsgmsCmoRAvQ+AJ9GeC6rsYWb7HxeXnEVsCRYx9eVxgCgwqXl r3pOieMkJByCafQgUfydTiQ= =Hxpe -----END PGP SIGNATURE-----