From rjh at sixdemonbag.org Wed Dec 1 01:43:22 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 30 Nov 2010 19:43:22 -0500 Subject: Passwords are unwillingly being saved throughout session In-Reply-To: <5782E20A-BB2B-4105-8494-997639BA3E3E@mac.com> References: <5782E20A-BB2B-4105-8494-997639BA3E3E@mac.com> Message-ID: <66CBB61E-AC34-4AAD-8DA8-52DBAB9BD168@sixdemonbag.org> > I hope one of you might have experienced something like this before and can give me a short hint as to where to look. This is expected behavior. In GnuPG 2.0 and later, passphrase caching is handled by a program called gpg-agent. If you want to set timeouts and whatnot, that's the program you'll need to configure. http://www.gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html#Invoking-GPG_002dAGENT -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin at py-soft.co.uk Wed Dec 1 11:32:37 2010 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 1 Dec 2010 10:32:37 +0000 Subject: Passwords are unwillingly being saved throughout session In-Reply-To: <5782E20A-BB2B-4105-8494-997639BA3E3E@mac.com> References: <5782E20A-BB2B-4105-8494-997639BA3E3E@mac.com> Message-ID: On 30 November 2010 22:56, Holger N?ther wrote: > I hope one of you might have experienced something like this before and can give me a short hint as to where to look. It is how gpg2 (and hence MacGPG2) is designed to work. To achieve that you want, add the following to the file ~/.gnupg/gpg-agent.conf: default-cache-ttl 0 Then terminate gpg-agent - either using 'killall gpg-agent" from the command line and then run start-gpg-agent from Applications. Alternatively, just restart your machine. Ben From holger.naether at mac.com Wed Dec 1 11:40:02 2010 From: holger.naether at mac.com (=?utf-8?Q?Holger_N=C3=A4ther?=) Date: Wed, 01 Dec 2010 11:40:02 +0100 Subject: Passwords are unwillingly being saved throughout session In-Reply-To: References: <5782E20A-BB2B-4105-8494-997639BA3E3E@mac.com> Message-ID: <13E2AA73-F819-4193-99B1-BAFCCBA90210@mac.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 01.12.2010 um 11:32 schrieb Benjamin Donnachie: > On 30 November 2010 22:56, Holger N?ther wrote: >> I hope one of you might have experienced something like this before and can give me a short hint as to where to look. > > It is how gpg2 (and hence MacGPG2) is designed to work. > > To achieve that you want, add the following to the file ~/.gnupg/gpg-agent.conf: > > default-cache-ttl 0 > > Then terminate gpg-agent - either using 'killall gpg-agent" from the > command line and then run start-gpg-agent from Applications. > Alternatively, just restart your machine. > > Ben Thank you Ben. I have actually received this hint this morning as well and tried it directly. When I was searching for solutions last night, I was getting stuck since I had no pgp-agent.conf in my ~/.gnupg directory. Only after being pointed to it directly this morning, I noticed that I just have to create it. Everything is working just as I would like it to now. So thank you so much for your support and help on this issue! Best regards, Holger -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iQIcBAEBAgAGBQJM9iYKAAoJENVOU/3eUfz6CEsP/30RG77tTcAuWHPXnYvJYG+f d/1/eVA1wsPM1P6MIHcaZ31EyEW1Ljy90uML0NkrmEZLdYAhfxJeoPk/DoH9Q+Ub /bwSTvGGQZtDfkbr1YOOkgKUH3AHwxWug0Jph4AOS5CdHW18jXM/eh9yYzuUVity bGDmZcjoTtOXpZyASpNtEUw8sAm6xKAE485Dovsj6atyk9DOgt5hPpQomULUf3rW fjckbuR3N4WjXidrlOA6Xxd4CxDp5wLA2TSaxAKZwkCVaZm5DVXHnn7B0nDPG05b 2jg1NepEHPKm/ejDcq5ou+6JPu4moj+b6ybuYbIzOoNVV8kuVEP6QEhtnNeaPOtN 5vwY8cS7HGOJPCD6gnLT97xqqDCAkTwJLYR2uR9aK7JzbqJsHvqLf4tzVx6fesX5 EzxGI46crucF5eh4KGKtouyakuinlJ3UdfmvvWGL6u80wpBImGaru/EwZRYzQhef Ia/K8sRdO+zxMZadHO5Rp5nghY9p8UqvgHk48H1HHEDOsylhZ64fJBdI+u7PCPiS 2JM+8e0aoWV6dYxNZir+Y4tOOgQaRV7KAd5twXQx2IS+VhEFl/N6Bupx3c3lt9rf 0U41vQeZe39HOv6+b10J17fc8x6rS+/QDV2/GYqPOlRg47/gRXcDUPXk96i6ILLB mq2xqSVVu9GRKjBhr1vB =KNti -----END PGP SIGNATURE----- From lukasz.stelmach at iem.pw.edu.pl Thu Dec 2 01:05:19 2010 From: lukasz.stelmach at iem.pw.edu.pl (=?utf-8?Q?=C5=81ukasz?= Stelmach) Date: Thu, 02 Dec 2010 01:05:19 +0100 Subject: GPF Crypto Stick vs OpenPGP Card Message-ID: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> Hello. I'd like to buy either of . Which one should I choose? If I choose OpenPGP Card it would porbably be an ID-OOO with a small USB reader so in both cases I end up with a USB stick. The Card and a reader is 35?, the Stick is 49?. Is there a reason to choose the latter? I've seen this question asked when the Stick has been released but without any answer given. -- Best regards, ?ukasz Stelmach From mailinglisten at hauke-laging.de Thu Dec 2 01:23:46 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 2 Dec 2010 01:23:46 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> Message-ID: <201012020123.46816.mailinglisten@hauke-laging.de> Am Donnerstag 02 Dezember 2010 01:05:19 schrieb ?ukasz Stelmach: > I'd like to buy either of . Which one should I choose? Depends on the number of smartcards you intend to use and on whether you want a PIN pad. The Crypto stick is easier to transport but if it is used with other PCs than yours then the PIN pad becomes even more interesting. > The Card and a reader is 35?, But that's probably one without PIN pad, isn't it? Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From lukasz.stelmach at iem.pw.edu.pl Thu Dec 2 11:00:32 2010 From: lukasz.stelmach at iem.pw.edu.pl (=?utf-8?Q?=C5=81ukasz?= Stelmach) Date: Thu, 02 Dec 2010 11:00:32 +0100 Subject: GPF Crypto Stick vs OpenPGP Card References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012020123.46816.mailinglisten__30328.0058586553$1291249488$gmane$org@hauke-laging.de> Message-ID: <87hbewjxz3.fsf%lukasz.stelmach@iem.pw.edu.pl> Hauke Laging writes: > Am Donnerstag 02 Dezember 2010 01:05:19 schrieb ?ukasz Stelmach: > >> I'd like to buy either of . Which one should I choose? > > Depends on the number of smartcards you intend to use Most probably two. But if I choose the Card+stick-reader option, I will buy two readers. > and on whether you want a PIN pad. Is it strictly required for the Card. > The Crypto stick is easier to transport Portability, the physical one, is near, if not on the very top of the list of priorities. I've got two PCs and a netbook (without a slot for PCMCIA/ExpressCards). That's why I don't consider buying ID-O (full size) Card and *some* readers. > but if it is used with other PCs than yours Most probably not. No PC I know and don't trust, has GPG installed. If it won't by mine the it will belong to someone who is conscious enough to both: install GPG and keep the PC quite clean. > then the PIN pad becomes even more interesting. I am not that paranoid to carry a full sized card reader with a PIN pad with me. >> The Card and a reader is 35?, > > But that's probably one without PIN pad, isn't it? Without but with a Gemalto USB Shell Token V2 reader (USB stick form factor). -- Best regards, ?ukasz Stelmach From ldm at gmx.at Fri Dec 3 03:52:59 2010 From: ldm at gmx.at (Markus Krainz) Date: Fri, 03 Dec 2010 03:52:59 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <87hbewjxz3.fsf%lukasz.stelmach@iem.pw.edu.pl> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012020123.46816.mailinglisten__30328.0058586553$1291249488$gmane$org@hauke-laging.de> <87hbewjxz3.fsf%lukasz.stelmach@iem.pw.edu.pl> Message-ID: <4CF85B8B.7090407@gmx.at> On 2010-12-02 11:00, ?ukasz Stelmach wrote: > >> then the PIN pad becomes even more interesting. > I am not that paranoid to carry a full sized card reader with a PIN pad > with me. > Even with PIN-pad on a compromised computer you still have no guarantee WHAT you are signing. My opinion is that if the computer is compromised you are lost anyway. Regards, Markus From wk at gnupg.org Fri Dec 3 10:26:45 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Dec 2010 10:26:45 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <4CF85B8B.7090407@gmx.at> (Markus Krainz's message of "Fri, 03 Dec 2010 03:52:59 +0100") References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012020123.46816.mailinglisten__30328.0058586553$1291249488$gmane$org@hauke-laging.de> <87hbewjxz3.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> Message-ID: <87fwufb416.fsf@vigenere.g10code.de> On Fri, 3 Dec 2010 03:52, ldm at gmx.at said: > Even with PIN-pad on a compromised computer you still have no guarantee > WHAT you are signing. Right. > My opinion is that if the computer is compromised you are lost anyway. However your key won't become compromised and by plugin the smartcard in only if needed you limit the time frame for malicious use of your key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nils.faerber at kernelconcepts.de Fri Dec 3 09:47:27 2010 From: nils.faerber at kernelconcepts.de (Nils Faerber) Date: Fri, 03 Dec 2010 09:47:27 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <4CF85B8B.7090407@gmx.at> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012020123.46816.mailinglisten__30328.0058586553$1291249488$gmane$org@hauke-laging.de> <87hbewjxz3.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> Message-ID: <4CF8AE9F.7010805@kernelconcepts.de> Am 03.12.2010 03:52, schrieb Markus Krainz: > On 2010-12-02 11:00, ?ukasz Stelmach wrote: >>> then the PIN pad becomes even more interesting. >> I am not that paranoid to carry a full sized card reader with a PIN pad >> with me. >> > > Even with PIN-pad on a compromised computer you still have no guarantee > WHAT you are signing. > My opinion is that if the computer is compromised you are lost anyway. Well, yes and no. With a pinpad at least you have to confirm any transaction so that transactions cannot take place "under the hood" without you noticing. Assuming the attacker got hold of the PIN a malicious software could do an almost unlimited number of transactions without the user being able to notice (well, at least most of the card readers I know do not have something like an activity LED). The non-obvious content of the transaction, what you say as "you do not see what you sign even on the PIN-pad" is an issue that has been discussed a lot of times already - yes, it is definitely an issue but very hard to solve. IMHO this would require a card terminal that understands the data to be signed and present the user with a meaningful summary. But it strictly assumes again that this terminal cannot be compromised too. And being more intelligent (in order to display complex data) means to be a more complex device containing more complex device software which again opens new possible security holes. Very difficult... I once worked in a consortium on such a specialised solution where a PDA would be used as a crypto token and was sent a parsable XML which was to be signed. The (parsed) XML could be presented to the user, a hash calculated and be signed, all on the PDA token terminal. But of course this only worked for the project's special XML data... > Regards, > Markus Cheers nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de From mailinglisten at hauke-laging.de Fri Dec 3 13:21:20 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 3 Dec 2010 13:21:20 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <4CF8AE9F.7010805@kernelconcepts.de> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> <4CF8AE9F.7010805@kernelconcepts.de> Message-ID: <201012031321.30145.mailinglisten@hauke-laging.de> Am Freitag 03 Dezember 2010 09:47:27 schrieb Nils Faerber: > The non-obvious content of the transaction, what you say as "you do not > see what you sign even on the PIN-pad" is an issue that has been > discussed a lot of times already - yes, it is definitely an issue but > very hard to solve. IMHO this would require a card terminal that > understands the data to be signed and present the user with a meaningful > summary. > But it strictly assumes again that this terminal cannot be compromised > too. And being more intelligent (in order to display complex data) means > to be a more complex device containing more complex device software > which again opens new possible security holes. A first improvement would be to show the hash to be signed. Of course, you cannot trust the hash calculation on a potentially compromised PC but this would be a start for further protection (e.g. by sending the file to someone else and comparing the hashes). If I understand the process correctly then not the file hash is signed but the hash for a combination of the file hash and some metadata (timestamp, signer ID). For a security progress the card reader would have to see both hash components which would require a protocol change. IMHO it makes sense to plan this for the future. Ask the card reader whether it has a display and can do the hash calculation itself. If so then send the data in a new format. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From ldm at gmx.at Fri Dec 3 14:12:36 2010 From: ldm at gmx.at (Markus Krainz) Date: Fri, 03 Dec 2010 14:12:36 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <201012031321.30145.mailinglisten@hauke-laging.de> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> <4CF8AE9F.7010805@kernelconcepts.de> <201012031321.30145.mailinglisten@hauke-laging.de> Message-ID: <4CF8ECC4.1050809@gmx.at> On 2010-12-03 13:21, Hauke Laging wrote: > A first improvement would be to show the hash to be signed. Of course, you > cannot trust the hash calculation on a potentially compromised PC but this > would be a start for further protection (e.g. by sending the file to someone > else and comparing the hashes). > > If I understand the process correctly then not the file hash is signed but the > hash for a combination of the file hash and some metadata (timestamp, signer > ID). For a security progress the card reader would have to see both hash > components which would require a protocol change. IMHO it makes sense to plan > this for the future. Ask the card reader whether it has a display and can do > the hash calculation itself. If so then send the data in a new format. > > > Hauke Hi! Very interesting ideas and valuable discussion. Why is this issue so important to me? Because I personally witnessed the Austrian government giving away hundreds of so called "B?rgerkarten" smartcards and free smartcard readers during the 2009 student election. They gave them to the students without explaination and everyone chose a PIN on a public, possibly compromised, laptop form the university. The whole procedure took about 3 minutes per student. What nobody explained to them was that these cards can be used to sign almost anything. The signatures are equal by law to written signatures in almost all kinds of contracts. If your computer is infected you can not tell if you just sold your car for 20.000 euros or 5.000 euros. I think this was a mayor scandal but I never heard anything about it in the media. This is why am I so sensitive about this distinction. This card is still sold and required for online activities with the goverment [1]. Back to gnupg: On 2010-12-03 10:26, Werner Koch wrote: > However your key won't become compromised and by plugin the smartcard in > only if needed you limit the time frame for malicious use of your key. Thats absolutely right. And I think this is why we use the gnupg smartcard including me ;) However you trade this for other disadvantages. My laptop is closely monitored for physical access and I think it's temper evident for me if someone would install a hardware keylogger. So tell me where is the key more secure: 1. on my laptop, which is protected with full disk encryption implemented in open source, and which I operate with an open source operating system and where I employ a rigid patching policy or 2. on a smartcard, where I know nothing about the hardware implementation and where my key is either not encrypted at all or encrypted with a pin that is 6 digits only by default. I have no idea what hardware flaws the card has and how well it can withstand reverse engineering [2]. I am pretty confidet that my OSS-FDE protected harddisk does a better job in protecting my key against physical attacks. Regards, Markus [1]: http://www.buergerkarte.at/ [2]: http://en.wikipedia.org/wiki/Reverse_engineering#Reverse_engineering_of_integrated_circuits.2Fsmart_cards From marcio.barbado at gmail.com Fri Dec 3 14:55:34 2010 From: marcio.barbado at gmail.com (Marcio B. Jr.) Date: Fri, 3 Dec 2010 11:55:34 -0200 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <201012031321.30145.mailinglisten@hauke-laging.de> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> <4CF8AE9F.7010805@kernelconcepts.de> <201012031321.30145.mailinglisten@hauke-laging.de> Message-ID: Ok, let me utilize this thread to clarify something. I've never used those external devices, and my private keys have always been one place only located, a computer. That situation is a sort of "trade-off" for it keeps the referred keys more protected/restricted whereas it gives me little chance of using them in other hosts, easily. So, I guess one of the ideas behind making use of those devices would be the facility of taking all of my keyrings ("secring.gpg" for example) with me everywhere, is it correct? If so, by doing that, weren't we losing the whole point? Regards, On Fri, Dec 3, 2010 at 10:21 AM, Hauke Laging wrote: > Am Freitag 03 Dezember 2010 09:47:27 schrieb Nils Faerber: > >> The non-obvious content of the transaction, what you say as "you do not >> see what you sign even on the PIN-pad" is an issue that has been >> discussed a lot of times already - yes, it is definitely an issue but >> very hard to solve. IMHO this would require a card terminal that >> understands the data to be signed and present the user with a meaningful >> summary. >> But it strictly assumes again that this terminal cannot be compromised >> too. And being more intelligent (in order to display complex data) means >> to be a more complex device containing more complex device software >> which again opens new possible security holes. > > A first improvement would be to show the hash to be signed. Of course, you > cannot trust the hash calculation on a potentially compromised PC but this > would be a start for further protection (e.g. by sending the file to someone > else and comparing the hashes). > > If I understand the process correctly then not the file hash is signed but the > hash for a combination of the file hash and some metadata (timestamp, signer > ID). For a security progress the card reader would have to see both hash > components which would require a protocol change. IMHO it makes sense to plan > this for the future. Ask the card reader whether it has a display and can do > the hash calculation itself. If so then send the data in a new format. > > > Hauke > -- > PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > Marcio Barbado, Jr. From wk at gnupg.org Fri Dec 3 17:32:50 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Dec 2010 17:32:50 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <201012031321.30145.mailinglisten@hauke-laging.de> (Hauke Laging's message of "Fri, 3 Dec 2010 13:21:20 +0100") References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> <4CF8AE9F.7010805@kernelconcepts.de> <201012031321.30145.mailinglisten@hauke-laging.de> Message-ID: <87zksmakb1.fsf@vigenere.g10code.de> On Fri, 3 Dec 2010 13:21, mailinglisten at hauke-laging.de said: > A first improvement would be to show the hash to be signed. Of course, you That does not help. Even if you would be able to compare it with the hash displayed on the host box, you gain nothing: Any malware which foist you a different file for signing won't have a problem to display you the same hash value on the host and and the pinpad. The whole problem of a secure signing device is a problem of the data formats you want to sign. With any of todays en vogue data formats, you need a lot of code on your secure signing device (e.g. a pinpad) to render it for display. This increases the complexity to a level where it will be possible to exploit bugs in those OpenOffice or PDF viewers. In addition those formats have other intrinsic problems which make them a bad choice to be signed in a secure way. What might work are JPEGs - but who wants to sign a JPEG file and have recipients work with an image of your text? Plain text may work, though. For a long text it won't work either, because nobody is going to proofread a text on some small display before signing it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Dec 3 18:45:18 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Dec 2010 12:45:18 -0500 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <87zksmakb1.fsf@vigenere.g10code.de> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> <4CF8AE9F.7010805@kernelconcepts.de> <201012031321.30145.mailinglisten@hauke-laging.de> <87zksmakb1.fsf@vigenere.g10code.de> Message-ID: <4CF92CAE.7040403@fifthhorseman.net> On 12/03/2010 11:32 AM, Werner Koch wrote: > What might work are JPEGs - > but who wants to sign a JPEG file and have recipients work with an image > of your text? JPEGs themselves are problematic because of the ability to embed arbitrary data in the metadata fields (EXIF, etc [0]). So unless Are you willing to try to display arbitrary metadata on your externalized device, you're in trouble there too. > Plain text may work, though. For a long text it won't > work either, because nobody is going to proofread a text on some small > display before signing it. my laptop display is pretty small, and i read what i sign on it ;) --dkg [0] http://blogs.sitepoint.com/2006/08/24/open-source-image-archiving-exif-iptc-xmp-and-all-that/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Dec 3 18:50:00 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Dec 2010 12:50:00 -0500 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <4CF92CAE.7040403@fifthhorseman.net> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> <4CF8AE9F.7010805@kernelconcepts.de> <201012031321.30145.mailinglisten@hauke-laging.de> <87zksmakb1.fsf@vigenere.g10code.de> <4CF92CAE.7040403@fifthhorseman.net> Message-ID: <4CF92DC8.30907@fifthhorseman.net> On 12/03/2010 12:45 PM, Daniel Kahn Gillmor wrote: > So unless Are you willing to try to display [...] > my laptop display is pretty small, and i read what i sign on it ;) sigh. I may read what i sign, but apparently either my grammar or my proofreading skills are still below par :P --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From lukasz.stelmach at iem.pw.edu.pl Fri Dec 3 20:10:33 2010 From: lukasz.stelmach at iem.pw.edu.pl (=?utf-8?Q?=C5=81ukasz?= Stelmach) Date: Fri, 03 Dec 2010 20:10:33 +0100 Subject: GPF Crypto Stick vs OpenPGP Card References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <4CF85B8B.7090407@gmx.at> <4CF8AE9F.7010805@kernelconcepts.de> <201012031321.30145.mailinglisten@hauke-laging.de> <87zksmakb1.fsf@vigenere.g10code.de> <4CF92CAE.7040403@fifthhorseman.net> <4CF92DC8.30907__33292.9825447083$1291398657$gmane$org@fifthhorseman.net> Message-ID: <87k4jqfz9y.fsf%lukasz.stelmach@iem.pw.edu.pl> Daniel Kahn Gillmor writes: > On 12/03/2010 12:45 PM, Daniel Kahn Gillmor wrote: >> So unless Are you willing to try to display > [...] >> my laptop display is pretty small, and i read what i sign on it ;) > > sigh. I may read what i sign, but apparently either my grammar or my > proofreading skills are still below par :P [...] Stick? -- Best regards, ?ukasz Stelmach From mailinglisten at hauke-laging.de Sat Dec 4 02:37:47 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 4 Dec 2010 02:37:47 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <87zksmakb1.fsf@vigenere.g10code.de> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012031321.30145.mailinglisten@hauke-laging.de> <87zksmakb1.fsf@vigenere.g10code.de> Message-ID: <201012040237.48199.mailinglisten@hauke-laging.de> Am Freitag 03 Dezember 2010 17:32:50 schrieb Werner Koch: > On Fri, 3 Dec 2010 13:21, mailinglisten at hauke-laging.de said: > > A first improvement would be to show the hash to be signed. Of course, > > you > > That does not help. Even if you would be able to compare it with the > hash displayed on the host box, you gain nothing: Any malware which > foist you a different file for signing won't have a problem to display > you the same hash value on the host and and the pinpad. Sure, that was clear to me. Let's have a second look at what I wrote: #################### Of course, you cannot trust the hash calculation on a potentially compromised PC but this would be a start for further protection (e.g. by sending the file to someone else and comparing the hashes). #################### :-) Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Mon Dec 6 12:06:19 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 6 Dec 2010 12:06:19 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012031321.30145.mailinglisten@hauke-laging.de> Message-ID: <201012061206.26963.mailinglisten@hauke-laging.de> Am Freitag 03 Dezember 2010 14:55:34 schrieb Marcio B. Jr.: > I've never used those external devices, and my private keys have > always been one place only located, a computer. > > That situation is a sort of "trade-off" for it keeps the referred keys > more protected/restricted whereas it gives me little chance of using > them in other hosts, easily. > > So, I guess one of the ideas behind making use of those devices would > be the facility of taking all of my keyrings ("secring.gpg" for > example) with me everywhere, is it correct? If so, by doing that, > weren't we losing the whole point? As you said: ONE of the ideas. The other one is to ptotect the keys (though not completely their usage) on your more protected system. As "more protected" is still a serious risk in typical environments. Using secret keys on other systems is the more serious argument but even for keys on a single host we are not missing the point. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From marcio.barbado at gmail.com Mon Dec 6 20:21:36 2010 From: marcio.barbado at gmail.com (Marcio B. Jr.) Date: Mon, 6 Dec 2010 17:21:36 -0200 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <201012061206.26963.mailinglisten@hauke-laging.de> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012031321.30145.mailinglisten@hauke-laging.de> <201012061206.26963.mailinglisten@hauke-laging.de> Message-ID: Hello, sorry for this insistence. I just want to get it clearly. So, you mean those devices certainly protect information better than a regular computer (even if making proper use of disk encryption software)? On Mon, Dec 6, 2010 at 9:06 AM, Hauke Laging wrote: > Am Freitag 03 Dezember 2010 14:55:34 schrieb Marcio B. Jr.: > >> I've never used those external devices, and my private keys have >> always been one place only located, a computer. >> >> That situation is a sort of "trade-off" for it keeps the referred keys >> more protected/restricted whereas it gives me little chance of using >> them in other hosts, easily. >> >> So, I guess one of the ideas behind making use of those devices would >> be the facility of taking all of my keyrings ("secring.gpg" for >> example) with me everywhere, is it correct? If so, by doing that, >> weren't we losing the whole point? > > As you said: ONE of the ideas. The other one is to ptotect the keys (though > not completely their usage) on your more protected system. As "more protected" > is still a serious risk in typical environments. Using secret keys on other > systems is the more serious argument but even for keys on a single host we are > not missing the point. > > > Hauke > -- > PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 > Marcio Barbado, Jr. From kgo at grant-olson.net Mon Dec 6 20:38:41 2010 From: kgo at grant-olson.net (Grant Olson) Date: Mon, 06 Dec 2010 14:38:41 -0500 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012031321.30145.mailinglisten@hauke-laging.de> <201012061206.26963.mailinglisten@hauke-laging.de> Message-ID: <4CFD3BC1.7000009@grant-olson.net> On 12/6/10 2:21 PM, Marcio B. Jr. wrote: > Hello, > sorry for this insistence. I just want to get it clearly. > > So, you mean those devices certainly protect information better than a > regular computer (even if making proper use of disk encryption > software)? > Yes. Ultimately a malicious user with 'root' access can compromise any software solution. Maybe that means downloading your keys and mounting an offline attack. Maybe that means downloading your keys and installing a keylogger to get your passphrase. Or finding your unencrypted key that's been cached by gpg-agent in system memory. Full Disk Encryption doesn't provide protection there when your system is up and running, it only helps when someone steals your laptop, or tries to access the system while it's powered down. By moving the keys to a dedicated hardware device, it creates a partition between your (possibly compromised) computer's OS and and the device. The key information never gets loaded into the OS and is opaque to the system. So now a malicious user would need to 'root' your card, or card reader, which would probably involve something like trying to access or change the physical chips on the device, and is much much harder than installing a root-kit, or creating a virus, or developing some other malicious software. That's also why people are talking about readers with pin-pads. That prevents someone from installing a general-purpose keyboard sniffer to get your pin, stealing your physical token, and having the two pieces of info they need to use your keys. -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 559 bytes Desc: OpenPGP digital signature URL: From andre at amorim.me Mon Dec 6 22:50:29 2010 From: andre at amorim.me (Andre Amorim) Date: Mon, 6 Dec 2010 21:50:29 +0000 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <4CFD3BC1.7000009@grant-olson.net> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012031321.30145.mailinglisten@hauke-laging.de> <201012061206.26963.mailinglisten@hauke-laging.de> <4CFD3BC1.7000009@grant-olson.net> Message-ID: Hi, Sorry, I didn't want get too far from the subject of the topic. But the previous post raised a doubt on top of my head. Can anybody explain (if it's not too much technical) why people say that once a key is generated inside the smartcard it is impossible to that key get out of it (except of course the Command> generate Make off-card backup of encryption key? (Y/n)?) Thanks AA On 6 December 2010 19:38, Grant Olson wrote: > On 12/6/10 2:21 PM, Marcio B. Jr. wrote: >> Hello, >> sorry for this insistence. I just want to get it clearly. >> >> So, you mean those devices certainly protect information better than a >> regular computer (even if making proper use of disk encryption >> software)? >> > > Yes. ?Ultimately a malicious user with 'root' access can compromise any > software solution. ?Maybe that means downloading your keys and mounting > an offline attack. ?Maybe that means downloading your keys and > installing a keylogger to get your passphrase. ?Or finding your > unencrypted key that's been cached by gpg-agent in system memory. ?Full > Disk Encryption doesn't provide protection there when your system is up > and running, it only helps when someone steals your laptop, or tries to > access the system while it's powered down. > > By moving the keys to a dedicated hardware device, it creates a > partition between your (possibly compromised) computer's OS and and the > device. ?The key information never gets loaded into the OS and is opaque > to the system. ?So now a malicious user would need to 'root' your card, > or card reader, which would probably involve something like trying to > access or change the physical chips on the device, and is much much > harder than installing a root-kit, or creating a virus, or developing > some other malicious software. > > That's also why people are talking about readers with pin-pads. ?That > prevents someone from installing a general-purpose keyboard sniffer to > get your pin, stealing your physical token, and having the two pieces of > info they need to use your keys. > > > -- > Grant > > "I am gravely disappointed. Again you have made me unleash my dogs of war." > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > From lukasz.stelmach at iem.pw.edu.pl Mon Dec 6 23:27:16 2010 From: lukasz.stelmach at iem.pw.edu.pl (=?utf-8?Q?=C5=81ukasz?= Stelmach) Date: Mon, 06 Dec 2010 23:27:16 +0100 Subject: GPF Crypto Stick vs OpenPGP Card References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012031321.30145.mailinglisten@hauke-laging.de> <201012061206.26963.mailinglisten@hauke-laging.de> <4CFD3BC1.7000009@grant-olson.net> Message-ID: <87lj42bkqj.fsf%lukasz.stelmach@iem.pw.edu.pl> Andre Amorim writes: > Sorry, I didn't want get too far from the subject of the topic. But > the previous post raised a doubt on top of my head. Can anybody > explain (if it's not too much technical) why people say that once a > key is generated inside the smartcard it is impossible to that key get > out of it As far as I know about crypto smartcards (not only OpenPGP on) they have software onboard that can generate a key pair but there is virtually no code that can send it outside of the card. > (except of course the Command> generate > Make off-card backup of encryption key? (Y/n)?) I know: secret keys may be uploaded to a card but not downloaded from it. I think (read speculate): the above question is asked when you generate a key pair on the PC and upload it to a card. -- Mi?ego dnia, ?ukasz Stelmach From lists at chrispoole.com Tue Dec 7 14:05:12 2010 From: lists at chrispoole.com (Chris Poole) Date: Tue, 7 Dec 2010 13:05:12 +0000 Subject: Store revoke cert. in symmetric file? Message-ID: I want to check I'm not doing something stupid. I have backed up my .gnupg directory, including my revoke certificate, to a symmetrically-encrypted tar file. The password for this is a 50 character randomly-generated, stored in my KeePass database (protected via a strong passphrase that I know). --- I should be fine to keep this file and the KeePass database on many locations, and I'm not somehow compromising my private key or revoke certificate? (Standard CAST cipher for the gpg file, AES-256 for the KeePass DB.) Thanks. From dshaw at jabberwocky.com Tue Dec 7 16:24:22 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 7 Dec 2010 10:24:22 -0500 Subject: Store revoke cert. in symmetric file? In-Reply-To: References: Message-ID: On Dec 7, 2010, at 8:05 AM, Chris Poole wrote: > I want to check I'm not doing something stupid. > > I have backed up my .gnupg directory, including my revoke certificate, > to a symmetrically-encrypted tar file. > > The password for this is a 50 character randomly-generated, stored in > my KeePass database (protected via a strong passphrase that I know). > > --- > > I should be fine to keep this file and the KeePass database on many > locations, and I'm not somehow compromising my private key or revoke > certificate? (Standard CAST cipher for the gpg file, AES-256 for the > KeePass DB.) It's hard to answer as there are more factors in play here than what you give above. Given the layers you describe (the GPG passphrase is stored in KeePass, and the GPG encrypted file is stored alongside the KeePass database) I'm not sure where the benefit is in the extra KeePass layer. Why not just store the GPG encrypted file directly with the "strong passphrase that I know" ? David From lists at chrispoole.com Tue Dec 7 17:56:06 2010 From: lists at chrispoole.com (Chris Poole) Date: Tue, 7 Dec 2010 16:56:06 +0000 Subject: Store revoke cert. in symmetric file? In-Reply-To: References: Message-ID: > Why not just store the GPG encrypted file directly with the "strong passphrase that I know" ? I'm happy to do that, I'm just trying to keep the "very long, complicated passphrases I have to remember" to as few as possible. I really just want to make sure that storing my revoke certificate this way (and not in any unencrypted form like on a piece of paper in a safe location) isn't doing something stupid. From vedaal at nym.hush.com Tue Dec 7 20:22:28 2010 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 07 Dec 2010 14:22:28 -0500 Subject: Store revoke cert. in symmetric file? Message-ID: <20101207192228.BC8AE16593F@smtp.hushmail.com> Chris Poole lists at chrispoole.com wrote on Tue Dec 7 17:56:06 CET 2010 : >I'm happy to do that, I'm just trying to keep the "very long, >complicated passphrases I have to remember" to as few as possible. There are many different ways to approach storing a revocation cerificate. ( I have a special key in a safety deposit box, that is a 'designated revoker' for all my other keys. ) Here is an option to do what you want without remembering any other passphrases except for the secret key you already have: [1] Encrypt any file (preferably a very short text message so that you can type the ciphertext as backup) to your existing key. [2] Decrypt the file with the option of --show-session-key . [3] Copy the 64 character session key to use as the passphrase to symmetrically encrypt your revocation certificate. (you can't get a more secure passphrase, ;-) ) [4] Store your symmetrically encrypted revocation certificate, and the encrypted file from step [1] in a location you consider safe for your threat models. vedaal From dshaw at jabberwocky.com Tue Dec 7 20:32:16 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 7 Dec 2010 14:32:16 -0500 Subject: Store revoke cert. in symmetric file? In-Reply-To: References: Message-ID: <4C1F0D7C-64D7-4B74-B827-0CE89EB7B242@jabberwocky.com> On Dec 7, 2010, at 11:56 AM, Chris Poole wrote: >> Why not just store the GPG encrypted file directly with the "strong passphrase that I know" ? > > I'm happy to do that, I'm just trying to keep the "very long, > complicated passphrases I have to remember" to as few as possible. > > I really just want to make sure that storing my revoke certificate > this way (and not in any unencrypted form like on a piece of paper in > a safe location) isn't doing something stupid. It's not necessarily stupid, but it might not be ideal. The idea behind generating a revoke certificate ahead of time is to protect you in case you lose access (forget the passphrase, delete the key, etc, etc) to your secret key. Storing it in an encrypted bundle doesn't really help you if you forget the passphrase to the bundle. David From kgo at grant-olson.net Tue Dec 7 20:40:03 2010 From: kgo at grant-olson.net (Grant Olson) Date: Tue, 07 Dec 2010 14:40:03 -0500 Subject: Store revoke cert. in symmetric file? In-Reply-To: <20101207192228.BC8AE16593F@smtp.hushmail.com> References: <20101207192228.BC8AE16593F@smtp.hushmail.com> Message-ID: <4CFE8D93.4070405@grant-olson.net> On 12/7/10 2:22 PM, vedaal at nym.hush.com wrote: > Here is an option to do what you want without remembering any other > passphrases except for the secret key you already have: > > [1] Encrypt any file (preferably a very short text message so that > you can type the ciphertext as backup) to your existing key. > > [2] Decrypt the file with the option of --show-session-key . > > [3] Copy the 64 character session key to use as the passphrase to > symmetrically encrypt your revocation certificate. > (you can't get a more secure passphrase, ;-) ) > > [4] Store your symmetrically encrypted revocation certificate, and > the encrypted file from step [1] in a location you consider safe > for your threat models. > > But that does no good if you lose your private-key. You can't re-decrypt the file from [1] to get the symmetric key when you need it. And if you still have the private key, you don't need the revocation certificate. You can generate a new one on the fly if your key has been compromised but not lost forever. -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 559 bytes Desc: OpenPGP digital signature URL: From marcio.barbado at gmail.com Tue Dec 7 23:35:46 2010 From: marcio.barbado at gmail.com (Marcio B. Jr.) Date: Tue, 7 Dec 2010 20:35:46 -0200 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: <4CFD3BC1.7000009@grant-olson.net> References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012031321.30145.mailinglisten@hauke-laging.de> <201012061206.26963.mailinglisten@hauke-laging.de> <4CFD3BC1.7000009@grant-olson.net> Message-ID: Thank you, Grant, and perhaps, it's a good idea to own more than one of those devices. One would be in constant use and the other(s) would mirror the former for backup purposes. Because a small size device is easier to be carried, and maybe this fact increases the chances of losing it or getting it stolen. I know its contents cannot be used by other than its legitimate owner. Still, a coherent backup policy would include at least a second device. However, considering what ?ukasz Stelmach answered to Andre Amorim: > I know: secret keys may be uploaded to a card but not downloaded from > it. I think (read speculate): the above question is asked when you > generate a key pair on the PC and upload it to a card. backup seems to be a hard task. Well, supposing you have 2 Crypto Sticks or 2 OpenPGP cards. Is it possible to create a mirroring/"synchronization" scheme between them? And if possible, is it prudent? What do you think of that? Regards, On Mon, Dec 6, 2010 at 5:38 PM, Grant Olson wrote: > On 12/6/10 2:21 PM, Marcio B. Jr. wrote: >> Hello, >> sorry for this insistence. I just want to get it clearly. >> >> So, you mean those devices certainly protect information better than a >> regular computer (even if making proper use of disk encryption >> software)? >> > > Yes. ?Ultimately a malicious user with 'root' access can compromise any > software solution. ?Maybe that means downloading your keys and mounting > an offline attack. ?Maybe that means downloading your keys and > installing a keylogger to get your passphrase. ?Or finding your > unencrypted key that's been cached by gpg-agent in system memory. ?Full > Disk Encryption doesn't provide protection there when your system is up > and running, it only helps when someone steals your laptop, or tries to > access the system while it's powered down. > > By moving the keys to a dedicated hardware device, it creates a > partition between your (possibly compromised) computer's OS and and the > device. ?The key information never gets loaded into the OS and is opaque > to the system. ?So now a malicious user would need to 'root' your card, > or card reader, which would probably involve something like trying to > access or change the physical chips on the device, and is much much > harder than installing a root-kit, or creating a virus, or developing > some other malicious software. > > That's also why people are talking about readers with pin-pads. ?That > prevents someone from installing a general-purpose keyboard sniffer to > get your pin, stealing your physical token, and having the two pieces of > info they need to use your keys. > > > -- > Grant > > "I am gravely disappointed. Again you have made me unleash my dogs of war." > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > Marcio Barbado, Jr. From kgo at grant-olson.net Wed Dec 8 00:55:57 2010 From: kgo at grant-olson.net (Grant Olson) Date: Tue, 07 Dec 2010 18:55:57 -0500 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012031321.30145.mailinglisten@hauke-laging.de> <201012061206.26963.mailinglisten@hauke-laging.de> <4CFD3BC1.7000009@grant-olson.net> Message-ID: <4CFEC98D.3030706@grant-olson.net> On 12/7/10 5:35 PM, Marcio B. Jr. wrote: > > backup seems to be a hard task. > > Well, supposing you have 2 Crypto Sticks or 2 OpenPGP cards. Is it > possible to create a mirroring/"synchronization" scheme between them? > > And if possible, is it prudent? What do you think of that? > I don't think you need two active cards. I personally created a key normally (actually the one that I had been using for months before I got the card), had backups and all that, and migrated the keys to the card. Alternately, it sounds like people are saying you are prompted to create a backup file if you try to create a key directly on a card, but I didn't do this so I can't confirm if/how that works. Either way, if you have a proper backup, you can restore the backup to disk normally, then move it onto a replacement key's hardware. -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 559 bytes Desc: OpenPGP digital signature URL: From mohanr at fss.co.in Wed Dec 8 14:01:15 2010 From: mohanr at fss.co.in (Mohan Radhakrishnan) Date: Wed, 8 Dec 2010 18:31:15 +0530 Subject: Armor key - X.501 Message-ID: <0EE14841E1FD8545B7E084F22AEF96810444F831@fssbemail.fss.india> Hi, What is the standard that the GPG armor key is compliant with ? X.501 ? Thanks, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Wed Dec 8 15:32:55 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 8 Dec 2010 09:32:55 -0500 Subject: Armor key - X.501 In-Reply-To: <0EE14841E1FD8545B7E084F22AEF96810444F831@fssbemail.fss.india> References: <0EE14841E1FD8545B7E084F22AEF96810444F831@fssbemail.fss.india> Message-ID: On Dec 8, 2010, at 8:01 AM, Mohan Radhakrishnan wrote: > Hi, > What is the standard that the GPG armor key is compliant with ? X.501 ? RFC-4880 (http://tools.ietf.org/html/rfc4880). See section 6 in particular for how the armor is formed, and sections 4 and 11 for what goes into the armor. David From hankivy at hot.rr.com Wed Dec 8 21:20:14 2010 From: hankivy at hot.rr.com (Hank Ivy) Date: Wed, 8 Dec 2010 14:20:14 -0600 Subject: Protecting IDs at a key signing party Message-ID: <201012081420.14986.hankivy@hot.rr.com> I moved to a small town in a new state for personal reasons. For work I telecommuted as an independent consultant. A computer user group I joined recently is going to be holding a key signing party. NOBODY has met me more than three times, once a month. Should I take more than two government issued IDs? If the answer is to take more IDs, how should I organize, and protect them? I could also bring a birth certificate, high school yearbook, URL to a college yearbook, US Army BCT yearbook, a photo of my US Army BCT platoon (signed on the back by 80% of the platoon), several college student IDs, four or five business cards from employment at two major computer manufacturers, three expired passports, URL to Linkedin, and an URL to Facebook. All of it would seem like overkill. What should I take? How should I organize, and protect the IDs? -- Hank Ivy GPG Fingerprint: 1A0F E1CB 0160 0069 7C19 4B00 911C 92E8 F8B0 4C7C From rjh at sixdemonbag.org Wed Dec 8 22:54:02 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 08 Dec 2010 16:54:02 -0500 Subject: Protecting IDs at a key signing party In-Reply-To: <201012081420.14986.hankivy@hot.rr.com> References: <201012081420.14986.hankivy@hot.rr.com> Message-ID: <4CFFFE7A.6010704@sixdemonbag.org> On 12/8/10 3:20 PM, Hank Ivy wrote: > What should I take? How should I organize, and protect the IDs? For me, I bring a passport and a driver's license. If anyone tells me "that's not enough for me!", well, okay: it's not enough for them. There are plenty of other people at the keysigning party, and I might not want to have a signature from someone quite that paranoid and tinfoil-hatted, anyway. :) The best way to protect the ID is to not let it out of your sight. If someone wants to hold onto your ID to inspect it, let them: but don't let them walk away with it. Sounds stupid, but it works. Honestly, the biggest ID risk at a keysigning party is people accidentally walking away with each others' drivers' licenses. From dshaw at jabberwocky.com Wed Dec 8 23:12:54 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 8 Dec 2010 17:12:54 -0500 Subject: Protecting IDs at a key signing party In-Reply-To: <201012081420.14986.hankivy@hot.rr.com> References: <201012081420.14986.hankivy@hot.rr.com> Message-ID: On Dec 8, 2010, at 3:20 PM, Hank Ivy wrote: > I moved to a small town in a new state for personal reasons. For work I telecommuted as an > independent consultant. A computer user group I joined recently is going to be holding a key > signing party. NOBODY has met me more than three times, once a month. > > Should I take more than two government issued IDs? > > If the answer is to take more IDs, how should I organize, and protect them? > > I could also bring a birth certificate, high school yearbook, URL to a college yearbook, US Army > BCT yearbook, a photo of my US Army BCT platoon (signed on the back by 80% of the platoon), > several college student IDs, four or five business cards from employment at two major computer > manufacturers, three expired passports, URL to Linkedin, and an URL to Facebook. All of it > would seem like overkill. > > What should I take? How should I organize, and protect the IDs? There isn't a simple answer here, since people who sign keys can each decide what they want before signing. Personally, I'll sign with two government issued IDs, and wouldn't bother to bring more than that to a party. David From jh at jameshoward.us Wed Dec 8 22:29:03 2010 From: jh at jameshoward.us (James P. Howard, II) Date: Wed, 8 Dec 2010 16:29:03 -0500 Subject: Protecting IDs at a key signing party In-Reply-To: <201012081420.14986.hankivy@hot.rr.com> References: <201012081420.14986.hankivy@hot.rr.com> Message-ID: On Wed, Dec 8, 2010 at 15:20, Hank Ivy wrote: > What should I take? ?How should I organize, and protect the IDs? Take two. A driver's license and a passport would be best, though one probably authenticated you for the other. To protect them, put them in your wallet or pocket. James From mailinglisten at hauke-laging.de Wed Dec 8 23:35:04 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 8 Dec 2010 23:35:04 +0100 Subject: Protecting IDs at a key signing party In-Reply-To: <4CFFFE7A.6010704@sixdemonbag.org> References: <201012081420.14986.hankivy@hot.rr.com> <4CFFFE7A.6010704@sixdemonbag.org> Message-ID: <201012082335.11639.mailinglisten@hauke-laging.de> Am Mittwoch 08 Dezember 2010 22:54:02 schrieb Robert J. Hansen: > For me, I bring a passport and a driver's license. If anyone tells me > "that's not enough for me!", well, okay: it's not enough for them. That should not be a question of personal attitude but of the signing policy for the respective key. As there are different scenarios in real life there should be different keys or at least signing descriptions available for everyone. As reading prose policys does not scale well I would like to have a standard for that. I have mentioned that on this list before. The very simple certification level scheme could be extended be e.g. standardized notations. There is a IETF reserved notation namespace but there aren't any IETF notations yet. I suggest a standard for at least these pieces of information: - key owner has been personally known for x years - frequent contact with the key owner for x years - x family members of the key owner have been personally known for y years - identity has been checked by looking at document of type x - identity has been checked by electronic means (of type x) - email address has been checked - key is on a smartcard - key has been created on a smartcard with no backup - key has been created on a smartcard with a secure offline backup only - main key has been created in a secure environment - key is intended for usage in an unsecure environment (e.g. Webmail) - key is intended for usage in a secure environment only - other keys of this key owner: ... (for better trust calculations) - key is (not) intended for signing (small / high amount) treaties The result would be a machine readable signature policy. And you could certify any key. GnuPG could be configured how to translate this detailed data into the current three levels of checking effort. Today you have signature policies for some keys. But what are they worth? Imagine you have a rather insecure key for spam (filter) protection and the like. This key gets compromised. The attacker can easily write a signing policy which claims this key to be a high security smartcard key and sign it. Worth nothing. Trustworthy signature policies have to be signed by the people who sign the key itself, too. This would be achieved if you had a kind of signature policy within the signature notations. The document types should contain both general entries and national extentions. This way an important feature could be added: Signing subkeys. The impossibility to do this makes GnuPG incompatible with at least the German law for digital signatures (unless the CA would destroy the secret main key and give only the subkeys to the customer which is not the idea of GnuPG I think). The subkeys would not be signed directly but their fingerprints would become signature notations. A bit off-topic. Sorry. :-) But I really hope there are a few people out there who see the same need... Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From faramir.cl at gmail.com Thu Dec 9 01:17:53 2010 From: faramir.cl at gmail.com (Faramir) Date: Wed, 08 Dec 2010 21:17:53 -0300 Subject: Store revoke cert. in symmetric file? In-Reply-To: <4C1F0D7C-64D7-4B74-B827-0CE89EB7B242@jabberwocky.com> References: <4C1F0D7C-64D7-4B74-B827-0CE89EB7B242@jabberwocky.com> Message-ID: <4D002031.3070206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 07-12-2010 16:32, David Shaw escribi?: > On Dec 7, 2010, at 11:56 AM, Chris Poole wrote: > >>> Why not just store the GPG encrypted file directly with the "strong passphrase that I know" ? >> >> I'm happy to do that, I'm just trying to keep the "very long, >> complicated passphrases I have to remember" to as few as possible. >> >> I really just want to make sure that storing my revoke certificate >> this way (and not in any unencrypted form like on a piece of paper in >> a safe location) isn't doing something stupid. > > It's not necessarily stupid, but it might not be ideal. The idea behind generating a revoke certificate ahead of time is to protect you in case you lose access (forget the passphrase, delete the key, etc, etc) to your secret key. Storing it in an encrypted bundle doesn't really help you if you forget the passphrase to the bundle. I (but that is ME, just my opinion) would remove that 50 characters long randomly generated passphrase. Chances are if you don't use it very often, you will forget it, and then you won't be able to revoke your keys. Or maybe, I would change it for a shorter password, easy to remember, just in case somebody steals the rev-certs while I'm at the rest-room (well, probably replacing my keys would require less time than to change all my passwords). IMHO (but again, it's just my opinion), revocation certificates don't need to be protected as much as your private keys. If somebody revokes your keys, that's bad, and you need to make new keys. But that person won't be able to sign things on your name or read your encrypted messages. It's like if somebody cuts your credit card in half: you need to replace it, but your money remains safe. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNACAxAAoJEMV4f6PvczxAtCQIAJwkxXfFliaRzI0WXvZ9q/eF NGaOa31M9zsbzVuAHkrqyws/ipCxc5r7BOq2VhKz/7yncZ2mRWSzq4OgY1nqmUw2 OhZ0V/OqpoBC/2Ichzf3t/RB97Rs7KeWeRCtI9MP6OeOIPrCN+B8+bGOoCR9aj9m +HKDc20d2pDAEwvovByu1/MmhlvKfSClUVWInJ3JYqbm9DCJ9hxU56IAswKv/QEi LBoEzefEr8npHa45JfEBp4FHbqq+E7A3S8opI1VWOpE1l0wce8QLy9jkG1ApPsCy +0THtAPkbTs8TRWqbrMOBfcOqqSlRL/6NjIZPP383pvqQJaYwoLENIF+HhrvijM= =aOhg -----END PGP SIGNATURE----- From ben at adversary.org Thu Dec 9 07:14:53 2010 From: ben at adversary.org (Ben McGinnes) Date: Thu, 09 Dec 2010 17:14:53 +1100 Subject: multiple subkeys and key transition Message-ID: <4D0073DD.3020701@adversary.org> Hello, I am giving very serious thought to creating new keys and doing a (long-term) transition to them. This is partly to respond to known flaws with SHA-1 and take advantage of SHA-256 and higher. There is currently a push to move away from SHA-1 usage by the end of 2010, although it will almost certainly take longer than that. There is a discussion of some of the issues involved here. http://www.debian-administration.org/users/dkg/weblog/48 At the moment I am planning on using an RSA signing key, but I have not made my final decision on the encryption subkeys. I am leaning towards Elgamal, but that's by no means certain. The other option, of course, is to create a key with both RSA and Elgamal encryption subkeys, which does lead to questions: 1) I've forgotten how GPG handles the subkeys, does it choose the strongest key or the newest key by default or does it encrypt to all active (non-revoked or non-expired) subkeys? 2) How does PGP (of any version) handle multiple subkeys? 3) Does anyone know of any problems or issues with any version of PGP or GPG when handling keys with multiple subkeys? 4) Which encryption algorithm do people prefer of RSA and Elgamal, if either, and why? I'm doing my own research here, of course, but it doesn't hurt to ask (yes, I'm already aware of Sam Simpson's informative FAQ and am re-reading it). The opinions of the list on any or all of these questions would be greatly appreciated. Regards, Ben P.S. Apologies to readers of PGPNET and/or PGPMIMENET, who have already seen this message. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From maheswara.mandala at aon.com Wed Dec 8 23:12:01 2010 From: maheswara.mandala at aon.com (Maheswara Mandala) Date: Wed, 8 Dec 2010 16:12:01 -0600 Subject: Windows 2008 64 bit version Message-ID: <14681C0755EC264295179ABD1CEFA521101D64F32F@021-NAMSG-04.021d.mgd.msft.net> Hi, We have currently GnuPG installed on Windows2000 server and version is 1.4.5. We are establishing new servers with Windows 2008 (64 bit) and we want to install GnuPG on our new servers. Could you tell me what is the compatible GnuPG version to this Operating system. It will be appreciated if you get back ASAP. Thanks, Mahesh Mahesh Mandala | Sr. Software Engineer Aon eSolutions | Data Services 200 E Randolph Street | Chicago, Illinois 60601 | United States t +1.312.381.3960 maheswara.mandala at aon.com | aon-esolutions.com This email message, including any attachment(s), is intended only for the named recipient(s) and may contain confidential, proprietary or legally privileged information. Unauthorized individuals or entities are not permitted access to this information. Any dissemination, distribution, disclosure, or copying of this information is unauthorized and strictly prohibited. If you have received this message in error, please advise the sender by reply email, and delete this message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at klomp.eu Thu Dec 9 14:38:48 2010 From: mail at klomp.eu (Sven Klomp) Date: Thu, 9 Dec 2010 14:38:48 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D0073DD.3020701@adversary.org> References: <4D0073DD.3020701@adversary.org> Message-ID: <201012091438.49007.mail@klomp.eu> On Thursday 09 December 2010 07:14:53 Ben McGinnes wrote: > Hello, > I am giving very serious thought to creating new keys and > doing a (long-term) transition to them. This is partly to respond to > known flaws with SHA-1 and take advantage of SHA-256 and higher. > > There is currently a push to move away from SHA-1 usage by the end of > 2010, although it will almost certainly take longer than that. There > is a discussion of some of the issues involved here. > > http://www.debian-administration.org/users/dkg/weblog/48 > Hi Ben, I had a similar situation: I started to use a CryptoStick, which can only handel RSA keys. After some discussions [1], I revoked the ElGamal and have now only one encryption key in my keyring. Sven [1] http://lists.gnupg.org/pipermail/gnupg-users/2010-November/039828.html > At the moment I am planning on using an RSA signing key, but I have > not made my final decision on the encryption subkeys. I am leaning > towards Elgamal, but that's by no means certain. > > The other option, of course, is to create a key with both RSA and > Elgamal encryption subkeys, which does lead to questions: > > 1) I've forgotten how GPG handles the subkeys, does it choose the > strongest key or the newest key by default or does it encrypt to all > active (non-revoked or non-expired) subkeys? > > 2) How does PGP (of any version) handle multiple subkeys? > > 3) Does anyone know of any problems or issues with any version of PGP > or GPG when handling keys with multiple subkeys? > > 4) Which encryption algorithm do people prefer of RSA and Elgamal, if > either, and why? I'm doing my own research here, of course, but it > doesn't hurt to ask (yes, I'm already aware of Sam Simpson's > informative FAQ and am re-reading it). > > The opinions of the list on any or all of these questions would be > greatly appreciated. > > > Regards, > Ben > > P.S. Apologies to readers of PGPNET and/or PGPMIMENET, who have > already seen this message. ;) > > From mailinglisten at hauke-laging.de Thu Dec 9 14:41:10 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 9 Dec 2010 14:41:10 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D0073DD.3020701@adversary.org> References: <4D0073DD.3020701@adversary.org> Message-ID: <201012091441.11255.mailinglisten@hauke-laging.de> Am Donnerstag 09 Dezember 2010 07:14:53 schrieb Ben McGinnes: > Hello, > I am giving very serious thought to creating new keys and > doing a (long-term) transition to them. This is partly to respond to > known flaws with SHA-1 and take advantage of SHA-256 and higher. What is the relation between a key and the hashing algorithms? > At the moment I am planning on using an RSA signing key, but I have > not made my final decision on the encryption subkeys. I am leaning > towards Elgamal, but that's by no means certain. In case of doubt choose RSA. It's the only one you can use with the g10 smartcard. > 1) I've forgotten how GPG handles the subkeys, does it choose the > strongest key or the newest key by default or does it encrypt to all > active (non-revoked or non-expired) subkeys? It chooses the newest subkey. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Thu Dec 9 15:08:24 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 09:08:24 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D0073DD.3020701@adversary.org> References: <4D0073DD.3020701@adversary.org> Message-ID: <4D00E2D8.4080406@sixdemonbag.org> On 12/9/2010 1:14 AM, Ben McGinnes wrote: > I am giving very serious thought to creating new keys and > doing a (long-term) transition to them. This is partly to respond to > known flaws with SHA-1 and take advantage of SHA-256 and higher. My best counsel is: don't, at least not yet. First, there are no imminent practical attacks on SHA-1. Second, the OpenPGP Working Group ("the WG") is currently figuring out how to get SHA-1 out of the OpenPGP spec and how to replace it with something better. If you do a transition now, it's possible you'll want to transition again in six months or a year once the WG updates the RFC. I'd hold off on this, at least for now. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From ben at adversary.org Thu Dec 9 16:40:34 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 02:40:34 +1100 Subject: multiple subkeys and key transition In-Reply-To: <201012091441.11255.mailinglisten@hauke-laging.de> References: <4D0073DD.3020701@adversary.org> <201012091441.11255.mailinglisten@hauke-laging.de> Message-ID: <4D00F872.6050906@adversary.org> On 10/12/10 12:41 AM, Hauke Laging wrote: > Am Donnerstag 09 Dezember 2010 07:14:53 schrieb Ben McGinnes: >> Hello, >> I am giving very serious thought to creating new keys and >> doing a (long-term) transition to them. This is partly to respond to >> known flaws with SHA-1 and take advantage of SHA-256 and higher. > > What is the relation between a key and the hashing algorithms? The current key is DSA/Elgamal > In case of doubt choose RSA. It's the only one you can use with the > g10 smartcard. That would matter if I had/used smartcards, but I don't so it doesn't. I prefer to simply have complete physical control over any system which my secret keys are installed on. >> 1) I've forgotten how GPG handles the subkeys, does it choose the >> strongest key or the newest key by default or does it encrypt to all >> active (non-revoked or non-expired) subkeys? > > It chooses the newest subkey. Excellent. I had a nagging feeling that that was right, thanks for confirming it. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 16:55:30 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 02:55:30 +1100 Subject: multiple subkeys and key transition In-Reply-To: <201012091438.49007.mail@klomp.eu> References: <4D0073DD.3020701@adversary.org> <201012091438.49007.mail@klomp.eu> Message-ID: <4D00FBF2.5010101@adversary.org> On 10/12/10 12:38 AM, Sven Klomp wrote: > > I had a similar situation: I started to use a CryptoStick, which can > only handel RSA keys. I assume the CryptoStick is a brand name version of a smartcard based system, right? Not something I plan on using. My decisions will be based in crypto strength, not the prevalence of Internet cafes and libraries. > After some discussions [1], I revoked the ElGamal and have now only > one encryption key in my keyring. As the smartcard isn't on the agenda for me at all, I'll base my decision on security rather than convenience. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 17:04:34 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 03:04:34 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D00E2D8.4080406@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> Message-ID: <4D00FE12.9060907@adversary.org> On 10/12/10 1:08 AM, Robert J. Hansen wrote: > On 12/9/2010 1:14 AM, Ben McGinnes wrote: >> I am giving very serious thought to creating new keys and >> doing a (long-term) transition to them. This is partly to respond to >> known flaws with SHA-1 and take advantage of SHA-256 and higher. > > My best counsel is: don't, at least not yet. Okay. > First, there are no imminent practical attacks on SHA-1. Second, > the OpenPGP Working Group ("the WG") is currently figuring out how > to get SHA-1 out of the OpenPGP spec and how to replace it with > something better. Userful to know, can I track the WG's progress through this list or is that done through the IETF or the OpenPGP site? > If you do a transition now, it's possible you'll want to transition > again in six months or a year once the WG updates the RFC. Urgh, what a hideous thought. > I'd hold off on this, at least for now. Well, my current key has been perfectly fine since it's creation nearly a dozen years ago. I'm still sufficiently sure that there is no imminent threat, so I'm happy to just watch and wait and see what the WG says. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From j-001 at ottosson.nu Thu Dec 9 17:58:22 2010 From: j-001 at ottosson.nu (J. Ottosson) Date: Thu, 09 Dec 2010 17:58:22 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D00FBF2.5010101@adversary.org> References: <4D0073DD.3020701@adversary.org>, <201012091438.49007.mail@klomp.eu>, <4D00FBF2.5010101@adversary.org> Message-ID: <4D010AAE.16331.74F06902@j-001.ottosson.nu> On 10 Dec 2010 at 2:55, Ben McGinnes wrote: > On 10/12/10 12:38 AM, Sven Klomp wrote: > > > > I had a similar situation: I started to use a CryptoStick, which can > > only handel RSA keys. > > I assume the CryptoStick is a brand name version of a smartcard based > system, right? Not something I plan on using. My decisions will be based > in crypto strength, not the prevalence of Internet cafes and libraries. > > > After some discussions [1], I revoked the ElGamal and have now only one > > encryption key in my keyring. > > As the smartcard isn't on the agenda for me at all, I'll base my > decision on security rather than convenience. If smartcard is not on your agenda you are certainly not basing your decision on security. > > > Regards, > Ben > > From ben at adversary.org Thu Dec 9 18:18:00 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 04:18:00 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D010AAE.16331.74F06902@j-001.ottosson.nu> References: <4D0073DD.3020701@adversary.org>, <201012091438.49007.mail@klomp.eu>, <4D00FBF2.5010101@adversary.org> <4D010AAE.16331.74F06902@j-001.ottosson.nu> Message-ID: <4D010F48.5070208@adversary.org> On 10/12/10 3:58 AM, J. Ottosson wrote: > On 10 Dec 2010 at 2:55, Ben McGinnes wrote: >> >> As the smartcard isn't on the agenda for me at all, I'll base my >> decision on security rather than convenience. > > If smartcard is not on your agenda you are certainly not basing your > decision on security. And you're basing that assessment on what? I know where all the physical media containing a copy of my secret key(s) are and I control all the hardware that can access them. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Thu Dec 9 18:25:53 2010 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 09 Dec 2010 12:25:53 -0500 Subject: multiple subkeys and key transition In-Reply-To: <201012091441.11255.mailinglisten@hauke-laging.de> References: <4D0073DD.3020701@adversary.org> <201012091441.11255.mailinglisten@hauke-laging.de> Message-ID: <4D011121.1020505@grant-olson.net> On 12/9/10 8:41 AM, Hauke Laging wrote: > Am Donnerstag 09 Dezember 2010 07:14:53 schrieb Ben McGinnes: >> Hello, >> I am giving very serious thought to creating new keys and >> doing a (long-term) transition to them. This is partly to respond to >> known flaws with SHA-1 and take advantage of SHA-256 and higher. > > What is the relation between a key and the hashing algorithms? > > Right. If the hash algo is your only concern, you can just change that. No need to regenerate a key, unless you're just using that as an motivator to bump up your key-size and/or create an offline primary key. Regarding RSA vs DSA/ElGamal, without having done any research at all, I'm assuming the defaults in GPG changed from DSA/ElGamal to RSA/RSA for a reason, so I went with the latter. And apologies, because I know you said you have no intention of using a smartcard (twice), but if you're creating a key for the next ten years then it's possible you'll change your mind say five years from now. -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 559 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Dec 9 18:35:00 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 12:35:00 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D010AAE.16331.74F06902@j-001.ottosson.nu> References: <4D0073DD.3020701@adversary.org>, <201012091438.49007.mail@klomp.eu>, <4D00FBF2.5010101@adversary.org> <4D010AAE.16331.74F06902@j-001.ottosson.nu> Message-ID: <4D011344.1020209@sixdemonbag.org> On 12/9/10 11:58 AM, J. Ottosson wrote: > If smartcard is not on your agenda you are certainly not basing your decision on > security. Security is a subjective criteria. If you don't know what his threat model is, you're in no position to be making pronouncements like this. From mailinglisten at hauke-laging.de Thu Dec 9 18:38:01 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 9 Dec 2010 18:38:01 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D010F48.5070208@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D010AAE.16331.74F06902@j-001.ottosson.nu> <4D010F48.5070208@adversary.org> Message-ID: <201012091838.08651.mailinglisten@hauke-laging.de> Am Donnerstag 09 Dezember 2010 18:18:00 schrieb Ben McGinnes: > > If smartcard is not on your agenda you are certainly not basing your > > decision on security. > > And you're basing that assessment on what? > > I know where all the physical media containing a copy of my secret > key(s) are and I control all the hardware that can access them. And this hardware is always offline with no complex applications running? There are scenarios in which controlling the hardware is enough. But they are very rare. Probably somebody with such a scenario had said something different from "based on security". Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Thu Dec 9 18:42:10 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 9 Dec 2010 18:42:10 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D011344.1020209@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D010AAE.16331.74F06902@j-001.ottosson.nu> <4D011344.1020209@sixdemonbag.org> Message-ID: <201012091842.10439.mailinglisten@hauke-laging.de> Am Donnerstag 09 Dezember 2010 18:35:00 schrieb Robert J. Hansen: > On 12/9/10 11:58 AM, J. Ottosson wrote: > > If smartcard is not on your agenda you are certainly not basing your > > decision on security. > > Security is a subjective criteria. If you don't know what his threat > model is, you're in no position to be making pronouncements like this. That attitude renders a term like "decision based on security" with no further information completely useless. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Thu Dec 9 18:54:44 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 04:54:44 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D011121.1020505@grant-olson.net> References: <4D0073DD.3020701@adversary.org> <201012091441.11255.mailinglisten@hauke-laging.de> <4D011121.1020505@grant-olson.net> Message-ID: <4D0117E4.4020705@adversary.org> On 10/12/10 4:25 AM, Grant Olson wrote: > > Right. If the hash algo is your only concern, you can just change > that. No need to regenerate a key, unless you're just using that as > an motivator to bump up your key-size and/or create an offline > primary key. I've already switched the hash preference on the key, it will now use RIPEMD-160 before SHA-1, but it won't accept the higher SHA algorithms. Currently it only switches back to SHA-1 when I'm signing and encrypting to other keys which can't handle RIPEMD-160. > Regarding RSA vs DSA/ElGamal, without having done any research at > all, I'm assuming the defaults in GPG changed from DSA/ElGamal to > RSA/RSA for a reason, so I went with the latter. Since it has already been mentioned that smartcards only work with RSA, that could be a factor. I suspect their development, which I haven't followed too closely, was to address the concerns of OpenPGP users who were unable to control the hardware on which their mail and/or keys were stored and required an additional level of physical security to prevent an unscrupulous systems administrator from accessing a secret keyring (and possibly brute forcing the passphrase). > And apologies, because I know you said you have no intention of > using a smartcard (twice), but if you're creating a key for the next > ten years then it's possible you'll change your mind say five years > from now. It's possible, at this stage unlikely, but I won't rule anything out. I'm already used to having a single key operational for a long time. The key I'm currently using was generated nearly a dozen years ago. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Dec 9 19:01:39 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Dec 2010 13:01:39 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D00E2D8.4080406@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> Message-ID: <4D011983.6060905@fifthhorseman.net> On 12/09/2010 09:08 AM, Robert J. Hansen wrote: > On 12/9/2010 1:14 AM, Ben McGinnes wrote: >> I am giving very serious thought to creating new keys and >> doing a (long-term) transition to them. This is partly to respond to >> known flaws with SHA-1 and take advantage of SHA-256 and higher. > > My best counsel is: don't, at least not yet. Sorry, but i have to disagree with Robert on this (yes, i'm the author of the blog post you linked to earlier). If you want to switch to stronger algorithms, now is a reasonable time to do it. > First, there are no imminent practical attacks on SHA-1. That we know of, anyway. Nonetheless, its use for digital signatures has been strongly deprecated by groups like NIST. See [0] for links to NIST recommendations. > Second, the > OpenPGP Working Group ("the WG") is currently figuring out how to get > SHA-1 out of the OpenPGP spec and how to replace it with something better. This discussion currently seems to be idle, so i would not wait on it. We need to get the discussion going again, certainly. > If you do a transition now, it's possible you'll want to transition > again in six months or a year once the WG updates the RFC. This statement seems to assume that the RFC can't or won't be updated in a way that people could make the transition using the same key material, assuming they were using strong enough keys and digests in the first place. My own personal bottom line: i've been using digests from the SHA-2 family for well over a year now (and larger RSA keys for twice that time) and have had no interoperability problems. --dkg [0] http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 19:07:10 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 05:07:10 +1100 Subject: multiple subkeys and key transition In-Reply-To: <201012091838.08651.mailinglisten@hauke-laging.de> References: <4D0073DD.3020701@adversary.org> <4D010AAE.16331.74F06902@j-001.ottosson.nu> <4D010F48.5070208@adversary.org> <201012091838.08651.mailinglisten@hauke-laging.de> Message-ID: <4D011ACE.6030801@adversary.org> On 10/12/10 4:38 AM, Hauke Laging wrote: > Am Donnerstag 09 Dezember 2010 18:18:00 schrieb Ben McGinnes: > >> And you're basing that assessment on what? >> >> I know where all the physical media containing a copy of my secret >> key(s) are and I control all the hardware that can access them. > > And this hardware is always offline with no complex applications > running? Effectively. The server is always on, but my secret keyring is not installed on the server. The only active system with the secret keyring is only running when I am in front of it. > There are scenarios in which controlling the hardware is enough. But > they are very rare. Probably somebody with such a scenario had said > something different from "based on security". Well, I suppose there's the threat of people kicking in the door, but if that kind of situation were to become a possibility (again), my concerns wouldn't pertain to my email and/or files, my concerns would be more in the nature of defending life and limb. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 19:30:17 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 05:30:17 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D011983.6060905@fifthhorseman.net> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> Message-ID: <4D012039.9060506@adversary.org> On 10/12/10 5:01 AM, Daniel Kahn Gillmor wrote: > On 12/09/2010 09:08 AM, Robert J. Hansen wrote: >> On 12/9/2010 1:14 AM, Ben McGinnes wrote: >>> I am giving very serious thought to creating new keys and >>> doing a (long-term) transition to them. This is partly to respond to >>> known flaws with SHA-1 and take advantage of SHA-256 and higher. >> >> My best counsel is: don't, at least not yet. > > Sorry, but i have to disagree with Robert on this (yes, i'm the > author of the blog post you linked to earlier). If you want to > switch to stronger algorithms, now is a reasonable time to do it. Ah, a debate, excellent. Now let's make it a little more entertaining, where do you see RIPEMD-160 in the scheme of things? I ask because that seems to be the only update my current DSA/Elgamal key can accept (via setpref). >> First, there are no imminent practical attacks on SHA-1. > > That we know of, anyway. Nonetheless, its use for digital > signatures has been strongly deprecated by groups like NIST. See > [0] for links to NIST recommendations. Thanks, more reading material is a welcome addition. >> Second, the OpenPGP Working Group ("the WG") is currently figuring >> out how to get SHA-1 out of the OpenPGP spec and how to replace it >> with something better. > > This discussion currently seems to be idle, so i would not wait on > it. We need to get the discussion going again, certainly. Is it possible that this current transition push is partially aimed at reigniting the WG's discussion by creating a new de-facto standard? In much the same way that PGP 5.x became the foundation for OpenPGP (RFC 2440 and then 4880). >> If you do a transition now, it's possible you'll want to transition >> again in six months or a year once the WG updates the RFC. > > This statement seems to assume that the RFC can't or won't be > updated in a way that people could make the transition using the > same key material, assuming they were using strong enough keys and > digests in the first place. What is the likelihood of that actually being the case? > My own personal bottom line: i've been using digests from the SHA-2 > family for well over a year now (and larger RSA keys for twice that > time) and have had no interoperability problems. Good to know. Should I make the transition now/soon, my current plan is either of these two options: 1) 4,096-bit RSA signing key with a 4,096-bit Elgamal encryption key. 2) 4,096-bit RSA signing key with a 4,096-bit RSA encryption key and a 4,096-bit Elgamal encryption key. Since I prefer a more long-term approach, this should eventually lead to 8,192-bit encryption keys when 4,096-bit becomes the default. That's probably a fair way down the track, though, very likely several years away. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Dec 9 17:52:42 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Dec 2010 17:52:42 +0100 Subject: Protecting IDs at a key signing party In-Reply-To: <201012082335.11639.mailinglisten@hauke-laging.de> (Hauke Laging's message of "Wed, 8 Dec 2010 23:35:04 +0100") References: <201012081420.14986.hankivy@hot.rr.com> <4CFFFE7A.6010704@sixdemonbag.org> <201012082335.11639.mailinglisten@hauke-laging.de> Message-ID: <87y67ysxb9.fsf@gnupg.org> On Wed, 8 Dec 2010 23:35, mailinglisten at hauke-laging.de said: > aren't any IETF notations yet. I suggest a standard for at least these pieces > of information: > > - key owner has been personally known for x years > - frequent contact with the key owner for x years [many more] It is very unlikely that OpenPGP will ever adopt such standards. There is an unspoken policy that we don't define policies but merely provide a framework so others can implement something on top of it. If we would start to adopt any such policies we would soon end up in the X.509 mud. The signature classes 0x10 to 0x13 are for a reason not very strictly defined. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Dec 9 20:12:38 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Dec 2010 14:12:38 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D012039.9060506@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> Message-ID: <4D012A26.5060900@fifthhorseman.net> On 12/09/2010 01:30 PM, Ben McGinnes wrote: > Ah, a debate, excellent. Now let's make it a little more > entertaining, :P > where do you see RIPEMD-160 in the scheme of things? RIPEMD-160 is another 160-bit hash, same size as SHA-1. I don't think that it has undergone as extensive cryptanalysis as SHA-1; i'm sure others on this list can give more intelligent commentary on its properties. I prefer signatures made over digests longer than 160 bits (as do newer versions of gpg, which default to stating SHA256 as a preferred digest). > I ask because that seems to be the only update my current DSA/Elgamal > key can accept (via setpref). That's probably because your primary key (the one doing signing and certifying) is a standard 1024-bit DSA key (the original DSA standard itself, FIPS-186 [0], specifies 1024 bit keylength -- longer DSA keys come from later revisions of the standard, and are collectively known in gpg as DSA2, if i understand it correctly). But FIPS-186, as defined, only operates over 160-bit digests. So longer digest algorithms won't work with DSA1 keys. > Is it possible that this current transition push is partially aimed at > reigniting the WG's discussion by creating a new de-facto standard? > In much the same way that PGP 5.x became the foundation for OpenPGP > (RFC 2440 and then 4880). The transition push is to make sure we have a functional WoT available when SHA-1's collision-resistance is ultimately publicly broken in a practical attac. If that happens to re-ignite the WG discussion, that's fine. AFAICT, the only cryptographically-relevant places where the current standard (RFC 4880) has SHA-1 "baked in" are: 0) the fingerprint-calculating mechanism 1) the designated-revoker sub-packet, because it references the fingerprint. 2) that SHA-1 is the only official "must-implement" digest algorithm A defeat of SHA-1's collision-resistance shouldn't have an effect on point 0 because fingerprints are generated by a single party, on their own -- there's no way for me to convince you to generate a key with a specific fingerprint. (a preimage attack against SHA-1 would be devastating, though) The loose consensus seems to be that point 1 should be trivially resolvable by defining a new version of the designated-revoker subpacket that embeds the revoker's entire key (instead of just the fingerprint) but no one has done the work to make that happen yet. This wouldn't even need a new version of the entire spec, it would just be an update to the spec, claiming a new subpacket type from IANA. And an example implementation in a popular tool like GnuPG wouldn't hurt either, of course. :) point 2 is a potential cause for concern, but in practice all OpenPGP implementations distributed in the last 5 years have been able to support SHA-256. It seems like some folks in the OpenPGP WG would prefer to wait until NIST's SHA-3 contest's results are announced and settle on that outcome as a new must-implement digest for the next major revision of the standard. But that shouldn't stop you from using stronger digests today. >> This statement seems to assume that the RFC can't or won't be >> updated in a way that people could make the transition using the >> same key material, assuming they were using strong enough keys and >> digests in the first place. > > What is the likelihood of that actually being the case? i don't know, but it doesn't seem out of the question to me. There may need to be a translation (and possibly re-certifying) step to move existing strong keys to a new version when that comes out, but i don't think it should require discarding those keys. Weak keys, on the other hand, will probably not be translatable. > 2) 4,096-bit RSA signing key with a 4,096-bit RSA encryption key and a > 4,096-bit Elgamal encryption key. i don't see the advantage of having two encryption-capable subkeys myself, but it's your call. > Since I prefer a more long-term approach, this should eventually lead > to 8,192-bit encryption keys when 4,096-bit becomes the default. > That's probably a fair way down the track, though, very likely several > years away. i think we are at least as likely to switch to elliptic-curve as an asymmetric algorithm than to ever start defaulting to 4096- or 8192-bit RSA keys, but that's too far in the future for my crystal ball to see clearly. --dkg [0] http://www.itl.nist.gov/fipspubs/fip186.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Dec 9 20:17:02 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 14:17:02 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D012039.9060506@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> Message-ID: <4D012B2E.7080109@sixdemonbag.org> On 12/9/10 1:30 PM, Ben McGinnes wrote: > Ah, a debate, excellent. Now let's make it a little more > entertaining, where do you see RIPEMD-160 in the scheme of things? My suspicion is RIPEMD-160 is broken, we just don't know how. It has an awful lot of mathematical similarities to hashes that have been broken: it is my suspicion existing attacks will be successful when tweaked to apply to RIPEMD-160. > Is it possible that this current transition push is partially aimed at > reigniting the WG's discussion by creating a new de-facto standard? Dunno, ask the WG. >> This statement seems to assume that the RFC can't or won't be >> updated in a way that people could make the transition using the >> same key material, assuming they were using strong enough keys and >> digests in the first place. > > What is the likelihood of that actually being the case? IMO, quite high. If you use the same key material, then if the old OpenPGP certificate format ever becomes weak an attacker can simply take an old certificate of yours, upgrade it to the new format, and bang they're off to the races. If/when the time comes for SHA-1 to be completely removed from OpenPGP, the migration path will quite likely involve new keys -- the same way that the V3/V4 migration path in the past necessitated new keys. > Since I prefer a more long-term approach, this should eventually lead > to 8,192-bit encryption keys when 4,096-bit becomes the default. It is unlikely it ever will. 3K RSA keys are believed to be equivalent to a 128-bit symmetric key. If computational power ever develops to that point, the solution is going to involve moving to entirely different algorithms instead of just tacking on another couple of bits. From rjh at sixdemonbag.org Thu Dec 9 20:18:58 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 14:18:58 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D012A26.5060900@fifthhorseman.net> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012A26.5060900@fifthhorseman.net> Message-ID: <4D012BA2.8030305@sixdemonbag.org> On 12/9/10 2:12 PM, Daniel Kahn Gillmor wrote: > But FIPS-186, as defined, only operates over 160-bit digests. So longer > digest algorithms won't work with DSA1 keys. Not true. Per the OpenPGP spec, it will simply truncate a longer digest down to 160 bits. From j-001 at ottosson.nu Thu Dec 9 20:22:07 2010 From: j-001 at ottosson.nu (J. Ottosson) Date: Thu, 09 Dec 2010 20:22:07 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D010F48.5070208@adversary.org> References: <4D0073DD.3020701@adversary.org>, <4D010AAE.16331.74F06902@j-001.ottosson.nu>, <4D010F48.5070208@adversary.org> Message-ID: <4D012C5F.7871.757404D7@j-001.ottosson.nu> On 10 Dec 2010 at 4:18, Ben McGinnes wrote: > On 10/12/10 3:58 AM, J. Ottosson wrote: > > On 10 Dec 2010 at 2:55, Ben McGinnes wrote: > >> > >> As the smartcard isn't on the agenda for me at all, I'll base my > >> decision on security rather than convenience. > > > > If smartcard is not on your agenda you are certainly not basing your > > decision on security. > > And you're basing that assessment on what? > > I know where all the physical media containing a copy of my secret > key(s) are and I control all the hardware that can access them. But you do know what purpose a smartcard type of device is for, right? Protection of some kind of data, most often a key or several of them. We use hardware security devices of various sorts in many situations where high security is a requirement. We use them for tokens, crypto keys and we use them in systems processing our PIN handling in the financial systems etc (like the IBM 4758 etc). Since protection of the private key is the single most important issue for any openpgp user, it is very natural to think about smartcard, since it is the best way to protect a key from disclosure. Then, after having made the analysis of threats and cost one may opt to not use it anyway, as most of us do, at least partly and for some keys. Unless you are using some kind of trusted computer system you simply do not have that kind of control over what is or is not done on your computer. Then when it comes to media that the key is written onto and has ever been written onto, well that's often a bigger issue than most people tend to think. Anyone having used EnCase and tools alike it know what I mean. It all depends, partly on luck, if someone raids your home, if you're owned or not. Do you remember any old floppys that your earlier keys were ever saved to? Most don't. It all comes down to what opponent we're having. So, it's partly a question about what threat model we're sitting in. A normal user like you and me are in most circumstances ok with an ordinary keyring on a portable USB stick or perhaps in a Truecrypt container for extra protection but others are not. And I've been attending tempest lab tests too, so I'd say that most anything many users think is impossible or only happens on film is not even close to the limits of what some TLAs are readily doing. A clue on that can also be picked up by looking at the counterintel procedures for sigint by the KGB during the cold war. If those types of guys are after you, a hardware security type of device is of limited protection to you too btw. I can say this much, there exist smartcard research papers today, that are classified since a decade back or more and not seen by more than 10-20 people, and they are so for a reason. So actually, nothing is safe come to think of it. But that't too depressing so we pretend smartcards are, from a practical perspective. nuff said > > > Regards, > Ben > > A few related links: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html http://en.wikipedia.org/wiki/Trusted_Computing http://en.wikipedia.org/wiki/Smart_card http://en.wikipedia.org/wiki/FIPS_140-2 http://www.cl.cam.ac.uk/~mkb23/research/Survey.pdf From j-001 at ottosson.nu Thu Dec 9 20:22:08 2010 From: j-001 at ottosson.nu (J. Ottosson) Date: Thu, 09 Dec 2010 20:22:08 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D011344.1020209@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org>, <4D010AAE.16331.74F06902@j-001.ottosson.nu>, <4D011344.1020209@sixdemonbag.org> Message-ID: <4D012C60.4782.7574061F@j-001.ottosson.nu> que? On 9 Dec 2010 at 12:35, Robert J. Hansen wrote: > On 12/9/10 11:58 AM, J. Ottosson wrote: > > If smartcard is not on your agenda you are certainly not basing your > > decision on security. > > Security is a subjective criteria. If you don't know what his threat > model is, you're in no position to be making pronouncements like this. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From ben at adversary.org Thu Dec 9 20:33:43 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 06:33:43 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D012BA2.8030305@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012A26.5060900@fifthhorseman.net> <4D012BA2.8030305@sixdemonbag.org> Message-ID: <4D012F17.5040501@adversary.org> On 10/12/10 6:18 AM, Robert J. Hansen wrote: > On 12/9/10 2:12 PM, Daniel Kahn Gillmor wrote: >> But FIPS-186, as defined, only operates over 160-bit digests. So longer >> digest algorithms won't work with DSA1 keys. > > Not true. Per the OpenPGP spec, it will simply truncate a longer digest > down to 160 bits. Well, I changed the prefs on my key to this: [ultimate] (1). Ben McGinnes Cipher: AES256, TWOFISH, CAMELLIA256, AES192, CAMELLIA192, AES, CAMELLIA128, 3DES, CAST5, BLOWFISH, IDEA Digest: SHA512, SHA384, SHA256, SHA224, RIPEMD160, SHA1, MD5 Compression: BZIP2, ZLIB, ZIP, Uncompressed Features: MDC, Keyserver no-modify Yet it still ignores everything which precedes RIPEMD160, presumably because it's a DSA1 key and can't handle the SHA-2 digests. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Dec 9 20:42:27 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 14:42:27 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D012F17.5040501@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012A26.5060900@fifthhorseman.net> <4D012BA2.8030305@sixdemonbag.org> <4D012F17.5040501@adversary.org> Message-ID: <4D013123.2090701@sixdemonbag.org> On 12/9/10 2:33 PM, Ben McGinnes wrote: > Yet it still ignores everything which precedes RIPEMD160, presumably > because it's a DSA1 key and can't handle the SHA-2 digests. This is premature. It could be any of the following: * You do not have a personal-digest-preferences in your gpg.conf * You do not have enable-dsa2 in your gpg.conf * Any of dozens of other reasons Check the first two. :) From ben at adversary.org Thu Dec 9 21:09:08 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 07:09:08 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D012A26.5060900@fifthhorseman.net> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012A26.5060900@fifthhorseman.net> Message-ID: <4D013764.1060207@adversary.org> On 10/12/10 6:12 AM, Daniel Kahn Gillmor wrote: > On 12/09/2010 01:30 PM, Ben McGinnes wrote: >> Ah, a debate, excellent. Now let's make it a little more >> entertaining, > > :P I'm glad I'm not the only one who likes to find answers this way. :) > RIPEMD-160 is another 160-bit hash, same size as SHA-1. For some reason I thought SHA-1 was 128-bit, but I've no idea why I thought that. > I don't think that it has undergone as extensive cryptanalysis as > SHA-1; That sounds an awful lot like security through obscurity. Or, more to the point, the absence of evidence is not evidence of absence (of a security flaw). > i'm sure others on this list can give more intelligent commentary on > its properties. Yeah, I'll get to Robert's response next. ;) > I prefer signatures made over digests longer than 160 bits (as do > newer versions of gpg, which default to stating SHA256 as a > preferred digest). Which seems reasonable to me. > That's probably because your primary key (the one doing signing and > certifying) is a standard 1024-bit DSA key (the original DSA > standard itself, FIPS-186 [0], specifies 1024 bit keylength -- > longer DSA keys come from later revisions of the standard, and are > collectively known in gpg as DSA2, if i understand it correctly). My current key was created at the end of 1998, I'm pretty sure that DSA2 wasn't around then. Back then the biggest argument was maintaining compatibility with PGP 2.6.x (and earlier); when many people would not update because of fears of backdoors being inserted in software that was able to be exported outside of the United States. Ah ... the Crypto Wars, how we don't miss them! >> Is it possible that this current transition push is partially aimed at >> reigniting the WG's discussion by creating a new de-facto standard? >> In much the same way that PGP 5.x became the foundation for OpenPGP >> (RFC 2440 and then 4880). > > The transition push is to make sure we have a functional WoT > available when SHA-1's collision-resistance is ultimately publicly > broken in a practical attac. Okay. My key doesn't have that many signatures, but I like the ones I've got. Still, I suppose the sanctity of my own signatures should be of just as great, if not greater, concern. > If that happens to re-ignite the WG discussion, that's fine. Fair enough. > AFAICT, the only cryptographically-relevant places where the current > standard (RFC 4880) has SHA-1 "baked in" are: > > 0) the fingerprint-calculating mechanism > > 1) the designated-revoker sub-packet, because it references the > fingerprint. > > 2) that SHA-1 is the only official "must-implement" digest algorithm > > A defeat of SHA-1's collision-resistance shouldn't have an effect on > point 0 because fingerprints are generated by a single party, on their > own -- there's no way for me to convince you to generate a key with a > specific fingerprint. Yep, okay. > (a preimage attack against SHA-1 would be devastating, though) I assume that there's still no indication of if and/or when that might be viable? I suppose a better question is: is a preimage attack against SHA-1 simply a matter of time? > The loose consensus seems to be that point 1 should be trivially > resolvable by defining a new version of the designated-revoker > subpacket that embeds the revoker's entire key (instead of just the > fingerprint) Is this why a revoked key can still be used to decrypt data that was encrypted with a non-revoked copy of the key? > but no one has done the work to make that happen yet. This wouldn't > even need a new version of the entire spec, it would just be an update > to the spec, claiming a new subpacket type from IANA. And an example > implementation in a popular tool like GnuPG wouldn't hurt either, of > course. :) Why do I get the feeling that this bit is addressed to Werner ... ;) > point 2 is a potential cause for concern, but in practice all OpenPGP > implementations distributed in the last 5 years have been able to > support SHA-256. > It seems like some folks in the OpenPGP WG would prefer to wait > until NIST's SHA-3 contest's results are announced and settle on > that outcome as a new must-implement digest for the next major > revision of the standard. Okay, I just looked that up and in spite of a tentative statement that the final round would be announced this year, there doesn't appear to be any statement on that front. I suppose that could happen in the next three weeks, but it could also mean delays in the process. > But that shouldn't stop you from using stronger digests today. Hmm, I'm beginning to be swayed again. >>> This statement seems to assume that the RFC can't or won't be >>> updated in a way that people could make the transition using the >>> same key material, assuming they were using strong enough keys and >>> digests in the first place. >> >> What is the likelihood of that actually being the case? > > i don't know, but it doesn't seem out of the question to me. There > may need to be a translation (and possibly re-certifying) step to > move existing strong keys to a new version when that comes out, but > i don't think it should require discarding those keys. Weak keys, > on the other hand, will probably not be translatable. This is somewhat encouraging. >> 2) 4,096-bit RSA signing key with a 4,096-bit RSA encryption key and a >> 4,096-bit Elgamal encryption key. > > i don't see the advantage of having two encryption-capable subkeys > myself, but it's your call. I'm not sure I do either, which brings me back to the RSA vs. Elgamal debate (and more reading). >> Since I prefer a more long-term approach, this should eventually >> lead to 8,192-bit encryption keys when 4,096-bit becomes the >> default. That's probably a fair way down the track, though, very >> likely several years away. > > i think we are at least as likely to switch to elliptic-curve as an > asymmetric algorithm than to ever start defaulting to 4096- or > 8192-bit RSA keys, but that's too far in the future for my crystal > ball to see clearly. I know better than to ask for that kind of prediction, especially with EC possibly entering the arena. Thanks. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 21:14:35 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 07:14:35 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D013123.2090701@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012A26.5060900@fifthhorseman.net> <4D012BA2.8030305@sixdemonbag.org> <4D012F17.5040501@adversary.org> <4D013123.2090701@sixdemonbag.org> Message-ID: <4D0138AB.6040508@adversary.org> On 10/12/10 6:42 AM, Robert J. Hansen wrote: > On 12/9/10 2:33 PM, Ben McGinnes wrote: >> Yet it still ignores everything which precedes RIPEMD160, presumably >> because it's a DSA1 key and can't handle the SHA-2 digests. > > This is premature. > > It could be any of the following: > > * You do not have a personal-digest-preferences in your gpg.conf I had that. > * You do not have enable-dsa2 in your gpg.conf I didn't have that, but I do now. :) > * Any of dozens of other reasons > > Check the first two. :) I guess I'm about to find out. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 21:26:51 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 07:26:51 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D012B2E.7080109@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> Message-ID: <4D013B8B.6060103@adversary.org> On 10/12/10 6:17 AM, Robert J. Hansen wrote: > On 12/9/10 1:30 PM, Ben McGinnes wrote: >> Ah, a debate, excellent. Now let's make it a little more >> entertaining, where do you see RIPEMD-160 in the scheme of things? > > My suspicion is RIPEMD-160 is broken, we just don't know how. It > has an awful lot of mathematical similarities to hashes that have > been broken: it is my suspicion existing attacks will be successful > when tweaked to apply to RIPEMD-160. Okay, I can't say I've been overjoyed at having it as the only apparent alternative to SHA-1. I think, however, that the "enable-dsa2" option you mentioned is working, so that's a much better solution. >> Is it possible that this current transition push is partially aimed >> at reigniting the WG's discussion by creating a new de-facto >> standard? > > Dunno, ask the WG. As soon as I find them ... >>> This statement seems to assume that the RFC can't or won't be >>> updated in a way that people could make the transition using the >>> same key material, assuming they were using strong enough keys and >>> digests in the first place. >> >> What is the likelihood of that actually being the case? > > IMO, quite high. If you use the same key material, then if the old > OpenPGP certificate format ever becomes weak an attacker can simply > take an old certificate of yours, upgrade it to the new format, and > bang they're off to the races. Nasty. > If/when the time comes for SHA-1 to be completely removed from > OpenPGP, the migration path will quite likely involve new keys -- > the same way that the V3/V4 migration path in the past necessitated > new keys. That sounds an awful lot like the reason behind creating my current key. Actually, that's not true, there's a set from about six months earlier that I thought I new the passphrase to, but ... you know the rest of that tale (just about everyone does that at least once). ;) >> Since I prefer a more long-term approach, this should eventually >> lead to 8,192-bit encryption keys when 4,096-bit becomes the >> default. > > It is unlikely it ever will. 3K RSA keys are believed to be > equivalent to a 128-bit symmetric key. If computational power ever > develops to that point, the solution is going to involve moving to > entirely different algorithms instead of just tacking on another > couple of bits. Well, I have rather enjoyed the fact that the 4096-bit Elgamal key I created a dozen years ago is still considered practically impossible to defeat (not counting if I ever managed to piss off the NSA/DSD). Any larger would start getting a bit ridiculous (although I do know which bit of keygen.c to tweak to make it possible). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Dec 9 21:48:33 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Dec 2010 15:48:33 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D013764.1060207@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012A26.5060900@fifthhorseman.net> <4D013764.1060207@adversary.org> Message-ID: <4D0140A1.5010909@fifthhorseman.net> On 12/09/2010 03:09 PM, Ben McGinnes wrote: > Is this why a revoked key can still be used to decrypt data that was > encrypted with a non-revoked copy of the key? the things that get revoked are OpenPGP certificates. the certificates themselves contain key material. The math that makes the key material effective for encryption, decryption, signing, or verification doesn't know or care about the revocation of the certificates. We *interpret* those revocations to give us some reasonable real-world guidance about whether to rely on a given key for encryption, signature verification, or authentication. But the underlying asymmetric crypto operations will continue to work regardless of whether the certificates are revoked. >> even need a new version of the entire spec, it would just be an update >> to the spec, claiming a new subpacket type from IANA. And an example >> implementation in a popular tool like GnuPG wouldn't hurt either, of >> course. :) > > Why do I get the feeling that this bit is addressed to Werner ... ;) It was addressed to anyone who wants to implement it, actually. Anyone looking to cut their teeth on this kind of stuff could pick this up as a reasonable project. Here's a previous discussion to get you started: http://www.imc.org/ietf-openpgp/mail-archive/msg06733.html hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 21:55:01 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 07:55:01 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D012C5F.7871.757404D7@j-001.ottosson.nu> References: <4D0073DD.3020701@adversary.org>, <4D010AAE.16331.74F06902@j-001.ottosson.nu>, <4D010F48.5070208@adversary.org> <4D012C5F.7871.757404D7@j-001.ottosson.nu> Message-ID: <4D014225.8050409@adversary.org> On 10/12/10 6:22 AM, J. Ottosson wrote: > > But you do know what purpose a smartcard type of device is for, right? Yep, they were standard issue when I worked at Sun. > Protection of some kind of data, most often a key or several of > them. We use hardware security devices of various sorts in many > situations where high security is a requirement. We use them for > tokens, crypto keys and we use them in systems processing our PIN > handling in the financial systems etc (like the IBM 4758 etc). The Sun ones are authentication tokens, combined with RFID security passes. > Since protection of the private key is the single most important > issue for any openpgp user, it is very natural to think about > smartcard, since it is the best way to protect a key from > disclosure. Then, after having made the analysis of threats and > cost one may opt to not use it anyway, as most of us do, at least > partly and for some keys. Yeah, I can see the value of them, but I don't really see how they would make enough addition to my security requirements to justify either the monetary or operational expense (i.e. additional complication). If I piss off a TLA or the local equivalent (a couple of them have four letters) then they've got other ways of getting what they want. > Unless you are using some kind of trusted computer system you simply > do not have that kind of control over what is or is not done on your > computer. Not in the sense you mean. > Then when it comes to media that the key is written onto and has > ever been written onto, well that's often a bigger issue than most > people tend to think. Anyone having used EnCase and tools alike it > know what I mean. It all depends, partly on luck, if someone raids > your home, if you're owned or not. Do you remember any old floppys > that your earlier keys were ever saved to? Most don't. Actually, since writing what I did earlier, I did a quick double-check. And I do recall everything the keys were ever backed up to and I really do know exactly where they all are. I was quite impressed given the age of the key. ;) > It all comes down to what opponent we're having. So, it's partly a > question about what threat model we're sitting in. It always does. > A normal user like you and me are in most circumstances ok with > an ordinary keyring on a portable USB stick Highly unlikely I'd ever do this. > or perhaps in a Truecrypt container for extra protection but others > are not. This is more viable, though. > And I've been attending tempest lab tests too, so I'd say that most > anything many users think is impossible or only happens on film is > not even close to the limits of what some TLAs are readily doing. I've no doubt that the spooks can do things we'd consider amazing, but I'm equally sure that I wouldn't be considered at all threatening to them. Possibly threatening to politicians, but that's an entirely different kettle of fish. > A clue on that can also be picked up by looking at the counterintel > procedures for sigint by the KGB during the cold war. If those types > of guys are after you, a hardware security type of device is of > limited protection to you too btw. I'm not trying to defeat spooks or play at their level. It doesn't really hold enough interest for me because it would require living in a way that would be just too damn depressing. Contrary to most films, it is *not* cool. > I can say this much, there exist smartcard research papers today, > that are classified since a decade back or more and not seen by more > than 10-20 people, and they are so for a reason. > > So actually, nothing is safe come to think of it. But that't too > depressing so we pretend smartcards are, from a practical > perspective. Don't you hate it when you get to the end of what seemed a well constructed argument, only to consider a possibility which presents a huge gaping hole in it? ;) I take your points, though, there are certainly valid reasons for using smartcards. So it would be clearer for me to say that I don't believe they suit my circumstances. > A few related links: Thanks, I was aware of some of them, but not a couple (the first and last). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 22:01:09 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 08:01:09 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D0140A1.5010909@fifthhorseman.net> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012A26.5060900@fifthhorseman.net> <4D013764.1060207@adversary.org> <4D0140A1.5010909@fifthhorseman.net> Message-ID: <4D014395.2020705@adversary.org> On 10/12/10 7:48 AM, Daniel Kahn Gillmor wrote: > On 12/09/2010 03:09 PM, Ben McGinnes wrote: > >> Is this why a revoked key can still be used to decrypt data that was >> encrypted with a non-revoked copy of the key? > > the things that get revoked are OpenPGP certificates. the certificates > themselves contain key material. The math that makes the key material > effective for encryption, decryption, signing, or verification doesn't > know or care about the revocation of the certificates. > > We *interpret* those revocations to give us some reasonable real-world > guidance about whether to rely on a given key for encryption, signature > verification, or authentication. But the underlying asymmetric crypto > operations will continue to work regardless of whether the certificates > are revoked. Ah, thankyou very much. I think this is the clearest explanation of the process and why it behaves the way it does that I've seen anywhere. >>> even need a new version of the entire spec, it would just be an update >>> to the spec, claiming a new subpacket type from IANA. And an example >>> implementation in a popular tool like GnuPG wouldn't hurt either, of >>> course. :) >> >> Why do I get the feeling that this bit is addressed to Werner ... ;) > > It was addressed to anyone who wants to implement it, actually. Anyone > looking to cut their teeth on this kind of stuff could pick this up as a > reasonable project. Cool. My C knowledge is, ah, rudimentary so I'll have to wait for a guru to look into it. > Here's a previous discussion to get you started: > > http://www.imc.org/ietf-openpgp/mail-archive/msg06733.html > > hth, Very much so, thanks again. :) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Dec 9 22:02:30 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Dec 2010 16:02:30 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D012B2E.7080109@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> Message-ID: <4D0143E6.50104@fifthhorseman.net> On 12/09/2010 02:17 PM, Robert J. Hansen wrote: > IMO, quite high. If you use the same key material, then if the old > OpenPGP certificate format ever becomes weak an attacker can simply take > an old certificate of yours, upgrade it to the new format, and bang > they're off to the races. Maybe we're not talking about the same thing, but i don't understand the attack you describe. Why would a weakness in the old certificate format would be able to invalidate the same key under a new format? Note: i am *not* talking about a weakness in the underlying ciphers, digests, or asymmetric algorithms involved. A weakness in the certificate format itself would certainly make me wary of relying on certificates in the weak format, but why would it mandate re-keying? Could you give a more detailed example of such an attack? > If/when the time comes for SHA-1 to be completely removed from OpenPGP, > the migration path will quite likely involve new keys -- the same way > that the V3/V4 migration path in the past necessitated new keys. Could you point to a reference that explains why a person with a v3 key considered sufficiently-strong by that day's estimation (say, 1024-bit RSA) would have had to create an entirely new key instead of just migrating their old key to v4? Thanks for clarifying, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Dec 9 22:33:06 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 16:33:06 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D0143E6.50104@fifthhorseman.net> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D0143E6.50104@fifthhorseman.net> Message-ID: <4D014B12.6030607@sixdemonbag.org> On 12/9/10 4:02 PM, Daniel Kahn Gillmor wrote: > Maybe we're not talking about the same thing, but i don't understand the > attack you describe. Why would a weakness in the old certificate > format would be able to invalidate the same key under a new format? I did not communicate the idea well. In retrospect, I communicated it quite poorly. Imagine a certificate that depends on a trivially weak hash -- say MD5 was used instead of SHA-1 for self-signatures, etc. Fine: that certificate is now out there in the wild. The signatures it makes are quite suspect. A new certificate standard comes out. You migrate your old certificate material to a new cert. You want to continue using it, after all. (Why, I don't know: it isn't as if it's hard to generate new certs.) Great, except that your old cert is, in many jurisdictions, legally enforceable against you. You haven't revoked it: in fact, you continue to assert that it is usable (albeit in a new cert format). Someone else exploits the old, insecure cert format in a way you don't like. Now you're stuck arguing, "wait, that's not my cert... well, it /is/ my cert, it's the same cert material, but it's /not/ my cert, because that's an old insecure format..." So far I've handwaved all different kinds of interesting issues and questions -- and I've *still* gone over the heads of the vast majority of lawyers and judges who would be arguing over the question of, "is this signature enforceable?" Remember, in the eyes of the U.S. federal court system, MD5 is considered a strong hash with no known attacks against it. I don't trust the courts to understand these subtle nuances. There is a big difference between something that is possible and harmless in a technical sense, and something that is possible but not recommended in a human sense. Technically, yes, it's possible. From a human factors perspective I would revoke the old cert, create a new one, make a clean break with the past and move forward. Less opportunities for human factors to bite me in the posterior. > Could you point to a reference that explains why a person with a v3 key > considered sufficiently-strong by that day's estimation (say, 1024-bit > RSA) would have had to create an entirely new key instead of just > migrating their old key to v4? *Have* to? None. From John at Mozilla-Enigmail.org Thu Dec 9 22:33:59 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Thu, 09 Dec 2010 15:33:59 -0600 Subject: multiple subkeys and key transition In-Reply-To: <4D013B8B.6060103@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D013B8B.6060103@adversary.org> Message-ID: <4D014B47.1090502@Mozilla-Enigmail.org> Ben McGinnes wrote: > On 10/12/10 6:17 AM, Robert J. Hansen wrote: >> On 12/9/10 1:30 PM, Ben McGinnes wrote: > >>> Is it possible that this current transition push is partially aimed >>> at reigniting the WG's discussion by creating a new de-facto >>> standard? >> >> Dunno, ask the WG. > > As soon as I find them ... > mailto://ietf-openpgp at imc.org http://www.imc.org/ietf-openpgp/ I'll hit some of the other points in another post. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Thu Dec 9 23:11:37 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 09:11:37 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D014B47.1090502@Mozilla-Enigmail.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D013B8B.6060103@adversary.org> <4D014B47.1090502@Mozilla-Enigmail.org> Message-ID: <4D015419.6050507@adversary.org> On 10/12/10 8:33 AM, John Clizbe wrote: > Ben McGinnes wrote: >> On 10/12/10 6:17 AM, Robert J. Hansen wrote: >>> On 12/9/10 1:30 PM, Ben McGinnes wrote: >> >>>> Is it possible that this current transition push is partially aimed >>>> at reigniting the WG's discussion by creating a new de-facto >>>> standard? >>> >>> Dunno, ask the WG. >> >> As soon as I find them ... >> > > mailto://ietf-openpgp at imc.org > > http://www.imc.org/ietf-openpgp/ Thanks. I think I'll lurk for a bit before I start causing trouble, though. ;) > I'll hit some of the other points in another post. Sure, take your time. Since Robert has pointed out that I'd overlooked (and had not been aware of) the enable-dsa2 option, I'm not rushing into a key migration at this point. I'm glad I asked, though, I've learned a lot in the last few hours. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From JPClizbe at tx.rr.com Thu Dec 9 23:28:08 2010 From: JPClizbe at tx.rr.com (John Clizbe) Date: Thu, 09 Dec 2010 16:28:08 -0600 Subject: multiple subkeys and key transition In-Reply-To: <4D012B2E.7080109@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> Message-ID: <4D0157F8.2070509@tx.rr.com> Robert J. Hansen wrote: > On 12/9/10 1:30 PM, Ben McGinnes wrote: > > If/when the time comes for SHA-1 to be completely removed from OpenPGP, > the migration path will quite likely involve new keys -- the same way > that the V3/V4 migration path in the past necessitated new keys. > >> Since I prefer a more long-term approach, this should eventually lead >> to 8,192-bit encryption keys when 4,096-bit becomes the default. > > It is unlikely it ever will. 3K RSA keys are believed to be equivalent > to a 128-bit symmetric key. If computational power ever develops to > that point, the solution is going to involve moving to entirely > different algorithms instead of just tacking on another couple of bits. Big ACK to what Rob just said. Why 8192? 4096 RSA is extremely *unlikely* to ever be a default. Over the summer, readers of the [Cryptography] mailing list were reminded that in 1993 folks thought that 1024-bit RSA 'should be ok (safe from key-factoring attacks) for "a few decades".' A later post in that same thread went on to compare equivalent strengths of RSA, symmetric keys and Elliptic Curve (ECC) keys. How do elliptic curves compare to RSA today? From the National Institutes of Science and Technology (one of the gold standards for engineering know-how): RSA ECC Sym 1024 160 80 2048 224 112 3072 256 128 7680 384 192 15360 512 256 These recommendations can be found on page 63 of NIST Special Publication 800-57, Recommendations for Key Management, Part I. 2nd Revision, 8 Mar, 2007. [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf] 112-bit symmetric is usually a reference to [three-key] 3DES. (It's worth noting that most people in the crypto community are *deeply* skeptical of any claims that 3DES can be cracked. If 112 bits of symmetric encryption are good enough for your purposes, then RSA-2048 should also be good enough for your purposes.) That is to say, a 3072 bit RSA key is as tough as an ECC key based on a 256 bit field, which is as tough as a 128 bit symmetric key. ECC cryptosystems on 256 bit field are practical today. 3072 bit RSA systems are not. The NSA's 2010 Suite-B[4] recommendations are: Type Symmetric Elliptic Curve Hash Secret 128 256 256 Top Secret 256 384 384 A key aspect of Suite B is its use of elliptic curve technology instead of classical public key technology. During the transition to the use of elliptic curve cryptography in ECDH and ECDSA, DH, DSA and RSA can be used with a 2048-bit modulus to protect classified information up to the _secret_ level [http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml]. So, depending on the source, a consensus seems to be forming that beyond a 2048 or 3072 bit modulus for DSA2 or RSA, folks need to switch to ECC. 2048-RSA is the current default in GnuPG. OpenPGP cards will support up to 3072-bit RSA; GnuPG up to 4096-bit RSA and 3072-bit DSA2. ECC in OpenPGP is on its way toward becoming a RFC and being included in OpenPGP. Larger and larger RSA keys aren't the solution, ECC is. The balance of power has tipped away from RSA and toward ECC. Feel free to ignore everything I've told you. There's no reason you should trust me. But by all means, keep asking questions. But everything I've read agrees longer RSA are not the path forward. -John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From John at Mozilla-Enigmail.org Thu Dec 9 23:32:31 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Thu, 09 Dec 2010 16:32:31 -0600 Subject: multiple subkeys and key transition In-Reply-To: <4D015419.6050507@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D013B8B.6060103@adversary.org> <4D014B47.1090502@Mozilla-Enigmail.org> <4D015419.6050507@adversary.org> Message-ID: <4D0158FF.70802@Mozilla-Enigmail.org> Ben McGinnes wrote: > On 10/12/10 8:33 AM, John Clizbe wrote: >> Ben McGinnes wrote: >>> On 10/12/10 6:17 AM, Robert J. Hansen wrote: >>>> On 12/9/10 1:30 PM, Ben McGinnes wrote: >>> >>>>> Is it possible that this current transition push is partially aimed >>>>> at reigniting the WG's discussion by creating a new de-facto >>>>> standard? >>>> >>>> Dunno, ask the WG. >>> >>> As soon as I find them ... >>> >> >> mailto://ietf-openpgp at imc.org >> >> http://www.imc.org/ietf-openpgp/ > > Thanks. I think I'll lurk for a bit before I start causing trouble, > though. ;) You should also be able to download the complete archives of the list in mbox format for review. If not, write to me off-list and I'll see what I can do :) Traffic is a bit bursty and the list can be quiet for long periods at a time. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Dec 9 23:32:52 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Dec 2010 17:32:52 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D014B12.6030607@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D0143E6.50104@fifthhorseman.net> <4D014B12.6030607@sixdemonbag.org> Message-ID: <4D015914.2040309@fifthhorseman.net> On 12/09/2010 04:33 PM, Robert J. Hansen wrote: > Someone else exploits the old, insecure cert format in a way you don't > like. Again, can you give an example of such an exploit? > Now you're stuck arguing, "wait, that's not my cert... well, it > /is/ my cert, it's the same cert material, but it's /not/ my cert, > because that's an old insecure format..." This sounds confused mainly because you're not distinguishing between public key material and certificates. I grant that the distinction may well not be understood by lawyers and judges, but the conflation of the terms here makes it needlessly confusing. Clearer: "That is not my certificate. It was revoked (marked as superseded) on $date. I continue to use the same key material in a different certificate." And if addressing a hopelessly legally-minded audience in the USA, you could add: "of course i didn't make that signature; it uses $deprecated_algorithm, which i haven't used since NIST deprecated it back in 2010." Unless, of course, you didn't follow NIST's guidelines and continued to use the deprecated algorithms. Then you couldn't make that claim. > Remember, in the eyes of the U.S. federal > court system, MD5 is considered a strong hash with no known attacks > against it. Could you cite a reference for this? > I don't trust the courts to understand these subtle nuances. There are lots of attacks that can be used against a clueless judiciary, including things like creating a new key and associating it with your victim's user ID, generating back-dated signatures and certifications, etc. That doesn't make the clueless judiciary a good argument against the use of User IDs or timestamped signatures and certifications, though. > There is a big difference between something that is possible and > harmless in a technical sense, and something that is possible but not > recommended in a human sense. Technically, yes, it's possible. From a > human factors perspective I would revoke the old cert, create a new one, > make a clean break with the past and move forward. Less opportunities > for human factors to bite me in the posterior. Except that you've now broken entirely with the past, which is itself a human factor. Smooth migration, phased upgrades, and planned transitions are all good things from a human factors perspective. Propagating a key across certificate formats might be a reasonable approach for some of these goals (and of course, there may be other ways to accomplish them too). As part of the plans for a new OpenPGP certificate format, i certainly hope we'll address ways to make the transition to the new format as smooth as possible for most existing users. >> Could you point to a reference that explains why a person with a v3 key >> considered sufficiently-strong by that day's estimation (say, 1024-bit >> RSA) would have had to create an entirely new key instead of just >> migrating their old key to v4? > > *Have* to? None. OK, how about "were recommended to", or any other reference that discusses the topic for that key version transition? My point here is to avoid the creation of FUD around a potential new version of OpenPGP causing a lot of work, or discouraging people from using stronger crypto. The possibility (probability) of a new certificate format coming down the pike eventually should *not* be used to discourage people from migrating away from known-weak and deprecated cryptographic algorithms today. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From John at Mozilla-Enigmail.org Thu Dec 9 23:51:32 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Thu, 09 Dec 2010 16:51:32 -0600 Subject: multiple subkeys and key transition In-Reply-To: <4D00FE12.9060907@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> Message-ID: <4D015D74.8020607@Mozilla-Enigmail.org> Ben McGinnes wrote: > On 10/12/10 1:08 AM, Robert J. Hansen wrote: >> On 12/9/2010 1:14 AM, Ben McGinnes wrote: >>> I am giving very serious thought to creating new keys and >>> doing a (long-term) transition to them. This is partly to respond to >>> known flaws with SHA-1 and take advantage of SHA-256 and higher. >> >> My best counsel is: don't, at least not yet. > > Okay. > >> First, there are no imminent practical attacks on SHA-1. Second, >> the OpenPGP Working Group ("the WG") is currently figuring out how >> to get SHA-1 out of the OpenPGP spec and how to replace it with >> something better. > If one is still using keys of the old signing default of DSA/1024, a 160-bit hash is the only choice available. That's dictated by the standard. But there's no pressing need to generate a new key -- one can just switch to using RIPEMD-160 instead of SHA-1. The fire alarm for SHA-1 has gone off and it's time to move safely and calmly to the exits. It's not worth panicking over, but folks should have a transition plan in place. For my own use, I waited until I had obtained a v2 OpenPGP card, the earlier v1 cards were limited to 1024 bit RSA and only the two stock 160 bit hashes, SHA-1 and RIPMED-160. Or one can use enable-dsa2 in GnuPG and use any of the SHA2 hashes, they'll just be truncated down to 160 bits similarly to the SHA-224/SHA-256 arrangement described below. The best statement on keeping SHA-1 in use I've read comes from NIST: "SHA-1 has recently been demonstrated to provide less than 80 bits of security for digital signatures; at the publication of this Recommendation, the security strength against collisions is assessed at 69 bits. The use of SHA-1 is not recommended for the generation of digital signatures in new systems; new systems should use one of the larger hash functions. For the present time, SHA-1 is included here to reflect it's widespread use in existing systems, for which the reduced security strength may not be of great concern when only 80-bits of security are required." (NIST SP800-57 Part 1. Footnote 23, page 62.) NIST recommends SHA-224 for 2048 bit RSA and DSA2 keys and SHA-256 for 3072 bit keys. In practice SHA-256 is used for both. The same work is involved bor both. SHA-224 is just a truncated SHA-256, albeit with a different initialization. > Userful to know, can I track the WG's progress through this list or is > that done through the IETF or the OpenPGP site? > >> If you do a transition now, it's possible you'll want to transition >> again in six months or a year once the WG updates the RFC. > > Urgh, what a hideous thought. One of the very important, but least notied changes in RFC 4880 was that the WG made it much easier to amend the RFC without rewriting the entire document. This is how Camellia was included into OpenPGP and how ECC will most likely be included. Expect to see some movement once the new NIST hash competition is complete. >> I'd hold off on this, at least for now. > > Well, my current key has been perfectly fine since it's creation > nearly a dozen years ago. I'm still sufficiently sure that there is > no imminent threat, so I'm happy to just watch and wait and see what > the WG says. I just created new keys after almost 8 years, my old key was 1024D/2048ElG. The new keys are 2048-DSA2/2048-RSA and a 3x2048-RSA OpenPGP card. 3072 just felt like overkill for me. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Fri Dec 10 00:18:35 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 10:18:35 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D0157F8.2070509@tx.rr.com> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D0157F8.2070509@tx.rr.com> Message-ID: <4D0163CB.7010903@adversary.org> On 10/12/10 9:28 AM, John Clizbe wrote: > Robert J. Hansen wrote: >> On 12/9/10 1:30 PM, Ben McGinnes wrote: >> >> If/when the time comes for SHA-1 to be completely removed from OpenPGP, >> the migration path will quite likely involve new keys -- the same way >> that the V3/V4 migration path in the past necessitated new keys. >> >>> Since I prefer a more long-term approach, this should eventually lead >>> to 8,192-bit encryption keys when 4,096-bit becomes the default. >> >> It is unlikely it ever will. 3K RSA keys are believed to be equivalent >> to a 128-bit symmetric key. If computational power ever develops to >> that point, the solution is going to involve moving to entirely >> different algorithms instead of just tacking on another couple of bits. > > Big ACK to what Rob just said. Okey-dokies. > Why 8192? Bigger is better mentality. I'm happy to be corrected to whatever is most usefully secure. When I created my current key I was essentially moving from a 1024-bit RSA key made with PGP 2.3a and there were a whole bunch of reasons to go with something stronger. At the time I erred on the side of caution and picked the largest key size available to me. > 4096 RSA is extremely *unlikely* to ever be a default. Good to know. Presumably the same goes for Elgamal. > Over the summer, readers of the [Cryptography] mailing list were > reminded that in 1993 folks thought that 1024-bit RSA 'should be ok > (safe from key-factoring attacks) for "a few decades".' A later post > in that same thread went on to compare equivalent strengths of RSA, > symmetric keys and Elliptic Curve (ECC) keys. The last bit of documentation I saw on ECC is a little old and stated that it wasn't well known enough to consider using. I guess that's changed now. > How do elliptic curves compare to RSA today? > > From the National Institutes of Science and Technology (one of the gold > standards for engineering know-how): [SNIP] > 112-bit symmetric is usually a reference to [three-key] 3DES. (It's > worth noting that most people in the crypto community are *deeply* > skeptical of any claims that 3DES can be cracked. If 112 bits of > symmetric encryption are good enough for your purposes, then > RSA-2048 should also be good enough for your purposes.) > > That is to say, a 3072 bit RSA key is as tough as an ECC key based > on a 256 bit field, which is as tough as a 128 bit symmetric key. [SNIP] > A key aspect of Suite B is its use of elliptic curve technology > instead of classical public key technology. During the transition to > the use of elliptic curve cryptography in ECDH and ECDSA, DH, DSA > and RSA can be used with a 2048-bit modulus to protect classified > information up to the _secret_ level So my 4096-bit Elgamal key with an AES256 cipher would be somewhere between SECRET and TOP SECRET (discounting the real information security policies that are applied by any DoD/spook personnel, in either your country or mine). > So, depending on the source, a consensus seems to be forming that > beyond a 2048 or 3072 bit modulus for DSA2 or RSA, folks need to > switch to ECC. 2048-RSA is the current default in GnuPG. OpenPGP > cards will support up to 3072-bit RSA; GnuPG up to 4096-bit RSA and > 3072-bit DSA2. ECC in OpenPGP is on its way toward becoming a RFC > and being included in OpenPGP. Larger and larger RSA keys aren't the > solution, ECC is. The balance of power has tipped away from RSA and > toward ECC. Okay, it looks like I've got more reading to do, so I know what to expect when it puts in an appearance. Thanks. > Feel free to ignore everything I've told you. There's no reason you > should trust me. But by all means, keep asking questions. But > everything I've read agrees longer RSA are not the path forward. Since you're backing it all up with verifiable and useful data, I'm happy to take these suggestions. In the past I've seen similar arguments, but rarely with the relevant reference material to back the assertions up. So this is all most welcome. As for more questions, no doubt I'll have more as I plough through all this stuff. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Fri Dec 10 00:21:16 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 10:21:16 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D0158FF.70802@Mozilla-Enigmail.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D013B8B.6060103@adversary.org> <4D014B47.1090502@Mozilla-Enigmail.org> <4D015419.6050507@adversary.org> <4D0158FF.70802@Mozilla-Enigmail.org> Message-ID: <4D01646C.6000902@adversary.org> On 10/12/10 9:32 AM, John Clizbe wrote: > Ben McGinnes wrote: >> >> Thanks. I think I'll lurk for a bit before I start causing trouble, >> though. ;) > > You should also be able to download the complete archives of the > list in mbox format for review. If not, write to me off-list and > I'll see what I can do :) Not to worry, I already have it. > Traffic is a bit bursty and the list can be quiet for long periods > at a time. Yeah, I saw that from a glance at the archives. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Dec 10 00:45:53 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 18:45:53 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D015914.2040309@fifthhorseman.net> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D0143E6.50104@fifthhorseman.net> <4D014B12.6030607@sixdemonbag.org> <4D015914.2040309@fifthhorseman.net> Message-ID: <4D016A31.20206@sixdemonbag.org> On 12/9/2010 5:32 PM, Daniel Kahn Gillmor wrote: > Again, can you give an example of such an exploit? Here is where I get to say either of, "I don't have to," or "pick one," or "you're the one who's positing the attacks." All I'm positing is some future attack that will allow people to abuse a cert in a way you don't like. You're counseling that people move away from SHA-1 *today* based on the fear that somewhere someone has already done chosen-preimage collisions against SHA-1 in a reasonable timeframe. My assumption is quite a lot weaker than yours. > "That is not my certificate. It was revoked (marked as superseded) on > $date. I continue to use the same key material in a different certificate." If the law in your jurisdiction recognizes such and the court has precedent to lean upon, this argument will fly. Speaking just for myself, I have no desire to be the first person to make such an argument. The instant you re-use key material, it opens the door to someone saying, "Your Honor, the existing precedent doesn't apply. He's still using the same certificate!" And now you're depending on a judge having better technical acumen than many of the people on this mailing list. Ultimately, it will reduce to a battle of the dueling expert opinions. > And if addressing a hopelessly legally-minded audience in the USA, you > could add: "of course i didn't make that signature; it uses > $deprecated_algorithm, which i haven't used since NIST deprecated it > back in 2010." "You made it with that signature because you wanted to be able to repudiate it later. You're trying to deceive the Court." On the one hand, what you say is perfectly reasonable. On the other hand, so is what I say. >> Remember, in the eyes of the U.S. federal >> court system, MD5 is considered a strong hash with no known attacks >> against it. > > Could you cite a reference for this? _Sanders v. State_, 191 S.W.3d 272 (Tex. App. - Waco 2006) (cert. denied 549 U.S. 1167, 127 S.Ct. 1141, 166 L.Ed.2d 893)(2007) _State v. Morris_, 2005 WL 356801 (Ohio App. 9 Dist. Feb 16, 2005). _State v. Cook_, 777 N.E.2d 882, 886 (Ohio App. 2002), including the money quote "In the present case, there is no doubt that the mirror image was an authentic copy of what was present on the computer's hard drive" -- the hard drive was imaged using EnCase, and MD5 was used to ensure the accuracy of the data. Also, check the Federal Rules of Evidence. You may also want to read _Daubert v. Merrell Dow Pharmaceuticals_. > There are lots of attacks that can be used against a clueless judiciary, Yes. Which is why we don't create more of them without good cause. There's a difference between saying, "we have to play Russian Roulette," and, "let's put another few rounds in the cylinder first." > Except that you've now broken entirely with the past, which is itself a > human factor. Smooth migration, phased upgrades, and planned > transitions are all good things from a human factors perspective. If your migration path can't accommodate a planned, scheduled change of key material, it is quite likely you're doing it wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From ben at adversary.org Fri Dec 10 00:49:28 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 10:49:28 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D015D74.8020607@Mozilla-Enigmail.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> <4D015D74.8020607@Mozilla-Enigmail.org> Message-ID: <4D016B08.6030805@adversary.org> On 10/12/10 9:51 AM, John Clizbe wrote: > > If one is still using keys of the old signing default of DSA/1024, a > 160-bit hash is the only choice available. That's dictated by the > standard. That's what I've got. > But there's no pressing need to generate a new key -- one > can just switch to using RIPEMD-160 instead of SHA-1. The fire alarm > for SHA-1 has gone off and it's time to move safely and calmly to > the exits. It's not worth panicking over, but folks should have a > transition plan in place. Which is what I'm trying to formulate. > Or one can use enable-dsa2 in GnuPG and use any of the SHA2 hashes, > they'll just be truncated down to 160 bits similarly to the > SHA-224/SHA-256 arrangement described below. Just to clarify, does this mean that SHA-256 or 512 (or whatever) truncated to 160-bits prevent the potential collision attacks that might be able to be launched against SHA-1? > One of the very important, but least notied changes in RFC 4880 was > that the WG made it much easier to amend the RFC without rewriting > the entire document. This is how Camellia was included into OpenPGP > and how ECC will most likely be included. Ah, cool. > Expect to see some movement once the new NIST hash competition is > complete. So around the end of 2012, assuming they stick to the schedule. > I just created new keys after almost 8 years, my old key was > 1024D/2048ElG. The new keys are 2048-DSA2/2048-RSA and a 3x2048-RSA > OpenPGP card. > > 3072 just felt like overkill for me. To quote Howard Tayler's _Schlock Mercenary_, "there's no such thing as overkill, only 'Open fire!' and 'I need to reload!'" :) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Dec 10 00:55:57 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 18:55:57 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D0163CB.7010903@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D0157F8.2070509@tx.rr.com> <4D0163CB.7010903@adversary.org> Message-ID: <4D016C8D.9090209@sixdemonbag.org> On 12/9/2010 6:18 PM, Ben McGinnes wrote: > The last bit of documentation I saw on ECC is a little old and stated > that it wasn't well known enough to consider using. I guess that's > changed now. Back in 2000 or so, the consensus was that ECC was too new and rested on some dicey conjectures. Since the proof of the Taniyama-Shimura conjecture (or, as it's now called, Wiles' Theorem), ECC's theoretical underpinnings seem to be on fairly solid ground. The National Security Agency has approved ECC for use in its Suite B of cryptographic algorithms, and has authorized it for protection of the highest levels of state secrets (TS/SCI) when used with 384-bit ECC keys. John's information (that Suite B was authorized for SECRET) is correct: he was looking at the bit about Suite B that relates to 256-bit ECC keys. > So my 4096-bit Elgamal key with an AES256 cipher would be somewhere > between SECRET and TOP SECRET (discounting the real information > security policies that are applied by any DoD/spook personnel, in > either your country or mine). The NSA is quite good about publishing its real information security policies. They have a *lot* of contractors who work with them, and keeping the rules for how to secure classified information hidden would ultimately only harm overall operational security. They *want* people to know the right way to take care of TS/SCI material. They never want to hear someone say, "sure, I sent that TS/SCI file in plaintext. Wait, I wasn't supposed to do that? I was never told! Why aren't those rules on your website?" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From rjh at sixdemonbag.org Fri Dec 10 00:57:43 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 18:57:43 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D016B08.6030805@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> <4D015D74.8020607@Mozilla-Enigmail.org> <4D016B08.6030805@adversary.org> Message-ID: <4D016CF7.2060503@sixdemonbag.org> On 12/9/2010 6:49 PM, Ben McGinnes wrote: > Just to clarify, does this mean that SHA-256 or 512 (or whatever) > truncated to 160-bits prevent the potential collision attacks that > might be able to be launched against SHA-1? Correct. Truncating a hash does not introduce any flaws in the algorithm. If you truncate a bad hash, you now have a truncated bad hash. Truncate a good hash and you have a truncated good hash. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From mailinglisten at hauke-laging.de Fri Dec 10 01:03:58 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 10 Dec 2010 01:03:58 +0100 Subject: GPF Crypto Stick vs OpenPGP Card In-Reply-To: References: <87lj49vy2o.fsf%lukasz.stelmach@iem.pw.edu.pl> <201012061206.26963.mailinglisten@hauke-laging.de> Message-ID: <201012100104.05974.mailinglisten@hauke-laging.de> Am Montag 06 Dezember 2010 20:21:36 schrieb Marcio B. Jr.: Sorry, spam filter... > Hello, > sorry for this insistence. I just want to get it clearly. > > So, you mean those devices certainly protect information better than a > regular computer (even if making proper use of disk encryption > software)? In general that is correct. In detail that depends on the kind of attack and the computer usage. If the computer has a network connection with not completely secure systems then the discussion ends at that point. Disk encryption does not protect against online attacks. With regard to every normal PC a smartcard is the better solution. You need a hardware attack in order to get keys out of a smartcard. If you can spend millions of dollars for that then it's possible. If you have an offline PC which never runs complex software with data from outside then disk encryption can be even safer than a smartcard. If the integrity of the hardware is not an issue and only obvious attacks are an issue (stealing and siezing) then only software attacks against the disk encryption are possible which can easily be made as hard as the key itself (making an attack a waste of time, no matter how much money you throw at it). But can you be sure that this is the only kind of attack? ;-) It would usually be much cheaper to get access to the system and manipulate the hardware, with a hardware keylogger e.g. than to get a key out of a smartcard. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Fri Dec 10 01:07:17 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 11:07:17 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D016CF7.2060503@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> <4D015D74.8020607@Mozilla-Enigmail.org> <4D016B08.6030805@adversary.org> <4D016CF7.2060503@sixdemonbag.org> Message-ID: <4D016F35.10906@adversary.org> On 10/12/10 10:57 AM, Robert J. Hansen wrote: > On 12/9/2010 6:49 PM, Ben McGinnes wrote: >> Just to clarify, does this mean that SHA-256 or 512 (or whatever) >> truncated to 160-bits prevent the potential collision attacks that >> might be able to be launched against SHA-1? > > Correct. Truncating a hash does not introduce any flaws in the > algorithm. If you truncate a bad hash, you now have a truncated bad > hash. Truncate a good hash and you have a truncated good hash. :) Excellent. Thanks. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri Dec 10 01:16:03 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 9 Dec 2010 19:16:03 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D016B08.6030805@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> <4D015D74.8020607@Mozilla-Enigmail.org> <4D016B08.6030805@adversary.org> Message-ID: <7058F089-237A-40D1-A8D4-C7FCB1C1BCF2@jabberwocky.com> On Dec 9, 2010, at 6:49 PM, Ben McGinnes wrote: >> Or one can use enable-dsa2 in GnuPG and use any of the SHA2 hashes, >> they'll just be truncated down to 160 bits similarly to the >> SHA-224/SHA-256 arrangement described below. > > Just to clarify, does this mean that SHA-256 or 512 (or whatever) > truncated to 160-bits prevent the potential collision attacks that > might be able to be launched against SHA-1? Yes, but at the risk of pedantry: The attacks against SHA-1 haven't been extended to the SHA-2 family yet. By truncating a SHA-2 to 160 bits, you're creating a non-broken (for now) 160-bit hash. Think of it as a non-broken SHA-1: it's theoretically as strong as SHA-1 once was thought to be, but not stronger. (i.e. it's a great SHA-1 alternative, but it's not as strong as a full-sized SHA-2). David From ben at adversary.org Fri Dec 10 01:33:11 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 11:33:11 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D016C8D.9090209@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D0157F8.2070509@tx.rr.com> <4D0163CB.7010903@adversary.org> <4D016C8D.9090209@sixdemonbag.org> Message-ID: <4D017547.9040905@adversary.org> On 10/12/10 10:55 AM, Robert J. Hansen wrote: > On 12/9/2010 6:18 PM, Ben McGinnes wrote: >> The last bit of documentation I saw on ECC is a little old and stated >> that it wasn't well known enough to consider using. I guess that's >> changed now. > > Back in 2000 or so, the consensus was that ECC was too new and > rested on some dicey conjectures. The last thing I read on ECC was Sam Simpson's FAQ on PGP, which was published in 1999 and was saying exactly that. > Since the proof of the Taniyama-Shimura conjecture (or, as it's now > called, Wiles' Theorem), ECC's theoretical underpinnings seem to be > on fairly solid ground. That's a fairly significant update. > The National Security Agency has approved ECC for use in its Suite B > of cryptographic algorithms, and has authorized it for protection of > the highest levels of state secrets (TS/SCI) when used with 384-bit > ECC keys. > > John's information (that Suite B was authorized for SECRET) is > correct: he was looking at the bit about Suite B that relates to > 256-bit ECC keys. The DSD over here have fairly similar recommendations, but then they work very closely with the NSA. The unclassified version of their Information Security Manual is here: http://www.dsd.gov.au/infosec/ism/index.htm > The NSA is quite good about publishing its real information security > policies. They have a *lot* of contractors who work with them, and And a lot of vendors supporting those contractors and other personnel. > keeping the rules for how to secure classified information hidden > would ultimately only harm overall operational security. They > *want* people to know the right way to take care of TS/SCI material. > > They never want to hear someone say, "sure, I sent that TS/SCI file > in plaintext. Wait, I wasn't supposed to do that? I was never > told! Why aren't those rules on your website?" It doesn't help if the rules are ignored, though, as recent events have demonstrated. I've no doubt there are people inside the NSA reaching for the LARTs and the Clue-by-Fours. ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Fri Dec 10 01:45:02 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 10 Dec 2010 11:45:02 +1100 Subject: multiple subkeys and key transition In-Reply-To: <7058F089-237A-40D1-A8D4-C7FCB1C1BCF2@jabberwocky.com> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> <4D015D74.8020607@Mozilla-Enigmail.org> <4D016B08.6030805@adversary.org> <7058F089-237A-40D1-A8D4-C7FCB1C1BCF2@jabberwocky.com> Message-ID: <4D01780E.6020407@adversary.org> On 10/12/10 11:16 AM, David Shaw wrote: > > Yes, but at the risk of pedantry: I'd rather the accuracy of pedantry than be mired in uffish thought. > The attacks against SHA-1 haven't been extended to the SHA-2 family > yet. By truncating a SHA-2 to 160 bits, you're creating a > non-broken (for now) 160-bit hash. Think of it as a non-broken > SHA-1: it's theoretically as strong as SHA-1 once was thought to be, > but not stronger. > > (i.e. it's a great SHA-1 alternative, but it's not as strong as a > full-sized SHA-2). Alright, that's pretty clear, thanks. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From John at Mozilla-Enigmail.org Fri Dec 10 02:48:42 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Thu, 09 Dec 2010 19:48:42 -0600 Subject: multiple subkeys and key transition In-Reply-To: <4D016C8D.9090209@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D0157F8.2070509@tx.rr.com> <4D0163CB.7010903@adversary.org> <4D016C8D.9090209@sixdemonbag.org> Message-ID: <4D0186FA.6040101@Mozilla-Enigmail.org> Robert J. Hansen wrote: > On 12/9/2010 6:18 PM, Ben McGinnes wrote: >> The last bit of documentation I saw on ECC is a little old and stated >> that it wasn't well known enough to consider using. I guess that's >> changed now. > > Back in 2000 or so, the consensus was that ECC was too new and rested on > some dicey conjectures. Since the proof of the Taniyama-Shimura > conjecture (or, as it's now called, Wiles' Theorem), ECC's theoretical > underpinnings seem to be on fairly solid ground. > > The National Security Agency has approved ECC for use in its Suite B of > cryptographic algorithms, and has authorized it for protection of the > highest levels of state secrets (TS/SCI) when used with 384-bit ECC keys. > > John's information (that Suite B was authorized for SECRET) is correct: > he was looking at the bit about Suite B that relates to 256-bit ECC keys. > "A key aspect of Suite B is its use of elliptic curve technology instead of classical public key technology. During the transition to the use of elliptic curve cryptography in ECDH and ECDSA, DH, DSA and RSA can be used with a 2048-bit modulus to protect classified information up to the _secret_ level." -- http://www.keylength.com/en/6/ "...This process will allow vendors who have NSA-certified Type 1 cryptographic products to develop a version of this product that uses Suite B cryptography and meets a revised set of NSA?s security standards which are appropriate for protecting information up to the SECRET level. Also, depending on our clients? needs, it will allow vendors to develop cryptographic products that only meet the set of NSA?s security standards that are appropriate for protecting information up to the SECRET level. When these products do not contain any classified algorithms or technology, the handling and accountability requirements will be less stringent than for a Controlled COMSEC Item (CCI)." -- http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml Over and over on that page, one sees the phrase "up to the SECRET level." Most details of Suite-B for information above SECRET are classified, IIRC. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From faramir.cl at gmail.com Fri Dec 10 02:40:10 2010 From: faramir.cl at gmail.com (Faramir) Date: Thu, 09 Dec 2010 22:40:10 -0300 Subject: multiple subkeys and key transition In-Reply-To: <4D012039.9060506@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> Message-ID: <4D0184FA.2070201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 09-12-2010 15:30, Ben McGinnes escribi?: ... > Good to know. Should I make the transition now/soon, my current plan > is either of these two options: > > 1) 4,096-bit RSA signing key with a 4,096-bit Elgamal encryption key. > > 2) 4,096-bit RSA signing key with a 4,096-bit RSA encryption key and a > 4,096-bit Elgamal encryption key. Or you can use a 4,096-bit RSA main key (the one you use to sign other keys), with a 2048-bit RSA subkey, for signing things, and a 2048-bit whatever subkey for encryption. You can replace subkeys latter, and a 4096 main key should remain safe for some time. Best Regards P.S: I would use a smart card to store my keys for daily use, but I wouldn't create the keys in a smart card, since I wouldn't be able to backup them... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNAYT6AAoJEMV4f6PvczxAVaoH/327iMrmudM3itetq/L8ZAOL 07hh+kWx14AmQbFPMaiJVOc/XrJ9NA+0ek7m8tt1aM+TdWvhVrH1Qd40bvykDrya fmLsAnYs8mehy3+uZmxt77XeAhg4zuFqDGS/5slDB/Bj7JV7MCv2D++s52lTr1pi gZpu6Xsgb3cmOeRco5LpOlmwYjjEcp/WsU6P2+2dBKDofI1JZF+u3itQBtEv3yPl mDHASO0TIGCz+MNfGqgSYG9xmRckz/4JqMEsVGWyl2Tj3RMpp2p4BHYCdoVSMlIq 3lViMYQ+pVUELRU8HjRNMYpzToxpT0IWw6KA9SZqXPTARMv/bShpjdfETANLqq0= =6oT7 -----END PGP SIGNATURE----- From faramir.cl at gmail.com Fri Dec 10 03:21:20 2010 From: faramir.cl at gmail.com (Faramir) Date: Thu, 09 Dec 2010 23:21:20 -0300 Subject: multiple subkeys and key transition In-Reply-To: <4D012B2E.7080109@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> Message-ID: <4D018EA0.5040705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 09-12-2010 16:17, Robert J. Hansen escribi?: ... > It is unlikely it ever will. 3K RSA keys are believed to be equivalent > to a 128-bit symmetric key. If computational power ever develops to > that point, the solution is going to involve moving to entirely > different algorithms instead of just tacking on another couple of bits. I might be wrong, but I remember Bruce Schneier used thermodynamic to show it is not feasible to brute-force a 256 bits key, because the energy required to do it would be too much (like all the energy generated by the sun for several years, or something like that), even considering the computer used is fast enough, and doesn't lose energy as heat. It was somewhere in "Applied Cryptography, 2nd Ed." (search by "Thermodynamic Limitations" title). But of course, a flaw in AES would be a very different problem. Now, I'm not advocating for the usage of 32,768-bit RSA keys (nor tweaking GnuPG to allow 8,192-bit keys), but I was thinking... What is the key length of the OpenPGP implementation of Twofish? (I put Twofish as an example, because of the for-now-useless flaws in AES 256). If it is 256 bits, and provided the algorithm doesn't have flaws (or given it doesn't get as much attention as AES, the flaws remain undiscovered), we would already have "the ultimate symmetric algo" available, so we might want to use the strongest asymmetric size currently available. And a question: does the computation power required to factor RSA keys increase in lineal or more-than-lineal way? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNAY6gAAoJEMV4f6PvczxAdpQH/i+nbcvE4RHOvjRQT2KBsKnT sdHYIgcU1B0TtEYeyWBDDwTY73przqnrtQ792WAjVvTjde5vhVkYdg6q8rJ7520D oNBEIkNarpWOoHC/ubqsTNq0mCKlqjH5xXq2vD0ATHbwiTGGErxbCZmn+IxEt2J1 aNGSfEho2LiAozzYVGZDPXFK6qQnk5JPlwEhJSYND30XEDIaLr0nDsdzBirsYv/g /27WfcKWcAWQ54rBZ2J43W2sxCOEOk5TJh6S4XYHBf3gL5ZXBBj60MUXCdGg4N5T maRL1xMDGpTBbOn45gBYfQ38nYi28HkFYgOlzTBcHoVKUciFoDB5ui7zmeHKchk= =IzV+ -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Fri Dec 10 03:40:47 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 21:40:47 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D0186FA.6040101@Mozilla-Enigmail.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D0157F8.2070509@tx.rr.com> <4D0163CB.7010903@adversary.org> <4D016C8D.9090209@sixdemonbag.org> <4D0186FA.6040101@Mozilla-Enigmail.org> Message-ID: <4D01932F.1030800@sixdemonbag.org> On 12/9/2010 8:48 PM, John Clizbe wrote: > Most details of Suite-B for information above SECRET are classified, IIRC. Suite A is still classified. Suite B is pretty thoroughly documented. :) From http://www.nsa.gov/ia/programs/suiteb_cryptography/ : "AES with 256-bit keys, Elliptic Curve Public Key Cryptography using the 384-bit prime modulus elliptic curve as specified in FIPS PUB 186-3 and SHA-384 are required to protect classified information at the TOP SECRET level." ... TS/SCI, which is usually thought of as "above TS", is really just TS with some additional conditions and qualifiers on it -- so Suite B is usable with TS/SCI material. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From avi.wiki at gmail.com Fri Dec 10 03:44:28 2010 From: avi.wiki at gmail.com (Avi) Date: Thu, 9 Dec 2010 21:44:28 -0500 Subject: multiple subkeys and key transition Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 As someone who has been lurking on this list for years, I'd just like to thank everyone for their patience and detailed explanations. Ben is not the only one who has learned (or been re-taught) quite a bit from this conversation. Thanks! - --Avi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) - GPGshell v3.76 Comment: Most recent key: Click show in box @ http://is.gd/4xJrs iF4EAREKAAYFAk0Bk9MACgkQDWKwGfgOKfl1KgEAmHSOG8MM/lK222WPQ22bjgTy 68pPHRUhOMA9piDQETsA/jWKrpSIRge+/A5pTLGybZIVduAJc0l8bij+zM3mJ+p2 =UQTb -----END PGP SIGNATURE----- ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Dec 10 03:53:31 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 21:53:31 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D018EA0.5040705@gmail.com> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <4D012B2E.7080109@sixdemonbag.org> <4D018EA0.5040705@gmail.com> Message-ID: <4D01962B.2040407@sixdemonbag.org> On 12/9/2010 9:21 PM, Faramir wrote: > I might be wrong, but I remember Bruce Schneier used thermodynamic to > show it is not feasible to brute-force a 256 bits key... He just repeated the work of Landauer, Margolus and Levitin. Basically, for a digital computer working in base N, the amount of energy required to clear a unit of information is kT*lnN -- the Boltzmann Constant, multiplied by the temperature in kelvins at which the computer runs, times the natural log of the computer's numerical base. For a conventional digital computer, it requires about 10^-23 joules to erase a bit. That energy must be radiated as heat. If you're going to brute-force a 128-bit keyspace, you're going to be erasing 64 bits per key.[*] About 10^-21 joules per key must be radiated, multiplied by the 10^38 attempts you'd have to try on average, gets you 10^17 joules of heat... or about a 100-megaton nuclear explosion. Since Fort Meade is not a smoking radioactive sea of glass, I conclude the NSA is not brute-forcing 128-bit keys. :) In reality the thermodynamic analysis is even more ridiculous than this, since we're assuming you're not tampering with memory in any other way than just to set bits for a key. That's wildly unrealistic. In theory you can break the Landauer Bound with things like adiabatic computing and supra-Turing processing, but those things are so far out in the realm of science fiction they deserve to be called... well... science fiction. [*] You could brute-force the keyspace in a way that only requires you to erase fewer bits per key, but then the defender would just choose a key close to the end of your brute-force schedule. Hence, it's most efficient to do them more or less at random... > And a question: does the computation power required to factor RSA keys > increase in lineal or more-than-lineal way? Roughly logarithmic. As the moduli get larger, the number of primes get fewer and fewer. This is why a 1024-bit key is roughly proportional to an 80-bit symmetric key, a 2048-bit key is roughly proportional to a 112-bit symmetric key, and a 3072-bit key is roughly proportional to a 128-bit symmetric key. Three times the asymmetric key length only gives you half-again the symmetric length. From dshaw at jabberwocky.com Fri Dec 10 04:33:05 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 9 Dec 2010 22:33:05 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D012039.9060506@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> Message-ID: <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> On Dec 9, 2010, at 1:30 PM, Ben McGinnes wrote: > Good to know. Should I make the transition now/soon, my current plan > is either of these two options: > > 1) 4,096-bit RSA signing key with a 4,096-bit Elgamal encryption key. > > 2) 4,096-bit RSA signing key with a 4,096-bit RSA encryption key and a > 4,096-bit Elgamal encryption key. A good way to look at this is to pick what you want your primary key to be. The subkeys don't really matter that much, as the primary is the one that gathers signatures, and the one that makes (i.e. signs) subkeys. It's the key that establishes "identity" in the web of trust. The subkeys matter a lot less as it's trivial to make new subkeys whenever you feel the need, using whatever algorithm and size is favored at that point. One useful model is to make a large & non-expiring primary key, and use it only to make subkeys. Use a subkey for signing data, and a (different) subkey for encryption. This has a few advantages, such as that you can leave this primary key offline altogether (since you only actually need it to make more subkeys). It's hard to compromise a key that isn't actually on your computer most of the time :) David From avi.wiki at gmail.com Fri Dec 10 04:55:47 2010 From: avi.wiki at gmail.com (Avi) Date: Thu, 9 Dec 2010 22:55:47 -0500 Subject: multiple subkeys and key transition Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I believe our very own Rob discusses that here: - --Avi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) - GPGshell v3.76 Comment: Most recent key: Click show in box @ http://is.gd/4xJrs iF4EAREKAAYFAk0BpKwACgkQDWKwGfgOKfmFQAD+OOcvI8ZMsEEvhT+htzhhAdVj IDxpJF+PhUjolU+VRT4A/i18Js8aHAQRNzqO06/x48Zr9yohKeIx9/0D9se50Wve =TOR9 -----END PGP SIGNATURE----- ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 From: Faramir > To: "gnupg-users at gnupg.org" > Date: Thu, 09 Dec 2010 23:21:20 -0300 > Subject: Re: multiple subkeys and key transition > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > El 09-12-2010 16:17, Robert J. Hansen escribi?: > ... > > It is unlikely it ever will. 3K RSA keys are believed to be equivalent > > to a 128-bit symmetric key. If computational power ever develops to > > that point, the solution is going to involve moving to entirely > > different algorithms instead of just tacking on another couple of bits. > > I might be wrong, but I remember Bruce Schneier used thermodynamic to > show it is not feasible to brute-force a 256 bits key, because the > energy required to do it would be too much (like all the energy > generated by the sun for several years, or something like that), even > considering the computer used is fast enough, and doesn't lose energy as > heat. It was somewhere in "Applied Cryptography, 2nd Ed." (search by > "Thermodynamic Limitations" title). But of course, a flaw in AES would > be a very different problem. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Dec 10 05:32:08 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 09 Dec 2010 23:32:08 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D015D74.8020607@Mozilla-Enigmail.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> <4D015D74.8020607@Mozilla-Enigmail.org> Message-ID: <4D01AD48.8070001@sixdemonbag.org> On 12/9/2010 5:51 PM, John Clizbe wrote: > I just created new keys after almost 8 years, my old key was 1024D/2048ElG. The > new keys are 2048-DSA2/2048-RSA and a 3x2048-RSA OpenPGP card. My personal opinion -- can't back it up with anything more than my own meandering experience -- is that many OpenPGP users are way too attached to their certificates. Sooner or later you *will* have a key compromise event, you *will* need to revoke keys in a hurry and you *will* need to find some way to re-establish a WoT with your core correspondents. The question is not if, the question is only when. If you never revoke-and-reissue certs (perhaps out of a desire to preserve your WoT), then when the time comes not only are you going to be stressed out and not thinking clearly, but you'll be performing a task that's unfamiliar to you. This isn't something I'd think wise. Every couple of years I open a binder, flip to the Cert Revocation Checklist, and go down the list. It's a dry run for a for-real event. By the end of the event I've discovered places the checklist fails and needs to be fixed, found "oh, heck, Bob's entered my WoT since I last wrote this, I need to update that!", etc., etc. The one time I've needed my Cert Rev Checklist for-real, I was really glad I had it. I find this to be a useful exercise. Your mileage may, and probably will, vary. If you have a very well-developed WoT and don't want to jeopardize breaking other people's WoTs, then you might not want to do this. :) From david at systemoverlord.com Fri Dec 10 05:08:56 2010 From: david at systemoverlord.com (David Tomaschik) Date: Thu, 9 Dec 2010 23:08:56 -0500 Subject: Best Practices Message-ID: I'm currently in the process of changing my "primary" email address. I have hopes to make this a permanent transition, and have had some thoughts about my existing GPG keypair. For better or worse, I've been playing around with GPG since I was a teenager, and (unfortunately) there are a number of keys on the keyservers that bear my name. The good news is that with the exception of one old (2000) keypair, all the others that I no longer use have been revoked. I feel bad for the "litter" this introduces to the keyservers. I currently have a 4096-bit RSA sign/encrypt keypair with no subkeys. I believe, but am not certain, that it was generated with SHA1 hashes. (Is there a way I can check?) This keypair was generated in May of this year. What is the best way to transition my email address? Add a new UID and revoke the old? Should a new keypair be generated? What is the conventional wisdom on the strength of RSA-4096? If a new keypair is generated, what length would be sufficient for a decent (10+ year, preferrably 20+) margin of safety? I know that there may be unforeseen advances in computing that allow for keys to be broken rapidly (Quantum computing, new sieve algorithms, etc.), but there's surely some guidance based on the current generation of things. keylength.com suggests 4096 bits should probably be fine. In a new keypair, is it safe to use SHA512 for hashes? I know SHA1 is unlikely to hold up for 20+ years. I can't say that SHA512 will, but it will almost certainly outlast SHA1. Is it considered best practice to use a "master key" only for key signing and use separate subkeys for signing/encrypting data? Most of the GPG best practices I can find online are quite dated, and since the field of encryption is changing so rapidly, I thought the insights of this group might be useful in my next steps. Your help is appreciated. -- David Tomaschik, RHCE, LPIC-1 GNU/Linux System Architect david at systemoverlord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From olav at mozilla-enigmail.org Fri Dec 10 10:08:56 2010 From: olav at mozilla-enigmail.org (Olav Seyfarth) Date: Fri, 10 Dec 2010 10:08:56 +0100 Subject: clearsign failed: Bad signature Message-ID: <4D01EE28.2000304@mozilla-enigmail.org> Hi list, since a couple of days I encounter gpg errors that I do not know how to solve. echo "test" > _ gpg --clearsign < _ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 "test" gpg: checking created signature failed: Bad signature gpg: signing failed: Bad signature gpg: [stdin]: clearsign failed: Bad signature System: Windows 7 64bit, gpg (GnuPG) 2.0.16 (Gpg4win 2.1.0-beta1) Any hint appreciated, Olav -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications From wk at gnupg.org Fri Dec 10 10:43:10 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Dec 2010 10:43:10 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D011983.6060905@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 09 Dec 2010 13:01:39 -0500") References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> Message-ID: <87tyimezf5.fsf@vigenere.g10code.de> On Thu, 9 Dec 2010 19:01, dkg at fifthhorseman.net said: > This discussion currently seems to be idle, so i would not wait on it. > We need to get the discussion going again, certainly. The understanding of the WG is that we want to wait for the outcome of the SHA-3 contest before we change anything in OpenPGP. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 10 10:48:23 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 10 Dec 2010 10:48:23 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D01AD48.8070001@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 09 Dec 2010 23:32:08 -0500") References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> <4D015D74.8020607@Mozilla-Enigmail.org> <4D01AD48.8070001@sixdemonbag.org> Message-ID: <87pqtaez6g.fsf@vigenere.g10code.de> On Fri, 10 Dec 2010 05:32, rjh at sixdemonbag.org said: > Sooner or later you *will* have a key compromise event, you *will* need > to revoke keys in a hurry and you *will* need to find some way to Unless you use an offline primary key which should not suffer from a key compromise unless you are directly targeted by nightly visits to your home . If one of your subkeys gets compromised, revoking and creating a new subkey is then really easy. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Fri Dec 10 14:15:36 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 10 Dec 2010 14:15:36 +0100 Subject: multiple subkeys and key transition In-Reply-To: <4D0184FA.2070201@gmail.com> References: <4D0073DD.3020701@adversary.org> <4D012039.9060506@adversary.org> <4D0184FA.2070201@gmail.com> Message-ID: <201012101415.36652.mailinglisten@hauke-laging.de> Am Freitag 10 Dezember 2010 02:40:10 schrieb Faramir: > P.S: I would use a smart card to store my keys for daily use, but I > wouldn't create the keys in a smart card, since I wouldn't be able to > backup them... man gpg2 bkuptocard file Restore the given file to a card. This command may be used to restore a backup key (as generated during card initialization) to a new card. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Fri Dec 10 14:49:16 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 10 Dec 2010 08:49:16 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D011983.6060905@fifthhorseman.net> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> Message-ID: <6E65FDD7-0EDD-4407-A893-F26DFE20F9DE@jabberwocky.com> On Dec 9, 2010, at 1:01 PM, Daniel Kahn Gillmor wrote: >> Second, the >> OpenPGP Working Group ("the WG") is currently figuring out how to get >> SHA-1 out of the OpenPGP spec and how to replace it with something better. > > This discussion currently seems to be idle, so i would not wait on it. > We need to get the discussion going again, certainly. It's not likely to go anywhere useful until the NIST hash competition is finished (or at least is almost finished). The competition came about at least partially because people realized we don't really know enough about hashing, so it's foolish to make hash-related decisions for OpenPGP before the competition completes. >> If you do a transition now, it's possible you'll want to transition >> again in six months or a year once the WG updates the RFC. > > This statement seems to assume that the RFC can't or won't be updated in > a way that people could make the transition using the same key material, > assuming they were using strong enough keys and digests in the first place. I think that an update that truly removes SHA-1 is almost certainly going to not have a way to "upgrade" an existing key. I ran through a bunch of cases when discussing this a while ago, and the various permutations where where Alice has a new key and Baker has an old implementation were rather unpleasant. Why would you want to do it? To avoid the hit to the web of trust? (i.e. getting all of your signatures again?) This gets dramatically easier (and you can probably keep your existing keys) if you're willing to keep SHA-1 fingerprints, though not everyone is. > My own personal bottom line: i've been using digests from the SHA-2 > family for well over a year now (and larger RSA keys for twice that > time) and have had no interoperability problems. Yes. This was an issue once. I don't see it as an issue any longer. Not just because many implementations support the whole set of ciphers and hashes, but because most implementations properly support the preference system, so even if they don't support a particular cipher or hash, the protocol can properly deal with it. David From rjh at sixdemonbag.org Fri Dec 10 15:41:28 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 10 Dec 2010 09:41:28 -0500 Subject: Best Practices In-Reply-To: References: Message-ID: <4D023C18.2060300@sixdemonbag.org> On 12/9/2010 11:08 PM, David Tomaschik wrote: > I feel bad for the "litter" this introduces to the keyservers. Don't. :) The keyservers don't have a problem with this litter. I wish people showed more care with their certificates, but that's because I get too many "I forgot my passphrase, help!" emails, not because I think the keyserver network is getting clogged. > I currently have a 4096-bit RSA sign/encrypt keypair with no subkeys. I > believe, but am not certain, that it was generated with SHA1 hashes. > (Is there a way I can check?) This keypair was generated in May of this > year. Well, you have one subkey, it's just that the subkey is capable of both signing and encryption. You don't have separate subkeys for separate tasks, if I understand you correctly. Some people think this is a bad idea, since if you're compelled to produce an encryption key to the authorities (so they can decrypt an email sent to you) you've also provided them with your signature key (so they can now impersonate you). > What is the best way to transition my email address? Add a new UID and > revoke the old? Should a new keypair be generated? What is the > conventional wisdom on the strength of RSA-4096? Add a new UID and revoke the old. You don't need to generate a new certificate. RSA-4K is, IMO, phenomenal overkill for the vast majority of users. Breaking RSA-2K is believed comparable in difficulty to breaking 3DES, and that prospect is ... let's just say "implausible." RSA-3K is roughly comparable to breaking AES-128. RSA-4K is not very much harder than that. Given all this, I really don't see any point in going past RSA-2K. Adding another 2,000 bits to the key in order to get about another 20 bits of symmetric-key equivalent just strikes me as bad art. > If a new keypair is generated, what length would be sufficient for a > decent (10+ year, preferrably 20+) margin of safety? I know that there > may be unforeseen advances in computing that allow for keys to be broken > rapidly (Quantum computing, new sieve algorithms, etc.), but there's > surely some guidance based on the current generation of things. There is not. In twenty years we will see commonplace attacks that today are just speculative science fiction. It's incredibly hard to make good long-term predictions about crypto. It is possible that in twenty years national governments will have large-scale quantum processors. Once that happens, RSA, DSA and ElGamal all die horrible screaming deaths. As an example: almost twenty years ago Schneier wrote in _Applied Cryptography_ of the Chinese Lottery Attack. It involved putting a small processor in every Chinese television set, which could be programmed by broadcasts from Party headquarters. Each processor would crunch a small part of the keyspace, and as soon as a hit was achieved the television would tell the viewer, "You have won! Call Party headquarters with this authorization number: [insert key here]." Twenty years ago the Chinese Lottery Attack was an interesting thought experiment, but nobody took it seriously. Today we have RC5-64, distributed.net, seti at home, botnets, Amazon EC2 and all manner of other massively distributed computing frameworks. The question today isn't whether a Chinese Lottery Attack is possible: the question is how much it will cost you to rent your server time. The future is a scary place. But fun, too, and I look forward to getting there. :) > In a new keypair, is it safe to use SHA512 for hashes? Sure, but you don't need to create a new cert to use new hash algorithms. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From dshaw at jabberwocky.com Fri Dec 10 16:32:23 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 10 Dec 2010 10:32:23 -0500 Subject: Speaking about SHA-3... Message-ID: <4227A18C-9F8F-47F7-8500-D5F15C1A6EEE@jabberwocky.com> With the various discussions about OpenPGP and hashes recently, I thought this would be of interest to the folks here: http://www.reddit.com/r/crypto/comments/ej7m2/sha3_finalists Incidentally, Skein is one of the finalists. Here's some analysis of Skein: http://eprint.iacr.org/2010/623 David From John at Mozilla-Enigmail.org Fri Dec 10 23:52:33 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Fri, 10 Dec 2010 16:52:33 -0600 Subject: Best Practices In-Reply-To: <4D023C18.2060300@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> Message-ID: <4D02AF31.8000707@Mozilla-Enigmail.org> Robert J. Hansen wrote: > On 12/9/2010 11:08 PM, David Tomaschik wrote: >> If a new keypair is generated, what length would be sufficient for a >> decent (10+ year, preferrably 20+) margin of safety? I know that there >> may be unforeseen advances in computing that allow for keys to be broken >> rapidly (Quantum computing, new sieve algorithms, etc.), but there's >> surely some guidance based on the current generation of things. > > There is not. In twenty years we will see commonplace attacks that > today are just speculative science fiction. It's incredibly hard to > make good long-term predictions about crypto. Good case in point of this, some weeks ago a user on another list was asking about increasing his RSA key size to 8192 bits, based on reading that "Bruce Schneier, in _Applied Cryptography_, has recommended a 8192 bit key if you want it to have a useful lifetime beyond 2015." It was pointed out, Bruce Schneier has done a lot of great work, but relying on 14-year-old advice for RSA key sizes ignores current work and best practice thought in cryptography. Over the summer, readers of the [Cryptography] mailing list were reminded that in 1993 folks thought that 1024-bit RSA 'should be ok (safe from key-factoring attacks) for "a few decades".' These are just two examples long term predictions that missed. Back when these predictions were made, no one foresaw the development of Elliptic Curve Cryptography which is looking likely to be the "upgrade" path for RSA/DSA2 keys larger than 2048-3072 bits. A 3072 bit RSA key is as tough as an ECC key based on a 256 bit field, which is as tough as a 128 bit symmetric key. ECC cryptosystems on a 256 bit field are practical today. 3072 bit RSA systems are not. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Sat Dec 11 00:04:55 2010 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 11 Dec 2010 00:04:55 +0100 Subject: Best Practices In-Reply-To: <4D02AF31.8000707@Mozilla-Enigmail.org> References: <4D023C18.2060300@sixdemonbag.org> <4D02AF31.8000707@Mozilla-Enigmail.org> Message-ID: <4D02B217.8080803@vulcan.xs4all.nl> On 10-12-2010 23:52, John Clizbe wrote: > ECC cryptosystems on a 256 bit field are practical today. 3072 bit RSA systems > are not. Why are 3072 bit RSA systems not practical today? Except for situations where very few data can be transmitted (text messages on your phone is the only application that I can think of now, where an application CryptoSMS exists that does indeed use ECC) even my old P3 computer has absolutely no problems using 3072 bit keys (or even larger keys for that matter, wether it is usefull or not). -- Met vriendelijke groet, Johan Wevers From rjh at sixdemonbag.org Sat Dec 11 01:11:53 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 10 Dec 2010 19:11:53 -0500 Subject: Best Practices In-Reply-To: <4D02B217.8080803@vulcan.xs4all.nl> References: <4D023C18.2060300@sixdemonbag.org> <4D02AF31.8000707@Mozilla-Enigmail.org> <4D02B217.8080803@vulcan.xs4all.nl> Message-ID: <4D02C1C9.30109@sixdemonbag.org> On 12/10/2010 6:04 PM, Johan Wevers wrote: > Why are 3072 bit RSA systems not practical today? Except for situations > where very few data can be transmitted... Answered your own question there. :) RSA-3K is practical for a lot of problem domains, but I wouldn't consider it a good general recommendation. For instance, there are a lot of smartcards that don't play well with 3K keys. As a general recommendation, I think 3K is a bad idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From david at systemoverlord.com Sat Dec 11 03:16:56 2010 From: david at systemoverlord.com (David Tomaschik) Date: Fri, 10 Dec 2010 21:16:56 -0500 Subject: Best Practices In-Reply-To: <4D023C18.2060300@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> Message-ID: I appreciate everyone's feedback on this matter. Comments/questions below... On Fri, Dec 10, 2010 at 9:41 AM, Robert J. Hansen wrote: > On 12/9/2010 11:08 PM, David Tomaschik wrote: > > I feel bad for the "litter" this introduces to the keyservers. > > Don't. :) The keyservers don't have a problem with this litter. I > wish people showed more care with their certificates, but that's because > I get too many "I forgot my passphrase, help!" emails, not because I > think the keyserver network is getting clogged. > Only my oldest key (ca. 2000) is still in the wild, with a lost private key. Many lessons were learned from that. > > > I currently have a 4096-bit RSA sign/encrypt keypair with no subkeys. I > > believe, but am not certain, that it was generated with SHA1 hashes. > > (Is there a way I can check?) This keypair was generated in May of this > > year. > > Well, you have one subkey, it's just that the subkey is capable of both > signing and encryption. You don't have separate subkeys for separate > tasks, if I understand you correctly. Some people think this is a bad > idea, since if you're compelled to produce an encryption key to the > authorities (so they can decrypt an email sent to you) you've also > provided them with your signature key (so they can now impersonate you). > Are there any disadvantages to distinct signature & encryption keys? Seems like there's benefit with little cost (other than a bigger keyring). I'm currently considering generating an offline-only master key and using that to sign other keys. Some of the other threads in the archives seemed to recommend this. > > > What is the best way to transition my email address? Add a new UID and > > revoke the old? Should a new keypair be generated? What is the > > conventional wisdom on the strength of RSA-4096? > > Add a new UID and revoke the old. You don't need to generate a new > certificate. RSA-4K is, IMO, phenomenal overkill for the vast majority > of users. Breaking RSA-2K is believed comparable in difficulty to > breaking 3DES, and that prospect is ... let's just say "implausible." > > RSA-3K is roughly comparable to breaking AES-128. RSA-4K is not very > much harder than that. Given all this, I really don't see any point in > going past RSA-2K. Adding another 2,000 bits to the key in order to get > about another 20 bits of symmetric-key equivalent just strikes me as bad > art. > > > If a new keypair is generated, what length would be sufficient for a > > decent (10+ year, preferrably 20+) margin of safety? I know that there > > may be unforeseen advances in computing that allow for keys to be broken > > rapidly (Quantum computing, new sieve algorithms, etc.), but there's > > surely some guidance based on the current generation of things. > > There is not. In twenty years we will see commonplace attacks that > today are just speculative science fiction. It's incredibly hard to > make good long-term predictions about crypto. > > It is possible that in twenty years national governments will have > large-scale quantum processors. Once that happens, RSA, DSA and ElGamal > all die horrible screaming deaths. > > As an example: almost twenty years ago Schneier wrote in _Applied > Cryptography_ of the Chinese Lottery Attack. It involved putting a > small processor in every Chinese television set, which could be > programmed by broadcasts from Party headquarters. Each processor would > crunch a small part of the keyspace, and as soon as a hit was achieved > the television would tell the viewer, "You have won! Call Party > headquarters with this authorization number: [insert key here]." > > Twenty years ago the Chinese Lottery Attack was an interesting thought > experiment, but nobody took it seriously. > > Today we have RC5-64, distributed.net, seti at home, botnets, Amazon EC2 > and all manner of other massively distributed computing frameworks. The > question today isn't whether a Chinese Lottery Attack is possible: the > question is how much it will cost you to rent your server time. > > The future is a scary place. But fun, too, and I look forward to > getting there. :) > > > In a new keypair, is it safe to use SHA512 for hashes? > > Sure, but you don't need to create a new cert to use new hash algorithms. > > Is the weakness in the hash used to sign the key internally, or just when it is used to sign data? I guess that's the part that eludes me. I've been looking at the thread earlier this month regarding smartcards. Are the options from kernel concepts basically the full range of GPG-compatible smart cards, or are there other products I haven't seen? Obviously I'd need a new keypair if I switched to that, as they only go up to RSA3k. Thanks again, David Tomaschik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at adversary.org Sat Dec 11 10:15:04 2010 From: ben at adversary.org (Ben McGinnes) Date: Sat, 11 Dec 2010 20:15:04 +1100 Subject: multiple subkeys and key transition In-Reply-To: <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> Message-ID: <4D034118.6090901@adversary.org> On 10/12/10 2:33 PM, David Shaw wrote: > > A good way to look at this is to pick what you want your primary key > to be. The subkeys don't really matter that much, as the primary is > the one that gathers signatures, and the one that makes (i.e. signs) > subkeys. It's the key that establishes "identity" in the web of > trust. The subkeys matter a lot less as it's trivial to make new > subkeys whenever you feel the need, using whatever algorithm and > size is favored at that point. Very interesting. > One useful model is to make a large & non-expiring primary key, and > use it only to make subkeys. Use a subkey for signing data, and a > (different) subkey for encryption. This has a few advantages, such > as that you can leave this primary key offline altogether (since you > only actually need it to make more subkeys). It's hard to > compromise a key that isn't actually on your computer most of the > time :) I think this is probably what I will do for my next key, but how do I specify between the primary key and the signing subkey when signing messages? Is that done with the Sign, Encrypt, Certify and Authenticate capabilities during key creation? I'm happy to do it in expert mode, I just want to be clear on the different options. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Sat Dec 11 10:18:43 2010 From: ben at adversary.org (Ben McGinnes) Date: Sat, 11 Dec 2010 20:18:43 +1100 Subject: multiple subkeys and key transition In-Reply-To: <4D01AD48.8070001@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D00FE12.9060907@adversary.org> <4D015D74.8020607@Mozilla-Enigmail.org> <4D01AD48.8070001@sixdemonbag.org> Message-ID: <4D0341F3.1000902@adversary.org> On 10/12/10 3:32 PM, Robert J. Hansen wrote: > > I find this to be a useful exercise. Your mileage may, and probably > will, vary. If you have a very well-developed WoT and don't want to > jeopardize breaking other people's WoTs, then you might not want to do > this. :) It certainly looks useful (along with the other signature key suggestions). I suspect I will be referring back to this thread a lot in the future. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From htd at fritha.org Sat Dec 11 09:17:58 2010 From: htd at fritha.org (Heinz Diehl) Date: Sat, 11 Dec 2010 09:17:58 +0100 Subject: Speaking about SHA-3... In-Reply-To: <4227A18C-9F8F-47F7-8500-D5F15C1A6EEE@jabberwocky.com> References: <4227A18C-9F8F-47F7-8500-D5F15C1A6EEE@jabberwocky.com> Message-ID: <20101211081758.GA6793@fritha.org> On 10.12.2010, David Shaw wrote: > Here's some analysis of Skein: http://eprint.iacr.org/2010/623 I can only see 10 pages full of statements without any discussion or proof, which doesn't even meet the criteria of a standard abtract. Either I'm doing something wrong, being just too dumb to see, or the whole article is nothing more than bull. From mlisten at hammernoch.net Sat Dec 11 11:48:57 2010 From: mlisten at hammernoch.net (=?ISO-8859-1?Q?Ludwig_H=FCgelsch=E4fer?=) Date: Sat, 11 Dec 2010 11:48:57 +0100 Subject: Speaking about SHA-3... In-Reply-To: <20101211081758.GA6793@fritha.org> References: <4227A18C-9F8F-47F7-8500-D5F15C1A6EEE@jabberwocky.com> <20101211081758.GA6793@fritha.org> Message-ID: <4D035719.1010403@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Heinz Diehl wrote on 11.12.10 09:17: > On 10.12.2010, David Shaw wrote: > >> Here's some analysis of Skein: http://eprint.iacr.org/2010/623 > > I can only see 10 pages full of statements without any discussion or > proof, which doesn't even meet the criteria of a standard abtract. > > Either I'm doing something wrong, being just too dumb to see, or > the whole article is nothing more than bull. Your irony detector seems to need some adjustment ;-) Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJNA1cQAAoJEA52XAUJWdLjnOUIALJq7aVrPdg/VFxq2Hchb+e/ Q8eLZj8YML3/3J4Hf8bzerGHODy4a9HxEEhI/JY6ygzGjccJLOxGL6U4q/LUbbeF qqt8O0hFJxY+3auIC3GNAb1Bn5WOpTkb3aBmHD0l023ivLRBlWv1x0U/X6VHl4Fl KWYwgWkSLSJHN/+JbsfopycBiXyA3U2g6/tUYYHECC2q83DbP6PVWt08sxMNppJI Gbr3wRlhLqUFWbQjPlJ+mno5bDCLEhT/fu5IloxX3MivY7wsQyV+9646vyesp/5b GumQoxg+NuWA4bUG3f0TXs+yNNMr0bumQP0iusTLIWl2OIZ5pusNwITbPgmH3xw= =eLiy -----END PGP SIGNATURE----- From olav at mozilla-enigmail.org Sat Dec 11 14:57:34 2010 From: olav at mozilla-enigmail.org (Olav Seyfarth) Date: Sat, 11 Dec 2010 14:57:34 +0100 Subject: clearsign failed: Bad signature In-Reply-To: <4D01EE28.2000304@mozilla-enigmail.org> References: <4D01EE28.2000304@mozilla-enigmail.org> Message-ID: <4D03834E.4010208@mozilla-enigmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hi list, > Hash: SHA256 > gpg: checking created signature failed: Bad signature I found the cause (in gpg.conf): | personal-digest-preferences SHA256 doesn't work | personal-digest-preferences SHA512 doesn't work either | personal-digest-preferences RIPEMD160 does work. My key: OpenPGP SmartCard v2 key 0x6AE1EF56 (3072 Bit RSA) Card 0005 00000222 Why can't I use SHA256/SHA512 with this card? | enable-dsa2 is set and showpref lists | [ultimate] (1). Olav Seyfarth (Card 011D) | Cipher: AES256, AES192, AES, CAST5, 3DES | Digest: SHA256, SHA1, SHA384, SHA512, SHA224 | Compression: ZLIB, BZIP2, ZIP, Uncompressed | Features: MDC, Keyserver no-modify | [ultimate] (3) Olav Seyfarth (Card 011D) | Cipher: AES256, AES192, AES, CAST5, 3DES | Digest: SHA256, SHA1, SHA384, SHA512, SHA224 | Compression: ZLIB, BZIP2, ZIP, Uncompressed | Features: MDC, Keyserver no-modify | [ultimate] (4) Olav Seyfarth (Card 011D) | Cipher: AES256, AES192, AES, CAST5, 3DES | Digest: SHA256, SHA1, SHA384, SHA512, SHA224 | Compression: ZLIB, BZIP2, ZIP, Uncompressed | Features: MDC, Keyserver no-modify | [ultimate] (5) [jpeg image of size 1540] | Cipher: AES256, AES192, AES, CAST5, 3DES | Digest: SHA256, SHA1, SHA384, SHA512, SHA224 | Compression: ZLIB, BZIP2, ZIP, Uncompressed | Features: MDC, Keyserver no-modify Olav - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGcBAEBAwAGBQJNA4NFAAoJEKGX32tq4e9W08wL/R9hEDl5ZMqeYXY262T1jARr 237XCqZ9kbAAaB/LWrhyqgb7wmRpDBDf4mKP1EAOkPr/uuPt4AHHr6r9lWqT9sfu qLR3/6zSz4n29/DYKu077KsmKh26Cmzaa0KrOlDjgu9zO6E84X/fEWKxHJtQezpM MXgXu+7YXkl9413WMntiBdFH8r0XBHQqrLSEtVkWTr6xzYNbqDHKfdWR7eWn2SJY 1yLOtVzWWfhzrVUNKyp3aLTpjz0mfCP4s6FQSrBIStMZKoQNYDde8qHHkfVsYCFm ZVclvA0m9NoROdVBpdo9GbiZsx1jnQXhjd6TpqrcKK+Lbnz0CugdqdpWwYGpVkSR IyWCVjbJtCYwLobio0OrO5+3L19in89ylzWeSlHTzoRFsd2XamKpQxl/Tl/hJH4n +bREhgSy2egt7cl5vQMIvWr6OuRLWoPmWHyND/YbBDFXkfvzpEfxClic+1S/ic2R SyhtVhnsB78tm+aAo2XXqTjvX2hEKYDkaxJ0tS5bQw== =blaG -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sat Dec 11 17:24:46 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 11 Dec 2010 11:24:46 -0500 Subject: Best Practices In-Reply-To: References: <4D023C18.2060300@sixdemonbag.org> Message-ID: <4D03A5CE.2080509@sixdemonbag.org> On 12/10/2010 9:16 PM, David Tomaschik wrote: > Are there any disadvantages to distinct signature & encryption keys? None that I've found. > Is the weakness in the hash used to sign the key internally, or just when > it is used to sign data? I guess that's the part that eludes me. Err -- "yes." A certificate is just a block of key material plus some associated data. SHA-1 is used internally by the certificate to sign some parts of the data, as well as for computing a key fingerprint. You can to some extent mitigate how much SHA-1 gets used, but you can't remove it completely. You can also choose to use SHA-1 to sign messages and files. Here, you can remove it completely in favor of some other hash algorithm. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From lists at chrispoole.com Sat Dec 11 17:36:46 2010 From: lists at chrispoole.com (Chris Poole) Date: Sat, 11 Dec 2010 16:36:46 +0000 Subject: Add sign key only? Message-ID: I have been using gpg for a while now, with just one subkey for signing and encryption. I decided I wanted a separate key for signing, so if I have to give away my private key for decrypting documents, they can't use it to impersonate me too. Listing my keys was like this: pub 1024D/BAD246F9 created: 2006-03-31 expires: never usage: SC sub 4096g/E71D7B3E created: 2006-03-31 expires: never usage: E So I ran `gpg --edit-key BAD246F9`, and `addkey`. I chose DSA (sign only) 2048-bit. My keychain looks like this now: pub 1024D/BAD246F9 created: 2006-03-31 expires: never usage: SC sub 4096g/E71D7B3E created: 2006-03-31 expires: never usage: E sub 2048D/7ED39759 created: 2010-12-11 expires: never usage: S It seems like I've done the right thing: I have a key for encryption, and one for signing. It seems like my main public key is also allowed for signing too: is this right? Also, since I have two subkeys for encryption and signing, both use the same passphrase, so I don't see how it'll stop anyone who gets my encryption key being able to sign documents as me too. Have I done it right? (Also, my public key has now changed, which I guess is to be expected.) From dshaw at jabberwocky.com Sat Dec 11 20:07:52 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 11 Dec 2010 14:07:52 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D034118.6090901@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> Message-ID: On Dec 11, 2010, at 4:15 AM, Ben McGinnes wrote: > On 10/12/10 2:33 PM, David Shaw wrote: >> >> A good way to look at this is to pick what you want your primary key >> to be. The subkeys don't really matter that much, as the primary is >> the one that gathers signatures, and the one that makes (i.e. signs) >> subkeys. It's the key that establishes "identity" in the web of >> trust. The subkeys matter a lot less as it's trivial to make new >> subkeys whenever you feel the need, using whatever algorithm and >> size is favored at that point. > > Very interesting. > >> One useful model is to make a large & non-expiring primary key, and >> use it only to make subkeys. Use a subkey for signing data, and a >> (different) subkey for encryption. This has a few advantages, such >> as that you can leave this primary key offline altogether (since you >> only actually need it to make more subkeys). It's hard to >> compromise a key that isn't actually on your computer most of the >> time :) > > I think this is probably what I will do for my next key, but how do I > specify between the primary key and the signing subkey when signing > messages? Is that done with the Sign, Encrypt, Certify and > Authenticate capabilities during key creation? I'm happy to do it in > expert mode, I just want to be clear on the different options. The flags you can turn on and off in expert mode are: Sign: sign data (i.e. sign a file) Encrypt: encrypt Authenticate: prove your identity (for example, sign a challenge token presented by a server so it will let you in) You can't actually turn on or off certify (which is to sign a key - either your own or someone elses). In OpenPGP, the primary key can always certify (it may be able to encrypt/sign/authenticate as well, but the only strict requirement is that it must be able to certify). Without the ability to certify, you could never make a subkey, since subkeys are signed by the primary key. So given that all primary keys will certify, you just need to decide whether you want it to sign, encrypt, or both. The default is to certify and sign, and that is what I recommend (no expert mode needed). Once you make that primary key, you just add subkeys for whatever capabilities you desire. Again, the defaults are recommended (they are correct for virtually everyone). I'd add a sign-only subkey and an encrypt-only subkey. GnuPG will automatically use the subkey for signing over the primary key for signing. David From ben at adversary.org Sat Dec 11 20:55:25 2010 From: ben at adversary.org (Ben McGinnes) Date: Sun, 12 Dec 2010 06:55:25 +1100 Subject: multiple subkeys and key transition In-Reply-To: References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> Message-ID: <4D03D72D.1000607@adversary.org> On 12/12/10 6:07 AM, David Shaw wrote: > > The flags you can turn on and off in expert mode are: > > Sign: sign data (i.e. sign a file) > Encrypt: encrypt > Authenticate: prove your identity (for example, sign a challenge > token presented by a server so it will let you in) Ah, this explains its use for SSH as well. Nice. > You can't actually turn on or off certify (which is to sign a key - > either your own or someone elses). In OpenPGP, the primary key can > always certify (it may be able to encrypt/sign/authenticate as well, > but the only strict requirement is that it must be able to certify). > Without the ability to certify, you could never make a subkey, since > subkeys are signed by the primary key. Cool. On a tangential note, could this be used as a basis for applying a PKI/WoT model to certification of SSL keys, rather than relying on CAs? I don't really want to hijack my own thread, but I've always been deeply suspicious of the obvious money grab of the CA system of (mainly website) SSL certificates and I think alternatives a worth exploring. > So given that all primary keys will certify, you just need to decide > whether you want it to sign, encrypt, or both. The default is to > certify and sign, and that is what I recommend (no expert mode > needed). Cool. I've already had a play around with that, but having the option of skipping it is good for those who might be worried about messing it up. > Once you make that primary key, you just add subkeys for whatever > capabilities you desire. Again, the defaults are recommended (they > are correct for virtually everyone). I'd add a sign-only subkey and > an encrypt-only subkey. GnuPG will automatically use the subkey for > signing over the primary key for signing. I assume this means that if the primary key can sign & certify, that key will still be used to sign other keys even if there is a specific signing subkey for messages and files. Right? Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Sat Dec 11 21:00:49 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 11 Dec 2010 15:00:49 -0500 Subject: Add sign key only? In-Reply-To: References: Message-ID: On Dec 11, 2010, at 11:36 AM, Chris Poole wrote: > I have been using gpg for a while now, with just one subkey for signing and > encryption. > > I decided I wanted a separate key for signing, so if I have to give away my > private key for decrypting documents, they can't use it to impersonate me too. > > Listing my keys was like this: > > pub 1024D/BAD246F9 created: 2006-03-31 expires: never usage: SC > sub 4096g/E71D7B3E created: 2006-03-31 expires: never usage: E > > So I ran `gpg --edit-key BAD246F9`, and `addkey`. I chose DSA (sign only) > 2048-bit. My keychain looks like this now: > > pub 1024D/BAD246F9 created: 2006-03-31 expires: never usage: SC > sub 4096g/E71D7B3E created: 2006-03-31 expires: never usage: E > sub 2048D/7ED39759 created: 2010-12-11 expires: never usage: S > > It seems like I've done the right thing: I have a key for encryption, and one > for signing. It seems like my main public key is also allowed for signing too: > is this right? Yes it is. You can make signatures from either your primary or your subkey. By default, GnuPG will pick the subkey. You can override this choice using "-u BAD246F9!" Note the ! exclamation mark. > Also, since I have two subkeys for encryption and signing, both use the same > passphrase, so I don't see how it'll stop anyone who gets my encryption key > being able to sign documents as me too. If you were forced to disclose your encryption key, you could give them just that particular subkey and not give them the signing subkey at all. What some people (me, among others) do in addition to this, is to remove the primary key and store it offline. That way even if it's an accidental leak of the key (rather than a compelled one), the primary key is safe. Since the primary key can be used to revoke the old subkeys and make new ones, this is a very safe way to handle keys. David From ben at adversary.org Sat Dec 11 21:06:59 2010 From: ben at adversary.org (Ben McGinnes) Date: Sun, 12 Dec 2010 07:06:59 +1100 Subject: Add sign key only? In-Reply-To: References: Message-ID: <4D03D9E3.4010604@adversary.org> On 12/12/10 7:00 AM, David Shaw wrote: > > If you were forced to disclose your encryption key, you could give > them just that particular subkey and not give them the signing > subkey at all. What some people (me, among others) do in addition > to this, is to remove the primary key and store it offline. That > way even if it's an accidental leak of the key (rather than a > compelled one), the primary key is safe. Since the primary key can > be used to revoke the old subkeys and make new ones, this is a very > safe way to handle keys. Obviously the offline storage/copy would include the subkeys and essentially be a backup of all 3, but how is the primary key removed from the two subkeys in the keyring? Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Sat Dec 11 21:16:43 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sat, 11 Dec 2010 15:16:43 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D03D72D.1000607@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> Message-ID: <4D03DC2B.7060209@grant-olson.net> On 12/11/10 2:55 PM, Ben McGinnes wrote: > > Cool. On a tangential note, could this be used as a basis for > applying a PKI/WoT model to certification of SSL keys, rather than > relying on CAs? > > I don't really want to hijack my own thread, but I've always been > deeply suspicious of the obvious money grab of the CA system of > (mainly website) SSL certificates and I think alternatives a worth > exploring. > There's the MonkeySphere project, but I don't think it's widely used... http://web.monkeysphere.info/ -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." From dshaw at jabberwocky.com Sat Dec 11 21:21:58 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 11 Dec 2010 15:21:58 -0500 Subject: multiple subkeys and key transition In-Reply-To: <4D03D72D.1000607@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> Message-ID: <0A395D87-F792-4D16-A105-6DD18670208A@jabberwocky.com> On Dec 11, 2010, at 2:55 PM, Ben McGinnes wrote: >> You can't actually turn on or off certify (which is to sign a key - >> either your own or someone elses). In OpenPGP, the primary key can >> always certify (it may be able to encrypt/sign/authenticate as well, >> but the only strict requirement is that it must be able to certify). >> Without the ability to certify, you could never make a subkey, since >> subkeys are signed by the primary key. > > Cool. On a tangential note, could this be used as a basis for > applying a PKI/WoT model to certification of SSL keys, rather than > relying on CAs? Yes indeed. See http://web.monkeysphere.info/ for a project using the WoT for both SSH and HTTPS. >> Once you make that primary key, you just add subkeys for whatever >> capabilities you desire. Again, the defaults are recommended (they >> are correct for virtually everyone). I'd add a sign-only subkey and >> an encrypt-only subkey. GnuPG will automatically use the subkey for >> signing over the primary key for signing. > > I assume this means that if the primary key can sign & certify, that > key will still be used to sign other keys even if there is a specific > signing subkey for messages and files. Right? Right. Since only the primary can certify, it will be automatically chosen whenever you try to sign another key. David From lists at chrispoole.com Sat Dec 11 21:25:46 2010 From: lists at chrispoole.com (Chris Poole) Date: Sat, 11 Dec 2010 20:25:46 +0000 Subject: Add sign key only? In-Reply-To: References: Message-ID: > If you were forced to disclose your encryption key, you could give them just that particular subkey and not give them the signing subkey at all. But isn't the likelihood that they'll get your passphrase too, so the security lies in the hope that they don't have access to the signing subkey? This seems quite likely to me... I doubt they'd let you go away and send them just the encryption/decryption key. Also, my public key has changed now to reflect this extra key, but the fingerprint remains the same. I just need to send this new key to the keyserver? I don't have to re-generate a revoke certificate, since my encryption subkey hasn't changed, right? Thanks. From ben at adversary.org Sat Dec 11 21:29:05 2010 From: ben at adversary.org (Ben McGinnes) Date: Sun, 12 Dec 2010 07:29:05 +1100 Subject: multiple subkeys and key transition In-Reply-To: <0A395D87-F792-4D16-A105-6DD18670208A@jabberwocky.com> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <0A395D87-F792-4D16-A105-6DD18670208A@jabberwocky.com> Message-ID: <4D03DF11.4080407@adversary.org> On 12/12/10 7:21 AM, David Shaw wrote: > On Dec 11, 2010, at 2:55 PM, Ben McGinnes wrote: >> >> Cool. On a tangential note, could this be used as a basis for >> applying a PKI/WoT model to certification of SSL keys, rather than >> relying on CAs? > > Yes indeed. See http://web.monkeysphere.info/ for a project using > the WoT for both SSH and HTTPS. Awesome, I'm definitely going to have to take a look at this. Grant, thanks for mentioning it too. :) >> I assume this means that if the primary key can sign & certify, that >> key will still be used to sign other keys even if there is a specific >> signing subkey for messages and files. Right? > > Right. Since only the primary can certify, it will be automatically > chosen whenever you try to sign another key. Cool, I'm glad I'm on the right path. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Sat Dec 11 21:57:00 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 11 Dec 2010 15:57:00 -0500 Subject: Add sign key only? In-Reply-To: References: Message-ID: <2C1A9F3D-8E89-4265-AEB4-7D68479C5E9B@jabberwocky.com> On Dec 11, 2010, at 3:25 PM, Chris Poole wrote: >> If you were forced to disclose your encryption key, you could give them just that particular subkey and not give them the signing subkey at all. > > But isn't the likelihood that they'll get your passphrase too, so the > security lies in the hope that they don't have access to the signing > subkey? This seems quite likely to me... I doubt they'd let you go > away and send them just the encryption/decryption key. It depends on what they ask for. Without getting into legal issues, it's foolish to hand over more than is requested (or demanded). If they ask for the decryption key, I certainly wouldn't send them the signing key. Why would I? They didn't ask for it. If they ask for everything, then it's a different story. Plus, you can change the passphrase on the encryption key (or just remove the passphrase altogether) before you send it to them. There is no need to give them your passphrase unless, again, they are demanding it. > Also, my public key has changed now to reflect this extra key, but the > fingerprint remains the same. I just need to send this new key to the > keyserver? I don't have to re-generate a revoke certificate, since my > encryption subkey hasn't changed, right? Just send it to the keyserver, and you'll be fine. The revoke certificate applies to the key as a whole, so it doesn't matter what you do with subkeys. Whatever happens with subkeys, the revoke certificate will work. David From dshaw at jabberwocky.com Sat Dec 11 22:03:22 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 11 Dec 2010 16:03:22 -0500 Subject: Add sign key only? In-Reply-To: <4D03D9E3.4010604@adversary.org> References: <4D03D9E3.4010604@adversary.org> Message-ID: On Dec 11, 2010, at 3:06 PM, Ben McGinnes wrote: > On 12/12/10 7:00 AM, David Shaw wrote: >> >> If you were forced to disclose your encryption key, you could give >> them just that particular subkey and not give them the signing >> subkey at all. What some people (me, among others) do in addition >> to this, is to remove the primary key and store it offline. That >> way even if it's an accidental leak of the key (rather than a >> compelled one), the primary key is safe. Since the primary key can >> be used to revoke the old subkeys and make new ones, this is a very >> safe way to handle keys. > > Obviously the offline storage/copy would include the subkeys and > essentially be a backup of all 3, but how is the primary key removed > from the two subkeys in the keyring? GPG has an option to create a special key like this. Basically, after you make your backup copy, run: gpg --export-secret-subkeys (thekey) > my-subkeys-only.gpg Then delete the real secret key (make sure you have a backup!): gpg --delete-secret-key (thekey) And import the special no-primary-key version: gpg --import my-subkeys-only.gpg The key will then work just like any other key, except that it can't sign other keys, and it can't make more subkeys (since you need the primary to do that). The only visible difference is a "#" sign after the "sec" when you --list-secret-keys. If your subkeys are compromised, or you need a new subkey, or want to sign someone elses key, you bring back your backed up copy of the full key, do what you need to do, and then go back to the no-primary-key version. David From kgo at grant-olson.net Sat Dec 11 21:42:15 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sat, 11 Dec 2010 15:42:15 -0500 Subject: Add sign key only? In-Reply-To: References: Message-ID: <4D03E227.1060306@grant-olson.net> On 12/11/10 3:25 PM, Chris Poole wrote: >> If you were forced to disclose your encryption key, you could give them just that particular subkey and not give them the signing subkey at all. > > But isn't the likelihood that they'll get your passphrase too, so the > security lies in the hope that they don't have access to the signing > subkey? This seems quite likely to me... I doubt they'd let you go > away and send them just the encryption/decryption key. > If you're voluntarily handing the key over to the authorities because of a court order or something, you could delete the signing key, change the passphrase, run export-secret-subkeys, and they'll still get everything they want. Having a seperate encryption key probably doesn't help with a malicious attacker, or someone who's forcing you to hand over the key with a rubber hose. -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." From ben at adversary.org Sat Dec 11 22:42:27 2010 From: ben at adversary.org (Ben McGinnes) Date: Sun, 12 Dec 2010 08:42:27 +1100 Subject: Add sign key only? In-Reply-To: References: <4D03D9E3.4010604@adversary.org> Message-ID: <4D03F043.9070003@adversary.org> On 12/12/10 8:03 AM, David Shaw wrote: > > GPG has an option to create a special key like this. Basically, > after you make your backup copy, run: > > gpg --export-secret-subkeys (thekey) > my-subkeys-only.gpg > > Then delete the real secret key (make sure you have a backup!): > > gpg --delete-secret-key (thekey) > > And import the special no-primary-key version: > > gpg --import my-subkeys-only.gpg Awesome, thanks. > The key will then work just like any other key, except that it can't > sign other keys, and it can't make more subkeys (since you need the > primary to do that). The only visible difference is a "#" sign > after the "sec" when you --list-secret-keys. Cool. What difference (if any) does this make to the generation/export of the public key? And, more to the point, is it best to provide a public key block generated without the presence of the primary key or not? > If your subkeys are compromised, or you need a new subkey, or want > to sign someone elses key, you bring back your backed up copy of the > full key, do what you need to do, and then go back to the > no-primary-key version. Cool. Now that I think about it, anyone needing to check a signature one added to their key would need a public key that included data from the primary key. Did I just answer my own question? Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Sat Dec 11 22:51:56 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 11 Dec 2010 16:51:56 -0500 Subject: Add sign key only? In-Reply-To: <4D03F043.9070003@adversary.org> References: <4D03D9E3.4010604@adversary.org> <4D03F043.9070003@adversary.org> Message-ID: On Dec 11, 2010, at 4:42 PM, Ben McGinnes wrote: > On 12/12/10 8:03 AM, David Shaw wrote: >> >> GPG has an option to create a special key like this. Basically, >> after you make your backup copy, run: >> >> gpg --export-secret-subkeys (thekey) > my-subkeys-only.gpg >> >> Then delete the real secret key (make sure you have a backup!): >> >> gpg --delete-secret-key (thekey) >> >> And import the special no-primary-key version: >> >> gpg --import my-subkeys-only.gpg > > Awesome, thanks. > >> The key will then work just like any other key, except that it can't >> sign other keys, and it can't make more subkeys (since you need the >> primary to do that). The only visible difference is a "#" sign >> after the "sec" when you --list-secret-keys. > > Cool. What difference (if any) does this make to the > generation/export of the public key? And, more to the point, is it > best to provide a public key block generated without the presence of > the primary key or not? No difference. The public key is completely separate from the private key in this regard, so it makes no difference if the primary key is present or not. >> If your subkeys are compromised, or you need a new subkey, or want >> to sign someone elses key, you bring back your backed up copy of the >> full key, do what you need to do, and then go back to the >> no-primary-key version. > > Cool. Now that I think about it, anyone needing to check a signature > one added to their key would need a public key that included data from > the primary key. Did I just answer my own question? They'd need the public half of the primary key, but that's part of your public key. The --export-secret-subkeys trick doesn't touch the public key (no point - it's public), so anyone who wants to check a key signature can do that. David From mailinglisten at hauke-laging.de Sat Dec 11 22:55:35 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 11 Dec 2010 22:55:35 +0100 Subject: Add sign key only? In-Reply-To: References: Message-ID: <201012112255.41720.mailinglisten@hauke-laging.de> Am Samstag 11 Dezember 2010 17:36:46 schrieb Chris Poole: > Also, since I have two subkeys for encryption and signing, both use the > same passphrase, so I don't see how it'll stop anyone who gets my > encryption key being able to sign documents as me too. 1) Make a backup of the public (--export) and then of all secret keys (-- export-secret-keys). 2) Delete the signing subkey. 3) Change the passphrase (--edit-key ...; passwd) 4) Export the secret subkey (the one for encryption): --export-secret-subkeys 5) Delete the key and import the backup. Now you have a file with the key you may be forced to give away. This file is passphrase protected but with a different passphrase. Depending on the scenario it may not be neccessary to give away your private key but be enough to give away the symmetric keys for the respective files. See --show-session-key. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From ben at adversary.org Sat Dec 11 22:59:43 2010 From: ben at adversary.org (Ben McGinnes) Date: Sun, 12 Dec 2010 08:59:43 +1100 Subject: Add sign key only? In-Reply-To: References: <4D03D9E3.4010604@adversary.org> <4D03F043.9070003@adversary.org> Message-ID: <4D03F44F.40100@adversary.org> On 12/12/10 8:51 AM, David Shaw wrote: > On Dec 11, 2010, at 4:42 PM, Ben McGinnes wrote: >> >> Cool. What difference (if any) does this make to the >> generation/export of the public key? And, more to the point, is it >> best to provide a public key block generated without the presence of >> the primary key or not? > > No difference. The public key is completely separate from the > private key in this regard, so it makes no difference if the primary > key is present or not. Makes sense. >> Cool. Now that I think about it, anyone needing to check a signature >> one added to their key would need a public key that included data from >> the primary key. Did I just answer my own question? > > They'd need the public half of the primary key, but that's part of > your public key. The --export-secret-subkeys trick doesn't touch > the public key (no point - it's public), so anyone who wants to > check a key signature can do that. Excellent. I think that between this and the key transition thread, all my questions have been answered. :) Thanks very much and also to everyone who dived into the other thread. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From expires2010 at ymail.com Sun Dec 12 00:22:05 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 11 Dec 2010 23:22:05 +0000 Subject: multiple subkeys and key transition In-Reply-To: <4D03D72D.1000607@adversary.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> Message-ID: <69357333.20101211232205@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 11 December 2010 at 7:55:25 PM, in , Ben McGinnes wrote: > I don't really want to hijack my own thread, but I've > always been deeply suspicious of the obvious money grab > of the CA system of (mainly website) SSL certificates > and I think alternatives a worth exploring. A question on the subject of SSL/TLS certificates and HTTPS: often there is no user requirement to "authenticate" the identity of the server, but rather a simple requirement to prevent snooping; why does this need a certificate? - -- Best regards MFPA mailto:expires2010 at ymail.com Versifiers write poems for it. -----BEGIN PGP SIGNATURE----- iQCVAwUBTQQHs6ipC46tDG5pAQqsMAQAr3tjhxAlkb9nwfoKlsPOD0HW5VKLo2y8 MV4MHNHAkyE+8d3ImvJY+bYuyQ8VB+NZNmOQ5ukPxbHypNCBwC+H99BoOnLCIqFt N9HiH1DE9iGwjkyXkOY7FiS2w+AcHrJ9oc1XPbgUMzlPSiKfgxUC2lf7Noq4E1DA Ii7jAEZV6YU= =KMe5 -----END PGP SIGNATURE----- From ben at adversary.org Sun Dec 12 00:36:47 2010 From: ben at adversary.org (Ben McGinnes) Date: Sun, 12 Dec 2010 10:36:47 +1100 Subject: multiple subkeys and key transition In-Reply-To: <69357333.20101211232205@my_localhost> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> Message-ID: <4D040B0F.7080009@adversary.org> On 12/12/10 10:22 AM, MFPA wrote: > On Saturday 11 December 2010 at 7:55:25 PM, in > , Ben McGinnes wrote: > >> I don't really want to hijack my own thread, but I've >> always been deeply suspicious of the obvious money grab >> of the CA system of (mainly website) SSL certificates >> and I think alternatives a worth exploring. > > A question on the subject of SSL/TLS certificates and HTTPS: often > there is no user requirement to "authenticate" the identity of the > server, but rather a simple requirement to prevent snooping; why does > this need a certificate? SSL Certificates have nothing to do with the encryption or security and everything to do with a third party confirmation that the site is owned and operated by the organisation that it says it is. The CAs have managed to carve a nice little niche for themselves by preying on the fears of people who don't understand this and have made that a de-facto standard business practice. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun Dec 12 00:49:23 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 11 Dec 2010 18:49:23 -0500 Subject: multiple subkeys and key transition In-Reply-To: <69357333.20101211232205@my_localhost> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> Message-ID: <4D040E03.1020404@fifthhorseman.net> On 12/11/2010 06:22 PM, MFPA wrote: > A question on the subject of SSL/TLS certificates and HTTPS: often > there is no user requirement to "authenticate" the identity of the > server, but rather a simple requirement to prevent snooping; why does > this need a certificate? "prevent snooping" means "only me and the remote server i'm connected to has access to the communication". if you don't know who the remote server actually *is*, you cannot prevent snooping by a man-in-the-middle. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From expires2010 at ymail.com Sun Dec 12 03:14:07 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 12 Dec 2010 02:14:07 +0000 Subject: multiple subkeys and key transition In-Reply-To: <4D040E03.1020404@fifthhorseman.net> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> <4D040E03.1020404@fifthhorseman.net> Message-ID: <184690999.20101212021407@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 11 December 2010 at 11:49:23 PM, in , Daniel Kahn Gillmor wrote: > On 12/11/2010 06:22 PM, MFPA wrote: >> A question on the subject of SSL/TLS certificates and >> HTTPS: often there is no user requirement to >> "authenticate" the identity of the server, but rather >> a simple requirement to prevent snooping; why does >> this need a certificate? > "prevent snooping" means "only me and the remote server > i'm connected to has access to the communication". > if you don't know who the remote server actually *is*, > you cannot prevent snooping by a man-in-the-middle. That's a fair point; it depends on the threat model. RFC 5246 says the authentication is optional, but that completely anonymous connections only provide protection against passive eavesdropping, and server authentication is required where active man-in-the-middle attacks are a concern. But couldn't a man-in-the-middle server authenticate by presenting the user's browser with an acceptable certificate signed by a "trusted" CA? And is a self-signed certificate any more or any less secure in this scenario? - -- Best regards MFPA mailto:expires2010 at ymail.com Was time invented by an Irishman named O'Clock? -----BEGIN PGP SIGNATURE----- iQCVAwUBTQQv/KipC46tDG5pAQpW0AP/bAu1BH4NQMa95FaZ89A2kB2gdE4koxmj xhKTdTLwnW/PHLPch1vCk6YAPkZxlxAr1wrTi7Mp/9zZWJ5HDi/IZqMnEKyCB7nX GVe/zuVzd1U2HjIK9IvTzko7UIek9YSNmKE94ejz5Bo/c/1AXZ32xgrZ0w97US6k LdhIQd2Np+Q= =RAF9 -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun Dec 12 03:15:50 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 11 Dec 2010 21:15:50 -0500 Subject: multiple subkeys and key transition In-Reply-To: <69357333.20101211232205@my_localhost> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> Message-ID: <4D043056.40600@sixdemonbag.org> On 12/11/2010 6:22 PM, MFPA wrote: > A question on the subject of SSL/TLS certificates and HTTPS: often > there is no user requirement to "authenticate" the identity of the > server, but rather a simple requirement to prevent snooping; why does > this need a certificate? Otherwise the snooper could just use a MitM and you'd be none the wiser. When you visit Amazon.com, both you and Amazon need some way to ensure you're talking to the real McCoy. Amazon authenticates you by having you provide a username and password. You authenticate Amazon by checking their SSL cert and seeing that it was issued by a trusted authority. If you didn't check the SSL cert, I could provide a self-signed SSL cert, have you accept it, and then do a MitM on your connection. Next thing you know, you've paid for all my Christmas shopping... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From rjh at sixdemonbag.org Sun Dec 12 03:21:43 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 11 Dec 2010 21:21:43 -0500 Subject: multiple subkeys and key transition In-Reply-To: <184690999.20101212021407@my_localhost> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> <4D040E03.1020404@fifthhorseman.net> <184690999.20101212021407@my_localhost> Message-ID: <4D0431B7.3090801@sixdemonbag.org> On 12/11/2010 9:14 PM, MFPA wrote: > But couldn't a man-in-the-middle server authenticate by presenting the > user's browser with an acceptable certificate signed by a "trusted" > CA? And is a self-signed certificate any more or any less secure in > this scenario? The entire idea of a "self-signed certificate" is kind of a non sequitur. The question isn't whether a certificate is self-signed or signed by Verisign. The question is whether the certificate is signed by someone you trust. If you know the certificate issuer, you've verified the certificate fingerprint with the web site owner, etc., then you can use a self-signed certificate with great confidence. With respect to your hypothetical scenario, sure. Getting marks to trust people who plan on betraying that trust is a ploy that's about as old as the hills. I think Samson might have something to say about Delilah, and Holofernes' troops might have something to say about Judith, just to name two instances... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From faramir.cl at gmail.com Sun Dec 12 03:36:27 2010 From: faramir.cl at gmail.com (Faramir) Date: Sat, 11 Dec 2010 23:36:27 -0300 Subject: Add sign key only? In-Reply-To: <4D03D9E3.4010604@adversary.org> References: <4D03D9E3.4010604@adversary.org> Message-ID: <4D04352B.3000400@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 11-12-2010 17:06, Ben McGinnes escribi?: > On 12/12/10 7:00 AM, David Shaw wrote: >> >> If you were forced to disclose your encryption key, you could give >> them just that particular subkey and not give them the signing >> subkey at all. What some people (me, among others) do in addition >> to this, is to remove the primary key and store it offline. That ... > Obviously the offline storage/copy would include the subkeys and > essentially be a backup of all 3, but how is the primary key removed > from the two subkeys in the keyring? Take a look at http://tjl73.altervista.org/secure_keygen/en/index.html Since your keys have already been generated, I think you can skip part of the instructions. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNBDUrAAoJEMV4f6PvczxAlLUH/1iznE+mcHsZsDg06uIoISak oOWMCSBeWdFpAE1dqf6h3nK/amNiLKtUSvD13sdhaVYh9KJoWiwpTSkIuC5ixMr/ y5IxU63RPoLE0rxibmcPBV+/bn4ZDytx7drXlwd1hKtDTDp+QoVnPpT/nMvtmzyY wlDIjJ8rOJ3pMQjZfwD0T0RUIzZNjQI6MTjQA102QGzRLm8XNJWL092UPCVuserR mldCrZava3RIPTuZYYzMKW2CSCVdGCGVfHJath8SuXdIIV4wVp+3aoovDpnb/+EA YX+GBDX5gwXvq6nnbG/Skqx/fDz5oMGXIE6Ls+hG43Lzcf9hB7KVSbu8m5Pu5V4= =BnU5 -----END PGP SIGNATURE----- From faramir.cl at gmail.com Sun Dec 12 03:53:20 2010 From: faramir.cl at gmail.com (Faramir) Date: Sat, 11 Dec 2010 23:53:20 -0300 Subject: multiple subkeys and key transition In-Reply-To: <184690999.20101212021407@my_localhost> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> <4D040E03.1020404@fifthhorseman.net> <184690999.20101212021407@my_localhost> Message-ID: <4D043920.2070402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 11-12-2010 23:14, MFPA escribi?: > Hi ... > But couldn't a man-in-the-middle server authenticate by presenting the > user's browser with an acceptable certificate signed by a "trusted" > CA? And is a self-signed certificate any more or any less secure in > this scenario? Yes, that's why it is important CAs don't sign things they should not sign. Selfsigned certificates make things worst, because now you have to worry about flawed CAs and also you need to check the legitimate but unknown (to you) certificate used in the site... Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNBDkgAAoJEMV4f6PvczxAgkkIAIRXO3lC6EAZjNw4wF9kHyHC ULwXPLczITOZMDWY27jcs6XyZfbSFr9AJ+H1UugaXrJlVvjrvOH1NcLpm5E7vLuh eAfc8AzlOkdGWRWmKDLNzQ8Q+69VDj6aQUTfUHCc71l8Zau+SKkzeXOHKBDlMEN0 ZQQwkrKftl6LK4x9IWI/18z0rJseKECjAk2fYkrUKwivvvJukvDK0I4EANQHTfWP 9UOrFGGtklUtKbYs87EP9F0KAudw3ujiPpRtPCO/II169YfkjjCzUUXC9ldtoeO9 YWyzsPpUvRh0L2ptKQfVBikZrDn7VB8r/vHSFeZILQCWl5TZln7+HP4QC1BRdPo= =zjGl -----END PGP SIGNATURE----- From expires2010 at ymail.com Sun Dec 12 04:28:21 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 12 Dec 2010 03:28:21 +0000 Subject: multiple subkeys and key transition In-Reply-To: <4D043056.40600@sixdemonbag.org> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> <4D043056.40600@sixdemonbag.org> Message-ID: <2110159726.20101212032821@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 12 December 2010 at 2:15:50 AM, in , Robert J. Hansen wrote: > On 12/11/2010 6:22 PM, MFPA wrote: >> A question on the subject of SSL/TLS certificates and HTTPS: often >> there is no user requirement to "authenticate" the identity of the >> server, but rather a simple requirement to prevent snooping; why does >> this need a certificate? > Otherwise the snooper could just use a MitM and you'd > be none the wiser. I'd be no worse off than if the connection had just been plain vanilla http. > When you visit Amazon.com, both you and Amazon need > some way to ensure you're talking to the real McCoy. > Amazon authenticates you by having you provide a > username and password. In the instance that I'm only browsing around on Amazon and not actually ordering any books at the moment, I would not sign up and create a username/password. But I might not wish for my ISP to log all the books I looked at in case the government wanted to know... > You authenticate Amazon by > checking their SSL cert and seeing that it was issued > by a trusted authority. Or do I just notice the padlock icon and the yellow addressbar indicating an encrypted connection? > If you didn't check the SSL cert, I could provide a > self-signed SSL cert, have you accept it, and then do a > MitM on your connection. Since my browser would display a warning about untrusted certificates, I'd be likely to notice that. If you provided a cert signed by a CA that my browser trusts, and that matched your server details so no warning was displayed, I probably wouldn't notice. (Of course, there are browser add-ons to detect changes of certificate on previously-visited sites...) > Next thing you know, you've > paid for all my Christmas shopping... To me, the page where payment details are entered does not look much like an example of "no user requirement to authenticate the identity of the server, but rather a simple requirement to prevent snooping." - -- Best regards MFPA mailto:expires2010 at ymail.com Success isn't how far you got, but the distance you travelled from where you started -----BEGIN PGP SIGNATURE----- iQCVAwUBTQRBXqipC46tDG5pAQq/UgP+Mq8u/+5KCco37haU1/S8tAF8U2lMr3RK Rr9fFBwew8FiPYbkVydKa0DE3lWDGGQjCzGlGWVfArg/Xibr6qKQxVFwI+EF9f2T 9s4dl4mR1ecIQHb5WxHjncQRENGZE/76ai55tDPz9mMryu2CuCW+OtoY2QmOYHDo 7lq5a56bNGI= =F+JO -----END PGP SIGNATURE----- From expires2010 at ymail.com Sun Dec 12 04:39:51 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 12 Dec 2010 03:39:51 +0000 Subject: multiple subkeys and key transition In-Reply-To: <4D043920.2070402@gmail.com> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> <4D040E03.1020404@fifthhorseman.net> <184690999.20101212021407@my_localhost> <4D043920.2070402@gmail.com> Message-ID: <1839985745.20101212033951@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 12 December 2010 at 2:53:20 AM, in , Faramir wrote: > Yes, that's why it is important CAs don't sign things > they should not sign. And maybe, at times, it's important to governments or criminals that CAs *do* sign things they shouldn't. - -- Best regards MFPA mailto:expires2010 at ymail.com Ballerinas are always on their toes. We need taller ballerinas! -----BEGIN PGP SIGNATURE----- iQCVAwUBTQRECqipC46tDG5pAQpBiAP/cTGiA2ZBHRkWXHd7q8Hoqxz2C35fBqZo 4WYTeYAizUY5/BsiZuD7hSl7MVxPBH1GWYfeQVkDFS12tiPu0IJ8/Qf3Zzs/H/gh u2i4O2/7gGT65JiruLw3WzWUMu6czE+84Hg3GH4w4CAAvNX2+fxxn1PBtsan0tJh 4fIJ7ceWkYI= =eSjb -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun Dec 12 05:25:39 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 11 Dec 2010 23:25:39 -0500 Subject: multiple subkeys and key transition In-Reply-To: <2110159726.20101212032821@my_localhost> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> <4D043056.40600@sixdemonbag.org> <2110159726.20101212032821@my_localhost> Message-ID: <4D044EC3.5000403@sixdemonbag.org> On 12/11/2010 10:28 PM, MFPA wrote: >> You authenticate Amazon by >> checking their SSL cert and seeing that it was issued >> by a trusted authority. > > Or do I just notice the padlock icon and the yellow addressbar > indicating an encrypted connection? The two are generally synonymous. Whether a user *should* trust the same CAs as their browser vendor is a very good question -- however, the fact is the overwhelming majority of users *do*. If the browser says "a trusted CA certifies this site is for real," the user is going to believe it. > To me, the page where payment details are entered does not look much > like an example of "no user requirement to authenticate the identity > of the server, but rather a simple requirement to prevent snooping." Can't please everybody. If it was an involved process the vast majority of users wouldn't bother. Instead, it's just a "check for a padlock and a yellow address bar." -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From faramir.cl at gmail.com Sun Dec 12 05:13:26 2010 From: faramir.cl at gmail.com (Faramir) Date: Sun, 12 Dec 2010 01:13:26 -0300 Subject: multiple subkeys and key transition In-Reply-To: <1839985745.20101212033951@my_localhost> References: <4D0073DD.3020701@adversary.org> <4D00E2D8.4080406@sixdemonbag.org> <4D011983.6060905@fifthhorseman.net> <4D012039.9060506@adversary.org> <14898391-E873-488F-8211-1EA76F1BE43C@jabberwocky.com> <4D034118.6090901@adversary.org> <4D03D72D.1000607@adversary.org> <69357333.20101211232205@my_localhost> <4D040E03.1020404@fifthhorseman.net> <184690999.20101212021407@my_localhost> <4D043920.2070402@gmail.com> <1839985745.20101212033951@my_localhost> Message-ID: <4D044BE6.4070204@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 12-12-2010 0:39, MFPA escribi?: ... > , Faramir wrote: > > >> Yes, that's why it is important CAs don't sign things >> they should not sign. > > And maybe, at times, it's important to governments or criminals that > CAs *do* sign things they shouldn't. Exactly... but we don't want to make criminals happy. And about governments, sure, it's great if CAs help to fight criminals or terrorists, but, what if the government is the kind of government that send dissidents to jail instead of defeating them in elections? How can you tell government is not going to abuse its power? Not much time ago I read some criticism to... I think it was Nokia, because they sold some equipment to Iran, which gave them the capability to locate dissidents. And human rights activists blamed them for selling the equipment. But from Iran's point of view, they are a legitimate government, and they used the equipment to catch dangerous people. We could debate about it a long time, and the only thing I can say, is I'm really happy I am not a CA, so I don't have to deal with the consequences of granting or denying fake certificates (you grant them, and people is sent to a Gulag. You don't grant them, and an stadium explode and thousands of innocent people get killed). But I think we are moving off-topic here... not that I complain, but other people might. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNBEvmAAoJEMV4f6PvczxAx7AH/1MYCmvv2bspn6AS/q3pAqW5 EG0D/XOS8i3pzpbGf6eRKGMasxf85Y4CtOt6MDFNzCtCWMghZyDRSGqGpH70JuxA 7vnJuhTecWTGO+sFlvGPuMONNrOP/kLluyGTmIHlSUiv52cb8p31u570R+rFpkXx +WHHivp7wN5EVb9QQHGOUfYQ8WJjMgOnTJKp6ORvpteVtp2omghLn/oASAGdnylc N1hse5INRn/tFrnF+Tq1eZL+8s0s8HCv8zercCmfl2P1TNDjSuFNk0sUWKmWRXqW IIPvTfUGoRnPWdAuKts17ygHAfbu015yA3DkntSVZDRHelRVm0fYQZrmcEPq4U8= =tkhU -----END PGP SIGNATURE----- From david at systemoverlord.com Sun Dec 12 08:10:04 2010 From: david at systemoverlord.com (David Tomaschik) Date: Sun, 12 Dec 2010 02:10:04 -0500 Subject: Best Practices In-Reply-To: <4D03A5CE.2080509@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> Message-ID: My thoughts at this point are to generate a new RSA4k certify-only key, generate subkeys (probably RSA2k) for each encrypt and sign, move the primary key offline (stored in 2 secure places) and then use the subkeys for daily operations. This seems to be the method most people who are fairly concerned with security are using. I may place my keys on a smart card at some point, but I haven't decided on that yet. (I'm aware that there are some attacks I'm vulnerable to by not using one, but the offline certify/primary key should help mitigate some of that.) In my gpg.conf, I have (other than keyserver/no-greeting/etc. settings): personal-digest-preferences SHA512 cert-digest-algo SHA512 Are there any other settings (or changes to these) that would be considered more "forward looking"? I appreciate everyone's help on this -- trying to make sure I get it "right". David On Sat, Dec 11, 2010 at 11:24 AM, Robert J. Hansen wrote: > On 12/10/2010 9:16 PM, David Tomaschik wrote: > > Are there any disadvantages to distinct signature & encryption keys? > > None that I've found. > > > Is the weakness in the hash used to sign the key internally, or just when > > it is used to sign data? I guess that's the part that eludes me. > > Err -- "yes." > > A certificate is just a block of key material plus some associated data. > SHA-1 is used internally by the certificate to sign some parts of the > data, as well as for computing a key fingerprint. You can to some > extent mitigate how much SHA-1 gets used, but you can't remove it > completely. > > You can also choose to use SHA-1 to sign messages and files. Here, you > can remove it completely in favor of some other hash algorithm. > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- David Tomaschik, RHCE, LPIC-1 GNU/Linux System Architect GPG: 0x david at systemoverlord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Dec 12 08:58:12 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 12 Dec 2010 02:58:12 -0500 Subject: Best Practices In-Reply-To: References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> Message-ID: <4D048094.8060101@sixdemonbag.org> On 12/12/2010 2:10 AM, David Tomaschik wrote: > In my gpg.conf, I have (other than keyserver/no-greeting/etc. settings): > personal-digest-preferences SHA512 > cert-digest-algo SHA512 > > Are there any other settings (or changes to these) that would be > considered more "forward looking"? personal-digest-prefs is probably a bit off. For instance, if for any reason SHA512 is unavailable it will degrade to SHA-1, which you probably don't want. It's generally best to include all the algorithms you'll accept, in whatever order you like. E.g.: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1 This way you have a natural degradation in hash preferences: rather than immediately degrading to SHA-1, it gives you more options to keep on using strong hashes. From laurent.jumet at skynet.be Sun Dec 12 09:34:05 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sun, 12 Dec 2010 09:34:05 +0100 Subject: Best Practices In-Reply-To: Message-ID: Hello David ! David Tomaschik wrote: > In my gpg.conf, I have (other than keyserver/no-greeting/etc. settings): > personal-digest-preferences SHA512 > cert-digest-algo SHA512 > Are there any other settings (or changes to these) that would be considered > more "forward looking"? Hello ! To set the preferences, this can help: ?????????????????????????????????????????????????????????? ? Cipher-Algos: ? Digest-Algos: ? Compress-Algos: ? ?????????????????????????????????????????????????????????? ? ? ? Z0 Uncompressed ? ? S1 IDEA ? H1 MD5 ? Z1 ZIP ? ? S2 3DES ? H2 SHA1 ? Z2 ZLIB ? ? S3 CAST5 ? H3 RIPEMD160 ? Z3 BZIP2 ? ? S4 BLOWFISH ? ? ? ? ? ? ? ? ? ? ? ? S7 AES ? ? ? ? S8 AES192 ? H8 SHA256 ? ? ? S9 AES256 ? H9 SHA384 ? ? ? S10 TWOFISH ? H10 SHA512 ? ? ? S11 CAMELLIA128 ? H11 SHA224 ? ? ? S12 CAMELLIA192 ? ? ? ? S13 CAMELLIA256 ? ? ? ?????????????????????????????????????????????????????????? Those are my settings in GPG.CONF: default-preference-list S7 S1 S10 S3 S4 S2 S9 S8 H3 H8 H9 H10 H11 H2 H1 Z1 Z3 Z2 Z0 personal-cipher-preferences S7 S1 S10 S3 S4 S2 S9 S8 personal-digest-preferences H3 H8 H9 H10 H11 H2 H1 personal-compress-preferences Z1 Z3 Z2 Z0 As you can see, you can replace the whole name by its tag. When you change the settings, you must edit and save your public key and reload it on the servers; otherwise those changes will not work as they will stay internal in your system. -- Laurent Jumet KeyID: 0xCFAF704C From dkg at fifthhorseman.net Sun Dec 12 16:23:19 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 12 Dec 2010 10:23:19 -0500 Subject: Best Practices In-Reply-To: <4D03A5CE.2080509@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> Message-ID: <4D04E8E7.90509@fifthhorseman.net> On 12/11/2010 11:24 AM, Robert J. Hansen wrote: > A certificate is just a block of key material plus some associated data. > SHA-1 is used internally by the certificate to sign some parts of the > data Really? i've got several certifications over my key's user IDs that i'm pretty sure don't use SHA1 at all. i note that gpg seems incapable of certifying subkeys using anything other than SHA1, but that doesn't seem required by the standard. What part of OpenPGP certificates require SHA-1? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Dec 12 17:21:13 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 12 Dec 2010 11:21:13 -0500 Subject: Best Practices In-Reply-To: <4D04E8E7.90509@fifthhorseman.net> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> Message-ID: <4D04F679.3060301@sixdemonbag.org> On 12/12/2010 10:23 AM, Daniel Kahn Gillmor wrote: > What part of OpenPGP certificates require SHA-1? ... At first blush, V4 certificate checksums, symmetrically encrypted integrity protected data packets, the MDC system in general, certificate fingerprints, etc. I just grepped through the RFC looking for any hardcoded SHA-1; David is probably a much better reference than I am on this. Probably the most annoying -- to me, at least -- is the fingerprint requirement. If a preimage collision is discovered in SHA-1 then it's all over. I can take your signature on my enemy's key, graft it onto my own impersonator of my enemy's key, and then get others to believe it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From rjh at sixdemonbag.org Sun Dec 12 17:22:48 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 12 Dec 2010 11:22:48 -0500 Subject: Best Practices In-Reply-To: References: Message-ID: <4D04F6D8.1070905@sixdemonbag.org> On 12/12/2010 3:34 AM, Laurent Jumet wrote: > As you can see, you can replace the whole name by its tag. But why would you want to? Humans should use tags convenient for humans. Machines should use tags convenient for machines. > When you change the settings, you must edit and save your public key > and reload it on the servers; otherwise those changes will not work > as they will stay internal in your system. Not if all he's changing are the personal-*-preferences. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From ldm at gmx.at Sun Dec 12 18:10:34 2010 From: ldm at gmx.at (Markus Krainz) Date: Sun, 12 Dec 2010 18:10:34 +0100 Subject: OpenPGP card and poldi-ctrl In-Reply-To: References: Message-ID: <4D05020A.1060105@gmx.at> Hi Alphazo, thanks for this great howto. I got it working right away. Where I still have problems: The gnome-keyring (seahorse), still demands the user-password. Also I often have to unplug and replug the reader to authenticate. This works, but it is very inconvenient. Regards, Markus On 2010-11-27 08:31, wrote: > Hi Markus, > > Poldi tutorials are outdated. The new versions is configured > differently. Poldi 0.4.1 works flawlessly with my Cryptostick token > (OpenPGP card V2) for PAM authentication > > I used the default /etc/poldi/poldi.conf > /auth-method localdb > log-file /var/log/poldi.log > debug > scdaemon-program /usr/bin/scdaemon > / > Added one line to /etc/poldi/localdb/users with CryptoStick's serial > number (get it from gpg --card status | grep Application) : > /D1234678912346789123467891234678 alpha/ > > And they dumped the public key from my Cryptostick into poldi local db: > /sudo poldi-ctrl -k > > /etc/poldi/localdb/keys//D1234678912346789123467891234678 > > The rest is pretty standard as it requires to modify pam configuration > files. I keep the possibility to log in with password for the moment > so I just added in /etc/pam.d/gdm /etc/pam.d/login > /etc/pam.d/sudo /etc/pam.d/gnome-screensaver: > /auth sufficient pam_poldi.so/ > > That's it really! > > One more thing, for better stability I recommend to disable opensc > daemon when using Cryptostick. I had it enabled because I was playing > with a PKCSC#11 token and got all sort of problems. I also had > opensc-pkcs11.so module loaded in Thunderbird that had a tendency to > restart opensc daemon also. So best is to disable it too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alphazo at gmail.com Sun Dec 12 19:20:02 2010 From: alphazo at gmail.com (Alphazo) Date: Sun, 12 Dec 2010 19:20:02 +0100 Subject: OpenPGP card and poldi-ctrl In-Reply-To: <4D05020A.1060105@gmx.at> References: <4D05020A.1060105@gmx.at> Message-ID: Hi Markus, What you are seeing with gnome-keyring is normal. The database of gnome-keyring is encrypted with a password that is usually the same as the login password. Therefore when you login with password, your gnome-keyring database gets automatically decrypted and you can access your WPA protected Wifi (if using network-manager) network without entering any additional password. Now when you login with an OpenPGP card, you can no longer decrypt the gnome-keyring database. I haven't found a practical way to avoid that. One alternative could be to use an encrypted space (truecrypt/encfs...) to store the gnome-keyring database and other home related information and therefore get rid of the gnome-keyring password. But you will still have to enter a password to unlock this encrypted space ;( Alphazo On Sun, Dec 12, 2010 at 6:10 PM, Markus Krainz wrote: > Hi Alphazo, > > thanks for this great howto. I got it working right away. > Where I still have problems: The gnome-keyring (seahorse), still demands > the user-password. Also I often have to unplug and replug the reader to > authenticate. This works, but it is very inconvenient. > > Regards, > Markus > > > > On 2010-11-27 08:31, wrote: > > Hi Markus, > > Poldi tutorials are outdated. The new versions is configured > differently. Poldi 0.4.1 works flawlessly with my Cryptostick token (OpenPGP > card V2) for PAM authentication > > I used the default /etc/poldi/poldi.conf > *auth-method localdb > log-file /var/log/poldi.log > debug > scdaemon-program /usr/bin/scdaemon > * > Added one line to /etc/poldi/localdb/users with CryptoStick's serial number > (get it from gpg --card status | grep Application) : > * D1234678912346789123467891234678 alpha* > > And they dumped the public key from my Cryptostick into poldi local db: > *sudo poldi-ctrl -k > /etc/poldi/localdb/keys/* > D1234678912346789123467891234678 > > The rest is pretty standard as it requires to modify pam configuration > files. I keep the possibility to log in with password for the moment so I > just added in /etc/pam.d/gdm /etc/pam.d/login /etc/pam.d/sudo > /etc/pam.d/gnome-screensaver: > *auth sufficient pam_poldi.so* > > That's it really! > > One more thing, for better stability I recommend to disable opensc daemon > when using Cryptostick. I had it enabled because I was playing with a > PKCSC#11 token and got all sort of problems. I also had opensc-pkcs11.so > module loaded in Thunderbird that had a tendency to restart opensc daemon > also. So best is to disable it too. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alphazo at gmail.com Sun Dec 12 19:24:16 2010 From: alphazo at gmail.com (Alphazo) Date: Sun, 12 Dec 2010 19:24:16 +0100 Subject: OpenPGP card and poldi-ctrl In-Reply-To: <4D05020A.1060105@gmx.at> References: <4D05020A.1060105@gmx.at> Message-ID: Also regarding the unplug/replug issue. Please make sure that pcsc daemon is not running and openct is not installed. I also had to uninstall libpkcs11.so in Thunderbird (used for PKCS#11 token). Please also disable gnupg agent as it can interact with the OpenPGP card. On Sun, Dec 12, 2010 at 6:10 PM, Markus Krainz wrote: > Hi Alphazo, > > thanks for this great howto. I got it working right away. > Where I still have problems: The gnome-keyring (seahorse), still demands > the user-password. Also I often have to unplug and replug the reader to > authenticate. This works, but it is very inconvenient. > > Regards, > Markus > > > > On 2010-11-27 08:31, wrote: > > Hi Markus, > > Poldi tutorials are outdated. The new versions is configured > differently. Poldi 0.4.1 works flawlessly with my Cryptostick token (OpenPGP > card V2) for PAM authentication > > I used the default /etc/poldi/poldi.conf > *auth-method localdb > log-file /var/log/poldi.log > debug > scdaemon-program /usr/bin/scdaemon > * > Added one line to /etc/poldi/localdb/users with CryptoStick's serial number > (get it from gpg --card status | grep Application) : > * D1234678912346789123467891234678 alpha* > > And they dumped the public key from my Cryptostick into poldi local db: > *sudo poldi-ctrl -k > /etc/poldi/localdb/keys/* > D1234678912346789123467891234678 > > The rest is pretty standard as it requires to modify pam configuration > files. I keep the possibility to log in with password for the moment so I > just added in /etc/pam.d/gdm /etc/pam.d/login /etc/pam.d/sudo > /etc/pam.d/gnome-screensaver: > *auth sufficient pam_poldi.so* > > That's it really! > > One more thing, for better stability I recommend to disable opensc daemon > when using Cryptostick. I had it enabled because I was playing with a > PKCSC#11 token and got all sort of problems. I also had opensc-pkcs11.so > module loaded in Thunderbird that had a tendency to restart opensc daemon > also. So best is to disable it too. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sun Dec 12 21:03:42 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 12 Dec 2010 15:03:42 -0500 Subject: Best Practices In-Reply-To: <4D04F679.3060301@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> Message-ID: <4D052A9E.3070001@fifthhorseman.net> On 12/12/2010 11:21 AM, Robert J. Hansen wrote: > On 12/12/2010 10:23 AM, Daniel Kahn Gillmor wrote: >> What part of OpenPGP certificates require SHA-1? > > ... At first blush, V4 certificate checksums, what do you mean by "V4 certificate checksums"? > symmetrically encrypted > integrity protected data packets, the MDC system in general These are not part of the OpenPGP certificate format. > certificate fingerprints, etc. yeah, this is serious, but it's not embedded in the certificate. if we were to come up with a new fingerprint format, it would not invalidate any existing certificates -- it would just change how we refer to them. > Probably the most annoying -- to me, at least -- is the fingerprint > requirement. If a preimage collision is discovered in SHA-1 then it's > all over. I can take your signature on my enemy's key, graft it onto my > own impersonator of my enemy's key, and then get others to believe it. agreed. but this is not part of the certificate format. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Dec 12 21:51:10 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 12 Dec 2010 15:51:10 -0500 Subject: Best Practices In-Reply-To: <4D052A9E.3070001@fifthhorseman.net> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D052A9E.3070001@fifthhorseman.net> Message-ID: <4D0535BE.9040207@sixdemonbag.org> On 12/12/2010 3:03 PM, Daniel Kahn Gillmor wrote: > what do you mean by "V4 certificate checksums"? Read the RFC. It's in there, and does a better job than I can do of explaining it. Section 5.5.3. > yeah, this is serious, but it's not embedded in the certificate. if we > were to come up with a new fingerprint format, it would not invalidate > any existing certificates -- it would just change how we refer to them. I am very skeptical of this claim you seem to be making, that we can just upgrade-in-place. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From lukasz.stelmach at iem.pw.edu.pl Sun Dec 12 23:21:38 2010 From: lukasz.stelmach at iem.pw.edu.pl (=?utf-8?Q?=C5=81ukasz?= Stelmach) Date: Sun, 12 Dec 2010 23:21:38 +0100 Subject: [OT] broken threading via gmane Message-ID: <8739q2ocnh.fsf%lukasz.stelmach@iem.pw.edu.pl> Hello. I've noticed that Gmane's doing something evil to message-ids in this group. I read several other groups via Gmane and this is *the only* that has such broken threading. E.g. Hank Ivy started the "Protecting IDs at a keysigning party" thread with e message <201012081420.14986.hankivy at hot.rr.com> which has been mangled at Gmane to <201012081420.14986.hankivy__6874.93589143759$1291842486$gmane$org at hot.rr.com> David Shaw's reply refers to the original non-gmane ID. Even though my MUA (Gnus) puts David's message somewhere near Hank's (they share the subject) it can't put it completely right. BTW David's message-id is mangled to. I assume it's because of some strange settings specific to this particular group. Is there anyone who could, please, fix this? PS. I send this message via Gmane with an ID: <874oaiocpp.fsf%lukasz.stelmach at iem.pw.edu.pl> -- Mi?ego dnia, ?ukasz Stelmach From david at systemoverlord.com Sun Dec 12 23:59:03 2010 From: david at systemoverlord.com (David Tomaschik) Date: Sun, 12 Dec 2010 17:59:03 -0500 Subject: [OT] broken threading via gmane In-Reply-To: <8739q2ocnh.fsf%lukasz.stelmach@iem.pw.edu.pl> References: <8739q2ocnh.fsf%lukasz.stelmach@iem.pw.edu.pl> Message-ID: My guess is that it has something to do with the fact that this list (bizarrely, IMO) uses reply to sender by default rather than reply to list. Some MUAs may mangle the Message ID in such a case (when the list email is manually specified). Just a guess. David 2010/12/12 ?ukasz Stelmach > Hello. > > I've noticed that Gmane's doing something evil to message-ids in this > group. I read several other groups via Gmane and this is *the only* that > has such broken threading. > > E.g. > > Hank Ivy started the "Protecting IDs at a keysigning party" thread with > e message > > <201012081420.14986.hankivy at hot.rr.com> > > which has been mangled at Gmane to > > <201012081420.14986.hankivy__6874.93589143759$1291842486$gmane$ > org at hot.rr.com> > > David Shaw's reply refers to the original non-gmane ID. Even though my > MUA (Gnus) puts David's message somewhere near Hank's (they share the > subject) it can't put it completely right. BTW David's message-id is > mangled to. > > I assume it's because of some strange settings specific to this > particular group. Is there anyone who could, please, fix this? > > PS. I send this message via Gmane with an ID: > <874oaiocpp.fsf%lukasz.stelmach at iem.pw.edu.pl<874oaiocpp.fsf%25lukasz.stelmach at iem.pw.edu.pl> > > > -- > Mi?ego dnia, > ?ukasz Stelmach > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- David Tomaschik, RHCE, LPIC-1 GNU/Linux System Architect GPG: 0x david at systemoverlord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at adversary.org Mon Dec 13 00:04:39 2010 From: ben at adversary.org (Ben McGinnes) Date: Mon, 13 Dec 2010 10:04:39 +1100 Subject: [OT] broken threading via gmane In-Reply-To: References: <8739q2ocnh.fsf%lukasz.stelmach@iem.pw.edu.pl> Message-ID: <4D055507.3060709@adversary.org> On 13/12/10 9:59 AM, David Tomaschik wrote: > My guess is that it has something to do with the fact that this list > (bizarrely, IMO) uses reply to sender by default rather than reply to > list. Some MUAs may mangle the Message ID in such a case (when the list > email is manually specified). This is one of the reasons I like the Reply to List option in Thunderbird. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Dec 13 00:37:36 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 12 Dec 2010 18:37:36 -0500 Subject: Best Practices In-Reply-To: <4D0535BE.9040207@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D052A9E.3070001@fifthhorseman.net> <4D0535BE.9040207@sixdemonbag.org> Message-ID: <4D055CC0.6010608@fifthhorseman.net> On 12/12/2010 03:51 PM, Robert J. Hansen wrote: > On 12/12/2010 3:03 PM, Daniel Kahn Gillmor wrote: >> what do you mean by "V4 certificate checksums"? > > Read the RFC. It's in there, and does a better job than I can do of > explaining it. Section 5.5.3. i thought that you might be referring to 5.5.3, but that is also not part of the OpenPGP certificate format. It's part of the secret key packet format, and it's not a part that is cryptographically-signed either. It looks to me like that checksum is a way to verify that you've decrypted the key properly, and it's made over material that you generated yourself. If you've retained physical control over your secret key material, this is certainly not a cryptographic concern. >> yeah, this is serious, but it's not embedded in the certificate. if we >> were to come up with a new fingerprint format, it would not invalidate >> any existing certificates -- it would just change how we refer to them. > > I am very skeptical of this claim you seem to be making, that we can > just upgrade-in-place. We can (and some of us do) use OpenPGP certificates and exchange encrypted and signed material without relying on SHA-1 already. The *fingerprint* format probably will need to change eventually (though i haven't seen any indication of preimage attacks against SHA1 yet), and the designated revoker subpacket is acknowledged to need an overhaul. But you still haven't pointed to anything within the OpenPGP *certificate* format itself that embeds SHA-1. RFC 4880 mandates SHA-1 as a "must-implement" for compliant implementations, but (aside from the rarely-used designated-revoker subpacket) it doesn't require you to actually use it anywhere in the certificates, as far as i can tell. If i'm wrong about that, i certainly hope to be made aware of it. Again, the entire reason i'm engaging in this thread is to encourage people to move to stronger cryptographic algorithms *today*. I see no good reason to wait for a new revision of the OpenPGP specification to take advantage of stronger algorithms now. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Dec 13 00:52:47 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 12 Dec 2010 18:52:47 -0500 Subject: Best Practices In-Reply-To: <4D055CC0.6010608@fifthhorseman.net> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D052A9E.3070001@fifthhorseman.net> <4D0535BE.9040207@sixdemonbag.org> <4D055CC0.6010608@fifthhorseman.net> Message-ID: <4D05604F.6000405@sixdemonbag.org> On 12/12/2010 6:37 PM, Daniel Kahn Gillmor wrote: > We can (and some of us do) use OpenPGP certificates and exchange > encrypted and signed material without relying on SHA-1 already. Not so long as you're looking up key IDs by fragments of SHA-1 hashes, you're not. > Again, the entire reason i'm engaging in this thread is to encourage > people to move to stronger cryptographic algorithms *today*. That's not the point of this thread. In fact, as near as I can tell that's *never* been the point of this thread. The original poster wanted to create an entirely new certificate in order to migrate, and my advice to him was that if he wanted to create an entirely new certificate that he should wait until the next revision, otherwise he'd likely be doing another new certificate in a year or two. I have *never* claimed that we shouldn't move away from SHA-1. Heck, I was even the one who told the original poster to use enable-dsa2 in order to get access to the stronger hash algorithms. I maintain my original point: if you're thinking of creating an entirely new certificate just in order to get access to better hash algorithms, then you are best off waiting for the new revision: otherwise, use the existing technologies. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From ben at adversary.org Mon Dec 13 01:09:52 2010 From: ben at adversary.org (Ben McGinnes) Date: Mon, 13 Dec 2010 11:09:52 +1100 Subject: Best Practices In-Reply-To: <4D05604F.6000405@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D052A9E.3070001@fifthhorseman.net> <4D0535BE.9040207@sixdemonbag.org> <4D055CC0.6010608@fifthhorseman.net> <4D05604F.6000405@sixdemonbag.org> Message-ID: <4D056450.1060000@adversary.org> On 13/12/10 10:52 AM, Robert J. Hansen wrote: > > I have *never* claimed that we shouldn't move away from SHA-1. Heck, I > was even the one who told the original poster to use enable-dsa2 in > order to get access to the stronger hash algorithms. Actually, I'm pretty sure that recommendation appeared in the key transition thread I started on Thursday. It's working very well for me and I probably will hold off on the transition since the SHA-3 progress appears to be sticking to their timetable after all. ;) Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon Dec 13 01:27:29 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 12 Dec 2010 19:27:29 -0500 Subject: Best Practices In-Reply-To: <4D0535BE.9040207@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D052A9E.3070001@fifthhorseman.net> <4D0535BE.9040207@sixdemonbag.org> Message-ID: On Dec 12, 2010, at 3:51 PM, Robert J. Hansen wrote: > On 12/12/2010 3:03 PM, Daniel Kahn Gillmor wrote: >> what do you mean by "V4 certificate checksums"? > > Read the RFC. It's in there, and does a better job than I can do of > explaining it. Section 5.5.3. Ah, I also wasn't sure what you were referring to. The checksum in 5.5.3 is to foil the Klima-Rosa attack (see http://eprint.iacr.org/2002/076 for the whole paper). Briefly, though, it means that if an attacker can get access to your secret key, they can modify it slightly and then wait for you to issue a signature. Once they see a signature issued from the modified key, they can reconstruct the secret key. The passphrase on your secret key does not protect against this. It's a very interesting attack, though if someone had access to your computer where your secret key lived, there is a whole load of other stuff they could do besides tamper with your secret key and wait for you to issue a signature. :) The fix in OpenPGP is to hash the contents of the secret key, so any tampering is evident. >> yeah, this is serious, but it's not embedded in the certificate. if we >> were to come up with a new fingerprint format, it would not invalidate >> any existing certificates -- it would just change how we refer to them. > > I am very skeptical of this claim you seem to be making, that we can > just upgrade-in-place. I am also skeptical of this. I strongly doubt that new fingerprints can be achieved without going to a V5 key format. There are just too many interoperability gotchas with an upgraded V4. We might be able to fight our way through them, but therein lies extra complexity and confusion for the implementer and user, which is not what is wanted for a secure system. V5 has the advantage of cleanliness and simplicity: there is no interoperability. Which doesn't mean that you couldn't have V4 alongside V5 for a period of time, just as we had V3 alongside V4 for at least a decade. The WoT would survive this just as it survived the V3->V4 transition. As V4 ramped up, V3 died out. David From faramir.cl at gmail.com Mon Dec 13 01:37:03 2010 From: faramir.cl at gmail.com (Faramir) Date: Sun, 12 Dec 2010 21:37:03 -0300 Subject: Best Practices In-Reply-To: <4D023C18.2060300@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> Message-ID: <4D056AAF.5020007@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 10-12-2010 11:41, Robert J. Hansen escribi?: ... > Add a new UID and revoke the old. You don't need to generate a new > certificate. RSA-4K is, IMO, phenomenal overkill for the vast majority > of users. Breaking RSA-2K is believed comparable in difficulty to > breaking 3DES, and that prospect is ... let's just say "implausible." Based on Schneier's estimations in "Applied Cryptography, Second Edition", I calculated breaking RSA 2048 would be between 1E7 and 1E9 times harder than breaking RSA 1024 (I divided the MIPS required to break RSA 2048 by the MIPS required to break RSA 1024). I know the book is old, and the estimations might be wrong, but still... there is a huge difference between breaking RSA 1024 (which so far has not happened), and breaking RSA 2048. It's not like saying "it would require 2 times more computing power", it's several orders of magnitude harder. If RSA 1024 becomes breakable today, and after that factorizing keys become 1000 times easier that it is today, and computers become 1000 times more powerful, they would still need at least 10 times more power to break RSA 2048. Yes, a lot of if's, but still useful to give an idea about how harder it would be. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEbBAEBCAAGBQJNBWqvAAoJEMV4f6PvczxAasYH92kLwCf2y9A5LvwQlLd/G2d4 jiUQ8PK922yAJ9UnjqAhJOoKJ3AtZw3URYp9IXGNJpUSgI1OSUVX5KHkCCwxaZWq NZ5m/8euHkqLd6PBqDWlHnK0lrkgEj0kUZyvSs0iceFwCt+WR7vp9QT1kAqC3kTN FCXGYKJzIhs8IkzYbYdD4BY6Lm4natCpN6mvA9btaF/Yi4UEyknu2Nmc1NCRlojY 8WfjdzNmFNWZH/ulkVRlfUgUF+gaFBZvuxByyCbFq0U4JwDwEfn34C2WXtamEDBd wXGdXu7J5NN6ZHsN2iiKdFMmwdXop1iaAKy1/aOilw0W/bpuO3J2i1K4yBdK7w== =hm7Y -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Dec 13 05:03:35 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 12 Dec 2010 23:03:35 -0500 Subject: Best Practices In-Reply-To: <4D04F679.3060301@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> Message-ID: On Dec 12, 2010, at 11:21 AM, Robert J. Hansen wrote: > On 12/12/2010 10:23 AM, Daniel Kahn Gillmor wrote: >> What part of OpenPGP certificates require SHA-1? > > ... At first blush, V4 certificate checksums, symmetrically encrypted > integrity protected data packets, the MDC system in general, certificate > fingerprints, etc. I just grepped through the RFC looking for any > hardcoded SHA-1; David is probably a much better reference than I am on > this. > > Probably the most annoying -- to me, at least -- is the fingerprint > requirement. If a preimage collision is discovered in SHA-1 then it's > all over. I can take your signature on my enemy's key, graft it onto my > own impersonator of my enemy's key, and then get others to believe it. Yes. The other uses of SHA-1 are not nearly as significant as the fingerprint (and thus key ID). For example, it's true that the MDC uses SHA-1, but no big deal - just make a new MDC that uses whatever you like, and repeat as needed. Virtually all deployed code will handle this correctly (for example, a feature flag indicating the existence of the "mdc2" capability), and use it only when all participants can handle it. The fingerprint issue is more than just making a new packet for a new MDC or revocation subpacket, though. There is no concept in OpenPGP of a flag telling an implementation how to calculate the fingerprint - or rather there IS a flag: the version field, but its hardcoded :) David From dkg at fifthhorseman.net Mon Dec 13 05:50:24 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 12 Dec 2010 23:50:24 -0500 Subject: Best Practices In-Reply-To: References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> Message-ID: <4D05A610.10108@fifthhorseman.net> On 12/12/2010 11:03 PM, David Shaw wrote: > The fingerprint issue is more than just making a new packet for a new MDC > or revocation subpacket, though. There is no concept in OpenPGP of a flag > telling an implementation how to calculate the fingerprint - or rather > there IS a flag: the version field, but its hardcoded :) In the discussion last year on the IETF list, the general consensus seemed to be that the fingerprints of primary keys were not endangered by a weakening of SHA-1's collision resistance. (This is in stark contrast to digital signatures and certifications, where weakened collision resistance in an algorithm represents a real threat [0]). But as far as i know, no one has yet reported a significant practical concern about SHA-1's resistance to a pre-image attack, which suggests that reliance on SHA-1 for fingerprints is probably reasonable until SHA-3 is selected. Nonetheless, the purpose of the fingerprint is just to help humans identify and communicate keys. It is not embedded in the parts of the spec for any part of the certificate format (aside from desig-revoker, an acknowledged flaw in RFC 4880). So i see no reason that when SHA-3 comes out, we couldn't define a new form of fingerprint (call it v5 if you want) based on SHA-3, produce/consume that fingerprint alongside the traditional v4 fingerprint for a reasonable time period, stop producing v4 fingerprints, and then ultimately stop consuming v4 fingerprints. Presumably when rolling out the new fingerprint format, we'd also specify that SHA-3 is the new "must-implement" digest for compliant implementations. Clearly, anyone capable of providing an SHA-3-based fingerprint has a tool capable of calculating SHA-3. These strike me as updates to the specification, certainly ("we now calculate fingerprints in the following way; We now require SHA-3 as the lowest-common-denominator digest"). But this is not a change of the certificate format. Can you help me understand why a change in the choice of fingerprint technique and a change in the must-implement-digest-algorithm would require a change in the certificates themselves? --dkg [0] http://www.win.tue.nl/hashclash/rogue-ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Mon Dec 13 11:10:44 2010 From: kloecker at kde.org (Ingo =?utf-8?q?Kl=C3=B6cker?=) Date: Mon, 13 Dec 2010 11:10:44 +0100 Subject: Best Practices In-Reply-To: <4D056AAF.5020007@gmail.com> References: <4D023C18.2060300@sixdemonbag.org> <4D056AAF.5020007@gmail.com> Message-ID: <201012131110.45038@thufir.ingo-kloecker.de> On Monday 13 December 2010, Faramir wrote: > El 10-12-2010 11:41, Robert J. Hansen escribi?: > ... > > > Add a new UID and revoke the old. You don't need to generate a new > > certificate. RSA-4K is, IMO, phenomenal overkill for the vast > > majority of users. Breaking RSA-2K is believed comparable in > > difficulty to breaking 3DES, and that prospect is ... let's just > > say "implausible." > > Based on Schneier's estimations in "Applied Cryptography, Second > Edition", I calculated breaking RSA 2048 would be between 1E7 and 1E9 > times harder than breaking RSA 1024 (I divided the MIPS required to > break RSA 2048 by the MIPS required to break RSA 1024). > > I know the book is old, and the estimations might be wrong, but > still... there is a huge difference between breaking RSA 1024 (which > so far has not happened), and breaking RSA 2048. It's not like > saying "it would require 2 times more computing power", it's several > orders of magnitude harder. > > If RSA 1024 becomes breakable today, and after that factorizing > keys become 1000 times easier that it is today, and computers become > 1000 times more powerful, they would still need at least 10 times > more power to break RSA 2048. Yes, a lot of if's, but still useful > to give an idea about how harder it would be. Well, SETI at Home claims to have over 3 million users. Large botnets have tens of thousands slaves. GPUs are in some areas several magnitudes faster than CPUs. There go your "several orders of magnitude". Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Dec 13 14:37:26 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Dec 2010 14:37:26 +0100 Subject: Best Practices In-Reply-To: (David Shaw's message of "Sun, 12 Dec 2010 19:27:29 -0500") References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D052A9E.3070001@fifthhorseman.net> <4D0535BE.9040207@sixdemonbag.org> Message-ID: <87pqt5equh.fsf@vigenere.g10code.de> On Mon, 13 Dec 2010 01:27, dshaw at jabberwocky.com said: > The fix in OpenPGP is to hash the contents of the secret key, so any tampering is evident. FWIW: We verify a signature immediatley after its creation which also thwarts this attack. > I am also skeptical of this. I strongly doubt that new fingerprints > can be achieved without going to a V5 key format. There are just too > many interoperability gotchas with an upgraded V4. We might be able Switching to V5 will be a lot of work in GnuPG because under the hood we need to replace a lot of data structures which use a 160 bit hash. It will eventually be done but before we do that we need SHA-3; lets talk about this in 2 years. Recall that the rush towards SHA-256 is due to collisions on SHA-1 expected in the near future. There are no signs at all that we will have a pre-image attack on SHA-1 any time soon [1]. Shalom-Salam, Werner [1] #include -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Mon Dec 13 17:16:04 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 13 Dec 2010 11:16:04 -0500 Subject: Best Practices In-Reply-To: <4D05A610.10108@fifthhorseman.net> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D05A610.10108@fifthhorseman.net> Message-ID: <0247FF86-9D81-4A5D-BBF4-228AE2FA501D@jabberwocky.com> On Dec 12, 2010, at 11:50 PM, Daniel Kahn Gillmor wrote: > Can you help me understand why a change in the choice of fingerprint > technique and a change in the must-implement-digest-algorithm would > require a change in the certificates themselves? It doesn't work that way. If you want to make a proposal, I'm all ears, as are the folks on the IETF list, but it seems to me you are focusing on one specific part of the design (the secret key format), forcing it to remain unchanged, and (presumably) using changes elsewhere to accommodate this fixed point in the design (for example, doubled PKESK packets, one for each key ID). As I see it, three major things need to happen to get OpenPGP using something other than SHA-1: 1) SHA-3 needs to exist: we will almost certainly use SHA-3, but even if we don't, we should wait until the SHA-3 reports are in. SHA-3 is a major amount of effort focused on hashing. It would be foolish to design something new involving hashing without using the latest research. 2) We need OpenPGP changes to incorporate the new hash in a way that works alongside the existing design. It's not as easy as "s/SHA-1/SHA-3/", especially given the deployed base of OpenPGP programs. 3) We need to roll out those changes in a way that won't break things. We're going to be running with SHA-1 and SHA-3 together for (at least) years. Even if we assume that there will be no other unrelated changes at the same time (an assumption I'm not willing to make - everyone has the half-dozen fiddle things (like hard expiration dates) that they think could be better, but aren't really worth fixing unless there is a key version jump), I'm still not willing to go into the design process in step 2 with the assumption that changing the secret key format is somehow off-limits. (And mind you, we haven't even reached step 1 yet!) David From dkg at fifthhorseman.net Mon Dec 13 18:23:16 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Dec 2010 12:23:16 -0500 Subject: Best Practices In-Reply-To: <0247FF86-9D81-4A5D-BBF4-228AE2FA501D@jabberwocky.com> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D05A610.10108@fifthhorseman.net> <0247FF86-9D81-4A5D-BBF4-228AE2FA501D@jabberwocky.com> Message-ID: <4D065684.7050206@fifthhorseman.net> On 12/13/2010 11:16 AM, David Shaw wrote: > it seems to me you are focusing on one specific part of > the design (the secret key format), forcing it to remain unchanged, FWIW, i don't particularly care about the secret key packet format. My focus in this discussion has been on the certificate format -- that is, the public primary key packet format and the certifications binding public primary keys to their User IDs, User Attributes, and subkeys. Avoiding a systemic change to the certificate format seems like it would be a Good Thing in that people could participate in a global smooth transition, without requiring a hard cut-over or a global interruption of existing networks of identity verification. > and (presumably) using changes elsewhere to accommodate this fixed > point in the design (for example, doubled PKESK packets, one for > each key ID). Given that the truncated keyid in the PKESK packet is only advisory material to help the recipient choose which key to use to try to decrypt (and not of sufficient length to provide cryptographic assurances even if it was intended to do so), i think this packet could stay as it currently stands, even if we choose to calculate the human-readable fingerprint in some other way. > As I see it, three major things need to happen to get OpenPGP using > something other than SHA-1: Wait -- i've been saying all along here that aside from non-cryptographic uses like the MDC, and the primary key fingerprint format itself (which is not vulnerable to weakened collision-resistance), we *can* use OpenPGP with something other than SHA-1 today. As far as i understand it, that was the point of building algorithm flexibility into OpenPGP in the first place. Do you think this has failed? The IETF discussion last year reviewing the OpenPGP spec for use of SHA-1 didn't turn up anything other than the parts we've been talking about in this thread, right? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon Dec 13 19:13:07 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 13 Dec 2010 13:13:07 -0500 Subject: Best Practices In-Reply-To: <4D065684.7050206@fifthhorseman.net> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D05A610.10108@fifthhorseman.net> <0247FF86-9D81-4A5D-BBF4-228AE2FA501D@jabberwocky.com> <4D065684.7050206@fifthhorseman.net> Message-ID: <21A90EEA-8548-47F3-BD97-994294FA161D@jabberwocky.com> On Dec 13, 2010, at 12:23 PM, Daniel Kahn Gillmor wrote: > Avoiding a systemic change to the certificate format seems like it would > be a Good Thing in that people could participate in a global smooth > transition, without requiring a hard cut-over or a global interruption > of existing networks of identity verification. Why is it that using the method you advocate, there is a graceful changeover between fingerprint formats, but a change in the certificate format requires a "hard cut-over" with "global interruption of existing networks..." ? That's a straw man. Who is advocating a hard cut over or any interruption whatsoever? Personally, I suspect a changeover would take somewhere between 5 and 10 years, just as the v3->v4 changeover did. It is premature to try and force a particular format into the design before we even have a SHA-3 to talk about. David From dkg at fifthhorseman.net Mon Dec 13 22:40:56 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Dec 2010 16:40:56 -0500 Subject: Best Practices In-Reply-To: <21A90EEA-8548-47F3-BD97-994294FA161D@jabberwocky.com> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D05A610.10108@fifthhorseman.net> <0247FF86-9D81-4A5D-BBF4-228AE2FA501D@jabberwocky.com> <4D065684.7050206@fifthhorseman.net> <21A90EEA-8548-47F3-BD97-994294FA161D@jabberwocky.com> Message-ID: <4D0692E8.9080308@fifthhorseman.net> On 12/13/2010 01:13 PM, David Shaw wrote: > Why is it that using the method you advocate, there is a graceful > changeover between fingerprint formats, but a change in the > certificate format requires a "hard cut-over" with "global > interruption of existing networks..." ? I was assuming that new certificates come with new keys, and that new keys could not certify or be certified by existing (old) certificates. Are v3 keys able to certify or be certified by v4 certificates? > I suspect a changeover would take somewhere between 5 and 10 years, > just as the v3->v4 changeover did. That sounds like what i would expect as well. > It is premature to try and force a particular format into the > design before we even have a SHA-3 to talk about. i agree. That's why i've been proposing that people transition to new algorithms without trying to wait for a format change that is likely to take years to even begin, plus many more years to complete. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon Dec 13 23:41:51 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 13 Dec 2010 17:41:51 -0500 Subject: Best Practices In-Reply-To: <4D0692E8.9080308@fifthhorseman.net> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D05A610.10108@fifthhorseman.net> <0247FF86-9D81-4A5D-BBF4-228AE2FA501D@jabberwocky.com> <4D065684.7050206@fifthhorseman.net> <21A90EEA-8548-47F3-BD97-994294FA161D@jabberwocky.com> <4D0692E8.9080308@fifthhorseman.net> Message-ID: <8E1987A3-13F7-420A-8CEC-5B67B4660647@jabberwocky.com> On Dec 13, 2010, at 4:40 PM, Daniel Kahn Gillmor wrote: > On 12/13/2010 01:13 PM, David Shaw wrote: >> Why is it that using the method you advocate, there is a graceful >> changeover between fingerprint formats, but a change in the >> certificate format requires a "hard cut-over" with "global >> interruption of existing networks..." ? > > I was assuming that new certificates come with new keys, and that new > keys could not certify or be certified by existing (old) certificates. > > Are v3 keys able to certify or be certified by v4 certificates? Sure, in both directions. David From faramir.cl at gmail.com Mon Dec 13 23:48:49 2010 From: faramir.cl at gmail.com (Faramir) Date: Mon, 13 Dec 2010 19:48:49 -0300 Subject: Best Practices In-Reply-To: <201012131110.45038@thufir.ingo-kloecker.de> References: <4D023C18.2060300@sixdemonbag.org> <4D056AAF.5020007@gmail.com> <201012131110.45038@thufir.ingo-kloecker.de> Message-ID: <4D06A2D1.3020706@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 13-12-2010 7:10, Ingo Kl?cker escribi?: > On Monday 13 December 2010, Faramir wrote: ... >> If RSA 1024 becomes breakable today, and after that factorizing >> keys become 1000 times easier that it is today, and computers become >> 1000 times more powerful, they would still need at least 10 times >> more power to break RSA 2048. Yes, a lot of if's, but still useful >> to give an idea about how harder it would be. > > Well, SETI at Home claims to have over 3 million users. Large botnets have > tens of thousands slaves. GPUs are in some areas several magnitudes > faster than CPUs. There go your "several orders of magnitude". But supposedly, even with all these botnets, RSA-1024 has not been broken yet. I don't know if there is some RSA at Home, but anyway, the thing is breaking RSA-2048 would require about 10.000.000 times more power than breaking RSA-1024, which -so far as we know- has not been broken yet, they would need a botnet a lot bigger... I searched in google, and found a paper doing estimations about how many MIPS-year would a botnet have on year 2007. Based on that assumption, they calculated how much time would it take to break 1 RSA-1024 key. I searched by "MIPS year botnet" (without the " marks), and the first result is the paper, named "Spam, Phishing, and the Looming Challenge of Big Botnets", by Ren? H. Hemmingsen. Department of Computer Science. University of Copenhagen, Denmark. Pages 7 to 9. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNBqLRAAoJEMV4f6PvczxAjtgH/iQifbgqqiWX7n9Q9cI4cNA3 II4dc4gLlOcDrcnyW87+x1NkYZQ04Fb+YYCu4rJCZH6EzGjK9AxTbZ7xEabIn19c rhUC18S7JKBRHRs5Sq+uaGrhpxPyTD/5shblzxoQdXBLzlGrucDhaRhdps69SIqi dOMWRQgIZj+qEyMSBiNBoxaf30UdOCs4hGEJKRkPrqUUIXlVcUqpSuxZ/i3odOHr UHoOaFd2Rlai59i1Co0qw/+WfC/JK7Cn4ETjsmx1lPC1D9LPIfoWqhgVQPJAkqgo K5oJNRexBDOZUCkBXiHl4yA04dNc/uiDeTiTOj0KT0MMNtBRK7Shm0HBR5nX+AY= =3/dq -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Dec 14 02:26:43 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 13 Dec 2010 20:26:43 -0500 Subject: Best Practices In-Reply-To: <4D065684.7050206@fifthhorseman.net> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D05A610.10108@fifthhorseman.net> <0247FF86-9D81-4A5D-BBF4-228AE2FA501D@jabberwocky.com> <4D065684.7050206@fifthhorseman.net> Message-ID: <4D06C7D3.5050800@sixdemonbag.org> On 12/13/2010 12:23 PM, Daniel Kahn Gillmor wrote: > Avoiding a systemic change to the certificate format seems like it would > be a Good Thing in that people could participate in a global smooth > transition, without requiring a hard cut-over or a global interruption > of existing networks of identity verification. *What* hard cut-over or interruption of existing networks? The v3/v4 transition was seamless because there was neither a cut-over date nor an interruption: people migrated at their own pace, when they were ready to, and not before. v3 keys are still used today, although they're increasingly niche. v4/v5 will coexist the same as v3/v4 coexist. In fact, it's quite likely v3 and v5 will coexist. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From rjh at sixdemonbag.org Tue Dec 14 02:28:24 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 13 Dec 2010 20:28:24 -0500 Subject: Best Practices In-Reply-To: <4D0692E8.9080308@fifthhorseman.net> References: <4D023C18.2060300@sixdemonbag.org> <4D03A5CE.2080509@sixdemonbag.org> <4D04E8E7.90509@fifthhorseman.net> <4D04F679.3060301@sixdemonbag.org> <4D05A610.10108@fifthhorseman.net> <0247FF86-9D81-4A5D-BBF4-228AE2FA501D@jabberwocky.com> <4D065684.7050206@fifthhorseman.net> <21A90EEA-8548-47F3-BD97-994294FA161D@jabberwocky.com> <4D0692E8.9080308@fifthhorseman.net> Message-ID: <4D06C838.5000003@sixdemonbag.org> On 12/13/2010 4:40 PM, Daniel Kahn Gillmor wrote: > i agree. That's why i've been proposing that people transition to new > algorithms without trying to wait for a format change that is likely to > take years to even begin, plus many more years to complete. And no one is arguing against this. All people are arguing against is, "I want to migrate to a new certificate in order to avoid SHA-1." To the extent it is possible to avoid SHA-1, it can be avoided today without migrating to a new cert; and for the rest, it cannot be avoided today even if one migrates to a new cert. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From rjh at sixdemonbag.org Tue Dec 14 02:30:29 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 13 Dec 2010 20:30:29 -0500 Subject: Best Practices In-Reply-To: <4D06A2D1.3020706@gmail.com> References: <4D023C18.2060300@sixdemonbag.org> <4D056AAF.5020007@gmail.com> <201012131110.45038@thufir.ingo-kloecker.de> <4D06A2D1.3020706@gmail.com> Message-ID: <4D06C8B5.9030702@sixdemonbag.org> On 12/13/2010 5:48 PM, Faramir wrote: > But supposedly, even with all these botnets, RSA-1024 has not been > broken yet. I don't know if there is some RSA at Home The Berkeley BOINC framework can be pretty easily adapted to do this. > thing is breaking RSA-2048 would require about 10.000.000 times more > power than breaking RSA-1024, which -so far as we know- has not been > broken yet Off by about a factor of 100 there. RSA-2048 is roughly equivalent to a 112-bit symmetric key; RSA-1024 is roughly equivalent to an 80-bit key. 32 bits of difference equals a factor of four billion. It's way harder than you think. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From kloecker at kde.org Tue Dec 14 10:11:54 2010 From: kloecker at kde.org (Ingo =?iso-8859-15?q?Kl=F6cker?=) Date: Tue, 14 Dec 2010 10:11:54 +0100 Subject: Best Practices In-Reply-To: <4D06C8B5.9030702@sixdemonbag.org> References: <4D06A2D1.3020706@gmail.com> <4D06C8B5.9030702@sixdemonbag.org> Message-ID: <201012141012.01129@thufir.ingo-kloecker.de> On Tuesday 14 December 2010, Robert J. Hansen wrote: > Off by about a factor of 100 there. RSA-2048 is roughly equivalent > to a 112-bit symmetric key; RSA-1024 is roughly equivalent to an > 80-bit key. 32 bits of difference equals a factor of four billion. > It's way harder than you think. Those equivalences have been mentioned a few times. Is there a good (freely available) reference for this? Thanks in advance! Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From vedaal at nym.hush.com Tue Dec 14 15:39:18 2010 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 14 Dec 2010 09:39:18 -0500 Subject: Best Practices Message-ID: <20101214143918.1ACA0FEC6@smtp.hushmail.com> Ingo Kl?cker kloecker at kde.org wrote on Tue Dec 14 10:11:54 CET 2010 : >>RSA-2048 is roughly equivalent >> to a 112-bit symmetric key; RSA-1024 is roughly equivalent to an >> 80-bit key. >Those equivalences have been mentioned a few times. Is there a good >(freely available) reference for this? There was a NIST or FIPS publication about the time of rfc4880 that had tables listing which asymmetric keys lengths were appropriate for use with which symmetric algorithms (don't have the exact reference offhand, but remember it was definitely a NIST or FIPS pdf easily available Here is a starting point: http://csrc.nist.gov/publications/drafts/800-78-3/markup_draft-nist- SP_800-78-3.pdf p.12 If somoene knows the exact NIST or FIPS document I'm thinking of, please post, TIA! vedaal From rjh at sixdemonbag.org Tue Dec 14 15:47:08 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Dec 2010 09:47:08 -0500 Subject: Best Practices In-Reply-To: <201012141012.01129@thufir.ingo-kloecker.de> References: <4D06A2D1.3020706@gmail.com> <4D06C8B5.9030702@sixdemonbag.org> <201012141012.01129@thufir.ingo-kloecker.de> Message-ID: <4D07836C.4000509@sixdemonbag.org> On 12/14/2010 4:11 AM, Ingo Kl?cker wrote: > Those equivalences have been mentioned a few times. Is there a good > (freely available) reference for this? Thanks in advance! http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf Page 63. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From vedaal at nym.hush.com Tue Dec 14 16:08:12 2010 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 14 Dec 2010 10:08:12 -0500 Subject: best practices Message-ID: <20101214150812.5658BFEC4@smtp.hushmail.com> Robert J. Hansen rjh at sixdemonbag.org wrote on Tue Dec 14 15:47:08 CET 2010 : > http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1- revised2_Mar08-2007.pdf Page 63. > Thanks. Always wondered about that. The table says: AES-256 ... RSA k = 15360 Does anybody who is careful about using a 256 symmetric cipher actually use a 15k rsa key?? (makes me more comfortable with my prefereces for 3DES and a 4k key ;-) ) vedaal From rjh at sixdemonbag.org Tue Dec 14 18:11:54 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Dec 2010 12:11:54 -0500 Subject: best practices In-Reply-To: <20101214150812.5658BFEC4@smtp.hushmail.com> References: <20101214150812.5658BFEC4@smtp.hushmail.com> Message-ID: <4D07A55A.9060809@sixdemonbag.org> On 12/14/10 10:08 AM, vedaal at nym.hush.com wrote: > Does anybody who is careful about using a 256 symmetric cipher > actually use a 15k rsa key?? There are a few of them on the keyservers, IIRC. Whether this is the result of a deliberate and carefully chosen policy, or rampant paranoid schizophrenia, is an open question... From ben at adversary.org Tue Dec 14 18:42:24 2010 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Dec 2010 04:42:24 +1100 Subject: best practices In-Reply-To: <4D07A55A.9060809@sixdemonbag.org> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <4D07A55A.9060809@sixdemonbag.org> Message-ID: <4D07AC80.4040409@adversary.org> On 15/12/10 4:11 AM, Robert J. Hansen wrote: > > There are a few of them on the keyservers, IIRC. Whether this is the > result of a deliberate and carefully chosen policy, or rampant paranoid > schizophrenia, is an open question... They could be a result of using the old Cyber Knights Templar versions of PGP that cropped up in the mid-'90s which allowed creating 16Kb keys. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Dec 14 19:12:48 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Dec 2010 13:12:48 -0500 Subject: best practices In-Reply-To: <4D07AC80.4040409@adversary.org> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <4D07A55A.9060809@sixdemonbag.org> <4D07AC80.4040409@adversary.org> Message-ID: <4D07B3A0.4020702@sixdemonbag.org> On 12/14/10 12:42 PM, Ben McGinnes wrote: > They could be a result of using the old Cyber Knights Templar versions > of PGP that cropped up in the mid-'90s which allowed creating 16Kb keys. What tool was used really doesn't interest me very much -- you can create them with GnuPG, too, if you're willing to tweak the source a little bit. What I find morbidly fascinating is contemplating what kind of deranged individual would actually do this. :) From dshaw at jabberwocky.com Tue Dec 14 19:23:43 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 14 Dec 2010 13:23:43 -0500 Subject: best practices In-Reply-To: <20101214150812.5658BFEC4@smtp.hushmail.com> References: <20101214150812.5658BFEC4@smtp.hushmail.com> Message-ID: <03911CBE-AEA7-404A-8B26-CBC6759E02C2@jabberwocky.com> On Dec 14, 2010, at 10:08 AM, vedaal at nym.hush.com wrote: > Robert J. Hansen rjh at sixdemonbag.org wrote on > Tue Dec 14 15:47:08 CET 2010 : > >> > http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1- > revised2_Mar08-2007.pdf > > Page 63. >> > > Thanks. > > Always wondered about that. The table says: > > AES-256 ... RSA k = 15360 > > Does anybody who is careful about using a 256 symmetric cipher > actually use a 15k rsa key?? Not many. Not that there is any *harm* in using a 256-bit symmetric cipher and a 2048-bit asymmetric key together. It just means that, as with many things, including those in the physical world (think: heavy metal front door next to a glass window), your overall level of security is that of the weakest item. There is no harm (aside from potential interoperability problems) as long as you aren't fooling yourself. There is a weak safety factor argument, too. If it turns out that (for example) AES-256 isn't as strong as expected, it may well be that AES-256 is actually a good match to RSA-2048, and you were wise to use it instead of AES-128 (which given the same imaginary attack would be weaker than RSA-2048). You sort of need a crystal ball to make that argument though... David From ben at adversary.org Tue Dec 14 19:34:29 2010 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Dec 2010 05:34:29 +1100 Subject: best practices In-Reply-To: <4D07B3A0.4020702@sixdemonbag.org> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <4D07A55A.9060809@sixdemonbag.org> <4D07AC80.4040409@adversary.org> <4D07B3A0.4020702@sixdemonbag.org> Message-ID: <4D07B8B5.30709@adversary.org> On 15/12/10 5:12 AM, Robert J. Hansen wrote: > > What tool was used really doesn't interest me very much -- you can > create them with GnuPG, too, if you're willing to tweak the source a > little bit. True, that one just made it a lot easier for people who did not realise how easy it is to tweak the source code and recompile. > What I find morbidly fascinating is contemplating what kind of > deranged individual would actually do this. :) There are many deranged individuals on the Internet and many kinds of them too. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Dec 14 19:41:20 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Dec 2010 13:41:20 -0500 Subject: best practices In-Reply-To: <03911CBE-AEA7-404A-8B26-CBC6759E02C2@jabberwocky.com> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <03911CBE-AEA7-404A-8B26-CBC6759E02C2@jabberwocky.com> Message-ID: <4D07BA50.3010501@sixdemonbag.org> On 12/14/10 1:23 PM, David Shaw wrote: > You sort of need a crystal ball to make that argument though... To underline and agree with what David said -- the entire field of communications security requires crystal balls. It sounds neat and simple to say, "the weakest part of the system must be stronger than the adversary's ability to break it," but in reality it's messy and complicated. The weakest part of the system, in your estimation, may not be the same as the weakest part in the enemy's estimation. If you don't know what your enemy's capabilities are, well, figuring out what the enemy will consider "weakest" requires a crystal ball. For that matter, you may not know who your enemies are. If you're worried about the FBI eavesdropping on your email, you might be totally blind to J. Random Sysadmin who gets his jollies from planting keyloggers on systems. Just knowing who your enemies are requires a crystal ball. You may... etc., etc. It's an incredibly difficult and Byzantine problem. From kgo at grant-olson.net Tue Dec 14 19:47:01 2010 From: kgo at grant-olson.net (Grant Olson) Date: Tue, 14 Dec 2010 13:47:01 -0500 Subject: best practices In-Reply-To: <4D07B3A0.4020702@sixdemonbag.org> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <4D07A55A.9060809@sixdemonbag.org> <4D07AC80.4040409@adversary.org> <4D07B3A0.4020702@sixdemonbag.org> Message-ID: <4D07BBA5.7080904@grant-olson.net> On 12/14/10 1:12 PM, Robert J. Hansen wrote: > On 12/14/10 12:42 PM, Ben McGinnes wrote: >> They could be a result of using the old Cyber Knights Templar versions >> of PGP that cropped up in the mid-'90s which allowed creating 16Kb keys. > > What tool was used really doesn't interest me very much -- you can > create them with GnuPG, too, if you're willing to tweak the source a > little bit. What I find morbidly fascinating is contemplating what kind > of deranged individual would actually do this. :) > Now I'm going to spend all day wondering if anyone's tweaked the source to make smaller keys. An eight-bit key would surely save your bandwidth, right? -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 559 bytes Desc: OpenPGP digital signature URL: From nick-art at alice.nl Tue Dec 14 22:45:42 2010 From: nick-art at alice.nl (Nick ALice) Date: Tue, 14 Dec 2010 22:45:42 +0100 Subject: Some questions from a new opengpg card v. 2 user Message-ID: <4D07E586.6070503@alice.nl> Hi, I just bought a few OpenPGP cards V2.0 0005 xxxxxxx. I was hoping that I could use them within minutes. That is not the case. I'm running Windows 7 - 64Bit combined with Thunderbird/Enigmail (latest versions) combined with gpg4win 2.0.4. (GnuPG 2.0.14). Info about proper usage of card with enigmail/gnugp is distributed around and sometimes old or non existant. Questions about the PIN's: gpg2 --card-edit -> admin, passwd What is option 2 Unblock PIN ? and what is the meaning of option 4 Reset code ? What will happen if I use several times the wrong admin password? Will it brick the card or can it be resurrected with the method of sending data to it using the gpg-connect-agent (see e.g. http://www.gossamer-threads.com/lists/gnupg/users/49737 ) ? (I have not tried it out to find the answer to this :-D ) Is there a proper manual that describes the different commands at low level? I have also many questions about the usage at higher levels - I will post them later. Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From John at Mozilla-Enigmail.org Tue Dec 14 23:40:19 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Tue, 14 Dec 2010 16:40:19 -0600 Subject: Best Practices In-Reply-To: <201012141012.01129@thufir.ingo-kloecker.de> References: <4D06A2D1.3020706@gmail.com> <4D06C8B5.9030702@sixdemonbag.org> <201012141012.01129@thufir.ingo-kloecker.de> Message-ID: <4D07F253.4040605@Mozilla-Enigmail.org> Ingo Kl?cker wrote: > On Tuesday 14 December 2010, Robert J. Hansen wrote: >> Off by about a factor of 100 there. RSA-2048 is roughly equivalent >> to a 112-bit symmetric key; RSA-1024 is roughly equivalent to an >> 80-bit key. 32 bits of difference equals a factor of four billion. >> It's way harder than you think. > > Those equivalences have been mentioned a few times. Is there a good > (freely available) reference for this? Thanks in advance! In the "multiple subkeys and key transition" thread, I wrote on 12/9/2010 at 16:28 (US/Central): +> How do elliptic curves compare to RSA today? +> +> From the National Institutes of Science and Technology (one of the gold +> standards for engineering know-how): +> +> RSA ECC Sym +> 1024 160 80 +> 2048 224 112 <+ +> 3072 256 128 +> 7680 384 192 +> 15360 512 256 +> +> These recommendations can be found on page 63 of NIST Special +> Publication 800-57, Recommendations for Key Management, Part I. 2nd Revision, +> 8 Mar, 2007. +> [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf] > -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From faramir.cl at gmail.com Wed Dec 15 00:37:07 2010 From: faramir.cl at gmail.com (Faramir) Date: Tue, 14 Dec 2010 20:37:07 -0300 Subject: best practices In-Reply-To: <4D07B3A0.4020702@sixdemonbag.org> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <4D07A55A.9060809@sixdemonbag.org> <4D07AC80.4040409@adversary.org> <4D07B3A0.4020702@sixdemonbag.org> Message-ID: <4D07FFA3.9090201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 14-12-2010 15:12, Robert J. Hansen escribi?: > On 12/14/10 12:42 PM, Ben McGinnes wrote: >> They could be a result of using the old Cyber Knights Templar versions >> of PGP that cropped up in the mid-'90s which allowed creating 16Kb keys. > > What tool was used really doesn't interest me very much -- you can > create them with GnuPG, too, if you're willing to tweak the source a > little bit. What I find morbidly fascinating is contemplating what kind > of deranged individual would actually do this. :) Well, somebody could think "if they made a 256 bits symmetric algo, there should be a reason for that. And since if the asymmetric key is broken, the message is decrypted, no matter how strong is the symmetric algo, then it makes sense to use something equally strong". Now I think about it, AES-256 would be also an overkill, and the only reason why we don't think it is a bad idea, is because we don't notice a reduction in performance (with "normal usage") compared with AES-128. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNB/+jAAoJEMV4f6PvczxAg74H/RF9GLennMUSPZ79pEHcSuWz zdIwDVbuXmZ3KXopADGlF6QMr9LX1jJjtWFoLSA7/BVXu/DfqX263uwixfMP+Xvz FZL90hhzaU410Nt6xdgenRqORQnzRuyVKYmpj5psBNVeedsE+yY3tcRVIKNy9ePi chdPrK/vwQ47Aq6+a8VBnCKhXlcFwo3rXQKgFgzy17fRuIhrbgu8Dany4TosWFwP xNdo4Cdje6Na1RzKgkKiHORZzROzFV+OKQioy+yJPKEjYDmj566djNNWgU2Pu/ZZ VbHEIR1kQX7P4idJv0BJmgfVUUMGlHJWgSj2k6IRy+w5pKRZuY7N8I5PUXr7JUI= =FxHq -----END PGP SIGNATURE----- From faramir.cl at gmail.com Wed Dec 15 00:43:54 2010 From: faramir.cl at gmail.com (Faramir) Date: Tue, 14 Dec 2010 20:43:54 -0300 Subject: best practices In-Reply-To: <03911CBE-AEA7-404A-8B26-CBC6759E02C2@jabberwocky.com> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <03911CBE-AEA7-404A-8B26-CBC6759E02C2@jabberwocky.com> Message-ID: <4D08013A.10507@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 14-12-2010 15:23, David Shaw escribi?: ... > There is a weak safety factor argument, too. If it turns out that (for example) AES-256 isn't as strong as expected, it may well be that AES-256 is actually a good match to RSA-2048, and you were wise to use it instead of AES-128 (which given the same imaginary attack would be weaker than RSA-2048). You sort of need a crystal ball to make that argument though... I wish I had read that message before writing my last reply XD I know I asked before, but I can't remember if I saw an answer. Is TwoFish implementation the 256 bit key version? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNCAE6AAoJEMV4f6PvczxAtqIH/3a+8kwHqB9WuHDScknpwx+M PCaquhrAoSKbZP06NG/+BH7wq4ChDBz2TLAy0MyUDdu9pb7uQWbu2btppubzxJBB /zJ81qPBg/n1nBLlQ98UMYgIihxriuf+tC4x3JL7t0MhRrt/UaYEZwjdW/Xk1mRn hJKZOiZdaGU23OcIVB4kcQIOo+yUYUatWIgsQDQSKJ2CGAxiWObW1hAaTMh/ZFa+ ppsfB859ULz4mXd85zsOqzrDMQaMRMCZmhJwLmODjspiQb1p5dl5K85PGDVnIt5F shEqgctt3FxEWr4XvLwfrOm+kUwqijxbunWXT5XHqAIher6GwyKFR918A8+bkEE= =ZJ7N -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Dec 15 00:49:03 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Dec 2010 18:49:03 -0500 Subject: best practices In-Reply-To: <4D07FFA3.9090201@gmail.com> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <4D07A55A.9060809@sixdemonbag.org> <4D07AC80.4040409@adversary.org> <4D07B3A0.4020702@sixdemonbag.org> <4D07FFA3.9090201@gmail.com> Message-ID: <4D08026F.8050409@sixdemonbag.org> On 12/14/2010 6:37 PM, Faramir wrote: > Well, somebody could think "if they made a 256 bits symmetric algo, > there should be a reason for that. And since if the asymmetric key is > broken, the message is decrypted, no matter how strong is the symmetric > algo, then it makes sense to use something equally strong". Sure. But someone could also think, "since they make both high proof whiskey and fast cars, and they're each perfectly safe, there's no harm in mixing them." Thinking, "if they make a 256-bit symmetric algo, there should be a reason for that," is quite correct as far as it goes. Thinking its existence means you need to use it, though, is not. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From rjh at sixdemonbag.org Wed Dec 15 01:24:27 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Dec 2010 19:24:27 -0500 Subject: best practices In-Reply-To: <4D08013A.10507@gmail.com> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <03911CBE-AEA7-404A-8B26-CBC6759E02C2@jabberwocky.com> <4D08013A.10507@gmail.com> Message-ID: <4D080ABB.4000607@sixdemonbag.org> On 12/14/2010 6:43 PM, Faramir wrote: > I know I asked before, but I can't remember if I saw an answer. Is > TwoFish implementation the 256 bit key version? Yes. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From dshaw at jabberwocky.com Wed Dec 15 01:42:58 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 14 Dec 2010 19:42:58 -0500 Subject: best practices In-Reply-To: <4D08013A.10507@gmail.com> References: <20101214150812.5658BFEC4@smtp.hushmail.com> <03911CBE-AEA7-404A-8B26-CBC6759E02C2@jabberwocky.com> <4D08013A.10507@gmail.com> Message-ID: On Dec 14, 2010, at 6:43 PM, Faramir wrote: > I know I asked before, but I can't remember if I saw an answer. Is > TwoFish implementation the 256 bit key version? Yes it is. David From faramir.cl at gmail.com Wed Dec 15 03:07:27 2010 From: faramir.cl at gmail.com (Faramir) Date: Tue, 14 Dec 2010 23:07:27 -0300 Subject: Best Practices In-Reply-To: <4D06C8B5.9030702@sixdemonbag.org> References: <4D023C18.2060300@sixdemonbag.org> <4D056AAF.5020007@gmail.com> <201012131110.45038@thufir.ingo-kloecker.de> <4D06A2D1.3020706@gmail.com> <4D06C8B5.9030702@sixdemonbag.org> Message-ID: <4D0822DF.1020808@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 13-12-2010 22:30, Robert J. Hansen escribi?: > On 12/13/2010 5:48 PM, Faramir wrote: >> But supposedly, even with all these botnets, RSA-1024 has not been >> broken yet. I don't know if there is some RSA at Home > > The Berkeley BOINC framework can be pretty easily adapted to do this. Ah, good hint, I found NFS at home, a project to factor large integers... There is also Enigma at home, but that is a bit old fashioned ;) I think I'll stay with Folding at home >> thing is breaking RSA-2048 would require about 10.000.000 times more >> power than breaking RSA-1024, which -so far as we know- has not been >> broken yet > > Off by about a factor of 100 there. RSA-2048 is roughly equivalent to a > 112-bit symmetric key; RSA-1024 is roughly equivalent to an 80-bit key. > 32 bits of difference equals a factor of four billion. It's way harder > than you think. Ok, that's even better ;) I took the MIPS-years estimation to break RSA-1024, the estimation for breaking RSA-2048, and divided. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJNCCLfAAoJEMV4f6PvczxAdm0H/1uvdoRRiiYoPUYVH4TbzGaV LsK4b2URAzq7e51vjPqx3RfTsPSDLiKUP1aRyJXmAWiyLI5gftXhjT5wshc78BDQ OEiP+BEVwe4Dh6mpVtODSUm8lpNcG5rViOAnRxE2nh/PYryZSyJcP/ipylGtxNVI EDUAj3RYxQ5Vzpl+D3ouri33E+2FpG7XetHRoh/v/eCxyTccWHFHYa+T7U4HMFuJ D7XTx337CFRsmkPgI7AMPgaENY9z3f+5IISeM4Ld0m/cyspl28IbG9ajk6GmHs8Z 6W/62xPwnWfWYqyxDxOXZ9ulftONkziWSyBpMuMdtBkigeelQbfnP6ztljTXZ8k= =ln/S -----END PGP SIGNATURE----- From info at kgo.de Wed Dec 15 11:12:28 2010 From: info at kgo.de (Klaus Gotthardt) Date: Wed, 15 Dec 2010 11:12:28 +0100 Subject: gnupg with thingw (thin gui wrapper) Message-ID: Hello, you can find some gnupg commands in thingw: http://www.kgo.de/thingw/index.html comments are welcome. klaus From tozajaczkowski at gmail.com Thu Dec 16 15:11:50 2010 From: tozajaczkowski at gmail.com (=?UTF-8?Q?Tomasz_Zaj=C4=85czkowski?=) Date: Thu, 16 Dec 2010 14:11:50 +0000 Subject: gnupgp basics - using same keys with multiple local accounts Message-ID: Hi All, I have installed gnupgp on Solaris 10 and created a pair of keys for myself and imported key from my client. I need use same set for different local account - unfortunately whenever I try to change the folder with --homedir option I am ending up with: gpg --homedir /my-folder gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Go ahead and type your message ... Is there an easy way how to share the keys between different OS local accounts? Regards, Tomasz From johanw at vulcan.xs4all.nl Thu Dec 16 17:19:16 2010 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 16 Dec 2010 17:19:16 +0100 Subject: gnupgp basics - using same keys with multiple local accounts In-Reply-To: References: Message-ID: <4D0A3C04.6080906@vulcan.xs4all.nl> On 16-12-2010 15:11, Tomasz Zaj?czkowski wrote: > Is there an easy way how to share the keys between different OS local accounts? Copy secring.gpg and pubring.gpg to a ~/.gnupg dir in each account. Or, if they have already their own different keyrings, import the keys in question into their keyring. -- Met vriendelijke groet, Johan Wevers From John at Mozilla-Enigmail.org Fri Dec 17 03:32:48 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Thu, 16 Dec 2010 20:32:48 -0600 Subject: gnupgp basics - using same keys with multiple local accounts In-Reply-To: References: Message-ID: <4D0ACBD0.4030501@Mozilla-Enigmail.org> Tomasz Zaj?czkowski wrote: > Hi All, > > I have installed gnupgp on Solaris 10 and created a pair of keys for > myself and imported key from my client. I need use same set for > different local account - unfortunately whenever I try to change the > folder with --homedir option I am ending up with: > gpg --homedir /my-folder > gpg: WARNING: using insecure memory! > gpg: please see http://www.gnupg.org/faq.html for more information > gpg: Go ahead and type your message ... > > Is there an easy way how to share the keys between different OS local accounts? I believe you want '--homedir /my-folder/.gnupg'. GnuPG's homedir option does not point to $HOME, but $HOME/.gnupg, the location of GnuPG's keyring files and optional gpg.conf. The other alternative is to either copy {pubring,secring,trustdb}.gpg to the new account or, if populated keyring files already exist, to import secring.gpg and pubring.gpg from the original account to the new account. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 499 bytes Desc: OpenPGP digital signature URL: From jcruff at gmail.com Fri Dec 17 17:22:37 2010 From: jcruff at gmail.com (Chris Ruff) Date: Fri, 17 Dec 2010 11:22:37 -0500 Subject: clearsign failed: Bad signature In-Reply-To: <4D03834E.4010208@mozilla-enigmail.org> References: <4D01EE28.2000304@mozilla-enigmail.org> <4D03834E.4010208@mozilla-enigmail.org> Message-ID: <1292602957.9417.83.camel@silence.i.fourings.com> On Sat, 2010-12-11 at 14:57 +0100, Olav Seyfarth wrote: > My key: OpenPGP SmartCard v2 key 0x6AE1EF56 (3072 Bit RSA) Card 0005 00000222 > > Why can't I use SHA256/SHA512 with this card? > | enable-dsa2 > is set and showpref lists The documentation for OpenPGP v2 smartcard states that only RIPEMD-160 & SHA-1 are supported as a digest algorithm at this point in time. You'll have to change your digest prefs accordingly to use the card. excert from doc: "Cards with Version < 2.0 sup?port RIPEMD-160 and SHA-1 only and may check it, so other hash algorithms cannot be used." Although I assume it should say =<2.0. Feedback from others if this was a typo in teh doc and should be =<2.0? -- __________________________________ Chris Ruff email: jcruff at gmail.com gpg key: 0xDD55B6FC gpg fgpr: 1BA1 71D7 ADA7 1E8B 1623 A43D 283B 2F81 BDD5 B810 From olav at mozilla-enigmail.org Fri Dec 17 22:04:16 2010 From: olav at mozilla-enigmail.org (Olav Seyfarth) Date: Fri, 17 Dec 2010 22:04:16 +0100 Subject: clearsign failed: Bad signature In-Reply-To: <1292602957.9417.83.camel@silence.i.fourings.com> References: <4D01EE28.2000304@mozilla-enigmail.org> <4D03834E.4010208@mozilla-enigmail.org> <1292602957.9417.83.camel@silence.i.fourings.com> Message-ID: <4D0BD050.2020001@mozilla-enigmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Thanks Chris, > The documentation for OpenPGP v2 smartcard states that only RIPEMD-160 > & SHA-1 are supported as a digest algorithm at this point in time. I overlooked that part. Olav - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGcBAEBAwAGBQJNC9BIAAoJEKGX32tq4e9WtMEL/1sJqnybJxTsUKV6/o5vGK9k KmAjcCsQXnLHUnm4M7ky5uF6NZ3a0wNnpr2N6PatgYMqcCUqPw+ASpVCB3kQcDNZ ybdUu/yHt3OMHq2td2qLhXJoogzOXqVK7iN3Jeb6KP+K3KyFX4gmCckoRE6eKsFT uqB1RsD0V9uv2C4al3IQHCNx2Mdh5VwHm03oUzbte6b/vuhOZZ6CAVmY60eQ03RI faKUi+DSM0icOJqRqxQeBWtJyqvPoWXV4XN9wlaW8WN7RbWOA9o1y7xP+Fgi0j5C c1/8TVi7UuKQsD2q/VL9YyIymsoMhTvPvN3q0i63RuY2AvndAqst4ZoqWelfJw2d uYP4nxICLztnToi+01izGw9hrLZW6fKVpqkmAuqXjPZt6HSisHylWWNG0DzjRSlU TbIwQa6PNLFr5GMT6Ycdvj2Jum2sdRqNkhHjusjD9ZNrpssvVEoqSjndxMjrYkWE MsA9QnUDnyIcW2XkPshKHjWqb4tpps7lvoUNC3mR5w== =CzC9 -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sat Dec 18 19:22:53 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 18 Dec 2010 13:22:53 -0500 Subject: 'Tis the Season -- again. Message-ID: <926E5592-BED6-4A22-89E2-B02FAB584EBF@sixdemonbag.org> Every December I write one of these emails to the list, about how the end of the year makes a good time to reflect on what's happened this year, how much good luck we've had, how much fraternity and community we've enjoyed, and what might happen next year. I feel we've been fortunate to have GnuPG. Just reading the newspapers is enough to give you the willies nowadays: there's all this sensationalism about our constantly eroding privacy, about how governments want ever-extending powers to surveil, how Facebook is luring people into giving up all kinds of personal information just for some virtual currency in Farmville and Mafia Wars, how... Reading this mailing list is a good restorative after reading all of that. It's beautiful to know that people care about privacy, that people care enough to write privacy software and share it freely with the world as their gift to human knowledge. It's beautiful to know we do not have to settle for the world which we are given. It's beautiful to know the outcome of all this is not and never has been preordained. Privacy is one hell of a social battle to be fought, but it can be fought and it can even be won. As disheartening as it might be to realize that privacy is losing, it is also immensely cheering to know it has not lost, and the outcome is still in doubt. This year, as with previous years, I'm donating money to the EFF in honor of GnuPG, the developers, the community, and the privacy fight. I wish I could donate to GnuPG directly, but that's infeasible for a whole lot of reasons and I suspect the EFF is as good a proxy as any. Thank you all. Keep up the good work. :) From david at gbenet.com Sat Dec 18 20:33:25 2010 From: david at gbenet.com (david at gbenet.com) Date: Sat, 18 Dec 2010 19:33:25 +0000 Subject: 'Tis the Season -- again. In-Reply-To: <926E5592-BED6-4A22-89E2-B02FAB584EBF@sixdemonbag.org> References: <926E5592-BED6-4A22-89E2-B02FAB584EBF@sixdemonbag.org> Message-ID: <4D0D0C85.8040400@gbenet.com> Hello Robert, I think the battles for our freedoms is without end. People for societies - they gather together against real and perceived threats. Those societies of men - in working men's club's or of some gentleman's club. Today we live in a very different world - global capitalism - the internet - communication is global socities are global where people gather round shared ideas. Ideas - common values become global - the increased Americanism - the increased control of all forms of media - to share in and be part of the common global experience - to have the "right" views of our world. We are a society - but without Articles of Association - other than a common "right" to send and receive encrypted mail - people find it a useful tool in their daily lives. I suspect a politician to say "we will take this right away from you for the common good because "terrorists" will use it to communicate." There is no such thing as the "common good" there is only vested interests to control what people think what they believe in. It is good to be associated with this list - where the only common factor that binds us to it is that we can and do send encrypted e-mails. I would like to see every Journalist and every NGO and Charity using GNUPG - perhaps we should try and get it onto a free CD available with a popular computing magazine. I have a whole load of links on my web site - though fraturing my skull - I've yet to develop the enthusiasm to do more. We have perceived risks - not real risks of losing our "right" to send and receive encrypted mail - perhaps with the common global spread we will face real threats from those which perceive we need to be told want to think and what to believe. Keep up the good work!! David Robert J. Hansen wrote: > Every December I write one of these emails to the list, about how the end of the year makes a good time to reflect on what's happened this year, how much good luck we've had, how much fraternity and community we've enjoyed, and what might happen next year. > > I feel we've been fortunate to have GnuPG. Just reading the newspapers is enough to give you the willies nowadays: there's all this sensationalism about our constantly eroding privacy, about how governments want ever-extending powers to surveil, how Facebook is luring people into giving up all kinds of personal information just for some virtual currency in Farmville and Mafia Wars, how... > > Reading this mailing list is a good restorative after reading all of that. It's beautiful to know that people care about privacy, that people care enough to write privacy software and share it freely with the world as their gift to human knowledge. It's beautiful to know we do not have to settle for the world which we are given. It's beautiful to know the outcome of all this is not and never has been preordained. Privacy is one hell of a social battle to be fought, but it can be fought and it can even be won. As disheartening as it might be to realize that privacy is losing, it is also immensely cheering to know it has not lost, and the outcome is still in doubt. > > This year, as with previous years, I'm donating money to the EFF in honor of GnuPG, the developers, the community, and the privacy fight. I wish I could donate to GnuPG directly, but that's infeasible for a whole lot of reasons and I suspect the EFF is as good a proxy as any. > > Thank you all. Keep up the good work. :) > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Sat Dec 18 21:26:19 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sat, 18 Dec 2010 15:26:19 -0500 Subject: 'Tis the Season -- again. In-Reply-To: <926E5592-BED6-4A22-89E2-B02FAB584EBF@sixdemonbag.org> References: <926E5592-BED6-4A22-89E2-B02FAB584EBF@sixdemonbag.org> Message-ID: <4D0D18EB.8060809@grant-olson.net> It's also a good time to take care of all those administrative tasks that you've been lazy about. I created an authentication subkey this year and never properly backed it up. Sure I could revoke it and create a new one, but getting the new key onto a bunch of servers will be a pain. Also put FDE on my laptop, but I was running Time Machine on an unencrypted external drive. So now I'm encrypting this 2 TB whopper. Looks like I've got about 1 day, 3 hours, and 28 minutes to go. So ask yourself if you have backups of your critical info. If the backups are up-to-date. If the media is still good. If it's appropriately secured. If you printed out a rev cert. If you're still using the same lame password on every website, even though you know deep down you shouldn't be. Etc... -- Grant "I am gravely disappointed. Again you have made me unleash my dogs of war." From dshaw at jabberwocky.com Mon Dec 20 00:16:54 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 19 Dec 2010 18:16:54 -0500 Subject: clearsign failed: Bad signature In-Reply-To: <1292602957.9417.83.camel@silence.i.fourings.com> References: <4D01EE28.2000304@mozilla-enigmail.org> <4D03834E.4010208@mozilla-enigmail.org> <1292602957.9417.83.camel@silence.i.fourings.com> Message-ID: <7D9D70E0-C25C-4BAD-8B65-F19DCA8AD99C@jabberwocky.com> On Dec 17, 2010, at 11:22 AM, Chris Ruff wrote: > On Sat, 2010-12-11 at 14:57 +0100, Olav Seyfarth wrote: > >> My key: OpenPGP SmartCard v2 key 0x6AE1EF56 (3072 Bit RSA) Card 0005 00000222 >> >> Why can't I use SHA256/SHA512 with this card? >> | enable-dsa2 >> is set and showpref lists > > The documentation for OpenPGP v2 smartcard states that only RIPEMD-160 & > SHA-1 are supported as a digest algorithm at this point in time. You'll > have to change your digest prefs accordingly to use the card. > > excert from doc: > > "Cards with Version < 2.0 sup port RIPEMD-160 and SHA-1 only and may > check it, so other hash algorithms cannot be > used." > > Although I assume it should say =<2.0. Feedback from others if this was > a typo in teh doc and should be =<2.0? That is not a typo. The v2 card works just fine with other algorithms. If it isn't working for you, then there may be an issue, but it is not related to the fact that you are using a v2 card. David From imranoffline at googlemail.com Mon Dec 20 18:58:36 2010 From: imranoffline at googlemail.com (Imran Khan) Date: Mon, 20 Dec 2010 18:58:36 +0100 Subject: multiple trust signatures Message-ID: Hi, Can someone please guide me, if there are multiple trust signatures(tsign) with different trust values and trust depth on the same key k, what values (trust-value and trust-depth) are stored for the key k. For instance : key A----------tsign/3/full ---------->key B -------------tsign/3/full---------->key D \ ^ \---------tsign/2/marginal---> key C------------tsign/2/marginal-------/ i.e. key A assign trust signature to key B with trust value (full) and trust depth(3). key A assign trust signature to key C with trust value (marginal) and trust depth(2). key B assign trust signature to key D with trust value ( full) and and trust depth(3) key C assign trust signature to key D with trust value (marginal) and trust depth(2) and assume that key A is ultimately trusted key. than my understanding and analysis is that if signatures for key D are read in the order of (B, C), Key D's trust value and trust depth will be evaluated on the basis of key C's (last read) signature and will be set to '0' for 'trust-depth' and 'marginal' for 'trust-value'.Have I interpreted it correctly or am I missing something? The question is does it depends on the order by which signatures are evaluated which will eventually store the value from the last signature read? Also can someone please answer whether trust signatures are made on the key or (key,id) pair? Best regards Imran Khan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Mon Dec 20 20:35:47 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 20 Dec 2010 14:35:47 -0500 Subject: multiple trust signatures In-Reply-To: References: Message-ID: <4D0FB013.8080308@fifthhorseman.net> Hi Imran-- you're asking good questions, but your example might be more complicated than you need it to be. More interleaved below: On 12/20/2010 12:58 PM, Imran Khan wrote: > Can someone please guide me, if there are multiple trust > signatures(tsign) with different trust values and trust depth on the same > key k, what values (trust-value and trust-depth) are stored for the key k. Note that there are two underlying questions involved here: ownertrust and calculated validity. GnuPG internally assigns ownertrust to a *key* (that is, "how strongly are we willing to rely on OpenPGP certifications made by this key?"). But validity is calculated over a User ID and its primary key (that is, "How sure are we that this primary key (and consequently, all of its properly-bound subkeys) belongs to the real-world entity referred to by the User ID in question?"). With that in mind... > key A assign trust signature to key B with trust value (full) and trust depth(3). > key A assign trust signature to key C with trust value (marginal) and trust depth(2). > key B assign trust signature to key D with trust value ( full) and and trust depth(3) > key C assign trust signature to key D with trust value (marginal) and trust depth(2) > > and assume that key A is ultimately trusted key In this case, B's certification of D's key+UserID is sufficient on its own for the user to believe that D's key belongs to D's User ID. (this is a question of *calculated validity*.) This is because A's tsig on B implies a delegated full ownertrust of depth >= 1. So much for calculated validity. Let's move on to ownertrust. Directly-assigned (i.e. not via tsigs) full ownertrust is always implicitly of depth 1. That is, we're willing to accept certifications made by this party, but we're not willing to rely on chaining through their tsigs. > my understanding > and analysis is that if signatures for key D are read in the order of (B, > C), Key D's trust value and trust depth will be evaluated on the basis of > key C's (last read) signature and will be set to '0' for 'trust-depth' and > 'marginal' for 'trust-value'.Have I interpreted it correctly or am I > missing something? If this is the behavior you're seeing, it sounds like a bug to me. From the above, i would expect gpg to treat D as having a trust depth of 2 at "full" -- this is because A's delegation to B of (full, depth 3) would drop one depth level, across B's full tsig on D. so the path through B is (full,3)_(full,3) ? (full,2) and the path through C is (marginal,2)_(marginal,2) ? (marginal,1) Combining the two paths should leave us with the strongest trust: (full,2). For a single trust path, i'd expect the chaining rule to be: if you start with: (level_n,depth_n) on X and encounter the next-hop tsig (from X to Y) of (level_m,depth_m), it seems like the trust value for Y should be: (min(level_m,level_n), min((depth_n-1),depth_m)) But if you have multiple independent trust paths to Y, the general merging case is unclear to me. And with non-independent trust paths to Y (i.e. where some paths share more than one node), the merging case is even more unclear. I would think that if any one path resulted in a depth no less than other, and with a higher trust level, the trust values from that path should be chosen. > Also can someone please answer whether trust signatures are made on the key > or (key,id) pair? trust signatures are made over the key+userid pair. i touched on this briefly earlier in the year in my post to gnupg-devel titled: "WoT Proposal: double-counting suppression": http://lists.gnupg.org/pipermail/gnupg-devel/2010-May/025586.html You might also be interested in the spec for trust signatures: https://tools.ietf.org/html/rfc4880#section-5.2.3.13 hope this is helpful, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From imranoffline at googlemail.com Mon Dec 20 22:06:40 2010 From: imranoffline at googlemail.com (Imran Khan) Date: Mon, 20 Dec 2010 22:06:40 +0100 Subject: multiple trust signatures In-Reply-To: <4D0FB013.8080308@fifthhorseman.net> References: <4D0FB013.8080308@fifthhorseman.net> Message-ID: > > > > > key A assign trust signature to key B with trust value (full) and > trust depth(3). > > key A assign trust signature to key C with trust value (marginal) and > trust depth(2). > > key B assign trust signature to key D with trust value ( full) and and > trust depth(3) > > key C assign trust signature to key D with trust value (marginal) and > trust depth(2) > > > > and assume that key A is ultimately trusted key > > In this case, B's certification of D's key+UserID is sufficient on its > own for the user to believe that D's key belongs to D's User ID. (this > is a question of *calculated validity*.) > > This is because A's tsig on B implies a delegated full ownertrust of > depth >= 1. > > So much for calculated validity. Let's move on to ownertrust. > > Directly-assigned (i.e. not via tsigs) full ownertrust is always > implicitly of depth 1. That is, we're willing to accept certifications > made by this party, but we're not willing to rely on chaining through > their tsigs. > > > my understanding > > and analysis is that if signatures for key D are read in the order of (B, > > C), Key D's trust value and trust depth will be evaluated on the basis of > > key C's (last read) signature and will be set to '0' for 'trust-depth' > and > > 'marginal' for 'trust-value'.Have I interpreted it correctly or am I > > missing something? > > If this is the behavior you're seeing, it sounds like a bug to me. From > the above, i would expect gpg to treat D as having a trust depth of 2 at > "full" -- this is because A's delegation to B of (full, depth 3) would > drop one depth level, across B's full tsig on D. > > so the path through B is (full,3)_(full,3) ? (full,2) > > and the path through C is (marginal,2)_(marginal,2) ? (marginal,1) > > Combining the two paths should leave us with the strongest trust: (full,2). > > For a single trust path, i'd expect the chaining rule to be: > > if you start with: > (level_n,depth_n) on X > > and encounter the next-hop tsig (from X to Y) of (level_m,depth_m), it > seems like the trust value for Y should be: > > (min(level_m,level_n), min((depth_n-1),depth_m)) > > But if you have multiple independent trust paths to Y, the general > merging case is unclear to me. And with non-independent trust paths to > Y (i.e. where some paths share more than one node), the merging case is > even more unclear. > > I would think that if any one path resulted in a depth no less than > other, and with a higher trust level, the trust values from that path > should be chosen. > > > Also can someone please answer whether trust signatures are made on the > key > > or (key,id) pair? > > trust signatures are made over the key+userid pair. i touched on this > briefly earlier in the year in my post to gnupg-devel titled: "WoT > Proposal: double-counting suppression": > > http://lists.gnupg.org/pipermail/gnupg-devel/2010-May/025586.html > > You might also be interested in the spec for trust signatures: > > https://tools.ietf.org/html/rfc4880#section-5.2.3.13 > > hope this is helpful, > > --dkg > > Thank you very much for your detail reply but unfortunately it got complex :) Well, let me rephrase, In its simplest form GPG code says that browse all signatures on the (key, id) pair, and if it encounter a trust signature, get trust value from it ,and set it for the current key(not uid), and set trust-depth of the key to 'trust_depth -1' ( in GPG code this is stated in validate_one_keyblock( ) function as: pk->trust_value=sig->trust_value; pk->trust_depth=depth-1;) Now my understanding is that this code, during a validation of keyblock, replace trust-depth and trust-value for the current key(pk) with the values from latest trust signature encountered every time, either on the same or different id of the key (pk). This definitely lead to some erroneous assignments of values, or I must be missing something causing me a confusion. you mentioned some metrics, like (min(level_m,level_n), min((depth_n-1),depth_m)) and in other place u stated, "Combining the two paths should leave us with the strongest trust". Are these your own intuition or these things are mentioned in GPG code somewhere? BR Imran Khan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Mon Dec 20 22:13:48 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 20 Dec 2010 16:13:48 -0500 Subject: multiple trust signatures In-Reply-To: References: <4D0FB013.8080308@fifthhorseman.net> Message-ID: <4D0FC70C.7070101@fifthhorseman.net> On 12/20/2010 04:06 PM, Imran Khan wrote: > you mentioned some metrics, like (min(level_m,level_n), > min((depth_n-1),depth_m)) and in other place u stated, "Combining the two > paths should leave us with the strongest trust". Are these your > own intuition or these things are mentioned in GPG code somewhere? These are my intuitions about how trust path calculations *should* work, not evidence from any particular code. if you're referring to a code path, can you reference the specific version, file, and line numbers you're asking about? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From imranoffline at googlemail.com Mon Dec 20 22:19:20 2010 From: imranoffline at googlemail.com (Imran Khan) Date: Mon, 20 Dec 2010 22:19:20 +0100 Subject: multiple trust signatures In-Reply-To: <4D0FC70C.7070101@fifthhorseman.net> References: <4D0FB013.8080308@fifthhorseman.net> <4D0FC70C.7070101@fifthhorseman.net> Message-ID: version: gnupg-1.4.11 file : trustdb.c function: validate_one_keyblock (...) Br IK On Mon, Dec 20, 2010 at 10:13 PM, Daniel Kahn Gillmor wrote: > On 12/20/2010 04:06 PM, Imran Khan wrote: > > you mentioned some metrics, like (min(level_m,level_n), > > min((depth_n-1),depth_m)) and in other place u stated, "Combining the two > > paths should leave us with the strongest trust". Are these your > > own intuition or these things are mentioned in GPG code somewhere? > > These are my intuitions about how trust path calculations *should* work, > not evidence from any particular code. > > if you're referring to a code path, can you reference the specific > version, file, and line numbers you're asking about? > > --dkg > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcruff at gmail.com Tue Dec 21 13:59:16 2010 From: jcruff at gmail.com (John Ruff) Date: Tue, 21 Dec 2010 07:59:16 -0500 Subject: clearsign failed: Bad signature In-Reply-To: <7D9D70E0-C25C-4BAD-8B65-F19DCA8AD99C@jabberwocky.com> References: <4D01EE28.2000304@mozilla-enigmail.org> <4D03834E.4010208@mozilla-enigmail.org> <1292602957.9417.83.camel@silence.i.fourings.com> <7D9D70E0-C25C-4BAD-8B65-F19DCA8AD99C@jabberwocky.com> Message-ID: On Dec 19, 2010, at 6:16 PM, David Shaw wrote: > On Dec 17, 2010, at 11:22 AM, Chris Ruff wrote: > >> On Sat, 2010-12-11 at 14:57 +0100, Olav Seyfarth wrote: >> >>> My key: OpenPGP SmartCard v2 key 0x6AE1EF56 (3072 Bit RSA) Card >>> 0005 00000222 >>> >>> Why can't I use SHA256/SHA512 with this card? >>> | enable-dsa2 >>> is set and showpref lists >> >> The documentation for OpenPGP v2 smartcard states that only >> RIPEMD-160 & >> SHA-1 are supported as a digest algorithm at this point in time. >> You'll >> have to change your digest prefs accordingly to use the card. >> >> excert from doc: >> >> "Cards with Version < 2.0 sup port RIPEMD-160 and SHA-1 only and may >> check it, so other hash algorithms cannot be >> used." >> >> Although I assume it should say =<2.0. Feedback from others if >> this was >> a typo in teh doc and should be =<2.0? > > That is not a typo. The v2 card works just fine with other > algorithms. If it isn't working for you, then there may be an > issue, but it is not related to the fact that you are using a v2 card. > > David > Interesting, but yes, when I attempt to sign with SHA256 I receive 'gpg: signing failed: Bad signature'. I seem to recall a discussion around this and it wasn't the signing that was failing but rather the post validation check of the newly made signature. I could be wrong. ___________________ Chris Ruff jcruff at gmail.com GPG Key: 0x307A351B4EC4B6A1 FGPR: BF2F 2497 22E7 FEB5 C805 075C 307A 351B 4EC4 B6A1 "No one can see past a choice they don't understand." --The Oracle -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 527 bytes Desc: This is a digitally signed message part URL: From mailinglisten at hauke-laging.de Tue Dec 21 16:17:49 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 21 Dec 2010 16:17:49 +0100 Subject: clearsign failed: Bad signature In-Reply-To: References: <4D01EE28.2000304@mozilla-enigmail.org> <7D9D70E0-C25C-4BAD-8B65-F19DCA8AD99C@jabberwocky.com> Message-ID: <201012211617.49421.mailinglisten@hauke-laging.de> Am Dienstag 21 Dezember 2010 13:59:16 schrieb John Ruff: > >> "Cards with Version < 2.0 sup port RIPEMD-160 and SHA-1 only and may > >> check it, so other hash algorithms cannot be > >> used." > around this and it wasn't the signing that was failing but rather the > post validation check of the newly made signature. I could be wrong. It seems that I have not understood the process of signing correctly. Does the smardcard create the hash value? Does not make sense IMHO. Or is this about the length of the value to be signed? And I have no idea how tha smartcard could be involved in checking a signature as you don't need the secret key for that. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From ueno at unixuser.org Wed Dec 22 09:55:24 2010 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 22 Dec 2010 17:55:24 +0900 Subject: gpg --list-secret-keys does not skip revoked keys Message-ID: Hi, I noticed that gpg --list-secret-keys skips expired keys but not revoked keys. For example, when I have two keys (one is expired and another is revoked): $ gpg --list-keys A6CC6651 D1458906 pub 2048R/A6CC6651 2010-11-10 [expired: 2010-11-17] uid Daiki Ueno pub 2048R/D1458906 2010-12-22 [revoked: 2010-12-22] uid Daiki Ueno $ gpg --list-secret-keys A6CC6651 D1458906 sec 2048R/D1458906 2010-12-22 uid Daiki Ueno ssb 2048R/AE471CB5 2010-12-22 Is this an intended behavior? Also, if I supply the revoked key to say gpg --sign, it simply fails: $ gpg --sign -u D1458906 < /dev/null gpg: skipped "D1458906": unusable secret key gpg: signing failed: unusable secret key BTW, I'm wondering if there is any reason why the validity field (Field 2 of --with-colons output) is not used for secret keys. It might be useful for the libraries which call gpg internally (epg.el I mean :) to check if a key is usable. Currently we need to run gpg --list-keys followed by gpg --list-secret-keys. Regards, -- Daiki Ueno From aaron.toponce at gmail.com Thu Dec 23 01:08:33 2010 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Wed, 22 Dec 2010 17:08:33 -0700 Subject: Mutt not showing signature flag Message-ID: <20101223000833.GV16774@poseidon.cocyt.us> This really is a post for the mutt-users mailing list, but I'm not getting the response there that I think is accurate, so I'm posting here, hoping mapbe another user on this list has experinced the same issue and what they did to fix it. As the subject says, the signature flag is not showing in the index. Well, that's not entirely true. It will show after I view the signed message in the pager then go back to the index tree. This is entirely inconsistent with the rest of the mailboxes I subscribe to. With every other mailbox, the 's', 'S' or 'P' flags show, as expected when a message is signed. Not for the gnupg-users list. Anyone else who's a mutt user experience this inconsistency? I'm familiar with both inline and PGP/MIME signatures. I've been signing my personal mail since 2004 when I created my key. Why do I not see the signature flags for this mailbox until after viewing the message in mutt? Thanks, -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: Digital signature URL: From simon at bleah.co.uk Thu Dec 23 12:59:49 2010 From: simon at bleah.co.uk (Simon Ward) Date: Thu, 23 Dec 2010 11:59:49 +0000 Subject: Mutt not showing signature flag In-Reply-To: <20101223000833.GV16774@poseidon.cocyt.us> References: <20101223000833.GV16774@poseidon.cocyt.us> Message-ID: <20101223115946.GB10648@penfold.cosgrove.lan> On Wed, Dec 22, 2010 at 05:08:33PM -0700, Aaron Toponce wrote: > As the subject says, the signature flag is not showing in the index. > Well, that's not entirely true. It will show after I view the signed > message in the pager then go back to the index tree. [?] > Anyone else who's a mutt user experience this inconsistency? I'm > familiar with both inline and PGP/MIME signatures. Now that you mention it, this does happen for me too, both for inline PGP and PGP/MIME, also for S/MIME. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.?John Gall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From simon at bleah.co.uk Thu Dec 23 14:59:11 2010 From: simon at bleah.co.uk (Simon Ward) Date: Thu, 23 Dec 2010 13:59:11 +0000 Subject: Mutt not showing signature flag In-Reply-To: <20101223115946.GB10648@penfold.cosgrove.lan> References: <20101223000833.GV16774@poseidon.cocyt.us> <20101223115946.GB10648@penfold.cosgrove.lan> Message-ID: <20101223135911.GA18607@penfold.cosgrove.lan> On Thu, Dec 23, 2010 at 11:59:49AM +0000, Simon Ward wrote: > On Wed, Dec 22, 2010 at 05:08:33PM -0700, Aaron Toponce wrote: > > As the subject says, the signature flag is not showing in the index. > > Well, that's not entirely true. It will show after I view the signed > > message in the pager then go back to the index tree. > [?] > > Anyone else who's a mutt user experience this inconsistency? I'm > > familiar with both inline and PGP/MIME signatures. > > Now that you mention it, this does happen for me too, both for inline > PGP and PGP/MIME, also for S/MIME. After a little investigation I believe signed mails that have had signatures from mailing lists attached are not decoded until you view the message. I?m guessing that Mutt only checks for Content-Type multipart/signed, but these messages are multipart/mixed. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.?John Gall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From aaron.toponce at gmail.com Thu Dec 23 16:29:33 2010 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Thu, 23 Dec 2010 08:29:33 -0700 Subject: Mutt not showing signature flag In-Reply-To: <20101223135911.GA18607@penfold.cosgrove.lan> References: <20101223000833.GV16774@poseidon.cocyt.us> <20101223115946.GB10648@penfold.cosgrove.lan> <20101223135911.GA18607@penfold.cosgrove.lan> Message-ID: <20101223152933.GX16774@poseidon.cocyt.us> On Thu, Dec 23, 2010 at 01:59:11PM +0000, Simon Ward wrote: > After a little investigation I believe signed mails that have had > signatures from mailing lists attached are not decoded until you view > the message. I?m guessing that Mutt only checks for Content-Type > multipart/signed, but these messages are multipart/mixed. I want to believe that, but it's not the case, at least not for me. On say the debian-devel mailing list, I can see the signature flag on the message before I fetch it (I only cache the headers). ... now that I think about it, is the gnupg-users mailing list modifying mail headers and stripping/modifying PGP info? As you mentioned, changing from multipart/signed to multipart/mixed, which would prevent the signature flags from showing until after you view the message in the pager? -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: Digital signature URL: From simon at bleah.co.uk Thu Dec 23 16:49:27 2010 From: simon at bleah.co.uk (Simon Ward) Date: Thu, 23 Dec 2010 15:49:27 +0000 Subject: Mutt not showing signature flag In-Reply-To: <20101223152933.GX16774@poseidon.cocyt.us> References: <20101223000833.GV16774@poseidon.cocyt.us> <20101223115946.GB10648@penfold.cosgrove.lan> <20101223135911.GA18607@penfold.cosgrove.lan> <20101223152933.GX16774@poseidon.cocyt.us> Message-ID: <20101223154926.GA30124@penfold.cosgrove.lan> On Thu, Dec 23, 2010 at 08:29:33AM -0700, Aaron Toponce wrote: > On Thu, Dec 23, 2010 at 01:59:11PM +0000, Simon Ward wrote: > > After a little investigation I believe signed mails that have had > > signatures from mailing lists attached are not decoded until you view > > the message. I?m guessing that Mutt only checks for Content-Type > > multipart/signed, but these messages are multipart/mixed. > > I want to believe that, but it's not the case, at least not for me. On > say the debian-devel mailing list, I can see the signature flag on the > message before I fetch it (I only cache the headers). I suppose I should have been more clear, especially given we are talking about cryptographic signatures. When I said ?signatures from mailing lists?, I meant the plain text footers that get appended to single messages. With PGP/MIME signed messages sent to (at least GNU Mailman) lists that add footers, the mail is wrapped in another MIME message of type multipart/mixed, and another part containing the signature is added. I?m not on debian-devel, but none of the Debian lists I am on appear to attach these footers. Indeed, looking at the debian-devel archives, that list doesn?t either. > ... now that I think about it, is the gnupg-users mailing list modifying > mail headers and stripping/modifying PGP info? The information isn?t lost in the above case, just contained in a MIME subpart. > As you mentioned, changing from multipart/signed to multipart/mixed, > which would prevent the signature flags from showing until after you > view the message in the pager? Yes, I think this is what is happening. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.?John Gall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rjh at sixdemonbag.org Thu Dec 23 21:20:55 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Dec 2010 15:20:55 -0500 Subject: Block cipher mode? In-Reply-To: References: Message-ID: <4D13AF27.9090004@sixdemonbag.org> On 12/23/10 1:26 PM, smu johnson wrote: > I was wondering what anyone thought of including which block cipher > mode gpg uses in the -v[erbose] mode. OpenPGP specifies a kind of messed-up and strange variant of CFB. Don't get me wrong, it /is/ a CFB mode, it's just messed-up and strange. Cryptanalytically strong, just very much different from what most people call CFB mode. From ueno at unixuser.org Fri Dec 24 03:47:13 2010 From: ueno at unixuser.org (Daiki Ueno) Date: Fri, 24 Dec 2010 11:47:13 +0900 Subject: gpg --list-secret-keys does not skip revoked keys In-Reply-To: (Daiki Ueno's message of "Wed, 22 Dec 2010 17:55:24 +0900") References: Message-ID: Daiki Ueno writes: > BTW, I'm wondering if there is any reason why the validity field (Field > 2 of --with-colons output) is not used for secret keys. It might be > useful for the libraries which call gpg internally (epg.el I mean :) to > check if a key is usable. Actually, it looks that GPGME ignores the validity when listing keys with SECRET_ONLY flag. Here is a sample program: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: list-key-validity.c URL: -------------- next part -------------- I get: $ ./list-key-validity A6CC6651 D1458906 084B0E86A6CC6651 (pub) revoked = 0, expired = 1 892F1451D1458906 (pub) revoked = 1, expired = 0 892F1451D1458906 (sec) revoked = 0, expired = 0 Maybe I'm missing some points of the OpenPGP concept. Regards, -- Daiki Ueno From dshaw at jabberwocky.com Fri Dec 24 18:57:16 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 24 Dec 2010 12:57:16 -0500 Subject: Block cipher mode? In-Reply-To: <4D13AF27.9090004@sixdemonbag.org> References: <4D13AF27.9090004@sixdemonbag.org> Message-ID: On Dec 23, 2010, at 3:20 PM, Robert J. Hansen wrote: > On 12/23/10 1:26 PM, smu johnson wrote: >> I was wondering what anyone thought of including which block cipher >> mode gpg uses in the -v[erbose] mode. > > OpenPGP specifies a kind of messed-up and strange variant of CFB. Don't > get me wrong, it /is/ a CFB mode, it's just messed-up and strange. > Cryptanalytically strong, just very much different from what most people > call CFB mode. One of my vague desires for a "someday we'll do that" is to use a standard cipher mode in OpenPGP. It's not a security issue (as you say, OpenPGP's CFB is strong), but it avoids the question, which has a benefit all its own. Maybe in V5.... David From marcio.barbado at gmail.com Tue Dec 28 14:35:39 2010 From: marcio.barbado at gmail.com (Marcio B. Jr.) Date: Tue, 28 Dec 2010 11:35:39 -0200 Subject: Fyi: keysigning parties in Brazil Message-ID: Hi, this wiki, maintained by "Associa??o Software Livre", is dedicated to coordinate (and subsequently, list) all of the keysigning parties in Brazil: http://wiki.softwarelivre.org/KSP/WebHomeEn regards, and a harmonious 2011 to you all, Marcio Barbado, Jr. From julius.remigio at cymetrix.com Tue Dec 28 20:55:05 2010 From: julius.remigio at cymetrix.com (Julius Remigio) Date: Tue, 28 Dec 2010 11:55:05 -0800 Subject: Thread-Safety on Windows Message-ID: I am using the 1.4.11 binary for windows. I would like to know if it is thread-safe? I am deploying this in a production machine where multiple instance of gpg will be called simultaneously for encrypting and decrypting. Thanks, -Julius -------------- next part -------------- An HTML attachment was scrubbed... URL: From freejack at is-not-my.name Wed Dec 29 18:10:10 2010 From: freejack at is-not-my.name (freejack at is-not-my.name) Date: Wed, 29 Dec 2010 17:10:10 -0000 Subject: How to process a big file of encrypted mails? Message-ID: <20101229171010.jvqsci@is-not-my.name> Hi, Occasionally I get a big file of encrypted emails with mail headers stripped out. All thats in the file is the begin and end PGP marks and all the encrypted armored text in between. Some are encrypted to me, others to my coworkers. Sometimes if I do gpg filename it finds all my mails and asks for my password etc sometimes it doesn't. Is there anyway to tell gpg to keep processing the entire file all the way until the end? Each of us in the team will need to do the same thing to get his own emails. I didn't see any option for gpg to carry on till it processes the entire file. Someone said we should write a script to parse all the messages into individual files and then do gpg on each one and that's what i'll do if there isn't a way to get gpg to scan the whole file. Thanks. From rjh at sixdemonbag.org Wed Dec 29 19:51:20 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 29 Dec 2010 13:51:20 -0500 Subject: How to process a big file of encrypted mails? In-Reply-To: <20101229171010.jvqsci@is-not-my.name> References: <20101229171010.jvqsci@is-not-my.name> Message-ID: <4D1B8328.7030701@sixdemonbag.org> On 12/29/2010 12:10 PM, freejack at is-not-my.name wrote: > Someone said we should write a script to parse all the messages into > individual files and then do gpg on each one and that's what i'll do > if there isn't a way to get gpg to scan the whole file. We will have an easier time helping you if we have more information. Such as, is only inline encoding used? Is PGP/MIME ever used? Which operating system are you running? Which version of GnuPG are you using? Etc. From dougb at dougbarton.us Wed Dec 29 20:28:24 2010 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 29 Dec 2010 11:28:24 -0800 Subject: How to process a big file of encrypted mails? In-Reply-To: <20101229171010.jvqsci@is-not-my.name> References: <20101229171010.jvqsci@is-not-my.name> Message-ID: <4D1B8BD8.1020903@dougbarton.us> On 12/29/2010 09:10, freejack at is-not-my.name wrote: > Hi, > > Occasionally I get a big file of encrypted emails with mail headers > stripped out. All thats in the file is the begin and end PGP marks and all > the encrypted armored text in between. Some are encrypted to me, others to > my coworkers. Sometimes if I do gpg filename it finds all my mails and asks > for my password etc sometimes it doesn't. Is there anyway to tell gpg to > keep processing the entire file all the way until the end? Each of us in > the team will need to do the same thing to get his own emails. I didn't see > any option for gpg to carry on till it processes the entire file. I think you're right about that. > Someone said we should write a script to parse all the messages into > individual files and then do gpg on each one and that's what i'll do if > there isn't a way to get gpg to scan the whole file. Yes, that's likely your only alternative. If you're on a Unix'y system I suggest looking at split, which might be spelt "csplit" if you're on Linux. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From freejack at is-not-my.name Wed Dec 29 22:03:59 2010 From: freejack at is-not-my.name (freejack at is-not-my.name) Date: Wed, 29 Dec 2010 21:03:59 -0000 Subject: How to process a big file of encrypted mails? References: <4D1B8328.7030701__18593.9417839565$1293648750$gmane$org@sixdemonbag.org> Message-ID: <20101229210359.pabjvp@is-not-my.name> "Robert J. Hansen" wrote: > On 12/29/2010 12:10 PM, freejack at is-not-my.name wrote: > > Someone said we should write a script to parse all the messages into > > individual files and then do gpg on each one and that's what i'll do > > if there isn't a way to get gpg to scan the whole file. > > We will have an easier time helping you if we have more information. > Such as, is only inline encoding used? Is PGP/MIME ever used? Which > operating system are you running? Which version of GnuPG are you using? > Etc. Ah snap...yes only inline coding, no PGP/MIME as far as the guys know. We're using Linux and recent versions of gpg such as 1.4.9 and newer. Thanks! From rjh at sixdemonbag.org Wed Dec 29 22:51:56 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 29 Dec 2010 16:51:56 -0500 Subject: How to process a big file of encrypted mails? In-Reply-To: <20101229210359.pabjvp@is-not-my.name> References: <4D1B8328.7030701__18593.9417839565$1293648750$gmane$org@sixdemonbag.org> <20101229210359.pabjvp@is-not-my.name> Message-ID: <4D1BAD7C.7030207@sixdemonbag.org> On 12/29/2010 4:03 PM, freejack at is-not-my.name wrote: > Ah snap...yes only inline coding, no PGP/MIME as far as the guys know. > We're using Linux and recent versions of gpg such as 1.4.9 and newer. Makes it a lot easier. Yeah, your best bet here is probably some scripted solution. Shouldn't be too hard: an hour or two of $weapon_of_choice should do the job. (For non-programmers, $weapon_of_choice can be read as "your preferred programming language, and I really don't want to get into arguments about which one people /should/ prefer.") From freejack at is-not-my.name Thu Dec 30 11:40:52 2010 From: freejack at is-not-my.name (freejack at is-not-my.name) Date: Thu, 30 Dec 2010 10:40:52 -0000 Subject: How to process a big file of encrypted mails? References: <4D1B8BD8.1020903__6823.55037793076$1293650988$gmane$org@dougbarton.us> Message-ID: <20101230104052.pgavce@is-not-my.name> Right then. Thanks Robert and Doug. Happy New Years to all! Cheers! From jziff at sindegra.com Fri Dec 31 22:37:46 2010 From: jziff at sindegra.com (Joseph Isadore Ziff) Date: Fri, 31 Dec 2010 16:37:46 -0500 Subject: Problem Compiling gpgme: link error stuff Message-ID: <20101231163746.28d15fdc.jziff@sindegra.com> Hello, I'm having trouble compiling gpgme. What follows is part of my cmd line: ./configure --prefix=/usr <...> config.status: executing depfiles commands config.status: executing libtool commands GPGME v1.3.0 has been configured as follows: GnuPG path: /usr/bin/gpg GnuPG version: 2.0.16, min. 1.4.0 GpgSM path: /usr/bin/gpgsm GpgSM version: 2.0.16, min. 1.9.6 GpgConf path: /usr/bin/gpgconf GpgConf version: 2.0.16, min. 2.0.4 G13 path: no G13 version: unknown, min. 2.1.0 Assuan version: 2.0.1 UI Server: no FD Passing: GPGME Pthread: yes GPGME Pth: yes <...> make <...> /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-thread1 t-thread1.o ../../src/libgpgme-pthread.la libtool: link: gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o .libs/t-thread1 t-thread1.o ../../src/.libs/libgpgme-pthread.so /usr/bin/ld: t-thread1.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /usr/bin/ld: note: 'pthread_create@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[3]: *** [t-thread1] Error 1 make[3]: Leaving directory `/home/sindegra/Source/gnupg2/gpgme-1.3.0/tests/gpg' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sindegra/Source/gnupg2/gpgme-1.3.0/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sindegra/Source/gnupg2/gpgme-1.3.0' make: *** [all] Error 2 I do not know how to add the libary to the linker command line. I confess I am not so knowledgeable about these kind of things. Any advice? Sincerely, Joseph Isadore Ziff , , This email was signed for authenticity with GnuPG version 2.0.16. See http://www.gnupg.org for information on state-of-the-art secure signing and encryption software compatible with the openPGP standard. Reclaim your right to privacy now. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jziff at sindegra.com Fri Dec 31 22:00:27 2010 From: jziff at sindegra.com (Joseph Isadore Ziff) Date: Fri, 31 Dec 2010 16:00:27 -0500 Subject: Problem Compiling gpgme: link error stuff Message-ID: <20101231160027.d5d57bba.jziff@sindegra.com> Hello, I'm having trouble compiling gpgme. What follows is part of my cmd line: ./configure --prefix=/usr <...> config.status: executing depfiles commands config.status: executing libtool commands GPGME v1.3.0 has been configured as follows: GnuPG path: /usr/bin/gpg GnuPG version: 2.0.16, min. 1.4.0 GpgSM path: /usr/bin/gpgsm GpgSM version: 2.0.16, min. 1.9.6 GpgConf path: /usr/bin/gpgconf GpgConf version: 2.0.16, min. 2.0.4 G13 path: no G13 version: unknown, min. 2.1.0 Assuan version: 2.0.1 UI Server: no FD Passing: GPGME Pthread: yes GPGME Pth: yes <...> make <...> /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-thread1 t-thread1.o ../../src/libgpgme-pthread.la libtool: link: gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o .libs/t-thread1 t-thread1.o ../../src/.libs/libgpgme-pthread.so /usr/bin/ld: t-thread1.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /usr/bin/ld: note: 'pthread_create@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[3]: *** [t-thread1] Error 1 make[3]: Leaving directory `/home/sindegra/Source/gnupg2/gpgme-1.3.0/tests/gpg' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sindegra/Source/gnupg2/gpgme-1.3.0/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sindegra/Source/gnupg2/gpgme-1.3.0' make: *** [all] Error 2 I do not know how to add the libary to the linker command line. I confess I am not so knowledgeable about these kind of things. Any advice? Sincerely, Joseph Isadore Ziff , , This email was signed for authenticity with GnuPG version 2.0.16. See http://www.gnupg.org for information on state-of-the-art secure signing and encryption software compatible with the openPGP standard. Reclaim your right to privacy now. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mel.gordon at wellnow.com Fri Dec 31 02:17:12 2010 From: mel.gordon at wellnow.com (Mel) Date: Thu, 30 Dec 2010 20:17:12 -0500 Subject: gnupg-2.0.16 problems when runing MAKE !!! H-E-L-P !!! Message-ID: <20101230201712.7f2d80f4@wellnow.com> Hi Users, I've spent all week trying to get either gnupg-2.0.16 or gnupg-2.0.15 to make on my system....no luck. I have googled the problem, and tried every suggestion...no luck. I'm running CentOS x86_64. I've tried both rpm's, and the tar files. I've had to pull the rpm's which are behind my version of claws-mail 3.7.8 INSTALLED: libgpg-error (ftp://ftp.gnupg.org/gcrypt/libgpg-error/) libgcrypt (ftp://ftp.gnupg.org/gcrypt/libgcrypt/) libksba (ftp://ftp.gnupg.org/gcrypt/libksba/) libassuan >= 2.0 (ftp://ftp.gnupg.org/gcrypt/libassuan/) All my passwords were encryted before I upgraded the gnupg program. Really need to be able to access my password ! If I try some of the configure options it complains about unable to open shared linraries of libassuan...even when using "export PKG_CONFIG_PATH" to indicate exactly where they are ?? I'm at my wits end...any help would be greatly appreciated. Sincerely, Mel G. Below is results of configure, and trying to run MAKE: ------------------------------------------------------------- checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu configure: autobuild project... gnupg configure: autobuild revision... 2.0.16 configure: autobuild hostname... localhost.localdomain configure: autobuild timestamp... 20101230-200518 checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether SELinux support is requested... no checking whether to enable the BZIP2 compression algorithm... yes checking whether to enable external program execution... yes checking whether to enable photo ID viewing... yes checking whether to use a fixed photo ID viewer... no checking whether to enable external keyserver helpers... yes checking whether LDAP keyserver support is requested... yes checking whether HKP keyserver support is requested... yes checking whether finger key fetching support is requested... yes checking whether generic object key fetching support is requested... yes checking whether email keyserver support is requested... no checking whether keyserver exec-path is enabled... yes checking for the size of the key and uid cache... 4096 checking whether use of capabilities is requested... no checking whether to enable the internal CCID driver... yes checking whether to enable maintainer-specific portions of Makefiles... no configure: checking for programs checking whether make sets $(MAKE)... (cached) yes checking whether build environment is sane... yes checking for gawk... (cached) gawk checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking dependency style of gcc... (cached) gcc3 checking how to run the C preprocessor... gcc -E checking whether gcc and cc understand -c and -o together... yes checking whether ln -s works... yes checking for ranlib... ranlib checking for ar... ar checking for perl... /usr/bin/perl checking for windres... no checking for strerror in -lcposix... no checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for faqprog.pl... no checking for tar... /bin/tar checking whether /bin/tar speaks USTAR... yes checking for cc for build... gcc checking whether to use a standard socket by default... no configure: checking for libraries checking for gpg-error-config... /usr/local/bin/gpg-error-config checking for GPG Error - version >= 1.7... yes (1.10) checking for libgcrypt-config... /usr/local/bin/libgcrypt-config checking for LIBGCRYPT - version >= 1.4.0... yes (1.4.6) checking LIBGCRYPT API version... okay checking for libassuan-config... /usr/local/bin/libassuan-config checking for LIBASSUAN - version >= 2.0.0... yes (2.0.1) checking LIBASSUAN API version... okay checking for ksba-config... /usr/local/bin/ksba-config checking for KSBA - version >= 1.0.7... yes (1.1.0) checking KSBA API version... okay checking for usb_bulk_write in -lusb... yes checking for usb_create_match... no checking for library containing dlopen... -ldl checking for openpty in -lutil... yes checking for shred... /usr/bin/shred checking for pth-config... /usr/bin/pth-config checking for PTH - version >= 1.3.7... yes checking whether PTH installation is sane... yes configure: checking for networking options checking for gethostbyname... yes checking for setsockopt... yes checking adns.h usability... no checking adns.h presence... no checking for adns.h... no checking for adns_free... no checking for library containing res_query... no checking for library containing __res_query... -lresolv checking for library containing dn_expand... no checking for library containing __dn_expand... none required checking for library containing dn_skipname... no checking for library containing __dn_skipname... none required checking whether the resolver is usable... yes checking whether LDAP via "-lldap" is present and sane... yes checking for ldap_get_option... yes checking for ldap_set_option... yes checking for ldap_start_tls_s... yes checking for ldap_start_tls_sA... no checking for gawk... (cached) gawk checking for curl-config... /usr/bin/curl-config checking for the version of libcurl... 7.15.5 checking for libcurl >= version 7.10... yes checking whether libcurl is usable... yes checking for curl_free... yes checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking for iconv... yes checking for working iconv... yes checking for iconv declaration... install-shextern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); configure: checking for gettext checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for CFPreferencesCopyAppValue... no checking for CFLocaleCopyCurrent... no checking for GNU gettext in libc... yes checking whether to use NLS... yes checking where the gettext function comes from... libc checking for strchr... yes checking for nl_langinfo and CODESET... yes checking for LC_MESSAGES... yes configure: checking for header files checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking termio.h usability... yes checking termio.h presence... yes checking for termio.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking pty.h usability... yes checking pty.h presence... yes checking for pty.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking for inttypes.h... (cached) yes checking whether time.h and sys/time.h may both be included... yes configure: checking for system characteristics checking for an ANSI C-conforming const... yes checking for inline... inline checking for working volatile... yes checking for size_t... yes checking for mode_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for unistd.h... (cached) yes checking for wchar.h... yes checking for stdint.h... (cached) yes checking for socklen_t... yes checking endianess... little checking for byte typedef... no checking for ushort typedef... yes checking for ulong typedef... yes checking for u16 typedef... no checking for u32 typedef... no checking size of unsigned short... 2 checking size of unsigned int... 4 checking size of unsigned long... 8 checking size of unsigned long long... 8 checking size of time_t... 8 checking for UINT64_C... yes checking size of uint64_t... 8 configure: checking for library functions checking whether getpagesize is declared... yes checking for _LARGEFILE_SOURCE value needed for large files... no checking for vprintf... yes checking for _doprnt... no checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for strerror... yes checking for strlwr... no checking for tcgetattr... yes checking for mmap... yes checking for strcasecmp... yes checking for strncasecmp... yes checking for ctermid... yes checking for times... yes checking for gmtime_r... yes checking for unsetenv... yes checking for fcntl... yes checking for ftruncate... yes checking for gettimeofday... yes checking for getrusage... yes checking for getrlimit... yes checking for setrlimit... yes checking for clock_gettime... no checking for atexit... yes checking for raise... yes checking for getpagesize... yes checking for strftime... yes checking for nl_langinfo... yes checking for setlocale... yes checking for waitpid... yes checking for wait4... yes checking for sigaction... yes checking for sigprocmask... yes checking for pipe... yes checking for stat... yes checking for getaddrinfo... yes checking for ttyname... yes checking for rand... yes checking for ftello... yes checking for fsync... yes checking for struct sigaction... yes checking for sigset_t... yes checking for memicmp... no checking for stpcpy... yes checking for strsep... yes checking for strlwr... (cached) no checking for strtoul... yes checking for memmove... yes checking for stricmp... no checking for strtol... yes checking for memrchr... yes checking for isascii... yes checking for timegm... yes checking for getrusage... (cached) yes checking for setrlimit... (cached) yes checking for stat... (cached) yes checking for setlocale... (cached) yes checking for flockfile... yes checking for funlockfile... yes checking for fopencookie... yes checking for funopen... no checking for getpwnam... yes checking for getpwuid... yes checking for working alloca.h... yes checking for alloca... yes checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for long long int... yes checking for long double... yes checking whether stat file-mode macros are broken... no checking for unsigned long long int... yes checking for mkdtemp... yes checking for setenv... yes checking for unsetenv... (cached) yes checking for unsetenv() return type... int checking for stdint.h... (cached) yes checking for SIZE_MAX... yes checking absolute name of ... ///usr/include/stdint.h checking whether stdint.h conforms to C99... yes checking for strpbrk... yes checking for unistd.h... (cached) yes checking for stdint.h... (cached) yes checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking if mkdir takes one argument... no checking whether regular expression support is requested... yes checking for library containing regcomp... none required checking for regcomp... yes checking whether your system's regexp library is broken... no checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for deflateInit2_ in -lz... yes checking for bzlib.h... no checking whether readline via "-lreadline" is present and sane... no checking whether readline via "-lreadline -ltermcap" is present and sane... no checking whether readline via "-lreadline -lcurses" is present and sane... no checking whether readline via "-lreadline -lncurses" is present and sane... no configure: checking for cc features checking if gcc supports -Wno-pointer-sign... yes checking if gcc supports -Wpointer-arith... yes configure: checking system features for estream-printf checking for stdint.h... (cached) yes checking for long long int... (cached) yes checking for long double... yes checking for intmax_t... yes checking for uintmax_t... yes checking for ptrdiff_t... yes checking size of unsigned long... (cached) 8 checking size of void *... 8 checking for nl_langinfo and THOUSANDS_SEP... yes configure: checking system features for estream configure: creating ./config.status config.status: creating m4/Makefile config.status: creating Makefile config.status: creating po/Makefile.in config.status: creating gl/Makefile config.status: creating include/Makefile config.status: creating jnlib/Makefile config.status: creating common/Makefile config.status: creating kbx/Makefile config.status: creating g10/Makefile config.status: creating sm/Makefile config.status: creating agent/Makefile config.status: creating scd/Makefile config.status: creating keyserver/Makefile config.status: creating keyserver/gpg2keys_mailto config.status: creating keyserver/gpg2keys_test config.status: creating tools/gpg-zip config.status: creating tools/Makefile config.status: creating doc/Makefile config.status: creating tests/Makefile config.status: creating tests/openpgp/Makefile config.status: creating tests/pkits/Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing po-directories commands config.status: creating po/POTFILES config.status: creating po/Makefile GnuPG v2.0.16 has been configured as follows: Platform: GNU/Linux (x86_64-unknown-linux-gnu) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes Protect tool: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) FINAL RESULT GIVEN FROM MAKE: /'`status.c status.c:25:26: error: status-codes.h: No such file or directory status.c: In function ?get_status_string?: status.c:32: warning: implicit declaration of function ?statusstr_msgidxof? status.c:36: error: ?statusstr_msgstr? undeclared (first use in this function) status.c:36: error: (Each undeclared identifier is reported only once status.c:36: error: for each function it appears in.) status.c:36: error: ?statusstr_msgidx? undeclared (first use in this function) make[3]: *** [libcommon_a-status.o] Error 1 make[3]: Leaving directory `/usr/share/gnupg-2.0.16/common' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/share/gnupg-2.0.16/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/share/gnupg-2.0.16' make: *** [all] Error 2