From dshaw@jabberwocky.com Fri Mar 1 02:58:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Fri Mar 1 02:58:01 2002 Subject: Designated revoker Message-ID: <20020301015514.GB677@akamai.com> Hi folks, I committed read-side support for designated revokers in GnuPG today. It will now accept designated revoker packets on keys, and accept revocations from the designated revoker to revoke the key. It does not (yet) allow a user to set a designated revoker on their own key or allow the designated revoker to issue a revocation. Anyway, it's a reasonably fussy change, so if anyone is using the CVS version and has some keys with designated revokers on them, I'd be grateful if you'd poke at it and try to break it. Thanks :) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From wk@gnupg.org Fri Mar 1 18:31:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 1 18:31:01 2002 Subject: Key version games (was Re: problem with exporting subkeys) In-Reply-To: <20020228135159.GD678@akamai.com> (David Shaw's message of "Thu, 28 Feb 2002 08:51:59 -0500") References: <3C7E0B5D.25D67550@saiknes.lv.NO.SPaM.NET> <20020228135159.GD678@akamai.com> Message-ID: <87k7swpnyl.fsf@alberti.gnupg.de> On Thu, 28 Feb 2002 08:51:59 -0500, David Shaw said: > Florian, this can give you the unchangeable expiration date that you > wanted, if you're willing to accept the restrictions (RSA only, etc.) > on v3 keys :) as well as easy to fake keyIDs. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From dshaw@jabberwocky.com Fri Mar 1 19:29:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Fri Mar 1 19:29:02 2002 Subject: Key version games (was Re: problem with exporting subkeys) In-Reply-To: <87k7swpnyl.fsf@alberti.gnupg.de> References: <3C7E0B5D.25D67550@saiknes.lv.NO.SPaM.NET> <20020228135159.GD678@akamai.com> <87k7swpnyl.fsf@alberti.gnupg.de> Message-ID: <20020301182701.GA680@akamai.com> On Fri, Mar 01, 2002 at 11:44:02AM +0100, Werner Koch wrote: > On Thu, 28 Feb 2002 08:51:59 -0500, David Shaw said: > > > Florian, this can give you the unchangeable expiration date that you > > wanted, if you're willing to accept the restrictions (RSA only, etc.) > > on v3 keys :) > > as well as easy to fake keyIDs. Yeah, and the MD5-only restriction if you use it for signing. :/ David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From ftobin@neverending.org Fri Mar 1 19:47:03 2002 From: ftobin@neverending.org (Frank Tobin) Date: Fri Mar 1 19:47:03 2002 Subject: [Announce] Ann.: keystory 0.1.0 (initial) release Message-ID: <20020228234703.T93061-100000@palanthas.neverending.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Announcing the 0.1.0 (initial) release of keystory: keystory, by analyzing email history, gathers data on the usage of OpenPGP signatures, and provides information to imperfectly, but practically complement the web of trust, answering questions such as "What keys has foo@bar.baz.com used, where and when?" The homepage for keystory is at: http://keystory.sourceforge.net/ tar.gz's and RPM's can be found at: http://sourceforge.net/project/showfiles.php?group_id=42442 I have put up a demo of keystory having a CGI interface at http://palanthas.neverending.org/keystory/ The demo site contains information gathered from the gnupg-users and gnupg-devel archives. keystory requires Python 2.2 or later, GnuPG, and other Python modules that are described in the README. >From the NEWS file: Noteworthy changes in 0.1.0 - ----------------------------------------------------------------- * Initial release of keystory. * Current issues are that there is no recognition of duplicately imported data and compile time is slow. - -- Frank Tobin http://www.neverending.org/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjx/E/gACgkQVv/RCiYMT6NwfQCgigfN1v7620XSGa+qoEfGZwMb jwkAniEOgAXGuOLO0aG+FO1CLqsmyRaX =fpYe -----END PGP SIGNATURE----- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From bwpearre@alumni.princeton.edu Fri Mar 1 23:48:01 2002 From: bwpearre@alumni.princeton.edu (Ben Pearre) Date: Fri Mar 1 23:48:01 2002 Subject: Anderson's attack? In-Reply-To: References: <20020206131032.D21208@diverge.seunglab.mit.edu> Message-ID: <20020301224617.GA22601@diverge.seunglab.mit.edu> --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 06, 2002 at 03:50:22PM -0800, Len Sassaman wrote: > This was addressed pretty thoroughly on the Cryptography list when Davis's > paper first came out. Basically, the "flaws" the paper is discussing are > social, not technical. The steps that can be taken on a technical level > to prevent this are few. (FWIW, OpenPGP's timestamping helps this a bit.) Ok, y'all have convinced me that this is a mailer problem, not an engine problem. But it's very widespread. Couldn't it at least be better documented? I couldn't find any info in the documentation as to whether it encrypt-signed or sign-encrypted, and what the implications were. Just make it clear that when something arrives encrypted, gpg doesn't know who encrypted it. This would probably want to go in the man page, where people who read about --encrypt and --sign will see it. Cheers, -Ben --=20 bwpearre@alumni.princeton.edu http://hebb.mit.edu/~ben --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8gAS5+CWfKs/abNoRAonAAKDRVWJtpcW0O3S0KCeP2Nthc/PHfwCg/qZc 8nT/PZ7Hh8gv9QyDIAq6tjE= =kgLm -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From rjhansen@inav.net Sat Mar 2 01:53:01 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Sat Mar 2 01:53:01 2002 Subject: GPGME and CVS Message-ID: <1015030337.2058.23.camel@numbers.robnet.net> Has anyone committed anything to CVS which would break GPGME? I just grabbed a cvs checkout and make has broken with an "undefined reference to `_gpgme_gpgsm_op_keylist_ext'". I would just grab an ftp of the latest alpha release, but ftp.gnupg.org doesn't seem to like me very much at the moment--can't get a thing out of it. From disastry@saiknes.lv.NO.SPaM.NET Sat Mar 2 10:49:01 2002 From: disastry@saiknes.lv.NO.SPaM.NET (disastry@saiknes.lv.NO.SPaM.NET) Date: Sat Mar 2 10:49:01 2002 Subject: Key version games (was Re: problem with exporting subkeys) Message-ID: <3C809F50.1DD54A65@saiknes.lv.NO.SPaM.NET> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 David Shaw dshaw@jabberwocky.com wrote: > > Florian, this can give you the unchangeable expiration date that you > > wanted, if you're willing to accept the restrictions (RSA only, etc.) > > on v3 keys :) > > as well as easy to fake keyIDs. Yeah, and the MD5-only restriction if you use it for signing. :/ David not true. there is no such restriction. you can use any hash and cipher. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPICCtDBaTVEuJQxkEQOqAwCgzhFlo/267VWdXbf0nsL6za5gqK4An1G2 356Readm6A51X5WKZZYyApWQ =9tU9 -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Sat Mar 2 15:20:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Sat Mar 2 15:20:02 2002 Subject: Key version games (was Re: problem with exporting subkeys) In-Reply-To: <3C809F50.1DD54A65@saiknes.lv.NO.SPaM.NET> References: <3C809F50.1DD54A65@saiknes.lv.NO.SPaM.NET> Message-ID: <20020302141749.GA9761@akamai.com> On Sat, Mar 02, 2002 at 11:45:52AM +0200, disastry@saiknes.lv.NO.SPaM.NET wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > David Shaw dshaw@jabberwocky.com wrote: > > > Florian, this can give you the unchangeable expiration date that you > > > wanted, if you're willing to accept the restrictions (RSA only, etc.) > > > on v3 keys :) > > > > as well as easy to fake keyIDs. > > Yeah, and the MD5-only restriction if you use it for signing. :/ > David > > not true. there is no such restriction. you can use any hash and cipher. Oops, you're right. I was thinking in terms of backwards compatibility to PGP2 (yes I know there are a whole handful of modified versions that allow other hashes, but vanilla MIT PGP 2 does not), but used as a subkey on a OpenPGP key any OpenPGP hash is fine. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From disastry@saiknes.lv.NO.SPaM.NET Sat Mar 2 16:18:01 2002 From: disastry@saiknes.lv.NO.SPaM.NET (disastry@saiknes.lv.NO.SPaM.NET) Date: Sat Mar 2 16:18:01 2002 Subject: Key version games (was Re: problem with exporting subkeys) Message-ID: <3C80ECB1.7EFEC980@saiknes.lv.NO.SPaM.NET> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 David Shaw dshaw@jabberwocky.com wrote: > > On Sat, Mar 02, 2002 at 11:45:52AM +0200, disastry@saiknes.lv.NO.SPaM.NET wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: RIPEMD160 > > > > David Shaw dshaw@jabberwocky.com wrote: > > > > Florian, this can give you the unchangeable expiration date that you > > > > wanted, if you're willing to accept the restrictions (RSA only, etc.) > > > > on v3 keys :) > > > > > > as well as easy to fake keyIDs. > > > > Yeah, and the MD5-only restriction if you use it for signing. :/ > > David > > > > not true. there is no such restriction. you can use any hash and cipher. > > Oops, you're right. I was thinking in terms of backwards > compatibility to PGP2 (yes I know there are a whole handful of > modified versions that allow other hashes, but vanilla MIT PGP 2 does > not), but used as a subkey on a OpenPGP key any OpenPGP hash is fine. > David :) btw, if we talk about subkeys, fake keyIDs is not a problem for subkeys at all, it's only problem for master keys. of course one can generate key with th same keyId as yours subkey, but it is unusable anyway :) __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPIDQRDBaTVEuJQxkEQOvDACgi8RjJxRB59amfeEoNbui0ReHeoIAnjoU 9o2wu7k8dBiiAZa0HiM9P1/4 =LJG5 -----END PGP SIGNATURE----- From Weimer@CERT.Uni-Stuttgart.DE Sat Mar 2 19:00:01 2002 From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer) Date: Sat Mar 2 19:00:01 2002 Subject: Key version games (was Re: problem with exporting subkeys) In-Reply-To: <20020228135159.GD678@akamai.com> (David Shaw's message of "Thu, 28 Feb 2002 08:51:59 -0500") References: <3C7E0B5D.25D67550@saiknes.lv.NO.SPaM.NET> <20020228135159.GD678@akamai.com> Message-ID: <87wuwudfk6.fsf@CERT.Uni-Stuttgart.DE> David Shaw writes: > Speaking of key versions - I spent some time looking at what versions > were permitted with what a while ago and one thing that does seem to > be explicitly permitted is v4 keys with v3 subkeys. I did test this > and PGP supports it (though this may be accidental support). GnuPG > 1.0.6 only partially supports it, but I fixed that in 1.0.7. > > Florian, this can give you the unchangeable expiration date that you > wanted, if you're willing to accept the restrictions (RSA only, etc.) > on v3 keys :) Interesting. But actually, I wanted to force this down the throat of all GnuPG users, that's why this feature is only of limited help. ;-) -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From rick@openfortress.nl Sun Mar 3 00:30:02 2002 From: rick@openfortress.nl (Rick van Rein) Date: Sun Mar 3 00:30:02 2002 Subject: timestamp (0x40) signatures? Message-ID: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> Hello, I just noticed that GnuPG is not willing to parse a timestamp signature that follows RFC 2440 properly. In the source I did not find it either, so that makes sense. Shall I make a patchit, or is there a reason not to? Groeten, Rick van Rein. -- >>> Oorlog betekent dat iemand met een te groot ego op een te hoge post zit <<< Universiteit Twente * INF-3027 * Postbus 217 * 7500 AE Enschede * 053-4894291 From wk@gnupg.org Sun Mar 3 13:48:02 2002 From: wk@gnupg.org (Werner Koch) Date: Sun Mar 3 13:48:02 2002 Subject: GPGME and CVS In-Reply-To: <1015030337.2058.23.camel@numbers.robnet.net> ("Robert J. Hansen"'s message of "01 Mar 2002 18:52:13 -0600") References: <1015030337.2058.23.camel@numbers.robnet.net> Message-ID: <87vgcdu8fw.fsf@alberti.gnupg.de> On 01 Mar 2002 18:52:13 -0600, Robert J Hansen said: > Has anyone committed anything to CVS which would break GPGME? I just > grabbed a cvs checkout and make has broken with an "undefined reference > to `_gpgme_gpgsm_op_keylist_ext'". Very likely. We even have to introduce an API change. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk@gnupg.org Sun Mar 3 13:50:02 2002 From: wk@gnupg.org (Werner Koch) Date: Sun Mar 3 13:50:02 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> (Rick van Rein's message of "Sun, 3 Mar 2002 00:28:11 +0100 (MET)") References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> Message-ID: <87r8n1u8c4.fsf@alberti.gnupg.de> On Sun, 3 Mar 2002 00:28:11 +0100 (MET), Rick van Rein said: > I just noticed that GnuPG is not willing to parse a timestamp signature > that follows RFC 2440 properly. In the source I did not find it either, > so that makes sense. Shall I make a patchit, or is there a reason not to? Please send me such a signature so that I can write a test case. For larger patches we need papers (> ~10 lines total), so it might be easier if we write it. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From Marcus.Brinkmann@ruhr-uni-bochum.de Sun Mar 3 16:18:01 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Mar 3 16:18:01 2002 Subject: GPGME and CVS In-Reply-To: <1015030337.2058.23.camel@numbers.robnet.net> References: <1015030337.2058.23.camel@numbers.robnet.net> Message-ID: <20020303144949.GD973@212.23.136.22> On Fri, Mar 01, 2002 at 06:52:13PM -0600, Robert J. Hansen wrote: > Has anyone committed anything to CVS which would break GPGME? I just > grabbed a cvs checkout and make has broken with an "undefined reference > to `_gpgme_gpgsm_op_keylist_ext'". Thanks for reporting it. Should be fixed now with this change: 2002-03-03 Marcus Brinkmann * engine-gpgsm.c (_gpgme_gpgsm_op_keylist_ext) [!ENABLE_GPGSM]: Add stub function. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de From Marcus.Brinkmann@ruhr-uni-bochum.de Sun Mar 3 17:58:02 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Mar 3 17:58:02 2002 Subject: GPGME and verification of normal signatures In-Reply-To: <200202161516.g1GFGOK32016@mail.space2u.com> <3C6D4E89.F4634650@free.fr> References: <200202161516.g1GFGOK32016@mail.space2u.com> <3C6D4E89.F4634650@free.fr> Message-ID: <20020303165607.GE973@212.23.136.22> On Fri, Feb 15, 2002 at 07:08:09PM +0100, Laurent CHEYLUS wrote: > I use GPGME library to develop GPG support in Balsa (MUA of Gnome) but I > have some problems to verify a "PGP Signed Message" with > "gpgme_op_verify" function :-( [...] > Must the text begin with "-----BEGIN PGP SIGNED MESSAGE-----" or this > header must be suppress ? Must the signature begin with "-----BEGIN PGP > SIGNATURE-----" and finsih with "-----END PGP SIGNATURE-----" ? Must > these lines finish with "\n" or another caracter ? On Sat, Feb 16, 2002 at 05:12:04PM +0100, Andreas Agorander wrote: > 1. Looking through the documentation it seems like only detached signatures > can be verified by GPGME, is there any possibility to verify a clearsigned > message directly, or do I have to "separate" the signature from the message? The gpgme_op_verify function in CVS now supports that the plaintext argument is an _uninitialized_ data object and will return the plaintext data for a normal or cleartext signature in that. Here is an example how this can be done (mmmh, such examples should be in the manual :) const char *signed_message = "-----BEGIN PGP SIGNED MESSAGE-----..."; GpgmeData sig, text; GpgmeSigStat sigstat; char *plaintext; int plaintext_len; gpgme_data_new (&text); gpgme_data_new_from_mem (&sig, signed_message, strlen (signed_message), 0); gpgme_op_verify (ctx, sig, text, &sigstat); plaintext = gpgme_data_release_and_get_mem (text, &plaintext_len); ... Please let me know if you experience any problems with it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de From j_anderson@uop.edu Mon Mar 4 02:35:02 2002 From: j_anderson@uop.edu (John Anderson) Date: Mon Mar 4 02:35:02 2002 Subject: GPGME GpgmeTrustItem -- What is this? Message-ID: <1015205552.2025.5.camel@ivory> Hi there, I'm working on doing a Java version of gpgme, to see whether I can, and because I need it for some other stuff I want to work on. I'm making the API very similar to gpgme's, but making it object oriented of course. I'm not using JNI or CNI like I saw a few other people using, so I don't know if I'm being redundant or not. Maybe one of you could tell me? My question is about the GpgmeTrustItem type in gpgme. What the heck is this? I understand contexts, data handles, keys, and all that, but I can't garner what these trust items are and what they would do. Is this to establish a web-of-trust data structure? What is it, and how is it used? Thanks in advance, John Anderson From disastry@saiknes.lv.NO.SPaM.NET Mon Mar 4 09:17:01 2002 From: disastry@saiknes.lv.NO.SPaM.NET (disastry@saiknes.lv.NO.SPaM.NET) Date: Mon Mar 4 09:17:01 2002 Subject: advantages/disadvantages of DSA/RSA keys (was: Re: implications of subkeys?) Message-ID: <3C832CFE.EB84F9D3@saiknes.lv.NO.SPaM.NET> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Ingo Klöcker ingo.kloecker@epost.de wrote: > On Saturday 02 March 2002 15:21, David Shaw wrote: > > On Sat, Mar 02, 2002 at 01:51:01PM +0100, Ingo Klöcker wrote: > > > On Friday 01 March 2002 20:39, David Shaw wrote: > > > > Yes. The algorithm is up to you and what you trust more. GnuPG > > > > 1.0.7 gives you the choice between DSA and RSA. They each have > > > > advantages and disadvantages. > > > > > > Is there somewhere a short but complete list of the advantages and > > > disadvantages? > > > > This is pretty good: > > http://www.samsimpson.com/pgpfaq.html > > Thanks. At least from section 8.1 it doesn't seem that RSA keys have any > advantages (except the backwards compatibility with plain PGP 2.x). > Ingo note that this FAQ was written when there was only v3 RSA keys. RSA keys have some advantages, at least two: they are not limited to 1024 bits like DSA they can use hash longer than 160 bits. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPIMQvDBaTVEuJQxkEQOrpwCgs0UDyUhjSsVolXG3YI63SfB3h/YAnj3J S33waNVWzt90tC/JZsrXIfVf =6dWO -----END PGP SIGNATURE----- From lists@lina.inka.de Mon Mar 4 11:37:02 2002 From: lists@lina.inka.de (Bernd Eckenfels) Date: Mon Mar 4 11:37:02 2002 Subject: advantages/disadvantages of DSA/RSA keys (was: Re: implications of subkeys?) In-Reply-To: <3C832CFE.EB84F9D3@saiknes.lv.NO.SPaM.NET> References: <3C832CFE.EB84F9D3@saiknes.lv.NO.SPaM.NET> Message-ID: <20020304103530.GA11946@lina.inka.de> On Mon, Mar 04, 2002 at 10:14:54AM +0200, disastry@saiknes.lv.NO.SPaM.NET wrote: > RSA keys have some advantages, at least two: > they are not limited to 1024 bits like DSA > they can use hash longer than 160 bits. And DSA Cecking is faster than signing, whereas DSA Checking is slower and the signing is fast. Greetings Bernd -- (OO) -- Bernd_Eckenfels@Wendelinusstrasse39.76646Bruchsal.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! From dshaw@jabberwocky.com Mon Mar 4 16:14:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Mar 4 16:14:01 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <87r8n1u8c4.fsf@alberti.gnupg.de> References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> <87r8n1u8c4.fsf@alberti.gnupg.de> Message-ID: <20020304151130.GA6935@akamai.com> On Sun, Mar 03, 2002 at 01:47:07PM +0100, Werner Koch wrote: > On Sun, 3 Mar 2002 00:28:11 +0100 (MET), Rick van Rein said: > > > I just noticed that GnuPG is not willing to parse a timestamp signature > > that follows RFC 2440 properly. In the source I did not find it either, > > so that makes sense. Shall I make a patchit, or is there a reason not to? > > Please send me such a signature so that I can write a test case. For > larger patches we need papers (> ~10 lines total), so it might be > easier if we write it. It's an interesting question as to just what an 0x40 signature is. RFC 2440 defines it as a "timestamp" signature, but does not really define what it is a signature on (if anything). RFC 1991 goes into more detail and defines it as a signature on a signature, which is more useful - this is the idea of a notary for PGP, which proves that a key owner saw a signature and gives this new signature as proof. Of course, 2440 replaces 1991, so who knows? If all that is wanted here is a straight standalone timestamp, then the 0x02 signature (standalone signature over an empty document) would be more appropriate. I actually have the code for this ready, but I wasn't planning on checking it in so as to help freeze this version. Werner, I can check it in if you want. :) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From william.newman@airmail.net Mon Mar 4 17:21:02 2002 From: william.newman@airmail.net (William Harold Newman) Date: Mon Mar 4 17:21:02 2002 Subject: buglet in --passphrase-fd option in 1.0.6 Message-ID: <20020304160352.GC11839@balefire.localdomain> I was playing around with the --passphrase-fd option under Emacs shell mode (with gpg-1.0.6, under OpenBSD 2.9), and noticed that the output looks like $ lightning:/tmp (emacs *shell*) $ echo ppp | gpg --symmetric --passphrase-fd 0 foo gpg: Warning: using insecure memory! Reading passphrase from file descriptor 0 ...^H^H^H where the extra ^H characters are ASCII BS='\010', not the '^' followed by 'H' that I've munged them into so that they'll be visible in everyone's mailer. Under an ordinary terminal, the ^H characters wouldn't be visible, and so they could've been overlooked so far, but in my Emacs window, they were visible. The extra ^H characters aren't a big deal, but they seem pointless and untidy, potentially either messing up someone's screen on a display which places special significance on ASCII BS characters, or even leaking a few bits of information about the passphrase (i.e. its length) under some even more obscure circumstance. -- William Harold Newman "Look on my works, ye Mighty, and despair!" -- Ozymandias, King of Kings PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C From wk@gnupg.org Mon Mar 4 17:24:01 2002 From: wk@gnupg.org (Werner Koch) Date: Mon Mar 4 17:24:01 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <20020304151130.GA6935@akamai.com> (David Shaw's message of "Mon, 4 Mar 2002 10:11:30 -0500") References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> <87r8n1u8c4.fsf@alberti.gnupg.de> <20020304151130.GA6935@akamai.com> Message-ID: <87k7sspamn.fsf@alberti.gnupg.de> On Mon, 4 Mar 2002 10:11:30 -0500, David Shaw said: > define what it is a signature on (if anything). RFC 1991 goes into > more detail and defines it as a signature on a signature, which is > more useful - this is the idea of a notary for PGP, which proves > that Indeed. A timestamping service makes more sense when it can be used to certify that a given signature was done at that time. Does PGP implemnt this, are there any notary services out providing such a service, should we clear this up in the next OpenPGP draft? > Werner, I can check it in if you want. :) I have not seen any requests for this, so better don't check it in. BTW, I have released 1.0.6d but not written an announcement yet. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk@gnupg.org Mon Mar 4 17:44:01 2002 From: wk@gnupg.org (Werner Koch) Date: Mon Mar 4 17:44:01 2002 Subject: buglet in --passphrase-fd option in 1.0.6 In-Reply-To: <20020304160352.GC11839@balefire.localdomain> (William Harold Newman's message of "Mon, 4 Mar 2002 10:03:52 -0600") References: <20020304160352.GC11839@balefire.localdomain> Message-ID: <87bse4p9oz.fsf@alberti.gnupg.de> On Mon, 4 Mar 2002 10:03:52 -0600, William Harold Newman said: > echo ppp | gpg --symmetric --passphrase-fd 0 foo > gpg: Warning: using insecure memory! > Reading passphrase from file descriptor 0 ...^H^H^H add --batch -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From dshaw@jabberwocky.com Mon Mar 4 18:19:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Mar 4 18:19:01 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <87k7sspamn.fsf@alberti.gnupg.de> References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> <87r8n1u8c4.fsf@alberti.gnupg.de> <20020304151130.GA6935@akamai.com> <87k7sspamn.fsf@alberti.gnupg.de> Message-ID: <20020304171724.GA1082@akamai.com> On Mon, Mar 04, 2002 at 05:21:04PM +0100, Werner Koch wrote: > On Mon, 4 Mar 2002 10:11:30 -0500, David Shaw said: > > > define what it is a signature on (if anything). RFC 1991 goes into > > more detail and defines it as a signature on a signature, which is > > more useful - this is the idea of a notary for PGP, which proves > > that > > Indeed. A timestamping service makes more sense when it can be used > to certify that a given signature was done at that time. > > Does PGP implemnt this, are there any notary services out providing > such a service, should we clear this up in the next OpenPGP draft? As far as I can tell, nobody implements this. I just tried feeding a 0x40 signature to PGP (6 and 7) and it just ignored it. PGP 2 doesn't like it either (no surprise). I think it would be very good to clear this up in the next OpenPGP draft though. A notary signature sounds very useful and if it was clear what it meant, then we could implement and use it :) > BTW, I have released 1.0.6d but not written an announcement yet. Cool! David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From disastry@saiknes.lv Mon Mar 4 19:32:02 2002 From: disastry@saiknes.lv (disastry@saiknes.lv) Date: Mon Mar 4 19:32:02 2002 Subject: 106d & Cygwin Message-ID: <3C83BCB6.490C3586@saiknes.lv> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message Werner Koch wk@gnupg.org wrote: > BTW, I have released 1.0.6d but not written an announcement yet. > Werner doesn't compile on Cygwin, here is the pacth: --- g10/tdbio.c.old Mon Mar 4 20:18:30 2002 +++ g10/tdbio.c Mon Mar 4 20:20:43 2002 @@ -39,7 +39,7 @@ #include "trustdb.h" #include "tdbio.h" -#ifdef HAVE_DOSISH_SYSTEM +#if defined(HAVE_DOSISH_SYSTEM) && !defined(__CYGWIN32__) #define ftruncate chsize #endif __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6d (Cygwin32) iD8DBQE8g7xGMFpNUS4lDGQRAqtcAJ9jhtKU4xOBT3LxVce8uqRCeVSN/gCgr2m4 vW20LWkuCzrACbBAh0D/w14= =EM/q -----END PGP SIGNATURE----- From disastry@saiknes.lv Mon Mar 4 20:35:01 2002 From: disastry@saiknes.lv (disastry@saiknes.lv) Date: Mon Mar 4 20:35:01 2002 Subject: 106d & Mingw32 Message-ID: <3C83CB62.D1282D29@saiknes.lv> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Werner Koch wk@gnupg.org wrote: > BTW, I have released 1.0.6d but not written an announcement yet. > Werner doesn't compile on Mingw32: /usr/local/lib/mingw32-cpd/i386--mingw32/bin/ld: cannot open -lws2_32: No such file or directory I have: ftp://ftp.gnupg.org/people/werner/cpd/mingw32-cpd-0.3.0.tar.gz ftp://ftp.gnupg.org/people/werner/cpd/gcc-core-2.95.2.tar.gz ftp://ftp.gnupg.org/people/werner/cpd/binutils-2.9.1.tar.gz ftp://ftp.gnupg.org/people/werner/cpd/windows32api-0.1.2.tar.gz probably I need some newer version of windows32api :-/ __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPIOvJDBaTVEuJQxkEQNwIACfY54sVltvyQrgYbvBHHoEajxjYvIAniXY 3WSHKrb1e/kAdndLRGt5ld5C =Tt/d -----END PGP SIGNATURE----- From lists@lina.inka.de Mon Mar 4 22:31:02 2002 From: lists@lina.inka.de (Bernd Eckenfels) Date: Mon Mar 4 22:31:02 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <20020304171724.GA1082@akamai.com> References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> <87r8n1u8c4.fsf@alberti.gnupg.de> <20020304151130.GA6935@akamai.com> <87k7sspamn.fsf@alberti.gnupg.de> <20020304171724.GA1082@akamai.com> Message-ID: <20020304212841.GA24547@lina.inka.de> On Mon, Mar 04, 2002 at 12:17:24PM -0500, David Shaw wrote: > I think it would be very good to clear this up in the next OpenPGP > draft though. A notary signature sounds very useful and if it was > clear what it meant, then we could implement and use it :) The question is, if a special signature packet type is needed, anyway. The notar can simply envelop the detached signature and a time-stamp-packet with a normal PGP signature? BTW: for X.509/SigG Applications something similiar is a requirement: one checks the signature of a received document and asks the CA if the certificate is still valid (OSPC). The received statement that for a given time/query the certificate was not revoked should be archived by the original receiver, to proof that the signature was not revoked (this is, to avoid re-dating of signatures, which do not eed to carry a official timestamp according to law, yet). I guess something similiar can be added to the OpenPGP draft as the usual application for Timestamp signatures. Greetings Bernd -- (OO) -- Bernd_Eckenfels@Wendelinusstrasse39.76646Bruchsal.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! From dshaw@jabberwocky.com Mon Mar 4 23:55:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Mar 4 23:55:01 2002 Subject: Comments on 1.0.6d Message-ID: <20020304225310.GB31127@akamai.com> Hi, As promised, here's are some comments about the latest snapshot. These are the "doesn't work right" comments. I'll do the "would be nice" list later :) I've started on fixes for #5, #8, #10, #13, and #15. 1) --edit a public key you have the secret key for, and use "adduid". Make up any user ID you like, but when prompted for a passphrase, just hit enter a few times. This causes an assertion failure: "free-packet.c:287: free_user_id: Assertion `uid->ref > 0' failed." 2) The RPM spec file in scripts/gnupg.spec(.in) needs updating for the keyserver helpers (gpgkeys_ldap, gpgkeys_mailto). 3) If a key is revoked, it is not shown as revoked in the --edit menu until ownertrust is set for that key. This happens with expired keys as well. 4) The 'keyid!' (with exclamation point) syntax works with public (i.e. for encryption), but does not work with private (for signing) keys. This seems to be because lookup() in getkey.c calls itself and the flags are wiped. 5) When revoking a local key signature (i.e. from 'lsign'), the revocation should be local as well to prevent possibly leaking information about the local signature. 6) --list-packets shows an awful lot more than it used to in 1.0.6. For example, when decrypting a message it shows the packets in the keyring as they are read to find the key to decrypt with. This makes it a lot less useful than it used to be. 1.0.6 used to only show the immediate object being worked with - when decrypting for example, it showed only the packets in the encrypted message. 7) When you delete a key with ownertrust set it does not disappear from the trustdb. I mentioned this one a few months ago and I think it was concluded to be a feature and not a bug, though I still think that if I delete a key there should be no remnants of that key left behind. The more significant problem is if there is an ultimately trusted key that gets deleted, then gpg will complain constantly: gpg: Oops: keyid_from_fingerprint: no pubkey and whenever --update-trustdb or --check-trustdb is run: gpg: public key of ultimately trusted key 00000000 not found 8) V3 key revocations should not prompt for a revocation reason since V3 revocations do not use it anyway. 9) For some reason --with-colons no longer shows anything in the ownertrust field. 10) The keyserver stuff needs an "exec-path" or similar, as the user's path may be untrustworthy, and it is also difficult to use the keyserver stuff via cron or other non-login methods without it. 11) --list-packets does not work with partial body lengths 12) Should "RIJNDAEL" be called "AES" now that the standard (at least the US standard) went through? PGP calls it "AES", so there may be confusion there. Perhaps GnuPG should accept both names? 13) The command "gpg --export 0xz blah" causes BUG() to be called. 14) Sign a key so that it's trust goes to "full". Now, delete or revoke the signature. The trust level stays at "full" until you export, delete, and then re-import the trustdb. 15) Compiler warning in util/: iobuf.c:1891: warning: static declaration for `fseeko' follows non-static (I'm not mentioning the compiler warnings in g10/keyedit.c as that is the fault of the compiler and not the code.) 16) Assembler warning in mpi/: _mpih-rshift.s:129: Warning: using `%dl' instead of `%edx' due to `b' suffix 17) Something seems to be not correct with MDC packets. Encrypt a message so that MDC packets are included, and then run gpg on the message. Do not enter a passphrase, but just hit enter a few times. You get errors that seem to imply the message goes on longer than gpg expects it to. This is visible with --list-packets as well. 18) Using several config options like "default-recipient" or "secret-keyring" in a config file with no argument causes a segfault. 19) If the user makes a key ultimately trusted, there is no way to later make it not ultimately trusted without deleting the trustdb or exporting the trustdb, editing it manually and re-importing it. 20) This isn't a problem, but I just wanted to comment on it in case someone disagrees. In the way I wrote the signature expiration and non-revocability code, expiration subpackets are marked critical, and non-revocable subpackets are not. The rationale for the non-revocable subpacket being not critical is that the worst thing that could happen with such a signature is that it ended up on an implementation that treated it as revocable. Since the user is the only person who could issue the revocation anyway, there is no problem here. The expiration subpacket on the other hand, *is* marked as critical, as if it was used on an implementation that did not understand expiring signatures the signature could live longer then the signer intended, which is clearly wrong. Better in that case to have no signature rather than a signature that persisted beyond when the user intended. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From Marcus.Brinkmann@ruhr-uni-bochum.de Tue Mar 5 00:09:02 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Mar 5 00:09:02 2002 Subject: GPGME GpgmeTrustItem -- What is this? In-Reply-To: <1015205552.2025.5.camel@ivory> References: <1015205552.2025.5.camel@ivory> Message-ID: <20020304230712.GG742@212.23.136.22> On Sun, Mar 03, 2002 at 05:32:32PM -0800, John Anderson wrote: > My question is about the GpgmeTrustItem type in gpgme. What the heck is > this? I understand contexts, data handles, keys, and all that, but I > can't garner what these trust items are and what they would do. Is this > to establish a web-of-trust data structure? What is it, and how is it > used? Yes, it is supposed to provide information about the validity of a key, or the amount of trust the user has assigned to it. Feel free to leave this interface out for now (or do it when everything else is done): It is experimental (as documented in the manual, which you have certainly read :), and probably subject to change. The whole key management interface in gpgme still needs to evolve a bit more... Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de From dshaw@jabberwocky.com Tue Mar 5 06:51:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Mar 5 06:51:01 2002 Subject: Comments on 1.0.6d In-Reply-To: <20020304225310.GB31127@akamai.com> References: <20020304225310.GB31127@akamai.com> Message-ID: <20020305054827.GC678@akamai.com> On Mon, Mar 04, 2002 at 05:53:10PM -0500, David Shaw wrote: > As promised, here's are some comments about the latest snapshot. > These are the "doesn't work right" comments. I'll do the "would be > nice" list later :) > > I've started on fixes for #5, #8, #10, #13, and #15. > 5) When revoking a local key signature (i.e. from 'lsign'), the > revocation should be local as well to prevent possibly leaking > information about the local signature. > 8) V3 key revocations should not prompt for a revocation reason since > V3 revocations do not use it anyway. > 10) The keyserver stuff needs an "exec-path" or similar, as the user's > path may be untrustworthy, and it is also difficult to use the > keyserver stuff via cron or other non-login methods without it. > 13) The command "gpg --export 0xz blah" causes BUG() to be called. > 15) Compiler warning in util/: > iobuf.c:1891: warning: static declaration for `fseeko' follows non-static Ok, all these are fixed. #15 was particularly interesting - it turned out to be an odd interaction between my libc headers and autoconf. It wasn't the code at all. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From foxy@free.fr Tue Mar 5 16:02:01 2002 From: foxy@free.fr (Laurent Cheylus) Date: Tue Mar 5 16:02:01 2002 Subject: Example for GPGME function "gpgme_set_passphrase_cb" ? Message-ID: <3C84DD88.A72329F3@free.fr> Hi, in GPGME library, the function "gpgme_set_passphrase_cb" has prototype : void gpgme_set_passphrase_cb (GpgmeCtx ctx , GpgmePassphraseCb cb , void * cb_value ) with : typedef const char *(*GpgmePassphraseCb)(void*cb_value, const char *desc, void **r_hd) for the callback "cb". But I don't understand how to get the status of the passphrase entry. I have some code who works well when the passphrase is good but how get the status, if the passphrase is bad or missing ?? Has anybody some example of code to help me with this function ? Thanks, Foxy. -- Laurent Cheylus OpenPGP ID 0x5B766EC2 From wk@gnupg.org Tue Mar 5 16:36:01 2002 From: wk@gnupg.org (Werner Koch) Date: Tue Mar 5 16:36:01 2002 Subject: Example for GPGME function "gpgme_set_passphrase_cb" ? In-Reply-To: <3C84DD88.A72329F3@free.fr> (Laurent Cheylus's message of "Tue, 05 Mar 2002 16:00:24 +0100") References: <3C84DD88.A72329F3@free.fr> Message-ID: <87henvuiz6.fsf@alberti.gnupg.de> On Tue, 05 Mar 2002 16:00:24 +0100, Laurent Cheylus said: > But I don't understand how to get the status of the passphrase entry. I > have some code who works well when the passphrase is good but how get > the status, if the passphrase is bad or missing ?? >From Sylpheed: static const char * passphrase_cb (void *opaque, const char *desc, void *r_hd) { struct passphrase_cb_info_s *info = opaque; GpgmeCtx ctx = info ? info->c : NULL; const char *pass; if (!desc) { /* FIXME: cleanup by looking at *r_hd */ return NULL; } g_message ("%% requesting passphrase for `%s': ", desc ); pass = gpgmegtk_passphrase_mbox (desc); if (!pass) { g_message ("%% cancel passphrase entry"); gpgme_cancel (ctx); } else g_message ("%% sending passphrase"); return pass; } Somewhere in gpgmegtk_passphrase_mbox the window is created and the displayed prompt varied by looking at the first line of the description (TRY_AGAIN) static GtkWidget * create_description (const gchar *desc) { const gchar *cmd=NULL, *uid=NULL, *info=NULL; gchar *buf; GtkWidget *label; cmd = desc; uid = strchr (cmd, '\n'); if (uid) { info = strchr (++uid, '\n'); if (info ) info++; } if (!uid) uid = _("[no user id]"); if (!info) info = ""; buf = g_strdup_printf (_("%sPlease enter the passphrase for:\n\n" " %.*s \n" "(%.*s)\n"), !strncmp (cmd, "TRY_AGAIN", 9 ) ? _("Bad passphrase! Try again...\n\n") : "", linelen (uid), uid, linelen (info), info); label = gtk_label_new (buf); g_free (buf); return label; } -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From rabbi@quickie.net Tue Mar 5 23:57:02 2002 From: rabbi@quickie.net (Len Sassaman) Date: Tue Mar 5 23:57:02 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <87k7sspamn.fsf@alberti.gnupg.de> Message-ID: On Mon, 4 Mar 2002, Werner Koch wrote: > On Mon, 4 Mar 2002 10:11:30 -0500, David Shaw said: > > > define what it is a signature on (if anything). RFC 1991 goes into > > more detail and defines it as a signature on a signature, which is > > more useful - this is the idea of a notary for PGP, which proves > > that > > Indeed. A timestamping service makes more sense when it can be used > to certify that a given signature was done at that time. Exactly. > Does PGP implemnt this, are there any notary services out providing > such a service, should we clear this up in the next OpenPGP draft? I don't think PGP implements this, though this came directly from an idea Phil and Hal had, I believe. I had been working on a notary service that would use this (among other things), though that project has been put on the back burner recently. It would be useful if GnuPG knew what it was, however. --Len. From legoxx@yahoo.com Thu Mar 7 11:48:01 2002 From: legoxx@yahoo.com (lego lego) Date: Thu Mar 7 11:48:01 2002 Subject: problem with using files as a keyring Message-ID: <20020307104555.23129.qmail@web14510.mail.yahoo.com> hello i'm trying this from the doc/DETAILS $ cat >foo < ssb 1024g/8F70E2C0 2000-03-09 i just got this: gpg: Warning: using insecure memory! gpg: /home/peter/.gnupg/foo.sec: keyring created gpg: /home/peter/.gnupg/foo.pub: keyring created i tried to sign files using foo.sec but it won't work it seems that the keyrings are not even open... well when i run gpg --no-default-keyring --secret-keyring foo.sec --keyring foo.pub --list-secret-keys for second time i got not output at all just gpg: Warning: using insecure memory! [peter@love1 foo]$ i want to sign a file without importing key to my keyring, and i need my customer to verify signature without installing public key to his keyring. Just simple command line interface. Ideally in batch file i want to use foo.pub and foo.sec in the current direcotory not /home/user/.gnupg so i modified my script:gpg --no-default-keyring --secret-keyring ./foo.sec --keyring ./foo.pub --list-secret-keys but i got this... gpg: Warning: using insecure memory! gpg: [don't know]: invalid packet (ctb=2d) gpg: read_keyblock: read error: invalid packet gpg: enum_keyblocks(read) failed: invalid keyring can anyone help me please? __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From Enzo Michelangeli" RFC2440 says that the correctness of a passphrase can be checked just verifying a checksum in the Secret Key Packets: 5.5.3. Secret Key Packet Formats [...] The 16-bit checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm- specific octets (including MPI prefix and data). With V3 keys, the checksum is stored in the clear. With V4 keys, the checksum is encrypted like the algorithm-specific data. This value is used to check that the passphrase was correct. Is this true also inside the gpg keyring files, or just in the exported keys? And in any case, wouldn't it be more prudent to obsolete that checksum requirement and/or deliberately ignore it in the keyring implementations, in order to slow down dictionary attacks? The correctness of the passphrase could always be checked, fast enough if done once for legitimate purposes, against the corresponding public key. Enzo From wk@gnupg.org Fri Mar 8 17:00:02 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 8 17:00:02 2002 Subject: Passphrase protection of secret keys In-Reply-To: <011301c1c6a1$492e7420$0200000a@noip.com> ("Enzo Michelangeli"'s message of "Fri, 8 Mar 2002 21:00:05 +0800") References: <011301c1c6a1$492e7420$0200000a@noip.com> Message-ID: <87n0xjf3xb.fsf@alberti.gnupg.de> On Fri, 8 Mar 2002 21:00:05 +0800, Enzo Michelangeli said: > Is this true also inside the gpg keyring files, or just in the exported > keys? And in any case, wouldn't it be more prudent to obsolete that checksum Yes it is still true. However GnuPG checks a signature right after creation, so the Klima/Rosa attack won't work. > requirement and/or deliberately ignore it in the keyring implementations, in > order to slow down dictionary attacks? The correctness of the passphrase Plaintext (i.e. the unprotected secret key) detection can be done w/o calculating the checksum and thus faster, so it won't help. Forthcoming GnuPG versions are going to use there own format to protect secret keys. See: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/newpg/agent/keyformat.txt?rev=1.4&content-type=text/vnd.viewcvs-markup&cvsroot=Project+Aegypten Ciao, Werner From rjhansen@inav.net Fri Mar 8 23:53:01 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Fri Mar 8 23:53:01 2002 Subject: GPGME, C++ wrappers and Stupid Questions. Message-ID: <1015627911.8896.62.camel@numbers.robnet.net> Is there any project underway to wrap GPGME in C++? (I know that a lot of people on the list have no fondness for C++, but hey, I like the language.) If not, I've got the beginnings of a wrapper going--right now it's only adequate for querying the keyring, but it shouldn't be too terribly hard to extend it to support the full range of GPGME operations. Before I do any more work on it, though, I'd like to make sure I'm not reinventing the wheel. And on a related note, I'm having some real troubles deleting keys from a keyring. The following is a snippet of code that shows the bug: void Key::deleteKey(bool deleteSecret = false) { GpgmeError err = GPGME_No_Error; switch (deleteSecret) { case false: err = gpgme_op_delete_start(ctx, key, 0); ctx = gpgme_wait(ctx, &err, 1); break; case true: err = gpgme_op_delete_start(ctx, key, 1); ctx = gpgme_wait(ctx, &err, 1); break; }; errswitch(err); } ... Whenever I call Key::deleteKey, err is GPGME_No_Error by the time the error-switcher is reached. However, the key remains on my GPG keyring even after the function ends. Am I misusing the API, or is there some subtle error elsewhere in my code that's causing this to fail? From ben.bucksch.news@beonex.com Sat Mar 9 16:02:01 2002 From: ben.bucksch.news@beonex.com (Ben Bucksch) Date: Sat Mar 9 16:02:01 2002 Subject: Mozilla, License (again), PPG, GPGME Message-ID: <3C8A2228.4020408@beonex.com> Hi, sorry for reopening the old, annoying question [1], but... Mozilla is MPL, GnuPG is GPL, MPL and GPL are not compatible. Mozilla wants PGP, GnuPG wants to have an interface in Mozilla (at least Werner and the German gov't says so). The Mozilla relicensing is not necessarily of much help, because a GPL lib would force all of Mozilla under the GPL, which would make other inclusions impossible (e.g. Macromedia Flash). GnuPG is a separate executable, so there doesn't have to be a problem, if Mozilla communicates with GnuPG via pipes. Enigmail does this, for example. The most sane method is to have a standard library, which can be linked from other apps (like MUAs) and which wraps the communication with GnuPG into a nice API. That's what GPGME [5] and PPG [4] try to achieve. However, because that lib is then linked directly with the using program (e.g. Mozilla), the lib license must be compatible with the license of the using program. I.e. the lib cannot be GPL, if it wants to be used by Mozilla and other programs. "Other programs" might include Microsoft Outlook [Express], now that the future of the commercial PGP is unclear. (Outlook has such a large market share that OpenPGP needs to have a nice UI for it, if it ever wants to be a widely used standard. I know the security concerns, but I think they are not really relevant.) The author expressed intend to open the PPG license specifically so that Mozilla could use it. (Thanks!) [2] GPGME, however, is GPL. PPG, however, seems to be dormant (last release 2 years ago), and GPGME is actively developed (last checkin 2 days ago). I found a diary entry [3] of Werner Koch, reading: > /Monday, October 30 / > > Worked on *GPGME*, which may translate to GPG Made Easy. This the 3rd > attempt to write a usable wrapper libary around GPG. Why? While > playing with Evolution and Mozilla, I figured out that we should not > duplicate gpg access code (which is pretty obvious) but have a good > library to do that once and bulletproof. > > I looked at GPAPA but it actually is too strong bound to GPA and the > design is not very flexibel. Looked again at *PGG* but this thing is > too complicated and too much OOed. So, what to do? I stared out of the > window for a long time before I decided that this 3rd attempt is worth > a try. The goals of *gpgme* are: Should be able to run asyncronously, > take filenames or memory areas, design must allow a better integration > with OO systems, easy to read (at least for me), easy to build, limit > use of resources. > So far for the facts, as I understood them. My questions: * What's the state of PGG? I guess it's unusable by now? * (What's wrong with OO? - no answer required :). ) * Why GPL for GPGME? Werner, you say you want to use the lib for Mozilla, but you are surely aware of the license problems. What was your plan, or did you just "default" to GPL :), planning to think about the problem later? Ben Bucksch P.S. In case you didn't hear of: * Mozilla has now partial S/MIME support, and Netscape claims that the underlying stuff is general enough for OpenPGP. As usual, they have no docs whatsoover. I haven't looked at it myself. * NAI worked on a Mozilla plugin last year, but the code was rejected. IMHO, it looked better than the Netscape S/MIME stuff. [1] [2] [3] [4] [5] From wk@gnupg.org Sat Mar 9 16:52:01 2002 From: wk@gnupg.org (Werner Koch) Date: Sat Mar 9 16:52:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <3C8A2228.4020408@beonex.com> (Ben Bucksch's message of "Sat, 09 Mar 2002 15:54:32 +0100") References: <3C8A2228.4020408@beonex.com> Message-ID: <877kold9mq.fsf@alberti.gnupg.de> On Sat, 09 Mar 2002 15:54:32 +0100, Ben Bucksch said: > include Microsoft Outlook [Express], now that the future of the > commercial PGP is unclear. (Outlook has such a large market share that You mean the proprietary PGP. Wether a software is commcercial or not has nothing to do with Free Software versus proprietary software. The furture of PGP is not that unlcear: There is and will be no more development for it. They have laid off all engineers working on PGP. > OpenPGP needs to have a nice UI for it, if it ever wants to be a > widely used standard. I know the security concerns, but I think they Yes, definitely. Noone as volunteered to make GPA or any of the other frontends a workable solution, so I fear that without a proper funding there will be no good GUI in the near future. I know that this is very important. I have a list of things in mind which should be undertaken by further GPA (or whatever) development. > My questions: > * What's the state of PGG? I guess it's unusable by now? Right. > * (What's wrong with OO? - no answer required :). ) It needs to be done right and frankly OO is far older than what Brooch claims to have invented. The IEEE Software had a good article on the disadvantage of several OO approaches (look for something like "Why OO does not sync with our thinking" about 2 years old) > * Why GPL for GPGME? Werner, you say you want to use the lib for > Mozilla, but you are surely aware of the license problems. What > was your plan, or did you just "default" to GPL :), planning to > think about the problem later? Now that Mozilla is dual licensed there is no more problem to use it. If you want to use in addtion a proprietary plugin, you may not be able to do so. In theory I can still change the GPGME license but I don't see a reason to endorse the use of proprietary software by doing that. Mozilla is free and if someone wants a Flash plugin, he should write a compatible plugin or even better use a standard vector format. > * Mozilla has now partial S/MIME support, and Netscape claims that > the underlying stuff is general enough for OpenPGP. As usual, they > have no docs whatsoover. I haven't looked at it myself. What's wrong with enigmail? If you worry about performance problems due to the fork/exec approach, this will be solved soon by a gpg server mode. > * NAI worked on a Mozilla plugin last year, but the code was > rejected. IMHO, it looked better than the Netscape S/MIME stuff. Although I am much in favor of OpenPGP, I can tell you that GPGME does support S/MIME (well, the CMS part). Werner From ben.bucksch.news@beonex.com Sat Mar 9 18:46:01 2002 From: ben.bucksch.news@beonex.com (Ben Bucksch) Date: Sat Mar 9 18:46:01 2002 Subject: Mozilla, License (again), PPG, GPGME References: <3C8A2228.4020408@beonex.com> <877kold9mq.fsf@alberti.gnupg.de> Message-ID: <3C8A4887.60004@beonex.com> Werner Koch wrote: >Now that Mozilla is dual licensed there is no more problem to use it. > That Mozilla relicensing was intended for Mozilla being *used* in GPL apps like Galeon or Evolution, not for having GPL code included in Mozilla. >If you want to use in addtion a proprietary plugin, you may not be >able to do so. In theory I can still change the GPGME license but I >don't see a reason to endorse the use of proprietary software by doing >that. Mozilla is free and if someone wants a Flash plugin, he should >write a compatible plugin or even better use a standard vector format. > I don't want to offend you, but you are free to write a Flash plugin that works with Mozilla. And a RealPlayer plugin, and a Quicktime one, and a Java engine with decent Swing support, and what-have-you. Never mind that you are probably not even allowed to, due to patents (arg!). Believe me, I created Beonex Communicator, and I really try to keep everything completely Open-Source. But users want a browser that works, with Flash and all the other goodies, *now*. They don't want to be locked out of (stupid) sites like . While I much dislike having proprietary bits in a version of Beonex Communicator (there will always be a Open-Source-only version), I prefer that over people using MSIE6 on Windows XP or Netscape 6. I also care about security, that's why PGP is important to Beonex. Please don't make these goals incompatible. As I said, I choose a slightly less compatible Open-Source implementation over the "original" proprietary one, but what do I do until the latter exists? I can't write all of that myself. To take a concrete example: A browser for the Bundestag. What, do you think, would be the options? If you were to offer one, what would you include in the browser? Surely, PGP would be desireable. Do you think that the Abgeordneten would accept not to be able to see Flash content? Also, I don't think you "endorse" anything. You just *refrain* from *forcing* other people (like me) to do or not to do something (which would be a major problem). And last but not least, your lib probably has 0 chance to be part of the base Mozilla, if it is not MPL/GPL/LGPL tripple-licensed. Any such plugin would surely live a third-party life, left bitrotting after a few months of frequent Mozilla changes. > or even better use a standard vector format. > As much as I'd like to, I cannot change the content that is out there on the web. Being locked out of a few major sites makes users already consider to switch the browser. You guess which one that is. >What's wrong with enigmail? > I haven't looked at all at it, because its author basically says that it's just a little toy that he dumped on an ftp server, not really ready for use. Have you audited it security-wise? I don't know enough about the problems there (exec() etc.) to do that. >If you worry about performance problems > Not at all. From agent@ibcine.tv Sun Mar 10 01:00:02 2002 From: agent@ibcine.tv (agent) Date: Sun Mar 10 01:00:02 2002 Subject: [±¤°í]¿µÈ­°üÀ» ÀÌ °¡°Ý¿¡ °¡Áú¼ö ÀÖ´Ù¸é ¹ÏÀ¸½Ã°Ú½À´Ï±î? Message-ID: <200203092357.g29NvWor022293@mail.openit.de> =BC=BC=BB=F3=BF=A1=BC=AD =B0=A1=C0=E5 =B4=DE=C4=DE=C7=D1 =BF=B5=C8= =AD=B0=FC


=
=B9=F6=C6=B0=C0=BB =C5=AC=B8=AF=C7=CF=BD=C3=B8=E9= =BC=F6=BD=C5=B0=C5=BA=CE=C3=B3=B8=AE=B0=A1 =C0=CC=B7=E7=BE=EE =C1=FD=B4=CF= =B4=D9.



3D= 3D"=BB=F3=B4=E3=B8=DE=C0=CF" 3D"=BE=C6=C0=CC=BA=F1=C5=AC=B7=B4" From wagner@tik.ee.ethz.ch Mon Mar 11 13:42:01 2002 From: wagner@tik.ee.ethz.ch (Arno Wagner) Date: Mon Mar 11 13:42:01 2002 Subject: Mozilla, License (again), PPG, GPGME Message-ID: <20020311133946.A28603@tik.ee.ethz.ch> > > * (What's wrong with OO? - no answer required :). ) > > It needs to be done right and frankly OO is far older than what Brooch > claims to have invented. The IEEE Software had a good article on the > disadvantage of several OO approaches (look for something like "Why OO > does not sync with our thinking" about 2 years old) Just for the record that is  Does OO sync with how we think? Hatton, L. IEEE Software , Volume: 15 Issue: 3 , May-June 1998 Page(s): 46 -54 Can be downloaded from http://ieeexplore.ieee.org/lpdocs/epic03/EarlierIssue.HTM?punumber=52&isyr=1998 You might have to be an IEEE member to do so. Personally I don't agree with the conclusions. The Article is mainly based on C++. There are far better OO languages, e.g. Eiffel, that may change the situation drastically. Personally I kept running into limitations, non-orthogonalities and plain stupid implementation of OO features when dealing with C++. Some things, like the protection model, are also far too complicated. Multiple inheritance with its property that the first implementation encounterd in compiling makes it into the final functionality is just wrong, silly and dangerous. And there ist the problem that it is very easy to mix OO and non-OO styles and end up with a completely unusable pice of code... Numerous other problems make C++ an bad candidate to judge the merits of OO languages on it. Regards, Arno -- Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@tik.ee.ethz.ch GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F A modern US Navy cruiser now requires 26 tons of manuals. This is enough to affect the vessel's performance. -- New Scientist on the paperless office From 31016789@atphone.com Mon Mar 11 21:07:02 2002 From: 31016789@atphone.com (¾ÜÆù) Date: Mon Mar 11 21:07:02 2002 Subject: ÇÚµåÆù±îÁö ¸¶À½´ë·Î »ç¿ëÇϼ¼¿ä Message-ID: <200203112005.g2BK5K8b025846@mail.openit.de>

=BE=DC=C6=F9=BF=A1=BC=AD= =20 =C8=B9=B1=E2=C0=FB=C0=CE =C1=A6=C7=B0=C0=BB =BC=D2=B0=B3=C7=D5=B4=CF=B4=D9= .

 

 

=C1=D9=C0=CC=B0=ED =C1=D9=BF=A9=B5=B5 =C0=FC=C8=AD=C5=EB=BD=C5 =BF= =E4=B1=DD=C0=CC 2=B8=B8=BF=F8=C0=CC =B3=D1=B4=C2=B4=D9= =B8=E9=20

 =C1=F6=B1=DD =BE=DC= =C6=F9=C0=B8=B7=CE=20 =B9=D9=B2=D9=BD=CA=BD=C3=BF=E4.

=BF=F9 19,800=BF=F8 =C1=A4=BE=D7=C1=A6=B7=CE =BD=C3=B3=BB=BD=C3=BF=DC=B4=C2=20 =B9=B0=B7=D0=20 =C7=DA=B5=E5=C6=F9=B1=EE=C1=F6 =

=C6=F2=BB=FD =B0=F8=C2=A5=B0=B0=C0=BA =C5=EB=BD=C5=C0=FC=C8=AD=B8= =A6 =B9=AB=C1=A6=C7=D1 =C0=CC=BF=EB =C7=CF=BD=C7=BC=F6 =C0=D6=BD=C0=B4=CF= =B4=D9.

 

=C0=E5=C1=A1

1.=C7=D1=B1=B9=C5=EB=BD=C5=BF=E4=B1=DD =BF=F9 20=B8=B8=BF=F8=C0=CC=BB=F3=C0=CF=B0=E6=BF=EC=B5=B5

=3D=3D=3D> =BE=DC=C6=F9 19800=BF=F8 + =B1=E2=BA=BB=BF=E4=B1=DD 3000=BF=F8=C0=CC=B8=E9 =C7=D8=B0=E1

   ##=B1=B9=C1= =A6=C0=FC=C8=AD 80~90% =BA=F1=BF=EB=C0=FD=B0=A8=20

(=BF=B9) =B9=CC=B1=B9 3=BA=D0=C5=EB=C8=AD=C0=CF=B0=E6=BF=EC

-a=20 =C7=D1=B1=B9=C5=EB=BD=C5 --2300=BF=F8&n= bsp; / =B9=DD=B8=E9 =BE=DC=C6=F9=C0=BA=20 270=BF=F8=C0=CC=B8=E9=B5=CB=B4=CF=B4=D9.

 

2.=BB=E7=BF=EB=C0=CC =C6=ED=B8=AE =3D=3D=3D=3D> =C3=CA=B0=ED=BC= =D3=C5=EB=BD=C5=C8=AF=B0=E6(ADSL, cable=B8=F0=B5=A9, =C0=FC=BF=EB=BC=B1)=C0= =CC =B1=F2=B7=C1=C0=D6=B4=C2=20 =B0=F7=BF=A1=BC=AD

 =C4=C4=C7=BB=C5=CD= =B8=A6 =C4=D3 =C7=CA=BF=E4=BE=F8=C0=CC=20 =BB=E7=BF=EB=B0=A1=B4=C9.

 

3.=B6=D9=BE=EE=B3=AD =C5=EB=C8=AD=C0=BD=C1=FA =3D=3D=3D=3D=3D>= ; =C3=CA=B0=ED=BC=D3=C5=EB=BD=C5=C8=AF=B0=E6=C0=CC=B9=C7=B7=CE =C0=FC=C7=F4= =B2=F7=B1=E8=BE=F8=C0=CC

=B1=FA=B2=FD=C7=D1=20 =C0=BD=C1=FA=C0=BB=20 =B0=E6=C7=E8=C7=D2=BC=F6 =C0=D6=BD=C0=B4=CF=B4=D9.

 

4.=B2=C0 =C7=CA=BF=E4=C7=D1 =BA=D0=B5=E9  

< =B0=A1 =C1=A4 >

1.=C7=D8=BF=DC =B6=C7=B4=C2 =C1=F6=B9=E6=BF=A1 =C4=A3=C1=F6=B3=AA= =BF=AC=C0=CE=C0=CC =C0=D6=B4=C2 =BA=D0

2.=C0=AF=C7=D0=BB=FD=C0=CC =C0=D6=B4=C2 =B0=A1=C1=A4 =

3.=BD=C3=B3=BB, =BD=C3=BF=DC, =C7=DA=B5=E5=C6=F9=C0=BB =B8=B9=C0= =CC =BE=B2=B4=C2 =B0=A1=C1=A4

< =C8=B8 =BB=E7 >

1.=B1=B9=C1=A6=C0=FC=C8=AD=B8=A6 =B8=B9=C0=CC =BE=B2=B0=C5=B3=AA= =C1=F6=B9=E6, =C7=D8=BF=DC=BF=A1 =C1=F6=BB=E7, =B0=C5=B7=A1=C3=B3=B0=A1 = =C0=D6=B4=C2 =B1=E2=BE=F7

2.=B9=AB=BF=AA, =C7=D8=BF=EE, =C7=D7=B0=F8, =BF=A9=C7=E0, =BF=DC= =B1=B9=C0=CE,  

=BC=F6=C3=E2=C0=D4=BE=F7=C3=BC =B9=D7 =C1=A6=C1=B6, =B9=B0=B7=F9, =C5=EB=BD=C5, =BF=AC=B1=B8, =C6=D0=BC=C7 =B0=FC=B7=C3= =BE=F7=C3=BC=20

3.=B1=B9=B3=BB=BF=DC =B0=F8=C0=E5, =B0=C7=BC=B3=C7=F6=C0=E5, =C7= =CF=C3=BB=BE=F7=C3=BC=B8=A6 =B5=D0 =B1=E2=BE=F7 =

 

***=BB=F3=B4=E3=B9=AE=C0= =C7

T.018-343-6780

Email: 34009876@atphone.com

www.internet-phone.co.kr

 

=BE=F7=B9=AB=BF=A1 =B9=E6=C7=D8=B0=A1 =B5=C7=BE=FA=B4=D9=B8=E9 =C1= =A4=B8=BB=C1=CB=BC=DB=C7=D5=B4=CF=B4=D9.

=BC=F6= =BD=C5=C0=BB=20 =BF=F8=C4=A1=BE=CA=C0=B8=BD=C3=B8=E9 =BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =B4=AD=B7=AF=C1=D6=BC=BC=BF=E4.
From jan@gondor.com Mon Mar 11 23:36:01 2002 From: jan@gondor.com (Jan Niehusmann) Date: Mon Mar 11 23:36:01 2002 Subject: zlib issues Message-ID: <20020311223355.GA22794@gondor.com> Hi! The security bug in zlib has probably been posted on every important news site by now... for anybody who didn't hear about it: http://www.gzip.org/zlib/advisory-2002-03-11.txt gnupg 1.0.6 contains a version of zlib which seems to be vulnerable. Please consider upgrading to the latest version of zlib. Jan From mihwa38@dreamwiz.com Tue Mar 12 06:25:02 2002 From: mihwa38@dreamwiz.com (¹Ù¶÷²É) Date: Tue Mar 12 06:25:02 2002 Subject: [±¤°í] È­ÀÌÆ®µ¥ÀÌ! ²ÉÀ¸·Î ´ç½ÅÀÇ »ç¶ûÀ»... Message-ID: ¢¿¢½¡Ú [È­ÀÌÆ®µ¥ÀÌ] ¼±¹°Àº "ÇູÇѲɹæ"¿¡¼­...
   
Çϴÿ¡ Âù¶õÇÑ º°ÀÌ ºû³ª°í ¶¥¿¡´Â ¾Æ¸§´Ù¿î ²ÉÀÌ ÇǾµíÀÌ,
»ç¶÷¿¡°Ô´Â µû½ºÇÑ »ç¶ûÀÌ ÀÖ¾î¾ß ÇÑ´Ù....

Çöó¿öµµ»çÀÇ "ÇູÇÑ ²É¹æ"¿¡¼­ [È­ÀÌÆ®µ¥ÀÌ] ¼±¹°À» ÁغñÇϼ¼¿ä!

È¥Çղɹٱ¸´Ï+»çÅÁ
60,000¿ø

Àå¹ÌÇÏÆ®¹Ù±¸´Ï+
»çÅÁ
65,000¿ø
100¼ÛÀ̲ɹٱ¸´Ï+
»çÅÁ
130,000¿ø

100¼ÛÀÌ»óÀÚ+»çÅÁ
130,000¿ø

100¼ÛÀÌÇÏÆ®¹Ú½º+
»çÅÁ
150,000¿ø

20¼ÛÀÌ»óÀÚ+»çÅÁ
50,000¿ø

ÇÏÆ®¹Ú½º+»çÅÁ
100,000¿ø

50¼ÛÀÌÇÏÆ®(»¡°­)+
»çÅÁ
80,000¿ø

25¼ÛÀÌÇÏÆ®+»çÅÁ
60,000¿ø

»¡°­Àå¹Ì²É´Ù¹ß+»çÅÁ
50,000¿ø

20¼ÛÀÌÀå¹Ì²É´Ù¹ß+
»çÅÁ
45,000¿ø
ºÐÈ«Àå¹Ì²É´Ù¹ß+»çÅÁ
50,000¿ø
È¥Çղɴٹß+»çÅÁ
50,000¿ø
100¼ÛÀ̲ɴٹß+»çÅÁ
130,000¿ø

 



     È­ÀÌÆ®µ¥ÀÌ ¿¹¾àÁÖ¹®À» ¹Þ½À´Ï´Ù.(¹è´Þ½Ã°£Àº ¿ÀÀü / ¿ÀÈÄ ±¸ºÐÇÕ´Ï´Ù)
    * È­ÀÌÆ®µ¥ÀÌ ¹è´ÞÁÖ¹®Àº ÁÖ¹®ÆøÁÖ·Î ÀÎÇØ ´çÀÏ¿¡ ÇÑÇÏ¿© ¿ÀÀü/¿ÀÈÄ ¹è´ÞÀ» ÇÕ´Ï´Ù.
    * »çÅÁÀº Áö¿ªº°·Î ´Ù¸¦ ¼öµµ ÀÖ½À´Ï´Ù.
    »çÀü ¾çÇؾøÀÌ ¸ÞÀÏÀ» º¸³»¼­ Á˼ÛÇÕ´Ï´Ù.
    º» ¸ÞÀÏÀº ÀÎÅÍ³Ý»ó¿¡ ¿Ã¶ó¿Â ¸ÞÀÏÁÖ¼Ò¸¦ ¹ßÃéÇÏ¿© ¹ß¼ÛÇÏ¿´½À´Ï´Ù.
    º» ¸ÞÀÏÀº Á¤º¸ Åë½Å¸Á ÀÌ¿ë ÃËÁø ¹× Á¤º¸º¸È£ µî¿¡ °üÇÑ ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.

    ¿øÄ¡ ¾ÊÀ¸½Ã¸é »èÁ¦ÇϽðųª, [¼ö½Å°ÅºÎ]¸¦ ´­·¯ÁÖ¼¼¿ä!

Copyright ¨Ï 2001-2002   J&Y Á¶³ª´Ü Á¤º¸Åë½Å. All Rights Reserved.
From dzon21@netian.com Thu Mar 14 03:46:02 2002 From: dzon21@netian.com (dazon21) Date: Thu Mar 14 03:46:02 2002 Subject: [±¤°í]À̺¸´Ù ´õ½Î¸éµÎ¹èȯºÒ/¼îÅ·°æ¸Å6ź(¼îÇθô±¤°íÀÔ´Ï´Ù) Message-ID: 5ÀÏ ÀåÅÍÇà»ç!

 

¡Ú ȸ¿øÀ¸·Î °¡ÀÔÇϽøé À̽´¿Í À̺¥Æ®µî,¾ËÂ¥ Á¤º¸¿Í °¢Á¾ ÇýÅÃÀ» ¹ÞÀ¸½Ç ¼ö ÀÖ½À´Ï´Ù.
¡Ú¼îÇθô ¿î¿µ¿¡ °ü½É ÀÖÀ¸½ÅºÐÀº [¿©±â]

 ±ÍÇÏÀÇ ¸áÁÖ¼Ò´Â À¥¼­ÇÎÁß ¾Ë°Ô µÇ¾úÀ¸¸ç ¸áÁÖ¼Ò ÀÌ¿ÜÀÇ ´Ù¸¥ Á¤º¸´Â ÀÏü ¾ËÁö ¸øÇÕ´Ï´Ù.
 µÎ ¹ø ´Ù½Ã ¸áÀ» º¸³»Áö ¾ÊÀ» °ÍÀÌ¿À´Ï ÀϺη¯ ¼ö½Å°ÅºÎ ÇÏÁö ¾ÊÀ¸¼Åµµ ÁÁ½À´Ï´Ù.
                                                  [¼ö½Å°ÅºÎ]

From madhatter@necroerotic.org Thu Mar 14 21:14:01 2002 From: madhatter@necroerotic.org (Kevin McMullen) Date: Thu Mar 14 21:14:01 2002 Subject: gpgme documentation Message-ID: <20020314122141.A30169@necroerotic.org> hello, i see at the URL http://www.gnu.org/directory/GPGME.html that there seem to be plans for documentation, but none right now. Is there an expected time that there will be documentation on using the library? Or if I'm just an idiot and there already is, where can I find it? Thanks. From marcus@gnu.org Thu Mar 14 22:06:01 2002 From: marcus@gnu.org (Marcus Brinkmann) Date: Thu Mar 14 22:06:01 2002 Subject: gpgme documentation In-Reply-To: <20020314122141.A30169@necroerotic.org> References: <20020314122141.A30169@necroerotic.org> Message-ID: <20020314210312.GC9211@gnu.org> On Thu, Mar 14, 2002 at 12:21:41PM -0800, Kevin McMullen wrote: > hello, i see at the URL http://www.gnu.org/directory/GPGME.html that there > seem to be plans for documentation, but none right now. Is there an > expected time that there will be documentation on using the library? Or > if I'm just an idiot and there already is, where can I find it? Thanks. Since version 0.3.1 or so, GPGME comes with a reference manual in texinfo format in the doc/ directory. We should put it online one of these days, but it will also be built by default if you build the library. Thanks, Marcus From wk@gnupg.org Fri Mar 15 14:52:02 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 15 14:52:02 2002 Subject: w32 test please Message-ID: <87vgby9c09.fsf@alberti.gnupg.de> Hi! I have just created a new binary package of GnuPG for Windows to fix the zlib bug. I have currently no running Windows system here, so I need a volunteer to test this build. It is available as ftp://ftp.gnupg.org/gcrypt/binary/test/gnupg-w32-1.0.6-2.zip (689k) As soon as a get a report that there are no new bugs in it, I will move it one directory up. The changes are in the diff file and only related to the compression code. tia, Werner From wk@gnupg.org Fri Mar 15 15:56:05 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 15 15:56:05 2002 Subject: [Announce] GnuPG fix for included zlib Message-ID: <871yemar0b.fsf@alberti.gnupg.de> --=-=-= Hi! As you probably all know, a security problem with the compress library zlib has been found which affects a lot of software. For details see: http://www.zlib.org/advisory-2002-03-11.txt and the security announcements for your OS. GnuPG does also use zlib; however in most environments the system provided zlib is used. So an update to this system library is sufficient to fix the problem in GnuPG. On systems without a installed zlib, the GnuPG build process automatically includes the zlib copy which come with it. This may also be forced by using the --with-included-zlib configure option. On those systems, GnuPG needs to be updated! A patch with instructions is attached to this mail. Note, that the MS-Windows version is also affected by this bug; an updated binary package will be available soon. Werner --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=gnupg-zlib.patch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message This is a patch against gnupg 1.0.6 to fix the security bug in the zlib code. Please note that on most systems the zlib code which comes with GnuPG is not used because usually the zlib provided by the system is used. This is in almost all cases a shared library, so it is sufficient to upgrade this one. If the system does only provide a static library, you have to build GnuPG again. Apply this patch if your system does not provide a usable zlib or you configured GnuPG using the option --with-included-zlib. The patch file is GnuPG signed; you might want to check the signature after visual inspection that the patch file itself is not a compressed one (which might trigger the bug). gpg --verify gnupg-zlib.patch Change to the source directory (cd gnupg-1.0.6) and enter: patch -p2 Merged changes from zlib 1.1.4. diff -u orig/gnupg-1.0.6/zlib/deflate.c gnupg-stable/zlib/deflate.c --- orig/gnupg-1.0.6/zlib/deflate.c Wed Jan 13 14:12:48 1999 +++ gnupg-stable/zlib/deflate.c Tue Mar 12 10:34:29 2002 @@ -1,5 +1,5 @@ /* deflate.c -- compress data using the deflation algorithm - * Copyright (C) 1995-1998 Jean-loup Gailly. + * Copyright (C) 1995-2002 Jean-loup Gailly. * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -47,12 +47,12 @@ * */ -/* @(#) $Id: deflate.c,v 1.2 1999/01/13 13:12:48 koch Exp $ */ +/* @(#) $Id: deflate.c,v 1.2.2.1 2002/03/12 09:34:29 werner Exp $ */ #include "deflate.h" const char deflate_copyright[] = - " deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly "; + " deflate 1.1.4 Copyright 1995-2002 Jean-loup Gailly "; /* If you use the zlib library in a product, an acknowledgment is welcome in the documentation of your product. If for some reason you cannot @@ -242,7 +242,7 @@ windowBits = -windowBits; } if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED || - windowBits < 8 || windowBits > 15 || level < 0 || level > 9 || + windowBits < 9 || windowBits > 15 || level < 0 || level > 9 || strategy < 0 || strategy > Z_HUFFMAN_ONLY) { return Z_STREAM_ERROR; } diff -u orig/gnupg-1.0.6/zlib/infblock.c gnupg-stable/zlib/infblock.c --- orig/gnupg-1.0.6/zlib/infblock.c Wed Jan 13 14:12:48 1999 +++ gnupg-stable/zlib/infblock.c Tue Mar 12 10:19:38 2002 @@ -1,5 +1,5 @@ /* infblock.c -- interpret and process block types to last block - * Copyright (C) 1995-1998 Mark Adler + * Copyright (C) 1995-2002 Mark Adler * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -249,10 +249,12 @@ &s->sub.trees.tb, s->hufts, z); if (t != Z_OK) { - ZFREE(z, s->sub.trees.blens); r = t; if (r == Z_DATA_ERROR) + { + ZFREE(z, s->sub.trees.blens); s->mode = BAD; + } LEAVE } s->sub.trees.index = 0; @@ -313,11 +315,13 @@ t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) & 0x1f), s->sub.trees.blens, &bl, &bd, &tl, &td, s->hufts, z); - ZFREE(z, s->sub.trees.blens); if (t != Z_OK) { if (t == (uInt)Z_DATA_ERROR) + { + ZFREE(z, s->sub.trees.blens); s->mode = BAD; + } r = t; LEAVE } @@ -329,6 +333,7 @@ } s->sub.decode.codes = c; } + ZFREE(z, s->sub.trees.blens); s->mode = CODES; case CODES: UPDATE diff -u orig/gnupg-1.0.6/zlib/infcodes.c gnupg-stable/zlib/infcodes.c --- orig/gnupg-1.0.6/zlib/infcodes.c Wed Jan 13 14:12:48 1999 +++ gnupg-stable/zlib/infcodes.c Tue Mar 12 10:19:38 2002 @@ -1,5 +1,5 @@ /* infcodes.c -- process literals and length/distance pairs - * Copyright (C) 1995-1998 Mark Adler + * Copyright (C) 1995-2002 Mark Adler * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -196,15 +196,9 @@ Tracevv((stderr, "inflate: distance %u\n", c->sub.copy.dist)); c->mode = COPY; case COPY: /* o: copying bytes in window, waiting for space */ -#ifndef __TURBOC__ /* Turbo C bug for following expression */ - f = (uInt)(q - s->window) < c->sub.copy.dist ? - s->end - (c->sub.copy.dist - (q - s->window)) : - q - c->sub.copy.dist; -#else f = q - c->sub.copy.dist; - if ((uInt)(q - s->window) < c->sub.copy.dist) - f = s->end - (c->sub.copy.dist - (uInt)(q - s->window)); -#endif + while (f < s->window) /* modulo window size-"while" instead */ + f += s->end - s->window; /* of "if" handles invalid distances */ while (c->len) { NEEDOUT diff -u orig/gnupg-1.0.6/zlib/inffast.c gnupg-stable/zlib/inffast.c --- orig/gnupg-1.0.6/zlib/inffast.c Wed Jan 13 14:12:48 1999 +++ gnupg-stable/zlib/inffast.c Tue Mar 12 10:19:38 2002 @@ -1,5 +1,5 @@ /* inffast.c -- process literals and length/distance pairs fast - * Copyright (C) 1995-1998 Mark Adler + * Copyright (C) 1995-2002 Mark Adler * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -93,28 +93,41 @@ /* do the copy */ m -= c; - if ((uInt)(q - s->window) >= d) /* offset before dest */ - { /* just copy */ - r = q - d; - *q++ = *r++; c--; /* minimum count is three, */ - *q++ = *r++; c--; /* so unroll loop a little */ - } - else /* else offset after destination */ + r = q - d; + if (r < s->window) /* wrap if needed */ { - e = d - (uInt)(q - s->window); /* bytes from offset to end */ - r = s->end - e; /* pointer to offset */ - if (c > e) /* if source crosses, */ + do { + r += s->end - s->window; /* force pointer in window */ + } while (r < s->window); /* covers invalid distances */ + e = s->end - r; + if (c > e) { - c -= e; /* copy to end of window */ + c -= e; /* wrapped copy */ do { - *q++ = *r++; + *q++ = *r++; } while (--e); - r = s->window; /* copy rest from start of window */ + r = s->window; + do { + *q++ = *r++; + } while (--c); } + else /* normal copy */ + { + *q++ = *r++; c--; + *q++ = *r++; c--; + do { + *q++ = *r++; + } while (--c); + } + } + else /* normal copy */ + { + *q++ = *r++; c--; + *q++ = *r++; c--; + do { + *q++ = *r++; + } while (--c); } - do { /* copy all or what's left */ - *q++ = *r++; - } while (--c); break; } else if ((e & 64) == 0) diff -u orig/gnupg-1.0.6/zlib/inftrees.c gnupg-stable/zlib/inftrees.c --- orig/gnupg-1.0.6/zlib/inftrees.c Wed Jan 13 14:12:49 1999 +++ gnupg-stable/zlib/inftrees.c Tue Mar 12 10:19:38 2002 @@ -1,5 +1,5 @@ /* inftrees.c -- generate Huffman trees for efficient decoding - * Copyright (C) 1995-1998 Mark Adler + * Copyright (C) 1995-2002 Mark Adler * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -11,7 +11,7 @@ #endif const char inflate_copyright[] = - " inflate 1.1.3 Copyright 1995-1998 Mark Adler "; + " inflate 1.1.4 Copyright 1995-2002 Mark Adler "; /* If you use the zlib library in a product, an acknowledgment is welcome in the documentation of your product. If for some reason you cannot @@ -104,8 +104,7 @@ /* Given a list of code lengths and a maximum table size, make a set of tables to decode that set of codes. Return Z_OK on success, Z_BUF_ERROR if the given code set is incomplete (the tables are still built in this - case), Z_DATA_ERROR if the input is invalid (an over-subscribed set of - lengths), or Z_MEM_ERROR if not enough memory. */ + case), or Z_DATA_ERROR if the input is invalid. */ { uInt a; /* counter for codes of length k */ @@ -231,7 +230,7 @@ /* allocate new table */ if (*hn + z > MANY) /* (note: doesn't matter for fixed) */ - return Z_MEM_ERROR; /* not enough memory */ + return Z_DATA_ERROR; /* overflow of MANY */ u[h] = q = hp + *hn; *hn += z; diff -u orig/gnupg-1.0.6/zlib/zlib.h gnupg-stable/zlib/zlib.h --- orig/gnupg-1.0.6/zlib/zlib.h Wed Jan 13 14:12:49 1999 +++ gnupg-stable/zlib/zlib.h Tue Mar 12 10:19:41 2002 @@ -1,7 +1,7 @@ /* zlib.h -- interface of the 'zlib' general purpose compression library - version 1.1.3, July 9th, 1998 + version 1.1.4, March 11th, 2002 - Copyright (C) 1995-1998 Jean-loup Gailly and Mark Adler + Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages @@ -37,7 +37,7 @@ extern "C" { #endif -#define ZLIB_VERSION "1.1.3" +#define ZLIB_VERSION "1.1.4" /* The 'zlib' compression library provides in-memory compression and -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6d-cvs (GNU/Linux) iD8DBQE8keynaLeriVdUjc0RAnZaAJ0Q5AX4oAWCkkE5Yqxb4mOcY8rhDQCfTd7D TR5ke8FWP2dRrl/EP5AU6i4= =uKF5 -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From hideki@allcity.net Fri Mar 15 15:59:01 2002 From: hideki@allcity.net (Hideki Saito) Date: Fri Mar 15 15:59:01 2002 Subject: w32 test please In-Reply-To: <87vgby9c09.fsf@alberti.gnupg.de> References: <87vgby9c09.fsf@alberti.gnupg.de> Message-ID: <200203151457.g2FEvQs24248@server-1.visp.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Working just fine :-) >Hi! > >I have just created a new binary package of GnuPG for Windows to fix >the zlib bug. I have currently no running Windows system here, so I >need a volunteer to test this build. It is available as > > ftp://ftp.gnupg.org/gcrypt/binary/test/gnupg-w32-1.0.6-2.zip (689k) > >As soon as a get a report that there are no new bugs in it, I will >move it one directory up. The changes are in the diff file and only >related to the compression code. > >tia, > > Werner > > > >_______________________________________________ >Gnupg-devel mailing list >Gnupg-devel@gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6-2 (MingW32) Comment: For info see http://www.gnupg.org iD8DBQE8kgvv4VMN+RBdJUkRAtksAKCtdUbpgvZpNlH3Rpn01tnz5H7+qwCgmiZn LlZZlllX3rgVNodXtMNsVWc= =zbQN -----END PGP SIGNATURE----- -- Hideki Saito mailto:hideki@allcity.net From wk@gnupg.org Fri Mar 15 19:16:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 15 19:16:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <3C8A4887.60004@beonex.com> (Ben Bucksch's message of "Sat, 09 Mar 2002 18:38:15 +0100") References: <3C8A2228.4020408@beonex.com> <877kold9mq.fsf@alberti.gnupg.de> <3C8A4887.60004@beonex.com> Message-ID: <871yelaedn.fsf@alberti.gnupg.de> On Sat, 09 Mar 2002 18:38:15 +0100, Ben Bucksch said: > That Mozilla relicensing was intended for Mozilla being *used* in GPL > apps like Galeon or Evolution, not for having GPL code included in This turned out to be a very good decision; Galeon is a pretty useful browser for websites which won't show up nicely using Lynx or w3m ;-) > Believe me, I created Beonex Communicator, and I really try to keep > everything completely Open-Source. But users want a browser that > works, with Flash and all the other goodies, *now*. They don't want to If users wants that they should go and get this stuff from elsewhere but don't expect that the GNU project trades Freedom for convenience of so-called "must-haves". Most sites are pretty useless for any security aware users because they are not usable without JavaScript. > Please don't make these goals incompatible. As I said, I choose a > slightly less compatible Open-Source implementation over the PGP and compatible with OpenPGP? They don't even support signing subkeys which is really weird as OpenPGP is (too) closely based on the protocol used by PGP >=5. > include in the browser? Surely, PGP would be desireable. Do you think > that the Abgeordneten would accept not to be able to see Flash content? I hope they can stay away from this stuff. Such kind of easy to trojan software can lead to a lot of work restoring valuable documents. Well, if the office of the chancellor had used such a software, we might had an opportunity to know the content of all the files Mr. Kohl's officers had to purge from their servers after the lost election in 98 ;-) > And last but not least, your lib probably has 0 chance to be part of > the base Mozilla, if it is not MPL/GPL/LGPL tripple-licensed. Any such > plugin would surely live a third-party life, left bitrotting after a > few months of frequent Mozilla changes. I don't care. > As much as I'd like to, I cannot change the content that is out there > on the web. I you have something important to say or write, you should do it in a standard format. If not, well it can't be that important or there is no need to attract more customers. > Being locked out of a few major sites makes users already consider to > switch the browser. You guess which one that is. I am not on a crusade to ban a specific proprietary browser. > I haven't looked at all at it, because its author basically says that > it's just a little toy that he dumped on an ftp server, not really > ready for use. A friend checked it out under Windows and according to him it basically works and he could exchange encrypted or signed mails with Mutt and Gnus users. We will see whether someone starts to work on it. > Have you audited it security-wise? I don't know enough about the > problems there (exec() etc.) to do that. I have not looked at it. Werner From rmartini@cipsga.org.br Fri Mar 15 21:44:02 2002 From: rmartini@cipsga.org.br (Renato Martini) Date: Fri Mar 15 21:44:02 2002 Subject: w32 test please In-Reply-To: <87vgby9c09.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Fri, 15 Mar 2002, Werner Koch wrote: > Date: Fri, 15 Mar 2002 14:49:42 +0100 > From: Werner Koch > To: gnupg-devel@gnupg.org > Subject: w32 test please > > Hi! > > I have just created a new binary package of GnuPG for Windows to fix > the zlib bug. I have currently no running Windows system here, so I > need a volunteer to test this build. It is available as > Hi! My simple test... ____________________________________________________________________ OS: Windows Millennium [Version 4.90.3000] 1. create keyring *sec.key 2048 bits* OKAY 2. import public keys OKAY 3. export public keys ("gpg -a --export -o pub_keys") OKAY 4. export secret keys ("gpg -a -o sec_key --export-secret-keys") OKAY 5. Generate and verify a detached-sign OKAY 6. Encrypt and sign a file OKAY ** NOTE: The gpg diplays the an old version (GnuPG v1.0.4-1) at the openpgp heading - -------------------------------------------------------------------------- Bye - --------- __|_ _| _ \ __| __| \ | Renato Martini ::: Diretor Administrativo ( | __/\__ \ (_ | _ \ | http://www.cipsga.org.br \___|___|_| ____/\___|_/ _\ | http://gnupg.unixsecurity.com.br - ----------------------------------------------------------------------- "O Fantasia, che dei tempi e delle distanze fai il tuo giuoco audace!" (Gabriele d'Annunzio) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8k68RYogE2yD8bPYRA3WNAJ9jWCihYsKFItoU4RH9QvkBfsm/IACfdjTk qwRFTfm+b3J866rvxCh60XU= =yltW -----END PGP SIGNATURE----- From wk@gnupg.org Fri Mar 15 21:58:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 15 21:58:01 2002 Subject: w32 test please In-Reply-To: (Renato Martini's message of "Sat, 16 Mar 2002 17:45:44 -0300 (BRT)") References: Message-ID: <87elil8sct.fsf@alberti.gnupg.de> On Sat, 16 Mar 2002 17:45:44 -0300 (BRT), Renato Martini said: > ** NOTE: > The gpg diplays the an old version (GnuPG v1.0.4-1) at the openpgp heading What does gpg --version say? Perhaps you run it with -v and you are seeing the header lines of files generated with an old versions? Thanks for the tests, Werner From rmartini@cipsga.org.br Sat Mar 16 03:28:01 2002 From: rmartini@cipsga.org.br (Renato Martini) Date: Sat Mar 16 03:28:01 2002 Subject: w32 test please In-Reply-To: <87elil8sct.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Fri, 15 Mar 2002, Werner Koch wrote: > Date: Fri, 15 Mar 2002 21:54:10 +0100 > From: Werner Koch > To: Renato Martini > Cc: gnupg-devel@gnupg.org > Subject: Re: w32 test please > > On Sat, 16 Mar 2002 17:45:44 -0300 (BRT), Renato Martini said: > > > ** NOTE: > > The gpg diplays the an old version (GnuPG v1.0.4-1) at the openpgp heading > > What does gpg --version say? Perhaps you run it with -v and you are > seeing the header lines of files generated with an old versions? Hi Werner! No problems man! There was an old file signed with gpg 1.0.4 in the gpg directory... So, there aren't problems, the release works *really* fine! best regards - --------- __|_ _| _ \ __| __| \ | Renato Martini ::: Diretor Administrativo ( | __/\__ \ (_ | _ \ | http://www.cipsga.org.br \___|___|_| ____/\___|_/ _\ | http://gnupg.unixsecurity.com.br - ----------------------------------------------------------------------- "O Fantasia, che dei tempi e delle distanze fai il tuo giuoco audace!" (Gabriele d'Annunzio) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8k/+NYogE2yD8bPYRA60KAJ9jTg0yFDUsbXU8keeknRQgoGscnwCggSwE MDKTGDvDKxgx4RYuSHa+o4Q= =8rjK -----END PGP SIGNATURE----- From Enzo Michelangeli" <877kold9mq.fsf@alberti.gnupg.de> Message-ID: <022f01c1cc94$b7f99da0$0200000a@noip.com> ----- Original Message ----- From: "Werner Koch" To: Sent: Saturday, 09 March, 2002 11:49 PM Subject: Re: Mozilla, License (again), PPG, GPGME [...] > > OpenPGP needs to have a nice UI for it, if it ever wants to be a > > widely used standard. I know the security concerns, but I think they > > Yes, definitely. Noone as volunteered to make GPA or any of the other > frontends a workable solution, so I fear that without a proper funding > there will be no good GUI in the near future. I know that this is > very important. I have a list of things in mind which should be > undertaken by further GPA (or whatever) development. Timo Schultz's WinPT (www.winpt.org) looks pretty nice to me, and should definitely help PGP users willing to migrate smoothly to GnuPG. Did I miss any horrible hidden shortcoming? :-) Enzo From ddm@pizzashack.org Sat Mar 16 18:45:01 2002 From: ddm@pizzashack.org (Derek D. Martin) Date: Sat Mar 16 18:45:01 2002 Subject: gpg subkeys, revisited In-Reply-To: <1016257151.16327.1.camel@allevil> References: <20020315233857.A6820@pizzashack.org> <1016257151.16327.1.camel@allevil> Message-ID: <20020316124152.A7155@pizzashack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At some point hitherto, Douglas Calvert hath spake thusly: > On Fri, 2002-03-15 at 23:38, Derek D. Martin wrote: > > I missed it the first time, but it sounds like I'm having the same > > exact problem as Douglas Calvert had a couple of weeks ago: [SNIP] > No dice. There is a problem with the keyservers. They cannot handle > multiple subkeys. [SNIP] Ok thanks, but well, my problem is a bit more involved than just that. Basically the problem is that on the machine that I read mail, I accidentally deleted my old encryption subkey. I still have other subkeys on that keyring associated with my signing key (0x81CFE75D) that I need to keep. But obviously, I want to keep my old encryption key around, so I can decrypt messages that are sent to me by people who haven't yet gotten the new subkey from me, or forgot to import it, or for messages I already have hanging around... I have a copy of the old subkey on another machine. That old keyring does not have the other subkeys that I wish to keep. What I need to do is merge the two keyrings. I can do this with the PUBLIC subkeys no problem. However, GPG will not let me incorporate the SECRET subkey, no matter what I try. I've tried using both --export-secret-key and --export-secret-subkey on the export side of things, and I always use --allow-secret on the import side, but I only get error messages from gpg as such: $ ssh otherhost gpg -a --export-secret-subkey ddm |gpg --allow-secret --import ddm@otherhost's password: gpg: key 81CFE75D: already in secret keyring gpg: Total number processed: 1 gpg: secret keys read: 1 gpg: secret keys unchanged: 1 So, gpg seems to fail to realize that there are subkeys in the exported block that are not in the local copy, and refuses to import them. Whether or not this is intended behavior, I think this is a bug. Otherwise, there's no way to recover accidentally deleted subkeys, and if you DO accidentally delete a subkey, your options would be to maintain two different keyrings (one with the deleted one and the other with all the other keys), or throw up your hands in frustration and generate a whole new key. And if you have old messages that you still need to decrypt with the old key, the latter isn't even really an option. Neither of those options is ideal. IMO, the best solution is for gpg to allow the import of secret subkeys. Please note: I'm not on gnupg-devel, so please CC me ONLY if your reply is going to be ONLY on that list (I'm on gnupg-users). Thanks. - -- Derek Martin ddm@pizzashack.org - --------------------------------------------- I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8k4PedjdlQoHP510RAoVjAKCbgELUN80DO5xj+/Stl6luJpsM7QCeK+7L 7fTlskD+WiOs0fQjNcXkezM= =IgBT -----END PGP SIGNATURE----- From redbird@rbisland.cx Sun Mar 17 01:59:01 2002 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Mar 17 01:59:01 2002 Subject: Easy Install 1.0.6r5: dynload and zlib Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So far it seems like the dynload patch is working for everyone except for a very few of us, and even then it will work with a little hacking. So, with the zlib bug announced and fixed, I want to get 1.0.6r5 out soon. Since Apple still has not updated their dynamically loading version of zlib, 1.0.6r5 will continue to statically link against zlib, but other things will be dynamically linked against where possible (as I understand it, GnuPG should try to dynamically link against libraries when dynload is enabled by default). I haven't heard from Chad lately, so I don't know if he'll be doing this next release or not. Probably not tomorrow but on Monday I'm going to try to get an Installer package together if we still haven't heard from Chad. Also, I'll finish updating the documentation and post the dynload patch and a link to the zlib 1.1.4 patch. BTW, for those who haven't being paying attention, zlib 1.1.3, which GnuPG and about a million other programs use, has a double free error in it that might allow an attacker to run arbitrary code. zlib 1.1.4 fixes this and a couple of other small issues. I have yet to mention this because I didn't want all our users to panic before we had new binaries posted. - -- Gordon Worley `When I use a word,' Humpty Dumpty http://www.rbisland.cx/ said, `it means just what I choose redbird@rbisland.cx it to mean--neither more nor less.' PGP: 0xBBD3B003 --Lewis Carroll -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: http://www.rbisland.cx/publickeys.html iEYEARECAAYFAjyT6eYACgkQMDmH6OHSe1sgGwCgjGP1RVP832qRLlDosrIOy2bW e7UAnAwojPruWeLH5PLha4eZ8+o0TGp+ =aCPl -----END PGP SIGNATURE----- From redbird@rbisland.cx Sun Mar 17 02:15:02 2002 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Mar 17 02:15:02 2002 Subject: Easy Install 1.0.6r5: dynload and zlib In-Reply-To: Message-ID: <15492819-3944-11D6-8893-000A27B4DEFC@rbisland.cx> On Saturday, March 16, 2002, at 07:56 PM, Gordon Worley wrote: Oops, I typed the wrong address again. Oh well, I guess these slip ups at least let everyone know what's up on the Mac side from time to time. ;-) -- Gordon Worley `When I use a word,' Humpty Dumpty http://www.rbisland.cx/ said, `it means just what I choose redbird@rbisland.cx it to mean--neither more nor less.' PGP: 0xBBD3B003 --Lewis Carroll From rjhansen@inav.net Sun Mar 17 08:28:02 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Sun Mar 17 08:28:02 2002 Subject: GPGME and Weird Keys Message-ID: <1016350036.23132.20.camel@numbers.robnet.net> I've got a strange bug which is most likely either a bug in GPGME, or else a bizarre key that GPG is able to show just fine, but GPGME can't. (Of course, my own code is utterly bug-free and has never known the slightest defect or fault... :) ) I've been tearing my head out over this one for days now; there are two keys which will sometimes render correctly, but which more often than not will render incorrectly. I can query everything about these keys except for their names, which strikes me as really strange--for every given key at index 0 there ought to be a valid name/email/etc. So finally in despair, I used gpg_key_get_as_xml(foo) to dump out key data of each key as I was querying it. A GpgmeKey with queryable names, after having been run through gpgme_key_get_as_xml(): 3D8AF1B209AC0A6A 7A1A407FB1CA7E4EAE85E7303D8AF1B209AC0A6A 17 1024 900443902 L. Sassaman <rabbi@NO.SPAM.quickie.net> L. Sassaman rabbi@NO.SPAM.quickie.net << given this is Len's key, many many more userids deleted... >> D9CE865681451634 16 2048 900443903 ... and a keyblock which apparently only has queryable keyID, fingerprint, algorithm, length and creation date, after being run through gpgme_key_get_as_xml(): 1E419D60B21D6AA7 32002537B225D1613F1008B0C3F666DE 0 2048 924419219 ... Now, when I do "gpg --list-key B21D6AA7", I get: pub 2048R/B21D6AA7 1999-04-18 Ted Parvu uid Ted Parvu uid Ted Parvu (All email addresses are spamblocked. The spamblocking isn't in the native data, o'course.) ... So apparently there's some information stuck in the key data which GPGME simply isn't getting, isn't reading, isn't--well, something isn't getting processed/handled appropriately. Is this a known bug? Are there any workarounds? From redbird@rbisland.cx Sun Mar 17 15:56:02 2002 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Mar 17 15:56:02 2002 Subject: GPGME and Weird Keys In-Reply-To: <1016350036.23132.20.camel@numbers.robnet.net> Message-ID: On Sunday, March 17, 2002, at 02:27 AM, Robert J. Hansen wrote: > Is this a known bug? Are there any workarounds? Well, I know about it, but I just figured I had a bad key from someone. At any rate, the way I get around it in GPGKeys on OS X is to put the key listing code inside an error handling block. Then I just return an error saying `hey, there's a bad key' and leave it at that. Also, it may be helpful to print out the xml representation of the key for the user. -- Gordon Worley `When I use a word,' Humpty Dumpty http://www.rbisland.cx/ said, `it means just what I choose redbird@rbisland.cx it to mean--neither more nor less.' PGP: 0xBBD3B003 --Lewis Carroll From pgut001@cs.auckland.ac.nz Mon Mar 18 05:33:01 2002 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Mon Mar 18 05:33:01 2002 Subject: Mozilla, License (again), PPG, GPGME Message-ID: <200203180429.QAA97621@ruru.cs.auckland.ac.nz> Arno Wagner writes: >Just for the record that is > > M- Does OO sync with how we think? > Hatton, L. > IEEE Software , Volume: 15 Issue: 3 , May-June 1998 > Page(s): 46 -54 There are a number of other analyses of OO available which point out problems, including some OO aspects which are so problematic that they can be used as warning signs for code bugs: -- Snip -- [...] Examples of semantic complexity which go beyond obvious factors such as the choice of algorithm include the fact that recursive functions are harder to comprehend than non-recursive ones, the fact that linked lists are more difficult to comprehend than arrays, and the use of certain OO techniques which lead to non-linear code which is more difficult to follow than non-OO equivalents [ ][ ] (so much so that the presence of indicators such as a high use of method invocation and inheritance has been used as a means of identifying fault-prone C++ classes [ ][ ]). [ ] .Does OO Sync with How We Think?., Les Hatton, IEEE Software, Vol.15, No.3 (May/June 1998), p.46. [ ] .Experimental assessment of the effect of inheritance on the maintainability of object-oriented systems., R.Harrison, S.Counsell, and R.Nithi, The Journal of Systems and Software, Vol.52, No.2/3 (1 June 2000), p.173. [ ] .Exploring the relationships between design measures and software quality in object-oriented systems., Lionel Brand, Jürgen Wüst, John Daly, and D.Victor Porter, The Journal of Systems and Software, Vol.51, No.3 (1 May 2000), p.245. [ ] .An Empirical Investigation of an Object-Oriented Software System., Michelle Cartwright and Martin Shepperd, IEEE Transactions on Software Engineering, Vol.26, No.8 (August 2000), p.786. -- Snip -- (Excuse the broken formatting, it's a cut&paste from a MS doc). Peter. From ajs@ajs.com Mon Mar 18 15:27:01 2002 From: ajs@ajs.com (Aaron Sherman) Date: Mon Mar 18 15:27:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <200203180429.QAA97621@ruru.cs.auckland.ac.nz> References: <200203180429.QAA97621@ruru.cs.auckland.ac.nz> Message-ID: <1016461508.11412.520.camel@pps> On Sun, 2002-03-17 at 23:29, Peter Gutmann wrote: > Arno Wagner writes: > > >Just for the record that is > > > > M- Does OO sync with how we think? > > Hatton, L. > > IEEE Software , Volume: 15 Issue: 3 , May-June 1998 > > Page(s): 46 -54 > > There are a number of other analyses of OO available which point out problems, > including some OO aspects which are so problematic that they can be used as > warning signs for code bugs: It has always been my impression that OO was going through a stage where it was the new technique, but that in the long run, we'd learn to incorporate the OO paradigm into our toolbox without letting it take over every line of code produced (just as many features of functional programming have been absorbed by higher-level procedural languages like Perl, Python, etc). The idea that thing X is of class Y, which is a sub-class of Z makes sense, and IS the way we think about certain aspects of our world. It is, if you will pardon the metaphor, our noun-think. We also have a verb-think which is mostly procedural in nature: "go to the store. buy eggs. come home. cook eggs." You will note that we do not use the passive voice by default: "I will have been caused to go to the store. The eggs will be cooked now." Until programming *techniques* begin to mature to the point where we can flow between the paradigms, we will continue to mis-apply them and thereby increase the complexity of our code. From daloonim@hanmail.net Mon Mar 18 21:22:02 2002 From: daloonim@hanmail.net (¾ßÈÄ) Date: Mon Mar 18 21:22:02 2002 Subject: ÀÌ»Û º½ ºê¶ó¿ì½º¸¦ ²ÇÂ¥·Î µå¸®´Â °÷!![±¤~~~°í] Message-ID: <200203182020.g2IKKFB7014771@mail.openit.de> html>=20 =20 =20 =20 =20 =BB=F5 =C6=E4=C0=CC=C1=F6 1=20 =20 =20

=20 =20 =20 From rodmur@maybe.org Mon Mar 18 23:54:02 2002 From: rodmur@maybe.org (Dale Harris) Date: Mon Mar 18 23:54:02 2002 Subject: list closed to subscribers? In-Reply-To: <200203182020.g2IKKFB7014771@mail.openit.de>; from daloonim@hanmail.net on Tue, Mar 19, 2002 at 05:18:37AM +0900 References: <200203182020.g2IKKFB7014771@mail.openit.de> Message-ID: <20020318144953.D26540@maybe.org> So is this list closed to subscribers only? That would be one way of cutting down on the spam to the list. I assume the spammers are not subscribed. Dale From rjhansen@inav.net Tue Mar 19 00:13:01 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Tue Mar 19 00:13:01 2002 Subject: OO and the Real World? (Was: Moz, License) In-Reply-To: <1016461508.11412.520.camel@pps> References: <200203180429.QAA97621@ruru.cs.auckland.ac.nz> <1016461508.11412.520.camel@pps> Message-ID: <1016493100.6859.19.camel@numbers.robnet.net> > Until programming *techniques* begin to mature to the point where we can > flow between the paradigms, we will continue to mis-apply them and > thereby increase the complexity of our code. Let me edit your first sentence: until /programmers/ mature to the point where we can abandon One True Way thinking and instead use the proper tool for the job, we will continue to mis-apply our tools and thereby increase the complexity of our code. This is, incidentally, why I'm such a fan of C++ and Python. C++, contrary to popular opinion, isn't an object-oriented language. It's a multiparadigm language and one of the paradigms it supports is OO. Procedural, functional, generic, OO... they're all tools in the toolbox. The wise programmer uses the correct tool for the job. C++ and Python just give me an awful lot of tools. I really think the idea of One True Way is a childhood disease of programmers. All of us fall victim to it at some point, and for a lot of us, the disease becomes a chronic condition. From newsweeek@kebi.com Tue Mar 19 07:48:02 2002 From: newsweeek@kebi.com (Áß¾ÓÀ̺¥Æ®) Date: Tue Mar 19 07:48:02 2002 Subject: *Ãà* ¼±¹° ¹Þ¾Æ °¡¼¼¿ä *Ãà* (È« º¸) Message-ID: ¾È³çÇϼ¼¿ä? Áß¾Ó Å׸¶ À̺¥Æ®ÀÔ´Ï´Ù.

º» ¸ÞÀÏÀº ¹ß½ÅÀü¿ëÀÔ´Ï´Ù.¶§¹®¿¡ ¼Û½ÅÀÚ ¸ÞÀÏÁּҷδ ȸ½ÅÀ» º¸³¾ ¼ö ¾ø½À´Ï´Ù.
Á˼ÛÇÏÁö¸¸ ¼ö½ÅÀ» ¿øÇÏÁö ¾ÊÀ¸½Ã¸é ¸Ç¾Æ·¡ÀÇ ¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯ÇØ Áֽʽÿä.
¹®ÀÇ»çÇ×Àº ȨÆäÀÌÁö¿¡ ¿À¼Å¼­ ¹®ÀÇÇϽøé Ä£ÀýÇÏ°Ô ´äÇص帳´Ï´Ù.
±ÍÇÏÀÇ ½Â¶ô¾øÀÌ È«º¸¼º ¸ÞÀÏÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°úµå¸³´Ï´Ù.

 
     
 
Áö±Ý ½ÅûÇϽô ºÐ¿¡ ÇÑÇÏ¿© Æú¶ó·ÎÀ̵å Ä«¸Þ¶ó³ª ·Î¸¸¼Õ °í±Þ Ä¿Çà ¼Õ¸ñ½Ã°è¸¦ µå¸³´Ï´Ù 
¹®ÀÇ : 02) 771-9495

´ã´ç : ¹Ú    Çö    ÁÖ

 

  
     
                 Áß¾ÓÅ׸¶À̺¥Æ®´Â Áß¾ÓÀϺ¸ ´º½ºÀ§Å©Áö»ç¿¡¼­ ÇÏ´Â À̺¥Æ® È«º¸Çà»çÀÔ´Ï´Ù

  [¿ùȸºñ 10,500¿ø]

Ưº° »çÀºÇ°ÁõÁ¤ : Æú¶ó·ÎÀ̵å Ä«¸Þ¶ó ¶Ç´Â ·Î¸¸¼Õ °í±Þ Ä¿ÇýðèÁß ÅÃÀÏ
±¹Á¦ ½Ã»çÁÖ°£Áö ´º½ºÀ§Å© Çѱ¹ÆÇ : 2³â°£ 100ºÎ (¸ÅÁÖ1±Ç)¹ß¼Û, ¿µÇÑÇؼ³ º°ÁöºÎ·Ï 8Page
                                                        Æ÷ÇÔ 
¿µÈ­·ÎÀÇÃÊ´ë : ¿¬ 8ȸÀÌ»ó, ¹«·áÃÊ´ë±Ç (2ÀÎ ÀÔÀå)
    ÁÖ¸»¿¡ »ó¿µÇÏ¸ç ½Ã°£¼±Åð¡´É, °³ºÀÇÏ´Â ¿ì¼ö¿µÈ­ ¶Ç´Â ½Ã»çȸ¸¦ ¼±Á¤

                        *ÀÌÀü¿µÈ­ - ¾ÆÆ®¾îºê¿ö,ij½ºÆ®¾î¿þÀÌ,¹Ì½º¿¡ÀÌÀüÆ®,¼¶¿ø¶óÀÌÅ©À¯,½Å¶óÀÇ´Þ¹ã,
                                          È¤¼ºÅ»Ãâ,ų·¯µéÀǼö´Ù,´Þ¸¶¾ß³îÀÚ,È­»ê°í,¹ÝÁöÀÇ Á¦¿Õ µî
¶óÀ̺êÄܼ­Æ® : ¿¬ 4ȸÀÌ»ó, ¹«·áÃÊ´ë±Ç (2ÀÎ ÀÔÀå)

                        *ÀÌÀüÄܼ­Æ®-ÀÌÀº¹Ì,±è°æÈ£,¾Èġȯ,±è¹ÎÁ¾,±èÇöÁ¤,Àڿ츲,À±µµÇö¹êµå,¼­¹®Å¹ µî
¸í°­»ç ¸í°­ÀÇ : ¿¬ 6ȸ ÀÌ»ó, ¹«·áÃÊ´ë±Ç (2ÀÎ ÀÔÀå)

                         *ÀÌÀü°­ÀÇ-Ȳ¼ö°ü,À̽ÃÇü,¾ö±æû,Á¤´öÈñ,Àü¿©¿Á,±¸¼º¾Ö,¹éÁö¿¬,Ç¥ÁøÀÎ,²ô·¹º§¹Ú µî
¿¬±Ø, ¹ÂÁöÄà : ¿¬ 12ȸÀÌ»ó, ÇÒÀοì´ë±Ç (50%~20% ÇÒÀÎÀ²)

                        *ÀÌÀü°ø¿¬ - ºê·Îµå¿þÀÌ 42¹ø°¡,ÄÚ·¯½º¶óÀÎ,³Í¼¾½º,¾Æ¸®¶û,µå¶óÅ¥¶ó,¿©·Î µî
Á¤µ¿±ØÀå : °ø¿¬ 20% ÇÒÀÎÇýÅà (Áß¾Ó Á¤È¸¿ø ¸â¹ö½± Ä«µåÁöÂü½Ã)
 Á¤È¸¿ø ¸â¹ö½± Ä«µå¹ß±Þ : Áß¾ÓÅ׸¶À̺¥Æ®¿¡¼­ ÁÖ°üÇÏ´Â ¹®È­Çà»ç ÃÊ´ë

 

ÀúÈñ°¡ ȸ¿øºÐµé¿¡°Ô Á¦°øÇØ µå¸®´Â ȸ¿øÇýÅÃÀ» ÀÚºñ·Î ÀÌ¿ëÇÏ½Å´Ù¸é ¿ù 50,000¿ø ÀÌ»ó ÁöÃâµÉ °ÍÀÔ´Ï´Ù.Çà»ç±â°£¿¡ ȸ¿ø°¡ÀÔÀ» Çϼż­ ¿ù 10,500¿ø¿¡ ÀÌ ¸ðµç ¹®È­»ýÈ°À» ´©¸®¼¼¿ä. Æú¶ó·ÎÀ̵å Ä«¸Þ¶ó³ª ·Î¸¸¼Õ Ä¿Çüոñ½Ã°è´Â Çà»ç±â°£¿¡ °¡ÀÔÇϽô ȸ¿øºÐµé²² µå¸®´Â »çÀºÇ°ÀÔ´Ï´Ù. ¿©·¯ºÐÀÇ Áú³ôÀº ¹®È­»ýÈ°¿¡ µµ¿òÀÌ µÇ°íÀÚ ÇÏ´Â Áß¾ÓÅ׸¶À̺¥Æ®ÀÔ´Ï´Ù.

                                                                       È¸¿ø°¡ÀÔ°ú ÀÚ¼¼ÇÑ ³»¿ëÀº ȨÆäÀÌÁö·Î
  


º» ¸ÞÀÏÀ» °ÅºÎÇϽô ºÐÀº [¼ö½Å°ÅºÎ ]¸¦ ´­·¯Áֽʽÿä. ºÒÆíÇÏ°Ô Çصå·È´Ù¸é Á˼ÛÇÕ´Ï´Ù.
From dshaw@jabberwocky.com Tue Mar 19 22:42:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Mar 19 22:42:01 2002 Subject: gpg subkeys, revisited In-Reply-To: <20020316124152.A7155@pizzashack.org> References: <20020315233857.A6820@pizzashack.org> <1016257151.16327.1.camel@allevil> <20020316124152.A7155@pizzashack.org> Message-ID: <20020319213951.GC683@akamai.com> On Sat, Mar 16, 2002 at 12:41:53PM -0500, Derek D. Martin wrote: > So, gpg seems to fail to realize that there are subkeys in the > exported block that are not in the local copy, and refuses to import > them. Whether or not this is intended behavior, I think this is a > bug. Otherwise, there's no way to recover accidentally deleted > subkeys, and if you DO accidentally delete a subkey, your options > would be to maintain two different keyrings (one with the deleted one > and the other with all the other keys), or throw up your hands in > frustration and generate a whole new key. And if you have old > messages that you still need to decrypt with the old key, the latter > isn't even really an option. Neither of those options is ideal. IMO, > the best solution is for gpg to allow the import of secret subkeys. GnuPG does not currently allow importing secret subkeys. In your particular example where you have two different copies of the secret key, each with a different subkey, you are going to have a difficulties. It's not exactly a common problem. :) The solution is to generate one key from your two, and import that. To do this, you need the "gpgsplit" tool, which is part of GnuPG 1.0.7 (grab the test version from ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6d.tar.gz if you need it). Run one of the keys through gpgsplit and delete all the files that come before the first "XXXXXXX-007.secret_subkey" file. Then cat the key you didn't split along with the files that are left after you deleted everything before the secret subkey. For example: $ gpgsplit mykey2 $ rm 000001-005.secret_key 000002-013.user_id 000003-002.sig $ cat mykey1 000004-007.secret_subkey 000005-002.sig > mywholekey $ gpg --allow-secret-key-import --import mywholekey David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From jmos@gmx.net Wed Mar 20 00:00:01 2002 From: jmos@gmx.net (jmos@gmx.net) Date: Wed Mar 20 00:00:01 2002 Subject: iterated+salted s2k insecure ? Message-ID: <401.1016578678@www13.gmx.net> Hello! I am wondering if "s2k-mode 3" (which is the default for GnuPG 1.0.6) is secure. I read RFC 2440 section 3.6.1.3. "Iterated and Salted S2K" and it seems to me that certain passphrase lengths are subject to an attack to the corresponding session key. E.g. passphrases that consist of 7, 27, 47, 67 or 87 characters result in a session key with only 256 possibilities which are shared among all passphrases with the given lengths. I would consider this a strong security risk because 256 possiblities for a session key is nothing. I do not know if I understood the RFC right but maybe one of you gurus can (hopefully) proof me wrong! -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From kcl@2-sun.com Wed Mar 20 13:11:01 2002 From: kcl@2-sun.com (kcl) Date: Wed Mar 20 13:11:01 2002 Subject: ±¤°í-»ï¼º Ä®¶óÇÁ¸°ÅÍ°¡ ÀÌ·±°¡°Ý¿¡...... Message-ID:
¾È³ç Çϼ¼¿ä.  º» ¸ÞÀÏÀº ±¤°í ¸ÞÀÏ ÀÔ´Ï´Ù.
»çÀü Çã¶ô¾øÀÌ ¸ÞÀÏÀ» º¸³»°Ô µÇ¾î¼­ Áø½ÉÀ¸·Î Á˼ÛÇÕ´Ï´Ù
¸ÞÀÏ ¹Þ±â¸¦ ¿øÄ¡  ¾ÊÀ¸½Å´Ù¸é ¾Æ·¡ ¸ÞÀÏ·Î ¹Ý¼Û¸ÞÀÏÀ» º¸³»Áֽøé
ÀÌÈÄ¿¡´Â Àý´ë·Î ¸ÞÀÏÀÌ ¼ö½ÅµÇÁö ¾ÊÀ» °ÍÀÔ´Ï´Ù.
.
¹Ý¼Û¸ÞÀÏ ÁÖ¼Ò : webmaster@2-Sun.com
                Àü È­ : 02-701-9111
-------------------------------------------------------------------------------------------
     »ï¼ºÇÁ¸°ÅÍ MJC-935 i    110,000 ¿ø¿¡ ÆǸŠ  ( Ư°¡ ÆǸŰ¡°Ý ÀÔ´Ï´Ù )
                          ¼ÒºñÀÚ°¡:157,000 ¿ø ======> 110,000 ¿ø¿¡ ÆǸÅ
                     
  --------------------------------------------------------------------------------------------  
  • 1200dpi ÃÊ°íÇØ»óµµ
    1ÀÎÄ¡´ç ÂïÈ÷´Â À×Å©¹æ¿ïÀÇ Å©±â°¡ ±âÁ¸ÀÇ ¹æ½Äº¸´Ù ÈξÀ ÀÛÀº
  • '±Ø¹Ì¼¼ À×Å©¹æ½Ä'À» ä¿ë,ÀϹݿëÁö¿¡¼­µµ ¼¶¼¼ÇÑ Ä÷¯ÀÇ ´À³¦À» ±×´ë·Î ÀçÇöÇØ µå¸³´Ï´Ù.

  • ½Ã¿øÇÑ ¼Óµµ 7PPM
    1ºÐ¿¡ ÃÖ´ë 7ÀåÀÇ Èæ¹é¹®¼­ ¹× 3ÀåÀÇ Ä÷¯¹®¼­¸¦ Ãâ·ÂÇÒ ¼ö Àִ Ź¿ùÇÑ ½ºÇǵå!
  • ÀÏ¹Ý ÇнÀ¿ëÀ¸·Î³ª ¼Ò±Ô¸ð »ç¹«½Ç¿ëÀ¸·Î »ç¿ëÇϱ⿡ ¾Ë¸ÂÀº ¼ÓµµÀÔ´Ï´Ù.

  • ¹øÁü¾ø°í ±ò²ûÇÑ ÇDZ׸ÕÆ® À×Å©
    ¾î¶² Á¾·ùÀÇ ¿ëÁö¸¦ »ç¿ëÇصµ ¹øÁöÁö ¾Ê°í ¶Ç·ÈÇÏ°Ô ÀμâÇØÁÖ´Â °ËÁ¤»ö ÇDZ׸ÕÆ®À×Å©¸¦ »ç¿ë,
  • Ãâ·ÂµÈ ¹®¼­°¡ ÇÑ°á ±ò²ûÇØ º¸ÀÔ´Ï´Ù.

  • 45dBÀÇ Á¶¿ëÇÑ ÇÁ¸°ÆÃ
    45dB ÀÌÇÏÀÇ Àú¼ÒÀ½ ÇÁ¸°ÆÃÀÌ °¡´ÉÇÑ ÃÊÁ¤¹Ð ¸ÞÄ«´ÏÁò ¿£ÁøÀ» ä¿ë, ÀÏ¹Ý °¡Á¤À̳ª »ç¹«½Ç¿¡¼­
  • Á¶¿ëÇÏ°Ô »ç¿ëÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù.

    »ó¼¼spec

  • Àμâ¼Óµµ : 7ppm(Èæ¹é) / 3ppm(Ä÷¯)

  • ÇØ»óµµ : 1,200 x 1,200dpi(Ä÷¯, Èæ¹é)

  • ÀÎÀÚ¸ðµå : HBP

  • ȣȯ¼º : Window 95/98/NT 4.0 /2000/Me/XP,Mac OS 8.6/9.xÁö¿ø

  • ¸Þ¸ð¸® : 512KB

  • ÀÎÅÍÆäÀ̽º : USB(Universal Serial Bus), Æз¯·¼

  • ¿ëÁöÅ©±â : A4,A5,B5,Legal,Executive,A6,¹è³Ê,¿±¼­,¶óº§ ¿ëÁö

  • ±ÞÁö¿ë·® : 100¸Å(ÇÁ¸®¹Ì¾ö ¿ëÁö100¸Å ¹«·áÁ¦°ø)

  • ¹èÁö¿ë·® : 25¸Å

  • Á¦Ç° Å©±â(W*D*H) : 447 X 170X 210 mm

  • Á¤°ÝÀü¿ø : AC 220V Àü¿ë,60 Hz


        .
  1. ¼Ò ºñ ÀÚ °¡  :  157,000 ¿ø  ¸ðµ¨:MJC-935 i  »ï¼ºÇÁ¸°ÅÍ
  2. Çö±ÝÆǸŰ¡  :  110,000 ¿ø
  3. ÅÃ¹è ¹ß¼Û                    
  4. ÇÑ Á¤ ÆÇ ¸Å : 2002 .03.31±îÁö

 

 »ï¼ºÇÁ¸°ÅÍ ÃÑÆÇ  ÀüÈ­: 02-701-9111

From dhill@wgate.com Wed Mar 20 18:53:02 2002 From: dhill@wgate.com (Dave Hill) Date: Wed Mar 20 18:53:02 2002 Subject: Space-padded lines in crypt-text Message-ID: <42C66B69F1F5D411B99300508BAC454606851657@mail.tvol.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D037.56A2C0D0 Content-Type: text/plain; charset="iso-8859-1" Hi all. I've run into a problem running GnuPG on text copied out of an email in Eudora or Netscape. With the right combination of circumstances, the GPG text ends up padded with a space at the end of each line (ie space-cr-lf or space-lf on every line). The spaces in the crypt-text block itself don't cause GPG a problem, but the space at the end of the -----BEGIN PGP MESSAGE----- line causes GnuPG not to recognize the block as valid crypt-text. I was wondering: 1) Why does the space in the BEGIN line cause a problem, but not the spaces in the crypt-text block? 2) If it makes sense, could someone in the group implement a fix that wouldn't break other stuff in the process? Thanks for any input you can provide, Dave Hill WorldGate Communications, Inc. ------_=_NextPart_001_01C1D037.56A2C0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Space-padded lines in crypt-text

Hi all.  I've run into a problem running GnuPG = on text copied out of an email in Eudora or Netscape.  With the = right combination of circumstances, the GPG text ends up padded with a = space at the end of each line (ie space-cr-lf or space-lf on every = line).  The spaces in the crypt-text block itself don't cause GPG = a problem, but the space at the end of the -----BEGIN PGP MESSAGE----- = line causes GnuPG not to recognize the block as valid crypt-text.  = I was wondering:

1)  Why does the space in the BEGIN line cause a = problem, but not the spaces in the crypt-text block?

2)  If it makes sense, could someone in the = group implement a fix that wouldn't break other stuff in the = process?

Thanks for any input you can provide,

Dave Hill
WorldGate Communications, Inc.

------_=_NextPart_001_01C1D037.56A2C0D0-- From dshaw@jabberwocky.com Wed Mar 20 19:24:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Mar 20 19:24:01 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <42C66B69F1F5D411B99300508BAC454606851657@mail.tvol.net> References: <42C66B69F1F5D411B99300508BAC454606851657@mail.tvol.net> Message-ID: <20020320182214.GB683@akamai.com> On Wed, Mar 20, 2002 at 12:47:43PM -0500, Dave Hill wrote: > Hi all. I've run into a problem running GnuPG on text copied out of an > email in Eudora or Netscape. With the right combination of circumstances, > the GPG text ends up padded with a space at the end of each line (ie > space-cr-lf or space-lf on every line). The spaces in the crypt-text block > itself don't cause GPG a problem, but the space at the end of the -----BEGIN > PGP MESSAGE----- line causes GnuPG not to recognize the block as valid > crypt-text. I was wondering: > > 1) Why does the space in the BEGIN line cause a problem, but not the spaces > in the crypt-text block? This is according to the spec. Since you refer to coping the text out of an email, I'll assume the text is either clearsigned text or an ASCII armored message. In clearsigned text, extra spaces at the end of lines are ignored. In ASCII armored text, spaces in general are ignored. The reason a space in the BEGIN line causes a problem is also by the spec - all of the armor BEGIN or END lines must be complete on their own line and contain nothing else > 2) If it makes sense, could someone in the group implement a fix that > wouldn't break other stuff in the process? Why does text copied out of an email grow extra spaces? David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From nils@gnupg.org Wed Mar 20 19:27:01 2002 From: nils@gnupg.org (nils@gnupg.org) Date: Wed Mar 20 19:27:01 2002 Subject: New GnuPG FAQ maintainer wanted Message-ID: <15512.54260.451259.397881@barber.fmi.uni-passau.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, a while ago, based on Werner's ASCII FAQ file, I set up the current GnuPG FAQ, because I was annoyed by the amount of reoccuring questions especially on gnupg-users. As I was frequently reading the lists I could regularly update the FAQ with new issues and remove stale entries. Very helpful were submissions by friendly FAQ readers. However, during the last months I had less and less time to maintain the FAQ so there were only very few updates, although more might have been necessary. I tried to find a new maintainer by private conversation, but to no avail so far. I probably didn't try hard enough, so I'm sorry about the FAQ right now being slightly out of date. This should change, so in agreement with Werner: A NEW GNUPG FAQ MAINTAINER IS WANTED! A volunteer for this job should ... * have a good understanding of how to use GnuPG * follow the discussions on the mailings lists * being able to identify FAQ-worthy entries I'm not here to set up guidelines how to do it, but I think one of the biggest caveats is not to try to be an extension to the manual. Lots of people mailed me stuff that either was in the man page or should have been there. My aim was to keep the FAQ short and not clutter it with lots of tips and tricks around GnuPG. However, your mileage may vary. If you're interested, please drop me a line. I will help to set you up. If there's more than one volunteer, I'll talk to Werner whom to pick. One would be enough, I guess. [If you want to suggest a different selection process, feel free to discuss it in this list ;-) ] May the applications come ... ;) Cheers, Nils -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard iD8DBQE8mNPIFwvIHy+DHcMRAjnnAKCR22qNUSAuoFrJIC/r9hnk0LIYIQCeJUYR bnwqWqkNVhtLFMMXvlQYqZA= =PsCQ -----END PGP SIGNATURE----- From dhill@wgate.com Wed Mar 20 19:47:01 2002 From: dhill@wgate.com (Dave Hill) Date: Wed Mar 20 19:47:01 2002 Subject: Space-padded lines in crypt-text Message-ID: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D03E.EC0D5110 Content-Type: text/plain; charset="iso-8859-1" David, Eudora and Netscape users on our lan receive email from Outlook as HTML when they connect using IMAP. This happens regardless of any plain-text settings at the sender, server, or receiver software. When HTML text from these apps is copied to the Windoze clipboard, it ends up space padded. I haven't been able to figure out whether this is a problem in the client apps, or the Windoze clipboard implementation, although if I had to make a guess... Unfortunately, this breaks GPGShell, which I've been setting up for non-tech types to be able to decrypt PGP email. I thought that rather than come up with an ugly hack elsewhere, and since I'm unlikely to get MS to fix their clipboard, GnuPG would be the right place to look for a clean fix. Dave >Why does text copied out of an email grow extra spaces? ------_=_NextPart_001_01C1D03E.EC0D5110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Space-padded lines in crypt-text

David,

Eudora and Netscape users on our lan receive email = from Outlook as HTML when they connect using IMAP.  This happens = regardless of any plain-text settings at the sender, server, or = receiver software.  When HTML text from these apps is copied to = the Windoze clipboard, it ends up space padded.  I haven't been = able to figure out whether this is a problem in the client apps, or the = Windoze clipboard implementation, although if I had to make a = guess...  Unfortunately, this breaks GPGShell, which I've been = setting up for non-tech types to be able to decrypt PGP email.  I = thought that rather than come up with an ugly hack elsewhere, and since = I'm unlikely to get MS to fix their clipboard, GnuPG would be the right = place to look for a clean fix.

Dave

>Why does text copied out of an email grow extra = spaces?

------_=_NextPart_001_01C1D03E.EC0D5110-- From saravn@mozdev.org Wed Mar 20 20:26:01 2002 From: saravn@mozdev.org (R. Saravanan) Date: Wed Mar 20 20:26:01 2002 Subject: Mozilla, License (again), PPG, GPGME Message-ID: <3C98E2E1.5070000@mozdev.org> Regarding Enigmail: On Fri Mar 15 19:16:01 2002, Werner Koch said: > A friend checked it out under Windows and according to him > it basically works and he could exchange encrypted or signed mails > with Mutt and Gnus users. Just to confirm that Enigmail, a mozilla "plugin" for GPG/PGP, is now in much better shape than it was just a few months ago, and is being used by several people.I will shortly post an "official" announcement in the users mailing list regarding the availability of Enigmail from http://enigmail.mozdev.org As for Enigmail's architecture, it uses pipes to communicate with command-line PGP or GPG; hence no license issues. This seems to work fine for encryption/decryption/verification etc. although it could be cumbersome for key management, which Enigmail doesn't really do at the moment. As for security, using Enigmail is in a sense only as secure as using Mozilla itself. If you are using Mozilla, and a malicious web page manages to gain "Universal Browser Access" privileges, it could read or write files in your directory, and perhaps even modify your GPG executable! Additional insecurities introduced by Enigmail mostly have to with obtaining and caching the passphrase. Enigmail has a passphrase caching option which can be turned off. Enigmail also takes some basic precautions to prevent access to the cached passphrase. There is still the possibility of "user interface spoofing" to obtain the passphrase, which I don't see a way of completely avoiding. One could perhaps gain some extra security by running the Mozilla mailer in a stand-alone mode, i.e., not as part of the browser. Saravanan Enigmail developer From dfc@anize.org Wed Mar 20 22:10:02 2002 From: dfc@anize.org (Douglas Calvert) Date: Wed Mar 20 22:10:02 2002 Subject: New GnuPG FAQ maintainer wanted In-Reply-To: <15512.54260.451259.397881@barber.fmi.uni-passau.de> References: <15512.54260.451259.397881@barber.fmi.uni-passau.de> Message-ID: <1016658454.27438.34.camel@allevil> --=-h8I8oTIaW4cB+t7cKwmP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I would be interested in maintaing the FAQ. I read users daily and have asked enough stupid questions that I know good FAQs. I have been buggin werner about what I could do to help out and this seems like a good thing for me. My coding skills are fairly weak but I can read and write. I am a grad student at syr.edu so i have a good deal of free time and spend a lot of it staring at my computer. Please let me know what else you would like from me. =20 I sent this to the list only to get feedback from others on my ability to handle this task. Any other emails can be off-list most likely... --=20 +---------------+-----------------------------------+ |Douglas Calvert| http://anize.org/dfc | | dfc@anize.org | http://imissjerry.org | +---------------+-----------------------------------+ | If you use envelopes, why not use encryption? | | http://anize.org/dfc/dfc-keys.asc | | 0817 30D4 82B6 BB8D 5E66 06F6 B796 073D C954 1FB2 | +-------------| http://www.gnupg.org |--------------+ --=-h8I8oTIaW4cB+t7cKwmP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8mPoWt5YHPclUH7IRAhnpAJ9LFsmFVMsqYjDpqqeoFIdaeJaCPQCgtPLJ noU8snF8X2fSOLUlj5MhEgs= =nB7+ -----END PGP SIGNATURE----- --=-h8I8oTIaW4cB+t7cKwmP-- From wk@gnupg.org Wed Mar 20 22:14:02 2002 From: wk@gnupg.org (Werner Koch) Date: Wed Mar 20 22:14:02 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> (Dave Hill's message of "Wed, 20 Mar 2002 13:42:00 -0500") References: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> Message-ID: <87r8mf0wug.fsf@alberti.gnupg.de> On Wed, 20 Mar 2002 13:42:00 -0500, Dave Hill said: > Windoze clipboard implementation, although if I had to make a guess... > Unfortunately, this breaks GPGShell, which I've been setting up for non-tech Please fix it there. Trimming all blanks from lines starting with at least 2 dashes should do the task while not even changing the actual message, although this is won't matter either. Werner From dhill@wgate.com Wed Mar 20 22:36:02 2002 From: dhill@wgate.com (Dave Hill) Date: Wed Mar 20 22:36:02 2002 Subject: Space-padded lines in crypt-text Message-ID: <42C66B69F1F5D411B99300508BAC454606851661@mail.tvol.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D056.83854A40 Content-Type: text/plain; charset="iso-8859-1" > Please fix it there. Trimming all blanks from lines starting with at > least 2 dashes should do the task while not even changing the actual > message, although this is won't matter either. > Not sure what you mean by "fix it there". I'd love to fix the Windoze clipboard implementation, but so far MS has been reluctant to give me the source code ) Dave ------_=_NextPart_001_01C1D056.83854A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Space-padded lines in crypt-text

> Please fix it there.  Trimming all blanks = from lines starting with at
> least 2 dashes should do the task while not = even changing the actual
> message, although this is won't matter = either.
>
Not sure what you mean by "fix it = there".  I'd love to fix the Windoze clipboard = implementation, but so far MS has been reluctant to give me the source = code )

Dave

------_=_NextPart_001_01C1D056.83854A40-- From jmos@gmx.net Thu Mar 21 01:50:01 2002 From: jmos@gmx.net (jmos@gmx.net) Date: Thu Mar 21 01:50:01 2002 Subject: iterated+salted s2k insecure ? Message-ID: <17145.1016671668@www46.gmx.net> >Hello! > >I am wondering if "s2k-mode 3" (which is the default for GnuPG 1.0.6) >is secure. >I read RFC 2440 section 3.6.1.3. "Iterated and Salted S2K" and it >seems to me that certain passphrase lengths are subject to an attack >to the corresponding session key. >E.g. passphrases that consist of 7, 27, 47, 67 or 87 characters >result in a session key with only 256 possibilities which are shared >among all passphrases with the given lengths. >I would consider this a strong security risk because 256 possiblities >for a session key is nothing. > >I do not know if I understood the RFC right but maybe one of you gurus >can (hopefully) proof me wrong! Ok no one answered, I guess I have to be a little more precise. According to RFC 2440 "Iterated+Salted S2K" works as follows: First, eight random bytes (the 'salt') are calculated. These random bytes followed by the passphrase data are repeatedly hashed until the number of bytes specified by the octet count has been hashed. Normally GnuPG uses 96 as the octet count. So, if someone uses a passphrase of 87 octets length the 8 octets of salt are prepended to yield a total of 95 octets. The result is normally a 20 octets hash value. But to satisfy the octet count of 96 one more octet has to be hashed. This is taken from the 20 octets hash value which was calculated before. But because only one more octet is hashed there are only 256 possibilities for the resulting hash value and therefore for the corresponding session key (at least for keys that are smaller than 160 bits). The same for passphrases with 67, 47, 27 and 7 octets length except that the hashing is done more often. Any comments ? Did I understand the RFC right ? -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From Enzo Michelangeli" Message-ID: <006c01c1d074$a5ede6a0$0200000a@noip.com> This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C1D0B7.AE5E6920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Space-padded lines in crypt-textBut won't the added spaces anyway = break cleartext (non-armoured) signed messages? Those can't be trimmed = easily. Enzo ----- Original Message -----=20 From: Dave Hill=20 To: gnupg-devel@gnupg.org=20 Sent: Thursday, 21 March, 2002 5:30 AM Subject: RE: Space-padded lines in crypt-text > Please fix it there. Trimming all blanks from lines starting with = at=20 > least 2 dashes should do the task while not even changing the actual = > message, although this is won't matter either.=20 >=20 Not sure what you mean by "fix it there". I'd love to fix the Windoze = clipboard implementation, but so far MS has been reluctant to give me = the source code ) Dave=20 ------=_NextPart_000_0067_01C1D0B7.AE5E6920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Space-padded lines in crypt-text
But won't the added spaces = anyway break=20 cleartext (non-armoured) signed messages? Those can't be trimmed=20 easily.
 
Enzo
----- Original Message -----
From:=20 Dave = Hill
Sent: Thursday, 21 March, 2002 = 5:30=20 AM
Subject: RE: Space-padded lines = in=20 crypt-text

> Please fix it there.  Trimming all blanks = from lines=20 starting with at
> least 2 dashes should = do the=20 task while not even changing the actual
> = message,=20 although this is won't matter either.
>=20
Not sure what you mean by "fix it = there".  I'd=20 love to fix the Windoze clipboard implementation, but so far MS has = been=20 reluctant to give me the source code )

Dave

------=_NextPart_000_0067_01C1D0B7.AE5E6920-- From bobmathews@mindspring.com Thu Mar 21 03:20:01 2002 From: bobmathews@mindspring.com (Bob Mathews) Date: Thu Mar 21 03:20:01 2002 Subject: iterated+salted s2k insecure ? In-Reply-To: <17145.1016671668@www46.gmx.net> References: <17145.1016671668@www46.gmx.net> Message-ID: <20020321021740.30B0A9D1B@cabbit.cat> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 20 March 2002 04:47 pm, jmos@gmx.net wrote: > These random bytes followed by the passphrase data are repeatedly > hashed until the number of bytes specified by the octet count has > been hashed. "Repeatedly hashed" doesn't mean that the hash value is computed and then fed back into the hash function again and again. It means that the same salt and password are fed into one hash calculation repeatedly, and one hash value is computed at the end. > Normally GnuPG uses 96 as the octet count. I just checked, and the octet count was 65536. Don't forget that part of the count field is actually a left-shift amount. > So, if someone uses a passphrase of 87 octets length the 8 octets > of salt are prepended to yield a total of 95 octets. The result is > normally a 20 octets hash value. The 20 octet hash value is not computed until after the required number of octets have been passed through the hash function. > But to satisfy the octet count of 96 one more octet has to be hashed. > This is taken from the 20 octets hash value which was calculated before. No, if 96 octets are to be hashed, the extra octet would come from the beginning of the salt. -bob mathews -----BEGIN PGP SIGNATURE----- Comment: What's this? http://bobmathews.home.mindspring.com/bob/ iD8DBQE8mUKfPgDecCrBEpcRAob2AKCH17JqxfmGr0PYTW088B4eBxMuTQCdFUJ+ jSByJ64w2WqTlh1tuY0QgFg= =9gvR -----END PGP SIGNATURE----- From wk@gnupg.org Thu Mar 21 10:14:02 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 10:14:02 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <42C66B69F1F5D411B99300508BAC454606851661@mail.tvol.net> (Dave Hill's message of "Wed, 20 Mar 2002 16:30:53 -0500") References: <42C66B69F1F5D411B99300508BAC454606851661@mail.tvol.net> Message-ID: <87adt2z3p6.fsf@alberti.gnupg.de> On Wed, 20 Mar 2002 16:30:53 -0500, Dave Hill said: > Not sure what you mean by "fix it there". I'd love to fix the Windoze In GPGShell. Afaik WinPT does not have this problem and the clipboard is used as well. Werner From wk@gnupg.org Thu Mar 21 10:16:01 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 10:16:01 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <006c01c1d074$a5ede6a0$0200000a@noip.com> ("Enzo Michelangeli"'s message of "Thu, 21 Mar 2002 09:06:26 +0800") References: <42C66B69F1F5D411B99300508BAC454606851661@mail.tvol.net> <006c01c1d074$a5ede6a0$0200000a@noip.com> Message-ID: <87663qz3m3.fsf@alberti.gnupg.de> On Thu, 21 Mar 2002 09:06:26 +0800, Enzo Michelangeli said: > RE: Space-padded lines in crypt-textBut won't the added spaces anyway break cleartext (non-armoured) signed messages? Those can't be trimmed easily. According to the specs trailing white spaces are to be trimmed in clear text message for signature creation and verification. The dash lines are boundaries and are not part of the signed text. Werner From wk@gnupg.org Thu Mar 21 11:44:01 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 11:44:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <3C98E2E1.5070000@mozdev.org> ("R. Saravanan"'s message of "Wed, 20 Mar 2002 12:28:33 -0700") References: <3C98E2E1.5070000@mozdev.org> Message-ID: <87henaxky2.fsf@alberti.gnupg.de> On Wed, 20 Mar 2002 12:28:33 -0700, R Saravanan said: > command-line PGP or GPG; hence no license issues. This seems to work > fine for encryption/decryption/verification etc. although it could be > cumbersome for key management, which Enigmail doesn't really do at the Better leave this task for other utilities, seahorse, Geheimnis, WinPT or whatever. > executable! Additional insecurities introduced by Enigmail mostly have > to with obtaining and caching the passphrase. Enigmail has a Don't put too much work into this. gpg 1.0.7 (1.0.6d already has this) will be able to use the private key framework of aegyptne (ie. gpg-agent and pinentry) and thus an application does not need to take car of this. Thanks, Werner From wk@gnupg.org Thu Mar 21 12:12:06 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 12:12:06 2002 Subject: [Announce] Announcing a GnuPG "plugin" for Mozilla (Enigmail) Message-ID: <87pu1yxlq6.fsf@alberti.gnupg.de> From: "R. Saravanan" To: gnupg-users@gnupg.org Date: Wed, 20 Mar 2002 12:50:51 -0700 Enigmail, a GnuPG "plugin" for Mozilla which has been under development for some time, has now reached a state of practical usability with the Mozilla 0.9.9 release. It allows you to send or receive encrypted mail using the Mozilla mailer and GPG. Enigmail is open source and dually licensed under GPL/MPL. You can download and install the software from the website http://enigmail.mozdev.org Enigmail is cross-platform like Mozilla, although binaries are supplied only for the Win32 and Linux-x86 platforms on the website.At the moment there is no version of Enigmail available for Netscape 6.2 or earlier, which are based on much older versions of Mozilla.There will be a version available for the next Netscape release, which is expected to be based on Mozilla 1.0. You may post enigmail-specific comments to the Enigmail newsgroup/mailing list at mozdev.org _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dhill@wgate.com Thu Mar 21 15:03:01 2002 From: dhill@wgate.com (Dave Hill) Date: Thu Mar 21 15:03:01 2002 Subject: Space-padded lines in crypt-text Message-ID: <42C66B69F1F5D411B99300508BAC45460685167C@mail.tvol.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D0E0.7365FD00 Content-Type: text/plain; charset="iso-8859-1" Actually, WinPT 0.5.5 has the exact same problem. I contacted the developer of GPGShell, and he told me that his program doesn't do any operations on the text in the clippboard at all, so it would require a major re-design. Dave > In GPGShell. Afaik WinPT does not have this problem and the clipboard > is used as well. > > Werner ------_=_NextPart_001_01C1D0E0.7365FD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Space-padded lines in crypt-text

Actually, WinPT 0.5.5 has the exact = same problem.  I contacted the developer of GPGShell, and he told = me that his program doesn't do any operations on the text in the = clippboard at all, so it would require a major re-design.  =

Dave

> In GPGShell.  Afaik WinPT does not have = this problem and the clipboard
> is used as well.
>=20
>  Werner

------_=_NextPart_001_01C1D0E0.7365FD00-- From twoaday@freakmail.de Thu Mar 21 17:18:01 2002 From: twoaday@freakmail.de (Timo Schulz) Date: Thu Mar 21 17:18:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <87henaxky2.fsf@alberti.gnupg.de> References: <3C98E2E1.5070000@mozdev.org> <87henaxky2.fsf@alberti.gnupg.de> Message-ID: <20020321160915.GA702@daredevil.joesixpack.net> On Thu Mar 21 2002; 11:40, Werner Koch wrote: > Don't put too much work into this. gpg 1.0.7 (1.0.6d already has > this) will be able to use the private key framework of aegyptne > (ie. gpg-agent and pinentry) and thus an application does not need to > take car of this. Maybe it's a good idea to mention, that the gpg-agent is also available for Win32 and GPG also contains some code to access the Win32 version. Timo From gzenker@pop500.gsfc.nasa.gov Thu Mar 21 18:28:01 2002 From: gzenker@pop500.gsfc.nasa.gov (Glenn Zenker) Date: Thu Mar 21 18:28:01 2002 Subject: gpgme-0.3.4 Message-ID: <20020321122459.3e5f6551.gzenker@pop500.gsfc.nasa.gov> I am on a Sun Solaris box trying to compile gpgme-0.3.4 and I get this error. Making all in gpgme make all-am source='util.c' object='util.lo' libtool=yes \ depfile='.deps/util.Plo' tmpdepfile='.deps/util.TPlo' \ depmode=gcc /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile /usr/local/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c -o util.lo `test -f util.c || echo './'`util.c rm -f .libs/util.lo /usr/local/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c util.c -Wp,-MD,.deps/util.TPlo -fPIC -DPIC -o .libs/util.lo In file included from util.c:28: util.h:142: parse error before `*' util.h:142: warning: function declaration isn't a prototype *** Error code 1 make: Fatal error: Command failed for target `util.lo' Current working directory /folks/gzenker/gpgme-0.3.4/gpgme *** Error code 1 make: Fatal error: Command failed for target `all' Current working directory /folks/gzenker/gpgme-0.3.4/gpgme *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /folks/gzenker/gpgme-0.3.4 *** Error code 1 make: Fatal error: Command failed for target `all' I compiled with the options: ./configure --prefix=/usr/tools && make I was able to compile gpgme-0.3.3 the same way with no problems at all. Any ideas why I am getting this error? Thanks for any help! -- Glenn.Zenker@gsfc.nasa.gov From wk@gnupg.org Thu Mar 21 20:48:01 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 20:48:01 2002 Subject: gpgme-0.3.4 In-Reply-To: <20020321122459.3e5f6551.gzenker@pop500.gsfc.nasa.gov> (Glenn Zenker's message of "Thu, 21 Mar 2002 12:24:59 -0500") References: <20020321122459.3e5f6551.gzenker@pop500.gsfc.nasa.gov> Message-ID: <87bsdhu2l1.fsf@alberti.gnupg.de> Hi! There is a new function which is not yet used in gpgme but the required structure needs off_t and ssize_t. To fix it, please insert this line #include /* make sure that ssize_t and off_t are defined */ right after the line #if !HAVE_FOPENCOOKIE Hth, Werner From wk@gnupg.org Thu Mar 21 22:38:01 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 22:38:01 2002 Subject: gpgme-0.3.4 In-Reply-To: <20020321160906.7d2c26b7.gzenker@pop500.gsfc.nasa.gov> (Glenn Zenker's message of "Thu, 21 Mar 2002 16:09:06 -0500") References: <20020321122459.3e5f6551.gzenker@pop500.gsfc.nasa.gov> <87bsdhu2l1.fsf@alberti.gnupg.de> <20020321160906.7d2c26b7.gzenker@pop500.gsfc.nasa.gov> Message-ID: <87bsdhsiyt.fsf@alberti.gnupg.de> On Thu, 21 Mar 2002 16:09:06 -0500, Glenn Zenker said: > I apologize, but I don't see the line > #if !HAVE_FOPENCOOKIE gpgme-0.3.4/gpgme/util.h near the end you find #if !HAVE_FOPENCOOKIE typedef struct { ssize_t (*read)(void*,char*,size_t); ssize_t (*write)(void*,const char*,size_t); int (*seek)(void*,off_t*,int); int (*close)(coid*); } _IO_cookie_io_functions_t; typedef _IO_cookie_io_functions_t cookie_io_functions_t; FILE *fopencookie (void *cookie, const char *opentype, cookie_io_functions_t funclist); #endif /*!HAVE_FOPENCOOKIE*/ #endif /*HAVE_CONFIG_H*/ Ahemm, there is a typo I already fixed in the CVS - this is probably what caused the trouble: int (*close)(coid*); should be int (*close)(void*); From jmos@gmx.net Fri Mar 22 01:21:01 2002 From: jmos@gmx.net (jmos@gmx.net) Date: Fri Mar 22 01:21:01 2002 Subject: iterated+salted s2k insecure ? Message-ID: <22453.1016756306@www40.gmx.net> On Wednesday 20 March 2002 04:47 pm, jmos@gmx.net wrote: >> These random bytes followed by the passphrase data are repeatedly >> hashed until the number of bytes specified by the octet count has >> been hashed. >"Repeatedly hashed" doesn't mean that the hash value is computed and then fed >back into the hash function again and again. It means that the same salt and >password are fed into one hash calculation repeatedly, and one hash value is >computed at the end. >> Normally GnuPG uses 96 as the octet count. >I just checked, and the octet count was 65536. Don't forget that part of the >count field is actually a left-shift amount. >> So, if someone uses a passphrase of 87 octets length the 8 octets >> of salt are prepended to yield a total of 95 octets. The result is >> normally a 20 octets hash value. >The 20 octet hash value is not computed until after the required number of >octets have been passed through the hash function. >> But to satisfy the octet count of 96 one more octet has to be hashed. >> This is taken from the 20 octets hash value which was calculated before. >No, if 96 octets are to be hashed, the extra octet would come from the >beginning of the salt. > -bob mathews Thanks Bob for your explanation of what is actually meant by the RFC ! Am I the only person who misunderstood that section ? I think it could have been written a little bit more precise. Jens -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From JanuszA.Urbanowicz Sun Mar 24 18:41:02 2002 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Sun Mar 24 18:41:02 2002 Subject: keyring-splitting program Message-ID: --ELM72123749-26264-0_ Content-Type: application/pgp; format=text; x-action=sign Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello I've written a small Python program/module to split my keyring into sepaarte keys for rebuilding since it got corrupted. It is also useful for importing large amounts of keys into PGP - all versions have problems with importing large (>50) solid blobs of public keys. Since its a spinoff of generic gnupg gnupg interface I'm writing, I named id gnupg.py, feel encouraged to rename it as you like during installation. I consider this a submission for the Project's tools directory. Hope you will find the code useful. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6d (GNU/Linux) iD8DBQE8nhEdTfkBjn4ugD0RA+hJAJ9f/Zuv5kFG3EDkY2+sLmHYCgQ9lgCeJajl V69/47wLvRSE/82UUyaOw4o= =OZVm -----END PGP SIGNATURE----- --ELM72123749-26264-0_ Content-Type: text/plain; charset=ISO-8859-2 Content-Disposition: attachment; filename=gnupg.py Content-Description: python program Content-Transfer-Encoding: 7bit #! /usr/bin/env python '''Utility program for GNU Privacy Guard. This code runs under Python 1.5.2 on GNU/Linux. It should run on newer versions of Python as well. Some of the functions won't run on other architectures. Copyright 2002 Janusz A. Urbanowicz $Id: gnupg.py,v 1.2.1.5 2002/03/24 17:16:07 alex Exp $ This program is distributed under the terms opf GNU General Public License. Version 2 or later. When called as a program, exports every key in the public keyring to a file named by the key's 64 bit key ID in binary or ascii armored form. Optionally, binary mode and destination directory can be specified. For usage info, run the program with -h parameter. The program can be laso used as a Python module with following public functions: listkeys(), listkey(), simpledecrypt() and recipients(). For description of those, refer to appropriate docstrings. ''' import tempfile,os,re,popen2,sys,getopt,os.path # # Utility functions # def listkeys(): "Returns a dictionary of long-keyid (key) and primary UID (value) for default keyring)" primaryre = re.compile('^pub:(?:-|u|r|f|d|m|q|e):[0-9]{3,4}?:(?:1|17):((?:[A-Z]|[0-9])+?):[0-9]{4}\-[0-9]{2}\-[0-9]{2}:(?:[0-9]{4}\-[0-9]{2}\-[0-9]{2})?:\w*?:\w*?:(.*?):\w*?:\w*?:') secondaryre = re.compile('^uid:(?:-|u|r|f|d|m|q|e)::::::::(.*?):') imagere = re.compile('^\[image of size [0-9]+?\]') klucze = {} gpghandle = os.popen('gpg --with-colons -k','r') gpgoutput = gpghandle.readlines() gpghandle.close() for i in range(len(gpgoutput)): result = primaryre.match(gpgoutput[i]) try: keyid = result.groups()[0] except AttributeError: continue klucze[keyid] = result.groups()[1] if imagere.match(klucze[keyid]) == None: continue else: klucze[keyid] = None while primaryre.match(gpgoutput[i+1]) == None: i = i+1 result = secondaryre.match(gpgoutput[i]) try: klucze[keyid] = result.groups()[0] assert imagere.match(klucze[keyid]) == None break except AttributeError,AssertionError: pass if klucze[keyid] == None: del klucze[keyid] del keyid return klucze def listkey(key): "Returns a dictionary of long-keyid (key) and primary UID (value) for a single key." primaryre = re.compile('^pub:(?:-|u|r|f|d|m|q|e):[0-9]{3,4}?:(?:1|17):((?:[A-Z]|[0-9])+?):[0-9]{4}\-[0-9]{2}\-[0-9]{2}:(?:[0-9]{4}\-[0-9]{2}\-[0-9]{2})?:\w*?:\w*?:(.*?):\w*?:\w*?:') secondaryre = re.compile('^uid:(?:-|u|r|f|d|m|q|e)::::::::(.*?):') imagere = re.compile('^\[image of size [0-9]+?\]') klucze = {} gpghandle = os.popen('gpg --with-colons -k %s' % key,'r') gpgoutput = gpghandle.readlines() gpghandle.close() for i in range(len(gpgoutput)): result = primaryre.match(gpgoutput[i]) try: keyid = result.groups()[0] except AttributeError: continue klucze[keyid] = result.groups()[1] if imagere.match(klucze[keyid]) == None: continue else: klucze[keyid] = None while primaryre.match(gpgoutput[i+1]) == None: i = i+1 result = secondaryre.match(gpgoutput[i]) try: klucze[keyid] = result.groups()[0] assert imagere.match(klucze[keyid]) == None break except AttributeError,AssertionError: pass if klucze[keyid] == None: del klucze[keyid] del keyid return klucze def simpledecrypt(passphrase,data): 'Decrypt PGP encrypted data with supplied passphrase, the result is the return value' tempfilename = tempfile.mktemp() tempfile = open(tempfilename,'w') tempfile.write(data) tempfile.close() gpghandle = popen2.popen2('gpg --passphrase-fd 0 --batch --output - %s' % tempfilename) gpghandle[1].write(passphrase) gpghandle[1].close() data = gpghandle[0].read() gpghandle[0].close() os.unlink(tempfilename) return data def recipients(data): "Returns a tuple of key IDs the message is encrypted to. Based on the code from GnuPG FAQ." gpghandle = popen2.popen2('gpg --batch --decrypt --list-only --status-fd 1') gpghandle[1].write(data) gpghandle[1].close() results = gpghandle[0].readlines() gpghandle[0].close() recipientre = re.compile('^\[GNUPG:\] ENC_TO ((?:[A-Z]|[0-9]){16}) .*$',re.MULTILINE) result = [] for line in results: try: match = recipientre.search(line).groups() except AttributeError: continue result.append(match[0]) return tuple(result) # # Splitkeyring code. # if __name__ == '__main__': dir = '' mode = '--armor' params,args = getopt.getopt(sys.argv[1:],'hd:b',['help','output-dir','binary']) for param in params: if '-h' in param or '--help' in param: print '%s $Revision: 1.2.1.5 $\n' % sys.argv[0] print 'Copyright 2002 Janusz A. Urbanowicz .\n' print 'This program is distributed under the terms of GNU General Public License.' print 'Version 2 or later.\n' print 'Synopsis: %s [-d | --output-dir ] [-b | --binary]' % sys.argv[0] print '\nOptions: \n\n -d, --output-dir directtory to store the keys in (default: cwd)' print ' -b, --binary export keys in binary form (default: off)' print ' -h, --help this help message\n' sys.exit(0) if '-d' in param or '--output-dir' in param: try: dir = param[1] except: print 'No output directory supplied.' sys.exit(1) dir = os.path.abspath(dir) if '-b' in param or '--binary' in param: mode = '' lkeys = listkeys() for keyid in lkeys.keys(): file = open(os.path.join(dir,keyid),'w+') if mode: file.write('%s\n\n' % lkeys[keyid]) gpghandle = os.popen('gpg --quiet %s --batch --export %s' % (mode, keyid), 'r') data = gpghandle.readlines() gpghandle.close() file.writelines(data) file.close() ## Local Variables: ## mode: Python ## py-indent-offset: 2 ## fill-column: 100 ## End: --ELM72123749-26264-0_ Content-Type: application/pgp Content-Disposition: attachment; filename=gnupg.py.asc Content-Description: detached signature file Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6d (GNU/Linux) Comment: http://quiston.tpsa.com/~alex/pgp.html iQCVAwUAPJ4Qerm/3a0nyBvJAQPbMQQAhKJQNmwYrEwd5Gk0dOJfvGL+UZM+aD4Q FPHneoXj137/8fN+/0BgOY6FjRoAFxr1jJ6ErTO/INBJA5xulR6yhZNW5qRDDl/a KuxzC1ptCcnFQNLNkUdbIMsqzjErPCffBtrgkMbg/ubTNPutKRNn3c8E+cFzFv24 i5TsumSSvZA= =6beb -----END PGP SIGNATURE----- --ELM72123749-26264-0_-- From dshaw@jabberwocky.com Tue Mar 26 01:27:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Mar 26 01:27:01 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> References: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> Message-ID: <20020326002513.GG745@akamai.com> > >Why does text copied out of an email grow extra spaces? On Wed, Mar 20, 2002 at 01:42:00PM -0500, Dave Hill wrote: > David, > > Eudora and Netscape users on our lan receive email from Outlook as HTML when > they connect using IMAP. This happens regardless of any plain-text settings > at the sender, server, or receiver software. When HTML text from these apps > is copied to the Windoze clipboard, it ends up space padded. I haven't been > able to figure out whether this is a problem in the client apps, or the > Windoze clipboard implementation, although if I had to make a guess... > Unfortunately, this breaks GPGShell, which I've been setting up for non-tech > types to be able to decrypt PGP email. I thought that rather than come up > with an ugly hack elsewhere, and since I'm unlikely to get MS to fix their > clipboard, GnuPG would be the right place to look for a clean fix. FYI, after some discussion with Werner, and in the interests of "be liberal in what you accept, conservative in what you generate", I changed the code in GnuPG 1.0.7 to permit extra spaces on the armor header lines. The --openpgp flag makes this strict again. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From dmitri@users.sourceforge.net Tue Mar 26 04:28:01 2002 From: dmitri@users.sourceforge.net (Dmitri) Date: Tue Mar 26 04:28:01 2002 Subject: The key size warning Message-ID: <20020326032520.GC3916@mars.networkfab.com> --NKoe5XOeduwbEQHU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, All: In light of http://online.securityfocus.com/archive/1/263924 GnuPG probably should remove the confirmation/warning message, and change the suggested key size: $ gpg --gen-key gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc. [...] Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) Your selection?=20 DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits <=3D=3D=3D=3D=3D=3D=3D=3D HERE = =3D=3D highest suggested keysize is 2048 bits What keysize do you want? (1024) 2048 Do you really need such a large keysize? yes <=3D=3D=3D=3D=3D=3D=3D=3D HER= E =3D=3D Requested keysize is 2048 bits =20 [...] Unless, of course, the abovementioned email is not correct... Cheers Dmitri --=20 A Windows user spends 1/3 his life sleeping, 1/3 working, 1/3 waiting. --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8n+ogXksyLpO6T4IRAn6iAJ9H1W8tgTdbt9BrZGLsEhdn4sMvIACfUdSZ BNuY9pUiF6TEKtlj91A7mMk= =wE+Y -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU-- From wk@gnupg.org Tue Mar 26 08:48:02 2002 From: wk@gnupg.org (Werner Koch) Date: Tue Mar 26 08:48:02 2002 Subject: The key size warning In-Reply-To: <20020326032520.GC3916@mars.networkfab.com> (Dmitri's message of "Mon, 25 Mar 2002 19:25:20 -0800") References: <20020326032520.GC3916@mars.networkfab.com> Message-ID: <878z8fbwmb.fsf@alberti.gnupg.de> On Mon, 25 Mar 2002 19:25:20 -0800, Dmitri said: > In light of http://online.securityfocus.com/archive/1/263924 > GnuPG probably should remove the confirmation/warning message, and This is probably Lucky Green's announcement - don't forget to read also Ian Goldberg's reply. No need to change the suggested keysize, remember that you should make the weakest link stronger to get better protection and not one of the ver bold ones. Already updated the latest zlib, fixed the ssh bug of the month, audited the GnuPG code, installed a stronger lock at your door, did a security check of all your friends? Werner From rabbi@quickie.net Tue Mar 26 08:59:02 2002 From: rabbi@quickie.net (Len Sassaman) Date: Tue Mar 26 08:59:02 2002 Subject: The key size warning In-Reply-To: <878z8fbwmb.fsf@alberti.gnupg.de> Message-ID: On Tue, 26 Mar 2002, Werner Koch wrote: > This is probably Lucky Green's announcement - don't forget to read > also Ian Goldberg's reply. No need to change the suggested keysize, I have to disagree with you, Werner. The current warning appears to discourage users from generating 2048 bit and greater keys. There's really no necessity for doing so. I also think that 768 bit keys shouldn't be permitted to be generated. From rjhansen@inav.net Tue Mar 26 09:36:02 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Tue Mar 26 09:36:02 2002 Subject: The key size warning In-Reply-To: References: Message-ID: <1017131690.23435.32.camel@numbers.robnet.net> > I have to disagree with you, Werner. The current warning appears to > discourage users from generating 2048 bit and greater keys. There's really > no necessity for doing so. I'm with Len on this one. Frankly, given that generating and using 2048-bit keys on modern hardware is no more taxing than generating and using 1024-bit keys five years ago, I think it's entirely appropriate to change the default keysize as a way of buying us a little extra security from any further unexpected surprises. > I also think that 768 bit keys shouldn't be permitted to be generated. Here I disagree--it's possible that there are circumstances or conditions in which moving up to 2k keys is not possible. One company I worked at had code which was hardcoded to require 768-bit keys. There are legacy and just plain badly-designed systems out there, and we should permit keys to be generated which will interoperate with them. 768-bit keys should, IMO, flag a warning about "This key is far below the recommended keysize". But that's it. From wk@gnupg.org Tue Mar 26 11:08:01 2002 From: wk@gnupg.org (Werner Koch) Date: Tue Mar 26 11:08:01 2002 Subject: The key size warning In-Reply-To: (Len Sassaman's message of "Mon, 25 Mar 2002 23:56:52 -0800 (PST)") References: Message-ID: <87zo0vabl8.fsf@alberti.gnupg.de> On Mon, 25 Mar 2002 23:56:52 -0800 (PST), Len Sassaman said: > I have to disagree with you, Werner. The current warning appears to > discourage users from generating 2048 bit and greater keys. There's really I will remove the warning for keys > 1536. > I also think that 768 bit keys shouldn't be permitted to be generated. 1024 is already the minimum for RSA: else if( algo == PUBKEY_ALGO_RSA && nbits < 1024 ) tty_printf(_("keysize too small;" " 1024 is smallest value allowed for RSA.\n")); Werner From d1234hill11@comcast.net Tue Mar 26 13:09:02 2002 From: d1234hill11@comcast.net (d1234hill11@comcast.net) Date: Tue Mar 26 13:09:02 2002 Subject: Space-padded lines in crypt-text Message-ID: <002501c1d4be$e3ac9e20$6401a8c0@norr1.pa.home.com> David, Sounds great - any possibility you could point me to a Win32 Binary? FYI, Roger Sonderman has made GPGShell handle this case as well. Dave > > FYI, after some discussion with Werner, and in the interests of "be > liberal in what you accept, conservative in what you generate", I > changed the code in GnuPG 1.0.7 to permit extra spaces on the armor > header lines. The --openpgp flag makes this strict again. > > David > From max@quendi.de Tue Mar 26 13:44:01 2002 From: max@quendi.de (Max Horn) Date: Tue Mar 26 13:44:01 2002 Subject: Patch to make GPGME 0.3.4 compile on OS X Message-ID: diff -ru gpgme-0.3.4/gpgme/util.h gpgme-0.3.4-patched/gpgme/util.h --- gpgme-0.3.4/gpgme/util.h Wed Feb 13 14:41:18 2002 +++ gpgme-0.3.4-patched/gpgme/util.h Tue Mar 26 13:18:29 2002 @@ -139,7 +139,7 @@ ssize_t (*read)(void*,char*,size_t); ssize_t (*write)(void*,const char*,size_t); int (*seek)(void*,off_t*,int); - int (*close)(coid*); + int (*close)(void*); } _IO_cookie_io_functions_t; typedef _IO_cookie_io_functions_t cookie_io_functions_t; FILE *fopencookie (void *cookie, const char *opentype, *cough* a little bit embarrassing to have this in a release, isn't it? =) Well, I am happy I am not the only one to whom such misfortunes happen, Thanks for your work, Max -- ----------------------------------------------- Max Horn Software Developer email: phone: (+49) 6151-494890 From wk@gnupg.org Tue Mar 26 14:44:02 2002 From: wk@gnupg.org (Werner Koch) Date: Tue Mar 26 14:44:02 2002 Subject: Patch to make GPGME 0.3.4 compile on OS X In-Reply-To: (Max Horn's message of "Tue, 26 Mar 2002 13:42:38 +0100") References: Message-ID: <87y9gf8mzm.fsf@alberti.gnupg.de> On Tue, 26 Mar 2002 13:42:38 +0100, Max Horn said: > *cough* a little bit embarrassing to have this in a release, isn't > it? =) Well, I am happy I am not the only one to whom such misfortunes It has already been fixed. However we are developing using GNU systems so we can't easily spot errors in replacement code. Werner From marcus@gnu.org Tue Mar 26 14:59:01 2002 From: marcus@gnu.org (Marcus Brinkmann) Date: Tue Mar 26 14:59:01 2002 Subject: Patch to make GPGME 0.3.4 compile on OS X In-Reply-To: References: Message-ID: <20020326135713.GE25196@gnu.org> On Tue, Mar 26, 2002 at 01:42:38PM +0100, Max Horn wrote: > - int (*close)(coid*); > + int (*close)(void*); Thanks for reporting it. This is already fixed in CVS. > *cough* a little bit embarrassing to have this in a release, isn't > it? =) Well, I am happy I am not the only one to whom such > misfortunes happen, Well, the 0.3.1 release was worse ;) The above typo only shows up on non-GNU systems. Thanks, Marcus From alfons@proteus.demon.nl Tue Mar 26 22:42:01 2002 From: alfons@proteus.demon.nl (Alfons Hoogervorst) Date: Tue Mar 26 22:42:01 2002 Subject: [Sylpheed-claws-users] Good News In-Reply-To: <20020326222803.017208a6.ml-lists@macbyte.info> References: <20020326222803.017208a6.ml-lists@macbyte.info> Message-ID: <20020326221906.46103415.alfons@proteus.demon.nl> Lo Michael, On Tue, 26 Mar 2002 22:28:03 +0100 Michael Raab wrote: | i have today read on the WebSite http://www.gnupp.de/software.html | that Sylpheed becomes support for GNUPG from the german Goverment | BMWi. This is really great news, any comments from the GnuPG guys? Bye. PS. When responding, please at least include sylpheed@good-day.net, which is the official Sylpheed ML. Thanks. -- Ecuación algebraico sin solución posible, a menos de poseer profundos conocimientos en matemática - Revueltas (Ocho Por Radio) From mwy-gpg41@the-youngs.org Wed Mar 27 00:36:01 2002 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Wed Mar 27 00:36:01 2002 Subject: The key size warning References: Message-ID: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: "Robert J. Hansen" > > 768-bit keys should, IMO, flag a warning about "This key is far below > the recommended keysize". But that's it. I agree. If I *really* want a smaller key, despite the warning, why should it be GnuPG's job to prevent me? I can buy the argument that some programs should protect the incurably stupid, but GnuPG is just chock-full of options that can be horribly misused already. A protectionist policy seems out of place. I have a relatively short key for low-value material I may keep on my Palm device. I'm willing to let someone spend $1B (or even $1M) if they really want this material, but I'm not willing to wait minutes to get my data. (Some perhaps, but not all.) I actually have a 384-bit key that I've used as an MDC. (It won't cost you very much to break this. Heck, for $1, I'll give you the secret key myself. :-) You could argue that I should use a new key that gets automatic MDC treatment, or force GnuPG to use an MDC, but sometimes I need to use a pre-MDC product. So, I sign with a ridiculously short key. I'd have generated an even shorter one, but this was the lower limit for PGP2.6. No, not everybody needs to do these things. But should I really have to dig up an antique product or roll my own key generator if this is what I really want to do? -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPKEEQFMkvpTT8vCGEQISRACdFGmLj0n66njq6C7EYz+2ttDxOIoAoJqT c6rq6L099BiKVLu5zKlDeC66 =wTxj -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Wed Mar 27 01:15:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Mar 27 01:15:02 2002 Subject: The key size warning In-Reply-To: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> References: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> Message-ID: <20020327001240.GF1419@akamai.com> On Tue, Mar 26, 2002 at 06:31:41PM -0500, Michael Young wrote: > > From: "Robert J. Hansen" > > > > 768-bit keys should, IMO, flag a warning about "This key is far below > > the recommended keysize". But that's it. > > I agree. If I *really* want a smaller key, despite the warning, > why should it be GnuPG's job to prevent me? I can buy the > argument that some programs should protect the incurably stupid, > but GnuPG is just chock-full of options that can be horribly misused > already. A protectionist policy seems out of place. I agree that if a user wants to do something stupid, they should be allowed to (with appropriate warnings). Still, it's in the OpenPGP spec that applications shouldn't generate keys smaller than 768 bits. It's a SHOULD, and not a MUST, but it's there. I'd say disallow it unless the user sets the --expert flag. By setting that, the user is swearing they won't blame GnuPG for not protecting them :) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From JanuszA.Urbanowicz Wed Mar 27 16:05:01 2002 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Wed Mar 27 16:05:01 2002 Subject: The key size warning In-Reply-To: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> from Michael Young at "Mar 26, 2002 06:31:41 pm" Message-ID: Michael Young wrote/napisa=B3[a]/schrieb: -- Start of PGP signed section. > > From: "Robert J. Hansen" > > > > 768-bit keys should, IMO, flag a warning about "This key is far below > > the recommended keysize". But that's it. >=20 > I agree. If I *really* want a smaller key, despite the warning, > why should it be GnuPG's job to prevent me? I can buy the > argument that some programs should protect the incurably stupid, > but GnuPG is just chock-full of options that can be horribly misused > already. A protectionist policy seems out of place. I have to disagree. It depends on who you are protecting. If you are dealing with people who can do a realistic risk assessment. But as long as we aim for getting PGP/GPG more popular, it means that people who are unable to do so (casual users) will use the software. Thus the software should take precautions to protect them, by assuming reasonably secure defaults, and with protecting them from doing stupid mistakes. While I don't like adding YA commandline option to gpg, a option --expert-mode allowing to do 'stupid things' seems reasonable in the context. Alex --=20 C _-=3D-_ H| Janusz A. Urbanowicz | ALEX3-RIPE | SF-F Framling | | = * =09 ; (_O : +-------------------------------------------------------------+ --= +~|=09 ! &~) ? | P=B3yn=B1=E6 chc=EA na Wsch=F3d, za Suez, gdzie jest dobrem ka= =BFde z=B3o | l_|/=09 A ~-=3D-~ O| Gdzie przykaza=F1 brak dziesi=EAciu, a pi=E6 mo=BFna a=BF po d= no; | | =20 From dshaw@jabberwocky.com Wed Mar 27 17:22:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Mar 27 17:22:02 2002 Subject: The key size warning In-Reply-To: References: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> Message-ID: <20020327161908.GC20745@akamai.com> On Wed, Mar 27, 2002 at 03:50:13PM +0100, Janusz A. Urbanowicz wrote: > Michael Young wrote/napisa?[a]/schrieb: > -- Start of PGP signed section. > > > From: "Robert J. Hansen" > > > > > > 768-bit keys should, IMO, flag a warning about "This key is far below > > > the recommended keysize". But that's it. > > > > I agree. If I *really* want a smaller key, despite the warning, > > why should it be GnuPG's job to prevent me? I can buy the > > argument that some programs should protect the incurably stupid, > > but GnuPG is just chock-full of options that can be horribly misused > > already. A protectionist policy seems out of place. > > I have to disagree. > > It depends on who you are protecting. If you are dealing with people who can > do a realistic risk assessment. But as long as we aim for getting PGP/GPG > more popular, it means that people who are unable to do so (casual users) > will use the software. Thus the software should take precautions to protect > them, by assuming reasonably secure defaults, and with protecting them from > doing stupid mistakes. > > While I don't like adding YA commandline option to gpg, a option > --expert-mode allowing to do 'stupid things' seems reasonable in the > context. There is already an --expert in 1.0.7. It controls whether a user is allowed to sign a revoked key, sign a revoked uid, sign an expired key, add multiple photo IDs to a key and add a photo ID to a PGP 2.x-style key. All things that probably shouldn't happen unless the user knows what they are doing. It seems reasonable to use it for allowing really small keysizes as well. In any case, the RFC discourages ("SHOULD NOT") sizes smaller than 768. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From JanuszA.Urbanowicz Wed Mar 27 19:02:01 2002 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Wed Mar 27 19:02:01 2002 Subject: How to make invalid OpenPGP packets with GNUPG (a bugreport). Message-ID: Hash: SHA1 The method is simple (at least for me): - - write text in text editor (joe) - - mark the whole text as a block - - pipe the block though GnuPG for signing with a signing v4 subkey and for encryption for untrusted v3 RSA key. (gpg -sea -r for my setup) - - answer yes when asked if you really want to use that key The resulting OpenPGP message will make all tested PGP (and GPG) versions barf with the following message: gpg: packet(1) too short gpg: block_filter 0x80fdd48: read error (size=3D8763,a->size=3D36031) gpg: block_filter: pending bytes! The effect is repeatable. Alex - --=20 C _-=3D-_ H| Janusz A. Urbanowicz | ALEX3-RIPE | SF-F Framling | | = * =09 ; (_O : +-------------------------------------------------------------+ --= +~|=09 ! &~) ? | P=B3yn=B1=E6 chc=EA na Wsch=F3d, za Suez, gdzie jest dobrem ka= =BFde z=B3o | l_|/=09 A ~-=3D-~ O| Gdzie przykaza=F1 brak dziesi=EAciu, a pi=E6 mo=BFna a=BF po d= no; | | =20 From rra@stanford.edu Wed Mar 27 23:54:02 2002 From: rra@stanford.edu (Russ Allbery) Date: Wed Mar 27 23:54:02 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG Message-ID: (I'm not a member of this mailing list, so please cc me on any replies.) Hello folks, I'm working on putting in place more standard procedures and control message handling for the gnu.* Usenet hierarchy. Currently, Usenet control messages are verified using PGP signatures and a Usenet-specific protocol for including that signature in the headers. Nearly everyone verifying control messages is currently using PGP 2.6.2 or some varient thereof, and all current control message signatures are done with RSA keys. For the gnu.* hierarchy, we'd obviously prefer to use GnuPG for all stages of the process rather than using PGP (which is not free software). I see that generation of RSA keys for signing only has been added to the latest GnuPG development snapshots. However, when I generate a key with: gpg --gen-key --pgp2 and then export the public key with either of: gpg --pgp2 --export gnu.gnusenet.announce > gnu.key gpg --pgp2 --armor --export gnu.gnusenet.announce > ! gnu.key running the command: pgp -ka gnu.key using PGP 2.6.2 (like most Usenet administrators currently are) results in the error message: No keys found in 'gnu.key'. Keyring add error. The output of gpg --list-packets is as follows: windlord:~> gpg --list-packets gnu.key :public key packet: version 4, algo 1, created 1017268539, expires 0 pkey[0]: [1024 bits] pkey[1]: [6 bits] :user ID packet: "gnu.gnusenet.announce" :signature packet: algo 1, keyid DC39A12336D978BB version 4, created 1017268539, md5len 0, sigclass 13 digest algo 2, begin of digest 2e 40 hashed subpkt 2 len 5 (sig created 2002-03-27) hashed subpkt 27 len 2 (key flags: 03) hashed subpkt 11 len 6 (pref-sym-algos: 7 10 3 4 2) hashed subpkt 21 len 3 (pref-hash-algos: 3 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 1) hashed subpkt 30 len 2 (features: 01) hashed subpkt 23 len 2 (key server preferences: 80) subpkt 16 len 9 (issuer key ID DC39A12336D978BB) data: [1023 bits] If I understand the issues correctly (and it's quite likely that I don't), those "version 4" notes in the packet are a bad sign for compatibility with PGP 2.6.2. First question: Is this something that's supposed to be working already and I'm just doing something wrong? Second question: If this isn't already implemented, are there plans to implement it, or is there some other way that I can approach this problem? I know I can create the initial key using PGP 2.6.2 and then import it into GnuPG and the resulting signatures can be verified using PGP 2.6.2, but I'd rather not do that if there's an alternative. Thank you very much for any help! -- Russ Allbery (rra@stanford.edu) From rabbi@quickie.net Thu Mar 28 00:20:01 2002 From: rabbi@quickie.net (Len Sassaman) Date: Thu Mar 28 00:20:01 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG In-Reply-To: Message-ID: On Wed, 27 Mar 2002, Russ Allbery wrote: > For the gnu.* hierarchy, we'd obviously prefer to use GnuPG for all stages > of the process rather than using PGP (which is not free software). I see PGP 2.3 was GPL'd. There might be forks of that floating around somewhere that still bear the GPL, if that will serve your purpose. (2.3 proper won't work, because it uses v2 keys.) > If I understand the issues correctly (and it's quite likely that I don't), > those "version 4" notes in the packet are a bad sign for compatibility > with PGP 2.6.2. Yes; PGP 2.6.2 used a different key format, version 3, which had a number of problems with it. The IETF created a new, improved key format to address a number of these issues. OpenPGP compliant apps all use v4. > First question: Is this something that's supposed to be working already > and I'm just doing something wrong? Nope -- GnuPG has partial v3 key support, but does not generate them. > Second question: If this isn't already implemented, are there plans to > implement it, To my knowledge, there are no plans to implement it, because encouraging the creation of more v3 keys isn't really the best thing to be doing. > or is there some other way that I can approach this problem? Have everyone upgrade to an OpenPGP compliant application, like GnuPG or PGP 6.5.8/7.x Other than your suggestion below, not really. There are some utilities out there that will convert a v4 RSA key to a v3 key, but I don't know how stable they are. --Len. From wk@gnupg.org Thu Mar 28 10:02:02 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 28 10:02:02 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG In-Reply-To: (Russ Allbery's message of "Wed, 27 Mar 2002 14:51:57 -0800") References: Message-ID: <87k7rxrruj.fsf@alberti.gnupg.de> On Wed, 27 Mar 2002 14:51:57 -0800, Russ Allbery said: > gpg --gen-key --pgp2 GnuPG does not create the old v3 keys used with PGP2. There are good reasons not to support the old format any longer; it has some minor flaws. GnuPG can use these v3 keys without any problems, though. I'd suggest that you either create the key using PGP2, continue to use an old one or send private mail to discuss whether I can provide an inofficial patch for this. We should add a warning that --pgp2 has no effect on key creation. Werner From disastry@saiknes.lv Thu Mar 28 13:14:01 2002 From: disastry@saiknes.lv (disastry@saiknes.lv) Date: Thu Mar 28 13:14:01 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG Message-ID: <3CA308A5.2A1156A0@saiknes.lv> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Russ Allbery rra@stanford.edu wrote: > If I understand the issues correctly (and it's quite likely that I don't), > those "version 4" notes in the packet are a bad sign for compatibility > with PGP 2.6.2. yes > First question: Is this something that's supposed to be working already > and I'm just doing something wrong? no, but it's very easy to patch gpg so that it can generate RSAv3 keys patch available here: http://disastry.dhs.org/pgp/gpg/gnupg-1.0.6d-keygen.diff With patched GPG to generate RSAv3 key: gpg --expert --pgp2 --gen-key This patch also enables to generate RSA v4 sign+encrypt key as single key. Such keys are not recommended, it's better to generate RSA v4 sign-only key and then generate RSA v4 encrypt-only subkey for it. Anyway: to generate RSA v4 sign+encrypt key: gpg --expert --gen-key > Second question: If this isn't already implemented, are there plans to > implement it, or is there some other way that I can approach this problem? I believe users should be able to generate v3 keys in --expert mode, but I don't think that Werner will apply this patch to official release... :( __ Disastry http://disastry.dhs.org/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPKLsYDBaTVEuJQxkEQPPoQCg6n++keIu+qF15ETDYlLRnYN28bIAoK9r ifmdx4kLrRbKgB3rlaG0vsT+ =uxZW -----END PGP SIGNATURE----- From mwy-gpg41@the-youngs.org Thu Mar 28 20:41:02 2002 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Thu Mar 28 20:41:02 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG References: Message-ID: <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Werner Koch > GnuPG does not create the old v3 keys used with PGP2. There are good > reasons not to support the old format any longer; it has some minor > flaws. GnuPG can use these v3 keys without any problems, though. The flaws are not in the key itself. They're in the fingerprint and keyId computations that get used for identification. You don't *have* to use these forms of identification in order to use the key. As Len noted, you can convert a V4 RSA key to a V3 key (or vice versa). Lookups won't work, and signatures binding that key to names (even the self-signature) won't be valid. But signatures made *by* the key, or material encrypted to the key will be perfectly usable. [Also, note that generating a V4 key and converting to V3 doesn't address the root problem; it's just a workaround.] > I'd suggest that you either create the key using PGP2, continue to use > an old one or send private mail to discuss whether I can provide an > inofficial patch for this. Here, the user appears willing to live with the identification issue. Others are using PGP2.6 anyway, so they already have to be (or should be) careful with identification. Their key distribution and verification may not depend on keyId or fingerprint behavior. If someone is willing to make an patch for it, I would plead for making it official. I would not make it easy -- a separate switch ("--gen-v3-key") and requiring the "--expert" switch seems reasonable. If I thought there were only one user looking for this, an unofficial patch would make more sense to me. I've seen questions here and in newsgroups that suggest that this is not a unique desire. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPKNwp1MkvpTT8vCGEQJ/DwCgvn4wSCa6NqfFECU69Z0g3vwCHfsAn3rV puxSxGteUvVNiUCB7OSsZR1N =ZuJI -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Thu Mar 28 22:32:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Thu Mar 28 22:32:01 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG In-Reply-To: <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> References: <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> Message-ID: <20020328212930.GB2019@akamai.com> On Thu, Mar 28, 2002 at 02:36:38PM -0500, Michael Young wrote: > > From: Werner Koch > > I'd suggest that you either create the key using PGP2, continue to use > > an old one or send private mail to discuss whether I can provide an > > inofficial patch for this. > > Here, the user appears willing to live with the identification issue. > Others are using PGP2.6 anyway, so they already have to be (or should > be) careful with identification. Their key distribution and > verification may not depend on keyId or fingerprint behavior. > > If someone is willing to make an patch for it, I would plead for > making it official. I would not make it easy -- a separate switch > ("--gen-v3-key") and requiring the "--expert" switch seems reasonable. I'm on the fence with this. I've seen enough requests for it that I'm fairly sure that a suitably buried (--expert & --pgp2 & warning) v3 key generation would be useful. That's the whole idea of --expert anyway: to enable doing silly/broken/incompatible things that only people who know what they are doing should do. The fact that it would be "useful" is also what worries me... The code change itself is pretty trivial - there would be more code added to print suitably lurid warning messages than there would be added to support generating v3 keys :) With regards to using v3 keys on Usenet control messages, while I think that v3 keys were deprecated for many good reasons, I have some experience with this usage and it's one of the few things I'd be content using v3 keys for. There is such a large installed base of (sometimes half-forgotten) news servers still running PGP 2 that it's safe to say that upgrading any time soon is just not in the cards. Russ, what I'd ask you to do is to send each gnu.* control message twice - each signed with a different (one v3, one v4) key. At least then Usenet can start on the path of using v4 keys. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From md@Linux.IT Fri Mar 29 02:09:02 2002 From: md@Linux.IT (Marco d'Itri) Date: Fri Mar 29 02:09:02 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG In-Reply-To: <20020328212930.GB2019@akamai.com> References: <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> <20020328212930.GB2019@akamai.com> Message-ID: <20020329005631.GA12250@wonderland.linux.it> On Mar 28, David Shaw wrote: >Russ, what I'd ask you to do is to send each gnu.* control message >twice - each signed with a different (one v3, one v4) key. At least >then Usenet can start on the path of using v4 keys. If we want to be incompatible then let's just use DSS. -- ciao, Marco From Enzo Michelangeli" <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> <20020328212930.GB2019@akamai.com> <20020329005631.GA12250@wonderland.linux.it> Message-ID: <00c501c1d6cd$fbe345a0$0200000a@noip.com> But DSS is limited to 1024 bit, the strength of which may not be taken for granted anymore considering recent developments. If we have to be incompatible, let's do it planning ahead, or else in a few years we'll have to change again. Enzo ----- Original Message ----- From: "Marco d'Itri" To: Sent: Friday, 29 March, 2002 8:56 AM Subject: Re: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG > On Mar 28, David Shaw wrote: > > >Russ, what I'd ask you to do is to send each gnu.* control message > >twice - each signed with a different (one v3, one v4) key. At least > >then Usenet can start on the path of using v4 keys. > If we want to be incompatible then let's just use DSS. > > -- > ciao, > Marco > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From jsogo@debian.org Fri Mar 29 18:41:01 2002 From: jsogo@debian.org (Jose Carlos Garcia Sogo) Date: Fri Mar 29 18:41:01 2002 Subject: [GPGME] Problem with info doc Message-ID: <20020329173858.GB16122@jaimedelamo.eu.org> tag 139631 patch pending thanks I have a little problem with the info doc that comes with GPGPME in the Debian package. I think the patch explains all :) If you want to see which the problem is, look at bug #139631 I won't make a new upload only for this little bug. It's a pity I hadn't time to look at it before uploading the last one in order to move it from non-US to main. Thanks! Jose Carlos Garcia Sogo jsogo@debian.org ---------------------------------------------------------- diff -u -r1.28 gpgme.texi --- doc/gpgme.texi 2002/03/18 00:01:51 1.28 +++ doc/gpgme.texi 2002/03/29 17:31:00 @@ -4,7 +4,7 @@ @dircategory GNU Libraries @direntry -* @acronym{GPGME}: (gpgme) Adding support for cryptography to your program. +* @acronym{GPGME}: (gpgme). Adding support for cryptography to your program. @end direntry @include version.texi From Marcus.Brinkmann@ruhr-uni-bochum.de Fri Mar 29 22:05:02 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Mar 29 22:05:02 2002 Subject: [GPGME] Problem with info doc In-Reply-To: <20020329173858.GB16122@jaimedelamo.eu.org> References: <20020329173858.GB16122@jaimedelamo.eu.org> Message-ID: <20020329210242.GD921@212.23.136.22> On Fri, Mar 29, 2002 at 06:38:58PM +0100, Jose Carlos Garcia Sogo wrote: > I have a little problem with the info doc that comes with GPGPME in the > Debian package. I think the patch explains all :) > If you want to see which the problem is, look at bug #139631 Thanks, I have checked in your change into CVS, but kept the start of the description at column 28, so it aligns with other entries. Thanks you for reporting it. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de From vab@cryptnet.net Sat Mar 30 05:09:02 2002 From: vab@cryptnet.net (V Alex Brennen) Date: Sat Mar 30 05:09:02 2002 Subject: The key size warning In-Reply-To: <1017131690.23435.32.camel@numbers.robnet.net> Message-ID: On 26 Mar 2002, Robert J. Hansen wrote: > > I have to disagree with you, Werner. The current warning appears to > > discourage users from generating 2048 bit and greater keys. There's really > > no necessity for doing so. > > I'm with Len on this one. Frankly, given that generating and using > 2048-bit keys on modern hardware is no more taxing than generating and > using 1024-bit keys five years ago, I think it's entirely appropriate to > change the default keysize as a way of buying us a little extra security > from any further unexpected surprises. 2048bits is good, but be careful about just bumping up keysize. There is much more to it than just the CPU time the math takes. Is there enough entropy available on the average PC to support the generation of strong default 2048bit keys? Yes, most likely. 4096bits? Yes, most likely. 8192bits? Probably. But, at what keysize does that become usually not the case? I recall reading predictions of 4GB (~32Gb) keys to ensure some strength in the presence of quantum computers. I'm unsure that the average PC could generate strong 4GB keys. Does anyone know of any research that has been done into this - what the average period is over a large sample of systems for data from /dev/random or /dev/urandom on GNU/Linux? Obviously, this is especially important in the case of SSL or something else with needs for lots of session keys - not to mention the problem of DoS attacks against pseudorandom devices on such systems through mass session initiations which yield entropy depletion. - VAB From dmitri@users.sourceforge.net Sat Mar 30 06:14:02 2002 From: dmitri@users.sourceforge.net (Dmitri) Date: Sat Mar 30 06:14:02 2002 Subject: The key size warning In-Reply-To: References: Message-ID: <1017465102.24746.96.camel@usb.networkfab.com> --=-ttA+cr1EcDY3oG2NYn8I Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-03-29 at 19:59, V Alex Brennen wrote: > 2048bits is good, but be careful about just bumping up keysize. > There is much more to it than just the CPU time the math takes. >=20 > Is there enough entropy available on the average PC to support the=20 > generation of strong default 2048bit keys? Yes, most likely.=20 > 4096bits? Yes, most likely. 8192bits? Probably. But, at what > keysize does that become usually not the case? Entropy is not in short supply :-) On key sizes that you mention, probably the user will need to wiggle the mouse couple of times. For megabit-sized keys, the user will need to play a game or two in Unreal Tournament. For gigabit-sized keys he will need a local source of randomness, something like a PCI card with a white noise generator and the necessary A-D converter. The RF noise from the sky is quite random as well - a stream of samples from Seti@Home will do just fine :-) A popular idea, since "Johnny Mnemonic" the movie, is to use broadcast TV as source of randomness. This is especially useful because the MPEG-2 compressed stream is very random (since this is the point of compression). Anyone with HDTV receiver already has *gigabits* of randomness, just strip the MPEG framing, since it is regular. > I recall reading predictions of 4GB (~32Gb) keys to ensure some=20 > strength in the presence of quantum computers. I'm unsure that=20 > the average PC could generate strong 4GB keys. Probably not. How would you publish them? :-) Dmitri --=-ttA+cr1EcDY3oG2NYn8I Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8pUkOXksyLpO6T4IRAkp9AKCIkFZAqub7LkzMjumcyVbQPuJuYgCgi4kX /k69E2kW36ROPwQn8uBMuW0= =EF4q -----END PGP SIGNATURE----- --=-ttA+cr1EcDY3oG2NYn8I-- From Enzo Michelangeli" <1017465102.24746.96.camel@usb.networkfab.com> Message-ID: <012901c1d7c3$5da56700$0200000a@noip.com> ----- Original Message ----- From: "Dmitri" To: Sent: Saturday, 30 March, 2002 1:11 PM Subject: Re: The key size warning [...] > A popular idea, since "Johnny Mnemonic" the movie, is to use broadcast > TV as source of randomness. This is especially useful because the MPEG-2 > compressed stream is very random (since this is the point of > compression). Anyone with HDTV receiver already has *gigabits* of > randomness, just strip the MPEG framing, since it is regular. A random stream that can be eavesdropped by an attacker (as it's surely the case with digital broadcasts) is useless for cryptographic purposes. Don't trust architectural designs from sci-fi movies, especially those where smuggling data requires a chip implanted in Keanu Reeves' brain :-) > > I recall reading predictions of 4GB (~32Gb) keys to ensure some > > strength in the presence of quantum computers. I'm unsure that > > the average PC could generate strong 4GB keys. > > Probably not. How would you publish them? :-) Besides, those predictions sounds pretty meaningless. Quantum computers, when/if built, would break current public key cryptosystems because quantum algorithms of polynomial complexity have been found for the underlying problems (factorization and discrete logarithm). I don't see how that could be fixed by using huge keys. Enzo From dmitri@users.sourceforge.net Sun Mar 31 12:41:01 2002 From: dmitri@users.sourceforge.net (Dmitri) Date: Sun Mar 31 11:41:01 2002 Subject: The key size warning In-Reply-To: <012901c1d7c3$5da56700$0200000a@noip.com> References: <1017465102.24746.96.camel@usb.networkfab.com> <012901c1d7c3$5da56700$0200000a@noip.com> Message-ID: <1017567512.1312.84.camel@usb.networkfab.com> --=-lsyfUr0FeD0ECRvbuRHA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2002-03-30 at 00:17, Enzo Michelangeli wrote: > [...] > > A popular idea, since "Johnny Mnemonic" the movie, is to use broadcast > > TV as source of randomness. >=20 > A random stream that can be eavesdropped by an attacker (as it's surely t= he > case with digital broadcasts) is useless for cryptographic purposes. Though you certainly have a point, the TV bitstream is quite random in a sense that the opponent does not know at what point in time you grab a bit of it, and from what channel. Let's assume that there is only one HDTV channel, with 1 Mbps stream. Let's also assume that the attacker records this stream and timestamps it. Also we have to assume some window of stream capture - for example, 1 hour (which is too small, something like weeks would be more practical). Within 1 hour (3600 seconds) you can choose any moment (any bit) in time to start capturing the HDTV signal. This is the random event (not the data itself), and you have 1e6*3600 =3D 3.6e9 possible choices. The event that actually happens (one of those billions) can produce from 1 bit to as many as you want, but if you take more than one bit then the second and later bits are related to each other (as recorded by attacker). If you take only one bit then the case is simple - the data is random simply because you take the bits at random moments, defined only by your own physical actions. It is similar to throwing a coin. The attacker knows that you may stumble upon 0 or 1, but he has no way of knowing which one you in fact took (aside from Tempest attack). More interesting case is when you take more than one bit. Then the bits are related to each other, and the relationship is known to the attacker. Whether you take one bit or one gigabit (within the known hour), the moment you start the capture is absolutely random. The probability that your key starts with k[i] where i E [0..3.6e9-1] is the same, namely 1/3.6e9 =3D 2.8e-10. But the trick is that if you take _as many bits as you want_ from the HDTV datastream, this does not increase the strength of the key - the attacker still has to go through the same 3.6e9 possible cases to recover the exact same bitstream that you had. This is the problem. What this all means is simple. The randomness of the captured data decreases as you capture more and more data, and as your "capturing time frame" becomes more known. In worst case, if you captured the entire HDTV stream of your local PBS station from the moment it was built to the monent the meteor hit and destroyed it, the probability of the recovery of the stream is exactly 1 (a certainty). Therefore, each user-initiated capture event (in the scenario above) gives you one outcome out of 3.6e9 possibilities. This is more than a standard dice can offer (one possible outcome out of 6). In binary terms, one throw of a coin gives you 1 random bit; one throw of a 6-sided dice will result in 2.5 bits; one reading from the TV receiver gives you about 32 bits. The fact that the attacker knows your alphabet (list of choices) is not a danger because the attacker also knows how coins fall, and how a dice can possibly roll. What the attacker does not know is *how exactly* the dice fell, and *what channel and when* you switched to. The amount of entropy you get translates into the dictionary entries that you use as your random output. The coin's heads can be translated into 0, and tails - into 1. But you must not translate it into "000" and "111". If you capture from the HDTV, you can grab up to 32 bits of the stream, and even if the attacker knows the entire stream, he will need to try all 3.6e9 combinations to get to the same 32-bit segment; there is no other way to reconstruct it; he can as well just try all 32-bit numbers, without even accessing the recorded TV stream. However if you *exceed* the entropy of your random event and take more than 32 bits (in this scenario!) then the attacker will be better off trying the recorded TV stream. For example, if you take 100 bits instead of 32, then the attack on the key itself will take 1.3e30 tries, but the attack on the HDTV stream will cost only the same 3.6e9 attempts - a big difference! All this means that one *can* use the HDTV streams as source of randomness, but one have to understand exactly how much entropy one event produces, and then to manually generate the necessary number of events to make enough of random bits. If there are many channels, and if there is a longer window of capture, then the amount of entropy per capture increases. The exact calculation is not easy because there are other factors involved (such as correlation between user-initiated events). In any case, one can always point a digital camcorder to a HDTV screen, tune to a football game, and the output of the camcorder is likely to be very random (reencoded), and unavailable to any attacker since it is not stored anywhere. Thanks, Dmitri --=-lsyfUr0FeD0ECRvbuRHA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8ptkYXksyLpO6T4IRAjieAJ94jD3uJF7Kq6FVmy1NXm5E2KF3kgCfTPIt KfQMWmgU5kc1Xq2Skv2Re84= =zKg8 -----END PGP SIGNATURE----- --=-lsyfUr0FeD0ECRvbuRHA-- From dshaw@jabberwocky.com Fri Mar 1 02:58:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Fri Mar 1 02:58:01 2002 Subject: Designated revoker Message-ID: <20020301015514.GB677@akamai.com> Hi folks, I committed read-side support for designated revokers in GnuPG today. It will now accept designated revoker packets on keys, and accept revocations from the designated revoker to revoke the key. It does not (yet) allow a user to set a designated revoker on their own key or allow the designated revoker to issue a revocation. Anyway, it's a reasonably fussy change, so if anyone is using the CVS version and has some keys with designated revokers on them, I'd be grateful if you'd poke at it and try to break it. Thanks :) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From wk@gnupg.org Fri Mar 1 18:31:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 1 18:31:01 2002 Subject: Key version games (was Re: problem with exporting subkeys) In-Reply-To: <20020228135159.GD678@akamai.com> (David Shaw's message of "Thu, 28 Feb 2002 08:51:59 -0500") References: <3C7E0B5D.25D67550@saiknes.lv.NO.SPaM.NET> <20020228135159.GD678@akamai.com> Message-ID: <87k7swpnyl.fsf@alberti.gnupg.de> On Thu, 28 Feb 2002 08:51:59 -0500, David Shaw said: > Florian, this can give you the unchangeable expiration date that you > wanted, if you're willing to accept the restrictions (RSA only, etc.) > on v3 keys :) as well as easy to fake keyIDs. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From dshaw@jabberwocky.com Fri Mar 1 19:29:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Fri Mar 1 19:29:02 2002 Subject: Key version games (was Re: problem with exporting subkeys) In-Reply-To: <87k7swpnyl.fsf@alberti.gnupg.de> References: <3C7E0B5D.25D67550@saiknes.lv.NO.SPaM.NET> <20020228135159.GD678@akamai.com> <87k7swpnyl.fsf@alberti.gnupg.de> Message-ID: <20020301182701.GA680@akamai.com> On Fri, Mar 01, 2002 at 11:44:02AM +0100, Werner Koch wrote: > On Thu, 28 Feb 2002 08:51:59 -0500, David Shaw said: > > > Florian, this can give you the unchangeable expiration date that you > > wanted, if you're willing to accept the restrictions (RSA only, etc.) > > on v3 keys :) > > as well as easy to fake keyIDs. Yeah, and the MD5-only restriction if you use it for signing. :/ David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From ftobin@neverending.org Fri Mar 1 19:47:03 2002 From: ftobin@neverending.org (Frank Tobin) Date: Fri Mar 1 19:47:03 2002 Subject: [Announce] Ann.: keystory 0.1.0 (initial) release Message-ID: <20020228234703.T93061-100000@palanthas.neverending.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Announcing the 0.1.0 (initial) release of keystory: keystory, by analyzing email history, gathers data on the usage of OpenPGP signatures, and provides information to imperfectly, but practically complement the web of trust, answering questions such as "What keys has foo@bar.baz.com used, where and when?" The homepage for keystory is at: http://keystory.sourceforge.net/ tar.gz's and RPM's can be found at: http://sourceforge.net/project/showfiles.php?group_id=42442 I have put up a demo of keystory having a CGI interface at http://palanthas.neverending.org/keystory/ The demo site contains information gathered from the gnupg-users and gnupg-devel archives. keystory requires Python 2.2 or later, GnuPG, and other Python modules that are described in the README. >From the NEWS file: Noteworthy changes in 0.1.0 - ----------------------------------------------------------------- * Initial release of keystory. * Current issues are that there is no recognition of duplicately imported data and compile time is slow. - -- Frank Tobin http://www.neverending.org/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjx/E/gACgkQVv/RCiYMT6NwfQCgigfN1v7620XSGa+qoEfGZwMb jwkAniEOgAXGuOLO0aG+FO1CLqsmyRaX =fpYe -----END PGP SIGNATURE----- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From bwpearre@alumni.princeton.edu Fri Mar 1 23:48:01 2002 From: bwpearre@alumni.princeton.edu (Ben Pearre) Date: Fri Mar 1 23:48:01 2002 Subject: Anderson's attack? In-Reply-To: References: <20020206131032.D21208@diverge.seunglab.mit.edu> Message-ID: <20020301224617.GA22601@diverge.seunglab.mit.edu> --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 06, 2002 at 03:50:22PM -0800, Len Sassaman wrote: > This was addressed pretty thoroughly on the Cryptography list when Davis's > paper first came out. Basically, the "flaws" the paper is discussing are > social, not technical. The steps that can be taken on a technical level > to prevent this are few. (FWIW, OpenPGP's timestamping helps this a bit.) Ok, y'all have convinced me that this is a mailer problem, not an engine problem. But it's very widespread. Couldn't it at least be better documented? I couldn't find any info in the documentation as to whether it encrypt-signed or sign-encrypted, and what the implications were. Just make it clear that when something arrives encrypted, gpg doesn't know who encrypted it. This would probably want to go in the man page, where people who read about --encrypt and --sign will see it. Cheers, -Ben --=20 bwpearre@alumni.princeton.edu http://hebb.mit.edu/~ben --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8gAS5+CWfKs/abNoRAonAAKDRVWJtpcW0O3S0KCeP2Nthc/PHfwCg/qZc 8nT/PZ7Hh8gv9QyDIAq6tjE= =kgLm -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From rjhansen@inav.net Sat Mar 2 01:53:01 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Sat Mar 2 01:53:01 2002 Subject: GPGME and CVS Message-ID: <1015030337.2058.23.camel@numbers.robnet.net> Has anyone committed anything to CVS which would break GPGME? I just grabbed a cvs checkout and make has broken with an "undefined reference to `_gpgme_gpgsm_op_keylist_ext'". I would just grab an ftp of the latest alpha release, but ftp.gnupg.org doesn't seem to like me very much at the moment--can't get a thing out of it. From disastry@saiknes.lv.NO.SPaM.NET Sat Mar 2 10:49:01 2002 From: disastry@saiknes.lv.NO.SPaM.NET (disastry@saiknes.lv.NO.SPaM.NET) Date: Sat Mar 2 10:49:01 2002 Subject: Key version games (was Re: problem with exporting subkeys) Message-ID: <3C809F50.1DD54A65@saiknes.lv.NO.SPaM.NET> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 David Shaw dshaw@jabberwocky.com wrote: > > Florian, this can give you the unchangeable expiration date that you > > wanted, if you're willing to accept the restrictions (RSA only, etc.) > > on v3 keys :) > > as well as easy to fake keyIDs. Yeah, and the MD5-only restriction if you use it for signing. :/ David not true. there is no such restriction. you can use any hash and cipher. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPICCtDBaTVEuJQxkEQOqAwCgzhFlo/267VWdXbf0nsL6za5gqK4An1G2 356Readm6A51X5WKZZYyApWQ =9tU9 -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Sat Mar 2 15:20:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Sat Mar 2 15:20:02 2002 Subject: Key version games (was Re: problem with exporting subkeys) In-Reply-To: <3C809F50.1DD54A65@saiknes.lv.NO.SPaM.NET> References: <3C809F50.1DD54A65@saiknes.lv.NO.SPaM.NET> Message-ID: <20020302141749.GA9761@akamai.com> On Sat, Mar 02, 2002 at 11:45:52AM +0200, disastry@saiknes.lv.NO.SPaM.NET wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > David Shaw dshaw@jabberwocky.com wrote: > > > Florian, this can give you the unchangeable expiration date that you > > > wanted, if you're willing to accept the restrictions (RSA only, etc.) > > > on v3 keys :) > > > > as well as easy to fake keyIDs. > > Yeah, and the MD5-only restriction if you use it for signing. :/ > David > > not true. there is no such restriction. you can use any hash and cipher. Oops, you're right. I was thinking in terms of backwards compatibility to PGP2 (yes I know there are a whole handful of modified versions that allow other hashes, but vanilla MIT PGP 2 does not), but used as a subkey on a OpenPGP key any OpenPGP hash is fine. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From disastry@saiknes.lv.NO.SPaM.NET Sat Mar 2 16:18:01 2002 From: disastry@saiknes.lv.NO.SPaM.NET (disastry@saiknes.lv.NO.SPaM.NET) Date: Sat Mar 2 16:18:01 2002 Subject: Key version games (was Re: problem with exporting subkeys) Message-ID: <3C80ECB1.7EFEC980@saiknes.lv.NO.SPaM.NET> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 David Shaw dshaw@jabberwocky.com wrote: > > On Sat, Mar 02, 2002 at 11:45:52AM +0200, disastry@saiknes.lv.NO.SPaM.NET wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: RIPEMD160 > > > > David Shaw dshaw@jabberwocky.com wrote: > > > > Florian, this can give you the unchangeable expiration date that you > > > > wanted, if you're willing to accept the restrictions (RSA only, etc.) > > > > on v3 keys :) > > > > > > as well as easy to fake keyIDs. > > > > Yeah, and the MD5-only restriction if you use it for signing. :/ > > David > > > > not true. there is no such restriction. you can use any hash and cipher. > > Oops, you're right. I was thinking in terms of backwards > compatibility to PGP2 (yes I know there are a whole handful of > modified versions that allow other hashes, but vanilla MIT PGP 2 does > not), but used as a subkey on a OpenPGP key any OpenPGP hash is fine. > David :) btw, if we talk about subkeys, fake keyIDs is not a problem for subkeys at all, it's only problem for master keys. of course one can generate key with th same keyId as yours subkey, but it is unusable anyway :) __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPIDQRDBaTVEuJQxkEQOvDACgi8RjJxRB59amfeEoNbui0ReHeoIAnjoU 9o2wu7k8dBiiAZa0HiM9P1/4 =LJG5 -----END PGP SIGNATURE----- From Weimer@CERT.Uni-Stuttgart.DE Sat Mar 2 19:00:01 2002 From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer) Date: Sat Mar 2 19:00:01 2002 Subject: Key version games (was Re: problem with exporting subkeys) In-Reply-To: <20020228135159.GD678@akamai.com> (David Shaw's message of "Thu, 28 Feb 2002 08:51:59 -0500") References: <3C7E0B5D.25D67550@saiknes.lv.NO.SPaM.NET> <20020228135159.GD678@akamai.com> Message-ID: <87wuwudfk6.fsf@CERT.Uni-Stuttgart.DE> David Shaw writes: > Speaking of key versions - I spent some time looking at what versions > were permitted with what a while ago and one thing that does seem to > be explicitly permitted is v4 keys with v3 subkeys. I did test this > and PGP supports it (though this may be accidental support). GnuPG > 1.0.6 only partially supports it, but I fixed that in 1.0.7. > > Florian, this can give you the unchangeable expiration date that you > wanted, if you're willing to accept the restrictions (RSA only, etc.) > on v3 keys :) Interesting. But actually, I wanted to force this down the throat of all GnuPG users, that's why this feature is only of limited help. ;-) -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From rick@openfortress.nl Sun Mar 3 00:30:02 2002 From: rick@openfortress.nl (Rick van Rein) Date: Sun Mar 3 00:30:02 2002 Subject: timestamp (0x40) signatures? Message-ID: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> Hello, I just noticed that GnuPG is not willing to parse a timestamp signature that follows RFC 2440 properly. In the source I did not find it either, so that makes sense. Shall I make a patchit, or is there a reason not to? Groeten, Rick van Rein. -- >>> Oorlog betekent dat iemand met een te groot ego op een te hoge post zit <<< Universiteit Twente * INF-3027 * Postbus 217 * 7500 AE Enschede * 053-4894291 From wk@gnupg.org Sun Mar 3 13:48:02 2002 From: wk@gnupg.org (Werner Koch) Date: Sun Mar 3 13:48:02 2002 Subject: GPGME and CVS In-Reply-To: <1015030337.2058.23.camel@numbers.robnet.net> ("Robert J. Hansen"'s message of "01 Mar 2002 18:52:13 -0600") References: <1015030337.2058.23.camel@numbers.robnet.net> Message-ID: <87vgcdu8fw.fsf@alberti.gnupg.de> On 01 Mar 2002 18:52:13 -0600, Robert J Hansen said: > Has anyone committed anything to CVS which would break GPGME? I just > grabbed a cvs checkout and make has broken with an "undefined reference > to `_gpgme_gpgsm_op_keylist_ext'". Very likely. We even have to introduce an API change. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk@gnupg.org Sun Mar 3 13:50:02 2002 From: wk@gnupg.org (Werner Koch) Date: Sun Mar 3 13:50:02 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> (Rick van Rein's message of "Sun, 3 Mar 2002 00:28:11 +0100 (MET)") References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> Message-ID: <87r8n1u8c4.fsf@alberti.gnupg.de> On Sun, 3 Mar 2002 00:28:11 +0100 (MET), Rick van Rein said: > I just noticed that GnuPG is not willing to parse a timestamp signature > that follows RFC 2440 properly. In the source I did not find it either, > so that makes sense. Shall I make a patchit, or is there a reason not to? Please send me such a signature so that I can write a test case. For larger patches we need papers (> ~10 lines total), so it might be easier if we write it. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From Marcus.Brinkmann@ruhr-uni-bochum.de Sun Mar 3 16:18:01 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Mar 3 16:18:01 2002 Subject: GPGME and CVS In-Reply-To: <1015030337.2058.23.camel@numbers.robnet.net> References: <1015030337.2058.23.camel@numbers.robnet.net> Message-ID: <20020303144949.GD973@212.23.136.22> On Fri, Mar 01, 2002 at 06:52:13PM -0600, Robert J. Hansen wrote: > Has anyone committed anything to CVS which would break GPGME? I just > grabbed a cvs checkout and make has broken with an "undefined reference > to `_gpgme_gpgsm_op_keylist_ext'". Thanks for reporting it. Should be fixed now with this change: 2002-03-03 Marcus Brinkmann * engine-gpgsm.c (_gpgme_gpgsm_op_keylist_ext) [!ENABLE_GPGSM]: Add stub function. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de From Marcus.Brinkmann@ruhr-uni-bochum.de Sun Mar 3 17:58:02 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Mar 3 17:58:02 2002 Subject: GPGME and verification of normal signatures In-Reply-To: <200202161516.g1GFGOK32016@mail.space2u.com> <3C6D4E89.F4634650@free.fr> References: <200202161516.g1GFGOK32016@mail.space2u.com> <3C6D4E89.F4634650@free.fr> Message-ID: <20020303165607.GE973@212.23.136.22> On Fri, Feb 15, 2002 at 07:08:09PM +0100, Laurent CHEYLUS wrote: > I use GPGME library to develop GPG support in Balsa (MUA of Gnome) but I > have some problems to verify a "PGP Signed Message" with > "gpgme_op_verify" function :-( [...] > Must the text begin with "-----BEGIN PGP SIGNED MESSAGE-----" or this > header must be suppress ? Must the signature begin with "-----BEGIN PGP > SIGNATURE-----" and finsih with "-----END PGP SIGNATURE-----" ? Must > these lines finish with "\n" or another caracter ? On Sat, Feb 16, 2002 at 05:12:04PM +0100, Andreas Agorander wrote: > 1. Looking through the documentation it seems like only detached signatures > can be verified by GPGME, is there any possibility to verify a clearsigned > message directly, or do I have to "separate" the signature from the message? The gpgme_op_verify function in CVS now supports that the plaintext argument is an _uninitialized_ data object and will return the plaintext data for a normal or cleartext signature in that. Here is an example how this can be done (mmmh, such examples should be in the manual :) const char *signed_message = "-----BEGIN PGP SIGNED MESSAGE-----..."; GpgmeData sig, text; GpgmeSigStat sigstat; char *plaintext; int plaintext_len; gpgme_data_new (&text); gpgme_data_new_from_mem (&sig, signed_message, strlen (signed_message), 0); gpgme_op_verify (ctx, sig, text, &sigstat); plaintext = gpgme_data_release_and_get_mem (text, &plaintext_len); ... Please let me know if you experience any problems with it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de From j_anderson@uop.edu Mon Mar 4 02:35:02 2002 From: j_anderson@uop.edu (John Anderson) Date: Mon Mar 4 02:35:02 2002 Subject: GPGME GpgmeTrustItem -- What is this? Message-ID: <1015205552.2025.5.camel@ivory> Hi there, I'm working on doing a Java version of gpgme, to see whether I can, and because I need it for some other stuff I want to work on. I'm making the API very similar to gpgme's, but making it object oriented of course. I'm not using JNI or CNI like I saw a few other people using, so I don't know if I'm being redundant or not. Maybe one of you could tell me? My question is about the GpgmeTrustItem type in gpgme. What the heck is this? I understand contexts, data handles, keys, and all that, but I can't garner what these trust items are and what they would do. Is this to establish a web-of-trust data structure? What is it, and how is it used? Thanks in advance, John Anderson From disastry@saiknes.lv.NO.SPaM.NET Mon Mar 4 09:17:01 2002 From: disastry@saiknes.lv.NO.SPaM.NET (disastry@saiknes.lv.NO.SPaM.NET) Date: Mon Mar 4 09:17:01 2002 Subject: advantages/disadvantages of DSA/RSA keys (was: Re: implications of subkeys?) Message-ID: <3C832CFE.EB84F9D3@saiknes.lv.NO.SPaM.NET> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Ingo Klöcker ingo.kloecker@epost.de wrote: > On Saturday 02 March 2002 15:21, David Shaw wrote: > > On Sat, Mar 02, 2002 at 01:51:01PM +0100, Ingo Klöcker wrote: > > > On Friday 01 March 2002 20:39, David Shaw wrote: > > > > Yes. The algorithm is up to you and what you trust more. GnuPG > > > > 1.0.7 gives you the choice between DSA and RSA. They each have > > > > advantages and disadvantages. > > > > > > Is there somewhere a short but complete list of the advantages and > > > disadvantages? > > > > This is pretty good: > > http://www.samsimpson.com/pgpfaq.html > > Thanks. At least from section 8.1 it doesn't seem that RSA keys have any > advantages (except the backwards compatibility with plain PGP 2.x). > Ingo note that this FAQ was written when there was only v3 RSA keys. RSA keys have some advantages, at least two: they are not limited to 1024 bits like DSA they can use hash longer than 160 bits. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPIMQvDBaTVEuJQxkEQOrpwCgs0UDyUhjSsVolXG3YI63SfB3h/YAnj3J S33waNVWzt90tC/JZsrXIfVf =6dWO -----END PGP SIGNATURE----- From lists@lina.inka.de Mon Mar 4 11:37:02 2002 From: lists@lina.inka.de (Bernd Eckenfels) Date: Mon Mar 4 11:37:02 2002 Subject: advantages/disadvantages of DSA/RSA keys (was: Re: implications of subkeys?) In-Reply-To: <3C832CFE.EB84F9D3@saiknes.lv.NO.SPaM.NET> References: <3C832CFE.EB84F9D3@saiknes.lv.NO.SPaM.NET> Message-ID: <20020304103530.GA11946@lina.inka.de> On Mon, Mar 04, 2002 at 10:14:54AM +0200, disastry@saiknes.lv.NO.SPaM.NET wrote: > RSA keys have some advantages, at least two: > they are not limited to 1024 bits like DSA > they can use hash longer than 160 bits. And DSA Cecking is faster than signing, whereas DSA Checking is slower and the signing is fast. Greetings Bernd -- (OO) -- Bernd_Eckenfels@Wendelinusstrasse39.76646Bruchsal.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! From dshaw@jabberwocky.com Mon Mar 4 16:14:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Mar 4 16:14:01 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <87r8n1u8c4.fsf@alberti.gnupg.de> References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> <87r8n1u8c4.fsf@alberti.gnupg.de> Message-ID: <20020304151130.GA6935@akamai.com> On Sun, Mar 03, 2002 at 01:47:07PM +0100, Werner Koch wrote: > On Sun, 3 Mar 2002 00:28:11 +0100 (MET), Rick van Rein said: > > > I just noticed that GnuPG is not willing to parse a timestamp signature > > that follows RFC 2440 properly. In the source I did not find it either, > > so that makes sense. Shall I make a patchit, or is there a reason not to? > > Please send me such a signature so that I can write a test case. For > larger patches we need papers (> ~10 lines total), so it might be > easier if we write it. It's an interesting question as to just what an 0x40 signature is. RFC 2440 defines it as a "timestamp" signature, but does not really define what it is a signature on (if anything). RFC 1991 goes into more detail and defines it as a signature on a signature, which is more useful - this is the idea of a notary for PGP, which proves that a key owner saw a signature and gives this new signature as proof. Of course, 2440 replaces 1991, so who knows? If all that is wanted here is a straight standalone timestamp, then the 0x02 signature (standalone signature over an empty document) would be more appropriate. I actually have the code for this ready, but I wasn't planning on checking it in so as to help freeze this version. Werner, I can check it in if you want. :) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From william.newman@airmail.net Mon Mar 4 17:21:02 2002 From: william.newman@airmail.net (William Harold Newman) Date: Mon Mar 4 17:21:02 2002 Subject: buglet in --passphrase-fd option in 1.0.6 Message-ID: <20020304160352.GC11839@balefire.localdomain> I was playing around with the --passphrase-fd option under Emacs shell mode (with gpg-1.0.6, under OpenBSD 2.9), and noticed that the output looks like $ lightning:/tmp (emacs *shell*) $ echo ppp | gpg --symmetric --passphrase-fd 0 foo gpg: Warning: using insecure memory! Reading passphrase from file descriptor 0 ...^H^H^H where the extra ^H characters are ASCII BS='\010', not the '^' followed by 'H' that I've munged them into so that they'll be visible in everyone's mailer. Under an ordinary terminal, the ^H characters wouldn't be visible, and so they could've been overlooked so far, but in my Emacs window, they were visible. The extra ^H characters aren't a big deal, but they seem pointless and untidy, potentially either messing up someone's screen on a display which places special significance on ASCII BS characters, or even leaking a few bits of information about the passphrase (i.e. its length) under some even more obscure circumstance. -- William Harold Newman "Look on my works, ye Mighty, and despair!" -- Ozymandias, King of Kings PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C From wk@gnupg.org Mon Mar 4 17:24:01 2002 From: wk@gnupg.org (Werner Koch) Date: Mon Mar 4 17:24:01 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <20020304151130.GA6935@akamai.com> (David Shaw's message of "Mon, 4 Mar 2002 10:11:30 -0500") References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> <87r8n1u8c4.fsf@alberti.gnupg.de> <20020304151130.GA6935@akamai.com> Message-ID: <87k7sspamn.fsf@alberti.gnupg.de> On Mon, 4 Mar 2002 10:11:30 -0500, David Shaw said: > define what it is a signature on (if anything). RFC 1991 goes into > more detail and defines it as a signature on a signature, which is > more useful - this is the idea of a notary for PGP, which proves > that Indeed. A timestamping service makes more sense when it can be used to certify that a given signature was done at that time. Does PGP implemnt this, are there any notary services out providing such a service, should we clear this up in the next OpenPGP draft? > Werner, I can check it in if you want. :) I have not seen any requests for this, so better don't check it in. BTW, I have released 1.0.6d but not written an announcement yet. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk@gnupg.org Mon Mar 4 17:44:01 2002 From: wk@gnupg.org (Werner Koch) Date: Mon Mar 4 17:44:01 2002 Subject: buglet in --passphrase-fd option in 1.0.6 In-Reply-To: <20020304160352.GC11839@balefire.localdomain> (William Harold Newman's message of "Mon, 4 Mar 2002 10:03:52 -0600") References: <20020304160352.GC11839@balefire.localdomain> Message-ID: <87bse4p9oz.fsf@alberti.gnupg.de> On Mon, 4 Mar 2002 10:03:52 -0600, William Harold Newman said: > echo ppp | gpg --symmetric --passphrase-fd 0 foo > gpg: Warning: using insecure memory! > Reading passphrase from file descriptor 0 ...^H^H^H add --batch -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From dshaw@jabberwocky.com Mon Mar 4 18:19:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Mar 4 18:19:01 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <87k7sspamn.fsf@alberti.gnupg.de> References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> <87r8n1u8c4.fsf@alberti.gnupg.de> <20020304151130.GA6935@akamai.com> <87k7sspamn.fsf@alberti.gnupg.de> Message-ID: <20020304171724.GA1082@akamai.com> On Mon, Mar 04, 2002 at 05:21:04PM +0100, Werner Koch wrote: > On Mon, 4 Mar 2002 10:11:30 -0500, David Shaw said: > > > define what it is a signature on (if anything). RFC 1991 goes into > > more detail and defines it as a signature on a signature, which is > > more useful - this is the idea of a notary for PGP, which proves > > that > > Indeed. A timestamping service makes more sense when it can be used > to certify that a given signature was done at that time. > > Does PGP implemnt this, are there any notary services out providing > such a service, should we clear this up in the next OpenPGP draft? As far as I can tell, nobody implements this. I just tried feeding a 0x40 signature to PGP (6 and 7) and it just ignored it. PGP 2 doesn't like it either (no surprise). I think it would be very good to clear this up in the next OpenPGP draft though. A notary signature sounds very useful and if it was clear what it meant, then we could implement and use it :) > BTW, I have released 1.0.6d but not written an announcement yet. Cool! David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From disastry@saiknes.lv Mon Mar 4 19:32:02 2002 From: disastry@saiknes.lv (disastry@saiknes.lv) Date: Mon Mar 4 19:32:02 2002 Subject: 106d & Cygwin Message-ID: <3C83BCB6.490C3586@saiknes.lv> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message Werner Koch wk@gnupg.org wrote: > BTW, I have released 1.0.6d but not written an announcement yet. > Werner doesn't compile on Cygwin, here is the pacth: --- g10/tdbio.c.old Mon Mar 4 20:18:30 2002 +++ g10/tdbio.c Mon Mar 4 20:20:43 2002 @@ -39,7 +39,7 @@ #include "trustdb.h" #include "tdbio.h" -#ifdef HAVE_DOSISH_SYSTEM +#if defined(HAVE_DOSISH_SYSTEM) && !defined(__CYGWIN32__) #define ftruncate chsize #endif __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6d (Cygwin32) iD8DBQE8g7xGMFpNUS4lDGQRAqtcAJ9jhtKU4xOBT3LxVce8uqRCeVSN/gCgr2m4 vW20LWkuCzrACbBAh0D/w14= =EM/q -----END PGP SIGNATURE----- From disastry@saiknes.lv Mon Mar 4 20:35:01 2002 From: disastry@saiknes.lv (disastry@saiknes.lv) Date: Mon Mar 4 20:35:01 2002 Subject: 106d & Mingw32 Message-ID: <3C83CB62.D1282D29@saiknes.lv> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Werner Koch wk@gnupg.org wrote: > BTW, I have released 1.0.6d but not written an announcement yet. > Werner doesn't compile on Mingw32: /usr/local/lib/mingw32-cpd/i386--mingw32/bin/ld: cannot open -lws2_32: No such file or directory I have: ftp://ftp.gnupg.org/people/werner/cpd/mingw32-cpd-0.3.0.tar.gz ftp://ftp.gnupg.org/people/werner/cpd/gcc-core-2.95.2.tar.gz ftp://ftp.gnupg.org/people/werner/cpd/binutils-2.9.1.tar.gz ftp://ftp.gnupg.org/people/werner/cpd/windows32api-0.1.2.tar.gz probably I need some newer version of windows32api :-/ __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPIOvJDBaTVEuJQxkEQNwIACfY54sVltvyQrgYbvBHHoEajxjYvIAniXY 3WSHKrb1e/kAdndLRGt5ld5C =Tt/d -----END PGP SIGNATURE----- From lists@lina.inka.de Mon Mar 4 22:31:02 2002 From: lists@lina.inka.de (Bernd Eckenfels) Date: Mon Mar 4 22:31:02 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <20020304171724.GA1082@akamai.com> References: <200203022328.g22NSCY26072@theatre.cs.utwente.nl> <87r8n1u8c4.fsf@alberti.gnupg.de> <20020304151130.GA6935@akamai.com> <87k7sspamn.fsf@alberti.gnupg.de> <20020304171724.GA1082@akamai.com> Message-ID: <20020304212841.GA24547@lina.inka.de> On Mon, Mar 04, 2002 at 12:17:24PM -0500, David Shaw wrote: > I think it would be very good to clear this up in the next OpenPGP > draft though. A notary signature sounds very useful and if it was > clear what it meant, then we could implement and use it :) The question is, if a special signature packet type is needed, anyway. The notar can simply envelop the detached signature and a time-stamp-packet with a normal PGP signature? BTW: for X.509/SigG Applications something similiar is a requirement: one checks the signature of a received document and asks the CA if the certificate is still valid (OSPC). The received statement that for a given time/query the certificate was not revoked should be archived by the original receiver, to proof that the signature was not revoked (this is, to avoid re-dating of signatures, which do not eed to carry a official timestamp according to law, yet). I guess something similiar can be added to the OpenPGP draft as the usual application for Timestamp signatures. Greetings Bernd -- (OO) -- Bernd_Eckenfels@Wendelinusstrasse39.76646Bruchsal.de -- ( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE (O____O) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! From dshaw@jabberwocky.com Mon Mar 4 23:55:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Mar 4 23:55:01 2002 Subject: Comments on 1.0.6d Message-ID: <20020304225310.GB31127@akamai.com> Hi, As promised, here's are some comments about the latest snapshot. These are the "doesn't work right" comments. I'll do the "would be nice" list later :) I've started on fixes for #5, #8, #10, #13, and #15. 1) --edit a public key you have the secret key for, and use "adduid". Make up any user ID you like, but when prompted for a passphrase, just hit enter a few times. This causes an assertion failure: "free-packet.c:287: free_user_id: Assertion `uid->ref > 0' failed." 2) The RPM spec file in scripts/gnupg.spec(.in) needs updating for the keyserver helpers (gpgkeys_ldap, gpgkeys_mailto). 3) If a key is revoked, it is not shown as revoked in the --edit menu until ownertrust is set for that key. This happens with expired keys as well. 4) The 'keyid!' (with exclamation point) syntax works with public (i.e. for encryption), but does not work with private (for signing) keys. This seems to be because lookup() in getkey.c calls itself and the flags are wiped. 5) When revoking a local key signature (i.e. from 'lsign'), the revocation should be local as well to prevent possibly leaking information about the local signature. 6) --list-packets shows an awful lot more than it used to in 1.0.6. For example, when decrypting a message it shows the packets in the keyring as they are read to find the key to decrypt with. This makes it a lot less useful than it used to be. 1.0.6 used to only show the immediate object being worked with - when decrypting for example, it showed only the packets in the encrypted message. 7) When you delete a key with ownertrust set it does not disappear from the trustdb. I mentioned this one a few months ago and I think it was concluded to be a feature and not a bug, though I still think that if I delete a key there should be no remnants of that key left behind. The more significant problem is if there is an ultimately trusted key that gets deleted, then gpg will complain constantly: gpg: Oops: keyid_from_fingerprint: no pubkey and whenever --update-trustdb or --check-trustdb is run: gpg: public key of ultimately trusted key 00000000 not found 8) V3 key revocations should not prompt for a revocation reason since V3 revocations do not use it anyway. 9) For some reason --with-colons no longer shows anything in the ownertrust field. 10) The keyserver stuff needs an "exec-path" or similar, as the user's path may be untrustworthy, and it is also difficult to use the keyserver stuff via cron or other non-login methods without it. 11) --list-packets does not work with partial body lengths 12) Should "RIJNDAEL" be called "AES" now that the standard (at least the US standard) went through? PGP calls it "AES", so there may be confusion there. Perhaps GnuPG should accept both names? 13) The command "gpg --export 0xz blah" causes BUG() to be called. 14) Sign a key so that it's trust goes to "full". Now, delete or revoke the signature. The trust level stays at "full" until you export, delete, and then re-import the trustdb. 15) Compiler warning in util/: iobuf.c:1891: warning: static declaration for `fseeko' follows non-static (I'm not mentioning the compiler warnings in g10/keyedit.c as that is the fault of the compiler and not the code.) 16) Assembler warning in mpi/: _mpih-rshift.s:129: Warning: using `%dl' instead of `%edx' due to `b' suffix 17) Something seems to be not correct with MDC packets. Encrypt a message so that MDC packets are included, and then run gpg on the message. Do not enter a passphrase, but just hit enter a few times. You get errors that seem to imply the message goes on longer than gpg expects it to. This is visible with --list-packets as well. 18) Using several config options like "default-recipient" or "secret-keyring" in a config file with no argument causes a segfault. 19) If the user makes a key ultimately trusted, there is no way to later make it not ultimately trusted without deleting the trustdb or exporting the trustdb, editing it manually and re-importing it. 20) This isn't a problem, but I just wanted to comment on it in case someone disagrees. In the way I wrote the signature expiration and non-revocability code, expiration subpackets are marked critical, and non-revocable subpackets are not. The rationale for the non-revocable subpacket being not critical is that the worst thing that could happen with such a signature is that it ended up on an implementation that treated it as revocable. Since the user is the only person who could issue the revocation anyway, there is no problem here. The expiration subpacket on the other hand, *is* marked as critical, as if it was used on an implementation that did not understand expiring signatures the signature could live longer then the signer intended, which is clearly wrong. Better in that case to have no signature rather than a signature that persisted beyond when the user intended. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From Marcus.Brinkmann@ruhr-uni-bochum.de Tue Mar 5 00:09:02 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Mar 5 00:09:02 2002 Subject: GPGME GpgmeTrustItem -- What is this? In-Reply-To: <1015205552.2025.5.camel@ivory> References: <1015205552.2025.5.camel@ivory> Message-ID: <20020304230712.GG742@212.23.136.22> On Sun, Mar 03, 2002 at 05:32:32PM -0800, John Anderson wrote: > My question is about the GpgmeTrustItem type in gpgme. What the heck is > this? I understand contexts, data handles, keys, and all that, but I > can't garner what these trust items are and what they would do. Is this > to establish a web-of-trust data structure? What is it, and how is it > used? Yes, it is supposed to provide information about the validity of a key, or the amount of trust the user has assigned to it. Feel free to leave this interface out for now (or do it when everything else is done): It is experimental (as documented in the manual, which you have certainly read :), and probably subject to change. The whole key management interface in gpgme still needs to evolve a bit more... Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org Marcus.Brinkmann@ruhr-uni-bochum.de http://www.marcus-brinkmann.de From dshaw@jabberwocky.com Tue Mar 5 06:51:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Mar 5 06:51:01 2002 Subject: Comments on 1.0.6d In-Reply-To: <20020304225310.GB31127@akamai.com> References: <20020304225310.GB31127@akamai.com> Message-ID: <20020305054827.GC678@akamai.com> On Mon, Mar 04, 2002 at 05:53:10PM -0500, David Shaw wrote: > As promised, here's are some comments about the latest snapshot. > These are the "doesn't work right" comments. I'll do the "would be > nice" list later :) > > I've started on fixes for #5, #8, #10, #13, and #15. > 5) When revoking a local key signature (i.e. from 'lsign'), the > revocation should be local as well to prevent possibly leaking > information about the local signature. > 8) V3 key revocations should not prompt for a revocation reason since > V3 revocations do not use it anyway. > 10) The keyserver stuff needs an "exec-path" or similar, as the user's > path may be untrustworthy, and it is also difficult to use the > keyserver stuff via cron or other non-login methods without it. > 13) The command "gpg --export 0xz blah" causes BUG() to be called. > 15) Compiler warning in util/: > iobuf.c:1891: warning: static declaration for `fseeko' follows non-static Ok, all these are fixed. #15 was particularly interesting - it turned out to be an odd interaction between my libc headers and autoconf. It wasn't the code at all. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From foxy@free.fr Tue Mar 5 16:02:01 2002 From: foxy@free.fr (Laurent Cheylus) Date: Tue Mar 5 16:02:01 2002 Subject: Example for GPGME function "gpgme_set_passphrase_cb" ? Message-ID: <3C84DD88.A72329F3@free.fr> Hi, in GPGME library, the function "gpgme_set_passphrase_cb" has prototype : void gpgme_set_passphrase_cb (GpgmeCtx ctx , GpgmePassphraseCb cb , void * cb_value ) with : typedef const char *(*GpgmePassphraseCb)(void*cb_value, const char *desc, void **r_hd) for the callback "cb". But I don't understand how to get the status of the passphrase entry. I have some code who works well when the passphrase is good but how get the status, if the passphrase is bad or missing ?? Has anybody some example of code to help me with this function ? Thanks, Foxy. -- Laurent Cheylus OpenPGP ID 0x5B766EC2 From wk@gnupg.org Tue Mar 5 16:36:01 2002 From: wk@gnupg.org (Werner Koch) Date: Tue Mar 5 16:36:01 2002 Subject: Example for GPGME function "gpgme_set_passphrase_cb" ? In-Reply-To: <3C84DD88.A72329F3@free.fr> (Laurent Cheylus's message of "Tue, 05 Mar 2002 16:00:24 +0100") References: <3C84DD88.A72329F3@free.fr> Message-ID: <87henvuiz6.fsf@alberti.gnupg.de> On Tue, 05 Mar 2002 16:00:24 +0100, Laurent Cheylus said: > But I don't understand how to get the status of the passphrase entry. I > have some code who works well when the passphrase is good but how get > the status, if the passphrase is bad or missing ?? From Sylpheed: static const char * passphrase_cb (void *opaque, const char *desc, void *r_hd) { struct passphrase_cb_info_s *info = opaque; GpgmeCtx ctx = info ? info->c : NULL; const char *pass; if (!desc) { /* FIXME: cleanup by looking at *r_hd */ return NULL; } g_message ("%% requesting passphrase for `%s': ", desc ); pass = gpgmegtk_passphrase_mbox (desc); if (!pass) { g_message ("%% cancel passphrase entry"); gpgme_cancel (ctx); } else g_message ("%% sending passphrase"); return pass; } Somewhere in gpgmegtk_passphrase_mbox the window is created and the displayed prompt varied by looking at the first line of the description (TRY_AGAIN) static GtkWidget * create_description (const gchar *desc) { const gchar *cmd=NULL, *uid=NULL, *info=NULL; gchar *buf; GtkWidget *label; cmd = desc; uid = strchr (cmd, '\n'); if (uid) { info = strchr (++uid, '\n'); if (info ) info++; } if (!uid) uid = _("[no user id]"); if (!info) info = ""; buf = g_strdup_printf (_("%sPlease enter the passphrase for:\n\n" " %.*s \n" "(%.*s)\n"), !strncmp (cmd, "TRY_AGAIN", 9 ) ? _("Bad passphrase! Try again...\n\n") : "", linelen (uid), uid, linelen (info), info); label = gtk_label_new (buf); g_free (buf); return label; } -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From rabbi@quickie.net Tue Mar 5 23:57:02 2002 From: rabbi@quickie.net (Len Sassaman) Date: Tue Mar 5 23:57:02 2002 Subject: timestamp (0x40) signatures? In-Reply-To: <87k7sspamn.fsf@alberti.gnupg.de> Message-ID: On Mon, 4 Mar 2002, Werner Koch wrote: > On Mon, 4 Mar 2002 10:11:30 -0500, David Shaw said: > > > define what it is a signature on (if anything). RFC 1991 goes into > > more detail and defines it as a signature on a signature, which is > > more useful - this is the idea of a notary for PGP, which proves > > that > > Indeed. A timestamping service makes more sense when it can be used > to certify that a given signature was done at that time. Exactly. > Does PGP implemnt this, are there any notary services out providing > such a service, should we clear this up in the next OpenPGP draft? I don't think PGP implements this, though this came directly from an idea Phil and Hal had, I believe. I had been working on a notary service that would use this (among other things), though that project has been put on the back burner recently. It would be useful if GnuPG knew what it was, however. --Len. From legoxx@yahoo.com Thu Mar 7 11:48:01 2002 From: legoxx@yahoo.com (lego lego) Date: Thu Mar 7 11:48:01 2002 Subject: problem with using files as a keyring Message-ID: <20020307104555.23129.qmail@web14510.mail.yahoo.com> hello i'm trying this from the doc/DETAILS $ cat >foo < ssb 1024g/8F70E2C0 2000-03-09 i just got this: gpg: Warning: using insecure memory! gpg: /home/peter/.gnupg/foo.sec: keyring created gpg: /home/peter/.gnupg/foo.pub: keyring created i tried to sign files using foo.sec but it won't work it seems that the keyrings are not even open... well when i run gpg --no-default-keyring --secret-keyring foo.sec --keyring foo.pub --list-secret-keys for second time i got not output at all just gpg: Warning: using insecure memory! [peter@love1 foo]$ i want to sign a file without importing key to my keyring, and i need my customer to verify signature without installing public key to his keyring. Just simple command line interface. Ideally in batch file i want to use foo.pub and foo.sec in the current direcotory not /home/user/.gnupg so i modified my script:gpg --no-default-keyring --secret-keyring ./foo.sec --keyring ./foo.pub --list-secret-keys but i got this... gpg: Warning: using insecure memory! gpg: [don't know]: invalid packet (ctb=2d) gpg: read_keyblock: read error: invalid packet gpg: enum_keyblocks(read) failed: invalid keyring can anyone help me please? __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From Enzo Michelangeli" RFC2440 says that the correctness of a passphrase can be checked just verifying a checksum in the Secret Key Packets: 5.5.3. Secret Key Packet Formats [...] The 16-bit checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm- specific octets (including MPI prefix and data). With V3 keys, the checksum is stored in the clear. With V4 keys, the checksum is encrypted like the algorithm-specific data. This value is used to check that the passphrase was correct. Is this true also inside the gpg keyring files, or just in the exported keys? And in any case, wouldn't it be more prudent to obsolete that checksum requirement and/or deliberately ignore it in the keyring implementations, in order to slow down dictionary attacks? The correctness of the passphrase could always be checked, fast enough if done once for legitimate purposes, against the corresponding public key. Enzo From wk@gnupg.org Fri Mar 8 17:00:02 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 8 17:00:02 2002 Subject: Passphrase protection of secret keys In-Reply-To: <011301c1c6a1$492e7420$0200000a@noip.com> ("Enzo Michelangeli"'s message of "Fri, 8 Mar 2002 21:00:05 +0800") References: <011301c1c6a1$492e7420$0200000a@noip.com> Message-ID: <87n0xjf3xb.fsf@alberti.gnupg.de> On Fri, 8 Mar 2002 21:00:05 +0800, Enzo Michelangeli said: > Is this true also inside the gpg keyring files, or just in the exported > keys? And in any case, wouldn't it be more prudent to obsolete that checksum Yes it is still true. However GnuPG checks a signature right after creation, so the Klima/Rosa attack won't work. > requirement and/or deliberately ignore it in the keyring implementations, in > order to slow down dictionary attacks? The correctness of the passphrase Plaintext (i.e. the unprotected secret key) detection can be done w/o calculating the checksum and thus faster, so it won't help. Forthcoming GnuPG versions are going to use there own format to protect secret keys. See: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/newpg/agent/keyformat.txt?rev=1.4&content-type=text/vnd.viewcvs-markup&cvsroot=Project+Aegypten Ciao, Werner From rjhansen@inav.net Fri Mar 8 23:53:01 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Fri Mar 8 23:53:01 2002 Subject: GPGME, C++ wrappers and Stupid Questions. Message-ID: <1015627911.8896.62.camel@numbers.robnet.net> Is there any project underway to wrap GPGME in C++? (I know that a lot of people on the list have no fondness for C++, but hey, I like the language.) If not, I've got the beginnings of a wrapper going--right now it's only adequate for querying the keyring, but it shouldn't be too terribly hard to extend it to support the full range of GPGME operations. Before I do any more work on it, though, I'd like to make sure I'm not reinventing the wheel. And on a related note, I'm having some real troubles deleting keys from a keyring. The following is a snippet of code that shows the bug: void Key::deleteKey(bool deleteSecret = false) { GpgmeError err = GPGME_No_Error; switch (deleteSecret) { case false: err = gpgme_op_delete_start(ctx, key, 0); ctx = gpgme_wait(ctx, &err, 1); break; case true: err = gpgme_op_delete_start(ctx, key, 1); ctx = gpgme_wait(ctx, &err, 1); break; }; errswitch(err); } ... Whenever I call Key::deleteKey, err is GPGME_No_Error by the time the error-switcher is reached. However, the key remains on my GPG keyring even after the function ends. Am I misusing the API, or is there some subtle error elsewhere in my code that's causing this to fail? From ben.bucksch.news@beonex.com Sat Mar 9 16:02:01 2002 From: ben.bucksch.news@beonex.com (Ben Bucksch) Date: Sat Mar 9 16:02:01 2002 Subject: Mozilla, License (again), PPG, GPGME Message-ID: <3C8A2228.4020408@beonex.com> Hi, sorry for reopening the old, annoying question [1], but... Mozilla is MPL, GnuPG is GPL, MPL and GPL are not compatible. Mozilla wants PGP, GnuPG wants to have an interface in Mozilla (at least Werner and the German gov't says so). The Mozilla relicensing is not necessarily of much help, because a GPL lib would force all of Mozilla under the GPL, which would make other inclusions impossible (e.g. Macromedia Flash). GnuPG is a separate executable, so there doesn't have to be a problem, if Mozilla communicates with GnuPG via pipes. Enigmail does this, for example. The most sane method is to have a standard library, which can be linked from other apps (like MUAs) and which wraps the communication with GnuPG into a nice API. That's what GPGME [5] and PPG [4] try to achieve. However, because that lib is then linked directly with the using program (e.g. Mozilla), the lib license must be compatible with the license of the using program. I.e. the lib cannot be GPL, if it wants to be used by Mozilla and other programs. "Other programs" might include Microsoft Outlook [Express], now that the future of the commercial PGP is unclear. (Outlook has such a large market share that OpenPGP needs to have a nice UI for it, if it ever wants to be a widely used standard. I know the security concerns, but I think they are not really relevant.) The author expressed intend to open the PPG license specifically so that Mozilla could use it. (Thanks!) [2] GPGME, however, is GPL. PPG, however, seems to be dormant (last release 2 years ago), and GPGME is actively developed (last checkin 2 days ago). I found a diary entry [3] of Werner Koch, reading: > /Monday, October 30 / > > Worked on *GPGME*, which may translate to GPG Made Easy. This the 3rd > attempt to write a usable wrapper libary around GPG. Why? While > playing with Evolution and Mozilla, I figured out that we should not > duplicate gpg access code (which is pretty obvious) but have a good > library to do that once and bulletproof. > > I looked at GPAPA but it actually is too strong bound to GPA and the > design is not very flexibel. Looked again at *PGG* but this thing is > too complicated and too much OOed. So, what to do? I stared out of the > window for a long time before I decided that this 3rd attempt is worth > a try. The goals of *gpgme* are: Should be able to run asyncronously, > take filenames or memory areas, design must allow a better integration > with OO systems, easy to read (at least for me), easy to build, limit > use of resources. > So far for the facts, as I understood them. My questions: * What's the state of PGG? I guess it's unusable by now? * (What's wrong with OO? - no answer required :). ) * Why GPL for GPGME? Werner, you say you want to use the lib for Mozilla, but you are surely aware of the license problems. What was your plan, or did you just "default" to GPL :), planning to think about the problem later? Ben Bucksch P.S. In case you didn't hear of: * Mozilla has now partial S/MIME support, and Netscape claims that the underlying stuff is general enough for OpenPGP. As usual, they have no docs whatsoover. I haven't looked at it myself. * NAI worked on a Mozilla plugin last year, but the code was rejected. IMHO, it looked better than the Netscape S/MIME stuff. [1] [2] [3] [4] [5] From wk@gnupg.org Sat Mar 9 16:52:01 2002 From: wk@gnupg.org (Werner Koch) Date: Sat Mar 9 16:52:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <3C8A2228.4020408@beonex.com> (Ben Bucksch's message of "Sat, 09 Mar 2002 15:54:32 +0100") References: <3C8A2228.4020408@beonex.com> Message-ID: <877kold9mq.fsf@alberti.gnupg.de> On Sat, 09 Mar 2002 15:54:32 +0100, Ben Bucksch said: > include Microsoft Outlook [Express], now that the future of the > commercial PGP is unclear. (Outlook has such a large market share that You mean the proprietary PGP. Wether a software is commcercial or not has nothing to do with Free Software versus proprietary software. The furture of PGP is not that unlcear: There is and will be no more development for it. They have laid off all engineers working on PGP. > OpenPGP needs to have a nice UI for it, if it ever wants to be a > widely used standard. I know the security concerns, but I think they Yes, definitely. Noone as volunteered to make GPA or any of the other frontends a workable solution, so I fear that without a proper funding there will be no good GUI in the near future. I know that this is very important. I have a list of things in mind which should be undertaken by further GPA (or whatever) development. > My questions: > * What's the state of PGG? I guess it's unusable by now? Right. > * (What's wrong with OO? - no answer required :). ) It needs to be done right and frankly OO is far older than what Brooch claims to have invented. The IEEE Software had a good article on the disadvantage of several OO approaches (look for something like "Why OO does not sync with our thinking" about 2 years old) > * Why GPL for GPGME? Werner, you say you want to use the lib for > Mozilla, but you are surely aware of the license problems. What > was your plan, or did you just "default" to GPL :), planning to > think about the problem later? Now that Mozilla is dual licensed there is no more problem to use it. If you want to use in addtion a proprietary plugin, you may not be able to do so. In theory I can still change the GPGME license but I don't see a reason to endorse the use of proprietary software by doing that. Mozilla is free and if someone wants a Flash plugin, he should write a compatible plugin or even better use a standard vector format. > * Mozilla has now partial S/MIME support, and Netscape claims that > the underlying stuff is general enough for OpenPGP. As usual, they > have no docs whatsoover. I haven't looked at it myself. What's wrong with enigmail? If you worry about performance problems due to the fork/exec approach, this will be solved soon by a gpg server mode. > * NAI worked on a Mozilla plugin last year, but the code was > rejected. IMHO, it looked better than the Netscape S/MIME stuff. Although I am much in favor of OpenPGP, I can tell you that GPGME does support S/MIME (well, the CMS part). Werner From ben.bucksch.news@beonex.com Sat Mar 9 18:46:01 2002 From: ben.bucksch.news@beonex.com (Ben Bucksch) Date: Sat Mar 9 18:46:01 2002 Subject: Mozilla, License (again), PPG, GPGME References: <3C8A2228.4020408@beonex.com> <877kold9mq.fsf@alberti.gnupg.de> Message-ID: <3C8A4887.60004@beonex.com> Werner Koch wrote: >Now that Mozilla is dual licensed there is no more problem to use it. > That Mozilla relicensing was intended for Mozilla being *used* in GPL apps like Galeon or Evolution, not for having GPL code included in Mozilla. >If you want to use in addtion a proprietary plugin, you may not be >able to do so. In theory I can still change the GPGME license but I >don't see a reason to endorse the use of proprietary software by doing >that. Mozilla is free and if someone wants a Flash plugin, he should >write a compatible plugin or even better use a standard vector format. > I don't want to offend you, but you are free to write a Flash plugin that works with Mozilla. And a RealPlayer plugin, and a Quicktime one, and a Java engine with decent Swing support, and what-have-you. Never mind that you are probably not even allowed to, due to patents (arg!). Believe me, I created Beonex Communicator, and I really try to keep everything completely Open-Source. But users want a browser that works, with Flash and all the other goodies, *now*. They don't want to be locked out of (stupid) sites like . While I much dislike having proprietary bits in a version of Beonex Communicator (there will always be a Open-Source-only version), I prefer that over people using MSIE6 on Windows XP or Netscape 6. I also care about security, that's why PGP is important to Beonex. Please don't make these goals incompatible. As I said, I choose a slightly less compatible Open-Source implementation over the "original" proprietary one, but what do I do until the latter exists? I can't write all of that myself. To take a concrete example: A browser for the Bundestag. What, do you think, would be the options? If you were to offer one, what would you include in the browser? Surely, PGP would be desireable. Do you think that the Abgeordneten would accept not to be able to see Flash content? Also, I don't think you "endorse" anything. You just *refrain* from *forcing* other people (like me) to do or not to do something (which would be a major problem). And last but not least, your lib probably has 0 chance to be part of the base Mozilla, if it is not MPL/GPL/LGPL tripple-licensed. Any such plugin would surely live a third-party life, left bitrotting after a few months of frequent Mozilla changes. > or even better use a standard vector format. > As much as I'd like to, I cannot change the content that is out there on the web. Being locked out of a few major sites makes users already consider to switch the browser. You guess which one that is. >What's wrong with enigmail? > I haven't looked at all at it, because its author basically says that it's just a little toy that he dumped on an ftp server, not really ready for use. Have you audited it security-wise? I don't know enough about the problems there (exec() etc.) to do that. >If you worry about performance problems > Not at all. From agent@ibcine.tv Sun Mar 10 01:00:02 2002 From: agent@ibcine.tv (agent) Date: Sun Mar 10 01:00:02 2002 Subject: [±¤°í]¿µÈ­°üÀ» ÀÌ °¡°Ý¿¡ °¡Áú¼ö ÀÖ´Ù¸é ¹ÏÀ¸½Ã°Ú½À´Ï±î? Message-ID: <200203092357.g29NvWor022293@mail.openit.de> =BC=BC=BB=F3=BF=A1=BC=AD =B0=A1=C0=E5 =B4=DE=C4=DE=C7=D1 =BF=B5=C8= =AD=B0=FC


=
=B9=F6=C6=B0=C0=BB =C5=AC=B8=AF=C7=CF=BD=C3=B8=E9= =BC=F6=BD=C5=B0=C5=BA=CE=C3=B3=B8=AE=B0=A1 =C0=CC=B7=E7=BE=EE =C1=FD=B4=CF= =B4=D9.



3D= 3D"=BB=F3=B4=E3=B8=DE=C0=CF" 3D"=BE=C6=C0=CC=BA=F1=C5=AC=B7=B4" From wagner@tik.ee.ethz.ch Mon Mar 11 13:42:01 2002 From: wagner@tik.ee.ethz.ch (Arno Wagner) Date: Mon Mar 11 13:42:01 2002 Subject: Mozilla, License (again), PPG, GPGME Message-ID: <20020311133946.A28603@tik.ee.ethz.ch> > > * (What's wrong with OO? - no answer required :). ) > > It needs to be done right and frankly OO is far older than what Brooch > claims to have invented. The IEEE Software had a good article on the > disadvantage of several OO approaches (look for something like "Why OO > does not sync with our thinking" about 2 years old) Just for the record that is  Does OO sync with how we think? Hatton, L. IEEE Software , Volume: 15 Issue: 3 , May-June 1998 Page(s): 46 -54 Can be downloaded from http://ieeexplore.ieee.org/lpdocs/epic03/EarlierIssue.HTM?punumber=52&isyr=1998 You might have to be an IEEE member to do so. Personally I don't agree with the conclusions. The Article is mainly based on C++. There are far better OO languages, e.g. Eiffel, that may change the situation drastically. Personally I kept running into limitations, non-orthogonalities and plain stupid implementation of OO features when dealing with C++. Some things, like the protection model, are also far too complicated. Multiple inheritance with its property that the first implementation encounterd in compiling makes it into the final functionality is just wrong, silly and dangerous. And there ist the problem that it is very easy to mix OO and non-OO styles and end up with a completely unusable pice of code... Numerous other problems make C++ an bad candidate to judge the merits of OO languages on it. Regards, Arno -- Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@tik.ee.ethz.ch GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F A modern US Navy cruiser now requires 26 tons of manuals. This is enough to affect the vessel's performance. -- New Scientist on the paperless office From 31016789@atphone.com Mon Mar 11 21:07:02 2002 From: 31016789@atphone.com (¾ÜÆù) Date: Mon Mar 11 21:07:02 2002 Subject: ÇÚµåÆù±îÁö ¸¶À½´ë·Î »ç¿ëÇϼ¼¿ä Message-ID: <200203112005.g2BK5K8b025846@mail.openit.de>

=BE=DC=C6=F9=BF=A1=BC=AD= =20 =C8=B9=B1=E2=C0=FB=C0=CE =C1=A6=C7=B0=C0=BB =BC=D2=B0=B3=C7=D5=B4=CF=B4=D9= .

 

 

=C1=D9=C0=CC=B0=ED =C1=D9=BF=A9=B5=B5 =C0=FC=C8=AD=C5=EB=BD=C5 =BF= =E4=B1=DD=C0=CC 2=B8=B8=BF=F8=C0=CC =B3=D1=B4=C2=B4=D9= =B8=E9=20

 =C1=F6=B1=DD =BE=DC= =C6=F9=C0=B8=B7=CE=20 =B9=D9=B2=D9=BD=CA=BD=C3=BF=E4.

=BF=F9 19,800=BF=F8 =C1=A4=BE=D7=C1=A6=B7=CE =BD=C3=B3=BB=BD=C3=BF=DC=B4=C2=20 =B9=B0=B7=D0=20 =C7=DA=B5=E5=C6=F9=B1=EE=C1=F6 =

=C6=F2=BB=FD =B0=F8=C2=A5=B0=B0=C0=BA =C5=EB=BD=C5=C0=FC=C8=AD=B8= =A6 =B9=AB=C1=A6=C7=D1 =C0=CC=BF=EB =C7=CF=BD=C7=BC=F6 =C0=D6=BD=C0=B4=CF= =B4=D9.

 

=C0=E5=C1=A1

1.=C7=D1=B1=B9=C5=EB=BD=C5=BF=E4=B1=DD =BF=F9 20=B8=B8=BF=F8=C0=CC=BB=F3=C0=CF=B0=E6=BF=EC=B5=B5

=3D=3D=3D> =BE=DC=C6=F9 19800=BF=F8 + =B1=E2=BA=BB=BF=E4=B1=DD 3000=BF=F8=C0=CC=B8=E9 =C7=D8=B0=E1

   ##=B1=B9=C1= =A6=C0=FC=C8=AD 80~90% =BA=F1=BF=EB=C0=FD=B0=A8=20

(=BF=B9) =B9=CC=B1=B9 3=BA=D0=C5=EB=C8=AD=C0=CF=B0=E6=BF=EC

-a=20 =C7=D1=B1=B9=C5=EB=BD=C5 --2300=BF=F8&n= bsp; / =B9=DD=B8=E9 =BE=DC=C6=F9=C0=BA=20 270=BF=F8=C0=CC=B8=E9=B5=CB=B4=CF=B4=D9.

 

2.=BB=E7=BF=EB=C0=CC =C6=ED=B8=AE =3D=3D=3D=3D> =C3=CA=B0=ED=BC= =D3=C5=EB=BD=C5=C8=AF=B0=E6(ADSL, cable=B8=F0=B5=A9, =C0=FC=BF=EB=BC=B1)=C0= =CC =B1=F2=B7=C1=C0=D6=B4=C2=20 =B0=F7=BF=A1=BC=AD

 =C4=C4=C7=BB=C5=CD= =B8=A6 =C4=D3 =C7=CA=BF=E4=BE=F8=C0=CC=20 =BB=E7=BF=EB=B0=A1=B4=C9.

 

3.=B6=D9=BE=EE=B3=AD =C5=EB=C8=AD=C0=BD=C1=FA =3D=3D=3D=3D=3D>= ; =C3=CA=B0=ED=BC=D3=C5=EB=BD=C5=C8=AF=B0=E6=C0=CC=B9=C7=B7=CE =C0=FC=C7=F4= =B2=F7=B1=E8=BE=F8=C0=CC

=B1=FA=B2=FD=C7=D1=20 =C0=BD=C1=FA=C0=BB=20 =B0=E6=C7=E8=C7=D2=BC=F6 =C0=D6=BD=C0=B4=CF=B4=D9.

 

4.=B2=C0 =C7=CA=BF=E4=C7=D1 =BA=D0=B5=E9  

< =B0=A1 =C1=A4 >

1.=C7=D8=BF=DC =B6=C7=B4=C2 =C1=F6=B9=E6=BF=A1 =C4=A3=C1=F6=B3=AA= =BF=AC=C0=CE=C0=CC =C0=D6=B4=C2 =BA=D0

2.=C0=AF=C7=D0=BB=FD=C0=CC =C0=D6=B4=C2 =B0=A1=C1=A4 =

3.=BD=C3=B3=BB, =BD=C3=BF=DC, =C7=DA=B5=E5=C6=F9=C0=BB =B8=B9=C0= =CC =BE=B2=B4=C2 =B0=A1=C1=A4

< =C8=B8 =BB=E7 >

1.=B1=B9=C1=A6=C0=FC=C8=AD=B8=A6 =B8=B9=C0=CC =BE=B2=B0=C5=B3=AA= =C1=F6=B9=E6, =C7=D8=BF=DC=BF=A1 =C1=F6=BB=E7, =B0=C5=B7=A1=C3=B3=B0=A1 = =C0=D6=B4=C2 =B1=E2=BE=F7

2.=B9=AB=BF=AA, =C7=D8=BF=EE, =C7=D7=B0=F8, =BF=A9=C7=E0, =BF=DC= =B1=B9=C0=CE,  

=BC=F6=C3=E2=C0=D4=BE=F7=C3=BC =B9=D7 =C1=A6=C1=B6, =B9=B0=B7=F9, =C5=EB=BD=C5, =BF=AC=B1=B8, =C6=D0=BC=C7 =B0=FC=B7=C3= =BE=F7=C3=BC=20

3.=B1=B9=B3=BB=BF=DC =B0=F8=C0=E5, =B0=C7=BC=B3=C7=F6=C0=E5, =C7= =CF=C3=BB=BE=F7=C3=BC=B8=A6 =B5=D0 =B1=E2=BE=F7 =

 

***=BB=F3=B4=E3=B9=AE=C0= =C7

T.018-343-6780

Email: 34009876@atphone.com

www.internet-phone.co.kr

 

=BE=F7=B9=AB=BF=A1 =B9=E6=C7=D8=B0=A1 =B5=C7=BE=FA=B4=D9=B8=E9 =C1= =A4=B8=BB=C1=CB=BC=DB=C7=D5=B4=CF=B4=D9.

=BC=F6= =BD=C5=C0=BB=20 =BF=F8=C4=A1=BE=CA=C0=B8=BD=C3=B8=E9 =BC=F6=BD=C5=B0=C5=BA=CE=B8=A6 =B4=AD=B7=AF=C1=D6=BC=BC=BF=E4.
From jan@gondor.com Mon Mar 11 23:36:01 2002 From: jan@gondor.com (Jan Niehusmann) Date: Mon Mar 11 23:36:01 2002 Subject: zlib issues Message-ID: <20020311223355.GA22794@gondor.com> Hi! The security bug in zlib has probably been posted on every important news site by now... for anybody who didn't hear about it: http://www.gzip.org/zlib/advisory-2002-03-11.txt gnupg 1.0.6 contains a version of zlib which seems to be vulnerable. Please consider upgrading to the latest version of zlib. Jan From mihwa38@dreamwiz.com Tue Mar 12 06:25:02 2002 From: mihwa38@dreamwiz.com (¹Ù¶÷²É) Date: Tue Mar 12 06:25:02 2002 Subject: [±¤°í] È­ÀÌÆ®µ¥ÀÌ! ²ÉÀ¸·Î ´ç½ÅÀÇ »ç¶ûÀ»... Message-ID: ¢¿¢½¡Ú [È­ÀÌÆ®µ¥ÀÌ] ¼±¹°Àº "ÇູÇѲɹæ"¿¡¼­...
   
Çϴÿ¡ Âù¶õÇÑ º°ÀÌ ºû³ª°í ¶¥¿¡´Â ¾Æ¸§´Ù¿î ²ÉÀÌ ÇǾµíÀÌ,
»ç¶÷¿¡°Ô´Â µû½ºÇÑ »ç¶ûÀÌ ÀÖ¾î¾ß ÇÑ´Ù....

Çöó¿öµµ»çÀÇ "ÇູÇÑ ²É¹æ"¿¡¼­ [È­ÀÌÆ®µ¥ÀÌ] ¼±¹°À» ÁغñÇϼ¼¿ä!

È¥Çղɹٱ¸´Ï+»çÅÁ
60,000¿ø

Àå¹ÌÇÏÆ®¹Ù±¸´Ï+
»çÅÁ
65,000¿ø
100¼ÛÀ̲ɹٱ¸´Ï+
»çÅÁ
130,000¿ø

100¼ÛÀÌ»óÀÚ+»çÅÁ
130,000¿ø

100¼ÛÀÌÇÏÆ®¹Ú½º+
»çÅÁ
150,000¿ø

20¼ÛÀÌ»óÀÚ+»çÅÁ
50,000¿ø

ÇÏÆ®¹Ú½º+»çÅÁ
100,000¿ø

50¼ÛÀÌÇÏÆ®(»¡°­)+
»çÅÁ
80,000¿ø

25¼ÛÀÌÇÏÆ®+»çÅÁ
60,000¿ø

»¡°­Àå¹Ì²É´Ù¹ß+»çÅÁ
50,000¿ø

20¼ÛÀÌÀå¹Ì²É´Ù¹ß+
»çÅÁ
45,000¿ø
ºÐÈ«Àå¹Ì²É´Ù¹ß+»çÅÁ
50,000¿ø
È¥Çղɴٹß+»çÅÁ
50,000¿ø
100¼ÛÀ̲ɴٹß+»çÅÁ
130,000¿ø

 



     È­ÀÌÆ®µ¥ÀÌ ¿¹¾àÁÖ¹®À» ¹Þ½À´Ï´Ù.(¹è´Þ½Ã°£Àº ¿ÀÀü / ¿ÀÈÄ ±¸ºÐÇÕ´Ï´Ù)
    * È­ÀÌÆ®µ¥ÀÌ ¹è´ÞÁÖ¹®Àº ÁÖ¹®ÆøÁÖ·Î ÀÎÇØ ´çÀÏ¿¡ ÇÑÇÏ¿© ¿ÀÀü/¿ÀÈÄ ¹è´ÞÀ» ÇÕ´Ï´Ù.
    * »çÅÁÀº Áö¿ªº°·Î ´Ù¸¦ ¼öµµ ÀÖ½À´Ï´Ù.
    »çÀü ¾çÇؾøÀÌ ¸ÞÀÏÀ» º¸³»¼­ Á˼ÛÇÕ´Ï´Ù.
    º» ¸ÞÀÏÀº ÀÎÅÍ³Ý»ó¿¡ ¿Ã¶ó¿Â ¸ÞÀÏÁÖ¼Ò¸¦ ¹ßÃéÇÏ¿© ¹ß¼ÛÇÏ¿´½À´Ï´Ù.
    º» ¸ÞÀÏÀº Á¤º¸ Åë½Å¸Á ÀÌ¿ë ÃËÁø ¹× Á¤º¸º¸È£ µî¿¡ °üÇÑ ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÑ [±¤°í] ¸ÞÀÏÀÔ´Ï´Ù.

    ¿øÄ¡ ¾ÊÀ¸½Ã¸é »èÁ¦ÇϽðųª, [¼ö½Å°ÅºÎ]¸¦ ´­·¯ÁÖ¼¼¿ä!

Copyright ¨Ï 2001-2002   J&Y Á¶³ª´Ü Á¤º¸Åë½Å. All Rights Reserved.
From dzon21@netian.com Thu Mar 14 03:46:02 2002 From: dzon21@netian.com (dazon21) Date: Thu Mar 14 03:46:02 2002 Subject: [±¤°í]À̺¸´Ù ´õ½Î¸éµÎ¹èȯºÒ/¼îÅ·°æ¸Å6ź(¼îÇθô±¤°íÀÔ´Ï´Ù) Message-ID: 5ÀÏ ÀåÅÍÇà»ç!

 

¡Ú ȸ¿øÀ¸·Î °¡ÀÔÇϽøé À̽´¿Í À̺¥Æ®µî,¾ËÂ¥ Á¤º¸¿Í °¢Á¾ ÇýÅÃÀ» ¹ÞÀ¸½Ç ¼ö ÀÖ½À´Ï´Ù.
¡Ú¼îÇθô ¿î¿µ¿¡ °ü½É ÀÖÀ¸½ÅºÐÀº [¿©±â]

 ±ÍÇÏÀÇ ¸áÁÖ¼Ò´Â À¥¼­ÇÎÁß ¾Ë°Ô µÇ¾úÀ¸¸ç ¸áÁÖ¼Ò ÀÌ¿ÜÀÇ ´Ù¸¥ Á¤º¸´Â ÀÏü ¾ËÁö ¸øÇÕ´Ï´Ù.
 µÎ ¹ø ´Ù½Ã ¸áÀ» º¸³»Áö ¾ÊÀ» °ÍÀÌ¿À´Ï ÀϺη¯ ¼ö½Å°ÅºÎ ÇÏÁö ¾ÊÀ¸¼Åµµ ÁÁ½À´Ï´Ù.
                                                  [¼ö½Å°ÅºÎ]

From madhatter@necroerotic.org Thu Mar 14 21:14:01 2002 From: madhatter@necroerotic.org (Kevin McMullen) Date: Thu Mar 14 21:14:01 2002 Subject: gpgme documentation Message-ID: <20020314122141.A30169@necroerotic.org> hello, i see at the URL http://www.gnu.org/directory/GPGME.html that there seem to be plans for documentation, but none right now. Is there an expected time that there will be documentation on using the library? Or if I'm just an idiot and there already is, where can I find it? Thanks. From marcus@gnu.org Thu Mar 14 22:06:01 2002 From: marcus@gnu.org (Marcus Brinkmann) Date: Thu Mar 14 22:06:01 2002 Subject: gpgme documentation In-Reply-To: <20020314122141.A30169@necroerotic.org> References: <20020314122141.A30169@necroerotic.org> Message-ID: <20020314210312.GC9211@gnu.org> On Thu, Mar 14, 2002 at 12:21:41PM -0800, Kevin McMullen wrote: > hello, i see at the URL http://www.gnu.org/directory/GPGME.html that there > seem to be plans for documentation, but none right now. Is there an > expected time that there will be documentation on using the library? Or > if I'm just an idiot and there already is, where can I find it? Thanks. Since version 0.3.1 or so, GPGME comes with a reference manual in texinfo format in the doc/ directory. We should put it online one of these days, but it will also be built by default if you build the library. Thanks, Marcus From wk@gnupg.org Fri Mar 15 14:52:02 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 15 14:52:02 2002 Subject: w32 test please Message-ID: <87vgby9c09.fsf@alberti.gnupg.de> Hi! I have just created a new binary package of GnuPG for Windows to fix the zlib bug. I have currently no running Windows system here, so I need a volunteer to test this build. It is available as ftp://ftp.gnupg.org/gcrypt/binary/test/gnupg-w32-1.0.6-2.zip (689k) As soon as a get a report that there are no new bugs in it, I will move it one directory up. The changes are in the diff file and only related to the compression code. tia, Werner From wk@gnupg.org Fri Mar 15 15:56:05 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 15 15:56:05 2002 Subject: [Announce] GnuPG fix for included zlib Message-ID: <871yemar0b.fsf@alberti.gnupg.de> --=-=-= Hi! As you probably all know, a security problem with the compress library zlib has been found which affects a lot of software. For details see: http://www.zlib.org/advisory-2002-03-11.txt and the security announcements for your OS. GnuPG does also use zlib; however in most environments the system provided zlib is used. So an update to this system library is sufficient to fix the problem in GnuPG. On systems without a installed zlib, the GnuPG build process automatically includes the zlib copy which come with it. This may also be forced by using the --with-included-zlib configure option. On those systems, GnuPG needs to be updated! A patch with instructions is attached to this mail. Note, that the MS-Windows version is also affected by this bug; an updated binary package will be available soon. Werner --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=gnupg-zlib.patch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message This is a patch against gnupg 1.0.6 to fix the security bug in the zlib code. Please note that on most systems the zlib code which comes with GnuPG is not used because usually the zlib provided by the system is used. This is in almost all cases a shared library, so it is sufficient to upgrade this one. If the system does only provide a static library, you have to build GnuPG again. Apply this patch if your system does not provide a usable zlib or you configured GnuPG using the option --with-included-zlib. The patch file is GnuPG signed; you might want to check the signature after visual inspection that the patch file itself is not a compressed one (which might trigger the bug). gpg --verify gnupg-zlib.patch Change to the source directory (cd gnupg-1.0.6) and enter: patch -p2 Merged changes from zlib 1.1.4. diff -u orig/gnupg-1.0.6/zlib/deflate.c gnupg-stable/zlib/deflate.c --- orig/gnupg-1.0.6/zlib/deflate.c Wed Jan 13 14:12:48 1999 +++ gnupg-stable/zlib/deflate.c Tue Mar 12 10:34:29 2002 @@ -1,5 +1,5 @@ /* deflate.c -- compress data using the deflation algorithm - * Copyright (C) 1995-1998 Jean-loup Gailly. + * Copyright (C) 1995-2002 Jean-loup Gailly. * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -47,12 +47,12 @@ * */ -/* @(#) $Id: deflate.c,v 1.2 1999/01/13 13:12:48 koch Exp $ */ +/* @(#) $Id: deflate.c,v 1.2.2.1 2002/03/12 09:34:29 werner Exp $ */ #include "deflate.h" const char deflate_copyright[] = - " deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly "; + " deflate 1.1.4 Copyright 1995-2002 Jean-loup Gailly "; /* If you use the zlib library in a product, an acknowledgment is welcome in the documentation of your product. If for some reason you cannot @@ -242,7 +242,7 @@ windowBits = -windowBits; } if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED || - windowBits < 8 || windowBits > 15 || level < 0 || level > 9 || + windowBits < 9 || windowBits > 15 || level < 0 || level > 9 || strategy < 0 || strategy > Z_HUFFMAN_ONLY) { return Z_STREAM_ERROR; } diff -u orig/gnupg-1.0.6/zlib/infblock.c gnupg-stable/zlib/infblock.c --- orig/gnupg-1.0.6/zlib/infblock.c Wed Jan 13 14:12:48 1999 +++ gnupg-stable/zlib/infblock.c Tue Mar 12 10:19:38 2002 @@ -1,5 +1,5 @@ /* infblock.c -- interpret and process block types to last block - * Copyright (C) 1995-1998 Mark Adler + * Copyright (C) 1995-2002 Mark Adler * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -249,10 +249,12 @@ &s->sub.trees.tb, s->hufts, z); if (t != Z_OK) { - ZFREE(z, s->sub.trees.blens); r = t; if (r == Z_DATA_ERROR) + { + ZFREE(z, s->sub.trees.blens); s->mode = BAD; + } LEAVE } s->sub.trees.index = 0; @@ -313,11 +315,13 @@ t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) & 0x1f), s->sub.trees.blens, &bl, &bd, &tl, &td, s->hufts, z); - ZFREE(z, s->sub.trees.blens); if (t != Z_OK) { if (t == (uInt)Z_DATA_ERROR) + { + ZFREE(z, s->sub.trees.blens); s->mode = BAD; + } r = t; LEAVE } @@ -329,6 +333,7 @@ } s->sub.decode.codes = c; } + ZFREE(z, s->sub.trees.blens); s->mode = CODES; case CODES: UPDATE diff -u orig/gnupg-1.0.6/zlib/infcodes.c gnupg-stable/zlib/infcodes.c --- orig/gnupg-1.0.6/zlib/infcodes.c Wed Jan 13 14:12:48 1999 +++ gnupg-stable/zlib/infcodes.c Tue Mar 12 10:19:38 2002 @@ -1,5 +1,5 @@ /* infcodes.c -- process literals and length/distance pairs - * Copyright (C) 1995-1998 Mark Adler + * Copyright (C) 1995-2002 Mark Adler * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -196,15 +196,9 @@ Tracevv((stderr, "inflate: distance %u\n", c->sub.copy.dist)); c->mode = COPY; case COPY: /* o: copying bytes in window, waiting for space */ -#ifndef __TURBOC__ /* Turbo C bug for following expression */ - f = (uInt)(q - s->window) < c->sub.copy.dist ? - s->end - (c->sub.copy.dist - (q - s->window)) : - q - c->sub.copy.dist; -#else f = q - c->sub.copy.dist; - if ((uInt)(q - s->window) < c->sub.copy.dist) - f = s->end - (c->sub.copy.dist - (uInt)(q - s->window)); -#endif + while (f < s->window) /* modulo window size-"while" instead */ + f += s->end - s->window; /* of "if" handles invalid distances */ while (c->len) { NEEDOUT diff -u orig/gnupg-1.0.6/zlib/inffast.c gnupg-stable/zlib/inffast.c --- orig/gnupg-1.0.6/zlib/inffast.c Wed Jan 13 14:12:48 1999 +++ gnupg-stable/zlib/inffast.c Tue Mar 12 10:19:38 2002 @@ -1,5 +1,5 @@ /* inffast.c -- process literals and length/distance pairs fast - * Copyright (C) 1995-1998 Mark Adler + * Copyright (C) 1995-2002 Mark Adler * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -93,28 +93,41 @@ /* do the copy */ m -= c; - if ((uInt)(q - s->window) >= d) /* offset before dest */ - { /* just copy */ - r = q - d; - *q++ = *r++; c--; /* minimum count is three, */ - *q++ = *r++; c--; /* so unroll loop a little */ - } - else /* else offset after destination */ + r = q - d; + if (r < s->window) /* wrap if needed */ { - e = d - (uInt)(q - s->window); /* bytes from offset to end */ - r = s->end - e; /* pointer to offset */ - if (c > e) /* if source crosses, */ + do { + r += s->end - s->window; /* force pointer in window */ + } while (r < s->window); /* covers invalid distances */ + e = s->end - r; + if (c > e) { - c -= e; /* copy to end of window */ + c -= e; /* wrapped copy */ do { - *q++ = *r++; + *q++ = *r++; } while (--e); - r = s->window; /* copy rest from start of window */ + r = s->window; + do { + *q++ = *r++; + } while (--c); } + else /* normal copy */ + { + *q++ = *r++; c--; + *q++ = *r++; c--; + do { + *q++ = *r++; + } while (--c); + } + } + else /* normal copy */ + { + *q++ = *r++; c--; + *q++ = *r++; c--; + do { + *q++ = *r++; + } while (--c); } - do { /* copy all or what's left */ - *q++ = *r++; - } while (--c); break; } else if ((e & 64) == 0) diff -u orig/gnupg-1.0.6/zlib/inftrees.c gnupg-stable/zlib/inftrees.c --- orig/gnupg-1.0.6/zlib/inftrees.c Wed Jan 13 14:12:49 1999 +++ gnupg-stable/zlib/inftrees.c Tue Mar 12 10:19:38 2002 @@ -1,5 +1,5 @@ /* inftrees.c -- generate Huffman trees for efficient decoding - * Copyright (C) 1995-1998 Mark Adler + * Copyright (C) 1995-2002 Mark Adler * For conditions of distribution and use, see copyright notice in zlib.h */ @@ -11,7 +11,7 @@ #endif const char inflate_copyright[] = - " inflate 1.1.3 Copyright 1995-1998 Mark Adler "; + " inflate 1.1.4 Copyright 1995-2002 Mark Adler "; /* If you use the zlib library in a product, an acknowledgment is welcome in the documentation of your product. If for some reason you cannot @@ -104,8 +104,7 @@ /* Given a list of code lengths and a maximum table size, make a set of tables to decode that set of codes. Return Z_OK on success, Z_BUF_ERROR if the given code set is incomplete (the tables are still built in this - case), Z_DATA_ERROR if the input is invalid (an over-subscribed set of - lengths), or Z_MEM_ERROR if not enough memory. */ + case), or Z_DATA_ERROR if the input is invalid. */ { uInt a; /* counter for codes of length k */ @@ -231,7 +230,7 @@ /* allocate new table */ if (*hn + z > MANY) /* (note: doesn't matter for fixed) */ - return Z_MEM_ERROR; /* not enough memory */ + return Z_DATA_ERROR; /* overflow of MANY */ u[h] = q = hp + *hn; *hn += z; diff -u orig/gnupg-1.0.6/zlib/zlib.h gnupg-stable/zlib/zlib.h --- orig/gnupg-1.0.6/zlib/zlib.h Wed Jan 13 14:12:49 1999 +++ gnupg-stable/zlib/zlib.h Tue Mar 12 10:19:41 2002 @@ -1,7 +1,7 @@ /* zlib.h -- interface of the 'zlib' general purpose compression library - version 1.1.3, July 9th, 1998 + version 1.1.4, March 11th, 2002 - Copyright (C) 1995-1998 Jean-loup Gailly and Mark Adler + Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages @@ -37,7 +37,7 @@ extern "C" { #endif -#define ZLIB_VERSION "1.1.3" +#define ZLIB_VERSION "1.1.4" /* The 'zlib' compression library provides in-memory compression and -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6d-cvs (GNU/Linux) iD8DBQE8keynaLeriVdUjc0RAnZaAJ0Q5AX4oAWCkkE5Yqxb4mOcY8rhDQCfTd7D TR5ke8FWP2dRrl/EP5AU6i4= =uKF5 -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From hideki@allcity.net Fri Mar 15 15:59:01 2002 From: hideki@allcity.net (Hideki Saito) Date: Fri Mar 15 15:59:01 2002 Subject: w32 test please In-Reply-To: <87vgby9c09.fsf@alberti.gnupg.de> References: <87vgby9c09.fsf@alberti.gnupg.de> Message-ID: <200203151457.g2FEvQs24248@server-1.visp.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Working just fine :-) >Hi! > >I have just created a new binary package of GnuPG for Windows to fix >the zlib bug. I have currently no running Windows system here, so I >need a volunteer to test this build. It is available as > > ftp://ftp.gnupg.org/gcrypt/binary/test/gnupg-w32-1.0.6-2.zip (689k) > >As soon as a get a report that there are no new bugs in it, I will >move it one directory up. The changes are in the diff file and only >related to the compression code. > >tia, > > Werner > > > >_______________________________________________ >Gnupg-devel mailing list >Gnupg-devel@gnupg.org >http://lists.gnupg.org/mailman/listinfo/gnupg-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6-2 (MingW32) Comment: For info see http://www.gnupg.org iD8DBQE8kgvv4VMN+RBdJUkRAtksAKCtdUbpgvZpNlH3Rpn01tnz5H7+qwCgmiZn LlZZlllX3rgVNodXtMNsVWc= =zbQN -----END PGP SIGNATURE----- -- Hideki Saito mailto:hideki@allcity.net From wk@gnupg.org Fri Mar 15 19:16:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 15 19:16:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <3C8A4887.60004@beonex.com> (Ben Bucksch's message of "Sat, 09 Mar 2002 18:38:15 +0100") References: <3C8A2228.4020408@beonex.com> <877kold9mq.fsf@alberti.gnupg.de> <3C8A4887.60004@beonex.com> Message-ID: <871yelaedn.fsf@alberti.gnupg.de> On Sat, 09 Mar 2002 18:38:15 +0100, Ben Bucksch said: > That Mozilla relicensing was intended for Mozilla being *used* in GPL > apps like Galeon or Evolution, not for having GPL code included in This turned out to be a very good decision; Galeon is a pretty useful browser for websites which won't show up nicely using Lynx or w3m ;-) > Believe me, I created Beonex Communicator, and I really try to keep > everything completely Open-Source. But users want a browser that > works, with Flash and all the other goodies, *now*. They don't want to If users wants that they should go and get this stuff from elsewhere but don't expect that the GNU project trades Freedom for convenience of so-called "must-haves". Most sites are pretty useless for any security aware users because they are not usable without JavaScript. > Please don't make these goals incompatible. As I said, I choose a > slightly less compatible Open-Source implementation over the PGP and compatible with OpenPGP? They don't even support signing subkeys which is really weird as OpenPGP is (too) closely based on the protocol used by PGP >=5. > include in the browser? Surely, PGP would be desireable. Do you think > that the Abgeordneten would accept not to be able to see Flash content? I hope they can stay away from this stuff. Such kind of easy to trojan software can lead to a lot of work restoring valuable documents. Well, if the office of the chancellor had used such a software, we might had an opportunity to know the content of all the files Mr. Kohl's officers had to purge from their servers after the lost election in 98 ;-) > And last but not least, your lib probably has 0 chance to be part of > the base Mozilla, if it is not MPL/GPL/LGPL tripple-licensed. Any such > plugin would surely live a third-party life, left bitrotting after a > few months of frequent Mozilla changes. I don't care. > As much as I'd like to, I cannot change the content that is out there > on the web. I you have something important to say or write, you should do it in a standard format. If not, well it can't be that important or there is no need to attract more customers. > Being locked out of a few major sites makes users already consider to > switch the browser. You guess which one that is. I am not on a crusade to ban a specific proprietary browser. > I haven't looked at all at it, because its author basically says that > it's just a little toy that he dumped on an ftp server, not really > ready for use. A friend checked it out under Windows and according to him it basically works and he could exchange encrypted or signed mails with Mutt and Gnus users. We will see whether someone starts to work on it. > Have you audited it security-wise? I don't know enough about the > problems there (exec() etc.) to do that. I have not looked at it. Werner From rmartini@cipsga.org.br Fri Mar 15 21:44:02 2002 From: rmartini@cipsga.org.br (Renato Martini) Date: Fri Mar 15 21:44:02 2002 Subject: w32 test please In-Reply-To: <87vgby9c09.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Fri, 15 Mar 2002, Werner Koch wrote: > Date: Fri, 15 Mar 2002 14:49:42 +0100 > From: Werner Koch > To: gnupg-devel@gnupg.org > Subject: w32 test please > > Hi! > > I have just created a new binary package of GnuPG for Windows to fix > the zlib bug. I have currently no running Windows system here, so I > need a volunteer to test this build. It is available as > Hi! My simple test... ____________________________________________________________________ OS: Windows Millennium [Version 4.90.3000] 1. create keyring *sec.key 2048 bits* OKAY 2. import public keys OKAY 3. export public keys ("gpg -a --export -o pub_keys") OKAY 4. export secret keys ("gpg -a -o sec_key --export-secret-keys") OKAY 5. Generate and verify a detached-sign OKAY 6. Encrypt and sign a file OKAY ** NOTE: The gpg diplays the an old version (GnuPG v1.0.4-1) at the openpgp heading - -------------------------------------------------------------------------- Bye - --------- __|_ _| _ \ __| __| \ | Renato Martini ::: Diretor Administrativo ( | __/\__ \ (_ | _ \ | http://www.cipsga.org.br \___|___|_| ____/\___|_/ _\ | http://gnupg.unixsecurity.com.br - ----------------------------------------------------------------------- "O Fantasia, che dei tempi e delle distanze fai il tuo giuoco audace!" (Gabriele d'Annunzio) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8k68RYogE2yD8bPYRA3WNAJ9jWCihYsKFItoU4RH9QvkBfsm/IACfdjTk qwRFTfm+b3J866rvxCh60XU= =yltW -----END PGP SIGNATURE----- From wk@gnupg.org Fri Mar 15 21:58:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Mar 15 21:58:01 2002 Subject: w32 test please In-Reply-To: (Renato Martini's message of "Sat, 16 Mar 2002 17:45:44 -0300 (BRT)") References: Message-ID: <87elil8sct.fsf@alberti.gnupg.de> On Sat, 16 Mar 2002 17:45:44 -0300 (BRT), Renato Martini said: > ** NOTE: > The gpg diplays the an old version (GnuPG v1.0.4-1) at the openpgp heading What does gpg --version say? Perhaps you run it with -v and you are seeing the header lines of files generated with an old versions? Thanks for the tests, Werner From rmartini@cipsga.org.br Sat Mar 16 03:28:01 2002 From: rmartini@cipsga.org.br (Renato Martini) Date: Sat Mar 16 03:28:01 2002 Subject: w32 test please In-Reply-To: <87elil8sct.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Fri, 15 Mar 2002, Werner Koch wrote: > Date: Fri, 15 Mar 2002 21:54:10 +0100 > From: Werner Koch > To: Renato Martini > Cc: gnupg-devel@gnupg.org > Subject: Re: w32 test please > > On Sat, 16 Mar 2002 17:45:44 -0300 (BRT), Renato Martini said: > > > ** NOTE: > > The gpg diplays the an old version (GnuPG v1.0.4-1) at the openpgp heading > > What does gpg --version say? Perhaps you run it with -v and you are > seeing the header lines of files generated with an old versions? Hi Werner! No problems man! There was an old file signed with gpg 1.0.4 in the gpg directory... So, there aren't problems, the release works *really* fine! best regards - --------- __|_ _| _ \ __| __| \ | Renato Martini ::: Diretor Administrativo ( | __/\__ \ (_ | _ \ | http://www.cipsga.org.br \___|___|_| ____/\___|_/ _\ | http://gnupg.unixsecurity.com.br - ----------------------------------------------------------------------- "O Fantasia, che dei tempi e delle distanze fai il tuo giuoco audace!" (Gabriele d'Annunzio) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8k/+NYogE2yD8bPYRA60KAJ9jTg0yFDUsbXU8keeknRQgoGscnwCggSwE MDKTGDvDKxgx4RYuSHa+o4Q= =8rjK -----END PGP SIGNATURE----- From Enzo Michelangeli" <877kold9mq.fsf@alberti.gnupg.de> Message-ID: <022f01c1cc94$b7f99da0$0200000a@noip.com> ----- Original Message ----- From: "Werner Koch" To: Sent: Saturday, 09 March, 2002 11:49 PM Subject: Re: Mozilla, License (again), PPG, GPGME [...] > > OpenPGP needs to have a nice UI for it, if it ever wants to be a > > widely used standard. I know the security concerns, but I think they > > Yes, definitely. Noone as volunteered to make GPA or any of the other > frontends a workable solution, so I fear that without a proper funding > there will be no good GUI in the near future. I know that this is > very important. I have a list of things in mind which should be > undertaken by further GPA (or whatever) development. Timo Schultz's WinPT (www.winpt.org) looks pretty nice to me, and should definitely help PGP users willing to migrate smoothly to GnuPG. Did I miss any horrible hidden shortcoming? :-) Enzo From ddm@pizzashack.org Sat Mar 16 18:45:01 2002 From: ddm@pizzashack.org (Derek D. Martin) Date: Sat Mar 16 18:45:01 2002 Subject: gpg subkeys, revisited In-Reply-To: <1016257151.16327.1.camel@allevil> References: <20020315233857.A6820@pizzashack.org> <1016257151.16327.1.camel@allevil> Message-ID: <20020316124152.A7155@pizzashack.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At some point hitherto, Douglas Calvert hath spake thusly: > On Fri, 2002-03-15 at 23:38, Derek D. Martin wrote: > > I missed it the first time, but it sounds like I'm having the same > > exact problem as Douglas Calvert had a couple of weeks ago: [SNIP] > No dice. There is a problem with the keyservers. They cannot handle > multiple subkeys. [SNIP] Ok thanks, but well, my problem is a bit more involved than just that. Basically the problem is that on the machine that I read mail, I accidentally deleted my old encryption subkey. I still have other subkeys on that keyring associated with my signing key (0x81CFE75D) that I need to keep. But obviously, I want to keep my old encryption key around, so I can decrypt messages that are sent to me by people who haven't yet gotten the new subkey from me, or forgot to import it, or for messages I already have hanging around... I have a copy of the old subkey on another machine. That old keyring does not have the other subkeys that I wish to keep. What I need to do is merge the two keyrings. I can do this with the PUBLIC subkeys no problem. However, GPG will not let me incorporate the SECRET subkey, no matter what I try. I've tried using both --export-secret-key and --export-secret-subkey on the export side of things, and I always use --allow-secret on the import side, but I only get error messages from gpg as such: $ ssh otherhost gpg -a --export-secret-subkey ddm |gpg --allow-secret --import ddm@otherhost's password: gpg: key 81CFE75D: already in secret keyring gpg: Total number processed: 1 gpg: secret keys read: 1 gpg: secret keys unchanged: 1 So, gpg seems to fail to realize that there are subkeys in the exported block that are not in the local copy, and refuses to import them. Whether or not this is intended behavior, I think this is a bug. Otherwise, there's no way to recover accidentally deleted subkeys, and if you DO accidentally delete a subkey, your options would be to maintain two different keyrings (one with the deleted one and the other with all the other keys), or throw up your hands in frustration and generate a whole new key. And if you have old messages that you still need to decrypt with the old key, the latter isn't even really an option. Neither of those options is ideal. IMO, the best solution is for gpg to allow the import of secret subkeys. Please note: I'm not on gnupg-devel, so please CC me ONLY if your reply is going to be ONLY on that list (I'm on gnupg-users). Thanks. - -- Derek Martin ddm@pizzashack.org - --------------------------------------------- I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8k4PedjdlQoHP510RAoVjAKCbgELUN80DO5xj+/Stl6luJpsM7QCeK+7L 7fTlskD+WiOs0fQjNcXkezM= =IgBT -----END PGP SIGNATURE----- From redbird@rbisland.cx Sun Mar 17 01:59:01 2002 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Mar 17 01:59:01 2002 Subject: Easy Install 1.0.6r5: dynload and zlib Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So far it seems like the dynload patch is working for everyone except for a very few of us, and even then it will work with a little hacking. So, with the zlib bug announced and fixed, I want to get 1.0.6r5 out soon. Since Apple still has not updated their dynamically loading version of zlib, 1.0.6r5 will continue to statically link against zlib, but other things will be dynamically linked against where possible (as I understand it, GnuPG should try to dynamically link against libraries when dynload is enabled by default). I haven't heard from Chad lately, so I don't know if he'll be doing this next release or not. Probably not tomorrow but on Monday I'm going to try to get an Installer package together if we still haven't heard from Chad. Also, I'll finish updating the documentation and post the dynload patch and a link to the zlib 1.1.4 patch. BTW, for those who haven't being paying attention, zlib 1.1.3, which GnuPG and about a million other programs use, has a double free error in it that might allow an attacker to run arbitrary code. zlib 1.1.4 fixes this and a couple of other small issues. I have yet to mention this because I didn't want all our users to panic before we had new binaries posted. - -- Gordon Worley `When I use a word,' Humpty Dumpty http://www.rbisland.cx/ said, `it means just what I choose redbird@rbisland.cx it to mean--neither more nor less.' PGP: 0xBBD3B003 --Lewis Carroll -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: http://www.rbisland.cx/publickeys.html iEYEARECAAYFAjyT6eYACgkQMDmH6OHSe1sgGwCgjGP1RVP832qRLlDosrIOy2bW e7UAnAwojPruWeLH5PLha4eZ8+o0TGp+ =aCPl -----END PGP SIGNATURE----- From redbird@rbisland.cx Sun Mar 17 02:15:02 2002 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Mar 17 02:15:02 2002 Subject: Easy Install 1.0.6r5: dynload and zlib In-Reply-To: Message-ID: <15492819-3944-11D6-8893-000A27B4DEFC@rbisland.cx> On Saturday, March 16, 2002, at 07:56 PM, Gordon Worley wrote: Oops, I typed the wrong address again. Oh well, I guess these slip ups at least let everyone know what's up on the Mac side from time to time. ;-) -- Gordon Worley `When I use a word,' Humpty Dumpty http://www.rbisland.cx/ said, `it means just what I choose redbird@rbisland.cx it to mean--neither more nor less.' PGP: 0xBBD3B003 --Lewis Carroll From rjhansen@inav.net Sun Mar 17 08:28:02 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Sun Mar 17 08:28:02 2002 Subject: GPGME and Weird Keys Message-ID: <1016350036.23132.20.camel@numbers.robnet.net> I've got a strange bug which is most likely either a bug in GPGME, or else a bizarre key that GPG is able to show just fine, but GPGME can't. (Of course, my own code is utterly bug-free and has never known the slightest defect or fault... :) ) I've been tearing my head out over this one for days now; there are two keys which will sometimes render correctly, but which more often than not will render incorrectly. I can query everything about these keys except for their names, which strikes me as really strange--for every given key at index 0 there ought to be a valid name/email/etc. So finally in despair, I used gpg_key_get_as_xml(foo) to dump out key data of each key as I was querying it. A GpgmeKey with queryable names, after having been run through gpgme_key_get_as_xml(): 3D8AF1B209AC0A6A 7A1A407FB1CA7E4EAE85E7303D8AF1B209AC0A6A 17 1024 900443902 L. Sassaman <rabbi@NO.SPAM.quickie.net> L. Sassaman rabbi@NO.SPAM.quickie.net << given this is Len's key, many many more userids deleted... >> D9CE865681451634 16 2048 900443903 ... and a keyblock which apparently only has queryable keyID, fingerprint, algorithm, length and creation date, after being run through gpgme_key_get_as_xml(): 1E419D60B21D6AA7 32002537B225D1613F1008B0C3F666DE 0 2048 924419219 ... Now, when I do "gpg --list-key B21D6AA7", I get: pub 2048R/B21D6AA7 1999-04-18 Ted Parvu uid Ted Parvu uid Ted Parvu (All email addresses are spamblocked. The spamblocking isn't in the native data, o'course.) ... So apparently there's some information stuck in the key data which GPGME simply isn't getting, isn't reading, isn't--well, something isn't getting processed/handled appropriately. Is this a known bug? Are there any workarounds? From redbird@rbisland.cx Sun Mar 17 15:56:02 2002 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Mar 17 15:56:02 2002 Subject: GPGME and Weird Keys In-Reply-To: <1016350036.23132.20.camel@numbers.robnet.net> Message-ID: On Sunday, March 17, 2002, at 02:27 AM, Robert J. Hansen wrote: > Is this a known bug? Are there any workarounds? Well, I know about it, but I just figured I had a bad key from someone. At any rate, the way I get around it in GPGKeys on OS X is to put the key listing code inside an error handling block. Then I just return an error saying `hey, there's a bad key' and leave it at that. Also, it may be helpful to print out the xml representation of the key for the user. -- Gordon Worley `When I use a word,' Humpty Dumpty http://www.rbisland.cx/ said, `it means just what I choose redbird@rbisland.cx it to mean--neither more nor less.' PGP: 0xBBD3B003 --Lewis Carroll From pgut001@cs.auckland.ac.nz Mon Mar 18 05:33:01 2002 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Mon Mar 18 05:33:01 2002 Subject: Mozilla, License (again), PPG, GPGME Message-ID: <200203180429.QAA97621@ruru.cs.auckland.ac.nz> Arno Wagner writes: >Just for the record that is > > M- Does OO sync with how we think? > Hatton, L. > IEEE Software , Volume: 15 Issue: 3 , May-June 1998 > Page(s): 46 -54 There are a number of other analyses of OO available which point out problems, including some OO aspects which are so problematic that they can be used as warning signs for code bugs: -- Snip -- [...] Examples of semantic complexity which go beyond obvious factors such as the choice of algorithm include the fact that recursive functions are harder to comprehend than non-recursive ones, the fact that linked lists are more difficult to comprehend than arrays, and the use of certain OO techniques which lead to non-linear code which is more difficult to follow than non-OO equivalents [ ][ ] (so much so that the presence of indicators such as a high use of method invocation and inheritance has been used as a means of identifying fault-prone C++ classes [ ][ ]). [ ] .Does OO Sync with How We Think?., Les Hatton, IEEE Software, Vol.15, No.3 (May/June 1998), p.46. [ ] .Experimental assessment of the effect of inheritance on the maintainability of object-oriented systems., R.Harrison, S.Counsell, and R.Nithi, The Journal of Systems and Software, Vol.52, No.2/3 (1 June 2000), p.173. [ ] .Exploring the relationships between design measures and software quality in object-oriented systems., Lionel Brand, Jürgen Wüst, John Daly, and D.Victor Porter, The Journal of Systems and Software, Vol.51, No.3 (1 May 2000), p.245. [ ] .An Empirical Investigation of an Object-Oriented Software System., Michelle Cartwright and Martin Shepperd, IEEE Transactions on Software Engineering, Vol.26, No.8 (August 2000), p.786. -- Snip -- (Excuse the broken formatting, it's a cut&paste from a MS doc). Peter. From ajs@ajs.com Mon Mar 18 15:27:01 2002 From: ajs@ajs.com (Aaron Sherman) Date: Mon Mar 18 15:27:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <200203180429.QAA97621@ruru.cs.auckland.ac.nz> References: <200203180429.QAA97621@ruru.cs.auckland.ac.nz> Message-ID: <1016461508.11412.520.camel@pps> On Sun, 2002-03-17 at 23:29, Peter Gutmann wrote: > Arno Wagner writes: > > >Just for the record that is > > > > M- Does OO sync with how we think? > > Hatton, L. > > IEEE Software , Volume: 15 Issue: 3 , May-June 1998 > > Page(s): 46 -54 > > There are a number of other analyses of OO available which point out problems, > including some OO aspects which are so problematic that they can be used as > warning signs for code bugs: It has always been my impression that OO was going through a stage where it was the new technique, but that in the long run, we'd learn to incorporate the OO paradigm into our toolbox without letting it take over every line of code produced (just as many features of functional programming have been absorbed by higher-level procedural languages like Perl, Python, etc). The idea that thing X is of class Y, which is a sub-class of Z makes sense, and IS the way we think about certain aspects of our world. It is, if you will pardon the metaphor, our noun-think. We also have a verb-think which is mostly procedural in nature: "go to the store. buy eggs. come home. cook eggs." You will note that we do not use the passive voice by default: "I will have been caused to go to the store. The eggs will be cooked now." Until programming *techniques* begin to mature to the point where we can flow between the paradigms, we will continue to mis-apply them and thereby increase the complexity of our code. From daloonim@hanmail.net Mon Mar 18 21:22:02 2002 From: daloonim@hanmail.net (¾ßÈÄ) Date: Mon Mar 18 21:22:02 2002 Subject: ÀÌ»Û º½ ºê¶ó¿ì½º¸¦ ²ÇÂ¥·Î µå¸®´Â °÷!![±¤~~~°í] Message-ID: <200203182020.g2IKKFB7014771@mail.openit.de> html>=20 =20 =20 =20 =20 =BB=F5 =C6=E4=C0=CC=C1=F6 1=20 =20 =20

=20 =20 =20 From rodmur@maybe.org Mon Mar 18 23:54:02 2002 From: rodmur@maybe.org (Dale Harris) Date: Mon Mar 18 23:54:02 2002 Subject: list closed to subscribers? In-Reply-To: <200203182020.g2IKKFB7014771@mail.openit.de>; from daloonim@hanmail.net on Tue, Mar 19, 2002 at 05:18:37AM +0900 References: <200203182020.g2IKKFB7014771@mail.openit.de> Message-ID: <20020318144953.D26540@maybe.org> So is this list closed to subscribers only? That would be one way of cutting down on the spam to the list. I assume the spammers are not subscribed. Dale From rjhansen@inav.net Tue Mar 19 00:13:01 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Tue Mar 19 00:13:01 2002 Subject: OO and the Real World? (Was: Moz, License) In-Reply-To: <1016461508.11412.520.camel@pps> References: <200203180429.QAA97621@ruru.cs.auckland.ac.nz> <1016461508.11412.520.camel@pps> Message-ID: <1016493100.6859.19.camel@numbers.robnet.net> > Until programming *techniques* begin to mature to the point where we can > flow between the paradigms, we will continue to mis-apply them and > thereby increase the complexity of our code. Let me edit your first sentence: until /programmers/ mature to the point where we can abandon One True Way thinking and instead use the proper tool for the job, we will continue to mis-apply our tools and thereby increase the complexity of our code. This is, incidentally, why I'm such a fan of C++ and Python. C++, contrary to popular opinion, isn't an object-oriented language. It's a multiparadigm language and one of the paradigms it supports is OO. Procedural, functional, generic, OO... they're all tools in the toolbox. The wise programmer uses the correct tool for the job. C++ and Python just give me an awful lot of tools. I really think the idea of One True Way is a childhood disease of programmers. All of us fall victim to it at some point, and for a lot of us, the disease becomes a chronic condition. From newsweeek@kebi.com Tue Mar 19 07:48:02 2002 From: newsweeek@kebi.com (Áß¾ÓÀ̺¥Æ®) Date: Tue Mar 19 07:48:02 2002 Subject: *Ãà* ¼±¹° ¹Þ¾Æ °¡¼¼¿ä *Ãà* (È« º¸) Message-ID: ¾È³çÇϼ¼¿ä? Áß¾Ó Å׸¶ À̺¥Æ®ÀÔ´Ï´Ù.

º» ¸ÞÀÏÀº ¹ß½ÅÀü¿ëÀÔ´Ï´Ù.¶§¹®¿¡ ¼Û½ÅÀÚ ¸ÞÀÏÁּҷδ ȸ½ÅÀ» º¸³¾ ¼ö ¾ø½À´Ï´Ù.
Á˼ÛÇÏÁö¸¸ ¼ö½ÅÀ» ¿øÇÏÁö ¾ÊÀ¸½Ã¸é ¸Ç¾Æ·¡ÀÇ ¼ö½Å°ÅºÎ ¹öÆ°À» Ŭ¸¯ÇØ Áֽʽÿä.
¹®ÀÇ»çÇ×Àº ȨÆäÀÌÁö¿¡ ¿À¼Å¼­ ¹®ÀÇÇϽøé Ä£ÀýÇÏ°Ô ´äÇص帳´Ï´Ù.
±ÍÇÏÀÇ ½Â¶ô¾øÀÌ È«º¸¼º ¸ÞÀÏÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°úµå¸³´Ï´Ù.

 
     
 
Áö±Ý ½ÅûÇϽô ºÐ¿¡ ÇÑÇÏ¿© Æú¶ó·ÎÀ̵å Ä«¸Þ¶ó³ª ·Î¸¸¼Õ °í±Þ Ä¿Çà ¼Õ¸ñ½Ã°è¸¦ µå¸³´Ï´Ù 
¹®ÀÇ : 02) 771-9495

´ã´ç : ¹Ú    Çö    ÁÖ

 

  
     
                 Áß¾ÓÅ׸¶À̺¥Æ®´Â Áß¾ÓÀϺ¸ ´º½ºÀ§Å©Áö»ç¿¡¼­ ÇÏ´Â À̺¥Æ® È«º¸Çà»çÀÔ´Ï´Ù

  [¿ùȸºñ 10,500¿ø]

Ưº° »çÀºÇ°ÁõÁ¤ : Æú¶ó·ÎÀ̵å Ä«¸Þ¶ó ¶Ç´Â ·Î¸¸¼Õ °í±Þ Ä¿ÇýðèÁß ÅÃÀÏ
±¹Á¦ ½Ã»çÁÖ°£Áö ´º½ºÀ§Å© Çѱ¹ÆÇ : 2³â°£ 100ºÎ (¸ÅÁÖ1±Ç)¹ß¼Û, ¿µÇÑÇؼ³ º°ÁöºÎ·Ï 8Page
                                                        Æ÷ÇÔ 
¿µÈ­·ÎÀÇÃÊ´ë : ¿¬ 8ȸÀÌ»ó, ¹«·áÃÊ´ë±Ç (2ÀÎ ÀÔÀå)
    ÁÖ¸»¿¡ »ó¿µÇÏ¸ç ½Ã°£¼±Åð¡´É, °³ºÀÇÏ´Â ¿ì¼ö¿µÈ­ ¶Ç´Â ½Ã»çȸ¸¦ ¼±Á¤

                        *ÀÌÀü¿µÈ­ - ¾ÆÆ®¾îºê¿ö,ij½ºÆ®¾î¿þÀÌ,¹Ì½º¿¡ÀÌÀüÆ®,¼¶¿ø¶óÀÌÅ©À¯,½Å¶óÀÇ´Þ¹ã,
                                          È¤¼ºÅ»Ãâ,ų·¯µéÀǼö´Ù,´Þ¸¶¾ß³îÀÚ,È­»ê°í,¹ÝÁöÀÇ Á¦¿Õ µî
¶óÀ̺êÄܼ­Æ® : ¿¬ 4ȸÀÌ»ó, ¹«·áÃÊ´ë±Ç (2ÀÎ ÀÔÀå)

                        *ÀÌÀüÄܼ­Æ®-ÀÌÀº¹Ì,±è°æÈ£,¾Èġȯ,±è¹ÎÁ¾,±èÇöÁ¤,Àڿ츲,À±µµÇö¹êµå,¼­¹®Å¹ µî
¸í°­»ç ¸í°­ÀÇ : ¿¬ 6ȸ ÀÌ»ó, ¹«·áÃÊ´ë±Ç (2ÀÎ ÀÔÀå)

                         *ÀÌÀü°­ÀÇ-Ȳ¼ö°ü,À̽ÃÇü,¾ö±æû,Á¤´öÈñ,Àü¿©¿Á,±¸¼º¾Ö,¹éÁö¿¬,Ç¥ÁøÀÎ,²ô·¹º§¹Ú µî
¿¬±Ø, ¹ÂÁöÄà : ¿¬ 12ȸÀÌ»ó, ÇÒÀοì´ë±Ç (50%~20% ÇÒÀÎÀ²)

                        *ÀÌÀü°ø¿¬ - ºê·Îµå¿þÀÌ 42¹ø°¡,ÄÚ·¯½º¶óÀÎ,³Í¼¾½º,¾Æ¸®¶û,µå¶óÅ¥¶ó,¿©·Î µî
Á¤µ¿±ØÀå : °ø¿¬ 20% ÇÒÀÎÇýÅà (Áß¾Ó Á¤È¸¿ø ¸â¹ö½± Ä«µåÁöÂü½Ã)
 Á¤È¸¿ø ¸â¹ö½± Ä«µå¹ß±Þ : Áß¾ÓÅ׸¶À̺¥Æ®¿¡¼­ ÁÖ°üÇÏ´Â ¹®È­Çà»ç ÃÊ´ë

 

ÀúÈñ°¡ ȸ¿øºÐµé¿¡°Ô Á¦°øÇØ µå¸®´Â ȸ¿øÇýÅÃÀ» ÀÚºñ·Î ÀÌ¿ëÇÏ½Å´Ù¸é ¿ù 50,000¿ø ÀÌ»ó ÁöÃâµÉ °ÍÀÔ´Ï´Ù.Çà»ç±â°£¿¡ ȸ¿ø°¡ÀÔÀ» Çϼż­ ¿ù 10,500¿ø¿¡ ÀÌ ¸ðµç ¹®È­»ýÈ°À» ´©¸®¼¼¿ä. Æú¶ó·ÎÀ̵å Ä«¸Þ¶ó³ª ·Î¸¸¼Õ Ä¿Çüոñ½Ã°è´Â Çà»ç±â°£¿¡ °¡ÀÔÇϽô ȸ¿øºÐµé²² µå¸®´Â »çÀºÇ°ÀÔ´Ï´Ù. ¿©·¯ºÐÀÇ Áú³ôÀº ¹®È­»ýÈ°¿¡ µµ¿òÀÌ µÇ°íÀÚ ÇÏ´Â Áß¾ÓÅ׸¶À̺¥Æ®ÀÔ´Ï´Ù.

                                                                       È¸¿ø°¡ÀÔ°ú ÀÚ¼¼ÇÑ ³»¿ëÀº ȨÆäÀÌÁö·Î
  


º» ¸ÞÀÏÀ» °ÅºÎÇϽô ºÐÀº [¼ö½Å°ÅºÎ ]¸¦ ´­·¯Áֽʽÿä. ºÒÆíÇÏ°Ô Çصå·È´Ù¸é Á˼ÛÇÕ´Ï´Ù.
From dshaw@jabberwocky.com Tue Mar 19 22:42:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Mar 19 22:42:01 2002 Subject: gpg subkeys, revisited In-Reply-To: <20020316124152.A7155@pizzashack.org> References: <20020315233857.A6820@pizzashack.org> <1016257151.16327.1.camel@allevil> <20020316124152.A7155@pizzashack.org> Message-ID: <20020319213951.GC683@akamai.com> On Sat, Mar 16, 2002 at 12:41:53PM -0500, Derek D. Martin wrote: > So, gpg seems to fail to realize that there are subkeys in the > exported block that are not in the local copy, and refuses to import > them. Whether or not this is intended behavior, I think this is a > bug. Otherwise, there's no way to recover accidentally deleted > subkeys, and if you DO accidentally delete a subkey, your options > would be to maintain two different keyrings (one with the deleted one > and the other with all the other keys), or throw up your hands in > frustration and generate a whole new key. And if you have old > messages that you still need to decrypt with the old key, the latter > isn't even really an option. Neither of those options is ideal. IMO, > the best solution is for gpg to allow the import of secret subkeys. GnuPG does not currently allow importing secret subkeys. In your particular example where you have two different copies of the secret key, each with a different subkey, you are going to have a difficulties. It's not exactly a common problem. :) The solution is to generate one key from your two, and import that. To do this, you need the "gpgsplit" tool, which is part of GnuPG 1.0.7 (grab the test version from ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6d.tar.gz if you need it). Run one of the keys through gpgsplit and delete all the files that come before the first "XXXXXXX-007.secret_subkey" file. Then cat the key you didn't split along with the files that are left after you deleted everything before the secret subkey. For example: $ gpgsplit mykey2 $ rm 000001-005.secret_key 000002-013.user_id 000003-002.sig $ cat mykey1 000004-007.secret_subkey 000005-002.sig > mywholekey $ gpg --allow-secret-key-import --import mywholekey David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From jmos@gmx.net Wed Mar 20 00:00:01 2002 From: jmos@gmx.net (jmos@gmx.net) Date: Wed Mar 20 00:00:01 2002 Subject: iterated+salted s2k insecure ? Message-ID: <401.1016578678@www13.gmx.net> Hello! I am wondering if "s2k-mode 3" (which is the default for GnuPG 1.0.6) is secure. I read RFC 2440 section 3.6.1.3. "Iterated and Salted S2K" and it seems to me that certain passphrase lengths are subject to an attack to the corresponding session key. E.g. passphrases that consist of 7, 27, 47, 67 or 87 characters result in a session key with only 256 possibilities which are shared among all passphrases with the given lengths. I would consider this a strong security risk because 256 possiblities for a session key is nothing. I do not know if I understood the RFC right but maybe one of you gurus can (hopefully) proof me wrong! -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From kcl@2-sun.com Wed Mar 20 13:11:01 2002 From: kcl@2-sun.com (kcl) Date: Wed Mar 20 13:11:01 2002 Subject: ±¤°í-»ï¼º Ä®¶óÇÁ¸°ÅÍ°¡ ÀÌ·±°¡°Ý¿¡...... Message-ID:
¾È³ç Çϼ¼¿ä.  º» ¸ÞÀÏÀº ±¤°í ¸ÞÀÏ ÀÔ´Ï´Ù.
»çÀü Çã¶ô¾øÀÌ ¸ÞÀÏÀ» º¸³»°Ô µÇ¾î¼­ Áø½ÉÀ¸·Î Á˼ÛÇÕ´Ï´Ù
¸ÞÀÏ ¹Þ±â¸¦ ¿øÄ¡  ¾ÊÀ¸½Å´Ù¸é ¾Æ·¡ ¸ÞÀÏ·Î ¹Ý¼Û¸ÞÀÏÀ» º¸³»Áֽøé
ÀÌÈÄ¿¡´Â Àý´ë·Î ¸ÞÀÏÀÌ ¼ö½ÅµÇÁö ¾ÊÀ» °ÍÀÔ´Ï´Ù.
.
¹Ý¼Û¸ÞÀÏ ÁÖ¼Ò : webmaster@2-Sun.com
                Àü È­ : 02-701-9111
-------------------------------------------------------------------------------------------
     »ï¼ºÇÁ¸°ÅÍ MJC-935 i    110,000 ¿ø¿¡ ÆǸŠ  ( Ư°¡ ÆǸŰ¡°Ý ÀÔ´Ï´Ù )
                          ¼ÒºñÀÚ°¡:157,000 ¿ø ======> 110,000 ¿ø¿¡ ÆǸÅ
                     
  --------------------------------------------------------------------------------------------  
  • 1200dpi ÃÊ°íÇØ»óµµ
    1ÀÎÄ¡´ç ÂïÈ÷´Â À×Å©¹æ¿ïÀÇ Å©±â°¡ ±âÁ¸ÀÇ ¹æ½Äº¸´Ù ÈξÀ ÀÛÀº
  • '±Ø¹Ì¼¼ À×Å©¹æ½Ä'À» ä¿ë,ÀϹݿëÁö¿¡¼­µµ ¼¶¼¼ÇÑ Ä÷¯ÀÇ ´À³¦À» ±×´ë·Î ÀçÇöÇØ µå¸³´Ï´Ù.

  • ½Ã¿øÇÑ ¼Óµµ 7PPM
    1ºÐ¿¡ ÃÖ´ë 7ÀåÀÇ Èæ¹é¹®¼­ ¹× 3ÀåÀÇ Ä÷¯¹®¼­¸¦ Ãâ·ÂÇÒ ¼ö Àִ Ź¿ùÇÑ ½ºÇǵå!
  • ÀÏ¹Ý ÇнÀ¿ëÀ¸·Î³ª ¼Ò±Ô¸ð »ç¹«½Ç¿ëÀ¸·Î »ç¿ëÇϱ⿡ ¾Ë¸ÂÀº ¼ÓµµÀÔ´Ï´Ù.

  • ¹øÁü¾ø°í ±ò²ûÇÑ ÇDZ׸ÕÆ® À×Å©
    ¾î¶² Á¾·ùÀÇ ¿ëÁö¸¦ »ç¿ëÇصµ ¹øÁöÁö ¾Ê°í ¶Ç·ÈÇÏ°Ô ÀμâÇØÁÖ´Â °ËÁ¤»ö ÇDZ׸ÕÆ®À×Å©¸¦ »ç¿ë,
  • Ãâ·ÂµÈ ¹®¼­°¡ ÇÑ°á ±ò²ûÇØ º¸ÀÔ´Ï´Ù.

  • 45dBÀÇ Á¶¿ëÇÑ ÇÁ¸°ÆÃ
    45dB ÀÌÇÏÀÇ Àú¼ÒÀ½ ÇÁ¸°ÆÃÀÌ °¡´ÉÇÑ ÃÊÁ¤¹Ð ¸ÞÄ«´ÏÁò ¿£ÁøÀ» ä¿ë, ÀÏ¹Ý °¡Á¤À̳ª »ç¹«½Ç¿¡¼­
  • Á¶¿ëÇÏ°Ô »ç¿ëÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù.

    »ó¼¼spec

  • Àμâ¼Óµµ : 7ppm(Èæ¹é) / 3ppm(Ä÷¯)

  • ÇØ»óµµ : 1,200 x 1,200dpi(Ä÷¯, Èæ¹é)

  • ÀÎÀÚ¸ðµå : HBP

  • ȣȯ¼º : Window 95/98/NT 4.0 /2000/Me/XP,Mac OS 8.6/9.xÁö¿ø

  • ¸Þ¸ð¸® : 512KB

  • ÀÎÅÍÆäÀ̽º : USB(Universal Serial Bus), Æз¯·¼

  • ¿ëÁöÅ©±â : A4,A5,B5,Legal,Executive,A6,¹è³Ê,¿±¼­,¶óº§ ¿ëÁö

  • ±ÞÁö¿ë·® : 100¸Å(ÇÁ¸®¹Ì¾ö ¿ëÁö100¸Å ¹«·áÁ¦°ø)

  • ¹èÁö¿ë·® : 25¸Å

  • Á¦Ç° Å©±â(W*D*H) : 447 X 170X 210 mm

  • Á¤°ÝÀü¿ø : AC 220V Àü¿ë,60 Hz


        .
  1. ¼Ò ºñ ÀÚ °¡  :  157,000 ¿ø  ¸ðµ¨:MJC-935 i  »ï¼ºÇÁ¸°ÅÍ
  2. Çö±ÝÆǸŰ¡  :  110,000 ¿ø
  3. ÅÃ¹è ¹ß¼Û                    
  4. ÇÑ Á¤ ÆÇ ¸Å : 2002 .03.31±îÁö

 

 »ï¼ºÇÁ¸°ÅÍ ÃÑÆÇ  ÀüÈ­: 02-701-9111

From dhill@wgate.com Wed Mar 20 18:53:02 2002 From: dhill@wgate.com (Dave Hill) Date: Wed Mar 20 18:53:02 2002 Subject: Space-padded lines in crypt-text Message-ID: <42C66B69F1F5D411B99300508BAC454606851657@mail.tvol.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D037.56A2C0D0 Content-Type: text/plain; charset="iso-8859-1" Hi all. I've run into a problem running GnuPG on text copied out of an email in Eudora or Netscape. With the right combination of circumstances, the GPG text ends up padded with a space at the end of each line (ie space-cr-lf or space-lf on every line). The spaces in the crypt-text block itself don't cause GPG a problem, but the space at the end of the -----BEGIN PGP MESSAGE----- line causes GnuPG not to recognize the block as valid crypt-text. I was wondering: 1) Why does the space in the BEGIN line cause a problem, but not the spaces in the crypt-text block? 2) If it makes sense, could someone in the group implement a fix that wouldn't break other stuff in the process? Thanks for any input you can provide, Dave Hill WorldGate Communications, Inc. ------_=_NextPart_001_01C1D037.56A2C0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Space-padded lines in crypt-text

Hi all.  I've run into a problem running GnuPG = on text copied out of an email in Eudora or Netscape.  With the = right combination of circumstances, the GPG text ends up padded with a = space at the end of each line (ie space-cr-lf or space-lf on every = line).  The spaces in the crypt-text block itself don't cause GPG = a problem, but the space at the end of the -----BEGIN PGP MESSAGE----- = line causes GnuPG not to recognize the block as valid crypt-text.  = I was wondering:

1)  Why does the space in the BEGIN line cause a = problem, but not the spaces in the crypt-text block?

2)  If it makes sense, could someone in the = group implement a fix that wouldn't break other stuff in the = process?

Thanks for any input you can provide,

Dave Hill
WorldGate Communications, Inc.

------_=_NextPart_001_01C1D037.56A2C0D0-- From dshaw@jabberwocky.com Wed Mar 20 19:24:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Mar 20 19:24:01 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <42C66B69F1F5D411B99300508BAC454606851657@mail.tvol.net> References: <42C66B69F1F5D411B99300508BAC454606851657@mail.tvol.net> Message-ID: <20020320182214.GB683@akamai.com> On Wed, Mar 20, 2002 at 12:47:43PM -0500, Dave Hill wrote: > Hi all. I've run into a problem running GnuPG on text copied out of an > email in Eudora or Netscape. With the right combination of circumstances, > the GPG text ends up padded with a space at the end of each line (ie > space-cr-lf or space-lf on every line). The spaces in the crypt-text block > itself don't cause GPG a problem, but the space at the end of the -----BEGIN > PGP MESSAGE----- line causes GnuPG not to recognize the block as valid > crypt-text. I was wondering: > > 1) Why does the space in the BEGIN line cause a problem, but not the spaces > in the crypt-text block? This is according to the spec. Since you refer to coping the text out of an email, I'll assume the text is either clearsigned text or an ASCII armored message. In clearsigned text, extra spaces at the end of lines are ignored. In ASCII armored text, spaces in general are ignored. The reason a space in the BEGIN line causes a problem is also by the spec - all of the armor BEGIN or END lines must be complete on their own line and contain nothing else > 2) If it makes sense, could someone in the group implement a fix that > wouldn't break other stuff in the process? Why does text copied out of an email grow extra spaces? David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From nils@gnupg.org Wed Mar 20 19:27:01 2002 From: nils@gnupg.org (nils@gnupg.org) Date: Wed Mar 20 19:27:01 2002 Subject: New GnuPG FAQ maintainer wanted Message-ID: <15512.54260.451259.397881@barber.fmi.uni-passau.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, a while ago, based on Werner's ASCII FAQ file, I set up the current GnuPG FAQ, because I was annoyed by the amount of reoccuring questions especially on gnupg-users. As I was frequently reading the lists I could regularly update the FAQ with new issues and remove stale entries. Very helpful were submissions by friendly FAQ readers. However, during the last months I had less and less time to maintain the FAQ so there were only very few updates, although more might have been necessary. I tried to find a new maintainer by private conversation, but to no avail so far. I probably didn't try hard enough, so I'm sorry about the FAQ right now being slightly out of date. This should change, so in agreement with Werner: A NEW GNUPG FAQ MAINTAINER IS WANTED! A volunteer for this job should ... * have a good understanding of how to use GnuPG * follow the discussions on the mailings lists * being able to identify FAQ-worthy entries I'm not here to set up guidelines how to do it, but I think one of the biggest caveats is not to try to be an extension to the manual. Lots of people mailed me stuff that either was in the man page or should have been there. My aim was to keep the FAQ short and not clutter it with lots of tips and tricks around GnuPG. However, your mileage may vary. If you're interested, please drop me a line. I will help to set you up. If there's more than one volunteer, I'll talk to Werner whom to pick. One would be enough, I guess. [If you want to suggest a different selection process, feel free to discuss it in this list ;-) ] May the applications come ... ;) Cheers, Nils -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard iD8DBQE8mNPIFwvIHy+DHcMRAjnnAKCR22qNUSAuoFrJIC/r9hnk0LIYIQCeJUYR bnwqWqkNVhtLFMMXvlQYqZA= =PsCQ -----END PGP SIGNATURE----- From dhill@wgate.com Wed Mar 20 19:47:01 2002 From: dhill@wgate.com (Dave Hill) Date: Wed Mar 20 19:47:01 2002 Subject: Space-padded lines in crypt-text Message-ID: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D03E.EC0D5110 Content-Type: text/plain; charset="iso-8859-1" David, Eudora and Netscape users on our lan receive email from Outlook as HTML when they connect using IMAP. This happens regardless of any plain-text settings at the sender, server, or receiver software. When HTML text from these apps is copied to the Windoze clipboard, it ends up space padded. I haven't been able to figure out whether this is a problem in the client apps, or the Windoze clipboard implementation, although if I had to make a guess... Unfortunately, this breaks GPGShell, which I've been setting up for non-tech types to be able to decrypt PGP email. I thought that rather than come up with an ugly hack elsewhere, and since I'm unlikely to get MS to fix their clipboard, GnuPG would be the right place to look for a clean fix. Dave >Why does text copied out of an email grow extra spaces? ------_=_NextPart_001_01C1D03E.EC0D5110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Space-padded lines in crypt-text

David,

Eudora and Netscape users on our lan receive email = from Outlook as HTML when they connect using IMAP.  This happens = regardless of any plain-text settings at the sender, server, or = receiver software.  When HTML text from these apps is copied to = the Windoze clipboard, it ends up space padded.  I haven't been = able to figure out whether this is a problem in the client apps, or the = Windoze clipboard implementation, although if I had to make a = guess...  Unfortunately, this breaks GPGShell, which I've been = setting up for non-tech types to be able to decrypt PGP email.  I = thought that rather than come up with an ugly hack elsewhere, and since = I'm unlikely to get MS to fix their clipboard, GnuPG would be the right = place to look for a clean fix.

Dave

>Why does text copied out of an email grow extra = spaces?

------_=_NextPart_001_01C1D03E.EC0D5110-- From saravn@mozdev.org Wed Mar 20 20:26:01 2002 From: saravn@mozdev.org (R. Saravanan) Date: Wed Mar 20 20:26:01 2002 Subject: Mozilla, License (again), PPG, GPGME Message-ID: <3C98E2E1.5070000@mozdev.org> Regarding Enigmail: On Fri Mar 15 19:16:01 2002, Werner Koch said: > A friend checked it out under Windows and according to him > it basically works and he could exchange encrypted or signed mails > with Mutt and Gnus users. Just to confirm that Enigmail, a mozilla "plugin" for GPG/PGP, is now in much better shape than it was just a few months ago, and is being used by several people.I will shortly post an "official" announcement in the users mailing list regarding the availability of Enigmail from http://enigmail.mozdev.org As for Enigmail's architecture, it uses pipes to communicate with command-line PGP or GPG; hence no license issues. This seems to work fine for encryption/decryption/verification etc. although it could be cumbersome for key management, which Enigmail doesn't really do at the moment. As for security, using Enigmail is in a sense only as secure as using Mozilla itself. If you are using Mozilla, and a malicious web page manages to gain "Universal Browser Access" privileges, it could read or write files in your directory, and perhaps even modify your GPG executable! Additional insecurities introduced by Enigmail mostly have to with obtaining and caching the passphrase. Enigmail has a passphrase caching option which can be turned off. Enigmail also takes some basic precautions to prevent access to the cached passphrase. There is still the possibility of "user interface spoofing" to obtain the passphrase, which I don't see a way of completely avoiding. One could perhaps gain some extra security by running the Mozilla mailer in a stand-alone mode, i.e., not as part of the browser. Saravanan Enigmail developer From dfc@anize.org Wed Mar 20 22:10:02 2002 From: dfc@anize.org (Douglas Calvert) Date: Wed Mar 20 22:10:02 2002 Subject: New GnuPG FAQ maintainer wanted In-Reply-To: <15512.54260.451259.397881@barber.fmi.uni-passau.de> References: <15512.54260.451259.397881@barber.fmi.uni-passau.de> Message-ID: <1016658454.27438.34.camel@allevil> --=-h8I8oTIaW4cB+t7cKwmP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I would be interested in maintaing the FAQ. I read users daily and have asked enough stupid questions that I know good FAQs. I have been buggin werner about what I could do to help out and this seems like a good thing for me. My coding skills are fairly weak but I can read and write. I am a grad student at syr.edu so i have a good deal of free time and spend a lot of it staring at my computer. Please let me know what else you would like from me. =20 I sent this to the list only to get feedback from others on my ability to handle this task. Any other emails can be off-list most likely... --=20 +---------------+-----------------------------------+ |Douglas Calvert| http://anize.org/dfc | | dfc@anize.org | http://imissjerry.org | +---------------+-----------------------------------+ | If you use envelopes, why not use encryption? | | http://anize.org/dfc/dfc-keys.asc | | 0817 30D4 82B6 BB8D 5E66 06F6 B796 073D C954 1FB2 | +-------------| http://www.gnupg.org |--------------+ --=-h8I8oTIaW4cB+t7cKwmP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8mPoWt5YHPclUH7IRAhnpAJ9LFsmFVMsqYjDpqqeoFIdaeJaCPQCgtPLJ noU8snF8X2fSOLUlj5MhEgs= =nB7+ -----END PGP SIGNATURE----- --=-h8I8oTIaW4cB+t7cKwmP-- From wk@gnupg.org Wed Mar 20 22:14:02 2002 From: wk@gnupg.org (Werner Koch) Date: Wed Mar 20 22:14:02 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> (Dave Hill's message of "Wed, 20 Mar 2002 13:42:00 -0500") References: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> Message-ID: <87r8mf0wug.fsf@alberti.gnupg.de> On Wed, 20 Mar 2002 13:42:00 -0500, Dave Hill said: > Windoze clipboard implementation, although if I had to make a guess... > Unfortunately, this breaks GPGShell, which I've been setting up for non-tech Please fix it there. Trimming all blanks from lines starting with at least 2 dashes should do the task while not even changing the actual message, although this is won't matter either. Werner From dhill@wgate.com Wed Mar 20 22:36:02 2002 From: dhill@wgate.com (Dave Hill) Date: Wed Mar 20 22:36:02 2002 Subject: Space-padded lines in crypt-text Message-ID: <42C66B69F1F5D411B99300508BAC454606851661@mail.tvol.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D056.83854A40 Content-Type: text/plain; charset="iso-8859-1" > Please fix it there. Trimming all blanks from lines starting with at > least 2 dashes should do the task while not even changing the actual > message, although this is won't matter either. > Not sure what you mean by "fix it there". I'd love to fix the Windoze clipboard implementation, but so far MS has been reluctant to give me the source code ) Dave ------_=_NextPart_001_01C1D056.83854A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Space-padded lines in crypt-text

> Please fix it there.  Trimming all blanks = from lines starting with at
> least 2 dashes should do the task while not = even changing the actual
> message, although this is won't matter = either.
>
Not sure what you mean by "fix it = there".  I'd love to fix the Windoze clipboard = implementation, but so far MS has been reluctant to give me the source = code )

Dave

------_=_NextPart_001_01C1D056.83854A40-- From jmos@gmx.net Thu Mar 21 01:50:01 2002 From: jmos@gmx.net (jmos@gmx.net) Date: Thu Mar 21 01:50:01 2002 Subject: iterated+salted s2k insecure ? Message-ID: <17145.1016671668@www46.gmx.net> >Hello! > >I am wondering if "s2k-mode 3" (which is the default for GnuPG 1.0.6) >is secure. >I read RFC 2440 section 3.6.1.3. "Iterated and Salted S2K" and it >seems to me that certain passphrase lengths are subject to an attack >to the corresponding session key. >E.g. passphrases that consist of 7, 27, 47, 67 or 87 characters >result in a session key with only 256 possibilities which are shared >among all passphrases with the given lengths. >I would consider this a strong security risk because 256 possiblities >for a session key is nothing. > >I do not know if I understood the RFC right but maybe one of you gurus >can (hopefully) proof me wrong! Ok no one answered, I guess I have to be a little more precise. According to RFC 2440 "Iterated+Salted S2K" works as follows: First, eight random bytes (the 'salt') are calculated. These random bytes followed by the passphrase data are repeatedly hashed until the number of bytes specified by the octet count has been hashed. Normally GnuPG uses 96 as the octet count. So, if someone uses a passphrase of 87 octets length the 8 octets of salt are prepended to yield a total of 95 octets. The result is normally a 20 octets hash value. But to satisfy the octet count of 96 one more octet has to be hashed. This is taken from the 20 octets hash value which was calculated before. But because only one more octet is hashed there are only 256 possibilities for the resulting hash value and therefore for the corresponding session key (at least for keys that are smaller than 160 bits). The same for passphrases with 67, 47, 27 and 7 octets length except that the hashing is done more often. Any comments ? Did I understand the RFC right ? -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From Enzo Michelangeli" Message-ID: <006c01c1d074$a5ede6a0$0200000a@noip.com> This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C1D0B7.AE5E6920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Space-padded lines in crypt-textBut won't the added spaces anyway = break cleartext (non-armoured) signed messages? Those can't be trimmed = easily. Enzo ----- Original Message -----=20 From: Dave Hill=20 To: gnupg-devel@gnupg.org=20 Sent: Thursday, 21 March, 2002 5:30 AM Subject: RE: Space-padded lines in crypt-text > Please fix it there. Trimming all blanks from lines starting with = at=20 > least 2 dashes should do the task while not even changing the actual = > message, although this is won't matter either.=20 >=20 Not sure what you mean by "fix it there". I'd love to fix the Windoze = clipboard implementation, but so far MS has been reluctant to give me = the source code ) Dave=20 ------=_NextPart_000_0067_01C1D0B7.AE5E6920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Space-padded lines in crypt-text
But won't the added spaces = anyway break=20 cleartext (non-armoured) signed messages? Those can't be trimmed=20 easily.
 
Enzo
----- Original Message -----
From:=20 Dave = Hill
Sent: Thursday, 21 March, 2002 = 5:30=20 AM
Subject: RE: Space-padded lines = in=20 crypt-text

> Please fix it there.  Trimming all blanks = from lines=20 starting with at
> least 2 dashes should = do the=20 task while not even changing the actual
> = message,=20 although this is won't matter either.
>=20
Not sure what you mean by "fix it = there".  I'd=20 love to fix the Windoze clipboard implementation, but so far MS has = been=20 reluctant to give me the source code )

Dave

------=_NextPart_000_0067_01C1D0B7.AE5E6920-- From bobmathews@mindspring.com Thu Mar 21 03:20:01 2002 From: bobmathews@mindspring.com (Bob Mathews) Date: Thu Mar 21 03:20:01 2002 Subject: iterated+salted s2k insecure ? In-Reply-To: <17145.1016671668@www46.gmx.net> References: <17145.1016671668@www46.gmx.net> Message-ID: <20020321021740.30B0A9D1B@cabbit.cat> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 20 March 2002 04:47 pm, jmos@gmx.net wrote: > These random bytes followed by the passphrase data are repeatedly > hashed until the number of bytes specified by the octet count has > been hashed. "Repeatedly hashed" doesn't mean that the hash value is computed and then fed back into the hash function again and again. It means that the same salt and password are fed into one hash calculation repeatedly, and one hash value is computed at the end. > Normally GnuPG uses 96 as the octet count. I just checked, and the octet count was 65536. Don't forget that part of the count field is actually a left-shift amount. > So, if someone uses a passphrase of 87 octets length the 8 octets > of salt are prepended to yield a total of 95 octets. The result is > normally a 20 octets hash value. The 20 octet hash value is not computed until after the required number of octets have been passed through the hash function. > But to satisfy the octet count of 96 one more octet has to be hashed. > This is taken from the 20 octets hash value which was calculated before. No, if 96 octets are to be hashed, the extra octet would come from the beginning of the salt. -bob mathews -----BEGIN PGP SIGNATURE----- Comment: What's this? http://bobmathews.home.mindspring.com/bob/ iD8DBQE8mUKfPgDecCrBEpcRAob2AKCH17JqxfmGr0PYTW088B4eBxMuTQCdFUJ+ jSByJ64w2WqTlh1tuY0QgFg= =9gvR -----END PGP SIGNATURE----- From wk@gnupg.org Thu Mar 21 10:14:02 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 10:14:02 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <42C66B69F1F5D411B99300508BAC454606851661@mail.tvol.net> (Dave Hill's message of "Wed, 20 Mar 2002 16:30:53 -0500") References: <42C66B69F1F5D411B99300508BAC454606851661@mail.tvol.net> Message-ID: <87adt2z3p6.fsf@alberti.gnupg.de> On Wed, 20 Mar 2002 16:30:53 -0500, Dave Hill said: > Not sure what you mean by "fix it there". I'd love to fix the Windoze In GPGShell. Afaik WinPT does not have this problem and the clipboard is used as well. Werner From wk@gnupg.org Thu Mar 21 10:16:01 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 10:16:01 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <006c01c1d074$a5ede6a0$0200000a@noip.com> ("Enzo Michelangeli"'s message of "Thu, 21 Mar 2002 09:06:26 +0800") References: <42C66B69F1F5D411B99300508BAC454606851661@mail.tvol.net> <006c01c1d074$a5ede6a0$0200000a@noip.com> Message-ID: <87663qz3m3.fsf@alberti.gnupg.de> On Thu, 21 Mar 2002 09:06:26 +0800, Enzo Michelangeli said: > RE: Space-padded lines in crypt-textBut won't the added spaces anyway break cleartext (non-armoured) signed messages? Those can't be trimmed easily. According to the specs trailing white spaces are to be trimmed in clear text message for signature creation and verification. The dash lines are boundaries and are not part of the signed text. Werner From wk@gnupg.org Thu Mar 21 11:44:01 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 11:44:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <3C98E2E1.5070000@mozdev.org> ("R. Saravanan"'s message of "Wed, 20 Mar 2002 12:28:33 -0700") References: <3C98E2E1.5070000@mozdev.org> Message-ID: <87henaxky2.fsf@alberti.gnupg.de> On Wed, 20 Mar 2002 12:28:33 -0700, R Saravanan said: > command-line PGP or GPG; hence no license issues. This seems to work > fine for encryption/decryption/verification etc. although it could be > cumbersome for key management, which Enigmail doesn't really do at the Better leave this task for other utilities, seahorse, Geheimnis, WinPT or whatever. > executable! Additional insecurities introduced by Enigmail mostly have > to with obtaining and caching the passphrase. Enigmail has a Don't put too much work into this. gpg 1.0.7 (1.0.6d already has this) will be able to use the private key framework of aegyptne (ie. gpg-agent and pinentry) and thus an application does not need to take car of this. Thanks, Werner From wk@gnupg.org Thu Mar 21 12:12:06 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 12:12:06 2002 Subject: [Announce] Announcing a GnuPG "plugin" for Mozilla (Enigmail) Message-ID: <87pu1yxlq6.fsf@alberti.gnupg.de> From: "R. Saravanan" To: gnupg-users@gnupg.org Date: Wed, 20 Mar 2002 12:50:51 -0700 Enigmail, a GnuPG "plugin" for Mozilla which has been under development for some time, has now reached a state of practical usability with the Mozilla 0.9.9 release. It allows you to send or receive encrypted mail using the Mozilla mailer and GPG. Enigmail is open source and dually licensed under GPL/MPL. You can download and install the software from the website http://enigmail.mozdev.org Enigmail is cross-platform like Mozilla, although binaries are supplied only for the Win32 and Linux-x86 platforms on the website.At the moment there is no version of Enigmail available for Netscape 6.2 or earlier, which are based on much older versions of Mozilla.There will be a version available for the next Netscape release, which is expected to be based on Mozilla 1.0. You may post enigmail-specific comments to the Enigmail newsgroup/mailing list at mozdev.org _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dhill@wgate.com Thu Mar 21 15:03:01 2002 From: dhill@wgate.com (Dave Hill) Date: Thu Mar 21 15:03:01 2002 Subject: Space-padded lines in crypt-text Message-ID: <42C66B69F1F5D411B99300508BAC45460685167C@mail.tvol.net> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D0E0.7365FD00 Content-Type: text/plain; charset="iso-8859-1" Actually, WinPT 0.5.5 has the exact same problem. I contacted the developer of GPGShell, and he told me that his program doesn't do any operations on the text in the clippboard at all, so it would require a major re-design. Dave > In GPGShell. Afaik WinPT does not have this problem and the clipboard > is used as well. > > Werner ------_=_NextPart_001_01C1D0E0.7365FD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Space-padded lines in crypt-text

Actually, WinPT 0.5.5 has the exact = same problem.  I contacted the developer of GPGShell, and he told = me that his program doesn't do any operations on the text in the = clippboard at all, so it would require a major re-design.  =

Dave

> In GPGShell.  Afaik WinPT does not have = this problem and the clipboard
> is used as well.
>=20
>  Werner

------_=_NextPart_001_01C1D0E0.7365FD00-- From twoaday@freakmail.de Thu Mar 21 17:18:01 2002 From: twoaday@freakmail.de (Timo Schulz) Date: Thu Mar 21 17:18:01 2002 Subject: Mozilla, License (again), PPG, GPGME In-Reply-To: <87henaxky2.fsf@alberti.gnupg.de> References: <3C98E2E1.5070000@mozdev.org> <87henaxky2.fsf@alberti.gnupg.de> Message-ID: <20020321160915.GA702@daredevil.joesixpack.net> On Thu Mar 21 2002; 11:40, Werner Koch wrote: > Don't put too much work into this. gpg 1.0.7 (1.0.6d already has > this) will be able to use the private key framework of aegyptne > (ie. gpg-agent and pinentry) and thus an application does not need to > take car of this. Maybe it's a good idea to mention, that the gpg-agent is also available for Win32 and GPG also contains some code to access the Win32 version. Timo From gzenker@pop500.gsfc.nasa.gov Thu Mar 21 18:28:01 2002 From: gzenker@pop500.gsfc.nasa.gov (Glenn Zenker) Date: Thu Mar 21 18:28:01 2002 Subject: gpgme-0.3.4 Message-ID: <20020321122459.3e5f6551.gzenker@pop500.gsfc.nasa.gov> I am on a Sun Solaris box trying to compile gpgme-0.3.4 and I get this error. Making all in gpgme make all-am source='util.c' object='util.lo' libtool=yes \ depfile='.deps/util.Plo' tmpdepfile='.deps/util.TPlo' \ depmode=gcc /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile /usr/local/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c -o util.lo `test -f util.c || echo './'`util.c rm -f .libs/util.lo /usr/local/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c util.c -Wp,-MD,.deps/util.TPlo -fPIC -DPIC -o .libs/util.lo In file included from util.c:28: util.h:142: parse error before `*' util.h:142: warning: function declaration isn't a prototype *** Error code 1 make: Fatal error: Command failed for target `util.lo' Current working directory /folks/gzenker/gpgme-0.3.4/gpgme *** Error code 1 make: Fatal error: Command failed for target `all' Current working directory /folks/gzenker/gpgme-0.3.4/gpgme *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /folks/gzenker/gpgme-0.3.4 *** Error code 1 make: Fatal error: Command failed for target `all' I compiled with the options: ./configure --prefix=/usr/tools && make I was able to compile gpgme-0.3.3 the same way with no problems at all. Any ideas why I am getting this error? Thanks for any help! -- Glenn.Zenker@gsfc.nasa.gov From wk@gnupg.org Thu Mar 21 20:48:01 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 20:48:01 2002 Subject: gpgme-0.3.4 In-Reply-To: <20020321122459.3e5f6551.gzenker@pop500.gsfc.nasa.gov> (Glenn Zenker's message of "Thu, 21 Mar 2002 12:24:59 -0500") References: <20020321122459.3e5f6551.gzenker@pop500.gsfc.nasa.gov> Message-ID: <87bsdhu2l1.fsf@alberti.gnupg.de> Hi! There is a new function which is not yet used in gpgme but the required structure needs off_t and ssize_t. To fix it, please insert this line #include /* make sure that ssize_t and off_t are defined */ right after the line #if !HAVE_FOPENCOOKIE Hth, Werner From wk@gnupg.org Thu Mar 21 22:38:01 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 21 22:38:01 2002 Subject: gpgme-0.3.4 In-Reply-To: <20020321160906.7d2c26b7.gzenker@pop500.gsfc.nasa.gov> (Glenn Zenker's message of "Thu, 21 Mar 2002 16:09:06 -0500") References: <20020321122459.3e5f6551.gzenker@pop500.gsfc.nasa.gov> <87bsdhu2l1.fsf@alberti.gnupg.de> <20020321160906.7d2c26b7.gzenker@pop500.gsfc.nasa.gov> Message-ID: <87bsdhsiyt.fsf@alberti.gnupg.de> On Thu, 21 Mar 2002 16:09:06 -0500, Glenn Zenker said: > I apologize, but I don't see the line > #if !HAVE_FOPENCOOKIE gpgme-0.3.4/gpgme/util.h near the end you find #if !HAVE_FOPENCOOKIE typedef struct { ssize_t (*read)(void*,char*,size_t); ssize_t (*write)(void*,const char*,size_t); int (*seek)(void*,off_t*,int); int (*close)(coid*); } _IO_cookie_io_functions_t; typedef _IO_cookie_io_functions_t cookie_io_functions_t; FILE *fopencookie (void *cookie, const char *opentype, cookie_io_functions_t funclist); #endif /*!HAVE_FOPENCOOKIE*/ #endif /*HAVE_CONFIG_H*/ Ahemm, there is a typo I already fixed in the CVS - this is probably what caused the trouble: int (*close)(coid*); should be int (*close)(void*); From jmos@gmx.net Fri Mar 22 01:21:01 2002 From: jmos@gmx.net (jmos@gmx.net) Date: Fri Mar 22 01:21:01 2002 Subject: iterated+salted s2k insecure ? Message-ID: <22453.1016756306@www40.gmx.net> On Wednesday 20 March 2002 04:47 pm, jmos@gmx.net wrote: >> These random bytes followed by the passphrase data are repeatedly >> hashed until the number of bytes specified by the octet count has >> been hashed. >"Repeatedly hashed" doesn't mean that the hash value is computed and then fed >back into the hash function again and again. It means that the same salt and >password are fed into one hash calculation repeatedly, and one hash value is >computed at the end. >> Normally GnuPG uses 96 as the octet count. >I just checked, and the octet count was 65536. Don't forget that part of the >count field is actually a left-shift amount. >> So, if someone uses a passphrase of 87 octets length the 8 octets >> of salt are prepended to yield a total of 95 octets. The result is >> normally a 20 octets hash value. >The 20 octet hash value is not computed until after the required number of >octets have been passed through the hash function. >> But to satisfy the octet count of 96 one more octet has to be hashed. >> This is taken from the 20 octets hash value which was calculated before. >No, if 96 octets are to be hashed, the extra octet would come from the >beginning of the salt. > -bob mathews Thanks Bob for your explanation of what is actually meant by the RFC ! Am I the only person who misunderstood that section ? I think it could have been written a little bit more precise. Jens -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From JanuszA.Urbanowicz Sun Mar 24 18:41:02 2002 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Sun Mar 24 18:41:02 2002 Subject: keyring-splitting program Message-ID: --ELM72123749-26264-0_ Content-Type: application/pgp; format=text; x-action=sign Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello I've written a small Python program/module to split my keyring into sepaarte keys for rebuilding since it got corrupted. It is also useful for importing large amounts of keys into PGP - all versions have problems with importing large (>50) solid blobs of public keys. Since its a spinoff of generic gnupg gnupg interface I'm writing, I named id gnupg.py, feel encouraged to rename it as you like during installation. I consider this a submission for the Project's tools directory. Hope you will find the code useful. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6d (GNU/Linux) iD8DBQE8nhEdTfkBjn4ugD0RA+hJAJ9f/Zuv5kFG3EDkY2+sLmHYCgQ9lgCeJajl V69/47wLvRSE/82UUyaOw4o= =OZVm -----END PGP SIGNATURE----- --ELM72123749-26264-0_ Content-Type: text/plain; charset=ISO-8859-2 Content-Disposition: attachment; filename=gnupg.py Content-Description: python program Content-Transfer-Encoding: 7bit #! /usr/bin/env python '''Utility program for GNU Privacy Guard. This code runs under Python 1.5.2 on GNU/Linux. It should run on newer versions of Python as well. Some of the functions won't run on other architectures. Copyright 2002 Janusz A. Urbanowicz $Id: gnupg.py,v 1.2.1.5 2002/03/24 17:16:07 alex Exp $ This program is distributed under the terms opf GNU General Public License. Version 2 or later. When called as a program, exports every key in the public keyring to a file named by the key's 64 bit key ID in binary or ascii armored form. Optionally, binary mode and destination directory can be specified. For usage info, run the program with -h parameter. The program can be laso used as a Python module with following public functions: listkeys(), listkey(), simpledecrypt() and recipients(). For description of those, refer to appropriate docstrings. ''' import tempfile,os,re,popen2,sys,getopt,os.path # # Utility functions # def listkeys(): "Returns a dictionary of long-keyid (key) and primary UID (value) for default keyring)" primaryre = re.compile('^pub:(?:-|u|r|f|d|m|q|e):[0-9]{3,4}?:(?:1|17):((?:[A-Z]|[0-9])+?):[0-9]{4}\-[0-9]{2}\-[0-9]{2}:(?:[0-9]{4}\-[0-9]{2}\-[0-9]{2})?:\w*?:\w*?:(.*?):\w*?:\w*?:') secondaryre = re.compile('^uid:(?:-|u|r|f|d|m|q|e)::::::::(.*?):') imagere = re.compile('^\[image of size [0-9]+?\]') klucze = {} gpghandle = os.popen('gpg --with-colons -k','r') gpgoutput = gpghandle.readlines() gpghandle.close() for i in range(len(gpgoutput)): result = primaryre.match(gpgoutput[i]) try: keyid = result.groups()[0] except AttributeError: continue klucze[keyid] = result.groups()[1] if imagere.match(klucze[keyid]) == None: continue else: klucze[keyid] = None while primaryre.match(gpgoutput[i+1]) == None: i = i+1 result = secondaryre.match(gpgoutput[i]) try: klucze[keyid] = result.groups()[0] assert imagere.match(klucze[keyid]) == None break except AttributeError,AssertionError: pass if klucze[keyid] == None: del klucze[keyid] del keyid return klucze def listkey(key): "Returns a dictionary of long-keyid (key) and primary UID (value) for a single key." primaryre = re.compile('^pub:(?:-|u|r|f|d|m|q|e):[0-9]{3,4}?:(?:1|17):((?:[A-Z]|[0-9])+?):[0-9]{4}\-[0-9]{2}\-[0-9]{2}:(?:[0-9]{4}\-[0-9]{2}\-[0-9]{2})?:\w*?:\w*?:(.*?):\w*?:\w*?:') secondaryre = re.compile('^uid:(?:-|u|r|f|d|m|q|e)::::::::(.*?):') imagere = re.compile('^\[image of size [0-9]+?\]') klucze = {} gpghandle = os.popen('gpg --with-colons -k %s' % key,'r') gpgoutput = gpghandle.readlines() gpghandle.close() for i in range(len(gpgoutput)): result = primaryre.match(gpgoutput[i]) try: keyid = result.groups()[0] except AttributeError: continue klucze[keyid] = result.groups()[1] if imagere.match(klucze[keyid]) == None: continue else: klucze[keyid] = None while primaryre.match(gpgoutput[i+1]) == None: i = i+1 result = secondaryre.match(gpgoutput[i]) try: klucze[keyid] = result.groups()[0] assert imagere.match(klucze[keyid]) == None break except AttributeError,AssertionError: pass if klucze[keyid] == None: del klucze[keyid] del keyid return klucze def simpledecrypt(passphrase,data): 'Decrypt PGP encrypted data with supplied passphrase, the result is the return value' tempfilename = tempfile.mktemp() tempfile = open(tempfilename,'w') tempfile.write(data) tempfile.close() gpghandle = popen2.popen2('gpg --passphrase-fd 0 --batch --output - %s' % tempfilename) gpghandle[1].write(passphrase) gpghandle[1].close() data = gpghandle[0].read() gpghandle[0].close() os.unlink(tempfilename) return data def recipients(data): "Returns a tuple of key IDs the message is encrypted to. Based on the code from GnuPG FAQ." gpghandle = popen2.popen2('gpg --batch --decrypt --list-only --status-fd 1') gpghandle[1].write(data) gpghandle[1].close() results = gpghandle[0].readlines() gpghandle[0].close() recipientre = re.compile('^\[GNUPG:\] ENC_TO ((?:[A-Z]|[0-9]){16}) .*$',re.MULTILINE) result = [] for line in results: try: match = recipientre.search(line).groups() except AttributeError: continue result.append(match[0]) return tuple(result) # # Splitkeyring code. # if __name__ == '__main__': dir = '' mode = '--armor' params,args = getopt.getopt(sys.argv[1:],'hd:b',['help','output-dir','binary']) for param in params: if '-h' in param or '--help' in param: print '%s $Revision: 1.2.1.5 $\n' % sys.argv[0] print 'Copyright 2002 Janusz A. Urbanowicz .\n' print 'This program is distributed under the terms of GNU General Public License.' print 'Version 2 or later.\n' print 'Synopsis: %s [-d | --output-dir ] [-b | --binary]' % sys.argv[0] print '\nOptions: \n\n -d, --output-dir directtory to store the keys in (default: cwd)' print ' -b, --binary export keys in binary form (default: off)' print ' -h, --help this help message\n' sys.exit(0) if '-d' in param or '--output-dir' in param: try: dir = param[1] except: print 'No output directory supplied.' sys.exit(1) dir = os.path.abspath(dir) if '-b' in param or '--binary' in param: mode = '' lkeys = listkeys() for keyid in lkeys.keys(): file = open(os.path.join(dir,keyid),'w+') if mode: file.write('%s\n\n' % lkeys[keyid]) gpghandle = os.popen('gpg --quiet %s --batch --export %s' % (mode, keyid), 'r') data = gpghandle.readlines() gpghandle.close() file.writelines(data) file.close() ## Local Variables: ## mode: Python ## py-indent-offset: 2 ## fill-column: 100 ## End: --ELM72123749-26264-0_ Content-Type: application/pgp Content-Disposition: attachment; filename=gnupg.py.asc Content-Description: detached signature file Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6d (GNU/Linux) Comment: http://quiston.tpsa.com/~alex/pgp.html iQCVAwUAPJ4Qerm/3a0nyBvJAQPbMQQAhKJQNmwYrEwd5Gk0dOJfvGL+UZM+aD4Q FPHneoXj137/8fN+/0BgOY6FjRoAFxr1jJ6ErTO/INBJA5xulR6yhZNW5qRDDl/a KuxzC1ptCcnFQNLNkUdbIMsqzjErPCffBtrgkMbg/ubTNPutKRNn3c8E+cFzFv24 i5TsumSSvZA= =6beb -----END PGP SIGNATURE----- --ELM72123749-26264-0_-- From dshaw@jabberwocky.com Tue Mar 26 01:27:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Mar 26 01:27:01 2002 Subject: Space-padded lines in crypt-text In-Reply-To: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> References: <42C66B69F1F5D411B99300508BAC45460685165A@mail.tvol.net> Message-ID: <20020326002513.GG745@akamai.com> > >Why does text copied out of an email grow extra spaces? On Wed, Mar 20, 2002 at 01:42:00PM -0500, Dave Hill wrote: > David, > > Eudora and Netscape users on our lan receive email from Outlook as HTML when > they connect using IMAP. This happens regardless of any plain-text settings > at the sender, server, or receiver software. When HTML text from these apps > is copied to the Windoze clipboard, it ends up space padded. I haven't been > able to figure out whether this is a problem in the client apps, or the > Windoze clipboard implementation, although if I had to make a guess... > Unfortunately, this breaks GPGShell, which I've been setting up for non-tech > types to be able to decrypt PGP email. I thought that rather than come up > with an ugly hack elsewhere, and since I'm unlikely to get MS to fix their > clipboard, GnuPG would be the right place to look for a clean fix. FYI, after some discussion with Werner, and in the interests of "be liberal in what you accept, conservative in what you generate", I changed the code in GnuPG 1.0.7 to permit extra spaces on the armor header lines. The --openpgp flag makes this strict again. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From dmitri@users.sourceforge.net Tue Mar 26 04:28:01 2002 From: dmitri@users.sourceforge.net (Dmitri) Date: Tue Mar 26 04:28:01 2002 Subject: The key size warning Message-ID: <20020326032520.GC3916@mars.networkfab.com> --NKoe5XOeduwbEQHU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, All: In light of http://online.securityfocus.com/archive/1/263924 GnuPG probably should remove the confirmation/warning message, and change the suggested key size: $ gpg --gen-key gpg (GnuPG) 1.0.6; Copyright (C) 2001 Free Software Foundation, Inc. [...] Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) Your selection?=20 DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits <=3D=3D=3D=3D=3D=3D=3D=3D HERE = =3D=3D highest suggested keysize is 2048 bits What keysize do you want? (1024) 2048 Do you really need such a large keysize? yes <=3D=3D=3D=3D=3D=3D=3D=3D HER= E =3D=3D Requested keysize is 2048 bits =20 [...] Unless, of course, the abovementioned email is not correct... Cheers Dmitri --=20 A Windows user spends 1/3 his life sleeping, 1/3 working, 1/3 waiting. --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8n+ogXksyLpO6T4IRAn6iAJ9H1W8tgTdbt9BrZGLsEhdn4sMvIACfUdSZ BNuY9pUiF6TEKtlj91A7mMk= =wE+Y -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU-- From wk@gnupg.org Tue Mar 26 08:48:02 2002 From: wk@gnupg.org (Werner Koch) Date: Tue Mar 26 08:48:02 2002 Subject: The key size warning In-Reply-To: <20020326032520.GC3916@mars.networkfab.com> (Dmitri's message of "Mon, 25 Mar 2002 19:25:20 -0800") References: <20020326032520.GC3916@mars.networkfab.com> Message-ID: <878z8fbwmb.fsf@alberti.gnupg.de> On Mon, 25 Mar 2002 19:25:20 -0800, Dmitri said: > In light of http://online.securityfocus.com/archive/1/263924 > GnuPG probably should remove the confirmation/warning message, and This is probably Lucky Green's announcement - don't forget to read also Ian Goldberg's reply. No need to change the suggested keysize, remember that you should make the weakest link stronger to get better protection and not one of the ver bold ones. Already updated the latest zlib, fixed the ssh bug of the month, audited the GnuPG code, installed a stronger lock at your door, did a security check of all your friends? Werner From rabbi@quickie.net Tue Mar 26 08:59:02 2002 From: rabbi@quickie.net (Len Sassaman) Date: Tue Mar 26 08:59:02 2002 Subject: The key size warning In-Reply-To: <878z8fbwmb.fsf@alberti.gnupg.de> Message-ID: On Tue, 26 Mar 2002, Werner Koch wrote: > This is probably Lucky Green's announcement - don't forget to read > also Ian Goldberg's reply. No need to change the suggested keysize, I have to disagree with you, Werner. The current warning appears to discourage users from generating 2048 bit and greater keys. There's really no necessity for doing so. I also think that 768 bit keys shouldn't be permitted to be generated. From rjhansen@inav.net Tue Mar 26 09:36:02 2002 From: rjhansen@inav.net (Robert J. Hansen) Date: Tue Mar 26 09:36:02 2002 Subject: The key size warning In-Reply-To: References: Message-ID: <1017131690.23435.32.camel@numbers.robnet.net> > I have to disagree with you, Werner. The current warning appears to > discourage users from generating 2048 bit and greater keys. There's really > no necessity for doing so. I'm with Len on this one. Frankly, given that generating and using 2048-bit keys on modern hardware is no more taxing than generating and using 1024-bit keys five years ago, I think it's entirely appropriate to change the default keysize as a way of buying us a little extra security from any further unexpected surprises. > I also think that 768 bit keys shouldn't be permitted to be generated. Here I disagree--it's possible that there are circumstances or conditions in which moving up to 2k keys is not possible. One company I worked at had code which was hardcoded to require 768-bit keys. There are legacy and just plain badly-designed systems out there, and we should permit keys to be generated which will interoperate with them. 768-bit keys should, IMO, flag a warning about "This key is far below the recommended keysize". But that's it. From wk@gnupg.org Tue Mar 26 11:08:01 2002 From: wk@gnupg.org (Werner Koch) Date: Tue Mar 26 11:08:01 2002 Subject: The key size warning In-Reply-To: (Len Sassaman's message of "Mon, 25 Mar 2002 23:56:52 -0800 (PST)") References: Message-ID: <87zo0vabl8.fsf@alberti.gnupg.de> On Mon, 25 Mar 2002 23:56:52 -0800 (PST), Len Sassaman said: > I have to disagree with you, Werner. The current warning appears to > discourage users from generating 2048 bit and greater keys. There's really I will remove the warning for keys > 1536. > I also think that 768 bit keys shouldn't be permitted to be generated. 1024 is already the minimum for RSA: else if( algo == PUBKEY_ALGO_RSA && nbits < 1024 ) tty_printf(_("keysize too small;" " 1024 is smallest value allowed for RSA.\n")); Werner From d1234hill11@comcast.net Tue Mar 26 13:09:02 2002 From: d1234hill11@comcast.net (d1234hill11@comcast.net) Date: Tue Mar 26 13:09:02 2002 Subject: Space-padded lines in crypt-text Message-ID: <002501c1d4be$e3ac9e20$6401a8c0@norr1.pa.home.com> David, Sounds great - any possibility you could point me to a Win32 Binary? FYI, Roger Sonderman has made GPGShell handle this case as well. Dave > > FYI, after some discussion with Werner, and in the interests of "be > liberal in what you accept, conservative in what you generate", I > changed the code in GnuPG 1.0.7 to permit extra spaces on the armor > header lines. The --openpgp flag makes this strict again. > > David > From max@quendi.de Tue Mar 26 13:44:01 2002 From: max@quendi.de (Max Horn) Date: Tue Mar 26 13:44:01 2002 Subject: Patch to make GPGME 0.3.4 compile on OS X Message-ID: diff -ru gpgme-0.3.4/gpgme/util.h gpgme-0.3.4-patched/gpgme/util.h --- gpgme-0.3.4/gpgme/util.h Wed Feb 13 14:41:18 2002 +++ gpgme-0.3.4-patched/gpgme/util.h Tue Mar 26 13:18:29 2002 @@ -139,7 +139,7 @@ ssize_t (*read)(void*,char*,size_t); ssize_t (*write)(void*,const char*,size_t); int (*seek)(void*,off_t*,int); - int (*close)(coid*); + int (*close)(void*); } _IO_cookie_io_functions_t; typedef _IO_cookie_io_functions_t cookie_io_functions_t; FILE *fopencookie (void *cookie, const char *opentype, *cough* a little bit embarrassing to have this in a release, isn't it? =) Well, I am happy I am not the only one to whom such misfortunes happen, Thanks for your work, Max -- ----------------------------------------------- Max Horn Software Developer email: phone: (+49) 6151-494890 From wk@gnupg.org Tue Mar 26 14:44:02 2002 From: wk@gnupg.org (Werner Koch) Date: Tue Mar 26 14:44:02 2002 Subject: Patch to make GPGME 0.3.4 compile on OS X In-Reply-To: (Max Horn's message of "Tue, 26 Mar 2002 13:42:38 +0100") References: Message-ID: <87y9gf8mzm.fsf@alberti.gnupg.de> On Tue, 26 Mar 2002 13:42:38 +0100, Max Horn said: > *cough* a little bit embarrassing to have this in a release, isn't > it? =) Well, I am happy I am not the only one to whom such misfortunes It has already been fixed. However we are developing using GNU systems so we can't easily spot errors in replacement code. Werner From marcus@gnu.org Tue Mar 26 14:59:01 2002 From: marcus@gnu.org (Marcus Brinkmann) Date: Tue Mar 26 14:59:01 2002 Subject: Patch to make GPGME 0.3.4 compile on OS X In-Reply-To: References: Message-ID: <20020326135713.GE25196@gnu.org> On Tue, Mar 26, 2002 at 01:42:38PM +0100, Max Horn wrote: > - int (*close)(coid*); > + int (*close)(void*); Thanks for reporting it. This is already fixed in CVS. > *cough* a little bit embarrassing to have this in a release, isn't > it? =) Well, I am happy I am not the only one to whom such > misfortunes happen, Well, the 0.3.1 release was worse ;) The above typo only shows up on non-GNU systems. Thanks, Marcus From alfons@proteus.demon.nl Tue Mar 26 22:42:01 2002 From: alfons@proteus.demon.nl (Alfons Hoogervorst) Date: Tue Mar 26 22:42:01 2002 Subject: [Sylpheed-claws-users] Good News In-Reply-To: <20020326222803.017208a6.ml-lists@macbyte.info> References: <20020326222803.017208a6.ml-lists@macbyte.info> Message-ID: <20020326221906.46103415.alfons@proteus.demon.nl> Lo Michael, On Tue, 26 Mar 2002 22:28:03 +0100 Michael Raab wrote: | i have today read on the WebSite http://www.gnupp.de/software.html | that Sylpheed becomes support for GNUPG from the german Goverment | BMWi. This is really great news, any comments from the GnuPG guys? Bye. PS. When responding, please at least include sylpheed@good-day.net, which is the official Sylpheed ML. Thanks. -- Ecuación algebraico sin solución posible, a menos de poseer profundos conocimientos en matemática - Revueltas (Ocho Por Radio) From mwy-gpg41@the-youngs.org Wed Mar 27 00:36:01 2002 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Wed Mar 27 00:36:01 2002 Subject: The key size warning References: Message-ID: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: "Robert J. Hansen" > > 768-bit keys should, IMO, flag a warning about "This key is far below > the recommended keysize". But that's it. I agree. If I *really* want a smaller key, despite the warning, why should it be GnuPG's job to prevent me? I can buy the argument that some programs should protect the incurably stupid, but GnuPG is just chock-full of options that can be horribly misused already. A protectionist policy seems out of place. I have a relatively short key for low-value material I may keep on my Palm device. I'm willing to let someone spend $1B (or even $1M) if they really want this material, but I'm not willing to wait minutes to get my data. (Some perhaps, but not all.) I actually have a 384-bit key that I've used as an MDC. (It won't cost you very much to break this. Heck, for $1, I'll give you the secret key myself. :-) You could argue that I should use a new key that gets automatic MDC treatment, or force GnuPG to use an MDC, but sometimes I need to use a pre-MDC product. So, I sign with a ridiculously short key. I'd have generated an even shorter one, but this was the lower limit for PGP2.6. No, not everybody needs to do these things. But should I really have to dig up an antique product or roll my own key generator if this is what I really want to do? -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPKEEQFMkvpTT8vCGEQISRACdFGmLj0n66njq6C7EYz+2ttDxOIoAoJqT c6rq6L099BiKVLu5zKlDeC66 =wTxj -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Wed Mar 27 01:15:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Mar 27 01:15:02 2002 Subject: The key size warning In-Reply-To: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> References: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> Message-ID: <20020327001240.GF1419@akamai.com> On Tue, Mar 26, 2002 at 06:31:41PM -0500, Michael Young wrote: > > From: "Robert J. Hansen" > > > > 768-bit keys should, IMO, flag a warning about "This key is far below > > the recommended keysize". But that's it. > > I agree. If I *really* want a smaller key, despite the warning, > why should it be GnuPG's job to prevent me? I can buy the > argument that some programs should protect the incurably stupid, > but GnuPG is just chock-full of options that can be horribly misused > already. A protectionist policy seems out of place. I agree that if a user wants to do something stupid, they should be allowed to (with appropriate warnings). Still, it's in the OpenPGP spec that applications shouldn't generate keys smaller than 768 bits. It's a SHOULD, and not a MUST, but it's there. I'd say disallow it unless the user sets the --expert flag. By setting that, the user is swearing they won't blame GnuPG for not protecting them :) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From JanuszA.Urbanowicz Wed Mar 27 16:05:01 2002 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Wed Mar 27 16:05:01 2002 Subject: The key size warning In-Reply-To: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> from Michael Young at "Mar 26, 2002 06:31:41 pm" Message-ID: Michael Young wrote/napisa=B3[a]/schrieb: -- Start of PGP signed section. > > From: "Robert J. Hansen" > > > > 768-bit keys should, IMO, flag a warning about "This key is far below > > the recommended keysize". But that's it. >=20 > I agree. If I *really* want a smaller key, despite the warning, > why should it be GnuPG's job to prevent me? I can buy the > argument that some programs should protect the incurably stupid, > but GnuPG is just chock-full of options that can be horribly misused > already. A protectionist policy seems out of place. I have to disagree. It depends on who you are protecting. If you are dealing with people who can do a realistic risk assessment. But as long as we aim for getting PGP/GPG more popular, it means that people who are unable to do so (casual users) will use the software. Thus the software should take precautions to protect them, by assuming reasonably secure defaults, and with protecting them from doing stupid mistakes. While I don't like adding YA commandline option to gpg, a option --expert-mode allowing to do 'stupid things' seems reasonable in the context. Alex --=20 C _-=3D-_ H| Janusz A. Urbanowicz | ALEX3-RIPE | SF-F Framling | | = * =09 ; (_O : +-------------------------------------------------------------+ --= +~|=09 ! &~) ? | P=B3yn=B1=E6 chc=EA na Wsch=F3d, za Suez, gdzie jest dobrem ka= =BFde z=B3o | l_|/=09 A ~-=3D-~ O| Gdzie przykaza=F1 brak dziesi=EAciu, a pi=E6 mo=BFna a=BF po d= no; | | =20 From dshaw@jabberwocky.com Wed Mar 27 17:22:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Mar 27 17:22:02 2002 Subject: The key size warning In-Reply-To: References: <000e01c1d51e$65351f80$c23fa8c0@transarc.ibm.com> Message-ID: <20020327161908.GC20745@akamai.com> On Wed, Mar 27, 2002 at 03:50:13PM +0100, Janusz A. Urbanowicz wrote: > Michael Young wrote/napisa?[a]/schrieb: > -- Start of PGP signed section. > > > From: "Robert J. Hansen" > > > > > > 768-bit keys should, IMO, flag a warning about "This key is far below > > > the recommended keysize". But that's it. > > > > I agree. If I *really* want a smaller key, despite the warning, > > why should it be GnuPG's job to prevent me? I can buy the > > argument that some programs should protect the incurably stupid, > > but GnuPG is just chock-full of options that can be horribly misused > > already. A protectionist policy seems out of place. > > I have to disagree. > > It depends on who you are protecting. If you are dealing with people who can > do a realistic risk assessment. But as long as we aim for getting PGP/GPG > more popular, it means that people who are unable to do so (casual users) > will use the software. Thus the software should take precautions to protect > them, by assuming reasonably secure defaults, and with protecting them from > doing stupid mistakes. > > While I don't like adding YA commandline option to gpg, a option > --expert-mode allowing to do 'stupid things' seems reasonable in the > context. There is already an --expert in 1.0.7. It controls whether a user is allowed to sign a revoked key, sign a revoked uid, sign an expired key, add multiple photo IDs to a key and add a photo ID to a PGP 2.x-style key. All things that probably shouldn't happen unless the user knows what they are doing. It seems reasonable to use it for allowing really small keysizes as well. In any case, the RFC discourages ("SHOULD NOT") sizes smaller than 768. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From JanuszA.Urbanowicz Wed Mar 27 19:02:01 2002 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Wed Mar 27 19:02:01 2002 Subject: How to make invalid OpenPGP packets with GNUPG (a bugreport). Message-ID: Hash: SHA1 The method is simple (at least for me): - - write text in text editor (joe) - - mark the whole text as a block - - pipe the block though GnuPG for signing with a signing v4 subkey and for encryption for untrusted v3 RSA key. (gpg -sea -r for my setup) - - answer yes when asked if you really want to use that key The resulting OpenPGP message will make all tested PGP (and GPG) versions barf with the following message: gpg: packet(1) too short gpg: block_filter 0x80fdd48: read error (size=3D8763,a->size=3D36031) gpg: block_filter: pending bytes! The effect is repeatable. Alex - --=20 C _-=3D-_ H| Janusz A. Urbanowicz | ALEX3-RIPE | SF-F Framling | | = * =09 ; (_O : +-------------------------------------------------------------+ --= +~|=09 ! &~) ? | P=B3yn=B1=E6 chc=EA na Wsch=F3d, za Suez, gdzie jest dobrem ka= =BFde z=B3o | l_|/=09 A ~-=3D-~ O| Gdzie przykaza=F1 brak dziesi=EAciu, a pi=E6 mo=BFna a=BF po d= no; | | =20 From rra@stanford.edu Wed Mar 27 23:54:02 2002 From: rra@stanford.edu (Russ Allbery) Date: Wed Mar 27 23:54:02 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG Message-ID: (I'm not a member of this mailing list, so please cc me on any replies.) Hello folks, I'm working on putting in place more standard procedures and control message handling for the gnu.* Usenet hierarchy. Currently, Usenet control messages are verified using PGP signatures and a Usenet-specific protocol for including that signature in the headers. Nearly everyone verifying control messages is currently using PGP 2.6.2 or some varient thereof, and all current control message signatures are done with RSA keys. For the gnu.* hierarchy, we'd obviously prefer to use GnuPG for all stages of the process rather than using PGP (which is not free software). I see that generation of RSA keys for signing only has been added to the latest GnuPG development snapshots. However, when I generate a key with: gpg --gen-key --pgp2 and then export the public key with either of: gpg --pgp2 --export gnu.gnusenet.announce > gnu.key gpg --pgp2 --armor --export gnu.gnusenet.announce > ! gnu.key running the command: pgp -ka gnu.key using PGP 2.6.2 (like most Usenet administrators currently are) results in the error message: No keys found in 'gnu.key'. Keyring add error. The output of gpg --list-packets is as follows: windlord:~> gpg --list-packets gnu.key :public key packet: version 4, algo 1, created 1017268539, expires 0 pkey[0]: [1024 bits] pkey[1]: [6 bits] :user ID packet: "gnu.gnusenet.announce" :signature packet: algo 1, keyid DC39A12336D978BB version 4, created 1017268539, md5len 0, sigclass 13 digest algo 2, begin of digest 2e 40 hashed subpkt 2 len 5 (sig created 2002-03-27) hashed subpkt 27 len 2 (key flags: 03) hashed subpkt 11 len 6 (pref-sym-algos: 7 10 3 4 2) hashed subpkt 21 len 3 (pref-hash-algos: 3 2) hashed subpkt 22 len 3 (pref-zip-algos: 2 1) hashed subpkt 30 len 2 (features: 01) hashed subpkt 23 len 2 (key server preferences: 80) subpkt 16 len 9 (issuer key ID DC39A12336D978BB) data: [1023 bits] If I understand the issues correctly (and it's quite likely that I don't), those "version 4" notes in the packet are a bad sign for compatibility with PGP 2.6.2. First question: Is this something that's supposed to be working already and I'm just doing something wrong? Second question: If this isn't already implemented, are there plans to implement it, or is there some other way that I can approach this problem? I know I can create the initial key using PGP 2.6.2 and then import it into GnuPG and the resulting signatures can be verified using PGP 2.6.2, but I'd rather not do that if there's an alternative. Thank you very much for any help! -- Russ Allbery (rra@stanford.edu) From rabbi@quickie.net Thu Mar 28 00:20:01 2002 From: rabbi@quickie.net (Len Sassaman) Date: Thu Mar 28 00:20:01 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG In-Reply-To: Message-ID: On Wed, 27 Mar 2002, Russ Allbery wrote: > For the gnu.* hierarchy, we'd obviously prefer to use GnuPG for all stages > of the process rather than using PGP (which is not free software). I see PGP 2.3 was GPL'd. There might be forks of that floating around somewhere that still bear the GPL, if that will serve your purpose. (2.3 proper won't work, because it uses v2 keys.) > If I understand the issues correctly (and it's quite likely that I don't), > those "version 4" notes in the packet are a bad sign for compatibility > with PGP 2.6.2. Yes; PGP 2.6.2 used a different key format, version 3, which had a number of problems with it. The IETF created a new, improved key format to address a number of these issues. OpenPGP compliant apps all use v4. > First question: Is this something that's supposed to be working already > and I'm just doing something wrong? Nope -- GnuPG has partial v3 key support, but does not generate them. > Second question: If this isn't already implemented, are there plans to > implement it, To my knowledge, there are no plans to implement it, because encouraging the creation of more v3 keys isn't really the best thing to be doing. > or is there some other way that I can approach this problem? Have everyone upgrade to an OpenPGP compliant application, like GnuPG or PGP 6.5.8/7.x Other than your suggestion below, not really. There are some utilities out there that will convert a v4 RSA key to a v3 key, but I don't know how stable they are. --Len. From wk@gnupg.org Thu Mar 28 10:02:02 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Mar 28 10:02:02 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG In-Reply-To: (Russ Allbery's message of "Wed, 27 Mar 2002 14:51:57 -0800") References: Message-ID: <87k7rxrruj.fsf@alberti.gnupg.de> On Wed, 27 Mar 2002 14:51:57 -0800, Russ Allbery said: > gpg --gen-key --pgp2 GnuPG does not create the old v3 keys used with PGP2. There are good reasons not to support the old format any longer; it has some minor flaws. GnuPG can use these v3 keys without any problems, though. I'd suggest that you either create the key using PGP2, continue to use an old one or send private mail to discuss whether I can provide an inofficial patch for this. We should add a warning that --pgp2 has no effect on key creation. Werner From disastry@saiknes.lv Thu Mar 28 13:14:01 2002 From: disastry@saiknes.lv (disastry@saiknes.lv) Date: Thu Mar 28 13:14:01 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG Message-ID: <3CA308A5.2A1156A0@saiknes.lv> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Russ Allbery rra@stanford.edu wrote: > If I understand the issues correctly (and it's quite likely that I don't), > those "version 4" notes in the packet are a bad sign for compatibility > with PGP 2.6.2. yes > First question: Is this something that's supposed to be working already > and I'm just doing something wrong? no, but it's very easy to patch gpg so that it can generate RSAv3 keys patch available here: http://disastry.dhs.org/pgp/gpg/gnupg-1.0.6d-keygen.diff With patched GPG to generate RSAv3 key: gpg --expert --pgp2 --gen-key This patch also enables to generate RSA v4 sign+encrypt key as single key. Such keys are not recommended, it's better to generate RSA v4 sign-only key and then generate RSA v4 encrypt-only subkey for it. Anyway: to generate RSA v4 sign+encrypt key: gpg --expert --gen-key > Second question: If this isn't already implemented, are there plans to > implement it, or is there some other way that I can approach this problem? I believe users should be able to generate v3 keys in --expert mode, but I don't think that Werner will apply this patch to official release... :( __ Disastry http://disastry.dhs.org/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPKLsYDBaTVEuJQxkEQPPoQCg6n++keIu+qF15ETDYlLRnYN28bIAoK9r ifmdx4kLrRbKgB3rlaG0vsT+ =uxZW -----END PGP SIGNATURE----- From mwy-gpg41@the-youngs.org Thu Mar 28 20:41:02 2002 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Thu Mar 28 20:41:02 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG References: Message-ID: <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Werner Koch > GnuPG does not create the old v3 keys used with PGP2. There are good > reasons not to support the old format any longer; it has some minor > flaws. GnuPG can use these v3 keys without any problems, though. The flaws are not in the key itself. They're in the fingerprint and keyId computations that get used for identification. You don't *have* to use these forms of identification in order to use the key. As Len noted, you can convert a V4 RSA key to a V3 key (or vice versa). Lookups won't work, and signatures binding that key to names (even the self-signature) won't be valid. But signatures made *by* the key, or material encrypted to the key will be perfectly usable. [Also, note that generating a V4 key and converting to V3 doesn't address the root problem; it's just a workaround.] > I'd suggest that you either create the key using PGP2, continue to use > an old one or send private mail to discuss whether I can provide an > inofficial patch for this. Here, the user appears willing to live with the identification issue. Others are using PGP2.6 anyway, so they already have to be (or should be) careful with identification. Their key distribution and verification may not depend on keyId or fingerprint behavior. If someone is willing to make an patch for it, I would plead for making it official. I would not make it easy -- a separate switch ("--gen-v3-key") and requiring the "--expert" switch seems reasonable. If I thought there were only one user looking for this, an unofficial patch would make more sense to me. I've seen questions here and in newsgroups that suggest that this is not a unique desire. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPKNwp1MkvpTT8vCGEQJ/DwCgvn4wSCa6NqfFECU69Z0g3vwCHfsAn3rV puxSxGteUvVNiUCB7OSsZR1N =ZuJI -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Thu Mar 28 22:32:01 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Thu Mar 28 22:32:01 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG In-Reply-To: <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> References: <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> Message-ID: <20020328212930.GB2019@akamai.com> On Thu, Mar 28, 2002 at 02:36:38PM -0500, Michael Young wrote: > > From: Werner Koch > > I'd suggest that you either create the key using PGP2, continue to use > > an old one or send private mail to discuss whether I can provide an > > inofficial patch for this. > > Here, the user appears willing to live with the identification issue. > Others are using PGP2.6 anyway, so they already have to be (or should > be) careful with identification. Their key distribution and > verification may not depend on keyId or fingerprint behavior. > > If someone is willing to make an patch for it, I would plead for > making it official. I would not make it easy -- a separate switch > ("--gen-v3-key") and requiring the "--expert" switch seems reasonable. I'm on the fence with this. I've seen enough requests for it that I'm fairly sure that a suitably buried (--expert & --pgp2 & warning) v3 key generation would be useful. That's the whole idea of --expert anyway: to enable doing silly/broken/incompatible things that only people who know what they are doing should do. The fact that it would be "useful" is also what worries me... The code change itself is pretty trivial - there would be more code added to print suitably lurid warning messages than there would be added to support generating v3 keys :) With regards to using v3 keys on Usenet control messages, while I think that v3 keys were deprecated for many good reasons, I have some experience with this usage and it's one of the few things I'd be content using v3 keys for. There is such a large installed base of (sometimes half-forgotten) news servers still running PGP 2 that it's safe to say that upgrading any time soon is just not in the cards. Russ, what I'd ask you to do is to send each gnu.* control message twice - each signed with a different (one v3, one v4) key. At least then Usenet can start on the path of using v4 keys. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From md@Linux.IT Fri Mar 29 02:09:02 2002 From: md@Linux.IT (Marco d'Itri) Date: Fri Mar 29 02:09:02 2002 Subject: Generating PGP 2.6.2-compatible RSA signing keys with GnuPG In-Reply-To: <20020328212930.GB2019@akamai.com> References: <002a01c1d68f$e7e20020$ebc42609@transarc.ibm.com> <20020328212930.GB2019@akamai.com> Message-ID: <20020329005631.GA12250@wonderland.linux.it> On Mar 28, David Shaw wrote: >Russ, what I'd ask you to do is to send each gnu.* control message >twice - each signed with a different (one v3, one v4) key. At least >then Usenet can start on the path of using v4 keys. If we want to be incompatible then let's just use DSS. -- ciao, Marco From Enzo Michelangeli"