From stephane@sente.ch Fri Feb 1 17:56:02 2002 From: stephane@sente.ch (Stephane Corthesy) Date: Fri Feb 1 17:56:02 2002 Subject: GPGME bug Message-ID: Hi, I've been playing a little bit again with gpgme, and discovered the following problem: When enumerating keys: the "secret" attribute is retrieved only if we enumerate secret keys! If we enumerate all keys, the attribute "secret" is always set to 0. I also discovered a strange thing with gpg (1.0.6): My PGP key has 2 uids; if I display them with gpg --list-secret-keys or --list-keys, main uid is not the same (swapped). About secret keys again: can a subkey be secret without the main key being secret? Consequence for gpgme is that if I retrieve only secret keys, the main uid of my PGP Key is not the same as if I retrieve all keys. I'm suspecting two other problems (I need to check again): gpgme_op_decrypt(): doesn't return an error if no valid passphrase is given gpgme_op_encrypt(): doesn't return an error if no recipient is trusted, but encrypts nothing Thanks for having written all the doc! It's been very helpful, and I could finally document a little bit the ObjC wrapper :-) Stephane From test@test.com Tue Feb 5 07:49:01 2002 From: test@test.com (test) Date: Tue Feb 5 07:49:01 2002 Subject: (no subject) Message-ID: <3c5f7fc13ca1df8a@relay2.kornet.net> (added by relay2.kornet.net)

안녕하십니까?

"우일산업"입니다

먼저 허락없이 이글을 띄워 죄송합니다.

다름이 아니라 국내에서 순수하게 개발된 "용접대체신제품'

금속*콘크리트 초강력 보수접착제 및 내구성이강한 특수 방식 방수제등

신기술 9종류를 소개하고자 합니다.

특징은 1. 남녀노소 누구나 손쉽게 사용할 수 있다는것과

2. 가정은 물론이고 건축설비, 주택보수, 선박등 다양하게 사용되며

3. 아주 저렴한 가격으로 판매되어 공사및 작업보수비가

매우 적은 비용으로 해결됩니다...

군부대로만 납품하던것을 공공기관이나,건축설비,선박,

공공주택하자보수업체등 다용도로 납품이 되고 있으며,

이제는 소비자들 개개인에게까지 보급하고자 글을 올립니다.

그냥 지나쳐 버리지 마시고 잠깐의 시간을 내셔서

저희 홈페이지인 ☞ www.wooil21.com 오시면

더 자세한 설명과 더 좋은 상품을 만나실수 있을 것입니다.

더 궁금한 사항이 있으시면 02) 967-6704로 연락 주세요

감사합니다.

