From peter at digitalbrains.com Sun Dec 1 11:12:00 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 01 Dec 2013 11:12:00 +0100 Subject: Aw: Re: multiple keys with different UIDs and common WoT? In-Reply-To: References: , <529A5D1D.4030805@digitalbrains.com> Message-ID: <529B0B70.50802@digitalbrains.com> On 30/11/13 23:42, Klaus wrote: > Ok, this will fix the WoT from my perspective. What about other users > importing my work key? Yes, you are of course correct. I forgot the other side for a moment :). How about this: - On your work PC, you only have the secret subkeys (signing and encryption) of your work keypair. The master key (for certification) is held securely at your home. - You ask people, when they certify you, to certify both keys. It's a rare event, it's not that big of a burden all in all. - When you switch jobs, you revoke the existing subkeys, the ones where the secret material was on the work PC. You create new subkeys for signing and encryption and place those on your new work PC. That way, the IT department of the company (or other people with access to your work PC) will only gain access to work-related stuff /for that company/. Once you go work for the competitor, they can no longer access any new work-related stuff which is encrypted to the new subkey. Your secret master key never enters the premises of the company you work for, and other people certify that master key, so you don't lose the certifications when you switch jobs. > That shouldn't be a problem, as long as I don't ask people to sign my work > key and don't sign with my work key. You are a lot more free than that. Other people can sign both keys, and you can sign other people's keys with either of your master keys. You just shouldn't sign a key with /both/, if you want to keep the famous "some people" happy. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun Dec 1 11:30:58 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 01 Dec 2013 11:30:58 +0100 Subject: Aw: Re: multiple keys with different UIDs and common WoT? In-Reply-To: <529B0B70.50802@digitalbrains.com> References: , <529A5D1D.4030805@digitalbrains.com> <529B0B70.50802@digitalbrains.com> Message-ID: <529B0FE2.4070104@digitalbrains.com> On 01/12/13 11:12, Peter Lebbing wrote: > - You ask people, when they certify you, to certify both keys. It's a rare > event, it's not that big of a burden all in all. A small detail I forgot to mention: people sign key/UID pairs. Obviously when you have an UID "Klaus " and you go work for employer2, that UID should be revoked and you will lose signatures on that UID. But you can also[1] add an UID "Klaus", without e-mail, and get that certified. That UID will still be valid, and there are multiple options for people sending you mail to : - They see your UID "Klaus" and select the key manually from their mail client - They see your UID "Klaus" and make a local signature on the other UID to make it valid[2] - You ask the people who signed your UID "Klaus" to please also sign the new UID to get it back in the WoT. You never changed your key (or your name), their certification is still the same, you just added an e-mail address. People can choose how they wish to verify that information, f.e. by sending their new signature encrypted to your key, to that e-mail address. But since you never changed the key, they don't need to do a full verification (identity and fingerprint). I think the last solution is the best. It has the downside that other people have to actually do it. Hmm, not such a small detail after all! HTH, Peter. [1] I'm not being literal here, I mean an UID with your full name, not just Klaus :). [2] This method has its downsides, for instance maintenance. What if the signatures that made "Klaus" valid are revoked for some reason? Your local sig is not automatically revoked as well, so the other UID stays valid even though the WoT basis for the validity is removed. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From gpgml at gmx-topmail.de Sun Dec 1 12:42:16 2013 From: gpgml at gmx-topmail.de (Klaus) Date: Sun, 1 Dec 2013 12:42:16 +0100 (CET) Subject: Aw: Re: Re: multiple keys with different UIDs and common WoT? In-Reply-To: <529B0FE2.4070104@digitalbrains.com> References: , <529A5D1D.4030805@digitalbrains.com> <529B0B70.50802@digitalbrains.com>, <529B0FE2.4070104@digitalbrains.com> Message-ID: > From: "Peter Lebbing" > > - You ask people, when they certify you, to certify both keys. It's a rare > > event, it's not that big of a burden all in all. > > A small detail I forgot to mention: people sign key/UID pairs. Obviously when > you have an UID "Klaus " and you go work for employer2, that > UID should be revoked and you will lose signatures on that UID. But you can > also[1] add an UID "Klaus", without e-mail, and get that certified. That UID > will still be valid, and there are multiple options for people sending you mail > to : That is currently maybe the best way, but it creates another problem: What if I have/want to still be available under my old address? One solution would be not to split between private/work, but between secure/unsecure. When I leave employer1, I will remove the UID for this address from the unsecure and add it to my secure key. That way, I will still be able to receive new mail on my home machine. Will it harm to have the same email-part of an UID for two keys? e.g. - Klaus (secure) klaus at employer1.de - Klaus (unsecure) klaus at employer1.de Klaus -- Diese E-Mail wurde aus dem Sicherheitsverbund E-Mail made in Germany versendet: http://www.gmx.net/e-mail-made-in-germany From einarr at pvv.org Sun Dec 1 12:45:10 2013 From: einarr at pvv.org (Einar Ryeng) Date: Sun, 1 Dec 2013 12:45:10 +0100 Subject: Any future for the Crypto Stick? Message-ID: <20131201114510.GA7948@pvv.ntnu.no> Hi. The GPF Crypto Stick has been unavailable for months now, and I wondered if anyone here has information on its future. After the German Privacy Foundation apparently closed down this summer, I've started getting worried that we've seen the end of what I consider the most practical hardware token for GPG. Any news on the crypto stick (or similar initiatives) would be appreciated. Cheers, -- Einar Ryeng From peter at digitalbrains.com Sun Dec 1 12:58:07 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 01 Dec 2013 12:58:07 +0100 Subject: multiple keys with different UIDs and common WoT? In-Reply-To: References: , <529A5D1D.4030805@digitalbrains.com> <529B0B70.50802@digitalbrains.com>, <529B0FE2.4070104@digitalbrains.com> Message-ID: <529B244F.2000803@digitalbrains.com> On 01/12/13 12:42, Klaus wrote: > Will it harm to have the same email-part of an UID for two keys? e.g. > - Klaus (secure) klaus at employer1.de > - Klaus (unsecure) klaus at employer1.de I suppose it depends on how the mail client handles the case of multiple valid UIDs on different keys matching the e-mail address. The GnuPG command line simply picks the first in the keyring. If the mail client also does this, it's entirely unpredictable which one will be picked by others. In this case, it would be ideal if the mail client prompted with the two matches, allowing the sender to pick one. Although it's debatable whether it should do this every time; it might become annoying. Maybe someone else knows more... But keeping the e-mail address of your old employer with the scheme I proposed, just means that your new employer will in principle have access to messages encrypted to the work key. This might not be objectionable when you have left your previous employer. It depends on the scenario; what type of mails people send you after you have left the first employer. > That way, I will still be able to receive new mail on my > home machine. If you have the private keys of the work key at home, you will also have access to the mails sent to the work key. But I suppose you meant: at home but /not/ at my new job. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From josef at netpage.dk Sun Dec 1 18:01:43 2013 From: josef at netpage.dk (Josef Schneider) Date: Sun, 01 Dec 2013 18:01:43 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <529B6B77.4090404@netpage.dk> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> Message-ID: <529B6B77.4090404@netpage.dk> Einar Ryeng schrieb: > > Hi. > > The GPF Crypto Stick has been unavailable for months now, and I > wondered if > anyone here has information on its future. > > Any news on the crypto stick (or similar initiatives) would be > appreciated. I just use a OpenPGP Card in a small gemalto stick reader. AFAIK in the Crypto stick they just soldered a OpenPGP card in, so it is basically the same! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4914 bytes Desc: S/MIME Cryptographic Signature URL: From tristan.santore at internexusconnect.net Sun Dec 1 20:09:35 2013 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Sun, 01 Dec 2013 19:09:35 +0000 Subject: Any future for the Crypto Stick? In-Reply-To: <529B6B77.4090404@netpage.dk> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> Message-ID: <529B896F.1000704@internexusconnect.net> On 01/12/13 17:01, Josef Schneider wrote: > Einar Ryeng schrieb: >> Hi. >> >> The GPF Crypto Stick has been unavailable for months now, and I >> wondered if >> anyone here has information on its future. > > >> Any news on the crypto stick (or similar initiatives) would be >> appreciated. > > I just use a OpenPGP Card in a small gemalto stick reader. AFAIK in the > Crypto stick they just soldered a OpenPGP card in, so it is basically > the same! > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users You might want to check out the Yubikey guys. They make a yubikey with an openpgp applet. https://www.yubico.com/2012/12/yubikey-neo-openpgp/ And the applet code is here: https://github.com/Yubico/ykneo-openpgp Some people should peer review this stuff though. At least the code is FOSS. I would still prefer a openpgp card though mainly because I trust a German company more, than a business that also might be harassed by the US Government. However, if there is no other way to connect a device like a card reader, then maybe this would offer an alternative. As Bruce Schneier said, FOSS is harder to manipulate, so that is a good thing, and also he warns of US (non US)influence on proprietary companies. To be honest, I think one now has to take any US business with a pinch of salt. This of course also applies to other businesses, which are not located in the US. All depends on the legal situation and the willingness of companies to abuse their position, because they are being lobbied by governments. The usual, do this or we won't offer your products for tendering in the public sector (government departments), or worse threats where laws allow that. Or just plain stupidity, thinking they are doing the right thing, believing all the rubbish they have been fed. Regards, Tristan -- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore at internexusconnect.net Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust) For Fedora related issues, please email me at: TSantore at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.faerber at kernelconcepts.de Sun Dec 1 19:35:53 2013 From: nils.faerber at kernelconcepts.de (Nils Faerber) Date: Sun, 01 Dec 2013 19:35:53 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <529B6B77.4090404@netpage.dk> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> Message-ID: <529B8189.1020508@kernelconcepts.de> Am 01.12.2013 18:01, schrieb Josef Schneider: > Einar Ryeng schrieb: >> Hi. >> >> The GPF Crypto Stick has been unavailable for months now, and I >> wondered if >> anyone here has information on its future. > >> Any news on the crypto stick (or similar initiatives) would be >> appreciated. > > I just use a OpenPGP Card in a small gemalto stick reader. AFAIK in the > Crypto stick they just soldered a OpenPGP card in, so it is basically > the same! Well, at least similar, let's say. The CryptoStick uses an AVR microcontroller as cardreader chip and the sotware to that AVR is also AFAIK free software. Cheers nils -- kernel concepts GmbH Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From arne.renkema-padmos at cased.de Sun Dec 1 13:21:56 2013 From: arne.renkema-padmos at cased.de (arne renkema-padmos) Date: Sun, 01 Dec 2013 13:21:56 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <20131201114510.GA7948@pvv.ntnu.no> References: <20131201114510.GA7948@pvv.ntnu.no> Message-ID: <529B29E4.3060104@cased.de> On 12/01/2013 12:45 PM, Einar Ryeng wrote: > Hi. > > The GPF Crypto Stick has been unavailable for months now, and I wondered if > anyone here has information on its future. > > After the German Privacy Foundation apparently closed down this summer, I've > started getting worried that we've seen the end of what I consider the most > practical hardware token for GPG. > > Any news on the crypto stick (or similar initiatives) would be appreciated. > > Cheers, > An OpenPGP card with something like a Gemalto SIM usb adapter would seem to fit the bill. Cheers, arne -- Arne Renkema-Padmos Doctoral researcher SecUSo ? Security, Usability and Society Center for Advanced Security Research Darmstadt TU Darmstadt, Department of Computer Science Building S2|02, Room B214 Phone: +49 163 734 6164 Web: https://www.secuso.informatik.tu-darmstadt.de/de/staff/arne-renkema-padmos/ From ndk.clanbo at gmail.com Mon Dec 2 15:24:04 2013 From: ndk.clanbo at gmail.com (NdK) Date: Mon, 02 Dec 2013 15:24:04 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <529B896F.1000704@internexusconnect.net> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> Message-ID: <529C9804.4030603@gmail.com> Il 01/12/2013 20:09, Tristan Santore ha scritto: > You might want to check out the Yubikey guys. They make a yubikey with > an openpgp applet. > https://www.yubico.com/2012/12/yubikey-neo-openpgp/ Yubikeys would be interesting, if only it would be possible to develop personal applets to load on 'em. Too bad some needed libraries (like the one to access the button for OOB consent) are only available under NDA from NXP (quite uncollaborative with hobbyists). Moreover, their applet doesn't allow key import, only on-card generation! > Some people should peer review this stuff though. At least the code is FOSS. Quite useless to review something you won't be able to compile and load yourself, don't you think? > I would still prefer a openpgp card though mainly because I trust a > German company more, than a business that also might be harassed by the > US Government. Another alternative is getting a SIM-cut Java card and a reader for it, then load one of the OpenPGP Java applets you can find around. You'll then be able to load code you compiled (and audited) yourself and can import your 'old' keys if you like. > All depends on the legal situation and the willingness of companies to > abuse their position, because they are being lobbied by governments. Who can you really trust? If you don't trust NXP, then you can't use any of their JCOP chips... What would stop 'em from adding an undocumented command to the card manager that dumps the whole memory? PS: too bad all the Java cards I could get are limited to 2048 bit keys... Only BasicCard supports longer keys, but I'm not using Basic since Commodore-64 era :) BYtE, Diego. From harningt at gmail.com Mon Dec 2 16:49:04 2013 From: harningt at gmail.com (Thomas Harning Jr.) Date: Mon, 2 Dec 2013 10:49:04 -0500 Subject: Any future for the Crypto Stick? In-Reply-To: <529C9804.4030603@gmail.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> Message-ID: On Mon, Dec 2, 2013 at 9:24 AM, NdK wrote: > Il 01/12/2013 20:09, Tristan Santore ha scritto: > > > You might want to check out the Yubikey guys. They make a yubikey with > > an openpgp applet. > > https://www.yubico.com/2012/12/yubikey-neo-openpgp/ > Yubikeys would be interesting, if only it would be possible to develop > personal applets to load on 'em. Too bad some needed libraries (like the > one to access the button for OOB consent) are only available under NDA > from NXP (quite uncollaborative with hobbyists). > Moreover, their applet doesn't allow key import, only on-card generation! > Not lately - there has been an update to support key import. Tested it and it works great for keeping keys off my machine. Hopefully we do see more features being made accessible for Open-Source usage, though. [commit reference where it was added] https://github.com/Yubico/ykneo-openpgp/commit/b30612237e610cbc35d37fc5ebe59629de93001d -- Thomas Harning Jr. (http://about.me/harningt) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ctsonetemp at yahoo.com Mon Dec 2 17:17:44 2013 From: ctsonetemp at yahoo.com (Cts Onetemp) Date: Mon, 2 Dec 2013 08:17:44 -0800 (PST) Subject: Importing a PGP public key with no expiry date to GPG 1..4.2, sets the create_date to expiry_date & errors Message-ID: <1386001064.30777.YahooMailNeo@web164906.mail.bf1.yahoo.com> Hi? ?? When I import a PGP public key that has "NO expiry" date, into GPG 1.4.2, it shows the key as expired & the PGP created date shows as 'expired date' . Is this a bug? or is there a way to force GPG to not set the expiry date from the created date?? When I try to encrypt with the PGP public key (ignoring the date), it gives the following error? gpg: 6988865C: skipped: unusable public key gpg: install.txt: encryption failed: unusable public key When I try to sign the pgp public key, it gives the below error Command> sign gpg: no default secret key: malformed user id Any suggestions. There is NO issue with the PGP public key & it is used currently. GPG is setting the PGP created date as expired date.? Thanks Marina -------------- next part -------------- An HTML attachment was scrubbed... URL: From ctsonetemp at yahoo.com Mon Dec 2 19:25:56 2013 From: ctsonetemp at yahoo.com (Cts Onetemp) Date: Mon, 2 Dec 2013 10:25:56 -0800 (PST) Subject: IMporting PGP public key into GPG 1.4.2 with no expiry shows as expired in GPG In-Reply-To: References: Message-ID: <1386008756.21446.YahooMailNeo@web164901.mail.bf1.yahoo.com> Hi? ?? When I import a PGP public key that has "NO expiry" date, into GPG 1.4.2, it shows the key as expired & the PGP created date shows as 'expired date' . Is this a bug? or is there a way to force GPG to not set the expiry date from the created date?? When I try to encrypt with the PGP public key (ignoring the date), it gives the following error? gpg: 6988865C: skipped: unusable public key gpg: install.txt: encryption failed: unusable public key When I try to sign the pgp public key, it gives the below error Command> sign gpg: no default secret key: malformed user id Any suggestions. There is NO issue with the PGP public key & it is used currently. GPG is setting the PGP created date as expired date.? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Mon Dec 2 19:33:22 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 02 Dec 2013 19:33:22 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <529C9804.4030603@gmail.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> Message-ID: <529CD272.5040901@digitalbrains.com> On 02/12/13 15:24, NdK wrote: > Who can you really trust? If you don't trust NXP, then you can't use any > of their JCOP chips... What would stop 'em from adding an undocumented > command to the card manager that dumps the whole memory? Exactly the point I was going to make when I read your mail up to this point. And don't forget that the draconian US laws aren't just for multinationals whose main offices are in the US... it's also for multinationals with any office in the US. I wouldn't count on it that NXP thought "we'd rather lose the US market than backdoor our smartcards". Since smartcards are primarily used for security purposes, I wouldn't be surprised if it responded specially to a message signed by the NSA (or encrypted with a symmetric cipher with a specific key known to the NSA). > Only BasicCard supports longer keys, but I'm not using Basic > since Commodore-64 era :) I agree with you, but programs on BasicCards are generally rather simple since they just define the contents for the ISO 7816 APDU's and files, and everything else, including the file system on the card, is part of the interpreter and OS on the card. And BASIC has two advantages: it's easy to learn, and it's easy to compile to bytecode (that is, writing a compiler is easy). Obviously, the design of the language from an academic standpoint is really bad by todays standards; we learned a lot since BASIC was designed. But that's not so important for the small applet-like programs that only work with the contents of ISO 7816 APDU's and files. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From andreas.schwier.ml at cardcontact.de Mon Dec 2 20:37:07 2013 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier (ML)) Date: Mon, 02 Dec 2013 20:37:07 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <529CD272.5040901@digitalbrains.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> Message-ID: <529CE163.9080503@cardcontact.de> Wait a second - you can not simply hide a backdoor in a Common Criteria evaluated operating system. There are too many entities that would need to be involved in the process: The manufacturer, the evaluator, the certification body and possibly a national regulator (Here for example NXP, T?V-IT, BSI and Bundesnetzagentur). And if there were a backdoor, then the manufacturer could be held liable if the backdoor was exploited. They wouldn't risk their business just to comply with a fairly small US smart card market requirement. Btw. we are working on a solution to add OpenPGP support for our SmartCard-HSM, which is running on a JCOP platform. It's available as card, USB-Stick or MicroSD card. Andreas Am 02.12.2013 19:33, schrieb Peter Lebbing: > On 02/12/13 15:24, NdK wrote: >> Who can you really trust? If you don't trust NXP, then you can't use any >> of their JCOP chips... What would stop 'em from adding an undocumented >> command to the card manager that dumps the whole memory? > > Exactly the point I was going to make when I read your mail up to this point. > > And don't forget that the draconian US laws aren't just for multinationals whose > main offices are in the US... it's also for multinationals with any office in > the US. I wouldn't count on it that NXP thought "we'd rather lose the US market > than backdoor our smartcards". > > Since smartcards are primarily used for security purposes, I wouldn't be > surprised if it responded specially to a message signed by the NSA (or encrypted > with a symmetric cipher with a specific key known to the NSA). > >> Only BasicCard supports longer keys, but I'm not using Basic >> since Commodore-64 era :) > > I agree with you, but programs on BasicCards are generally rather simple since > they just define the contents for the ISO 7816 APDU's and files, and everything > else, including the file system on the card, is part of the interpreter and OS > on the card. And BASIC has two advantages: it's easy to learn, and it's easy to > compile to bytecode (that is, writing a compiler is easy). > > Obviously, the design of the language from an academic standpoint is really bad > by todays standards; we learned a lot since BASIC was designed. But that's not > so important for the small applet-like programs that only work with the contents > of ISO 7816 APDU's and files. > > Peter. > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org From peter at digitalbrains.com Mon Dec 2 23:14:02 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 02 Dec 2013 23:14:02 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <529CE163.9080503@cardcontact.de> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> Message-ID: <529D062A.3090603@digitalbrains.com> On 02/12/13 20:37, Andreas Schwier (ML) wrote: > Wait a second - you can not simply hide a backdoor in a Common Criteria > evaluated operating system. There are too many entities that would need > to be involved in the process Why couldn't the manufacturer simply put a different, backdoored firmware in the card ROM than the one they showed to the other entities? Are those other entities physically examining the ROM mask of the final product or somehow bypassing the code protection and reading out the flash ROM? > And if there were a backdoor, then the manufacturer could be held liable > if the backdoor was exploited. They wouldn't risk their business just to > comply with a fairly small US smart card market requirement. I'm not so sure. This is equally true for the backdoors than are known to have been placed by the NSA; yet still there they are. By the way, when NXP is kicked out of the US, they lose their whole US market, not just the smartcard market. Instead of "kicked out", also think of "harassed", "not getting government contracts", etcetera. > Btw. we are working on a solution to add OpenPGP support for our > SmartCard-HSM, which is running on a JCOP platform. It's available as > card, USB-Stick or MicroSD card. Cool, the more, the merrier. NdK just pointed me to the FST-01 USB stick, not a JCOP platform, but cool in a different way. Fully free software on a generic ARM platform. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Tue Dec 3 10:45:32 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Dec 2013 10:45:32 +0100 Subject: IMporting PGP public key into GPG 1.4.2 with no expiry shows as expired in GPG In-Reply-To: <1386008756.21446.YahooMailNeo@web164901.mail.bf1.yahoo.com> (Cts Onetemp's message of "Mon, 2 Dec 2013 10:25:56 -0800 (PST)") References: <1386008756.21446.YahooMailNeo@web164901.mail.bf1.yahoo.com> Message-ID: <877gbm9sjn.fsf@vigenere.g10code.de> On Mon, 2 Dec 2013 19:25, ctsonetemp at yahoo.com said: > When I import a PGP public key that has "NO expiry" date, into GPG > 1.4.2, it s 1.4.2 is quite old (8 years) and you should definitely not use it anymore. It seems that you did not invoked gpg correctly. Please show us the actual command line you used and also the content of gpg.conf. You may redact keyids and user ids but please change only digits to '1' and letters to 'a' - do not redact and blanks etc. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mwood at IUPUI.Edu Tue Dec 3 15:30:28 2013 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 3 Dec 2013 09:30:28 -0500 Subject: Any future for the Crypto Stick? In-Reply-To: <529CD272.5040901@digitalbrains.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> Message-ID: <20131203143027.GB24693@IUPUI.Edu> On Mon, Dec 02, 2013 at 07:33:22PM +0100, Peter Lebbing wrote: [snip] > Since smartcards are primarily used for security purposes, I wouldn't be > surprised if it responded specially to a message signed by the NSA (or encrypted > with a symmetric cipher with a specific key known to the NSA). I wonder how feasible that really is. The system surrounding the card is not under control of the card's manufacturer or anyone who might have corrupted him. All it takes is one knowledgable person watching the data stream for interesting anomalies, and you have given the game away. The cost, as we've recently seen, could be considerable. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Machines should not be friendly. Machines should be obedient. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From ctsonetemp at yahoo.com Tue Dec 3 16:59:47 2013 From: ctsonetemp at yahoo.com (Cts Onetemp) Date: Tue, 3 Dec 2013 07:59:47 -0800 (PST) Subject: IMporting PGP public key into GPG 1.4.2 with no expiry shows as expired in GPG In-Reply-To: <877gbm9sjn.fsf@vigenere.g10code.de> References: <1386008756.21446.YahooMailNeo@web164901.mail.bf1.yahoo.com> <877gbm9sjn.fsf@vigenere.g10code.de> Message-ID: <1386086387.27285.YahooMailNeo@web164905.mail.bf1.yahoo.com> Thanks Werner? This is for a client who is using gpg 142 and I am trying to simulate that here. we are providing them the pgp keys.? attched the conf file.? here is the list of commands run? C:\gpg>set GNUPGHOME=home C:\GPG>gpg --list-keys home\pubring.gpg ---------------- pub ? 1024D/551A09BA 2013-11-26 uid ? ? ? ? ? ? ? ? ?aa sub ? 2048g/8BF467D3 2013-11-26 C:\gpg>gpg --import pgp_compatible.pgp ? ( this is the one generated with the pgp --export-format compatible option) gpg: key 6988865C: public key "nadm at xxxx.com" imported gpg: Total number processed: 1 gpg: ? ? ? ? ? ? ? imported: 1 ?(RSA: 1) C:\gpg>gpg --list-keys home\pubring.gpg ---------------- pub ? 1024D/7017503A 2013-11-29 uid ? ? ? ? ? ? ? ? ?aa sub ? 2048g/41B425C7 2013-11-29 pub ? 1024R/6988865C 2010-10-26 [expired: 2010-10-26] ?( This is incorrect. the PGP key does not have an expiry set ) uid ? ? ? ? ? ? ? ? ?nadm at xxxx.com -- ?Edit and set trust to see if that helps? C:\gpg>gpg --edit-key 6988865C pub ?1024R/6988865C ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: CS sub ?1024R/8530919D ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: E sub ?2048R/939E43AE ?created: 2010-12-12 ?expired: 2010-12-12 ?usage: E sub ?2048R/0DF32565 ?created: 2012-12-31 ?expired: 2015-01-10 ?usage: E [ expired] (1). nadm at xxxx.com Command> trust pub ?1024R/6988865C ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: CS sub ?1024R/8530919D ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: E sub ?2048R/939E43AE ?created: 2010-12-12 ?expired: 2010-12-12 ?usage: E sub ?2048R/0DF32565 ?created: 2012-12-31 ?expired: 2015-01-10 ?usage: E [ expired] (1). nadm at xxxx.com Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) ? 1 = I don't know or won't say ? 2 = I do NOT trust ? 3 = I trust marginally ? 4 = I trust fully ? 5 = I trust ultimately ? m = back to the main menu Your decision? 4 pub ?1024R/6988865C ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: CS sub ?1024R/8530919D ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: E sub ?2048R/939E43AE ?created: 2010-12-12 ?expired: 2010-12-12 ?usage: E sub ?2048R/0DF32565 ?created: 2012-12-31 ?expired: 2015-01-10 ?usage: E [ expired] (1). nadm at xxxx.com Please note that the shown key validity is not necessarily correct unless you restart the program. Command> save Key not changed so no update needed. -- I try to sign this key? C:\gpg>gpg --edit-key 6988846C pub ?1024R/6988865C ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: CS sub ?1024R/8530919D ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: E sub ?2048R/939E43AE ?created: 2010-12-12 ?expired: 2010-12-12 ?usage: E sub ?2048R/0DF32565 ?created: 2012-12-31 ?expired: 2015-01-10 ?usage: E [ expired] (1). nadm at xxxx.com Command> sign pub ?1024R/6988865C ?created: 2010-10-26 ?expired: 2010-10-26 ?usage: CS ?Primary key fingerprint: 9568 7369 43F0 F8F2 512F ?AAAA A123 82DB 6988 846C ? ??nadm at xxxx.com This key has expired! ?Unable to sign. -- The PGP key is definitely not expired.? If i further go ahead and try to encrypt? C:\gpg>gpg --encrypt --recipient 6988865C ?install.txt gpg:??nadm at xxxx.com: skipped: unusable public key gpg: install.txt: encryption failed: unusable public key ------ If I use a PGP key that has expiry date set, it seems to import fine into GPG,. But for a PGP key that has expiry set to Never, the above happens. We use PGP 10. ?Any suggestions? ?I am not familiar with config file for gpg. any help is appreciated.? Thanks On Tuesday, December 3, 2013 4:45 AM, Werner Koch wrote: On Mon,? 2 Dec 2013 19:25, ctsonetemp at yahoo.com said: > When I import a PGP public key that has "NO expiry" date, into GPG > 1.4.2, it s 1.4.2 is quite old (8 years) and you should definitely not use it anymore. It seems that you did not invoked gpg correctly.? Please show us the actual command line you used and also the content of gpg.conf.? You may redact keyids and user ids but please change only digits to '1' and letters to 'a' - do not redact and blanks etc. Salam-Shalom, ? Werner -- Die Gedanken sind frei.? Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg.conf.cpy Type: application/octet-stream Size: 1206 bytes Desc: not available URL: From ndk.clanbo at gmail.com Tue Dec 3 17:59:53 2013 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 03 Dec 2013 17:59:53 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <20131203143027.GB24693@IUPUI.Edu> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <20131203143027.GB24693@IUPUI.Edu> Message-ID: <529E0E09.8000906@gmail.com> Il 03/12/2013 15:30, Mark H. Wood ha scritto: > I wonder how feasible that really is. The system surrounding the card > is not under control of the card's manufacturer or anyone who might > have corrupted him. All it takes is one knowledgable person watching > the data stream for interesting anomalies, and you have given the game > away. The cost, as we've recently seen, could be considerable. Unless the exploit could be categorised as "bug". Like the power glitch that allows clearing fuses in some PICs (advertised as secure chips, at the time... now they're saying it's secure unless operated outside nominal values) w/o wiping the rest of the memory. This way you'd have to use a non-standard reader to introduce a specific error. Or, maybe, a protection layer that fails if frozen before exposing it to oxygen, allowing the attacker to succesfully decap the chip before it self-erases. There are simply too many attack vectors to say the evaluation considers 'em all. It needs to stop somewhere saying "this chip is secure against these attacks" since it can't say "it's secure against any attack you could think of". And/or it places a budget limit on the attack: if it costs more than that, the attack is worthless. I've seen this tradeoff while studying openalarm, a (wannabe, still in its early stages) burglar alarm system scalable from garage to bank: as long as you can trust a producer and an installer, it's quite easy and anything will do (if you need to protect your personal mail from your nosy boss, FST-01 is more than enough). If you can't, you need exponentially more resources to be able to pinpoint the black hat, be it the producer of a node, of one of the management systems or the installer trying to slip a backdoor in. If you don't/can't trust a single smartcard manufacturer, you'd need to use at least four (if you need to be able to say who is the misbehaving one -- byzantine generals problem in case of 3 with one misbehaving agent). So, for the vast majority of uses, the solution might be non-technical: use a certified Common Criteria card and make sure to have evidence that if the key is leaked then that certification is bogus. Quite unlikely the NSA will reveal having a backdoor just to arrest *you* :) BYtE, Diego. From blueapplejacks at gmail.com Tue Dec 3 18:21:26 2013 From: blueapplejacks at gmail.com (bj) Date: Tue, 3 Dec 2013 12:21:26 -0500 Subject: Windows command line to decrypt multiple files Message-ID: Hi all. I found and modified a batch file that encrypts files prior to sending them out. Now we need to decrypt incoming files from another company (encrypted with our key). The GPG4Win GUI allows me to do this manually but I would like to automate on a server. The echo line below seems to be the meat of the encrypt process. Changing the command to decrypt (and trying several variations) has led to failures. Sorry I lost the specific errors. My technical understanding is still newby. Can anyone please help me? Where is password defined? Thanks much *FOR /F "delims=" %%F IN ('MORE ^< "%TMP%\~encryptlist.txt"') DO (IF EXIST %%F (ECHO Password|GPG --batch --encrypt --passphrase-fd 0 -r F75C5TE0 -o "C:\encryptedfiles\%%F.pgp" %%F IF ERRORLEVEL == 0 DEL "%%F"))POPD* (NEXT SECTION IS FTP TRANSFERS) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Tue Dec 3 20:55:03 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 03 Dec 2013 20:55:03 +0100 Subject: Windows command line to decrypt multiple files In-Reply-To: References: Message-ID: <1461305.vlyIFjffTz@inno.berlin.laging.de> Am Di 03.12.2013, 12:21:26 schrieb bj: > Where is password defined? passwort is (implicitly) defined in the keyring. The secret key is stored encrypted. You need the passphrase in order to use the key. You must know the passphrase, you cannot get it from the GnuPG installation. > *FOR /F "delims=" %%F IN ('MORE ^< "%TMP%\~encryptlist.txt"') DO (IF EXIST > %%F (ECHO Password|GPG --batch --encrypt --passphrase-fd 0 -r F75C5TE0 -o > "C:\encryptedfiles\%%F.pgp" %%F IF ERRORLEVEL == 0 DEL "%%F"))POPD* > (NEXT SECTION IS FTP TRANSFERS) I am not familiar with that DOS / Windows stuff. Just a few comments: 1) You do not need a passphrase when you encrypt files. You need the passphrase for signing and decrypting. 2) ECHO Password| gpg --passphrase-fd 0 --batch -o "..." --decrypt %%F should do. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From epoellinger at yahoo.com Tue Dec 3 17:22:28 2013 From: epoellinger at yahoo.com (Eric Poellinger) Date: Tue, 3 Dec 2013 08:22:28 -0800 (PST) Subject: Renewing expiring key - done correctly? Message-ID: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> Hello all This is my first experience with renewing GPG keys - I did some research but wanted to confirm an observation. This is the key before issuing the 'expire' command: pub ?2048R/4A4DBDC7 ?created: 2012-01-13 ?expires: 2014-01-12 ?usage: SC ? ? ? ? ? ? ? ? ? ? ?trust: ultimate ? ? ?validity: ultimate sub ?2048R/0C0305EC ?created: 2012-01-13 ?expires: 2014-01-12 ?usage: E I did a 2 year expiration and the master key (4A4DBDC7 ) was updated as expected (to 2015-12-03) PRIMARY QUESTIONS - I am uncertain about the sub-key. ?When I attempt to 'expire' it the date does not seem to change. ?Maybe you cannot expire a sub-key? ?Maybe I do not need to care because we are not using it in our encryption commands?? ?FYI, this key is only with one trading partner, so managing the change is not difficult. ? SECONDARY QUESTION - is there documentation regarding 'best practices' on managing expiring keys and renewing via sub-keys --- my theory is that doing it this way minimizes the coordination necessary but I am not understanding how it works if you have multiple trading partners to coordinate with. Thanks for everyone's time to read this! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Dec 3 22:02:06 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 03 Dec 2013 13:02:06 -0800 Subject: Renewing expiring key - done correctly? In-Reply-To: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> Message-ID: <20131203130206.Horde.fYzgqN0VU-HGDd3A2OUjFw1@mail.sixdemonbag.org> > PRIMARY QUESTIONS - I am uncertain about the sub-key. ?When I > attempt to 'expire' it the date does not seem to change. The first question I have is, "How did you attempt to 'expire' it?" > SECONDARY QUESTION - is there documentation regarding 'best > practices' on managing expiring keys and renewing via sub-keys Unfortunately, no. There will certainly be well-meaning people who will speak up with their own idea of what the best practices for such a thing are. I encourage skepticism. Key management is at least 95% policy, and policy will vary from person to person and place to place based on each individual's perceptions of risks and risk mitigation strategies. By all means listen to these opinions, but please be skeptical of thinking they are correct. What makes sense for one person's risk profile may not make sense for yours. There are very few universal truths here, and that makes attempts at compiling best practices extremely difficult. From rjh at sixdemonbag.org Tue Dec 3 22:04:43 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 03 Dec 2013 13:04:43 -0800 Subject: Windows command line to decrypt multiple files In-Reply-To: References: Message-ID: <20131203130443.Horde.M7j74WNpTssGhDajDuQW-A1@mail.sixdemonbag.org> Quoting bj : > Hi all. I found and modified a batch file that encrypts files prior to > sending them out. Now we need to decrypt incoming files from another > company (encrypted with our key). What operating system are you using? This is the sort of thing that's more appropriate for a Windows service as opposed to a batchfile. I may have something around here that is useful for your niche, but I've only tested it on a Windows 7/64 box. From mailinglisten at hauke-laging.de Tue Dec 3 23:44:20 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 03 Dec 2013 23:44:20 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> Message-ID: <1698298.qLckIO9PU3@inno.berlin.laging.de> Am Di 03.12.2013, 08:22:28 schrieb Eric Poellinger: > PRIMARY QUESTIONS - I am uncertain about the sub-key. When I attempt to > 'expire' it the date does not seem to change. What exactly did you do? Did you mark the subkey before and did you save the changes to the keyring after the expire command? gpg> key 1 pub 3072R/0x711D8152 created: 2013-11-27 expires: 2014-11-27 usage: SCE trust: ultimate validity: ultimate sub* 2048R/0x48C7F0CD created: 2013-11-27 expires: 2015-12-03 usage: S [...] gpg> save > Maybe you cannot expire a sub-key? You can. > SECONDARY QUESTION - is there documentation regarding 'best practices' on > managing expiring keys and renewing via sub-keys --- my theory is that > doing it this way minimizes the coordination necessary but I am not > understanding how it works if you have multiple trading partners to > coordinate with. Expiration serves two purposes: 1) Passively revoke a key if you have lost access to the secret mainkey (i.e. to the key itself or to its passphrase). 2) Force your communication partners (people are lazy) to update your certificate from time to time (requires some understanding on their side). The length of the validity period is a compromise between higher "security" and less inconvenience (your own, too). I am not sure whether I understand correctly what you mean by "renewing". You can prolong the validity of subkeys and you can replace subkeys. It's not a big difference for your communication partners. Replacing subkeys for security reasons makes real sense only if you use a secure offline mainkey. Usually you upload your certificate (public key) to a key server (or more) from where everyone can get updates of your certificate. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From johannes at zarl.at Wed Dec 4 00:00:21 2013 From: johannes at zarl.at (Johannes Zarl) Date: Wed, 04 Dec 2013 00:00:21 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <1698298.qLckIO9PU3@inno.berlin.laging.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1698298.qLckIO9PU3@inno.berlin.laging.de> Message-ID: <2591578.WzTNMIAjlz@mani> On Tuesday 03 December 2013 23:44:20 Hauke Laging wrote: > Expiration serves two purposes: > 1) Passively revoke a key if you have lost access to the secret mainkey > (i.e. to the key itself or to its passphrase). > 2) Force your communication partners (people are lazy) to update your > certificate from time to time (requires some understanding on their side). > > The length of the validity period is a compromise between higher "security" > and less inconvenience (your own, too). Sorry for asking a possibly stupid question, but how exactly does a shorter validity period get you more security? Johannes From mailinglisten at hauke-laging.de Wed Dec 4 00:20:10 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 04 Dec 2013 00:20:10 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <2591578.WzTNMIAjlz@mani> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1698298.qLckIO9PU3@inno.berlin.laging.de> <2591578.WzTNMIAjlz@mani> Message-ID: <3242368.vbyNuFUAGG@inno.berlin.laging.de> Am Mi 04.12.2013, 00:00:21 schrieb Johannes Zarl: > Sorry for asking a possibly stupid question, but how exactly does a shorter > validity period get you more security? This is the security against the possibility that a) the key has been compromised and revoked and you don't know that (because your last certificate update was before the revocation publishing) b) the key has been compromised and cannot be revoked (because the owner has lost access to the secret mainkey and has neither a revocation certificate nor a (usable) designated revoker) Imagine a certificate which is always prolonged for just one day. If this gets compromised then it will not be prolonged any more (at least not by its owner but we all love our highly secure offline mainkeys, don't we?) so everyone will notice that within hours. On the other hand imagine a certificate which never expires and a lazy user (who seldom uses that key). Even a year after its revocation the lazy user may not have noticed the revocation yet. And thus encrypts critical information to the compromised key. Or worse (because the key owner wouldn't notice): Uses it to validate software. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From johannes at zarl.at Wed Dec 4 00:39:46 2013 From: johannes at zarl.at (Johannes Zarl) Date: Wed, 04 Dec 2013 00:39:46 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <3242368.vbyNuFUAGG@inno.berlin.laging.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <2591578.WzTNMIAjlz@mani> <3242368.vbyNuFUAGG@inno.berlin.laging.de> Message-ID: <4249245.2OFWiGlN5j@mani> On Wednesday 04 December 2013 00:20:10 Hauke Laging wrote: > Am Mi 04.12.2013, 00:00:21 schrieb Johannes Zarl: > > Sorry for asking a possibly stupid question, but how exactly does a > > shorter > > validity period get you more security? > > This is the security against the possibility that > > a) the key has been compromised and revoked and you don't know that (because > your last certificate update was before the revocation publishing) Ok. > b) the key has been compromised and cannot be revoked (because the owner has > lost access to the secret mainkey and has neither a revocation certificate > nor a (usable) designated revoker) Isn't that just a false sense of security? After all, if the key has been compromised, the attacker can just prolong the validity like the real owner would do (I guess even after the key has been expired). > Imagine a certificate which is always prolonged for just one day. If this > gets compromised then it will not be prolonged any more (at least not by > its owner but we all love our highly secure offline mainkeys, don't we?) so > everyone will notice that within hours. I'm not sure if I get that example. To me it seems either that the attacker can just renew the key as the owner would (entire key is compromised), or that the owner can just issue a revocation certificate (only subkey is compromised). > On the other hand imagine a certificate which never expires and a lazy user > (who seldom uses that key). Even a year after its revocation the lazy user > may not have noticed the revocation yet. And thus encrypts critical > information to the compromised key. Or worse (because the key owner > wouldn't notice): Uses it to validate software. Ok, I can see the benefit here. So in summary, the short validity period is essentially a reminder for people to regularly check whether the key has been revoked. And the security lies not in the expiry in itself, but in forcing people to refresh their keyrings. Thanks! Johannes From mailinglisten at hauke-laging.de Wed Dec 4 00:59:53 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 04 Dec 2013 00:59:53 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <4249245.2OFWiGlN5j@mani> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <3242368.vbyNuFUAGG@inno.berlin.laging.de> <4249245.2OFWiGlN5j@mani> Message-ID: <2414422.DFPHD7CR7i@inno.berlin.laging.de> Am Mi 04.12.2013, 00:39:46 schrieb Johannes Zarl: > Isn't that just a false sense of security? After all, if the key has been > compromised, the attacker can just prolong the validity He could but he would need the secret mainkey for that operation and... > > but we all love our highly secure offline mainkeys, don't we? ...keys without offline mainkey on insecure systems are a security joke anyway. > that the owner can just issue a revocation certificate It may be possible to prevent someone from seeing the revocation certificate. Certificate distribution is a lot less secure than the keys themselves. But you cannot trick someone into using an expired key. > So in summary, the short validity period is essentially a reminder for > people to regularly check whether the key has been revoked. And besides security: It allows detection of dead keys on the keyservers. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Wed Dec 4 01:03:13 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 03 Dec 2013 19:03:13 -0500 Subject: Renewing expiring key - done correctly? In-Reply-To: <3242368.vbyNuFUAGG@inno.berlin.laging.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1698298.qLckIO9PU3@inno.berlin.laging.de> <2591578.WzTNMIAjlz@mani> <3242368.vbyNuFUAGG@inno.berlin.laging.de> Message-ID: <529E7141.7030209@sixdemonbag.org> On 12/3/2013 6:20 PM, Hauke Laging wrote: > Imagine a certificate which is always prolonged for just one day. If this gets > compromised then it will not be prolonged any more (at least not by its owner > but we all love our highly secure offline mainkeys, don't we?) so everyone > will notice that within hours. 1. The attacker can just extend the validity himself. He's successfully compromised the key, after all. 2. As a consequence of #1, no one will notice. There are certainly reasons to limit certificate and/or subkey lifetimes, but these reasons are principally to comply with regulations, policies and/or laws -- not so much because doing so is a security best-practice. From rjh at sixdemonbag.org Wed Dec 4 01:26:09 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 03 Dec 2013 19:26:09 -0500 Subject: Renewing expiring key - done correctly? In-Reply-To: <2414422.DFPHD7CR7i@inno.berlin.laging.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <3242368.vbyNuFUAGG@inno.berlin.laging.de> <4249245.2OFWiGlN5j@mani> <2414422.DFPHD7CR7i@inno.berlin.laging.de> Message-ID: <529E76A1.6030205@sixdemonbag.org> On 12/3/2013 6:59 PM, Hauke Laging wrote: > He could but he would need the secret mainkey for that operation > and... Could you please share a realistic scenario by which an attacker could compromise a subkey without also having the ability to compromise the primary signing key? I've been trying to come up with one and I just can't. > ...keys without offline mainkey on insecure systems are a security > joke anyway. * There is no such thing as a secure (or insecure) system * The words 'security' and 'insecurity' are intimately tied to risk models: to use the words glibly deprives them of any meaning * There exist risk models in which an 'insecure system,' as you would call it, is a perfectly reasonable place to store a secret primary signing key I'm sorry, but this entire argument is just too glib to be taken seriously. > It may be possible to prevent someone from seeing the revocation > certificate. Certificate distribution is a lot less secure than the > keys themselves. But you cannot trick someone into using an expired > key. Of course you can. Reset their computer's clock. You don't even have to compromise their computer in order to do it: compromising whatever NTP server they're contacting is enough. From mailinglisten at hauke-laging.de Wed Dec 4 01:49:21 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 04 Dec 2013 01:49:21 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <529E76A1.6030205@sixdemonbag.org> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <2414422.DFPHD7CR7i@inno.berlin.laging.de> <529E76A1.6030205@sixdemonbag.org> Message-ID: <1939706.LWtWs2ekmt@inno.berlin.laging.de> Am Di 03.12.2013, 19:26:09 schrieb Robert J. Hansen: > Could you please share a realistic scenario by which an attacker could > compromise a subkey without also having the ability to compromise the > primary signing key? That's really easy: In order to get access to the subkey which will sign this email you just need online access to the system on which I write this email. A system which is used to read a lot of email, for IM and for accessing the WWW. It may (should) be harder to crack this system than it would be with the average system but it is without doubt possible (in the usual sense). Compromising the respective mainkey is more difficult by several orders of magnitude. You would have to compromise at least the boot medium (CD/DVD) or the hardware I use. > * There exist risk models in which an 'insecure system,' as > you would call it, is a perfectly reasonable place to > store a secret primary signing key Of course. But these risk models are incompatible with the requirements of crypto usage in a business environment. They are even incompatible with a real Web of Trust. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Wed Dec 4 01:53:46 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 04 Dec 2013 01:53:46 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <529E7141.7030209@sixdemonbag.org> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <3242368.vbyNuFUAGG@inno.berlin.laging.de> <529E7141.7030209@sixdemonbag.org> Message-ID: <1587922.Z1bN9dCvH3@inno.berlin.laging.de> Am Di 03.12.2013, 19:03:13 schrieb Robert J. Hansen: > 1. The attacker can just extend the validity himself. He's > successfully compromised the key, after all. Sure but it makes little sense to play best practice in one part of key management (expiration) and simultaneously worst practice (online mainkey) in a much more important part of key management. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Wed Dec 4 02:10:32 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 03 Dec 2013 20:10:32 -0500 Subject: Renewing expiring key - done correctly? In-Reply-To: <1939706.LWtWs2ekmt@inno.berlin.laging.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <2414422.DFPHD7CR7i@inno.berlin.laging.de> <529E76A1.6030205@sixdemonbag.org> <1939706.LWtWs2ekmt@inno.berlin.laging.de> Message-ID: <529E8108.1080005@sixdemonbag.org> On 12/3/2013 7:49 PM, Hauke Laging wrote: > Compromising the respective mainkey is more difficult by several > orders of magnitude. You would have to compromise at least the boot > medium (CD/DVD) or the hardware I use. Why do you think it's hard to compromise your boot medium? Your boot medium isn't a CD or DVD: your boot medium is the UEFI firmware that gives you the choice of where to boot from next. UEFI is a surprisingly capable operating environment. If I can compromise your machine, then I put down my own code in the UEFI loader and wait for you to reboot your machine. > Of course. But these risk models are incompatible with the > requirements of crypto usage in a business environment. They are even > incompatible with a real Web of Trust. Hauke, you don't get to define what other people's models are, or even what they should be. Neither do I, for that matter. Those models are incompatible with what *you perceive* to be the requirements of crypto usage in a business environment, but I promise you there are people using crypto in a business environment who perceive things much differently. From rjh at sixdemonbag.org Wed Dec 4 02:20:07 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 03 Dec 2013 20:20:07 -0500 Subject: Renewing expiring key - done correctly? In-Reply-To: <1587922.Z1bN9dCvH3@inno.berlin.laging.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <3242368.vbyNuFUAGG@inno.berlin.laging.de> <529E7141.7030209@sixdemonbag.org> <1587922.Z1bN9dCvH3@inno.berlin.laging.de> Message-ID: <529E8347.4060001@sixdemonbag.org> On 12/3/2013 7:53 PM, Hauke Laging wrote: > Sure but it makes little sense to play best practice in one part of key > management (expiration) and simultaneously worst practice (online mainkey) in > a much more important part of key management. By introducing offline primary key storage on an air-gapped system, your policy has become so complicated that no one, yourself included, is capable of always following it to the letter. A system so complex it cannot be used correctly, won't be used correctly. This is why avoiding expiration dates, offline key storage, etc., often results in a stronger system: because by making it easier to use correctly you increase both the likelihood it will be used at all, and the likelihood it will be used correctly. From mailinglisten at hauke-laging.de Wed Dec 4 02:31:34 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 04 Dec 2013 02:31:34 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <529E8108.1080005@sixdemonbag.org> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1939706.LWtWs2ekmt@inno.berlin.laging.de> <529E8108.1080005@sixdemonbag.org> Message-ID: <3886478.Cl6uqa4JJC@inno.berlin.laging.de> Am Di 03.12.2013, 20:10:32 schrieb Robert J. Hansen: > UEFI is a surprisingly capable operating environment. If I can > compromise your machine, then I put down my own code in the UEFI loader > and wait for you to reboot your machine. That's why crypto best practices should be extended to "what hardware to buy". Of course, then the point is approaching where your next argument kicks in: Complexity which limits the usage to 1% of the population. But this is what the chipset-based write protection for flash has been invented for long ago. That, of course, doesn't exclude the possibility to hack the firmware on boot by some bogus NVRAM content... Unfortunately it seems to be impossible to ensure that a (normal) system is incapable of storing data. Disconnecting the disk just limits the available storage. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Wed Dec 4 02:45:50 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 04 Dec 2013 02:45:50 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <529E8347.4060001@sixdemonbag.org> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1587922.Z1bN9dCvH3@inno.berlin.laging.de> <529E8347.4060001@sixdemonbag.org> Message-ID: <16907708.U07IQKJZoI@inno.berlin.laging.de> Am Di 03.12.2013, 20:20:07 schrieb Robert J. Hansen: > By introducing offline primary key storage on an air-gapped system, your > policy has become so complicated that no one, yourself included, is > capable of always following it to the letter. Oh, recently I involuntarily proved that I do: I "managed" to DoS myself (what a luck nobody uses crypto) by letting my certificate expire over two days because I was to lazy to do the effort of prolongig it "securely". > A system so complex it cannot be used correctly, won't be used > correctly. Many people (not including you?) would be surprised where the "so complex" border is. When people attend to my courses and use their firmware-hacked systems to security pretendingly boot from ro media then I give them sheets of paper with the most important information. One of them is for writing their secure passphrase down (how about hacking keyboard firmware?). On that sheet it says: "This is NEVER to be entered on an insecure (te-hee) system." Recently a computer science Ph.D. student attended to my course. Guess what he did first after he had imported the subkeys onto his normal system and something didn't work the way he expected it to... But I am sure that this border does not have an absolute position. It depends on the security culture. If we manage to make crypto an everyday technology and most people around you are doing it right (te-hee) then you will probably do it right, too, even though you wouldn't today. In such a culture systems with a firmware hardware combination which allows overwriting the firmware from the OS level could not be sold any more. A better world is possible. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Wed Dec 4 03:58:25 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 04 Dec 2013 03:58:25 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <1386124373.73230.YahooMailNeo@web121004.mail.ne1.yahoo.com> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1698298.qLckIO9PU3@inno.berlin.laging.de> <1386124373.73230.YahooMailNeo@web121004.mail.ne1.yahoo.com> Message-ID: <2066474.EitT3E6bc0@inno.berlin.laging.de> Am Di 03.12.2013, 18:32:53 schrieb Eric Poellinger: > Regarding the steps I took to expire the keys (4A4DBDC7 is the primary > key, 0C0305EC is the sub) 1. gpg --edit-key 4A4DBDC7 > 1a. expire...2y > 1b. enter passphrase > 1c. quit and save It would have been more helpful to see the exact steps for the operation that does NOT work... > 2. same as #1, but for the sub-key Meaning what? As you are obviously doing something wrong this very general description isn't helpful at all. Maybe you just believe it's for the subkey. > I am not 100% sure what you mean by 'marking' the key Thus I gave the commands and (part of) the output: gpg> key 1 pub 3072R/0x711D8152 created: 2013-11-27 expires: 2014-11-27 usage: SCE trust: ultimate validity: ultimate sub* 2048R/0x48C7F0CD created: 2013-11-27 expires: 2015-12-03 usage: S After "key 1" the respective subkey is marked as "active" by the "*". > Regarding the "renewal" best practice I am thinking about scenarios where > you have automated file transfers and how to minimize the coordination > effort so as not to disrupt and data flows. A certificate update takes seconds only (and you can run it when the main process has just finished). Or just a share of a second if you suppress the trustdb calculations (or the keyring is small). > For example, if process runs > every 10 minutes to encrypt, sign and send a file, do you just have to > accept there is some 'downtime' while you update the key, send it to the > trading partner and have them import it? You can make the changes to the certificate on another system so that yours running this process doesn't have any downtime but just the one second import of the new certificate. > What if the trading partner > requires lots of paperwork (e.g. banks) like faxes on top of emails?! I do not see how this is related to the technical questions we can answer. We know nothing about this paperwork. I am not even sure what your question is. If key updates are difficult then do not update the keys (more often than really necessary). This leads to the next recommendation: secure the keys. Use them in a very limited environment only. It may make sense to create separate keys for each business contact (or at least one for each "paperwork business contact") in order to minimize the effects of activities not related to this contact to the key for this contact. Another idea: It may help to have a separate certification key (like your own CA) which is used in a "very secure" environment only. Your contacts can make a trust signature (tsign) for this key so that new (main)keys with email addresses in your domain become valid automatically. But whether this causes more or less paperwork depends on your contact's policy. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From blueapplejacks at gmail.com Wed Dec 4 04:47:59 2013 From: blueapplejacks at gmail.com (bj) Date: Tue, 3 Dec 2013 22:47:59 -0500 Subject: Fwd: Windows command line to decrypt multiple files In-Reply-To: <1461305.vlyIFjffTz@inno.berlin.laging.de> References: <1461305.vlyIFjffTz@inno.berlin.laging.de> Message-ID: Hi. Good catch. I previously did not need to supply a password to encrypt. I know the password, just not sure where to define it with GPG4Win or other method. Even though the server is internal, I want it to be secure. I could lock down file permissions if that helps. When I try #2, it gives me the following usage: gpg [options] [filename] I still get this putting the file at the end. Thanks, BJ ---------- Forwarded message ---------- From: Hauke Laging Date: Tue, Dec 3, 2013 at 2:55 PM Subject: Re: Windows command line to decrypt multiple files To: gnupg-users at gnupg.org Cc: bj Am Di 03.12.2013, 12:21:26 schrieb bj: > Where is password defined? passwort is (implicitly) defined in the keyring. The secret key is stored encrypted. You need the passphrase in order to use the key. You must know the passphrase, you cannot get it from the GnuPG installation. > *FOR /F "delims=" %%F IN ('MORE ^< "%TMP%\~encryptlist.txt"') DO (IF EXIST > %%F (ECHO Password|GPG --batch --encrypt --passphrase-fd 0 -r F75C5TE0 -o > "C:\encryptedfiles\%%F.pgp" %%F IF ERRORLEVEL == 0 DEL "%%F"))POPD* > (NEXT SECTION IS FTP TRANSFERS) I am not familiar with that DOS / Windows stuff. Just a few comments: 1) You do not need a passphrase when you encrypt files. You need the passphrase for signing and decrypting. 2) ECHO Password| gpg --passphrase-fd 0 --batch -o "..." --decrypt %%F should do. Hauke -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 585 bytes Desc: not available URL: From epoellinger at yahoo.com Wed Dec 4 03:32:53 2013 From: epoellinger at yahoo.com (Eric Poellinger) Date: Tue, 3 Dec 2013 18:32:53 -0800 (PST) Subject: Renewing expiring key - done correctly? In-Reply-To: <1698298.qLckIO9PU3@inno.berlin.laging.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1698298.qLckIO9PU3@inno.berlin.laging.de> Message-ID: <1386124373.73230.YahooMailNeo@web121004.mail.ne1.yahoo.com> First, thank you for taking the time to reply! Regarding the steps I took to expire the keys (4A4DBDC7 is the primary key,?0C0305EC is the sub) 1. gpg --edit-key?4A4DBDC7? 1a. expire...2y 1b. enter passphrase 1c. quit and save 2. same as #1, but for the sub-key I am not 100% sure what you mean by 'marking' the key - and I assume the 'quit and save' is saving the key ring Regarding the "renewal" best practice I am thinking about scenarios where you have automated file transfers and how to minimize the coordination effort so as not to disrupt and data flows. ?For example, if process runs every 10 minutes to encrypt, sign and send a file, do you just have to accept there is some 'downtime' while you update the key, send it to the trading partner and have them import it? ?What if the trading partner requires lots of paperwork (e.g. banks) like faxes on top of emails?! Thanks again for your support. On Tuesday, December 3, 2013 5:44 PM, Hauke Laging wrote: Am Di 03.12.2013, 08:22:28 schrieb Eric Poellinger: > PRIMARY QUESTIONS - I am uncertain about the sub-key.? When I attempt to > 'expire' it the date does not seem to change. What exactly did you do? Did you mark the subkey before and did you save the changes to the keyring after the expire command? gpg> key 1 pub? 3072R/0x711D8152? created: 2013-11-27? expires: 2014-11-27? usage: SCE ? ? ? ? ? ? ? ? ? ? ? trust: ultimate? ? ? validity: ultimate sub* 2048R/0x48C7F0CD? created: 2013-11-27? expires: 2015-12-03? usage: S? [...] gpg> save > Maybe you cannot expire a sub-key? You can. > SECONDARY QUESTION - is there documentation regarding 'best practices' on > managing expiring keys and renewing via sub-keys --- my theory is that > doing it this way minimizes the coordination necessary but I am not > understanding how it works if you have multiple trading partners to > coordinate with. Expiration serves two purposes: 1) Passively revoke a key if you have lost access to the secret mainkey (i.e. to the key itself or to its passphrase). 2) Force your communication partners (people are lazy) to update your certificate from time to time (requires some understanding on their side). The length of the validity period is a compromise between higher "security" and less inconvenience (your own, too). I am not sure whether I understand correctly what you mean by "renewing". You can prolong the validity of subkeys and you can replace subkeys. It's not a big difference for your communication partners. Replacing subkeys for security reasons makes real sense only if you use a secure offline mainkey. Usually you upload your certificate (public key) to a key server (or more) from where everyone can get updates of your certificate. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From blueapplejacks at gmail.com Wed Dec 4 14:11:36 2013 From: blueapplejacks at gmail.com (bj) Date: Wed, 4 Dec 2013 08:11:36 -0500 Subject: Windows command line to decrypt multiple files In-Reply-To: References: <1461305.vlyIFjffTz@inno.berlin.laging.de> Message-ID: * Hi. We are using 64bit Windows 2008 OS. I am looking forward to your suggestion. Thanks* *----------------------------------------------------------------------------------------------------------*Robert J. Hansen rjh at sixdemonbag.org Tue Dec 3 22:04:43 CET 2013 What operating system are you using? This is the sort of thing that's more appropriate for a Windows service as opposed to a batchfile. I may have something around here that is useful for your niche, but I've only tested it on a Windows 7/64 box ---------------------------------------- Forwarded message ------------------------------------------------ From: bj Date: Tue, Dec 3, 2013 at 10:47 PM Subject: Fwd: Windows command line to decrypt multiple files To: gnupg-users at gnupg.org Hi. Good catch. I previously did not need to supply a password to encrypt. I know the password, just not sure where to define it with GPG4Win or other method. Even though the server is internal, I want it to be secure. I could lock down file permissions if that helps. When I try #2, it gives me the following usage: gpg [options] [filename] I still get this putting the file at the end. Thanks, BJ ---------------------------------------- Forwarded message ------------------------------------------------ From: Hauke Laging Date: Tue, Dec 3, 2013 at 2:55 PM Subject: Re: Windows command line to decrypt multiple files To: gnupg-users at gnupg.org Cc: bj Am Di 03.12.2013, 12:21:26 schrieb bj: > Where is password defined? passwort is (implicitly) defined in the keyring. The secret key is stored encrypted. You need the passphrase in order to use the key. You must know the passphrase, you cannot get it from the GnuPG installation. > *FOR /F "delims=" %%F IN ('MORE ^< "%TMP%\~encryptlist.txt"') DO (IF EXIST > %%F (ECHO Password|GPG --batch --encrypt --passphrase-fd 0 -r F75C5TE0 -o > "C:\encryptedfiles\%%F.pgp" %%F IF ERRORLEVEL == 0 DEL "%%F"))POPD* > (NEXT SECTION IS FTP TRANSFERS) I am not familiar with that DOS / Windows stuff. Just a few comments: 1) You do not need a passphrase when you encrypt files. You need the passphrase for signing and decrypting. 2) ECHO Password| gpg --passphrase-fd 0 --batch -o "..." --decrypt %%F should do. Hauke -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 585 bytes Desc: not available URL: From shavital at gmail.com Wed Dec 4 14:03:07 2013 From: shavital at gmail.com (Charly Avital) Date: Wed, 04 Dec 2013 15:03:07 +0200 Subject: Renewing expiring key - done correctly? In-Reply-To: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> Message-ID: <529F280B.5080005@gmail.com> Eric Poellinger wrote on 12/3/13, 6:22 PM: > This is the key before issuing the 'expire' command: > > pub 2048R/4A4DBDC7 created: 2012-01-13 expires: 2014-01-12 usage: SC > trust: ultimate validity: ultimate > sub 2048R/0C0305EC created: 2012-01-13 expires: 2014-01-12 usage: E > > > I did a 2 year expiration and the master key (4A4DBDC7 ) was updated as > expected (to 2015-12-03) > > PRIMARY QUESTIONS - I am uncertain about the sub-key. When I attempt to > 'expire' it the date does not seem to change. Maybe you cannot expire a > sub-key? Maybe I do not need to care because we are not using it in our > encryption commands?? FYI, this key is only with one trading partner, > so managing the change is not difficult. I had the same problem a short time ago, and solved it with the help of a friend, and this is what I did in MacOSX's Terminal $ gpg edit-key [key ID] [..] Secret key is available, pub 2048R/[key ID] created: [..] expires: [..] usage: SC trust: ultimate validity: ultimate sub 2048R/[sub-key ID] created: [..] expires: [..] usage: E Then: > key 1 expire pub 2048R/[key ID] created: [..] expires: [..] usage: SC trust: ultimate validity: ultimate sub* 2048R/[sub-key ID] created: [..] expires: [..] usage: E [note the asterisk after sub, that indicates that this is the key which has been selected for expiry] then again: expiry I got: Changing expiration time for a subkey. Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Hope this helps. I don't know whether you can use this method in your system. You seem to be using web-mail with html format. Charly 0x15E4F2EA Mac OS X 10.9 13A603 MacBook Intel C2Duo 2GHz 13-inch, Aluminum, Late 2008 . (GnuPG/MacGPG2) 2.0.20 - gpg (GnuPG) 1.4.15 TB 24.1.1 Enigmail version 1.6 (20131006-1849) From otto at goldstockbull.com Wed Dec 4 17:10:54 2013 From: otto at goldstockbull.com (Otto Hamlin) Date: Wed, 4 Dec 2013 08:10:54 -0800 Subject: confused Message-ID: <3A68E31C-D411-4BEB-A6F4-6D496348F2E6@goldstockbull.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Open PGP is installed and working fine on my Macbook using Apple Mail. So far only have used it with one other person who also uses Open PGP. I am wanting to publicize my public key to others. Problem is I don't know what my public key is, nor do I know how to find it or make it available to others. I never gave the key to anyone yet I am somehow able to encrypt and decrypt messages with that one person mentioned above. I can't even find any sign of GPG software on my computer anywhere, only a few .pkr and .skr files I found in my Documents folder. Can anyone Help? -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSn1QPAAoJEFm2qfbOEq+yPAcH/0DMjMrRE2IAWz37A/gIM2bH uzIs0sFiyU7SplZltrJvJdZTR9KLYjKO+7VK/Wa3v2BXfj27h8rvN2zuB04GAyT6 vxYK05yoGxVa758ZZA4e4R354azMOAQjtRk3C4nHUq4hgSpNRUVlJ+zbdEcaMgrU mC8qXRNxlwiRmxpc9bJDvlcQJ0raoP+A6GV1NE4sFcAma71GyOU8ilOx1DGFpeQv juJbmwP6iXnmOrb6A69BCRF1Vky6odK5gJn47gkI+feOdOJ49xL4Qq8CcQIuW2DS nz2BBrYtn54z4Y1UJ7h3LOAum/AlUGLbrpYnreACXPHTn0QvBjZsO+yMjxiVJS4= =GGVu -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Wed Dec 4 22:25:56 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 04 Dec 2013 22:25:56 +0100 Subject: confused In-Reply-To: <3A68E31C-D411-4BEB-A6F4-6D496348F2E6@goldstockbull.com> References: <3A68E31C-D411-4BEB-A6F4-6D496348F2E6@goldstockbull.com> Message-ID: <4609077.A2P624vk2L@inno.berlin.laging.de> Am Mi 04.12.2013, 08:10:54 schrieb Otto Hamlin: > Open PGP is installed No, OpenPGP is a standard not a software and thus cannot be installed on your system (just be supported by it). You probably have gpgtools installed. Thus your question is not a GnuPG question but a gpgtools question: http://support.gpgtools.org/kb > I am wanting to publicize my public key to others. There is probably an easier way but you can open a terminal, have a look at the available keys gpg --list-keys and export yours to a keyserver (assuming one has been defined in your config file) gpg --send-keys 0x12CF0B88 or gpg --keyserver my.preferred.keyserver --send-keys 0x12CF0B88 > I never gave the key to anyone The key 0x12CF0B88 (which has signed your email) is already available on the keyservers. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From ekleog at gmail.com Thu Dec 5 00:14:10 2013 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 5 Dec 2013 00:14:10 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <529E76A1.6030205@sixdemonbag.org> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <3242368.vbyNuFUAGG@inno.berlin.laging.de> <4249245.2OFWiGlN5j@mani> <2414422.DFPHD7CR7i@inno.berlin.laging.de> <529E76A1.6030205@sixdemonbag.org> Message-ID: <20131204231410.GB18777@leortable> On Tue, Dec 03, 2013 at 07:26:09PM -0500, Robert J. Hansen wrote: > On 12/3/2013 6:59 PM, Hauke Laging wrote: > > It may be possible to prevent someone from seeing the revocation > > certificate. Certificate distribution is a lot less secure than the > > keys themselves. But you cannot trick someone into using an expired > > key. > > Of course you can. Reset their computer's clock. You don't even have > to compromise their computer in order to do it: compromising whatever > NTP server they're contacting is enough. AFAIK by default ntpd dismisses changes to the RTC when NTP time is off more than 15 min of the RTC. One would need a special flag to force it to update the clock in this case. (at least the ntpd I used) So you could only delay the expiration date by 15 min... So useful ? From will.bryant at gmail.com Thu Dec 5 01:14:27 2013 From: will.bryant at gmail.com (Will Bryant) Date: Thu, 5 Dec 2013 13:14:27 +1300 Subject: Much slower than other block cipher implementations? Message-ID: <539685F2-BF84-493C-B941-383F00C497C3@gmail.com> Hi all, My understanding is that when you encrypt a file using GPG a random session key gets generated, that gets encrypted using public key crypto, and then that session key is used to encrypt the file using a regular block cipher. Why then does GPG only encrypt at about 12 MB/s when OpenSSL can encrypt using the same block cipher at over 260 MB/s on the same machine? Is it just a faster implementation of the block cipher, or is GPG doing something else that slows it down? I'm using fairly modern Intel CPUs that do have AES instructions, so I was wondering if that was it. Cheers, Will From rjh at sixdemonbag.org Thu Dec 5 04:04:44 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 04 Dec 2013 22:04:44 -0500 Subject: Renewing expiring key - done correctly? In-Reply-To: <20131204231334.GA18777@leortable> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <3242368.vbyNuFUAGG@inno.berlin.laging.de> <4249245.2OFWiGlN5j@mani> <2414422.DFPHD7CR7i@inno.berlin.laging.de> <529E76A1.6030205@sixdemonbag.org> <20131204231334.GA18777@leortable> Message-ID: <529FED4C.6020706@sixdemonbag.org> On 12/4/2013 6:13 PM, Leo Gaspard wrote: > So you could only delay the expiration date by 15 min... So useful ? Sure. I can think of three ways to leverage a 15-minute maximum shift into dialing the clock back to whenever I want. I'm sure if I were to spend more time thinking I could find more ways. Spend some time considering the problem: it's a fun thought experiment and will help sharpen your skill at thinking like an attacker. NTP is not, and was never meant to be, secure against a malicious adversary. It's resistant against random failures, but an attacker is going to induce conditions that are very far from random. From cai.0407 at gmail.com Thu Dec 5 03:41:32 2013 From: cai.0407 at gmail.com (Kosuke Kaizuka) Date: Thu, 05 Dec 2013 11:41:32 +0900 Subject: Much slower than other block cipher implementations? In-Reply-To: <539685F2-BF84-493C-B941-383F00C497C3@gmail.com> References: <539685F2-BF84-493C-B941-383F00C497C3@gmail.com> Message-ID: <529FE7DC.7020107@gmail.com> Hi Will, On Thu, 5 Dec 2013 13:14:27 +1300, Will Bryant wrote: > Hi all, > > My understanding is that when you encrypt a file using GPG a random session key gets generated, that gets encrypted using public key crypto, and then that session key is used to encrypt the file using a regular block cipher. > > Why then does GPG only encrypt at about 12 MB/s when OpenSSL can encrypt using the same block cipher at over 260 MB/s on the same machine? > > Is it just a faster implementation of the block cipher, or is GPG doing something else that slows it down? > > I'm using fairly modern Intel CPUs that do have AES instructions, so I was wondering if that was it. Which version of GnuPG (ligcrypt) and OS are you using? As far as I know, only GnuPG 2.0.x on x86 environments supports AES-NI. 1. GnuPG 1.4.x or lower does not support AES-NI at all. 2. GnuPG 2.0.x with ligcrypt 1.5.0 and above supports AES-NI on x86 environments. 3. GnuPG 2.0.x on x86-64 Ligcrypt 1.5 branch does not support AES-NI yet on x86-64 environments. Support of AES-NI on x86-64 has been implemented to ligcrypt master[1], but not backported to current 1.5 branch[2]. [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=d8bdfa42ed582655c180e7db9b16d4e756a12a6e [2] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=shortlog;h=refs/heads/LIBGCRYPT-1-5-BRANCH -- Kosuke Kaizuka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Dec 5 08:55:10 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Dec 2013 08:55:10 +0100 Subject: Much slower than other block cipher implementations? In-Reply-To: <529FE7DC.7020107@gmail.com> (Kosuke Kaizuka's message of "Thu, 05 Dec 2013 11:41:32 +0900") References: <539685F2-BF84-493C-B941-383F00C497C3@gmail.com> <529FE7DC.7020107@gmail.com> Message-ID: <87mwkf68bl.fsf@vigenere.g10code.de> On Thu, 5 Dec 2013 03:41, cai.0407 at gmail.com said: > As far as I know, only GnuPG 2.0.x on x86 environments supports AES-NI. Right. I addition you can't compare it with a simple block cipher as implemented by OpenSSL. OpenPGP does a lot more: It hashes the text to create a signature (which most uses do). A kind of MAC is computed to detected manipulations of the ciphertext. The data is compressed. The data is split up into parts so that you do not have an optimal alignment. GnuPG may decide to use the slow 3DES algorithm (unlikely these days) and in general it has never been optimized for highest speed. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From will.bryant at gmail.com Thu Dec 5 09:52:58 2013 From: will.bryant at gmail.com (Will Bryant) Date: Thu, 5 Dec 2013 21:52:58 +1300 Subject: Much slower than other block cipher implementations? In-Reply-To: <529FE7DC.7020107@gmail.com> References: <539685F2-BF84-493C-B941-383F00C497C3@gmail.com> <529FE7DC.7020107@gmail.com> Message-ID: <8D476F42-D160-4BD6-B172-C65A82236D3A@gmail.com> Hi Kosuke, On 5/12/2013, at 15:41 , Kosuke Kaizuka wrote: > Which version of GnuPG (ligcrypt) and OS are you using? We're using 1.4.11 on Ubuntu 12.04, on x86-64. The libgcrypt11 package is 1.5.0. > 3. GnuPG 2.0.x on x86-64 > Ligcrypt 1.5 branch does not support AES-NI yet on x86-64 environments. > Support of AES-NI on x86-64 has been implemented to ligcrypt master[1], but not > backported to current 1.5 branch[2]. Ah, thanks - that sounds good, I look forward to it. I was wondering how much difference the AES-NI instructions make so today I went back to an older server running the same OS, architecture, and GnuPG version. On this server GnuPG encrypts at around 11 MB/s but OpenSSL encrypts at well over 100 MB/s (which surprised me). So the difference seems to be mostly due to other factors. I think Werner's email explains much of the remaining differences though. Thanks both, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From free10pro at gmail.com Thu Dec 5 13:20:42 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Thu, 05 Dec 2013 04:20:42 -0800 Subject: Any future for the Crypto Stick? In-Reply-To: <529D062A.3090603@digitalbrains.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> Message-ID: <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> Peter Lebbing wrote: >On 02/12/13 20:37, Andreas Schwier (ML) wrote: >> Wait a second - you can not simply hide a backdoor in a Common >Criteria >> evaluated operating system. There are too many entities that would >need >> to be involved in the process > >Why couldn't the manufacturer simply put a different, backdoored >firmware in the >card ROM than the one they showed to the other entities? Are those >other >entities physically examining the ROM mask of the final product or >somehow >bypassing the code protection and reading out the flash ROM? On that note, why assume that the manufacturer would not do the opposite: feign helping the spy agency by giving them a compromised ROM and then substituting a secure one on the real product. In either case, we are assuming the company would try to supply different bodies with different ROMs. It is not that the mentioned scenario is impossible. It is that it just seems like too much effort to be made by a company that has no benefit in such duplicity. Cheers, --Paul -- PGP: 3DB6D884 From kloecker at kde.org Thu Dec 5 19:30:07 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 05 Dec 2013 19:30:07 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <529E7141.7030209@sixdemonbag.org> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <3242368.vbyNuFUAGG@inno.berlin.laging.de> <529E7141.7030209@sixdemonbag.org> Message-ID: <1586126.av1FOtFX2Q@thufir.ingo-kloecker.de> On Tuesday 03 December 2013 19:03:13 Robert J. Hansen wrote: > On 12/3/2013 6:20 PM, Hauke Laging wrote: > > Imagine a certificate which is always prolonged for just one day. If > > this gets compromised then it will not be prolonged any more (at > > least not by its owner but we all love our highly secure offline > > mainkeys, don't we?) so everyone will notice that within hours. > > 1. The attacker can just extend the validity himself. He's > successfully compromised the key, after all. > > 2. As a consequence of #1, no one will notice. In your quotation you've snipped away too much of Hauke's message. Hauke gave two scenarios. In the second scenario > > b) the key has been compromised and cannot be revoked (because the > > owner has lost access to the secret mainkey and has neither a > > revocation certificate nor a (usable) designated revoker) your assertion is correct. In the first scenario > > a) the key has been compromised and revoked and you don't know that > > (because your last certificate update was before the revocation > > publishing) it is incorrect because the attacker cannot extend the validity of the revoked key. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Thu Dec 5 19:47:57 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 05 Dec 2013 19:47:57 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <1586126.av1FOtFX2Q@thufir.ingo-kloecker.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <529E7141.7030209@sixdemonbag.org> <1586126.av1FOtFX2Q@thufir.ingo-kloecker.de> Message-ID: <4902265.BhXMdL6RVI@inno.berlin.laging.de> Am Do 05.12.2013, 19:30:07 schrieb Ingo Kl?cker: > your assertion is correct. > > > In the first scenario > > > > a) the key has been compromised and revoked and you don't know that > > > (because your last certificate update was before the revocation > > > publishing) > > it is incorrect because the attacker cannot extend the validity of the > revoked key. You misunderstand the attack. If you completely control the system time (which is not realistic for big discrepancies, of course) then you can prevent the certificate from becoming invalid: You never reach the expiration date. BTW, OT: May I point you at this? https://bugs.kde.org/show_bug.cgi?id=318005 https://bugs.kde.org/show_bug.cgi?id=326476 https://bugs.kde.org/show_bug.cgi?id=326477 Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Thu Dec 5 20:08:22 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 05 Dec 2013 20:08:22 +0100 Subject: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?) In-Reply-To: <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> Message-ID: <52A0CF26.4070103@digitalbrains.com> On 05/12/13 13:20, Paul R. Ramer wrote: > On that note, why assume that the manufacturer would not do the opposite: > feign helping the spy agency by giving them a compromised ROM and then > substituting a secure one on the real product. In either case, we are > assuming the company would try to supply different bodies with different > ROMs. We're debating the risk that a card is backdoored. If there is such a risk, that risk still exists if we allow for the possibility that manufacturers try to do what you say. They're not mutually exclusive; how come you infer that I assume that the manufacturer would not do the opposite? But anyway: So the NSA simply buys a card from a shop, and notices that it doesn't respond to the backdoor command. Or they want to use the backdoor to get a suspect's private key, and again, the card does not respond. How is the manufacturer going to talk its way out of that? However, if you're up against specific investigation by the NSA (not the dragnet method), I think pretty much anybody will lose, backdoor or not. If they can't extract your private key, they'll simply hack your computer and batch up decryption requests to be bundled with your own next access of the card, or something similar, or something really smart I didn't think of. So it's really a question if it matters whether the NSA has a backdoor or not :). Peter. PS: the new subject line is very verbose because I wanted to avoid the risk that people interpret "Chance smartcard backdoored" as a statement rather than a question. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Thu Dec 5 20:21:50 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 05 Dec 2013 20:21:50 +0100 Subject: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?) In-Reply-To: <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> Message-ID: <52A0D24E.6090402@digitalbrains.com> On 05/12/13 13:20, Paul R. Ramer wrote: > On that note, why assume that the manufacturer would not do the opposite: > feign helping the spy agency By the way, there's a big difference. In the scenario that they install a backdoor but don't show it to the certification entities and such, they do that because they're forced to do so by the NSA (the NSA wouldn't want their backdoor certified :). If they feign helping the NSA, they aren't forced to do that, it would be their choice. > In either case, we are assuming the company would try to supply different > bodies with different ROMs. But they are completely different circumstances: force versus own choice. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From holtzm at cox.net Thu Dec 5 20:57:07 2013 From: holtzm at cox.net (Robert Holtzman) Date: Thu, 5 Dec 2013 12:57:07 -0700 Subject: Any future for the Crypto Stick? In-Reply-To: <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> Message-ID: <20131205195707.GD6976@cox.net> On Thu, Dec 05, 2013 at 04:20:42AM -0800, Paul R. Ramer wrote: > Peter Lebbing wrote: > >On 02/12/13 20:37, Andreas Schwier (ML) wrote: > >> Wait a second - you can not simply hide a backdoor in a Common > >Criteria > >> evaluated operating system. There are too many entities that would > >need > >> to be involved in the process > > > >Why couldn't the manufacturer simply put a different, backdoored > >firmware in the > >card ROM than the one they showed to the other entities? Are those > >other > >entities physically examining the ROM mask of the final product or > >somehow > >bypassing the code protection and reading out the flash ROM? > > On that note, why assume that the manufacturer would not do the opposite: feign helping the spy agency by giving them a compromised ROM and then substituting a secure one on the real product. In either case, we are assuming the company would try to supply different bodies with different ROMs. Probably because the company might be open to criminal charges. I understand that the NSA has used this threat in the past. -- Bob Holtzman Your mail is being read by tight lipped NSA agents who fail to see humor in Doctor Strangelove Key ID 8D549279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From kloecker at kde.org Thu Dec 5 21:14:08 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 05 Dec 2013 21:14:08 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <4902265.BhXMdL6RVI@inno.berlin.laging.de> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <1586126.av1FOtFX2Q@thufir.ingo-kloecker.de> <4902265.BhXMdL6RVI@inno.berlin.laging.de> Message-ID: <3396657.q0rKucJL3g@thufir.ingo-kloecker.de> On Thursday 05 December 2013 19:47:57 Hauke Laging wrote: > Am Do 05.12.2013, 19:30:07 schrieb Ingo Kl?cker: > > your assertion is correct. > > > > > > In the first scenario > > > > > > a) the key has been compromised and revoked and you don't know > > > > that > > > > (because your last certificate update was before the revocation > > > > publishing) > > > > it is incorrect because the attacker cannot extend the validity of > > the revoked key. > > You misunderstand the attack. No. I don't. :-) The attack involving control over the system time came up later in the thread. For every countermeasure there is an attack that circumvents this countermeasure, bribery and torture probably being the most effective attacks. But this doesn't mean that your argument for using key expiration, i.e. to "force" the users of the key to update the key regularly, is wrong. It just means that your argument doesn't work if your adversary can control your system clock. OTOH, your argument works if the key has been compromised by an adversary like me and you, e.g. by a colleague of the key owner (who does not happen to work for a three letter organization). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From einarr at pvv.org Thu Dec 5 21:14:34 2013 From: einarr at pvv.org (Einar Ryeng) Date: Thu, 5 Dec 2013 21:14:34 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <529B29E4.3060104@cased.de> References: <20131201114510.GA7948@pvv.ntnu.no> <529B29E4.3060104@cased.de> Message-ID: <20131205201434.GB7948@pvv.ntnu.no> On Sun, Dec 01, 2013 at 01:21:56PM +0100, arne renkema-padmos wrote: > On 12/01/2013 12:45 PM, Einar Ryeng wrote: > > > >Any news on the crypto stick (or similar initiatives) would be appreciated. > > An OpenPGP card with something like a Gemalto SIM usb adapter would > seem to fit the bill. Thanks for the replies. I've got some Crypto Sticks, so for my own use I'm covered for the time being, but I was wondering what to recommend to friends who have been trying to buy crypto sticks without luck for some time now. Gemalto SIM USB adapter seems to be sort of the same thing as the Crypto Stick. However, it is a bit more hassle to get a USB adapter and a smart card, cut the card to fit etc. The yubikey solution mentioned in the thread seems simpler in that regard, and depening on your use, you may or may not be worried that NSA or some other service has wrangled some kind of backdoor into it (which I doubt, except if they've done it by compromising security standards). None the less I'd probably opt for open solutions for my personal use just due to ethical/political reasons, but would have no worries about using Yubico stuff at work. Cheers, -- Einar Ryeng From kristian.fiskerstrand at sumptuouscapital.com Thu Dec 5 20:22:54 2013 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 05 Dec 2013 20:22:54 +0100 Subject: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?) In-Reply-To: <52A0CF26.4070103@digitalbrains.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> <52A0CF26.4070103@digitalbrains.com> Message-ID: <52A0D28E.80901@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/05/2013 08:08 PM, Peter Lebbing wrote: > On 05/12/13 13:20, Paul R. Ramer wrote: >> On that note, why assume that the manufacturer would not do the >> opposite: feign helping the spy agency by giving them a >> compromised ROM and then substituting a secure one on the real >> product. In either case, we are assuming the company would try to >> supply different bodies with different ROMs. > > We're debating the risk that a card is backdoored. If there is such > a risk, that risk still exists if we allow for the possibility that > manufacturers try to do what you say. They're not mutually > exclusive; how come you infer that I assume that the manufacturer > would not do the opposite? > The smartcard having a bad RNG as seen in [0] springs to mind. References: [0] http://sites.miis.edu/cysec/2013/10/10/taiwans-citizen-smart-card-plan-compromised-by-bad-rngs/ - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Great things are not accomplished by those who yield to trends and fads and popular opinion." (Jack Kerouac) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSoNKKAAoJEAt/i2Dj7frjgacQAKftpqC3shsP1p4oF1Ksdd25 bjS1lX/SsGUKe5ynKr6elY7NxAea6L7QH5yP9uinBYDGpZnUV9JcNAyYtwUwYlDS MwPoYXcOdoYVe/cSIJflARDBzDDdaLw/51O/4ZReeYUjOQlz5Lr+JqO0O/02FcwJ E3jKHkQo44CbpYEqF3LAIl7qua2eMwNV99hxvuUQxrj3k3FJAZaPrAP9duJkA9BA Ssvq4iBWVgikPw8jrefBrzhIpSTjSYSslXEJzgBnYsQ6zbPtWnX/15cVz8n4GWiI o06A7Obx1siIzOL/S+nJK1jv8as3JU/Q5Xh5OfvmiXhjljhjQr0lKo4DMEaQ4z6B IPJODsL8Pe6u44kC+qyZ0JABFxUlDPh4RD8xpFeJBizZPajoYfJWBEyNuW0swB5J L2WZqRITYiz/epQROp6SLPY06O2ym78twwjM/ldtH1dgVqygze15aNB0onHeSZd7 8LDvm4Dnn4F259nuPyJ0ejjtvupOu/DkHE8UShynEELuFIrxenEEULplISRJ8To9 d+bwEaX0nfPMSbj6j8cBsMa1YyxI2NHqmgPweqc9UB+FUi6Mc6/W9HfRH5XgAW+J sSZDWJvOBLWMAf6qOnCIK6WmhhlPY0YYiFQByiBF3idmVIj4iAokbr7kHvPepIMj 6tzH0YpBaNF9wSLh7tMh =fTni -----END PGP SIGNATURE----- From kloecker at kde.org Thu Dec 5 21:38:50 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 05 Dec 2013 21:38:50 +0100 Subject: Promoting the usage of OpenPGP (was: Re: Renewing expiring key - done correctly?) Message-ID: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> On Thursday 05 December 2013 19:47:57 Hauke Laging wrote: > BTW, OT: May I point you at this? > https://bugs.kde.org/show_bug.cgi?id=318005 > https://bugs.kde.org/show_bug.cgi?id=326476 > https://bugs.kde.org/show_bug.cgi?id=326477 I'm sometimes pondering a different approach. I'm quite pessimistic about being able to educate the general population about OpenPGP. Therefore, I'm wondering whether it wouldn't be better if we, the developers of Free Software mail clients, made the usage of OpenPGP (or S/MIME) for email as transparent to the users as possible. Ideally, the users wouldn't even have to notice that they are communicating via encrypted email. Unfortunately, I think email is a lost cause because there are so many different mail clients that will never support encryption. I think we have a much better chance to replace email with something new that has end-to-end encryption (and probably also authentication) built in than we have to fix email. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Thu Dec 5 22:57:34 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 05 Dec 2013 22:57:34 +0100 Subject: Promoting the usage of OpenPGP (was: Re: Renewing expiring key - done correctly?) In-Reply-To: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> References: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> Message-ID: <9245658.28CkC7uQu3@inno.berlin.laging.de> Am Do 05.12.2013, 21:38:50 schrieb Ingo Kl?cker: > On Thursday 05 December 2013 19:47:57 Hauke Laging wrote: > > BTW, OT: May I point you at this? > > https://bugs.kde.org/show_bug.cgi?id=318005 > > https://bugs.kde.org/show_bug.cgi?id=326476 > > https://bugs.kde.org/show_bug.cgi?id=326477 > > I'm sometimes pondering a different approach. That's OK but I think its obvious that in the current situation (i.e. some public attention for the subject but still ridiculously small numbers of new users with no prospect of real change) we have to at least try *everything* that seems to make sense and can be done at nearly no effort. The resources are VERY limited. The "let someone else do that" attitude simply does not work here. This is the archive of the international Cryptoparty mailinglist: http://cryptoparty.is/pipermail/global/ Does that look like a lot is going to happen beyond small groups who organize events? Not to me. I am extremely ? the diplomatic wording would be: ? disappointed about it how many people and organizations (quite related to the subject) do not even give the support which they could deliver at nearly no effort. I guess we need both a public hall of fame and a hall of shame which the media can be pointed at every time they call. It seems like a joke to me that I get hardly any feedback from the IT and political community (let alone positive feedback; thus even though that wasn't a positive response it already made you a positive exception) but good feedback and support from the cultural community. WTF? Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Dec 6 09:51:07 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Dec 2013 09:51:07 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <20131205201434.GB7948@pvv.ntnu.no> (Einar Ryeng's message of "Thu, 5 Dec 2013 21:14:34 +0100") References: <20131201114510.GA7948@pvv.ntnu.no> <529B29E4.3060104@cased.de> <20131205201434.GB7948@pvv.ntnu.no> Message-ID: <8738m64b2c.fsf@vigenere.g10code.de> On Thu, 5 Dec 2013 21:14, einarr at pvv.org said: > Gemalto SIM USB adapter seems to be sort of the same thing as the Crypto Stick. > However, it is a bit more hassle to get a USB adapter and a smart card, cut the > card to fit etc. That is not a problem. You can buy pre-punched standard OpenPGP cards: it takes less then 10 seconds to break the ID000 sized part out and put it into one of the USB stick reader (I am using an SCT2512). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 6 10:10:41 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Dec 2013 10:10:41 +0100 Subject: Promoting the usage of OpenPGP In-Reply-To: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Thu, 05 Dec 2013 21:38:50 +0100") References: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> Message-ID: <87y53y2vla.fsf@vigenere.g10code.de> On Thu, 5 Dec 2013 21:38, kloecker at kde.org said: > S/MIME) for email as transparent to the users as possible. Ideally, the > users wouldn't even have to notice that they are communicating via > encrypted email. 100% agreement here. > Unfortunately, I think email is a lost cause because there are so many > different mail clients that will never support encryption. I think we Please name those email clients. I am not aware of any mainstream mail cleint without encryption support (yes, Notes, but that is not mainstream). The real problem are webmailers. > have a much better chance to replace email with something new that has > end-to-end encryption (and probably also authentication) built in than > we have to fix email. There are some groups proposing this for some time now. A few of them have an obvious business case for their new system. However, mail will stay with us because everything works by mail. Mail has replaced letters, folder and files cabinets. You can't replace that with an online communication system, much as it is not possible to replace documents with phone call. Mail is not done for the communication but for documenting transactions. A business needs to retain most of its communication for 10 years and more. In Germany you are even required to archive certain private mails for 2 years (invoices by craftsmen). The online media is by design not able to fulfill such requirements. Well, some are saying ?you may send an attachment? using our system. But in this case you are back to standard mail with just a different transport layer (i.e. no RFC-821). RFC-822 will stay with us and it is actual trivial to secure. Given that anonymity is very hard to impossible to achieve using the current internet infrastructure, I would also claim that SMTP will stay for the foreseeable future. STARTTLS is security wise not very different from https and has a chance to work reliable as soon as we have working mechanism to replace PKIX. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christophe.brocas at cnamts.fr Fri Dec 6 10:20:38 2013 From: christophe.brocas at cnamts.fr (Christophe Brocas) Date: Fri, 06 Dec 2013 10:20:38 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <8738m64b2c.fsf@vigenere.g10code.de> References: <20131201114510.GA7948@pvv.ntnu.no> <529B29E4.3060104@cased.de> <20131205201434.GB7948@pvv.ntnu.no> <8738m64b2c.fsf@vigenere.g10code.de> Message-ID: <52A196E6.1070309@cnamts.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 06/12/2013 09:51, Werner Koch a ?crit : > On Thu, 5 Dec 2013 21:14, einarr at pvv.org said: > >> Gemalto SIM USB adapter seems to be sort of the same thing as the Crypto Stick. >> However, it is a bit more hassle to get a USB adapter and a smart card, cut the >> card to fit etc. > > That is not a problem. You can buy pre-punched standard OpenPGP cards: > it takes less then 10 seconds to break the ID000 sized part out and put > it into one of the USB stick reader (I am using an SCT2512). Recently done with : * Gemalto usb reader : http://shop.kernelconcepts.de/product_info.php?products_id=119 * OpenPGP smartcard v2 with SIM breakout : http://shop.kernelconcepts.de/product_info.php?products_id=42&language=en As saying Werner : a fast and easy move :) +1 Christophe > Shalom-Salam, > > Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQGcBAEBAgAGBQJSoZbXAAoJENlOz/4GYcu6NVIL+wRj2jL2xqOXvtc8Z0d9bBeI R6+j3gVEGbDROerWLZR6IHT2hrI1TlJlSmE3jWcSbq9PgocScFeVbgM1Mulg/YJf 2xhj2JPlMyzSZ8hWSgeqRw6Cg/3iaIpelVetdqxEwMVU+iHOgQbNnjJq0IYYoUYO Cm8kZ68l1j2scpEtRt9R0BoqunUYh44Ndt/Q1mHC/fgNkD0Rt/4JnZq8CImo2epf o1UJRsLPAdwLq11myfVORkawB4h+QHKGQcIWEp9uYWATvUQU8REjiYNOATMAF84U lmNGRIUd/6lFNH0WAvTFtoF/oa5WjQkTEu6sEf/NokESTSGRigvd6aIRuxYsFVcL 7bU2Aa0LZ+m1QBMzVUZfWq9mRc2mEat+WIMdm9niZp2ewSf4H7OC0l6JD3f9Tcyc 5BSkQrhAYU3w3KynldBMvSKbG61nEEHmxuovZ0rOu06oG9MUmhr3QNfswOelJvKq iUZ0hfrxKZFQl6mt68ZUmPpT/4AjIWP2/Pt4WI4GaQ== =LHd/ -----END PGP SIGNATURE----- ***************************************************** "Le contenu de ce courriel et ses eventuelles pi?ces jointes sont confidentiels. Ils s'adressent exclusivement ? la personne destinataire. Si cet envoi ne vous est pas destin?, ou si vous l'avez re?u par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre ? d'autres personnes ni le reproduire. Merci de le renvoyer ? l'?metteur et de le d?truire. Attention : L'Organisme de l'?metteur du message ne pourra ?tre tenu responsable de l'alt?ration du pr?sent courriel. Il appartient au destinataire de v?rifier que les messages et pi?ces jointes re?us ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses ?ventuelles pi?ces jointes sont celles de l'?metteur. Elles ne refl?tent pas la position de l'Organisme sauf s'il en est dispos? autrement dans le pr?sent courriel." ****************************************************** From robertc at broadcom.com Fri Dec 6 19:41:31 2013 From: robertc at broadcom.com (Bob (Robert) Cavanaugh) Date: Fri, 6 Dec 2013 18:41:31 +0000 Subject: Any future for the Crypto Stick? In-Reply-To: <8738m64b2c.fsf@vigenere.g10code.de> References: <20131201114510.GA7948@pvv.ntnu.no> <529B29E4.3060104@cased.de> <20131205201434.GB7948@pvv.ntnu.no> <8738m64b2c.fsf@vigenere.g10code.de> Message-ID: <8F0B09FC6339FA439524099BFCABC11F2D2C2071@IRVEXCHMB11.corp.ad.broadcom.com> If it is not violating any agreements or policies, can somebody on this thread please point to a source in the US for these products? Thanks, Bob Cavanaugh -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Werner Koch Sent: Friday, December 06, 2013 12:51 AM To: Einar Ryeng Cc: gnupg-users at gnupg.org Subject: Re: Any future for the Crypto Stick? On Thu, 5 Dec 2013 21:14, einarr at pvv.org said: > Gemalto SIM USB adapter seems to be sort of the same thing as the Crypto Stick. > However, it is a bit more hassle to get a USB adapter and a smart card, cut the > card to fit etc. That is not a problem. You can buy pre-punched standard OpenPGP cards: it takes less then 10 seconds to break the ID000 sized part out and put it into one of the USB stick reader (I am using an SCT2512). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Sat Dec 7 05:16:57 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 06 Dec 2013 23:16:57 -0500 Subject: Holiday giving Message-ID: <52A2A139.4030006@sixdemonbag.org> For some years now I've done a little bit of fundraising for GnuPG, in the form of reminding people that the holiday season is a great time to show our thanks and appreciation for the important things in life. Privacy is important to me, and I'd like to say thank-you to Werner and to the rest of the GnuPG crew for all their work in providing high-quality tools with which we may assert our right to privacy. To show this, I'm going to be making a contribution to GnuPG. And to encourage you to make your own contribution, I will match any contribution you make between now and January 1, 2014. If you donate ten euros, I'll pitch in another ten euros. If you donate a hundred euros, I'll pitch in another hundred euros. It couldn't be simpler.[1] Merry Christmas to everyone, and I hope you are all having the good fortune to spend it with your loved ones. :) [1] My generosity has no limits, but my paycheck does: my offer caps out after 250 euros. From phobos at panopticism.net Sat Dec 7 07:31:48 2013 From: phobos at panopticism.net (/dev/ph0b0s) Date: Sat, 7 Dec 2013 01:31:48 -0500 Subject: Holiday giving (crowd-funding campaign?) In-Reply-To: <52A2A139.4030006@sixdemonbag.org> References: <52A2A139.4030006@sixdemonbag.org> Message-ID: <20131207063148.GA5522@phobos.panopticism.net> I've Cc:'d Sam Tuke (listed as the Press Contact and Campaign Manager). On 12/06, Robert J. Hansen wrote: > For some years now I've done a little bit of fundraising for GnuPG, in > the form of reminding people that the holiday season is a great time to > show our thanks and appreciation for the important things in life. > Privacy is important to me, and I'd like to say thank-you to Werner and > to the rest of the GnuPG crew for all their work in providing > high-quality tools with which we may assert our right to privacy. > > To show this, I'm going to be making a contribution to GnuPG. And to > encourage you to make your own contribution, I will match any > contribution you make between now and January 1, 2014. If you donate > ten euros, I'll pitch in another ten euros. If you donate a hundred > euros, I'll pitch in another hundred euros. It couldn't be simpler.[1] Wow, that's very generous of you, Robert. Thank you very much. Related: A month or so ago, a post on the GnuPG blog mentioned a crowd-funding campaign that was to be launched "in early December". Details were scarce, however. This sounds like perfect timing; perhaps either Sam or Werner can provide us with an update on the campaign? Thanks, /p From einarr at pvv.org Sat Dec 7 11:29:32 2013 From: einarr at pvv.org (Einar Ryeng) Date: Sat, 7 Dec 2013 11:29:32 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <8F0B09FC6339FA439524099BFCABC11F2D2C2071@IRVEXCHMB11.corp.ad.broadcom.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B29E4.3060104@cased.de> <20131205201434.GB7948@pvv.ntnu.no> <8738m64b2c.fsf@vigenere.g10code.de> <8F0B09FC6339FA439524099BFCABC11F2D2C2071@IRVEXCHMB11.corp.ad.broadcom.com> Message-ID: <20131207102932.GC7948@pvv.ntnu.no> On Fri, Dec 06, 2013 at 06:41:31PM +0000, Bob (Robert) Cavanaugh wrote: > If it is not violating any agreements or policies, can somebody on this > thread please point to a source in the US for these products? AFAIK, the US has no import restrictions on cryptography, and the RSA patent ran out years ago, so e.g. shop.kernelconcepts.de should be able to ship it to you. -- Einar Ryeng From dan at geer.org Sun Dec 8 05:59:08 2013 From: dan at geer.org (dan at geer.org) Date: Sat, 07 Dec 2013 23:59:08 -0500 Subject: UK Guardian newspaper publishes USA NSA papers In-Reply-To: Your message of "Mon, 04 Nov 2013 21:29:24 GMT." <909795965.20131104212924@my_localhost> Message-ID: <20131208045908.DFBC722809C@palinka.tinho.net> > "You don't need to be talking to a terror suspect to have your > communications data analysed by the NSA. The agency is allowed to > travel "three hops" from its targets." Barnett, "Facebook Cuts Six Degrees of Separation to Four," 22 November 2011 http://www.telegraph.co.uk/technology/facebook/8906693/Facebook-cuts-six-degrees-of-separation-to-four.html average distance on Twitter is 4.67, as found in "Six Degrees of Separation, Twitter Style," 30 April 2010 http://www.sysomos.com/insidetwitter/sixdegrees/ or maybe it is only 3.43, as found in Bakhshandeh, Samadi, Azimifar & Schaeffer, "Degrees of Separation in Social Networks," 2011 http://www.aaai.org/ocs/index.php/SOCS/SOCS11/paper/view/4031 "Allowed three hops" is closer to a grand mal seizure than a twitch. For a sideline, look up "percolation theory." --dan From wk at gnupg.org Sun Dec 8 11:31:36 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 08 Dec 2013 11:31:36 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <20131207102932.GC7948@pvv.ntnu.no> (Einar Ryeng's message of "Sat, 7 Dec 2013 11:29:32 +0100") References: <20131201114510.GA7948@pvv.ntnu.no> <529B29E4.3060104@cased.de> <20131205201434.GB7948@pvv.ntnu.no> <8738m64b2c.fsf@vigenere.g10code.de> <8F0B09FC6339FA439524099BFCABC11F2D2C2071@IRVEXCHMB11.corp.ad.broadcom.com> <20131207102932.GC7948@pvv.ntnu.no> Message-ID: <87iouzzl9z.fsf@vigenere.g10code.de> On Sat, 7 Dec 2013 11:29, einarr at pvv.org said: > AFAIK, the US has no import restrictions on cryptography, and the RSA patent > ran out years ago, so e.g. shop.kernelconcepts.de should be able to ship it to > you. IIRC, Petra of kernelconcepts told me that there is no problem for them to ship to the US. You may also order by simple or encrypted mail (Petra's fingerprint is on their website); the shop is merely an email frontend to them. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From free10pro at gmail.com Sun Dec 8 11:51:49 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Sun, 08 Dec 2013 02:51:49 -0800 Subject: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?) In-Reply-To: <52A0CF26.4070103@digitalbrains.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> <52A0CF26.4070103@digitalbrains.com> Message-ID: <44baa3bf-7046-4fa8-aeb5-f2399614c177@email.android.com> Peter Lebbing wrote: >On 05/12/13 13:20, Paul R. Ramer wrote: >> On that note, why assume that the manufacturer would not do the >opposite: >> feign helping the spy agency by giving them a compromised ROM and >then >> substituting a secure one on the real product. In either case, we are >> assuming the company would try to supply different bodies with >different >> ROMs. > >We're debating the risk that a card is backdoored. If there is such a >risk, that >risk still exists if we allow for the possibility that manufacturers >try to do >what you say. They're not mutually exclusive; how come you infer that I >assume >that the manufacturer would not do the opposite? It was not my intent to make it seem that I had made any insinuations on your part. It was more that I wanted to express an alternate possibility rather than the nefarious one that was being discussed. It seemed that the only scenario involving pressure or coercion on the part of the U.S. being discussed was one of compliance by the company rather than a range of possibilities. Events in life do not always happen neatly and predictably. If we are going to discuss outcomes, we need to talk about more than one. Cheers, --Paul -- PGP: 3DB6D884 From wk at gnupg.org Sun Dec 8 11:54:01 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 08 Dec 2013 11:54:01 +0100 Subject: Holiday giving (crowd-funding campaign?) In-Reply-To: <20131207063148.GA5522@phobos.panopticism.net> (dev's message of "Sat, 7 Dec 2013 01:31:48 -0500") References: <52A2A139.4030006@sixdemonbag.org> <20131207063148.GA5522@phobos.panopticism.net> Message-ID: <87eh5nzk8m.fsf@vigenere.g10code.de> On Sat, 7 Dec 2013 07:31, phobos at panopticism.net said: > Details were scarce, however. This sounds like perfect timing; perhaps > either Sam or Werner can provide us with an update on the campaign? Sam is preparing the campaign and twittering on https://twitter.com/gnupg . This campaign will be about a better website and easier accessible information on GnuPG. Sam already has some sketches for the new website for example https://twitter.com/gnupg/status/408611650887905280 GnuPG has for too long been a tool like a sendmail/exim/postfix but deserves more user attention. This is what we want to change. In the course of the preparation, Sam convinced be that we need Twitter and even web site statistics. I have done the latter only the first two years of running GnuPG but stopped that for privacy reasons. Now we installed Piwik and people with JS enabled are tracked by us. Of course this is pseudo-anonymized and we won't hand out the raw data to anyone outside of g10 code. Piwik gives some interesting insights, for example most direct visits to gpg4win.org come from gnupg.org. Aside from the usual Google triggered visits, lifehacker.com and philzimmermann.com are top listed referrers for gnupg.org. gnupg.org has 2000 to 3000 visits a day, gpg4win.org 1500 to 2500. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ms at it-infrastrukturen.org Sun Dec 8 14:15:51 2013 From: ms at it-infrastrukturen.org (Mark Schneider) Date: Sun, 08 Dec 2013 14:15:51 +0100 Subject: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?) In-Reply-To: <44baa3bf-7046-4fa8-aeb5-f2399614c177@email.android.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> <52A0CF26.4070103@digitalbrains.com> <44baa3bf-7046-4fa8-aeb5-f2399614c177@email.android.com> Message-ID: <52A47107.7090902@it-infrastrukturen.org> Am 08.12.2013 11:51, schrieb Paul R. Ramer: > Peter Lebbing wrote: >> We're debating the risk that a card is backdoored. If there is such a >> risk, that >> risk still exists if we allow for the possibility that manufacturers >> try to do >> what you say. They're not mutually exclusive; how come you infer that I >> assume >> that the manufacturer would not do the opposite? > It was not my intent to make it seem that I had made any insinuations on your part. It was more that I wanted to express an alternate possibility rather than the nefarious one that was being discussed. > > It seemed that the only scenario involving pressure or coercion on the part of the U.S. being discussed was one of compliance by the company rather than a range of possibilities. Events in life do not always happen neatly and predictably. If we are going to discuss outcomes, we need to talk about more than one. Looking backwards (history) if there was a possibility to build in a backdoor such one always had happened and had been exploited. It applied and still applies for "most" of commercial IT software and hardware vendors and even such OSS projects focused on securiry like openBSD (in the past). Smart cards are good only for a certain level of privacy to keep rather primitive ciriminals away. As long everyone is not able to audit the source code of firmware or operating systems (in particular closed source software products) there are a lot of other possibilities to steal your secrets. I didn't follow the history of the CryptoStick until now but I would like to add my "few cents" somewhere later. An idea would be not to trust anyone and to create so called linux live images yourself. (saving them on a read-only medium and booting from it into live mode). Example and some description how to do it: http://rsync.it-infrastrukturen.org/banque-live/ http://git.it-infrastrukturen.org/banque-live.git Due to my limited time resources all existing .iso images there are currently NOT up to date (8 months old). It is for me a time intensive challenge to patch gnupg 2.0 or the much more interesting 2.1 to support longer keys and create .deb packages with all dependencies. (like RSA 15k .. even they are not inside "secure" standards .. from my "paranoid" point of view) A little security is not real security. There always can be backdoors in the firmware (BIOS, closed source drivers etc). Kind regards, Mark -- ms at it-infrastrukturen.org http://rsync.it-infrastrukturen.org From cryptostick at privacyfoundation.de Sun Dec 8 13:56:01 2013 From: cryptostick at privacyfoundation.de (Crypto Stick) Date: Sun, 08 Dec 2013 13:56:01 +0100 Subject: Any future for the Crypto Stick? In-Reply-To: <20131201114510.GA7948@pvv.ntnu.no> References: <20131201114510.GA7948@pvv.ntnu.no> Message-ID: <52A46C61.3050704@privacyfoundation.de> Regarding the initial question, the Crypto Stick is under active development and we are working to make the Crypto Stick available again. Here I'm posting a short status overview published at https://www.crypto-stick.com/2013/project-roadmap In the recent weeks we got increasing questions on the status and future of the project. Other than our website might indicate, we are continuously developing but we should do better in order to keep you updated. Now, let's give you an overview: You may have noticed that the Crypto Stick is out of stock for a while already. We are working on a new device (think of it as a version 1.4) which super seeds the current Crypto Stick. To achieve better robustness the integrated smart card won't be soldered anymore but be inserted. The device will contain a new OATH (not OAuth) one-time-password feature which is the same standard used by the Google Authenticator. This device enables you to securely and easily login to popular websites like Amazon Web Services, DropBox, GMail, GDocs etc. without entering a password. Furthermore the Crypto Stick will have a smaller and custom-made casing. The long-awaited Crypto Stick "version 2" containing an encrypted storage is still under development. We shipped a few devices as part of a closed beta program and we are currently investigating a bug (#42) which occasionally prevents the device from starting up properly, primarily under Linux. For this purpose we did setup a test- and metering-installation and run test scripts to nail the problem down. The error seems to occur only once in a few thousand startup cycles which doesn't make life easier for us. There are a few more things to do and you may want to follow the progress in our ticketing system. Furthermore we plan to release a Crypto Stick "light" without a smart card and without storage. It will be based on GNUK which is a software-only implementation of the OpenPGP Card which is executed by the STM32 microprocessor. Eventually all three flavors will be available in parallel to address different demands. Now you may be interested to know when the new devices will be ready. Since our earlier estimations were wrong, we won't comment on specific release dates anymore. The "version 1.4" with the one-time-password feature is available as "series zero" which means we have 20 devices to currently undergo intensive testing. Unless significant bugs are found, the next step would be to release the device and start the production. Because of some pending work items the "version 2" (with storage) may take a while to be released for production. Please subscribe to this newsletter or blog where we will announce any news and releases. Am 01.12.2013 12:45, schrieb Einar Ryeng: > Hi. > > The GPF Crypto Stick has been unavailable for months now, and I wondered if > anyone here has information on its future. > > After the German Privacy Foundation apparently closed down this summer, I've > started getting worried that we've seen the end of what I consider the most > practical hardware token for GPG. > > Any news on the crypto stick (or similar initiatives) would be appreciated. > > Cheers, > From free10pro at gmail.com Sun Dec 8 15:14:01 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Sun, 08 Dec 2013 06:14:01 -0800 Subject: Any future for the Crypto Stick? In-Reply-To: <87iouzzl9z.fsf@vigenere.g10code.de> References: <20131201114510.GA7948@pvv.ntnu.no> <529B29E4.3060104@cased.de> <20131205201434.GB7948@pvv.ntnu.no> <8738m64b2c.fsf@vigenere.g10code.de> <8F0B09FC6339FA439524099BFCABC11F2D2C2071@IRVEXCHMB11.corp.ad.broadcom.com> <20131207102932.GC7948@pvv.ntnu.no> <87iouzzl9z.fsf@vigenere.g10code.de> Message-ID: <6ee1468a-b0d1-423c-b48c-af2975c8cc81@email.android.com> Werner Koch wrote: >On Sat, 7 Dec 2013 11:29, einarr at pvv.org said: > >> AFAIK, the US has no import restrictions on cryptography, and the RSA >patent >> ran out years ago, so e.g. shop.kernelconcepts.de should be able to >ship it to >> you. > >IIRC, Petra of kernelconcepts told me that there is no problem for them >to ship to the US. You may also order by simple or encrypted mail >(Petra's fingerprint is on their website); the shop is merely an email >frontend to them. I am in the U.S., and I have ordered successfully a couple of times. Cheers, --Paul -- PGP: 3DB6D884 From rjh at sixdemonbag.org Sun Dec 8 16:48:19 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 08 Dec 2013 10:48:19 -0500 Subject: UK Guardian newspaper publishes USA NSA papers In-Reply-To: <20131208045908.DFBC722809C@palinka.tinho.net> References: <20131208045908.DFBC722809C@palinka.tinho.net> Message-ID: <52A494C3.3030301@sixdemonbag.org> On 12/7/2013 11:59 PM, dan at geer.org wrote: > average distance on Twitter is 4.67... And, of course, the distance to felons is far less. There isn't a single person on this list whose distance to a pedophile is more than two hops, for instance... The hop counts of modern social networks are flat-out *scary*. From ekleog at gmail.com Thu Dec 5 21:50:47 2013 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 5 Dec 2013 21:50:47 +0100 Subject: Renewing expiring key - done correctly? In-Reply-To: <529FED4C.6020706@sixdemonbag.org> References: <1386087748.24656.YahooMailNeo@web121005.mail.ne1.yahoo.com> <3242368.vbyNuFUAGG@inno.berlin.laging.de> <4249245.2OFWiGlN5j@mani> <2414422.DFPHD7CR7i@inno.berlin.laging.de> <529E76A1.6030205@sixdemonbag.org> <20131204231334.GA18777@leortable> <529FED4C.6020706@sixdemonbag.org> Message-ID: <20131205205047.GA466@leortable> On Wed, Dec 04, 2013 at 10:04:44PM -0500, Robert J. Hansen wrote: > On 12/4/2013 6:13 PM, Leo Gaspard wrote: > > So you could only delay the expiration date by 15 min... So useful ? > > Sure. I can think of three ways to leverage a 15-minute maximum shift > into dialing the clock back to whenever I want. I'm sure if I were to > spend more time thinking I could find more ways. Spend some time > considering the problem: it's a fun thought experiment and will help > sharpen your skill at thinking like an attacker. > > NTP is not, and was never meant to be, secure against a malicious > adversary. It's resistant against random failures, but an attacker is > going to induce conditions that are very far from random. I only have in mind moving the clock 15min by 15min, but thought this method could not be used. Indeed, the clock can only be reset 1000s by 1000s, and by default I thought ntpd queries the server 1024s by 1024s, thus allowing the attacker only to slow down time on the machine. However, it seems that by sending times not exactly 1000s apart from the machine clock but alternatively 1000s - clock jitter and 1000s, you could force the query time to be back to 64s, thus making this attack possible. However, a basic security measure (setting panic threshold to 50s, as there is no reason the local time should be off by more than 50s, being re-updated every 1024s at most) would be enough to counter this fact. BTW, reading more about ntpd [1], I learned that the query time could not be back more than 300s. So, even in an unconfigured system, the attacker would have to be in control of the victim's network for at least half the time since the expiration date. Granted, this is not a lot (especially knowing the attacker could have been attacking since before the expiration date), but is better than mere immediate clock setting. And this 300s delay could be arbitrarily increased, thus allowing to counter the attack by a second mean : setting it to more than 2000s, for example. Finally, I believe the user would notice, if their computer clock was suddenly off one day / month / year / more... One last comments : not everyone uses NTP (e.g. I rely on RTC, once in a while syncing it with my watch -- did not have to for a year, and I'm 2min off) Just wondering... What are your other two solutions ? [1] http://www.eecis.udel.edu/~mills/ntp/html/clock.html From ndk.clanbo at gmail.com Sun Dec 8 19:13:52 2013 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 08 Dec 2013 19:13:52 +0100 Subject: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?) In-Reply-To: <52A47107.7090902@it-infrastrukturen.org> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> <52A0CF26.4070103@digitalbrains.com> <44baa3bf-7046-4fa8-aeb5-f2399614c177@email.android.com> <52A47107.7090902@it-infrastrukturen.org> Message-ID: <52A4B6E0.8040705@gmail.com> Il 08/12/2013 14:15, Mark Schneider ha scritto: > A little security is not real security. There always can be backdoors in > the firmware (BIOS, closed source drivers etc). Why is everyone thinking 'BIOS' as backdoorable piece of sw? Why not the hard disk? http://spritesmods.com/?art=hddhack Just another piece to think of when building a secure system... BYtE, Diego. From ms at it-infrastrukturen.org Sun Dec 8 21:13:34 2013 From: ms at it-infrastrukturen.org (Mark Schneider) Date: Sun, 08 Dec 2013 21:13:34 +0100 Subject: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?) In-Reply-To: <52A4B6E0.8040705@gmail.com> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> <52A0CF26.4070103@digitalbrains.com> <44baa3bf-7046-4fa8-aeb5-f2399614c177@email.android.com> <52A47107.7090902@it-infrastrukturen.org> <52A4B6E0.8040705@gmail.com> Message-ID: <52A4D2EE.2020504@it-infrastrukturen.org> Am 08.12.2013 19:13, schrieb NdK: > Why is everyone thinking 'BIOS' as backdoorable piece of sw? Why not the > hard disk? > http://spritesmods.com/?art=hddhack > > Just another piece to think of when building a secure system... Excellent article! Thank you. Writing firmware I meant every piece of code "for / inside" all involved hardware components and in particular with their own controllers (eg. keyboard, USB ...) and not only the BIOS of the motherboard. Some backdoors can be hardcoded in the hardware of controller chips (eg. network controller etc). Sending a special sequence of data to them can turn them in the "debug or whatever" mode. Hacking smartcards is more complicated but possible. BTW: there is no video at: http://achtbaan.nikhef.nl/events/OHM/video/d2-t1-13-20130801-2300-hard_disks_more_than_just_block_devices-sprite_tm.m4v Kind regards, Mark -- ms at it-infrastrukturen.org http://rsync.it-infrastrukturen.org From peter at digitalbrains.com Sun Dec 8 21:26:14 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 08 Dec 2013 21:26:14 +0100 Subject: Is there a chance smartcards have a backdoor? (was Re: Any future for the Crypto Stick?) In-Reply-To: <52A4D2EE.2020504@it-infrastrukturen.org> References: <20131201114510.GA7948@pvv.ntnu.no> <529B6B77.4090404@netpage.dk> <529B6B77.4090404@netpage.dk> <529B896F.1000704@internexusconnect.net> <529C9804.4030603@gmail.com> <529CD272.5040901@digitalbrains.com> <529CE163.9080503@cardcontact.de> <529D062A.3090603@digitalbrains.com> <30806aba-3011-492d-a1b9-8a99da3555b4@email.android.com> <52A0CF26.4070103@digitalbrains.com> <44baa3bf-7046-4fa8-aeb5-f2399614c177@email.android.com> <52A47107.7090902@it-infrastrukturen.org> <52A4B6E0.8040705@gmail.com> <52A4D2EE.2020504@it-infrastrukturen.org> Message-ID: <52A4D5E6.8070203@digitalbrains.com> On 08/12/13 21:13, Mark Schneider wrote: > BTW: there is no video at: > http://achtbaan.nikhef.nl/events/OHM/video/d2-t1-13-20130801-2300-hard_disks_more_than_just_block_devices-sprite_tm.m4v You can find it at: http://bofh.nikhef.nl/events/OHM/video/d2-t1-13-20130801-2300-hard_disks_more_than_just_block_devices-sprite_tm.m4v And I've just told Sprite the link is dead :). I was just telling him he was just featured on this mailing list :). HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mailinglisten at hauke-laging.de Sun Dec 8 22:11:25 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 08 Dec 2013 22:11:25 +0100 Subject: determine the source(s) of validity Message-ID: <4768519.Z4uxJCJdye@inno.berlin.laging.de> Hello, I want to find out what makes a key valid (and with which certification level): a certification by one of the systems keys or one or more certifications from the WoT. I think that it is important that applications show this information in key selection dialogs. IIRC this has been discussed here a while ago and there is no way to get this information from GnuPG. I would like to know whether there is already software available which does this; no need to reinvent the wheel. If there isn't any I would do this (but maybe there is a better approach): 1) Find all keys which have ultimate trust. BTW: I noticed that a key becomes invalid if its certifying key expires and has complete trust. But if it has ultimate trust then the expiration does not make the certification invalid. Is this intentional? 2) Import all these keys plus the key to be checked (with import-clean) into a new keyring (with a separate trustdb). 3) If (the key was valid in the normal keyring and) the key is not valid in the check keyring then it is validated via the WoT. Otherwise I can look for the signature with the highest certification level (I am interested in this information). Another, related question: I was surprised to read the recommendation to create a local certification for keys which have been validated via the WoT. But the one who wrote that seems extremely competent to me with respect to OpenPGP. Is there a general concensus on that? What are your opinions? Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Mon Dec 9 04:26:54 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 09 Dec 2013 04:26:54 +0100 Subject: Holiday giving In-Reply-To: <52A2A139.4030006@sixdemonbag.org> References: <52A2A139.4030006@sixdemonbag.org> Message-ID: <3057883.RXJJT4KrjY@inno.berlin.laging.de> Am Fr 06.12.2013, 23:16:57 schrieb Robert J. Hansen: > And to encourage you to make your own contribution, And to make that easier I add the URL: http://www.g10code.de/gnupg-donation.html Furthermore I would like to encourage everyone to spread the mailinglist archive link to Rob's mail (together with the one above) via your blog, social network profile and so on: http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048332.html Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Mon Dec 9 11:16:03 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 09 Dec 2013 11:16:03 +0100 Subject: determine the source(s) of validity In-Reply-To: <4768519.Z4uxJCJdye@inno.berlin.laging.de> References: <4768519.Z4uxJCJdye@inno.berlin.laging.de> Message-ID: <52A59863.3020509@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/12/13 22:11, Hauke Laging wrote: > IIRC this has been discussed here a while ago and there is no way to get > this information from GnuPG. I would like to know whether there is already > software available which does this; no need to reinvent the wheel. The Debian package signing-party has some tools working on this info, but I don't think you can get the information you're really after, unfortunately. It goes some way towards achieving it, though. $ gpg --list-sig|sig2dot >sigs.dot will create a .dot file for Graphviz and similar tools that has keys as nodes and signatures as edges. $ springgraph sigs.png will create a picture of that graph; it's an alternative tool to the ones provided by Graphviz. Some other statistics can be had by: $ pgpring -S -k ~/.gnupg/pubring.gpg|process_keys >preprocess.keys $ keyanalyze The first command will create a file preprocess.keys and the second a directory called 'output' with distance analysis and stuff on the keys. None of these commands take the trust database into account, AFAIK[1]. A program that would take the output of --export-trustdb and the sigs.dot file and annotates it with validity information would be cool. Perhaps pruning sigs.dot to only include valid signatures. > If there isn't any I would do this (but maybe there is a better approach): I think the better approach is to write a tool combining --export-trustdb and the sigs.dot file ;). > BTW: I noticed that a key becomes invalid if its certifying key expires and > has complete trust. But if it has ultimate trust then the expiration does > not make the certification invalid. Is this intentional? I think it's intentional. You would typically use ultimate trust for your own keys. And if your own key expires, you might still very well trust the certifications you made with that key. If the key of a fully trusted person expires, that key no longer "validly represents" that person, and perhaps its certifications can't be trusted anymore. I suppose the bond between you and an ultimately trusted key is so strong that you are supposed to know all there is to know about that key, and you should revoke the ultimate trust if you no longer have ultimate trust in that key. Ultimate trust: I don't care what anybody says, I believe in you. > Another, related question: I was surprised to read the recommendation to > create a local certification for keys which have been validated via the > WoT. But the one who wrote that seems extremely competent to me with > respect to OpenPGP. Is there a general concensus on that? What are your > opinions? In and of itself, it sounds unnecessary. The most important reason you would make a local sig, is to make a key valid, but if it's already valid through the Web of Trust, that's no longer necessary. It also creates the burden of maintenance: through expiry or revocation of keys and signatures, your WoT might at some point no longer consider a key to be valid. But you did a local sig, so the key stays valid. You might not notice that the validity has diminished. But suppose that in certain scenario's, you consider a key (which isn't valid yet) as "valid enough", but don't want to announce this to the world. I've been pressing my point lately that I strongly believe your exportable signatures should represent verification effort, not a belief of validity. Still, you might want to use that belief of validity that you have to make a key valid in your own keyring. This sounds like a perfect use case for a local signature. There might well be a scenario where you local-sign a key that's already valid through the Web-of-Trust, but I can't think of one just now. HTH, Peter. [1] Since you give either the public keyring file, or the output of gpg - --list-sig, very explicit input that doesn't include trust, it seems highly unlikely that those programs also access the trust database on their own. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From parcarlssonlong at gmail.com Fri Dec 6 19:54:53 2013 From: parcarlssonlong at gmail.com (=?ISO-8859-1?Q?P=E4r_Carlsson?=) Date: Fri, 6 Dec 2013 19:54:53 +0100 Subject: Simple encryption/decryption Message-ID: Hi. I have a very simple thing I want to do and I have not found out how. I want to send/receive receive files to a FTP-server. The files has to be encrypted when it's sent to FTP. Vice versa I will receive files which I have to decrypt. In the best of worlds I thougth this was very simple using gnupg. Something like this perhaps but not.... gnupg --encrypt myFile.txt --myPrivateKey --output myEncryptedFile and gnupg --decrypt anEncryptedFile --theirPublicKey --output myDecryptedFile.txt -- /p -------------- next part -------------- An HTML attachment was scrubbed... URL: From einarr at pvv.org Mon Dec 9 14:52:52 2013 From: einarr at pvv.org (Einar Ryeng) Date: Mon, 9 Dec 2013 14:52:52 +0100 Subject: Simple encryption/decryption In-Reply-To: References: Message-ID: <20131209135252.GD7948@pvv.ntnu.no> On Fri, Dec 06, 2013 at 07:54:53PM +0100, P?r Carlsson wrote: > > I have a very simple thing I want to do and I have not found out how. > > I want to send/receive receive files to a FTP-server. The files has to be > encrypted when it's sent to FTP. Vice versa I will receive files which I > have to decrypt. > > In the best of worlds I thougth this was very simple using gnupg. Something > like this perhaps but not.... I may have misunderstood your post, but it seems like you're asking how to do the most basic public key encryption/decryption operations in gpg. If so, you probably want to read some of the documentation to become familiar with the concepts. However, here are what I think you're asking for: > gnupg --encrypt myFile.txt --myPrivateKey --output myEncryptedFile (assuming you want to encrypt something to someone else, and their key ID is 12341234, which it isn't) gpg -e -a -r 12341234 somefile.txt This will produce a file named somefile.txt.asc which is encrypted and base-64-encoded to be friendly towards any FTP protocol settings. > and > > gnupg --decrypt anEncryptedFile --theirPublicKey --output > myDecryptedFile.txt To decrypt a file that is encrypted to you, type: gpg somefile.txt.asc or, if the encryption was done without -a gpg somefile.txt.gpg Both of these will decrypt the file and produce a file named somefile.txt, provided that you have the private key they are encrypted to. (The GnuPG executable is usually named just gpg on linux, I'm not sure what the command is called if you're on another operating system) Cheers, -- Einar Ryeng From avi.wiki at gmail.com Mon Dec 9 16:48:16 2013 From: avi.wiki at gmail.com (Avi) Date: Mon, 9 Dec 2013 10:48:16 -0500 Subject: Holiday giving In-Reply-To: <52A2A139.4030006@sixdemonbag.org> References: <52A2A139.4030006@sixdemonbag.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OK, Robert. You're on the hook for at least ?100. :) Thank you for the reminder, and thank you, Werner and your team, for the decades of work and toil whose fruits you have donated to the world at large. Avi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) - GPGshell v3.78 Comment: Most recent key: Click show in box @ http://is.gd/4xJrs iL4EAREIAGYFAlKl5c9fGGh0dHA6Ly9rZXlzZXJ2ZXIudWJ1bnR1LmNvbS9wa3Mv bG9va3VwP29wPWdldCZoYXNoPW9uJmZpbmdlcnByaW50PW9uJnNlYXJjaD0weDBE NjJCMDE5RjgwRTI5RjkACgkQDWKwGfgOKfm2QgD9HPwMa7wWcyRW8EL63UVoAlwc PhpksJt0yfEyH0II91wA/jck/BI65+kXOSQ4k/rwGBS9CIebBlyinVb5J1GYHWzj =1Jnv -----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 On Fri, Dec 6, 2013 at 11:16 PM, Robert J. Hansen wrote: > For some years now I've done a little bit of fundraising for GnuPG, in > the form of reminding people that the holiday season is a great time to > show our thanks and appreciation for the important things in life. > Privacy is important to me, and I'd like to say thank-you to Werner and > to the rest of the GnuPG crew for all their work in providing > high-quality tools with which we may assert our right to privacy. > > To show this, I'm going to be making a contribution to GnuPG. And to > encourage you to make your own contribution, I will match any > contribution you make between now and January 1, 2014. If you donate > ten euros, I'll pitch in another ten euros. If you donate a hundred > euros, I'll pitch in another hundred euros. It couldn't be simpler.[1] > > Merry Christmas to everyone, and I hope you are all having the good > fortune to spend it with your loved ones. :) > > > > [1] My generosity has no limits, but my paycheck does: my offer > caps out after 250 euros. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Mon Dec 9 20:36:13 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 09 Dec 2013 20:36:13 +0100 Subject: Promoting the usage of OpenPGP In-Reply-To: <87y53y2vla.fsf@vigenere.g10code.de> References: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> <87y53y2vla.fsf@vigenere.g10code.de> Message-ID: <7304409.289d5sHYbK@thufir.ingo-kloecker.de> On Friday 06 December 2013 10:10:41 Werner Koch wrote: > On Thu, 5 Dec 2013 21:38, kloecker at kde.org said: > > Unfortunately, I think email is a lost cause because there are so > > many different mail clients that will never support encryption. I > > think we > > Please name those email clients. I am not aware of any mainstream > mail cleint without encryption support (yes, Notes, but that is not > mainstream). The real problem are webmailers. Exactly. Webmailers was what I was thinking about. And probably mail clients used on mobile devices. I don't know how many of those support encryption. > > have a much better chance to replace email with something new that > > has end-to-end encryption (and probably also authentication) built > > in than we have to fix email. > > There are some groups proposing this for some time now. A few of them > have an obvious business case for their new system. > > However, mail will stay with us because everything works by mail. > Mail has replaced letters, folder and files cabinets. You can't > replace that with an online communication system, much as it is not > possible to replace documents with phone call. Mail is not done for > the communication but for documenting transactions. Where? AFAIK, in Germany, we still have to send faxes or registered letters with reply advice because email is not approved. (Well, maybe de-mail or whatever it's called is, but who's using that?) > A business needs > to retain most of its communication for 10 years and more. In > Germany you are even required to archive certain private mails for 2 > years (invoices by craftsmen). The online media is by design not > able to fulfill such requirements. What do you mean by "online media"? Is de-mail such an "online medium"? > Well, some are saying ?you may send an attachment? using our system. > But in this case you are back to standard mail with just a different > transport layer (i.e. no RFC-821). RFC-822 will stay with us and it > is actual trivial to secure. Given that anonymity is very hard to > impossible to achieve using the current internet infrastructure, I > would also claim that SMTP will stay for the foreseeable future. > STARTTLS is security wise not very different from https and has a > chance to work reliable as soon as we have working mechanism to > replace PKIX. I don't dispute that. And yes, key exchange is the real challenge. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Dec 9 21:40:03 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Dec 2013 21:40:03 +0100 Subject: Promoting the usage of OpenPGP In-Reply-To: <7304409.289d5sHYbK@thufir.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Mon, 09 Dec 2013 20:36:13 +0100") References: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> <87y53y2vla.fsf@vigenere.g10code.de> <7304409.289d5sHYbK@thufir.ingo-kloecker.de> Message-ID: <87haahwyfw.fsf@vigenere.g10code.de> On Mon, 9 Dec 2013 20:36, kloecker at kde.org said: > Exactly. Webmailers was what I was thinking about. And probably mail > clients used on mobile devices. I don't know how many of those support > encryption. Well Kontact for N900 and Windows Mobile 6.5 has very good support (as long as you carry an extra spare battery with you);-) The guardianproject is working hard on providing support for Android and there are are a couple of other projects for encryption on mobiles. My fingers are to clumsy to even think about regularly sending or reading mails on a mobile phone (okay, a tablet might be more useful). >> possible to replace documents with phone call. Mail is not done for >> the communication but for documenting transactions. > > Where? AFAIK, in Germany, we still have to send faxes or registered > letters with reply advice because email is not approved. (Well, maybe Since about two years we are even able to send invoices by email without any signature (before that a qualified signature was required, but that never took up). For about everything you can do by plain letter you may also use email. In fact, if you have published an email address for your business you are required to read the email and archive them in the same way you do it with snails. > What do you mean by "online media"? Is de-mail such an "online medium"? Chat. In contrast to store and forward systems like email. No de-mail is a store and forward system. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kevhilton at gmail.com Tue Dec 10 05:43:28 2013 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 9 Dec 2013 22:43:28 -0600 Subject: Git clone index-pack failed Message-ID: Trying to clone gnupg repository on cygwin which I've done many times in the past, but this is what I'm getting: $ git clone git://git.gnupg.org/gnupg.git Cloning into 'gnupg'... fatal: index-pack failed I've even tried: $ git clone git://git.gnupg.org/gnupg.git --depth=1 Cloning into 'gnupg'... fatal: index-pack failed I'm not sure what I should be trying at this point. Frustrating. -------------- next part -------------- An HTML attachment was scrubbed... URL: From psusi at ubuntu.com Tue Dec 10 21:42:40 2013 From: psusi at ubuntu.com (Phillip Susi) Date: Tue, 10 Dec 2013 15:42:40 -0500 Subject: Importing new subkeys Message-ID: <52A77CC0.8040902@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So my old subkeys are about to expire so I created some new ones at home and exported them with --export-secret-subkeys. When I try to import them at work, gpg just says I already have that key and stops. Why isn't it merging the new subkeys? I ended up having to delete the master key from the keyring in order to import the new subkeys. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSp3zAAAoJEI5FoCIzSKrwa7oH/1ShDWfl3BngAx930jCGExaM nFCDRswSZ1M1ivSMdi3x8QF1pWmuxkjLAfxcItv+xfsmjPgO3ET5e1UZNCIN9M+5 OqBlv4DrqmtrnFxDhE9MmvupazW7Z/HGoK+hC6xter6Bbjyk110B0dfHgndhqR5L eT1yXfDTppH+uKdoEdny2hdg0bKe5Sz5r1eusdi/fp94ixFKYBuRCgSOFJHqpcjL 7pHL3QMysjD7JzJRqxo2gtpPMI7pWv4WAPBo4pOKyhlTL4vwhXaZr0ff1mQ0sk4p xZIhWY9jVcCKbzXiVwQbBV67ViWaY/yJozTNvywuYRe4Wr2KaL/UX5aAHmJnGIY= =+SEe -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Tue Dec 10 23:15:54 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 10 Dec 2013 23:15:54 +0100 Subject: Importing new subkeys In-Reply-To: <52A77CC0.8040902@ubuntu.com> References: <52A77CC0.8040902@ubuntu.com> Message-ID: <3977178.USHP51pp1x@inno.berlin.laging.de> Am Di 10.12.2013, 15:42:40 schrieb Phillip Susi: > So my old subkeys are about to expire so I created some new ones at > home and exported them with --export-secret-subkeys. When I try to > import them at work, gpg just says I already have that key and stops. > Why isn't it merging the new subkeys? I ended up having to delete > the master key from the keyring in order to import the new subkeys. There is a technical restriction which prevents merging secret keys or secret key components from different sources. This is not going to change before 2.1. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From dougb at dougbarton.us Wed Dec 11 00:27:06 2013 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 10 Dec 2013 15:27:06 -0800 Subject: Importing new subkeys In-Reply-To: <52A77CC0.8040902@ubuntu.com> References: <52A77CC0.8040902@ubuntu.com> Message-ID: <52A7A34A.6030509@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/10/2013 12:42 PM, Phillip Susi wrote: | So my old subkeys are about to expire so I created some new ones Why are you creating new ones instead of simply extending the expiry of the existing ones? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSp6NKAAoJEFzGhvEaGryEzzoH+wfHFc1h7C25blYXzdPzqexn qleQtCza9iycpbSbQSrDHGFSrGZwtZkSBGUXS0xtWUa1ffBZjSyu6qNF0o+cvgxc +j6N83Aq1I8Kh23CZ7uNz+fCqtzkei8qY6dkI8Jm4ePIOOMBQ2IxPcycPF7q3cNj uawvqfqesV5MBQKK4JANDt1pqLEo2igSLB4DNI3QbpG44JR39vUrYoM/rTuhSdCN GIutwCwpmi2TylFL2H+l3IXz+84crkL/HCe1dl986IDHhv3wGHuGgRyZfAjpE9qE 54ElNFsh7DPWBg47K8XZW2iRG/07al9H8UlOFdaY5x2a1V0X7YfWjZkMBomOBKk= =T2y8 -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Wed Dec 11 01:57:59 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Dec 2013 01:57:59 +0100 Subject: a maximally simplified GUI for OpenPGP (no code) Message-ID: <10125856.7jfF6JoXsq@inno.berlin.laging.de> Hello, some time ago I had a discussion about what a really simple crypto GUI should look like. This is the result: http://www.crypto-fuer-alle.de/wishlist/simple-crypto-gui/index.en.html It's just an HTML page which allows you to jump from screen to screen (for most suggested features) via internal links. Maybe this is interesting for someone. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From psusi at ubuntu.com Wed Dec 11 05:01:22 2013 From: psusi at ubuntu.com (Phillip Susi) Date: Tue, 10 Dec 2013 23:01:22 -0500 Subject: Importing new subkeys In-Reply-To: <52A7A34A.6030509@dougbarton.us> References: <52A77CC0.8040902@ubuntu.com> <52A7A34A.6030509@dougbarton.us> Message-ID: <52A7E392.7070700@ubuntu.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12/10/2013 06:27 PM, Doug Barton wrote: > On 12/10/2013 12:42 PM, Phillip Susi wrote: | So my old subkeys are > about to expire so I created some new ones > > Why are you creating new ones instead of simply extending the > expiry of the existing ones? Because I already extended them for a second year once, so I figured it's about time for a new one on the off chance that someone might be trying to crack them using the plethora of public email I have signed using them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSp+OPAAoJEI5FoCIzSKrw1F4H/1Va5Vlsge6YMTKNXXkX9Hs7 7VKAfaBePrTs/M7MlmN+dfRpUKYkKiUWxddBREDPPO/5lsSTy2g77uPmH/dIgcPf agE3tl2OAuNh+wurUl1IniJTNwoV0NM+q0QjfJ41FjpnTgsYiS6GE5FI1u0R8Nx2 2I1f6glIBZCoeWJ62nQz/MBCH9C0Scrh8xzYYpYzXBC855r1ehJXSU8x4TdB2gcj //lYRNLTncIhla0UNiMKsauQXeGWuW59zZmSnWuYT2jxEJJi9Ii7/HEKddS+/MtB r2q0If6yo2MTXIDp9fLwXsuTXCXfQgT9dl5CmTVzZK+Axqmvz0VusX/+uyXmcTo= =3mL/ -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Wed Dec 11 05:35:30 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Dec 2013 05:35:30 +0100 Subject: gpg-agent: pinentry-mode Message-ID: <106675827.IljrMTUNQZ@inno.berlin.laging.de> Hello, I have just been reading the man page of gpg-agent and found this: ######################################## --allow-loopback-pinentry Allow clients to use the loopback pinentry features; see the option pinentry- mode for details. ######################################## That made me curious so I wanted to do just that but: That is the only occurrence of "pinentry-mode" in the man page... Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Wed Dec 11 08:38:04 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Dec 2013 08:38:04 +0100 Subject: change passphrase in batch mode In-Reply-To: <87li4out8e.fsf@vigenere.g10code.de> References: <1917350.s8A95XkTby@inno.berlin.laging.de> <2948506.db0LsOqkDV@inno.berlin.laging.de> <87li4out8e.fsf@vigenere.g10code.de> Message-ID: <1475918.n97NhBl2zD@inno.berlin.laging.de> Am Di 30.07.2013, 14:28:49 schrieb Werner Koch: > Sure. Here is a very basic one: Took me some time to give that a try but... > echo "OK - what's up?" > while read cmd rest; do > echo "cmd=$cmd rest=$rest" >&2 > case "$cmd" in > \#*) > ;; > GETPIN) > echo "D ${PINENTRY_USER_DATA}" > echo "OK" > ;; > BYE) > echo "OK" > exit 0 > ;; > *) > echo "OK" > ;; > esac > done That works, thanks a lot. I added GETINFO) if [ "pid" = "$rest" ]; then echo "D $$" fi echo "OK" ;; > It simply echos the content of the envvar PINENTRY_USER_DATA which is > passed from gpg to via gpg-agent to the pinentry. This simple example works if just one passphrase is needed (e.g. signing). The problem is that pinentry is called three times when the passphrase is changed. I could put both the old and the new passphrase in PINENTRY_USER_DATA. Unfortunately it is not obvious for pinentry (or rather: me looking at the communication) which of the three calls is the current one. That may be detectable but seems too complicated. My solution is that I let the wrapper read the data from a FIFO. Before gpg --passwd is called the three passphrases are written to the FIFO. I wonder why none of these commands (GETPIN, GETINFO, not even BYE) are explained on http://www.gnupg.org/documentation/manuals/gnupg/Agent-Protocol.html Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Wed Dec 11 10:43:11 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 11 Dec 2013 10:43:11 +0100 Subject: change passphrase in batch mode In-Reply-To: <1475918.n97NhBl2zD@inno.berlin.laging.de> References: <1917350.s8A95XkTby@inno.berlin.laging.de> <2948506.db0LsOqkDV@inno.berlin.laging.de> <87li4out8e.fsf@vigenere.g10code.de> <1475918.n97NhBl2zD@inno.berlin.laging.de> Message-ID: <52A833AF.5080707@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/12/13 08:38, Hauke Laging wrote: > I wonder why none of these commands (GETPIN, GETINFO, not even BYE) are > explained on > http://www.gnupg.org/documentation/manuals/gnupg/Agent-Protocol.html I suppose because that is the agent protocol description, not the pinentry protocol description. They're both Assuan protocols, but they're different protocols. I can get a description of the pinentry protocol simply by: $ info pinentry HTH, Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Dec 11 10:51:16 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 11 Dec 2013 10:51:16 +0100 Subject: gpg-agent: pinentry-mode In-Reply-To: <106675827.IljrMTUNQZ@inno.berlin.laging.de> References: <106675827.IljrMTUNQZ@inno.berlin.laging.de> Message-ID: <52A83594.9080504@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/12/13 05:35, Hauke Laging wrote: > That made me curious so I wanted to do just that but: That is the only > occurrence of "pinentry-mode" in the man page... That one is elusive indeed! I found it in the gpg2 manpage rather than the gpg-agent man page (by simply grepping the source for GnuPG 2). HTH, Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Wed Dec 11 10:57:05 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Dec 2013 10:57:05 +0100 Subject: gpg-agent: pinentry-mode In-Reply-To: <106675827.IljrMTUNQZ@inno.berlin.laging.de> (Hauke Laging's message of "Wed, 11 Dec 2013 05:35:30 +0100") References: <106675827.IljrMTUNQZ@inno.berlin.laging.de> Message-ID: <87y53rsob2.fsf@vigenere.g10code.de> On Wed, 11 Dec 2013 05:35, mailinglisten at hauke-laging.de said: > That made me curious so I wanted to do just that but: That is the only > occurrence of "pinentry-mode" in the man page... Should have shown up in 2.0 - this is a 2.1 feature. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Wed Dec 11 23:30:39 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Dec 2013 23:30:39 +0100 Subject: gpg-agent: pinentry-mode In-Reply-To: <52A83594.9080504@digitalbrains.com> References: <106675827.IljrMTUNQZ@inno.berlin.laging.de> <52A83594.9080504@digitalbrains.com> Message-ID: <4420350.UqY9PHdDxq@inno.berlin.laging.de> Am Mi 11.12.2013, 10:51:16 schrieb Peter Lebbing: > On 11/12/13 05:35, Hauke Laging wrote: > > That made me curious so I wanted to do just that but: That is the only > > occurrence of "pinentry-mode" in the man page... > > That one is elusive indeed! I found it in the gpg2 manpage rather than the > gpg-agent man page (by simply grepping the source for GnuPG 2). That must be new. It's not in my gpg2 man page (2013-10-06; gpg-agent man page from the same day). Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Dec 12 14:08:13 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 12 Dec 2013 14:08:13 +0100 Subject: BitMail.sf.net v 0.6 - Secure Encrypting Email Client In-Reply-To: <1a9dac14d5d12e1373bcea91257c1c01.cm1@countermail.com> References: <1a9dac14d5d12e1373bcea91257c1c01.cm1@countermail.com> Message-ID: <201312121408.20343.bernhard@intevation.de> On Tuesday 05 November 2013 at 08:39:42, rwest at countermail.com wrote: > can BitMail.sf.net as a p2p email tool for encrypted Email (and hybrid with > IMAP-Email) be regarded as a reference model for research to create a > secure Email Client? as it uses both, gnupg and openssl! > > http://bitmail.sourceforge.net/ As bitmail.sf.net claims to be Free Software and using libgrypt, I wonder if anybody has looked at it, maybe its design from the GnuPG perspective. Maybe you know a good review comparing it to other p2p or secure textmessaging approaches? -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Dec 12 14:13:39 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 12 Dec 2013 14:13:39 +0100 Subject: Git clone index-pack failed In-Reply-To: References: Message-ID: <201312121413.41092.bernhard@intevation.de> On Tuesday 10 December 2013 at 05:43:28, Kevin Hilton wrote: > I'm not sure what I should be trying at this point. ?Frustrating. ... try again later. Check disc space. Check git version. Check if it works from the different machine/operating system/git repository. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Dec 12 14:24:18 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 12 Dec 2013 14:24:18 +0100 Subject: a maximally simplified GUI for OpenPGP (no code) In-Reply-To: <10125856.7jfF6JoXsq@inno.berlin.laging.de> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> Message-ID: <201312121424.23552.bernhard@intevation.de> Moin Hauke, On Wednesday 11 December 2013 at 01:57:59, Hauke Laging wrote: > some time ago I had a discussion about what a really simple crypto GUI > should look like. This is the result: > http://www.crypto-fuer-alle.de/wishlist/simple-crypto-gui/index.en.html thanks for caring and sharing. A few random thoughts: * I'm not quite sure what the aim of your gui is. To create a nice and usable gui (which then automatically means it has to be understandable and as simple as possible) we need to know what it should do. In my point of view most of the "crypto" problem should be done in the application that needs the crypto operations. So End-to-End Email -> Email application. File Encryption/Decryption -> File manager. Managing "contacts", your PIM or Email application. So what tasks are still left? * Gnupg can do CMS for S/MIME and OpenPGP for PGP/MIME, there have been long discussions over the Gpg4win compendium that led to the suggestion to call the "public key part" _certificate_. Thjs could improve your gui's wording. * The hard part, IMO is to build, maintain and somehow display the trust path and its level to the communication partners. Your draft does not address this part. E.g. your gui is used to find a certificate for "Hauke Laging", now you can import it, but how does the user know its you? Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Dec 12 14:36:58 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 12 Dec 2013 14:36:58 +0100 Subject: Promoting the usage of OpenPGP (was: Re: Renewing expiring key - done correctly?) In-Reply-To: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> References: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> Message-ID: <201312121437.03495.bernhard@intevation.de> Ingo, On Thursday 05 December 2013 at 21:38:50, Ingo Kl?cker wrote: > Therefore, I'm wondering whether it wouldn't be better if we, the > developers of Free Software mail clients, made the usage of OpenPGP (or > S/MIME) for email as transparent to the users as possible. Ideally, the > users wouldn't even have to notice that they are communicating via > encrypted email. you are probably aware of it, but just in case you aren't: STEED would help a lot to make start using encryption easier _and_ it is upwards compatible with end-to-end encryption in S/MIME and OpenPGP. http://g10code.com/steed.html Also note that at least for Kontact Mail, GnuPG, Gpg4win there is not enough effort to create a cool crypto solution. It would either mean significant funding or a bunch of very talented developers with free time on their hands. It probably falls back to funding, so: How can we make people fund crypto improvements and tool maintenance? Especially when it is Free Software? There are a number of ideas, but some of them require significant investments (e.g. approaching providers about STEED. Crowd Funding. App-Stores.) Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Dec 12 16:46:52 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Dec 2013 16:46:52 +0100 Subject: Git clone index-pack failed In-Reply-To: <201312121413.41092.bernhard@intevation.de> (Bernhard Reiter's message of "Thu, 12 Dec 2013 14:13:39 +0100") References: <201312121413.41092.bernhard@intevation.de> Message-ID: <87mwk6qdg3.fsf@vigenere.g10code.de> On Thu, 12 Dec 2013 14:13, bernhard at intevation.de said: > ... try again later. Check disc space. > Check git version. Check if it works from the different machine/operating > system/git repository. Actually this is a remote problem. git.gnupg.org had a storage failure and thus remounted itself read-only. It is currently been worked on. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 12 17:20:23 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Dec 2013 17:20:23 +0100 Subject: Git clone index-pack failed In-Reply-To: <87mwk6qdg3.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 12 Dec 2013 16:46:52 +0100") References: <201312121413.41092.bernhard@intevation.de> <87mwk6qdg3.fsf@vigenere.g10code.de> Message-ID: <8738lyqbw8.fsf@vigenere.g10code.de> On Thu, 12 Dec 2013 16:46, wk at gnupg.org said: > Actually this is a remote problem. git.gnupg.org had a storage failure > and thus remounted itself read-only. It is currently been worked on. git.gnupg.org is now back. Sorry for the problems. I realized them too late. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Thu Dec 12 18:33:29 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Dec 2013 18:33:29 +0100 Subject: a maximally simplified GUI for OpenPGP (no code) In-Reply-To: <201312121424.23552.bernhard@intevation.de> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> Message-ID: <2229901.gKbUVoJkIQ@inno.berlin.laging.de> Hello, Am Do 12.12.2013, 14:24:18 schrieb Bernhard Reiter: > * I'm not quite sure what the aim of your gui is. To create a nice and > usable gui (which then automatically means it has to be understandable and > as simple as possible) we need to know what it should do. may be. But I didn't know that (or that this knowlege is already available; and is it public so that people can assess and discuss it?) when this became a relevant question for me. I do not believe that "a nice and usable gui" has to be "as simple as possible" in any case. I am quite sure that this depends a lot on the targeted user category. What I did is targeted at people with absolutely no clue about the subject; people who are confused by the amount of options and operations of e.g. Enigmail or kleopatra. My approach was: "Show less, require more clicks (selection steps)" > In my point of > view most of the "crypto" problem should be done in the application that > needs the crypto operations. I do not think that this is a big difference. Furthermore: The GUI doesn't care whether it belongs to a limited (key management) application which is completely covered by it or whether it is part of a larger application and covers just a certain part of it. Does it? You could even use the same GUI twice (both for the key management application and as part of a bigger one). > Thjs could improve your gui's wording. Mine was intentional. Without having the benefit of your discussion I guess that "key" is good enough for the no clue target group. I wanted to avoid everything (as far as possible) that would probably confuse this kind of user. BTW: I went very slowly through the whole process (together with a friend who was not familiar with crypto at all): installing Gpg4win, installing Enigmail, configuring Enigmail. I am quite sure that I have reached a certain above- average level of OpenPGP understanding so it was kind of fun to notice that the normal key generation with Enigmail lead to a question / option which not even I understood... (but that's made by people who think it's clever not to show any certificates by default, WTF...) > * The hard part, IMO is to build, maintain and somehow display the trust > path and its level to the communication partners. Your draft does not > address this part. Really? Importing leads you directly here: http://www.crypto-fuer-alle.de/wishlist/simple-crypto-gui/index.en.html#certkeyinfo And: This is a two-level import (using an additional keyring) so that keys do not become available to applications before the user has 1) either stated that he has verified the key 2) or stated that he doesn't care And even in case (2) http://www.crypto-fuer-alle.de/wishlist/simple-crypto-gui/index.en.html#keygroups shows in a very simple way that the key has not been verified yet. Compare that to 1) gpg not showing the UID (or overall) key validity by default 2) Enigmail not even being capable of showing it 3) the nightmare GUI of kleopatra In all these applications import and certification are independent steps (i.e. certification has to be started separately). In my proposal they are linked together. CU Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Thu Dec 12 19:00:15 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Dec 2013 13:00:15 -0500 Subject: a maximally simplified GUI for OpenPGP (no code) In-Reply-To: <2229901.gKbUVoJkIQ@inno.berlin.laging.de> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> Message-ID: <52A9F9AF.1010200@fifthhorseman.net> On 12/12/2013 12:33 PM, Hauke Laging wrote: > 1) gpg not showing the UID (or overall) key validity by default What do people think about changing the default of show-uid-validity to yes? I would support this change; i think it would help users of gpg to better-understand their keyring. and users who really don't want to see it can always set it back to no in ~/.gnupg/gpg.conf --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Dec 12 20:37:28 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 12 Dec 2013 20:37:28 +0100 Subject: show-uid-validity default to yes (was Re: a maximally simplified GUI for OpenPGP (no code)) In-Reply-To: <52A9F9AF.1010200@fifthhorseman.net> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> <52A9F9AF.1010200@fifthhorseman.net> Message-ID: <52AA1078.8000501@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/12/13 19:00, Daniel Kahn Gillmor wrote: > What do people think about changing the default of show-uid-validity to > yes? I think it's a good idea. It's a vital piece of information if you actually want to use the key properly, IMHO. Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Thu Dec 12 20:45:44 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 12 Dec 2013 20:45:44 +0100 Subject: (OT) signature generation failed (was show-uid-validity default to yes) In-Reply-To: <52AA1078.8000501@digitalbrains.com> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> <52A9F9AF.1010200@fifthhorseman.net> <52AA1078.8000501@digitalbrains.com> Message-ID: <52AA1268.2010400@digitalbrains.com> On 12/12/13 20:37, Peter Lebbing wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 And that was all... I never intended to sign, but I have Enigmail's option "Encrypt/sign replies to encrypted/signed message" turned on because I don't want to forget encrypting when I reply to encrypted mail, which is especially important if you quote something. So Enigmail wanted to sign the message, but I don't have my card reader plugged in. Normally it complains, but this time it sent this message with just the header and no footer. It's less annoying than the time it ASCII-armoured an ASCII-armoured OpenPGP message in much the same way (the recipient thought his mail client wasn't decrypting, but it was actually only doing it once and showing the inner "layer"). I should probably file a feature request for two separate checkboxes: - "Sign replies to signed message" - "Encrypt replies to encrypted message" Anyway, now you know why you see the strange header/no-footer combo: it was a bug triggered by an unavailable smartcard reader (I think). Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mindiell at mindiell.net Fri Dec 13 12:12:12 2013 From: mindiell at mindiell.net (Mindiell) Date: Fri, 13 Dec 2013 12:12:12 +0100 (CET) Subject: Sharing/Storing a private key Message-ID: Hello, I'm using GPG regularly and did want to "save" my private key. On the IRC channel someone linked me to paperkey : http://www.jabberwocky.com/software/paperkey/ While this project is really interseting, it does not fit my needs. I found ssss (http://point-at-infinity.org/ssss/) too, but it wasn't really usable beacause it has too many limitations IMHO. So I did it myself : ShareIt (https://gitorious.org/shareit) It's a very simple program which take a file (whatever in it a GPG key or a pdf, etc...) and generates some fragments which can be given to some contacts in order to "store" the document while not making it readable directly. It is using the Shamir's Sharing Secret Algorithm (http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). I ever worked on a faster fragmentation this morning and will push it on the repo this evening (I can't from here). I planned a C version too, I hope to release quickly, but it is not really needed urgently because the Python version is fast enough to share a GnuPG key. Any Comments and/or critics are more than welcome, especially on security issues. Regards, Mindiell From ndk.clanbo at gmail.com Fri Dec 13 13:47:16 2013 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 13 Dec 2013 13:47:16 +0100 Subject: Android and E2E security Message-ID: <52AB01D4.9090009@gmail.com> Hi all. Seems someone is actively working on securing phones in an user-effortless way... http://www.techthefuture.com/technology/cyanogenmod-brings-system-wide-secure-messaging-to-android-phones I've only had a quick look at it and something yet doesn't "sound right", but might be just an impression... BYtE, Diego. From wk at gnupg.org Fri Dec 13 15:34:19 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Dec 2013 15:34:19 +0100 Subject: Another step towards crowdfunding Message-ID: <87mwk4q0pg.fsf@vigenere.g10code.de> Hi, you may want to check out http://blog.gnupg.org which has more infos on the upcoming campaign. Sorry, for all that Javascript stuff. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 13 15:37:59 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Dec 2013 15:37:59 +0100 Subject: show-uid-validity default to yes In-Reply-To: <52AA1078.8000501@digitalbrains.com> (Peter Lebbing's message of "Thu, 12 Dec 2013 20:37:28 +0100") References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> <52A9F9AF.1010200@fifthhorseman.net> <52AA1078.8000501@digitalbrains.com> Message-ID: <87iousq0jc.fsf@vigenere.g10code.de> On Thu, 12 Dec 2013 20:37, peter at digitalbrains.com said: > I think it's a good idea. It's a vital piece of information if you actually The majority of users are using a GUI and thus the command line version does not matter at all. Although people should know better, I am pretty sure that there are many scripts out which parse the human readable output. Such a change would break them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Fri Dec 13 17:04:42 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 13 Dec 2013 17:04:42 +0100 Subject: show-uid-validity default to yes In-Reply-To: <87iousq0jc.fsf@vigenere.g10code.de> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> <52A9F9AF.1010200@fifthhorseman.net> <52AA1078.8000501@digitalbrains.com> <87iousq0jc.fsf@vigenere.g10code.de> Message-ID: <52AB301A.4080502@digitalbrains.com> On 13/12/13 15:37, Werner Koch wrote: > The majority of users are using a GUI and thus the command line > version does not matter at all. I suppose when those people have questions they go the mailing list of the GUI in question, but still, since there is an amount of more-or-less newbies coming here on gnupg-users with questions who are using the command line, it would seem that there are inexperienced users who are using the command line. Has it ever been researched in which way users use GnuPG? A part of the GUI users might also still use the command line for certain things. > Although people should know better, I am pretty sure that there are > many scripts out which parse the human readable output. Such a > change would break them. Yes, but if you first say "Avoid using the output of this command in scripts or other programs as it is likely to change as GnuPG changes" and then still not make changes to the output because unthoughtful people depend on it being stable, it kind of defeats the purpose. It's something you should keep in mind, but it shouldn't stop you from implementing something which is a clear improvement. It is indeed debatable whether this particular improvement is worth it. Just some thoughts, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From christophe.brocas at cnamts.fr Fri Dec 13 17:05:00 2013 From: christophe.brocas at cnamts.fr (Christophe Brocas) Date: Fri, 13 Dec 2013 17:05:00 +0100 Subject: Another step towards crowdfunding In-Reply-To: <87mwk4q0pg.fsf@vigenere.g10code.de> References: <87mwk4q0pg.fsf@vigenere.g10code.de> Message-ID: <52AB302C.2030604@cnamts.fr> Le 13/12/2013 15:34, Werner Koch a ?crit : > Hi, > > you may want to check out > > http://blog.gnupg.org > > which has more infos on the upcoming campaign. Sorry, for all that > Javascript stuff. Hello Werner A lot of good news currently in the free software crypto area :) : * impressive roadmap news for the 3 new instances of Cryptostick (I cross my fingers to see IRL a cryptostick with OATH feature and removable smartcard) * an upcoming crowdfunding campaign * a very lean and clean GnuPG blog design :) and excellent promotional video ! One question : will STEED be in the scope of theupcoming crowdfunding campaign ? Cheers Christophe > Shalom-Salam, > > Werner ***************************************************** "Le contenu de ce courriel et ses eventuelles pi?ces jointes sont confidentiels. Ils s'adressent exclusivement ? la personne destinataire. Si cet envoi ne vous est pas destin?, ou si vous l'avez re?u par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre ? d'autres personnes ni le reproduire. Merci de le renvoyer ? l'?metteur et de le d?truire. Attention : L'Organisme de l'?metteur du message ne pourra ?tre tenu responsable de l'alt?ration du pr?sent courriel. Il appartient au destinataire de v?rifier que les messages et pi?ces jointes re?us ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses ?ventuelles pi?ces jointes sont celles de l'?metteur. Elles ne refl?tent pas la position de l'Organisme sauf s'il en est dispos? autrement dans le pr?sent courriel." ****************************************************** From wk at gnupg.org Fri Dec 13 19:57:40 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Dec 2013 19:57:40 +0100 Subject: Another step towards crowdfunding In-Reply-To: <52AB302C.2030604@cnamts.fr> (Christophe Brocas's message of "Fri, 13 Dec 2013 17:05:00 +0100") References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> Message-ID: <87ppp0o9y3.fsf@vigenere.g10code.de> On Fri, 13 Dec 2013 17:05, christophe.brocas at cnamts.fr said: > * a very lean and clean GnuPG blog design :) and excellent promotional video ! I was somehow able to convice Sam not to install Wordpress like blogging software right now. Which also means that for comments you need to resort to gnupg-users ;-). > One question : will STEED be in the scope of theupcoming crowdfunding > campaign No. A better communication platform will help us to gain more attention. If that works out, I hope to be able to help working on STEED without having to wonder how to feed my family the next month. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 13 20:09:35 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Dec 2013 20:09:35 +0100 Subject: show-uid-validity default to yes In-Reply-To: <52AB301A.4080502@digitalbrains.com> (Peter Lebbing's message of "Fri, 13 Dec 2013 17:04:42 +0100") References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> <52A9F9AF.1010200@fifthhorseman.net> <52AA1078.8000501@digitalbrains.com> <87iousq0jc.fsf@vigenere.g10code.de> <52AB301A.4080502@digitalbrains.com> Message-ID: <87lhzoo9e8.fsf@vigenere.g10code.de> On Fri, 13 Dec 2013 17:04, peter at digitalbrains.com said: > Has it ever been researched in which way users use GnuPG? A part of the > GUI users might also still use the command line for certain things. My guess is that the majority of GnuPG users are not aware that they are using GnuPG. They see Enigmail, or GpgOL, or Mac tools. I even heard rumors that most sysadmins these days are preferring web based administration tools; so if sysadmins are using GUIs why should users prefer the command line. I estimate that not more than 1% of all GnuPG users are using gpg in the shell. Right, the audience of this list is for the geeks - they know how to use mailing lists. Most users don't. > Yes, but if you first say "Avoid using the output of this command in > scripts or other programs as it is likely to change as GnuPG changes" > and then still not make changes to the output because unthoughtful I know. But part of the relative stability of the GPG interface is that even we deprecate stuff we keep supporting them for a long long time. I have suggested hundreds of times to better change a certain script to use --with-colons but I doubt that many followed that suggestion. After all it worked for them and why should the spend time changing a running system. > It is indeed debatable whether this particular improvement is worth it. Better add a hint to the FAQ. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Fri Dec 13 21:05:59 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 13 Dec 2013 21:05:59 +0100 Subject: show-uid-validity default to yes In-Reply-To: <87iousq0jc.fsf@vigenere.g10code.de> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <52AA1078.8000501@digitalbrains.com> <87iousq0jc.fsf@vigenere.g10code.de> Message-ID: <2248067.qONUW47MYh@inno.berlin.laging.de> Am Fr 13.12.2013, 15:37:59 schrieb Werner Koch: > The majority of users are using a GUI and thus the command line version > does not matter at all. Strange argument IMHO. Would you say the same about Linux? 99% of the desktop users don't know that there is a shell / console layer thus it's not important whether Linux has a good shell? I think in both cases the 1% are much more important than their tiny share implies because it is mostly the users who are very familiar with a software who care about spreading it. On the other hand we should support the development of pure users to users with relevant knowledge. This development is supported by a better console tool. Thus I believe that it does make sense to think about it how 1) gpg can be made easier to use 2) gpg can help the users understand the situation better. > Although people should know better, I am pretty > sure that there are many scripts out which parse the human readable > output. Such a change would break them. Maybe. But it is trivial to check whether gpg runs as part of a script, isn't it? It already does so today. I have forgotten where it is done but some output formatting is changed depending on whether the output is written to a tty or not. And if someone writes a script with such tricks that the script environment cannot easily be detected and then even complains about that then my reaction would probably be non-verbal. It might be easier to decide to have some changes if these are not planned for future versions of 1.4 or 2.0 but for 2.1 only. There have been output format changes from 1.4.x to 2.0.x, too. And to avoid a situation wich such arguing in the future (i.e. 2.1.x) it might be a good idea to "enforce" avoiding the use of non-script output for scripts by making small changes (irrelevant to the human reader) in the output format in every version. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Fri Dec 13 21:24:43 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Dec 2013 15:24:43 -0500 Subject: show-uid-validity default to yes In-Reply-To: <87lhzoo9e8.fsf@vigenere.g10code.de> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> <52A9F9AF.1010200@fifthhorseman.net> <52AA1078.8000501@digitalbrains.com> <87iousq0jc.fsf@vigenere.g10code.de> <52AB301A.4080502@digitalbrains.com> <87lhzoo9e8.fsf@vigenere.g10code.de> Message-ID: <52AB6D0B.8010506@fifthhorseman.net> On 12/13/2013 02:09 PM, Werner Koch wrote: > I estimate that not more than 1% of all GnuPG users are using gpg in the shell. this sounds like an argument for being willing to change the human-readable output on the shell -- there are not many people looking at it anyway, and most of those people are sophisticated user. > I know. But part of the relative stability of the GPG interface is that > even we deprecate stuff we keep supporting them for a long long time. I think for a piece of critical security infrastructure, GPG has been supporting some insecure practices for far too long. If we want to support insecure practices as a way to allow people to deal with outdated, insecure peers, or older, insecure stored data, we should be expecting those users with those needs to modify the configuration to make gpg more insecure specifically, rather than leaving all users insecure by default. > I > have suggested hundreds of times to better change a certain script to > use --with-colons but I doubt that many followed that suggestion. After > all it worked for them and why should the spend time changing a running > system. If you're referring to a specific script, please point me to it and its authors; i'll badger them as well; that's not a fun job, and there is no reason you should do it solo. If this is a general complaint (which i can easily imagine), then it presumably relates to people who *do* use gpg from the command line (they're actually scripting it!), and should know better. The way to get people to learn about it is to go ahead and improve the UI. There's no reason that developers who do not listen to clear, well-formed suggestions about what kind of commitments are made to an API should get to hold the rest of the userbase hostage. >> It is indeed debatable whether this particular improvement is worth it. > > Better add a hint to the FAQ. Most people do not read FAQs either. :( thanks as always for your work on GnuPG, and for the discussion. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Dec 13 22:27:15 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Dec 2013 22:27:15 +0100 Subject: show-uid-validity default to yes In-Reply-To: <52AB6D0B.8010506@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 13 Dec 2013 15:24:43 -0500") References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> <52A9F9AF.1010200@fifthhorseman.net> <52AA1078.8000501@digitalbrains.com> <87iousq0jc.fsf@vigenere.g10code.de> <52AB301A.4080502@digitalbrains.com> <87lhzoo9e8.fsf@vigenere.g10code.de> <52AB6D0B.8010506@fifthhorseman.net> Message-ID: <87ppp0mogc.fsf@vigenere.g10code.de> On Fri, 13 Dec 2013 21:24, dkg at fifthhorseman.net said: > this sounds like an argument for being willing to change the > human-readable output on the shell -- there are not many people looking > at it anyway, and most of those people are sophisticated user. It is a Unix tool and people want to have it as a Unix tools. The separation between a machine readable and the human interface is not a standard Unix tool property. Thus admins don't know about it. > I think for a piece of critical security infrastructure, GPG has been > supporting some insecure practices for far too long. Why do you think this is insecure? Because gpg does not encrypt to a key and users work around this by using --always-trust? > If you're referring to a specific script, please point me to it and its > authors; i'll badger them as well; that's not a fun job, and there is no > reason you should do it solo. I can't point you to such scripts. Most software is not in public use but used in-house. Sometimes I receive bug reports or requests for help and then I notice these problems. Not much we can do about. In fact, too many sites are using outdated versions because they fear things may break. Such breaks have been very rare with gpg and that is a good thing. > presumably relates to people who *do* use gpg from the command line > (they're actually scripting it!), and should know better. The way to They implemented something and then it is never touched again. > get people to learn about it is to go ahead and improve the UI. I am willing to consider a change for 2.1 - that will anyway break things (no more secring.gpg). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 13 22:30:34 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Dec 2013 22:30:34 +0100 Subject: show-uid-validity default to yes In-Reply-To: <2248067.qONUW47MYh@inno.berlin.laging.de> (Hauke Laging's message of "Fri, 13 Dec 2013 21:05:59 +0100") References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <52AA1078.8000501@digitalbrains.com> <87iousq0jc.fsf@vigenere.g10code.de> <2248067.qONUW47MYh@inno.berlin.laging.de> Message-ID: <87lhzomoat.fsf@vigenere.g10code.de> On Fri, 13 Dec 2013 21:05, mailinglisten at hauke-laging.de said: > Maybe. But it is trivial to check whether gpg runs as part of a script, isn't > it? It already does so today. I have forgotten where it is done but some Huh? It is impossible without using a lot of heuristics and knowledge of the environment. You mean the istty thing? Think about expect(1). > future versions of 1.4 or 2.0 but for 2.1 only. There have been output format > changes from 1.4.x to 2.0.x, too. Not that I can remember right now (unless you mean --fixed-list-mode). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From micah at micahflee.com Fri Dec 13 22:39:33 2013 From: micah at micahflee.com (Micah Lee) Date: Fri, 13 Dec 2013 13:39:33 -0800 Subject: Another step towards crowdfunding In-Reply-To: <87ppp0o9y3.fsf@vigenere.g10code.de> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> Message-ID: <52AB7E95.3010403@micahflee.com> Hi, I think this is my first post to this list, but I've been a lurker for a bit. This campaign looks pretty awesome. I tweeted the video and it's getting some pickup: https://twitter.com/micahflee/status/411569314097934336 I hope you don't mind a bit of feedback. On 12/13/2013 10:57 AM, Werner Koch wrote: > I was somehow able to convice Sam not to install Wordpress like blogging > software right now. Which also means that for comments you need to > resort to gnupg-users ;-). One way that I think the blog could be improved is by providing permalinks for the individual posts. I actually wanted to tweet the "Preparing for launch" post, but the only URL I could tweet is http://blog.gnupg.org/, so I decided to post the YouTube URL instead. Looking back through this list archives it appears that this fundraising campaign actually has a "matching grant", to use non-profit development language? Each donation is doubled? If so, that can be a major selling point for getting donations this "giving season". Each year for 3 years now EFF has had a wildly successful video game-themed "Power Up Your Donation" campaign that's based on matching grants, and it's currently going on for the next couple days: https://supporters.eff.org/donate/power-up-2013 In the video you say that GPG is used by the government, hackers, and billion dollar companies. I think when promoting GPG it's good to include in that list activists, journalists, whistleblowers, and ordinary people that care about privacy. I think you can brag about widespread use amongst this same set of people: https://www.torproject.org/about/torusers.html.en In fact, organizations like Tactical Technology Collective do GPG trainings for activists all the time, and Edward Snowden insisted on Glenn Greenwald using GPG before they wrote any emails of substance. The use of GPG amongst journalists has blown up in the last 6 months now that everyone knows they're being spied on. Finally, if you're raising money to rebuild the website, could you add HTTPS to your to do list? Using HTTPS, making HTTP redirect to HTTPS, using the HSTS header, using perfect forward secrecy ciphersuites, and all those other best practices? I'm well aware of the drawbacks of CAs and centralized trust, but I don't think that's a very good reason to not protect privacy of website visitors by default. -- Micah Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From micah at micahflee.com Fri Dec 13 22:23:06 2013 From: micah at micahflee.com (Micah Lee) Date: Fri, 13 Dec 2013 13:23:06 -0800 Subject: Another step towards crowdfunding In-Reply-To: <87ppp0o9y3.fsf@vigenere.g10code.de> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> Message-ID: <52AB7ABA.8030209@micahflee.com> Hi, I think this is my first post to this list, but I've been a lurker for a bit. This campaign looks pretty awesome. I tweeted the video and it's getting some pickup: https://twitter.com/micahflee/status/411569314097934336 I hope you don't mind a bit of feedback. On 12/13/2013 10:57 AM, Werner Koch wrote: > I was somehow able to convice Sam not to install Wordpress like blogging > software right now. Which also means that for comments you need to > resort to gnupg-users ;-). One way that I think the blog could be improved is by providing permalinks for the individual posts. I actually wanted to tweet the "Preparing for launch" post, but the only URL I could tweet is http://blog.gnupg.org/, so I decided to post the YouTube URL instead. Looking back through this list archives it appears that this fundraising campaign actually has a "matching grant", to use non-profit development language? Each donation is doubled? If so, that can be a major selling point for getting donations this "giving season". Each year for 3 years now EFF has had a wildly successful video game-themed "Power Up Your Donation" campaign that's based on matching grants, and it's currently going on for the next couple days: https://supporters.eff.org/donate/power-up-2013 In the video you say that GPG is used by the government, hackers, and billion dollar companies. I think when promoting GPG it's good to include in that list activists, journalists, whistleblowers, and ordinary people that care about privacy. I think you can brag about widespread use amongst this same set of people: https://www.torproject.org/about/torusers.html.en In fact, organizations like Tactical Technology Collective do GPG trainings for activists all the time, and Edward Snowden insisted on Glenn Greenwald using GPG before they wrote any emails of substance. The use of GPG amongst journalists has blown up in the last 6 months now that everyone knows they're being spied on. Finally, if you're raising money to rebuild the website, could you add HTTPS to your to do list? Using HTTPS, making HTTP redirect to HTTPS, using the HSTS header, using perfect forward secrecy ciphersuites, and all those other best practices? I'm well aware of the drawbacks of CAs and centralized trust, but I don't think that's a very good reason to not protect privacy of website visitors by default. -- Micah Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Dec 13 23:51:15 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Dec 2013 17:51:15 -0500 Subject: show-uid-validity default to yes In-Reply-To: <87ppp0mogc.fsf@vigenere.g10code.de> References: <10125856.7jfF6JoXsq@inno.berlin.laging.de> <201312121424.23552.bernhard@intevation.de> <2229901.gKbUVoJkIQ@inno.berlin.laging.de> <52A9F9AF.1010200@fifthhorseman.net> <52AA1078.8000501@digitalbrains.com> <87iousq0jc.fsf@vigenere.g10code.de> <52AB301A.4080502@digitalbrains.com> <87lhzoo9e8.fsf@vigenere.g10code.de> <52AB6D0B.8010506@fifthhorseman.net> <87ppp0mogc.fsf@vigenere.g10code.de> Message-ID: <52AB8F63.3020307@fifthhorseman.net> On 12/13/2013 04:27 PM, Werner Koch wrote: > On Fri, 13 Dec 2013 21:24, dkg at fifthhorseman.net said: >> I think for a piece of critical security infrastructure, GPG has been >> supporting some insecure practices for far too long. > > Why do you think this is insecure? Because gpg does not encrypt to a > key and users work around this by using --always-trust? yes, in this example, that's most likely the short path to an insecure configuration. I think most users don't really understand the default trust model, and that makes it more difficult for them to use the tool securely. Exposing the UID validity is a step toward making the trust model calculations more visible to users, which is necessary for understanding. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From adrelanos at riseup.net Fri Dec 13 23:56:07 2013 From: adrelanos at riseup.net (adrelanos) Date: Fri, 13 Dec 2013 22:56:07 +0000 Subject: Revocation certificate for sub key? Message-ID: <52AB9087.2060606@riseup.net> Hi, Is it possible to create a revocation certificate just for sub keys and not the master key? This would be useful for offline master keys. Trusted persons could be given the revocation certificate for sub keys and send it to key servers when they suspect compromise. But should the sub key revocation certificate get into the wrong hands due to compromise, the damage would be limited. Cheers, adrelanos From mailinglisten at hauke-laging.de Sat Dec 14 00:05:48 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 14 Dec 2013 00:05:48 +0100 Subject: Revocation certificate for sub key? In-Reply-To: <52AB9087.2060606@riseup.net> References: <52AB9087.2060606@riseup.net> Message-ID: <2539392.NlUImXUdSN@inno.berlin.laging.de> Am Fr 13.12.2013, 22:56:07 schrieb adrelanos: > Hi, > > Is it possible to create a revocation certificate just for sub keys and > not the master key? --edit-key 0x12345678 key 1 revkey Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From ndk.clanbo at gmail.com Sat Dec 14 10:24:02 2013 From: ndk.clanbo at gmail.com (NdK) Date: Sat, 14 Dec 2013 10:24:02 +0100 Subject: Revocation certificate for sub key? In-Reply-To: <52AB9087.2060606@riseup.net> References: <52AB9087.2060606@riseup.net> Message-ID: <52AC23B2.80006@gmail.com> Il 13/12/2013 23:56, adrelanos ha scritto: > Is it possible to create a revocation certificate just for sub keys and > not the master key? I can't see how it can be useful... > This would be useful for offline master keys. Trusted persons could be > given the revocation certificate for sub keys and send it to key servers > when they suspect compromise. But should the sub key revocation > certificate get into the wrong hands due to compromise, the damage would > be limited. Since you still have your secure offline main key, you can revoke subkeys yourself... Or am I missing something? BYtE, Diego. From adrelanos at riseup.net Sat Dec 14 18:01:23 2013 From: adrelanos at riseup.net (adrelanos) Date: Sat, 14 Dec 2013 17:01:23 +0000 Subject: Revocation certificate for sub key? Message-ID: <52AC8EE3.7040009@riseup.net> > Am Fr 13.12.2013, 22:56:07 schrieb adrelanos: >> Hi, >> >> Is it possible to create a revocation certificate just for sub keys and >> not the master key? > > --edit-key 0x12345678 > key 1 > revkey That's doesn't create a revocation certificate, that revokes the key. From adrelanos at riseup.net Sat Dec 14 18:01:28 2013 From: adrelanos at riseup.net (adrelanos) Date: Sat, 14 Dec 2013 17:01:28 +0000 Subject: Revocation certificate for sub key? Message-ID: <52AC8EE8.2080603@riseup.net> >> This would be useful for offline master keys. Trusted persons could be >> given the revocation certificate for sub keys and send it to key servers >> when they suspect compromise. But should the sub key revocation >> certificate get into the wrong hands due to compromise, the damage would >> be limited. > Since you still have your secure offline main key, you can revoke > subkeys yourself... Or am I missing something? Others may be able to do that faster. That time advantage might result in much less damage when it comes to important keys, such as linux distribution signing keys. From samtuke at gnupg.org Sat Dec 14 18:32:10 2013 From: samtuke at gnupg.org (Sam Tuke) Date: Sat, 14 Dec 2013 18:32:10 +0100 Subject: Another step towards crowdfunding In-Reply-To: <52AB7ABA.8030209@micahflee.com> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> Message-ID: <52AC961A.7040004@gnupg.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks for your carefully considered input Micah. On 13/12/13 22:23, Micah Lee wrote: > I tweeted the video and it's getting some pickup: > https://twitter.com/micahflee/status/411569314097934336 Awesome! > One way that I think the blog could be improved is by providing permalinks > for the individual posts. This has been on the todo list for a while (the blog is all static hand written HTML at the moment). I made separate pages as requested just now and they're online. Should make linking easier (just click on the article headings on the blog front page). > Looking back through this list archives it appears that this fundraising > campaign actually has a "matching grant", to use non-profit development > language? Each donation is doubled? No we don't have a sponsor offering that at the moment (I'd be delighted if we did). Which archived mail gave you that impression? > In the video you say that GPG is used by the government, hackers, and > billion dollar companies. I think when promoting GPG it's good to include > in that list activists, journalists, whistleblowers, and ordinary people > that care about privacy. I think you can brag about widespread use amongst > this same set of people: https://www.torproject.org/about/torusers.html.en Good point, I'll speak to Anna who made the video about getting it changed. > Finally, if you're raising money to rebuild the website, could you add > HTTPS to your to do list? I guess you're referring to the blog (gnupg.org is HTTPS accessible, but blog.gnupg.org is not)? The new site will host the blog on a single (not sub) domain, so all pages will be reachable by an encrypted connection. Does that answer your question? Best, Sam. - -- Sam Tuke Campaign Manager Gnu Privacy Guard Tel: +49 176 81923811 IM: samtuke at jabber.fsfe.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKslhkACgkQ1bR1Itj7YQUUsgD/QZREgToDdk13xSmKcMOyCEvl Ofd0bFpow40F32DA0p4BAJU7OfmVeb+HOQJWVWSA7sxxyD8nHApjt5a6attmKOMN =5v3W -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Sat Dec 14 19:28:25 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 14 Dec 2013 13:28:25 -0500 Subject: Revocation certificate for sub key? In-Reply-To: <52AC8EE3.7040009@riseup.net> References: <52AC8EE3.7040009@riseup.net> Message-ID: <52ACA349.3030208@fifthhorseman.net> On 12/14/2013 12:01 PM, adrelanos wrote: > [hauke wrote:] >> Am Fr 13.12.2013, 22:56:07 schrieb adrelanos: >>> Hi, >>> >>> Is it possible to create a revocation certificate just for sub keys and >>> not the master key? >> >> --edit-key 0x12345678 >> key 1 >> revkey > > That's doesn't create a revocation certificate, that revokes the key. If you are comfortable with either the GNUPGHOME environment variable or gpg's --homedir option, you should be able to make what you're looking for: Make a new temporary gnupg homedir. import your primary secret key and your subkey into that homedir. from that homedir, take Hauke's advice and then export the key to a text file someplace safe. this text file will contain the revocation for the subkey. delete/purge/get rid of the temporary homedir. if/when you need to revoke your subkey, you can just gpg --import the stored text file, and then --send-key to push it to the public keyservers. does this make sense? --dkg PS your e-mail client appears to be breaking message threading (no In-Reply-To: or References: headers), and fails to provide attribution for your quoted text (i had to re-insert that hauke was the source of the good advice above). This makes it more difficult for people to carry on a conversation with you over e-mail. Please consider fixing your client or choosing a different one that supports proper message threading and attribution. thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From ekleog at gmail.com Sat Dec 14 21:14:07 2013 From: ekleog at gmail.com (Leo Gaspard) Date: Sat, 14 Dec 2013 21:14:07 +0100 Subject: Sharing/Storing a private key In-Reply-To: References: Message-ID: <20131214201407.GA7669@leortable> On Fri, Dec 13, 2013 at 12:12:12PM +0100, Mindiell wrote: > Hello, > > I'm using GPG regularly and did want to "save" my private key. > > [...] > > I found ssss (http://point-at-infinity.org/ssss/) too, but it wasn't > really usable beacause it has too many limitations IMHO. > > So I did it myself : ShareIt (https://gitorious.org/shareit) > > [...] > > It is using the Shamir's Sharing Secret Algorithm > (http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). > > [...] > > Any Comments and/or critics are more than welcome, especially on security > issues. AFAIK, ssss *is* an implementation of SSS. So, why would you write a new version? I must say I didn't look at the source, as I do not see the point at first. So, this is a warning about security issues : something you made yourself is likely to be unsafe. A tested implementation exists. Maybe is there really a point in writing it, but I can't see which. Maybe if you explained what the limitations of ssss are...? HTH, Leo From cousinwednesday at mail.com Sat Dec 14 21:27:38 2013 From: cousinwednesday at mail.com (Zechariah Seth) Date: Sat, 14 Dec 2013 15:27:38 -0500 Subject: Another step towards crowdfunding Message-ID: <20131214202738.27030@gmx.com> > On Fri, 13 Dec 2013 17:05, christophe.brocas at cnamts.fr said: > > > * a very lean and clean GnuPG blog design :) and excellent promotional video ! > > I was somehow able to convice Sam not to install Wordpress like blogging > software right now. Which also means that for comments you need to > resort to gnupg-users ;-). Will GnuPG blogs be cross-posted to the gnupg-users list? :) From mailinglisten at hauke-laging.de Sun Dec 15 02:54:43 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 15 Dec 2013 02:54:43 +0100 Subject: Revocation certificate for sub key? In-Reply-To: <52AC8EE3.7040009@riseup.net> References: <52AC8EE3.7040009@riseup.net> Message-ID: <1930276.xNxz3O3LKH@inno.berlin.laging.de> Am Sa 14.12.2013, 17:01:23 schrieb adrelanos: > > Am Fr 13.12.2013, 22:56:07 schrieb adrelanos: > >> Hi, > >> > >> Is it possible to create a revocation certificate just for sub keys and > >> not the master key? > > > > --edit-key 0x12345678 > > key 1 > > revkey > > That's doesn't create a revocation certificate, that revokes the key. It does create a revocation certificate. But it imports it automatically. There is a simple solution, maybe (matter of taste) easier than dkg's proposal: Make a backup of the key (i.e. export both secret and public key), do the above, export the certificate (public key), delete both secret and public key and import your backup. The exported certificate contains the revocation certificate. You may reduce the file by deleting all but one UIDs and all other subkeys after the backup and before the revkey. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Sun Dec 15 12:47:37 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 15 Dec 2013 12:47:37 +0100 Subject: Sharing/Storing a private key In-Reply-To: <20131214201407.GA7669@leortable> (Leo Gaspard's message of "Sat, 14 Dec 2013 21:14:07 +0100") References: <20131214201407.GA7669@leortable> Message-ID: <87iouqjpye.fsf@vigenere.g10code.de> On Sat, 14 Dec 2013 21:14, ekleog at gmail.com said: > AFAIK, ssss *is* an implementation of SSS. So, why would you write a new > version? FWIW, a few years ago, Phil Sutter wrote a daemon for GnuPG which implements secret key splitting. I don't have the URL handy, but it should be easy to find. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Sun Dec 15 13:58:58 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 15 Dec 2013 13:58:58 +0100 Subject: Sharing/Storing a private key In-Reply-To: References: Message-ID: <52ADA792.2000800@digitalbrains.com> On 14/12/13 21:14, Leo Gaspard wrote: > Maybe if you explained what the limitations of ssss are...? My guess is the fact that ssss only supports secrets up to 1024 bits; if you want to share a larger secret you need to do a hybrid approach where you symmetrically encrypt the data and then use secret sharing for the randomly chosen encryption key. If I understand Mindiell's message right, his implementation works for larger secrets. But I don't see why you wouldn't just use ssss and the hybrid approach. For one, it uses much less entropy, since Shamir's secret sharing algorithm requires a lot of it, I believe proportional to the size of the data to be shared. I haven't checked the code by Mindiell, but this sounds like a potentially big issue. It seems to me the hybrid approach is better. Since ssss supports the hybrid approach, I don't see the need for a new tool. I do see use for a much simpler tool that makes the hybrid approach more accessible: pick a random key, and use that for invocations of both (openssl or gnupg) and ssss. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun Dec 15 14:18:59 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 15 Dec 2013 14:18:59 +0100 Subject: Another step towards crowdfunding In-Reply-To: <52AC961A.7040004@gnupg.org> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> Message-ID: <52ADAC43.3050303@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/12/13 18:32, Sam Tuke wrote: > No we don't have a sponsor offering that at the moment (I'd be delighted if > we did). Which archived mail gave you that impression? That would most likely be the offer Robert J. Hansen made this year for his yearly "Holiday giving" money to GnuPG in this message: http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048332.html I was going to do my yearly donation as well and let Robert match it, but I chose to wait for your crowdfunding campaign because I'm curious about the "rewards for those who donate" :). Sorry Robert :). Hey, I'm Dutch, we love free stuff! Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From mindiell at mindiell.net Sun Dec 15 13:35:04 2013 From: mindiell at mindiell.net (Mindiell) Date: Sun, 15 Dec 2013 13:35:04 +0100 Subject: Sharing/Storing a private key In-Reply-To: <20131214201407.GA7669@leortable> References: <20131214201407.GA7669@leortable> Message-ID: <52ADA1F8.2010009@mindiell.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > AFAIK, ssss *is* an implementation of SSS. So, why would you write > a new version? > > I must say I didn't look at the source, as I do not see the point > at first. > > So, this is a warning about security issues : something you made > yourself is likely to be unsafe. A tested implementation exists. > > Maybe is there really a point in writing it, but I can't see which. > Maybe if you explained what the limitations of ssss are...? > > HTH, > > Leo > Hello, The demo of ssss shows : - - a secret limited to 128 characters - - a generation of n fragments in once pass. You couldn't generate a new fragment later - - you have to copy paste each fragments after splitting, and right again on combination Plus, in the source code, you can see it is not using the modulo part, needing a specific lib (if I understood well). Finally, when I tried it on the demo page, if I enter less fragments than needed, it seems to raise an error which can help into discovering how much fragments are needed. In the end, it was a good exercise for me and I wanted to share it. And as a Python version it is runnable everywhere without compiling which seems to be a problem with the last version of ssss. regards, - -- Mindiell -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKtofQACgkQUrT9WwBwY7xd4wD9HCDe/Rb6uNZTvT+Jlm1SZLVU k2+hl/971LMU8EcBSzwA/RSJE+CV0+vdrwKWOZyK2XQp5du3lsH69SAic5RU9IRm =L9PN -----END PGP SIGNATURE----- From cloudpg at informationelle-selbstbestimmung-im-internet.de Sun Dec 15 15:33:25 2013 From: cloudpg at informationelle-selbstbestimmung-im-internet.de (Jens Lechtenboerger) Date: Sun, 15 Dec 2013 15:33:25 +0100 Subject: gpgsm and dirmngr Message-ID: <86y53mmbey.fsf@informationelle-selbstbestimmung-im-internet.de> Dear reader, I?m experimenting with gpgsm and dirmngr. Please redirect me to a more appropriate mailing list, if it exists. Does dirmngr only speak LDAPv2? If I configure a LDAPv3 server, it complains about the ?historical protocol? upon bind from dirmngr. This appears to indicate use of v2 by dirmngr. The README (2013-04-26) of dirmngr 1.1.0 states: ?Note that GnuPG includes an updated Dirmngr starting with GnuPG 2.1.? The latest version of GnuPG 2.1 seems to be gnupg-2.1.0beta3 dating back to 20-Dec-2011. What happened to the GnuPG 2.1 branch? What is the most recent version of dirmngr? Thanks Jens From rmayer at nerd-residenz.de Sun Dec 15 13:48:10 2013 From: rmayer at nerd-residenz.de (Ralph J. Mayer) Date: Sun, 15 Dec 2013 13:48:10 +0100 Subject: Promoting the usage of OpenPGP In-Reply-To: <87y53y2vla.fsf@vigenere.g10code.de> References: <3020876.GljJUAuhlm@thufir.ingo-kloecker.de> <87y53y2vla.fsf@vigenere.g10code.de> Message-ID: Hi, the one I am using right now, iOS Mail. -- Viele Gr??e / Kind Regards / Cordiali Saluti / Met vriendelijke groet Ralph J.Mayer > Am 06.12.2013 um 10:10 schrieb Werner Koch : > > Please name those email clients. From jhs at berklix.com Sun Dec 15 17:12:09 2013 From: jhs at berklix.com (Julian H. Stacey) Date: Sun, 15 Dec 2013 17:12:09 +0100 Subject: Promoting the usage of OpenPGP In-Reply-To: Your message "Sun, 15 Dec 2013 13:48:10 +0100." Message-ID: <201312151612.rBFGC9aI037010@fire.js.berklix.net> Hi, Reference: > From: "Ralph J. Mayer" > Date: Sun, 15 Dec 2013 13:48:10 +0100 "Ralph J. Mayer" wrote: > Hi, > > the one I am using right now, iOS Mail. > > -- > Viele Gr????e / Kind Regards / Cordiali Saluti / Met vriendelijke groet > > > Ralph J.Mayer > > > Am 06.12.2013 um 10:10 schrieb Werner Koch : > > > > Please name those email clients. Avoid top posting. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with "> ". Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. Mailbox overflow 2013_12_10_21:00 - 2013_12_11_11:00 GMT. No reply: Resend. From adrelanos at riseup.net Mon Dec 16 18:37:25 2013 From: adrelanos at riseup.net (adrelanos) Date: Mon, 16 Dec 2013 17:37:25 +0000 Subject: please give us safer defaults for gnupg Message-ID: <52AF3A55.7080800@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi! [This was originally planed as an open letter, but I thought it might be better to hear your arguments beforehand.] We think gnupg still is the most used and most important encryption tool in the Free Software community. [1] But there is a big problem with gnupg's default config values. As an analogy, it is a somewhat usable racing car but it unfortunately comes with a limiter and you need to find out how to get rid of the limiter first. As a result many users mess up and use only the limited secure version. gnupg comes with poor defaults and since it is of that much importance, that is a problem. We even have a recommended gpg.conf in torbird's git repo. [2] [3] The fact that we even need such a thing is bad. For example cert-digest-algo why is it in gpg still sha1 and not sha256 or sha512? Now that a few people know, that short key ids can be easily forged [4], why isn't the keyid-format set to 0xlong by default? Update: now that long key ids can also be forged [8], why not show the full fingerprint by default? And why does gpg still create 2048 bit keys, if creating 4096 keys just takes a few seconds longer and virtually make no difference when using these keys? For the sake of argument, let's take it for granted, that 2048 bit is still secure enough and can not be broken with brute force. That doesn't take into account, that we now know, thanks to Eduard Snowden, that the NSA infinitively stores encrypted data until they develop methods to decrypt it. [5] Other organizations probably do that as well in case someone wants to make an argument "you can trust the NSA". Also that doesn't take into account, that the NSA is building a giant new center in Utah spending billions just for decrypting such messages (also verifiable in mainstream press [6]). Let's imagine, someone finds a vulnerability in RSA being able to reduce the difficulty for brute force by 1024 bit. In that case, we're much better off with a 4096 bit default rather than with a 2048 bit default. Having the advantages of such a change at hand (many) and comparing them with the cons (almost none), we think it's irrational not to crank up the default value to 4096 bit. Maybe let's add another weak argument to the mix. Part of using encryption software is reducing anxiety. Even if using 4096 bit instead of 2048 bit does little more than reducing anxiety, we'd argue, that reducing anxiety is a one of the tasks of encryption software. It also lets us focus on discussing more important things than this dull 2048 vs 4096 bit discussion. Those teaching others how to use gpg [at crypto parties etc.], won't have to understand why 2048 bit is the default, why some recommend to use 4096 bit or keep defending 2048 bit etc. Well, perhaps we understand little about interoperability and ignored that argument against cranking up the defaults. This is what we think about that... We do not care about closed source PGP compatible software, namely, well... Good question, it's difficult finding alternative OpenPGP compatible software at all. Probably there is only one product not based on gnupg, namely "Symantec Encryption Desktop". As long it was still called PGP Corp. and Philip Zimmermann was in charge, there was probably no backdoor. Now, that Symantec is in charge, a US company, and looking at the recent news... Quote guardian: "Through these covert partnerships, the agencies have inserted secret vulnerabilities ? known as backdoors or trapdoors ? into commercial encryption software" [7]. We don't see why, the Free Software community, should care about Symantec's OpenPGP. We are suggesting to just crank up the defaults - now. Maybe gpg should add a --compatible switch, where it uses weak default to be as inter-operable as possible. Oh, gpg already has switches such as --pgp6. Even better. We're all for Free Software / Open Source. Writing specification is even better. However, the specification process should be a bonus and not needlessly block improvements in security for years while we urgently need it. Alternative implementations (probably only Symantec) should be free to cope up. They can be even given a notification and few months to update their clients to the latest developments. But the pure existence of those shouldn't prevent us for years from getting secure defaults with no hope of improvement in sight. An argument against interoperability is, that using cranked up defaults creates few support requests. TorBirdy, Tails and Whonix are cranking up the gpg defaults. How many support requests of the type "recipient can't decrypt/verify my messages, because using an alternative OpenPGP implementation" do we have? Can't remember having this seen anywhere ever. We, the singers of this letter, are not all necessarily experts in cryptography or as knowledgeable about gnupg as the authors are. We give you the benefit of the doubt. It could very well be the case, that our hypotheses are totally wrong and that in fact defaults such as SHA1 and 2048 bit are totally fine for now and for ever. If that is case and/or if the interoperability argument is your standpoint, please remind the emotional argument of reducing anxiety. In that case, also consider cranking up the defaults just because security isn't worsened but due to popular request should enough people sign this letter. Rather please consider cranking up the defaults just for the sake of allowing (eventually in your view) paranoid and/or wrong people to reduce complexity of instructions. [7] That alone would probably help with a greater adaptation of gnupg. There would also be less room for conspiracy theories, why gpg is still using SHA1 and 2048 bit by default. We, the singers of this letter, are very thankful for everyone having contributed to gnupg and greatly respect them. Please take our positive criticism and crank up gpg's defaults, so people can make their instructions simpler (example [7]). The more there is to explain [7], the more difficult it becomes, and the more likely it becomes to mess up. All the best, adrelanos [1] That is hopefully beyond questioning. For example gnupg is used by major Linux distributions for package download verification, for the trust chain between developers and used by man Free Software developers to sign their releases. [2] https://github.com/ioerror/torbirdy/blob/master/gpg.conf [3] https://github.com/ioerror/torbirdy/pull/11 [4] http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html [5] Quote EFF "[...] More appallingly, the NSA is allowed to hold onto communications solely because you use encryption. Whether the communication is domestic or foreign, the NSA will hang on to the encrypted message forever, or at least until it is decrypted. And then at least five more years. [...]" from https://www.eff.org/deeplinks/2013/06/depth-review-new-nsa-documents-expose-how-americans-can-be-spied-without-warrant [6] https://en.wikipedia.org/wiki/Utah_Data_Center [7] Would be great if instrutions such as https://wiki.ubuntu.com/SecurityTeam/GPGMigration wouldn't require lines along "[...] Set defaults in ~/.gnupg/gpg.conf [...] cert-digest-algo SHA512 [...] default-preference-list SHA512 [...]". [8] http://debian-administration.org/users/dkg/weblog/105 -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJSrzpRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5 QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7v68MP/0pAsOVXHooY2TWjoeshYtyN nf2HUC2znVhj7d+o7jpatP9OdXU2IwgY9ODtbpnvDYE0b/IzEP9N33kgAjS7951b LO6KqXHP1RVbv953U84Ymuk+SM11QqNuov5rjdhmlj6vSAbOIbbajW4LYjsKnGQ5 SOp6aEsOWjgLwgtXV4JRWT1wuuPVz9NUSLWAkWmIMXWeTxuubJ+cXS1OJT7jZsz8 OazhLItAi+ENLOuS/KIw9NpcCtpZ/RZLQ4tkPpjuu97LdbddYv52EtY1k+Bz1bx+ fdBEkZzAfGuaJEtHwyl0pkJ69IDvLF1hMxH4zuOZwgXwFW8vdVR9YmHYZbG1wAGV aTKbrtDzgBCKeLiE2d3woknZ2umq4pVd+SnGFjtfu6ou987bgWqCj8q5Q8tP1s8D teCqXf3qHTEfsLT4khLfMMbv9enmA9W8iHEpFlUCJqvpnZuq5B2GgV7/IAH4Uski Fh/G2GnpcikJdR4OMWT1R+zHA31mQnUIBVdSieUbR17B0TjdtDSmi01MPhP6rl1F mVns4Gkko39+5eee1q7t7NgnaUIyotpeDkjzCCcRCKgNCcARUBwtZNuT7ekKpLfU YvT6Y9sYiLDRalobu4+VZPqdclSlZESsoMmKuUlHEPfz8pjZ1EvZJvE61UWb7Pld vdv4ioSzv+7VfEBeQIGL =gxuA -----END PGP SIGNATURE----- From wk at gnupg.org Mon Dec 16 18:49:01 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Dec 2013 18:49:01 +0100 Subject: [Announce] Libgcrypt 1.6.0 released Message-ID: <87haa8fzzm.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.0. This is the new stable version of Libgcrypt with the API being mostly compatible to previous versions. Due to the removal of certain long deprecated functions this version introduces an ABI change. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. The main features of this version are performance improvements [3], better support for elliptic curves, new algorithms and modes, as well as API and internal cleanups. Better performance of public key algorithms, in particular for Curve25519, is planned for forthcoming releases. Note that the 1.5 series will enter end of life state on 2016-12-31. Noteworthy changes between version 1.5.0 and 1.6.0: =================================================== * Removed the long deprecated gcry_ac interface. Thus Libgcrypt is not anymore ABI compatible to previous versions if they used the ac interface. * Removed the module register subsystem. * The deprecated message digest debug macros have been removed. Use gcry_md_debug instead. * Removed deprecated control codes. * Improved performance of most cipher algorithms as well as for the SHA family of hash functions. * Added support for the IDEA cipher algorithm. * Added support for the Salsa20 and reduced Salsa20/12 stream ciphers. * Added limited support for the GOST 28147-89 cipher algorithm. * Added support for the GOST R 34.11-94 and R 34.11-2012 (Stribog) hash algorithms. * Added a random number generator to directly use the system's RNG. Also added an interface to prefer the use of a specified RNG. * Added support for the SCRYPT algorithm. * Mitigated the Yarom/Falkner flush+reload side-channel attack on RSA secret keys. See [CVE-2013-4242]. * Added support for Deterministic DSA as per RFC-6969. * Added support for curve Ed25519. * Added a scatter gather hash convenience function. * Added several MPI amd SEXP helper functions. * Added support for negative numbers to gcry_mpi_print, gcry_mpi_aprint and gcry_mpi_scan. * The algorithm ids GCRY_PK_ECDSA and GCRY_PK_ECDH are now deprecated. Use GCRY_PK_ECC if you need an algorithm id. * Changed gcry_pk_genkey for "ecc" to only include the curve name and not the parameters. The flag "param" may be used to revert this. * Added a feature to globally disable selected hardware features. * Added debug helper functions. For Interface changes relative to the 1.5.0 release see below [4]. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.bz2 (2441k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.gz (2866k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.gz.sig Due to the amount of changes we don't provide a patch file against 1.5.x. The SHA-1 checksums are: 43283c0b41c41e3d3bc13c2d8f937dfe2aaa1a77 libgcrypt-1.6.0.tar.bz2 03551121fe5b706532158667699f63b6e2606755 libgcrypt-1.6.0.tar.gz Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Special thanks to Jussi Kivilinna who did most of the performance improvement work. Happy hacking, Werner [1] http://www.gnupg.org/documentation/mailing-lists.html [2] http://www.gnupg.org/service.html [3] http://blog.gnupg.org/20131215-gcrypt-bench.html [4] Interface changes relative to the 1.5.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gcry_ac_* REMOVED. GCRY_AC_* REMOVED. gcry_module_t REMOVED. gcry_cipher_register REMOVED. gcry_cipher_unregister REMOVED. gcry_cipher_list REMOVED. gcry_pk_register REMOVED. gcry_pk_unregister REMOVED. gcry_pk_list REMOVED. gcry_md_register REMOVED. gcry_md_unregister REMOVED. gcry_md_list REMOVED. gcry_md_start_debug REMOVED (macro). gcry_md_stop_debug REMOVED (macro). GCRYCTL_SET_KEY REMOVED. GCRYCTL_SET_IV REMOVED. GCRYCTL_SET_CTR REMOVED. GCRYCTL_DISABLE_ALGO CHANGED: Not anymore thread-safe. gcry_pk_genkey CHANGED: ECC curve params not returned. gcry_md_hash_buffers NEW. gcry_buffer_t NEW. GCRYCTL_SET_ENFORCED_FIPS_FLAG NEW. GCRYCTL_SET_PREFERRED_RNG_TYPE NEW. GCRYCTL_GET_CURRENT_RNG_TYPE NEW. GCRYCTL_CLOSE_RANDOM_DEVICE NEW. GCRY_RNG_TYPE_STANDARD NEW. GCRY_RNG_TYPE_FIPS NEW. GCRY_RNG_TYPE_SYSTEM NEW. gcry_mpi_is_neg NEW. gcry_mpi_neg NEW. gcry_mpi_abs NEW. gcry_mpi_snatch NEW. gcry_mpi_set_opaque_copy NEW. gcry_mpi_point_t NEW. gcry_mpi_point_new NEW. gcry_mpi_point_release NEW. gcry_mpi_point_get NEW. gcry_mpi_point_snatch_get NEW. gcry_mpi_point_set NEW. gcry_mpi_point_snatch_set NEW. gcry_ctx_t NEW. gcry_ctx_release NEW. gcry_mpi_ec_new NEW. gcry_mpi_ec_get_mpi NEW. gcry_mpi_ec_get_point NEW. gcry_mpi_ec_set_mpi NEW. gcry_mpi_ec_set_point NEW. gcry_mpi_ec_get_affine NEW. gcry_mpi_ec_dup NEW. gcry_mpi_ec_add NEW. gcry_mpi_ec_mul NEW. gcry_mpi_ec_curve_point NEW. GCRYMPI_FLAG_IMMUTABLE NEW. GCRYMPI_FLAG_CONST NEW. GCRYMPI_FLAG_USER1 NEW. GCRYMPI_FLAG_USER2 NEW. GCRYMPI_FLAG_USER3 NEW. GCRYMPI_FLAG_USER4 NEW. GCRYMPI_CONST_ONE NEW. GCRYMPI_CONST_TWO NEW. GCRYMPI_CONST_THREE NEW. GCRYMPI_CONST_FOUR NEW. GCRYMPI_CONST_EIGHT NEW. GCRYMPI_FMT_OPAQUE NEW. GCRYPT_VERSION_NUMBER NEW. GCRY_KDF_SCRYPT NEW. gcry_pubkey_get_sexp NEW. GCRYCTL_DISABLE_LOCKED_SECMEM NEW. GCRYCTL_DISABLE_PRIV_DROP NEW. GCRY_CIPHER_SALSA20 NEW. gcry_sexp_nth_buffer NEW. gcry_sexp_extract_param NEW. GCRY_CIPHER_SALSA20R12 NEW. GCRY_CIPHER_GOST28147 NEW. GCRY_MD_GOSTR3411_94 NEW. GCRY_MD_STRIBOG256 NEW. GCRY_MD_STRIBOG512 NEW. GCRY_PK_ECC NEW. gcry_log_debug NEW. gcry_log_debughex NEW. gcry_log_debugmpi NEW. gcry_log_debugpnt NEW. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From micah at micahflee.com Mon Dec 16 20:32:45 2013 From: micah at micahflee.com (Micah Lee) Date: Mon, 16 Dec 2013 11:32:45 -0800 Subject: Another step towards crowdfunding In-Reply-To: <52AC961A.7040004@gnupg.org> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> Message-ID: <52AF555D.30103@micahflee.com> On 12/14/2013 09:32 AM, Sam Tuke wrote: > This has been on the todo list for a while (the blog is all static hand > written HTML at the moment). I made separate pages as requested just now and > they're online. Should make linking easier (just click on the article headings > on the blog front page). Awesome. > No we don't have a sponsor offering that at the moment (I'd be delighted if we > did). Which archived mail gave you that impression? Yeah, I was talking about: http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048332.html > I guess you're referring to the blog (gnupg.org is HTTPS accessible, but > blog.gnupg.org is not)? The new site will host the blog on a single (not sub) > domain, so all pages will be reachable by an encrypted connection. Does that > answer your question? Ahh, it's good to know that gnupg.org is available for https. But I would guess a very small percentage of your visitors use it, or even know that it's available. If you want to fix this, you could make all incoming http traffic respond with a 301 redirect to https. Looking at my browser, for some reason gnupg.org has set two cookies, one of which is a uuid that anyone monitoring me can use to track me, even if I switch internet connections or start using a VPN. Because of this (and because it's good practice and doesn't hurt) you could also set the HSTS header, which prevents browser from accidentally (or being tricked into) loading the website over http: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security Also, looks like the CA is CAcert--an awesome CA, but not trusted by browsers by default. I'd suggest getting a cert from StartSSL [https://startssl.com/], since they're they only CA that gives certs for free. And a wildcard cert (for *.gnupg.org) ends up costing like $60 USD. Also, it would be great if the use of https could be done better. The Qualys SSL report gives https://gnupg.org/ an F (because of the CAcert issue), but even if you used a browser-trusted CA it still wouldn't be the best: https://www.ssllabs.com/ssltest/analyze.html?d=gnupg.org I notice you're using Boa Webserver, and their docs don't seem to show how to do things like set custom http headers or mess with the ciphersuites in use. But for other servers (apache, nginx, lighttpd) you can find security-hardened config examples here: https://github.com/ioerror/duraconf -- Micah Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Mon Dec 16 20:38:26 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 16 Dec 2013 20:38:26 +0100 Subject: [Announce] Libgcrypt 1.6.0 released In-Reply-To: <87haa8fzzm.fsf@vigenere.g10code.de> References: <87haa8fzzm.fsf@vigenere.g10code.de> Message-ID: <52AF56B2.3040104@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/12/13 18:49, Werner Koch wrote: > * Added support for Deterministic DSA as per RFC-6969. I think this is a typo and you mean RFC-6979 "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)" Thanks for keeping on releasing new stuff, Peter. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From wk at gnupg.org Mon Dec 16 20:42:54 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Dec 2013 20:42:54 +0100 Subject: please give us safer defaults for gnupg In-Reply-To: <52AF3A55.7080800@riseup.net> (adrelanos@riseup.net's message of "Mon, 16 Dec 2013 17:37:25 +0000") References: <52AF3A55.7080800@riseup.net> Message-ID: <87y53keg5d.fsf@vigenere.g10code.de> On Mon, 16 Dec 2013 18:37, adrelanos at riseup.net said: > [This was originally planed as an open letter, but I thought it might > be better to hear your arguments beforehand.] May I suggest to read the archives of just a few weeks to collect the reasons why suggestions of using SHA-512 are missing the point. Some folks here must have bleeding fingertips from repeating the arguments over and over. Having said this, I like to appreciate that you have such a trust in us GnuPG hackers in that our coding practice and development environment is bug free at a level that only cracking algorithms is the danger to your data. I think Adi Shamir was it who said: "Nobody breaks crypto algorithms; they work around the crypto". Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Mon Dec 16 20:57:52 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 16 Dec 2013 11:57:52 -0800 Subject: please give us safer defaults for gnupg In-Reply-To: <52AF3A55.7080800@riseup.net> References: <52AF3A55.7080800@riseup.net> Message-ID: <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4@mail.sixdemonbag.org> > We think... If you're writing on behalf of a group, I would love to know the name of the group and the names of its members. Otherwise, I can only assume you are suffering a mental illness and are speaking for the multiple voices in your head -- either that or else perhaps you're fighting off a parasitic infestation and are speaking on behalf of your guests. :) > gnupg still is the most used and most important encryption tool > in the Free Software community. [1] It is definitely not the most-used, and it is likely not the most-important. OpenSSL is free software, and is used orders of magnitude more often than GnuPG. I routinely go days without using GnuPG, but I rarely go even a few hours without accessing an OpenSSL-secured webpage. GnuPG is great, don't get me wrong -- but let's keep the hype in perspective. :) > it is a somewhat usable > racing car but it unfortunately comes with a limiter and you need to > find out how to get rid of the limiter first. Although you chose this metaphor, I'm not sure that it's a metaphor you really want to use. I am an amateur racer. (My suicide ride of choice is my Mustang GT.) This is exactly the behavior I want in a race car and exactly what I *don't* want a novice driver to do. A novice driver should be put behind the wheel of a limited vehicle, and those limitations should not be removed until such time as the driver demonstrates his or her skill behind the wheel. I will not share a track with you at 225kph without first seeing you demonstrate your skills at 150kph. The idea of giving a powerful and non-limited tool to a new user is sort of like putting a new driver behind the wheel of a Jaguar XJ220. Within an hour you'll have a dead driver and a smoking wreck that used to be worth half a million quid. What you call "limits" are, in reality, carefully chosen behaviors meant to keep new users safe from their own mistakes. I do not believe it is wise or ethical to tell new users they need to erase their margin for error. > gnupg comes with poor defaults... If GnuPG's defaults lead it to being subverted, then I agree it is a serious problem that will need remedy. However, as near as I can tell that is not the situation. > We even have a recommended gpg.conf in torbird's git repo. [2] [3] The > fact that we even need such a thing is bad. For as long as GnuPG has existed people have been saying "use this gpg.conf file that I wrote in order to get the most security." Very often these 'recommended' gpg.conf files are in conflict with someone else's 'recommended' gpg.conf file. > For example cert-digest-algo why is it in gpg still sha1 and not sha256 > or sha512? Interoperability. SHA-1's long-term prospects are not particularly good, but for now it is the only MUST digest algorithm in RFC4880. The people developing RFC4880 are well aware of this problem and the choice of digest algorithms will be addressed in the next revision of the standard. Until that new revision is published, GnuPG is choosing to maximize interoperability. > Now that a few people know, that short key ids can be easily > forged [4], why isn't the keyid-format set to 0xlong by default? Convenience. You should always use a long key ID to retrieve a key, but there's nothing wrong with using a short ID to refer to an already-validated key. The main risk of short ID collisions comes from people pulling the wrong certificate off the keyservers and mistakenly using that one; but when it comes to using keys you have already downloaded and validated the risk is minimal. > Update: now that long key ids can also be forged [8], why not show the > full fingerprint by default? Convenience. See above. > And why does gpg still create 2048 bit keys, if creating 4096 keys > just takes a few seconds longer and virtually make no difference > when using > these keys? NIST's recommendation is that a 2048-bit key will be sufficient for the next 30 years. ENISA concurs in this judgment (although they recommend 3072-bit keys for reasons that are not particularly relevant here). RSA Data Security also concurs. Given the vast majority of cryptologic think-tanks in the world believe 2048-bit RSA will be secure for the next 30 years, GnuPG has taken the reasonable position of defaulting to 2048-bit RSA. With respect to "if creating 4096-bit keys just takes a few seconds longer and virtually make no difference when using these keys," as several people here have attested to in the past it makes a big difference for many users. Mobile devices... embedded systems... sites that do bulk encryption... mailing lists... the list goes on. > For the sake of argument, let's take it for granted, that 2048 bit is > still secure enough and can not be broken with brute force. It is not necessary to take it for the sake of argument. Compelling thermodynamic arguments exist that say we will not break 2048-bit RSA until we've had truly science-fiction level breakthroughs in computing technology. > Let's imagine, someone finds a > vulnerability in RSA being able to reduce the difficulty for brute force > by 1024 bit. This would be a science-fiction level breakthrough in mathematics. If we can imagine a 1024-bit breakthrough, why not a 2048-bit, or a 3072-bit, or a 4096-bit, or a 16384-bit? The problem with assuming the existence of science-fiction level attacks is that once you start there's no reason to stop. > Maybe let's add another weak argument to the mix. Part of using > encryption software is reducing anxiety. Even if using 4096 bit instead > of 2048 bit does little more than reducing anxiety, we'd argue, that > reducing anxiety is a one of the tasks of encryption software. I'm reminded of a _Simpsons_ episode where Lisa gives Homer a tiger-proof rock. She points out to him that he's not being attacked by tigers, therefore the tiger-proof rock works. Homer, being foolish, believes Lisa and asks to buy the rock from her. I do not believe it is ethical for us to be in the business of giving people tiger-proof rocks. Even if it "reduces anxiety," as you put it, it's unethical. > We do not care about closed source PGP compatible software, namely, > well... Good question, it's difficult finding alternative > OpenPGP compatible software at all. McAfee has an offering, so does Symantec. I know that at least one major telecommunications firm is using the most brain-damaged and minimalistic RFC2440 implementation on the planet. There's BouncyCastle, there's Peter Gutmann's cryptlib, there's... > Can't remember having this seen anywhere ever. I'm part of the Enigmail team, and I field a fair number of help requests from users who are having trouble. I'm not sure this is the most common help request I see, but it's close: "I used this gpg.conf a friend of mine told me would give me the most security..." Almost always, it uses cert-digest-algo, digest-algo or cipher-algo in a way that is seriously affecting interoperability. From dkg at fifthhorseman.net Mon Dec 16 21:35:53 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Dec 2013 15:35:53 -0500 Subject: X.509 certificates for https://gnupg.org [was: Re: Another step towards crowdfunding] In-Reply-To: <52AF555D.30103@micahflee.com> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> Message-ID: <52AF6429.90201@fifthhorseman.net> On 12/16/2013 02:32 PM, Micah Lee wrote: > Also, looks like the CA is CAcert--an awesome CA, but not trusted by > browsers by default. I'd suggest getting a cert from StartSSL > [https://startssl.com/], since they're they only CA that gives certs for > free. And a wildcard cert (for *.gnupg.org) ends up costing like $60 USD. Regardless of how you feel about the CA cartel in general, StartSSL is not the only member of the cartel offering gratis certs, particularly for well-known free software projects (Also, as a business in Israel, StartSSL is the target of an ongoing international boycott due to Israeli domestic policy -- http://www.bdsmovement.net/). Other members of the CA cartel that offer gratis certificates (particularly for free software projects) include: https://www.globalsign.com/ssl/ssl-open-source/ https://www.godaddy.com/ssl/ssl-open-source.aspx https://www.instantssl.com/ssl-certificate-products/free-ssl-certificate.html A not-insignificant cost for all of this stuff (regardless of whether the cert itself is gratis or not) is understanding and compliance with the terms of service of the particular CA, keeping the certificate up-to-date, and figuring out which silly rules each CA happens to impose (for example, some CAs appear to only issue certs over the end-entity's RSA key if it has 2048-bits or 4096-bits, but they will not accept any keylength in between; other CAs require certain fields to be present in the CSR that are meaningless, but must be filled in with "NA" (meaning, presumably, 'not applicable'), and so on). Some gratis certificates become non-gratis after the first year, and some CAs change their policies from year to year as well. Some of these issues may be less bad when dealing with CACert. I'd argue that none of these cartel members are actually any more reliable than CACert, but it may still be useful to get a certification from a cartel member just because of the existing lock-in situation. In the meantime, other mechanisms (like DANE or monkeysphere) can provide parallel certification paths for people who do not want to rely on the cartel. I'm happy to see more advocacy for stronger crypto by default for as many public-facing services as possible. But i don't think we should be advocating for use of a single vendor, particularly one in the dominant CA cartel. Werner, if i can help with configuring or maintaining the web server for gnupg.org to address some of these issues, please let me know. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Mon Dec 16 22:30:01 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 16 Dec 2013 13:30:01 -0800 Subject: X.509 certificates for https://gnupg.org [was: Re: Another step towards crowdfunding] In-Reply-To: <52AF6429.90201@fifthhorseman.net> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <52AF6429.90201@fifthhorseman.net> Message-ID: <20131216133001.Horde.DruCq1XpA9hT8qPX4Ov4iA4@mail.sixdemonbag.org> > for well-known free software projects (Also, as a business in Israel, > StartSSL is the target of an ongoing international boycott due to > Israeli domestic policy -- http://www.bdsmovement.net/). Although I support each person's right to believe what they want with respect to Israeli domestic policy, and to act on those beliefs in whatever lawful manner they feel is appropriate, I don't think we want to encourage GnuPG to take a political position on this issue. I think getting tangled up in politics -- especially politics that has nothing to do with privacy rights -- would ultimately be a bad thing for GnuPG. From wk at gnupg.org Mon Dec 16 23:06:48 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Dec 2013 23:06:48 +0100 Subject: [Announce] Libgcrypt 1.6.0 released In-Reply-To: <52AF56B2.3040104@digitalbrains.com> (Peter Lebbing's message of "Mon, 16 Dec 2013 20:38:26 +0100") References: <87haa8fzzm.fsf@vigenere.g10code.de> <52AF56B2.3040104@digitalbrains.com> Message-ID: <87mwk0e9hj.fsf@vigenere.g10code.de> On Mon, 16 Dec 2013 20:38, peter at digitalbrains.com said: > I think this is a typo and you mean RFC-6979 "Deterministic Usage of the Sure. Sorry for the typo. At least the docs are correct: `rfc6979' For DSA and ECDSA use a deterministic scheme for the k parameter. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dougb at dougbarton.us Mon Dec 16 23:41:52 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 16 Dec 2013 14:41:52 -0800 Subject: Sharing/Storing a private key In-Reply-To: <52ADA792.2000800@digitalbrains.com> References: <52ADA792.2000800@digitalbrains.com> Message-ID: <52AF81B0.7080004@dougbarton.us> On 12/15/2013 04:58 AM, Peter Lebbing wrote: > On 14/12/13 21:14, Leo Gaspard wrote: >> Maybe if you explained what the limitations of ssss are...? > > My guess is the fact that ssss only supports secrets up to 1024 bits; if you > want to share a larger secret you need to do a hybrid approach where you > symmetrically encrypt the data and then use secret sharing for the randomly > chosen encryption key. > > If I understand Mindiell's message right, his implementation works for larger > secrets. > > But I don't see why you wouldn't just use ssss and the hybrid approach. I haven't looked at Mindiell's software, but one argument against what you're suggesting is that it's only as secure as the encryption used in step 1 of the hybrid approach. The ability to apply SSS to the entire secret would be quite valuable, although your concern about entropy use is something that should be addressed explicitly. Doug From adrelanos at riseup.net Tue Dec 17 00:11:24 2013 From: adrelanos at riseup.net (adrelanos) Date: Mon, 16 Dec 2013 23:11:24 +0000 Subject: please give us safer defaults for gnupg In-Reply-To: <87y53keg5d.fsf__45286.6765707315$1387223541$gmane$org@vigenere.g10code.de> References: <52AF3A55.7080800@riseup.net> <87y53keg5d.fsf__45286.6765707315$1387223541$gmane$org@vigenere.g10code.de> Message-ID: <52AF889C.4030503@riseup.net> Werner Koch: > On Mon, 16 Dec 2013 18:37, adrelanos at riseup.net said: > >> [This was originally planed as an open letter, but I thought it might >> be better to hear your arguments beforehand.] > > May I suggest to read the archives of just a few weeks to collect the > reasons why suggestions of using SHA-512 are missing the point. I'll do. > Some > folks here must have bleeding fingertips from repeating the arguments > over and over. I apologize if I haven't searched thoroughly enough in past and have missed the thread suggesting to crank up the default. I can imagine that running a project as this requires nerves of steel. > Having said this, I like to appreciate that you have such a trust in us > GnuPG hackers in that our coding practice and development environment is > bug free at a level that only cracking algorithms is the danger to your > data. I think Adi Shamir was it who said: "Nobody breaks crypto > algorithms; they work around the crypto". From adrelanos at riseup.net Tue Dec 17 00:11:28 2013 From: adrelanos at riseup.net (adrelanos) Date: Mon, 16 Dec 2013 23:11:28 +0000 Subject: please give us safer defaults for gnupg In-Reply-To: <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> Message-ID: <52AF88A0.1070406@riseup.net> Robert J. Hansen:>> We think... > > If you're writing on behalf of a group, I would love to know the name of > the group and the names of its members. Understandable. At the moment it's just one person sharing that opinion. [Didn't ask many more yet.] I asked if I am allowed to tell names, probably yes, soon. > Otherwise, I can only assume > you are suffering a mental illness and are speaking for the multiple > voices in your head -- either that or else perhaps you're fighting off a > parasitic infestation and are speaking on behalf of your guests. :) :) >> gnupg still is the most used and most important encryption tool >> in the Free Software community. [1] > > It is definitely not the most-used, and it is likely not the > most-important. OpenSSL is free software, and is used orders of > magnitude more often than GnuPG. I routinely go days without using > GnuPG, but I rarely go even a few hours without accessing an > OpenSSL-secured webpage. > > GnuPG is great, don't get me wrong -- but let's keep the hype in > perspective. :) We don't use OpenSSL to encrypt our mails. I'd suppose, OpenSSL is mostly used by users not being aware of it. While OpenSSL is probably great, the CA implementation is not. And that's another story. I'd always trust gnupg more than OpenSSL, but that's mostly for usability reasons and because no contacts I know are waiting for OpenSSL encrypted messages. >> it is a somewhat usable >> racing car but it unfortunately comes with a limiter and you need to >> find out how to get rid of the limiter first. > > Although you chose this metaphor, I'm not sure that it's a metaphor you > really want to use. I agree, it's not a good analogy. I'll try harder next time. However, I trust you got my point. >> gnupg comes with poor defaults... > > If GnuPG's defaults lead it to being subverted, then I agree it is a > serious problem that will need remedy. However, as near as I can tell > that is not the situation. >> We even have a recommended gpg.conf in torbird's git repo. [2] [3] The >> fact that we even need such a thing is bad. > > For as long as GnuPG has existed people have been saying "use this > gpg.conf file that I wrote in order to get the most security." When I searched for this on search engines, I haven't found one in a project's character. (I.e. were it's open for debate/pull requests/changes.) > Very > often these 'recommended' gpg.conf files are in conflict with someone > else's 'recommended' gpg.conf file. > >> For example cert-digest-algo why is it in gpg still sha1 and not sha256 >> or sha512? > > Interoperability. SHA-1's long-term prospects are not particularly > good, but for now it is the only MUST digest algorithm in RFC4880. The > people developing RFC4880 are well aware of this problem and the choice > of digest algorithms will be addressed in the next revision of the > standard. That's the point. I argue, that "we" [hopefully soon telling you the other name and if not, other supporters sharing my standpoint] prioritize working solutions which are as secure as possible rather than waiting for some RFC to finish. [Let's forget about the we until I maybe finished the letter after clearing up some points.] I'd also suppose [okay, I am risking false consensus here] that users of other messengers with security in mind, such as bitmessage, pond, retroshare, OTR [and probably others I am not aware of or have forgotten] have a similar view on this. > Until that new revision is published, GnuPG is choosing to > maximize interoperability. This is very unfortunate. >> Now that a few people know, that short key ids can be easily >> forged [4], why isn't the keyid-format set to 0xlong by default? > > Convenience. You should always use a long key ID to retrieve a key, but > there's nothing wrong with using a short ID to refer to an > already-validated key. The main risk of short ID collisions comes from > people pulling the wrong certificate off the keyservers and mistakenly > using that one; but when it comes to using keys you have already > downloaded and validated the risk is minimal. In my opinion, training users to get accustomed to insecure things and then expecting them to do the right thing when necessary seems likely to result in many users doing the wrong thing. >> Update: now that long key ids can also be forged [8], why not show the >> full fingerprint by default? > > Convenience. See above. >> And why does gpg still create 2048 bit keys, if creating 4096 keys >> just takes a few seconds longer and virtually make no difference when >> using >> these keys? > > NIST's recommendation is that a 2048-bit key will be sufficient for the > next 30 years. Too short for me. I don't want anyone to dig up what I did 30 years ago. Stuff that hasn't been deliberately stored in meanwhile should be forgotten. > ENISA concurs in this judgment (although they recommend > 3072-bit keys for reasons that are not particularly relevant here). RSA > Data Security also concurs. Given the vast majority of cryptologic > think-tanks in the world believe 2048-bit RSA will be secure for the > next 30 years, GnuPG has taken the reasonable position of defaulting to > 2048-bit RSA. > With respect to "if creating 4096-bit keys just takes a few seconds > longer and virtually make no difference when using these keys," as > several people here have attested to in the past it makes a big > difference for many users. Mobile devices... embedded systems... sites > that do bulk encryption... mailing lists... the list goes on. I certainly know too little about mobile/emended devices to be sure it really doesn't matter for them. But where should be the border? You're not supporting MS-DOS users either and they're still around. So what is the criteria here to say what the minimum system requirements should be? In my opinion, users who're still using slow systems should choose the "faster but less secure opt-in option" unless there are too many of them in favor of the majority (?) of users who don't see any disadvantages with 4096-bit keys. >> For the sake of argument, let's take it for granted, that 2048 bit is >> still secure enough and can not be broken with brute force. > > It is not necessary to take it for the sake of argument. Compelling > thermodynamic arguments exist that say we will not break 2048-bit RSA > until we've had truly science-fiction level breakthroughs in computing > technology. >> Let's imagine, someone finds a >> vulnerability in RSA being able to reduce the difficulty for brute force >> by 1024 bit. > > This would be a science-fiction level breakthrough in mathematics. Or just just someone having a clever idea no one else had before? Happens? > If > we can imagine a 1024-bit breakthrough, why not a 2048-bit, or a > 3072-bit, or a 4096-bit, or a 16384-bit? I don't know. Why where there 2 bit breakthroughs (happened for some other algorithm) and not 4 bit? > The problem with assuming the > existence of science-fiction level attacks is that once you start > there's no reason to stop. scifi-gpg? ngpg? For Next Generation gpg? ;) >> Maybe let's add another weak argument to the mix. Part of using >> encryption software is reducing anxiety. Even if using 4096 bit instead >> of 2048 bit does little more than reducing anxiety, we'd argue, that >> reducing anxiety is a one of the tasks of encryption software. > > I'm reminded of a _Simpsons_ episode where Lisa gives Homer a > tiger-proof rock. She points out to him that he's not being attacked by > tigers, therefore the tiger-proof rock works. Homer, being foolish, > believes Lisa and asks to buy the rock from her. > > I do not believe it is ethical for us to be in the business of giving > people tiger-proof rocks. Even if it "reduces anxiety," as you put it, > it's unethical. It's not like you suddenly start selling snakeoil. For one, you wouldn't have this discussion. ;) >> We do not care about closed source PGP compatible software, namely, >> well... Good question, it's difficult finding alternative >> OpenPGP compatible software at all. > > McAfee has an offering, so does Symantec. I know that at least one > major telecommunications firm is using the most brain-damaged and > minimalistic RFC2440 implementation on the planet. There's > BouncyCastle, there's Peter Gutmann's cryptlib, there's... >> Can't remember having this seen anywhere ever. > > I'm part of the Enigmail team, and I field a fair number of help > requests from users who are having trouble. > > I'm not sure this is the most common help request I see, but it's close: > "I used this gpg.conf a friend of mine told me would give me the most > security..." Almost always, it uses cert-digest-algo, digest-algo or > cipher-algo in a way that is seriously affecting interoperability. What about liberating ourselves by forgetting about compatibility at some point and starting fresh and most secure? By never breaking compatibility, you can never reduce complexity. Less complexity means more simplicity, thus perhaps more usability. In my experience, projects that were created long after gpg are much more usable, probably because they could learn from gpg which things do not work so well. And I am not cynic here, because without gpg we wouldn't have that knowledge and also not those other clients being so usable. Robert, Werner, let me say that I value a lot, that you're discussion these matters in public without taking offense even though our standpoints are quite different. (Most likely due to our different histories, knowledge, believes, etc.) Please tell me, what kind of argument would you accept? I guess you'd like to see loads of happy gpg users, gpg for the masses, etc. Would numbers convince you? I mean, What if alternative projects such as Bitmessage etc. managed to get far more users while gpg passes into oblivion [while they objectively provide more/less security]? From rjh at sixdemonbag.org Tue Dec 17 02:34:31 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 16 Dec 2013 20:34:31 -0500 Subject: please give us safer defaults for gnupg In-Reply-To: <52AF88A0.1070406@riseup.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> Message-ID: <52AFAA27.2080304@sixdemonbag.org> On 12/16/2013 6:11 PM, adrelanos wrote: > When I searched for this on search engines, I haven't found one in a > project's character. (I.e. were it's open for debate/pull > requests/changes.) Perhaps not, but you *did* find them. Your original email referenced, for instance, the Debian GnuPG migration guide, which makes its own recommendations for what one's gpg.conf file should contain. Websites with their own recommendations for "how to *really* make GnuPG secure" are a dime a dozen; most of them are put up by people who deeply misunderstand GnuPG. (The Debian guide is, fortunately, among the better ones.) > That's the point. I argue, that "we" [hopefully soon telling you the > other name and if not, other supporters sharing my standpoint] > prioritize working solutions which are as secure as possible rather > than waiting for some RFC to finish. Then you need to use some other tool. Alternately, you could create your own GnuPG distribution which installs a gpg.conf file tweaked the way you want it -- but I personally find it unlikely that the changes you seek will be incorporated into GnuPG's master branch. > I'd also suppose [okay, I am risking false consensus here] that > users of other messengers with security in mind... After Richard Nixon was re-elected President in 1972, the _New York Times_ film critic Pauline Kael exploded. "Nixon? Re-elected? That's impossible! Nobody I know voted for Nixon!" Nothing is less trustworthy than our supposition about the feeling of a community far, far larger than we are. > In my opinion, training users to get accustomed to insecure things > and then expecting them to do the right thing when necessary seems > likely to result in many users doing the wrong thing. This is not a vulnerability. Assume, for sake of argument, that my friend has a long key ID of 0xDECAFBADDEADBEEF. I verify the fingerprint, sign the certificate, and thus validate it. Someone else tries to trick me into a collision by sending me a certificate signed with 0xBADD00D5DEADBEEF. My email client automatically downloads the certificate from the server. I now have two certificates with the shortID of 0xDEADBEEF... ... and absolutely zero risk. My email client tells me whether a message is signed by a validated key or an invalid key, so no one can use the (invalid) 0xBADD00D5DEADBEEF key to trick me into believing it comes from the (valid) 0xDECAFBADDEADBEEF key. And when encrypting a message for my friend, GnuPG won't let me encrypt to 0xBADD00D5DEADBEEF because it's an invalid certificate. When certificates are properly verified and validated, the risk from shortID (or even longID) collisions is effectively zero. It's only when one disables key validation checking, or improperly validates certificates, that an attack surface becomes manifest. > Too short for me. Then use something other than GnuPG. PGP was originally "Pretty Good Privacy." Phil Zimmerman named it that for a reason: it's pretty good. It's not perfect and it won't be secure forever. GnuPG is built in that mold. If you need perfect privacy, or forever privacy, you need to look elsewhere. GnuPG offers neither. > So what is the criteria here to say what the minimum system > requirements should be? I imagine it's something like, "If enough people complain to Werner about how GnuPG is no longer usable on their system, Werner will know the system requirements should be lowered." >>> Let's imagine, someone finds a vulnerability in RSA being able >>> to reduce the difficulty for brute force by 1024 bit. >> >> This would be a science-fiction level breakthrough in mathematics. > > Or just just someone having a clever idea no one else had before? > Happens? At some point they're the same thing. The point remains, though, that we can't defend against science-fiction level attacks, nor is it productive for us to try. Because once you start imagining science-fiction level attacks, where does it stop? > I don't know. Why where there 2 bit breakthroughs (happened for some > other algorithm) and not 4 bit? A 2-bit reduction is not a science-fiction breakthrough. A 1024-bit reduction would be. > What about liberating ourselves by forgetting about compatibility at > some point and starting fresh and most secure? In 2000 I was a young software engineer living in San Francisco. I was considering applying for a job at a major, internationally-recognized bank. Before I sent in my resume, though, I talked to a friend who worked there to ask about what kind of work I'd be doing. My friend told me the bank was undertaking a massive clean-slate project to get rid of all their legacy COBOL code and replace it with modern, well-designed, object-oriented Java. I passed on the job. To the managers at that bank, starting over from a clean piece of paper sounded like the sort of thing that really should be done. To a software engineer, it sounds suicidal. Those ancient COBOL applications have been running with near-100% uptime for 50+ years and last had a bug 20 years ago. Getting rid of that is not the sort of thing one does lightly, and never just because it seems like a good time to do a clean-slate rewrite. I think that if you consider this story, you will come up with what I think of the idea of discarding RFC4880 and starting over from a clean slate. :) > Robert, Werner, let me say that I value a lot, that you're discussion > these matters in public without taking offense even though our > standpoints are quite different. (Most likely due to our different > histories, knowledge, believes, etc.) > > Please tell me, what kind of argument would you accept? My father is a federal judge who was asked to join FISA. (He declined.) I believe that, given my close association with the United States government, a lot of people would stop trusting GnuPG if I were to ever take a leadership or development role in GnuPG. For that reason "what kind of argument I would accept" is really kind of irrelevant -- you're trying to convince Werner, not me. All I do is answer questions, dude. :) (Also, it should follow that I am not speaking for Werner, nor for GnuPG! This email contains nothing except my own rambling opinions.) From micah at micahflee.com Tue Dec 17 04:05:20 2013 From: micah at micahflee.com (Micah Lee) Date: Mon, 16 Dec 2013 19:05:20 -0800 Subject: X.509 certificates for https://gnupg.org [was: Re: Another step towards crowdfunding] In-Reply-To: <52AF6429.90201@fifthhorseman.net> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <52AF6429.90201@fifthhorseman.net> Message-ID: <52AFBF70.4060209@micahflee.com> On 12/16/2013 12:35 PM, Daniel Kahn Gillmor wrote: > Regardless of how you feel about the CA cartel in general, StartSSL is > not the only member of the cartel offering gratis certs, particularly > for well-known free software projects Oh interesting, I didn't realize there were other CAs that give gratis certs. I don't think it matters at all what CA is used as long as browsers trust it, and I only suggested StartSSL because it's less scamy when it doesn't cost money. I hope some day one of the decentralized trust solutions takes over CAs. But on the topic of improving the HTTPS support on gnupg.org, I think torproject.org is pretty much an ideal example. They serve binaries of Tor Browser Bundle from https://www.torproject.org/ and have been attacked by governments all over the world, so they've put a lot of time and energy in doing things right. I'd like to see GPG have just as good web security. (And for that matter, why do I have two cookies in my browser that gnupg.org set? _pk_id.1.9e41 and _pk_ses.1.9e41 -- the id one is a unique id, which means it can be used to track my movements through that domain even if I switch IPs.) -- Micah Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From shmick at riseup.net Tue Dec 17 05:23:34 2013 From: shmick at riseup.net (shmick at riseup.net) Date: Tue, 17 Dec 2013 15:23:34 +1100 Subject: Libgcrypt 1.6.0 released and gunpg 2.x In-Reply-To: <87haa8fzzm.fsf@vigenere.g10code.de> References: <87haa8fzzm.fsf@vigenere.g10code.de> Message-ID: <52AFD1C6.4020600@riseup.net> this looks like a significant upgrade if i have already compiled gnupg 2.x with libgcrypt 1.5.3, and i want to use the new 1.6.0, do i need to uninstall gnupg & libcrypt and then compile both again together, and re-install ? gnupg 2.x would not work with the new libgcrypt if i just install it alone, would it ? (im sure i have to do it all again...) From wk at gnupg.org Tue Dec 17 10:02:16 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 10:02:16 +0100 Subject: Libgcrypt 1.6.0 released and gunpg 2.x In-Reply-To: <52AFD1C6.4020600@riseup.net> (shmick@riseup.net's message of "Tue, 17 Dec 2013 15:23:34 +1100") References: <87haa8fzzm.fsf@vigenere.g10code.de> <52AFD1C6.4020600@riseup.net> Message-ID: <87r49bdf53.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 05:23, shmick at riseup.net said: > use the new 1.6.0, do i need to uninstall gnupg & libcrypt and then > compile both again together, and re-install ? 1.6.0 has a new SO number so there are no runtime conflicts. However, to avoid building problems, better de-install or overwrite the 1.5.3 development files (static library (if build), header files, and libgcrypt-config). If you installed 1.5.3 yourself, simply installing 1.6.0 should do everything you need. I am not 100% sure that building gnupg 2.0 will work without problems - I only tested the latest 2.0 GIT version. > gnupg 2.x would not work with the new libgcrypt if i just install it > alone, would it ? (im sure i have to do it all again...) No you need to build gnupg again. Libgcrypt has a different ABI and thus a different SO number (20 on common Linux systems). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 17 10:43:34 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 10:43:34 +0100 Subject: please give us safer defaults for gnupg In-Reply-To: <52AF88A0.1070406@riseup.net> (adrelanos@riseup.net's message of "Mon, 16 Dec 2013 23:11:28 +0000") References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> Message-ID: <87mwjzdd89.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 00:11, adrelanos at riseup.net said: > compatibility, you can never reduce complexity. Less complexity means > more simplicity, thus perhaps more usability. In my experience, projects [ You may want to start getting rid of software which is run on your computer without you being in control of it (noscript seems to be the Anti-virus software counterpart for the Web) ] > Please tell me, what kind of argument would you accept? I guess you'd > like to see loads of happy gpg users, gpg for the masses, etc. Would > numbers convince you? I mean, What if alternative projects such as The next step will be the move to ECC which increases the security while at the same time reducing the computation load and allowing for really short keys (e.g. 32 bytes) > Bitmessage etc. managed to get far more users while gpg passes into > oblivion [while they objectively provide more/less security]? There are many systems with more users than gpg. Actually most systems have more users. Think of Skype, Bittorrent, or even Jabber. I believe GnuPG is still a useful tool, much like zip or tar. As with many infrastructure systems you will notices it only if it stops working. No more off-line credit card processing, hardware supply chains breaks, no way to detect tampered software distributions etc, no way to send account data. It is easy for centralized or semi-centralized systems to get usage statistics, for PGP (and to a less degree for S/MIME) it is much harder to get the figures. There are may keyservers running inside of many companies. Shalom-Salam, Werner ps. As a minor data point that OpenPGP is getting more attention might be the fact that the German Home Office has come around to prominent publish a PGP key at their contact page (576D4411C9AD3034). Funnily wrapped into a ZIP file, though. No hints for S/MIME or other encryption methods. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lev at serebryakov.spb.ru Tue Dec 17 10:09:10 2013 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Tue, 17 Dec 2013 13:09:10 +0400 Subject: Synchronize UID lists on public and private key -- how? Message-ID: <741976169.20131217130902@serebryakov.spb.ru> Hello, Gnupg-users. I have 2 systems, where I use gpg, lets name them A and B. I did this sequence of commands: (1, on A) generate key pair (2, on A) add 2 more UIDs to key pair (3 in total) (3, on A) send public key to public server (4, on A) copy private keyring to USB stick (5, on B) copy private keyring from USB stick (6, on B) get public part from public server (7, on B) add 2 more UIDs to key pair (5 in total) (8, on B) (re)send public key to public server (9, on A) refresh public key from public server Now on (A) I have key pair where UID lists are different for public and private keys! Public key has 5 UIDs and private key has 3 UIDs! And I cannot sign message from my "new" UID on computer A! Is it possible to synchronize UID list without transferring "new" version of private key from B to A by external means? -- // Black Lion AKA Lev Serebryakov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 960 bytes Desc: not available URL: From wk at gnupg.org Tue Dec 17 11:04:27 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 11:04:27 +0100 Subject: X.509 certificates for https://gnupg.org In-Reply-To: <52AFBF70.4060209@micahflee.com> (Micah Lee's message of "Mon, 16 Dec 2013 19:05:20 -0800") References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <52AF6429.90201@fifthhorseman.net> <52AFBF70.4060209@micahflee.com> Message-ID: <87ioundc9g.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 04:05, micah at micahflee.com said: > torproject.org is pretty much an ideal example. They serve binaries of > Tor Browser Bundle from https://www.torproject.org/ and have been > attacked by governments all over the world, so they've put a lot of time > and energy in doing things right. I'd like to see GPG have just as good gnupg.org is a bit different in that in general we only provide source code and not ready to use binaries. Thus this is not a mainstream download site. Gpg4win.org, at the other hand, provides Windows installers and we [1] even acquired a code signing certificate so that users don't complain about the Windows message about "downloaded from the Internet; unknown issuer". It is well known that a lot of rogue software shows up as valid and signed software and that this code signing does not provide any security. However, users want that. Far less people complained about Intevation's own CA for https access to gpg4win.org. I am unsure what to do about CA certificates - I don't trust the global PKIX at all. It lures users into false security. Thus, I believe CAcert is just as fine as any other - it can't be better because all root certificates are implicitly cross-signed (the browser treats them all the same). > (And for that matter, why do I have two cookies in my browser that > gnupg.org set? _pk_id.1.9e41 and _pk_ses.1.9e41 -- the id one is a > unique id, which means it can be used to track my movements through that You must be running with JavaScript enabled ;-). This seems to be from Piwik, which I recently installed to gather web statistics. I am not really happy with that but my campaign manager said that it is really needed and that organization like the EFF also run Piwik. Our privacy policy says ** Analytics This website uses Piwik, a Free Software web analytics system, to monitor traffic on our Web sites. Piwik records the general geographical vicinity of visitors as well as their browser and operating system, and records their navigation within the sites. This helps us gauge the impact of our materials and improve our work. Our Piwik system preserves privacy by anonymizing visitors? IP addresses. This means that we will not store any personally identifiable information about you, even though your visit produces a record that our site was visited by someone. Piwik also respects the ?[[http://donottrack.us/][Do Not Track]]? preference offered by some browsers, so if you have this option set, Piwik will ignore your visit entirely. Details of how Piwik protects privacy are on [[http://piwik.org/privacy/][their website]]. I guess we will eventually switch to log file statistics which basically returns the same information. And also tracks those who disabled JS - whether this is good or worse, I don't know. Salam-Shalom, Werner [1] g10 Code and Intevation, the latter being a company I often work with and co-run by yet another founder of the FSFE. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 17 11:59:13 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 11:59:13 +0100 Subject: Another step towards crowdfunding In-Reply-To: <52AF555D.30103@micahflee.com> (Micah Lee's message of "Mon, 16 Dec 2013 11:32:45 -0800") References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> Message-ID: <87eh5bd9q6.fsf@vigenere.g10code.de> On Mon, 16 Dec 2013 20:32, micah at micahflee.com said: > Ahh, it's good to know that gnupg.org is available for https. But I > would guess a very small percentage of your visitors use it, or even > know that it's available. Well, bowsers could first try to use https. Would it help them to provide a SRV record for this? > If you want to fix this, you could make all incoming http traffic > respond with a 301 redirect to https. I am not sure whether this helps. If we eventually offer http download we could use https: fro that instead. There is also a plan for provided a hidden tor service. > this (and because it's good practice and doesn't hurt) you could also > set the HSTS header, which prevents browser from accidentally (or being > tricked into) loading the website over http: Should be considered, I need to hack up Boa anyway. > Also, looks like the CA is CAcert--an awesome CA, but not trusted by > browsers by default. I'd suggest getting a cert from StartSSL > [https://startssl.com/], since they're they only CA that gives certs for > free. And a wildcard cert (for *.gnupg.org) ends up costing like $60 USD. I hesitate to pay the highwaymen. > Also, it would be great if the use of https could be done better. The > Qualys SSL report gives https://gnupg.org/ an F (because of the CAcert > issue), but even if you used a browser-trusted CA it still wouldn't be > the best: https://www.ssllabs.com/ssltest/analyze.html?d=gnupg.org Yes, there is a the problem with the CAcert intermediate certificate - it is on my todo list to update this. > I notice you're using Boa Webserver, and their docs don't seem to show > how to do things like set custom http headers or mess with the Adding headers is easy, as said. Boa does not do https. gnupg.org uses the pound proxy to implement https and redirection. I changed the cipher suite for gnupg.org to a quite restricted one. More to come. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From samtuke at gnupg.org Tue Dec 17 14:53:14 2013 From: samtuke at gnupg.org (Sam Tuke) Date: Tue, 17 Dec 2013 14:53:14 +0100 Subject: Another step towards crowdfunding In-Reply-To: <20131214202738.27030@gmx.com> References: <20131214202738.27030@gmx.com> Message-ID: <52B0574A.4090206@gnupg.org> On 14/12/13 21:27, Zechariah Seth wrote: > Will GnuPG blogs be cross-posted to the gnupg-users list? :) I could do that if others are happy with the idea. Any objections? Werner? Best, Sam. -- Sam Tuke Campaign Manager Gnu Privacy Guard Tel: +49 176 81923811 IM: samtuke at jabber.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 295 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Dec 17 16:07:11 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 10:07:11 -0500 Subject: Another step towards crowdfunding In-Reply-To: <52B0574A.4090206@gnupg.org> References: <20131214202738.27030@gmx.com> <52B0574A.4090206@gnupg.org> Message-ID: <52B0689F.7040301@fifthhorseman.net> On 12/17/2013 08:53 AM, Sam Tuke wrote: > On 14/12/13 21:27, Zechariah Seth wrote: >> Will GnuPG blogs be cross-posted to the gnupg-users list? :) > > I could do that if others are happy with the idea. If the expected volume is low-ish (e.g. no more than once a week or so) i think that would be a great thing to do. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From samtuke at gnupg.org Tue Dec 17 16:11:06 2013 From: samtuke at gnupg.org (Sam Tuke) Date: Tue, 17 Dec 2013 16:11:06 +0100 Subject: Another step towards crowdfunding In-Reply-To: <52B0689F.7040301@fifthhorseman.net> References: <20131214202738.27030@gmx.com> <52B0574A.4090206@gnupg.org> <52B0689F.7040301@fifthhorseman.net> Message-ID: <52B0698A.30007@gnupg.org> On 17/12/13 16:07, Daniel Kahn Gillmor wrote: > If the expected volume is low-ish (e.g. no more than once a week or so) > i think that would be a great thing to do. Yes it's unlikely to be more than that. Best, Sam. -- Sam Tuke Campaign Manager Gnu Privacy Guard Tel: +49 176 81923811 IM: samtuke at jabber.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 295 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 17 16:38:07 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 16:38:07 +0100 Subject: Another step towards crowdfunding In-Reply-To: <52B0574A.4090206@gnupg.org> (Sam Tuke's message of "Tue, 17 Dec 2013 14:53:14 +0100") References: <20131214202738.27030@gmx.com> <52B0574A.4090206@gnupg.org> Message-ID: <87fvprbi8w.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 14:53, samtuke at gnupg.org said: > I could do that if others are happy with the idea. Any objections? Werner? No. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 17 16:37:27 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 16:37:27 +0100 Subject: X.509 certificates for https://gnupg.org In-Reply-To: <52AF6429.90201@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 16 Dec 2013 15:35:53 -0500") References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <52AF6429.90201@fifthhorseman.net> Message-ID: <87k3f3bia0.fsf@vigenere.g10code.de> On Mon, 16 Dec 2013 21:35, dkg at fifthhorseman.net said: > Werner, if i can help with configuring or maintaining the web server for > gnupg.org to address some of these issues, please let me know. Yes, I have problems to figure out a woking cipher list which also allows for IE. What DHE cipher suite may I use with IE given that I have only an RSA certificate. Or should I simply give up on PFS for IE users? The active ciphers are right now: ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 Shalom-Salam, Werner p.s. Attached is I my SSLNoCompression patch for Debian's pound in case someone is interested. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: pound_no_compression.patch Type: text/x-diff Size: 3627 bytes Desc: not available URL: From md123 at nycap.rr.com Tue Dec 17 16:07:49 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 10:07:49 -0500 Subject: encryption algorithm In-Reply-To: <52AFAA27.2080304@sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> Message-ID: <52B068C5.2010003@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! What encryption algorithm do we use in OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsGjEAAoJECrdp7MWSIVbE3QH/iO9D8hesLb7YRufyGIGfPo3 Fufc97VKZ9NUrtYwJWhvnwOBFCKsUPQTFUx/uyQBoanL85HaFPzyPO8tdsZ2wUNc 3AxnGELdsdzI3BvunWAfOUXREBxfRmKXBT5ryAF4/uz3wmrMPWn2C9lQFXW+Mz5V KGrFBcpuJle5jpxfdru4W+J1vdUw8TufijC9qhKqw44koI9bHkCFc7ciUlPmFVdo bp+8gmJoC/aZGF7IhpgGfugM5T5XdiDgzHdpLlxtyaXJTyr3o27N0zd2AGLOH/wC +X0GKA7I2A7MQGurPSzgrVgw/I7Lzu3P5wui4Lc/xbee8v/yFQWhiRDGTTWh8Bc= =hQEy -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Tue Dec 17 17:09:33 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 11:09:33 -0500 Subject: encryption algorithm In-Reply-To: <52B068C5.2010003@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> Message-ID: <52B0773D.6020203@fifthhorseman.net> Hi Matt-- On 12/17/2013 10:07 AM, Matt D wrote: > Hi! What encryption algorithm do we use in OpenPGP OpenPGP has "algorithm agility", meaning that it's possible to use different encryption algorithms at different times in the same cryptographic framework. encrypted OpenPGP messages are generally also "hybrid" messages -- that is, the bulk of the message is encrypted with a symmetric encryption algorithm (using a random key), and that random key is encrypted to the recipient's public key using an asymmetric algorithm. If you want more details, you might be interested in the list of symmetric key algorithms: https://tools.ietf.org/html/rfc4880#section-9.2 or possibly the asymmetric algorithms: https://tools.ietf.org/html/rfc4880#section-9.1 Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 17 17:02:26 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 17:02:26 +0100 Subject: encryption algorithm In-Reply-To: <52B068C5.2010003@nycap.rr.com> (Matt D.'s message of "Tue, 17 Dec 2013 10:07:49 -0500") References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> Message-ID: <87txe7a2jx.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 16:07, md123 at nycap.rr.com said: > Hi! What encryption algorithm do we use in OpenPGP The defaults for the public key algorithm is RSA with a 2048 bits. For the symmentric session key the default algorithms are AES256, AES192, AES256, CAST5-128, 3DES where gpg picks the best macthing one depending on the capabilities of the recipients key. If all recipeins have new keys they will all use AES256. ("new" is measured in years). > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Tue Dec 17 17:31:43 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 08:31:43 -0800 Subject: encryption algorithm In-Reply-To: <52B068C5.2010003@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> Message-ID: <20131217083143.Horde.mYwF56OUJ52xyHWWAi7CAw1@mail.sixdemonbag.org> > Hi! What encryption algorithm do we use in OpenPGP It depends a lot on how you have GnuPG configured and how your recipient's certificate is configured. For asymmetric encryption, either RSA or Elgamal will be used. For symmetric encryption, one of Twofish, AES256, AES192, AES128, Camellia256, Camellia192, Camellia128, CAST5-128, Blowfish, IDEA or 3DES will be used. From md123 at nycap.rr.com Tue Dec 17 17:31:26 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 11:31:26 -0500 Subject: encryption algorithm In-Reply-To: <52B0773D.6020203@fifthhorseman.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> Message-ID: <52B07C5E.5030205@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 11:09 AM, Daniel Kahn Gillmor wrote: > Hi Matt-- > > On 12/17/2013 10:07 AM, Matt D wrote: >> Hi! What encryption algorithm do we use in OpenPGP > > OpenPGP has "algorithm agility", meaning that it's possible to use > different encryption algorithms at different times in the same > cryptographic framework. encrypted OpenPGP messages are generally > also "hybrid" messages -- that is, the bulk of the message is > encrypted with a symmetric encryption algorithm (using a random > key), and that random key is encrypted to the recipient's public > key using an asymmetric algorithm. Please excuse my ignorance but I have a question after looking at the list. It is my impression that I can choose an algorithm for my machine and whoever else I communicate with can choose another algorithm. Is this correct? Why would anyone choose AES-128 instead of something more secure, say AES-256? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsHxdAAoJECrdp7MWSIVb3icH/RgbWzDfDA/exNyu/Qt2+DPh 1kiEjxsRCxNlvhzLIvafvqgCHvqAtrq+BcqSiFSfY37FQymm02mAeEpExPmDSnHT K3MH361++55ur/53WjQZpfw/4T+40PzTukSGMupCSWS82x2osw4upbPDixZcTwXo byXaBcjdaXPza7W84LxBfQDXd3l1VyX0kwF51spXUrQ9TyrYIyzjDU4e/teUVaY1 HopB95dRLlT+SEih2f5lemPeRGvnd7D40cFXfiseLxRcsb3SPtAQ6keHGWz7xuRl 5juYws4xXTuZVBm4N8Euft/DNmi8SuSjc6iuALCpAYztTFId9q6AQLOumK9N7rk= =WISY -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Tue Dec 17 17:57:34 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 17 Dec 2013 11:57:34 -0500 Subject: encryption algorithm In-Reply-To: <52B07C5E.5030205@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> Message-ID: <2A8DBDAC-23C3-4B09-BD22-37E545F98BC2@jabberwocky.com> On Dec 17, 2013, at 11:31 AM, Matt D wrote: > On 12/17/2013 11:09 AM, Daniel Kahn Gillmor wrote: >> Hi Matt-- >> >> On 12/17/2013 10:07 AM, Matt D wrote: >>> Hi! What encryption algorithm do we use in OpenPGP >> >> OpenPGP has "algorithm agility", meaning that it's possible to use >> different encryption algorithms at different times in the same >> cryptographic framework. encrypted OpenPGP messages are generally >> also "hybrid" messages -- that is, the bulk of the message is >> encrypted with a symmetric encryption algorithm (using a random >> key), and that random key is encrypted to the recipient's public >> key using an asymmetric algorithm. > > Please excuse my ignorance but I have a question after looking at the > list. It is my impression that I can choose an algorithm for my > machine and whoever else I communicate with can choose another > algorithm. Is this correct? Why would anyone choose AES-128 instead > of something more secure, say AES-256? The short answer is that not every OpenPGP program supports all algorithms. The only algorithm that MUST be present is Triple-DES. Some algorithms are recommended, and some are totally optional, but 3DES is a hard requirement. It's possible that they simply don't have AES-256. It's not quite accurate that you can choose an algorithm for your machine and whoever you communicate with can choose another. Rather, algorithms in OpenPGP are ranked. Each user (i.e. each key) has their own list, in order, of algorithms. Triple-DES, the required algorithm, is always on this list (if you leave it off, GnuPG acts as if it's at the bottom of the list). This list serves several purposes at the same time - first, it means that an algorithm that a particular user can't use (say their OpenPGP program doesn't support it) is guaranteed never to be used. If it's not on the list somewhere, it won't be used. Secondly, it allows users to indicate which algorithms they prefer. If you prefer AES-256, above AES-128, then you list them in that order. (In practice, GnuPG usually supports all of the algorithms, so the ordering functionality is more useful than the "don't use an algorithm I don't have" functionality.) Different programs take this ordering into account in varying ways. For GnuPG specifically, it tries to make as many people as happy as possible. For example, if a message is being encrypted to three people, two of whom have AES-256 as their first choice, and one who has something else, the likely result will be that AES-256 is chosen. So you pick your favorites, and people you communicate with pick their favorites, and the OpenPGP protocol handles the rest. David From rjh at sixdemonbag.org Tue Dec 17 18:02:00 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 09:02:00 -0800 Subject: encryption algorithm In-Reply-To: <52B07C5E.5030205@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> Message-ID: <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> > Why would anyone choose AES-128 instead of something more secure, > say AES-256? "More secure" is sort of ... missing the point. It's sort of like arguing over whether King Kong or Godzilla is better at urban destruction. We choose between ciphers principally based on features other than some nebulous concept of 'security', at which we can say that all the ciphers are more or less equally secure. Insofar as why one might be chosen over another, a big reason is regulatory compliance. For instance, a business might be constrained by laws or regulations that require 128-bit crypto. Some regulations may require national standards to be used; in this case, a Japanese business may be required to use Camellia, while a U.S. business would be required to use AES or 3DES. The other big reason to prefer one over another is comfort. I've audited GnuPG's 3DES code and I'm satisfied that it's correct; I haven't audited the other algorithms. That means I feel more comfortable using 3DES. From cloudpg at informationelle-selbstbestimmung-im-internet.de Tue Dec 17 18:32:26 2013 From: cloudpg at informationelle-selbstbestimmung-im-internet.de (Jens Lechtenboerger) Date: Tue, 17 Dec 2013 18:32:26 +0100 Subject: gpgsm and encrypt-to Message-ID: <86d2kvfknp.fsf@informationelle-selbstbestimmung-im-internet.de> Hi there, gpgsm has the option encrypt-to, which is not mentioned in the man page. Is that option stable or might it disappear in the future? Thanks Jens From md123 at nycap.rr.com Tue Dec 17 18:41:28 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 12:41:28 -0500 Subject: encryption algorithm In-Reply-To: <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> Message-ID: <52B08CC8.8000009@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 12:02 PM, Robert J. Hansen wrote: >> Why would anyone choose AES-128 instead of something more secure, >> say AES-256? > > "More secure" is sort of ... missing the point. It's sort of like > arguing over whether King Kong or Godzilla is better at urban > destruction. We choose between ciphers principally based on > features other than some nebulous concept of 'security', at which > we can say that all the ciphers are more or less equally secure. (Definitely Godzilla) But why do people tell me that DH, DSA, and RSA under 2048 are unacceptable? > > Insofar as why one might be chosen over another, a big reason is > regulatory compliance. For instance, a business might be > constrained by laws or regulations that require 128-bit crypto. > Some regulations may require national standards to be used; in this > case, a Japanese business may be required to use Camellia, while a > U.S. business would be required to use AES or 3DES. > > The other big reason to prefer one over another is comfort. I've > audited GnuPG's 3DES code and I'm satisfied that it's correct; I > haven't audited the other algorithms. That means I feel more > comfortable using 3DES. > How can I find whats on my list? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsIzHAAoJECrdp7MWSIVb4z8H/3rsJx28X0LfAeRmMXo2yoce 48HnFEzs/jZ/aXT+yuBr73Ri81MCGtGvW0M0DNzWAwY5GRHiP6FiXbYBfMHovVVY hoFwq20MAEkkHRDx34pkrPMqiQj2m6hR/ayJ+bkIMZquYS3z6gnbJYpp1NS5Uwi0 PI81Q7gWzi4xTv/NFluCLfry7Gc6TGXop71L6RROqhkSG1MJ4c1Aev3D7cW7h0Ke r8WGlD9NDa9lZUSotKgQveIwFvwsMYmpeqWeP4/m5Xb+GReuVsy7ugirOMz4xmTA FoMSx63YyH5JLii/+z/Afn/iTXgXNRP3pIfqak2DseM0eDR1rh1dJFkR9xBJex0= =9656 -----END PGP SIGNATURE----- From adrelanos at riseup.net Tue Dec 17 18:44:36 2013 From: adrelanos at riseup.net (adrelanos) Date: Tue, 17 Dec 2013 17:44:36 +0000 Subject: please give us safer defaults for gnupg In-Reply-To: <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> Message-ID: <52B08D84.5090906@riseup.net> Robert J. Hansen: >> We think... > > If you're writing on behalf of a group, I would love to know the name of > the group and the names of its members. Otherwise, I can only assume > you are suffering a mental illness and are speaking for the multiple > voices in your head -- either that or else perhaps you're fighting off a > parasitic infestation and are speaking on behalf of your guests. :) Okay, I've got confirmation to lift the "secret". (I would have had it beforehand, but I am a careful person.) The person who agreed with me: carlo von lynX Also the autor of "15 reasons not to start using PGP". [1] Cheers, adrelanos [1] http://secushare.org/PGP From dkg at fifthhorseman.net Tue Dec 17 18:52:16 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 12:52:16 -0500 Subject: X.509 certificates for https://gnupg.org In-Reply-To: <87k3f3bia0.fsf@vigenere.g10code.de> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <52AF6429.90201@fifthhorseman.net> <87k3f3bia0.fsf@vigenere.g10code.de> Message-ID: <52B08F50.2050409@fifthhorseman.net> On 12/17/2013 10:37 AM, Werner Koch wrote: > On Mon, 16 Dec 2013 21:35, dkg at fifthhorseman.net said: > >> Werner, if i can help with configuring or maintaining the web server for >> gnupg.org to address some of these issues, please let me know. > > Yes, I have problems to figure out a woking cipher list which also > allows for IE. What DHE cipher suite may I use with IE given that I > have only an RSA certificate. Or should I simply give up on PFS for IE > users? The active ciphers are right now: > > ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 > DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 > DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 I think it depends on what flavor of IE you're using (and what version of the underlying OS you're using as well). The version of schannel in Windows XP doesn't support ECDHE (or AES(!)) at all, and i don't think any version of schannel supports DHE-RSA if i'm reading these tech reports correctly: Cipher Suites in Schannel http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx Schannel Cipher Suites in Windows Vista: http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx TLS Cipher Suites in Windows XP and Windows Server 2003: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx Secure Sockets Layer Protocol (v2 and v3) in Windows XP and Windows Server 2003: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380124%28v=vs.85%29.aspx If you want to be able to support these systems, you may need to add a low-priority "Lowest Common Denominator" ciphersuite to match them. Sadly, that seems likely to be TLS_RSA_WITH_3DES_EDE_CBC_SHA, unless you somehow can score a DSA certificate for the service as well (since TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA seems to be the only PFS ciphersuite supported by XP's native TLS stack). I've never even tried to get a DSA certificate for a web server from any member of the CA cartel. Have you? If you want to discourage clients from picking the lowest-common-denominator ciphersuite unless it's the only one they support, you should probably set "SSLHonorCipherOrder 1" in your pound configuration. > p.s. > Attached is I my SSLNoCompression patch for Debian's pound in case > someone is interested. Thanks, i've forwarded that to http://bugs.debian.org/727197 Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From avi.wiki at gmail.com Tue Dec 17 19:07:47 2013 From: avi.wiki at gmail.com (Avi) Date: Tue, 17 Dec 2013 13:07:47 -0500 Subject: encryption algorithm In-Reply-To: <52B08CC8.8000009@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> Message-ID: On Tue, Dec 17, 2013 at 12:41 PM, Matt D wrote: > > > > How can I find whats on my list? > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 You can see what is in your list with the 'showpref' command whilst in the key editing menu. Avi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) - GPGshell v3.78 Comment: Most recent key: Click show in box @ http://is.gd/4xJrs iL4EAREIAGYFAlKwkt1fGGh0dHA6Ly9rZXlzZXJ2ZXIudWJ1bnR1LmNvbS9wa3Mv bG9va3VwP29wPWdldCZoYXNoPW9uJmZpbmdlcnByaW50PW9uJnNlYXJjaD0weDBE NjJCMDE5RjgwRTI5RjkACgkQDWKwGfgOKfnZ2wD+J/oH3cMzrWmRVJxdvFaFStZB MV5CZUky+sX1tBYXrGkA/2VdBfiC5MDa4gh9yE/9T30WKE2kJ8VvdRBGl1uEamBQ =+z9c -----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 cloudpg at informationelle-selbstbestimmung-im-internet.de Tue Dec 17 18:57:48 2013 From: cloudpg at informationelle-selbstbestimmung-im-internet.de (Jens Lechtenboerger) Date: Tue, 17 Dec 2013 18:57:48 +0100 Subject: gpgsm and trusted keys Message-ID: <868uvjfjhf.fsf@informationelle-selbstbestimmung-im-internet.de> Hi there, after I imported my private key into gpgsm, it was not trusted for signatures by gpgsm, because the root CA was not trusted. After enabling allow-mark-trusted in gpg-agent.conf, gpg-agent asks whether I trust the root CA. Saying "yes" creates ~/.gnupg/trustlist.txt with the root certificate's fingerprint, and the key becomes usable. However, I actually don't trust them, so I don't want their fingerprint in trustlist.txt. Instead, I do trust the intermediate CA, which signed my certificate request. Manually adding their fingerprint to trustlist.txt did not work, though. I was still asked for trust in the root CA, and saying "No" resulted in a failed signature. Is there a way to mark intermediate CAs as trusted so that all certificates issued by them become usable? Thanks Jens From rjh at sixdemonbag.org Tue Dec 17 19:22:33 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 10:22:33 -0800 Subject: encryption algorithm In-Reply-To: <52B08CC8.8000009@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> Message-ID: <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> > (Definitely Godzilla) But why do people tell me that DH, DSA, and RSA > under 2048 are unacceptable? I have to let my cynicism shine through, unfortunately. For the vast majority of the population, cryptographic technologies are a giant black box. The popular view is that it's something only accessible to really blindingly smart people, and that these people know better than you. As a result, there is never a shortage of people who read a few web pages, come to a vague understanding of things, declare themselves to be experts, and then preach doom and gloom if you ever even think of violating their recommendations -- because, after all, they're *experts*. Charlatanry is so commonplace in the crypto world there's even a FAQ entry for it. With respect to 2048-bit crypto, don't believe the hype. Most users and most purposes will still be well-served with even a 1024-bit key. No one with half a brain is going to bother trying to break RSA-1024; they will instead come up with more effective ways of recovering your message. But there are some people and some users who have a true need for long-term security in their messages. The current recommendations of NIST, ENISA, RSADSI and others is that RSA-2048 will be safe for the next thirty years. This is long-term security; as such, 2048-bit crypto is generally a good recommendation. Further, 2048-bit keys are small enough that they may be used in smart cards, mobile devices and embedded markets. Basically, RSA-2048 hits the sweet spot. But don't believe people who preach doom and gloom if you use RSA-1024. Although it's not sufficient for long-term security, it's plenty sufficient to dissuade anyone who doesn't have the resources of a First World government behind them. If you're worried about someone at your ISP reading your email to your girlfriend, RSA-1024 will do the job just fine. If you're worried about the Russian FSB reading your Vladimir Putin slashfiction that you're sending to people in Russia, you might want to use RSA-2048. :) > How can I find whats on my list? Werner has already given you the default list. It starts with AES-256. From dshaw at jabberwocky.com Tue Dec 17 19:37:03 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 17 Dec 2013 13:37:03 -0500 Subject: encryption algorithm In-Reply-To: <52B08CC8.8000009@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> Message-ID: On Dec 17, 2013, at 12:41 PM, Matt D wrote: > How can I find whats on my list? gpg --edit-key (thekey) showpref You can see your own, or anyone else's preference list that way. Note that each user ID (or photo ID) has its own preference list. David From dougb at dougbarton.us Tue Dec 17 19:40:21 2013 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 17 Dec 2013 10:40:21 -0800 Subject: Synchronize UID lists on public and private key -- how? In-Reply-To: <741976169.20131217130902@serebryakov.spb.ru> References: <741976169.20131217130902@serebryakov.spb.ru> Message-ID: <52B09A95.70108@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/17/2013 01:09 AM, Lev Serebryakov wrote: | Is it possible to synchronize UID list without transferring "new" version | of private key from B to A by external means? No. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSsJqVAAoJEFzGhvEaGryECOkIAKJKJukZ4HLvIynKN4Mkn3hs qL+/xy0Y/prO/cci5dfcm+eLCvoGe6YqZPaUfz9zdUH9H5DSSoip3T6UGOaqsxNS vnUBtdNT3lObHXVVYcLb2wrt0Y0Ae5/DyBjn8G3gZMh3+pXpHlgSYIEKCEGQoqXD GEMOVWPa98eaDRZungoi/AN0zR3dLWRYW9MW0hDiPvP9O+PRwZejv3LEsplBfEXq h9+VxjMGhPHCXY1SQ+YwbB1fUEw0Db1tnpJ0ty4s/Z2tCpSM9FCnK/qzPr7axh+h ZLIzCgtgLFrNbSPjA+bmrqW4ZXm32XCz6xqjmFcBgaVJMg4nJgW8oYVQFVUFw4w= =LFW3 -----END PGP SIGNATURE----- From dougb at dougbarton.us Tue Dec 17 19:41:19 2013 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 17 Dec 2013 10:41:19 -0800 Subject: Another step towards crowdfunding In-Reply-To: <52B0574A.4090206@gnupg.org> References: <20131214202738.27030@gmx.com> <52B0574A.4090206@gnupg.org> Message-ID: <52B09ACF.5060009@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/17/2013 05:53 AM, Sam Tuke wrote: | On 14/12/13 21:27, Zechariah Seth wrote: |> Will GnuPG blogs be cross-posted to the gnupg-users list? :) | | I could do that if others are happy with the idea. Any objections? Werner? How about a synopsis and URL instead? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSsJrPAAoJEFzGhvEaGryEgYsIAMWo04DbDikfgXUpVuXttfrg E/uv1cLinKb+m34gig6SCNz2arSZz2oU8Y8AAFXmI2sLdB5WFkzEtiQdhOjqH2uE KkfIrB3Qmzq/JyqR5gchxq/anDzta1KHGY/FoFQO726LKI7WXxkZmXUDeEgDpEOf 3YdA+HHSbpARCRdCKCWM235VJ9RjjgqHLInNB5SK2Roz4McZ9QMsIrlWGWNzsyBp t0gYiBGCJo6qLjkfJAxp1zOgfeXimeF2y05Gff3wI/heXBb1awc2hq2wTEJWVNKZ l6EMjCqw11brfK82D4VuHr7Sw8aKm4eDx/WcdRZGAK5kw+ofD+qdgVZb9etbVg8= =rd/6 -----END PGP SIGNATURE----- From md123 at nycap.rr.com Tue Dec 17 19:53:04 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 13:53:04 -0500 Subject: encryption algorithm In-Reply-To: References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> Message-ID: <52B09D90.2020300@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 01:37 PM, David Shaw wrote: > On Dec 17, 2013, at 12:41 PM, Matt D wrote: > >> How can I find whats on my list? > > gpg --edit-key (thekey) showpref > > You can see your own, or anyone else's preference list that way. > Note that each user ID (or photo ID) has its own preference list. > > David > > Thanks a bunch that was easy. So mine is 2048 with AES-256. So whats all the complaining about the defaults? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsJ2QAAoJECrdp7MWSIVbAJoH/jWq0x3nx7bNzgxN4ScAMP8Y 1/7XBEgWTVUk8RcL37EaLcIrEjH3jnfWijl367/kvNVLxLiX+3IlRfAuxsndyXAZ BBAKNOegr1pbfFQS0IlvmKEed0W1snFK7kOC5OxXyyrfm0gU9F6GNuFismSYkttH CV19q427hT6ct6ysiBth4wT3ixXU0SCMnQlYq4wax7u1NSI6zaTMPR+7S+ym1K2b DxQTD9OS1ufK+0PHmw7kpDr8klsLihHGDZ9Ca/CGaBEvgWlgP36HbXWKWTm4TowX jx3fMa9ev88o4iOdyicqU1scmra2GdyR2hpmwwWdVevDk5kPDla9m+F1XGYz5/s= =WTGi -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Dec 17 20:28:58 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 11:28:58 -0800 Subject: encryption algorithm In-Reply-To: <52B09D90.2020300@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> Message-ID: <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> > Thanks a bunch that was easy. So mine is 2048 with AES-256. So whats > all the complaining about the defaults? Well, yes and no. When you encrypt an email for someone else, two *different* preference lists are consulted. The first is found in gpg.conf (or, if it's not there, it uses default values). The second is found on your recipient's certificate. So if you're looking at the preference list on your own certificate, that doesn't tell you what algorithm you'll be using -- it only tells you what algorithms other people may use in their traffic to you. With respect to "all the complaining about the defaults": excellent damn question, and I wish I had the answer. From vedaal at nym.hush.com Tue Dec 17 20:40:12 2013 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 17 Dec 2013 14:40:12 -0500 Subject: please give us safer defaults for gnupg In-Reply-To: <52B08D84.5090906@riseup.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52B08D84.5090906@riseup.net> Message-ID: <20131217194013.E38E0C036A@smtp.hushmail.com> On Tuesday, December 17, 2013 at 12:49 PM, "adrelanos" wrote: >The person who agreed with me: >carlo von lynX > >Also the autor of "15 reasons not to start using PGP". [1] > >Cheers, >adrelanos > >[1] http://secushare.org/PGP ===== All of his reasons are easily countered. In the interests of time and space, I'll just address the following ones: 2. The OpenPGP Format: You might aswell run around the city naked. 3. Transaction Data: Mallory knows who you are talking to. 8. PGP conflates non-repudiation and authentication First, as a general approach to encryption and authentication, it's important to recognize that there are several levels why a user may want to encrypt and/or authenticate. The simplest level: [a] It's not really important, but it's nobody else's business either. This is equivalent to sending a message in an envelope rather than a post-card, except that in PGP, it's easier for users to confirm that the sender and the recipient are who they are, than in the case of snail-mail through an envelope, or ordinary e-mail. The next level: [b] It's important, and the sender stands behind the information, and is willing to have the receiver vouch for the signature or send it on with the signature intact, to whoever needs to take action on the information. A more serious level: [c] It's very important, and needs to be kept confidential as to who sent it, who received it, and needs repudiation as to who signed it. There are several ways that, with a little effort, open-pgp can be used to do this. Here is one suggestion: (i) The sender and receiver each generate a key of typical size (2048 or 4096) but do not ever post it to a key server. Instead they exchange it, either in person, or by having it posted encrypted to the intended recipient's key, using the throw-keyid option, to a website or newsgroup that allows encrypted postings. (The reason 'typical size' is mentioned, is that the throw-keyid option does not hide the 'size' of the key, so if you happen to be the only one on the internet who decided to generate a cool atypical key of 3693, it will be pretty obvious who is behind the message, even with the throw-keyid used. It's also possible for someone to intentionally 'frame' you for the message ;-) ). (ii) The sender and receiver also generate a separate signing key that they give to each other, that they can each use, and post it as in (i). (iii) Messages can now be signed with the key generated in (ii), hidden-encrypted to the key generated in (i), put on a small clean usb, and posted anonymously from a public place to the website or newsgroup, and then physically destroy the usb. Depending on how serious the requirements are, the more precautions need to be taken. i.e. generating and decrypting pgp messages only on a machine never connected to the internet and under physical security at all times; posting from different public wifi sites with different laptops, etc. depending on the threat model. To borrow from the racing car analogy used earlier in this thread: GnuPG provides an extremely high performance sturdy vehicle that can be used for ordinary shopping as well as high speed off road chases ... ;-) There are enough capabilities and workarounds in GnuPG, to do almost anything a user wants to do in terms of storing, sending or authenticating any messages or files. Thanks again, to WK and the GnuPG team. vedaal From anthony at cajuntechie.org Tue Dec 17 20:01:03 2013 From: anthony at cajuntechie.org (Anthony Papillion) Date: Tue, 17 Dec 2013 13:01:03 -0600 Subject: ECC curves used in gnupg? Message-ID: I know that gnupg is experimenting with ECC and I'm wondering which curves the team has decided to use. I know there are some curves that are now suspected of being tainted by the NSA through NIST. Has the gnupg team ruled using those curves out? Anthony -- Anthony Papillion XMPP/Jabber: cajuntechie at jit.si SIP: 17772471988 at callcentric.com iNum: +883-5100-01190960 PGP Key: 0xDC89FF2E From dshaw at jabberwocky.com Tue Dec 17 20:42:34 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 17 Dec 2013 14:42:34 -0500 Subject: encryption algorithm In-Reply-To: <52B09D90.2020300@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> Message-ID: On Dec 17, 2013, at 1:53 PM, Matt D wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/17/2013 01:37 PM, David Shaw wrote: >> On Dec 17, 2013, at 12:41 PM, Matt D wrote: >> >>> How can I find whats on my list? >> >> gpg --edit-key (thekey) showpref >> >> You can see your own, or anyone else's preference list that way. >> Note that each user ID (or photo ID) has its own preference list. >> >> David >> >> > Thanks a bunch that was easy. So mine is 2048 with AES-256. So whats > all the complaining about the defaults? Search me. The defaults are reasonable defaults. Of course, not everyone agrees :) David From wk at gnupg.org Tue Dec 17 20:58:24 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 20:58:24 +0100 Subject: gpgsm and encrypt-to In-Reply-To: <86d2kvfknp.fsf@informationelle-selbstbestimmung-im-internet.de> (Jens Lechtenboerger's message of "Tue, 17 Dec 2013 18:32:26 +0100") References: <86d2kvfknp.fsf@informationelle-selbstbestimmung-im-internet.de> Message-ID: <87k3f39rmn.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 18:32, cloudpg at informationelle-selbstbestimmung-im-internet.de said: > gpgsm has the option encrypt-to, which is not mentioned in the man > page. Is that option stable or might it disappear in the future? It is stable - just missing in the man page. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From md123 at nycap.rr.com Tue Dec 17 21:18:24 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 15:18:24 -0500 Subject: encryption algorithm In-Reply-To: <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> Message-ID: <52B0B190.5000206@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 02:28 PM, Robert J. Hansen wrote: >> Thanks a bunch that was easy. So mine is 2048 with AES-256. Lets assume the people I email have the same preferences. So how long, and at what cost would it take to brute force crack a captured message? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsLGQAAoJECrdp7MWSIVb1CQIAJb6C9Q4BoDAUezBoDXR5Agv tNi7NoEMc0r2wZGeARYGQSBQ+5dWO7wbkQsyFmQqlBc3gTE4QOtasJvjMeeqrQa5 lexz1Pk+Chk15zbkiQZAXcMm5x+BSsg/CoqnWWY8kciU6+SZjWIRMOXbdcgzli5l eTUkDRBKhNDkUCTlE4C2Abdeox9KbGlU+JtZ7+cn1xP40OLxnuBmnyx5cl5CW2Wo ibvGAX/jEmCNQXFc+8FUlFcTflcPXjC/MGQk64Q1Q5ApGiuwN+ajT1W2NAwsgTTg XVEg9h6/5QyIq99nfTX5JYgoogWSgSNQtPwZaxKccc4VT1vKVUUdluQfQLQDbvM= =VflP -----END PGP SIGNATURE----- From cr at rheloud.net Tue Dec 17 20:40:13 2013 From: cr at rheloud.net (C. Rossberg) Date: Tue, 17 Dec 2013 20:40:13 +0100 Subject: Another step towards crowdfunding In-Reply-To: <52B09ACF.5060009@dougbarton.us> References: <20131214202738.27030@gmx.com> <52B0574A.4090206@gnupg.org> <52B09ACF.5060009@dougbarton.us> Message-ID: <20131217194013.GA4693@teletypeIII> On Tue, 17 Dec 2013, Doug Barton wrote: > On 12/17/2013 05:53 AM, Sam Tuke wrote: > | On 14/12/13 21:27, Zechariah Seth wrote: > |> Will GnuPG blogs be cross-posted to the gnupg-users list? :) > | > | I could do that if others are happy with the idea. Any objections? Werner? > > How about a synopsis and URL instead? How about an RSS-Feed. This would be a nifty trade-off. Clients like newsbeuter, gnus, liferea already provide a somewhat 'summarized' view of the blogpost and would allow your favourite browser to show the whole article, provided that you want to read more. That creates traffic to the blog itself and points interested people to gnupg.org. Additionally, RSS offers the opportunity of syndication. Those who don't want to use a rss-client of its own or the rss-feature of their mail-client could still use a browser-plugin. The RSS-Feed could be archived via gmane/gwene. Yours //c -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Dec 17 21:21:20 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 21:21:20 +0100 Subject: X.509 certificates for https://gnupg.org In-Reply-To: <52B08F50.2050409@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 17 Dec 2013 12:52:16 -0500") References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <52AF6429.90201@fifthhorseman.net> <87k3f3bia0.fsf@vigenere.g10code.de> <52B08F50.2050409@fifthhorseman.net> Message-ID: <87fvpr9qkf.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 18:52, dkg at fifthhorseman.net said: > I think it depends on what flavor of IE you're using (and what version > of the underlying OS you're using as well). The version of schannel in Seems so. I updated my Windows 7 box to IE11 with no channel. Maybe I need to update more. Anywa IE11 seems to pretty new. > If you want to be able to support these systems, you may need to add a > low-priority "Lowest Common Denominator" ciphersuite to match them. > Sadly, that seems likely to be TLS_RSA_WITH_3DES_EDE_CBC_SHA, unless Okay, IE users are anyway on Windows. So why provide PFS for an OS that may have a direct path to Maryland anyway. > supported by XP's native TLS stack). I've never even tried to get a DSA > certificate for a web server from any member of the CA cartel. Have you? No. I recall that I tried to get a certificate for mail use to test my DSA code in gpgsm but I was not able to get one. The customer then dropped the DSA support from the requirements list. For web servers this should be possible - why else do they add those algorithms. After all that could be a selling point for an E+V certificate - if they could only find a new color. > lowest-common-denominator ciphersuite unless it's the only one they > support, you should probably set "SSLHonorCipherOrder 1" in your pound Did exactly that for the g10code site buy now. I'll fix the intermediate CAcert certifciate problem tomorrow. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Dec 17 21:22:42 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Dec 2013 21:22:42 +0100 Subject: gpgsm and trusted keys In-Reply-To: <868uvjfjhf.fsf@informationelle-selbstbestimmung-im-internet.de> (Jens Lechtenboerger's message of "Tue, 17 Dec 2013 18:57:48 +0100") References: <868uvjfjhf.fsf@informationelle-selbstbestimmung-im-internet.de> Message-ID: <87bo0f9qi5.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 18:57, cloudpg at informationelle-selbstbestimmung-im-internet.de said: > Is there a way to mark intermediate CAs as trusted so that all > certificates issued by them become usable? Sorry, there is currently no such way. The code always walks up to the root. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Tue Dec 17 21:34:10 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 12:34:10 -0800 Subject: please give us safer defaults for gnupg In-Reply-To: <20131217194013.E38E0C036A@smtp.hushmail.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52B08D84.5090906@riseup.net> <20131217194013.E38E0C036A@smtp.hushmail.com> Message-ID: <20131217123410.Horde.Okx1mA4mHosv-vJRq18xHg1@mail.sixdemonbag.org> > All of his reasons are easily countered. Looking over it, my impression is that his principal criticism is, "It is not all things to all people." To which my response is -- nothing in this world is, so why should OpenPGP be any different? OpenPGP provides a useful set of capabilities and tools, but if you need it to do something that it clearly doesn't then you need to look elsewhere. To return to the racing metaphor -- my Mustang GT is a hardtop. If I feel like putting the top down and enjoying the wind through my hair, I need to get a different car. This doesn't make my Mustang GT inferior or inadequate, nor does it mean I shouldn't drive my Mustang GT. It just means I need to acknowledge the fact my car is a hardtop. From dkg at fifthhorseman.net Tue Dec 17 21:57:54 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 15:57:54 -0500 Subject: encryption algorithm In-Reply-To: <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> Message-ID: <52B0BAD2.6000807@fifthhorseman.net> On 12/17/2013 01:22 PM, Robert J. Hansen wrote: > With respect to 2048-bit crypto, don't believe the hype. Most users and > most purposes will still be well-served with even a 1024-bit key. No > one with half a brain is going to bother trying to break RSA-1024; they > will instead come up with more effective ways of recovering your message. Sure, and so-called export ciphers for TLS are probably effective against the overwhelming majority of attackers too. But we recommend people disable export ciphers and prefer stronger algorithms, because the goal of cryptographic tools is to help as many people as possible, even when attacks are rare. so strong algorithms by default is a good idea. > But there are some people and some users who have a true need for > long-term security in their messages. The current recommendations of > NIST, ENISA, RSADSI and others is that RSA-2048 will be safe for the > next thirty years. I'm not sure how you get this claim from these reports, but that's not what it looks like to me. For example, ECRYPT 2012's report sees 2432-bit RSA as equivalent of 112 bit symmetric cipher, which it claims is acceptable for ?20 years. Please see section 7.2: http://www.ecrypt.eu.org/documents/D.SPA.20.pdf For ?30-year protection, the ECRYPT authors recommend the equivalent of 128-bit symmetric ciphers, which they say corresponds to 3248 bit RSA (see the table on page 30). So according to ECRYPT's recommendations from two years ago, the current GnuPG default RSA key size is above the "legacy standard level" (?10 years) but below "Medium Term protectsion" (? 20 years). > Further, 2048-bit keys are small > enough that they may be used in smart cards, mobile devices and embedded > markets. If you are generating a key whose private key will be stored on a smart card, you should clearly generate a key that will fit your smartcard. The smartcard does secret key work (decryption, signing). None of the public key operations (signature verification, encryption) will be done on the smartcard, so smartcard constraints need not be a concern there. So users of constrained devices can choose their own tradeoffs for secret-key operations (decryption, signing). What about public-key operations? For signature verification, an implementation on a constrained device that interacts with a human could simply defer signature validation until a human decides the tradeoff of verifying the signature is worth the computation cost. For encryption, users would need to be made aware of the costs of any additional message recipient. So I don't think constrained devices are a good argument for weaker default keys, though clearly the smartcard case is a good argument for gpg still being able to create and handle those keys. > But don't believe people who preach doom and gloom if you use RSA-1024. > Although it's not sufficient for long-term security, it's plenty > sufficient to dissuade anyone who doesn't have the resources of a First > World government behind them. According to ECRYPT 2012 (same report referenced above), RSA 1024 falls in at the equivalent of about 73 bits of symmetric cipher. According to the authors, this is "Short-term protection against medium organizations, medium-term protection against small organizations", not "a First World government". While i don't agree with adrelanos' entire draft, i do agree that the default key size for gpg should be larger. A default key size of 3072 or 4096 bits for RSA keys sounds reasonable to me. I also think that the default certificate digest algorithm should be SHA-256 instead of SHA-1 (see section 10.2 of the ECRYPT document above for reasons why we should deprecate the issuance of signatures over SHA-1). Users stuck with OpenPGP implementations unable to process SHA-256 that also rely critically on the network of identity certifications known as the "web of trust" (do such users actually exist? That intersection seems likely to be vanishingly small) may need to upgrade. Users who can't process SHA-256 certifications but willing to manually indicate which keys are valid manually/locally (or who manage a "trusted" keyring) should still be able to carry on as before. We do not do the users of GnuPG any favors by continuing to generate weaker-than-expected keys and certifications by default. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Tue Dec 17 22:15:01 2013 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 17 Dec 2013 13:15:01 -0800 Subject: Another step towards crowdfunding In-Reply-To: <20131217194013.GA4693@teletypeIII> References: <20131214202738.27030@gmx.com> <52B0574A.4090206@gnupg.org> <52B09ACF.5060009@dougbarton.us> <20131217194013.GA4693@teletypeIII> Message-ID: <52B0BED5.8060404@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/17/2013 11:40 AM, C. Rossberg wrote: | How about an RSS-Feed. | | This would be a nifty trade-off. I thought an RSS feed would be a given. I was responding to the idea of sending the posts directly to the list. No reason not to do both IMO. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSsL7VAAoJEFzGhvEaGryEDCIIALHmXNnJilbFOC+GWkIpJ6lk Je1artdYtzGw1c3hJKF7XPsInGeMDFQahVG3ekUMAFiOfi1ab5+rJsCg1B9v7IcT oQEIu2gt59YXGhC9GydhewZL9uyIfmgUpa/dZGrugAO3fei0O3qCavVZ6NyKQun7 TPtPQ9F9S6pcDhhdDIA4NFLpaoPGv5UVqcZl2qbHaxTo5dPXgERtrVE4wEOAHzj6 008OkuGahzl7zGWo2sGMCeXpSDxKusX3zKz5RCLoN2lgHRBo3dUObm0RJyr4w7Lr QPBA7Ea2tMhIWiZ9p42TSSJtemWuWn57XxjWUEf2pDPpnjEfExl9QPRs733NW80= =vRTe -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Tue Dec 17 22:31:40 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 17 Dec 2013 22:31:40 +0100 Subject: encryption algorithm In-Reply-To: <52B0BAD2.6000807@fifthhorseman.net> References: <52AF3A55.7080800@riseup.net> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> Message-ID: <4597548.jYQYFaWSU4@inno.berlin.laging.de> Am Di 17.12.2013, 15:57:54 schrieb Daniel Kahn Gillmor: > RSA 1024 falls > in at the equivalent of about 73 bits of symmetric cipher. According to > the authors, this is "Short-term protection against medium > organizations, medium-term protection against small organizations", not > "a First World government". > > While i don't agree with adrelanos' entire draft, i do agree that the > default key size for gpg should be larger. A default key size of 3072 > or 4096 bits for RSA keys sounds reasonable to me. > We do not do the users of GnuPG any favors by continuing to generate > weaker-than-expected keys and certifications by default. There are non-technical arguments against your position. No, Rob, I don't have a scientific study for that but I guess (and invite everyone to follow mw with this) that using something above the minimum but below the maximum serves an educational purpose. I believe there is a broad agreement that you need to *learn* what good crypto is (involving the whole process containing crypto, not just the small crypto element) to get "security". One more wild guess: 99.9% of the systems on which GnuPG is *actively* used do not even provide the "equivalent" of a 73-bits key. If the 99.9% get 2048 bit by default then they ask: "Why not more?" That can be kind of annoying here but at least they ask and get told. And some probably understand. That's a security gain. If they notice "I have maximum security now" because the default is raised to 4096 then they will not ask but often make stupid assumptions about their overall security. Effective use of crypto mandatorily demands for some understanding. It is trivial for everyone with this understanding to select the key size. So what real-world problem is going to be solved here? And what could be the "expected key strength" for users with no clue about crypto? I support dkg with respect to the digests, though. And I think that GnuPG really needs an option like personal-digest-disallow. Sende-recipient negotiation all well and good, but it must be possible to say: Not me! Even against the RfC. With such a command line option an application can easily limit that to certain cases (though the validity calculations must be configured globally, of course). We should not expect the applications to filter disallowed digests. Often the crypto knowledge of application developers is limited. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Tue Dec 17 22:54:00 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 13:54:00 -0800 Subject: encryption algorithm In-Reply-To: <52B0B190.5000206@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> Message-ID: <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> > Lets assume the people I email have the same preferences. So how > long, and at what cost would it take to brute force crack a captured > message? [sigh] Not this again. I get very tired of answering this question. The Second Law of Thermodynamics puts a minimum energy requirement on how much energy it takes to change the state of a bit. That's given by kT ln 2, or on the order of 10**-23 joules. You want to exhaust keys in random order, because otherwise it would give the defender an easy way to make things hard for you: just use a key that's close to the end of your search order. By exhausting random keys you foil that defense. Between setting and clearing registers on the CPU, loading instructions into memory and so on, let's say that each rekeying operation takes 10,000,000 bits (10**7) being changed. (That's a wildly optimistic number, incidentally.) Finally, 2**255 (the average number of keys you'll have to exhaust) is about 10**77. 10**77 keys * 10**7 bitflips per rekeying * 10**-23 joules per bitflip equals... 10**61 joules of energy. A supernova releases 10**44 joules of energy. You'll need 10**17 of them just to power the computer to brute-force a 256-bit cipher. The Milky Way has about 10**11 stars; you'll need about 60 galaxies to go supernova all at once. This turns out to be about the same size as the Virgo Supercluster, which is the region of the universe the Milky Way is in. The amount of energy we're talking about here is so large there is a non-zero chance it would disturb the false vacuum of spacetime and annihilate the cosmos. People always seem to ask me if I'm making these numbers up. No, I am not, nor am I joking. No one will ever. Ever. Brute-force a 256-bit cipher. From rjh at sixdemonbag.org Tue Dec 17 23:04:08 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 14:04:08 -0800 Subject: encryption algorithm In-Reply-To: <52B0BAD2.6000807@fifthhorseman.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> Message-ID: <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> > so strong algorithms by default is a good idea. Yes, which is why RSA-2048 is recommended. I don't understand the reasoning by which you have concluded that I am advocating RSA-1024. I'm not. I think the default of RSA-2048 is a good one. I'm only saying that for most users and most purposes, RSA-1024 is sufficient; to reach "virtually all users" and "virtually all purposes" we have to move to RSA-2048. > I'm not sure how you get this claim from these reports... Simple: I'm human and I misremembered NIST's "secure until 2030" as "secure for 30 years". :) > what it looks like to me. For example, ECRYPT 2012's report sees > 2432-bit RSA as equivalent of 112 bit symmetric cipher, which it claims > is acceptable for ?20 years. Please see section 7.2: NIST's guidance says 2048-bit RSA is equivalent to 112 bits of symmetric cipher, as does ENISA and RSADSI. ECRYPT is certainly free to come up with their own metric; they're a competent outfit. But let's acknowledge that ECRYPT's opinion is a minority one, rather than cherry-pick an outlier opinion and declare it to be authoritative. > According to ECRYPT 2012 (same report referenced above), RSA 1024 falls > in at the equivalent of about 73 bits of symmetric cipher. According to > the authors, this is "Short-term protection against medium > organizations, medium-term protection against small organizations", not > "a First World government". NIST puts it in at 80 bits. Let's not forget how long it took the RC5-64 project to exhaust a 64-bit key. Can it be broken? Sure. Easily? No. If you're worried about Google being able to mine your message for targeted ads, that's plenty enough. If you're worried about your local sysadmin reading your personal mail, that's plenty enough. If you're sending Vladimir Putin slashfic to a Russian publisher, maybe you should rethink using such a short key. > While i don't agree with adrelanos' entire draft, i do agree that the > default key size for gpg should be larger. Yes. You've made this opinion abundantly clear many times. From rjh at sixdemonbag.org Tue Dec 17 23:08:38 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 14:08:38 -0800 Subject: encryption algorithm In-Reply-To: <4597548.jYQYFaWSU4@inno.berlin.laging.de> References: <52AF3A55.7080800@riseup.net> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <4597548.jYQYFaWSU4@inno.berlin.laging.de> Message-ID: <20131217140838.Horde.rxknGFmm4addk1Pddt6KTA2@mail.sixdemonbag.org> Quoting Hauke Laging : > element) to get "security". One more wild guess: 99.9% of the > systems on which GnuPG is *actively* used do not even provide the > "equivalent" > of a 73-bits key. This is almost certainly true. A couple of years ago Vint Cerf estimated that somewhere between a sixth and a quarter of all desktop PCs were infected with remote-root malware. The odds are quite high that your desktop PC running GnuPG provides *zero* bits of security. Sobering thought. Really, all the obsession over key lengths does is distract us. Pick a keylength, be done with it, and then start paying attention to more important things... From chd at chud.net Tue Dec 17 23:09:39 2013 From: chd at chud.net (Chris De Young) Date: Tue, 17 Dec 2013 15:09:39 -0700 Subject: encryption algorithm In-Reply-To: <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> Message-ID: <52B0CBA3.60708@chud.net> On 12/17/2013 2:54 PM, Robert J. Hansen wrote: > > The amount of energy we're talking about here is so large there is a > non-zero chance it would disturb the false vacuum of spacetime and > annihilate the cosmos. Well, probably not - because in order to apply this energy to your brute-force calculation process you presumably have some way of capturing it, thereby making it unavailable for use in the destruction of the cosmos. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Dec 17 23:31:52 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 14:31:52 -0800 Subject: encryption algorithm In-Reply-To: <52B0CBA3.60708@chud.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0CBA3.60708@chud.net> Message-ID: <20131217143152.Horde.0beusNvZy6FsfO1BI_PwpA1@mail.sixdemonbag.org> > Well, probably not - because in order to apply this energy to your > brute-force calculation process you presumably have some way of > capturing it, thereby making it unavailable for use in the destruction > of the cosmos. :-) Nope! That thermodynamic analysis is how much heat you have to dump in the universe. (Well, entropy, actually, but to a first approximation that's the same thing.) For more details, check Wikipedia's writeup on the Landauer bound: http://en.wikipedia.org/wiki/Landauer%27s_principle So, yeah, it really is as catastrophic as I make it out to be. :) From micah at micahflee.com Wed Dec 18 00:01:43 2013 From: micah at micahflee.com (Micah Lee) Date: Tue, 17 Dec 2013 15:01:43 -0800 Subject: Another step towards crowdfunding In-Reply-To: <87eh5bd9q6.fsf@vigenere.g10code.de> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <87eh5bd9q6.fsf@vigenere.g10code.de> Message-ID: <52B0D7D7.90609@micahflee.com> On 12/17/2013 02:59 AM, Werner Koch wrote: > Well, bowsers could first try to use https. Would it help them to provide > a SRV record for this? The reason is because people often have different websites running on port 443 than they do on port 80, and people also often have non-browser-trusted certs. For a prime example, check these two: https://www.theguardian.com/ http://www.theguardian.com/ If the browser tried https first, everything would would break, not to mention if you click through the cert warning you just get a generic "The page cannot be displayed" error page. This is why HTTPS Everywhere needs thousands of intricate rulesets to maximize the number of HTTPS requests, and do things like make cookies use the secure flag. >> If you want to fix this, you could make all incoming http traffic >> respond with a 301 redirect to https. > > I am not sure whether this helps. If we eventually offer http download > we could use https: fro that instead. There is also a plan for provided > a hidden tor service. I think it would help. There's no reason that security software should serve anything over port 80 besides 301 redirects to port 443. > I hesitate to pay the highwaymen. Yeah... The problem is you're wanting to make GnuPG go mainstream but then you end up with people seeing this: http://i.imgur.com/53nvUqm.png -- Micah Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From micah at micahflee.com Wed Dec 18 00:12:43 2013 From: micah at micahflee.com (Micah Lee) Date: Tue, 17 Dec 2013 15:12:43 -0800 Subject: X.509 certificates for https://gnupg.org In-Reply-To: <87ioundc9g.fsf@vigenere.g10code.de> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <52AF6429.90201@fifthhorseman.net> <52AFBF70.4060209@micahflee.com> <87ioundc9g.fsf@vigenere.g10code.de> Message-ID: <52B0DA6B.8040607@micahflee.com> On 12/17/2013 02:04 AM, Werner Koch wrote: > You must be running with JavaScript enabled ;-). This seems to be from > Piwik, which I recently installed to gather web statistics. I am not > really happy with that but my campaign manager said that it is really > needed and that organization like the EFF also run Piwik. I actually set up EFF's Piwik. :) If you're interested, there are a couple ways to make it less privacy invasive (though just using it instead of a centralized thing like Google Analytics is great). You can not include the Piwik code at all just use it to visualize your server logs, using the script misc/log-analytics/import_logs.py. More details about this method here: http://piwik.org/docs/log-analytics-tool-how-to/ The other way is to only include the image tracker but not the javascript tracker. e.g. You can pass other data to Piwik in this method as well (like page title) but it doesn't use javascript, so it's less intrusive: http://developer.piwik.org/api-reference/tracking-api -- Micah Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From adrelanos at riseup.net Wed Dec 18 01:02:44 2013 From: adrelanos at riseup.net (adrelanos) Date: Wed, 18 Dec 2013 00:02:44 +0000 Subject: please give us safer defaults for gnupg In-Reply-To: <20131217194013.E38E0C036A__36887.2711937458$1387309300$gmane$org@smtp.hushmail.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52B08D84.5090906@riseup.net> <20131217194013.E38E0C036A__36887.2711937458$1387309300$gmane$org@smtp.hushmail.com> Message-ID: <52B0E624.2020008@riseup.net> vedaal at nym.hush.com: > On Tuesday, December 17, 2013 at 12:49 PM, "adrelanos" wrote: > >> >The person who agreed with me: >> >carlo von lynX >> > >> >Also the autor of "15 reasons not to start using PGP". [1] >> > >> >Cheers, >> >adrelanos >> > >> >[1] http://secushare.org/PGP > ===== > > All of his reasons are easily countered. I don't want to discuss them here in this thread to avoid distraction. My topic: "please give us safer defaults for gnupg" I only provided that as a reference so you're sure which one I am talking about should there be multiple persons with that name. From dkg at fifthhorseman.net Wed Dec 18 01:07:42 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 19:07:42 -0500 Subject: encryption algorithm In-Reply-To: <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> Message-ID: <52B0E74E.3080206@fifthhorseman.net> On 12/17/2013 05:04 PM, Robert J. Hansen wrote: > I don't understand the reasoning by which you have concluded that I am > advocating RSA-1024. I'm not. I think the default of RSA-2048 is a > good one. I'm only saying that for most users and most purposes, > RSA-1024 is sufficient; to reach "virtually all users" and "virtually > all purposes" we have to move to RSA-2048. I never attributed RSA-1024 to you: i'm merely pointing out that good enough for "virtually all users" and "virtually all purposes" is the wrong way to select choices that we want to cover the most vulnerable targets. >> I'm not sure how you get this claim from these reports... > > Simple: I'm human and I misremembered NIST's "secure until 2030" as > "secure for 30 years". :) Thanks for the clarification. I get this sort of thing screwed up myself sometimes too, so i'm glad to be the one setting the record straight for once :) >> what it looks like to me. For example, ECRYPT 2012's report sees >> 2432-bit RSA as equivalent of 112 bit symmetric cipher, which it claims >> is acceptable for ?20 years. Please see section 7.2: > > NIST's guidance says 2048-bit RSA is equivalent to 112 bits of symmetric > cipher, as does ENISA and RSADSI. ECRYPT is certainly free to come up > with their own metric; they're a competent outfit. But let's > acknowledge that ECRYPT's opinion is a minority one, rather than > cherry-pick an outlier opinion and declare it to be authoritative. ECRYPT has some pretty decent conceptual frameworks, engineering, and mathematics to explain how they arrived at their strength equivalences. Chapter 6 has details. None of us can predict where the mathematical advances will happen next, of course, but these are hardly arbitrary "opinions" pulled from thin air. Arguably, it's probably also worth being more skeptical about guidance coming from NIST specifically, since they are known to have taken advice from the NSA, and the NSA is now known to have deliberately misused NIST's position of trust. This is a bad situation, but Werner's earlier line today about "a direct line to Maryland" seems apposite. If you're into figuring out which is the "outlier opinion" and assessing these things by conensus of authorities, i invite you to look at table 3.1 on page 22 of the ENISA algorithm report. NIST and SECG equate 112 to 2048-bit RSA. Lenstra and the IETF (RFC 3766) and ECRYPT all suggest that 2048-bit RSA is weaker than 112-bit symmetric ciphers. NIST and SECG (in which NIST played a prominent role) hold down the low end of the scale. Regardless of which group is "right", none of these authorities believe that 2048-bit RSA is in the range of a 128-bit symmetric cipher, just 112-bits at most. Do we care about the idea that a cryptosystem is as secure as its weakest link? I note that we don't generally support any symmetric ciphers with less than a 128-bit key (3DES with keying option 2 would use 112-bits -- but GnuPG uses keying option 1: 168 bits, derived from 192 bits). If we want to "even out" the crypto so that no one part is clearly weaker to attack than the others, we ought to to increase our RSA keylengths by default. RSA keys are currently the weakest link according to any of the authorities anyone has cited in this discussion thus far. Additionally, since breaking a long-term asymmetric key can effectively decrypt all messages encrypted to that key, breaking the RSA key has more value to an attacker than breaking any single symmetric cipher. So if there is going to be a strength difference, i'd expect it the other way around. A reasonable hybrid cryptosystem like OpenPGP should make the asymmetric part *stronger* than the symmetric part, since it presumably is a more valuable target anyway. Finally, in the face of adversaries who possess incremental (not catastrophic) mathematical or computational advances beyond what we know about, increasing keylength beyond what we think is strictly needed is a reasonable defense. In https://www.schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html Schneier writes: "it's pretty easy to stay a few steps ahead of the NSA by using ever-longer keys. We're already trying to phase out 1024-bit RSA keys in favor of 2048-bit keys. Perhaps we need to jump even further ahead and consider 3072-bit keys." The next day, Schneier announced his new 4096-bit RSA key: https://www.schneier.com/blog/archives/2013/09/my_new_gpgpgp_a.html Do we want the asymmetric key length to be the weakest link for users of GPG's default choices? > Can it be broken? Sure. Easily? No. If you're worried about Google > being able to mine your message for targeted ads, that's plenty enough. > If you're worried about your local sysadmin reading your personal mail, > that's plenty enough. If you're sending Vladimir Putin slashfic to a > Russian publisher, maybe you should rethink using such a short key. I think i've made it abundantly clear that i don't think it's trivial for anyone to break a 2048-bit key. My arguments here are not about protecting my e-mail contents from a hobbyist attack. I'm interested in trying to build cryptographic defenses against powerful adversaries. While we the systems programmers are choosing default key sizes for the overwhelming majority of users, we could put the onus on those who need *less* security (due to constrained devices or terribly-old interoperability concerns) to explicitly weaken their own tools, rather than requiring people who need stronger security to become cryptographic experts and figure out what needs to be done. If someone is choosing to use OpenPGP to secure their messaging or data, whether for confidentiality, integrity, or authenticity, the tools should offer strong security choices against powerful attackers, by default. The other two objections to stronger defaults that have been raised in on this list today are: 0) the cryptosystem isn't the weakest link for most people, and 1) we don't want huge keys because they're inefficient (0) is clearly true, and it *should remain true*. That's the whole point of using cryptography, not to leave open the possibility that someone who happens to have more compute power or better math can decrypt your messages or impersonate you without bothering to do any of the other stuff. That is, the security of my data should depend on my operational security, *not* on my cryptography. The cryptography should be standard, background stuff. So (0) is not an effective argument for why we should have default public key lengths that are widely acknowledged to be weaker than the symmetric keys we routinely use. The goal is to avoid having the math be the weakest link, for any potential attacker. As for (1), i'd find it easier to accept claims about efficiency and performance concerns if gpg was plausibly efficient or high-performance in other realms. Two obvious areas come to mind where efficiency and performance have not historically been a priority for gpg: key selection from even medium-sized keyrings, and the programmatic use of gpg as a backend to other tools. GPG's subprocess model, coupled with its need to do linear scans of a key ring each time any asymmetric mechanism is triggered leads to seriously low performance in many contexts. The performance difference between, say, a single 2048-bit RSA operation and a 3072-bit RSA operation (NIST's 128-bit-equivalent) is small compared to the cost of pulling the keyring off the disk, parsing all the keys, selecting the right(?) key, evaluating the trust model, etc. If it's worth arguing that 3072-bit is too expensive to be the default, then we probably need major work in giving gpg a plausible library (not subprocess) interface or proper indexed key storage (which i hear is coming for 2.1, and i'm quite happy about that, though i have yet to get to play with it). GnuPG and gcrypt's underlying crypto primitive code has also never been the fastest code, even among the free software variants available, and Werner has (rightly, i think) typically declined to prioritize speed over other development goals (like information security). I'm excited to see the recent speed improvements in gcrypt, though. As gcrypt's speed improves, maybe we can take advantage of the faster speeds to switch to stronger asymmetric keys and message digests by default as well? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Wed Dec 18 01:10:03 2013 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 17 Dec 2013 16:10:03 -0800 Subject: Another step towards crowdfunding In-Reply-To: <52B0D7D7.90609@micahflee.com> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <87eh5bd9q6.fsf@vigenere.g10code.de> <52B0D7D7.90609@micahflee.com> Message-ID: <52B0E7DB.3060008@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/17/2013 03:01 PM, Micah Lee wrote: |> I hesitate to pay the highwaymen. | Yeah... | | The problem is you're wanting to make GnuPG go mainstream but then you | end up with people seeing this:http://i.imgur.com/53nvUqm.png +1 I've made the same point before, at least once. I hate to repeat myself, but a real SSL cert really is the way to go here. CAcert is charming and all, but we do not want to encourage people to click past the "untrusted" warning, and there is more than ample evidence that users generally, particularly users who are new to cryptography, lack the requisite knowledge to make good decisions about if/when to do so. I have no connection to StartSSL other than "satisfied non-paying 'customer'" but they do the trick, and the price is right. There are other free options as well, as was pointed out here recently. It doesn't matter to me which one y'all choose, but please, choose one and let's move on. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSsOfbAAoJEFzGhvEaGryEvQoIAIpJiIIIGpESo8LAevjbc4Ml I7YjQclJ0+OWaZmwKmzpTTzKRM9q/Z0TV9bYV9vRTOMiQL1GwTpVMQ7hE1pHgwQ/ Vsw0fy+HkX6F+RPyc1XFxuHtiBPr1kcVSz508PgfCQjzdmozsbdRHDwvhd+vQZKX vHbTBotobiRH9f8qrA5fimmeuUxQT2E0Ha5XMWTXmgTdb9xj3QvKP5pDCnTcT6kh sIZk4CqIOLpCqaJ1dbTUa9LlpCcOUsPSMF33DSVQMxg1l8AP6I5DE/pQmzwYiKvR qNBc6mbS+/9ZfhTumQXg3FOJ8ksj4+DHhMWKX0pV8O9BmmSbTaiI2B+ZXNvnxrM= =UPRn -----END PGP SIGNATURE----- From md123 at nycap.rr.com Wed Dec 18 01:48:29 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 19:48:29 -0500 Subject: encryption algorithm In-Reply-To: <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> Message-ID: <52B0F0DD.9030706@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 04:54 PM, Robert J. Hansen wrote: >> Lets assume the people I email have the same preferences. So >> how long, and at what cost would it take to brute force crack a >> captured message? > > [sigh] > > Not this again. I get very tired of answering this question. > > The Second Law of Thermodynamics puts a minimum energy requirement > on how much energy it takes to change the state of a bit. That's > given by kT ln 2, or on the order of 10**-23 joules. > > You want to exhaust keys in random order, because otherwise it > would give the defender an easy way to make things hard for you: > just use a key that's close to the end of your search order. By > exhausting random keys you foil that defense. Between setting and > clearing registers on the CPU, loading instructions into memory and > so on, let's say that each rekeying operation takes 10,000,000 bits > (10**7) being changed. (That's a wildly optimistic number, > incidentally.) > > Finally, 2**255 (the average number of keys you'll have to exhaust) > is about 10**77. > > 10**77 keys * 10**7 bitflips per rekeying * 10**-23 joules per > bitflip equals... 10**61 joules of energy. > > A supernova releases 10**44 joules of energy. You'll need 10**17 > of them just to power the computer to brute-force a 256-bit cipher. > The Milky Way has about 10**11 stars; you'll need about 60 galaxies > to go supernova all at once. This turns out to be about the same > size as the Virgo Supercluster, which is the region of the universe > the Milky Way is in. > > The amount of energy we're talking about here is so large there is > a non-zero chance it would disturb the false vacuum of spacetime > and annihilate the cosmos. > > People always seem to ask me if I'm making these numbers up. No, I > am not, nor am I joking. > > No one will ever. Ever. Brute-force a 256-bit cipher. what about the 2048-bit DSA part of it? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsPDdAAoJECrdp7MWSIVbcdkH/ReJxrw76Vdx/cSVJFY20sGg OcH8hmdrB4gOCrvt1SJj3KiRl0bTgZyLkEpWR2UT3x4Zvd9Kni0gRsXSyNR6AlcE SCSIPOgDxeiWRWIuNSaRn9MBlzmpPnKWyECgeQ4S5HnDbZS+dApme+7AOZM54tm6 XPG57Ii2giUV6gmOdF0xMAt0uHd56hkoO09IYfkvbF4Vsk8vS4a0JCpCFzD4uaVa R007MRRUvTfmoukGoiaIC3315ZhQZHbN5jK4LRia02Zoy6t6dAjkInC+Y4aiE0pb 6nUiDg4s7dGzLUBfwsUqhcZ3/1Kr3MU6pLKsHOz4azP/u42DOjvQ9cvWvlqQN3A= =CUTC -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Dec 18 02:07:21 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 20:07:21 -0500 Subject: encryption algorithm In-Reply-To: <52B0F0DD.9030706@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0F0DD.9030706@nycap.rr.com> Message-ID: <52B0F549.9090707@sixdemonbag.org> > what about the 2048-bit DSA part of it? Search the list archives, please -- this question has been asked and answered a great number of times. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Dec 18 02:27:13 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 20:27:13 -0500 Subject: encryption algorithm In-Reply-To: <52B0E74E.3080206@fifthhorseman.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> Message-ID: <52B0F9F1.7020705@sixdemonbag.org> > I never attributed RSA-1024 to you: i'm merely pointing out that > good enough for "virtually all users" and "virtually all purposes" is > the wrong way to select choices that we want to cover the most > vulnerable targets. Perhaps: but that's not what I was responding to. The original poster was asking why "people" (unspecified people) said to never use anything less than 2048-bit asymmetric crypto. My answer was that "people" were wrong, and that what is needed for a particular environment needs to be evaluated on a case-by-case basis. I agree that RSA-2048 is a sensible default, but I don't see how that's relevant to the thing I was discussing. Did I miss a topic shift somewhere? > ECRYPT has some pretty decent conceptual frameworks, engineering, > and mathematics to explain how they arrived at their strength > equivalences. As do NIST, RSADSI, ENISA and others. I agree they are a highly professional outfit, but this makes them just one of many. > Arguably, it's probably also worth being more skeptical about > guidance coming from NIST specifically, since they are known to have > taken advice from the NSA... I have mixed feelings on this. On the one hand, I fully concur that there are some troubling possibilities there; on the other hand, it's too easy to fall down the hole of paranoia and wind up mistrusting everything and completely wreck your life. For myself (and this is purely my opinion), I believe NIST is still reliable. If there's evidence of tampering with a particular standard I think that standard should be revisited and distrusted, but I think it's a stretch to say we should distrust all things NIST for no other reason than it's conceptually possible that a given specification, recommendation, etc., has been tampered with. > This is a bad situation... Agreed. > Regardless of which group is "right", none of these authorities > believe that 2048-bit RSA is in the range of a 128-bit symmetric > cipher, just 112-bits at most. Do we care about the idea that a > cryptosystem is as secure as its weakest link? Yes -- but no one is claiming that 112-bit keyspaces are vulnerable today, or at any time within the near future. Further, moving to a 128-bit keyspace is not, IMO, any sort of a real win: you're only gaining 16 bits of keyspace. At most you're pushing things back for a few years; it is not any kind of a long-term solution. > I note that we don't generally support any symmetric ciphers with > less than a 128-bit key (3DES with keying option 2 would use 112-bits > -- but GnuPG uses keying option 1: 168 bits, derived from 192 bits). Still a 112-bit keyspace, assuming the attacker has effectively unlimited computational resources. > If we want to "even out" the crypto so that no one part is clearly > weaker to attack than the others, we ought to to increase our RSA > keylengths by default. Whoa there a second! You might want to backspace and overstrike that, because you just shifted to arguing that "since GnuPG defaults to AES-256, we need to use RSA-15000 by default otherwise the asymmetric portion will clearly be weaker to attack than the others." We don't want to even out the cryptosystem. We want to ensure that each component of the cryptosystem meets or exceeds our minimum standards for cryptanalytic resistance -- but the notion of "evening out" the system is, as near as I can tell, fashionable nonsense. > way around. A reasonable hybrid cryptosystem like OpenPGP should > make the asymmetric part *stronger* than the symmetric part, since > it presumably is a more valuable target anyway. So, RSA-30000, then? > The next day, Schneier announced his new 4096-bit RSA key: A good bit prior to his death, I asked Len Sassaman why he had a 4096-bit RSA key when he privately mocked them as being key-length fetishism. "Because it isn't just about what I think of them," he told me: "it's because of what *other people* think of them. There are a lot of people in the world who mistakenly think anything less is insecure. They might have something to say which I'd like to hear, and I can't if I only have a 2048-bit key." Or something like that, something similar -- it's been a few years. I understand Len's point of view. I just think it's bad policy. I think we should not cater to key-length fetishism. > Do we want the asymmetric key length to be the weakest link for users > of GPG's default choices? Unless we move to RSA-15000, it will be. > As gcrypt's speed improves, maybe we can take advantage of the faster > speeds to switch to stronger asymmetric keys and message digests by > default as well? So far in this thread I have not been giving my own opinion on things: I've been trying to explain the reasoning that has gone into the current state of things. Permit me to share my own opinion for a moment. :) I agree that a stronger asymmetric component would be nice, but I don't believe RSA is the way to go. We're already on the brink of introducing ECC support into GnuPG. I think that once ECC support is introduced in the mainline, it will then be an appropriate time to revisit the question. I would support shifting to stronger asymmetric component(s) at that time, but I don't think it's worth the headache of changing the defaults if we're just going to change them *again* in under a year. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From micah at micahflee.com Wed Dec 18 02:45:43 2013 From: micah at micahflee.com (Micah Lee) Date: Tue, 17 Dec 2013 17:45:43 -0800 Subject: Another step towards crowdfunding In-Reply-To: <52B0E7DB.3060008@dougbarton.us> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <87eh5bd9q6.fsf@vigenere.g10code.de> <52B0D7D7.90609@micahflee.com> <52B0E7DB.3060008@dougbarton.us> Message-ID: <52B0FE47.5010509@micahflee.com> On 12/17/2013 04:10 PM, Doug Barton wrote: > I have no connection to StartSSL other than "satisfied non-paying > 'customer'" but they do the trick, and the price is right. There are > other free options as well, as was pointed out here recently. It doesn't > matter to me which one y'all choose, but please, choose one and let's > move on. Another argument for doing this. The centralized public key infrastructure is badly flawed, but if you do have a cert that's signed by a CA that Firefox and Chromium trust you get added to the HSTS preload lists for those browsers. Here's a bit about what HSTS is: https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security Chromium (and by extension Chrome) ships with a list of websites that are preloaded with HSTS. Here info about getting in the Chromium list: http://www.chromium.org/sts (specifically, email Adam Langley at agl at chromium.org). Here's Firefox's feature definition for it's HSTS preload list: https://wiki.mozilla.org/Privacy/Features/HSTS_Preload_List I don't know what the policy is to get on their list, but Firefox currently ships with it: https://mxr.mozilla.org/mozilla-central/source/security/manager/boot/src/nsSTSPreloadList.inc So my guess is just open a bug asking for gnupg.org to get added. As far as I know these preload lists only force HTTPS for these domains. I wonder if anyone could convince the browser vendors to also do certificate pinning, bypassing PKI based on CAs altogether? -- Micah Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 866 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Dec 18 02:53:12 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 20:53:12 -0500 Subject: encryption algorithm In-Reply-To: <52B0E74E.3080206@fifthhorseman.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> Message-ID: <52B10008.10607@sixdemonbag.org> > I never attributed RSA-1024 to you: i'm merely pointing out that good > enough for "virtually all users" and "virtually all purposes" is the > wrong way to select choices that we want to cover the most vulnerable > targets. Sorry for the double response -- I thought I'd included this in my previous mail, but I didn't. I am not in favor of covering more than 'virtually all users' and 'virtually all purposes.' The difference between 99% of GnuPG's users and 100% of GnuPG's users is, first of all, impossible to close, and second of all, requires ever-increasing expense just to approximate it. Phil Z. designed PGP to be Pretty Good Privacy. Not perfect... just pretty good. GnuPG is quite clearly built in the same vein. "Virtually all" is the right way to select defaults. The next step beyond "virtually all" is "all." We can't achieve that and it's foolish to try. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Dec 18 03:20:49 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 21:20:49 -0500 Subject: encryption algorithm In-Reply-To: <52B0F9F1.7020705@sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> <52B0F9F1.7020705@sixdemonbag.org> Message-ID: <52B10681.1030701@fifthhorseman.net> On 12/17/2013 08:27 PM, Robert J. Hansen wrote: > Yes -- but no one is claiming that 112-bit keyspaces are vulnerable > today, or at any time within the near future. Further, moving to a > 128-bit keyspace is not, IMO, any sort of a real win: you're only > gaining 16 bits of keyspace. At most you're pushing things back for a > few years; it is not any kind of a long-term solution. from ?20 years to ?30 years, if we believe ECRYPT. Of course it's not a forever solution. It's still a significant improvement, and its one we can afford. >> If we want to "even out" the crypto so that no one part is clearly >> weaker to attack than the others, we ought to to increase our RSA >> keylengths by default. > > Whoa there a second! You might want to backspace and overstrike that, > because you just shifted to arguing that "since GnuPG defaults to > AES-256, we need to use RSA-15000 by default otherwise the asymmetric > portion will clearly be weaker to attack than the others." > > We don't want to even out the cryptosystem. We want to ensure that each > component of the cryptosystem meets or exceeds our minimum standards for > cryptanalytic resistance -- but the notion of "evening out" the system > is, as near as I can tell, fashionable nonsense. sigh. "weakest link" analysis is clearly useful, and just as clearly not the only analytic tool to use. I argued: right now gpg's weakest links are the default RSA key length and the digest used in cryptographic certification. Let's improve them both. Your argument in response seems to be "whoa! if we improve them all the way to the symmetric cipher length it would be computationally infeasible!" This is not an argument for not improving the weakest link. I agree with you that RSA doesn't scale well computationally as we approach equivalence to 256-bit symmetric ciphers. I'm not suggesting we take that step. >> Do we want the asymmetric key length to be the weakest link for users >> of GPG's default choices? > > Unless we move to RSA-15000, it will be. so, how much weaker are you ok with? 3072-bit keys are functional and available now, and even according to NIST's standards (i'm glad you still feel they're trustworthy, even in the context of them having issued a deliberately bad RNG, and their keylength recommendations being weaker than everyone else's!) > I agree that a stronger asymmetric component would be nice, but I don't > believe RSA is the way to go. We're already on the brink of introducing > ECC support into GnuPG. I think that once ECC support is introduced in > the mainline, it will then be an appropriate time to revisit the > question. I would support shifting to stronger asymmetric component(s) > at that time, but I don't think it's worth the headache of changing the > defaults if we're just going to change them *again* in under a year. Of course when ECC is available, we may want to shift to ECC. But ECC is not currently available, and even when it becomes available, RSA will be the dominant key type for years. This is a terrible argument for not improving the default RSA key length today. It costs very little to change the default, and it signals the user community that we take the existence of well-funded adversaries seriously. [from your other followup] > I am not in favor of covering more than 'virtually all users' and > 'virtually all purposes.' The difference between 99% of GnuPG's users > and 100% of GnuPG's users is, first of all, impossible to close, and > second of all, requires ever-increasing expense just to approximate it. We're engineers talking about building safety and security infrastructure here. Of course we may not get it right; bridges built with what they thought was a 200% safety margin have collapsed due to unforeseen factors. But we can make sure that we build in what we currently believe is a safety margin beyond what we believe anyone *should* need, and it is the responsible thing to do. Targeting exactly at the 99% percentile is irresponsible when we can safely and reasonably overshoot. To be clear: i'm not advocating for moving to 15000-bit or 30000-bit RSA keys by default. I'm advocating having a baseline 128-bit-symmetric-equivalent security by default, on all aspects of the cryptosystem. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From al-gnupg_users at none.at Wed Dec 18 00:58:51 2013 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Wed, 18 Dec 2013 00:58:51 +0100 Subject: X.509 certificates for https://gnupg.org In-Reply-To: <87k3f3bia0.fsf@vigenere.g10code.de> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <52AF6429.90201@fifthhorseman.net> <87k3f3bia0.fsf@vigenere.g10code.de> Message-ID: <69060e666128d9e1c253eb0cd26b070a@none.at> Hi Werner. Am 17-12-2013 16:37, schrieb Werner Koch: > On Mon, 16 Dec 2013 21:35, dkg at fifthhorseman.net said: > >> Werner, if i can help with configuring or maintaining the web server >> for >> gnupg.org to address some of these issues, please let me know. > > Yes, I have problems to figure out a woking cipher list which also > allows for IE. What DHE cipher suite may I use with IE given that I > have only an RSA certificate. Or should I simply give up on PFS for IE > users? The active ciphers are right now: > > ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) > Mac=SHA1 > DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) > Mac=SHA1 > DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) > Mac=SHA1 You can test your client with the Experimental SSL Client Test https://www.ssllabs.com/ssltest/viewMyClient.html The following site also explain how you can change the order of the ciphers in Windows Vista, maybe it is also possible in this way on other Windows versions. http://www.ditii.com/2007/11/07/windows-vista-changing-the-ssl-cipher-order-in-internet-explorer-7/ Cheers Aleks From dkg at fifthhorseman.net Wed Dec 18 03:26:00 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 21:26:00 -0500 Subject: Another step towards crowdfunding In-Reply-To: <52B0FE47.5010509@micahflee.com> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <87eh5bd9q6.fsf@vigenere.g10code.de> <52B0D7D7.90609@micahflee.com> <52B0E7DB.3060008@dougbarton.us> <52B0FE47.5010509@micahflee.com> Message-ID: <52B107B8.8050407@fifthhorseman.net> On 12/17/2013 08:45 PM, Micah Lee wrote: > As far as I know these preload lists only force HTTPS for these domains. > I wonder if anyone could convince the browser vendors to also do > certificate pinning, bypassing PKI based on CAs altogether? I believe the answer for public-key-pinning is the same as for HSTS. That is, if you've already implemented the possible footgun that is public-key-pinning on your web site via the standard HTTP headers, and you have demonstrated that it works for you, you can send patches to agl against: https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json (ironically, src.chromium.orgdoesn't appear to signal support for safe TLS negotiation via RFC 5746, sigh) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From md123 at nycap.rr.com Wed Dec 18 03:41:58 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 21:41:58 -0500 Subject: encryption algorithm In-Reply-To: <52B0F549.9090707@sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0F0DD.9030706@nycap.rr.com> <52B0F549.9090707@sixdemonbag.org> Message-ID: <52B10B76.5080302@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 08:07 PM, Robert J. Hansen wrote: >> what about the 2048-bit DSA part of it? > > Search the list archives, please -- this question has been asked > and answered a great number of times. > OK, I see. So . . . if brute force is impossible, then what sort of an attack is possible? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsQt2AAoJECrdp7MWSIVbJ7EH/2FBFnICQSUyubosjMq1BZTv 11pO4cn4j62x2iP4Hmq6n80zXJhP30hT3pLXW8ZOHqBp+yFW589/G6BSxRxK63lp 7HxSZJ8fSP7KWPdhKG7ykICEEwQPAWT9HoV4dmNomNMwJCD9LlMq+x1EIJWIoFzp XMvImaerg64tutM7Tnvku9zS2lgyd/NeIZKbHTEYifKYkOCVpIzjnpr1iEC0qoeY KHBiQwXjcMwUtqjRswQkXvp3INq44PxCYiAKbk5ZdR0IC57iYVFgJg1ExsH56ydv xk4rIGY5EoRGffymcth/uN0rjCPUXYU3Ce6/iY/Vejgs3L88YkNTSfK3VOIpDCg= =kQkY -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Dec 18 04:28:43 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 22:28:43 -0500 Subject: encryption algorithm In-Reply-To: <52B10681.1030701@fifthhorseman.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> <52B0F9F1.7020705@sixdemonbag.org> <52B10681.1030701@fifthhorseman.net> Message-ID: <52B1166B.9030703@sixdemonbag.org> On 12/17/2013 9:20 PM, Daniel Kahn Gillmor wrote: > sigh. "weakest link" analysis is clearly useful, and just as > clearly not the only analytic tool to use. I don't understand your position. First you're saying, "we currently have 112 bits of keyspace, we need at least 128," and then you're saying that you want to see the system evened out -- but the difference between a 128-bit keyspace and a 256-bit keyspace is so enormous that you might as well be talking about a 112-bit keyspace and a 256-bit keyspace. If a 3072-bit key makes you happy and makes you feel it's "evened out," well, my question is -- why? 256 bit keyspace versus 112 is not much different from 256 bit versus 128. > Your argument in response seems to be "whoa! if we improve them all > the way to the symmetric cipher length it would be computationally > infeasible!" No. My argument is that your reasoning is incoherent. If you want to even out the system -- or, as you advocated later, make the asymmetric component stronger than the symmetric component -- the *only possible* interpretation is that you're advocating for at least RSA-15000. If you truly believe the asymmetric component should be stronger, you're advocating for RSA-30000. I don't think that's what you want. (And I note that you have explicitly repudiated that notion.) And since I think that's not what you want, that means I have to conclude your reasoning is faulty. > so, how much weaker are you ok with? At least 128 bits of keyspace less, obviously. And when weighed in that respect, whether we're talking about 128 bits or 140 bits is really quite irrelevant. That's why we need to focus on keeping each component at or greater than our minimum specification. 112 bits of keyspace is a reasonable minimum for the time being; therefore, I'm happy with the current defaults. I don't want to see them used for the next ten years, mind you, but I absolutely reject the fierce moral urgency of immediate change that you seem to be subscribing to. > (i'm glad you still feel they're trustworthy, even in the context of > them having issued a deliberately bad RNG, and their keylength > recommendations being weaker than everyone else's!) That's a naked slander against NIST. You're better than that, Daniel. No one, and I emphasize *no one*, has presented any evidence that NIST issued a deliberately bad PRNG, or for that matter whether Dual_EC_DRBG is even backdoored. _Wired_ magazine wrote of it, A surprising uncertainty is still smouldering over whether Dual_EC_DRBG really is backdoored. The _Times_, crypto experts note, hasn't released the memos that purport to prove the existence of a backdoor, and the paper's direct quotes from the classified documents don't mention any backdoor in the algorithm or efforts by the NSA to weaken it or the standard. They only discuss efforts to push the standard through committees for approval. Jon Callas, the CTO of Silent Circle ... saw the presentation by Shumow. He says he wasn't alarmed by it at the time and still has doubts that what was exposed was actually a backdoor, in part because the algorithm is so badly done. "If [NSA] spent $250 million weakening the standard and this is the best that they could do, then we have nothing to fear from them," he says. "Because this was really ham-fisted. When you put on your conspiratorial hat about what the NSA would be doing, you would expect something more devious, Machiavellian... and this thing is just laughably bad. This is Boris and Natasha sort of stuff." Indeed, the Microsoft presenters themselves -- who declined to comment for this article -- didn't press the backdoor theory in their talk. They didn't mention NSA at all, and went out of their way to avoid accusing NIST of anything. "WE ARE NOT SAYING: NIST intentionally put a back door in this PRNG," read the last slide of their deck. The Microsoft manager who spoke with WIRED on condition of anonymity thinks the provocative title of the 2007 presentation overstates the issue with the algorithm and is being misinterpreted -- that perhaps reporters at the _Times_ read something in a classified document showing that the NSA worked on the algorithm and pushed it through the standards process, and quickly took it as proof that the title of the 2007 talk had been right to call the weakness in the standard and the algorithm a backdoor. ... [Schneier] adds that the uncertainty around the algorithm and the standard is the worst part of the whole matter. "This is the worst problem that the NSA has done," Schneier says. "They have so undermined the fundamental trust in the internet, that we don't know what to trust. We have to suspect everything. We're never sure. That's the greatest damage." (Link: http://www.wired.com/threatlevel/2013/09/nsa-backdoor/all/ ) I emphatically agree there's a lot of uncertainty around Dual_EC_DRBG. It is possible it was subverted -- but it's also possible it wasn't. It's possible it was subverted, NIST knew of the subversion, and approved the standard anyway -- but it's also possible NIST was caught unawares. It's possible that... etc. Claiming that they offered a *deliberately bad* PRNG is, quite frankly, a slander. There is no certainty there. There isn't even much in the way of evidence. There is a possibility. Let's not go about declaring NIST guilty based on nothing more than the possibility of wrongdoing. > Of course when ECC is available, we may want to shift to ECC. But > ECC is not currently available, and even when it becomes available, > RSA will be the dominant key type for years. Sure. That's because we can't retroactively change keys that have already been made. Even if we adopt your recommendation of moving to RSA-3072 immediately, RSA-2048 will still be the dominant key type for years. > This is a terrible argument for not improving the default RSA key > length today. I think it's a great one. One of the best things about GnuPG has been its stability. Changing the defaults is not something to be done lightly. Doing so invalidates FAQs and tutorials, it forces people to edit their scripts, it causes uncertainty and doubt and "why did you change...?" on the mailing lists. Changing to RSA-3072 now, and then to ECC in nine months or a year, is (IMO) unwise. "Why are you changing the defaults again? Did you make a mistake the last time?" Etc., etc. Better to wait until ECC is ready, make a single change to the defaults, and keep the transition crisp and clean. > It costs very little to change the default, and it signals the user > community that we take the existence of well-funded adversaries > seriously. I think GnuPG has already clearly established its reputation in that field. > We're engineers talking about building safety and security > infrastructure here. Yes -- and part of that is recognizing when the additional expense to mitigate a risk is greater than the risk itself. I'm sure we could reduce airplane crashes by 90% if we were to overengineer airplanes so much that a ticket cost a million dollars, but we don't do that. You want perfection. You're not going to get it. It's like trying to build a bridge that simply will not collapse, period, no matter how large a weight is moved over it. What I want instead is a quality bridge, one that's well-inspected, and has a big sign a half-kilometer out reading, "Maximum Load 10,000kg". That, we can do pretty easily. From rjh at sixdemonbag.org Wed Dec 18 04:33:35 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 22:33:35 -0500 Subject: encryption algorithm In-Reply-To: <52B10B76.5080302@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0F0DD.9030706@nycap.rr.com> <52B0F549.9090707@sixdemonbag.org> <52B10B76.5080302@nycap.rr.com> Message-ID: <52B1178F.50202@sixdemonbag.org> On 12/17/2013 9:41 PM, Matt D wrote: > OK, I see. So . . . if brute force is impossible, then what sort of > an attack is possible? Too many to list. Depends largely on your attacker's budget and the constraints of their operation. For instance, if I don't care if you know I've compromised your traffic, I'll tie you to a chair and start swinging a pipe wrench at your kneecaps. Cheap and effective. Or I can target your machine for compromise. If I can trick you into visiting a particular URL I might be able to plant a remote-root on your desktop and gain control over it. At that point it's easy to run a keylogger to intercept your passphrase, and easy to copy your private key off your desktop. Or I can hire a $5,000-a-night hooker. I'm pretty sure that inside of a week you'd be willing to tell your new charming companion pretty much anything. The KGB employed this against United States cipher clerks with amazing success. Or... etc. The list goes on and on and on. In fact, there are so many ways to gain access to your traffic that I think obsessing over whether the default should be 2048-bits or 3072-bits is ... it's like arguing over whether your security fence should be 100 feet high or 120 feet high. Either way you need to pay more attention to the guy who's digging a tunnel underneath it. From md123 at nycap.rr.com Wed Dec 18 04:57:01 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 22:57:01 -0500 Subject: encryption algorithm In-Reply-To: <52B1178F.50202@sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0F0DD.9030706@nycap.rr.com> <52B0F549.9090707@sixdemonbag.org> <52B10B76.5080302@nycap.rr.com> <52B1178F.50202@sixdemonbag.org> Message-ID: <52B11D0D.6090504@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 10:33 PM, Robert J. Hansen wrote: > On 12/17/2013 9:41 PM, Matt D wrote: >> OK, I see. So . . . if brute force is impossible, then what sort >> of an attack is possible? > > Too many to list. Depends largely on your attacker's budget and > the constraints of their operation. For instance, if I don't care > if you know I've compromised your traffic, I'll tie you to a chair > and start swinging a pipe wrench at your kneecaps. Cheap and > effective. > > Or I can target your machine for compromise. If I can trick you > into visiting a particular URL I might be able to plant a > remote-root on your desktop and gain control over it. At that > point it's easy to run a keylogger to intercept your passphrase, > and easy to copy your private key off your desktop. > > Or I can hire a $5,000-a-night hooker. I'm pretty sure that inside > of a week you'd be willing to tell your new charming companion > pretty much anything. The KGB employed this against United States > cipher clerks with amazing success. > > Or... etc. The list goes on and on and on. In fact, there are so > many ways to gain access to your traffic that I think obsessing > over whether the default should be 2048-bits or 3072-bits is ... > it's like arguing over whether your security fence should be 100 > feet high or 120 feet high. Either way you need to pay more > attention to the guy who's digging a tunnel underneath it. Lets assume I run Ubuntu live from USB stick or cd when I need secure messaging so an attacker cannot predict what machine i will send my message from and there will be nothing left on the machine. The encrypted message is captured but the adversary does not have access to me. What sort of attack has any chance to decrypt the message? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsR0MAAoJECrdp7MWSIVbJLUH/0WbAEDhm2vPBQMUaOTfgmpl SBnZnAxLOk3V/oA5moDF2SK4MHHWcwy5UNkgF+r/NIeSiKVevYVbeMCo8WzjRJwt 6T7B92sH9C5NDgxerimrliUcK3/HgkEQvWjBGa7BL4s2EpvSM34HtPC6eUyu9S4T Ylj8BuUnQC8p8Xpla7RQIZEY9xu/j4Rx7Gf/cuJKIhEGLbTMqXLQvF787/bqb7vG 2ib/QoUn8BVmRbgE186KVTX/uHm2FGNoTFRMQ/mgSQEoFdy8ELfs76QjYHFY4gAF rEa6arHXgttcnadrvcyAWr705TZILm0Oi/QuJJNhkN1e0/4+qDualXXbQSQqNtA= =GfAE -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Dec 18 05:02:41 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 17 Dec 2013 23:02:41 -0500 Subject: encryption algorithm In-Reply-To: <52B11D0D.6090504@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0F0DD.9030706@nycap.rr.com> <52B0F549.9090707@sixdemonbag.org> <52B10B76.5080302@nycap.rr.com> <52B1178F.50202@sixdemonbag.org> <52B11D0D.6090504@nycap.rr.com> Message-ID: <52B11E61.6030108@sixdemonbag.org> On 12/17/2013 10:57 PM, Matt D wrote: > Lets assume I run Ubuntu live from USB stick or cd when I need secure > messaging so an attacker cannot predict what machine i will send my > message from and there will be nothing left on the machine. The > encrypted message is captured but the adversary does not have access > to me. What sort of attack has any chance to decrypt the message? Beating your kneecaps into pulp, hiring a hooker to persuade the secret out of you, beating your recipient's kneecaps into pulp, hiring a hooker to persuade the secret out of your correspondent, Van Eycking your terminal, Van Eycking your recipient's terminal, figuring out a way to plant an exploit on your USB stick... I could go on for quite some time, but you get the idea. The best ways to recover the message do not involve cryptanalysis, and the non-cryptanalytic means are devastatingly effective. From dkg at fifthhorseman.net Wed Dec 18 05:11:38 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Dec 2013 23:11:38 -0500 Subject: encryption algorithm In-Reply-To: <52B1166B.9030703@sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> <52B0F9F1.7020705@sixdemonbag.org> <52B10681.1030701@fifthhorseman.net> <52B1166B.9030703@sixdemonbag.org> Message-ID: <52B1207A.4010709@fifthhorseman.net> On 12/17/2013 10:28 PM, Robert J. Hansen wrote: > On 12/17/2013 9:20 PM, Daniel Kahn Gillmor wrote: >> (i'm glad you still feel they're trustworthy, even in the context of >> them having issued a deliberately bad RNG, and their keylength >> recommendations being weaker than everyone else's!) > > That's a naked slander against NIST. You're better than that, Daniel. > > No one, and I emphasize *no one*, has presented any evidence that NIST > issued a deliberately bad PRNG, or for that matter whether Dual_EC_DRBG > is even backdoored. _Wired_ magazine wrote of it, Dual_EC_DRBG was widely acknowledged as bad even when it was released. It's bad simply because it's far slower than other comparable RNGs that were standardized at the same time. I did *not* claim it was deliberately backdoored, and i certainly didn't claim it was backdoored by NIST. I happen to love what NIST stands for (i'm a standards nerd because i'm a communications nerd, and i care that when i say "1 meter", you know what i mean), and i want to be able to trust them. But we do know that a powerful agency who is *not* NIST has been deliberately attempting to fiddle with the recommendations generated by this standards body. I'm not slandering NIST to say that Dual_EC_DRBG is bad. But it is indeed bad. It's bad because it's particularly slow, and it's bad because it *could be* backdoored if someone knows a special key that the rest of us don't know. These are not mistakes that standards agencies should make, though of course any organization of people is bound to make mistakes, especially ones that have people deliberately trying to make them make mistakes. NIST has acknowledged that Dual_EC_DRBG was a bad standard by withdrawing it. > Sure. That's because we can't retroactively change keys that have > already been made. Even if we adopt your recommendation of moving to > RSA-3072 immediately, RSA-2048 will still be the dominant key type for > years. All the more reason to change the default keylength now, no? >> This is a terrible argument for not improving the default RSA key >> length today. > > I think it's a great one. One of the best things about GnuPG has been > its stability. Changing the defaults is not something to be done > lightly. Doing so invalidates FAQs and tutorials, it forces people to > edit their scripts, it causes uncertainty and doubt and "why did you > change...?" on the mailing lists. Changing to RSA-3072 now, and then to > ECC in nine months or a year, is (IMO) unwise. "Why are you changing > the defaults again? Did you make a mistake the last time?" And if that comes up, we have an answer to that: "ECC is now available, and it wasn't before." But honestly, when the first version with ECC support is released, i strongly doubt gpg will switch to that as the default public key algorithm immediately, for the same interoperability concerns you're raising right now. So if gpg 2.1 releases in 6 months (i'm making this date up, of course), how many months will it take for the default algorithm to be changed to ECC? What about for the old branches (1.4.x, 2.0.x) that won't support ECC? What i'm saying is: even if you believe that somehow it would be bad to change defaults twice within a year of each other (which i don't), i don't believe that we will have ECC as the default public key type within a year, certainly not for the 1.4 branch. >> It costs very little to change the default, and it signals the user >> community that we take the existence of well-funded adversaries >> seriously. > > I think GnuPG has already clearly established its reputation in that field. It has; let's keep it up. >> We're engineers talking about building safety and security >> infrastructure here. > > Yes -- and part of that is recognizing when the additional expense to > mitigate a risk is greater than the risk itself. I'm sure we could > reduce airplane crashes by 90% if we were to overengineer airplanes so > much that a ticket cost a million dollars, but we don't do that. Come on now, what does this hyperbole do for your argument? I'm not asking for airplane tickets that cost a million dollars. I'm asking for a minimum level of 128-bit-symmetric-equivalent security by default. Do you really think that's the equivalent of a million dollar airplane ticket? > You want perfection. You're not going to get it. It's like trying to > build a bridge that simply will not collapse, period, no matter how > large a weight is moved over it. Have i asked for perfection? I feel like you're arguing with someone else here. I even wrote (in the very paragraph to which you are responding) "Of course we may not get it right". I'm asking for a strong baseline set of defaults with a reasonable security margin based on current knowledge. This isn't perfection, it's (fallible, human) engineering. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From md123 at nycap.rr.com Wed Dec 18 05:14:29 2013 From: md123 at nycap.rr.com (Matt D) Date: Tue, 17 Dec 2013 23:14:29 -0500 Subject: encryption algorithm In-Reply-To: <52B11E61.6030108@sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0F0DD.9030706@nycap.rr.com> <52B0F549.9090707@sixdemonbag.org> <52B10B76.5080302@nycap.rr.com> <52B1178F.50202@sixdemonbag.org> <52B11D0D.6090504@nycap.rr.com> <52B11E61.6030108@sixdemonbag.org> Message-ID: <52B12125.20706@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/17/2013 11:02 PM, Robert J. Hansen wrote: > On 12/17/2013 10:57 PM, Matt D wrote: >> Lets assume I run Ubuntu live from USB stick or cd when I need >> secure messaging so an attacker cannot predict what machine i >> will send my message from and there will be nothing left on the >> machine. The encrypted message is captured but the adversary >> does not have access to me. What sort of attack has any chance >> to decrypt the message? > > Beating your kneecaps into pulp, hiring a hooker to persuade the > secret out of you, beating your recipient's kneecaps into pulp, > hiring a hooker to persuade the secret out of your correspondent, > Van Eycking your terminal, Van Eycking your recipient's terminal, > figuring out a way to plant an exploit on your USB stick... I could > go on for quite some time, but you get the idea. The best ways to > recover the message do not involve cryptanalysis, and the > non-cryptanalytic means are devastatingly effective. > So in other words the message can not be read by some govt genius with a rack of computers?? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsSElAAoJECrdp7MWSIVb4tIH/j3GJ91LkIEWOKyJ12VD0zkZ PH2by0RFWP6EIZWcek2zCtwbte1u5EiF4qqrVhkkSs+mQD+K87rdZMZFGsTjqxzL j8u8leyOOUm6jWXzLvncIVG5qYO6Tk1xIFKvNZK34hgnpxJ4JZm4tuzlgbK6S803 8A0i9beBITbFGrUIqr4/Xn9Ir9UOJEW7knhTZZnv1168p4sN4tuq5ei42yespAkz HWMEtCyrI/xQHjc2YQB4mp9UnRAxIos0P8mdtJhN6ZSw6+UTFH30kSPslq159rWO cT8LYxfd7wZwcS36mbXpWU8U6cxzXQp3/KcZ9ffJJsi7etnKCUCNLUOvigbfz9U= =EAPZ -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Dec 18 06:05:47 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Dec 2013 00:05:47 -0500 Subject: encryption algorithm In-Reply-To: <52B12125.20706@nycap.rr.com> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0F0DD.9030706@nycap.rr.com> <52B0F549.9090707@sixdemonbag.org> <52B10B76.5080302@nycap.rr.com> <52B1178F.50202@sixdemonbag.org> <52B11D0D.6090504@nycap.rr.com> <52B11E61.6030108@sixdemonbag.org> <52B12125.20706@nycap.rr.com> Message-ID: <52B12D2B.4060901@sixdemonbag.org> > So in other words the message can not be read by some govt genius with > a rack of computers?? How would I know? Ask a government genius with a rack of computers. I don't know the extent of the government's capabilities, nor do I want to. That's the kind of knowledge that normally comes with some really strict rules on what you're allowed to say. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Dec 18 06:29:47 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Dec 2013 00:29:47 -0500 Subject: encryption algorithm In-Reply-To: <52B1207A.4010709@fifthhorseman.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> <52B0F9F1.7020705@sixdemonbag.org> <52B10681.1030701@fifthhorseman.net> <52B1166B.9030703@sixdemonbag.org> <52B1207A.4010709@fifthhorseman.net> Message-ID: <52B132CB.2010000@sixdemonbag.org> > It's bad simply because it's far slower than other comparable RNGs > that were standardized at the same time. I did *not* claim it was > deliberately backdoored, and i certainly didn't claim it was > backdoored by NIST. Then why did you use it as a "I'm glad you can still trust them even after they released a deliberately bad RNG?" Good people and good institutions release bad things all the time. Bad things escape committees. A lot of cryppies cringed when WEP was announced because it used RC4 and RC4 is so difficult to use correctly. (And true to form, WEP used it badly.) Does that mean we shouldn't trust IEEE? IPv4 is another great example: Vint Cerf has gone on the record saying that he's a little ashamed of its success, since only having a 32-bit address space has been sort of an ongoing professional embarrassment to him, and he knew it all the while he was working for widespread IPv4 deployment. Should we not trust Vint? A flawed standard is just that, a flawed standard. It's not a cause for a crisis of trust in an outfit that has enjoyed the community's trust for many decades. >> Sure. That's because we can't retroactively change keys that have >> already been made. Even if we adopt your recommendation of moving >> to RSA-3072 immediately, RSA-2048 will still be the dominant key >> type for years. > > All the more reason to change the default keylength now, no? I don't understand. If your argument against switching to ECC is "we won't get rid of RSA-2048 for a long time anyway," then how can you use the same logic to argue for switching to RSA-3072 right now, since presumably we still won't get rid of RSA-2048 for a long time anyway? > And if that comes up, we have an answer to that: "ECC is now > available, and it wasn't before." Doesn't address the issues of forcing people to rewrite tutorials and manuals, rewrite standard operating procedures for their businesses, rewrite scripts to accommodate the new defaults... etc. I think you are vastly underestimating the infrastructure here. > But honestly, when the first version with ECC support is released, i > strongly doubt gpg will switch to that as the default public key > algorithm immediately, for the same interoperability concerns you're > raising right now. Only Werner knows his timetable. > Come on now, what does this hyperbole do for your argument? I'm not > asking for airplane tickets that cost a million dollars. I'm asking > for a minimum level of 128-bit-symmetric-equivalent security by > default. And you're not making a compelling argument that 112 bits, as it currently stands, is inadequate. Further, there's nothing preventing you from packaging your own GnuPG build that has 3072-bit RSA as a default. Speaking just for myself, I'd welcome that -- I wouldn't use it, but I'm completely in favor of there being a competitive marketplace of ideas and letting the users sort it out. > Do you really think that's the equivalent of a million dollar > airplane ticket? The point of the metaphor was to show that moving from "adequate for 99% of the population" to "adequate for 100% of the population" has some extreme costs involved. > I'm asking for a strong baseline set of defaults with a reasonable > security margin based on current knowledge. This isn't perfection, > it's (fallible, human) engineering. And your belief is that 112 bits of keyspace is not a strong set of defaults with a reasonable security margin based on current knowledge? For crypto that's currently projected to be secure out until 2030? There's nothing more to say except, I disagree. At this point in time 112-bit keyspaces are reasonable defaults. We should be looking towards shifting towards larger keyspaces, but there's no immediately pressing urgency. Let's wait for ECC. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Dec 18 08:18:05 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 18 Dec 2013 02:18:05 -0500 Subject: encryption algorithm In-Reply-To: <52B132CB.2010000@sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> <52B0F9F1.7020705@sixdemonbag.org> <52B10681.1030701@fifthhorseman.net> <52B1166B.9030703@sixdemonbag.org> <52B1207A.4010709@fifthhorseman.net> <52B132CB.2010000@sixdemonbag.org> Message-ID: <52B14C2D.3050902@fifthhorseman.net> On 12/18/2013 12:29 AM, Robert J. Hansen wrote: > A flawed standard is just that, a flawed standard. It's not a cause for > a crisis of trust in an outfit that has enjoyed the community's trust > for many decades. Sorry, but NIST does face a crisis of trust, particularly in the area of cryptography, whether either of us wants that to happen or not. I don't think we should pretend otherwise. NIST certainly isn't pretending otherwise; it is taking the situation seriously: https://www.computerworld.com.au/article/528681/nsa_backdoor_fears_creating_crisis_confidence_u_high-tech_products_services/ http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0 http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/?src=twrhp&_r=1 http://csrc.nist.gov/publications/nistbul/itlbul2013_09_supplemental.pdf > I don't understand. If your argument against switching to ECC is "we > won't get rid of RSA-2048 for a long time anyway," then how can you use > the same logic to argue for switching to RSA-3072 right now, since > presumably we still won't get rid of RSA-2048 for a long time anyway? Because it takes a long time for these fixes to trickle into downstream distributions and reach wider adoption, and longer still for the users of those systems to adopt new stronger keys and integrate them into their workflow and their certification networks. You don't plant a tree now because you want fruit tomorrow; You plant a tree now because you want fruit in 3 years. > Doesn't address the issues of forcing people to rewrite tutorials and > manuals, rewrite standard operating procedures for their businesses, > rewrite scripts to accommodate the new defaults... etc. I think you are > vastly underestimating the infrastructure here. People are already rewriting tutorials and manuals and standard operating procedures. They're doing it because gpg isn't updating the defaults. That work is under way right now, it exactly in the ways that you've expressed frustration about on this thread, because the authors of manuals and tutorials want to provide their users with a strong safety margin, particularly in light of recent disclosures about powerful attackers who have access to large amounts of traffic and outlandish compute power. The best manual would say "Use a reasonably up-to-date version of GnuPG, and use the defaults. They are strong, and functional, and provide a security margin that everyone can rely on." That wouldn't require much updating if the defaults track the current cryptanalysis and publicly-acknowledged threats. > Further, there's nothing preventing you from packaging your own GnuPG > build that has 3072-bit RSA as a default. Speaking just for myself, I'd > welcome that -- I wouldn't use it, but I'm completely in favor of there > being a competitive marketplace of ideas and letting the users sort it out. sigh. Of course i could do this, but i don't want to, because i would rather that gnupg have a set of defaults with a forward-looking safety margin built in to begin with. > The point of the metaphor was to show that moving from "adequate for 99% > of the population" to "adequate for 100% of the population" has some > extreme costs involved. Except that i'm not asking for anything that has extreme costs. There are larger costs involved with just scanning and parsing a keyring with a few dozen keys than in the difference between a 2048-bit RSA operation and a 3072-bit RSA operation. >> I'm asking for a strong baseline set of defaults with a reasonable >> security margin based on current knowledge. This isn't perfection, >> it's (fallible, human) engineering. > > And your belief is that 112 bits of keyspace is not a strong set of > defaults with a reasonable security margin based on current knowledge? > For crypto that's currently projected to be secure out until 2030? 2048-bits is *at most* 112 bits of keyspace, depending on whose analysis you rely on. ENISA and ECRYPT both explicitly recommend 128 bit equivalence (but not 112-bit) as a "Good, generic application-indep. recommendation" (ECRYPT) and "secure for future use" (ENISA). We know that modern machinery can do this level of work without serious drawbacks, and we know that it's possible to change the defaults for gpg. Looking past RSA keysize, the default certification mechanism uses SHA-1, which has only 80-bits of protection against collision attacks (and is known to have cryptanalytic results that bring this figure down to the mid 60s). Fortunately, preimage attacks on SHA-1 appear to still be out of reach, and it's harder to exploit the cryptosystem as a whole with a collision attack than it would be with a preimage attack. But effective collision attacks possible against OpenPGP certifications could still be devastating, since users are signing data provided almost entirely by a potential attacker. Switching to a widely-supported stronger algorithm like SHA-256 by default for OpenPGP certificates would address this even weaker link. Look, i'm *not* a bitsize fetishist. I'm not advocating for 512-bit equivalent security everywhere, or 30Kbit RSA keys, or anything like that. I'm reading the same standards you are, aware of the same news you are, and trying to make plans for what we both know is a long upgrade cycle so that we don't have a bunch of users whose security is compromised in the mid-term future. If you want to continue to cite the weaker of the public standards, and ignore the advice in the stronger ones, and argue that we don't need to upgrade now because no one has demonstrated any attacks publicly, i guess that's your call. I want gpg to take the lead on this, to make it clear that we continue to take our users' information security seriously, and provide a healthy safety margin given our long-term stability and commitment to maintenance. We can't fix any user's operational security if it's terrible, but we can make sure that anyone who uses a reasonably modern version of gpg won't be burned by the crypto itself, even if they have a large organization as an adversary. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From micha137 at gmx.de Wed Dec 18 09:21:33 2013 From: micha137 at gmx.de (Michael Anders) Date: Wed, 18 Dec 2013 09:21:33 +0100 Subject: ECC curves used in gnupg? In-Reply-To: References: Message-ID: <1387354893.4590.16.camel@micha137-myAMD-CM1740> On Tue, 2013-12-17 at 13:01 -0600, Anthony Papillion wrote: > I know that gnupg is experimenting with ECC and I'm wondering which > curves the team has decided to use. I know there are some curves that > are now suspected of being tainted by the NSA through NIST. Has the > gnupg team ruled using those curves out? Wouldn't it be nice to include ecc curves up to 1024 bit(ecc brainpool gives you 512 bit at most, maryland 521). I calculated the parameters last year(no ties to maryland) and they are free for noncommercial use ;-) They can be found here: http://www.fh-wedel.de/~an/crypto/accessories/domains_anders.html In the ECC software "Academic Signature" -which contains a minimalistic GnuPG GUI by the way- you can check their sanity, including the MOV condition. There has been a thread on insecure GnuPG defaults lately. (SHA1 hmmmm....) Please keep in mind that (to my knowledge) maryland does allow the export of ecc software up to 256 bit if in the "interest of national security". So why not exclude bit sizes smaller than 256 from the very beginning. regards Michael From wk at gnupg.org Wed Dec 18 11:24:43 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 11:24:43 +0100 Subject: ECC curves used in gnupg? In-Reply-To: (Anthony Papillion's message of "Tue, 17 Dec 2013 13:01:03 -0600") References: Message-ID: <87sitq8nis.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 20:01, anthony at cajuntechie.org said: > I know that gnupg is experimenting with ECC and I'm wondering which > curves the team has decided to use. I know there are some curves that > are now suspected of being tainted by the NSA through NIST. Has the > gnupg team ruled using those curves out? We will support the curves specified in RFC-6637. These are the NIST curves P-256, P-384, and P-521. I recently added support for Brainpool P256r1, P384r1, and P512r1 to make some some European governments happy. I the wake of recent events and due to the fear of many people that the NIST curves might have some secret properties, I added support for Bernstein et al's Ed25519 signature scheme. The problem here is that it is not really covered by RFC-6637 because it does not use the ECDSA signature scheme but a Schnorr like scheme named EdDSA. Thus for a proper implementation we need to assign a new algorithm number to it which in turn means to write another RFC. I recently met with Phil Zimmermann and we talked about the OpenPGP future. It is pretty clear that we need to replace the current algorithms with elliptic curves to get a better security margin for the future. Alhough there are no technical reasons not to use existing standard curves, we better take the users unhappiness with NIS curves in account and move on to curves like Ed25519 which are easier to use and are an outcome of public research. Bernstein and Lange are currently working on a 384 bit curve and it is very likely that this one will also be added to GnuPG. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From oub at mat.ucm.es Wed Dec 18 11:30:00 2013 From: oub at mat.ucm.es (Uwe Brauer) Date: Wed, 18 Dec 2013 11:30:00 +0100 Subject: gpgsm, certificate expired, different certificate, epa does not encrypt Message-ID: <87d2ku78pj.fsf@mat.ucm.es> Hello I am using Xemacs, gnus the epa pkg for encrypting s/mime using gpgsm. I have several email accounts with different (comodo certificates). Now one certificate for the address address1 at gmail.com has expired. However I want to send an email from address2 (whose certificate is *not* expired) to a recipient. However when I try to encrypt this message, it does not work. I obtain an error message, whose epa bug trace I attach. It is not clear to me, who is the culprit, epa or gpgsm. But I consider this is a BUG, I don't want to use the expired certificate but one which is not expired. thanks Uwe Brauer -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gpg-experied URL: From wk at gnupg.org Wed Dec 18 11:41:38 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 11:41:38 +0100 Subject: encryption algorithm In-Reply-To: <52B0F9F1.7020705@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 17 Dec 2013 20:27:13 -0500") References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> <52B0F9F1.7020705@sixdemonbag.org> Message-ID: <87ob4e8mql.fsf@vigenere.g10code.de> On Wed, 18 Dec 2013 02:27, rjh at sixdemonbag.org said: > because you just shifted to arguing that "since GnuPG defaults to > AES-256, we need to use RSA-15000 by default otherwise the asymmetric FWIW: The rationale why we use the order AES256,192,128 is for compatibility reasons with PGP. If gpg would define AES128 first, we would get the somewhat confusing situation: gpg -r pgpkey -r gpgkey ---gives--> AES256 gpg -r gpgkey -r pgpkey ---gives--> AES PGP prefers AES256 for the simple reason that the marketing deptartment told the engineering that 256 sounds stronger than 128 (according to one of their lead developers). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From md123 at nycap.rr.com Wed Dec 18 12:01:45 2013 From: md123 at nycap.rr.com (Matt D) Date: Wed, 18 Dec 2013 06:01:45 -0500 Subject: encryption algorithm In-Reply-To: <52B12D2B.4060901@sixdemonbag.org> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <52B09D90.2020300@nycap.rr.com> <20131217112858.Horde.gXdmW8pbD6wOXog7bOwDQA4@mail.sixdemonbag.org> <52B0B190.5000206@nycap.rr.com> <20131217135400.Horde.CGCzCNavWrJ6wO9i8xOh-A3@mail.sixdemonbag.org> <52B0F0DD.9030706@nycap.rr.com> <52B0F549.9090707@sixdemonbag.org> <52B10B76.5080302@nycap.rr.com> <52B1178F.50202@sixdemonbag.org> <52B11D0D.6090504@nycap.rr.com> <52B11E61.6030108@sixdemonbag.org> <52B12125.20706@nycap.rr.com> <52B12D2B.4060901@sixdemonbag.org> Message-ID: <52B18099.3090900@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/18/2013 12:05 AM, Robert J. Hansen wrote: >> So in other words the message can not be read by some govt genius >> with a rack of computers?? > > How would I know? Ask a government genius with a rack of > computers. > > I don't know the extent of the government's capabilities, nor do I > want to. That's the kind of knowledge that normally comes with > some really strict rules on what you're allowed to say. > Oh OK. So there is a chance that someone has a special mathematical trick to reduce the key-space hence their need for things like Saville, BATON, etc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsYCZAAoJECrdp7MWSIVbwloH/3/xQFdjbrjc/36x1IdaJm8+ YWy3+g5XwXHZxhZRyFhCMwcMa6p8m4fBNZ3kjFCohCq6NwkvErrMWVtuzrI8JY50 poDmZKhUdxdDXv7Dqj/RnI2dzwa7CmcRO8Cqt1JTY51heeq0E1v1R95uL1QUtGGg v8ekuBwqvzUZLjAUrA3+WR+QZnWwoIzkcd884VEit/H4JZ6JYwyTeEMEhx47hsQE qnN1dZGnv5saJgsaowSDQu/6CvRfmVg8N1DOqJX2fradz1aAJaF4cZ8biO3oXSRY J/pmvtHZ0RA6lZRsWaqyAj18p561waE80w1fYdVChhzKskqzcRanmWO9Nld0wxU= =78sh -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Wed Dec 18 13:02:15 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 18 Dec 2013 13:02:15 +0100 Subject: Synchronize UID lists on public and private key -- how? In-Reply-To: <52B09A95.70108@dougbarton.us> References: <741976169.20131217130902@serebryakov.spb.ru> <52B09A95.70108@dougbarton.us> Message-ID: <6941012.SG4IRtrr7R@inno.berlin.laging.de> Am Di 17.12.2013, 10:40:21 schrieb Doug Barton: > On 12/17/2013 01:09 AM, Lev Serebryakov wrote: > | Is it possible to synchronize UID list without transferring "new" > > version > > | of private key from B to A by external means? > > No. I can reproduce the problem but it doesn't make any sense to me. Why are UIDs stored in the secring...? But it is possible to sync pubring and secring (i.e. the answer to the OP's question is yes, not no; whether it's fun...): mkdir split-pub split-sec cp public.gpg split-pub cp secret.gpg split-sec cd split-pub gpgsplit public.gpg # looks like this: 000001-006.public_key 000002-013.user_id 000003-002.sig 000004-013.user_id 000005-002.sig public.gpg cd ../split-sec gpgsplit secret.gpg # looks like this: 000001-005.secret_key 000002-013.user_id 000003-002.sig secret.gpg cp ../split-pub/000004-013.user_id ../split-pub/000005-002.sig . cat 00000* >secret.split.gpg gpg --delete-secret-key 0x12345678 gpg --import secret.split.gpg Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Wed Dec 18 14:23:46 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Dec 2013 08:23:46 -0500 Subject: encryption algorithm In-Reply-To: <52B14C2D.3050902@fifthhorseman.net> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> <52B0F9F1.7020705@sixdemonbag.org> <52B10681.1030701@fifthhorseman.net> <52B1166B.9030703@sixdemonbag.org> <52B1207A.4010709@fifthhorseman.net> <52B132CB.2010000@sixdemonbag.org> <52B14C2D.3050902@fifthhorseman.net> Message-ID: <52B1A1E2.2000507@sixdemonbag.org> On 12/18/2013 2:18 AM, Daniel Kahn Gillmor wrote: > Sorry, but NIST does face a crisis of trust, particularly in the area of > cryptography, whether either of us wants that to happen or not. Perhaps: but *not over the PRNG they published*. Please stay on point. You are demonstrating a tendency here to stake out a position ("NIST is untrustworthy") and argue towards it; and as soon as an argument is refuted, you do a weak backtrack of that argument and stake out a new one in the same direction. Your argument for moving towards RSA-3072 was that you wanted the system to be "more even." When pointed out that we could not make the asymmetric component "more even" with AES-256, you quickly said "well, I'm not advocating RSA-15000" and have since pretended you never made that argument. When you made a smear against NIST on the basis of a flawed PRNG algorithm -- and in context of what you were responding to, it's hard for me to believe you were saying anything other than it was a deliberate backdoor introduced with NIST's knowledge -- you backtracked to "well, I never said it was witting/willing, and anyway, just putting out a single bad spec is enough to damage trust in them." There's no point in having a discussion about a subject if it starts from a position and seeks arguments to support that position, rather than starting from arguments and hoping it will lead to a position. I firmly believe in the latter. The former is the specialty of bad cable news channels where talking heads scream past each other -- which is the state I fear this discussion has devolved into. I'm going to make one last brief summation of my position. Past that, I am done with this thread. It's not going anywhere useful. 1. 112 bits of keyspace is generally acknowledged to be the minimum level that current applications should support. New crypto code should aim for at least 128 bits; 256 bits is better. 2. The reason for the discrepancy is that when deploying a new system it's far easier to overdesign it. When changing an existing system, one has to deal with a large installed codebase. 3. GnuPG's asymmetric default meets the standard in #1. There is no imminent and pressing need to change. 4. GnuPG's asymmetric default is believed to be secure for about the next 15 years. That meets GnuPG's goal of providing pretty good privacy. 5. When GnuPG introduces ECC support it will be a fine opportunity to deploy new certificates, whereupon the default can be changed to 256 bits of keyspace with minimal disruption to people above and beyond the disruption shifting to ECC will do. 6. No one has presented any reason to shift to 128-bit keyspaces right this very instant, especially when ECC is on the horizon and approaching fast. Since the asymmetric component is expected to be safe for 15 years, we're not in an exposure window. 7. If you seriously believe that a 112-bit keyspace is inadequate, then you need to stop using computers. Pretty much every Authenticode-signed Windows application uses RSA-2048 at maximum. ATMs use 3DES, with a 112-bit keyspace. The HTTPS infrastructure tends to max out at RSA-2048. 112-bit keyspaces are endemic. It would be nice if they'd all move to ECC, and hopefully they will, but we are not facing an imminent Cryptoageddon because society's computing infrastructure uses 112-bit keyspaces. 8. I would like to see GnuPG migrate to 256-bit keyspaces. I'd like to see this migration done in a calm, orderly fashion. Given the total lack of risk presently associated with RSA-2048 -- or for the next 15 years or so -- I'm just fine with waiting a year to make a single cutover to minimize disruption to end-users. You may disagree with these; I imagine you will disagree vigorously. That's fine. But now I trust my position is clear, and we can put this to rest. From wk at gnupg.org Wed Dec 18 15:05:38 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 15:05:38 +0100 Subject: [Announce] [security fix] GnuPG 1.4.16 released Message-ID: <87wqj26yq5.fsf@vigenere.g10code.de> Hello! Along with the publication of an interesting new side channel attack by Daniel Genkin, Adi Shamir, and Eran Tromer we announce the availability of a new stable GnuPG release to relieve this bug: Version 1.4.16. This is a *security fix* release and all users of GnuPG versions 1.x are advised to updated to this version. GnuPG versions 2.x are not affected. See below for the impact of the problem. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, smartcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build, and also better portable to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.22) it comes with no support for S/MIME, Secure Shell, or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New =========== * Fixed the RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis attack as described by Genkin, Shamir, and Tromer. See . [CVE-2013-4576] * Put only the major version number by default into armored output. * Do not create a trustdb file if --trust-model=always is used. * Print the keyid for key packets with --list-packets. * Changed modular exponentiation algorithm to recover from a small performance loss due to a change in 1.4.14. Impact of the security problem ============================== CVE-2013-4576 has been assigned to this security bug. The paper describes two attacks. The first attack allows to distinguish keys: An attacker is able to notice which key is currently used for decryption. This is in general not a problem but may be used to reveal the information that a message, encrypted to a commonly not used key, has been received by the targeted machine. We do not have a software solution to mitigate this attack. The second attack is more serious. It is an adaptive chosen ciphertext attack to reveal the private key. A possible scenario is that the attacker places a sensor (for example a standard smartphone) in the vicinity of the targeted machine. That machine is assumed to do unattended RSA decryption of received mails, for example by using a mail client which speeds up browsing by opportunistically decrypting mails expected to be read soon. While listening to the acoustic emanations of the targeted machine, the smartphone will send new encrypted messages to that machine and re-construct the private key bit by bit. A 4096 bit RSA key used on a laptop can be revealed within an hour. GnuPG 1.4.16 avoids this attack by employing RSA blinding during decryption. GnuPG 2.x and current Gpg4win versions make use of Libgcrypt which employs RSA blinding anyway and are thus not vulnerable. For the highly interesting research on acoustic cryptanalysis and the details of the attack see http://www.cs.tau.ac.il/~tromer/acoustic/ . Getting the Software ==================== First of all, decide whether you really need GnuPG version 1.4.x - most users are better off with the modern GnuPG 2.0.x version. Then follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.16 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.16.tar.bz2 (3571k) gnupg-1.4.16.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.16.tar.gz (4955k) gnupg-1.4.16.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.15-1.4.15.diff.bz2 (26k) A patch file to upgrade a 1.4.15 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.16.exe (1573k) gnupg-w32cli-1.4.16.exe.sig GnuPG compiled for Microsoft Windows and its OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . Gpg4win uses GnuPG 2.x and is thus not affected by the security bug. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.16.tar.bz2 you would use this command: gpg --verify gnupg-1.4.16.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com | gpg --import or using a keyserver like gpg --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.16.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.16.tar.bz2 and check that the output matches the first line from the following list: 0bf5e475f3eb6f33d5474d017fe5bf66070e43f4 gnupg-1.4.16.tar.bz2 ea40324a5b2e3a16ffb63ea0ccc950a3faf5b11c gnupg-1.4.16.tar.gz ead70b47218ba76da51c16b652bee2a712faf2f6 gnupg-1.4.15-1.4.16.diff.bz2 82079c7c183467b4dd3795ca197983cd2494cec4 gnupg-w32cli-1.4.16.exe Internationalization ==================== GnuPG comes with support for 29 languages. The Chinese (Simple and Traditional), Czech, Danish, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish, Ukrainian, and Turkish translations are close to be complete. Support ======= A listing with commercial support offers for GnuPG is available at: http://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software take up a most of their resources. To allow them continue their work they ask to either purchase a support contract, engage them for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, donating money, spreading the word, or answering questions on the mailing lists. Many thanks to Eran Tromer for providing early drafts of the paper and testing the fixes. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed Dec 18 15:39:08 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 15:39:08 +0100 Subject: Another step towards crowdfunding In-Reply-To: <20131217194013.GA4693@teletypeIII> (C. Rossberg's message of "Tue, 17 Dec 2013 20:40:13 +0100") References: <20131214202738.27030@gmx.com> <52B0574A.4090206@gnupg.org> <52B09ACF.5060009@dougbarton.us> <20131217194013.GA4693@teletypeIII> Message-ID: <87ob4e6x6b.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 20:40, cr at rheloud.net said: > How about an RSS-Feed. We used to have one for the News. It is currently disabled but will come back with the new website. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Wed Dec 18 16:09:26 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 18 Dec 2013 16:09:26 +0100 Subject: FAQ? Re: please give us safer defaults for gnupg In-Reply-To: <87y53keg5d.fsf@vigenere.g10code.de> References: <52AF3A55.7080800@riseup.net> <87y53keg5d.fsf@vigenere.g10code.de> Message-ID: <201312181609.32000.bernhard@intevation.de> Am Montag, 16. Dezember 2013 20:42:54 schrieb Werner Koch: > May I suggest to read the archives of just a few weeks to collect the > reasons why suggestions of using SHA-512 are missing the point. ?Some > folks here must have bleeding fingertips from repeating the arguments > over and over. What about placing this as an FAQ in the wiki.gnupg.org? I believe we can then refine the argument, so it can be understood more easily. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From vedaal at nym.hush.com Wed Dec 18 16:10:49 2013 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Wed, 18 Dec 2013 10:10:49 -0500 Subject: [Announce] [security fix] GnuPG 1.4.16 released // workaround In-Reply-To: <87wqj26yq5.fsf@vigenere.g10code.de> Message-ID: <20131218151049.A28C1C036A@smtp.hushmail.com> On Wednesday, December 18, 2013 at 9:25 AM, "Werner Koch" wrote: >The paper describes two attacks. The first attack allows to >distinguish >keys: An attacker is able to notice which key is currently used for >decryption. ... > While listening to the acoustic >emanations of >the targeted machine, the smartphone will send new encrypted >messages to >that machine and re-construct the private key bit by bit. A 4096 >bit >RSA key used on a laptop can be revealed within an hour. > >GnuPG 1.4.16 avoids this attack by employing RSA blinding during >decryption. ===== Am not familiar with how RSA 'blinding' works, but am surprised that it cannot be used to 'blind' RSA as to the identity of the key ;-( Here is a potential workaround though: If a sender suspects that the receiver may be in a place where acoustical surveillance can detect the key id, then the sender and receiver can do the following: [1] The sender sends a message encrypted to both the sender's and receiver's usual keys, with an instruction in the plaintext, that if a 'special atypical' key is to be used, then the message is to be sent encrypted to that special atypical key, using the throw-keyid option, as well as encrypting conventionally to a passphrase. [2] The passphrase to be used for conventional encryption is the session key string for the first encrypted message in [1], which the sender and receiver now have, and they can decrypt the messages using conventional encryption. [3] Whenever the correspondents are in an environment 'safe' from this type of acoustic threat, the message can be decrypted using the 'special typical' key. Whatever information is intended to be conveyed by using a 'special key', will still be understood by the receiver. vedaal From samtuke at gnupg.org Wed Dec 18 16:32:21 2013 From: samtuke at gnupg.org (Sam Tuke) Date: Wed, 18 Dec 2013 16:32:21 +0100 Subject: Another step towards crowdfunding In-Reply-To: <52B0D7D7.90609@micahflee.com> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <87eh5bd9q6.fsf@vigenere.g10code.de> <52B0D7D7.90609@micahflee.com> Message-ID: <52B1C005.6000700@gnupg.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 18/12/13 00:01, Micah Lee wrote: > The problem is you're wanting to make GnuPG go mainstream but then you end > up with people seeing this: http://i.imgur.com/53nvUqm.png Yup. That should be avoided. However there are only a few pages that critically need to be https it seems to me. Anywhere that source files are provided clearly needs to be secure. Ideally the manual pages too. But the front page has no need in my opinion. Sam. - -- Sam Tuke Campaign Manager Gnu Privacy Guard Tel: +49 176 81923811 IM: samtuke at jabber.fsfe.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKxwAUACgkQ1bR1Itj7YQWX+QEAnWac1Ffn+/t4HyCkjRKGwrfh WyvtTH4A3fLSDvdOmR4A/1aqmhRX2mD/dKQJajbdrR6pvieN+F1CYsYqP1NLZoyz =QKDi -----END PGP SIGNATURE----- From shavital at mac.com Wed Dec 18 15:49:27 2013 From: shavital at mac.com (Charly Avital) Date: Wed, 18 Dec 2013 16:49:27 +0200 Subject: [Announce] [security fix] GnuPG 1.4.16 released In-Reply-To: <87wqj26yq5.fsf@vigenere.g10code.de> References: <87wqj26yq5.fsf@vigenere.g10code.de> Message-ID: <52B1B5F7.1040902@mac.com> Werner Koch wrote on 12/18/13, 4:05 PM: > Hello! > > Along with the publication of an interesting new side channel attack by > Daniel Genkin, Adi Shamir, and Eran Tromer we announce the availability > of a new stable GnuPG release to relieve this bug: Version 1.4.16. > > This is a *security fix* release and all users of GnuPG versions 1.x are > advised to updated to this version. GnuPG versions 2.x are not > affected. See below for the impact of the problem. [...] Hi, compiled from source: Version info: gnupg 1.4.16 Configured for: Darwin (x86_64-apple-darwin13.0.0) gpg (GnuPG) 1.4.16 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Thank you for your work. Charly 0x15E4F2EA Mac OS X 10.9.1 (13B42) MacBook Intel C2Duo 2GHz 13-inch, Aluminum, Late 2008 . (GnuPG/MacGPG2) 2.0.22 - gpg (GnuPG) 1.4.16 TB 24.2.0 Enigmail version 1.6 (20131006-1849) From wk at gnupg.org Wed Dec 18 16:28:28 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 16:28:28 +0100 Subject: FAQ? Re: please give us safer defaults for gnupg In-Reply-To: <201312181609.32000.bernhard@intevation.de> (Bernhard Reiter's message of "Wed, 18 Dec 2013 16:09:26 +0100") References: <52AF3A55.7080800@riseup.net> <87y53keg5d.fsf@vigenere.g10code.de> <201312181609.32000.bernhard@intevation.de> Message-ID: <87k3f26uw3.fsf@vigenere.g10code.de> On Wed, 18 Dec 2013 16:09, bernhard at intevation.de said: > What about placing this as an FAQ in the wiki.gnupg.org? We have a FAQ which answers a lot of questions around key sizes in ?Advanced Topics? section. If something is missing it can easily be added. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Wed Dec 18 17:53:43 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Dec 2013 17:53:43 +0100 Subject: Sharing/Storing a private key In-Reply-To: <52AF81B0.7080004@dougbarton.us> References: <52ADA792.2000800@digitalbrains.com> <52AF81B0.7080004@dougbarton.us> Message-ID: <52B1D317.2060000@digitalbrains.com> On 16/12/13 23:41, Doug Barton wrote: > but one argument against what you're suggesting is that it's only as secure > as the encryption used in step 1 of the hybrid approach. If only everything in cryptoland was "only as secure as 3DES"... > The ability to apply SSS to the entire secret would be quite valuable I don't see why. If this is because you avoid "insecurities in symmetric crypto", I just don't buy it. Otherwise, please explain. > although your concern about entropy use is something that should be addressed > explicitly. And how do you propose to do that? You can't conjure up good quality entropy. And if you don't trust symmetric crypto, you can't use that to create an almost-random stream either. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From cloudpg at informationelle-selbstbestimmung-im-internet.de Wed Dec 18 18:05:27 2013 From: cloudpg at informationelle-selbstbestimmung-im-internet.de (Jens Lechtenboerger) Date: Wed, 18 Dec 2013 18:05:27 +0100 Subject: gpgsm, certificate expired, different certificate, epa does not encrypt In-Reply-To: <87d2ku78pj.fsf@mat.ucm.es> (Uwe Brauer's message of "Wed, 18 Dec 2013 11:30:00 +0100") References: <87d2ku78pj.fsf@mat.ucm.es> Message-ID: <86y53i2ip4.fsf@informationelle-selbstbestimmung-im-internet.de> On Mi, Dez 18 2013, Uwe Brauer wrote: > I am using Xemacs, gnus the epa pkg for encrypting s/mime using gpgsm. > > I have several email accounts with different (comodo certificates). > Now one certificate for the address address1 at gmail.com has expired. > > However I want to send an email from address2 (whose certificate is > *not* expired) to a recipient. > > However when I try to encrypt this message, it does not work. Hi Uwe, if I understand you correctly, you fail to encrypt to your From address, right? If I?m not mistaken, epa does not encrypt to From addresses by default. What did you do to make that happen? Does your gpgsm.conf contain ?encrypt-to? for the expired certificate? Best wishes Jens From system at ioioioio.eu Wed Dec 18 18:31:41 2013 From: system at ioioioio.eu (system at ioioioio.eu) Date: Wed, 18 Dec 2013 18:31:41 +0100 Subject: gpg-rsa-key decryption with a mobile Message-ID: <52B1DBFD.6060609@ioioioio.eu> "Here, we describe a new acoustic cryptanalysis key extraction attack, applicable to GnuPG's current implementation of RSA. The attack can extract full 4096-bit RSA decryption keys from laptop computers (of various models), within an hour, using the sound generated by the computer during the decryption of some chosen ciphertexts." http://tau.ac.il/~tromer/acoustic/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Wed Dec 18 18:58:58 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 18 Dec 2013 09:58:58 -0800 Subject: Another step towards crowdfunding In-Reply-To: <52B1C005.6000700@gnupg.org> References: <87mwk4q0pg.fsf@vigenere.g10code.de> <52AB302C.2030604@cnamts.fr> <87ppp0o9y3.fsf@vigenere.g10code.de> <52AB7ABA.8030209@micahflee.com> <52AC961A.7040004@gnupg.org> <52AF555D.30103@micahflee.com> <87eh5bd9q6.fsf@vigenere.g10code.de> <52B0D7D7.90609@micahflee.com> <52B1C005.6000700@gnupg.org> Message-ID: <52B1E262.9000704@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/18/2013 07:32 AM, Sam Tuke wrote: | On 18/12/13 00:01, Micah Lee wrote: |> The problem is you're wanting to make GnuPG go mainstream but then you end |> up with people seeing this: http://i.imgur.com/53nvUqm.png | | Yup. That should be avoided. However there are only a few pages that | critically need to be https it seems to me. Anywhere that source files are | provided clearly needs to be secure. Ideally the manual pages too. But the | front page has no need in my opinion. Well, completely aside from the fact that "encrypt everything you can" is a good default policy, providing a consistent user experience is a good reason to make https the only access method. At very least, making sure that if a user enters the site via https that they stay on https (protocol-agnostic links/URLs). A better question would be why would you not want to serve all the pages via https? Please don't say "higher CPU usage" because the difference is negligible on any modern system. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSseJiAAoJEFzGhvEaGryET34H/1CP9ZXka+/6Jh4RRu+bWHQy ye1aUJmqqsBG/hYlRi3Bz3UhmyLiQUtIE9CyiXx3cU88Cmb+u2MsoiLwasFxxRtU FIik1zi4iudnkpZOzKKzlHSe1rb8qvOCB4RUYX/E9F990mU5dCL02bKhHMbqIhjb +xkYGnje3bSv/kvEmPVb862tQD2k9fLswlAmdDtXClMbG6ZQyZv3olfZ87RpN2EC VZGx4FVIyVjnAlGmTs2/U5U6oMdzZp5ScAu4z2S2FwnGc98ZNn1JAzGNh8BlKVix lw/3Fhzovjhjbxvy/PxNN3prmgf2IOPvqkl3gvdt2xHkEg9KqBsaiL8/HBs7yz0= =m2a9 -----END PGP SIGNATURE----- From wk at gnupg.org Wed Dec 18 18:55:26 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 18:55:26 +0100 Subject: gpg-rsa-key decryption with a mobile In-Reply-To: <52B1DBFD.6060609@ioioioio.eu> (system@ioioioio.eu's message of "Wed, 18 Dec 2013 18:31:41 +0100") References: <52B1DBFD.6060609@ioioioio.eu> Message-ID: <874n6659ip.fsf@vigenere.g10code.de> On Wed, 18 Dec 2013 18:31, system at ioioioio.eu said: > "Here, we describe a new acoustic cryptanalysis key extraction attack, > applicable to GnuPG's current implementation of RSA. The attack can Well that is what I posted a few hours ago to this list ;-). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From samtuke at gnupg.org Wed Dec 18 19:12:26 2013 From: samtuke at gnupg.org (Sam Tuke) Date: Wed, 18 Dec 2013 19:12:26 +0100 Subject: GPG Blog: Getting Goteo approval Message-ID: <52B1E58A.7080502@gnupg.org> Getting Goteo approval ====================== Posted 18th December 2013 by Sam Tuke http://blog.gnupg.org/20131218-getting-goteo-approval.html The targets are set, the rewards are prepared, the press release has been edited and translated, and now we?re waiting for approval from the crowdfunding platform Goteo. Goteo is like indiegogo, but more forward thinking. It has a special focus on communal benefits and rewards - projects that benefit society as a whole, not just project donors (though they can get special rewards too). Every ?good? produced by a campaign on Goteo, be it artwork, software, event, or manufactured product, has a license assigned to it, like GPL or Creative Commons, and as well as asking for money, projects ask for other forms of help called ?non-economic needs?, like translations or product testing. Goteo?s own source code is Free Software too, meaning anyone can run their own Goteo crowdfunding server. That?s the feature that swung our decision to use it for GnuPG. Because the type of project on Goteo is quite specific however, the acceptance phase of launching crowdfunding is taking us longer than expected. Right now we?re working with Goteo?s small team to answer questions which aren?t on the webforms you fill out when you design your project with their system. I?m hoping to provide what?s necessary and get acceptance quickly. As soon as we have it the crowdfunding will launch and newsletter subscribers and Twitter followers will be the first to know. -- Sam Tuke Campaign Manager Gnu Privacy Guard Tel: +49 176 81923811 IM: samtuke at jabber.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 295 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Wed Dec 18 19:25:43 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 18 Dec 2013 10:25:43 -0800 Subject: Sharing/Storing a private key In-Reply-To: <52B1D317.2060000@digitalbrains.com> References: <52ADA792.2000800@digitalbrains.com> <52AF81B0.7080004@dougbarton.us> <52B1D317.2060000@digitalbrains.com> Message-ID: <52B1E8A7.3080603@dougbarton.us> On 12/18/2013 08:53 AM, Peter Lebbing wrote: > On 16/12/13 23:41, Doug Barton wrote: >> but one argument against what you're suggesting is that it's only as secure >> as the encryption used in step 1 of the hybrid approach. > > If only everything in cryptoland was "only as secure as 3DES"... I understand that you're not interested in an argument that the encryption of the entire secret may not be secure, but everything is secure right up until it isn't. (Robert, please ignore my tortuous use of "secure" in that sentence.) :) >> The ability to apply SSS to the entire secret would be quite valuable > > I don't see why. If this is because you avoid "insecurities in symmetric > crypto", I just don't buy it. Otherwise, please explain. Completely aside from the possibility (however remote) of the crypto failing, I'm also thinking of layer 9 issues that can come into play. For example I was the one who proposed using SSS to distribute portions of the root DNSSEC KSK to members of the community to provide a disaster recovery procedure should something catastrophic happen to ICANN. They didn't finish the root key protocol until after I left IANA, and what they ended up doing instead was using a HSM to store the key. But they did end up using SSS with members of the community to share the password for the HSM, for the same reason I proposed. If the HSM hadn't come into play the politically expedient thing to do would have been to distribute pieces of the secret, rather than pieces of the key used to encrypt the secret. Now I realize that most of the people on the list aren't interested in layer 9, but some of us live in a world where it is necessary to do so. :) >> although your concern about entropy use is something that should be addressed >> explicitly. > > And how do you propose to do that? I don't, I was suggesting that your concerns are valid and that the author of the new software is responsible for addressing them. Doug From rjh at sixdemonbag.org Wed Dec 18 20:26:45 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Dec 2013 14:26:45 -0500 Subject: Sharing/Storing a private key In-Reply-To: <52B1E8A7.3080603@dougbarton.us> References: <52ADA792.2000800@digitalbrains.com> <52AF81B0.7080004@dougbarton.us> <52B1D317.2060000@digitalbrains.com> <52B1E8A7.3080603@dougbarton.us> Message-ID: <52B1F6F5.7090401@sixdemonbag.org> On 12/18/2013 1:25 PM, Doug Barton wrote: > (Robert, please ignore my tortuous use of "secure" in that sentence.) :) Hey, I was being *nice*. I wasn't even pointing out that 3DES only has 112 bits of keyspace... ;) From dshaw at jabberwocky.com Wed Dec 18 20:51:28 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 18 Dec 2013 14:51:28 -0500 Subject: encryption algorithm In-Reply-To: <87ob4e8mql.fsf@vigenere.g10code.de> References: <52AF3A55.7080800@riseup.net> <20131216115752.Horde.U2Ra7YYNRCvqHNoUgsbfIw4__37089.444200001$1387223954$gmane$org@mail.sixdemonbag.org> <52AF88A0.1070406@riseup.net> <52AFAA27.2080304@sixdemonbag.org> <52B068C5.2010003@nycap.rr.com> <52B0773D.6020203@fifthhorseman.net> <52B07C5E.5030205@nycap.rr.com> <20131217090200.Horde.BIiC6wgAzxRbsKSzqpckNw9@mail.sixdemonbag.org> <52B08CC8.8000009@nycap.rr.com> <20131217102233.Horde.NvP9DMI09qf8zA0l-zQBsw5@mail.sixdemonbag.org> <52B0BAD2.6000807@fifthhorseman.net> <20131217140408.Horde.QqkmNAoZTBfiszT1LDEglw1@mail.sixdemonbag.org> <52B0E74E.3080206@fifthhorseman.net> <52B0F9F1.7020705@sixdemonbag.org> <87ob4e8mql.fsf@vigenere.g10code.de> Message-ID: On Dec 18, 2013, at 5:41 AM, Werner Koch wrote: > On Wed, 18 Dec 2013 02:27, rjh at sixdemonbag.org said: > >> because you just shifted to arguing that "since GnuPG defaults to >> AES-256, we need to use RSA-15000 by default otherwise the asymmetric > > FWIW: > > The rationale why we use the order AES256,192,128 is > for compatibility reasons with PGP. If gpg would > define AES128 first, we would get the somewhat > confusing situation: > > gpg -r pgpkey -r gpgkey ---gives--> AES256 > gpg -r gpgkey -r pgpkey ---gives--> AES > > PGP prefers AES256 for the simple reason that the marketing deptartment > told the engineering that 256 sounds stronger than 128 (according to one > of their lead developers). Plus the related reason why Camellia is ordered the same way: because it would look strange to have AES 256,192,128 and then Camellia 128,192,256 ! Now that we have the preference list scoring, though, the above change is no longer necessary. Instead of using the command line ordering, the score code handles it the same way regardless. In the above example, AES (not AES256) would be chosen no matter what the order. The rationale from back then was: /* Note the '<' here. This means in case of a tie, we will favor the lower algorithm number. We have a choice between the lower number (probably an older algorithm with more time in use), or the higher number (probably a newer algorithm with less time in use). Older is probably safer here, even though the newer algorithms tend to be "stronger". */ I don't think it's worth changing the default ranking back at this point though. David From oub at mat.ucm.es Wed Dec 18 18:23:54 2013 From: oub at mat.ucm.es (Uwe Brauer) Date: Wed, 18 Dec 2013 18:23:54 +0100 Subject: gpgsm, certificate expired, different certificate, epa does not encrypt References: <87d2ku78pj.fsf@mat.ucm.es> <86y53i2ip4.fsf@informationelle-selbstbestimmung-im-internet.de> Message-ID: <87vbymm5sl.fsf@mat.ucm.es> >> "Jens" == Jens Lechtenboerger writes: > On Mi, Dez 18 2013, Uwe Brauer wrote: >> I am using Xemacs, gnus the epa pkg for encrypting s/mime using gpgsm. >> > Hi Uwe, > if I understand you correctly, you fail to encrypt to your From > address, right? Not really, my from address is oub at mat.ucm.es the corresponding certificate is *NOT* expired. I have also a gmail account whose certificate is expired, but which does not play any role here. Or should not play any role here. > If I?m not mistaken, epa does not encrypt to From addresses by > default. What did you do to make that happen? > Does your gpgsm.conf contain ?encrypt-to? for the expired > certificate? No! Yuk there is indeed a line! :'( encrypt-to Why the hell is this line there? Maybe I did some testing and forgot about it. :-D Thanks very much Uwe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From mindiell at mindiell.net Wed Dec 18 21:51:23 2013 From: mindiell at mindiell.net (Mindiell) Date: Wed, 18 Dec 2013 21:51:23 +0100 Subject: Sharing/Storing a private key In-Reply-To: <52B1D317.2060000@digitalbrains.com> References: <52ADA792.2000800@digitalbrains.com> <52AF81B0.7080004@dougbarton.us> <52B1D317.2060000@digitalbrains.com> Message-ID: <52B20ACB.6000503@mindiell.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Well, I'm really sorry to have set up such a conversation :o) As I said earlier I'm not quite good at crypto-things, all I wanted to do was to protect my private key easily in case of HDD error. And all I wanted to do with this little tool was to share it with you. If you can explain to such a nooby-noob like me what matters, I'll try to do my best not to make you loose your time ;o) Mindiell, Le 18/12/2013 17:53, Peter Lebbing a ?crit : > On 16/12/13 23:41, Doug Barton wrote: >> but one argument against what you're suggesting is that it's only >> as secure as the encryption used in step 1 of the hybrid >> approach. > > If only everything in cryptoland was "only as secure as 3DES"... > >> The ability to apply SSS to the entire secret would be quite >> valuable > > I don't see why. If this is because you avoid "insecurities in > symmetric crypto", I just don't buy it. Otherwise, please explain. > >> although your concern about entropy use is something that should >> be addressed explicitly. > > And how do you propose to do that? You can't conjure up good > quality entropy. And if you don't trust symmetric crypto, you can't > use that to create an almost-random stream either. > > Peter. > - -- Mindiell -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKyCscACgkQUrT9WwBwY7zakQD/YTei8nEPmIL+aiPrF+lVqJPP POvkULr4DoDGA+bV63cA/2rUxaY8epxpdtbQtT44zEJ6fL6cwO3Go4jtRPy2LSNu =i3nj -----END PGP SIGNATURE----- From adrelanos at riseup.net Wed Dec 18 23:20:26 2013 From: adrelanos at riseup.net (adrelanos) Date: Wed, 18 Dec 2013 22:20:26 +0000 Subject: How much load are keyservers willing to handle? Message-ID: <52B21FAA.1000406@riseup.net> Hi, I am planing to write a script, which will refresh the apt signing key before updating using "apt-get update". The script might get accepted in Debian. [1] With my Whonix hat on, it's safe to say, that this script will be added to Whonix (which is a derivative of Debian). Writing that script would be much simpler if it could re-use the existing keyserver infrastructure. Now imagine if this gets added to Debian, that all users of Debian and all its derivatives will always refresh their signing key against keyservers? Could keyservers cope up with the load? The legal question would be interesting, but don't worry, if you ask me not to use keyservers for this, I'll use a mechanism outside of keyservers. Cheers, adrelanos [1] http://lists.debian.org/debian-security/2013/12/msg00031.html From jharris at widomaker.com Thu Dec 19 02:04:11 2013 From: jharris at widomaker.com (Jason Harris) Date: Wed, 18 Dec 2013 21:04:11 -0400 Subject: How much load are keyservers willing to handle? In-Reply-To: <52B21FAA.1000406@riseup.net> References: <52B21FAA.1000406@riseup.net> Message-ID: <20131219010411.GA22382@wave> On Wed, Dec 18, 2013 at 10:20:26PM +0000, adrelanos wrote: > I am planing to write a script, which will refresh the apt signing key > before updating using "apt-get update". The script might get accepted in > Debian. [1] With my Whonix hat on, it's safe to say, that this script > will be added to Whonix (which is a derivative of Debian). > > Writing that script would be much simpler if it could re-use the > existing keyserver infrastructure. Now imagine if this gets added to > Debian, that all users of Debian and all its derivatives will always > refresh their signing key against keyservers? Could keyservers cope up > with the load? > > The legal question would be interesting, but don't worry, if you ask me > not to use keyservers for this, I'll use a mechanism outside of keyservers. > [1] http://lists.debian.org/debian-security/2013/12/msg00031.html 1) setup your own DNS so you can shut things off if anything goes wrong! (you can use dyn.com or others, no servers required) 2) probably best discussed on the sks-devel list, Reply-To set accordingly 3) try running your own keyserver(s), SKS is easy enough to deploy -- Jason Harris | PGP: This _is_ PGP-signed, isn't it? jharris at widomaker.com _|_ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 314 bytes Desc: not available URL: From rjh at sixdemonbag.org Thu Dec 19 03:44:48 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 18 Dec 2013 21:44:48 -0500 Subject: How much load are keyservers willing to handle? In-Reply-To: <52B21FAA.1000406@riseup.net> References: <52B21FAA.1000406@riseup.net> Message-ID: <52B25DA0.2040407@sixdemonbag.org> > I am planing to write a script, which will refresh the apt signing key > before updating using "apt-get update". The question I have is, "What problem are you trying to solve?" I am certain that Debian Security already has a protocol in place for how to handle compromised certificates. Is this protocol flawed or lacking? What problem does it not address which this idea will solve? The next question is, "Why is it important the certificate be retrieved from the keyserver network?" When talking about the global apt repositories, it's likely they have access to multiple of orders of magnitude more bandwidth than the keyserver network. Why not host the signing key on the apt repo server? > Could keyservers cope up with the load? Good question. Probably, but some keyserver operators might view it as rude. Best to ask on sks-devel at nongnu.org. From adrelanos at riseup.net Thu Dec 19 04:42:31 2013 From: adrelanos at riseup.net (adrelanos) Date: Thu, 19 Dec 2013 03:42:31 +0000 Subject: How much load are keyservers willing to handle? In-Reply-To: <20131219010411.GA22382@wave> References: <52B21FAA.1000406@riseup.net> <20131219010411.GA22382@wave> Message-ID: <52B26B27.3090906@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Jason Harris: > On Wed, Dec 18, 2013 at 10:20:26PM +0000, adrelanos wrote: > >> I am planing to write a script, which will refresh the apt >> signing key before updating using "apt-get update". The script >> might get accepted in Debian. [1] With my Whonix hat on, it's >> safe to say, that this script will be added to Whonix (which is a >> derivative of Debian). >> >> Writing that script would be much simpler if it could re-use the >> existing keyserver infrastructure. Now imagine if this gets added >> to Debian, that all users of Debian and all its derivatives will >> always refresh their signing key against keyservers? Could >> keyservers cope up with the load? >> >> The legal question would be interesting, but don't worry, if you >> ask me not to use keyservers for this, I'll use a mechanism >> outside of keyservers. > >> [1] >> http://lists.debian.org/debian-security/2013/12/msg00031.html > > 1) setup your own DNS so you can shut things off if anything goes > wrong! (you can use dyn.com or others, no servers required) Interesting idea. I guess in that case I'll got with what I wrote under 3). > 2) probably best discussed on the sks-devel list, Reply-To set > accordingly Okay, I'll repost there. > 3) try running your own keyserver(s), SKS is easy enough to deploy I don't have a lot servers with bandwidth available. And rather than spending money on that, in case keyservers decline, I am probably re-using sourceforge.net's infrastructure. I already asked them once about a similar thing [they're willing to host our project news files (comparable small files with comparable load)], they'll most likely accept that as well. I don't know how they or some others manage it, but their traffic comes virtually for free. -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJSsmskXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5 QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7vRloP/i0vZRFCyQY7NBc1ZxPuVJpA PPiKuXODo/+jG/VX8krkYWaAIL9otCwrUMFlS0LxFYHvtfx03NaISaGG1WV3mWJA 1KiqODX+5RszCf/By4tW9JE1EdNeOjZM+XhPZ6oRMQogpmtVAe1EFIscQ84H3k0T SOcd4I//Q+7qkomhEu+C0crSogzzyvYRhG52a7IGDUCLRrhAc+CX0WbYqc5OZj5c qHGdDMPbhpa0/Z514pYuewUu4tQDc3NLZ1fpZGd6GeY3zC/grrLEtnbQogkjeiwB nIu90TC5yYGw8B9reJlfb6lq6s+QG/bs6yweHVg4oaa/i7Lfe9O6/WMshshuu62z sMt3eyAeXTyKFYPv9kugSFNkqGHWlDome3PJzYOqRE3BkxYU21qegzTfNUD50jpH pNVX5I7wSecpvNa3yIEE9000FDOdwvx/sJrEhmlY90J12BHZATJHQgcgq04GAPQT OL+kYRhifdS6BE7VXT2eHepQzviGScPZ09n+5ZpkX6nn/pcW84McUYg3qpam8OoU hGmcoJ0V5dnGNJjmzdMfeej1TsYKjE+uWpAod/lPnXHry/4FYTTSxrdfyfaRQOJx yd2DkcjZ0EzP/13DS8GxgH53FKiqxIQxjDhVyBNeSVnjB/f6TbuMJH3ZEl0FL3gn /ex0cwPRQ6lVxLtcpg8f =/K1w -----END PGP SIGNATURE----- From adrelanos at riseup.net Thu Dec 19 04:42:39 2013 From: adrelanos at riseup.net (adrelanos) Date: Thu, 19 Dec 2013 03:42:39 +0000 Subject: How much load are keyservers willing to handle? In-Reply-To: <52B25DA0.2040407@sixdemonbag.org> References: <52B21FAA.1000406@riseup.net> <52B25DA0.2040407@sixdemonbag.org> Message-ID: <52B26B2F.2050602@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Robert J. Hansen: >> I am planing to write a script, which will refresh the apt >> signing key before updating using "apt-get update". > > The question I have is, "What problem are you trying to solve?" What in case the apt signing key gets compromised. What is the mechanism of invalidating the client's keys so they can't fetch malicious files from any mirrors. > I am certain that Debian Security already has a protocol in place > for how to handle compromised certificates. Certainty is what sometimes makes the world an unsafe place. I would have supposed that this is the case as well, but after verifying such suppositions I was often quite surprised. > Is this protocol flawed or lacking? It is non-existent. See my original question [1] and also in my current discussion [2] someone would have stepped in and said "we already have this". Since this didn't happen and since I also looked through apt's sources, I am certain this thing doesn't exist. Can't prove it though, Russell's teapot you know. ;) > What problem does it not address which this idea will solve? When there is reason to believe, the apt signing key has been compromised, the revocation certificate can be spread through a channel other than apt updates (which are compromised). > The next question is, "Why is it important the certificate be > retrieved from the keyserver network?" It's not important. I didn't mean to say that. It's just simpler to code (for me, in the draft in my head). And if they don't mind, I'll go the easy way, if they mind, I'll come up with another solution. > When talking about the global apt repositories, it's likely they > have access to multiple of orders of magnitude more bandwidth than > the keyserver network. Yes. > Why not host the signing key on the apt repo server? They could of course re-use their existing mirror network for this. >> Could keyservers cope up with the load? > > Good question. Probably, but some keyserver operators might view > it as rude. Best to ask on sks-devel at nongnu.org. Will do. [1] http://lists.debian.org/debian-security/2013/10/msg00065.html [2] http://lists.debian.org/debian-security/2013/12/msg00031.html -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJSsmssXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5 QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7v26MP/R1TMYHHE6l0Ayhs6qZS3iGf fKDKM8qVfJUo/YBxAaYXVtfD6Ovs4jgKR7KXvy/xzsq4XdoDWMEgsZG3MLP+JiyS j3g7BEVns+55A/vPDysMUstrwQPhSBklnA+my3QG4UnDdKUjx8/m3jxWbMphe+sj fdMtOAquRCj72dIgtiYSYCfOnb9UN7EaEWrIyK57c9J5ygD6HTOjU4VoNKwLfHnf W8IAeTv4N1PDZIZ/dPteDkBYuCdgJgB+QAYh7yJ5AuCV1dhiTkip92PkE3+tCVHs /mufO9Ffy3mAtsD7U0H6Mq2rCqa8v3tHpraMROHdyuyAK1VJqbfveOkeKHjL2ocZ 2uJbAF/m/JmQFLPH/+V8siItg2qhYS2I6qhxE5RvS1FmbwPf/yvulSQQmaNJNPLE pxR7LbOAS9zUfJsy44r+t4n6N64qDmEBk6g+tRLMpn0MC8zfdSvZBxxWP9JVkWc1 C8JHeluKH8jrQbbLSBeG9Ie8WUMSmJpqfQLI6jK6sW2zXRA11VSSFNyPB48vsuZB 9kUtJ7ido0/npI/225JN/oQJ3RaTKj62OyDQSW8X4C4gMWFj8EZAvoSj/nKiKUtB RH1IJ8GBCsK1QR5Biia/KchYlAW+HKpJpOrn6C8Wm+ubBooYuK7csud5exWZLS+Q VAq22Rq6RdgitL1O/4OJ =O6my -----END PGP SIGNATURE----- From wk at gnupg.org Thu Dec 19 11:08:59 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Dec 2013 11:08:59 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign Message-ID: <87eh592lvo.fsf@vigenere.g10code.de> GnuPG encryption project launches crowdfunding campaign Today GNU Privacy Guard (GnuPG) has launched its first crowdfunding campaign [1] with the aim of building a new website and long term infrastructure. The 24.000 EUR target will fund: - Fresh web interfaces for gnupg.org including mobile - Completion and release of GnuPG 2.1 - Anonymous Tor network access to the website - A new user friendly download page suitable for all devices - A new server for web services - New pages convening external guides, videos, and handbooks - Facilities for processing recurring donations for long term project support Project founder and Lead Developer Werner Koch said ?GnuPG has seen a huge upsurge in popularity following recent state spying revelations. After 16 years of continuous development, we are now asking for community support to capitalise on consumer demand for privacy, and make GnuPG easy to access for mainstream audiences?. GnuPG is one of the few tools remaining above suspicion in the wake of leaked NSA documents. Edward Snowden and his contacts including Bruce Schneier switched to GnuPG when they began handling the secret documents earlier this year [2]. The Wall Street Journal, The Committee to Protect Journalists, and ProPublica [3] have all embraced GnuPG for protection of staff and sources. Phil Zimmermann, original inventor of Pretty Good Privacy (PGP), has also moved to GnuPG in wake of the news. ?GnuPG is a key part of modern privacy infrastructure? said Sam Tuke, Campaign Manager, GnuPG. ?Millions of users rely on GnuPG to work securely on servers, laptops and smartphones, but 2013 donations totaling 3.000 EUR to date have not even covered fixed costs. Supporting new algorithms like elliptical curve and fixing newfound exploits fast takes a lot of work which is done voluntarily. Now is the time for people to contribute to making GnuPG slick and more sustainable in future?. Jacob Appelbaum, Tor Project developer, added ?GnuPG is important - it allows us the assurances we need to do our work. Community funding is a critical part of a confident outlook for GnuPG in future.? For further information, please contact Sam Tuke. Email: samtuke [at] gnupg.org Phone: +49 176 81923811 [1] [2] [3] == About GNU Privacy Guard == GnuPG is a leading cryptography app that protects emails and data from interception. It is developed by a community of Free Software engineers led by Werner Koch. GnuPG is used and recommended by the world?s top security experts, including Bruce Schneier and Phil Zimmermann. It offers best in class privacy free of charge and restriction. Hundreds of companies have integrated GnuPG into their products to perform mission critical security, including Red Hat, Deutsche Bahn, and many others. http://gnupg.org -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From christophe.brocas at cnamts.fr Thu Dec 19 12:17:30 2013 From: christophe.brocas at cnamts.fr (Christophe Brocas) Date: Thu, 19 Dec 2013 12:17:30 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign In-Reply-To: <87eh592lvo.fsf@vigenere.g10code.de> References: <87eh592lvo.fsf@vigenere.g10code.de> Message-ID: <52B2D5CA.10006@cnamts.fr> Le 19/12/2013 11:08, Werner Koch a ?crit : > GnuPG encryption project launches crowdfunding campaign > > Today GNU Privacy Guard (GnuPG) has launched its first crowdfunding > campaign [1] with the aim of building a new website and long term > infrastructure. The 24.000 EUR target will fund: > > - Fresh web interfaces for gnupg.org including mobile > - Completion and release of GnuPG 2.1 1. this is an excellent news ! 2. take care about one point : It is not very clear on the website campaign that the completion of the GnuPG 2.1 is in the scope of the campaign. If it is really in the scope, it would be necessary to emphasize this point. According to me, for many people, giving money for GnuPG development and giving money for website refresh are not the same thing imho. For the moment, the description and the title of the campaign are quite focused on the website/infrastructure refresh. Bye Christophe > - Anonymous Tor network access to the website > - A new user friendly download page suitable for all devices > - A new server for web services > - New pages convening external guides, videos, and handbooks > - Facilities for processing recurring donations for long > term project support > > Project founder and Lead Developer Werner Koch said ?GnuPG has > seen a huge upsurge in popularity following recent state spying > revelations. After 16 years of continuous development, we are now > asking for community support to capitalise on consumer demand for > privacy, and make GnuPG easy to access for mainstream audiences?. > > GnuPG is one of the few tools remaining above suspicion in the wake > of leaked NSA documents. Edward Snowden and his contacts including > Bruce Schneier switched to GnuPG when they began handling the secret > documents earlier this year [2]. The Wall Street Journal, The > Committee to Protect Journalists, and ProPublica [3] have all embraced > GnuPG for protection of staff and sources. Phil Zimmermann, original > inventor of Pretty Good Privacy (PGP), has also moved to GnuPG in > wake of the news. > > ?GnuPG is a key part of modern privacy infrastructure? said Sam Tuke, > Campaign Manager, GnuPG. ?Millions of users rely on GnuPG to work > securely on servers, laptops and smartphones, but 2013 donations > totaling 3.000 EUR to date have not even covered fixed costs. > Supporting new algorithms like elliptical curve and fixing newfound > exploits fast takes a lot of work which is done voluntarily. Now is the > time for people to contribute to making GnuPG slick and more sustainable > in future?. > > Jacob Appelbaum, Tor Project developer, added ?GnuPG is important - it > allows us the assurances we need to do our work. Community funding is a > critical part of a confident outlook for GnuPG in future.? > > > For further information, please contact Sam Tuke. > Email: samtuke [at] gnupg.org > Phone: +49 176 81923811 > > > [1] > [2] > [3] > > == About GNU Privacy Guard == > > GnuPG is a leading cryptography app that protects emails and data from > interception. It is developed by a community of Free Software engineers > led by Werner Koch. GnuPG is used and recommended by the world?s top > security experts, including Bruce Schneier and Phil Zimmermann. It > offers best in class privacy free of charge and restriction. Hundreds of > companies have integrated GnuPG into their products to perform mission > critical security, including Red Hat, Deutsche Bahn, and many others. > > http://gnupg.org > > -- Christophe Brocas CNAMTS/DDSI/DS | 12, all?es Haussmann 33300 Bordeaux (fixe)+33 557.855.355 | (mobile)+33 677.051.901 | 3072R/0x0661CBBA ***************************************************** "Le contenu de ce courriel et ses eventuelles pi?ces jointes sont confidentiels. Ils s'adressent exclusivement ? la personne destinataire. Si cet envoi ne vous est pas destin?, ou si vous l'avez re?u par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre ? d'autres personnes ni le reproduire. Merci de le renvoyer ? l'?metteur et de le d?truire. Attention : L'Organisme de l'?metteur du message ne pourra ?tre tenu responsable de l'alt?ration du pr?sent courriel. Il appartient au destinataire de v?rifier que les messages et pi?ces jointes re?us ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses ?ventuelles pi?ces jointes sont celles de l'?metteur. Elles ne refl?tent pas la position de l'Organisme sauf s'il en est dispos? autrement dans le pr?sent courriel." ****************************************************** From ricul77 at gmail.com Thu Dec 19 13:45:42 2013 From: ricul77 at gmail.com (Richard Ulrich) Date: Thu, 19 Dec 2013 13:45:42 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign In-Reply-To: <87eh592lvo.fsf@vigenere.g10code.de> References: <87eh592lvo.fsf@vigenere.g10code.de> Message-ID: <1387457142.1836.18.camel@XPS13dev> As this is about a crypto project, wouldn't it be adequate to accept payments in crypto currencies? Rgds Richard On Don, 2013-12-19 at 11:08 +0100, Werner Koch wrote: > GnuPG encryption project launches crowdfunding campaign > > Today GNU Privacy Guard (GnuPG) has launched its first crowdfunding > campaign [1] with the aim of building a new website and long term > infrastructure. The 24.000 EUR target will fund: > > - Fresh web interfaces for gnupg.org including mobile > - Completion and release of GnuPG 2.1 > - Anonymous Tor network access to the website > - A new user friendly download page suitable for all devices > - A new server for web services > - New pages convening external guides, videos, and handbooks > - Facilities for processing recurring donations for long > term project support > > Project founder and Lead Developer Werner Koch said ?GnuPG has > seen a huge upsurge in popularity following recent state spying > revelations. After 16 years of continuous development, we are now > asking for community support to capitalise on consumer demand for > privacy, and make GnuPG easy to access for mainstream audiences?. > > GnuPG is one of the few tools remaining above suspicion in the wake > of leaked NSA documents. Edward Snowden and his contacts including > Bruce Schneier switched to GnuPG when they began handling the secret > documents earlier this year [2]. The Wall Street Journal, The > Committee to Protect Journalists, and ProPublica [3] have all embraced > GnuPG for protection of staff and sources. Phil Zimmermann, original > inventor of Pretty Good Privacy (PGP), has also moved to GnuPG in > wake of the news. > > ?GnuPG is a key part of modern privacy infrastructure? said Sam Tuke, > Campaign Manager, GnuPG. ?Millions of users rely on GnuPG to work > securely on servers, laptops and smartphones, but 2013 donations > totaling 3.000 EUR to date have not even covered fixed costs. > Supporting new algorithms like elliptical curve and fixing newfound > exploits fast takes a lot of work which is done voluntarily. Now is the > time for people to contribute to making GnuPG slick and more sustainable > in future?. > > Jacob Appelbaum, Tor Project developer, added ?GnuPG is important - it > allows us the assurances we need to do our work. Community funding is a > critical part of a confident outlook for GnuPG in future.? > > > For further information, please contact Sam Tuke. > Email: samtuke [at] gnupg.org > Phone: +49 176 81923811 > > > [1] > [2] > [3] > > == About GNU Privacy Guard == > > GnuPG is a leading cryptography app that protects emails and data from > interception. It is developed by a community of Free Software engineers > led by Werner Koch. GnuPG is used and recommended by the world?s top > security experts, including Bruce Schneier and Phil Zimmermann. It > offers best in class privacy free of charge and restriction. Hundreds of > companies have integrated GnuPG into their products to perform mission > critical security, including Red Hat, Deutsche Bahn, and many others. > > http://gnupg.org > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From md123 at nycap.rr.com Thu Dec 19 14:25:31 2013 From: md123 at nycap.rr.com (Matt D) Date: Thu, 19 Dec 2013 08:25:31 -0500 Subject: What is the latest version In-Reply-To: <87eh592lvo.fsf@vigenere.g10code.de> References: <87eh592lvo.fsf@vigenere.g10code.de> Message-ID: <52B2F3CB.7050509@nycap.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am running enigmail 1.5.2 . Is this old? How can I get the latest? Thanks! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsvPLAAoJECrdp7MWSIVbdCgH/1YSseWaWgppLHseMmpN36qW OuiYuGKhctDl/J6EnIvan0RrRoCaixCl57or/xGs3kxgzJYfCnGkIHjpjjOzYfDh lWNHWaFPRoPezjMc/08+TiPz5Ez3SNnI0DKbwlzHBSwyP0HLCUYEkTzEC6I8ndio ZSGZ531beDLyevnakT9pUsuof8XaqdDA/RFbPsqq99mYFc61ZMRImlukXFVENre8 cfwQWbyAjhcDQ2uxCuZBvXRB/eKjh7/FNswuacO5gxaUtJNcTAixPH7UkkmZHCbf v3mbMOk+UjhV/GApGHkFbwJq6P4T8uTyfRk2qCjOtsLHCJp91CQQAFhHOODMzbE= =5ULF -----END PGP SIGNATURE----- From gollo at fsfe.org Thu Dec 19 14:31:01 2013 From: gollo at fsfe.org (Martin Gollowitzer) Date: Thu, 19 Dec 2013 14:31:01 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign In-Reply-To: <1387457142.1836.18.camel@XPS13dev> References: <87eh592lvo.fsf@vigenere.g10code.de> <1387457142.1836.18.camel@XPS13dev> Message-ID: <20131219133101.GC4089@platinum.gollo.at> * Richard Ulrich [131219 13:47, mID <1387457142.1836.18.camel at XPS13dev>]: > As this is about a crypto project, wouldn't it be adequate to accept > payments in crypto currencies? I wouldn't consider this a priority. Bitcoin violates one of the fundamental laws of economics and is therefore supposed to crash at some point. Choosing goteo was IMHO a good idea because their system is Free Software and I don't know if they even support BTC et al. Just my ?0,02 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: Digital signature URL: From wk at gnupg.org Thu Dec 19 14:43:26 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Dec 2013 14:43:26 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign In-Reply-To: <1387457142.1836.18.camel@XPS13dev> (Richard Ulrich's message of "Thu, 19 Dec 2013 13:45:42 +0100") References: <87eh592lvo.fsf@vigenere.g10code.de> <1387457142.1836.18.camel@XPS13dev> Message-ID: <87lhzh0xdt.fsf@vigenere.g10code.de> On Thu, 19 Dec 2013 13:45, ricul77 at gmail.com said: > As this is about a crypto project, wouldn't it be adequate to accept > payments in crypto currencies? Agreed. However, we don't have the resources to do that. The new infrastructure topic covers payment options and likely we will accept Bitcoins then. The funding platform seems not to support it yet. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 19 14:45:51 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Dec 2013 14:45:51 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign In-Reply-To: <52B2D5CA.10006@cnamts.fr> (Christophe Brocas's message of "Thu, 19 Dec 2013 12:17:30 +0100") References: <87eh592lvo.fsf@vigenere.g10code.de> <52B2D5CA.10006@cnamts.fr> Message-ID: <87haa50x9s.fsf@vigenere.g10code.de> On Thu, 19 Dec 2013 12:17, christophe.brocas at cnamts.fr said: > It is not very clear on the website campaign that the completion of the GnuPG > 2.1 is in the scope of the campaign. GnuPG 2.1 will be ready with the new website or even earlier. However, 2.1 won't immediately replace 2.0 (or 1.4) on all platforms I expect that this takes some time. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Thu Dec 19 15:07:57 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 19 Dec 2013 09:07:57 -0500 Subject: What is the latest version In-Reply-To: <52B2F3CB.7050509@nycap.rr.com> References: <87eh592lvo.fsf@vigenere.g10code.de> <52B2F3CB.7050509@nycap.rr.com> Message-ID: <52B2FDBD.5090301@sixdemonbag.org> On 12/19/2013 8:25 AM, Matt D wrote: > I am running enigmail 1.5.2 . Is this old? How can I get the > latest? Thanks! The latest Enigmail is 1.6. 1.5.2 is not tremendously old, but it's not the latest-and-greatest, either. Given that you got GnuPG and Enigmail from GPGtools, your best bet is to ask the GPGtools maintainers (politely!) to update the version of Enigmail they include with GPGtools. From wk at gnupg.org Thu Dec 19 15:42:49 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Dec 2013 15:42:49 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign In-Reply-To: <20131219133101.GC4089@platinum.gollo.at> (Martin Gollowitzer's message of "Thu, 19 Dec 2013 14:31:01 +0100") References: <87eh592lvo.fsf@vigenere.g10code.de> <1387457142.1836.18.camel@XPS13dev> <20131219133101.GC4089@platinum.gollo.at> Message-ID: <874n64297a.fsf@vigenere.g10code.de> On Thu, 19 Dec 2013 14:31, gollo at fsfe.org said: > point. Choosing goteo was IMHO a good idea because their system is Free > Software and I don't know if they even support BTC et al. Indeed. After all crowd funding is about community building and thus I consider it the Right Thing to help each other. Goteo is mainly used in Spain but it is worth to get better known. Agreed there a a couple of problems, like missing translations but Goteo has evolved much enough since we first looked at in September, to assume that the remaining problems will soon be fixed. The privacy policy and the terms or services are not translated to English - this is an unfortunate oversight of us. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From olav at enigmail.net Thu Dec 19 17:22:05 2013 From: olav at enigmail.net (Olav Seyfarth) Date: Thu, 19 Dec 2013 17:22:05 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign In-Reply-To: <87eh592lvo.fsf@vigenere.g10code.de> References: <87eh592lvo.fsf@vigenere.g10code.de> Message-ID: <52B31D2D.8030108@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hi Werner, am 19.12.2013 11:08, schrieb Werner Koch: > Today GNU Privacy Guard (GnuPG) has launched its first crowdfunding > campaign [1] with the aim of building a new website and long term > infrastructure. The 24.000 EUR target ... congratulations, 6 hours after your post, nearly half of that target is pledged. One note: apart from the data privacy statement being not available in english, my concern is invoices - I am self-employed and can just pledge without invoice, but most companies cannot. In the process, I only got the following receipt: FUNDACION FUENTES ABIERTAS (logo) On-line shopping (some other logo) Operation AUTHORIZED Operation number: Amount: 35.00 Euros (check mark) Card Payment Data that identifies the operation: (printer symbol) Operation number: Amount: 35.00 Euros Date / Time: 19/12/2013