Changing the email address on an existing key...how? Should I?
Is it possible (or advisable) to change the email address on an existing pgp key? I'm using GnuPG 1.4.1 on Linux. The man pages do not show how to change or edit the mail address of an existing key. I've had the key(s) a long time and friends use them. I use the same key on several platforms. It would not be too much hassle for me to just create another key with the correct mail address and distribute the public key. What is good practice in this regard and where might I read more about it? TIA. -- Heisenberg was right, I think. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing the email address on an existing key...how? Should I?
At Fri, 22 Jul 2005 16:32:25 -0700, mweisler wrote: > What is good practice in this regard and where might I read more about > it? You could create a new identity and, optionally, revoke the old one. Read more about it in the GNU Privacy Handbook. Also, keep in mind that, if your key is very old already, chances are that it's private part may have been stolen at some point during its life time, unless you have handled it very carefully. If you're worried about this, you may want to create a new key. -- Felix E. Klee ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: zlib inflate problem
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 David Shaw wrote: > On Sun, Jul 24, 2005 at 08:00:48PM +0400, Vladimir N. Kutinsky wrote: > >>Hi, >>I am decrypting files sent to me by another user through my HTTP server. >>Quite often I get errors that look like the following snippet: >> "gpg: fatal: zlib inflate problem: oversubscribed dynamic bit lengths >>tree >> secmem usage: 2368/3808 bytes in 4/9 blocks of pool 3904/32768" >>Could you please tell me what might cause this problem? >> >>I am using GnuPG 1.4.1 on a Win2000. >>File encryption/decription is performed in a batch mode. >>For encryption: >> gpg --openpgp --output OutFile --recipient >>Recipient --armor --yes --batch --encrypt InFile >>For decryption: >> gpg --openpgp --output OutFile --yes --batch --passphrase-fd 0 --decrypt >>InFile > > > Hmm. What version of zlib are you using? > Is this related to the zlib security flaw mentioned back around the 8th of July? Sounds like it might almost be a buffer overflow error... - -- Alphax | /"\ Encrypted Email Preferred | \ / ASCII Ribbon Campaign OpenPGP key ID: 0xF874C613 |X Against HTML email & vCards http://tinyurl.com/cc9up| / \ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC5LZc/RxM5Ph0xhMRA6YhAJ9DaQd/fb0/tM2HboQveux+PHqiFgCeL3Lj OhmBGBFb7f39ZB0xtiOopBA= =eSCH -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Getting Started...
On Monday 25 July 2005 4:06 am, Michael Nguyen wrote: > Eh...something very custom for our customer base. It wouldn't be useful to > anyone else. Assumption is the mother of all $^£&*^ ups. :-) > Basically, what I'm going to do is allow a PGP option for our > users. We'll have a bunch of key generation and storage stuff, but the > part I'm going to write is this: > > - Email comes in for user > - If user is set to have "PGP enabled", check to see if the email is > encrypted > - If encrypted, check the user's key rings and decrypt it Presumably users are aware that this would render their own keys insecure so you're using "group" or "corporate" keys via your key generation/storage? Why then check the *user's* keyrings? Shouldn't that be the central keyring of generated keys (presumably with no passphrase). Users should not be given the impression that these keys are secure for use with personal email, keysigning etc. > - Write this new decrypted buffer to the maildir For absolutely anyone to read - you're merely using encryption for the external part of the mail chain? You assume that your internal security is sufficient to prevent unauthorised users within the company reading the maildir? > That's really rough, but I hope you see what I'm getting at. Well I wouldn't use it! :-) If I encrypt to someone, I expect that person to be the only person to be able to decrypt the message. I do not expect some automated script to be able to decrypt it in passing - I wouldn't sign any such key so exactly who or what is encrypting to this script? Have you looked at x.509 certificates that have a different trust model, perhaps more suited to a "group" or "corporate" model rather than the individual trust inherent in GnuPG/PGP? > I intend to > do the same thing for outgoing mail. Automated encryption is fine - if you've got sufficient keys - but automated decryption always weakens the security and can make encryption itself worthless. How secure is the server that runs the script? How secure do you actually need the communication? Wouldn't using standard protocols via SSH accomplish the same end via much simpler (and standardised) methods? I use a script to automatically encrypt messages from the server to those members who have suitable keys, but I'd never trust any server open to the internet sufficiently to decrypt messages automatically. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpgKM6X6N4v5.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Getting Started...
On Fri, 22 Jul 2005 12:39:10 -0700, Michael Nguyen said:
> need to download? I started with GPGME, but realized that I'm not really
> sure what I need here. Is there a place where I can look at function
GPGME comes with a complete manual ("info gpgme" or build a printable
version using "cd doc; make gpgme.pdf") as well as test programs
useful as examples.
Shalom-Salam,
Werner
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP and Smartcards?
On Fri, 22 Jul 2005 22:42:20 +0200, Zeljko Vrba said: > I would disagree on that. Java Card is totally programmable and if you > want you can implement the complete ISO7816 command set (as far as the Sorry, this is was a misinterpretation by me. > hardware permits, of course). The downside is that you will have to > implement your own filesystem, etc, but it is doable. Well for the OpenPGP card you don't need any filesystem as we onjly use the get/put data commands. Thus a simple offset,length table is what you need. Well, you know that of course. > Why I didn't finish the development - because I've found some > discrepancies between the GPG code, OpenPGP card spec and the PKCS#1 Care to elaborate on this? I am still interested to have reference implementation for java card although I can't help very much with the implementation but I know all the details of the specs and have some knowledge of the gpg code. Salam-Shalom, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg doesn't know
On Sun, 24 Jul 2005 23:58:13 +0400, Vladimir N Kutinsky said: > Does anyone know what it means? > "gpg: CRC error; 92501E - 300D6B > gpg: [don't know]: invalid packet (ctb=2b)" The input data is garbled. Transmission error or the usual ascii vs. binary FTP problem. Salam-Shalom, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP and Smartcards?
On Fri, 22 Jul 2005 23:42:39 +0200, Felix E Klee said: > Your wording implies that the cards I mentioned aren't both secure and > fast. Any pointers? No, I was just not aware that they support 2k RSA and key generation in particular. My (old) specs don't say so. > isn't that interesting, though. The point is that AFAICS PKCS#11 > clearly defines an API, and perhaps it may become an ISO standard in the No it does not define a clean API. Almost everyone is using proprietary extensions and I don't consider that a standard. It is a complex specification targeted to allow some interoperabilty between proprietary applications. With Free Software we are not bound to some of these stupid things. If we would try to support all pcks#11 supported tokes we need to add a lot of extra code to gpg to cope with minor pecularities of the tokens. And well, complexity is the worsest enemy of security. > Framework or openCryptoki (unfortunately those two feature GPL > incompatible licenses but who says that this won't change?). Experience? Missing copyright assignments, lost contact to the authors? > About the weakest link: For a master key the length of the key may well > be the weakest link if the master key is stored away in a safe place and > if it is only used once in a while on reasonably tamper proof systems Unless you have real physical security with guards, barbed wire, 2m concrete walls I really doubt that. Hiring a burgler or a gunman is far out cheaper than to break one key - even if it is a CA key for a small or medium domain. Shalom-Salam, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP and Smartcards?
Felix E. Klee wrote: Huh? AFAICS, in general it is more important to have the subkeys on a smart card than the master key. After all the master key can be stored > But then you cannot commit a mortal sin of using GPG remotely ;) Seriously, I think you have a very strong point in case of keeping the subkeys on the smart card (btw, this will be possible too with the PKCS#11 patch). I carefully chose my passwords so that they have ~50 bits of entropy, using my own utility for the purpose, of course :) http://freshmeat.net/projects/secpwgen/ This key length won't stop NSA but will stop 95% of attackers. For the other 5% I do not worry because I'm not dealing with highly-sensitive data. This is a conscious trade-off security vs. comfort on my side. Having your frequently used keys on the smart-card.. has some disadvantages: - you can't use it remotely (yes, I know, it's bad for security, but I'm comfortable with it since I've defined my threat model) - maybe you'll want to access your mail from some computer on which you're not allowed to install the smart-card reader and its drivers (although it is questionable whether you SHOULD decrypt something on the computer you're not in charge of) I have been employed at a real-world PKI deployment - a national CA in fact. And esp. the 2nd point was one of the major complaints from the users about smart-cards. Another frequent problem was locked smart-card. With smart-card it is much easier to perform the denial-of-service on you than with file-based keys. Say you go on a business trip.. someone steals your smart-card and you can't do business. Or even worse, irreversibly locks both PINs so that the card is effectivly unusable. So, personally, I'd rather have one long-lived master key on the smart-card, get as many people as possible to sign it, and use *that* key to sign my other (shorter-lived) keys. The same scheme I'm also using now, but not with the smart-card. In the hope that I'll never go through the inconvenience of revoking my master key (which, of course, has much stronger passphrase than my 'regular' keys). Of course, it all depends on your threat model, the value of information you are protecting and the minimum desired secrecy lifetime. Best regards, Zeljko. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP and Smartcards?
Werner Koch wrote: On Fri, 22 Jul 2005 23:42:39 +0200, Felix E Klee said: isn't that interesting, though. The point is that AFAICS PKCS#11 clearly defines an API, and perhaps it may become an ISO standard in the No it does not define a clean API. Almost everyone is using proprietary extensions and I don't consider that a standard. It is a > The standard allows for proprietary extensions. However, I have seen several implementations and all of them can do what GPG needs w/o using any extensions. If we would try to support all pcks#11 supported tokes we need to add a lot of extra code to gpg to cope with minor pecularities of the tokens. Unfortunately :( Although the PKCS#11 defines an interface, every vendor has its own interpretation of it because it is, well, complex and vague at some points. Still, my opinion is that PKCS#11 has more-or-less succeeded where ISO7816 has failed: to unify the interface for accessing any kind of cryptographic token (it is not limited to smart-cards either). And I think it is illusionary to think that smart-card vendors are *ever* going to fully conform to the ISO spec. In their world of business, it makes all vendors replacable. And since most of the vendors already have an established market, it is not in their interest to become replacable. Which makes me wonder.. maybe they even interpret on purpose the vague PKCS#11 points differently from their competitors. And well, complexity is the worsest enemy of security. True. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Getting Started...
From: "Werner Koch" <[EMAIL PROTECTED]>
> On Fri, 22 Jul 2005 12:39:10 -0700, Michael Nguyen said:
>
> > need to download? I started with GPGME, but realized that I'm not
really
> > sure what I need here. Is there a place where I can look at function
>
> GPGME comes with a complete manual ("info gpgme" or build a printable
> version using "cd doc; make gpgme.pdf") as well as test programs
> useful as examples.
Yes, I think GPGME seems good enough. I just wanted to know if this is
indeed what I should be using. Thanks guys.
Michael
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP and Smartcards?
Werner Koch wrote: Well for the OpenPGP card you don't need any filesystem as we onjly use the get/put data commands. Thus a simple offset,length table is what you need. Well, you know that of course. Yeah, I know that very well :) It took me a bit of time to correctly implement the coding/decoding of composite objects, but this stuff is now fully working. Why I didn't finish the development - because I've found some discrepancies between the GPG code, OpenPGP card spec and the PKCS#1 Care to elaborate on this? Uff, I would have to look it up to be exact. It has to do with PKCS#1 padding block types. For example, in my signing function I'm not using the Java Signature class (which produces one kind of PKCS#1 block type) but the Cipher class and encrypt method (which produces another kind of PKCS#1 block type) AFAIR, I've lost quite a bit of time on figuring out what was wrong (reading the specs, everything should have fit perfectly) and in the moment of despair I've just changed it to use encrpytion with the private key instead of signature. Before the change GPG complained about invalid signature, but after, the thing magically worked! It may have to do with Sun's cref emulation but nevertheless.. > I am still interested to have reference implementation for java card although I can't help very much with the implementation but I know all thanks, but I don't need any help with the implementation. if I just bit the bullet I believe I could finish it up in a week to be completely functional. I'm having more of a logistic trouble: - I should buy the JCOP development toolkit (ok, that's no problem) - buy from somewhere else a smart-card reader (also shouldn't be a problem) - install Java, which is not trivial on FreeBSD. installing linux on my laptop is not really an option (too much data to move around). hmph, maybe a boot CD+10GB ext2 "disk file" on FAT32 for the linux :) - install Eclipse 3 (since the JCOP toolkit is an Eclipse plugin) - learn to use Eclipse - patch (again! - I've done it so it can talk to cref, but I don't think I've brought the patch with me when I moved :/ ) GPG somehow to talk to the emulated smart-card so I can test the applet without actually downloading it to the card until it's finally finished - and FINALLY, make the applet fully-functional I think that all of the above work exceeds the effort needed to finish the applet :( I'm extremly lazy to do all of the above grunt-work and if I start now, maybe I'll get it finished in 6 months :) then I can start working on the applet :) signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