From jgre@tzi.de Tue Feb 5 11:41:01 2002 From: jgre@tzi.de (Janico Greifenberg) Date: Tue Feb 5 11:41:01 2002 Subject: Questions about GPGME Message-ID: <20020205103806.GC664@tzi.de> Hi, I tried asking this before in the users mailing list but did ot receive an answer so I'm trying it here. My questions are: - Is it possible to change the keyrings used by GPGME and how does it work? - How can I extract more information about importing keys and verifying signatures? I need to know whose key I'm importing and who signed the text. Using GPG itself I can get this information with the --status-fd option but how can I get it with GPGME? Thanks in advance Janico -- Warning! Taking anyone (especially yourself) too serious will be harmful From s.aparna@digital.com Tue Feb 5 11:56:02 2002 From: s.aparna@digital.com (Aparna, S) Date: Tue Feb 5 11:56:02 2002 Subject: GnuPG on Tru64 versions Message-ID: <177E503C4DA3D311BC9D0008C791C30601FE08AB@diexch01.xko.dec.com> Hi, I'm a newbie to GnuPG. I'm interested to know if GnuPG is available for any of the flavors of Compaq Tru64 Unix. Any pointers would be greatly helpful. Thanks, Aparna. From Marcus.Brinkmann@ruhr-uni-bochum.de Tue Feb 5 14:17:01 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Feb 5 14:17:01 2002 Subject: Questions about GPGME In-Reply-To: <20020205103806.GC664@tzi.de> References: <20020205103806.GC664@tzi.de> Message-ID: <20020205131518.GC792@212.23.136.22> On Tue, Feb 05, 2002 at 11:38:06AM +0100, Janico Greifenberg wrote: > Hi, > I tried asking this before in the users mailing list but did ot receive an > answer so I'm trying it here. Mmmh. I think I am not following that list but should. I will subscribe. However, GPGME is still in its development stage, so this is the appropriate forum anyway. > My questions are: > - Is it possible to change the keyrings used by GPGME and how does it work? No, currently the default keyrings of the crypto backend are used. We will need some way to list keys in a seperate file for some other project, but this is probably not what you mean. The question is of course what style of interface we choose for such configuration options of the crypto backend. I will think about it. > - How can I extract more information about importing keys and verifying > signatures? I need to know whose key I'm importing and who signed the > text. Using GPG itself I can get this information with the --status-fd option > but how can I get it with GPGME? After importing a key, you can get back some information about it with gpgme_op_info, I am not sure if that includes everything you need, please come back with more details if you tried it and need more. For verify, there are two functions you can invoke after a successful verification, gpgme_get_sig_status and gpgme_get_sig_key. In the CVS repository of gpgme is a manual in doc/gpgme.texi that documents these functions. Also read the README how to build it, please. 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 toni@eyets.com Tue Feb 5 18:46:01 2002 From: toni@eyets.com (toni) Date: Tue Feb 5 18:46:01 2002 Subject: Hi.... Message-ID: <3C601AED.5070709@eyets.com> Hi, I would like to develop gpg in c for linux... where can i find documentation about functions, or example code? Thanks From Marcus.Brinkmann@ruhr-uni-bochum.de Wed Feb 6 02:15:02 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Feb 6 02:15:02 2002 Subject: aborting (or finishing) pending operations in GPGME In-Reply-To: <20020114004404.GD2449@212.23.136.22> References: <20020114004404.GD2449@212.23.136.22> Message-ID: <20020206011258.GD657@212.23.136.22> On Mon, Jan 14, 2002 at 01:44:05AM +0100, Marcus Brinkmann wrote: > 1. The pending flag is never reset and not resettable. This has been fixed by making gpgme_wait reset the pending flag. > 2. The resulting error value of the operation is not calculable via the > public interface. It is retrieved through internal interfaces. This has been fixed by adding a STATUS argument to gpgme_wait. It is now close to the semantics of waitpid. I also fixed the code to support ctx being non-NULL. 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 Marcus.Brinkmann@ruhr-uni-bochum.de Wed Feb 6 02:24:01 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Feb 6 02:24:01 2002 Subject: upcoming GPGME snapshot (call for last minute API requests) Message-ID: <20020206012210.GF657@212.23.136.22> Hi, if there is something that bugs you in the GPGME API, now would be a good time to tell me, so it can probably be fixed before the upcoming release of a new snapshot (around next weekend). There are some smaller things (and additions for GpgSM) I will do myself, and you don't need to remind me of anything that is on the TODO list (or was reported on the list recently), but if you want to be sure that something goes in, it is better to repeat it than to assume I took notice and rejected 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 Marcus.Brinkmann@ruhr-uni-bochum.de Wed Feb 6 02:32:01 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Feb 6 02:32:01 2002 Subject: aborting (or finishing) pending operations in GPGME In-Reply-To: <20020206011258.GD657@212.23.136.22> References: <20020114004404.GD2449@212.23.136.22> <20020206011258.GD657@212.23.136.22> Message-ID: <20020206012946.GG657@212.23.136.22> On Wed, Feb 06, 2002 at 02:12:58AM +0100, Marcus Brinkmann wrote: > This has been fixed by adding a STATUS argument to gpgme_wait. It is now > close to the semantics of waitpid. I also fixed the code to support ctx > being non-NULL. NULL. Not non-NULL. NULL. Sorry for the confusion. 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 s.aparna@digital.com Wed Feb 6 09:48:01 2002 From: s.aparna@digital.com (Aparna, S) Date: Wed Feb 6 09:48:01 2002 Subject: GnuPG and GPGME version compatibility Message-ID: <177E503C4DA3D311BC9D0008C791C30601FE08B2@diexch01.xko.dec.com> Hi, I'm trying to compile GnuPG on Tru64 platform. Is GPGME V 0.1.4 compatible with GnuPG V1.0.6 ? Thanks, Aparna. From marcus.brinkmann@ruhr-uni-bochum.de Wed Feb 6 11:04:01 2002 From: marcus.brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Feb 6 11:04:01 2002 Subject: GnuPG and GPGME version compatibility In-Reply-To: <177E503C4DA3D311BC9D0008C791C30601FE08B2@diexch01.xko.dec.com> References: <177E503C4DA3D311BC9D0008C791C30601FE08B2@diexch01.xko.dec.com> Message-ID: <20020206110218.GA451@finnegan> On Wed, Feb 06, 2002 at 02:12:56PM +0530, Aparna, S wrote: > I'm trying to compile GnuPG on Tru64 platform. > Is GPGME V 0.1.4 compatible with GnuPG V1.0.6 ? I don't think you should use GPGME V 0.1.4. The current version is 0.3.0. GPGME 0.3.0 (and 0.2.3, which you might give a try as well) is compatible with GnuPG 1.0.6 Thanks, Marcus From s.aparna@digital.com Wed Feb 6 12:32:02 2002 From: s.aparna@digital.com (Aparna, S) Date: Wed Feb 6 12:32:02 2002 Subject: GnuPG and GPGME version compatibility Message-ID: <177E503C4DA3D311BC9D0008C791C30601FE08B3@diexch01.xko.dec.com> I downloaded GPGME V 0.1.4 as it had the latest timestamp on it. Is GPGME 0.3.0 the latest version ? Thanks, Aparna. -----Original Message----- From: Marcus Brinkmann [mailto:marcus.brinkmann@ruhr-uni-bochum.de] Sent: Wednesday, February 06, 2002 4:32 PM To: Aparna, S Cc: 'gnupg-devel@gnupg.org' Subject: Re: GnuPG and GPGME version compatibility On Wed, Feb 06, 2002 at 02:12:56PM +0530, Aparna, S wrote: > I'm trying to compile GnuPG on Tru64 platform. > Is GPGME V 0.1.4 compatible with GnuPG V1.0.6 ? I don't think you should use GPGME V 0.1.4. The current version is 0.3.0. GPGME 0.3.0 (and 0.2.3, which you might give a try as well) is compatible with GnuPG 1.0.6 Thanks, Marcus _______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel From marcus.brinkmann@ruhr-uni-bochum.de Wed Feb 6 14:16:01 2002 From: marcus.brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Feb 6 14:16:01 2002 Subject: GnuPG and GPGME version compatibility In-Reply-To: <177E503C4DA3D311BC9D0008C791C30601FE08B3@diexch01.xko.dec.com> References: <177E503C4DA3D311BC9D0008C791C30601FE08B3@diexch01.xko.dec.com> Message-ID: <20020206141404.GE451@finnegan> On Wed, Feb 06, 2002 at 04:56:20PM +0530, Aparna, S wrote: > I downloaded GPGME V 0.1.4 as it had the latest timestamp on it. > Is GPGME 0.3.0 the latest version ? Yes. I will take a look at the time stamps later. Marcus From wk@gnupg.org Wed Feb 6 14:38:02 2002 From: wk@gnupg.org (Werner Koch) Date: Wed Feb 6 14:38:02 2002 Subject: GPGME bug In-Reply-To: (Stephane Corthesy's message of "Fri, 1 Feb 2002 17:54:12 +0100") References: Message-ID: <87pu3in39c.fsf@alberti.gnupg.de> On Fri, 1 Feb 2002 17:54:12 +0100, Stephane Corthesy said: > When enumerating keys: the "secret" attribute is retrieved only if > we enumerate secret keys! If we enumerate all keys, the attribute > "secret" is always set to 0. Correct. This _might_ change in future but you should not rely on this. If you want a listing of the secret keys you should list the secret keys (e.g. for deciding which key to use for signing). For most tasks you don't need the secret key. > I also discovered a strange thing with gpg (1.0.6): > My PGP key has 2 uids; if I display them with gpg --list-secret-keys > or --list-keys, main uid is not the same (swapped). The UIDs listed with --list-secret-keys are just for convenience. It needs a lot of code to keep them in sync with the ones on the public keyring. So the latest snapshots don't care anymore about packets on the secret keyring and instead do some merging with the public key information. > About secret keys again: can a subkey be secret without the main key > being secret? You should get away from the need to know wether a key is secret or not. The only relevant information is whether a key is capable of signing or decrypting. A secret is a secret is a secret :-) Eventually all secret key[*] handling will be done by gpg-agent and there will be no way for an application (except for special tools) to cope with a secret key. > I'm suspecting two other problems (I need to check again): > gpgme_op_decrypt(): doesn't return an error if no valid passphrase > is given > gpgme_op_encrypt(): doesn't return an error if no recipient is > trusted, but encrypts nothing Be prepared to get some errors after this has been fixed. > Thanks for having written all the doc! It's been very helpful, and I > could finally document a little bit the ObjC wrapper :-) That belongs to Marcus of course. Werner [*] When I talk about a secret key I usually mean the private keys of a public keypair. For conventional encryption a passphrase callback is still needed to automate some applications. -- 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 bwpearre@alumni.princeton.edu Wed Feb 6 19:13:02 2002 From: bwpearre@alumni.princeton.edu (Ben Pearre) Date: Wed Feb 6 19:13:02 2002 Subject: Anderson's attack? Message-ID: <20020206131032.D21208@diverge.seunglab.mit.edu> --FFoLq8A0u+X9iRU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm sorry if this is in the archives - I looked but didn't find it. This seems like a legitimate concern: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html Has this been addressed in GnuPG? The documentation doesn't mention whether gpg --encrypt --sign does Encrypt/Sign or Sign/Encrypt or what. What's really going on in there? Should there be an option --both, which does sign/encrypt/sign or some such? I believe that the first time I installed PGP, there was an option in my MUA to encrypt the relevant headers, but I don't think that this is a problem that should be foisted upon the MUA developers, as no-one seems to know about this issue. Thoughts? Cheers! -Ben --=20 bwpearre@alumni.princeton.edu http://hebb.mit.edu/~ben --FFoLq8A0u+X9iRU8 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 iD8DBQE8YXGY+CWfKs/abNoRAkKrAKCwMJ4q5lMksE7vYtfR0Pg3LyUJzACg4iOu 4BqwborCXiG76d8LNV1YMVI= =ZQG1 -----END PGP SIGNATURE----- --FFoLq8A0u+X9iRU8-- From jgre@tzi.de Wed Feb 6 21:43:02 2002 From: jgre@tzi.de (Janico Greifenberg) Date: Wed Feb 6 21:43:02 2002 Subject: Questions about GPGME In-Reply-To: <20020205131518.GC792@212.23.136.22> References: <20020205103806.GC664@tzi.de> <20020205131518.GC792@212.23.136.22> Message-ID: <20020206204004.GA5312@tzi.de> > No, currently the default keyrings of the crypto backend are used. We will > need some way to list keys in a seperate file for some other project, but > this is probably not what you mean. The question is of course what style > of interface we choose for such configuration options of the crypto backend. > I will think about it. What I would like is are functions like gpgme_set_pubkeyring(char *file); gpgme_set_seckeyring(char *file); gpgme_set_no_default_keyring(int ); or something like that simple setting the gpg options accordingly. > After importing a key, you can get back some information about it with > gpgme_op_info, I am not sure if that includes everything you need, please > come back with more details if you tried it and need more. I think that will work for me. > For verify, there are two functions you can invoke after a successful > verification, gpgme_get_sig_status and gpgme_get_sig_key. This sound good, I just can't get the verify (or decrypt_verify) working. I'm using the folling code: void Crypto::Test(char *msg) { size_t nread; int ret,cnt=0; char *buf_ptr; char str_out[MAX_DATA]; GpgmeSigStat stat; GpgmeData in, out, out2; err = gpgme_data_new_from_mem(&in,msg,strlen(msg),0); if (err) throw CoreError(gpgme_strerror(err)); err = gpgme_data_new ( &out ); if (err) throw CoreError(gpgme_strerror(err)); err = gpgme_op_sign (ctx,in,out,GPGME_SIG_MODE_NORMAL); if (err) throw CoreError(gpgme_strerror(err)); fflush (NULL); err = gpgme_data_rewind ( out ); if (err) throw CoreError(gpgme_strerror(err)); err = gpgme_data_read(out,str_out, MAX_DATA, &nread ); if(err) throw CoreError(gpgme_strerror(err)); gpgme_data_release (in); gpgme_data_release (out); cout<; from bwpearre@mit.edu on Wed, Feb 06, 2002 at 01:10:32PM -0500 References: <20020206131032.D21208@diverge.seunglab.mit.edu> Message-ID: <20020206225706.O25763@mbsks.franken.de> Mahlzeit On Wed, Feb 06, 2002 at 01:10:32PM -0500, Ben Pearre wrote: > Has this been addressed in GnuPG? I don't think this is the correct location to fix this. GnuPG does sign the message. That's it. To understand this, you can look how it is done in the paper world, where the same attack is possible. The way to prevent it here is not to encode the recepient of a letter in your own signature, but to write it onto the letter. So the correct play to fix this would be IMO e.g. the MUA (mutt, etc.). This can include some header lines before signing. Or if you write a contract with some editor, you write the parties yourself into it. Mahlzeit endergone Zwiebeltuete From harmil@spamcop.net Wed Feb 6 23:47:02 2002 From: harmil@spamcop.net (Aaron Sherman) Date: Wed Feb 6 23:47:02 2002 Subject: Anderson's attack? In-Reply-To: <20020206131032.D21208@diverge.seunglab.mit.edu> References: <20020206131032.D21208@diverge.seunglab.mit.edu> Message-ID: <1013035679.9324.239.camel@pps> On Wed, 2002-02-06 at 13:10, Ben Pearre wrote: > I'm sorry if this is in the archives - I looked but didn't find it. > > This seems like a legitimate concern: > > http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > Has this been addressed in GnuPG? The documentation doesn't mention > whether gpg --encrypt --sign does Encrypt/Sign or Sign/Encrypt or > what. What's really going on in there? Doh! This is a classic example of a social problem being attacked on a technical level (which is pretty much doomed to failure). The idea is that T[1]=E(B[pub],S(A[priv],P)) can be transformed into T[2]=E(C[pub],D(B[priv],T[1])) and the encryption envelope will tell you nothing to refute the assertion that A told C P. To which we all respond... duh. The document goes on to possit that where P is some permutation on "sender owes recipient US$X", recipient is ambiguous and all values of T[2,...] yeild an unexpected result for A (i.e. owing money to everyone on the planet). When I'm home, I'll look up and cite the page in AC where this is gone into in some depth, but the core of the argument here is that there is something wrong with this scenario, and that the encryption envelope should be responsible for protecting the innocent but stupid. If you feel this way, feel free to write a mail-encrypting system that duplicates the message headers and includes them in the signed plaintext. That will provide no assurance that you did NOT divulge information of course, but no cryptosystem alone can ever do that (mathematically speaking nothing can ever do that, but for some specialized applications, a reasonable subset can be achived). Ok, back to the topic: this is not gnupg's problem. It should not be gnupg's problem. This is the plaintext's author's problem, as it should be. As for the argument that someone could be fired for leaking company secrets or end up owing people money because of ambiguous statements I say foey. Turn that upside down, and I can buy it: the recipient cannot prove that they were the intended target of the message without some external data source (subpeonaed mailer logs, etc) and thus cannot rely on using the signed message as evidence of a contract or disclosure unless it is internally unambiguous. Yes, this is true. It means that recipients must require that the body of a signed message must be internally unambiguous or only rely on external information which is unambiguous (e.g. "USPS PKI ID xxxx owes USPS PKI ID yyyy the balance of PayPal account zzzz"; if you trust the USPS PKI and PayPal to maintain an unambiguos resolution of these values, then this message is fine....). Ok, I'm done ranting. I'll be in my corner ;-) From rabbi@quickie.net Thu Feb 7 00:52:02 2002 From: rabbi@quickie.net (Len Sassaman) Date: Thu Feb 7 00:52:02 2002 Subject: Anderson's attack? In-Reply-To: <20020206131032.D21208@diverge.seunglab.mit.edu> Message-ID: 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.) As for your Encrypt/Sign question, I think you are asking the order in which that occurs? The signature is inside the encryption envelope. This is the proper way to do it, for privacy/traffic analysis purposes. On Wed, 6 Feb 2002, Ben Pearre wrote: > I'm sorry if this is in the archives - I looked but didn't find it. > > This seems like a legitimate concern: > > http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > Has this been addressed in GnuPG? The documentation doesn't mention > whether gpg --encrypt --sign does Encrypt/Sign or Sign/Encrypt or > what. What's really going on in there? > > Should there be an option --both, which does sign/encrypt/sign or some > such? I believe that the first time I installed PGP, there was an > option in my MUA to encrypt the relevant headers, but I don't think > that this is a problem that should be foisted upon the MUA developers, > as no-one seems to know about this issue. > > Thoughts? > > Cheers! > -Ben > > -- > bwpearre@alumni.princeton.edu http://hebb.mit.edu/~ben > --Len. From s.aparna@digital.com Thu Feb 7 05:44:01 2002 From: s.aparna@digital.com (Aparna, S) Date: Thu Feb 7 05:44:01 2002 Subject: Compilation error while building GnuPG Message-ID: <177E503C4DA3D311BC9D0008C791C30601FE08B6@diexch01.xko.dec.com> Hi, I trying to build GnuPG on Tru64 V5.1. I'm getting the following compilation error while building the tools sources; Make: Don't know how to make -liconv. Stop. I'm curious to know if anyone has faced this problem. Thanks for any help, Aparna. From s.aparna@digital.com Thu Feb 7 13:16:01 2002 From: s.aparna@digital.com (Aparna, S) Date: Thu Feb 7 13:16:01 2002 Subject: GPGSM question Message-ID: <177E503C4DA3D311BC9D0008C791C30601FE08BD@diexch01.xko.dec.com> Hi, I used the 'configure' command while building GPGME. I got the following warning message; checking for gpgsm... no configure: WARNING: Could not find GpgSM, install GpgSM or use --with-gpgsm=PATH to enable it I checked the site www.gnupg.org site to get information on GPGSM. I could not find any. Any pointers ? Thanks, Aparna. From wk@gnupg.org Thu Feb 7 13:43:02 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Feb 7 13:43:02 2002 Subject: GPGSM question In-Reply-To: <177E503C4DA3D311BC9D0008C791C30601FE08BD@diexch01.xko.dec.com> ("Aparna, S"'s message of "Thu, 7 Feb 2002 17:40:33 +0530") References: <177E503C4DA3D311BC9D0008C791C30601FE08BD@diexch01.xko.dec.com> Message-ID: <87u1sth3ih.fsf@alberti.gnupg.de> On Thu, 7 Feb 2002 17:40:33 +0530, Aparna, S said: > I checked the site www.gnupg.org site to get information on GPGSM. I could > not find any. > Any pointers ? It is currently under development and will eventually be part of GnuPG. See http://www.gnupg.org/aegypten/ -- 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 Thu Feb 7 13:53:02 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Feb 7 13:53:02 2002 Subject: Questions about GPGME In-Reply-To: <20020206204004.GA5312@tzi.de> (jgre@tzi.de's message of "Wed, 6 Feb 2002 21:40:04 +0100") References: <20020205103806.GC664@tzi.de> <20020205131518.GC792@212.23.136.22> <20020206204004.GA5312@tzi.de> Message-ID: <87pu3hh32r.fsf@alberti.gnupg.de> On Wed, 6 Feb 2002 21:40:04 +0100, Janico Greifenberg said: > What I would like is are functions like > gpgme_set_pubkeyring(char *file); > gpgme_set_seckeyring(char *file); > gpgme_set_no_default_keyring(int ); > or something like that simple setting the gpg options accordingly. No we can't do this as this would bind the API to one specific backend. > err = gpgme_data_new_from_mem(&in,str_out,strlen(str_out),1); You should not use strlen() here because the signed data is in binary format. Use the value you have in NREAD or force creation of an armored signature using gpgme_set_armor before you do the sign. -- 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 Thu Feb 7 14:48:01 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Feb 7 14:48:01 2002 Subject: [Marcus.Brinkmann@ruhr-uni-bochum.de: Re: Questions about GPGME] Message-ID: <20020207134537.GK1026@212.23.136.22> Mmh, forgot to CC the list. Sorry. ----- Forwarded message from Marcus Brinkmann ----- From: Marcus Brinkmann To: Janico Greifenberg Subject: Re: Questions about GPGME On Wed, Feb 06, 2002 at 09:40:04PM +0100, Janico Greifenberg wrote: > This sound good, I just can't get the verify (or decrypt_verify) working. I'm > using the folling code: I can debug it, but please send in complete (but small) examples that compile without changes (this time I pulled together my C++ knowledge and made it compilable myself). First, a general comment. You might consider wrapping the GPGME data types in C++ classes. They should fall in the C++ style of programming quite naturally. > err = gpgme_op_sign (ctx,in,out,GPGME_SIG_MODE_NORMAL); gpgme_op_verify does only support detached signatures, so you must use GPGME_SIG_MODE_DETACH if you want to verify it with gpgme afterwards. (Except if something is encrypted and signed, then you can use decrypt_verify). > err = gpgme_data_read(out,str_out, MAX_DATA, &nread ); You should not use hard limits like that. Avoid it by using gpgme_data_release_and_get_mem, which returns a pointer to a buffer and its size. > err = gpgme_data_new_from_mem(&in,str_out,strlen(str_out),1); This is the next error. The string consists of binary and might contain binary zeroes. So you should use the size returned by gpgme_data_release_and_get_mem. Alternatively, you can gpgme_data_read the buffer and calculat > bzero(str_out,sizeof(str_out)); > if (err) throw CoreError(gpgme_strerror(err)); > err = gpgme_data_new(&out2); > if (err) throw CoreError(gpgme_strerror(err)); > err = gpgme_op_verify(ctx,in,out2,&stat); gpgme_op_verify does not take an in and an out argument, but a sig and a plain argument (signature and plaintext). Please check out the documentation in doc/gpgme.texi in the CVS repository. 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 ----- End forwarded message ----- -- `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 s.aparna@digital.com Thu Feb 7 15:30:01 2002 From: s.aparna@digital.com (Aparna, S) Date: Thu Feb 7 15:30:01 2002 Subject: GPGSM question Message-ID: <177E503C4DA3D311BC9D0008C791C30601FE08BF@diexch01.xko.dec.com> Thanks for the information. I have another question. Where can I find the documentation for GPGME ? Thanks, Aparna. -----Original Message----- From: Werner Koch [mailto:wk@gnupg.org] Sent: Thursday, February 07, 2002 6:07 PM To: Aparna, S Cc: 'gnupg-devel@gnupg.org' Subject: Re: GPGSM question On Thu, 7 Feb 2002 17:40:33 +0530, Aparna, S said: > I checked the site www.gnupg.org site to get information on GPGSM. I could > not find any. > Any pointers ? It is currently under development and will eventually be part of GnuPG. See http://www.gnupg.org/aegypten/ -- 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 _______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-devel From Marcus.Brinkmann@ruhr-uni-bochum.de Thu Feb 7 16:33:01 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Feb 7 16:33:01 2002 Subject: GPGSM question In-Reply-To: <177E503C4DA3D311BC9D0008C791C30601FE08BF@diexch01.xko.dec.com> References: <177E503C4DA3D311BC9D0008C791C30601FE08BF@diexch01.xko.dec.com> Message-ID: <20020207163033.A305@ulysses.alg.ruhr-uni-bochum.de> On Thu, Feb 07, 2002 at 07:54:51PM +0530, Aparna, S wrote: > Thanks for the information. > I have another question. > Where can I find the documentation for GPGME ? Check out the version from CVS, and run configure with the --enable-maintainer-mode, then it will be built along with gpgme. (see the README for more information, and the web site for more info how to use CVS). Thanks, Marcus From dres@cs.tu-berlin.de Thu Feb 7 20:11:01 2002 From: dres@cs.tu-berlin.de (Stefan Keller) Date: Thu Feb 7 20:11:01 2002 Subject: GnuPG PRNG insecure? Message-ID: <20020207200603.A28608@harry.cs.tu-berlin.de> Hello list, Recently, out of curiosity, I looked at GnuPG's random number generation and stumbled across something I think is problematic. However, I'm not a cryptographer, nor do I have in-depth knowledge on cryptographic secure pseudo random number generation. That's why I ask people here to comment on this. So read this with care; any or all of the things presented herein may be totally wrong. The problem: The problematic line that gave me headaches is in add_randomness() in random.c, where the random noise gathered by the (system dependant) different random code (rndlinux.c rndegd.c rndw32.c ..) is added to our random pool: rndpool[pool_writepos++] = *p++; The problem I see with this is, that previous data in our random pool is simply overwritten with new data. If our gathered data is already random in a cryptographically secure sense, this is not a problem per se. However, on non /dev/random systems such as win32 the system dependent random gather code simply puts much more "random" noise (gathered from lots of different sources of varying quality) into our pool, in the hope that the random pool code handles this correctly (like whitening the buffer via use of a hash function etc.). To further express this, imagine that the system-x random gatherer is asked to add x bytes of random data into our pool. The gatherer "decides" that to satisfy this demand he has to put out 2*POOLSIZE of random noise containing not-that-much entropy. After POOLSIZE bytes have been written, the code in random.c correctly whitens the buffer using RIPEMD160. However, the next POOLSIZE bytes of random data (of questionable quality) *overwrite* anything that was in the pool before, destroying the valuable accumulated entropy. (The worst case would be these last POOLSIZE bytes being all zeros.) The impact: This depends on the quality of the environmental noise gatherer used, but theoretically keys generated with GnuPG on systems lacking a good random source are at risk. The fix: As said, I'm not that experienced with PRNGs etc, but I think this would do just fine: rndpool[pool_writepos++] ^= *p++; This will also harden the PRNG against attacks on systems which *do* have a good random source (such as linux). Furthermore, already collected entropy is not simply thrown away (even if "used"), instead it is kept in full, still it is impossible to guess the current state of the pool based on the previous one (without knowledge of the actual random data). In short: this should always increase the PRNGs quality. Please Cc any replies, as I'm not subscribed. -- Stefan Keller From wk@gnupg.org Thu Feb 7 22:19:03 2002 From: wk@gnupg.org (Werner Koch) Date: Thu Feb 7 22:19:03 2002 Subject: New releases of libgcrypt, libksba and newpg Message-ID: <87u1st9er4.fsf@alberti.gnupg.de> Hi! I have just released some software for the Aegypten project. To demonstrate that we made some progress I bumbed some version numbers a bit ;-) ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.1.6.tar.gz (618k) ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.1.5-1.1.6.diff.gz (12k) ftp://ftp.gnupg.org/gcrypt/alpha/aegypten/libksba-0.2.0.tar.gz (357k) [sorry, no diff file] ftp://ftp.gnupg.org/gcrypt/alpha/aegypten/newpg-0.3.0.tar.gz (262k) ftp://ftp.gnupg.org/gcrypt/alpha/aegypten/newpg-0.0.0-0.3.0.diff.gz (102k) There is no need to build OpenSC yet as we only have some stubs. you need to build libksba and libgcrypt prior to newpg. The major news is that gpg-agent does now operate as a daemon ("eval `gpg-agent`"), caches the passphrases and encrypts the secret keys. You may want to try the gpg-agent with the latest GnuPG CVS version which supports the new protocol - I am using this daily with Gnus. There is also some progress with certicate handling etc. Because theDirMngr has not yet been released the gpgsm option --disable-crl-checks might come handy. For more information consult http://www.gnupg.org/aegypten/ or ask on gpa-dev@gnupg.org. Have fun, 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 mooney@dogbert.cc.ndsu.NoDak.edu Fri Feb 8 03:12:02 2002 From: mooney@dogbert.cc.ndsu.NoDak.edu (Tim Mooney) Date: Fri Feb 8 03:12:02 2002 Subject: GnuPG on Tru64 versions In-Reply-To: <177E503C4DA3D311BC9D0008C791C30601FE08AB@diexch01.xko.dec.com> Message-ID: In regard to: GnuPG on Tru64 versions, Aparna, S said (at 4:20pm on Feb 5,...: >I'm a newbie to GnuPG. I'm interested to know if GnuPG is available for any >of the flavors of Compaq Tru64 Unix. I had a lot of problems with the early 1.0.x versions not working correctly, but 1.0.6 seems to be much better. I haven't used it much yet, though. I compiled it using the vendor cc/ld on Tru64 5.1. Tim -- Tim Mooney mooney@dogbert.cc.ndsu.NoDak.edu Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 From pgut001@cs.auckland.ac.nz Fri Feb 8 07:13:01 2002 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Fri Feb 8 07:13:01 2002 Subject: GnuPG PRNG insecure? Message-ID: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> >Recently, out of curiosity, I looked at GnuPG's random number generation and >stumbled across something I think is problematic. However, I'm not a >cryptographer, nor do I have in-depth knowledge on cryptographic secure pseudo >random number generation. That's why I ask people here to comment on this. So >read this with care; any or all of the things presented herein may be totally >wrong. It's a pretty accurate analysis. The flaw is worrying, but not fatal, since (assuming it accurately implements the design in http://www.cryptoapps.com/~peter/06_random.pdf) the output is only taken from the mixed input of a significant portion of the pool, ie 640 bits of pool data are used for each output block. However, if user seeding is allowed it's a bit more problematic since an attacker can overwrite the pool contents with known values. The original implementation has the comment: /* Mix the incoming data into the pool. This operation is resistant to chosen- and known-input attacks because the pool contents are unknown to an attacker, so XOR'ing in known data won't help them. In an attacker could determine pool contents by observing the generator output (which is defeated by the postprocessing), we'd have to perform an extra input mixing operation to defeat these attacks */ which addresses chosen/known-input attacks (and just for the record, it does XOR the data :-). Without the XOR, you don't have these guarantees. Since GPG doesn't allow outside control of the seeding, this isn't a big problem, but it's still something which should be fixed. Incidentally, this bug is identical to the PGP 2.x xorbytes bug, a web search for that name will find further discussion on this topic. I think copying xorbytes is taking GPG's PGP compatibility a bit far :-). Peter. From wk@gnupg.org Fri Feb 8 08:33:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Feb 8 08:33:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <20020207200603.A28608@harry.cs.tu-berlin.de> (Stefan Keller's message of "Thu, 7 Feb 2002 20:06:03 +0100") References: <20020207200603.A28608@harry.cs.tu-berlin.de> Message-ID: <87bsf0a0yp.fsf@alberti.gnupg.de> On Thu, 7 Feb 2002 20:06:03 +0100, Stefan Keller said: > The problem I see with this is, that previous data in our random > pool is simply overwritten with new data. If our gathered data is Thanks Stefan for pointing this out. As Peter already mentioned, this is not a serious flaw because an attacker is not able to mix data of his choice in. I fixed it of course. 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 Fri Feb 8 08:59:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Feb 8 08:59:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> (pgut001@cs.auckland.ac.nz's message of "Fri, 8 Feb 2002 19:10:18 +1300 (NZDT)") References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> Message-ID: <8766589zoj.fsf@alberti.gnupg.de> On Fri, 8 Feb 2002 19:10:18 +1300 (NZDT), Peter Gutmann said: > (assuming it accurately implements the design in > http://www.cryptoapps.com/~peter/06_random.pdf) the output is only taken from It should implement a CSPRNG as described in your 1998(?) paper. > Incidentally, this bug is identical to the PGP 2.x xorbytes bug, a web search > for that name will find further discussion on this topic. I think copying > xorbytes is taking GPG's PGP compatibility a bit far :-). What worries me most is that it needed *4 years* to figure this bug out _and_ report it. I'd have expected that some more people had a close look at those critical things. It is a very sad thing that there is so less truth in the claim that bugs in Free Software are figured out very fast - I have seen too many counterexamples :-( 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 roam@ringlet.net Fri Feb 8 10:01:01 2002 From: roam@ringlet.net (Peter Pentchev) Date: Fri Feb 8 10:01:01 2002 Subject: Add a --fast option to --import and --recv-keys Message-ID: <20020208105758.A39499@straylight.oblivion.bg> --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, The attached patch adds the benefit of --import-fast to --recv-keys. The new --fast option works with both --import and --recv-keys, only importing the keys without updating the trustdb. --import-fast is still a valid option, but all it does is set the new 'fast' option and then fall back to the handling of --import. This speeds up things a *lot* when fetching multiple keys from a keyserver. Any comments on the patch are appreciated. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? Index: g10/g10.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvsroot/roam/c/contrib/sec/gnupg/g10/g10.c,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- g10/g10.c 8 Feb 2002 06:56:03 -0000 1.1.1.1 +++ g10/g10.c 8 Feb 2002 07:33:51 -0000 1.3 @@ -208,6 +208,7 @@ oNoSigCreateCheck, oEmu3DESS2KBug, /* will be removed in 1.1 */ oEmuMDEncodeBug, + oFast, aTest }; =20 =20 @@ -406,6 +407,7 @@ { aDeleteSecretAndPublicKey, "delete-secret-and-public-key",256, "@" }, { oEmu3DESS2KBug, "emulate-3des-s2k-bug", 0, "@"}, { oEmuMDEncodeBug, "emulate-md-encode-bug", 0, "@"}, + { oFast, "fast", 0, "@" }, {0} }; =20 =20 @@ -751,8 +753,8 @@ switch( pargs.r_opt ) { case aCheckKeys: set_cmd( &cmd, aCheckKeys); break; case aListPackets: set_cmd( &cmd, aListPackets); break; + case aFastImport: opt.fast_import=3D1; /* FALLTHROUGH */ case aImport: set_cmd( &cmd, aImport); break; - case aFastImport: set_cmd( &cmd, aFastImport); break; case aSendKeys: set_cmd( &cmd, aSendKeys); break; case aRecvKeys: set_cmd( &cmd, aRecvKeys); break; case aExport: set_cmd( &cmd, aExport); break; @@ -991,6 +993,7 @@ iobuf_enable_special_filenames (1); break; case oNoExpensiveTrustChecks: opt.no_expensive_trust_checks=3D1;= break; + case oFast: opt.fast_import=3D1; break; =20 default : pargs.err =3D configfp? 1:2; break; } @@ -1370,9 +1373,8 @@ } break; =20 - case aFastImport: case aImport: - import_keys( argc? argv:NULL, argc, (cmd =3D=3D aFastImport) ); + import_keys( argc? argv:NULL, argc, opt.fast_import ); break; =20 case aExport: @@ -1385,7 +1387,7 @@ if( cmd =3D=3D aSendKeys ) hkp_export( sl ); else if( cmd =3D=3D aRecvKeys ) - hkp_import( sl ); + hkp_import( sl , opt.fast_import ); else export_pubkeys( sl, (cmd =3D=3D aExport) ); free_strlist(sl); Index: g10/hkp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvsroot/roam/c/contrib/sec/gnupg/g10/hkp.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- g10/hkp.c 8 Feb 2002 06:56:03 -0000 1.1.1.1 +++ g10/hkp.c 8 Feb 2002 07:32:52 -0000 1.2 @@ -47,7 +47,7 @@ * or other error codes. */ int -hkp_ask_import( u32 *keyid ) +hkp_ask_import( u32 *keyid, int fast ) { struct http_context hd; char *request; @@ -85,7 +85,7 @@ : g10_errstr(rc) ); } else { - rc =3D import_keys_stream( hd.fp_read , 0 ); + rc =3D import_keys_stream( hd.fp_read , fast ); http_close( &hd ); } =20 @@ -96,7 +96,7 @@ =20 =20 int -hkp_import( STRLIST users ) +hkp_import( STRLIST users, int fast ) { if( !opt.keyserver_name ) { log_error(_("no keyserver known (use option --keyserver)\n")); @@ -114,7 +114,7 @@ * errorcounter ist not increaed and the program will return * with success - which is not good when this function is used. */ - if( hkp_ask_import( kid ) ) + if( hkp_ask_import( kid , fast ) ) log_inc_errorcount(); } return 0; Index: g10/hkp.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvsroot/roam/c/contrib/sec/gnupg/g10/hkp.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- g10/hkp.h 8 Feb 2002 06:56:03 -0000 1.1.1.1 +++ g10/hkp.h 8 Feb 2002 07:32:52 -0000 1.2 @@ -23,7 +23,7 @@ =20 =20 int hkp_ask_import( u32 *keyid ); -int hkp_import( STRLIST users ); +int hkp_import( STRLIST users, int fast ); int hkp_export( STRLIST users ); =20 =20 Index: g10/options.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvsroot/roam/c/contrib/sec/gnupg/g10/options.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- g10/options.h 8 Feb 2002 06:56:03 -0000 1.1.1.1 +++ g10/options.h 8 Feb 2002 07:32:52 -0000 1.2 @@ -103,6 +103,7 @@ int no_expensive_trust_checks; int no_sig_cache; int no_sig_create_check; + int fast_import; } opt; =20 =20 --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxjkxYACgkQ7Ri2jRYZRVPbuQCfRbIW2nl+hJkgal5irMkbg+5w aqIAn2rtZZMU0fFHoxColzbdAKVSmPBP =C4jG -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From wk@gnupg.org Fri Feb 8 11:07:01 2002 From: wk@gnupg.org (Werner Koch) Date: Fri Feb 8 11:07:01 2002 Subject: Add a --fast option to --import and --recv-keys In-Reply-To: <20020208105758.A39499@straylight.oblivion.bg> (Peter Pentchev's message of "Fri, 8 Feb 2002 10:57:59 +0200") References: <20020208105758.A39499@straylight.oblivion.bg> Message-ID: <878za48f88.fsf@alberti.gnupg.de> On Fri, 8 Feb 2002 10:57:59 +0200, Peter Pentchev said: > Any comments on the patch are appreciated. Thanks. However the CVS version and the 1.0.6c snapshot have a entirely revamped trustdb which is really fast compared to the old way. The one thing we have to improve is the speed of keylookup by replacing the sequential scans with an index and keeping some meta data. This is partly done but won't go into 1.0.7. Ciao, 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 dshaw@jabberwocky.com Fri Feb 8 15:45:02 2002 From: dshaw@jabberwocky.com (David Shaw) Date: Fri Feb 8 15:45:02 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <8766589zoj.fsf@alberti.gnupg.de> References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> <8766589zoj.fsf@alberti.gnupg.de> Message-ID: <20020208144156.GD678@akamai.com> On Fri, Feb 08, 2002 at 08:54:04AM +0100, Werner Koch wrote: > What worries me most is that it needed *4 years* to figure this bug > out _and_ report it. I'd have expected that some more people had a > close look at those critical things. It is a very sad thing that > there is so less truth in the claim that bugs in Free Software are > figured out very fast - I have seen too many counterexamples :-( Make it worth their while. Netscape used to give out money for each verified bug report. We could give them some free beer to go with their free software. :) I'd be willing to throw some money into a pot for people who find security-related bugs in GnuPG. 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 jas@extundo.com Fri Feb 8 20:07:01 2002 From: jas@extundo.com (Simon Josefsson) Date: Fri Feb 8 20:07:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> (pgut001@cs.auckland.ac.nz's message of "Fri, 8 Feb 2002 19:10:18 +1300 (NZDT)") References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> Message-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Incidentally, this bug is identical to the PGP 2.x xorbytes bug, a web search > for that name will find further discussion on this topic. I think copying > xorbytes is taking GPG's PGP compatibility a bit far :-). Makes you wonder if this code was simply copied from PGP? What about license etc? From dres@cs.tu-berlin.de Fri Feb 8 23:46:01 2002 From: dres@cs.tu-berlin.de (Stefan Keller) Date: Fri Feb 8 23:46:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <200202080610.TAA128327@ruru.cs.auckland.ac.nz>; from pgut001@cs.auckland.ac.nz on Fri, Feb 08, 2002 at 07:10:18PM +1300 References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> Message-ID: <20020208233946.A16027@harry.cs.tu-berlin.de> On Fri, Feb 08, 2002 at 07:10:18PM +1300, Peter Gutmann wrote: > It's a pretty accurate analysis. The flaw is worrying, but not fatal, since > (assuming it accurately implements the design in > http://www.cryptoapps.com/~peter/06_random.pdf) the output is only taken from > the mixed input of a significant portion of the pool, ie 640 bits of pool data > are used for each output block. I've just read your excellent paper (wish I had access to it / read it beforehand). Mind it to explain why the flaw is not fatal? As I explained, on non /dev/random (or equivalent) systems there are often *much* more bytes put into the pool than requested. As soon as 2*POOLSIZE bytes have been put into the pool, the entropy collected with the first POOLSIZE bytes is lost. (Things would be different if GnuPG was keeping some state information of the previous pool mixing operation, such as the last digest computed or the whole hash buffer.) So if those last POOLSIZE bytes happen to contain zero entropy (or a very small amount), it doesn't matter how the output is generated; it will not contain very much randomness, and thus might be easily guessable by an attacker. However, I don't know if this does really happen. I don't know how many bytes e.g. the slow_gatherer in rndw32.c really puts out, but if it happens to be much more than POOLSIZE, the quality of the PRNG solely depends on the last POOLSIZE bytes collected. Unless, of course, I completely misunderstood things. -- Stefan Keller From sroberts@uniserve.com Sat Feb 9 01:33:02 2002 From: sroberts@uniserve.com (Sam Roberts) Date: Sat Feb 9 01:33:02 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <200202080610.TAA128327@ruru.cs.auckland.ac.nz>; from pgut001@cs.auckland.ac.nz on Fri, Feb 08, 2002 at 07:10:18PM +1300 References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> Message-ID: <20020208073557.A50024497@localhost> "just for the record, it does XOR the data" I guess I'm missing something, too, because it certainly looks to me like new data is assigned over data already in the pool, and my understanding was XORing known values into a pool could not DECREASE the entropy in the pool, but assigning seems to mean you'll lose some of the current contents of the pool. What am I missing, where's the XOR occuring? Thanks, Sam Quoting Peter Gutmann , who wrote: > >Recently, out of curiosity, I looked at GnuPG's random number generation and > >stumbled across something I think is problematic. However, I'm not a > >cryptographer, nor do I have in-depth knowledge on cryptographic secure pseudo > >random number generation. That's why I ask people here to comment on this. So > >read this with care; any or all of the things presented herein may be totally > >wrong. > > It's a pretty accurate analysis. The flaw is worrying, but not fatal, since > (assuming it accurately implements the design in > http://www.cryptoapps.com/~peter/06_random.pdf) the output is only taken from > the mixed input of a significant portion of the pool, ie 640 bits of pool data > are used for each output block. > > However, if user seeding is allowed it's a bit more problematic since an > attacker can overwrite the pool contents with known values. The original > implementation has the comment: > > /* Mix the incoming data into the pool. This operation is resistant > to chosen- and known-input attacks because the pool contents are > unknown to an attacker, so XOR'ing in known data won't help them. > In an attacker could determine pool contents by observing the > generator output (which is defeated by the postprocessing), we'd > have to perform an extra input mixing operation to defeat these > attacks */ > > which addresses chosen/known-input attacks (and just for the record, it does > XOR the data :-). Without the XOR, you don't have these guarantees. Since GPG > doesn't allow outside control of the seeding, this isn't a big problem, but > it's still something which should be fixed. > > Incidentally, this bug is identical to the PGP 2.x xorbytes bug, a web search > for that name will find further discussion on this topic. I think copying > xorbytes is taking GPG's PGP compatibility a bit far :-). > > Peter. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- Sam Roberts (Vivez sans temps mort!) From rabbi@quickie.net Sat Feb 9 02:20:01 2002 From: rabbi@quickie.net (Len Sassaman) Date: Sat Feb 9 02:20:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <20020208144156.GD678@akamai.com> Message-ID: On Fri, 8 Feb 2002, David Shaw wrote: > On Fri, Feb 08, 2002 at 08:54:04AM +0100, Werner Koch wrote: > > > What worries me most is that it needed *4 years* to figure this bug > > out _and_ report it. I'd have expected that some more people had a > > close look at those critical things. It is a very sad thing that > > there is so less truth in the claim that bugs in Free Software are > > figured out very fast - I have seen too many counterexamples :-( > > Make it worth their while. Netscape used to give out money for each > verified bug report. We could give them some free beer to go with > their free software. :) Exactly. Open source developers who expect free audits of their code simply because it is open are going to be disappointed, especially if they don't actively seek them. The reasons why source code must be available (from a security auditing perspective) are a) that a user can commission an audit if he wishes, and b) he is assured that the code he just had audited is the real deal, and not a "cleaned" version without back doors. --Len. From dres@cs.tu-berlin.de Sat Feb 9 03:56:02 2002 From: dres@cs.tu-berlin.de (Stefan Keller) Date: Sat Feb 9 03:56:02 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <20020208073557.A50024497@localhost>; from sroberts@uniserve.com on Fri, Feb 08, 2002 at 07:35:58AM -0500 References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> <20020208073557.A50024497@localhost> Message-ID: <20020209035130.A20792@harry.cs.tu-berlin.de> On Fri, Feb 08, 2002 at 07:35:58AM -0500, Sam Roberts wrote: > "just for the record, it does XOR the data" > > What am I missing, where's the XOR occuring? Peter was referring to "the original implementation", which I guess (after reading his paper) is the PRNG implementation in cryptlib. -- Stefan Keller From sroberts@uniserve.com Sat Feb 9 04:56:01 2002 From: sroberts@uniserve.com (Sam Roberts) Date: Sat Feb 9 04:56:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <87bsf0a0yp.fsf@alberti.gnupg.de>; from wk@gnupg.org on Fri, Feb 08, 2002 at 08:26:22AM +0100 References: <20020207200603.A28608@harry.cs.tu-berlin.de> <87bsf0a0yp.fsf@alberti.gnupg.de> Message-ID: <20020208105910.B73285669@localhost> Quoting Werner Koch , who wrote: > On Thu, 7 Feb 2002 20:06:03 +0100, Stefan Keller said: > Thanks Stefan for pointing this out. As Peter already mentioned, this > is not a serious flaw because an attacker is not able to mix data of > his choice in. I fixed it of course. Perhaps it should be fixed in the stable 1.0 branch as well? Sam -- Sam Roberts (Vivez sans temps mort!) From jsogo@debian.org Sat Feb 9 15:43:01 2002 From: jsogo@debian.org (Jose Carlos Garcia Sogo) Date: Sat Feb 9 15:43:01 2002 Subject: GPGME/jnlib includes gcrypt.h Message-ID: <20020209144104.GB2706@jaimedelamo.eu.org> --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello! I was trying to compile latest GPGME 0.3.1, but I have seen that jnlib_config.h includes gcrypt.h, which is not available in the GPGME tarball, and I guess it's part of libgcrypt. Do I need libgcrypt to compile GPGME? The error I get is: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f stringhelp.c || echo './'`stringhelp.c In file included from stringhelp.c:27: libjnlib-config.h:29: gcrypt.h: No such file or directory make[3]: *** [stringhelp.o] Error 1 Cheers,=20 Jose Carlos Garcia Sogo jsogo@debian.org --ftEhullJWpWg/VHq 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 iD8DBQE8ZTUAS+BYJZB4jhERAjC/AKCPzL+QimP/9rQyXpGqYVD5Xtn2owCdHhJf Z4KyIHFb0Sb7dXXsgf+aDm0= =N5wB -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From Marcus.Brinkmann@ruhr-uni-bochum.de Sat Feb 9 22:45:01 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat Feb 9 22:45:01 2002 Subject: GPGME/jnlib includes gcrypt.h In-Reply-To: <20020209144104.GB2706@jaimedelamo.eu.org> References: <20020209144104.GB2706@jaimedelamo.eu.org> Message-ID: <20020209214306.GB1387@212.23.136.22> On Sat, Feb 09, 2002 at 03:41:04PM +0100, Jose Carlos Garcia Sogo wrote: > I was trying to compile latest GPGME 0.3.1, but I have seen that > jnlib_config.h includes gcrypt.h, which is not available in the GPGME > tarball, and I guess it's part of libgcrypt. D'oh! I obviously never read the jnlib README, and when updating it I overwrote the local part of it (of which I wasn't aware at all). As I have libgcrypt installed, I didn't notice this. Thanks for spotting it! You can fix it by going back to the old version of the file, but I will also upload a gpgme 0.3.2. But I will wait until tomorrow, in case you find another bug. Here is a diff for you that reverts the change: Index: libjnlib-config.h =================================================================== RCS file: /cvs/gnupg/gpgme/jnlib/libjnlib-config.h,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- libjnlib-config.h 2002/01/22 16:29:12 1.3 +++ libjnlib-config.h 2002/02/09 21:41:46 1.4 @@ -26,9 +26,11 @@ #ifndef LIBJNLIB_CONFIG_H #define LIBJNLIB_CONFIG_H -#include /* gcry_malloc & Cie. */ +#include "xmalloc.h" #include "logging.h" + + #ifdef USE_SIMPLE_GETTEXT int set_gettext_file( const char *filename ); const char *gettext( const char *msgid ); @@ -56,11 +58,11 @@ #endif /* !USE_SIMPLE_GETTEXT */ -#define jnlib_xmalloc(a) gcry_xmalloc( (a) ) -#define jnlib_xcalloc(a,b) gcry_xcalloc( (a), (b) ) -#define jnlib_xrealloc(a,n) gcry_xrealloc( (a), (n) ) -#define jnlib_xstrdup(a) gcry_xstrdup( (a) ) -#define jnlib_free(a) gcry_free( (a) ) +#define jnlib_xmalloc(a) xmalloc( (a) ) +#define jnlib_xcalloc(a,b) xcalloc( (a), (b) ) +#define jnlib_xrealloc(a,n) xrealloc( (a), (n) ) +#define jnlib_xstrdup(a) xstrdup( (a) ) +#define jnlib_free(a) free( (a) ) #define jnlib_log_debug log_debug #define jnlib_log_info log_info @@ -70,6 +72,4 @@ #endif /*LIBJNUTIL_CONFIG_H*/ - - -- `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 jsogo@debian.org Sun Feb 10 01:35:02 2002 From: jsogo@debian.org (Jose Carlos Garcia Sogo) Date: Sun Feb 10 01:35:02 2002 Subject: GPGME/jnlib includes gcrypt.h In-Reply-To: <20020209214306.GB1387@212.23.136.22> References: <20020209144104.GB2706@jaimedelamo.eu.org> <20020209214306.GB1387@212.23.136.22> Message-ID: <20020210003327.GA31140@jaimedelamo.eu.org> --SUOF0GtieIMvvwua Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El Sat, Feb 09, 2002 at 10:43:06PM +0100, Marcus Brinkmann escrib=EDa: > On Sat, Feb 09, 2002 at 03:41:04PM +0100, Jose Carlos Garcia Sogo wrote: > > I was trying to compile latest GPGME 0.3.1, but I have seen that > > jnlib_config.h includes gcrypt.h, which is not available in the GPGME > > tarball, and I guess it's part of libgcrypt. >=20 [snip] >=20 > Thanks for spotting it! You can fix it by going back to the old version = of > the file, but I will also upload a gpgme 0.3.2. But I will wait until > tomorrow, in case you find another bug. It builds fine now. I'll wait to version 0.3.2 to upload it to Debian. Thank you. Jose Carlos Garcia Sogo jsogo@debian.org --SUOF0GtieIMvvwua 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 iD8DBQE8Zb/XS+BYJZB4jhERAtkDAKCGseLDmq2Xk0NmPxSZoMjthq0aigCfS7pv 4OCUODPeknR0cDi0ECSf74Y= =AcqW -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From Katie19@aol.com Sun Feb 10 09:07:01 2002 From: Katie19@aol.com (Katie19@aol.com) Date: Sun Feb 10 09:07:01 2002 Subject: Free Trial Membership Message-ID: <200202100751.XAA01350@web66.fenzi.com> Below is the result of your feedback form. It was submitted by (Katie19@aol.com) on Saturday, February 9, 2002 at 23:51:16 --------------------------------------------------------------------------- :: Just as a new version is getting ready to come out, the Macverse is up to 0.3.0 of GPGME. The wrappers have some improvements in the API, better documentation, and such. Also, it should work with GNUStep. You can find more info at: http://macgpg.sourceforge.net/ -- 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 Marcus.Brinkmann@ruhr-uni-bochum.de Sun Feb 10 15:00:02 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Feb 10 15:00:02 2002 Subject: GPGME/jnlib includes gcrypt.h In-Reply-To: <20020210003327.GA31140@jaimedelamo.eu.org> References: <20020209144104.GB2706@jaimedelamo.eu.org> <20020209214306.GB1387@212.23.136.22> <20020210003327.GA31140@jaimedelamo.eu.org> Message-ID: <20020210135752.GD696@212.23.136.22> On Sun, Feb 10, 2002 at 01:33:27AM +0100, Jose Carlos Garcia Sogo wrote: > It builds fine now. I'll wait to version 0.3.2 to upload it to > Debian. Thanks, I have uploaded 0.3.2. My announcement is stuck because of moderation, though. 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 wk@gnupg.org Sun Feb 10 18:38:01 2002 From: wk@gnupg.org (Werner Koch) Date: Sun Feb 10 18:38:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: (Len Sassaman's message of "Fri, 8 Feb 2002 17:18:17 -0800 (PST)") References: Message-ID: <87heopkzr9.fsf@alberti.gnupg.de> On Fri, 8 Feb 2002 17:18:17 -0800 (PST), Len Sassaman said: > Exactly. Open source developers who expect free audits of their code > simply because it is open are going to be disappointed, especially if they However a lot of people try to sell this as the advantage of Free Software but the only evidence I have ever saw are counter examples. > The reasons why source code must be available (from a security auditing > perspective) are a) that a user can commission an audit if he wishes, and > b) he is assured that the code he just had audited is the real deal, and 100% agreed. 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 Sun Feb 10 18:48:01 2002 From: wk@gnupg.org (Werner Koch) Date: Sun Feb 10 18:48:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <20020208144156.GD678@akamai.com> (David Shaw's message of "Fri, 8 Feb 2002 09:41:56 -0500") References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> <8766589zoj.fsf@alberti.gnupg.de> <20020208144156.GD678@akamai.com> Message-ID: <87d6zdkzc4.fsf@alberti.gnupg.de> On Fri, 8 Feb 2002 09:41:56 -0500, David Shaw said: > I'd be willing to throw some money into a pot for people who find > security-related bugs in GnuPG. The main problem is that it needs expierenced programmers to find the non trivial bugs. Those programmers are usually writing new code or fixing old one and don't have the time to screen other programs and it is not so interesting to do audits - especially not on a unpaid or low paid basis. So I don't believe that a little bit money will help. 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 Sun Feb 10 18:50:02 2002 From: wk@gnupg.org (Werner Koch) Date: Sun Feb 10 18:50:02 2002 Subject: GnuPG PRNG insecure? In-Reply-To: (Simon Josefsson's message of "Fri, 08 Feb 2002 20:04:58 +0100") References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> Message-ID: <878za1kz7j.fsf@alberti.gnupg.de> On Fri, 08 Feb 2002 20:04:58 +0100, Simon Josefsson said: > Makes you wonder if this code was simply copied from PGP? What about > license etc? *a++ = *b++ is quite a common construct in C as well as *a++ ^= *b++ The random code used by GnuPG is entirely different from the one in PGP. I wrote from the description in Peter's paper. -- 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 mb@g10code.de Sun Feb 10 21:04:03 2002 From: mb@g10code.de (Marcus Brinkmann) Date: Sun Feb 10 21:04:03 2002 Subject: [Announce] GPGME 0.3.2 released Message-ID: <20020210135606.GB696@212.23.136.22> We are pleased to announce version 0.3.2 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 579 KB compressed) ftp://ftp.gnupg.org/gcrypt/alpha/gpgme/gpgme-0.3.2.tar.gz. It should soon appear on the mirrors listed at http://www.gnupg.org/mirrors.html. Bug reports and requests for assistance should be sent to gnupg-devel@gnu.org. The md5sum checksums for this distibution are 9cb02a8c4c70bb291ea002e25eb8dd30 gpgme-0.3.1-0.3.2.diff.gz 987838060829be0235abc4f430cf6cd3 gpgme-0.3.1-0.3.2.diff.gz.sig a3d208a615ccbbc9ce1e31ee7f2f5fc3 gpgme-0.3.2.tar.gz f2b2f839ea4e2f15a2cbd4fafc3dbf6c gpgme-0.3.2.tar.gz.sig Noteworthy changes in version 0.3.2 (2002-02-10) ------------------------------------------------ * Remove erroneous dependency on libgcrypt in jnlib. This is a bug fix release. Please also read the Noteworthy changes in version 0.3.1 (2002-02-09). Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From Marcus.Brinkmann@ruhr-uni-bochum.de Sun Feb 10 21:06:04 2002 From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Feb 10 21:06:04 2002 Subject: [Announce] GPGME 0.3.1 released Message-ID: <20020209020628.GE3429@212.23.136.22> We are pleased to announce version 0.3.1 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 577 KB compressed) ftp://ftp.gnupg.org/gcrypt/alpha/gpgme/gpgme-0.3.1.tar.gz. It should soon appear on the mirrors listed at http://www.gnupg.org/mirrors.html. Bug reports and requests for assistance should be sent to gnupg-devel@gnu.org. The md5sum checksums for this distibution are aa8f7033ac316458e100d3716ea7133b gpgme-0.3.1.tar.gz 518da3712aeeb10e5aeff7c02878c10c gpgme-0.3.1.tar.gz.sig 4cf626a2fd200b673e07e6de5979bedf gpgme-0.3.0-0.3.1.diff.gz 09e30e80bd5f834525ca65458c8b9db7 gpgme-0.3.0-0.3.1.diff.gz.sig Noteworthy changes in version 0.3.1 (2002-02-09) ------------------------------------------------ * There is a Texinfo manual documenting the API. * The gpgme_set_keylist_mode function returns an error, and changed its meaning. It is no longer usable to select between normal and fast mode (newer versions of GnuPG will always be fast), but selects between local keyring, remote keyserver, or both. For this, two new macros are defined, GPGME_KEYLIST_MODE_LOCAL and GPGME_KEYLIST_MODE_EXTERN. To make it possible to modify the current setting, a fucntion gpgme_get_keylist_mode was added to retrieve the current mode. * gpgme_wait accepts a new argument STATUS to return the error status of the operation on the context. Its definition is closer to waitpid() now than before. * The LENGTH argument to gpgme_data_new_from_filepart changed its type from off_t to the unsigned size_t. * The R_HD argument to the GpgmePassphraseCb type changed its type from void* to void**. * New interface gpgme_op_trustlist_end() to match gpgme_op_keylist_end(). * The CryptPlug modules have been renamed to gpgme-openpgp and gpgme-smime, and they are installed in pkglibdir by `make install'. * An idle function can be registered with gpgme_register_idle(). * The GpgSM backend supports key generation with gpgme_op_genkey(). * Interface changes relative to the 0.3.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpgme_data_new_from_filepart CHANGED: Type of LENGTH is size_t. GpgmePassphraseCb CHANGED: Type of R_HD is void **. gpgme_wait CHANGED: New argument STATUS. gpgme_set_keylist_mode CHANGED: Type of return value is GpgmeError. The function has a new meaning! gpgme_get_keylist_mode NEW GPGME_KEYLIST_MODE_LOCAL NEW GPGME_KEYLIST_MODE_EXTERN NEW gpgme_op_trustlist_next NEW GpgmeIdleFunc NEW gpgme_register_idle NEW ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk@gnupg.org Sun Feb 10 22:06:01 2002 From: wk@gnupg.org (Werner Koch) Date: Sun Feb 10 22:06:01 2002 Subject: GnuPG PRNG insecure? In-Reply-To: <20020208233946.A16027@harry.cs.tu-berlin.de> (Stefan Keller's message of "Fri, 8 Feb 2002 23:39:46 +0100") References: <200202080610.TAA128327@ruru.cs.auckland.ac.nz> <20020208233946.A16027@harry.cs.tu-berlin.de> Message-ID: <87n0yh2grw.fsf@alberti.gnupg.de> On Fri, 8 Feb 2002 23:39:46 +0100, Stefan Keller said: > As I explained, on non /dev/random (or equivalent) systems there are often *much* > more bytes put into the pool than requested. As soon as 2*POOLSIZE bytes have > been put into the pool, the entropy collected with the first POOLSIZE bytes is Okay, I did some tests on GNU/Linux (i383) to see how othen a mix_pool is done. For all relevant cases a mix is done not later than when ~65% of the buffer is filled; this carries more than 212 bytes state from one mix to the next. The usual case are mixes after 88 bytes right after a fast poll. But yes, the missing XOR is a serious bug which should be fixed in libgcrypt as ASAP because there we don't have a one-shot use of the application but might use the RNG under entirely different conditions. To make the implementaion more robust I will also carry a hash from the entrire pool between mixes. Thanks again, 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 info@nakawe.se Mon Feb 11 10:16:01 2002 From: info@nakawe.se (Veronica Loell) Date: Mon Feb 11 10:16:01 2002 Subject: generate keys on win2k prof Message-ID: Hello, When I try to generate a key (using winpt) I get an access violation and gpg is shut down by windows. I have searched the mailing list archives etc but not found any clues to what might be the problem. I am using gpg 1.0.6 and win2k 5.00.2195 sp2 Just in case there is any information in the log file I'm enclosing it at the end of this message. Might there be some installation settings that I have not done? I have looked for information about that but not found any. I am not a memebr of this list so if there is someone that has an idea I would appreciate a cc. Thanks. Veronica Loell --------------------- logfile: --------------------- Application exception occurred: App: (pid=1092) When: 2002-02-11 @ 09:58:23.748 Exception number: c0000005 (access violation) *----> System Information <----* Computer Name: NAKAWE-PII-266 User Name: Administrator Number of Processors: 1 Processor Type: x86 Family 6 Model 3 Stepping 3 Windows 2000 Version: 5.0 Current Build: 2195 Service Pack: 2 Current Type: Uniprocessor Free Registered Organization: Nakawe data Registered Owner: Veronica Loell State Dump for Thread Id 0x508 eax=a5a5a5a5 ebx=00000000 ecx=a5a5a5a5 edx=00000002 esi=024b0028 edi=c0000005 eip=77df9877 esp=0248ec64 ebp=0248ee28 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 function: 77df984a 399de0feffff cmp [ebp+0xfffffee0],ebx ss:0248ed08=a5a5a5a5 77df9850 7419 jz 77dffc6b 77df9852 64a118000000 mov eax,fs:[00000018] fs:00000018=???????? 77df9858 ffb5acfeffff push dword ptr [ebp+0xfffffeac] ss:0248ecd4=a5a5a5a5 77df985e 53 push ebx 77df985f 8b4030 mov eax,[eax+0x30] ds:a6947b77=???????? 77df9862 ff7018 push dword ptr [eax+0x18] ds:a6947b77=???????? 77df9865 ff150813db77 call dword ptr [77db1308] ds:77db1308=77fcb633 77df986b 8b8d04ffffff mov ecx,[ebp+0xffffff04] ss:0248ed2c=a5a5a5a5 77df9871 8b85e4feffff mov eax,[ebp+0xfffffee4] ss:0248ed0c=a5a5a5a5 FAULT ->77df9877 01481c add [eax+0x1c],ecx ds:a6947b77=???????? 77df987a 3bfb cmp edi,ebx 77df987c 0f8452010000 je 77df99d4 77df9882 399d0cffffff cmp [ebp+0xffffff0c],ebx ss:0248ed34=00000001 77df9888 7510 jnz 77e0199a 77df988a 81ffea000000 cmp edi,0xea 77df9890 745d jz 77e019ef 77df9892 81ff02010000 cmp edi,0x102 77df9898 7455 jz 77e01bef 77df989a 833d301fe07701 cmp dword ptr [77e01f30],0x1 ds:77e01f30=00000001 77df98a1 7c3e jl 77e021e1 77df98a3 89bd68ffffff mov [ebp+0xffffff68],edi ss:0248ed90=a5a5a5a5 *----> Stack Back Trace <----* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0248EE28 77DF7CC8 0248F164 00000000 7FFDEBF8 0248F2F0 advapi32! 0248F1B0 77DB8523 80000004 7FFDEBF8 00000000 0248F2E8 advapi32! 0248F288 77DB8B63 80000004 7FFDEBF8 0248F2E8 024F2008 advapi32!RegCloseKey 0248F2E0 004675C8 80000004 004671EC 00018000 00000000 advapi32!RegQueryValueExA 0248F3D0 00467829 00459F14 00000003 024D9E01 0046AE8B ! 0248F4A0 0045A10A 00459F14 00000003 0000012C 00000002 ! 0248F4D0 00459D49 00000003 0000012C 00000002 0046BE05 ! 0248F500 00459519 02497AD0 00000014 00000002 0046BD78 ! 0248F540 0045A81B 000000A0 00000002 00000001 02491378 ! 0248F580 0045AC3A 0248F5B0 00000400 0248F63C 00000000 ! 0248F5D0 00447384 00000011 00000400 0248F640 0248F63C ! 0248F600 0043FA21 00000011 00000400 0248F640 0248F63C ! 0248F660 00441827 00000400 024B0FD0 024B0398 02497870 ! 0248F6A0 00442FF3 00000011 00000400 024B0FD0 024B0398 ! 0248F750 00441EDC 024B4000 0248F7E0 00000008 74FC3CC0 ! 0248F790 0044265F 024B4000 00441F4D 0248F7E0 0248F948 ! 0248FCD0 004427B4 00441F4D 02496508 02496508 00402DF9 ! 0248FE00 0040606C 00000000 00000000 00000000 004034A3 ! 0248FF90 00401074 00000000 02492D7C 02495A80 0040105A ! 0248FFC0 77E97D08 0012E34C 00000002 7FFDF000 C0000005 ! 0248FFF0 00000000 00401044 00000000 000000C8 00000100 kernel32!CreateProcessW *----> Raw Stack Dump <----* 0248ec64 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ec74 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ec84 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ec94 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248eca4 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ecb4 a5 a5 a5 a5 a5 a5 a5 a5 - 05 00 00 c0 a5 a5 a5 a5 ................ 0248ecc4 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ecd4 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ece4 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ecf4 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed04 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed14 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed24 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed34 01 00 00 00 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed44 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed54 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed64 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed74 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed84 00 00 00 00 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ 0248ed94 a5 a5 a5 a5 a5 a5 a5 a5 - a5 a5 a5 a5 a5 a5 a5 a5 ................ State Dump for Thread Id 0x608 eax=000001ec ebx=00007530 ecx=024b0f20 edx=00000000 esi=00000000 edi=00000000 eip=77f82837 esp=0714febc ebp=0714fee4 iopl=0 nv up ei ng nz ac po cy cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000297 function: NtRemoveIoCompletion 77f8282c b8a8000000 mov eax,0xa8 77f82831 8d542404 lea edx,[esp+0x4] ss:0803d48f=???????? 77f82835 cd2e int 2e 77f82837 c21400 ret 0x14 *----> Stack Back Trace <----* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0714FEE4 77D470E6 00000074 0714FF1C 0714FF0C 0714FF14 ntdll!NtRemoveIoCompletion 0714FF20 77D5D195 00007530 0714FF60 0714FF5C 0714FF70 rpcrt4!I_RpcSetServerContextList 0714FF74 77D5D074 77D50D7F 0249CB58 00000008 0248E70C rpcrt4!NdrComplexArrayFree 0714FFA8 77D50C7A 024B5F98 0714FFEC 77E8758A 024B0F20 rpcrt4!NdrComplexArrayFree 0714FFB4 77E8758A 024B0F20 00000008 0248E70C 024B0F20 rpcrt4!RpcBindingSetOption 0714FFEC 00000000 00000000 00000000 00000000 00000000 kernel32!SetFilePointer State Dump for Thread Id 0x300 eax=778321fe ebx=00000003 ecx=77db0260 edx=00000000 esi=77f8281e edi=00000003 eip=77f82829 esp=094afd24 ebp=094afd70 iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246 function: NtWaitForMultipleObjects 77f8281e b8e9000000 mov eax,0xe9 77f82823 8d542404 lea edx,[esp+0x4] ss:0a39d2f7=???????? 77f82827 cd2e int 2e 77f82829 c21400 ret 0x14 *----> Stack Back Trace <----* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 094AFD70 77E86E1A 094AFD48 00000001 00000000 00000000 ntdll!NtWaitForMultipleObjects 094AFFB4 77E8758A 00000004 00000000 000B000A 024BEC60 kernel32!WaitForMultipleObjects 094AFFEC 00000000 778321FE 024BEC60 00000000 000000C8 kernel32!SetFilePointer *----> Raw Stack Dump <----* 094afd24 da 6d e8 77 03 00 00 00 - 48 fd 4a 09 01 00 00 00 .m.w....H.J..... 094afd34 00 00 00 00 00 00 00 00 - 00 00 00 00 60 ec 4b 02 ............`.K. 094afd44 01 00 00 00 08 03 00 00 - 0c 03 00 00 1c 03 00 00 ................ 094afd54 67 63 63 20 61 63 63 65 - 70 74 73 20 2d 67 2e 2e gcc accepts -g.. 094afd64 2e 20 79 65 73 0a 63 68 - 65 63 6b 69 b4 ff 4a 09 . yes.checki..J. 094afd74 1a 6e e8 77 48 fd 4a 09 - 01 00 00 00 00 00 00 00 .n.wH.J......... 094afd84 00 00 00 00 00 00 00 00 - b2 22 83 77 03 00 00 00 .........".w.... 094afd94 b0 fe 4a 09 00 00 00 00 - ff ff ff ff 60 ec 4b 02 ..J.........`.K. 094afda4 0a 00 0b 00 00 00 00 00 - 58 69 7a 65 64 20 49 53 ........Xized IS 094afdb4 43 2e 2e 2e 00 00 00 00 - 00 00 00 00 38 00 00 00 C...........8... 094afdc4 23 00 00 00 23 00 00 00 - 00 00 00 00 0a 00 0b 00 #...#........... 094afdd4 60 ec 4b 02 c8 43 f8 77 - 60 02 db 77 fe 21 83 77 `.K..C.w`..w.!.w 094afde4 00 00 00 00 32 75 e8 77 - 1b 00 00 00 00 02 00 00 ....2u.w........ 094afdf4 fc ff 4a 09 23 00 00 00 - 6e 2f 69 6e 73 74 61 6c ..J.#...n/instal 094afe04 6c 20 2d 63 0a 63 68 65 - 63 6b 69 6e 67 20 66 6f l -c.checking fo 094afe14 72 20 6d 61 77 6b 2e 2e - 2e 20 6e 6f 0a 63 68 65 r mawk... no.che 094afe24 63 6b 69 6e 67 20 66 6f - 72 20 67 61 77 6b 2e 2e cking for gawk.. 094afe34 2e 20 6e 6f 0a 63 68 65 - 63 6b 69 6e 67 20 66 6f . no.checking fo 094afe44 72 20 6e 61 77 6b 2e 2e - 2e 20 6e 61 77 6b 0a 63 r nawk... nawk.c 094afe54 68 65 63 6b 69 6e 67 20 - 66 6f 72 20 64 6f 63 62 hecking for docb State Dump for Thread Id 0x410 eax=77df9d61 ebx=00000102 ecx=024b62c0 edx=00000000 esi=77f827dd edi=00000000 eip=77f827e8 esp=0b50ff88 ebp=0b50ffb4 iopl=0 nv up ei ng nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000286 function: NtWaitForSingleObject 77f827dd b8ea000000 mov eax,0xea 77f827e2 8d542404 lea edx,[esp+0x4] ss:0c3fd55b=???????? 77f827e6 cd2e int 2e 77f827e8 c20c00 ret 0xc 77f827eb 8b4124 mov eax,[ecx+0x24] ds:033a3892=???????? 77f827ee 39420c cmp [edx+0xc],eax ds:00eed5d2=???????? 77f827f1 0f85c9100000 jne NtQueryDefaultLocale+0x115 (77f838c0) 77f827f7 ff4208 inc dword ptr [edx+0x8] ds:00eed5d2=???????? 77f827fa 33c0 xor eax,eax 77f827fc c20400 ret 0x4 77f827ff 90 nop 77f82800 ff4a04 dec dword ptr [edx+0x4] ds:00eed5d2=???????? 77f82803 c20400 ret 0x4 *----> Stack Back Trace <----* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0B50FFB4 77E8758A 00000000 00000001 024B0880 00000000 ntdll!NtWaitForSingleObject 0B50FFEC 00000000 77DF9D61 00000000 00000000 00000000 kernel32 From webmaster@dialtalks.com Tue Feb 12 21:47:02 2002 From: webmaster@dialtalks.com (다이얼톡) Date: Tue Feb 12 21:47:02 2002 Subject: [홍보] 엠피쓰리 플레이어를 무료로 드립니다 Message-ID: