From aeopare at gmail.com Thu Jan 2 13:34:16 2014 From: aeopare at gmail.com (Edwin A. Opare) Date: Thu, 2 Jan 2014 12:34:16 +0000 Subject: ePGP extension for mobile In-Reply-To: <52C2F7D4.2010207@enigmail.net> References: <52C1EB1D.6090407@vulcan.xs4all.nl> <52C22430.7020904@enigmail.net> <52C2F7D4.2010207@enigmail.net> Message-ID: Olav, All: Thanks for your valuable feedback. Kindly take a look at these lines from http://www.egpg.org/?page=About: - eGPG utilizes a centralized GnuPG installation and key-ring for encrypting and decrypting files, not a new concept, but it eliminates the need for key-ring importation after the client installation in an enterprise environment, while increasing key security. - eGPG eliminates the security risk of the public exposure of the private key. Using the centralized key-ring the client and user only has access to the private key for decryption only. The private key sits on your locked and secure server, not on the user's machine. Most of the email users in my buddy's environment receive and send emails on phone as much as on PC. Since they are unable to import their *private keys* to their mobile devices as the keys are centrally managed and locked on a server etc, how then do they *decrypt* *encrypted messages* they sent earlier from PC to partners/colleagues/self on their mobile devices ? How do they sign new emails they send from their mobile devices? I hope I could get some help on these. Many thanks Best, Edwin On Tue, Dec 31, 2013 at 4:59 PM, Olav Seyfarth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Hi Edwin, > > > [...] The current ePGP tool as-is is more of desktop solution. [...] Is > > there an Enterprise PGP solution for mobile devices running Android/iOS? > > you mean something that does not only work as plugin for default > Android/iOS > Mail apps but also full device encryption and/or file encryption? > Unfortunately > no, none that I know of. Multiple company requests might lead Symantec > product > development to implement one, though. > > I see solutions like "Good for Enterprise" and the use of encrypted > transport > (TLS) in companies. No company I know of uses either OpenPGP or S/MIME on > mobile > devices yet. But why not employing the OS device encryption and store > messages > encryptedly using one of the apps mentioned? If enterprise grade support is > vital, go ask the developer. Or Apple/Samsung/... ;-) > > Olav > - -- > The Enigmail Project - OpenPGP Email Security For Mozilla Applications > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/ > > iQGcBAEBAwAGBQJSwvfIAAoJEKGX32tq4e9WgS0L/2G8yO6FE1KABA52f8wNfXEa > Muli3Hwf4I5XI8ceoX7M95zASMVuOyBjpne2S+2A5em4P+JJgNwoiyz/nlPiL+Fk > pAnk7HNYyeUX/+p4tGv1mAJz1diH7Pg5VG0KZynqGHu/UvxLV6onLRqNCPlc5Gdz > 6YEuTpGw5MJ/CHdFOfVSPjmwtIehTWHgh1joxbEQeAMdNL6wmLonI7zTo+0h5Dtk > m3EsITTbn3/elz62qbgLiT9zfpIDINomdLt+nGda2l1TRY2RR4Jo7KgOpYd688hF > ZzAkrceY3VvpIWjSCDpIv2fNxSYpHUkG9sqEc77qBbcMhozO+W3Dvk+wfUlmGiGF > UUiWoThE0hapVWqbIQBOXSfL8rPkskl68i3eOLDLcXD+z6DTIUJTfqwmBiA/daMk > C9vX20uS6DhkSEVTNJPwWfEP4KF7WKc9YqSbQLFmnuPh6PbntD+ivovPBuHJh94s > txB7TaNOIn8BA7iOQaAdo7m7vKXOKDtt1OhJev6shg== > =wBAF > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 olav at enigmail.net Thu Jan 2 16:04:14 2014 From: olav at enigmail.net (Olav Seyfarth) Date: Thu, 02 Jan 2014 16:04:14 +0100 Subject: ePGP extension for mobile In-Reply-To: References: <52C1EB1D.6090407@vulcan.xs4all.nl> <52C22430.7020904@enigmail.net> <52C2F7D4.2010207@enigmail.net> Message-ID: <52C57FEE.3080007@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hi Edwin, IN SHORT To your question: I don't think there is a "mobile solution" for ePGP available. LONG ANSWER I wasn't aware that you referred to a product. I interpreted "Enterprise PGP" as (any) enterpsise-grade OpenPGP-Implemenation. I apologize for that confusion. While I see the benefit of centralized PGP implementations, I personally would not use epgp.org any more since it seems to be abandoned: the last build is from April 2007 - almost 7 years old. No (security relevant) bugs found since then? I don't know the product. I see no mail client integration in the screenshots, so I assume it works similar to http://www.symantec.com/gateway-email-encryption and http://www.zertificon.com/produkte/z1-securemail-gateway/ . In security gateways, messages get signed/verified/en-/decrypted on the server. Thus, messages behind that gateway (in the 'local network') travel unprotected. (Usual transport layer security such as TLS should be applied though.) Additional thoughts/ideas: To access Mail from mobile devices, one way would be to have a VPN connection to the mail server /behind/ the security gateway, leaving you with unencrypted messages on the phones. You might use a special app that uses phone-independent protected storage (such as R2Mail2), or put yor company mail app inside some secured container (such as Good for Enterprise). Or you might set up additional key pairs for each mobile device and push all incoming messages to special (even publicly available) 'mobile devices accounts'. You'd have to provision the corresponding key pair to each phone and may use any (unprotected) mail app. Olav - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/ iQGcBAEBAwAGBQJSxX/hAAoJEKGX32tq4e9WoWIMAJgyX8zyIfLPE/ZL+i/R6rOj sDMMTDuO/gDL3JBd/lwZugLnk2oA1Mym5bT8xAX28wjKGx7/EFpMByBALLNB2AY6 Ir/nkHcPwGF7FGzr9wsdD9wnsEN7co8KbaAbJEh7488dgJEkaxhUImAWZ6WEtMb8 AseE/jN18drFKRLk1uma6HrlTl0EFRco1I9pEKk9J8qgPiYuzFGJVhgRtNN1C/4a X2qN3qjpNODOp1cd+CvLQFaa8RO/SefTEiwDLE5U3/zZphS4WEzXAwivAixdF6d8 Tsi9LoKHrVP2BmitaErUh6xWQCK4lNqyylz3F8DNc2PCv+vjs94d9mNJ24v+GKs6 xBPqJQ/Lg0RKyWNNd1r7mndL70tWKp9D+9C6v1k5V9ohwWYY5qlWqkar9g35kLaD NS7V2V0aKF1yyBy1DUP0Z/xKNMOZFLtKvdMu/w2cQQeeZTP2aOB+jJq7p9zyqz2x C+msM9NNj6/IiidhmsN/bm3NfEXqIoylXi61f6ZESA== =9ofq -----END PGP SIGNATURE----- From wk at gnupg.org Thu Jan 2 16:29:10 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Jan 2014 16:29:10 +0100 Subject: deleting secret key not implemented In-Reply-To: <52C2CFB1.9010306@gmail.com> (NdK's message of "Tue, 31 Dec 2013 15:07:45 +0100") References: <1388481700.25952.4.camel@mepc.speedy.local> <52C2CB75.7090809@sumptuouscapital.com> <52C2CFB1.9010306@gmail.com> Message-ID: <87sit6xv09.fsf@vigenere.g10code.de> On Tue, 31 Dec 2013 15:07, ndk.clanbo at gmail.com said: > Maybe I'm missing something... What happens if keys are kept on smartcard? Deleting the key on the smartcard depends on the smartcard. The ~/.gnupg/private-keys-v1.d/XXXX...XX.key for a smartcard based key is only a stub storing the serial number of the card for user convenience (?please insert card no. NNN?). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From vedaal at nym.hush.com Thu Jan 2 18:38:56 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Thu, 02 Jan 2014 12:38:56 -0500 Subject: Gpg4Win // GnuPG 2.x Message-ID: <20140102173856.4379220387@smtp.hushmail.com> Am using Gpg4win 2.2.1 /GnuPG 2.0.22 Did gpg --dump-options and noticed that the --faked-system-time option is not listed. Was this option removed? vedaal From roam at ringlet.net Thu Jan 2 17:11:33 2014 From: roam at ringlet.net (Peter Pentchev) Date: Thu, 2 Jan 2014 18:11:33 +0200 Subject: Bug: --list-packets ignores second public key In-Reply-To: <1929039.26yMQMaxou@inno.berlin.laging.de> References: <1929039.26yMQMaxou@inno.berlin.laging.de> Message-ID: <20140102161132.GA7799@straylight.m.ringlet.net> On Mon, Dec 23, 2013 at 09:07:08PM +0100, Hauke Laging wrote: > Hello, > > I was just in a slightly embarrassing situation: I had a look with > gpg --list-packets > at the certificate(s) on > http://www.westphal.de/index.php?id=18 > > This is the (shortened) output: > :public key packet: > [...] > :user ID packet: > :signature packet: > [...] > :signature packet: > [...] > :user ID packet: > :signature packet: > [...] > :signature packet: > [...] > :user ID packet: > :signature packet: > [...] > :signature packet: > [...] > > So I told the site owner that there was (in contrast to his statement above) > just one certificate on the page. I had to realize that gpg sees both public > keys when importing the block instead. Hm, which version of GnuPG are you using? With both 1.4.15 and 2.0.22 on my Debian GNU/Linux system I can see a second 'public key packet': [roam at straylight ~/tmp/v/roam/pgp]$ gpg --list-packets foo.txt | egrep -ve '^[[:space:]]' :public key packet: :user ID packet: "Christian Westphal (always use together with 0x73C0BB28) " :signature packet: algo 1, keyid 1AC1BFC93FFF6951 :signature packet: algo 1, keyid A642416973C0BB28 :user ID packet: "Christian Westphal " :signature packet: algo 1, keyid 1AC1BFC93FFF6951 :signature packet: algo 1, keyid 1AC1BFC93FFF6951 :user ID packet: "Christian Westphal " :signature packet: algo 1, keyid 1AC1BFC93FFF6951 :signature packet: algo 1, keyid A642416973C0BB28 :public sub key packet: :signature packet: algo 1, keyid 1AC1BFC93FFF6951 :public sub key packet: :signature packet: algo 1, keyid 1AC1BFC93FFF6951 :public key packet: :user ID packet: "Christian Westphal " :signature packet: algo 1, keyid A642416973C0BB28 :user ID packet: "Christian Westphal (always use together with 0x3FFF6951) " :signature packet: algo 1, keyid A642416973C0BB28 :signature packet: algo 1, keyid 1AC1BFC93FFF6951 :public sub key packet: :signature packet: algo 1, keyid A642416973C0BB28 :public sub key packet: :signature packet: algo 1, keyid A642416973C0BB28 [roam at straylight ~/tmp/v/roam/pgp]$ The 15th line of the output is ':public key packet:'. G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at FreeBSD.org p.penchev at storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If I had finished this sentence, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From eagleeyes426 at yahoo.com Thu Jan 2 18:54:32 2014 From: eagleeyes426 at yahoo.com (Peter Humphreys) Date: Fri, 03 Jan 2014 01:54:32 +0800 Subject: Can't decrypt message encrypted with ECC In-Reply-To: <52C2CB75.7090809@sumptuouscapital.com> References: <1388481700.25952.4.camel@mepc.speedy.local> <52C2CB75.7090809@sumptuouscapital.com> Message-ID: <1388685272.31714.5.camel@mepc.speedy.local> I have created a test ECC 25519 subkey. If I encrypt a file & sign a file to myself with gpg2 -esa some_text.file it encrypts fine. But when trying gpg2 -v some_text.file.asc I get the following error: gpg: MyBuild gpg: armor header: Version: GnuPG v2 gpg: public key is 3EF4BBBB gpg: using subkey 3EF4BBBB instead of primary key D236473E gpg: encrypted with 256-bit ECC key, ID 3EF4BBBB, created 2014-01-02 "Peter Michael Humphreys (My Master Key RSA) " gpg: decryption failed: No secret key When listing my secret keys I get a # symbol next to the above key in question is that normal? ssb# 256e/3EF4BBBB 2014-01-02 Ed25519 [expires: 2015-01-02] Regards, Peter From mailinglisten at hauke-laging.de Thu Jan 2 23:39:02 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 02 Jan 2014 23:39:02 +0100 Subject: Bug: --list-packets ignores second public key In-Reply-To: <20140102161132.GA7799@straylight.m.ringlet.net> References: <1929039.26yMQMaxou@inno.berlin.laging.de> <20140102161132.GA7799@straylight.m.ringlet.net> Message-ID: <11576339.q8q0MIDRIJ@inno.berlin.laging.de> Am Do 02.01.2014, 18:11:33 schrieb Peter Pentchev: > > So I told the site owner that there was (in contrast to his statement > > above) just one certificate on the page. I had to realize that gpg sees > > both public keys when importing the block instead. > > Hm, which version of GnuPG are you using? With both 1.4.15 and 2.0.22 > on my Debian GNU/Linux system I can see a second 'public key packet': Thanks for checking. I use 2.0.19 but that is not the point. For some strange reason it works now here, too. I am not aware of changes. Strange. 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 Fri Jan 3 06:35:28 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 03 Jan 2014 06:35:28 +0100 Subject: sign encrypted emails Message-ID: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> Hello, this is not a GnuPG problem. GnuPG is capable of doing what I want. But I am interested in your opinion. I just noticed that you can easily be deluded about an email being encrypted: That you receive an encrypted mail does not mean that it was sent encrypted. An adversary may encrypt a non-encrypted message (which he has intercepted) in order to create more trust in the message for the recipient: If you receive critical information and are aware that it has not been encrypted then you may react differently from the case where you are sure that is was encrypted. Or similar: A message is encrypted to a low security key which has been compromised (unnoticed by the recipient). The adversary decrypts the message ans reencrypts it to a more secure key. This can be detected by asking the sender (which noone would do every time) or by signing the encrypted message (this may mean that you sign it twice: once before and once after encryption). I would like to ask mail client developers to add this feature. But before I would like to hear opinions whether that makes sense. >From the RfC perspective (PGP/MIME) this should not be a problem; you just need another level of nesting. Maybe the mail clients are not even prepared for reading such messages. That would not surprise me but would not be an argument against one client implementing this as the first one. I am interested in general arguments for and against this. I have tried to create a test file. Unfortunately I am not sure whether I have done that correctly. I am familiar with checking MIME signatures with gpg directly but creating a message is a different story: http://www.crypto-fuer-alle.de/docs/sign-encrypt-sign/demo.mbox KMail ignores the outer signature layer in its main window but shows the structure correctly in the lower part of the window. That could mean that my file is correct but KMail not prepared to display it correctly. Enigmail tells me that might be a signed message but doesn't show anything. If I encrypt some text manually and paste it as body content in a PGP/MIME mail which gets signed and encrypted then KMail shows all three layers in its main window. This could indicate that KMail is capable of handling three layers but that my test file is incorrect. 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 aeopare at gmail.com Fri Jan 3 09:14:45 2014 From: aeopare at gmail.com (Edwin A. Opare) Date: Fri, 3 Jan 2014 08:14:45 +0000 Subject: ePGP extension for mobile In-Reply-To: <52C57FEE.3080007@enigmail.net> References: <52C1EB1D.6090407@vulcan.xs4all.nl> <52C22430.7020904@enigmail.net> <52C2F7D4.2010207@enigmail.net> <52C57FEE.3080007@enigmail.net> Message-ID: Thanks once again for the feedback. Best, Edwin On Thu, Jan 2, 2014 at 3:04 PM, Olav Seyfarth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Hi Edwin, > > IN SHORT > > To your question: I don't think there is a "mobile solution" for ePGP > available. > > > LONG ANSWER > > I wasn't aware that you referred to a product. I interpreted "Enterprise > PGP" as > (any) enterpsise-grade OpenPGP-Implemenation. I apologize for that > confusion. > > While I see the benefit of centralized PGP implementations, I personally > would > not use epgp.org any more since it seems to be abandoned: the last build > is from > April 2007 - almost 7 years old. No (security relevant) bugs found since > then? > > I don't know the product. I see no mail client integration in the > screenshots, > so I assume it works similar to > http://www.symantec.com/gateway-email-encryption > and http://www.zertificon.com/produkte/z1-securemail-gateway/ . > > In security gateways, messages get signed/verified/en-/decrypted on the > server. > Thus, messages behind that gateway (in the 'local network') travel > unprotected. > (Usual transport layer security such as TLS should be applied though.) > > > > Additional thoughts/ideas: > > To access Mail from mobile devices, one way would be to have a VPN > connection > to the mail server /behind/ the security gateway, leaving you with > unencrypted > messages on the phones. You might use a special app that uses > phone-independent > protected storage (such as R2Mail2), or put yor company mail app inside > some > secured container (such as Good for Enterprise). > > Or you might set up additional key pairs for each mobile device and push > all > incoming messages to special (even publicly available) 'mobile devices > accounts'. You'd have to provision the corresponding key pair to each phone > and may use any (unprotected) mail app. > > > > Olav > - -- > The Enigmail Project - OpenPGP Email Security For Mozilla Applications > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/ > > iQGcBAEBAwAGBQJSxX/hAAoJEKGX32tq4e9WoWIMAJgyX8zyIfLPE/ZL+i/R6rOj > sDMMTDuO/gDL3JBd/lwZugLnk2oA1Mym5bT8xAX28wjKGx7/EFpMByBALLNB2AY6 > Ir/nkHcPwGF7FGzr9wsdD9wnsEN7co8KbaAbJEh7488dgJEkaxhUImAWZ6WEtMb8 > AseE/jN18drFKRLk1uma6HrlTl0EFRco1I9pEKk9J8qgPiYuzFGJVhgRtNN1C/4a > X2qN3qjpNODOp1cd+CvLQFaa8RO/SefTEiwDLE5U3/zZphS4WEzXAwivAixdF6d8 > Tsi9LoKHrVP2BmitaErUh6xWQCK4lNqyylz3F8DNc2PCv+vjs94d9mNJ24v+GKs6 > xBPqJQ/Lg0RKyWNNd1r7mndL70tWKp9D+9C6v1k5V9ohwWYY5qlWqkar9g35kLaD > NS7V2V0aKF1yyBy1DUP0Z/xKNMOZFLtKvdMu/w2cQQeeZTP2aOB+jJq7p9zyqz2x > C+msM9NNj6/IiidhmsN/bm3NfEXqIoylXi61f6ZESA== > =9ofq > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 dougb at dougbarton.us Fri Jan 3 09:33:51 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 03 Jan 2014 00:33:51 -0800 Subject: sign encrypted emails In-Reply-To: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> Message-ID: <52C675EF.4020008@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/02/2014 09:35 PM, Hauke Laging wrote: | I just noticed that you can easily be deluded about an email being | encrypted: That you receive an encrypted mail does not mean that it | was sent encrypted. An adversary may encrypt a non-encrypted message | (which he has intercepted) in order to create more trust in the | message for the recipient: If you receive critical information and | are aware that it has not been encrypted then you may react | differently from the case where you are sure that is was encrypted. This threat model doesn't make a lot of sense, except for very naive users who cannot distinguish the importance of a message that is encrypted vs. a message (encrypted or not) which is signed. If the user is not sophisticated enough to place the proper importance on a signature for the message itself; they are rather unlikely to care about signatures inside and outside the encryption. | Or similar: A message is encrypted to a low security key which has | been compromised (unnoticed by the recipient). The adversary decrypts | the message ans reencrypts it to a more secure key. This threat model makes no sense at all. It is the recipient's key that the message is encrypted TO. And again, the recipient should be verifying the signature on the message itself, and placing the proper importance on that. Have I missed some otherwise hidden value to your proposal? Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSxnXvAAoJEFzGhvEaGryEfGwH+gLr5xm6sV1l067eiyo1p2JI 2e8YYhr8DZL4+cju29nMnlf657rmHmDgqzAQhQMK1TadnVAEi/xubjximK76NHpS 5RWkW6arDvq9pYMHHHDMihpvgJdwPYDg5XJ3ZoCmjYHAjOHY+2fqW1QxxxcmloHT shSTtV/N2ZwGRTg3sKyQ6K6Bp8be45la7iiUXy/qwZTa86a3/A9t3FoxYxpqlq31 jLmofWYw0O+MxnNHWO6YuDOpjqDvdIkcwbQ/0P+48uYxCrzBj/vwj1dR5q4pclJD UtC3TNrQdEgOLmQZAYvOAN+z5brKXVIBBA1ckxf5TGP0kDNo0AOV+OyH9Ljo0Nw= =wBkw -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Fri Jan 3 09:59:26 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 03 Jan 2014 09:59:26 +0100 Subject: sign encrypted emails In-Reply-To: <52C675EF.4020008@dougbarton.us> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> Message-ID: <1843210.iObAQBZGL1@inno.berlin.laging.de> Am Fr 03.01.2014, 00:33:51 schrieb Doug Barton: > On 01/02/2014 09:35 PM, Hauke Laging wrote: > | I just noticed that you can easily be deluded about an email being > | encrypted: That you receive an encrypted mail does not mean that it > | was sent encrypted. An adversary may encrypt a non-encrypted message > | (which he has intercepted) in order to create more trust in the > | message for the recipient: If you receive critical information and > | are aware that it has not been encrypted then you may react > | differently from the case where you are sure that is was encrypted. > > This threat model doesn't make a lot of sense, except for very naive > users who cannot distinguish the importance of a message that is > encrypted vs. a message (encrypted or not) which is signed. I am quite sure you have misunderstood something. Sorry if I didn't make myself clear. Do you agree that it is (or, depending on the content, can be) an important information whether a message was encrypted by the sender (and for which key)? How can it make little sense to provide this information? Whether it is more important to encrypt a message or to sign it differs a lot with the content. Thus I do not understand your explanation of importance. This is similar to SSL/TLS without client negotiation: The client knows (or: can know) whether it is encrypting for the right server. But the server cannot know whether the legitimate client has started the connection or an MitM attacker. If the server demands certainty about that then it has to require the use of client certificates. But currently there is (AFAIK) no such thing as an analog for the client certificate in the OpenPGP world. The certificate itself is already there, of course, but it is not yet used in a way providing security for the recipient about the confidentiality of the message. 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 Fri Jan 3 10:13:13 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 03 Jan 2014 01:13:13 -0800 Subject: sign encrypted emails In-Reply-To: <1843210.iObAQBZGL1@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <1843210.iObAQBZGL1@inno.berlin.laging.de> Message-ID: <52C67F29.3000103@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FYI, your client has horrible line wrapping. If there is a setting, please change it to 72 columns. On 01/03/2014 12:59 AM, Hauke Laging wrote: | Do you agree that it is (or, depending on the content, can be) an | important information whether a message was encrypted by the sender | (and for which key)? Not particularly, no. The message doesn't get encrypted using the sender's key, although it may be encrypted to the sender's key, along with the recipient's. What advantage does it give to the attacker to encrypt a message via MITM? The likely outcome of doing so would be to reveal that they are intercepting messages, for what benefit? That's a legitimate question, not a snark. You seem to be suggesting that this would provide value to the attacker, if so can you elaborate? | How can it make little sense to provide this information? If the sender cares they can insert a statement in their signed message. "I did/did not encrypt this message before sending." Problem solved. | Whether it is more important to encrypt a message or to sign it | differs a lot with the content. Thus I do not understand your | explanation of importance. My argument is that the _only_ thing relevant to message validity is the signature on the message itself. Whether it was encrypted or not should play no role in the recipient's calculation of the validity of the message. | This is similar to SSL/TLS without client negotiation: No, it's not at all. But I don't want to quibble about that, I'm still interested in your description of the importance of the encryption itself, separate from the message and signature. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSxn8pAAoJEFzGhvEaGryEulsH/2u1seI5K62Y0Aa5fKI3SRAD eBc8n62Se7sXw8rOXR+Qp5k191Upg1/Po2mkTSpgPjqc47yeAPaj4pHBAQIiAlgC 1iDdb4RveB3zZeJ4HpVgrRR5ap3S8w+SmnDdbul4evVcnuHnzP7zOFOZ5ZgIVnr8 Aoaei1jaaKal6p6qf5FDOA2c/Ni8pALZ8ZaUDNlDOLMpRS02uKZHUJwpx7eCDuKK wvvk6X7nicetiKdklDX31eoabGuhu0ret3BbAwq6EEXaAD6FnPIuhgHcvLZzz6Tj c0XuJD+UYK67p/rm4EdxUdr57rJ3Kr/hKdTjtBVy/l17LZZoXuROa8KSblwtr2U= =aqFY -----END PGP SIGNATURE----- From dougb at dougbarton.us Fri Jan 3 10:17:23 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 03 Jan 2014 01:17:23 -0800 Subject: sign encrypted emails In-Reply-To: <52C67F29.3000103@dougbarton.us> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <1843210.iObAQBZGL1@inno.berlin.laging.de> <52C67F29.3000103@dougbarton.us> Message-ID: <52C68023.2000901@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/03/2014 01:13 AM, Doug Barton wrote: | My argument is that the_only_ thing relevant to message validity | is the signature on the message itself. Whether it was encrypted or | not should play no role in the recipient's calculation of the | validity of the message. Sorry, that's a little bit stronger than I intended. There are of course cases such as, "This is odd, every communication I have ever had with Alice about $SUBJECT previously has been encrypted, but this one is not, I wonder if there is a problem here?" But for the common case my point remains .... the fact that a message is encrypted should not enter into the validity calculation. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSxoAjAAoJEFzGhvEaGryE7GsH/0wItxi1Q8kvHU/0dy0mjRkE jgRl0d8njyWVxhx6SDAbyZoAJ6w+oTHz0fdLRhspwvSuKcvrX4Zs0G3Y9Kr18EJg 39rhpedLCijs/Q5x55V/RZR0Wfs3uNP7V58w4nCgL6pzhwgb2xmOarOn7reEuvn2 xFff4NXPAg6xKZpT/5IkT5Y2K0oD/xu7QIWfZKvYpI482QwkVVmZwv5j6sW2p/lm Wbi9Hh0bnhL46YVSoH6Z/Lh/cnwsfL89F5Xl6YHyzInWJhH2nHsRy6KLzZSOx00q Qv9Zli3bx5PvStujwxJ/iGHPgnYCZn2Qjsc/jAp3gSdItcdj4uDIDQGQucRO7lQ= =8OZQ -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Fri Jan 3 10:28:38 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 03 Jan 2014 04:28:38 -0500 Subject: sign encrypted emails In-Reply-To: <52C675EF.4020008@dougbarton.us> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> Message-ID: <52C682C6.1020309@sixdemonbag.org> On 1/3/2014 3:33 AM, Doug Barton wrote: > This threat model doesn't make a lot of sense, except for very naive > users who cannot distinguish the importance of a message that is > encrypted vs. a message (encrypted or not) which is signed. I'm going to cautiously disagree. What we call "very naive users" account for the vast majority of GnuPG users. Unfortunately, that's as far as my disagreement goes. I see what Hauke's getting at, but I disagree that it really amounts to much of a problem, or that his proposed fix would work. The real problem Hauke's discovered is, "people generally don't have the educational background to think formally and critically about trust." Which is, well, true -- but that one's a hell of a hard problem to solve. Everything else (including "sign-encrypt-sign" schemes) amounts to just ways to try to dodge the real issue. From mailinglisten at hauke-laging.de Fri Jan 3 10:50:35 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 03 Jan 2014 10:50:35 +0100 Subject: sign encrypted emails In-Reply-To: <52C67F29.3000103@dougbarton.us> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <1843210.iObAQBZGL1@inno.berlin.laging.de> <52C67F29.3000103@dougbarton.us> Message-ID: <20731322.CJoVRue8CV@inno.berlin.laging.de> Am Fr 03.01.2014, 01:13:13 schrieb Doug Barton: > On 01/03/2014 12:59 AM, Hauke Laging wrote: > | Do you agree that it is (or, depending on the content, can be) an > | important information whether a message was encrypted by the sender > | (and for which key)? > > Not particularly, no. The message doesn't get encrypted using the > sender's key, although it may be encrypted to the sender's key, along > with the recipient's. That's not what I am talking about. I am talking about the recipient having keys with different security levels. So there are keys I (insecure) and S (secure). By insecure I mean a key like the one which signs this email: Being used on a normal system (i.e. an insecure one; oh no, in a moment Rob will notice that I used "secure" and "insecure" again...). If data is so important that it shall not be encrypted for my key I but for my key S only then I want to be sure that it has been encrypted by the sender for S. That the message which arrives at me is encrypted for S does not ensure this. Anyone can encrypt messages for my key. > What advantage does it give to the attacker to encrypt a message via > MITM? As I said: If a normal user (i.e. one with nearly no security clue at all) starts an email conversation without encryption (or with weak encryption) and I notice that (because the message arrives unchanged) then I will tell the sender to change his behaviour. He will probably to that and the communication becomes secure. It is in the interest of an adversary to prevent the communication from becoming secure. > The likely outcome of doing so would be to reveal that they are > intercepting messages, In my opinion it is very unlikely that this would be revealed. There are people who like to get everything encrypted and those who prefer to get only important data encrypted. Every serious adversary will know what type his target is. This is more or less a public information. So if somebody wants everything encrypted why should he ever ask or mention that? It is possible, yes. "Thanks for encrypting your messages." Who does that? And how many senders unfamiliar with crypto would understand from that that their message has been modified? Maybe a nice feature of their great ISP? Even worse with asking such a sender whether he has used the right recipient key. Probably he will not even understand the problem or misassess the situation. And if the recipient expects only important data to be encrypted then the adversary would encrypt only important data (which may be hard to decide automatically though but who would notice a minute delay under normal circumstances?). And why should the adversary not risk being detected? We encrypt because we assume that there are adversaries. > | How can it make little sense to provide this information? > > If the sender cares they can insert a statement in their signed > message. "I did/did not encrypt this message before sending." Problem > solved. Yes. But why should the sender care? The sender can be sure about doing it right! The recipient is the one who cannot. And why should we bother writing that in every mail if there is a simple automatic solution to it? You cannot even be sure that the information is correct! People make mistakes. > My argument is that the _only_ thing relevant to message validity is > the signature on the message itself. I do not doubt that in any way but my argument isn't about validity at all. It is about guaranteed confidentiality! That is a big difference. 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 Fri Jan 3 10:57:43 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 03 Jan 2014 10:57:43 +0100 Subject: sign encrypted emails In-Reply-To: <52C682C6.1020309@sixdemonbag.org> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> Message-ID: <2599601.ahRAmgsk7D@inno.berlin.laging.de> Am Fr 03.01.2014, 04:28:38 schrieb Robert J. Hansen: > or that his proposed fix would work. Would you explain how that shall be avoided? You send an email to me. You encrypt it to the key which I want you to encrypt it to. Then you sign the encrypted data. If I receive an email from you which is not encrypted and signed (as the outer layer) then I go on red alert. Like today I might if the message is not encrypted or not signed. How shall THEY create an encrypted-signed message if you have e.g. sent it without encryption? The adversary needs your signing key. 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 expires2013 at ymail.com Fri Jan 3 11:02:28 2014 From: expires2013 at ymail.com (MFPA) Date: Fri, 3 Jan 2014 10:02:28 +0000 Subject: sign encrypted emails In-Reply-To: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> Message-ID: <1075766552.20140103100228@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 3 January 2014 at 5:35:28 AM, in , Hauke Laging wrote: > I just noticed that you can easily be deluded about an > email being encrypted: That you receive an encrypted > mail does not mean that it was sent encrypted. An > adversary may encrypt a non-encrypted message (which he > has intercepted) in order to create more trust in the > message for the recipient: If you receive critical > information and are aware that it has not been > encrypted then you may react differently from the case > where you are sure that is was encrypted. Encrypted or not, a message you receive may not come from the purported sender. Witness all the social engineering "phishing" emails purporting to be from banks who have mislaid your login details. OpenPGP's mitigation against this is signing emails, and the web of trust to give assurance who signed. > Or similar: A message is encrypted to a low security > key which has been compromised (unnoticed by the > recipient). The adversary decrypts the message ans > reencrypts it to a more secure key. You mean the recipient has 2 keys, one of which the adversary has compromised? And the adversary intercepts and decrypts mail that is encrypted to the compromised key, then sends it on its way encrypted to the non-compromised key? Again, this would be flagged up if the sender was in the habit of signing outgoing messages (as you stated). > (this may mean that you sign it twice: once > before and once after encryption). Is that better than the usual signing and encryption carried out together? > I would like to ask mail client developers to add this > feature. But before I would like to hear opinions > whether that makes sense. Both your examples seem to involve encrypted-only and not signed messages, so would be unaffected by introducing additional signature options. Unless signing were compulsory rather than an option. - -- Best regards MFPA mailto:expires2013 at ymail.com Two wrongs don't make a right. But three lefts do. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLGisdXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p0IEEALGbeUoK3xNL/QdlEWPWZVOap7Zivr6P7KdE sprOCy87gc50zIGIUu73DkBWJOWP+gFqlhEtWMzhOwAbpbVybj7UrerZSbIKawmn YoCd45X5Tu5bi1fHc+QtKoi8Z3/XUGv3Q4/wCNams75N4FCDhoWY+2FHmAdlrHrM fk1Nu2LK =P4s8 -----END PGP SIGNATURE----- From wk at gnupg.org Fri Jan 3 11:00:37 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Jan 2014 11:00:37 +0100 Subject: Can't decrypt message encrypted with ECC In-Reply-To: <1388685272.31714.5.camel@mepc.speedy.local> (Peter Humphreys's message of "Fri, 03 Jan 2014 01:54:32 +0800") References: <1388481700.25952.4.camel@mepc.speedy.local> <52C2CB75.7090809@sumptuouscapital.com> <1388685272.31714.5.camel@mepc.speedy.local> Message-ID: <871u0pmlkq.fsf@vigenere.g10code.de> On Thu, 2 Jan 2014 18:54, eagleeyes426 at yahoo.com said: > I have created a test ECC 25519 subkey. You mean using the experimental code in GnuPG master? Don't use it - it is is work in progress. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From danm at prime.gushi.org Fri Jan 3 10:14:22 2014 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Fri, 3 Jan 2014 01:14:22 -0800 (PST) Subject: How to do pinentry in same screen as gpg Message-ID: All, I have a script that I use to send mail (as part of pine/alpine) that needs to prompt for my key passphrase. I run alpine on a private unix server, within a screen session. It basically works perfectly with gpg1, where I can get an inline prompt for a password, but gpg2 falls short where it tries to set up some kind of a unix-socket connection to a pinentry dialog, and this all falls apart within the simple exec() alpine is doing to launch the filter. GPG hangs up and I wind up needing to kill the whole window. Here's where I've gotten on a possible solution: I could possibly have every window within my screen session have my .cshrc check for a running gpg-agent, and start one if it's not (this seems wasteful considering how infrequently I sign). Along these lines, I'd probably have to have every single screen process update the running TTY, so that my most recently-opened screen would contain the dialog. It seems that the pinentry command is invoked behind the scenes by the agent, and then directly writes to and reads/from the tty specified (so it could in theory interfere with whatever else I'm running on that screen), for example, if I were doing something while su'd to root. -or- It would also be nice if pinentry could cause the spawning of a new screen window via "screen -X", but as I have a password-protected screen, this isn't possible either. -or- It might also be nice if I could basically start a pinentry program in a dedicated window, and simply choose to use it when needed (similar in analog to how I might use a hardware pinpad, or a fingerprint reader). I don't know if this is possible. I could also start up some "dummy" program in a screen where the agent will spawn. I think that last one is the plan of attack I'll likely pursue. However, it would be really, really nice if, instead of gpg--agent--assuan--pinentry, GPG could just fall back to prompting for a password on the same tty where GPG is running. It would also be nice if GPG had some method of simply saying "hey, I can't find a place to spawn this pinentry, and could exit cleanly." Thoughts are welcome. -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From mailinglisten at hauke-laging.de Fri Jan 3 11:28:28 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 03 Jan 2014 11:28:28 +0100 Subject: sign encrypted emails In-Reply-To: <1075766552.20140103100228@my_localhost> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <1075766552.20140103100228@my_localhost> Message-ID: <2002014.1CKrbWpAov@inno.berlin.laging.de> Am Fr 03.01.2014, 10:02:28 schrieb MFPA: > OpenPGP's mitigation against this is signing emails, and the web of > trust to give assurance who signed. That's exactly why I want signatures. But I do not only want a signature which guarantees the data integrity, I want a(nother) signature which guarantees the (correct) encryption. > You mean the recipient has 2 keys, one of which the adversary has > compromised? And the adversary intercepts and decrypts mail that is > encrypted to the compromised key, then sends it on its way encrypted > to the non-compromised key? Yes, that is the more complicated case. > Again, this would be flagged up if the > sender was in the habit of signing outgoing messages (as you stated). No, it wouldn't. The reason is that the signature is created the same way in the two cases encrypted and non-encrypted. Thus you can apply encryption later with the recipient having no chance at all to determine who encrypted. > > (this may mean that you sign it twice: once > > before and once after encryption). > > Is that better than the usual signing and encryption carried out > together? It is better with respect to ensuring the encryption. It has disadvantages, though, otherwise we wouldn't do it the other way round. Proving the authenticity becomes more difficult if there is no signature within the encryption because a third party cannot encrypt the data. You would need to give them the session key. Who is capable of doing that? Furthermore you cannot know whether an encrypted message has been signed within. That may be an advantage in certain situations. You can send an encrypted message anonymously. That is not possible with my proposal (you would have to add a fourth layer... not difficult though). But I do not suggest to make my configuration the default. I just want to be able to use it. Sometimes it's best to send a signed cleartext message, sometimes to send an unsingned encrypted message, sometimes a first signed then encrypted message and I want to stress that sometimes it's best to send a first encrypted then signed (or signed-encrypted- signed) message. > Both your examples seem to involve encrypted-only and not signed > messages, The problem is the same with signed and unsigned messages. > so would be unaffected by introducing additional signature > options. I don't understand that statement. 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 Fri Jan 3 11:41:02 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 03 Jan 2014 11:41:02 +0100 Subject: How to do pinentry in same screen as gpg In-Reply-To: References: Message-ID: <2849610.ZRUgX8e7Ui@inno.berlin.laging.de> Am Fr 03.01.2014, 01:14:22 schrieb Dan Mahoney, System Admin: > It basically works perfectly with gpg1, where I can get an inline > prompt for a password, but gpg2 falls short where it tries to set up > some kind of a unix-socket connection to a pinentry dialog, and this > all falls apart within the simple exec() alpine is doing to launch > the filter. GPG hangs up and I wind up needing to kill the whole > window. Do you start gpg-agent before gpg2? I would expect the behaviour to be the same like gpg if gpg-agent is not running. > It might also be nice if I could basically start a pinentry program in > a dedicated window, You can write a wrapper around pinentry. This wrapper could start pinentry in a different console. See: http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047168.html http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html I assume this is much more a screen problem. Some time ago I tried to create a pipeline between two processes running in different screen windows. I didn't manage to do that. But maybe there are tricks unknown to me. Maybe that can be done with redirecting stdin and stdout to a socket with socat or something like that. 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 Fri Jan 3 12:21:05 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 03 Jan 2014 06:21:05 -0500 Subject: sign encrypted emails In-Reply-To: <2599601.ahRAmgsk7D@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> <2599601.ahRAmgsk7D@inno.berlin.laging.de> Message-ID: <52C69D21.3050605@sixdemonbag.org> On 1/3/2014 4:57 AM, Hauke Laging wrote: > Would you explain how that shall be avoided? I already did, in quite clear language. You are trying to solve a social problem ("people don't have the background to think formally about trust issues") via technological means ("if we just change the way we sign..."). From peter at digitalbrains.com Fri Jan 3 12:13:04 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 03 Jan 2014 12:13:04 +0100 Subject: sign encrypted emails In-Reply-To: <2599601.ahRAmgsk7D@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> <2599601.ahRAmgsk7D@inno.berlin.laging.de> Message-ID: <52C69B40.8010801@digitalbrains.com> On 03/01/14 10:57, Hauke Laging wrote: > If I receive an email from you which is not encrypted and signed (as the > outer layer) then I go on red alert. Like today I might if the message is > not encrypted or not signed. How do you know the sender doesn't have an unencrypted copy of the message in an easily broken into online backup service? The encryption of one copy of a message doesn't imply the confidentiality of all copies that exist. 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 ekleog at gmail.com Fri Jan 3 14:12:43 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Fri, 3 Jan 2014 14:12:43 +0100 Subject: sign encrypted emails In-Reply-To: <52C69D21.3050605@sixdemonbag.org> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> <2599601.ahRAmgsk7D@inno.berlin.laging.de> <52C69D21.3050605@sixdemonbag.org> Message-ID: <20140103131243.GA5823@leortable> On Fri, Jan 03, 2014 at 06:21:05AM -0500, Robert J. Hansen wrote: > On 1/3/2014 4:57 AM, Hauke Laging wrote: > > Would you explain how that shall be avoided? > > I already did, in quite clear language. > > You are trying to solve a social problem ("people don't have the > background to think formally about trust issues") via technological > means ("if we just change the way we sign..."). I think the need for such a fix could also be highlighted in the following example. I sign the message "Got to talk tomorrow at dawn", then send it to Alice, thinking about the cake for the birthday party, not important so not encrypting it. Bob grabs the message, and sends it encrypted to Alice's highest security key. Alice then thinks it is a really important message, and the matters to discuss are really important. She takes with her the top secret files we are working together on. Bob, knowing the place and date of the meeting, then comes and steals the top secret files. So changing the encryption could break an opsec. I'm not saying it would be useful everyday. But some use cases seem to require it. However, I'm not saying this feature should be included by default, as a fix would be easy (call gpg twice), and I can think of few use cases. BTW, is a timestamp included in the signature? If not, it could lead to similar issues. Cheers, Leo From danm at prime.gushi.org Fri Jan 3 14:31:44 2014 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Fri, 3 Jan 2014 05:31:44 -0800 (PST) Subject: How to do pinentry in same screen as gpg In-Reply-To: <2849610.ZRUgX8e7Ui@inno.berlin.laging.de> References: <2849610.ZRUgX8e7Ui@inno.berlin.laging.de> Message-ID: On Fri, 3 Jan 2014, Hauke Laging wrote: > Am Fr 03.01.2014, 01:14:22 schrieb Dan Mahoney, System Admin: > >> It basically works perfectly with gpg1, where I can get an inline >> prompt for a password, but gpg2 falls short where it tries to set up >> some kind of a unix-socket connection to a pinentry dialog, and this >> all falls apart within the simple exec() alpine is doing to launch >> the filter. GPG hangs up and I wind up needing to kill the whole >> window. > > Do you start gpg-agent before gpg2? I would expect the behaviour to be > the same like gpg if gpg-agent is not running. No, the agent "is required", per the manpage. If GPG doesn't find an agent, it starts one: I just fired up a gpg --gen-key on my system where 2.x is installed. danm 74860 0.0 0.1 13728 2120 ?? Ss 1:18PM 0:00.02 gpg-agent --daemon --use-standard-socket danm 74853 0.0 0.1 17408 3136 3 I+ 1:18PM 0:00.02 gpg --gen-key (gpg2) danm 74861 0.0 0.0 9264 1972 ?? I 1:18PM 0:00.01 pinentry (pinentry-curses) It leaves this agent running after you exit GPG, which feels sloppy -- ssh doesn't leave ssh-agent running after I connect, if I use it at all. >> It might also be nice if I could basically start a pinentry program in >> a dedicated window, > > You can write a wrapper around pinentry. This wrapper could start > pinentry in a different console. See: > > http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047168.html > http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html > > I assume this is much more a screen problem. Some time ago I tried to > create a pipeline between two processes running in different screen > windows. I didn't manage to do that. But maybe there are tricks unknown > to me. Maybe that can be done with redirecting stdin and stdout to a > socket with socat or something like that. I seem to recall that I was able to do it by messing heavily with environment variables. As I want to get back into playing with smartcards, the agent become more necessary. (Or keeping v1 and v2 installed in parallel, which seems nonoptimal). Hauke, in your posts, you mention that the pinentry protocol isn't on the GPG website. Could that please be fixed by the people who maintain the project? I notice it also missing from http://www.gnupg.org/documentation/manuals/ If I come up with a good method for doing so, I'll post a howto/blog here. I do wonder how difficult it would be to write a pinentry-getline which doesn't try to do any fancy display tricks -- I just want enough magic to turn echoing off. (I think the ncurses are part of what mess alpine up). I may try this as well. Thanks all, -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From danm at prime.gushi.org Fri Jan 3 14:45:51 2014 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Fri, 3 Jan 2014 05:45:51 -0800 (PST) Subject: How to do pinentry in same screen as gpg In-Reply-To: <2849610.ZRUgX8e7Ui@inno.berlin.laging.de> References: <2849610.ZRUgX8e7Ui@inno.berlin.laging.de> Message-ID: On Fri, 3 Jan 2014, Hauke Laging wrote: > Am Fr 03.01.2014, 01:14:22 schrieb Dan Mahoney, System Admin: > >> It basically works perfectly with gpg1, where I can get an inline >> prompt for a password, but gpg2 falls short where it tries to set up >> some kind of a unix-socket connection to a pinentry dialog, and this >> all falls apart within the simple exec() alpine is doing to launch >> the filter. GPG hangs up and I wind up needing to kill the whole >> window. > > Do you start gpg-agent before gpg2? I would expect the behaviour to be > the same like gpg if gpg-agent is not running. > > >> It might also be nice if I could basically start a pinentry program in >> a dedicated window, > > You can write a wrapper around pinentry. This wrapper could start > pinentry in a different console. See: > > http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047168.html > http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html > > I assume this is much more a screen problem. Some time ago I tried to > create a pipeline between two processes running in different screen > windows. I didn't manage to do that. But maybe there are tricks unknown > to me. Maybe that can be done with redirecting stdin and stdout to a > socket with socat or something like that. Actually -- it *looks like* loopback-pinentry is pretty much exactly what I'm looking for here, if I understand the feature. Hopefully recent fundraising activity can get 2.1 out the door soon. (I'm going to donate!) -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From dkg at fifthhorseman.net Fri Jan 3 18:50:47 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Jan 2014 12:50:47 -0500 Subject: sign encrypted emails In-Reply-To: <20140103131243.GA5823@leortable> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> <2599601.ahRAmgsk7D@inno.berlin.laging.de> <52C69D21.3050605@sixdemonbag.org> <20140103131243.GA5823@leortable> Message-ID: <52C6F877.1070205@fifthhorseman.net> On 01/03/2014 08:12 AM, Leo Gaspard wrote: > So changing the encryption could break an opsec. If someone's opsec is based on the question of whether a message was encrypted or not, then they've probably got their cart before their horse too. opsec requirements should indicate whether you encrypt, not the other way around. > BTW, is a timestamp included in the signature? If not, it could lead to similar > issues. Yes, all OpenPGP signatures generated by standards-compliant tools include a timestamp: https://tools.ietf.org/html/rfc4880#section-5.2.3.4 --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 ndk.clanbo at gmail.com Fri Jan 3 19:02:10 2014 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 03 Jan 2014 19:02:10 +0100 Subject: sign encrypted emails In-Reply-To: <2002014.1CKrbWpAov@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <1075766552.20140103100228@my_localhost> <2002014.1CKrbWpAov@inno.berlin.laging.de> Message-ID: <52C6FB22.2070409@gmail.com> Il 03/01/2014 11:28, Hauke Laging ha scritto: > But I do not suggest to make my configuration the default. I just want > to be able to use it. Sometimes it's best to send a signed cleartext > message, sometimes to send an unsingned encrypted message, sometimes a > first signed then encrypted message and I want to stress that sometimes > it's best to send a first encrypted then signed (or signed-encrypted- > signed) message. I can't come up with a situation where sign, encrypt, sign again w/ *same* key used in the first signature gives more security than first encrypt then sign. So two layers are enough. I (partially) get your point: receiving an encrypted message could mislead an uneducated user... But I doubt someone w/ access to top secret material falls in that category :) BYtE, Diego. From dkg at fifthhorseman.net Fri Jan 3 19:02:32 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Jan 2014 13:02:32 -0500 Subject: sign encrypted emails In-Reply-To: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> Message-ID: <52C6FB38.9060509@fifthhorseman.net> On 01/03/2014 12:35 AM, Hauke Laging wrote: > From the RfC perspective (PGP/MIME) this should not be a problem; you just > need another level of nesting. Maybe the mail clients are not even prepared > for reading such messages. That would not surprise me but would not be an > argument against one client implementing this as the first one. I am > interested in general arguments for and against this. it sounds to me like you might be interested in what the S/MIME community calls "triple-wrapping", which is used to provide cryptographic proof-of-origin and attribute-handling for intermediate transport agents: http://www.isode.com/whitepapers/smime-military-messaging.html https://bugzilla.mozilla.org/show_bug.cgi?id=380624 That said, triple-wrapping (or similar approaches) have tradeoffs that we might not want to encourage. For example, they leak metadata about who signed the message to anyone who observes it in transit; this is not the case for the traditional sign-then-encrypt layering. metadata gathering is a fruitful surveillance technique. but at its core, i think the problem you're raising is related to a fundamental (but probably common) misunderstanding: people assume that if something is encrypted to them then that is related to some signal from the message author, even though asymmetric encryption has nothing to do with authenticity or verifiability. I don't think you're going to solve that particular problem by having some e-mails have an extra layer of signature on them. --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 Fri Jan 3 20:29:50 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 03 Jan 2014 20:29:50 +0100 Subject: How to do pinentry in same screen as gpg In-Reply-To: References: <2849610.ZRUgX8e7Ui@inno.berlin.laging.de> Message-ID: <52C70FAE.40609@digitalbrains.com> On 03/01/14 14:31, Dan Mahoney, System Admin wrote: > Hauke, in your posts, you mention that the pinentry protocol isn't on the GPG > website. Could that please be fixed by the people who maintain the project? I > notice it also missing from http://www.gnupg.org/documentation/manuals/ I remember that post by Hauke. Let me quote my reply I wrote to this list back then: On 11/12/13 10:43, Peter Lebbing wrote: > 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 True, it's not exactly the website :). I agree it would be good if the manual were on the website, and I can't find it either, but let's wait for the new design. Oh, btw, slight addition: BYE is not in the agent (or pinentry) protocol description because it is a basic assuan command, so it's described at [1] or "info assuan". HTH, Peter. [1] http://www.gnupg.org/documentation/manuals/assuan/ -- 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 gnupg at oneiroi.net Sat Jan 4 00:07:44 2014 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sat, 04 Jan 2014 00:07:44 +0100 Subject: NSA seeks to build quantum computer that could crack most types of encryption Message-ID: <52C742C0.6020302@oneiroi.net> Hi all. Nothing new actually, but this is nice point: ?The irony of quantum computing is that if you can imagine someone building a quantum computer that can break encryption a few decades into the future, then you need to be worried right now,? Lidar said. [1] [1] http://www.washingtonpost.com/world/national-security/nsa-seeks-to-build-quantum-computer-that-could-crack-most-types-of-encryption/2014/01/02/8fff297e-7195-11e3-8def-a33011492df2_story.html Cheers, Filip From ekleog at gmail.com Sat Jan 4 00:56:36 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Sat, 4 Jan 2014 00:56:36 +0100 Subject: sign encrypted emails In-Reply-To: <52C6F877.1070205@fifthhorseman.net> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> <2599601.ahRAmgsk7D@inno.berlin.laging.de> <52C69D21.3050605@sixdemonbag.org> <20140103131243.GA5823@leortable> <52C6F877.1070205@fifthhorseman.net> Message-ID: <20140103235636.GD5823@leortable> On Fri, Jan 03, 2014 at 12:50:47PM -0500, Daniel Kahn Gillmor wrote: > On 01/03/2014 08:12 AM, Leo Gaspard wrote: > > So changing the encryption could break an opsec. > > If someone's opsec is based on the question of whether a message was > encrypted or not, then they've probably got their cart before their > horse too. > > opsec requirements should indicate whether you encrypt, not the other > way around. Well... So, where is the flow in my example? This example was designed so that, depending on the level of encryption (and so the "importance" of the safety of the message according to the sender), the message had different meanings. Sorry, I can't see yet where I went wrong. From dkg at fifthhorseman.net Sat Jan 4 01:31:29 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Jan 2014 19:31:29 -0500 Subject: sign encrypted emails In-Reply-To: <20140103235636.GD5823@leortable> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> <2599601.ahRAmgsk7D@inno.berlin.laging.de> <52C69D21.3050605@sixdemonbag.org> <20140103131243.GA5823@leortable> <52C6F877.1070205@fifthhorseman.net> <20140103235636.GD5823@leortable> Message-ID: <52C75661.8010409@fifthhorseman.net> On 01/03/2014 06:56 PM, Leo Gaspard wrote: > On Fri, Jan 03, 2014 at 12:50:47PM -0500, Daniel Kahn Gillmor wrote: >> On 01/03/2014 08:12 AM, Leo Gaspard wrote: >>> So changing the encryption could break an opsec. >> >> If someone's opsec is based on the question of whether a message was >> encrypted or not, then they've probably got their cart before their >> horse too. >> >> opsec requirements should indicate whether you encrypt, not the other >> way around. > > Well... So, where is the flow in my example? This example was designed so that, > depending on the level of encryption (and so the "importance" of the safety of > the message according to the sender), the message had different meanings. As you've noticed, the sender cannot verifiably communicate their intent by their choice of encryption key. If the sender wants to communicate their intent in a way that the recipient can verify it, they'll need to sign something. In your example, the fact that a message was encrypted makes the recipient treat it as though the sender had indicated something specific about the message because it was encrypted. This is bad policy, since there is no indication that the sender encrypted the message themselves, or even knew that the message was encrypted. --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 Sat Jan 4 02:28:05 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 03 Jan 2014 17:28:05 -0800 Subject: sign encrypted emails In-Reply-To: <52C682C6.1020309@sixdemonbag.org> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> Message-ID: <52C763A5.1000409@dougbarton.us> On 01/03/2014 01:28 AM, Robert J. Hansen wrote: > On 1/3/2014 3:33 AM, Doug Barton wrote: >> This threat model doesn't make a lot of sense, except for very naive >> users who cannot distinguish the importance of a message that is >> encrypted vs. a message (encrypted or not) which is signed. > > I'm going to cautiously disagree. What we call "very naive users" > account for the vast majority of GnuPG users. I don't necessarily disagree with you on that. :) > Unfortunately, that's as far as my disagreement goes. I see what > Hauke's getting at, but I disagree that it really amounts to much of a > problem, or that his proposed fix would work. > > The real problem Hauke's discovered is, "people generally don't have the > educational background to think formally and critically about trust." > Which is, well, true -- but that one's a hell of a hard problem to > solve. Everything else (including "sign-encrypt-sign" schemes) amounts > to just ways to try to dodge the real issue. Yes, that is the point I was trying to get across. ... and I did actually suggest a solution to the problem Hauke is (ostensibly) trying to solve. The sender can include a statement in their signed message regarding whether or not they also encrypted it before sending. However I would still argue that doing so would have no real benefit. Thinking further, what *may* be useful would be for the mail client to pop up a message that says something similar to, "This message was encrypted, but not signed. No assumptions should be made about the validity of the message itself." In the end however there is no substitute for user education. :-/ Doug From johanw at vulcan.xs4all.nl Sat Jan 4 12:10:27 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 04 Jan 2014 12:10:27 +0100 Subject: NSA seeks to build quantum computer that could crack most types of encryption In-Reply-To: <52C742C0.6020302@oneiroi.net> References: <52C742C0.6020302@oneiroi.net> Message-ID: <52C7EC23.9030809@vulcan.xs4all.nl> On 04-01-2014 0:07, Filip M. Nowak wrote: > ?The irony of quantum computing is that if you can imagine someone > building a quantum computer that can break encryption a few decades into > the future, then you need to be worried right now,? Lidar said. [1] There exists already quantum-computing resistant crypto algorithms: https://en.wikipedia.org/wiki/NTRUEncrypt Perhaps it's about time to start talking about implementing them in GnuPG? -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From micha137 at gmx.de Sat Jan 4 13:31:44 2014 From: micha137 at gmx.de (micha137) Date: Sat, 04 Jan 2014 13:31:44 +0100 Subject: Quantum computing Message-ID: They cheat, they bribe, they lie, they blackmail, they take polygraph tests on each other but they don't invent. A spoofing organization is no fertile ground for true innovation. The real scientists, not the NSA are going to make progress in quantum computing. And it is not going to be as cheap as some tens of megabucks. Progress to get it practical will be painfully slow. You IT people can sit back and relax. Cheers ? Michael Anders (a dedicated physicist) Von Samsung Mobile gesendet -------------- next part -------------- An HTML attachment was scrubbed... URL: From esteban.francisco at gmail.com Sat Jan 4 12:48:20 2014 From: esteban.francisco at gmail.com (Esteban Monge) Date: Sat, 4 Jan 2014 05:48:20 -0600 Subject: NSA seeks to build quantum computer that could crack most types of encryption In-Reply-To: <52C7EC23.9030809@vulcan.xs4all.nl> References: <52C742C0.6020302@oneiroi.net> <52C7EC23.9030809@vulcan.xs4all.nl> Message-ID: 2014/1/4 Johan Wevers > On 04-01-2014 0:07, Filip M. Nowak wrote: > > > ?The irony of quantum computing is that if you can imagine someone > > building a quantum computer that can break encryption a few decades into > > the future, then you need to be worried right now,? Lidar said. [1] > > There exists already quantum-computing resistant crypto algorithms: > https://en.wikipedia.org/wiki/NTRUEncrypt > > Perhaps it's about time to start talking about implementing them in GnuPG? > May be we can make better encryption algoritms with quantum computers and will replace actual standards > > -- > ir. J.C.A. Wevers > PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- http://www.nuevaeralatam.com Linux user number 478378 Linux machine number 2003329 Tec. Esteban Monge Mar?n Tel: (506) 8379-3562 ?No habr? manera de desarrollarnos y salir de la pobreza mientras los pocos negocios grandes de nuestro medio se entreguen a las econom?as for?neas y nosotros nos quedemos con solo negocios de pobre, mientras en vez de ser propietarios de nuestro propio pa?s nos convirtamos en un ej?rcito de empleados del exterior? Jos? Figueres Ferrer, 1952. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at oneiroi.net Sat Jan 4 14:51:59 2014 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sat, 04 Jan 2014 14:51:59 +0100 Subject: NSA seeks to build quantum computer that could crack most types of encryption In-Reply-To: References: <52C742C0.6020302@oneiroi.net> <52C7EC23.9030809@vulcan.xs4all.nl> Message-ID: <52C811FF.4080403@oneiroi.net> On 04.01.2014 12:48, Esteban Monge wrote: > > > > 2014/1/4 Johan Wevers > > > On 04-01-2014 0:07, Filip M. Nowak wrote: > > > ?The irony of quantum computing is that if you can imagine someone > > building a quantum computer that can break encryption a few > decades into > > the future, then you need to be worried right now,? Lidar said. [1] > > There exists already quantum-computing resistant crypto algorithms: > https://en.wikipedia.org/wiki/NTRUEncrypt > > Perhaps it's about time to start talking about implementing them in > GnuPG? By starting with changes in standard(s) which tools like PGP or GnuPG are implementing. Some other, good points were mentioned here: http://secushare.org/PGP Of course we can negate need of improvement by statements really popular these days like: "compilers, libcs and OSes kernels have so many holes it's not worth to care anyway" But this is rather questionable approach I think. > May be we can make better encryption algoritms with quantum computers > and will replace actual standards You seems to be missing the point: "if you can imagine someone building a quantum computer that can break encryption a few decades into the future, then you need to be worried right now" Regards, Filip From atom at smasher.org Sat Jan 4 15:13:17 2014 From: atom at smasher.org (Atom Smasher) Date: Sun, 5 Jan 2014 03:13:17 +1300 (NZDT) Subject: NSA seeks to build quantum computer that could crack most types of encryption In-Reply-To: <52C811FF.4080403@oneiroi.net> References: <52C742C0.6020302@oneiroi.net> <52C7EC23.9030809@vulcan.xs4all.nl> <52C811FF.4080403@oneiroi.net> Message-ID: On Sat, 4 Jan 2014, Filip M. Nowak wrote: > "if you can imagine someone building a quantum computer that can break > encryption a few decades into the future, then you need to be worried > right now" ==================== worried? probably not. concerned? maybe. planning ahead? probably. Post-quantum cryptography http://en.wikipedia.org/wiki/Post-quantum_cryptography -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "I tremble for my country when I reflect that God is just." -- Thomas Jefferson From lev at serebryakov.spb.ru Sat Jan 4 15:51:12 2014 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Sat, 4 Jan 2014 18:51:12 +0400 Subject: Quantum computing In-Reply-To: References: Message-ID: <1413115758.20140104185112@serebryakov.spb.ru> Hello, micha137. You wrote 4 ?????? 2014 ?., 16:31:44: m> They cheat, they bribe, they lie, they blackmail, they take polygraph m> tests on each other but they don't invent. As far as I know, NSA is biggest employer of mathematicians in the world. I don't know about physics and quantum computing, but they CAN invent something, that depends on number theory. -- // Black Lion AKA Lev Serebryakov From ekleog at gmail.com Sat Jan 4 16:09:51 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Sat, 4 Jan 2014 16:09:51 +0100 Subject: sign encrypted emails In-Reply-To: <52C75661.8010409@fifthhorseman.net> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C675EF.4020008@dougbarton.us> <52C682C6.1020309@sixdemonbag.org> <2599601.ahRAmgsk7D@inno.berlin.laging.de> <52C69D21.3050605@sixdemonbag.org> <20140103131243.GA5823@leortable> <52C6F877.1070205@fifthhorseman.net> <20140103235636.GD5823@leortable> <52C75661.8010409@fifthhorseman.net> Message-ID: <20140104150951.GA15241@leortable> On Fri, Jan 03, 2014 at 07:31:29PM -0500, Daniel Kahn Gillmor wrote: > On 01/03/2014 06:56 PM, Leo Gaspard wrote: > > On Fri, Jan 03, 2014 at 12:50:47PM -0500, Daniel Kahn Gillmor wrote: > >> On 01/03/2014 08:12 AM, Leo Gaspard wrote: > >>> So changing the encryption could break an opsec. > >> > >> If someone's opsec is based on the question of whether a message was > >> encrypted or not, then they've probably got their cart before their > >> horse too. > >> > >> opsec requirements should indicate whether you encrypt, not the other > >> way around. > > > > Well... So, where is the flow in my example? This example was designed so that, > > depending on the level of encryption (and so the "importance" of the safety of > > the message according to the sender), the message had different meanings. > > As you've noticed, the sender cannot verifiably communicate their intent > by their choice of encryption key. If the sender wants to communicate > their intent in a way that the recipient can verify it, they'll need to > sign something. > > In your example, the fact that a message was encrypted makes the > recipient treat it as though the sender had indicated something specific > about the message because it was encrypted. This is bad policy, since > there is no indication that the sender encrypted the message themselves, > or even knew that the message was encrypted. Which is exactly the reason for which Hauke proposed to sign the encrypted message in addition to signing the cleartext message, is it not? Sure, there might be other ways: add a message stating to which key the message is encrypted, etc. But this one has the advantage of requiring AFAICT no alteration to the standard, and of being easily automated, for humans are quite poor at remembering to always state to which key they encrypt. Anyway, wouldn't you react differently depending on whether a message was encrypted to your offline key or unencrypted? Cheers, Leo From raubvogel at gmail.com Sat Jan 4 15:34:24 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Sat, 4 Jan 2014 15:34:24 +0100 Subject: NSA seeks to build quantum computer that could crack most types of encryption In-Reply-To: <52C811FF.4080403@oneiroi.net> References: <52C742C0.6020302@oneiroi.net> <52C7EC23.9030809@vulcan.xs4all.nl> <52C811FF.4080403@oneiroi.net> Message-ID: On Sat, Jan 4, 2014 at 2:51 PM, Filip M. Nowak wrote: > On 04.01.2014 12:48, Esteban Monge wrote: >> >> >> >> 2014/1/4 Johan Wevers > > >> >> On 04-01-2014 0:07, Filip M. Nowak wrote: >> >> > ?The irony of quantum computing is that if you can imagine someone >> > building a quantum computer that can break encryption a few >> decades into >> > the future, then you need to be worried right now,? Lidar said. [1] >> >> There exists already quantum-computing resistant crypto algorithms: >> https://en.wikipedia.org/wiki/NTRUEncrypt >> >> Perhaps it's about time to start talking about implementing them in >> GnuPG? > > By starting with changes in standard(s) which tools like PGP or GnuPG > are implementing. > > Some other, good points were mentioned here: > > http://secushare.org/PGP > > Of course we can negate need of improvement by statements really popular > these days like: "compilers, libcs and OSes kernels have so many holes > it's not worth to care anyway" > Well, everything has flaws and limitations. If we did not care about addressing them, we would still be in loinclothes living in caves. And, I do not think I look nice in loinclothes; they do not match my eye colour. > But this is rather questionable approach I think. > >> May be we can make better encryption algoritms with quantum computers >> and will replace actual standards > > You seems to be missing the point: > > "if you can imagine someone building a quantum computer that can break > encryption a few decades into the future, then you need to be worried > right now" > Also, isn't the point that technology keep evolving, as in for each new threat there will also be a new defense for such threat. > Regards, > Filip > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rajat.103025 at gmail.com Sat Jan 4 19:39:33 2014 From: rajat.103025 at gmail.com (Rajat Somani) Date: Sun, 5 Jan 2014 00:09:33 +0530 Subject: Open Source and Gnupg related Message-ID: Hello, I am quite new to this list. I dont understand what you people discuss about,many-a-times. I too want to participate in. So please tell me, where to start from. Regards, Rajat -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes at zarl.at Sat Jan 4 22:28:26 2014 From: johannes at zarl.at (Johannes Zarl) Date: Sat, 04 Jan 2014 22:28:26 +0100 Subject: sign encrypted emails In-Reply-To: <20140104150951.GA15241@leortable> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C75661.8010409@fifthhorseman.net> <20140104150951.GA15241@leortable> Message-ID: <8372383.9Qlg9mTKm2@mani> On Saturday 04 January 2014 16:09:51 Leo Gaspard wrote: > On Fri, Jan 03, 2014 at 07:31:29PM -0500, Daniel Kahn Gillmor wrote: > > In your example, the fact that a message was encrypted makes the > > recipient treat it as though the sender had indicated something specific > > about the message because it was encrypted. This is bad policy, since > > there is no indication that the sender encrypted the message themselves, > > or even knew that the message was encrypted. > > Which is exactly the reason for which Hauke proposed to sign the encrypted > message in addition to signing the cleartext message, is it not? Wouldn't one have to encrypt the signed-encrypted-signed message again to prevent an attacker from stripping away the outer signature? What would the recipient then do with the simple signed-encrypted message? > Sure, there might be other ways: add a message stating to which key the > message is encrypted, etc. But this one has the advantage of requiring > AFAICT no alteration to the standard, and of being easily automated, for > humans are quite poor at remembering to always state to which key they > encrypt. > > Anyway, wouldn't you react differently depending on whether a message was > encrypted to your offline key or unencrypted? One should certainly not act differently depending on the encryption of a message. Maybe with the one exception of timeliness: If a message is encrypted, you'll probably be ok with me reading the mail when I'm at my home computer. If a message is encrypted to my offline key, you'll be prepared to wait for a month or so (many people have their offline-key in a safe deposit box). Of course this opens way to subtle timing attacks (delaying reading a message until it is no longer relevant), but these subtle attacks can be done using simpler means (holding the message in transit). Cheers, Johannes From nb.linux at xandea.de Sat Jan 4 22:41:32 2014 From: nb.linux at xandea.de (nb.linux) Date: Sat, 04 Jan 2014 21:41:32 +0000 Subject: keysigning: lsign and offline master key Message-ID: <52C8800C.5080107@xandea.de> Hi, I have an offline master key with C/S capabilities and two subkeys (E, S). When (publicly) signing keys, usually I load my air gapped system with the master key, sign each individual UID of the key to sign, and export the signatures. Then send the signatures encrypted to the UID. How would the procedure look like for an lsign? - load system with master key - lsign the key/UIDs - ...here I'm stuck, because (as I understand the lsign) I cannot export the signature... Is this right? How can I lsign a key and transfer the local signature from my air gapped system? Maybe by copying the keyring files between the systems? Thanks in advance, -- nb.linux From dkg at fifthhorseman.net Sun Jan 5 01:38:00 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 04 Jan 2014 19:38:00 -0500 Subject: keysigning: lsign and offline master key In-Reply-To: <52C8800C.5080107@xandea.de> References: <52C8800C.5080107@xandea.de> Message-ID: <52C8A968.9090107@fifthhorseman.net> On 01/04/2014 04:41 PM, nb.linux wrote: > - ...here I'm stuck, because (as I understand the lsign) I cannot export > the signature... > > Is this right? > How can I lsign a key and transfer the local signature from my air > gapped system? > Maybe by copying the keyring files between the systems? You have at least two approaches available to you: 0) --export-options export-local on your air-gapped system, combined with --import-options import-local on your "regular" system. 1) create a secret key that lives only on your "regular" system; give it ultimate ownertrust, but never publish it. Use it to make non-exportable signatures. Would either of these workflows meet your goals? --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 mailinglisten at hauke-laging.de Sun Jan 5 04:31:49 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 05 Jan 2014 04:31:49 +0100 Subject: keysigning: lsign and offline master key In-Reply-To: <52C8800C.5080107@xandea.de> References: <52C8800C.5080107@xandea.de> Message-ID: <1444580.QL8rnv0Ye3@inno.berlin.laging.de> Am Sa 04.01.2014, 21:41:32 schrieb nb.linux: > How can I lsign a key and transfer the local signature from my air > gapped system? --export-options export-local-sigs Not necessary for import if the importing system knows the signing key as secret key (no matter whether the mainkey is available or not). 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 Sun Jan 5 04:38:58 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 05 Jan 2014 04:38:58 +0100 Subject: sign encrypted emails In-Reply-To: <8372383.9Qlg9mTKm2@mani> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <20140104150951.GA15241@leortable> <8372383.9Qlg9mTKm2@mani> Message-ID: <2177361.8E2pnFKRuX@inno.berlin.laging.de> Am Sa 04.01.2014, 22:28:26 schrieb Johannes Zarl: > Wouldn't one have to encrypt the signed-encrypted-signed message again > to prevent an attacker from stripping away the outer signature? What > would the recipient then do with the simple signed-encrypted message? That would be possible for an attacker but not make any sense: If the recipient expects the outer signature (only then this feature is a protection like signing is a protection only if the recipient acts differently on signed vs. non-signed messages) then the attacker is discovered without any advantage. There is another reason for creating this fourth layer: Some people want to hide the metadata (who made the signature). > One should certainly not act differently depending on the encryption > of a message. You are aware that is doesn't make any sense to make this claim without any argument after the opposite has been claimed with an argument (a very strong one)? 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 sam.kuper at uclmail.net Sun Jan 5 05:19:07 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Sun, 5 Jan 2014 04:19:07 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: References: Message-ID: On 05/01/2014, Sam Kuper wrote: > In group 2 above, the smallest reader I have found online which offers > secure PIN entry is the ACR83. Hm, I've now found several mailing list and forum discussions, etc, that indicate the ACR83 is not compatible with OpenPGP cards. That's a pity, as its stated dimensions suggest it's about a tenth the physical volume of the next smallest smart card reader with PIN pad (at least, of those that I've found online so far): the Identive SPR332 or SPR532. If anyone knows differently and is sure that the ACR83 has been made to work with the OpnPGP cards, please say so. If not, then we might as well ignore it for the rest of this thread. Thanks again, Sam From sam.kuper at uclmail.net Sun Jan 5 05:02:57 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Sun, 5 Jan 2014 04:02:57 +0000 Subject: USB key form-factor smart-card readers with pinpads? Message-ID: Dear GnuPG users, I am new to this list, so please be gentle. At some point in the coming months, I may try to obtain an OpenPGP smart card and reader. At the moment, such combinations, whether separable or combined into a single device, seem to be available in two form factors, neither of which is ideal: 1. USB-key sized devices, e.g.: Crypto Stick; Yubikey NEO; conventional USB stick-sized readers (e.g. Omnikey 6121) + ID-000 (SIM) sized OpenPGP card. 2. Full-size (ID-1) card + reader. In group 1 above, none of the devices I have found online offer secure PIN entry. In group 2 above, the smallest reader I have found online which offers secure PIN entry is the ACR83. My question to you is: does anyone manufacture a smart card reader compatible with the OpenPGP card (or containing an implementation of one) that offers secure PIN entry AND is (nearly) as compact as the CryptoStick, NEO, etc? Bonus points if it is also waterproof, tamper-evident, etc. (I am imagining that such a device would physically resemble a datAshur[1], LOK-IT[2], Flash Padlock 2[3] or similar, but perhaps with an ID-000 card slot inside. If such a device doesn't yet exist, then given the success of the CryptoStick and Yubikey NEO, I suspect there would be a market for such a device; perhaps crowd-funded via Indiegogo, Kickstarter, etc.) Many thanks in advance for your assistance, Sam [1] http://www.istorage-uk.com/datashur.php [2] http://www.lok-it.net/ [3] http://www.corsair.com/en/usb-drive/flash-padlock-2-usb-drive.html From peter at digitalbrains.com Sun Jan 5 10:35:44 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 05 Jan 2014 10:35:44 +0100 Subject: sign encrypted emails In-Reply-To: <2177361.8E2pnFKRuX@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <20140104150951.GA15241@leortable> <8372383.9Qlg9mTKm2@mani> <2177361.8E2pnFKRuX@inno.berlin.laging.de> Message-ID: <52C92770.2020408@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/01/14 04:38, Hauke Laging wrote: > You are aware that is doesn't make any sense to make this claim without any > argument after the opposite has been claimed with an argument (a very > strong one)? Eh? You yourself start this whole discussion by making the point that it is, as things are now, unreliable to act differently depending on whether encryption is applied to the message or not. That is precisely the whole strong argument why people say: you just shouldn't act differently depending on whether encryption is applied to the message or not. I really do not understand one bit why you now say this is a claim without any argument, I'm quite surprised. Unless you read "without any argument" as "this is a thing we agree on", but that requires bending the sentence beyond breaking point ;). I agree with Robert, you're trying to solve a social problem with a technical solution. 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 Jan 5 11:15:54 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 05 Jan 2014 11:15:54 +0100 Subject: sign encrypted emails In-Reply-To: <52C92770.2020408@digitalbrains.com> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <2177361.8E2pnFKRuX@inno.berlin.laging.de> <52C92770.2020408@digitalbrains.com> Message-ID: <2215471.Xktjj1KbVc@inno.berlin.laging.de> Am So 05.01.2014, 10:35:44 schrieb Peter Lebbing: > On 05/01/14 04:38, Hauke Laging wrote: > > You are aware that is doesn't make any sense to make this claim > > without any argument after the opposite has been claimed with an > > argument (a very strong one)? > > Eh? You yourself start this whole discussion by making the point that > it is, as things are now, unreliable to act differently depending on > whether encryption is applied to the message or not. There are two different meanings of "whether encryption is applied" which we must tell apart here: 1) The message arrives encrypted. 2) You know that the message has been sent encrypted. (1) follows from (2) but not the other way round. What I say is: a) It makes sense to act differently depending on (2). b) It does not make much sense to act differently depending on (1). Do you agree on (a) and (b)? Today you hardly ever have (2). That's what I want to change. > I really do not understand one bit why you now say this is a claim > without any argument, I'm quite surprised. I replied to: "One should certainly not act differently depending on the encryption of a message." Maybe there is a misunderstanding (maybe even between the one I replied to and the one he replied to). In an earlier mail I have explained (a). It seemed to me that he said (a) was wrong without giving any reason for that claim. Maybe he meant (b) but that would not have anything to do with the discussion I started as (b) is the reason for me starting it. > I agree with Robert, you're trying to solve a social problem with a > technical solution. In my understanding this term refers to problems which are better solved socially than technically. But that simply isn't the case here. Why should I write "I will encrypt this message to 0x12345678" in every mail which is boring, easily forgotten and error-prone if the problem can *easily* be solved technically with much better results? Why should people prefer to have to change their behaviour (social solution) over not having to change their behaviour if the second option delivers better results with less effort? There has been an argument of the kind: "There is another solution to the problem than yours." OK. But that's not the point. The point is: Which is better? This is about technical guarantees. How can a social approach ever be better than a technical one in that area? GnuPG doesn't teach people to create huge keys it prevents it technically. Solving a social problem with a technical solution? And if so: Is that a problem? 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 nb.linux at xandea.de Sun Jan 5 12:01:17 2014 From: nb.linux at xandea.de (nb.linux) Date: Sun, 05 Jan 2014 11:01:17 +0000 Subject: keysigning: lsign and offline master key In-Reply-To: <52C8A968.9090107@fifthhorseman.net> References: <52C8800C.5080107@xandea.de> <52C8A968.9090107@fifthhorseman.net> Message-ID: <52C93B7D.10505@xandea.de> Daniel Kahn Gillmor: > 0) --export-options export-local on your air-gapped system, combined > with --import-options import-local on your "regular" system. > Would either of these workflows meet your goals? Thanks! That's exactly what I was looking for. -- nb.linux From johanw at vulcan.xs4all.nl Sun Jan 5 13:18:58 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 05 Jan 2014 13:18:58 +0100 Subject: Quantum computing In-Reply-To: References: Message-ID: <52C94DB2.1060706@vulcan.xs4all.nl> On 4-1-2014 13:31, micha137 wrote: > A spoofing organization is no fertile ground for true innovation. The > real scientists, not the NSA are going to make progress in quantum > computing. And it is not going to be as cheap as some tens of megabucks. > Progress to get it practical will be painfully slow. > You IT people can sit back and relax. Not really, whoever builds a quantum computer doesn't really matter. As soon as the technology becomes widely available QC-resistant crypto becomes necessary anyway. -- Met vriendelijke groet / With kind regards, Johan Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wk at gnupg.org Sun Jan 5 13:27:42 2014 From: wk at gnupg.org (Werner Koch) Date: Sun, 05 Jan 2014 13:27:42 +0100 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: (Sam Kuper's message of "Sun, 5 Jan 2014 04:02:57 +0000") References: Message-ID: <87mwjak401.fsf@vigenere.g10code.de> On Sun, 5 Jan 2014 05:02, sam.kuper at uclmail.net said: > conventional USB stick-sized readers (e.g. Omnikey 6121) + ID-000 Take care: The Omnikey does not work with free software and 2048 bit or larger keys. Better get a Gemalto or Identive (SCM) reader. > In group 2 above, the smallest reader I have found online which offers > secure PIN entry is the ACR83. The question is whether this is really helpful. Yes, it protects your PIN but it does not protect the use of your decryption key. Even if the latter would be changed, it would also be quite inconvenient to enter the PIN for each encryption. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Sun Jan 5 14:04:49 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 05 Jan 2014 14:04:49 +0100 Subject: sign encrypted emails In-Reply-To: <2215471.Xktjj1KbVc@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <2177361.8E2pnFKRuX@inno.berlin.laging.de> <52C92770.2020408@digitalbrains.com> <2215471.Xktjj1KbVc@inno.berlin.laging.de> Message-ID: <52C95871.4070700@digitalbrains.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/01/14 11:15, Hauke Laging wrote: > Why should I write "I will encrypt this message to 0x12345678" in every > mail which is boring, easily forgotten and error-prone if the problem can > *easily* be solved technically with much better results? Don't write "I will encrypt this message"[1] in every mail hoping that the recipient deduces that you want to do secret stuff, and leaving them to deduce from the absence of that message that you want to do the regular stuff. Hoping that other people will infer meaning from things that are totally not apparent, /that/ is error-prone. If someone writes me a signed statement "see me tomorrow", I will show up. I will not come carrying my highly volatile nuclear concoction just because the message is encrypted. You should feel confident a signed statement is coming from the person who signed it. You can't deduce very much at all from the message arriving encrypted, I think. When the message arrives /unencrypted/ and contains confidential stuff, you could show up with a clue-bat and say "Dude, not cool, not cool", because it was obviously (within reason) sent unencrypted. But it being encrypted means nothing. The social solution is not "include some statement each and every time" but "don't deduce anything from it being encrypted". It's not a burden, it's a change of expectation. If you want to convey something to someone, just say so. Don't say "see me tomorrow", but say "I want to discuss X tomorrow with you, be sure to bring Y." HTH, Peter. [1] By the way, your statement might not even be true; how often have you written "See the attachment" and then forgetting to attach the file? I have done it countless times. - -- 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 nicholas.cole at gmail.com Sun Jan 5 14:24:01 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 5 Jan 2014 13:24:01 +0000 Subject: V3 key lookup Message-ID: Dear list, I've been implementing a local version of http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 for some experimenting. I have a server working listening on local host and replying with the correct formats to the defined requests. Everything works fine with version 4 keys, but if gpg (version 1 or 2) attempts to download a version 3 key, it simply exits with an error about no valid data found. The odd thing is that the request doesn't even show up in the server logs. As far as I can tell, gpg doesn't even attempt the request. What could be going wrong? Is it that for some reason the v3 code doesn't like a local host? N. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Jan 5 16:15:51 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 05 Jan 2014 10:15:51 -0500 Subject: sign encrypted emails In-Reply-To: <52C92770.2020408@digitalbrains.com> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <20140104150951.GA15241@leortable> <8372383.9Qlg9mTKm2@mani> <2177361.8E2pnFKRuX@inno.berlin.laging.de> <52C92770.2020408@digitalbrains.com> Message-ID: <52C97727.3060505@sixdemonbag.org> > I agree with Robert, you're trying to solve a social problem with a technical > solution. More to the point, he's solving the wrong problem and conflating policy with mechanism. GnuPG does not provide policy. Policy is the responsibility of the people using GnuPG. All GnuPG provides is mechanism. Your problem can be solved trivially by establishing a policy of, "Encrypted messages must contain a notification within the signed message body of who the message is encrypted for." For many users this sort of policy is a good idea. For the majority of users it's overkill. Why do you want a policy decision to be permanently enshrined in GnuPG's mechanism? From sam.kuper at uclmail.net Sun Jan 5 16:18:53 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Sun, 5 Jan 2014 15:18:53 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: <87mwjak401.fsf@vigenere.g10code.de> References: <87mwjak401.fsf@vigenere.g10code.de> Message-ID: On Jan 5, 2014 1:18 PM, "Werner Koch" wrote: > On Sun, 5 Jan 2014 05:02, sam.kuper at uclmail.net said: > Take care: The Omnikey does not work with free software and 2048 bit > or larger keys. Better get a Gemalto or Identive (SCM) reader. Thanks for the warning :) > > In group 2 above, the smallest reader I have found online which offers > > secure PIN entry is the ACR83. > > The question is whether this is really helpful. Yes, it protects your > PIN but it does not protect the use of your decryption key. Please could you elaborate? > Even if the > latter would be changed, it would also be quite inconvenient to enter > the PIN for each encryption. Security generally has to be weighed against convenience. Calluses are a small price to pay for a secure PIN :) Best regards, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Jan 5 16:27:12 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 05 Jan 2014 10:27:12 -0500 Subject: sign encrypted emails In-Reply-To: <52C95871.4070700@digitalbrains.com> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <2177361.8E2pnFKRuX@inno.berlin.laging.de> <52C92770.2020408@digitalbrains.com> <2215471.Xktjj1KbVc@inno.berlin.laging.de> <52C95871.4070700@digitalbrains.com> Message-ID: <52C979D0.4040805@sixdemonbag.org> > Don't write "I will encrypt this message"[1] in every mail hoping that the > recipient deduces that you want to do secret stuff, and leaving them to deduce > from the absence of that message that you want to do the regular stuff. Hoping > that other people will infer meaning from things that are totally not > apparent, /that/ is error-prone. There also seems to be something else at work here: an allergy to rigor. GnuPG is most often used in a slipshod, half-thought-through manner. People don't articulate a security model, much less establish a plan to mitigate those threats, much less negotiate a policy with their correspondents to mitigate threats held in common. Sometime watch the movie _Crimson Tide_. It's a good action film and the central premise revolves around a message that violates policy. A nuclear ballistic missile submarine is given a legitimate order to launch missiles at a Russian city. While preparing to launch, the submarine receives a second message telling them to abort the launch -- but due to forces beyond their control that message is received only as a fragment. The captain refers to the policy: "Any message that does not fully conform to the policy must be completely disregarded." The captain insists on launching, since the last policy-conformant message was a launch order. The executive officer insists, "We received an abort signal; at the very least we need to delay the launch until we can confirm it." The executive officer insists on deviating from policy. I cannot think of the last time I saw a Hollywood blockbuster that was built around what is, at its heart, a very technical question about how high-security communications operate. It's worth viewing. The short version is -- if you don't have a policy established, you're not going to be using GnuPG to provide its fullest amount of communications security. That policy also needs to tell people how to handle messages that don't conform to policy. From mailinglisten at hauke-laging.de Sun Jan 5 17:07:08 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 05 Jan 2014 17:07:08 +0100 Subject: sign encrypted emails In-Reply-To: <52C97727.3060505@sixdemonbag.org> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C92770.2020408@digitalbrains.com> <52C97727.3060505@sixdemonbag.org> Message-ID: <5129052.bdhuF362kt@inno.berlin.laging.de> Am So 05.01.2014, 10:15:51 schrieb Robert J. Hansen: > Your problem can be solved trivially by establishing a policy of, > "Encrypted messages must contain a notification within the signed > message body of who the message is encrypted for." That is neither trivial nor reliable nor the best approach to deliver this information. > For many users this sort of policy is a good idea. For the majority > of users it's overkill. Like verifying fingerprints? 8-) > Why do you want a policy decision to be > permanently enshrined in GnuPG's mechanism? As I said in my first mail in this thread this isn't about changing GnuPG at all because a) this problem is one level above GnuPG b) GnuPG already has all the capabilities necessary to do this. As I also said the reason why I have asked this here is the availability of people who can make useful comments on that (and are probably interested in such general discussions). 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 Sun Jan 5 17:45:25 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 05 Jan 2014 11:45:25 -0500 Subject: sign encrypted emails In-Reply-To: <5129052.bdhuF362kt@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C92770.2020408@digitalbrains.com> <52C97727.3060505@sixdemonbag.org> <5129052.bdhuF362kt@inno.berlin.laging.de> Message-ID: <52C98C25.8020001@sixdemonbag.org> > That is neither trivial nor reliable nor the best approach to deliver > this information. It is a trivial fix; whether it is reliable depends on how committed participants are towards enforcing policy. > As I said in my first mail in this thread this isn't about changing > GnuPG at all because Then why are we talking about this? > As I also said the reason why I have asked this here is the availability > of people who can make useful comments on that (and are probably > interested in such general discussions). You are receiving useful comments. You are choosing to disregard them. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From nicholas.cole at gmail.com Sun Jan 5 17:48:58 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 5 Jan 2014 16:48:58 +0000 Subject: V3 key lookup In-Reply-To: References: Message-ID: On Sun, Jan 5, 2014 at 1:24 PM, Nicholas Cole wrote: > Dear list, > > I've been implementing a local version of > > http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 > > for some experimenting. > > I have a server working listening on local host and replying with the > correct formats to the defined requests. > > Everything works fine with version 4 keys, but if gpg (version 1 or 2) > attempts to download a version 3 key, it simply exits with an error about no > valid data found. > > The odd thing is that the request doesn't even show up in the server logs. > As far as I can tell, gpg doesn't even attempt the request. > > What could be going wrong? Is it that for some reason the v3 code doesn't > like a local host? At the risk of answering my own question experiments on the console (rather than using a front-end) revealed the helpful message: """ gpg: requesting key ?v3 fpr? from hkp server localhost gpgkeys: HKP keyservers do not support v3 fingerprints gpg: no valid OpenPGP data found. gpg: Total number processed: 0 gpg: keyserver internal error """ Thanks Werner for making your error messages so clear. From kloecker at kde.org Sun Jan 5 18:43:35 2014 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 05 Jan 2014 18:43:35 +0100 Subject: sign encrypted emails In-Reply-To: <52C95871.4070700@digitalbrains.com> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <2215471.Xktjj1KbVc@inno.berlin.laging.de> <52C95871.4070700@digitalbrains.com> Message-ID: <3134415.mNv6v6lQMj@thufir.ingo-kloecker.de> On Sunday 05 January 2014 14:04:49 Peter Lebbing wrote: > [1] By the way, your statement might not even be true; how often have > you written "See the attachment" and then forgetting to attach the > file? I have done it countless times. I bet Hauke never forgot to attach the file because he is using KMail which warns him about this. Recent Thunderbirds also shows such a warning. (I suppose this also counts as technical solution for a social problem. ;-) If one always attached the file the second one wrote "See the attachment", then one'd never forget to attach it and the technical solution wouldn't be necessary.) 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 ekleog at gmail.com Sun Jan 5 03:10:48 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Sun, 5 Jan 2014 03:10:48 +0100 Subject: sign encrypted emails In-Reply-To: <8372383.9Qlg9mTKm2@mani> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C75661.8010409@fifthhorseman.net> <20140104150951.GA15241@leortable> <8372383.9Qlg9mTKm2@mani> Message-ID: <20140105021048.GB15241@leortable> On Sat, Jan 04, 2014 at 10:28:26PM +0100, Johannes Zarl wrote: > On Saturday 04 January 2014 16:09:51 Leo Gaspard wrote: > > On Fri, Jan 03, 2014 at 07:31:29PM -0500, Daniel Kahn Gillmor wrote: > > > In your example, the fact that a message was encrypted makes the > > > recipient treat it as though the sender had indicated something specific > > > about the message because it was encrypted. This is bad policy, since > > > there is no indication that the sender encrypted the message themselves, > > > or even knew that the message was encrypted. > > > > Which is exactly the reason for which Hauke proposed to sign the encrypted > > message in addition to signing the cleartext message, is it not? > > Wouldn't one have to encrypt the signed-encrypted-signed message again to > prevent an attacker from stripping away the outer signature? What would the > recipient then do with the simple signed-encrypted message? Well, the idea would be that the receiving program would check there *is* an additional signature, and refuse it if not. Nevertheless, adding a second layer of encryption would help, both in avoiding this threat with less requirements on the receiving program, and in avoiding the metadata-analysis and irrevocability threat. Less requirements, as the receiving program merely has to run decrypt-and-check twice, not having to check it actually has two levels of signature, as any absence of the second level would be detected by a failed second check. Avoiding metadata analysis, as encrypting the second signature forbids an attacker to grab a message and have an undeniable proof that Alice sent an encrypted message to Bob, even without Bob's help. > > Sure, there might be other ways: add a message stating to which key the > > message is encrypted, etc. But this one has the advantage of requiring > > AFAICT no alteration to the standard, and of being easily automated, for > > humans are quite poor at remembering to always state to which key they > > encrypt. > > > > Anyway, wouldn't you react differently depending on whether a message was > > encrypted to your offline key or unencrypted? > > One should certainly not act differently depending on the encryption of a > message. Maybe with the one exception of timeliness: If a message is > encrypted, you'll probably be ok with me reading the mail when I'm at my home > computer. If a message is encrypted to my offline key, you'll be prepared to > wait for a month or so (many people have their offline-key in a safe deposit > box). > > Of course this opens way to subtle timing attacks (delaying reading a message > until it is no longer relevant), but these subtle attacks can be done using > simpler means (holding the message in transit). Well... I, personally, would attach more importance (no more validity, just importance, like in "listen to me very well" or whatever english people say to others to get them to listen carefully) to a message signed to an offline main key that might wait for a month than to a message sent in cleartext. For I would assume the sender designed his message to be important enough to make me move to my safe deposit box so as to read it. Of course, without encryption-checking, this assumption is wrong, and this is emphasized in one of my previous messages on this thread, with the "We got to talk tomorrow" taking importance for the receiver that is unexpected to the sender, thus leading to a security flaw. From johannes at zarl.at Mon Jan 6 00:31:59 2014 From: johannes at zarl.at (Johannes Zarl) Date: Mon, 06 Jan 2014 00:31:59 +0100 Subject: sign encrypted emails In-Reply-To: <20140105021048.GB15241@leortable> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <8372383.9Qlg9mTKm2@mani> <20140105021048.GB15241@leortable> Message-ID: <2252677.0zG1Id6UkM@mani> On Sunday 05 January 2014 03:10:48 Leo Gaspard wrote: > Well... I, personally, would attach more importance (no more validity, just > importance, like in "listen to me very well" or whatever english people say > to others to get them to listen carefully) to a message signed to an > offline main key that might wait for a month than to a message sent in > cleartext. For I would assume the sender designed his message to be > important enough to make me move to my safe deposit box so as to read it. In my feeling this is a rather subjective (to the sender) thing: some people encrypt *every* message no matter how trivial. Other people only encrypt those messages that match some rather specific criteria. Both kinds of people have good reasons for their behaviour. That's the reason why I don't attach an intrinsic importance or anything else to the fact that a message is encrypted. I can see your reasoning behind "that message feels more important", and I'm quite sure that many people feel that way. It's just that it went away for me some time after receiving the n'th encrypted grocery list. > Of course, without encryption-checking, this assumption is wrong, and this > is emphasized in one of my previous messages on this thread, with the "We > got to talk tomorrow" taking importance for the receiver that is unexpected > to the sender, thus leading to a security flaw. Yeah. That's definitely what I meant when I said that one should not act differently. Though if you want a really fancy policy you could require non-encrypted messages to be discarded and use the signed-but-not-encrypted communications for counter-intelligence. *g* (Yes, I know the flaw here is not-so-subtle...) From dougb at dougbarton.us Mon Jan 6 01:41:11 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 05 Jan 2014 16:41:11 -0800 Subject: sign encrypted emails In-Reply-To: <5129052.bdhuF362kt@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <52C92770.2020408@digitalbrains.com> <52C97727.3060505@sixdemonbag.org> <5129052.bdhuF362kt@inno.berlin.laging.de> Message-ID: <52C9FBA7.1040406@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/05/2014 08:07 AM, Hauke Laging wrote: | Am So 05.01.2014, 10:15:51 schrieb Robert J. Hansen: | |> >Your problem can be solved trivially by establishing a policy of, |> >"Encrypted messages must contain a notification within the signed |> >message body of who the message is encrypted for." | | That is neither trivial nor reliable nor the best approach to deliver | this information. It can be both trivial and reliable, simply place the following in your .signature file: I will not encrypt this message before sending. On those occasions when you do encrypt, remove the word "not." Now your (reasonable) objection is likely to be, "But what if the sender forgets to remove the word 'not'?" Well in that case we're right back to where we started, you cannot solve problems of bad operational practices with technology. No matter how fool-proof you make the tech, the universe will come along with a better fool. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSyfunAAoJEFzGhvEaGryEQR4H+gK3ZfMpugnnHMtiRclDsWID isMMuTzal57Zze7R0QbJE6hc7AEXdefr8hMDLUbbKgNO6SUspd8Yu8LAjxBSJla+ HW1xAh49M3yBLYgyJtfZhJAE39Ttsmpcdg2A2X7Z1xBiPsZXH7fbJqXEpOhjM0z1 BuBLZUZ7/Ama6DzcRavEoa/jLymCeaCRGSp765Z70qWrF4ZnsfAdRGXPTyQAsgeH OKRAzje5fUbLk5W4sbgiuJVJ9D7ORuvB3mUlimA1oqV6F3G+giTHR4eyzhzGiqsM YpslkIzy06X8fFpiB00qigw9wjdrtQUqk8xG6iC6D7CIjXspmEnyvriIfUGS8xA= =LjnW -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Mon Jan 6 01:51:50 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 06 Jan 2014 01:51:50 +0100 Subject: sign encrypted emails In-Reply-To: <52C9FBA7.1040406@dougbarton.us> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <5129052.bdhuF362kt@inno.berlin.laging.de> <52C9FBA7.1040406@dougbarton.us> Message-ID: <9582920.nVUfbaXZcU@inno.berlin.laging.de> Am So 05.01.2014, 16:41:11 schrieb Doug Barton: > It can be both trivial and reliable, simply place the following in > your .signature file: > > I will not encrypt this message before sending. > > On those occasions when you do encrypt, remove the word "not." Let me guess: Modifying the mail client so that it automatically removes the word "not" would be illegitimate because for some strange reason that would be "solving social problems by technical means"... -- 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 Mon Jan 6 02:26:16 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 05 Jan 2014 20:26:16 -0500 Subject: sign encrypted emails In-Reply-To: <9582920.nVUfbaXZcU@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <5129052.bdhuF362kt@inno.berlin.laging.de> <52C9FBA7.1040406@dougbarton.us> <9582920.nVUfbaXZcU@inno.berlin.laging.de> Message-ID: <52CA0638.8060700@sixdemonbag.org> > Let me guess: Modifying the mail client so that it automatically removes > the word "not" would be illegitimate because for some strange reason > that would be "solving social problems by technical means"... Hauke, at this point you've advocated your idea -- strongly -- and you've received a general response that is not favorable. Now, no one is saying you need to give up on this idea: but if you want to pursue this idea, you're going to need to implement it yourself. The best way to prove us wrong is to write a patch that will implement your idea. Reality is the ultimate test of all new ideas; make it real, put it out there, and let the marketplace of ideas choose. But for now, I don't think you're persuading anyone into implementing this for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From expires2013 at ymail.com Mon Jan 6 02:47:39 2014 From: expires2013 at ymail.com (MFPA) Date: Mon, 6 Jan 2014 01:47:39 +0000 Subject: sign encrypted emails In-Reply-To: <2002014.1CKrbWpAov@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <1075766552.20140103100228@my_localhost> <2002014.1CKrbWpAov@inno.berlin.laging.de> Message-ID: <242100547.20140106014739@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 3 January 2014 at 10:28:28 AM, in , Hauke Laging wrote: MFPA: >> Again, this would be flagged up if the sender was in >> the habit of signing outgoing messages (as you >> stated). > No, it wouldn't. The reason is that the signature is > created the same way in the two cases encrypted and > non-encrypted. Thus you can apply encryption later > with the recipient having no chance at all to determine > who encrypted. Most "signed and encrypted" messages created with PGP or GnuPG have the two processes applied together - you do not normally decrypt a message and then see a signed message as the output. An exception is "signed and encrypted" messages created in the Hushmail web interface. - -- Best regards MFPA mailto:expires2013 at ymail.com Confusion is always the most honest response -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLKC0pXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p50IEAKcL07PhoNvgH52ulIc+5ZPbo3dm1MH1a8aK nrecrH7gdIkNgriytz7bgOyK5TWmmar2c0LdDqWN5qw+iq/BdcUpokwd2fZC3ckQ z9cJe4BWBwKaTXYMSc1DTeoHage0Awuuv8E3P6cpFm0C6hiyQATbZw3kH0U4XfXj mxykuAU+ =F7H3 -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Mon Jan 6 03:24:10 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 06 Jan 2014 03:24:10 +0100 Subject: isolating the signature from encrypted data (was: sign encrypted emails) In-Reply-To: <242100547.20140106014739@my_localhost> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <2002014.1CKrbWpAov@inno.berlin.laging.de> <242100547.20140106014739@my_localhost> Message-ID: <7677715.1slNLpWZ3j@inno.berlin.laging.de> Am Mo 06.01.2014, 01:47:39 schrieb MFPA: > Most "signed and encrypted" messages created with PGP or GnuPG have > the two processes applied together - you do not normally decrypt a > message and then see a signed message as the output. That is correct. I am not aware of a possibility to get the data and the signature from GnuPG. But that doesn't mean it's not possible. AFAIK there is no difference in the signature in both cases. So it should be easy to patch GnuPG in order to get this data (if there isn't another OpenPGP implementation which offers this action). Use both ways (one step, two steps) to sign and encrypt a file and have a look at the result with gpg --list-packets. http://lists.gnupg.org/pipermail/gnupg-users/2004-April/022352.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 wk at gnupg.org Mon Jan 6 10:34:06 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 Jan 2014 10:34:06 +0100 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: (Sam Kuper's message of "Sun, 5 Jan 2014 15:18:53 +0000") References: <87mwjak401.fsf@vigenere.g10code.de> Message-ID: <874n5hihdd.fsf@vigenere.g10code.de> On Sun, 5 Jan 2014 16:18, sam.kuper at uclmail.net said: >> The question is whether this is really helpful. Yes, it protects your >> PIN but it does not protect the use of your decryption key. > > Please could you elaborate? To make use of the decryption key the smartcard first requires that a VERIFY command is send to the card. This is what asks for the PIN. After a successful verification of the PIN the card allows the use of the PSO Decrypt command until a power down or a reset operation. Thus an attacking malware only needs to trick you info decrypt an arbitrary message and is then free to use the smartcard without having the reader ask you again for a PIN. For the signature key we have this "forcesig" command which switches the card into a mode which requires a VERIFY command before each PSO Sign command. There is also the signature counter to tell you how often the signature key has been used. But for the other two keys we don't have such features. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jan 6 10:37:39 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 Jan 2014 10:37:39 +0100 Subject: V3 key lookup In-Reply-To: (Nicholas Cole's message of "Sun, 5 Jan 2014 16:48:58 +0000") References: Message-ID: <87wqidh2n0.fsf@vigenere.g10code.de> On Sun, 5 Jan 2014 17:48, nicholas.cole at gmail.com said: > Thanks Werner for making your error messages so clear. David did this and most other parts of the keyserver code. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Mon Jan 6 11:48:24 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 06 Jan 2014 11:48:24 +0100 Subject: sign encrypted emails In-Reply-To: <9582920.nVUfbaXZcU@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <5129052.bdhuF362kt@inno.berlin.laging.de> <52C9FBA7.1040406@dougbarton.us> <9582920.nVUfbaXZcU@inno.berlin.laging.de> Message-ID: <52CA89F8.1030309@digitalbrains.com> On 06/01/14 01:51, Hauke Laging wrote: > Let me guess: Modifying the mail client so that it automatically removes > the word "not" would be illegitimate because for some strange reason > that would be "solving social problems by technical means"... I guess it boils down to the point that I just don't see a use case. I believe there are two scenario's you're treating: - You wish to give significance to a mail being encrypted; this, for you, changes the context of the contents. I disagree; I'd rather see it context-free and unambiguous[1]. - You wish to catch noobs in the act when they forget to encrypt. I think secure communications with noobs is impossible, so it doesn't help to plug a single hole in the sieve[2]. The result is that I see no application for what you describe. At to that the fact I find it a rather ugly kludge to sign a single message twice instead of keeping all authenticated data inside the one signature, and you've lost me. So I guess this discussion is indeed pretty much done. HTH, Peter. [1] Hmmm, maybe we should define a formal e-mail language ;) [2] I'm using noobs rather broadly here, since I think it takes a lot of attention and rigour to secure communications. -- 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 erik.hjalmar.josefsson at gmail.com Mon Jan 6 11:09:55 2014 From: erik.hjalmar.josefsson at gmail.com (Erik Josefsson) Date: Mon, 06 Jan 2014 11:09:55 +0100 Subject: "no valid subkey" Message-ID: <52CA80F3.8040808@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, This might not be the best place for beginners to ask for help, but the reason I subscribed is that icedove says I have "no valid subkey" to my two registered email addresses: http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0xB240C11D Further, a friend told me that his key-manager won't let him encrypt to one of them. A pointer to a beginners "how to" fix this would be much appreciated. Best regards. //Erik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJSyoDwAAoJECDb7wayQMEd9CkQANDD/jkAs2S63137MPb01Qww 2EwShbybNi94uSJMnc0aYn0OpENLCGLPYibcQoTWQwq1ktafUVeehom2akwYydC7 jT57zTOepY9KRV/yAiSHG8h9dFs8vhGoCVxC/xF1vwdT9zErzA2rwRrRLPjkeaiX NoMunfrA2n0QC+nI30mklhtyndMV1+gJ1oD3wtSQL7SGbv6eSo2rcAGIng5e9jxC i1c+Hg856Q6XZQdVQkovW4hAIiaTb26TL6kuRrAO4kYb9qEhzOF04q9Egzo7FJh9 4raD3rJ7R/1V9CF/6GQSgXrcgJ84K+Bac2gLxKcy5Cm3Lag1Tc3a/1dfe57BP5Qa zWmY23h0jfMcDBJwW2XiTkxCtLgx+xuDMQaHzmJqrOJC95JHbK/NcDg7Boovhjq7 /FRi/vkj8DS+tW7lGUnleAEx0XWA7oWUan+5464d7wXzsXvKBTf1nX74c0LYVqYh R0dxXs5lmHa61fHgcrRZIZOFBBtfIgTIO3MrVY95N9zxwQ4YsvyCGaT88ZFJMxDR GNcNWGjtwG94eUvu0kj0y+f5a1XAZwGvDTOjpAXiRDcq22R/gIIdMdIQZq1ZEWMY RWYJu7WhElh/n3KDS+pOpTalSi7WGIQ5SCR0ia+favbjQqgHbIY9JpuECTJXnUbw pI0ifWcM50oH4BKFgFH7 =+pD2 -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Mon Jan 6 12:30:05 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 06 Jan 2014 12:30:05 +0100 Subject: "no valid subkey" In-Reply-To: <52CA80F3.8040808@gmail.com> References: <52CA80F3.8040808@gmail.com> Message-ID: <9717161.iLznBIg7JV@inno.berlin.laging.de> Am Mo 06.01.2014, 11:09:55 schrieb Erik Josefsson: > Further, a friend told me that his key-manager won't let him encrypt > to one of them. Not surprising: pub 4096R/0xB240C11D 2010-12-10 [expires: 2014-11-11] uid Erik Josefsson uid Erik Josefsson (ehj) sub 4096R/0x0971954D 2010-12-10 [expired: 2013-12-09] ^^^^^^^^^^^^^^^^^^^ > A pointer to a beginners "how to" fix this would be much appreciated. You must extend the validity period of the subkey. This may be easier with a GUI (GPA cannot do that but Enigmails key management can). In the console it's this: gpg --edit-key 0xB240C11D _ > key 1 _ > expire _ > ... _ > save 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 Mon Jan 6 12:33:49 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 Jan 2014 12:33:49 +0100 Subject: "no valid subkey" In-Reply-To: <52CA80F3.8040808@gmail.com> (Erik Josefsson's message of "Mon, 06 Jan 2014 11:09:55 +0100") References: <52CA80F3.8040808@gmail.com> Message-ID: <87bnzpgx9e.fsf@vigenere.g10code.de> On Mon, 6 Jan 2014 11:09, erik.hjalmar.josefsson at gmail.com said: > reason I subscribed is that icedove says I have "no valid subkey" to my > two registered email addresses: Your encryption subkey expired a month ago. > A pointer to a beginners "how to" fix this would be much appreciated. $ gpg --edit-key 0xb240c11d gpg> addkey and then follow the prompts. You probably want to add an RSA encryption subkey of the suggested size. After the key has been generated, enter "save" and back to the command line send your key to the keyservers: gpg --send-key 0xb240c11d Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ndk.clanbo at gmail.com Mon Jan 6 13:16:09 2014 From: ndk.clanbo at gmail.com (NdK) Date: Mon, 06 Jan 2014 13:16:09 +0100 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: <874n5hihdd.fsf@vigenere.g10code.de> References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: <52CA9E89.1070705@gmail.com> Il 06/01/2014 10:34, Werner Koch ha scritto: > To make use of the decryption key the smartcard first requires that a > VERIFY command is send to the card. This is what asks for the PIN. > After a successful verification of the PIN the card allows the use of > the PSO Decrypt command until a power down or a reset operation. Thus > an attacking malware only needs to trick you info decrypt an arbitrary > message and is then free to use the smartcard without having the reader > ask you again for a PIN. Is it just convenience or enforcing it (e.g. adding a "forcedecauth" flag) would lead to usability issues (maybe because sometimes decryption is called many times in sequence)? That would be the case for auth key, I think: using it to auth against a web page would ask auth for every sub-request of objects on the page. BYtE, Diego. From lists at michel-messerschmidt.de Mon Jan 6 15:47:06 2014 From: lists at michel-messerschmidt.de (Michel Messerschmidt) Date: Mon, 6 Jan 2014 15:47:06 +0100 Subject: "no valid subkey" In-Reply-To: <52CA80F3.8040808@gmail.com> References: <52CA80F3.8040808@gmail.com> Message-ID: <20140106144706.GA6518@ryu.matrix> As an additional hint how to find your encryption key (as opposed to signature or authentication keys), you need to look for keys with "usage: E". In your case it is 0971954D: $ gpg2 --edit-key 0xB240C11D pub 4096R/B240C11D created: 2010-12-10 expires: 2014-11-11 usage: SC trust: unknown validity: unknown sub 2048R/0320F4A4 created: 2014-01-06 expires: 2014-11-11 usage: S sub 4096R/0971954D created: 2010-12-10 expires: 2014-11-11 usage: E [ unknown] (1). Erik Josefsson [ unknown] (2) Erik Josefsson (ehj) -- Michel Messerschmidt lists at michel-messerschmidt.de From lists at michel-messerschmidt.de Mon Jan 6 16:10:06 2014 From: lists at michel-messerschmidt.de (Michel Messerschmidt) Date: Mon, 6 Jan 2014 16:10:06 +0100 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: <874n5hihdd.fsf@vigenere.g10code.de> References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: <20140106151006.GB6518@ryu.matrix> On Mon, Jan 06, 2014 at 10:34:06AM +0100, Werner Koch wrote: > an attacking malware only needs to trick you info decrypt an arbitrary > message and is then free to use the smartcard without having the reader > ask you again for a PIN. Although these are important attacks to consider, PIN entry on the reader itself still provides additional protection if you want to protect your own signatures. > But for the other two keys we don't have such features. There is the obvious possibility to remove and re-insert the card after every use to reduce this attack surface somewhat. But for such a tradeoff other things should be considerd first (is your PIN really your biggest concern if you don't trust your computer/keyboard, is your reader really more trustworthy than your computer, ...). -- Michel Messerschmidt lists at michel-messerschmidt.de From hans at guardianproject.info Tue Jan 7 04:01:09 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 06 Jan 2014 22:01:09 -0500 Subject: using an OpenPGP card with Java (keytool and jarsigner) Message-ID: <52CB6DF5.6040204@guardianproject.info> Hey all, Does anyone know if there is any chance of using an OpenPGP smart card for Java? I know that GnuPG doesn't support PKCS#11, but I was wondering if things work the otherway around: java using the OpenPGP card. It would be super useful to be able to use the same smartcard for both Android APK signing and OpenPGP signing. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From ndk.clanbo at gmail.com Tue Jan 7 12:02:02 2014 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 07 Jan 2014 12:02:02 +0100 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <52CB6DF5.6040204@guardianproject.info> References: <52CB6DF5.6040204@guardianproject.info> Message-ID: <52CBDEAA.6000906@gmail.com> Il 07/01/2014 04:01, Hans-Christoph Steiner ha scritto: > Does anyone know if there is any chance of using an OpenPGP smart card for > Java? I know that GnuPG doesn't support PKCS#11, but I was wondering if > things work the otherway around: java using the OpenPGP card. It would be > super useful to be able to use the same smartcard for both Android APK signing > and OpenPGP signing. IIRC there is an OpenSC "driver" for OpenPGP cards, that makes 'em accessible throught PKCS#11. https://www.mail-archive.com/opensc-devel at lists.opensc-project.org/msg06206.html Seems it's quite old... Maybe if you want to take over developement... BYtE, Diego. From hans at guardianproject.info Tue Jan 7 15:32:45 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 07 Jan 2014 09:32:45 -0500 Subject: using an OpenPGP card with Java (keytool and jarsigner) Message-ID: <52CC100D.9080303@guardianproject.info> NdK wrote: > Il 07/01/2014 04:01, Hans-Christoph Steiner ha scritto: > >> Does anyone know if there is any chance of using an OpenPGP smart card for >> Java? I know that GnuPG doesn't support PKCS#11, but I was wondering if >> things work the otherway around: java using the OpenPGP card. It would be >> super useful to be able to use the same smartcard for both Android APK signing >> and OpenPGP signing. > IIRC there is an OpenSC "driver" for OpenPGP cards, that makes 'em > accessible throught PKCS#11. > > https://www.mail-archive.com/opensc-devel at lists.opensc-project.org/msg06206.html > > Seems it's quite old... Maybe if you want to take over developement... > > BYtE, > Diego. opensc's support for the OpenPGP card has improved quite a bit in 0.13, it seems. There is now full write support and a specific 'openpgp-tool' even: https://www.opensc-project.org/opensc/wiki/OpenPGP I don't need write support at all, I just want to get keytool to use the OpenPGP card as a PKCS11 keystore. It seems that things are close: Java can use NSS as a provider of PKCS11. I guess the question is whether opensc is making a PKCS#11 interface to the OpenPGP card, that's the bit that I don't fully understand. Once I figure this out, my plan is to integrate my work into the relevant Debian packages, and then promote the use of the OpenPGP card for Android APK signing keys. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From sam.kuper at uclmail.net Tue Jan 7 16:28:10 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Tue, 7 Jan 2014 15:28:10 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: <874n5hihdd.fsf@vigenere.g10code.de> References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: Dear Werner, Thank you for your kind reply. On 06/01/2014, Werner Koch wrote: >>> The question is whether this is really helpful. Yes, it protects your >>> PIN That is helpful. No question about this part! > After a successful verification of the PIN the card allows the use of > the PSO Decrypt command until a power down or a reset operation. I have several questions about this statement. If, after reading them, you believe there exists documentation that should be able to answer them, then please simply point me to that documentation. 1. The document "Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems, Version 2.0.1"[1] mentions "PSO:DEC" but does not define it. That document also mentions "PSO:DECRYPT" but does not define it. And finally, that document defines "PSO: DECIPHER". Are these three terms synonyms, or do they denote different things? 2. I assume that your "PSO Decrypt" means the same as "PSO:Decrypt" in the specification document mentioned above. Is this assumption correct? 3. When you say, "a power down or a reset operation", do you mean (a) "the card is powered down or reset", or (b) "the host computer is powered down or reset", or (c) something else? > Thus > an attacking malware only needs to trick you [into decrypting] an arbitrary > message and is then free to use the smartcard without having the reader > ask you again for a PIN. That is somewhat disappointing to me, although perhaps that is because my knowledge is limited and I am simply unaware of a good reason for this behaviour. Anyhow, am I right in thinking that, having verified the PIN and decrypted a message, disconnecting the reader from the PC (or removing the card from the reader, or both), would cause subsequent malicious attempts to call PSO Decrypt, to result in failure (at least until the card and reader have been reconnected to the host PC and the PIN verified again)? > For the signature key we have this "forcesig" command which switches the > card into a mode which requires a VERIFY command before each PSO Sign > command. I can't find the string "PSO Sign" in [1]. Are you using it synonymously with "PSO: COMPUTE DIGITAL SIGNATURE" (and/or "PSO:CDS")? If not, please can you tell me where the "PSO Sign" command is documented? I can't find the string "forcesig" in [1]. Please can you tell me where it is documented? Many thanks, Sam [1] http://g10code.com/docs/openpgp-card-2.0.pdf From wk at gnupg.org Tue Jan 7 17:27:51 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Jan 2014 17:27:51 +0100 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: (Sam Kuper's message of "Tue, 7 Jan 2014 15:28:10 +0000") References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: <87iotvdaew.fsf@vigenere.g10code.de> On Tue, 7 Jan 2014 16:28, sam.kuper at uclmail.net said: > "PSO:DEC" but does not define it. That document also mentions > "PSO:DECRYPT" but does not define it. And finally, that document > defines "PSO: DECIPHER". Are these three terms synonyms, or do they I guess so. > 2. I assume that your "PSO Decrypt" means the same as "PSO:Decrypt" in > the specification document mentioned above. Is this assumption > correct? Yep. > 3. When you say, "a power down or a reset operation", do you mean (a) > "the card is powered down or reset", or (b) "the host computer is > powered down or reset", or (c) something else? With "power down" I mean that you remove power from the card. Thus the next time you access the card it will do a cold start. By reset I mean a couple of commands. For example selecting a different application or selecting again the OpenPGP app should reset the card state. But you better check the specs. >> an attacking malware only needs to trick you [into decrypting] an arbitrary >> message and is then free to use the smartcard without having the reader >> ask you again for a PIN. > > That is somewhat disappointing to me, although perhaps that is because > my knowledge is limited and I am simply unaware of a good reason for > this behaviour. Without that you won't like to read a bunch of encrypted mails. > the card from the reader, or both), would cause subsequent malicious > attempts to call PSO Decrypt, to result in failure (at least until the Right. Most likely they the PIN retry counter goes down until the card is locked. Thus attacking malware may easily DoS your card - however malware is commonly not interested in getting noticed by the user. I heard that some pinpad equipped readers have filters for the VERIFY command so that the HOST may not issue a plain VERIFY command to bypass the pinpad. > I can't find the string "PSO Sign" in [1]. Are you using it > synonymously with "PSO: COMPUTE DIGITAL SIGNATURE" (and/or "PSO:CDS")? Yep. Apologies for my non-standard compliant terms. > I can't find the string "forcesig" in [1]. Please can you tell me > where it is documented? See the card HOWTO or try gpg --card-edit, admin, help. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Tue Jan 7 21:35:51 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 07 Jan 2014 21:35:51 +0100 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: <87iotvdaew.fsf@vigenere.g10code.de> References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> <87iotvdaew.fsf@vigenere.g10code.de> Message-ID: <52CC6527.90305@digitalbrains.com> On 07/01/14 17:27, Werner Koch wrote: > See the card HOWTO or try gpg --card-edit, admin, help. Additionally, in the OpenPGP Card 2.0.1 spec, the DO with tag C4 on page 17, section 7.2.2 (VERIFY) and section 7.2.8 (PSO: COMPUTE DIGITAL SIGNATURE) all specify this one-VERIFY-per-SIG behaviour. 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 hans at guardianproject.info Tue Jan 7 22:37:05 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 07 Jan 2014 16:37:05 -0500 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <52CC100D.9080303@guardianproject.info> References: <52CC100D.9080303@guardianproject.info> Message-ID: <52CC7381.7020102@guardianproject.info> On 01/07/2014 09:32 AM, Hans-Christoph Steiner wrote: > > NdK wrote: >> Il 07/01/2014 04:01, Hans-Christoph Steiner ha scritto: >> >>> Does anyone know if there is any chance of using an OpenPGP smart card for >>> Java? I know that GnuPG doesn't support PKCS#11, but I was wondering if >>> things work the otherway around: java using the OpenPGP card. It would be >>> super useful to be able to use the same smartcard for both Android APK signing >>> and OpenPGP signing. >> IIRC there is an OpenSC "driver" for OpenPGP cards, that makes 'em >> accessible throught PKCS#11. >> >> https://www.mail-archive.com/opensc-devel at lists.opensc-project.org/msg06206.html >> >> Seems it's quite old... Maybe if you want to take over developement... >> >> BYtE, >> Diego. > > opensc's support for the OpenPGP card has improved quite a bit in 0.13, it > seems. There is now full write support and a specific 'openpgp-tool' even: > https://www.opensc-project.org/opensc/wiki/OpenPGP > > I don't need write support at all, I just want to get keytool to use the > OpenPGP card as a PKCS11 keystore. It seems that things are close: Java can > use NSS as a provider of PKCS11. I guess the question is whether opensc is > making a PKCS#11 interface to the OpenPGP card, that's the bit that I don't > fully understand. > > Once I figure this out, my plan is to integrate my work into the relevant > Debian packages, and then promote the use of the OpenPGP card for Android APK > signing keys. > > .hc So now I have it to the point where I can see the certificate on the OpenPGP card with keytool, but I can't get jarsigner to use it. Do I have to mark the key on the card as a signing key somehow? Is it just not possible to have the PKCS#11 certificate part of the OpenPGP card be used as a signing key? Here is the debug transcripts of my keytool and jarsigner commands: $ keytool -v -keystore NONE -storetype PKCS11 -providerName SunPKCS11-OpenSC -list Enter keystore password: Keystore type: PKCS11 Keystore provider: SunPKCS11-OpenSC Your keystore contains 1 entry Alias name: Cardholder certificate Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: O=Internet Widgits Pty Ltd, L=Brooklny, ST=New York, C=US Issuer: O=Internet Widgits Pty Ltd, L=Brooklny, ST=New York, C=US Serial number: d76589b02e0f422a Valid from: Mon Jan 06 20:09:06 EST 2014 until: Wed Feb 05 20:09:06 EST 2014 Certificate fingerprints: MD5: 75:CB:92:5C:F8:4B:F3:0D:54:59:48:D5:4D:8A:08:5B SHA1: 57:C1:4B:12:26:55:66:0E:94:5A:D1:53:46:C0:76:6E:D5:3F:08:91 SHA256: F6:EC:49:9A:AB:04:1A:E0:EE:89:E2:D1:21:8D:79:42:7F:B5:5F:2E:B2:F7:10:53:38:CD:85:20:92:78:69:9F Signature algorithm name: SHA1withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 85 1F 1B 01 09 3D 12 E2 88 17 0C 91 50 5F 88 1E .....=......P_.. 0010: D3 C1 1B D0 .... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 85 1F 1B 01 09 3D 12 E2 88 17 0C 91 50 5F 88 1E .....=......P_.. 0010: D3 C1 1B D0 .... ] ] ******************************************* ******************************************* $ export OPENSC_DEBUG=2 $ jarsigner -verbose -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg /etc/java-7-openjdk/security/opensc.cfg libs/commons-io-2.2.jar "Cardholder certificate" -J-Djava.security.debug=sunpkcs11 SunPKCS11 loading /etc/java-7-openjdk/security/opensc.cfg sunpkcs11: Initializing PKCS#11 library /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so Information for provider SunPKCS11-OpenSC Library info: cryptokiVersion: 2.20 manufacturerID: OpenSC (www.opensc-project.org) flags: 0 libraryDescription: Smart card PKCS#11 API libraryVersion: 0.00 All slots: -1, 1, 2 Slots with tokens: 1, 2 Slot info for slot 2: slotDescription: Gemalto GemPC Key 00 00 manufacturerID: OpenSC (www.opensc-project.org) flags: CKF_TOKEN_PRESENT | CKF_REMOVABLE_DEVICE | CKF_HW_SLOT hardwareVersion: 0.00 firmwareVersion: 0.00 Token info for token in slot 2: label: OpenPGP card (User PIN) manufacturerID: ZeitControl model: PKCS#15 emulated serialNumber: 0005000014f9 flags: CKF_RNG | CKF_LOGIN_REQUIRED | CKF_USER_PIN_INITIALIZED | CKF_TOKEN_INITIALIZED ulMaxSessionCount: CK_EFFECTIVELY_INFINITE ulSessionCount: 0 ulMaxRwSessionCount: CK_EFFECTIVELY_INFINITE ulRwSessionCount: 0 ulMaxPinLen: 32 ulMinPinLen: 6 ulTotalPublicMemory: CK_UNAVAILABLE_INFORMATION ulFreePublicMemory: CK_UNAVAILABLE_INFORMATION ulTotalPrivateMemory: CK_UNAVAILABLE_INFORMATION ulFreePrivateMemory: CK_UNAVAILABLE_INFORMATION hardwareVersion: 0.00 firmwareVersion: 0.00 utcTime: Mechanism CKM_SHA_1: ulMinKeySize: 0 ulMaxKeySize: 0 flags: 1024 = CKF_DIGEST Mechanism CKM_SHA256: ulMinKeySize: 0 ulMaxKeySize: 0 flags: 1024 = CKF_DIGEST Mechanism CKM_SHA384: ulMinKeySize: 0 ulMaxKeySize: 0 flags: 1024 = CKF_DIGEST Mechanism CKM_SHA512: ulMinKeySize: 0 ulMaxKeySize: 0 flags: 1024 = CKF_DIGEST Mechanism CKM_MD5: ulMinKeySize: 0 ulMaxKeySize: 0 flags: 1024 = CKF_DIGEST Mechanism CKM_RIPEMD160: ulMinKeySize: 0 ulMaxKeySize: 0 flags: 1024 = CKF_DIGEST Mechanism Unknown 0x0000000000001210: ulMinKeySize: 0 ulMaxKeySize: 0 flags: 1024 = CKF_DIGEST Mechanism CKM_RSA_X_509: ulMinKeySize: 2048 ulMaxKeySize: 3072 flags: 10753 = CKF_HW | CKF_DECRYPT | CKF_SIGN | CKF_VERIFY Mechanism CKM_RSA_PKCS: ulMinKeySize: 2048 ulMaxKeySize: 3072 flags: 10753 = CKF_HW | CKF_DECRYPT | CKF_SIGN | CKF_VERIFY Mechanism CKM_SHA1_RSA_PKCS: ulMinKeySize: 2048 ulMaxKeySize: 3072 flags: 10240 = CKF_SIGN | CKF_VERIFY Mechanism CKM_SHA256_RSA_PKCS: ulMinKeySize: 2048 ulMaxKeySize: 3072 flags: 10240 = CKF_SIGN | CKF_VERIFY Mechanism CKM_MD5_RSA_PKCS: ulMinKeySize: 2048 ulMaxKeySize: 3072 flags: 10240 = CKF_SIGN | CKF_VERIFY Mechanism CKM_RIPEMD160_RSA_PKCS: ulMinKeySize: 2048 ulMaxKeySize: 3072 flags: 10240 = CKF_SIGN | CKF_VERIFY Mechanism CKM_RSA_PKCS_KEY_PAIR_GEN: ulMinKeySize: 2048 ulMaxKeySize: 3072 flags: 65536 = CKF_GENERATE_KEY_PAIR Enter Passphrase for keystore: sunpkcs11: login operation not required for token - ignoring login request jarsigner: Certificate chain not found for: Cardholder certificate. Cardholder certificate must reference a valid KeyStore key entry containing a private key and corresponding public key certificate chain. -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From expires2013 at ymail.com Tue Jan 7 23:42:59 2014 From: expires2013 at ymail.com (MFPA) Date: Tue, 7 Jan 2014 22:42:59 +0000 Subject: isolating the signature from encrypted data (was: sign encrypted emails) In-Reply-To: <7677715.1slNLpWZ3j@inno.berlin.laging.de> References: <1681026.Oqz1BqeVtE@inno.berlin.laging.de> <2002014.1CKrbWpAov@inno.berlin.laging.de> <242100547.20140106014739@my_localhost> <7677715.1slNLpWZ3j@inno.berlin.laging.de> Message-ID: <94659202.20140107224259@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 6 January 2014 at 2:24:10 AM, in , Hauke Laging wrote: > That is correct. I am not aware of a possibility to get > the data and the signature from GnuPG. But that doesn't > mean it's not possible. I think the thread you linked to [1] says it is possible using GnuPG's --show-session-key and --override-session-key options. And at the end of the thread, Werner says PGP/MIME signs and encrypts using separate MIME containers, which makes it easy to strip off the encryption layer. [1] http://lists.gnupg.org/pipermail/gnupg-users/2004-April/022352.html > Use both ways (one step, two steps) to sign and encrypt > a file and have a look at the result with gpg > --list-packets. I did. Gpg --list-packets output starts the same. But to get all of the info on the two-step signed then encrypted, I have to run gpg - --list-packets again on the signed but not encrypted file to get the info about the signature. I also tried pgpdump, which gives the same information for the one step and the two step files. It appears to be a different (and smaller) set of information than gpg --list-packets generates. - -- Best regards MFPA mailto:expires2013 at ymail.com Live your life as though every day it was your last. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLMgwBXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pdTEEAIb9+tybdukWQQ5H68PnHeZulGIfsceOqSiH qssiSBuEKlthqEA+MsiksuweZ3E+uo0n7N4IGtQGV8YMJsv7JhmuvquxF8kg8fhz DwaaTZ/HrPT0Owf/0VszEM6+jgC5A+GseW3agdRXHmZjoQNVyixoT9s+0rhlYOUs GVhZMMd/ =s8a/ -----END PGP SIGNATURE----- From alan.meekins at gmail.com Wed Jan 8 00:30:23 2014 From: alan.meekins at gmail.com (Alan Meekins) Date: Tue, 7 Jan 2014 15:30:23 -0800 Subject: GPG Assuan protocol usage Message-ID: Hi gpg-ers, I'm interested in utilizing GnuPG in software that I'm writing and it seems that communicating with the gpg-agent over a unix socket using the Assuan protocol is best suited for my use case but am open to other options if there are better approaches. My problem lies in getting the assuan protocol in practice to match up with the documentation here . When attempting to use the GENKEY command as described here as new user I always get an invalid data error when using the example client requests: socat /tmp/gpg-xxxxx/S.gpg-agent - > OK Pleased to meet you, process 280 > GENKEY > INQUIRE KEYPARAM > D (genkey (rsa (nbits 4096))) > END > ERR 67108943 Invalid data > GENKEY > INQUIRE KEYPARAM > D (genkey (rsa (nbits 2048))) > END > ERR 67108943 Invalid data > GENKEY > INQUIRE KEYPARAM > D (genkey (rsa (nbits 1024))) > END > ERR 67108943 Invalid data Starting gpg-agent with --debug 10 I get the following debug output: [user at host]:~$ gpg-agent --daemon --no-detach --debug 10 gpg-agent[]: directory `/home/user/.gnupg' created gpg-agent[]: directory `/home/user/.gnupg/private-keys-v1.d' created gpg-agent[]: failed to convert keyparam: Invalid length specifier in S-expression gpg-agent[]: command genkey failed: Invalid data gpg-agent[]: failed to convert keyparam: Invalid length specifier in S-expression gpg-agent[]: command genkey failed: Invalid data gpg-agent[]: failed to convert keyparam: Invalid length specifier in S-expression gpg-agent[]: command genkey failed: Invalid data This seems to suggest that there exist more parameters to the GENKEY command than are documented. What am I missing here? Taking a step back is this a good solution for 3rd party software to use GPG or are there libraries I should be using instead to accomplish the communication? Diving into the code to see if I can't figure it out but maybe you can help. Thanks, -Alan Meekins -------------- next part -------------- An HTML attachment was scrubbed... URL: From spldemouser at gmail.com Wed Jan 8 09:06:54 2014 From: spldemouser at gmail.com (Calvin Tan) Date: Wed, 8 Jan 2014 16:06:54 +0800 Subject: GnuPG 2.0.22 installation on Suse Enterprise 11.3 Message-ID: Hi all, I was attempting to upgrade the GnuPG 2.0.9 on the Suse Linux to version 2.0.22 but was hit by some missing dependency. May I know what are the necessary package that I need to install before installing GnuPG 2.0.22? I have installed libassuan-2.1.1-1 which I believe is part of the missing dependency. Thank you for any advise that will point me to solve the problem. Regards, Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jan 8 13:02:50 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Jan 2014 13:02:50 +0100 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <52CC100D.9080303@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 07 Jan 2014 09:32:45 -0500") References: <52CC100D.9080303@guardianproject.info> Message-ID: <87txdebs0l.fsf@vigenere.g10code.de> On Tue, 7 Jan 2014 15:32, hans at guardianproject.info said: > OpenPGP card as a PKCS11 keystore. It seems that things are close: Java can > use NSS as a provider of PKCS11. I guess the question is whether opensc is > making a PKCS#11 interface to the OpenPGP card, that's the bit that I don't Scute also provides an pkcs#11 interface to NSS. Thus you should be able to use it also with Java. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 8 13:09:54 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Jan 2014 13:09:54 +0100 Subject: GPG Assuan protocol usage In-Reply-To: (Alan Meekins's message of "Tue, 7 Jan 2014 15:30:23 -0800") References: Message-ID: <87ppo2brot.fsf@vigenere.g10code.de> On Wed, 8 Jan 2014 00:30, alan.meekins at gmail.com said: >> D (genkey (rsa (nbits 4096))) Use D (genkey (rsa (nbits 4:4096))) to match the S-expression syntax. A leading digit denotes a length and thus you can't enter a number without its length. Yes, this is a common pitfall. Instead of socat, I suggest the use of gpg-connect-agent (which even feature a simple script language). If gpg-agent is installed on a system gpg-connect-agent is also available. As an alternative you may also use the Assuan interface of GPGME (see gpa/src/cardman.c for examples). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 8 13:10:59 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Jan 2014 13:10:59 +0100 Subject: GnuPG 2.0.22 installation on Suse Enterprise 11.3 In-Reply-To: (Calvin Tan's message of "Wed, 8 Jan 2014 16:06:54 +0800") References: Message-ID: <87lhyqbrn0.fsf@vigenere.g10code.de> On Wed, 8 Jan 2014 09:06, spldemouser at gmail.com said: > I was attempting to upgrade the GnuPG 2.0.9 on the Suse Linux to version > 2.0.22 but was hit by some missing dependency. May I know what are the > necessary package that I need to install before installing GnuPG 2.0.22? Running ./configure shows you all missing dependencies. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Jan 8 16:26:12 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 08 Jan 2014 10:26:12 -0500 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <87txdebs0l.fsf@vigenere.g10code.de> References: <52CC100D.9080303@guardianproject.info> <87txdebs0l.fsf@vigenere.g10code.de> Message-ID: <52CD6E14.5010803@guardianproject.info> On 01/08/2014 07:02 AM, Werner Koch wrote: > On Tue, 7 Jan 2014 15:32, hans at guardianproject.info said: > >> OpenPGP card as a PKCS11 keystore. It seems that things are close: Java can >> use NSS as a provider of PKCS11. I guess the question is whether opensc is >> making a PKCS#11 interface to the OpenPGP card, that's the bit that I don't > > Scute also provides an pkcs#11 interface to NSS. Thus you should be > able to use it also with Java. I haven't tried scute, but it seems that opensc v0.13 provides a PKCS#11 interface to the OpenPGP card. I am able to get keytool to report the certificate in key position #3, but the question I have now is that given that key #3 is for authentication, is there some restriction in the OpenPGP card that would prevent the certificate/key combo in position #3 from being used for signing? I did read about using opensc with an OpenPGP card to provide S/MIME services. What I read there is that in order to use the certificate/key combo in position #3 for decrypting emails, the key in position #2 (decryption) must match the key in position number #3. Is there a similar restriction for signing? I forget if I mentioned this, but the grand goal is to have a single hardware security module that can sign the Android APK using jarsigner, then make a OpenPGP signature on the APK, then optionally provide authentication for scp'ing the resulting files to the release server. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From alan.meekins at gmail.com Thu Jan 9 02:51:23 2014 From: alan.meekins at gmail.com (Alan Meekins) Date: Wed, 8 Jan 2014 17:51:23 -0800 Subject: GPG Assuan protocol usage In-Reply-To: <87ppo2brot.fsf@vigenere.g10code.de> References: <87ppo2brot.fsf@vigenere.g10code.de> Message-ID: Ah thanks, that was the problem. Would be helpful if this pagewere updated to reflect the correct syntax for future users. Was just using socat for testing purposes. My system requires the lowest latency and fewest memcpy's possible so if I continue with the socket interface I will use it directly. Since posting I've come across the Qt Cryptographic Architecture (qca) which looks to be a better approach for me as I'm already developing in Qt. Thanks again, -Alan On Wed, Jan 8, 2014 at 4:09 AM, Werner Koch wrote: > On Wed, 8 Jan 2014 00:30, alan.meekins at gmail.com said: > > >> D (genkey (rsa (nbits 4096))) > > Use > > D (genkey (rsa (nbits 4:4096))) > > to match the S-expression syntax. A leading digit denotes a length and > thus you can't enter a number without its length. Yes, this is a common > pitfall. > > Instead of socat, I suggest the use of gpg-connect-agent (which even > feature a simple script language). If gpg-agent is installed on a > system gpg-connect-agent is also available. As an alternative you may > also use the Assuan interface of GPGME (see gpa/src/cardman.c for > examples). > > > Salam-Shalom, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Jan 9 14:02:05 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jan 2014 14:02:05 +0100 Subject: GPG Assuan protocol usage In-Reply-To: (Alan Meekins's message of "Wed, 8 Jan 2014 17:51:23 -0800") References: <87ppo2brot.fsf@vigenere.g10code.de> Message-ID: <87y52p9ulu.fsf@vigenere.g10code.de> On Thu, 9 Jan 2014 02:51, alan.meekins at gmail.com said: > Ah thanks, that was the problem. Would be helpful if this > pagewere > updated to reflect the correct syntax for future users. I will add a cautionary note about correct S-expression syntax. > Was just using socat for testing purposes. My system requires the lowest > latency and fewest memcpy's possible so if I continue with the socket > interface I will use it directly. Since posting I've come across the Qt > Cryptographic Architecture (qca) which looks to be a better approach for me > as I'm already developing in Qt. You may want to view Ilja van Sprundel's lecture "X security" http://events.ccc.de/congress/2013/Fahrplan/events/5499.html Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mmfische at web.de Thu Jan 9 14:14:19 2014 From: mmfische at web.de (Matthias Fischer) Date: Thu, 9 Jan 2014 14:14:19 +0100 (CET) Subject: export-minimal and expired subkeys Message-ID: Hi, just a short question: Does the ?export-minimal? option also remove unusable (expired) subkeys, or not? The manpage only mentions user IDs and signatures. If not, is there a simple way to minimize the export further by dropping those subkeys? Regards, MM From peter at digitalbrains.com Thu Jan 9 14:47:41 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 09 Jan 2014 14:47:41 +0100 Subject: export-minimal and expired subkeys In-Reply-To: References: Message-ID: <52CEA87D.5060803@digitalbrains.com> On 09/01/14 14:14, Matthias Fischer wrote: > just a short question: Does the ?export-minimal? option also remove unusable (expired) subkeys, or not? A quick test indicates: no, it does not remove expired subkeys, using GnuPG 2.0.22. > If not, is there a simple way to minimize the export further by dropping those subkeys? I don't know. 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 Thu Jan 9 16:11:25 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 09 Jan 2014 16:11:25 +0100 Subject: export-minimal and expired subkeys In-Reply-To: (Matthias Fischer's message of "Thu, 9 Jan 2014 14:14:19 +0100 (CET)") References: Message-ID: <87ppo19oma.fsf@vigenere.g10code.de> On Thu, 9 Jan 2014 14:14, mmfische at web.de said: > just a short question: Does the ?export-minimal? option also remove unusable (expired) subkeys, or not? Expired subkeys are not removed. In fact expired signature subkeys are useful to verify old signatures (e.g. gnupg tarballs); gpg shows a warning that the key expired but that does not mean the signature is not anymore valid. Encryption subkeys are less important but useful for backup purposes. For example with 2.1 you need the public keys even to for decryption (because the public parts of the key are not anymore duplicated in the secret key). > If not, is there a simple way to minimize the export further by dropping those subkeys? Export the key to a temporary file, edit the key and remove the subkeys you don't want, export the key, import the backup. Not quite easy, though. Adding an option to export only valid subkeys might be useful. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sam.kuper at uclmail.net Thu Jan 9 18:42:44 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Thu, 9 Jan 2014 17:42:44 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: On 07/01/2014, Sam Kuper wrote: > On 06/01/2014, Werner Koch wrote: >>>> The question is whether this is really helpful. Yes, it protects your >>>> PIN > > That is helpful. No question about this part! Perhaps I should be clearer about why I believe it is unquestionably helpful for OpenPGP-compatible smart card readers to be trustworthy and to have pinpads. **Scenario 1: There is no doubt that the local machine is secure and completely free of malware.** In this case, there is no need for a pinpad; but there is also no need for an OpenPGP smart card. To address other threats (e.g. physical theft), the user's auth/sign/enc keys should of course be passphrase-protected; and they can additionally be stored in and/or backed up to an encrypted folder, for instance on a USB stick if portability is desired. **Scenario 2: There is some doubt about the local machine, such that the procedure outlined in scenario 1 is not considered sufficiently secure.** In this case, storing the private keys on an OpenPGP card will prevent them from being stolen; but any machine about which this level of doubt exists cannot be assumed to safeguard the PIN(s) of an OpenPGP card. Therefore, the solution here is to use an OpenPGP card and a card reader with a pinpad. I believe that in respect of any local PC, these two scenarios are exhaustive. It follows that I don't see much (any) value in a card reader without a pinpad. Nevertheless, perhaps that belief is wrong. If so, then I'm happy to stand corrected. In the meantime, I hope I can find a small form-factor OpenPGP-compatible smart card reader with a pin pad. I would be grateful for pointers :) Regards, Sam From david at systemoverlord.com Thu Jan 9 20:16:49 2014 From: david at systemoverlord.com (David Tomaschik) Date: Thu, 9 Jan 2014 11:16:49 -0800 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: Ignoring the fact that if the machine you are using for crypto operations is compromised, you have lost (at least for the operations conducted while it is compromised), a smartcard without a PIN pad may compromise your pin (and allow arbitrary operations while the smartcard is protected) but still protects the key material itself. Unless the malware has a history of all your previous email, an attacker still doesn't have the key to compromise your past email. The smartcard (without a PIN pad) also allows for use of a lower-entropy passphrase/PIN than Scenario 1 in the case of theft. Theft of a key stored on disk is vulnerable to offline attack, theft of a key on a smartcard is much harder to use (as the smartcard locks itself after some number of wrong pins). (This ignores three-letter-agency attacks against the smartcard hardware to extract the key material from the EEPROM of the smart card itself, bypassing the card applet.) On Thu, Jan 9, 2014 at 9:42 AM, Sam Kuper wrote: > On 07/01/2014, Sam Kuper wrote: > > On 06/01/2014, Werner Koch wrote: > >>>> The question is whether this is really helpful. Yes, it protects your > >>>> PIN > > > > That is helpful. No question about this part! > > Perhaps I should be clearer about why I believe it is unquestionably > helpful for OpenPGP-compatible smart card readers to be trustworthy > and to have pinpads. > > **Scenario 1: There is no doubt that the local machine is secure and > completely free of malware.** In this case, there is no need for a > pinpad; but there is also no need for an OpenPGP smart card. To > address other threats (e.g. physical theft), the user's auth/sign/enc > keys should of course be passphrase-protected; and they can > additionally be stored in and/or backed up to an encrypted folder, for > instance on a USB stick if portability is desired. > > **Scenario 2: There is some doubt about the local machine, such that > the procedure outlined in scenario 1 is not considered sufficiently > secure.** In this case, storing the private keys on an OpenPGP card > will prevent them from being stolen; but any machine about which this > level of doubt exists cannot be assumed to safeguard the PIN(s) of an > OpenPGP card. Therefore, the solution here is to use an OpenPGP card > and a card reader with a pinpad. > > I believe that in respect of any local PC, these two scenarios are > exhaustive. It follows that I don't see much (any) value in a card > reader without a pinpad. > > Nevertheless, perhaps that belief is wrong. If so, then I'm happy to > stand corrected. > > In the meantime, I hope I can find a small form-factor > OpenPGP-compatible smart card reader with a pin pad. I would be > grateful for pointers :) > > Regards, > > Sam > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- David Tomaschik OpenPGP: 0x5DEA789B http://systemoverlord.com david at systemoverlord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jernst at invacare.com Thu Jan 9 21:51:04 2014 From: jernst at invacare.com (Jim Ernst) Date: Thu, 9 Jan 2014 20:51:04 +0000 Subject: Question Regarding Passphrases When Signing Message-ID: <649436324320465d95bce648885b4362@CO2PR07MB475.namprd07.prod.outlook.com> Hello - I am trying to sign and encrypt a file using a UNIX script. No matter what I do, the passphrase that is requested appears to be for the first key that is listed via -list-keys. I have tried specifying a recipient but that does not seem to make any difference; it still asks for the same key's passphrase. Is it possible to specify which key that the passphrase is requested for when signing/encrypting ? Thanks, Jim Ernst Systems Analyst II Invacare Corporation jernst at invacare.com CONFIDENTIALITY NOTICE: The information in this e-mail message and any attachments may contain privileged, confidential or proprietary information, including confidential health information, protected by applicable Federal or state laws. Such information is intended only for the recipient named above. If you are not the intended recipient, please notify the sender immediately, and take notice that any use, disclosure or distribution of such information is prohibited by law. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jernst at invacare.com Thu Jan 9 21:20:39 2014 From: jernst at invacare.com (Jim Ernst) Date: Thu, 9 Jan 2014 20:20:39 +0000 Subject: Question Regarding Passphrases When Signing Message-ID: <4ad04d7e44b3463e98f4c1f4590eacdd@CO2PR07MB475.namprd07.prod.outlook.com> Hello - I am trying to sign and encrypt a file using a UNIX script. No matter what I do, the passphrase that is requested appears to be for the first key that is listed via -list-keys. I have tried specifying a recipient but that does not seem to make any difference; it still asks for the same key's passphrase. Is it possible to specify which key that the passphrase is requested for when signing/encrypting ? Thanks, Jim Ernst Systems Analyst II Invacare Corporation jernst at invacare.com CONFIDENTIALITY NOTICE: The information in this e-mail message and any attachments may contain privileged, confidential or proprietary information, including confidential health information, protected by applicable Federal or state laws. Such information is intended only for the recipient named above. If you are not the intended recipient, please notify the sender immediately, and take notice that any use, disclosure or distribution of such information is prohibited by law. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Fri Jan 10 09:44:16 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 10 Jan 2014 09:44:16 +0100 Subject: Question Regarding Passphrases When Signing In-Reply-To: <649436324320465d95bce648885b4362@CO2PR07MB475.namprd07.prod.outlook.com> References: <649436324320465d95bce648885b4362@CO2PR07MB475.namprd07.prod.outlook.com> Message-ID: <1964374.fI3t64Je4u@inno.berlin.laging.de> Am Do 09.01.2014, 20:51:04 schrieb Jim Ernst: > I am trying to sign and encrypt a file using a UNIX script. No matter > what I do, the passphrase that is requested appears to be for the > first key that is listed via -list-keys. > I have tried specifying a recipient You must define the signing key: gpg --local-user 0x12345678 --detach-sign file or shorter gpg -u 0x12345678 --detach-sign file 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 telegraph at gmx.net Fri Jan 10 09:38:28 2014 From: telegraph at gmx.net (Gregor Zattler) Date: Fri, 10 Jan 2014 09:38:28 +0100 Subject: Question Regarding Passphrases When Signing In-Reply-To: <4ad04d7e44b3463e98f4c1f4590eacdd@CO2PR07MB475.namprd07.prod.outlook.com> References: <4ad04d7e44b3463e98f4c1f4590eacdd@CO2PR07MB475.namprd07.prod.outlook.com> Message-ID: <20140110083828.GA16076@boo.workgroup> Hi Jim, * Jim Ernst [09. Jan. 2014]: > I am trying to sign and encrypt a file using a UNIX script. No > matter what I do, the passphrase that is requested appears to > be for the first key that is listed via -list-keys. I have > tried specifying a recipient but that does not seem to make any > difference; it still asks for the same key's passphrase. > > Is it possible to specify which key that the passphrase is > requested for when signing/encrypting ? The passphrase is not for enrcyption but for signing. Therefore gpg asks for the passphrase of your key. To enforce the use of one among several signung keys under your control use the `-u' option. From the man page: --local-user name -u Use name as the key to sign with. Note that this option overrides --default-key. HTH, Gregor From jernst at invacare.com Fri Jan 10 22:01:33 2014 From: jernst at invacare.com (Jim Ernst) Date: Fri, 10 Jan 2014 21:01:33 +0000 Subject: Question Regarding Passphrases When Signing In-Reply-To: <1964374.fI3t64Je4u@inno.berlin.laging.de> References: <649436324320465d95bce648885b4362@CO2PR07MB475.namprd07.prod.outlook.com> <1964374.fI3t64Je4u@inno.berlin.laging.de> Message-ID: <00038e8388cf468ab8bfbc6f0054d5cb@BY2PR07MB471.namprd07.prod.outlook.com> Hi Hauke - thanks for the info - it is now working. Jim E. -----Original Message----- From: Hauke Laging [mailto:mailinglisten at hauke-laging.de] Sent: Friday, January 10, 2014 3:44 AM To: gnupg-users at gnupg.org Cc: Jim Ernst Subject: Re: Question Regarding Passphrases When Signing Am Do 09.01.2014, 20:51:04 schrieb Jim Ernst: > I am trying to sign and encrypt a file using a UNIX script. No matter > what I do, the passphrase that is requested appears to be for the > first key that is listed via -list-keys. > I have tried specifying a recipient You must define the signing key: gpg --local-user 0x12345678 --detach-sign file or shorter gpg -u 0x12345678 --detach-sign file 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 CONFIDENTIALITY NOTICE: The information in this e-mail message and any attachments may contain privileged, confidential or proprietary information, including confidential health information, protected by applicable Federal or state laws. Such information is intended only for the recipient named above. If you are not the intended recipient, please notify the sender immediately, and take notice that any use, disclosure or distribution of such information is prohibited by law. From sam.kuper at uclmail.net Sat Jan 11 14:40:16 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Sat, 11 Jan 2014 13:40:16 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: <52CC6527.90305@digitalbrains.com> References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> <87iotvdaew.fsf@vigenere.g10code.de> <52CC6527.90305@digitalbrains.com> Message-ID: On 07/01/2014, Peter Lebbing wrote: > On 07/01/14 17:27, Werner Koch wrote: >> See the card HOWTO or try gpg --card-edit, admin, help. > > Additionally, in the OpenPGP Card 2.0.1 spec, the DO with tag C4 on page > 17, > section 7.2.2 (VERIFY) and section 7.2.8 (PSO: COMPUTE DIGITAL SIGNATURE) > all > specify this one-VERIFY-per-SIG behaviour. Thank you both :) All best, Sam From fabio.coatti at gmail.com Sat Jan 11 14:30:20 2014 From: fabio.coatti at gmail.com (Fabio Coatti) Date: Sat, 11 Jan 2014 14:30:20 +0100 Subject: dirmngr segfaults Message-ID: Hi all, I'm seeing several segfaults from dirmngr, tried googling around but with no success this time :) [sab gen 11 13:22:51 2014] dirmngr[11220]: segfault at 580 ip 00007fdbfe5abbe1 sp 00007fff12335980 error 4 in libpth.so.20.0.27[7fdbfe5a2000+13000] backtrace: cova at calvin ~ $ gdb /usr/bin/dirmngr core.4414 GNU gdb (Gentoo 7.6.2 p1) 7.6.2 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. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/bin/dirmngr...done. [New LWP 4414] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? Core was generated by `dirmngr --gpgconf-test'. Program terminated with signal 11, Segmentation fault. #0 0x00007fb080c64be1 in pth_key_setdata (key=0, value=value at entry=0x0) at pth_data.c:67 67 pth_data.c: File o directory non esistente. (gdb) bt #0 0x00007fb080c64be1 in pth_key_setdata (key=0, value=value at entry=0x0) at pth_data.c:67 #1 0x000000000040715d in main (argc=2, argv=0x7fff0baa1268) at dirmngr.c:723 dirmngr: 1.1.1 dev-libs/pth: 2.0.7-r3 distro: gentoo any help will be deeply appreciated; of course I can provide more data if needed. -- Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.kuper at uclmail.net Sat Jan 11 22:05:48 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Sat, 11 Jan 2014 21:05:48 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: On Jan 9, 2014 7:16 PM, "David Tomaschik" wrote: > > if the machine you are using for crypto operations is compromised, you have lost (at least for the operations conducted while it is compromised) Perhaps I'm wrong, but I don't entirely accept this. Surely if you are signing with a key stored in an OpenPGP card being used via a pinpad-protected reader, then - because the malware will not learn the PIN - although the malware could potentially corrupt the message being signed (or prevent it from being sent, etc), it could not do so in such a way that a conscientious recipient already in possession of the corresponding public key would mistake a tampered message for a genuine signed message. I would *guess* that there are additional operations that could be performed, without disclosing secrets (e.g. PIN; raw private key), on a compromised machine using a pinpad-protected reader. For instance, generating new keys. (Although the existence and correctness of any such generated keys would then have to be checked on a trusted machine before being used in earnest, so there would not be much point in using an untrusted machine for this task.) > a smartcard without a PIN pad may compromise your pin (and allow arbitrary operations while the smartcard is protected) but still protects the key material itself. Small comfort if the malware, knowing the PIN, can *use* that key material every time the card is connected! > Unless the malware has a history of all your previous email, an attacker still doesn't have the key to compromise your past email. I believe an attacker who knows the PIN and is able to execute commands on the machine to which the card is connected (via pinpad-less reader) has similar capability to an attacker who has the private key file and its passphrase. His/her ability to decrypt any messages in his/her possession is limited only by the bandwidth of his/her connection to the relevant machine, the resources available on that machine, and the alertness of that machine's legitimate operator(s). Similarly re: signing and authentication. > The smartcard (without a PIN pad) also allows for use of a lower-entropy passphrase/PIN than Scenario 1 in the case of theft [...] (as the smartcard locks itself after some number of wrong pins). True. (Equally true, incidentally, of a smart card being used *with* a pinpad-enabled reader.) Even so, this is a pretty small advantage, given that it would take me only a second or two longer to type a passphrase a couple of dozen characters long than it would for me to type a PW1 half a dozen characters long. And given that a USB flash drive is much more versatile than an OpenPGP card, and can be as compact as a SIM card-sized OpenPGP card (i.e. *without the reader*) and less expensive in total, it's arguable that the overall advantages of such a flash drive outweigh the convenience of a low-entropy PW1. > Theft of a key stored on disk is vulnerable to offline attack, theft of a key on a smartcard is much harder to use (as the smartcard locks itself after some number of wrong pins). (This ignores three-letter-agency attacks against the smartcard hardware to extract the key material from the EEPROM of the smart card itself, bypassing the card applet.) Allow me to "unignore" them :-) I assume that any agency likely to have a chance of extracting a raw key from a sensibly passphrase protected GPG key file, is likely to have a chance of successfully extracting a raw key from a smart card's EEPROM; and vice versa. I'd hazard a guess that the EEPROM attack is more feasible, but since I can only speculate blindly on the matter, I prefer not to assume that either technology has an advantage over the other in this particular respect. Best regards, Sam From david at systemoverlord.com Sat Jan 11 23:33:45 2014 From: david at systemoverlord.com (David Tomaschik) Date: Sat, 11 Jan 2014 14:33:45 -0800 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: On Sat, Jan 11, 2014 at 1:05 PM, Sam Kuper wrote: > On Jan 9, 2014 7:16 PM, "David Tomaschik" > wrote: > > > > if the machine you are using for crypto operations is compromised, you > have lost (at least for the operations conducted while it is compromised) > > Perhaps I'm wrong, but I don't entirely accept this. Surely if you are > signing with a key stored in an OpenPGP card being used via a > pinpad-protected reader, then - because the malware will not learn the > PIN - although the malware could potentially corrupt the message being > signed (or prevent it from being sent, etc), it could not do so in > such a way that a conscientious recipient already in possession of the > corresponding public key would mistake a tampered message for a > genuine signed message. > Or replace the message with a message of its choosing? It just needs to wait for you to want to do a legitimate signature, swap out the plaintext, and then it has signed data. > > I would *guess* that there are additional operations that could be > performed, without disclosing secrets (e.g. PIN; raw private key), on > a compromised machine using a pinpad-protected reader. For instance, > generating new keys. (Although the existence and correctness of any > such generated keys would then have to be checked on a trusted machine > before being used in earnest, so there would not be much point in > using an untrusted machine for this task.) > > > a smartcard without a PIN pad may compromise your pin (and allow > arbitrary operations while the smartcard is protected) but still protects > the key material itself. > > Small comfort if the malware, knowing the PIN, can *use* that key > material every time the card is connected! > Don't use sensitive keys on machines with malware? (Yes, I realize proving a machine is malware free is essentially impossible.) > > > Unless the malware has a history of all your previous email, an attacker > still doesn't have the key to compromise your past email. > > I believe an attacker who knows the PIN and is able to execute > commands on the machine to which the card is connected (via > pinpad-less reader) has similar capability to an attacker who has the > private key file and its passphrase. His/her ability to decrypt any > messages in his/her possession is limited only by the bandwidth of > his/her connection to the relevant machine, the resources available on > that machine, and the alertness of that machine's legitimate > operator(s). Similarly re: signing and authentication. > > > The smartcard (without a PIN pad) also allows for use of a lower-entropy > passphrase/PIN than Scenario 1 in the case of theft [...] (as the smartcard > locks itself after some number of wrong pins). > > True. (Equally true, incidentally, of a smart card being used *with* a > pinpad-enabled reader.) > > Agreed, I was just arguing why a smartcard without a PIN pad still offers some level of additional security. > Even so, this is a pretty small advantage, given that it would take me > only a second or two longer to type a passphrase a couple of dozen > characters long than it would for me to type a PW1 half a dozen > characters long. > > And given that a USB flash drive is much more versatile than an > OpenPGP card, and can be as compact as a SIM card-sized OpenPGP card > (i.e. *without the reader*) and less expensive in total, it's arguable > that the overall advantages of such a flash drive outweigh the > convenience of a low-entropy PW1. > > > Theft of a key stored on disk is vulnerable to offline attack, theft of > a key on a smartcard is much harder to use (as the smartcard locks itself > after some number of wrong pins). (This ignores three-letter-agency > attacks against the smartcard hardware to extract the key material from the > EEPROM of the smart card itself, bypassing the card applet.) > > Allow me to "unignore" them :-) I assume that any agency likely to > have a chance of extracting a raw key from a sensibly passphrase > protected GPG key file, is likely to have a chance of successfully > extracting a raw key from a smart card's EEPROM; and vice versa. I'd > hazard a guess that the EEPROM attack is more feasible, but since I > can only speculate blindly on the matter, I prefer not to assume that > either technology has an advantage over the other in this particular > respect. > You assume people choose good passphrases. While that may be true for readers of this list, that is not true of the general population. > > Best regards, > > Sam > -- David Tomaschik OpenPGP: 0x5DEA789B http://systemoverlord.com david at systemoverlord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.kuper at uclmail.net Sun Jan 12 00:18:55 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Sat, 11 Jan 2014 23:18:55 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: On 11/01/2014, David Tomaschik wrote: > On Sat, Jan 11, 2014 at 1:05 PM, Sam Kuper wrote: >> On Jan 9, 2014 7:16 PM, "David Tomaschik" >> wrote: >> > if the machine you are using for crypto operations is compromised, you >> have lost (at least for the operations conducted while it is compromised) >> >> Surely if you are >> signing with a key stored in an OpenPGP card being used via a >> pinpad-protected reader, then - because the malware will not learn the >> PIN - although the malware could potentially corrupt the message being >> signed (or prevent it from being sent, etc), it could not do so in >> such a way that a conscientious recipient already in possession of the >> corresponding public key would mistake a tampered message for a >> genuine signed message. > > Or replace the message with a message of its choosing? It just needs to > wait for you to want to do a legitimate signature, swap out the plaintext, > and then it has signed data. Yes, as I said, it could tamper with the message. But if it does that, then when a recipient attempts to verify the signature, gpg --verify will give the message, "gpg: BAD signature". So, as I also said, a conscientious recipient will not mistake it for a genuine signed message. > Don't use sensitive keys on machines with malware? Well, ideally, yes... > (Yes, I realize proving > a machine is malware free is essentially impossible.) ... but in an acknowledgedly imperfect world, using an OpenPGP smart card with a trustworthy reader with a pinpad is the next best thing. > Agreed, I was just arguing why a smartcard without a PIN pad still offers > some level of additional security [compared to a passphrase protected key in an ordinary or encrypted folder]. For the reasons I've given - and assuming that passphrases/PINs of adequate entropy/unpredictability are chosen in each case - I don't think it does. Perhaps we'll just have to agree to disagree. > You assume people choose good passphrases. While that may be true for > readers of this list, that is not true of the general population. You are right that my scope in this discussion has been the security-conscious. I suppose that the individuals in the set of "people who are not security-conscious enough to use adequate passphrases" might benefit from using an OpenGPG card and a reader without a pinpad, over using a key stored in an ordinary or encrypted folder. Unfortunately, I also suspect that the set of "people who know enough about OpenGPG cards to bother using one" has no intersection with the set of "people who are not security-conscious enough to use adequate passphrases". Again, perhaps I am wrong. But if I am not, then the use of OpenPGP cards with non-pinpad readers still makes no sense (at least, not to me). Kind regards, Sam From 2014-667rhzu3dc-lists-groups at riseup.net Sun Jan 12 04:42:27 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Sun, 12 Jan 2014 03:42:27 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: <312087937.20140112034227@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 11 January 2014 at 11:18:55 PM, in , Sam Kuper wrote: > Yes, as I said, it could tamper with the message. But > if it does that, then when a recipient attempts to > verify the signature, gpg --verify will give the > message, "gpg: BAD signature". Not if the malware tampered with the message *before* the signature was applied. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Those who do not read are no better off than those who cannot. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLSDylXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p+aUD/AmHNQ0q2ND2SQPzwnLr5iJTRdn/DLDzfl81 kMXA3snvbbWdLKWF4Cgp9yCdHmklcdA2hp5Bm639eMtywIAOHSCufXt5hbi1ueCu zHBbx0INVQmoszpiAIp1ljh5Pb8KklTaAMDNbWLF53sN00k8pA1PgLsupFzePf1a qYokFedS =T3Y2 -----END PGP SIGNATURE----- From sam.kuper at uclmail.net Sun Jan 12 10:37:20 2014 From: sam.kuper at uclmail.net (Sam Kuper) Date: Sun, 12 Jan 2014 09:37:20 +0000 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: <312087937.20140112034227@my_localhost> References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> <312087937.20140112034227@my_localhost> Message-ID: On Jan 12, 2014 3:52 AM, "MFPA" <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > Sam Kuper wrote: > > Yes, as I said, it could tamper with the message. But > > if it does that, then when a recipient attempts to > > verify the signature, gpg --verify will give the > > message, "gpg: BAD signature". > > Not if the malware tampered with the message *before* the signature > was applied. Good point :) Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Jan 13 10:11:44 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 13 Jan 2014 10:11:44 +0100 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <52CD6E14.5010803@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 08 Jan 2014 10:26:12 -0500") References: <52CC100D.9080303@guardianproject.info> <87txdebs0l.fsf@vigenere.g10code.de> <52CD6E14.5010803@guardianproject.info> Message-ID: <8761po9rfz.fsf@vigenere.g10code.de> On Wed, 8 Jan 2014 16:26, hans at guardianproject.info said: > key #3 is for authentication, is there some restriction in the OpenPGP card > that would prevent the certificate/key combo in position #3 from being used > for signing? No. At least not enforced by the card or GnuPG. > What I read there is that in order to use the certificate/key combo in > position #3 for decrypting emails, the key in position #2 (decryption) must > match the key in position number #3. Is there a similar restriction > for signing? I can't tell because I have not looked at OpenSC for many years. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Mon Jan 13 10:38:04 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 13 Jan 2014 10:38:04 +0100 Subject: USB key form-factor smart-card readers with pinpads? In-Reply-To: References: <87mwjak401.fsf@vigenere.g10code.de> <874n5hihdd.fsf@vigenere.g10code.de> Message-ID: <52D3B3FC.2090306@digitalbrains.com> On 12/01/14 00:18, Sam Kuper wrote: > Again, perhaps I am wrong. But if I am not, then the use of OpenPGP > cards with non-pinpad readers still makes no sense (at least, not to > me). Since most readers don't filter VERIFY commands and additionally you can't force the OpenPGP smartcard to require a VERIFY before each decryption anyway, the pinpad really doesn't add much at all for decryption. With regard to the PIN not being known to the attacker when using a pinpad: Werner disagrees that a pinpad can reliably accomplish that. I did a feature request about a year ago, you should read this thread: [1]. And especially Werners answer in [2]. So according to him, it doesn't add much for signatures either. A bugged reader firmware (certainly a possibility) would even still work in the face of a reader filtering VERIFY commands. I think most readers have upgradeable firmware. If an attacker has your PC and knows a vulnerability in the firmware upgrade method, they can just flash their own firmware in your smartcard reader. This is a really difficult to solve scenario. I do think it requires a rather capable attacker. So at least in its current state, a pinpad doesn't add that much. Over to the actual advantages of a smartcard. I disagree that an 8-digit PIN isn't a usability advantage over a good passphrase; it's much easier to enter. But the one big advantage of smartcards: you know that (ignoring very capable attackers) there is only one copy of the key in existence, and that's inside your smartcard[3]. It in principle can't be copied. While the card is connected, an attacker may do as they wish, but once you regain control of your systems, your key is safe again. Doing crypto on a compromised machine is in so many ways a lost cause that this is the best it is going to get in reality: containment of the problem to the compromised machine(s). > I would *guess* that there are additional operations that could be > performed, without disclosing secrets (e.g. PIN; raw private key), on > a compromised machine using a pinpad-protected reader. For instance, > generating new keys. This requires the admin PIN. It's also more of a denial of service than anything else. A denial of service is trivial by doing 3 false Admin PIN attempts, locking the card. By the way, all in all, I'm not convinced a pinpad reader with the ability to force a VERIFY for each decryption wouldn't add a substantial amount of security to the overall system, albeit not perfect. But this feature has been requested and denied. So that's where I agree with you. I disagree that a smartcard without a pinpad isn't useful. HTH, Peter. [1] http://lists.gnupg.org/pipermail/gnupg-users/2013-February/046051.html [2] http://lists.gnupg.org/pipermail/gnupg-users/2013-February/046060.html [3] Okay, for primary and decryption keys maybe some more backups inside a safe, but hey, that's safe ;). -- 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 raffaelr at gmx.de Mon Jan 13 21:07:17 2014 From: raffaelr at gmx.de (raffaelr at gmx.de) Date: Mon, 13 Jan 2014 21:07:17 +0100 Subject: gpg: [don't know]: invalid packet (ctb=3d) Message-ID: <52D44775.9030807@gmx.de> Hello everyone, something wrecked my keyring, there was a pubring.gpg~ in my home folder, a few days old, that still worked. Is there a smart way to find out what caused the problem? I run GnuPG 1.4.14 (Ubuntu), with thunderbird/enigmail. In Enigmail I couldn't manage keys or encrypt messages anymore. In the terminal I got the following error (together with the keys) when I ran $ gpg --list-keys [1] > gpg: [don't know]: invalid packet (ctb=3d) > gpg: keyring_get_keyblock: read error: invalid packet > gpg: keydb_get_keyblock failed: invalid keyring I guess that there was a problem with a key I tried to fetch from a keyserver, but I am not sure about it. Cheers, Raffael [1] same with > /usr/bin/gpg --charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 --with-fingerprint --fixed-list-mode --with-colons --list-keys From chris.gilg at link-comm.com Tue Jan 14 05:29:24 2014 From: chris.gilg at link-comm.com (Chris) Date: Tue, 14 Jan 2014 04:29:24 +0000 (UTC) Subject: Cross-compiling GPGME References: <4FEBE044.9070508@sixdemonbag.org> <4FEC8F4A.6050900@oneiroi.net> <4FEC9326.1030605@sixdemonbag.org> Message-ID: Robert J. Hansen sixdemonbag.org> writes: > > > What I note immediately is EXPORTS is declared twice. Now, I'm hardly a > libtool expert, but this seems ... incorrect. Any ideas? > I was curious what you did to fix this issue? As I am also running into it, and I'm not sure where to go from here. My file looks exactly the same as yours. From khine at possquare.com.sg Tue Jan 14 09:25:03 2014 From: khine at possquare.com.sg (khine) Date: Tue, 14 Jan 2014 16:25:03 +0800 Subject: Public key Message-ID: <001b01cf1102$1fa22300$5ee66900$@com.sg> Hello, I need to generate encrypted esd file. So, I would like to get public key. Please can you give me any suggestion? Thanks & Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Tue Jan 14 14:05:26 2014 From: fa-ml at ariis.it (fa-ml) Date: Tue, 14 Jan 2014 14:05:26 +0100 Subject: Public key In-Reply-To: <001b01cf1102$1fa22300$5ee66900$@com.sg> References: <001b01cf1102$1fa22300$5ee66900$@com.sg> Message-ID: <20140114130307.GA18399@efikamx> On Tue, Jan 14, 2014 at 04:25:03PM +0800, khine wrote: > I need to generate encrypted esd file. So, I would like to get public key. > Please can you give me any suggestion? Hey khine, if you want to encrypt a file, you need the public key *of the recipient*. So you need to /generate a key/ only if you plan to encrypt a file 'to yourself' (storage, backups, etc.); if you want to encrypt a file and send it to a friend, you need his/her public key. Some time ago, I wrote a simple tutorial on how to encrypt your first message [1]; there are many other tutorials on the net. Since you are a Windows user, you may want to download Gpg4win [2]. [1] http://ariis.it/items/123pgp/page.html [2] http://gpg4win.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From Glorius.Gaduang at ge.com Tue Jan 14 21:50:23 2014 From: Glorius.Gaduang at ge.com (Gaduang, Glorius (GE Oil & Gas)) Date: Tue, 14 Jan 2014 20:50:23 +0000 Subject: error during make Message-ID: <44C448438BED2843BD7983746387B2A31105D666@CINMBCNA06.e2k.ad.ge.com> Hi Guys, I was following the instructions per readme, and I am stuck with this error. I'm getting this during the make command. rm -f libcipher.a : cru libcipher.a cipher.o pubkey.o md.o dynload.o des.o twofish.o blowfish.o cast5.o rijndael.o camellia.o camellia-glue.o idea.o elgamal.o rsa.o primegen.o random.o dsa.o smallprime.o md5.o rmd160.o sha1.o sha256.o rndlinux.o sha512.o : libcipher.a Making all in tools make: Fatal error: Don't know how to make target `../cipher/libcipher.a' Current working directory /orpogdp1/app/proj_software/gnupg-1.4.16/tools *** Error code 1 Any help would be appreciated. Thanks, Glorius -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jan 15 13:27:26 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 15 Jan 2014 13:27:26 +0100 Subject: error during make In-Reply-To: <44C448438BED2843BD7983746387B2A31105D666@CINMBCNA06.e2k.ad.ge.com> (Glorius Gaduang's message of "Tue, 14 Jan 2014 20:50:23 +0000") References: <44C448438BED2843BD7983746387B2A31105D666@CINMBCNA06.e2k.ad.ge.com> Message-ID: <87r4894ehd.fsf@vigenere.g10code.de> On Tue, 14 Jan 2014 21:50, Glorius.Gaduang at ge.com said: > make: Fatal error: Don't know how to make target `../cipher/libcipher.a' > Current working directory /orpogdp1/app/proj_software/gnupg-1.4.16/tools Did you used "make -jN" - it is possible that a dependecy is missing. Or you make is broken. What OS and what compiler are you using? Workaround: (cd cipher && make) make Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Wed Jan 15 14:02:12 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 15 Jan 2014 14:02:12 +0100 Subject: Windows editor destroys gpg.conf Message-ID: <2493524.C6BlPeE1qm@inno.berlin.laging.de> Hello, when I help Windows users create keys then my script converts the Linux version of gpg.conf (after some editing) to the Windows line endings. This works. But if I edit the file with the Windows editor (unfortunately I have forgotten the Windows version) then gpg crashes with an error message like "error in gpg.conf:1". I have experienced that several times in the past already. Unfortunately I both don't have Windows at home and have forgotten to make a copy of the damaged file so that I cannot have a look at it. A wild guess is that the editor adds a UTF-8 BOM at the beginning of the file (but that wouldn't affect XP, would it?). Two concerns: 1) Does anyone know what the problem is and/or whether I can avoid it by using another program which is part of Windows (or widely used)? 2) Would it make sense to make gpg work with such config files...? 8-) 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 jerry at seibercom.net Wed Jan 15 14:33:11 2014 From: jerry at seibercom.net (Jerry) Date: Wed, 15 Jan 2014 08:33:11 -0500 Subject: Windows editor destroys gpg.conf In-Reply-To: <2493524.C6BlPeE1qm@inno.berlin.laging.de> References: <2493524.C6BlPeE1qm@inno.berlin.laging.de> Message-ID: <20140115083311.0c77e53f@scorpio> On Wed, 15 Jan 2014 14:02:12 +0100, Hauke Laging stated: > Hello, > > when I help Windows users create keys then my script converts the > Linux version of gpg.conf (after some editing) to the Windows line > endings. This works. > > But if I edit the file with the Windows editor (unfortunately I have > forgotten the Windows version) then gpg crashes with an error message > like "error in gpg.conf:1". I have experienced that several times in > the past already. > > Unfortunately I both don't have Windows at home and have forgotten to > make a copy of the damaged file so that I cannot have a look at it. > > A wild guess is that the editor adds a UTF-8 BOM at the beginning of > the file (but that wouldn't affect XP, would it?). > > Two concerns: > > 1) Does anyone know what the problem is and/or whether I can avoid it > by using another program which is part of Windows (or widely used)? > > 2) Would it make sense to make gpg work with such config files...? 8-) Personally, I use "PSPad" to edit files from different OSs on a Window's machine. . It can save in several different formats and styles. Plus, it is free. -- Jerry From bernhard at intevation.de Wed Jan 15 14:47:55 2014 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 15 Jan 2014 14:47:55 +0100 Subject: Qt security (Re: GPG Assuan protocol usage) In-Reply-To: <87y52p9ulu.fsf@vigenere.g10code.de> References: <87y52p9ulu.fsf@vigenere.g10code.de> Message-ID: <201401151448.06155.bernhard@intevation.de> On Thursday 09 January 2014 at 14:02:05, Werner Koch wrote: > . Since posting I've come across the Qt > > > Cryptographic Architecture (qca) which looks to be a better approach for > > me as I'm already developing in Qt. > > You may want to view Ilja van Sprundel's lecture "X security" > ? http://events.ccc.de/congress/2013/Fahrplan/events/5499.html Yes, the talk is interesting, there is only a little bit about Qt and the some responses from the Qt community are summarized here: https://daniel.molkentin.net/2014/01/04/on-practical-qt-security/ If somebody knows more about how qca fares as a crypto librariy or versus gnugp, I'd be interested in reviews (by pm, if you don't like to send it over the list.) -- 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 pete at heypete.com Wed Jan 15 14:31:16 2014 From: pete at heypete.com (Pete Stephenson) Date: Wed, 15 Jan 2014 14:31:16 +0100 Subject: Windows editor destroys gpg.conf In-Reply-To: <2493524.C6BlPeE1qm@inno.berlin.laging.de> References: <2493524.C6BlPeE1qm@inno.berlin.laging.de> Message-ID: On Wed, Jan 15, 2014 at 2:02 PM, Hauke Laging wrote: > Two concerns: > > 1) Does anyone know what the problem is and/or whether I can avoid it by > using another program which is part of Windows (or widely used)? I like using Notepad++ . It understands Unix and Windows end-of-line conventions and can switch between them as needed. I've had no problems editing my gpg.conf file with it. Cheers! -Pete -- Pete Stephenson From tristan.santore at internexusconnect.net Wed Jan 15 16:16:57 2014 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Wed, 15 Jan 2014 15:16:57 +0000 Subject: Windows editor destroys gpg.conf In-Reply-To: <20140115083311.0c77e53f@scorpio> References: <2493524.C6BlPeE1qm@inno.berlin.laging.de> <20140115083311.0c77e53f@scorpio> Message-ID: <52D6A669.8020806@internexusconnect.net> On 15/01/14 13:33, Jerry wrote: > On Wed, 15 Jan 2014 14:02:12 +0100, Hauke Laging stated: > >> Hello, >> >> when I help Windows users create keys then my script converts the >> Linux version of gpg.conf (after some editing) to the Windows line >> endings. This works. >> >> But if I edit the file with the Windows editor (unfortunately I have >> forgotten the Windows version) then gpg crashes with an error message >> like "error in gpg.conf:1". I have experienced that several times in >> the past already. >> >> Unfortunately I both don't have Windows at home and have forgotten to >> make a copy of the damaged file so that I cannot have a look at it. >> >> A wild guess is that the editor adds a UTF-8 BOM at the beginning of >> the file (but that wouldn't affect XP, would it?). >> >> Two concerns: >> >> 1) Does anyone know what the problem is and/or whether I can avoid it >> by using another program which is part of Windows (or widely used)? >> >> 2) Would it make sense to make gpg work with such config files...? 8-) > > Personally, I use "PSPad" to edit files from different OSs on a Window's > machine. . It can save in several different > formats and styles. Plus, it is free. > unix2dos and dos2unix are your friends. 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 From casey4nsa at hotmail.com Wed Jan 15 14:40:33 2014 From: casey4nsa at hotmail.com (Casey Lisa) Date: Wed, 15 Jan 2014 05:40:33 -0800 Subject: Windows editor destroys gpg.conf Message-ID: Jerry I just now received the email. My name : Casey Lisa. I am new and I am very sexy girl so I post ad on cl website because im still looking hot guy and I like 69 position and your ? I would firs of all want to state this is not my typical behavior. I consider my self exceedingly diffident, but really fascinated my interested and hopefully and I will fascinate yours. Let's get to know one another a little by email I went ahead and attached a image, I am a little frustrated that you didn't send a photo. Let me kow if I am want you are looking. I just love getting my titties fondled. but sorry i dont swallow, ew..plz dont ask for any personal info.. im here for discrete encounters..hehehe. anways, ive attached a pix of me,if you're interested, let me know. -------------- next part -------------- A non-text attachment was scrubbed... Name: Casey lisa (1).jpg Type: image/jpeg Size: 78343 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Casey lisa (2).jpg Type: image/jpeg Size: 60022 bytes Desc: not available URL: From nobody at dizum.com Wed Jan 15 14:48:32 2014 From: nobody at dizum.com (Nomen Nescio) Date: Wed, 15 Jan 2014 14:48:32 +0100 (CET) Subject: Windows editor destroys gpg.conf Message-ID: <4a47b85a0bb5ff733dbd5e3bcbb5eeb4@dizum.com> i do testing unix line end conf is ok on windows of course dos line end is ok too utf8-bom, unicode, unicode-be file formats all fail > gpg -K --options utf8-bom-conf.txt gpg: utf8-bom-conf.txt:1: invalid option > gpg -K --options unicode-be-conf.txt gpg: unicode-be-conf.txt:1: invalid option gpg: unicode-be-conf.txt:2: invalid option gpg: unicode-be-conf.txt:3: invalid option ... > gpg -K --options unicode-conf.txt gpg: unicode-conf.txt:1: invalid option gpg: unicode-conf.txt:2: invalid option gpg: unicode-conf.txt:3: invalid option ... From vedaal at nym.hush.com Wed Jan 15 16:38:18 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Wed, 15 Jan 2014 10:38:18 -0500 Subject: Windows editor destroys gpg.conf In-Reply-To: References: <2493524.C6BlPeE1qm@inno.berlin.laging.de> Message-ID: <20140115153818.D6C51200EC@smtp.hushmail.com> On Wed, Jan 15, 2014 at 2:02 PM, Hauke Laging wrote: > 1) Does anyone know what the problem is and/or whether I can >avoid it by > using another program which is part of Windows (or widely used)? ===== I often switch between Ubuntu and Windows, and have 2 separate gpg.conf. files, (my keyrings are in a truecrypt container, and in Windows, truecrypt containers mount to their own file letter (e.g. V:\) while in Ubuntu it mounts as a numbered directory as part of a dev/ directory, so the home directory for gnupg has a different address). Anyway, when using a gpg.conf file in windows that was done in Ubuntu, Windows sometimes 'decides' that the lines are too long and wrap them, thereby creating a new line in gpg.conf that makes no sense. This can happen if the 'Comment' option line is too long, or a # commented out line is too long. Another reason that might invalidate a gpg.conf, on windows, is if there are any '/' instead of '\' . The actual program in Linux that is used to write the gpg.conf doesn't really matter. Using Notepad to edit it in windows will quickly show if there is a problem. Notepad is in every edition of windows, and opens files without .txt extensions. (It easily open gpg.conf and saves it a gpg.conf). vedaal From dsaklad at gnu.org Thu Jan 16 11:34:34 2014 From: dsaklad at gnu.org (Don Warner Saklad) Date: Thu, 16 Jan 2014 05:34:34 -0500 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? Message-ID: <5i7ga0kyf9.fsf@fencepost.gnu.org> Any way for two correspondents to set up gnupg within a few moments without having to become expert? The usual gnupg materials are very dense. From mailinglisten at hauke-laging.de Thu Jan 16 12:31:56 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 16 Jan 2014 12:31:56 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <5i7ga0kyf9.fsf@fencepost.gnu.org> References: <5i7ga0kyf9.fsf@fencepost.gnu.org> Message-ID: <1946420.RbLcrh2XNO@inno.berlin.laging.de> Am Do 16.01.2014, 05:34:34 schrieb Don Warner Saklad: > Any way for two correspondents to set up gnupg within a few moments > without having to become expert? > > The usual gnupg materials are very dense. Ask an "expert" to do the setup. After that usage is simple. 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 fa-ml at ariis.it Thu Jan 16 12:39:59 2014 From: fa-ml at ariis.it (fa-ml) Date: Thu, 16 Jan 2014 12:39:59 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <5i7ga0kyf9.fsf@fencepost.gnu.org> References: <5i7ga0kyf9.fsf@fencepost.gnu.org> Message-ID: <20140116113959.GA30144@efikamx> On Thu, Jan 16, 2014 at 05:34:34AM -0500, Don Warner Saklad wrote: > Any way for two correspondents to set up gnupg within a few moments > without having to become expert? > > The usual gnupg materials are very dense. > The most "complex" part is generating and sharing your public keys, which can be as easy as: gpg --gen-key gpg --send-key gpg --search-key gpg --fingerprint After checking (on the phone or on some other channel) that the fingerprint matches, you can type gpg -e to encrypt a file. The commands are for the most part interactive, hence "easy to follow"). Mail client integration becomes a must if you need to exchange more than a few messages. I use mutt, but there are many other setups (Thunderbird & Enigmail, claws-mail, etc.) that are PGP friendly. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rsawhill at gmail.com Thu Jan 16 14:03:06 2014 From: rsawhill at gmail.com (Ryan Sawhill Aroha) Date: Thu, 16 Jan 2014 08:03:06 -0500 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <5i7ga0kyf9.fsf@fencepost.gnu.org> References: <5i7ga0kyf9.fsf@fencepost.gnu.org> Message-ID: Yes. Decide a shared passphrase via a secure channel and just use gpg -c. On Jan 16, 2014 6:24 AM, "Don Warner Saklad" wrote: > Any way for two correspondents to set up gnupg within a few moments > without having to become expert? > > The usual gnupg materials are very dense. > > _______________________________________________ > 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 seanl at literati.org Fri Jan 17 02:24:45 2014 From: seanl at literati.org (Sean Lynch) Date: Thu, 16 Jan 2014 17:24:45 -0800 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <87txdebs0l.fsf@vigenere.g10code.de> References: <52CC100D.9080303@guardianproject.info> <87txdebs0l.fsf@vigenere.g10code.de> Message-ID: On Wed, Jan 8, 2014 at 4:02 AM, Werner Koch wrote: > On Tue, 7 Jan 2014 15:32, hans at guardianproject.info said: > > > OpenPGP card as a PKCS11 keystore. It seems that things are close: Java > can > > use NSS as a provider of PKCS11. I guess the question is whether opensc > is > > making a PKCS#11 interface to the OpenPGP card, that's the bit that I > don't > > Scute also provides an pkcs#11 interface to NSS. Thus you should be > able to use it also with Java. > Scute works great with Firefox, but keep in mind it requires gpg-agent (or at least scdaemon). AFAIK it's not intended to work with anything other than Firefox right now. I've been meaning to try it out with wpa_supplicant and openvpn, so please let us know if you get it to work with anything other than Firefox! The code seems fairly straightforward and it comes with documentation for spying on the PKCS#11 calls to help troubleshoot the implementation, so even if it doesn't work it may not require too much hacking to make it work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Jan 17 09:05:19 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 17 Jan 2014 09:05:19 +0100 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: (Sean Lynch's message of "Thu, 16 Jan 2014 17:24:45 -0800") References: <52CC100D.9080303@guardianproject.info> <87txdebs0l.fsf@vigenere.g10code.de> Message-ID: <87r48711a8.fsf@vigenere.g10code.de> On Fri, 17 Jan 2014 02:24, seanl at literati.org said: > Scute works great with Firefox, but keep in mind it requires gpg-agent (or Sure. That is the whole point of the exercise. > at least scdaemon). AFAIK it's not intended to work with anything other > than Firefox right now. I've been meaning to try it out with wpa_supplicant Well, it has not been tested with anything else. However, it implements the pkcs#11 interface properly for signature keys and Marcus even came up with a free and readable implementation of the pkcs11 header file. > The code seems fairly straightforward and it comes with documentation for > spying on the PKCS#11 calls to help troubleshoot the implementation, so > even if it doesn't work it may not require too much hacking to make it Right. I would love to see a new maintainer for it. If there are any GnuPG related problems I will for sure help with it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From daniele.athome at gmail.com Fri Jan 17 11:44:55 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Fri, 17 Jan 2014 11:44:55 +0100 Subject: Reusing signed user ID or attribute Message-ID: Hello list, I'm manipulating PGP keys with Bouncy Castle, especially signatures of user IDs and user attributes. But my question is not about development, it's about signatures. My question is the following: suppose I create a user ID or attribute. I sign it with my key and that's ok. One day I revoke that user ID or attribute and sign it again with a certification revocation. A few years later, I want to restore that user ID or attribute because, e.g. I restored an old e-mail address. Is it enough to sign the revoked user attribute once again with a valid signature (then timestamps will do the rest) or do I have to create a new user ID with the same data? Thanks -- Daniele From mailinglisten at hauke-laging.de Fri Jan 17 13:28:50 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 17 Jan 2014 13:28:50 +0100 Subject: Reusing signed user ID or attribute In-Reply-To: References: Message-ID: <2749437.OFTHnCB0mO@inno.berlin.laging.de> Am Fr 17.01.2014, 11:44:55 schrieb Daniele Ricci: > My question is the following: suppose I create a user ID or attribute. > I sign it with my key and that's ok. > One day I revoke that user ID or attribute and sign it again with a > certification revocation. > > A few years later, I want to restore that user ID or attribute > because, e.g. I restored an old e-mail address. Is it enough to sign > the revoked user attribute once again with a valid signature (then > timestamps will do the rest) or do I have to create a new user ID with > the same data? I am afraid that depends on the implementation. The RfC isn't clear on that (if I understand it correctly). It says about self-signatures (a revocation is not a self-signature in this sense, though): "An implementation that encounters multiple self-signatures on the same object may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the most recent self-signature." About revocations it says: "0x30: Certification revocation signature This signature revokes an earlier User ID certification signature (signature class 0x10 through 0x13) or direct-key signature (0x1F). It should be issued by the same key that issued the revoked signature or an authorized revocation key. The signature is computed over the same data as the certificate that it revokes, and should have a later creation date than that certificate." IIRC then GnuPG accepts a later self-signature (overriding the revocation). IMHO that makes most sense. As long as the mainkey isn't revoked or expired why shouldn't one "change one's mind"? I haven't tried now but IIRC you have to delete the revocation first before you can create a new signature. 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 hans at guardianproject.info Fri Jan 17 16:44:10 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 17 Jan 2014 10:44:10 -0500 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <87r48711a8.fsf@vigenere.g10code.de> References: <52CC100D.9080303@guardianproject.info> <87txdebs0l.fsf@vigenere.g10code.de> <87r48711a8.fsf@vigenere.g10code.de> Message-ID: <52D94FCA.1060601@guardianproject.info> On 01/17/2014 03:05 AM, Werner Koch wrote: > On Fri, 17 Jan 2014 02:24, seanl at literati.org said: > >> Scute works great with Firefox, but keep in mind it requires gpg-agent (or > > Sure. That is the whole point of the exercise. > >> at least scdaemon). AFAIK it's not intended to work with anything other >> than Firefox right now. I've been meaning to try it out with wpa_supplicant > > Well, it has not been tested with anything else. However, it implements > the pkcs#11 interface properly for signature keys and Marcus even came > up with a free and readable implementation of the pkcs11 header file. > >> The code seems fairly straightforward and it comes with documentation for >> spying on the PKCS#11 calls to help troubleshoot the implementation, so >> even if it doesn't work it may not require too much hacking to make it > > Right. I would love to see a new maintainer for it. If there are any > GnuPG related problems I will for sure help with it. How does scute's PKCS#11 support differ from OpenSC's? If the OpenPGP card is supported by opensc, is that providing the same thing as scute? I already have Java's keytool talking to the OpenPGP card via OpenSC, I just can't get it to sign something yet. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From seanl at literati.org Fri Jan 17 18:37:52 2014 From: seanl at literati.org (Sean Lynch) Date: Fri, 17 Jan 2014 09:37:52 -0800 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <52D94FCA.1060601@guardianproject.info> References: <52CC100D.9080303@guardianproject.info> <87txdebs0l.fsf@vigenere.g10code.de> <87r48711a8.fsf@vigenere.g10code.de> <52D94FCA.1060601@guardianproject.info> Message-ID: Scute accesses the card via either scdaemon or gpg-agent (I can't remember which and I'm on my phone), so you don't need to release the card and reenter your PIN to switch back and forth between PKCS#11 and gpg/gpgsm. However, it's a minimal implementation of the parts of the API necessary for X.509 auth in Firefox, so I have no idea what else it might work for in its present state. I plan to try it with OpenVPN pretty soon. On Jan 17, 2014 7:44 AM, "Hans-Christoph Steiner" wrote: > > > On 01/17/2014 03:05 AM, Werner Koch wrote: > > On Fri, 17 Jan 2014 02:24, seanl at literati.org said: > > > >> Scute works great with Firefox, but keep in mind it requires gpg-agent > (or > > > > Sure. That is the whole point of the exercise. > > > >> at least scdaemon). AFAIK it's not intended to work with anything other > >> than Firefox right now. I've been meaning to try it out with > wpa_supplicant > > > > Well, it has not been tested with anything else. However, it implements > > the pkcs#11 interface properly for signature keys and Marcus even came > > up with a free and readable implementation of the pkcs11 header file. > > > >> The code seems fairly straightforward and it comes with documentation > for > >> spying on the PKCS#11 calls to help troubleshoot the implementation, so > >> even if it doesn't work it may not require too much hacking to make it > > > > Right. I would love to see a new maintainer for it. If there are any > > GnuPG related problems I will for sure help with it. > > How does scute's PKCS#11 support differ from OpenSC's? If the OpenPGP > card is > supported by opensc, is that providing the same thing as scute? I already > have Java's keytool talking to the OpenPGP card via OpenSC, I just can't > get > it to sign something yet. > > .hc > > > -- > PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes at zarl.at Fri Jan 17 20:03:15 2014 From: johannes at zarl.at (Johannes Zarl) Date: Fri, 17 Jan 2014 20:03:15 +0100 Subject: Reusing signed user ID or attribute In-Reply-To: <2749437.OFTHnCB0mO@inno.berlin.laging.de> References: <2749437.OFTHnCB0mO@inno.berlin.laging.de> Message-ID: <17626252.FzVL7xTleY@mani> On Friday 17 January 2014 13:28:50 Hauke Laging wrote: > IIRC then GnuPG accepts a later self-signature (overriding the > revocation). IMHO that makes most sense. As long as the mainkey isn't > revoked or expired why shouldn't one "change one's mind"? Wouldn't that have huge implications for the security(*) of the whole system? If the revocation is a final act, as long as I can make sure that the revocation certificate reaches my communication partners I can be sure that nobody can compromise the key and "reenable" it and start impersonating me. If, however, the revocation is only a temporary act until a newer self- signature supersedes it, it would be almost impossible to effectively and permanently revoke a key. One would either (as long as the private key is not yet compromised) have to destroy the private key, or make sure that all communication partners somehow prevent the key from receiving further updates... Johannes (*) please excuse the blanket-use of the term -------------- 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 dkg at fifthhorseman.net Fri Jan 17 20:33:25 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 17 Jan 2014 14:33:25 -0500 Subject: Reusing signed user ID or attribute In-Reply-To: <17626252.FzVL7xTleY@mani> References: <2749437.OFTHnCB0mO@inno.berlin.laging.de> <17626252.FzVL7xTleY@mani> Message-ID: <52D98585.20809@fifthhorseman.net> On 01/17/2014 02:03 PM, Johannes Zarl wrote: > If the revocation is a final act, as long as I can make sure that the > revocation certificate reaches my communication partners I can be sure that > nobody can compromise the key and "reenable" it and start impersonating me. > > If, however, the revocation is only a temporary act until a newer self- > signature supersedes it, it would be almost impossible to effectively and > permanently revoke a key. One would either (as long as the private key is not > yet compromised) have to destroy the private key, or make sure that all > communication partners somehow prevent the key from receiving further > updates... I think you're conflating revocation of the primary key with revocation of a user ID. Revocation of a primary key is permanent and cannot be overridden. Revocation of a user ID can be overridden as long as the primary key (the one making the certification) is not itself revoked. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Fri Jan 17 23:02:38 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 17 Jan 2014 23:02:38 +0100 Subject: Reusing signed user ID or attribute In-Reply-To: <17626252.FzVL7xTleY@mani> References: <2749437.OFTHnCB0mO@inno.berlin.laging.de> <17626252.FzVL7xTleY@mani> Message-ID: <5726061.rJceETfp0P@inno.berlin.laging.de> Am Fr 17.01.2014, 20:03:15 schrieb Johannes Zarl: > If, however, the revocation is only a temporary act until a newer > self- signature supersedes it, it would be almost impossible to > effectively and permanently revoke a key. That's why we all use only the super-secure (haha) offline mainkeys. 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 clif at eugeneweb.com Fri Jan 17 22:15:50 2014 From: clif at eugeneweb.com (Mr. Clif) Date: Fri, 17 Jan 2014 13:15:50 -0800 Subject: Looking for simple wrapper for symmetric key file encryption Message-ID: <52D99D86.3090003@eugeneweb.com> Greetings! I've been happily using pgp and gpg off and on for decades. One thing I never quite figured out was what the best way to use it for encrypting sensitive files on disk. After doing that one has to remember to cleanup after themselves and delete all the leftover plaintext versions of the file, or it kind of defeats the whole purpose, and its pretty easy to make a mistake when doing it manually. I always felt that GPG should help you a bit more in that regard. Now I know that full disk encryption might be a way around this, but it seems like overkill if you just have a couple of files to protect. I have searched high and low and checked out GnuPG Shell, GPA, Seahorse, XAP, and some other misc wrappers but nothing seemed to fit my use case. So I wrote a simple wrapper in perl. Basically it just lets you toggle a file between plaintext and encrypted forms without letting the plaintext version touch/remain on the disk, unless that is what you want. #! /usr/bin/perl -U # This Perl script is a wrapper around GPG to decrypt or encrypt a file. # It's goal is to try to prevent plaintext from touching, or remaining # on the disk, something GPG fails to do. If there is a new file created # It will be in the same directory as the original unless you specify a new # path in a second arg. # # By Clif 12/05/13 # # External utilities $GPG = "/usr/bin/gpg"; # GnuPG 1.4.15 $SHRED = "/usr/bin/shred"; # secure file deleter (GNU coreutils) 8.13 # Arguments ($arg, $dest) = @ARGV; # Break down the pathname $path = $1 if $arg =~ /^(.*?)(\/[^\/]*)$/; $file = $1 if $arg =~ /([^\/]+)\/?$/; $base = $1 if $file =~ /^(.+?)(\.[^.]*)?$/; $ext = $1 if $file =~ /\.([^. ]*)\s*$/; # Get destination if ($dest) { $destp = 1; $dest .= "/$base" if (-d $dest); $dest =~ s/\.asc\s*$//; } else { $dest = $path ? "$path/$base" : $base } # Is this a planetext or an encrypted file? if (-r $arg) { if ($ext eq "asc") { # Encrypted if ($destp) { system("$GPG -o $dest $arg") } else { system("$GPG -o - $arg") } } else { # Plaintext unlink "${dest}.asc"; $err = system("$GPG -o ${dest}.asc -ca --cipher-algo AES256 $arg"); if ($err) { print "ERROR = $err\n" } else { system("$SHRED -un9 $arg") } } } else { warn "No such file: $arg\n" } # All done Obviously it could be much more thorough but I just wanted to get the idea across. I was also thinking about adding a RAM based editing feature but I didn't want to reinvent the wheel if someone knows of a similar project. Thanks for any comments you might have, Clif From johannes at zarl.at Sat Jan 18 00:20:03 2014 From: johannes at zarl.at (Johannes Zarl) Date: Sat, 18 Jan 2014 00:20:03 +0100 Subject: Reusing signed user ID or attribute In-Reply-To: <52D98585.20809@fifthhorseman.net> References: <17626252.FzVL7xTleY@mani> <52D98585.20809@fifthhorseman.net> Message-ID: <1797702.JyA7KLmTuz@mani> On Friday 17 January 2014 14:33:25 Daniel Kahn Gillmor wrote: > I think you're conflating revocation of the primary key with revocation > of a user ID. > > Revocation of a primary key is permanent and cannot be overridden. > Revocation of a user ID can be overridden as long as the primary key > (the one making the certification) is not itself revoked. Ah, yes, I was indeed thinking of the primary key. Thanks for clearing that up! Cheers, Johannes -------------- 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 clif at eugeneweb.com Sun Jan 19 07:50:49 2014 From: clif at eugeneweb.com (Mr. Clif) Date: Sat, 18 Jan 2014 22:50:49 -0800 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: <52D99D86.3090003@eugeneweb.com> References: <52D99D86.3090003@eugeneweb.com> Message-ID: <52DB75C9.7060801@eugeneweb.com> So no one got back to me. Does anyone use symmetric file encryption? What is the best practice here? I heard of another solution which was to mount an encrypted directory with fuser to drop files into. I think I would wounder how safe the passphrase was for mounted filesystems, though I know of some techniques for protecting them. Any pointers regarding best practices for symmetric file encryption would be much appreciated. Thanks, Clif On 01/17/2014 01:15 PM, Mr. Clif wrote: > Greetings! > > I've been happily using pgp and gpg off and on for decades. One thing > I never quite figured out was what the best way to use it for > encrypting sensitive files on disk. After doing that one has to > remember to cleanup after themselves and delete all the leftover > plaintext versions of the file, or it kind of defeats the whole > purpose, and its pretty easy to make a mistake when doing it manually. > I always felt that GPG should help you a bit more in that regard. Now > I know that full disk encryption might be a way around this, but it > seems like overkill if you just have a couple of files to protect. > > I have searched high and low and checked out GnuPG Shell, GPA, > Seahorse, XAP, and some other misc wrappers but nothing seemed to fit > my use case. So I wrote a simple wrapper in perl. Basically it just > lets you toggle a file between plaintext and encrypted forms without > letting the plaintext version touch/remain on the disk, unless that is > what you want. > > #! /usr/bin/perl -U > # This Perl script is a wrapper around GPG to decrypt or encrypt > a file. > # It's goal is to try to prevent plaintext from touching, or remaining > # on the disk, something GPG fails to do. If there is a new file > created > # It will be in the same directory as the original unless you > specify a new > # path in a second arg. > # > # By Clif 12/05/13 > # > > # External utilities > $GPG = "/usr/bin/gpg"; # GnuPG 1.4.15 > $SHRED = "/usr/bin/shred"; # secure file deleter > (GNU coreutils) 8.13 > > # Arguments > ($arg, $dest) = @ARGV; > > # Break down the pathname > $path = $1 if $arg =~ /^(.*?)(\/[^\/]*)$/; > $file = $1 if $arg =~ /([^\/]+)\/?$/; > $base = $1 if $file =~ /^(.+?)(\.[^.]*)?$/; > $ext = $1 if $file =~ /\.([^. ]*)\s*$/; > > # Get destination > if ($dest) { > $destp = 1; > $dest .= "/$base" if (-d $dest); > $dest =~ s/\.asc\s*$//; > } else { $dest = $path ? "$path/$base" : $base } > > # Is this a planetext or an encrypted file? > > if (-r $arg) { > if ($ext eq "asc") { # Encrypted > if ($destp) { system("$GPG -o $dest $arg") } > else { system("$GPG -o - $arg") } > } else { # Plaintext > unlink "${dest}.asc"; > $err = system("$GPG -o ${dest}.asc -ca --cipher-algo AES256 > $arg"); > if ($err) { print "ERROR = $err\n" } > else { system("$SHRED -un9 $arg") } > } > } else { warn "No such file: $arg\n" } > # All done > > > Obviously it could be much more thorough but I just wanted to get the > idea across. I was also thinking about adding a RAM based editing > feature but I didn't want to reinvent the wheel if someone knows of a > similar project. > > Thanks for any comments you might have, > Clif > > From andy.ruddock at rainydayz.org Sun Jan 19 12:12:25 2014 From: andy.ruddock at rainydayz.org (Andy Ruddock) Date: Sun, 19 Jan 2014 11:12:25 +0000 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: <52DB75C9.7060801@eugeneweb.com> References: <52D99D86.3090003@eugeneweb.com> <52DB75C9.7060801@eugeneweb.com> Message-ID: <52DBB319.9050801@rainydayz.org> I use ecryptfs, as packages are available for my distro (Debian) which make it easy to install and use. I wouldn't like to make any claims about "best practice", for the most part I rely on defaults provided by more knowledgeable folks than myself. Mr. Clif wrote: > So no one got back to me. > > Does anyone use symmetric file encryption? What is the best practice > here? I heard of another solution which was to mount an encrypted > directory with fuser to drop files into. I think I would wounder how > safe the passphrase was for mounted filesystems, though I know of some > techniques for protecting them. > > Any pointers regarding best practices for symmetric file encryption > would be much appreciated. > > Thanks, > Clif > > On 01/17/2014 01:15 PM, Mr. Clif wrote: >> Greetings! >> >> I've been happily using pgp and gpg off and on for decades. One thing >> I never quite figured out was what the best way to use it for >> encrypting sensitive files on disk. After doing that one has to >> remember to cleanup after themselves and delete all the leftover >> plaintext versions of the file, or it kind of defeats the whole >> purpose, and its pretty easy to make a mistake when doing it manually. >> I always felt that GPG should help you a bit more in that regard. Now >> I know that full disk encryption might be a way around this, but it >> seems like overkill if you just have a couple of files to protect. >> >> I have searched high and low and checked out GnuPG Shell, GPA, >> Seahorse, XAP, and some other misc wrappers but nothing seemed to fit >> my use case. So I wrote a simple wrapper in perl. Basically it just >> lets you toggle a file between plaintext and encrypted forms without >> letting the plaintext version touch/remain on the disk, unless that is >> what you want. >> >> #! /usr/bin/perl -U >> # This Perl script is a wrapper around GPG to decrypt or encrypt >> a file. >> # It's goal is to try to prevent plaintext from touching, or remaining >> # on the disk, something GPG fails to do. If there is a new file >> created >> # It will be in the same directory as the original unless you >> specify a new >> # path in a second arg. >> # >> # By Clif 12/05/13 >> # >> >> # External utilities >> $GPG = "/usr/bin/gpg"; # GnuPG 1.4.15 >> $SHRED = "/usr/bin/shred"; # secure file deleter >> (GNU coreutils) 8.13 >> >> # Arguments >> ($arg, $dest) = @ARGV; >> >> # Break down the pathname >> $path = $1 if $arg =~ /^(.*?)(\/[^\/]*)$/; >> $file = $1 if $arg =~ /([^\/]+)\/?$/; >> $base = $1 if $file =~ /^(.+?)(\.[^.]*)?$/; >> $ext = $1 if $file =~ /\.([^. ]*)\s*$/; >> >> # Get destination >> if ($dest) { >> $destp = 1; >> $dest .= "/$base" if (-d $dest); >> $dest =~ s/\.asc\s*$//; >> } else { $dest = $path ? "$path/$base" : $base } >> >> # Is this a planetext or an encrypted file? >> >> if (-r $arg) { >> if ($ext eq "asc") { # Encrypted >> if ($destp) { system("$GPG -o $dest $arg") } >> else { system("$GPG -o - $arg") } >> } else { # Plaintext >> unlink "${dest}.asc"; >> $err = system("$GPG -o ${dest}.asc -ca --cipher-algo AES256 >> $arg"); >> if ($err) { print "ERROR = $err\n" } >> else { system("$SHRED -un9 $arg") } >> } >> } else { warn "No such file: $arg\n" } >> # All done >> >> >> Obviously it could be much more thorough but I just wanted to get the >> idea across. I was also thinking about adding a RAM based editing >> feature but I didn't want to reinvent the wheel if someone knows of a >> similar project. >> >> Thanks for any comments you might have, >> Clif >> >> > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Andy Ruddock ------------ andy.ruddock at rainydayz.org (OpenPGP Key ID 0xB0324245) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Sun Jan 19 12:53:55 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 19 Jan 2014 12:53:55 +0100 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: <52DB75C9.7060801@eugeneweb.com> References: <52D99D86.3090003@eugeneweb.com> <52DB75C9.7060801@eugeneweb.com> Message-ID: <52DBBCD3.8080705@vulcan.xs4all.nl> On 19-1-2014 7:50, Mr. Clif wrote: > Does anyone use symmetric file encryption? Yes, but only for encrypting files for personal use. Not in communication with others. > What is the best practice here? As always, that depends on your use case and threat model. > I heard of another solution which was to mount an encrypted > directory with fuser to drop files into. Possible, I use TrueCryot containers for that but that's similar (although more portable and usable on "that other OS"). > I think I would wounder how > safe the passphrase was for mounted filesystems, Are you asking how long it would take to brute-force the pasword, how difficult it is to snoop it or if there are known vulnarabilities in the symmetric encryption used by gnupg, fuser or others? > though I know of some techniques for protecting them. Remember the weakest link in all encryption: https://xkcd.com/538/ -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From ms at it-infrastrukturen.org Sun Jan 19 14:46:19 2014 From: ms at it-infrastrukturen.org (Mark Schneider) Date: Sun, 19 Jan 2014 14:46:19 +0100 Subject: =?UTF-8?B?Z251cGcgYmluYXJpZXMgdG9vIGJpZz8gLyBPcGVuQlNEIE1vdmluZyA=?= =?UTF-8?B?VG93YXJkcyBTaWduZWQgUGFja2FnZXMg4oCUIEJhc2VkIE9uIEQuIEouIEJlcm4=?= =?UTF-8?B?c3RlaW4gQ3J5cHRv?= Message-ID: <52DBD72B.8030003@it-infrastrukturen.org> Hi, Is there any possibility to create a minimal version of gnupg? http://bsd.slashdot.org/story/14/01/19/0124202/openbsd-moving-towards-signed-packages-based-on-d-j-bernstein-crypto # --- /"It's official: 'we are moving towards signed packages ,' says Theo de Raadt on the misc@ mailing list. This is shortly after a new utility, signify , was committed into the base tree. The reason a new utility had to be written in the first place is that gnupg is too big to fit on the floppy discs, which are still a supported installation medium for OpenBSD. Signatures are based on the Ed25519 public-key signature system from D. J. Bernstein and co., and his public domain code once again appears in the base tree of OpenBSD, only a few weeks after some other DJB inventions made it into the nearby OpenSSH as well."/ Kind regards, Mark -- ms at it-infrastrukturen.org http://rsync.it-infrastrukturen.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele.athome at gmail.com Sun Jan 19 15:55:51 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Sun, 19 Jan 2014 15:55:51 +0100 Subject: Reusing signed user ID or attribute In-Reply-To: <2749437.OFTHnCB0mO@inno.berlin.laging.de> References: <2749437.OFTHnCB0mO@inno.berlin.laging.de> Message-ID: Ok, so I have to conclude it's implementation specific? I'm using a custom user attribute to store something that can change quite often (privacy lists for a chat user). What do you suggest? On Fri, Jan 17, 2014 at 1:28 PM, Hauke Laging wrote: > Am Fr 17.01.2014, 11:44:55 schrieb Daniele Ricci: > >> My question is the following: suppose I create a user ID or attribute. >> I sign it with my key and that's ok. >> One day I revoke that user ID or attribute and sign it again with a >> certification revocation. >> >> A few years later, I want to restore that user ID or attribute >> because, e.g. I restored an old e-mail address. Is it enough to sign >> the revoked user attribute once again with a valid signature (then >> timestamps will do the rest) or do I have to create a new user ID with >> the same data? > > I am afraid that depends on the implementation. The RfC isn't clear on > that (if I understand it correctly). > > It says about self-signatures (a revocation is not a self-signature in > this sense, though): > > "An implementation that encounters multiple self-signatures on the same > object may resolve the ambiguity in any way it sees fit, but it is > RECOMMENDED that priority be given to the most recent self-signature." > > About revocations it says: > > "0x30: Certification revocation signature > This signature revokes an earlier User ID certification signature > (signature class 0x10 through 0x13) or direct-key signature > (0x1F). It should be issued by the same key that issued the > revoked signature or an authorized revocation key. The signature > is computed over the same data as the certificate that it > revokes, and should have a later creation date than that > certificate." > > IIRC then GnuPG accepts a later self-signature (overriding the > revocation). IMHO that makes most sense. As long as the mainkey isn't > revoked or expired why shouldn't one "change one's mind"? > > I haven't tried now but IIRC you have to delete the revocation first > before you can create a new signature. > > > 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 -- Daniele From mailinglisten at hauke-laging.de Sun Jan 19 17:14:58 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 19 Jan 2014 17:14:58 +0100 Subject: Reusing signed user ID or attribute In-Reply-To: References: <2749437.OFTHnCB0mO@inno.berlin.laging.de> Message-ID: <1481966.YEK3xHextA@inno.berlin.laging.de> Am So 19.01.2014, 15:55:51 schrieb Daniele Ricci: > Ok, so I have to conclude it's implementation specific? > I'm using a custom user attribute to store something that can change > quite often (privacy lists for a chat user). What do you suggest? My first thought is: Why should it make sense to put this data into a certificate? Use a simple file with a simple signature. Let the signature expire every few days (or hours, whatever you need). You may put the URL of the file into the certificate using a notation. 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 Sun Jan 19 17:21:14 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 19 Jan 2014 11:21:14 -0500 Subject: Reusing signed user ID or attribute In-Reply-To: References: <2749437.OFTHnCB0mO@inno.berlin.laging.de> Message-ID: <52DBFB7A.6030707@fifthhorseman.net> On 01/19/2014 09:55 AM, Daniele Ricci wrote: > Ok, so I have to conclude it's implementation specific? > I'm using a custom user attribute to store something that can change > quite often (privacy lists for a chat user). What do you suggest? I don't know what a "privacy list for a chat user" is. You should probably try to document what you are trying to achieve more clearly, and present it in a public forum where people can help you think through possible ways to achieve it. This thread started off by asking about user IDs or attributes, which seems to assume that this is the only way to provide the information you're looking for. But an OpenPGP notation (stored within the self-signature) could also provide that information directly. User IDs and User Attributes are for information that you need or want third parties to confirm and certify. Information in an OpenPGP notation does *not* need to be confirmed or certified by third parties. So if Alice wants to indicate something about her preferences about how to use chat, she can do so in a notation subpacket within her self-sig. does this make sense? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Sun Jan 19 17:52:41 2014 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 19 Jan 2014 17:52:41 +0100 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: <52DBB319.9050801@rainydayz.org> References: <52D99D86.3090003@eugeneweb.com> <52DB75C9.7060801@eugeneweb.com> <52DBB319.9050801@rainydayz.org> Message-ID: <52DC02D9.60609@vulcan.xs4all.nl> On 19-1-2014 12:12, Andy Ruddock wrote: > I wouldn't like to make any claims about "best practice", for the most > part I rely on defaults provided by more knowledgeable folks than myself. Although trust in that approach has gotten some drawback since the actions of RSA Inc. became public knowledge. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From clif at eugeneweb.com Sun Jan 19 17:56:03 2014 From: clif at eugeneweb.com (Mr. Clif) Date: Sun, 19 Jan 2014 08:56:03 -0800 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: <52DBBCD3.8080705@vulcan.xs4all.nl> References: <52D99D86.3090003@eugeneweb.com> <52DB75C9.7060801@eugeneweb.com> <52DBBCD3.8080705@vulcan.xs4all.nl> Message-ID: <52DC03A3.2040600@eugeneweb.com> On 01/19/2014 03:53 AM, Johan Wevers wrote: > On 19-1-2014 7:50, Mr. Clif wrote: > >> Does anyone use symmetric file encryption? > Yes, but only for encrypting files for personal use. Not in > communication with others. Same here. This is why I wrote that perl script, so I wouldn't have to remember to delete the plaintext file after I encrypted it. Are there other front ends or wrappers that help the work flow in this way? >> What is the best practice here? > As always, that depends on your use case and threat model. > >> I heard of another solution which was to mount an encrypted >> directory with fuser to drop files into. > Possible, I use TrueCryot containers for that but that's similar > (although more portable and usable on "that other OS"). > >> I think I would wounder how >> safe the passphrase was for mounted filesystems, > Are you asking how long it would take to brute-force the pasword, how > difficult it is to snoop it or if there are known vulnarabilities in the > symmetric encryption used by gnupg, fuser or others? > >> though I know of some techniques for protecting them. > Remember the weakest link in all encryption: https://xkcd.com/538/ Yes I suppose that's true. Though I was just thinking about ways I heard of to hide the key material in RAM. As I mentioned below, I'd rather not have to resort to an encrypted filesystem just to handle the occasional private file unless the conventional wisdom says that it's the only good way to do it. So I'm trying to get a sense from the users here if they feel that the process of using gpg for symmetric encryption is safe enough, and they are not worried about leaving clear text behind. Thanks, Clif From daniele.athome at gmail.com Sun Jan 19 19:05:20 2014 From: daniele.athome at gmail.com (Daniele Ricci) Date: Sun, 19 Jan 2014 19:05:20 +0100 Subject: Reusing signed user ID or attribute In-Reply-To: <52DBFB7A.6030707@fifthhorseman.net> References: <2749437.OFTHnCB0mO@inno.berlin.laging.de> <52DBFB7A.6030707@fifthhorseman.net> Message-ID: Thank you Daniel, it actually sounds very right. Now that I think about it, storing this kind of data in the public key block isn't so good afterall. I will investigate over this and ask to the right ML next time. Thank you everyone for your help. On Sun, Jan 19, 2014 at 5:21 PM, Daniel Kahn Gillmor wrote: > On 01/19/2014 09:55 AM, Daniele Ricci wrote: >> Ok, so I have to conclude it's implementation specific? >> I'm using a custom user attribute to store something that can change >> quite often (privacy lists for a chat user). What do you suggest? > > I don't know what a "privacy list for a chat user" is. You should > probably try to document what you are trying to achieve more clearly, > and present it in a public forum where people can help you think through > possible ways to achieve it. > > This thread started off by asking about user IDs or attributes, which > seems to assume that this is the only way to provide the information > you're looking for. But an OpenPGP notation (stored within the > self-signature) could also provide that information directly. > > User IDs and User Attributes are for information that you need or want > third parties to confirm and certify. Information in an OpenPGP > notation does *not* need to be confirmed or certified by third parties. > So if Alice wants to indicate something about her preferences about how > to use chat, she can do so in a notation subpacket within her self-sig. > > does this make sense? > > --dkg > > -- Daniele From dougb at dougbarton.us Sun Jan 19 22:23:17 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 19 Jan 2014 13:23:17 -0800 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: <52DC03A3.2040600@eugeneweb.com> References: <52D99D86.3090003@eugeneweb.com> <52DB75C9.7060801@eugeneweb.com> <52DBBCD3.8080705@vulcan.xs4all.nl> <52DC03A3.2040600@eugeneweb.com> Message-ID: <52DC4245.1030802@dougbarton.us> On 01/19/2014 08:56 AM, Mr. Clif wrote: > So I'm trying to get a sense from the users here if they feel that the > process of using gpg for symmetric encryption is safe enough, and they > are not worried about leaving clear text behind. I think you're misunderstanding a few things. First, the problem of the plain text file is not exclusive to symmetric encryption. In fact there is no difference between that, and the plain text file that's left behind after public key encryption. Second, you haven't defined your threat model. You have given us a vague sense of wanting to have a "secure" system, but you haven't said what you're trying to secure it against. Thus it's hard to respond intelligently to your query. That said, I would suggest that you consider using a RAM disk to do your work on. It can be created to do the work, then deleted after you're done, with no risk of leaving a file behind on disk. Of course you'd want to make sure your RAM disk was not swap-backed. hope this helps, Doug From clif at eugeneweb.com Sun Jan 19 22:48:17 2014 From: clif at eugeneweb.com (Mr. Clif) Date: Sun, 19 Jan 2014 13:48:17 -0800 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: <52DC4245.1030802@dougbarton.us> References: <52D99D86.3090003@eugeneweb.com> <52DB75C9.7060801@eugeneweb.com> <52DBBCD3.8080705@vulcan.xs4all.nl> <52DC03A3.2040600@eugeneweb.com> <52DC4245.1030802@dougbarton.us> Message-ID: <52DC4821.5000003@eugeneweb.com> Hi Doug, Thanks for the comments. Yes the threat model is mostly the worry of having old temp files or even the original cleartext files left behind on the HD, or even worse having them backed up. ;-) At the very least I want something that tries to protect me from stupid mistakes. Yep the RAM disk idea was part of the solution I'm heading towards. So do you or does anyone know of a nice front end that helps with that? An example of behavior that doesn't seem helpful is that when I use GPA to decrypt a file it defaults to saving it on the HD. I'm not trying to knock GPA here but wouldn't it be better to display the contents in a window? Well I realize that might be just what I want, and others have use cases that it works fine for. ;-) Clif On 01/19/2014 01:23 PM, Doug Barton wrote: > On 01/19/2014 08:56 AM, Mr. Clif wrote: >> So I'm trying to get a sense from the users here if they feel that the >> process of using gpg for symmetric encryption is safe enough, and they >> are not worried about leaving clear text behind. > > I think you're misunderstanding a few things. First, the problem of > the plain text file is not exclusive to symmetric encryption. In fact > there is no difference between that, and the plain text file that's > left behind after public key encryption. > > Second, you haven't defined your threat model. You have given us a > vague sense of wanting to have a "secure" system, but you haven't said > what you're trying to secure it against. Thus it's hard to respond > intelligently to your query. > > That said, I would suggest that you consider using a RAM disk to do > your work on. It can be created to do the work, then deleted after > you're done, with no risk of leaving a file behind on disk. Of course > you'd want to make sure your RAM disk was not swap-backed. > > hope this helps, > > Doug > From csabi.hlw at gmail.com Mon Jan 20 16:56:39 2014 From: csabi.hlw at gmail.com (Csabi) Date: Mon, 20 Jan 2014 16:56:39 +0100 Subject: old files decryption problem Message-ID: <52DD4737.7060400@googlemail.com> Hi All! I have some old files encrypted with (probably) the old PGP 2.6.x version. I tried to decrypt it with GNUPG 1.4.14, but i unable to do it. I use "gpg -v encryptedfile.pgp option to decrypt the file... gpg: assuming IDEA encrypted data Enter passphrase: gpg: ring trust w/o key gpg: [don't know] invalid packet (ctb=42) gpg: WARNING: message was not integrit protected gpg: packet(2) with unknown version 77 I remembered correctly the password which i used to encrypt the files. If i write any different password then GNUPG shows me the following message: gpg: assuming IDEA encrypted data Enter passphrase: gpg: packet(6) with unknown version 22 gpg: WARNING: message was not integrit protected gpg: uncompressing failed: unknown compress algorithm Are there any differences between this GNUPG version (with built-in IDEA support) and the older GNUPG 1.4.x versions that use the "idea.dll" module? Best regards, Csabi From yumkam at gmail.com Mon Jan 20 21:25:17 2014 From: yumkam at gmail.com (Yuriy Kaminskiy) Date: Tue, 21 Jan 2014 00:25:17 +0400 Subject: old files decryption problem In-Reply-To: <52DD4737.7060400__9340.60946242443$1390237320$gmane$org@googlemail.com> References: <52DD4737.7060400__9340.60946242443$1390237320$gmane$org@googlemail.com> Message-ID: Csabi wrote: > I have some old files encrypted with (probably) the old PGP 2.6.x version. > I tried to decrypt it with GNUPG 1.4.14, but i unable to do it. > I use "gpg -v encryptedfile.pgp option to decrypt the file... > > gpg: assuming IDEA encrypted data > Enter passphrase: > gpg: ring trust w/o key > gpg: [don't know] invalid packet (ctb=42) > gpg: WARNING: message was not integrit protected > gpg: packet(2) with unknown version 77 I've just compiled pgp-2.6.3ii (on linux/i386), encrypted file (pgp -c), with various options (+compress=on/off, +textmode=on/off, pipe/?file, small/?bigger), and decrypted it with gnupg 1.4.14 without any problem. (Of course I could've missed some combination, etc). $ gpg -v stdin.pgp gpg: assuming IDEA encrypted data gpg: WARNING: message was not integrity protected You may also want to try gpg --list-packet Note that when I tried to enter various *incorrect* passwords, error messages also *varied* (invalid packet, packet with unknown version, invalid marker packet, uncompression failed, etc; sometimes one message, sometimes more), so maybe your password just *still incorrect*. (For sake of completeness, I also tried to pass data other way round, pgp2 also was able to decrypt file created with gpg --pgp2 -c /path/to/file) > I remembered correctly the password which i used to encrypt the files. > If i write any different password then GNUPG shows me the following > message: > > gpg: assuming IDEA encrypted data > Enter passphrase: > gpg: packet(6) with unknown version 22 > gpg: WARNING: message was not integrit protected > gpg: uncompressing failed: unknown compress algorithm > > Are there any differences between this GNUPG version (with built-in IDEA > support) and the older GNUPG 1.4.x versions that use the "idea.dll" module? From dkg at fifthhorseman.net Tue Jan 21 00:00:46 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 20 Jan 2014 18:00:46 -0500 Subject: =?UTF-8?B?UmU6IGdudXBnIGJpbmFyaWVzIHRvbyBiaWc/IC8gT3BlbkJTRCBNb3Y=?= =?UTF-8?B?aW5nIFRvd2FyZHMgU2lnbmVkIFBhY2thZ2VzIOKAlCBCYXNlZCBPbiBELiBKLiA=?= =?UTF-8?B?QmVybnN0ZWluIENyeXB0bw==?= In-Reply-To: <52DBD72B.8030003@it-infrastrukturen.org> References: <52DBD72B.8030003@it-infrastrukturen.org> Message-ID: <52DDAA9E.1030708@fifthhorseman.net> On 01/19/2014 08:46 AM, Mark Schneider wrote: > Is there any possibility to create a minimal version of gnupg? gnupg already can produce gpgv, which (on debian at least) is 356KiB, though it also dynamically links to libresolv and libz and libbz2 and libc. I'm sure you could reduce that further if you wanted to tune it. Debian's package manager (apt) has been using signed manifests for years, and makes good use of gpgv for this. I'm sure OpenBSD could do the same if that was their goal. djb's Ed25519 signature mechanisms aren't bad, though, and if the goal is a particular targetted deployment (like it sounds like for openbsd's package management) then it shouldn't be too awkward (though it sounds like their implementation does some funny things with memory to be able to apply djb's code to their particular workload). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From free10pro at gmail.com Tue Jan 21 02:37:28 2014 From: free10pro at gmail.com (Paul R. Ramer) Date: Mon, 20 Jan 2014 17:37:28 -0800 Subject: Trouble reseting OpenPGP card after admin PIN lockout Message-ID: <52DDCF58.9040707@gmail.com> Hello, I am having trouble reseting an OpenPGP card on which I locked the admin PIN. Running gpg2 --card-status gives me the following error: gpg: OpenPGP card not available: Not supported When I try the instructions to reset the card from http://lists.gnupg.org/pipermail/gnupg-users/2013-March/046261.html, I get the following output: $ gpg-connect-agent > /hex > scd serialno ERR 100663405 Card reset required > scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 ERR 100663405 Card reset required > scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 ERR 100663405 Card reset required > scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 ERR 100663405 Card reset required > scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 ERR 100663405 Card reset required > scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 ERR 100663405 Card reset required > scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 ERR 100663405 Card reset required > scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 ERR 100663405 Card reset required > scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 ERR 100663405 Card reset required > scd apdu 00 44 00 00 ERR 100663405 Card reset required > scd apdu 00 e6 00 00 ERR 100663405 Card reset required My GnuPG version is 2.0.17. I have been searching around to find a solution to this, but I am at a loss thus far. Any help will be appreciated. Thanks. --Paul From chris.gilg at link-comm.com Tue Jan 21 04:31:02 2014 From: chris.gilg at link-comm.com (chris) Date: Tue, 21 Jan 2014 03:31:02 +0000 (UTC) Subject: GPGME trouble finding gpg executable. Message-ID: I have been attempting to use GPGME for a Qt app under Windows. I'm running into issues with two applications that use the same code finding the gpg executable. I set the engine info in both t-engine-info.c( exists in gpgme test directory ) and main.cpp ( exists in my Qt app directory ) applications using: gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP,"c:\\gnupg\\gpg.exe", "c:\\Users\\Chris\\AppData\\Roaming\\gnupg\\"); gpgme_check_version (NULL); err = gpgme_get_engine_info (&info); printf(" version = %s \n", info->version ); fail_if_err (err); The test app "t-engine-info" prints out " version = 1.4.9 ". My Qt app prints out " version = (null) ", The qt application throws a "GPGME: Invalid crypto engine" error on: err = gpgme_engine_check_version (GPGME_PROTOCOL_OpenPGP); fail_if_err (err); but the t-engine-info application does not. Why cannot it not find the executable in the my qt application but it can find the executable in the t-engine-info application? I've ran out of all possible ideas, and I am not sure what else I can try. Any tips or solutions would be great, as I really would like to use this in my app. From micha137 at gmx.de Tue Jan 21 10:45:20 2014 From: micha137 at gmx.de (Michael Anders) Date: Tue, 21 Jan 2014 10:45:20 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? Message-ID: <1390297520.4429.45.camel@micha137-myAMD-CM1740> >> Any way for two correspondents to set up gnupg within a few moments >> without having to become expert? >> >> The usual gnupg materials are very dense. > >Ask an "expert" to do the setup. After that usage is simple. In my opinion public license software is about empowering people. If you need an "expert" to install a software for you, the dependency on a software vendor is replaced by the dependency on an "expert", which might be even worse in some circumstances. Experts should also see their role in empowering people. Yes, there is a necessity to have good GUI based installers that don't need an experts assistance to get things right (and eventually change the insecure gpg defaults for that matter...) gpg4win works just fine.(So does Truecrypt or Academic Signature if you look at other crypto) The users must invest some minutes in understanding what asymmetric cryptography is about, however. That should be well within the scope of people with normal intelligence. Without that very basic understanding, using GnuPG(or other public key crypto) would be reckless nonsense anyways. Becoming a console wizard should definitely not be necessary. Regards Michael Anders From peter at digitalbrains.com Tue Jan 21 12:23:40 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 21 Jan 2014 12:23:40 +0100 Subject: Trouble reseting OpenPGP card after admin PIN lockout In-Reply-To: <52DDCF58.9040707@gmail.com> References: <52DDCF58.9040707@gmail.com> Message-ID: <52DE58BC.3020304@digitalbrains.com> TL;DR: I think you might be helped by [4]. Do an "scd killscd" from gpg-connect-agent, install and start pcscd, install the Python module pyscard and run the script from [4]. By the way, if you have an OpenPGP v.1 card, you're screwed, they self-destruct on 3 wrong Admin PINs. On 21/01/14 02:37, Paul R. Ramer wrote: > I am having trouble reseting an OpenPGP card on which I locked the admin > PIN. Since you already locked the PIN, the 8 commands that represent VERIFY attempts with a wrong PIN should no longer be needed. They are these commands: >> scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 For the normal PIN (to be overly exact, for doing a signature) >> scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 For the admin PIN >> scd apdu 00 44 00 00 > ERR 100663405 Card reset required This would normally be the first step of getting the card back to an unlocked, clean state. Note that an OpenPGP v1.1 card will self-destruct on 3 wrong admin PINs. If you have a v1.1 card, you're out of luck. However, a v2.0 card can be quite a bitch as well. I grabbed an unused v2.0 card to try to replicate your situation. I exhausted the Admin PINs, disconnected and reconnected the reader, and tried to re-initialise it. It wouldn't work. I accidentally lost the log of what I did, but it would respond to "TERMINATE DF" with the expected status 90 00, but "ACTIVATE FILE" would give an error in SW1-SW2. Then I also exhausted the regular PINs, thinking that maybe both need to be locked. No luck again. I interspersed all with the following APDU I constructed from the docs: scd apdu 00 ca 5f 52 00 Which gets the DO "Historical bytes" and looks like this for one of my v2.0 cards: D[0000] 00 31 C5 73 C0 01 40 05 90 00 90 00 The fourth-to-last byte, 05, indicates it is in "Operational state". At no point did the test card leave this state, even though after "TERMINATE DF" it should say 03 for "Initialisation state", IIUC. I changed the order of "TERMINATE DF" and "ACTIVATE FILE", and sometimes repeated one of those, but no matter what I tried, I could never get 90 00 for both commands, always only one of them. Then at some point, my card stopped working. I would get "Incorrect value" if I remember, euh... correctly. I got a bit worried at this point, and decided to kill scdaemon and gpg-agent to start with a clean slate. gpg-agent however is started by my X session, and killing it only made it . At this point I logged out, and lost my log of what I had done. Oops! There goes an exact and detailed transcript of how it went wrong. Aaarrrggh! Why didn't I set screen to log all to a file?! So now, the OpenPGP card would not select the OpenPGP application. A log of all APDU's, generated by scdaemon (debug 2048) is: -----------------8<--------------------->8----------------- 2014-01-21 10:51:00 scdaemon[9568] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6285 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 0C 07 D2 76 00 00 03 01 02 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=12 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 0C 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=08 p2=0C lc=2 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 08 0C 02 2F 00 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=01 p2=0C lc=2 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 01 0C 02 50 15 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=9 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 0C 09 D2 76 00 00 25 45 50 02 00 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=6 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 0C 06 D2 76 00 00 66 01 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] no supported card application found: Invalid value -----------------8<--------------------->8----------------- I tried to decode this. ISO 7816-4 is annoyingly expensive to buy, but you can find parts of it online. The first apdu "SELECT FILE" seems to request file control information, but P2=0C is not defined by [1]. The error response by the card is given, as "Wrong parameter(s) P1-P2" [2]. Hah, the card also doesn't understand P2, I think. On to the OpenPGP application. The second APDU is a "SELECT FILE" for the OpenPGP application, but unfortunately, the card returns 62 85. Again, not mentioned by [1] or [2]! It is of the class "State of non-volatile memory unchanged", but SW2=85 is not defined. But it is obviously different from the rest of the "SELECT FILE"s that follow, which aren't all that interesting because I think they refer to different cards that are also supported by scdaemon. The fact that selecting OpenPGP is different, is relevant, though. Oh, by the way, the ATR is normal. Perhaps I could get further with the full, real ISO 7816. But alas, I don't have it, and it's expensive. So I wrote all this, and then tried to find more about "TERMINATE DF". The reasoning is: normally we select the DF for OpenPGP, and then do a "TERMINATE DF", right? Selection errors out, so if we could parameterise "TERMINATE DF" to directly specify the OpenPGP DF, maybe that will work. At this point I came across this mailing list conversation: [3] and from that [4]. The script in [4] did the trick to bring back my card, and it differs from the scdaemon approach in that it doesn't error out when "SELECT FILE" doesn't work. What it does for me, is "SELECT FILE" OpenPGP, it errors with 62 85 just as with the author of the script, but then it nonetheless sends an "ACTIVATE FILE". Yes, at this point it seems that I was wrongly informed earlier, and that it is actually as follows: >> scd apdu 00 44 00 00 This is "ACTICATE FILE" >> scd apdu 00 e6 00 00 This is "TERMINATE DF" If I now, with this experience, read the descriptions of those in the OpenPGP card v2.0 spec, some more things become clear. "TERMINATE DF", INS=E6, will indeed somewhat terminate the OpenPGP application, in that it will, documented there, return 62 85 on a "SELECT FILE". Perhaps 62 85 is defined in ISO 7816-9, where "TERMINATE DF" is defined, a specification which I don't have either. However, it gets slightly annoying when scdaemon from then on will not talk to the card anymore because it returns said 62 85. The Python script will do the trick. That is, if I first do an "scd killscd" from gpg-connect-agent, then start pcscd, and also make sure I have the pyscard package installed for Python. At this point my card works again. A little while earlier in writing this mail, I thought "well that's the last time I experiment with resetting an OpenPGP card to help someone", but I suppose I'm good to go again :). I don't have to throw out my unused card after all. In fact, I did another test. As documented in the OpenPGP card spec, indeed both PIN counters need to be down to 0, not just the Admin one. And it seems the following is required to reset it: - Expire both PINs - scd apdu 00 e6 00 00 "TERMINATE DF". If at this point you reset your card, scdaemon will become useless because it will error out on selection of the OpenPGP DF. - scd apdu 00 44 00 00 "ACTIVATE FILE". Works from scdaemon when issued after "TERMINATE DF", otherwise, use the script in [4]. HTH, Peter. [1] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11 [2] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#chap5_4_5 [3] http://lists.gnupg.org/pipermail/gnupg-devel/2013-November/028058.html [4] http://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027518.html -- 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 Tue Jan 21 12:34:49 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 21 Jan 2014 12:34:49 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <1390297520.4429.45.camel@micha137-myAMD-CM1740> References: <1390297520.4429.45.camel@micha137-myAMD-CM1740> Message-ID: <52DE5B59.5040907@digitalbrains.com> On 21/01/14 10:45, Michael Anders wrote: > Yes, there is a necessity to have good GUI based installers that don't > need an experts assistance to get things right (and eventually change > the insecure gpg defaults for that matter...) You mean what you personally consider insecure defaults. Please let's not confuse people by stating opinions as facts. You're entitled to your opinion, though. 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 micha137 at gmx.de Tue Jan 21 14:03:07 2014 From: micha137 at gmx.de (Michael Anders) Date: Tue, 21 Jan 2014 14:03:07 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <52DE5B59.5040907@digitalbrains.com> References: <1390297520.4429.45.camel@micha137-myAMD-CM1740> <52DE5B59.5040907@digitalbrains.com> Message-ID: <1390309387.24382.5.camel@micha137-myAMD-CM1740> > You mean what you personally consider insecure defaults. Please let's not > confuse people by stating opinions as facts. You're entitled to your opinion, > though. > > HTH, > > Peter. > My opinion is that SHA1 should no longer be used. A link on SHA1 security: https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html regards, Michael Anders From micha137 at gmx.de Tue Jan 21 16:06:36 2014 From: micha137 at gmx.de (Michael Anders) Date: Tue, 21 Jan 2014 16:06:36 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <20140121141953.429a46d0@steves-laptop> References: <1390297520.4429.45.camel@micha137-myAMD-CM1740> <52DE5B59.5040907@digitalbrains.com> <1390309387.24382.5.camel@micha137-myAMD-CM1740> <20140121141953.429a46d0@steves-laptop> Message-ID: <1390316796.24382.20.camel@micha137-myAMD-CM1740> On Tue, 2014-01-21 at 14:19 +0000, Steve Jones wrote: > How do I prevent gnupg from using SHA1? Also how do I update my key to not use SHA1 digests which it appears to be using, as well as listing SHA1 as my second favourite algorithm. > I found a description in the web( http://sparkslinux.wordpress.com/2013/02/21/hashing-algorithm-is-your-gpg-configuration-secure/) that told me to do the following: You locate the file "gpg.conf" On my ubuntu it is in the directory ~/.gnupg/ In this file you can add the three lines at the bottom personal-cipher-preferences AES256 TWOFISH AES192 AES personal-digest-preferences SHA512 SHA384 SHA256 personal-compress-preferences ZLIB BZIP2 ZIP to set the preferences. GnuPG is supposed to pick the leftmost possible in the respective lists. But backup before editing! I remember some recent posts on problems editing GnuPG config files and tranferring to and fro windows and linux. There seems to be a danger to mess up things using wrong editor settings. I don't know if hash preference information is additionally attached to keys. I would guess it is not, it wouldn't make sense to me. regards, Michael Anders From steve at secretvolcanobase.org Tue Jan 21 15:19:53 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Tue, 21 Jan 2014 14:19:53 +0000 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <1390309387.24382.5.camel@micha137-myAMD-CM1740> References: <1390297520.4429.45.camel@micha137-myAMD-CM1740> <52DE5B59.5040907@digitalbrains.com> <1390309387.24382.5.camel@micha137-myAMD-CM1740> Message-ID: <20140121141953.429a46d0@steves-laptop> On Tue, 21 Jan 2014 14:03:07 +0100 Michael Anders wrote: > My opinion is that SHA1 should no longer be used. > > A link on SHA1 security: > > https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html How do I prevent gnupg from using SHA1? Also how do I update my key to not use SHA1 digests which it appears to be using, as well as listing SHA1 as my second favourite algorithm. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From mailinglisten at hauke-laging.de Tue Jan 21 17:30:07 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 21 Jan 2014 17:30:07 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <1390316796.24382.20.camel@micha137-myAMD-CM1740> References: <1390297520.4429.45.camel@micha137-myAMD-CM1740> <20140121141953.429a46d0@steves-laptop> <1390316796.24382.20.camel@micha137-myAMD-CM1740> Message-ID: <4636178.L3xY1sMNRx@inno.berlin.laging.de> Am Di 21.01.2014, 16:06:36 schrieb Michael Anders: > I don't know if hash preference information is additionally attached > to keys. I would guess it is not, it wouldn't make sense to me. Unfortunately that's not a reliable guide. http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html --default-preference-list 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 pete at heypete.com Tue Jan 21 17:39:13 2014 From: pete at heypete.com (Pete Stephenson) Date: Tue, 21 Jan 2014 17:39:13 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <4636178.L3xY1sMNRx@inno.berlin.laging.de> References: <1390297520.4429.45.camel@micha137-myAMD-CM1740> <20140121141953.429a46d0@steves-laptop> <1390316796.24382.20.camel@micha137-myAMD-CM1740> <4636178.L3xY1sMNRx@inno.berlin.laging.de> Message-ID: On Jan 21, 2014 5:32 PM, "Hauke Laging" wrote: > > Am Di 21.01.2014, 16:06:36 schrieb Michael Anders: > > > I don't know if hash preference information is additionally attached > > to keys. I would guess it is not, it wouldn't make sense to me. > > Unfortunately that's not a reliable guide. > > http://www.gnupg.org/documentation/manuals/gnupg-devel/GPG-Esoteric-Options.html > > --default-preference-list I've found http://www.debian-administration.org/users/dkg/weblog/48 to be a reasonably sensible guide for setting stronger preferences. I also added Twofish and Blowfish after AES256 and AES, respectively. I've not heard of any issues with that setup, but your mileage may vary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at b19.org Tue Jan 21 18:28:30 2014 From: ryan at b19.org (Ryan Sawhill) Date: Tue, 21 Jan 2014 12:28:30 -0500 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: <52DC4821.5000003@eugeneweb.com> References: <52D99D86.3090003@eugeneweb.com> <52DB75C9.7060801@eugeneweb.com> <52DBBCD3.8080705@vulcan.xs4all.nl> <52DC03A3.2040600@eugeneweb.com> <52DC4245.1030802@dougbarton.us> <52DC4821.5000003@eugeneweb.com> Message-ID: As already mentioned, you could decrypt the file to a ram disk -- the /dev/shm directory should already be there, but if you're trying to bypass creating an unnecessary file altogether, you need something else. I actually wrote a GUI frontend for this purpose (among others) a while back. It's called pyrite and available at: https://github.com/ryran/pyrite It's extremely versatile and can do everything but manage keys -- basically you can do any kind of signing & verifying with or without any kind of encryption/decryption (including symmetric). Your workflow with it could look like this: 1.) Run pyrite /path/to/encrypted/file [GUI opens up with text-input populated by encrypted text] 2.) Decrypt text [Cipher-text is replaced with decrypted version; never saved to disk] 3.) Make your edits/changes 4.) Re-encrypt 5.) Click save-to-disk button On Sun, Jan 19, 2014 at 4:48 PM, Mr. Clif wrote: > Hi Doug, > > Thanks for the comments. Yes the threat model is mostly the worry of having > old temp files or even the original cleartext files left behind on the HD, > or even worse having them backed up. ;-) At the very least I want something > that tries to protect me from stupid mistakes. Yep the RAM disk idea was > part of the solution I'm heading towards. > > So do you or does anyone know of a nice front end that helps with that? An > example of behavior that doesn't seem helpful is that when I use GPA to > decrypt a file it defaults to saving it on the HD. I'm not trying to knock > GPA here but wouldn't it be better to display the contents in a window? Well > I realize that might be just what I want, and others have use cases that it > works fine for. ;-) > > Clif > > > On 01/19/2014 01:23 PM, Doug Barton wrote: >> >> On 01/19/2014 08:56 AM, Mr. Clif wrote: >>> >>> So I'm trying to get a sense from the users here if they feel that the >>> process of using gpg for symmetric encryption is safe enough, and they >>> are not worried about leaving clear text behind. >> >> >> I think you're misunderstanding a few things. First, the problem of the >> plain text file is not exclusive to symmetric encryption. In fact there is >> no difference between that, and the plain text file that's left behind after >> public key encryption. >> >> Second, you haven't defined your threat model. You have given us a vague >> sense of wanting to have a "secure" system, but you haven't said what you're >> trying to secure it against. Thus it's hard to respond intelligently to your >> query. >> >> That said, I would suggest that you consider using a RAM disk to do your >> work on. It can be created to do the work, then deleted after you're done, >> with no risk of leaving a file behind on disk. Of course you'd want to make >> sure your RAM disk was not swap-backed. >> >> hope this helps, >> >> Doug >> > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From steve at secretvolcanobase.org Tue Jan 21 20:14:10 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Tue, 21 Jan 2014 19:14:10 +0000 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: References: <1390297520.4429.45.camel@micha137-myAMD-CM1740> <20140121141953.429a46d0@steves-laptop> <1390316796.24382.20.camel@micha137-myAMD-CM1740> <4636178.L3xY1sMNRx@inno.berlin.laging.de> Message-ID: <20140121191410.6794ab28@steves-laptop> On Tue, 21 Jan 2014 17:39:13 +0100 Pete Stephenson wrote: > I've found http://www.debian-administration.org/users/dkg/weblog/48 to be a > reasonably sensible guide for setting stronger preferences. I also added > Twofish and Blowfish after AES256 and AES, respectively. > > I've not heard of any issues with that setup, but your mileage may vary. Thanks, that was quite helpful. I've found I can just delete the self signatures on my UID and replace them with better ones but I can't see a way to change the subkey binding signature. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From arne.renkema-padmos at cased.de Tue Jan 21 16:40:48 2014 From: arne.renkema-padmos at cased.de (arne renkema-padmos) Date: Tue, 21 Jan 2014 16:40:48 +0100 Subject: Any way for two correspondents to set up gnupg within a few moments without having to become expert? In-Reply-To: <1390309387.24382.5.camel@micha137-myAMD-CM1740> References: <1390297520.4429.45.camel@micha137-myAMD-CM1740> <52DE5B59.5040907@digitalbrains.com> <1390309387.24382.5.camel@micha137-myAMD-CM1740> Message-ID: <52DE9500.8000608@cased.de> On 21/01/14 14:03, Michael Anders wrote: > >> You mean what you personally consider insecure defaults. Please let's not >> confuse people by stating opinions as facts. You're entitled to your opinion, >> though. >> >> HTH, >> >> Peter. >> > > My opinion is that SHA1 should no longer be used. Of course in the best of worlds it shouldn't be used anymore. But if everyone started signing their emails with SHA1 I couldn't be more pleased, because then you at least have the infrastructure in place, and can upgrade people later. The major problem we're facing is that we can't even get most people to use MD5 or DES. Heck, they don't even know who or what they are, and to be frank they shouldn't have to. Cheers, arne -- Arne Renkema-Padmos @hcisec, secuso.org Doctoral researcher CASED, TU Darmstadt From stefanxe at gmx.net Tue Jan 21 19:25:37 2014 From: stefanxe at gmx.net (Stefan Xenon) Date: Tue, 21 Jan 2014 19:25:37 +0100 Subject: using an OpenPGP card with Java (keytool and jarsigner) In-Reply-To: <52CD6E14.5010803@guardianproject.info> References: <52CC100D.9080303@guardianproject.info> <87txdebs0l.fsf@vigenere.g10code.de> <52CD6E14.5010803@guardianproject.info> Message-ID: <52DEBBA1.7050806@gmx.net> Am 08.01.2014 16:26, schrieb Hans-Christoph Steiner: > > > On 01/08/2014 07:02 AM, Werner Koch wrote: >> On Tue, 7 Jan 2014 15:32, hans at guardianproject.info said: >> >>> OpenPGP card as a PKCS11 keystore. It seems that things are close: Java can >>> use NSS as a provider of PKCS11. I guess the question is whether opensc is >>> making a PKCS#11 interface to the OpenPGP card, that's the bit that I don't >> >> Scute also provides an pkcs#11 interface to NSS. Thus you should be >> able to use it also with Java. > > I haven't tried scute, but it seems that opensc v0.13 provides a PKCS#11 > interface to the OpenPGP card. I am able to get keytool to report the > certificate in key position #3, but the question I have now is that given that > key #3 is for authentication, is there some restriction in the OpenPGP card > that would prevent the certificate/key combo in position #3 from being used > for signing? > > I did read about using opensc with an OpenPGP card to provide S/MIME services. > What I read there is that in order to use the certificate/key combo in > position #3 for decrypting emails, the key in position #2 (decryption) must > match the key in position number #3. Is there a similar restriction for signing? There is no restriction for Signing Key (first slot in OpenPGP card). For me Scute never worked successfully. I would recommend using OpenSC instead which is maintained actively. Best regards, Stefan > I forget if I mentioned this, but the grand goal is to have a single hardware > security module that can sign the Android APK using jarsigner, then make a > OpenPGP signature on the APK, then optionally provide authentication for > scp'ing the resulting files to the release server. > > .hc > From rahul.raviz at gmail.com Wed Jan 22 08:59:11 2014 From: rahul.raviz at gmail.com (Rahul R) Date: Wed, 22 Jan 2014 13:29:11 +0530 Subject: Usage of --symmetric Message-ID: Hi all, I am trying to run "gpg --symmetric test.txt" But its asking for Passphrase. Is there any way to skip this while running this command? -- Thanks, Regards, Rahul R .~. /V\ // \\ /( )\ ^`~'^ Mob: 09008030921 -------------- next part -------------- An HTML attachment was scrubbed... URL: From free10pro at gmail.com Wed Jan 22 10:59:37 2014 From: free10pro at gmail.com (Paul R. Ramer) Date: Wed, 22 Jan 2014 01:59:37 -0800 Subject: Trouble reseting OpenPGP card after admin PIN lockout In-Reply-To: <52DE58BC.3020304@digitalbrains.com> References: <52DDCF58.9040707@gmail.com> <52DE58BC.3020304@digitalbrains.com> Message-ID: <52DF9689.6020908@gmail.com> On 01/21/2014 03:23 AM, Peter Lebbing wrote: > TL;DR: I think you might be helped by [4]. Do an "scd killscd" from > gpg-connect-agent, install and start pcscd, install the Python module pyscard > and run the script from [4]. By the way, if you have an OpenPGP v.1 card, you're > screwed, they self-destruct on 3 wrong Admin PINs. I followed your instructions and they worked. Thank you very much. Thanks for doing all of the testing and research. I am sure that it will be of good use for others as well if they encounter this problem. > Note that an OpenPGP v1.1 card will self-destruct on 3 wrong admin PINs. If you > have a v1.1 card, you're out of luck. > > However, a v2.0 card can be quite a bitch as well. [...] Uh, yes. Well, this started out as testing to see if reseting the card after exhausting the 3 tries on the Admin PIN would be straight forward. I guess the old saying, "Be careful what you wish for," would apply here. I knew that the v1.1 card would be fried in this case, so armed with the knowledge that a v2.0 card could be reset I set out to test it. All the time I was thinking, "This should be easy." :-) > Then at some point, my card stopped working. I would get "Incorrect value" if I > remember, euh... correctly. I got a bit worried at this point, and decided to > kill scdaemon and gpg-agent to start with a clean slate. gpg-agent however is > started by my X session, and killing it only made it . At this point I > logged out, and lost my log of what I had done. Oops! There goes an exact and > detailed transcript of how it went wrong. Aaarrrggh! Why didn't I set screen to > log all to a file?! Our brains always seem to know the best course of action after the opportunity for it has passed. :-) > At this point my card works again. A little while earlier in writing this mail, > I thought "well that's the last time I experiment with resetting an OpenPGP card > to help someone", but I suppose I'm good to go again :). I don't have to throw > out my unused card after all. I have been there before with other hardware and software problems. But despite every time that I determined that I was finished with "X" software or hardware, I would later pick it up again and eventually figure it out. Cheers, --Paul -- PGP: 0x3DB6D884 From fa-ml at ariis.it Wed Jan 22 12:37:34 2014 From: fa-ml at ariis.it (fa-ml) Date: Wed, 22 Jan 2014 12:37:34 +0100 Subject: Usage of --symmetric In-Reply-To: References: Message-ID: <20140122113734.GA6771@efikamx> On Wed, Jan 22, 2014 at 01:29:11PM +0530, Rahul R wrote: > Hi all, > > I am trying to run > > "gpg --symmetric test.txt" > > But its asking for Passphrase. Is there any way to skip this while running > this command? gpg --symmetric -o output.pgp --passphrase mypasshere input.txt (found checking `man gpg`). Of course there are problems with this approach (using --passphrase-fd and --passphrase-file makes things only marginally safer). Encryption via public-key requires no password at all, so maybe you are better off switching to it, depending on your use case. From pete at heypete.com Wed Jan 22 11:17:28 2014 From: pete at heypete.com (Pete Stephenson) Date: Wed, 22 Jan 2014 11:17:28 +0100 Subject: Usage of --symmetric In-Reply-To: References: Message-ID: On Wed, Jan 22, 2014 at 8:59 AM, Rahul R wrote: > Hi all, > > I am trying to run > > "gpg --symmetric test.txt" > > But its asking for Passphrase. Is there any way to skip this while running > this command? No. When you symmetrically encrypt something you need to specify the passphrase that is used as a key to encrypt and decrypt that file. -- Pete Stephenson From pete at heypete.com Wed Jan 22 13:52:09 2014 From: pete at heypete.com (Pete Stephenson) Date: Wed, 22 Jan 2014 13:52:09 +0100 Subject: Spam sent in response to GnuPG-users messages? Message-ID: Hi folks, It appears that there's a spammer who has subscribed to the mailing list and is sending out "cute girl wants to chat" spam in response to messages sent to the list. They're not sending mail to the list itself, but rather to the individual sender addresses that have sent messages to the list. Has anyone else received similar messages? Is there some way of identifying the "trigger" address that's subscribed to the list and results in these messages being generated? I'd be happy to supply the spammy messages in question (off-list, of course) if that would help identify the offending spammer. Cheers! -Pete -- Pete Stephenson From mailinglisten at hauke-laging.de Wed Jan 22 13:58:12 2014 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 22 Jan 2014 13:58:12 +0100 Subject: Spam sent in response to GnuPG-users messages? In-Reply-To: References: Message-ID: <1770723.AZK0N5qj2H@inno.berlin.laging.de> Am Mi 22.01.2014, 13:52:09 schrieb Pete Stephenson: > They're not sending mail to the list itself, Once, accidentally maybe: http://lists.gnupg.org/pipermail/gnupg-users/2014-January/048800.html -- 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 Jan 22 14:06:34 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 22 Jan 2014 14:06:34 +0100 Subject: (OT) ISO 7816 communications defined In-Reply-To: <52DE58BC.3020304@digitalbrains.com> References: <52DDCF58.9040707@gmail.com> <52DE58BC.3020304@digitalbrains.com> Message-ID: <52DFC25A.3010406@digitalbrains.com> On 21/01/14 12:23, Peter Lebbing wrote: > I tried to decode this. ISO 7816-4 is annoyingly expensive to buy However, I just found out that, being registered as a student at the TU Delft, I can get them for free! \o/ The master I'm doing gives me a registration at multiple universities, and even though I'm studying at the University of Twente, I can still use the facilities of two other universities. > The first apdu "SELECT FILE" seems to request file control information, but > P2=0C is not defined by [1]. The error response by the card is given, as > "Wrong parameter(s) P1-P2" [2]. Hah, the card also doesn't understand P2, I > think. The current ISO 7816-4 defines this first SELECT as "Select MF, DF or EF" identified by the identifier "02 3F" which I could not find. P2 in combination with Le is defined in the current spec, as "No response data". > On to the OpenPGP application. The second APDU is a "SELECT FILE" for the > OpenPGP application, but unfortunately, the card returns 62 85. Which is defined in ISO 7816-9 as "Selected file in termination state", the proper response for a DF that has been terminated with "TERMINATE DF". It seems to me that "DEACTIVATE FILE" would have been more appropriate for the OpenPGP card than "TERMINATE DF", as ISO 7816 defines the latter as a permanent, irreversable action AFAICT. > So I wrote all this, and then tried to find more about "TERMINATE DF". The > reasoning is: normally we select the DF for OpenPGP, and then do a > "TERMINATE DF", right? Selection errors out, so if we could parameterise > "TERMINATE DF" to directly specify the OpenPGP DF, maybe that will work. This parameterisation would in fact be possible under ISO 7816-9, by the way. It would be: scd apdu 00 e6 04 00 06 d2 76 00 01 24 01 Although because of the mixup between "TERMINATE DF" and "ACTIVATE FILE", I think it would be more useful to directly give the DF to "ACTIVATE FILE", which would be: scd apdu 00 44 04 00 06 d2 76 00 01 24 01 Neither command is accepted by the OpenPGP card, though. It only implements the implicitly referenced form where you first "SELECT FILE". Unless I'm making mistakes, obviously. Well, that's it. My curiosity has been satisfied :). 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 clif at eugeneweb.com Wed Jan 22 17:16:27 2014 From: clif at eugeneweb.com (Mr. Clif) Date: Wed, 22 Jan 2014 08:16:27 -0800 Subject: Looking for simple wrapper for symmetric key file encryption In-Reply-To: References: <52D99D86.3090003@eugeneweb.com> <52DB75C9.7060801@eugeneweb.com> <52DBBCD3.8080705@vulcan.xs4all.nl> <52DC03A3.2040600@eugeneweb.com> <52DC4245.1030802@dougbarton.us> <52DC4821.5000003@eugeneweb.com> Message-ID: <52DFEEDB.6060007@eugeneweb.com> Hi Ryan, Yes that is exactly the kind of front end I was looking for, and it looks very nice. Thanks for writing it. :-) Though now I have finished the stab I took at solving the problem myself, which is a much simpler command line script. You can find the two versions of it here: https://www.eugenemakerspace.com/wiki/Sites/Cryptsym If folks have the time, I would appreciate any feed back on how they like it. Ciao! Clif On 01/21/2014 09:28 AM, Ryan Sawhill wrote: > As already mentioned, you could decrypt the file to a ram disk -- the > /dev/shm directory should already be there, but if you're trying to > bypass creating an unnecessary file altogether, you need something > else. > > I actually wrote a GUI frontend for this purpose (among others) a > while back. It's called pyrite and available at: > https://github.com/ryran/pyrite > > It's extremely versatile and can do everything but manage keys -- > basically you can do any kind of signing & verifying with or without > any kind of encryption/decryption (including symmetric). > > Your workflow with it could look like this: > > 1.) Run pyrite /path/to/encrypted/file > [GUI opens up with text-input populated by encrypted text] > > 2.) Decrypt text > [Cipher-text is replaced with decrypted version; never saved to disk] > > 3.) Make your edits/changes > > 4.) Re-encrypt > > 5.) Click save-to-disk button > > > On Sun, Jan 19, 2014 at 4:48 PM, Mr. Clif wrote: >> Hi Doug, >> >> Thanks for the comments. Yes the threat model is mostly the worry of having >> old temp files or even the original cleartext files left behind on the HD, >> or even worse having them backed up. ;-) At the very least I want something >> that tries to protect me from stupid mistakes. Yep the RAM disk idea was >> part of the solution I'm heading towards. >> >> So do you or does anyone know of a nice front end that helps with that? An >> example of behavior that doesn't seem helpful is that when I use GPA to >> decrypt a file it defaults to saving it on the HD. I'm not trying to knock >> GPA here but wouldn't it be better to display the contents in a window? Well >> I realize that might be just what I want, and others have use cases that it >> works fine for. ;-) >> >> Clif >> >> >> On 01/19/2014 01:23 PM, Doug Barton wrote: >>> On 01/19/2014 08:56 AM, Mr. Clif wrote: >>>> So I'm trying to get a sense from the users here if they feel that the >>>> process of using gpg for symmetric encryption is safe enough, and they >>>> are not worried about leaving clear text behind. >>> >>> I think you're misunderstanding a few things. First, the problem of the >>> plain text file is not exclusive to symmetric encryption. In fact there is >>> no difference between that, and the plain text file that's left behind after >>> public key encryption. >>> >>> Second, you haven't defined your threat model. You have given us a vague >>> sense of wanting to have a "secure" system, but you haven't said what you're >>> trying to secure it against. Thus it's hard to respond intelligently to your >>> query. >>> >>> That said, I would suggest that you consider using a RAM disk to do your >>> work on. It can be created to do the work, then deleted after you're done, >>> with no risk of leaving a file behind on disk. Of course you'd want to make >>> sure your RAM disk was not swap-backed. >>> >>> hope this helps, >>> >>> Doug >>> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users From oub at mat.ucm.es Thu Jan 23 15:34:17 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Thu, 23 Jan 2014 15:34:17 +0100 Subject: time delay unlock private key. Message-ID: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> Hello A Long time ago, IBM's proprietary OS, called CMS had a particular feature for the login: It gave you three attempts to login in. If you failed there was a time delay of 20 min, if you failed again, the time delay was prolonged to one hour, and then I think to one day. My private pgp and smime keys are secured by a password, but there is no time delay, which makes a brute force attack possible. Could a time delay be implemented similar to the one I just mentioned? regards Uwe Brauer From johannes at zarl.at Thu Jan 23 15:58:04 2014 From: johannes at zarl.at (Johannes Zarl) Date: Thu, 23 Jan 2014 15:58:04 +0100 Subject: time delay unlock private key. In-Reply-To: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> Message-ID: <1412391.8dJ22iTy69@mani> On Thursday 23 January 2014 15:34:17 Uwe Brauer wrote: > A Long time ago, IBM's proprietary OS, called CMS had a particular > feature for the login: > > It gave you three attempts to login in. If you failed there was a time > delay of 20 min, if you failed again, the time delay was prolonged to > one hour, and then I think to one day. The same feature is implemented in some form in many/most contemporary login systems as well, and it makes great sense for a login system. The main reason this makes sense is that as a regular user you can't just bypass the login screen and get direct access to the hashed password value. > My private pgp and smime keys are secured by a password, but there is no > time delay, which makes a brute force attack possible. > > Could a time delay be implemented similar to the one I just mentioned? In contrast to the login screen example, a delay implemented by gnupg won't help you in this case. Once an attacker has access to your private key, he or she can try a brute-force attack against the passphrase using a patched version of gnupg that does not implement the delay. So in short: - a delay won't help you - protect your private key so this won't happen - always use a strong passphrase Cheers, Johannes From dkg at fifthhorseman.net Thu Jan 23 16:01:23 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 Jan 2014 10:01:23 -0500 Subject: time delay unlock private key. In-Reply-To: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> Message-ID: <52E12EC3.5040402@fifthhorseman.net> On 01/23/2014 09:34 AM, Uwe Brauer wrote: > Hello > > A Long time ago, IBM's proprietary OS, called CMS had a particular > feature for the login: > > It gave you three attempts to login in. If you failed there was a time > delay of 20 min, if you failed again, the time delay was prolonged to > one hour, and then I think to one day. > > My private pgp and smime keys are secured by a password, but there is no > time delay, which makes a brute force attack possible. > > Could a time delay be implemented similar to the one I just mentioned? Nope; the IBM system was an active system; the GnuPG private keyring is an on-disk data format. If the gnupg executable (which is an active system) were to implement its own timeout/falloff, anyone who wanted to crack the file in question would just recompile their own gnupg without that timeout/falloff, so it wouldn't be an effective countermeasure against an attacker. However, you can make each single attempt significantly more expensive by playing with the s2k-count argument (assuming a reasonable choice for s2k-mode and s2k-digest-algo and s2k-cipher-algo). See the manual page notes about those options for more details, and the specification's string-to-key section for a description of what those arguments do to the underlying data: https://tools.ietf.org/html/rfc4880#section-3.7 Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jan 23 16:00:55 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Jan 2014 16:00:55 +0100 Subject: time delay unlock private key. In-Reply-To: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> (Uwe Brauer's message of "Thu, 23 Jan 2014 15:34:17 +0100") References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> Message-ID: <87bnz2d9p4.fsf@vigenere.g10code.de> On Thu, 23 Jan 2014 15:34, oub at mat.ucm.es said: > It gave you three attempts to login in. If you failed there was a time > delay of 20 min, if you failed again, the time delay was prolonged to > one hour, and then I think to one day. IIRC, each CMS users gets his own VM and minidisk. Thus what you mean is the regular login protection most OSes provide. For Unix you configure this in /etc/login.defs. However, GnuPG is a user process and the agent as well as the keys are under the full control of the user. Thus the OS is not able to handle this like the login. After all, why should it. If you are logged in you may do anything with your data - why restrict it. > My private pgp and smime keys are secured by a password, but there is no > time delay, which makes a brute force attack possible. What is your threat model? Users who are able to access gpg/gpg-agent but are not able to read secring.gpg or private-keys-v1.d? Well, it is possible to do this with SELinux and then such a feature might make sense. However, there is a plethora of other things you need to secure first. In any case if an attacker has access to your machine or at least to your account, you already reached game over state. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jan 23 17:27:24 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Jan 2014 17:27:24 +0100 Subject: BoF at FOSDEM ? Message-ID: <87txcubr4j.fsf@vigenere.g10code.de> Hi! is anyone interested in a BoF at FOSDEM on February 1 or 2? Anything special to put on the agenda? How long should we plan 30, 45 or 60 minutes? I plan to arrive on Saturday by noon which might be a bit too late to sign up for a slot. Thus if there is interest in holding a BoF, I would ask someone else to walk over to info desk at the H-Building and sign up for a slot on Saturday afternoon or Sunday. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Thu Jan 23 18:38:32 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 23 Jan 2014 18:38:32 +0100 Subject: BoF at FOSDEM ? In-Reply-To: <87txcubr4j.fsf@vigenere.g10code.de> References: <87txcubr4j.fsf@vigenere.g10code.de> Message-ID: <52E15398.4060404@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/23/2014 05:27 PM, Werner Koch wrote: > Hi! Hi Werner, > > is anyone interested in a BoF at FOSDEM on February 1 or 2? > Anything special to put on the agenda? How long should we plan 30, > 45 or 60 minutes? I'd be interested in a BoF at the event. I don't have anything special to put on the agenda, but I can probably contribute most about the further development of the keyserver pools and SKS myself. > > I plan to arrive on Saturday by noon which might be a bit too late > to sign up for a slot. Thus if there is interest in holding a BoF, > I would ask someone else to walk over to info desk at the > H-Building and sign up for a slot on Saturday afternoon or Sunday. I'll be arriving on friday evening, so I could do this on saturday morning. - -- - ---------------------------- 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 - ---------------------------- Primum ego, tum ego, deinde ego First I, then I, thereafter I. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS4VOUAAoJEPw7F94F4TagDJ0P/iAKnDsX/5zi2kJnxza8fXb8 eGdwDPPEfDjk6Zl74X7rBhYFQrK10d4VYYjnSmoWxvEX1AsEVav6lgs2pq5y+Qzf cR5v4azA0LN013ZKqyn1FX1F07NSJE54rXHvgcVFX8LmU2Z+SHCRcbq5BdouVrz1 Rb80D8AJt5yt5uvpxNYtSa8kko1Y2Qes7HTXIDNxvPpZbC+vK50itGD3yiudmLta dcaYunmTIiN7n9tQIK/NXtL2FP+ctf9O77s5JthNSHqU05s6m34Eh4xVPpIa/TL8 eHzQuqYa3SfguuhXPy6eDnvEN3F5IHO2kyZutevJfCN7qdiE+rhGNBYt7mRJL2C+ rEk5HjF6kXnkZyWhLl0XMbXwwmFNOEY4ehHXTjXb7Cteb/ORJKXtfr6oIwLTrCOJ GfA6/iWFs4K4YhdVmWUBgkHK1yNrtOr0KHj4DqiwAHekhU2Nddd36zLejZam+ad6 EDECwXNSXHCJK2wF2glr/k9q2UFcuH75j9dHb5CUSucNb6/MQp3ATEnqtY6A9uP2 2Ps9g4Wre1FMFXNQ08ZxxNq+L7+xsYIWVzq0IPEd96fuMPqLZU+3oJPFQvTSvOtW 8t8IWnfYqBijc3gsgzv/a21PAgy4oQ9GxqtZvaQoSYmUtyRN5zMkEZXXSZvEqlmn xvjwZQSDnm4Zx64kC4GU =e/eo -----END PGP SIGNATURE----- From nb.linux at xandea.de Thu Jan 23 18:53:57 2014 From: nb.linux at xandea.de (nb.linux) Date: Thu, 23 Jan 2014 17:53:57 +0000 Subject: time delay unlock private key. In-Reply-To: <1412391.8dJ22iTy69@mani> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> Message-ID: <52E15735.8080205@xandea.de> Hi Uwe, Johannes Zarl: > So in short: > - a delay won't help you > - protect your private key so this won't happen > - always use a strong passphrase and in addition: if you fear (or know) that your secret key was copied from your system, revoke it! To me, this is a very important feature of OpenPGP: _you_ can actually do something to reduce (not more, but also not less!) harm for yourself and others. And, you can be prepared for such an event (i.e. having created the revocation certificates in advance, stored them in a save but accessible place, printed out on paper,...). Cheers, -- nb.linux From rjh at sixdemonbag.org Thu Jan 23 19:20:32 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Jan 2014 10:20:32 -0800 Subject: time delay unlock private key. In-Reply-To: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> Message-ID: <20140123102032.Horde.AH1D1Vo4ncRZKQedmdqLxQ9@mail.sixdemonbag.org> > My private pgp and smime keys are secured by a password, but there is no > time delay, which makes a brute force attack possible. GnuPG doesn't make a brute force attack possible. You make a brute-force attack possible by choosing a weak passphrase. Choose a strong one. It's really that simple. > Could a time delay be implemented similar to the one I just mentioned? Not really, although DKG gave you a good heads-up about the number of iterations in s2k. From wk at gnupg.org Thu Jan 23 20:51:06 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Jan 2014 20:51:06 +0100 Subject: time delay unlock private key. In-Reply-To: <20140123102032.Horde.AH1D1Vo4ncRZKQedmdqLxQ9@mail.sixdemonbag.org> (Robert J. Hansen's message of "Thu, 23 Jan 2014 10:20:32 -0800") References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <20140123102032.Horde.AH1D1Vo4ncRZKQedmdqLxQ9@mail.sixdemonbag.org> Message-ID: <87wqhqa34l.fsf@vigenere.g10code.de> On Thu, 23 Jan 2014 19:20, rjh at sixdemonbag.org said: > Not really, although DKG gave you a good heads-up about the number of > iterations in s2k. FWIW: With GnuPG 2.x the default iteration count is calibrated to an iteration time of 100ms. That is of course machine dependent. To view that count you may run gpg-connect-agent as in this example: $ gpg-connect-agent 'getinfo s2k_count' /bye D 16777216 OK Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ekleog at gmail.com Thu Jan 23 21:25:26 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 23 Jan 2014 21:25:26 +0100 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <52E15735.8080205@xandea.de> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> Message-ID: <20140123202525.GA10540@leortable> On Thu, Jan 23, 2014 at 05:53:57PM +0000, nb.linux wrote: > Hi Uwe, > > Johannes Zarl: > > So in short: > > - a delay won't help you > > - protect your private key so this won't happen > > - always use a strong passphrase > and in addition: if you fear (or know) that your secret key was copied > from your system, revoke it! > To me, this is a very important feature of OpenPGP: _you_ can actually > do something to reduce (not more, but also not less!) harm for yourself > and others. > And, you can be prepared for such an event (i.e. having created the > revocation certificates in advance, stored them in a save but accessible > place, printed out on paper,...). Actually, this is something I never understood. Why should people create a revocation certificate and store it in a safe place, instead of backing up the main key? So long as the primary key is encrypted and the passphrase is strong, this should not lead to any security danger. (Anyway, it's stored in a "safe" place. And a revocation certificate misused is dangerous too, as it ruins a web of trust.) And the advantages of doing so are that in case or accidental erasing of the private key (who never accidentally deleted an important file?), it also allows the main key to be retrieved. The primary key allows one to create a revocation certificate, not the other way around. So, why store a safe revocation certificate? Leo PS: Please, do not tell me one might have forgotten his passphrase. In this case there is no harm in shredding the secret key and waiting for the expiration date, answering persons emailing you encrypted files that you lost your passphrase. Anyway, in this case, you're screwed, and a revocation certificate would be no better -- unless it was stored unencrypted, at the risk of having it used when you do not want it to be. From pete at heypete.com Thu Jan 23 21:59:30 2014 From: pete at heypete.com (Pete Stephenson) Date: Thu, 23 Jan 2014 21:59:30 +0100 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <20140123202525.GA10540@leortable> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> Message-ID: On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard wrote: > On Thu, Jan 23, 2014 at 05:53:57PM +0000, nb.linux wrote: >> And, you can be prepared for such an event (i.e. having created the >> revocation certificates in advance, stored them in a save but accessible >> place, printed out on paper,...). > > Actually, this is something I never understood. Why should people create a > revocation certificate and store it in a safe place, instead of backing up the > main key? It's a sensible thing to do both, of course. > So long as the primary key is encrypted and the passphrase is strong, this > should not lead to any security danger. (Anyway, it's stored in a "safe" place. > And a revocation certificate misused is dangerous too, as it ruins a web of > trust.) > > And the advantages of doing so are that in case or accidental erasing of the > private key (who never accidentally deleted an important file?), it also allows > the main key to be retrieved. > > The primary key allows one to create a revocation certificate, not the other way > around. So, why store a safe revocation certificate? The most damage that a misused revocation certificate can do is revoking one's certificate. This is a bit of a pain, in that one would need to create a new keypair, get it signed, etc., but it wouldn't result in the compromise of sensitive information, messages, etc. Misuse of a revocation certificate is a minor denial-of-service, but not a complete break of security. For example, one could easily give a trusted friend or family member a copy of a revocation certificate (perhaps printed on paper) to keep in a physically distant location. They would need to be trustworthy enough to not abuse the revocation certificate by revoking your certificate, but otherwise would not need to be given absolute trust that comes with having a copy of the private key. Same thing with keeping revocation certificates in a bank safe deposit box or some other location protected by a third-party -- if the box were compromised (say by the authorities with a court order), your private key would not be compromised. > Leo > > PS: Please, do not tell me one might have forgotten his passphrase. In this case > there is no harm in shredding the secret key and waiting for the expiration > date, answering persons emailing you encrypted files that you lost your > passphrase. Anyway, in this case, you're screwed, and a revocation certificate > would be no better -- unless it was stored unencrypted, at the risk of having it > used when you do not want it to be. Actually, that's a fairly reasonable scenario. Someone may have forgotten their passphrase for whatever reason (ranging from forgetfulness to head trauma) and would like to inform others that their key is no longer usable. Replying to people saying that their key is lost is essentially indistinguishable from a man-in-the-middle attack -- some people might simply resend the encrypted message in plaintext, defeating the purpose of encryption in the first place. A revocation certificate allows one to revoke the certificate even without access to the private key, so one could reply with their now-revoked public key (or direct someone to the revoked key on the keyserver) and say "Sorry, I lost the private key and had to revoke it." -- while this doesn't resolve the issue of people resending things in plaintext, it does permit someone to actually show that their key is, in fact, revoked. Also, not all keys have expiration dates. I, for one, tend not to set expiration dates on my primary keys, but instead rotate encryption and signing subkeys (which do have expiration dates) for day-to-day use. While I could put an expiration date on the primary and extend the date as needed, it's easier for me to just make revocation certificates and keep them stored off-site. Your mileage may vary, of course. Cheers! -Pete -- Pete Stephenson From rjh at sixdemonbag.org Thu Jan 23 22:27:58 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Jan 2014 13:27:58 -0800 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <20140123202525.GA10540@leortable> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> Message-ID: <20140123132758.Horde.zFvY_7tunE0XkdX2q3ELdQ2@mail.sixdemonbag.org> > Actually, this is something I never understood. Why should people create a > revocation certificate and store it in a safe place, instead of > backing up the main key? A "safe place" for a revocation certificate may be vastly different from a "safe place" for a backup of your certificate. For instance, if you're married you may be completely comfortable storing a revocation certificate in a locked desk drawer to which your spouse also has a key, but you may not wish to leave a backup of your certificate there. In the event of divorce proceedings the worst your now-aggrieved spouse can do is revoke your certificate; your spouse won't have access to your private key as well. And yes, a strong passphrase is still the strongest bar against these backups being misused -- but unless you've got an eye-poppingly strong passphrase, your best bet is to rely on denying attackers access to the data as well as the passphrase. (I've often told people I'd be happy to post my private key to this mailing list in order to prove my claim that with a strong passphrase you have nothing to fear -- I never said I wouldn't grab 32 bytes from /dev/random, base64 encode them, and use that as a passphrase. That counts as eye-poppingly strong, I think...) From wk at gnupg.org Thu Jan 23 22:26:33 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Jan 2014 22:26:33 +0100 Subject: Revocation certificates In-Reply-To: <20140123202525.GA10540@leortable> (Leo Gaspard's message of "Thu, 23 Jan 2014 21:25:26 +0100") References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> Message-ID: <87sise9ypi.fsf@vigenere.g10code.de> On Thu, 23 Jan 2014 21:25, ekleog at gmail.com said: > PS: Please, do not tell me one might have forgotten his passphrase. In this case > there is no harm in shredding the secret key and waiting for the expiration Experience has shown that this is the most common reason why there are so many secret keys on the servers which are useless. Further, an expiration data is not set by default and waiting a year until the key expired is not a good option. Further, it is also common that a secret key is lost (disk crash - no backup, backup not readable or too old) or simply stolen. This has the same effect as a forgotten passphrase. In particular in the stolen key case, you want to immediately revoke it and not wait until you can restore the key from a backup stored at some safe place. There are other rare scenarios, for example a high security key in a far away place, you are traveling and you want to immediately revoke the key for whatever reason. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ekleog at gmail.com Thu Jan 23 22:54:55 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 23 Jan 2014 22:54:55 +0100 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> Message-ID: <20140123215455.GA12290@leortable> On Thu, Jan 23, 2014 at 09:59:30PM +0100, Pete Stephenson wrote: > [...] > > They would need to be trustworthy > enough to not abuse the revocation certificate by revoking your > certificate, but otherwise would not need to be given absolute trust > that comes with having a copy of the private key. Same thing with > keeping revocation certificates in a bank safe deposit box or some > other location protected by a third-party -- if the box were > compromised (say by the authorities with a court order), your private > key would not be compromised. Well, why not give them a copy of the encrypted key? So long as your passphrase is strong enough (e.g. diceware for 128-bit passphrase), it should not require to have absolute trust in the backup holder. And if you want to account for risks of mental injury serious enough to make you forget your passphrase, well... our threat models are not the same: in mine, my key will expire soon enough in this case, and noone will ever be able to compromise my secret key as noone on earth remembers the cryptographically strong passphrase. > > PS: Please, do not tell me one might have forgotten his passphrase. In this case > > there is no harm in shredding the secret key and waiting for the expiration > > date, answering persons emailing you encrypted files that you lost your > > passphrase. Anyway, in this case, you're screwed, and a revocation certificate > > would be no better -- unless it was stored unencrypted, at the risk of having it > > used when you do not want it to be. > > Actually, that's a fairly reasonable scenario. Someone may have > forgotten their passphrase for whatever reason (ranging from > forgetfulness to head trauma) and would like to inform others that > their key is no longer usable. Replying to people saying that their > key is lost is essentially indistinguishable from a man-in-the-middle > attack -- some people might simply resend the encrypted message in > plaintext, defeating the purpose of encryption in the first place. As you put it, this is essentially indistinguishable from a man-in-the-middle attack, so anyone who resend the encrypted message unencrypted is not respecting the protocol (or believe it is not important enough to be encrypted -- let's remember a lot of people just send christmas cards without envelopes). If anything important has to be transmitted (and the sender refuses to send it in cleartext), the sender will most likely send the message to someone else with physical contact with the recipient. One might argue this protocol is non-perfect, yet it is the best one the sender could achieve, revocation certificate or not. > A revocation certificate allows one to revoke the certificate even > without access to the private key, so one could reply with their > now-revoked public key (or direct someone to the revoked key on the > keyserver) and say "Sorry, I lost the private key and had to revoke > it." -- while this doesn't resolve the issue of people resending > things in plaintext, it does permit someone to actually show that > their key is, in fact, revoked. Indeed. Yet absence of answer should be clear enough to let the sender understand his message did not come to the recipient. Sure, a MitM could block the outgoing message, but anyway the sender has no better option than to find another way of sending his message: the recipient clearly does not receive the message. In case the fact of knowing a key has been revoked is critical in time, well... Knowledge of head traumas tend to expand quickly enough into the circles of acquaintances. (Sure, forgetfulness is a risk. Yet, forgetting a passphrase you type so often must be quite hard past the first few weeks.) And, what's more, such a time-critical scenarios happen only with special needs, which are AFAICT not usual. > Also, not all keys have expiration dates. I, for one, tend not to set > expiration dates on my primary keys, but instead rotate encryption and > signing subkeys (which do have expiration dates) for day-to-day use. > While I could put an expiration date on the primary and extend the > date as needed, it's easier for me to just make revocation > certificates and keep them stored off-site. Well, you lose the dead-man-switch. BTW, once your key is revoked, will it some day be cleared out of the keyservers, or will it stay there forever? AFAIC guess, keys with an expiration date must be purged a little while after they expired, as there is no point in keeping them, while revoked keys must be kept, as anyone might need to update them to retrieve the revocation certificate. Of course, I'm only discussing the case of "normal people". There must be plenty of cases for which a revocation certificate is really useful, yet the number of tutorials in which I read "Store a backup of your private key and a revocation certificate" just looks like nonsense to me: if one stores both, it should at least be precised it should be in two different locations, as storing the two together is completely pointless, one being able to make the second. Of course, YMMV! Cheers! Leo From ekleog at gmail.com Thu Jan 23 23:06:14 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 23 Jan 2014 23:06:14 +0100 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <20140123132758.Horde.zFvY_7tunE0XkdX2q3ELdQ2@mail.sixdemonbag.org> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> <20140123132758.Horde.zFvY_7tunE0XkdX2q3ELdQ2@mail.sixdemonbag.org> Message-ID: <20140123220614.GB12290@leortable> On Thu, Jan 23, 2014 at 01:27:58PM -0800, Robert J. Hansen wrote: > [...] > > And yes, a strong passphrase is still the strongest bar against these > backups being misused -- but unless you've got an eye-poppingly strong > passphrase, your best bet is to rely on denying attackers access to the data > as well as the passphrase. > > [...] Well... Diceware generates 128-bit passphrases of ten words, which is not *that* much. Yet is can be regarded as far too much. Well... seven-word passphrase provides 90-bit of security, and should not be so hard to remember. And bruteforcing it should be quite long... Sure, you would need to use really good random number generator, yet you could use /dev/random just as well as you would have for your randomly-generated passphrase. Yet, I agree I would not send my encrypted private key. But having your divorced spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an unreasonable threat to me. And AFAICT even well-funded-organizations are not yet powerful enough to bruteforce a 90-bit passphrase with enough s2k iterations. Cheers, Leo From ekleog at gmail.com Thu Jan 23 23:15:16 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 23 Jan 2014 23:15:16 +0100 Subject: Revocation certificates In-Reply-To: <87sise9ypi.fsf@vigenere.g10code.de> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> <87sise9ypi.fsf@vigenere.g10code.de> Message-ID: <20140123221516.GC12290@leortable> On Thu, Jan 23, 2014 at 10:26:33PM +0100, Werner Koch wrote: > On Thu, 23 Jan 2014 21:25, ekleog at gmail.com said: > > > PS: Please, do not tell me one might have forgotten his passphrase. In this case > > there is no harm in shredding the secret key and waiting for the expiration > > Experience has shown that this is the most common reason why there are > so many secret keys on the servers which are useless. Further, an > expiration data is not set by default and waiting a year until the key > expired is not a good option. Oh? I thought the most common reason was test keys, and tutorials which explain step-by-step how to make a keypair and push it on a keyserver, without telling to put an expiration date. I, unfortunately, have myself put a few test keys on the keyservers (whose passphrase I no longer have) without expiration date before knowing they would never (?) be deleted, and am still remorseful about it. And keys with an expiration date are someday deleted, while keys, even revoked, without are never, are they? BTW, revocation certificates are not produced by default either. So, why not advise people to put an expiration date, instead of counselling them to generate a revocation certificate? > Further, it is also common that a secret key is lost (disk crash - no > backup, backup not readable or too old) or simply stolen. This has the > same effect as a forgotten passphrase. In particular in the stolen key > case, you want to immediately revoke it and not wait until you can > restore the key from a backup stored at some safe place. Well, my question is then: Why not restore the key immediately (having stored it at the place you would have stored the revocation certificate), and revoke it then? > There are other rare scenarios, for example a high security key in a far > away place, you are traveling and you want to immediately revoke the key > for whatever reason. These corner-case scenarios are ones I did not mean to discuss, sorry for not having made them clear. I'm also feeling I may have failed to make myself understood: I am not denying the usefulness of revocation certificate, just the advice always popping out to generate a revocation certificate in any case, without thinking of whether it would be useful. Cheers ! Leo From steve at secretvolcanobase.org Thu Jan 23 23:50:23 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Thu, 23 Jan 2014 22:50:23 +0000 Subject: Non email addresses in UID Message-ID: <20140123225023.3dcbe4dd@steves-laptop> I've been thinking about UIDs in keys, rfc4880 section 5.1 says that by convention a UID is an rfc2822 email address but this is not a requirement[1]. Gnupg does enforce that restriction unless you explicitly disable it. It would seem to make sense to include other strings that can identify a user, many people have various URLs which could be said to relate to their identity, Facebook accounts, blogs etc... It could potentially be useful to be able to associate a key with these other identities, i.e. if you get an email purporting to be from someone you only know on a webforum it would be useful to be able to verify this. I'm curious what other people on this list think of this. [1] http://tools.ietf.org/html/rfc4880#section-5.11 -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Jan 24 00:08:40 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Jan 2014 15:08:40 -0800 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <20140123220614.GB12290@leortable> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> <20140123132758.Horde.zFvY_7tunE0XkdX2q3ELdQ2@mail.sixdemonbag.org> <20140123220614.GB12290@leortable> Message-ID: <20140123150840.Horde.ZDqrrBGUA-H_wWNLT7x1KA7@mail.sixdemonbag.org> > Yet, I agree I would not send my encrypted private key. But having > your divorced > spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an > unreasonable threat to me. It is. That's why that's not the threat being defended against. The threat is against your spouse seeing you enter your passphrase. It's very easy for roommates to discover each other's passwords and passphrases; sometimes it happens by accident. Everyone knows not to enter a passphrase with a shoulder surfer around, but if you and your spouse are sitting on the couch with your laptops open and you receive an encrypted email, are you really going to tell her, "Sorry, honey, I have to take this into the other room so I can enter my passphrase without worrying about you spotting it"? So long as there's marital bliss, you're perfectly safe. You just can't rely on that lasting forever. From ekleog at gmail.com Fri Jan 24 00:58:00 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Fri, 24 Jan 2014 00:58:00 +0100 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <20140123150840.Horde.ZDqrrBGUA-H_wWNLT7x1KA7@mail.sixdemonbag.org> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> <20140123132758.Horde.zFvY_7tunE0XkdX2q3ELdQ2@mail.sixdemonbag.org> <20140123220614.GB12290@leortable> <20140123150840.Horde.ZDqrrBGUA-H_wWNLT7x1KA7@mail.sixdemonbag.org> Message-ID: <20140123235800.GD12290@leortable> On Thu, Jan 23, 2014 at 03:08:40PM -0800, Robert J. Hansen wrote: > >Yet, I agree I would not send my encrypted private key. But having your > >divorced > >spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an > >unreasonable threat to me. > > It is. That's why that's not the threat being defended against. > > The threat is against your spouse seeing you enter your passphrase. It's > very easy for roommates to discover each other's passwords and passphrases; > sometimes it happens by accident. Everyone knows not to enter a passphrase > with a shoulder surfer around, but if you and your spouse are sitting on the > couch with your laptops open and you receive an encrypted email, are you > really going to tell her, "Sorry, honey, I have to take this into the other > room so I can enter my passphrase without worrying about you spotting it"? > > So long as there's marital bliss, you're perfectly safe. You just can't > rely on that lasting forever. Well... I don't know how you type, but someone looking at me who sees me type my passphrase would really have to try hard to guess what passphrase I am using. And even more to remember a seven-word sentence seen once. BTW, I once had a fun experiment: just type an eight random chars password with no protection at all, and asking people behind me to remember it. The password was displayed as I typed it, and left approx. two seconds more. No one managed to see it and remember it. A few days later, I conducted the same experiment with the same people and the same password, and no password was successfully guessed. Sure, the information gathered would be enough to bootstrap a successful "bruteforce", but the experiment was a lot more easy to complete than peeping at and remembering a seven-word password. So, if the spouse is doing it, then marital bliss has already come to an end, and one should have noticed it. Yet, being unmarried, I cannot say anything about such things. So, within that threat model, revocation certificates are useful for sure. Assuming one's spouse would first grab the secret key and remember the passphrase before divorce. Thanks for making that point! Leo From rjh at sixdemonbag.org Fri Jan 24 01:38:19 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Jan 2014 16:38:19 -0800 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <20140123235800.GD12290@leortable> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> <20140123132758.Horde.zFvY_7tunE0XkdX2q3ELdQ2@mail.sixdemonbag.org> <20140123220614.GB12290@leortable> <20140123150840.Horde.ZDqrrBGUA-H_wWNLT7x1KA7@mail.sixdemonbag.org> <20140123235800.GD12290@leortable> Message-ID: <20140123163819.Horde.exJiuOqK1gi8yJSsDTjkNg5@mail.sixdemonbag.org> > Well... I don't know how you type With a nine-volt battery, a paperclip, and a USB cable that has only one end -- the other is bare wires. You wouldn't believe how difficult it is to do the initial handshake, but once you've got it down you can easily tap out oh, three or four words a minute. For speed, nothing else comes close. My father gets on my case for using the nine-volt battery. In his day, they had a potato and a couple of wire leads plunged into it. But really, technology marches on and we should all embrace battery technology. > passphrase would really have to try hard to guess what passphrase I am using. > And even more to remember a seven-word sentence seen once. You are not the typical use case. No one person is a typical use case. From wk at gnupg.org Fri Jan 24 07:47:15 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Jan 2014 07:47:15 +0100 Subject: Revocation certificates In-Reply-To: <20140123221516.GC12290@leortable> (Leo Gaspard's message of "Thu, 23 Jan 2014 23:15:16 +0100") References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> <87sise9ypi.fsf@vigenere.g10code.de> <20140123221516.GC12290@leortable> Message-ID: <87k3dpanbg.fsf@vigenere.g10code.de> On Thu, 23 Jan 2014 23:15, ekleog at gmail.com said: > Oh? I thought the most common reason was test keys, and tutorials which explain > step-by-step how to make a keypair and push it on a keyserver, without telling Obviously, I don't have no hard evidence for the claim that forgotten passpharses are a reason for many unusable keys. However, I have heard too many times statements like ?Please don't encrypt to that key; I - uhmm - can't remember my passphrase?. > And keys with an expiration date are someday deleted, while keys, even revoked, > without are never, are they? No they are not deleted. They are still useful for signature verification. Think about gnupg 1.0.0 which has been signed by a long expired key of mine - verifying it still gives some evidence that the tarball is genuine. The key merely expired. If I had reasons to assume that the key is compromised I would issue a revocation. Verification tools show that. > BTW, revocation certificates are not produced by default either. So, why not > advise people to put an expiration date, instead of counselling them The reason why they are not generated by default is that I am sure that many people would accidentally publish the revocation. That is not optimal and thus my current plan is to create a revocation be default but modify the armored file so that it can only be imported after editing the file. > Well, my question is then: Why not restore the key immediately (having stored it > at the place you would have stored the revocation certificate), and revoke it > then? The key is of course stored at a bank safe. The sheet/cdrom with the revocation is in the drawer of my desk. > the usefulness of revocation certificate, just the advice always popping out to > generate a revocation certificate in any case, without thinking of whether it > would be useful. Okay, that is a different thing. I plan to change that with a notice saying which file has the edited revocation certificate. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tomasio at gmail.com Fri Jan 24 09:48:49 2014 From: tomasio at gmail.com (tomasio) Date: Fri, 24 Jan 2014 09:48:49 +0100 Subject: Safely remove gnupg 1.4 without damaging gnugp 2 on Mac OS? Message-ID: <52E228F1.9090101@gmail.com> Dear all, I have GnuPG 1.4.11 left over from a former installation. Since I upgraded to GnuPG 2.0.22 during the installation of GPG-Suite for Mac OS (10. 8. 5 ? Mountain Lion) I do not need the older version. Is it possible to remove it without hurting my keyrings? Thank you in advance for your help. best regards, -- tomasio From arne.renkema-padmos at cased.de Thu Jan 23 23:28:01 2014 From: arne.renkema-padmos at cased.de (arne renkema-padmos) Date: Thu, 23 Jan 2014 23:28:01 +0100 Subject: BoF at FOSDEM ? In-Reply-To: <87txcubr4j.fsf@vigenere.g10code.de> References: <87txcubr4j.fsf@vigenere.g10code.de> Message-ID: <52E19771.60608@cased.de> On 23/01/14 17:27, Werner Koch wrote: > is anyone interested in a BoF at FOSDEM on February 1 or 2? Anything > special to put on the agenda? How long should we plan 30, 45 or 60 > minutes? Sound like a good plan. My preference would be the 1st of February around lunch. Cheers, arne -- Arne Renkema-Padmos @hcisec, secuso.org Doctoral researcher CASED, TU Darmstadt SecUSo ? Security, Usability and Society 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 wk at gnupg.org Fri Jan 24 13:03:32 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Jan 2014 13:03:32 +0100 Subject: BoF at FOSDEM ? In-Reply-To: <52E19771.60608@cased.de> (arne renkema-padmos's message of "Thu, 23 Jan 2014 23:28:01 +0100") References: <87txcubr4j.fsf@vigenere.g10code.de> <52E19771.60608@cased.de> Message-ID: <87a9ela8ob.fsf@vigenere.g10code.de> On Thu, 23 Jan 2014 23:28, arne.renkema-padmos at cased.de said: > Sound like a good plan. My preference would be the 1st of February > around lunch. Well, the BoF rooms are assigned on a first come first served base. Thus we can't sign up for a certain time. I am fine with Saturday, but better not before 13:00. Any topics you want to discuss? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From htd at fritha.org Fri Jan 24 13:36:23 2014 From: htd at fritha.org (Heinz Diehl) Date: Fri, 24 Jan 2014 13:36:23 +0100 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <20140123202525.GA10540@leortable> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> Message-ID: <20140124123623.GA2768@fritha.org> On 24.01.2014, Leo Gaspard wrote: > Actually, this is something I never understood. Why should people create a > revocation certificate and store it in a safe place, instead of backing up the > main key? Because a backup only makes sense when it's stored in a diffrent place than the key itself: With every backup you create, you have one place more you'll have to keep secure, and doubled the chance that your key can be accessed. From shmick at riseup.net Fri Jan 24 14:24:14 2014 From: shmick at riseup.net (shmick at riseup.net) Date: Sat, 25 Jan 2014 00:24:14 +1100 Subject: his public key is 5 monitors high, and her same key is 1 ? Message-ID: <52E2697E.6040204@riseup.net> what are the factors involved in creating such discrepancies with folks' public key lengths ? i mean, some people's are 5 monitors high where as the other joe has seemingly created a similar key and that key is one half a monitor in 'monitor' height what does all this mean ? how have people such varying public key 'sizes' ? and how is this achieved ? are public, private, and key pairs in general stronger/safer (what ever that may mean) if observing their public keys are many monitors high or have they gone to extreme measures in something in particular ? From pete at heypete.com Fri Jan 24 14:42:30 2014 From: pete at heypete.com (Pete Stephenson) Date: Fri, 24 Jan 2014 14:42:30 +0100 Subject: his public key is 5 monitors high, and her same key is 1 ? In-Reply-To: <52E2697E.6040204@riseup.net> References: <52E2697E.6040204@riseup.net> Message-ID: On Fri, Jan 24, 2014 at 2:24 PM, shmick at riseup.net wrote: > what are the factors involved in creating such discrepancies with folks' > public key lengths ? As far as I can tell, the two major factors that affect the size of public keys are: 1. Key length. (That is, a 4096-bit key will be larger than a 2048-bit or 1024-bit key.) 2. Number of signatures on the key. A brand-new key will be considerably shorter than one that has accumulated numerous signatures from other people. > are public, private, and key pairs in general stronger/safer (what ever > that may mean) if observing their public keys are many monitors high or > have they gone to extreme measures in something in particular ? Key length does have an effect on security: 2048-bit keys are larger and harder to brute-force than 1024-bit keys. The same applies to 3072 and 4096-bit keys compared to 2048-bit ones, though there is a point of diminishing returns. -- Pete Stephenson From steve at secretvolcanobase.org Fri Jan 24 14:46:10 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Fri, 24 Jan 2014 13:46:10 +0000 Subject: his public key is 5 monitors high, and her same key is 1 ? In-Reply-To: <52E2697E.6040204@riseup.net> References: <52E2697E.6040204@riseup.net> Message-ID: <20140124134610.1919dcee@steves-laptop> On Sat, 25 Jan 2014 00:24:14 +1100 "shmick at riseup.net" wrote: > what are the factors involved in creating such discrepancies with folks' > public key lengths ? > > i mean, some people's are 5 monitors high where as the other joe has > seemingly created a similar key and that key is one half a monitor in > 'monitor' height You can use the pgpdump tool to see all the data in a public key file. A given key might contain lots of extra data beside the actual key, like signatures and photos. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From rjh at sixdemonbag.org Fri Jan 24 15:09:13 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 24 Jan 2014 09:09:13 -0500 Subject: his public key is 5 monitors high, and her same key is 1 ? In-Reply-To: References: <52E2697E.6040204@riseup.net> Message-ID: <52E27409.9050709@sixdemonbag.org> On 1/24/2014 8:42 AM, Pete Stephenson wrote: > As far as I can tell, the two major factors that affect the size of > public keys are: > 1. Key length. (That is, a 4096-bit key will be larger than a 2048-bit > or 1024-bit key.) > 2. Number of signatures on the key. A brand-new key will be > considerably shorter than one that has accumulated numerous signatures > from other people. Don't forget photo IDs, which can massively expand the size of a certificate. From shmick at riseup.net Fri Jan 24 15:26:51 2014 From: shmick at riseup.net (shmick at riseup.net) Date: Sat, 25 Jan 2014 01:26:51 +1100 Subject: his public key is 5 monitors high, and her same key is 1 ? In-Reply-To: <20140124134610.1919dcee@steves-laptop> References: <52E2697E.6040204@riseup.net> <20140124134610.1919dcee@steves-laptop> Message-ID: <52E2782B.2050707@riseup.net> Steve Jones: > On Sat, 25 Jan 2014 00:24:14 +1100 "shmick at riseup.net" > wrote: > >> what are the factors involved in creating such discrepancies with >> folks' public key lengths ? >> >> i mean, some people's are 5 monitors high where as the other joe >> has seemingly created a similar key and that key is one half a >> monitor in 'monitor' height > > You can use the pgpdump tool to see all the data in a public key > file. A given key might contain lots of extra data beside the > actual key, like signatures and photos. thanks for that tip ... > > > > _______________________________________________ Gnupg-users mailing > list Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From shmick at riseup.net Fri Jan 24 15:29:40 2014 From: shmick at riseup.net (shmick at riseup.net) Date: Sat, 25 Jan 2014 01:29:40 +1100 Subject: his public key is 5 monitors high, and her same key is 1 ? In-Reply-To: References: <52E2697E.6040204@riseup.net> Message-ID: <52E278D4.5050505@riseup.net> Pete Stephenson: > On Fri, Jan 24, 2014 at 2:24 PM, shmick at riseup.net wrote: >> what are the factors involved in creating such discrepancies with folks' >> public key lengths ? > > As far as I can tell, the two major factors that affect the size of > public keys are: > 1. Key length. (That is, a 4096-bit key will be larger than a 2048-bit > or 1024-bit key.) > 2. Number of signatures on the key. A brand-new key will be > considerably shorter than one that has accumulated numerous signatures > from other people. that's makes sense; now i understand why Zimmerman's and callas' public keys are going through the ceiling as to who michael vario is it remains to be seen ! > >> are public, private, and key pairs in general stronger/safer (what ever >> that may mean) if observing their public keys are many monitors high or >> have they gone to extreme measures in something in particular ? > > Key length does have an effect on security: 2048-bit keys are larger > and harder to brute-force than 1024-bit keys. The same applies to 3072 > and 4096-bit keys compared to 2048-bit ones, though there is a point > of diminishing returns. > From dkg at fifthhorseman.net Fri Jan 24 18:15:40 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 24 Jan 2014 12:15:40 -0500 Subject: Non email addresses in UID In-Reply-To: <20140123225023.3dcbe4dd@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> Message-ID: <52E29FBC.5090004@fifthhorseman.net> On 01/23/2014 05:50 PM, Steve Jones wrote: > I've been thinking about UIDs in keys, rfc4880 section 5.1 says that by convention a UID is an rfc2822 email address but this is not a requirement[1]. Gnupg does enforce that restriction unless you explicitly disable it. It would seem to make sense to include other strings that can identify a user, many people have various URLs which could be said to relate to their identity, Facebook accounts, blogs etc... It could potentially be useful to be able to associate a key with these other identities, i.e. if you get an email purporting to be from someone you only know on a webforum it would be useful to be able to verify this. I'm curious what other people on this list think of this. There are already systems that make use of the flexibility in this field. For example SSH hosts can publish their RSA host key in an OpenPGP certificate using the monkeysphere (i'm a contributor to the monkeysphere project): http://web.monkeysphere.info/ Other people advocate including a human-readable name without an e-mail address as a User ID, so that you can refer to a person without making any claim about e-mail addresses (i'm don't find the utility of this use case particularly convincing myself, but it doesn't seem terrible). So the general question you're asking about is being done already. As for facebook or openid or webforums other identifiers, i don't think those have been particularly well-thought through yet. Under what circumstances would you use them? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From ekleog at gmail.com Fri Jan 24 18:23:35 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Fri, 24 Jan 2014 18:23:35 +0100 Subject: Revocation certificates [was: time delay unlock private key.] In-Reply-To: <20140123163819.Horde.exJiuOqK1gi8yJSsDTjkNg5@mail.sixdemonbag.org> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> <20140123132758.Horde.zFvY_7tunE0XkdX2q3ELdQ2@mail.sixdemonbag.org> <20140123220614.GB12290@leortable> <20140123150840.Horde.ZDqrrBGUA-H_wWNLT7x1KA7@mail.sixdemonbag.org> <20140123235800.GD12290@leortable> <20140123163819.Horde.exJiuOqK1gi8yJSsDTjkNg5@mail.sixdemonbag.org> Message-ID: <20140124172335.GE12290@leortable> On Thu, Jan 23, 2014 at 04:38:19PM -0800, Robert J. Hansen wrote: > >Well... I don't know how you type > > With a nine-volt battery, a paperclip, and a USB cable that has only one end > -- the other is bare wires. You wouldn't believe how difficult it is to do > the initial handshake, but once you've got it down you can easily tap out > oh, three or four words a minute. For speed, nothing else comes close. > > My father gets on my case for using the nine-volt battery. In his day, they > had a potato and a couple of wire leads plunged into it. But really, > technology marches on and we should all embrace battery technology. Great laugh! (of course, I meant how fast) > >passphrase would really have to try hard to guess what passphrase I am using. > >And even more to remember a seven-word sentence seen once. > > You are not the typical use case. No one person is a typical use case. Well... You are right, of course. Yet this does not answer my second point: if the spouse is spying on you to get your passphrase and remember it, then love is already gone, and you are being subject to the usual hooker attack. Yet I do see your point for revocation certificates here, I think. Oh, just found another one in favor of revocation certificates: they can be easily sent to keyservers from cybercafes without any special software installed. Thanks and cheers, Leo From ekleog at gmail.com Fri Jan 24 18:44:20 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Fri, 24 Jan 2014 18:44:20 +0100 Subject: Revocation certificates In-Reply-To: <87k3dpanbg.fsf@vigenere.g10code.de> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <1412391.8dJ22iTy69@mani> <52E15735.8080205@xandea.de> <20140123202525.GA10540@leortable> <87sise9ypi.fsf@vigenere.g10code.de> <20140123221516.GC12290@leortable> <87k3dpanbg.fsf@vigenere.g10code.de> Message-ID: <20140124174420.GF12290@leortable> On Fri, Jan 24, 2014 at 07:47:15AM +0100, Werner Koch wrote: > [...] > > > the usefulness of revocation certificate, just the advice always popping out to > > generate a revocation certificate in any case, without thinking of whether it > > would be useful. > > Okay, that is a different thing. I plan to change that with a notice > saying which file has the edited revocation certificate. OK, thanks! (for the remainder of the message as well, just have nothing to answer) Guess I got my answer, with every message combined. Thanks all! Leo From steve at secretvolcanobase.org Fri Jan 24 18:48:56 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Fri, 24 Jan 2014 17:48:56 +0000 Subject: Non email addresses in UID In-Reply-To: <52E29FBC.5090004@fifthhorseman.net> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> Message-ID: <20140124174856.4eb1fe40@steves-laptop> On Fri, 24 Jan 2014 12:15:40 -0500 Daniel Kahn Gillmor wrote: > There are already systems that make use of the flexibility in this > field. For example SSH hosts can publish their RSA host key in an > OpenPGP certificate using the monkeysphere (i'm a contributor to the > monkeysphere project): > > http://web.monkeysphere.info/ This looks pretty cool, and does cover some of the things I've been thinking about. I've been wondering about communications secured with OpenPGP, it strikes me that it's not really necessary to even involve SSL; and the nightmares that seems to involve. Does monkeysphere have any aims to do complete connection security via OpenPGP? > Other people advocate including a human-readable name without an > e-mail address as a User ID, so that you can refer to a person > without making any claim about e-mail addresses (i'm don't find the > utility of this use case particularly convincing myself, but it > doesn't seem terrible). The use case for this would match more closely what the GPG manpage and the PGP key signing party protocol dictate; i.e. that participants verify state issued photo Id to confirm the name of the key holder is their "real name" - none of my state issued Id has my email address on it. Plus it makes a bit more sense in the case of multiple UIDs, one for your name and possibly many for your email address. > So the general question you're asking about is being done already. As > for facebook or openid or webforums other identifiers, i don't think > those have been particularly well-thought through yet. Under what > circumstances would you use them? My thinking is that identity as it is used on the Internet (or the world in general) doesn't really match the way OpenPGP is used. To take an obscure example: some people have noticed that Github has no verification that commits submitted in repositories are actually made by the users registered with those name and email addresses with them, nor can it. This makes it possible, and some trolls have, to impersonate Github users. Git allows for signing commits with keys, but there's not really any way to associate those keys with accounts. Sticking the URL of a Github account in a UID field and having other contributors to a project sign that UID makes it possible to cross verify commits with users. Note that at no stage in this processes is Github required to implement or do anything and no-one's state confirmed identity is involved. Github could of course sign that URL UID if they wished to without saying anything about the user's passport. So I'm led to the idea that associating keys with areas on the web where a person's work, writings, etc... are known is more important than some sort of confirmation of a person's name, which is not even a unique identifier. If, for example, you'd signed your commits to monkeysphere I'd be able to verify your claim that you are a contributor to it (not that I doubt, or have any reason to doubt that). -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From hans at guardianproject.info Fri Jan 24 18:59:05 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 24 Jan 2014 12:59:05 -0500 Subject: Non email addresses in UID In-Reply-To: <20140123225023.3dcbe4dd@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> Message-ID: <52E2A9E9.8020107@guardianproject.info> I think it makes a lot of sense to be able to associate more things with OpenPGP keys. I'm particularly interested in seeing OTR keys and XMPP identities in OpenPGP keys. .hc On 01/23/2014 05:50 PM, Steve Jones wrote: > I've been thinking about UIDs in keys, rfc4880 section 5.1 says that by convention a UID is an rfc2822 email address but this is not a requirement[1]. Gnupg does enforce that restriction unless you explicitly disable it. It would seem to make sense to include other strings that can identify a user, many people have various URLs which could be said to relate to their identity, Facebook accounts, blogs etc... It could potentially be useful to be able to associate a key with these other identities, i.e. if you get an email purporting to be from someone you only know on a webforum it would be useful to be able to verify this. I'm curious what other people on this list think of this. > > > [1] http://tools.ietf.org/html/rfc4880#section-5.11 > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From arne.renkema-padmos at cased.de Fri Jan 24 21:14:12 2014 From: arne.renkema-padmos at cased.de (arne renkema-padmos) Date: Fri, 24 Jan 2014 21:14:12 +0100 Subject: BoF at FOSDEM ? In-Reply-To: <87a9ela8ob.fsf@vigenere.g10code.de> References: <87txcubr4j.fsf@vigenere.g10code.de> <52E19771.60608@cased.de> <87a9ela8ob.fsf@vigenere.g10code.de> Message-ID: <52E2C994.1050504@cased.de> On 24/01/14 13:03, Werner Koch wrote: > On Thu, 23 Jan 2014 23:28, arne.renkema-padmos at cased.de said: > >> Sound like a good plan. My preference would be the 1st of February >> around lunch. > > Well, the BoF rooms are assigned on a first come first served base. > Thus we can't sign up for a certain time. I am fine with Saturday, but > better not before 13:00. Ok. > Any topics you want to discuss? My personal pet-problem is the usability of tools like GPG. > Salam-Shalom, > > Werner > -- Arne Renkema-Padmos @hcisec, secuso.org Doctoral researcher CASED, TU Darmstadt From wk at gnupg.org Fri Jan 24 22:15:57 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Jan 2014 22:15:57 +0100 Subject: BoF at FOSDEM ? In-Reply-To: <52E2C994.1050504@cased.de> (arne renkema-padmos's message of "Fri, 24 Jan 2014 21:14:12 +0100") References: <87txcubr4j.fsf@vigenere.g10code.de> <52E19771.60608@cased.de> <87a9ela8ob.fsf@vigenere.g10code.de> <52E2C994.1050504@cased.de> Message-ID: <87lhy584j6.fsf@vigenere.g10code.de> On Fri, 24 Jan 2014 21:14, arne.renkema-padmos at cased.de said: > My personal pet-problem is the usability of tools like GPG. Okay, thus we have - Report on current keyserver work [Kristian] - Make GPG invisible to the user [Arne] - ECC and GnuPG progress [Werner] Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Jan 24 23:16:28 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 24 Jan 2014 17:16:28 -0500 Subject: Non email addresses in UID In-Reply-To: <20140124174856.4eb1fe40@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> Message-ID: <52E2E63C.3080102@fifthhorseman.net> On 01/24/2014 12:48 PM, Steve Jones wrote: > On Fri, 24 Jan 2014 12:15:40 -0500 Daniel Kahn Gillmor wrote: > >> http://web.monkeysphere.info/ > > This looks pretty cool, and does cover some of the things I've been > thinking about. I've been wondering about communications secured with > OpenPGP, it strikes me that it's not really necessary to even involve > SSL; and the nightmares that seems to involve. Does monkeysphere have > any aims to do complete connection security via OpenPGP? what do you mean "complete connection security via OpenPGP"? OpenPGP is not a stream-based communications protocol, it's a specification of a message format and a certificate format. Inventing a new stream-based communications protocol from scratch and shoehorning it into OpenPGP doesn't sound like a great idea to me. Monkeysphere uses OpenPGP's certificate format to provide a way for people to verify the keys used in SSH and TLS (and elsewhere -- OTR would be a lovely addition, for example). It does not intend to supplant those communications techniques. > So I'm led to the idea that associating keys with areas on the web > where a person's work, writings, etc... are known is more important > than some sort of confirmation of a person's name, which is not even a > unique identifier. If, for example, you'd signed your commits to > monkeysphere I'd be able to verify your claim that you are a > contributor to it (not that I doubt, or have any reason to doubt that). how are other people going to verify these propose User IDs? If you make a data element a subkey or a notation in your self-signature, you are not asking other people to attempt to certify it. If you make the same data element a User ID or User Attribute, then you are effectively putting it out there for other people to attempt to verify and then certify. If you came to me and said "I am the person who blogs at https://www.example.com/stevejones" , how am i supposed to verify that? when would you want me to certify it? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From steve at secretvolcanobase.org Sat Jan 25 00:08:16 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Fri, 24 Jan 2014 23:08:16 +0000 Subject: Non email addresses in UID In-Reply-To: <52E2E63C.3080102@fifthhorseman.net> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> Message-ID: <20140124230816.6ec33e69@steves-laptop> On Fri, 24 Jan 2014 17:16:28 -0500 Daniel Kahn Gillmor wrote: > what do you mean "complete connection security via OpenPGP"? OpenPGP > is not a stream-based communications protocol, it's a specification > of a message format and a certificate format. Inventing a new > stream-based communications protocol from scratch and shoehorning it > into OpenPGP doesn't sound like a great idea to me. OpenPGP is a packetised data format. There's nothing stopping it being used to send a stream of encrypted and signed data packets. The main thing you lose is the complicated and messy handshake at the start which seems to be the cause of so many implementation bugs. You do loose the possibility of perfect forward secrecy though. It was more an idle musing than anything else though. > how are other people going to verify these propose User IDs? > > If you make a data element a subkey or a notation in your > self-signature, you are not asking other people to attempt to certify > it. > > If you make the same data element a User ID or User Attribute, then > you are effectively putting it out there for other people to attempt > to verify and then certify. > > If you came to me and said "I am the person who blogs at > https://www.example.com/stevejones" , how am i supposed to verify > that? when would you want me to certify it? Well the simplest way would be if I signed my blog posts. It's easy enough to verify that my emails and posts are signed with the same key. Cryptographically easy that is, the existing tools are not so good for this kind of method of operation. Otherwise by usual web of trust means. If people who know me by other means are convinced that that blog is mine they can sign that UID, in the same manner as people could sign a photo attribute if they know what I look like. Finally there's the possibility of explicit verification, if someone sends me a challenge and I publish that challenge's signature on my blog then that verifies that I am in control of that private key and can publish to that blog. Which reminds me that I'd really like an email client that automatically signs keys at level 1 (persona) of anyone who replies with a signed email that quotes a significant portion of the text I sent, as this effectively counts as a challenge response protocol in my book. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From mbauer at gmx.org Sat Jan 25 08:08:17 2014 From: mbauer at gmx.org (Mathias Bauer) Date: Sat, 25 Jan 2014 08:08:17 +0100 Subject: his public key is 5 monitors high, and her same key is 1 ? In-Reply-To: <20140124134610.1919dcee@steves-laptop> References: <52E2697E.6040204@riseup.net> <20140124134610.1919dcee@steves-laptop> Message-ID: <20140125070817.GA11189@gmx.org> * Steve Jones wrote on Fri, 24 Jan 2014, at 13:46 (+0000): > On Sat, 25 Jan 2014 00:24:14 +1100 "shmick at riseup.net" > wrote: > > You can use the pgpdump tool to see all the data in a public > key file. A given key might contain lots of extra data beside > the actual key, like signatures and photos. If you don't have pgpdump[1] at your fingertips, you can also use $ gpg --list-packets FILE Although, of course, you may need RFC 4880[2] for looking up the constants. Best regards, Mathias [1] http://www.mew.org/~kazu/proj/pgpdump/en [2] https://tools.ietf.org/html/rfc4880 From shmick at riseup.net Sat Jan 25 10:31:17 2014 From: shmick at riseup.net (shmick at riseup.net) Date: Sat, 25 Jan 2014 20:31:17 +1100 Subject: time delay unlock private key. In-Reply-To: <87wqhqa34l.fsf@vigenere.g10code.de> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <20140123102032.Horde.AH1D1Vo4ncRZKQedmdqLxQ9@mail.sixdemonbag.org> <87wqhqa34l.fsf@vigenere.g10code.de> Message-ID: <52E38465.8050900@riseup.net> Werner Koch: > On Thu, 23 Jan 2014 19:20, rjh at sixdemonbag.org said: > >> Not really, although DKG gave you a good heads-up about the number of >> iterations in s2k. > > FWIW: With GnuPG 2.x the default iteration count is calibrated to an > iteration time of 100ms. That is of course machine dependent. To view > that count you may run gpg-connect-agent as in this example: > > $ gpg-connect-agent 'getinfo s2k_count' /bye > D 16777216 > OK $ gpg-connect-agent 'getinfo s2k_count' /bye ERR 280 not implemented hmmm ? > > > Shalom-Salam, > > Werner > From wk at gnupg.org Sat Jan 25 12:54:10 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 25 Jan 2014 12:54:10 +0100 Subject: time delay unlock private key. In-Reply-To: <52E38465.8050900@riseup.net> (shmick@riseup.net's message of "Sat, 25 Jan 2014 20:31:17 +1100") References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <20140123102032.Horde.AH1D1Vo4ncRZKQedmdqLxQ9@mail.sixdemonbag.org> <87wqhqa34l.fsf@vigenere.g10code.de> <52E38465.8050900@riseup.net> Message-ID: <87a9ek8efx.fsf@vigenere.g10code.de> On Sat, 25 Jan 2014 10:31, shmick at riseup.net said: > $ gpg-connect-agent 'getinfo s2k_count' /bye > ERR 280 not implemented You are using GnuPG version < 2.0.15. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From shmick at riseup.net Sat Jan 25 13:33:07 2014 From: shmick at riseup.net (shmick at riseup.net) Date: Sat, 25 Jan 2014 23:33:07 +1100 Subject: time delay unlock private key. In-Reply-To: <87a9ek8efx.fsf@vigenere.g10code.de> References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <20140123102032.Horde.AH1D1Vo4ncRZKQedmdqLxQ9@mail.sixdemonbag.org> <87wqhqa34l.fsf@vigenere.g10code.de> <52E38465.8050900@riseup.net> <87a9ek8efx.fsf@vigenere.g10code.de> Message-ID: <52E3AF03.2060208@riseup.net> Werner Koch: > On Sat, 25 Jan 2014 10:31, shmick at riseup.net said: > >> $ gpg-connect-agent 'getinfo s2k_count' /bye >> ERR 280 not implemented > > You are using GnuPG version < 2.0.15. $ gpg2 --version gpg (GnuPG) 2.0.22 libgcrypt 1.6.0 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, ELG, DSA, ECC, ? Cypher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 hmmm ... > > > Shalom-Salam, > > Werner > From justinquakenbush at gmail.com Sat Jan 25 01:37:11 2014 From: justinquakenbush at gmail.com (Justin Quakenbush) Date: Fri, 24 Jan 2014 16:37:11 -0800 Subject: trying to find a folder Message-ID: wheres my gnupg folder? From fa-ml at ariis.it Sat Jan 25 22:40:47 2014 From: fa-ml at ariis.it (fa-ml) Date: Sat, 25 Jan 2014 22:40:47 +0100 Subject: trying to find a folder In-Reply-To: References: Message-ID: <20140125214047.GA16288@efikamx> On Fri, Jan 24, 2014 at 04:37:11PM -0800, Justin Quakenbush wrote: > wheres my gnupg folder? > Have you tried checking 'man gpg' (search for 'FILES')? It should be ~/.gnupg/ , echo $GNUPGHOME to make sure. From pete at heypete.com Sat Jan 25 22:31:28 2014 From: pete at heypete.com (Pete Stephenson) Date: Sat, 25 Jan 2014 22:31:28 +0100 Subject: trying to find a folder In-Reply-To: References: Message-ID: On Sat, Jan 25, 2014 at 1:37 AM, Justin Quakenbush wrote: > wheres my gnupg folder? The folder containing the keyrings and configuration files is typically in ~/.gnupg/ on Linux and in %appdata%/gnupg on Windows, though it may be different on your specific system. -- Pete Stephenson From dougb at dougbarton.us Sun Jan 26 00:31:40 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 25 Jan 2014 15:31:40 -0800 Subject: Safely remove gnupg 1.4 without damaging gnugp 2 on Mac OS? In-Reply-To: <52E228F1.9090101@gmail.com> References: <52E228F1.9090101@gmail.com> Message-ID: <52E4495C.5080807@dougbarton.us> On 01/24/2014 12:48 AM, tomasio wrote: > Dear all, > > I have GnuPG 1.4.11 left over from a former installation. Since I > upgraded to GnuPG 2.0.22 during the installation of GPG-Suite for Mac OS > (10. 8. 5 ? Mountain Lion) I do not need the older version. Is it > possible to remove it without hurting my keyrings? Your keyrings are completely independent of what gnupg version you're running, but to be on the safe side you should probably back them up first. Since I don't know how the Mac versions of the gnupg software you installed work I would be mildly interested in the question of whether removing 1.4.11 might remove a library or something that the new version depends on. If I were you I would remove them both, then reinstall the new version. hope this helps, Doug From peter at digitalbrains.com Sun Jan 26 00:58:05 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 26 Jan 2014 00:58:05 +0100 Subject: trying to find a folder In-Reply-To: References: Message-ID: <52E44F8D.2050307@digitalbrains.com> On 25/01/14 01:37, Justin Quakenbush wrote: > wheres my gnupg folder? gpgconf --list-dirs It's the entry "homedir". Note that in general, with these kinds of questions, you should at least mention what operating system you're running. 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 Sun Jan 26 14:16:54 2014 From: wk at gnupg.org (Werner Koch) Date: Sun, 26 Jan 2014 14:16:54 +0100 Subject: time delay unlock private key. In-Reply-To: <52E3AF03.2060208@riseup.net> (shmick@riseup.net's message of "Sat, 25 Jan 2014 23:33:07 +1100") References: <87y526ydg6.fsf@gilgamesch.quim.ucm.es> <20140123102032.Horde.AH1D1Vo4ncRZKQedmdqLxQ9@mail.sixdemonbag.org> <87wqhqa34l.fsf@vigenere.g10code.de> <52E38465.8050900@riseup.net> <87a9ek8efx.fsf@vigenere.g10code.de> <52E3AF03.2060208@riseup.net> Message-ID: <8761p6992x.fsf@vigenere.g10code.de> On Sat, 25 Jan 2014 13:33, shmick at riseup.net said: >>> $ gpg-connect-agent 'getinfo s2k_count' /bye >>> ERR 280 not implemented >> >> You are using GnuPG version < 2.0.15. > > $ gpg2 --version > gpg (GnuPG) 2.0.22 Gnome-keyring or Seahorse gpg-agent connection hijacking active? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From oub at mat.ucm.es Mon Jan 27 10:51:19 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Mon, 27 Jan 2014 10:51:19 +0100 Subject: RFC3156: "application/pgp-keys" support enigmail, gnus etc Message-ID: <87iot5g3c8.fsf@mat.ucm.es> Hi according to http://tools.ietf.org/html/rfc3156 A pgpmime signed message contains lines such as Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" While an attached key should look like Content-Type: application/pgp-keys Required parameters: none Optional parameters: none A MIME body part of the content type "application/pgp-keys" contains ASCII-armored transferable Public Key Packets as defined in [1], section 10.1. I just implemented such a feature for gnus in Xemacs, but it seems that enigmail does not recognise the key! Does anybody know whether other MUA support this format? thanks Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From oub at mat.ucm.es Mon Jan 27 21:02:27 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Mon, 27 Jan 2014 21:02:27 +0100 Subject: pgp export private key with password Message-ID: <877g9lb3cc.fsf@mat.ucm.es> Hello I just tried out iPGmail a app for the iPhone which supports pgp. However I want to import my private key and here the trouble starts. For some reason iPGmail only supports private keys in armor format which are password protected. But gpg --export-secret-keys --passphrase hallo --armor > oub2.asc Did not really add a passphrase, since I could import oub2.asc as a different user, without being asked the password. Any advice is strongly appreciated. Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From dshaw at jabberwocky.com Mon Jan 27 21:12:20 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 27 Jan 2014 15:12:20 -0500 Subject: pgp export private key with password In-Reply-To: <877g9lb3cc.fsf@mat.ucm.es> References: <877g9lb3cc.fsf@mat.ucm.es> Message-ID: <119B191E-1A65-4517-A82A-3282B8972E44@jabberwocky.com> On Jan 27, 2014, at 3:02 PM, Uwe Brauer wrote: > Hello > > I just tried out iPGmail a app for the iPhone which supports > pgp. However I want to import my private key and here the trouble > starts. For some reason iPGmail only supports private keys in armor > format which are password protected. > > But > gpg --export-secret-keys --passphrase hallo --armor > oub2.asc > > Did not really add a passphrase, since I could import oub2.asc as a > different user, without being asked the password. I'm not sure I understand what you're trying to do. --export-secret-keys doesn't add or remove a passphrase. If the key has a passphrase, the exported one still does. If the key has no passphrase, neither does the exported one. If your secret key has a passphrase, then "--armor --export-secret-keys xxxxx" generates an armored key file with a passphrase. David From oub at mat.ucm.es Mon Jan 27 21:26:00 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Mon, 27 Jan 2014 21:26:00 +0100 Subject: pgp export private key with password References: <877g9lb3cc.fsf@mat.ucm.es> <119B191E-1A65-4517-A82A-3282B8972E44__7311.91031304679$1390853624$gmane$org@jabberwocky.com> Message-ID: <87y5219non.fsf@mat.ucm.es> >> "David" == David Shaw writes: > On Jan 27, 2014, at 3:02 PM, Uwe Brauer wrote: >> Hello >> >> I just tried out iPGmail a app for the iPhone which supports >> pgp. However I want to import my private key and here the trouble >> starts. For some reason iPGmail only supports private keys in armor >> format which are password protected. >> >> But >> gpg --export-secret-keys --passphrase hallo --armor > oub2.asc >> >> Did not really add a passphrase, since I could import oub2.asc as a >> different user, without being asked the password. > I'm not sure I understand what you're trying to do. > --export-secret-keys doesn't add or remove a passphrase. If the key > has a passphrase, the exported one still does. If the key has no > passphrase, neither does the exported one. Right there is a misunderstanding. What you say is of course correct so during exportation and importation no password is asked, however when I want to *use* the key then I must provide the password. However it seems that the application expects for some reason another a password during the import process. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From dshaw at jabberwocky.com Mon Jan 27 21:40:28 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 27 Jan 2014 15:40:28 -0500 Subject: pgp export private key with password In-Reply-To: <87y5219non.fsf@mat.ucm.es> References: <877g9lb3cc.fsf@mat.ucm.es> <119B191E-1A65-4517-A82A-3282B8972E44__7311.91031304679$1390853624$gmane$org@jabberwocky.com> <87y5219non.fsf@mat.ucm.es> Message-ID: <1E0C5454-134F-4B68-BF64-F3E221A8C385@jabberwocky.com> On Jan 27, 2014, at 3:26 PM, Uwe Brauer wrote: >>> "David" == David Shaw writes: > >> On Jan 27, 2014, at 3:02 PM, Uwe Brauer wrote: >>> Hello >>> >>> I just tried out iPGmail a app for the iPhone which supports >>> pgp. However I want to import my private key and here the trouble >>> starts. For some reason iPGmail only supports private keys in armor >>> format which are password protected. >>> >>> But >>> gpg --export-secret-keys --passphrase hallo --armor > oub2.asc >>> >>> Did not really add a passphrase, since I could import oub2.asc as a >>> different user, without being asked the password. > >> I'm not sure I understand what you're trying to do. >> --export-secret-keys doesn't add or remove a passphrase. If the key >> has a passphrase, the exported one still does. If the key has no >> passphrase, neither does the exported one. > > Right there is a misunderstanding. What you say is of course correct > so during exportation and importation no password is asked, however when > I want to *use* the key then I must provide the password. > > However it seems that the application expects for some reason another a > password during the import process. Interesting. I wonder why it does that - perhaps it stores the key unencrypted internally? What happens if you provide your regular key passphrase to the app on import? David From dkg at fifthhorseman.net Mon Jan 27 22:05:41 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 27 Jan 2014 16:05:41 -0500 Subject: RFC3156: "application/pgp-keys" support enigmail, gnus etc In-Reply-To: <87iot5g3c8.fsf@mat.ucm.es> References: <87iot5g3c8.fsf@mat.ucm.es> Message-ID: <52E6CA25.2080103@fifthhorseman.net> Hi Uwe-- On 01/27/2014 04:51 AM, Uwe Brauer wrote: > Hi according to > http://tools.ietf.org/html/rfc3156 > > > A pgpmime signed message contains lines such as > > Content-Type: multipart/signed; boundary="=-=-="; > micalg=pgp-sha1; protocol="application/pgp-signature" > > While an attached key should look like > Content-Type: application/pgp-keys > Required parameters: none > Optional parameters: none > > A MIME body part of the content type "application/pgp-keys" contains > ASCII-armored transferable Public Key Packets as defined in [1], > section 10.1. > > I just implemented such a feature for gnus in Xemacs, but it seems that > enigmail does not recognise the key! Does anybody know whether other MUA > support this format? This seems like a question you'd want to ask the MUAs themselsves. when you say "enigmail does not recognize the key", how did you test it? in icedove+enigmail 1.6, if i right-click on an attachment that is of type application/pgp-keys, i get a menu option "Import OpenPGP Key", which seems like it does what you would want to do with an e-mailed key. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jan 28 00:10:21 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jan 2014 00:10:21 +0100 Subject: RFC3156: "application/pgp-keys" support enigmail, gnus etc In-Reply-To: <87iot5g3c8.fsf@mat.ucm.es> (Uwe Brauer's message of "Mon, 27 Jan 2014 10:51:19 +0100") References: <87iot5g3c8.fsf@mat.ucm.es> Message-ID: <87vbx558de.fsf@vigenere.g10code.de> On Mon, 27 Jan 2014 10:51, oub at mat.ucm.es said: > I just implemented such a feature for gnus in Xemacs, but it seems that I think "gpg --import" is easier to remember .-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From oub at mat.ucm.es Mon Jan 27 21:51:48 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Mon, 27 Jan 2014 21:51:48 +0100 Subject: pgp export private key with password References: <877g9lb3cc.fsf@mat.ucm.es> <119B191E-1A65-4517-A82A-3282B8972E44__7311.91031304679$1390853624$gmane$org@jabberwocky.com> <87y5219non.fsf@mat.ucm.es> <1E0C5454-134F-4B68-BF64-F3E221A8C385@jabberwocky.com> Message-ID: <87ob2x9mhn.fsf@mat.ucm.es> >> "David" == David Shaw writes: >> >> However it seems that the application expects for some reason another a >> password during the import process. > Interesting. I wonder why it does that - perhaps it stores the key > unencrypted internally? What happens if you provide your regular key > passphrase to the app on import? It does not work. It seems that the only possibility is to edit my key, delete the password and import. However I don't know yet how the private key is protected within the application.. I am still discussing with the author. Uwe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From oub at mat.ucm.es Tue Jan 28 12:21:07 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Tue, 28 Jan 2014 12:21:07 +0100 Subject: RFC3156: "application/pgp-keys" support enigmail, gnus etc References: <87iot5g3c8.fsf@mat.ucm.es> <52E6CA25.2080103@fifthhorseman.net> Message-ID: <8738k8e4ik.fsf@gilgamesch.quim.ucm.es> >> "Daniel" == Daniel Kahn Gillmor writes: > Hi Uwe-- >> >> I just implemented such a feature for gnus in Xemacs, but it seems that >> enigmail does not recognise the key! Does anybody know whether other MUA >> support this format? > This seems like a question you'd want to ask the MUAs themselsves. > when you say "enigmail does not recognize the key", how did you test it? > in icedove+enigmail 1.6, if i right-click on an attachment that is of > type application/pgp-keys, i get a menu option "Import OpenPGP Key", > which seems like it does what you would want to do with an e-mailed key. Ok I tested it now with seamonkey 2.21 (or TB 17) +enigmail 1.6 and it works as you described. I think at home I am running TB11+enigmail 1.4, so I will upgrade. Thanks. Uwe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From meganbwinkler at yahoo.com Tue Jan 28 12:44:58 2014 From: meganbwinkler at yahoo.com (Megan Winkler) Date: Tue, 28 Jan 2014 03:44:58 -0800 (PST) Subject: Configuring gpg-agent to run in Windows Message-ID: <1390909498.90306.YahooMailNeo@web162603.mail.bf1.yahoo.com> I would like to decrypt files in batch mode using GPG2 on a Windows 7 machine. ??I have GPG4Win, version 2.2.1 installed. I have so far been unable to make it work. I suspect I haven't configured the gpg-agent properly as I get the following error when I try to cache the passphrase: C:\GnuPG>gpg-agent --daemon --allow-preset-passphrase --write-env-file --batch --debug-level 9 -vv gpg-agent[21568]: enabled debug flags: command mpi crypto memory cache memstat a ssuan gpg-agent[21568]: listening on socket `C:\Users\Megan\AppData\Roaming\gnupg\S.gp g-agent' set GPG_AGENT_INFO=C:\Users\Megan\AppData\Roaming\gnupg\S.gpg-agent;21568;1 gpg-agent[21568]: gpg-agent (GnuPG) 2.0.22 started gpg-agent[21568]: DBG: returning notify handle 00000100 gpg-agent[21568]: handler 0x544c for fd 268 started gpg-agent[21568]: chan_0000010C -> OK Pleased to meet you gpg-agent[21568]: chan_0000010C <- PRESET_PASSPHRASE 2C7C06CF44E5B9B58023F24A44D CB856B29B6933 -1 6661697468 gpg-agent[21568]: DBG: agent_put_cache `2C7C06CF44E5B9B58023F24A44DCB856B29B6933 ' requested ttl=-1 mode=1 gpg-agent[21568]: chan_0000010C -> OK gpg-agent[21568]: chan_0000010C <- [error: Input/output error] gpg-agent[21568]: Assuan processing failed: Input/output error gpg-agent[21568]: handler 0x544c for fd 268 terminated Any ideas would be appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: From oub at mat.ucm.es Tue Jan 28 15:37:36 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Tue, 28 Jan 2014 15:37:36 +0100 Subject: old pgp2.6x keys imported in gpg (compile pgp 2.6) Message-ID: <87lhy0cgun.fsf@gilgamesch.quim.ucm.es> Hello I have a problem to import my secret key into a iOS app called iPGmail. The problem is that of course the key is password protected and the app seem to have difficulties with the password. So I just deleted the password and then can import the secret key, but I don't like this possibility and so I deleted my key. The cipher for the key protection is CAST5 However the key was originally generated with pgp 2.6.2 more than 10 years ago (yes I know it is only 1024 bit long and should not be used anymore), but could it be that such a key has some incompatibilities with RFC 4880?? I just tried to compile old 2.62 on kubuntu 10.04 but failed, does anybody has a suggestion? thanks Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From dshaw at jabberwocky.com Tue Jan 28 16:11:45 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 28 Jan 2014 10:11:45 -0500 Subject: old pgp2.6x keys imported in gpg (compile pgp 2.6) In-Reply-To: <87lhy0cgun.fsf@gilgamesch.quim.ucm.es> References: <87lhy0cgun.fsf@gilgamesch.quim.ucm.es> Message-ID: On Jan 28, 2014, at 9:37 AM, Uwe Brauer wrote: > Hello > > I have a problem to import my secret key into a iOS app called iPGmail. > > The problem is that of course the key is password protected and the app > seem to have difficulties with the password. > > So I just deleted the password and then can import the secret key, but I > don't like this possibility and so I deleted my key. > > The cipher for the key protection is CAST5 > > However the key was originally generated with pgp 2.6.2 more than 10 > years ago (yes I know it is only 1024 bit long and should not be used > anymore), but could it be that such a key has some incompatibilities > with RFC 4880?? Yes and no. PGP 2.6.2 keys (version 3 keys) are compatible with RFC-4880, but that does not necessarily mean that every implementation supports them. Version 3 key support is optional in the standard, so it is possible that the iPGmail app only supports OpenPGP (version 4) keys. (Frankly, if I was writing a OpenPGP program today, I'd probably leave out version 3 support as well). David From vedaal at nym.hush.com Tue Jan 28 16:48:13 2014 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 28 Jan 2014 10:48:13 -0500 Subject: old pgp2.6x keys imported in gpg (compile pgp 2.6) In-Reply-To: <87lhy0cgun.fsf@gilgamesch.quim.ucm.es> Message-ID: <20140128154814.06E30A00E8@smtp.hushmail.com> On Tuesday, January 28, 2014 at 9:43 AM, "Uwe Brauer" wrote: >The cipher for the key protection is CAST5 > >However the key was originally generated with pgp 2.6.2 more than >10 >years ago (yes I know it is only 1024 bit long and should not be >used >anymore), but could it be that such a key has some >incompatibilities >with RFC 4880?? ===== NO key generated in PGP 2.x has anything other than IDEA as the cipher for key protection. (It is *possible* to construct such a key using Disastry's version of 2.6.3 multi x, but it would not be the default). It may be more likely that the key was imported into some version of GnuPG, after removing its password in PGP 2.x, and then GnuPG supplied its default cipher of CAST 5 when the passphrase was re-entered. >I just tried to compile old 2.62 on kubuntu 10.04 but failed, does >anybody has a suggestion? I couldn't compile Disastry's version either on Ubuntu, but was able to import the unix PGP he compiled on his website, into Ubuntu without problems. Here is the re-creation of his website: http://www.spywarewarrior.com/uiuc/disastry/263multi.htm His version allows all the ciphers GnuPG uses except for Camelia. vedaal From oub at mat.ucm.es Tue Jan 28 17:15:49 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Tue, 28 Jan 2014 17:15:49 +0100 Subject: default (secret) key for gpg Message-ID: <87y520qdze.fsf@gilgamesch.quim.ucm.es> Hello Finally I decided to generate a new 4096 keypair. Now gpg --list-keys tells me I have sec 1024R/93B61FDD 1998-09-17 uid Uwe Brauer uid Uwe Brauer uid Uwe Brauer uid Uwe Brauer sec 4096R/65AD077A 2014-01-28 uid Uwe Brauer (Second Key) ssb 4096R/F7D25222 2014-01-28 So I want to use the new key as default (For Xemacs and maybe this is an addional problem) So I added to the files in .gnupg - gpg.conf: default-key 65AD077A - options: default-key 65AD077A (I even rebooted to restart the gpg-agent). But xemacs, gnus, epg always picks up the old key. I will write to that list as well, but would like to know if there is anything wrong in my setting. thanks Uwe Brauer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Tue Jan 28 17:25:54 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 28 Jan 2014 17:25:54 +0100 Subject: old pgp2.6x keys imported in gpg (compile pgp 2.6) In-Reply-To: <87lhy0cgun.fsf@gilgamesch.quim.ucm.es> References: <87lhy0cgun.fsf@gilgamesch.quim.ucm.es> Message-ID: <52E7DA12.3090607@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/28/2014 03:37 PM, Uwe Brauer wrote: > Hello > > I have a problem to import my secret key into a iOS app called > iPGmail. > > The problem is that of course the key is password protected and the > app seem to have difficulties with the password. ... > > However the key was originally generated with pgp 2.6.2 more than > 10 years ago (yes I know it is only 1024 bit long and should not be > used anymore), but could it be that such a key has some > incompatibilities with RFC 4880?? I seem to recall a similar issue when first trying to use an old PGP 2.6 key to decrypt some files due to two leading checksum bytes. Looking through my archive [0,1] seems to confirm this, so might be of some help for you as well. [0] http://www.kfwebs.com/gnupg-2.0.4-idea.patch [1] http://www.kfwebs.net/articles/article/42/GnuPG-2.0---IDEA-support - -- - ---------------------------- 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 - ---------------------------- Acta est fabula So ends the story -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS59oOAAoJEPw7F94F4Tag0mQP/i7Ne25SdF/FchdtUbSgfoVU 9rBrtXOrx26/XxsdZR/j2d+LbyS32Yo+i2zq/oJYjhxWL4IH37fvKwxlLsi2qHP/ spcRlwhonNGoz24zvK4dpmyVJBtbfdo2sjJFUgmupG2LkinIRyPyIbfLxHHu8hui wpoe+GriaVAZkKFnyXtCIKXIAMnFcxhxjWK7kUZWlgVvs7RTF0dex7SbU7H85oE7 XdN5npkv8UQkuCiP4rX1PeJ6cLZGyOqNZ2I8m66cFrks7JtxntUOq5ndwjrIjRBW xSM3LOeCCO95JTWxNauXgZjFZzXbWTDbcg6qVKnKO4yWLAigFNvjj5EFP+170RUu ua/BNZ0DRae2yJ1iNICzUSVW0VCr3dhyrEwfoz2fM5veYO56f21HuoDHglPdoZGP ZP3OgZHgxPk9P7juzhxlRzrMrzlY7V26nr2HAGrVJcV9c3SQH7a0CgwmyH9N/rPs Hn+pQkVvtxfusdHT8UbtqZNM/CTiC/oaRFeEGPv+O0ovFVEg7fY1zSbHzn/CoFOV ian90taS/QDzD2o+PW2TvnPBJOW8rgLCvzAEhEiJ8Ll0F/hLjh52d1JdHlJO3DCj Afldwi6dRkW19VgAzfAWLnK6j8L6ZmstbycBJ07zU+IYZFKcxrZAZSrAmpMFERcC +zecACkEmhvjV+TR/EGK =ukRb -----END PGP SIGNATURE----- From oub at mat.ucm.es Tue Jan 28 19:13:55 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Tue, 28 Jan 2014 19:13:55 +0100 Subject: old pgp2.6x keys imported in gpg (compile pgp 2.6) References: <87lhy0cgun.fsf@gilgamesch.quim.ucm.es> <52E7DA12.3090607__12402.898775372$1390929719$gmane$org@sumptuouscapital.com> Message-ID: <87zjmgoty4.fsf@gilgamesch.quim.ucm.es> >> "Kristian" == Kristian Fiskerstrand writes: > http://www.kfwebs.net/articles/article/42/GnuPG-2.0---IDEA-support > <#secure method=smime mode=sign> cool, thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From ekleog at gmail.com Tue Jan 28 20:13:30 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Tue, 28 Jan 2014 20:13:30 +0100 Subject: Non email addresses in UID In-Reply-To: <20140124230816.6ec33e69@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> Message-ID: <20140128191330.GA21473@leortable> On Fri, Jan 24, 2014 at 11:08:16PM +0000, Steve Jones wrote: > [...] > > Finally there's the possibility of explicit verification, if someone > sends me a challenge and I publish that challenge's signature on my > blog then that verifies that I am in control of that private key and > can publish to that blog. > > [...] Wouldn't it be better to publish unencrypted (and unsigned) a challenge received encrypted? As signing unknown data should be avoided, as noone knows whether this data won't ever have a real meaning one does not intend to mean. Hope this message is not syntactically flawed to the point of being meaningless, Leo From wk at gnupg.org Tue Jan 28 21:35:14 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jan 2014 21:35:14 +0100 Subject: default (secret) key for gpg In-Reply-To: <87y520qdze.fsf@gilgamesch.quim.ucm.es> (Uwe Brauer's message of "Tue, 28 Jan 2014 17:15:49 +0100") References: <87y520qdze.fsf@gilgamesch.quim.ucm.es> Message-ID: <871tzr4zgd.fsf@vigenere.g10code.de> On Tue, 28 Jan 2014 17:15, oub at mat.ucm.es said: > - gpg.conf: default-key 65AD077A > > - options: default-key 65AD077A Do not use "options" - it has been replaced by gpg.conf so long ago that I barely remember that file. > (I even rebooted to restart the gpg-agent). > But xemacs, gnus, epg always picks up the old key. I will write to that Maybe (setq mml2015-signer "0x65AD077A") Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From John at enigmail.net Tue Jan 28 23:41:05 2014 From: John at enigmail.net (John Clizbe) Date: Tue, 28 Jan 2014 16:41:05 -0600 Subject: trying to find a folder In-Reply-To: <20140125214047.GA16288@efikamx> References: <20140125214047.GA16288@efikamx> Message-ID: <52E83201.8040600@enigmail.net> fa-ml wrote: > On Fri, Jan 24, 2014 at 04:37:11PM -0800, Justin Quakenbush wrote: >> wheres my gnupg folder? >> > > Have you tried checking 'man gpg' (search for 'FILES')? It should be > ~/.gnupg/ , echo $GNUPGHOME to make sure. GNUPGHOME isn't set by default. It is for overriding the default location. 'gpg --version' or 'gpgconf --list-dirs' will give one the location being used. -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 475 bytes Desc: OpenPGP digital signature URL: From steve at secretvolcanobase.org Wed Jan 29 00:37:25 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Tue, 28 Jan 2014 23:37:25 +0000 Subject: Non email addresses in UID In-Reply-To: <20140128191330.GA21473@leortable> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> <20140128191330.GA21473@leortable> Message-ID: <20140128233725.6b12b3d0@steves-laptop> On Tue, 28 Jan 2014 20:13:30 +0100 Leo Gaspard wrote: > On Fri, Jan 24, 2014 at 11:08:16PM +0000, Steve Jones wrote: > > [...] > > > > Finally there's the possibility of explicit verification, if someone > > sends me a challenge and I publish that challenge's signature on my > > blog then that verifies that I am in control of that private key and > > can publish to that blog. > > > > [...] > > Wouldn't it be better to publish unencrypted (and unsigned) a challenge received > encrypted? As signing unknown data should be avoided, as noone knows whether > this data won't ever have a real meaning one does not intend to mean. The challenge would not need to be the sole content of the message that is signed, so long as it is contained in the signed content. A simple human readable message to the effect that the signature is for response to a challenge should suffice. A more sophisticated approach would be for OpenPGP to include a new signature type for this purpose. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From John at enigmail.net Tue Jan 28 23:34:40 2014 From: John at enigmail.net (John Clizbe) Date: Tue, 28 Jan 2014 16:34:40 -0600 Subject: trying to find a folder In-Reply-To: References: Message-ID: <52E83080.9080207@enigmail.net> Justin Quakenbush wrote: > wheres my gnupg folder? On Mac OS X (you're using Applemail) and other *nix platforms, it is ~/.gnupg, which is a shortcut for $HOME/.gnupg. A directory named .gnupg in your main user folder. Since the name begins with '.' it is normally hid from Finder and other file managers. On Windows, GnuPG's files are stored by default in %APPDATA%\GnuPG. This usually translates as - Window XP and earlier (XP/2000/NT) - C:\Documents and Settings\\Application Data\GnuPG - Windows Vista and Windows 7: C:\Users\\AppData\Roaming\gnupg In either of the above, the default location may be overridden by setting the environment variable GNUPGHOME. -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 475 bytes Desc: OpenPGP digital signature URL: From telegraph at gmx.net Wed Jan 29 10:31:57 2014 From: telegraph at gmx.net (Gregor Zattler) Date: Wed, 29 Jan 2014 10:31:57 +0100 Subject: MUA "automatically signs keys"? (was: Re: Non email addresses in UID) In-Reply-To: <20140124230816.6ec33e69@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> Message-ID: <20140129093157.GB23625@boo.workgroup> Hi Steve, gnupg users, * Steve Jones [24. Jan. 2014]: > Which reminds me that I'd really like an email client that > automatically signs keys at level 1 (persona) of anyone who replies > with a signed email that quotes a significant portion of the text I > sent, as this effectively counts as a challenge response protocol in my > book. That's an interesting idea. But there is still the possibility of a man in the middle attac... The web of trust is supposed to counter MITM attacks by signing keys only if the verification was done directly (no middle person). Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- From oub at mat.ucm.es Wed Jan 29 12:07:07 2014 From: oub at mat.ucm.es (Uwe Brauer) Date: Wed, 29 Jan 2014 12:07:07 +0100 Subject: default (secret) key for gpg References: <87y520qdze.fsf@gilgamesch.quim.ucm.es> <871tzr4zgd.fsf__19483.4561007612$1390942056$gmane$org@vigenere.g10code.de> Message-ID: <87zjmfqc6c.fsf@gilgamesch.quim.ucm.es> >> "Werner" == Werner Koch writes: > (setq mml2015-signer "0x65AD077A") The correct setting is (setq mml2015-signers (list "0x65AD077A")) Just in case.... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From nb.linux at xandea.de Wed Jan 29 12:14:11 2014 From: nb.linux at xandea.de (nb.linux) Date: Wed, 29 Jan 2014 11:14:11 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <20140129093157.GB23625@boo.workgroup> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> <20140129093157.GB23625@boo.workgroup> Message-ID: <52E8E283.2060701@xandea.de> Gregor Zattler: > Hi Steve, gnupg users, > * Steve Jones [24. Jan. 2014]: >> Which reminds me that I'd really like an email client that >> automatically signs keys at level 1 (persona) of anyone who replies >> with a signed email that quotes a significant portion of the text I >> sent, as this effectively counts as a challenge response protocol in my >> book. > > That's an interesting idea. But there is still the possibility > of a man in the middle attac... The web of trust is supposed to > counter MITM attacks by signing keys only if the verification was > done directly (no middle person). maybe you already discussed that, but what about sending someone an encrypted email (with the challenge) and wait for an encrypted reply with the signed challenge? (as you seem to talk only about sending a clear text challenge) Personally, I don't want such behaviour. When I'm making a certification, then it's me doing it manually as I have the responsibility. I don't want some program to be able to make automatized certifications with my key. Here's a quote from an email on a very similar topic: From: Robert J. Hansen Subject: Re: trust your corporation for keyowner identification? Date: 2013-10-17 13:54 -0700 >> In my proposed scenario, the corporation [e.g. HR] is doing nothing more than >> providing a means for the participants to know that Bob is actually Bob >> because the company has checked his id and said he is and providing an >> authenticated means (again, IT being a black-hat aside) to communicate >> with Bob and verify fingerprints, etc. > > Under this scenario, the entire thing is dangerously bogus. > > When I sign a certificate, I am sending a message: "I am vouching for the identity of X." Under your scenario, I'm no longer vouching for the identity of X. I would instead be saying, "Someone else who is not listed on this signature has vouched for the identity of X. I am signing this without any direct personal knowledge of X's identity." > > If you're vouching for X's identity, you need to take positive steps to verify X's identity. If someone else is vouching for X's identity, then let them sign X's certificate. Why should you get involved without doing your own positive verification? Two replies later in the thread there was Stan Tobias who clarified: > [That] you vouch that the person told you "This is my key". Making a certification is *not* a confirmation of an identity. I like the term "vouch" here, because it highlights the responsibility in the Web of Trust of the person doing the certification. Cheers, -- nb.linux From wk at gnupg.org Wed Jan 29 14:49:12 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jan 2014 14:49:12 +0100 Subject: [Announce] Libgcrypt 1.6.1 released Message-ID: <87iot2290n.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.1. This is a maintenance release to fix problems found in the recently released 1.6.0 version. Libgcrypt is a general purpose library of cryptographic building blocks. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required for proper use Libgcrypt. Noteworthy changes in version 1.6.1 (2014-01-29) ================================================ * Added emulation for broken Whirlpool code prior to 1.6.0. * Improved performance of KDF functions. * Improved ECDSA compliance. * Fixed locking for Windows and non-ELF Pthread systems (regression in 1.6.0) * Fixed message digest lookup by OID (regression in 1.6.0). * Fixed a build problem on NetBSD. * Fixed memory leaks in ECC code. * Fixed some asm build problems and feature detection bugs. * Interface changes relative to the 1.6.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_MD_FLAG_BUGEMU1 NEW (minor API change). 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 tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.bz2 (2413k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.gz (2872k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.1.tar.gz.sig Alternativley you may upgrade using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0-1.6.1.diff.bz2 (244k) In order to check that the version of Libgcrypt you are going to build is an original and unmodified one, you can do it in one of the following ways: * Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.6.1.tar.bz2 you would use this command: gpg --verify libgcrypt-1.6.1.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 the release signing key 4F25E3B6 which is certified by my well known key 1E42B367. To retrieve the keys you may use the command "gpg --fetch-key finger:wk at g10code.com". * If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.6.1.tar.bz2 and check that the output matches the first line from the following list: f03d9b63ac3b17a6972fc11150d136925b702f02 libgcrypt-1.6.1.tar.bz2 fe6d442881a28a37d16348cdbf96b41b8ef38ced libgcrypt-1.6.1.tar.gz 35d002247186884ba3730c91f196a5de48c3fcf8 libgcrypt-1.6.0-1.6.1.diff.bz2 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. Happy hacking, Werner [1] http://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] http://www.gnupg.org/service.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 steve at secretvolcanobase.org Wed Jan 29 18:24:36 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Wed, 29 Jan 2014 17:24:36 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <52E8E283.2060701@xandea.de> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> <20140129093157.GB23625@boo.workgroup> <52E8E283.2060701@xandea.de> Message-ID: <20140129172436.22bde6d2@steves-laptop> On Wed, 29 Jan 2014 11:14:11 +0000 "nb.linux" wrote: > Gregor Zattler: > > Hi Steve, gnupg users, > > * Steve Jones [24. Jan. 2014]: > > That's an interesting idea. But there is still the possibility > > of a man in the middle attac... The web of trust is supposed to > > counter MITM attacks by signing keys only if the verification was > > done directly (no middle person). > > maybe you already discussed that, but what about sending someone an > encrypted email (with the challenge) and wait for an encrypted reply > with the signed challenge? (as you seem to talk only about sending a > clear text challenge) Yes, the message being sent would have to be encrypted for the procedure to be valid, otherwise an attacker could read the mail and spoof a response (after having already spoofed your communication with the key server). > Personally, I don't want such behaviour. When I'm making a > certification, then it's me doing it manually as I have the > responsibility. I don't want some program to be able to make > automatized certifications with my key. Well, it could be semi-automatic. I'm only talking about persona certifications, which appear to be understood as verifying that the key and the email address are under the control of the same person. Having your mail client being able to determine that the key and the email address seem to match and offering you a one click (plus passphrase) option to verify that fact would be nice. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Jan 29 18:38:54 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 29 Jan 2014 18:38:54 +0100 Subject: OpenPGP key statistics Message-ID: <52E93CAE.2070302@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I got curious about the current distribution of keys available on the keyservers and wrote up a quick tool to dump some of this information[a] from SKS yesterday. Since this might be of interest for others as well I'll include some of the findings here. The full post with main results including some charts are posted in a blog entry on [0]. I hope to get around to digging a bit deeper into more information going forwards, in particular taking into consideration subkeys and expiration/revocations (I just have to figure some good metrics to look at for this), so please let me know if there are specific things that might be interesting. A snippet from the post: The overall majority (94.74%) were Version 4 keys c.f. RFC4880 with V3 keys representing 4.73% and V2 keys representing 0.53%. DSA keys represented 74.4%, while 25.6% were RSA keys and a minority ElGamal (0.03%), Elliptic Curve keys (35 keys) and keys in the experimental range (32 keys) . The key lengths spans from 3 keys in the experimental range key with algo id 103 of 224 bits to 32,768 bits (3 keys, two of which are RSA and one DSA). Due to the low occurrence of ECC keys (that have an expectation of lower key lenghts for similar expected security levels - - normally in the 256-521 bit range, although there is a strong possibility that the aforementioned 224 bits keys should also fit in this category) I have not done any adjustment for these. A full 77.4% of the keys are included when looking at the aggregate figures up to and including 1024 bits, roughly 2.7 million of the keys, and the corresponding number when looking at a 2048 and 4096 bits respectively are 95.3% and 99.95% of all keys included. Endnotes: [a] sksstats is available as a patch to the current SKS tip in my mercurial queue at https://bitbucket.org/kristianf/sks-keyserver-patches/src/tip/SKSStats?at=default References: [0] http://blog.sumptuouscapital.com/2014/01/openpgp-key-statistics/ - -- - ---------------------------- 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 - ---------------------------- Acta est fabula So ends the story -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS6TyqAAoJEPw7F94F4TagdpkQAKyDGb3ExP7pbeEt37ObrQl1 25IFJQaHFiGr2e2qoLel8d2YiW5/COyqZgYM0sE2llDvJsTVA/nr1Wm3tAX19nV2 MmOE/WzZDs9JNT5HuWCc7Twm4M6NcbxLTvvbUQ4xsV2dfRQPNDRfTBY3HZw3VPgb P16uN6ryF6Xk5YubEkt3sm+5qFKw1AJmONmnDMSQjLqfKyKnTOLcXIVA3fFFJv0i gHPlblKAI4DP00kHaF1tGQtOqBHj5LbHH7f2UHsfJwvz75T/VLg2mElqQN6LfIJh TqZrilE2a9XNZEXaPvJlMKEseQJpaQsy7vlizPJxPrq9uPCK/svHLVH2u4PQsdGc PdSl3/5cFxsnr9Z4fwV2OijuWOpTBFucNI7VqhEjt212P/bQEPbTpe5hbkKcyGFp Q+cZvyjXH8YnQxigW8oQRZUS8in+BKcEW3/qkyo1S+ZOB54Ih6Qkcmx5f9WJZFP0 0Cy4JybQJhcAXPhCxkswQf2S0QCzHcg7q6jb16Tbze7NWAMsN++CrJgBo4osGa9Q g95DKuUndIELJUjUtuaVko0VjvxZuXVrTTntWqhqw+Cie+H3o1uRvbtmDCaxk1vr oc0FdFHOsNBIr+zBvkJ3GBS30jGYSw+e2aG/RSWENkSIQDIelFr8vVnVl1vU87uL 1zBFYvMyl1hKcCCtdZra =XRAs -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Jan 29 19:52:26 2014 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 29 Jan 2014 10:52:26 -0800 Subject: MUA "automatically signs keys"? In-Reply-To: <20140129172436.22bde6d2@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> <20140129093157.GB23625@boo.workgroup> <52E8E283.2060701@xandea.de> <20140129172436.22bde6d2@steves-laptop> Message-ID: <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> > Well, it could be semi-automatic. I'm only talking about persona > certifications, which appear to be understood as verifying that the key > and the email address are under the control of the same person. I suspect the majority of GnuPG and PGP users could not tell you what a persona-level verification means. Saying they appear to be understood as X appears to me to be a dangerous bit of conjecture. From johannes at zarl.at Wed Jan 29 20:57:12 2014 From: johannes at zarl.at (Johannes Zarl) Date: Wed, 29 Jan 2014 20:57:12 +0100 Subject: MUA "automatically signs keys"? In-Reply-To: <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> Message-ID: <6757499.FAIGtOWeFj@mani> On Wednesday 29 January 2014 10:52:26 Robert J. Hansen wrote: > > Well, it could be semi-automatic. I'm only talking about persona > > certifications, which appear to be understood as verifying that the key > > and the email address are under the control of the same person. > > I suspect the majority of GnuPG and PGP users could not tell you what > a persona-level verification means. Saying they appear to be > understood as X appears to me to be a dangerous bit of conjecture. Since gnupg does equate trust level 1/persona certification to an untrusted one, that should not be a problem IMO. I like how this idea could mirror a "natural" web of trust - given proper MUA support. Under the assumption that an attacker can't reliably do a MITM attack on every message that is sent over an extended time period, you would place almost no trust in a fresh persona-certified key, but high trust in an old and frequently encountered key. The trust would grow with time (just like the trust into someone you know in real life). Cheers, Johannes From ei8fdb at ei8fdb.org Wed Jan 29 22:21:17 2014 From: ei8fdb at ei8fdb.org (Bernard Tyers - ei8fdb) Date: Wed, 29 Jan 2014 21:21:17 +0000 Subject: BoF at FOSDEM ? Message-ID: <75DBD479-91C0-45B9-BFF3-D917AE391D6A@ei8fdb.org> Hello all, I?ll be attending FOSDEM, and would be very interested in that. My interest in general is usability of PETs in general, mainly GPG and OTR enabled IM. I am interested in talking about a redesign of the HKP web interface presented to users. From reading the RFC it seems relatively straight forward in terms of interactions and so I?d like to make is slightly more informative to the lay GPG user. Saturday seems like a good day. All the best, Bernard -------------------------------------- Bernard / bluboxthief / ei8fdb If you?d like to get in touch, please do: http://me.ei8fdb.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 881 bytes Desc: Message signed with OpenPGP using GPGMail URL: From telegraph at gmx.net Wed Jan 29 18:19:10 2014 From: telegraph at gmx.net (Gregor Zattler) Date: Wed, 29 Jan 2014 18:19:10 +0100 Subject: MUA "automatically signs keys"? In-Reply-To: <52E8E283.2060701@xandea.de> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> <20140129093157.GB23625@boo.workgroup> <52E8E283.2060701@xandea.de> Message-ID: <20140129171910.GA7095@boo.workgroup> Hi nb.linux, * nb.linux [29. Jan. 2014]: > Gregor Zattler: >> * Steve Jones [24. Jan. 2014]: >>> Which reminds me that I'd really like an email client that >>> automatically signs keys at level 1 (persona) of anyone who replies >>> with a signed email that quotes a significant portion of the text I >>> sent, as this effectively counts as a challenge response protocol in my >>> book. >> >> That's an interesting idea. But there is still the possibility >> of a man in the middle attac... The web of trust is supposed to >> counter MITM attacks by signing keys only if the verification was >> done directly (no middle person). > > maybe you already discussed that, but what about sending someone an > encrypted email (with the challenge) and wait for an encrypted reply > with the signed challenge? (as you seem to talk only about sending a > clear text challenge) This would not help against a MITM -Attack. I want to send you an email, email program fetches a key with uid nb.linux at xandea.de from the server, evil organisation intercepts this, sends me key with uid nb.linux at xandea.de, I send a challenge encrypted to this key, evil organisation decrypts it rencryts it to you key, sends it to you, you sign-reply to my encrypted challenge, evil organisation intercepts it... > Personally, I don't want such behaviour. When I'm making a > certification, then it's me doing it manually as I have the > responsibility. I don't want some program to be able to make automatized > certifications with my key. me too. Ciao; Gregor From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jan 30 01:04:17 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jan 2014 00:04:17 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <6757499.FAIGtOWeFj@mani> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> Message-ID: <827754268.20140130000417@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 January 2014 at 7:57:12 PM, in , Johannes Zarl wrote: > Under the assumption > that an attacker can't reliably do a MITM attack on > every message that is sent over an extended time > period Why would that be assumed? In a corporate setting the MITM could be placed within the company's network, for a home user their ISP or email provider could be used, and for mobiles, the phone network. > , you would place almost no trust in a fresh > persona-certified key, but high trust in an old and > frequently encountered key. The older the key, the greater the opportunity for compromise. > The trust would grow with > time (just like the trust into someone you know in real > life). If a person I knew well in real life were "compromised" they are likely a poor enough actor for it to be easily-noticed. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net The second mouse gets the cheese -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLplxVXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p/PAEAMLzMDuW9+rogvLcrYKTKPZOZDyfj3CwaG+l h5IjlkH1I+wsYooLti/c8hBklE1RxHXlbDjnmjph88IAK2+hHvBtC+HUra+2BZbp KxDeYvthnSeeZ7R1Ry3yX9c7OUO4J2xAZPCVTFmmBoX06jf/nBBHQGAelmnrTF5L dXkfQPTu =8zBv -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jan 30 01:18:40 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jan 2014 00:18:40 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <20140129172436.22bde6d2@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> <20140129093157.GB23625@boo.workgroup> <52E8E283.2060701@xandea.de> <20140129172436.22bde6d2@steves-laptop> Message-ID: <1857081765.20140130001840@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 29 January 2014 at 5:24:36 PM, in , Steve Jones wrote: > Well, it could be semi-automatic. I'm only talking > about persona certifications, which appear to be > understood as verifying that the key and the email > address are under the control of the same person. > Having your mail client being able to determine that > the key and the email address seem to match and > offering you a one click (plus passphrase) option to > verify that fact would be nice. So long as the certification applied were only a local signature, I see a niche for this functionality (and the individual user can invest the resulting local signatures with any meaning they wish). As soon as those signatures are exported, it dumps more "noise" to the web of trust for no obvious gain. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Don't talk unless you can improve on the silence -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLpmmxXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pz1QD/1VQrX52KpK/kNfsZl4A3QZJWYN2CznnaZo+ d1D4y8OZ4zcQOh2fCsraR8sXHU5/U6ctgpX7sBT9BbTYFCI1zAkkpRGR3iTpXDFy RpzJ3B9LamYlS5GYR8EjK+n/wKVbPn44WcwCx17mampyk2QLq5j+g4W+xynvPc5G 6OESu2eg =8u5b -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jan 30 01:22:08 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jan 2014 00:22:08 +0000 Subject: Non email addresses in UID In-Reply-To: <20140128233725.6b12b3d0@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> <20140128191330.GA21473@leortable> <20140128233725.6b12b3d0@steves-laptop> Message-ID: <861068626.20140130002208@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 28 January 2014 at 11:37:25 PM, in , Steve Jones wrote: > A more sophisticated approach > would be for OpenPGP to include a new signature type > for this purpose. There are already more than enough signature types. Wouldn't this lend itself quite well to using a signature notation? - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net The greater the power, the more dangerous the abuse. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLpmzZXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pOPoD/jfjg+2GAHzjy9XPrU7b5LR+HZuCNpP2nzcC EImp/7oEuWTEV1l/9nuUcK9mXzt0JSOsDvALilC9HEvhW82y3vj0kPWh3oz0BCo1 uo2W+n5Q8GDRsIBDXYKkHyBIwJKac2Z++QURPcADdYtf+IJchEJP2KUcbbk5UOtq nw75NoVs =nY4e -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jan 30 01:26:09 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jan 2014 00:26:09 +0000 Subject: Non email addresses in UID In-Reply-To: <20140124230816.6ec33e69@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> Message-ID: <1345741479.20140130002609@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 24 January 2014 at 11:08:16 PM, in , Steve Jones wrote: > I'd really like an email client > that automatically signs keys at level 1 (persona) of > anyone who replies with a signed email that quotes a > significant portion of the text I sent I'm guessing you would want the automation to skip keys that signed messages messages that were replies to your mailing-list postings. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Live your life as though every day it was your last. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLpnC5XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pSAgD/3eJUrZAsUf3C7geT9RhaHNkSyAf9gUvkCMg zymBKAfLuYmuACEdKsRgrgOQfkfE53dNBEHvRb2FAs+TCexut3y+qTxsA8/3dbMp pxaFnKuwubc9bUAXfAgzK1BsjMiq6zo7zjD0+1sKXDvgyuGMfL/YxqpH03VPXyyR 9JkWdZDr =RuXo -----END PGP SIGNATURE----- From steve at secretvolcanobase.org Thu Jan 30 01:58:44 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Thu, 30 Jan 2014 00:58:44 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <827754268.20140130000417@my_localhost> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> Message-ID: <20140130005844.1f0f5b54@steves-laptop> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, 30 Jan 2014 00:04:17 +0000 MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Wednesday 29 January 2014 at 7:57:12 PM, in > , Johannes Zarl wrote: > > > > Under the assumption > > that an attacker can't reliably do a MITM attack on > > every message that is sent over an extended time > > period > > Why would that be assumed? In a corporate setting the MITM could be > placed within the company's network, for a home user their ISP or > email provider could be used, and for mobiles, the phone network. The advantage you have here though is the web of trust. 1 level 1 signature would probably be not enough, but 5, 10, 100..? There comes a point where you have to decide that a certain level of security is good enough. An attacker that can MITM not only your communications with the key server and your emails but that of all your friends can probably do a lot more than just MITM communications - like insert custom hardware into the supply chain rendering software based security useless. > > , you would place almost no trust in a fresh > > persona-certified key, but high trust in an old and > > frequently encountered key. > > The older the key, the greater the opportunity for compromise. Yes, I'd say it's the number of signatures rather than their age which would lend trust. > > The trust would grow with > > time (just like the trust into someone you know in real > > life). > > If a person I knew well in real life were "compromised" they are > likely a poor enough actor for it to be easily-noticed. Maybe, a lot of compromised actors have gotten away with it for a long time. But that's a different story, all the trust in a person's key and identity is useless if they're secretly working against you. - -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJS6aPEAAoJEEgVHtdrBwIA3cMIAOR684K06OPgZP30NeK7qu3u fdP9tq8TkwsIBRdZBFEgR6wkp9YfCu4+qGVqutn4txC+4qyVzbfhMDDFGb17DNHL PVZ3LS0w2jjjpYxU6GUbU6icn4otzqU7GUqsWjQxkjUvDeKW4vuuiz75+dLiXi5B 8SttzmogWzAazVtTVMk4h0PE3dDb8mfWuv02h/BhemfMeN10VT6YJfBhSqmevTiw 4An+GEmvMbtH0lPPRQHtTNvsz632Szp/6I3LObnDKrQWUtPVITqx8cPL3HXC0ozz BwMCaPLDlKO69qnhuzoaqkHBfJ4UuXTKBwfiI9+cmxiFUvyphYm6LBaw7ZmSnNQ= =WDKc -----END PGP SIGNATURE----- From steve at secretvolcanobase.org Thu Jan 30 02:06:23 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Thu, 30 Jan 2014 01:06:23 +0000 Subject: Non email addresses in UID In-Reply-To: <861068626.20140130002208@my_localhost> References: <20140123225023.3dcbe4dd@steves-laptop> <52E29FBC.5090004@fifthhorseman.net> <20140124174856.4eb1fe40@steves-laptop> <52E2E63C.3080102@fifthhorseman.net> <20140124230816.6ec33e69@steves-laptop> <20140128191330.GA21473@leortable> <20140128233725.6b12b3d0@steves-laptop> <861068626.20140130002208@my_localhost> Message-ID: <20140130010623.38dae232@steves-laptop> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, 30 Jan 2014 00:22:08 +0000 MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > On Tuesday 28 January 2014 at 11:37:25 PM, in > , Steve Jones wrote: > > > > A more sophisticated approach > > would be for OpenPGP to include a new signature type > > for this purpose. > > There are already more than enough signature types. Wouldn't this lend > itself quite well to using a signature notation? Yes, in fact a policy url may be even more appropriate. - -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJS6aWPAAoJEEgVHtdrBwIARAsH/18vWhC4H+9HZlf+t8/ITrkr gqs4nV9M30M3k3o6d/Zj0eCn15Wj0cuaAem5o3oW/owXmvaM1GBkkoqDcnNlfN8S SQwKqNW01KuFYYel9fa37ahgM6I6LrgeRj6R24MehNN1tzPas8RTCJb+WcGgaROY 9niJF0LlgqhHEptvvBgrzMRV5LY6/gXOkLULohyhG7Md4tud98TAPD68hUo/A+in wVWBnIu/Gjjva29Je5l68l40AhCRclCA6Jg2qV7pSqexkQMXHS6aJcTKuj64TKc6 u2UdUtQq+XdeP6/k3jGhTuMkxcZtq0p41RK4KTqLYF1F09e9EOq7bUK1Mtd02Ps= =Zaxx -----END PGP SIGNATURE----- From bd9439 at att.com Thu Jan 30 02:14:17 2014 From: bd9439 at att.com (DUELL, BOB) Date: Thu, 30 Jan 2014 01:14:17 +0000 Subject: Setting up shared access to gpg on a UNIX server Message-ID: Hi, I'm looking for advice and comments about how I have set up a "shared" environment on our UNIX server for gpg operations. What I have certainly works but I thought I'd ask for any comments, suggestions, or criticism. I have gpg version 1.4.14 installed on my server. I have a large number of users who exchange encrypted files with external vendors. Users in my group come and go all the time. On my server, I created a directory named /opt/app/apps/dbmprod/gpg and set the permissions to global access (777). In that directory, I created a gpg instance and created a "group" key without a passphrase (DBMktg). The public key is sent to each vendor as an email attachment when we establish the file exchange procedure. I also added the public keys from all our vendors. I set the permission on all the files in this directory to allow global "read" access (744). Set up this way, any use on the system can decrypt a file intended for use using a command like this: gpg --homedir /opt/app/apps/dbmprod/gpg --batch --no-tty --quiet --local-user "DBMktg" --output --decrypt And to encrypt a file to a particular vendor, we use this: gpg --homedir /opt/app/apps/dbmprod/gpg --batch --recipient --encrypt As I said, this has worked well for use for several years. The main advantage is that I don't need to teach any of the other users about gpg and have a central point to contain all the keys from the many vendors we support. I only need to show users the above two command sequences and they can go on about their business. I suppose that my use of a private key without a passphrase might be of some concern, but I never figured out a better way to do this. In other words, if the single key required a passphrase, I'd have to give out that passphrase to everyone, so what would be the point? I will appreciate any and all comments. If there is a "better way" to do this, I'd love to learn. Bob From ndk.clanbo at gmail.com Thu Jan 30 07:59:49 2014 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 30 Jan 2014 07:59:49 +0100 Subject: Setting up shared access to gpg on a UNIX server In-Reply-To: References: Message-ID: <52E9F865.3000801@gmail.com> Il 30/01/2014 02:14, DUELL, BOB ha scritto: > I will appreciate any and all comments. If there is a "better way" to do this, I'd love to learn. Every user in the group could "leak" the secret key. At least put it into a smartcard/token connected to the server: they'll just be able to *use* it. BYtE, Diego. From dkg at fifthhorseman.net Thu Jan 30 08:09:44 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 30 Jan 2014 02:09:44 -0500 Subject: Setting up shared access to gpg on a UNIX server In-Reply-To: <52E9F865.3000801@gmail.com> References: <52E9F865.3000801@gmail.com> Message-ID: <52E9FAB8.8010809@fifthhorseman.net> On 01/30/2014 01:59 AM, NdK wrote: > Il 30/01/2014 02:14, DUELL, BOB ha scritto: > >> I will appreciate any and all comments. If there is a "better way" to do this, I'd love to learn. > Every user in the group could "leak" the secret key. At least put it > into a smartcard/token connected to the server: they'll just be able to > *use* it. Every user in the group could also destroy the secret key, if the directory itself is still mode 777 -- write access on a directory means you can unlink files from that directory, even if you don't have write access to those files in particular. A user just has to do: rm /opt/app/apps/dbmprod/gpg/secring.gpg and it seems likely that you will be unable to decrypt any further messages (unless someone has already leaked the secret key as NdK suggests, in which case maybe you could ask them for a copy :P) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Thu Jan 30 11:49:47 2014 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 30 Jan 2014 11:49:47 +0100 Subject: Setting up shared access to gpg on a UNIX server In-Reply-To: References: Message-ID: <52EA2E4B.4080501@digitalbrains.com> On 30/01/14 02:14, DUELL, BOB wrote: > On my server, I created a directory named /opt/app/apps/dbmprod/gpg and set > the permissions to global access (777). > I set the permission on all the files in this directory to allow global > "read" access (744). If you're trying to achieve by the 744 what I think you're trying to achieve, namely that users can't change the files, I think you're mistaken[1]. Look at the following session I just did[2]: ---------------------8<------------->8--------------------- $ ll -R .: total 4 drwxrwxrwx 2 root root 4096 Jan 30 11:40 gpg ./gpg: total 4 -rwxr--r-- 1 root root 17 Jan 30 11:40 gpg.conf $ cd gpg $ cat gpg.conf intended content $ echo "unwanted addition" >>gpg.conf bash: gpg.conf: Permission denied $ cp -a gpg.conf gpg.conf.new $ echo "unwanted addition" >>gpg.conf.new $ mv gpg.conf.new gpg.conf mv: try to overwrite ?gpg.conf?, overriding mode 0744 (rwxr--r--)? y $ cat gpg.conf intended content unwanted addition $ ll total 4 -rwxr--r-- 1 peter peter 35 Jan 30 11:42 gpg.conf ---------------------8<------------->8--------------------- The thing is, you're not allowed to change any files, but you are allowed to replace those files by your own. The sticky bit might help, but I'm not sure. gpg does stuff with a bunch of files in the homedir, and I suspect that some might need the permission to overwrite files one of your other users created. I haven't thought about the rest of your setup, this is just one issue that stood out to me so I commented on that. HTH, Peter. [1] Additionally, why are all files executable? [2] ll is shorthand for "ls -l" -- 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 johannes at zarl.at Thu Jan 30 17:54:06 2014 From: johannes at zarl.at (Johannes Zarl) Date: Thu, 30 Jan 2014 17:54:06 +0100 Subject: Setting up shared access to gpg on a UNIX server In-Reply-To: <52EA2E4B.4080501@digitalbrains.com> References: <52EA2E4B.4080501@digitalbrains.com> Message-ID: <4673075.aRAKCWQEsh@mani> On Thursday 30 January 2014 11:49:47 Peter Lebbing wrote: > If you're trying to achieve by the 744 what I think you're trying to > achieve, namely that users can't change the files, I think you're > mistaken[1]. Look at the following session I just did[2]: > The thing is, you're not allowed to change any files, but you are allowed to > replace those files by your own. Just in case this isn't clear to everybody already: The write-permission on the directory are the problem here, not the 744 on the file. > gpg does stuff with a bunch of files in the homedir, and I suspect > that some might need the permission to overwrite files one of your other > users created. If one really wanted to use a shared secret key in this way (as opposed to a token), I would only share the keyrings, not the home directory. Like that (only a mockup): ls -la /opt/app/apps/dbmprod/gpg -rwxr-x--- 1 root gpgusers . -rw-r----- 1 root gpgusers secring.gpg -rw-r----- 1 root gpgusers pubring.gpg Limiting readability to a user group would at least limit the access to the key material w.r.t. unprivileged processes running on the same machine. gpg --secret-keyring /opt/app/apps/dbmprod/gpg/secring.gpg --keyring /opt/app/apps/dbmprod/gpg/pubring.gpg ... As to what Bob wrote in the original message: > I suppose that my use of a private key without a passphrase might be of some > concern, but I never figured out a better way to do this. In other words, > if the single key required a passphrase, I'd have to give out that > passphrase to everyone, so what would be the point? It might not make much of a difference, but having a strong passphrase would still protect copies of your key lying on some backup. Other than that, I guess Diego's advice is sound -- limiting the potential damage by using a token/smartcard. Johannes From 2014-667rhzu3dc-lists-groups at riseup.net Thu Jan 30 22:09:45 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Thu, 30 Jan 2014 21:09:45 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <20140130005844.1f0f5b54@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> <20140130005844.1f0f5b54@steves-laptop> Message-ID: <1479487283.20140130210945@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 30 January 2014 at 12:58:44 AM, in , Steve Jones wrote: > The advantage you have here though is the web of trust. > 1 level 1 signature would probably be not enough, but > 5, 10, 100..? If the signatures are made automatically be email software without verifying identity, where is the web of trust? Lots of such signatures would tie the key to the email address but not to a person. Email addresses, just like phone numbers, may be re-used by a different person today to who used them last year. > There comes a point where you have to > decide that a certain level of security is good enough. That is one of the points of the oft-repeated mantra "It depends on your threat model." - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Great minds discuss ideas; Average minds discuss events; Small minds discuss people. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLqv59XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pT/8EAI9tSZ3POJC+LVqut0YRQFslGcxTZlROLJUb QLfAwUTb2u0o9sla57Seqpxcop8BV9ypbTS4raPMEOjrL0t/fz5kWb6I9sNguaxf szfcOq2KLwh/KzgaWKJrDEiTPxcQk1skevohts7137E+fGk7I/aBiMqX0AJTvW+8 I56nkmBm =JI5Y -----END PGP SIGNATURE----- From ekleog at gmail.com Thu Jan 30 22:28:27 2014 From: ekleog at gmail.com (Leo Gaspard) Date: Thu, 30 Jan 2014 22:28:27 +0100 Subject: MUA "automatically signs keys"? In-Reply-To: <1479487283.20140130210945@my_localhost> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> Message-ID: <20140130212827.GA30954@leortable> On Thu, Jan 30, 2014 at 09:09:45PM +0000, MFPA wrote: > > The advantage you have here though is the web of trust. > > 1 level 1 signature would probably be not enough, but > > 5, 10, 100..? > > If the signatures are made automatically be email software without > verifying identity, where is the web of trust? Lots of such signatures > would tie the key to the email address but not to a person. Email > addresses, just like phone numbers, may be re-used by a different > person today to who used them last year. Well... To this at least I can answer. Sure, it links a key to an email address. Yet, more often than not one knows the email address of the intended recipient (otherwise, how would he/she send the email?). So knowing an email address is associated to a key can be useful. About emails reused by different persons... AFAICT most major email services never re-issue the same email address twice. Which could be considered good practice. If one worries about an email agency stealing the email addresses, well... A signature on an email UID means "Yes, this key is used by the same person as the email address". So signing it "automatically" would not conflict with the meaning of the signature. Yet if the UID also includes a name, then it should be signed only after appropriate verification of the owner. Just my two cents, Leo From johannes at zarl.at Thu Jan 30 23:03:53 2014 From: johannes at zarl.at (Johannes Zarl) Date: Thu, 30 Jan 2014 23:03:53 +0100 Subject: MUA "automatically signs keys"? In-Reply-To: <1479487283.20140130210945@my_localhost> References: <20140123225023.3dcbe4dd@steves-laptop> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> Message-ID: <1703510.WrKrPo3DPU@mani> [resent, this time to the mailing list] Hi, On Thursday 30 January 2014 21:09:45 MFPA wrote: > , Steve Jones wrote: > > The advantage you have here though is the web of trust. > > 1 level 1 signature would probably be not enough, but > > 5, 10, 100..? > > If the signatures are made automatically be email software without > verifying identity, where is the web of trust? Lots of such signatures > would tie the key to the email address but not to a person. If the same email-address is used together with the same key for a long time, it effectively ties the email-address to a person for all practical concerns. After all, you are communicating via email with someone you have never seen. Otherwise, you would have exchanged keys in person. Just take this list: I don't give a damn whether Werner Koch is the real name of that guy working on that awesome piece of software. I do care about that awesome piece of software being signed by the same Werner Koch as last year. If I needed to clarify a legal issue pertaining to the German citizen Werner K., I would prefer a key that I can link to a government-issued id. > Email addresses, just like phone numbers, may be re-used by a different > person today to who used them last year. If someone else hijacks (maliciously or not) the email address without also infiltrating that person's PC and stealing the secret key, then the key would change. If the initial communication was subject to a MITM-attack, the key would change as soon as the MITM attack stops or gets sidestepped. The quality of this "canary" improves with the number of signatures over an extended time. In either scenario, you would notice that something was afoul as soon as the key changes and investigate. The result is not perfect glorious privacy, just pretty good for the average(tm) user. Cheers, Johannes From steve at secretvolcanobase.org Thu Jan 30 23:43:39 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Thu, 30 Jan 2014 22:43:39 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <1479487283.20140130210945@my_localhost> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> Message-ID: <20140130224339.5fcb0d27@steves-laptop> On Thu, 30 Jan 2014 21:09:45 +0000 MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > On Thursday 30 January 2014 at 12:58:44 AM, in > , Steve Jones wrote: > > The advantage you have here though is the web of trust. > > 1 level 1 signature would probably be not enough, but > > 5, 10, 100..? > > If the signatures are made automatically be email software without > verifying identity, where is the web of trust? Lots of such signatures > would tie the key to the email address but not to a person. Email > addresses, just like phone numbers, may be re-used by a different > person today to who used them last year. Well therein lies my problem with the PGP system. It relies on the notion of there being this singular thing called your identity. This doesn't really match how people work in the world, it certainly doesn't match how things work online. There are plenty of people I've known for years by a particular name and using a particular email address, but by the standards of PGP I haven't verified their identity so shouldn't sign their key. In online communications so many people are just names, urls or email addresses, their identity is just the things they've said and published. If I was accepting a cheque from one of those people I'd probably look for an identity confirmation, if I just wanted to talk to them in probable privacy then a few other people saying effectively "Yeah I've used that key for that person" is enough. To put it somewhat glibly, if a friend introduces someone to you do you ask for an affidavit that your friend has seen two forms of state issued photo id before you'll talk to them? > > There comes a point where you have to > > decide that a certain level of security is good enough. > > That is one of the points of the oft-repeated mantra "It depends on > your threat model." Yes, entirely. As it stands however the standard thread model seems that we have to assume that all attackers are the NSA. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From donaldmorganjr at gmail.com Thu Jan 30 22:15:08 2014 From: donaldmorganjr at gmail.com (Donald Morgan Jr.) Date: Thu, 30 Jan 2014 13:15:08 -0800 Subject: cryptanalysis question: Does knowing some of the content of the message make the full message vulnerable to decryption? Message-ID: If you know a user has a signature that they use to always end a message with, does that data aid in the decryption of the file? Would this exploit be applicable to symmetric encryption methods as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bd9439 at att.com Fri Jan 31 01:29:13 2014 From: bd9439 at att.com (DUELL, BOB) Date: Fri, 31 Jan 2014 00:29:13 +0000 Subject: Setting up shared access to gpg on a UNIX server In-Reply-To: <4673075.aRAKCWQEsh@mani> References: <52EA2E4B.4080501@digitalbrains.com> <4673075.aRAKCWQEsh@mani> Message-ID: Hi again, Firstly, as a Windows Outlook user, I've never figured out the correct etiquette on formatting responses to list-server messages, so I'm just going to post a new message without previous references. Taking previous comments to heart, I've altered my "home directory" permissions to remove write access to every other than the owner (755). I believe this plugs the hole that would have allowed others to replace files as Peter demonstrated. The reason I allowed "write" was to overcome an error message users were getting. Apparently, gpg needs to create some file in that location. Allowing "write" permission was the first thing that came to mind when I first started using gpg and it's stayed that way for several years. I was not previously familiar with the --keyring and --secret-keyring options and I believe that helps me a lot. So now, to encrypt files: gpg --keyring /opt/app/apps/dbmprod/gpg/pubring.gpg --always-trust --no-secmem-warning --recipient I found I had to add the --always-trust option to prevent a prompt for "batch" processes. The keys are all "trusted" in my "home directory, but I didn't find an option to point to the "trustdb" file. And to decrypt a file: gpg --secret-keyring /opt/app/apps/dbmprod/gpg/secring.gpg --keyring /opt/app/apps/dbmprod/gpg/pubring.gpg --no-secmem-warning --output --decrypt .gpg It seems that since my "secring" only contains the private key used by vendors to send files to us, I do not need to actually specify the key by name. My initial testing shows it works well. How does that look? >From what I can tell, the remaining risk is that anyone can copy and use my private key because I do not have it passphrase protected. I'd be happy to add a passphrase, as long as I can figure out how to make the key easily used by any user. A couple folks (Diego and Johannes) mentioned using a smartcard or a token. I think a smartcard refers to a piece of hardware, but I don't know what a "token" means. Our server is in a datacenter and I'm sure I cannot attach any sort of hardware. I might be able to use a software only solution; I've heard something about "agents", but don't really understand any details. Can such an agent be used, one that I can start and load the key with passphrase at system startup? Thanks again for the comments; very helpful so far! Bob From 2014-667rhzu3dc-lists-groups at riseup.net Fri Jan 31 02:15:07 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 31 Jan 2014 01:15:07 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <20140130224339.5fcb0d27@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> <20140130224339.5fcb0d27@steves-laptop> Message-ID: <467167660.20140131011507@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 30 January 2014 at 10:43:39 PM, in , Steve Jones wrote: > Well therein lies my problem with the PGP system. It > relies on the notion of there being this singular thing > called your identity. I'll take that to mean your problem with the web of trust. The pedantry about verifying government-issued identity is perhaps necessary if you have the need to be confident the government knows the other person as "John Smith" and that they are the right one of the many "John Smiths" in existence. If that is not needed, the name by which any government knows the person is irrelevant. > This doesn't really match how people work in the world, it certainly > doesn't match how things work online. That's right, each context in which a person presents themself is effectively a distinct identity or persona. If the contexts overlap, there is a certain amount of blending between the distinct personas. > There are plenty of people I've > known for years by a particular name and using a > particular email address, but by the standards of PGP I > haven't verified their identity so shouldn't sign their > key. Your certification on a key means exactly what you want it to mean. If your certification is published with a key, it is up to each user to interpret that certification as they see fit (or to ignore it entirely). > In online communications so many people are just > names, urls or email addresses, their identity is just > the things they've said and published. Is that so different from the person you don't actually know, but they are sometimes on the train when you are commuting, and just occasionally you chat? > If I was > accepting a cheque from one of those people I'd > probably look for an identity confirmation, If I didn't know their name or address, depending on the amount involved I may not accept the cheque. > if I just > wanted to talk to them in probable privacy then a few > other people saying effectively "Yeah I've used that > key for that person" is enough. Is what the signature means? Are they not simply saying, in effect, "Yeah I've used that key for that _email address_?" > To put it somewhat glibly, if a friend introduces > someone to you do you ask for an affidavit that your > friend has seen two forms of state issued photo id > before you'll talk to them? Depends on the conversation. (-; > Yes, entirely. As it stands however the standard threat > model seems that we have to assume that all attackers > are the NSA. There is no standard threat model. But the NSA and others are, at least anecdotally, monitoring all communications and retaining copies if they are encrypted. And any person could come under scrutiny as a result of being only a small number of communication hops from a "person of interest." - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net Lack of money is no obstacle. Lack of an idea is an obstacle. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLq+TFXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pArAD/i8aZhsGkl2sSAP9xGiRvpv8INKKdVQ+u5bg UcXmEXkFC3f1P3fmEaWOwilS71bOwmlicWSmi6SvLBFq+rW34BTamVG6W+YVN3gp xtHdOLFptzqVmHRrBardjTfA7UYsw5hZiOU6YVjuTKVRz05YFdvGiPyOYQP7MFDg NWI5jDv4 =beUa -----END PGP SIGNATURE----- From faramir.cl at gmail.com Fri Jan 31 01:19:37 2014 From: faramir.cl at gmail.com (Faramir) Date: Thu, 30 Jan 2014 21:19:37 -0300 Subject: cryptanalysis question: Does knowing some of the content of the message make the full message vulnerable to decryption? In-Reply-To: References: Message-ID: <52EAEC19.2000603@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 30-01-2014 18:15, Donald Morgan Jr. escribi?: > If you know a user has a signature that they use to always end a > message with, does that data aid in the decryption of the file? > Would this exploit be applicable to symmetric encryption methods as > well? I think padding helps to avoid that, but I'm not sure if gpg uses padding at the symmetric encryption step. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJS6uwZAAoJEMV4f6PvczxALTgIAJjfxFm1mkl4GtmoFk33q/xg fM7H+hE0NmpeUbNanGWplS8nTWftIHsqvLlo1Z9AVsn/hE+dDy4iNBZsi7hvwskG my2RCj2lAh2oZSTL/SnKaiLUPUGc8+L8Isje94oR0n+nKhUiJX8suGqkTQaoZ2ne SGSDGz7aGHKBF1sc7mWZCj435FMza8JY3UP6S0q7GO6MpoKzOZ4DjOjKeRPwBa7n m22MZZQQ2f4HpvY0hXvrgU7y+e3fhrybSnZFX6D+oCp6o/q0VjTGFQWAoVttG7vV oJKU4X8w8E403kK/obNRIweEtHvxfL77q67HZHNTMZGvLewXDO1pGalWdyGjqDQ= =zwS+ -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Fri Jan 31 02:28:20 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 31 Jan 2014 01:28:20 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <1703510.WrKrPo3DPU@mani> References: <20140123225023.3dcbe4dd@steves-laptop> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> <1703510.WrKrPo3DPU@mani> Message-ID: <327164260.20140131012820@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 30 January 2014 at 10:03:53 PM, in , Johannes Zarl wrote: > If the same email-address is used together with the > same key for a long time, it effectively ties the > email-address to a person for all practical concerns. > After all, you are communicating via email with someone > you have never seen. Didn't two or three people on this list all use the same key to sign messages to this list a few years ago, for quite a while before anybody noticed? > If someone else hijacks (maliciously or not) the email > address without also infiltrating that person's PC and > stealing the secret key, then the key would change. Fair point. > If the initial communication was subject to a > MITM-attack, the key would change as soon as the MITM > attack stops or gets sidestepped. The quality of this > "canary" improves with the number of signatures over an > extended time. If the MITM attack lasts "an extended time" all the signatures would be on the key of the MITM-attacker... > In either scenario, you would notice that something was > afoul as soon as the key changes and investigate. You _might_ notice. > The result is not perfect glorious privacy, just pretty > good for the average(tm) user. (-; - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net A wise man once said ..."I don't know." -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLq/DtXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pJw0D/iIg2+QPC9BhsyRJUeWvr9yuw0OzGrhO0ggq kdxWyzuKRVo2PLRWUhZ6hazO4miiosOW52D5WvTb6/UDM04xK7d4fjKmOmHobbgv fioOmpUCjWGxaKDo0kour7+gqiY54QVgi6XbdeXsmvLQcDJz+9oqWT53TtEnIdSq qDyTK9DO =E4xw -----END PGP SIGNATURE----- From 2014-667rhzu3dc-lists-groups at riseup.net Fri Jan 31 02:47:31 2014 From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA) Date: Fri, 31 Jan 2014 01:47:31 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <20140130212827.GA30954@leortable> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> <20140130212827.GA30954@leortable> Message-ID: <1768248246.20140131014731@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 30 January 2014 at 9:28:27 PM, in , Leo Gaspard wrote: > About emails reused by different persons... AFAICT most > major email services never re-issue the same email > address twice. Which could be considered good practice. Yahoo does. Some of my old yahoo accounts now say this when I log in: "Your Yahoo account has been inactive for an extended period of time and is being recycled. If you need a new account, please sign up for a new one." Other, even older, yahoo accounts give "This ID is not yet taken. Are you trying to register for a new account?" > If one worries about an email agency stealing the email > addresses, well... A signature on an email UID means > "Yes, this key is used by the same person as the email > address". So signing it "automatically" would not > conflict with the meaning of the signature. Fair enough. > Yet if the > UID also includes a name, then it should be signed only > after appropriate verification of the owner. Makes sense to me. - -- Best regards MFPA mailto:2014-667rhzu3dc-lists-groups at riseup.net War is a matter of vital importance to the State. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlLrALlXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pOfsD/2s71tagOl3322f/WIbP5CaqwruiCtQO3B8f Sg3DuqmM8kNenFJgjbAq8PTf5FF4WXF/4xZasCvdPkMlgtFaCKcWgdEPo87cwBxY gEzjnZESkosq5m3vpD3PHxmeDzxP9QBp9ETuBNp745ZzcS8Oqiic3r6dfAxa5OyB PbF5ntLK =ODsN -----END PGP SIGNATURE----- From micha137 at gmx.de Fri Jan 31 08:39:07 2014 From: micha137 at gmx.de (Michael Anders) Date: Fri, 31 Jan 2014 08:39:07 +0100 Subject: cryptanalysis question: Does knowing some of the content of the message make the full message vulnerable to decryption? Message-ID: <1391153947.7050.42.camel@micha137-myAMD-CM1740> Short answer: No. This would be a form of a (partially) known plaintext attack. Semantically secure ciphers are safe against this attack and it is not possible to extract information on the key. To be precise, you may of course be able guess a lot in the plaintext domain: "Edward Snowden is a %&@?" does leak further information and could easily be "fully deciphered". But this has nothing to do with cryptography. However, in plain CBC ore counter mode(CTR) for the symmetric encryption it would be possible to change the blocks of known content against content of your liking. This is especially easy and undetectable to the recipient for CTR-mode(just XOR it out). In CBC mode it is more complicated and you would usually mess up some other parts of the decrypted message to unreadable gobbledonk. That is why you need special provisions to protect the authenticity of the cipher in transit if you are using symmetric cryptography only. In this case knowledge of the shared symmetric key is sort of proof that you are a legitimate sender. I don't know how gpg does it, in academic signature I use an hmac to protect solely symmetrically enciphered messages. There are standardized modes you might use to achieve that e.g. EAX or CCM. In an asymmetrically enciphered message it makes sense only to use digital signatures to protect the message or cipher(as opposed to the EAX, CCM or other symmetrically authenticated modes). Here the symmetric key is created on the fly for just this message and knowledge of the symmetric key alone would be no proof of anything other than that the sender is the sender. If you have a shaky system that might get disrupted by feeding it maliciously crafted information, it would make sense to asymmetrically sign the cipher and only decrypt if the signature is valid. Generally it is logically more sound to sign the content and then symmetrically encipher content and signature. Again I don't know how gpg does it. May be someone knowing the gpg internals might supply the information. Some people may disagree on the content of this last paragraph regarding usefullness of authenticated symmetric encryption in combination with asymmetric cryptography. There is even a proposed standard "ECIES" which combines asymmetric cryptography with symmetrically authenticated ciphers. I do not consider ECIES to be logically sound. If you are interested in this topic, you may have fun listening into Dan Bonehs great lectures on cryptography in coursera (for free). https://www.coursera.org/courses?orderby=upcoming&search=cryptography regards Michael Anders From free10pro at gmail.com Fri Jan 31 08:48:13 2014 From: free10pro at gmail.com (Paul R. Ramer) Date: Thu, 30 Jan 2014 23:48:13 -0800 Subject: cryptanalysis question: Does knowing some of the content of the message make the full message vulnerable to decryption? In-Reply-To: References: Message-ID: On January 30, 2014 1:15:08 PM PST, "Donald Morgan Jr." wrote: >If you know a user has a signature that they use to always end a >message >with, does that data aid in the decryption of the file? Would this >exploit >be applicable to symmetric encryption methods as well? A common form of cryptanalytic research involves trying to find a faster than brute force method of discovering a key when several plaintexts are know. The symmetric ciphers that are employed in GnuPG are, to my knowledge, very good in their resistance to cryptanalysis, including this method. Just know that no one is going to attack to the cipher itself to get to your messages. There are much easier methods such as installing a key logger. Why beat the door down if you can open the window? Cheers, --Paul -- PGP: 3DB6D884 From steve at secretvolcanobase.org Fri Jan 31 10:24:17 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Fri, 31 Jan 2014 09:24:17 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <467167660.20140131011507@my_localhost> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> <20140130224339.5fcb0d27@steves-laptop> <467167660.20140131011507@my_localhost> Message-ID: <20140131092417.6515e1b0@steves-laptop> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, 31 Jan 2014 01:15:07 +0000 MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote: > On Thursday 30 January 2014 at 10:43:39 PM, in > , Steve Jones wrote: > > > Well therein lies my problem with the PGP system. It > > relies on the notion of there being this singular thing > > called your identity. > > I'll take that to mean your problem with the web of trust. To be really pedantic the web of trust established by conventional use of the OpenPGP protocol :-P > The pedantry about verifying government-issued identity is perhaps > necessary if you have the need to be confident the government knows > the other person as "John Smith" and that they are the right one of > the many "John Smiths" in existence. If that is not needed, the > name by which any government knows the person is irrelevant. > > Your certification on a key means exactly what you want it to mean. > If your certification is published with a key, it is up to each user > to interpret that certification as they see fit (or to ignore it > entirely). Well the conventions of use, for example the key signing party protocol, requires photographic id. If I publicly sign a key it has to be in line with how I expect others to interpret it. Policies and notations on signatures go some way to alleviate that but only if the tools support it. > > In online communications so many people are just > > names, urls or email addresses, their identity is just > > the things they've said and published. > > Is that so different from the person you don't actually know, but they > are sometimes on the train when you are commuting, and just > occasionally you chat? Nope, the difference is that in real life I have good mechanisms for being sure that the person I'm talking to today is the same as the person I was talking to yesterday. To me, you are just an email address, for all I know you're a dozen different people spoofing emails to the list. If all your mails are signed with the same key then I can at least assume all those people are working in concert :-) The issue is that the tools around OpenPGP use are designed around the idea that it's for verifying some fixed identity, whereas in this case it's continuity of identity that's more important. If your key had dozens of signatures at the persona level going back a few years then I'd have a reasonable belief that you're not just a brand new identity created for mischievousness (not that I'm claiming that you're trolling, it's just an example). With notations you get a system of distributed tagging, where identity becomes a matter of a collection of attested to attributes. Obviously this could create a lot of noise so you'd have a limited set of folks (including ephemeral Internet folks) who's tags you trust, probably the same people who's signatures you trust - which is handy. :-) My mail client, and all the others I've used, is only interested in whether I, or someone else, has certified that MFPA is your real name. > > If I was > > accepting a cheque from one of those people I'd > > probably look for an identity confirmation, > > If I didn't know their name or address, depending on the amount > involved I may not accept the cheque. Certainly. This BTW is why I think anonymous cryptocurrency is a daft idea. > > if I just > > wanted to talk to them in probable privacy then a few > > other people saying effectively "Yeah I've used that > > key for that person" is enough. > > Is what the signature means? Are they not simply saying, in effect, > "Yeah I've used that key for that _email address_?" Yes, I was being sloppy there. > > To put it somewhat glibly, if a friend introduces > > someone to you do you ask for an affidavit that your > > friend has seen two forms of state issued photo id > > before you'll talk to them? > > Depends on the conversation. (-; True, "This person is a police officer and would like to know where you were last night," might lead you to wanting to see id. It would be nice to be able to cryptographically verify such things. > There is no standard threat model. But the NSA and others are, at > least anecdotally, monitoring all communications and retaining copies > if they are encrypted. And any person could come under scrutiny as a > result of being only a small number of communication hops from a > "person of interest." By standard threat model I'm extrapolating from what all the docs seem to say. It appears to be an entity with the NSA's (purported) ability to monitor and intercept the Internet but without their ability to hack endpoints. - -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJS62vBAAoJEEgVHtdrBwIAyvcIAOG+j3e83zihc8VlmdbSThg3 QUp5+iXOpw0+Jv542AOHaEsfKkNl2+1KMbbEqUVPBHmB/eMFL9tb5mz82dyUppvK j2O2QPRQhHZlmJNuy84L9X8wf01IumbpfOEdwNXvWg5l3hr8qFRaQK4bkify1+Mr Ldlpgz0GCmByoud7T4abC4xLtEkybT4H2pW9tHw/3ZZ/b6CVPzFp+PslL+J//0CW /OkSQEcQS4x6XgmOozFclcUyUdznn4mus2hPX4V8cn5ATmmT7vdVlh42sL3vVxn6 Ws7/pH0kVHj6BYoUJ5BGnYRhZJXu59SaKiMDP3581QR6gvXVq/ZdWoKkuJk2gqg= =KkmQ -----END PGP SIGNATURE----- From ndk.clanbo at gmail.com Fri Jan 31 14:35:11 2014 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 31 Jan 2014 14:35:11 +0100 Subject: Setting up shared access to gpg on a UNIX server In-Reply-To: References: <52EA2E4B.4080501@digitalbrains.com> <4673075.aRAKCWQEsh@mani> Message-ID: <52EBA68F.2000507@gmail.com> Il 31/01/2014 01:29, DUELL, BOB ha scritto: > A couple folks (Diego and Johannes) mentioned using a smartcard or a > token. I think a smartcard refers to a piece of hardware, but I > don't know what a "token" means. Our server is in a datacenter and > I'm sure I cannot attach any sort of hardware. A token is a bundle of a smartcard and a reader, and usually looks like an USB stick. If you have a dedicated (non virtual) server, usually you can ask to have a token plugged in. If you're using a virtual server, then it's harder and there are other possible attacks against your key material, as previously discussed on-list. > I might be able to use a software only solution; I've heard something > about "agents", but don't really understand any details. Can such an > agent be used, one that I can start and load the key with passphrase > at system startup? I don't know if such an agent exists. BYtE, Diego. From ndk.clanbo at gmail.com Fri Jan 31 15:02:14 2014 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 31 Jan 2014 15:02:14 +0100 Subject: MUA "automatically signs keys"? In-Reply-To: <20140131092417.6515e1b0@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> <20140130224339.5fcb0d27@steves-laptop> <467167660.20140131011507@my_localhost> <20140131092417.6515e1b0@steves-laptop> Message-ID: <52EBACE6.4090105@gmail.com> Il 31/01/2014 10:24, Steve Jones ha scritto: > Well the conventions of use, for example the key signing party > protocol, requires photographic id. If I publicly sign a key it has to > be in line with how I expect others to interpret it. Policies and > notations on signatures go some way to alleviate that but only if the > tools support it. I tried looking around for some tutorials about notations, but could only find minimal information ("it's a string in 'tag at domain=value' format"). IIUC in *my* policy I could specify that when signing a key I use "ndk at mydomain=X" notation and that X=0 means "just checked the person can access the given mailbox", X=1 means "at least 2 other persons have confirmed that the same user used that email address for the last year" and so on. Is my understanding right? When I sign a key and use a notation, am I actually signing *all* the identities associated with that key? Or just one? BYtE, Diego. From johannes at zarl.at Fri Jan 31 15:53:18 2014 From: johannes at zarl.at (Johannes Zarl) Date: Fri, 31 Jan 2014 15:53:18 +0100 Subject: MUA "automatically signs keys"? In-Reply-To: <327164260.20140131012820@my_localhost> References: <20140123225023.3dcbe4dd@steves-laptop> <1703510.WrKrPo3DPU@mani> <327164260.20140131012820@my_localhost> Message-ID: <1474503.5seCfWejBJ@mani> On Friday 31 January 2014 01:28:20 MFPA wrote: > , Johannes Zarl wrote: > > If the same email-address is used together with the > > same key for a long time, it effectively ties the > > email-address to a person for all practical concerns. > > After all, you are communicating via email with someone > > you have never seen. > > Didn't two or three people on this list all use the same key to sign > messages to this list a few years ago, for quite a while before > anybody noticed? If a mail program were to implement this automatic-persona-signature scheme, that wouldn't prevent this kind of fooling around. But I still think it could improve the awareness for this sort of thing (beyond the current state as described in xkcd: https://xkcd.com/1181/) > > If the initial communication was subject to a > > MITM-attack, the key would change as soon as the MITM > > attack stops or gets sidestepped. The quality of this > > "canary" improves with the number of signatures over an > > extended time. > > If the MITM attack lasts "an extended time" all the signatures would > be on the key of the MITM-attacker... You are right - that's the implicit problem in a system without trust-anchor: you only ever can prove that a problem occurred, not that everything is fine. Basically it's a "physical" approach instead of a "mathematical" one: in mathematics you can prove everything from a few axioms (the trust-anchor). In physics you can never be certain, but we keep watching the world and whenever we spot an inconsistency with our model we investigate. > > In either scenario, you would notice that something was > > afoul as soon as the key changes and investigate. > > You _might_ notice. If a mail program implements this (and automatic signing would need explicit support from the mail program), then it would also implement a notification. Implementing the auto-signing part without using the information for spotting problems is like implementing PGP without support for key expiration and revocation ;-) Cheers, Johannes From johannes at zarl.at Fri Jan 31 16:37:28 2014 From: johannes at zarl.at (Johannes Zarl) Date: Fri, 31 Jan 2014 16:37:28 +0100 Subject: MUA "automatically signs keys"? In-Reply-To: <1474503.5seCfWejBJ@mani> References: <20140123225023.3dcbe4dd@steves-laptop> <327164260.20140131012820@my_localhost> <1474503.5seCfWejBJ@mani> Message-ID: <2827335.8JH1iAiQW2@mani> Hi, I've meanwhile seen that others assumed the automatic-persona certification to use exportable signatures. To clarify: As far as I understood the original idea, it would use local signatures only (preferably done with a special purpose local key only used for these signatures). If one would export these signatures, that would just DDoS the key server infrastructure for no gain. Cheers, Johannes From steve at secretvolcanobase.org Fri Jan 31 16:37:42 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Fri, 31 Jan 2014 15:37:42 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <52EBACE6.4090105@gmail.com> References: <20140123225023.3dcbe4dd@steves-laptop> <20140129172436.22bde6d2@steves-laptop> <20140129105226.Horde.mBoJDwHvBxCAWAwF8v8G5Q2@mail.sixdemonbag.org> <6757499.FAIGtOWeFj@mani> <827754268.20140130000417@my_localhost> <20140130005844.1f0f5b54@steves-laptop> <1479487283.20140130210945@my_localhost> <20140130224339.5fcb0d27@steves-laptop> <467167660.20140131011507@my_localhost> <20140131092417.6515e1b0@steves-laptop> <52EBACE6.4090105@gmail.com> Message-ID: <20140131153742.29dd9c6c@steves-laptop> On Fri, 31 Jan 2014 15:02:14 +0100 NdK wrote: > Il 31/01/2014 10:24, Steve Jones ha scritto: > > > Well the conventions of use, for example the key signing party > > protocol, requires photographic id. If I publicly sign a key it has > > to be in line with how I expect others to interpret it. Policies and > > notations on signatures go some way to alleviate that but only if > > the tools support it. > I tried looking around for some tutorials about notations, but could > only find minimal information ("it's a string in 'tag at domain=value' > format"). RFC 4880 seems to be the primary documentation. > IIUC in *my* policy I could specify that when signing a key I use > "ndk at mydomain=X" notation and that X=0 means "just checked the person > can access the given mailbox", X=1 means "at least 2 other persons > have confirmed that the same user used that email address for the > last year" and so on. That's pretty much it. I wouldn't worry about tracking what other people have seen though if I were implementing a scheme like this. My thinking is more notations like "only-emailed at example.org=true". But the point of the @domain part is that anyone can implement whatever namespaces they want. > Is my understanding right? When I sign a key and use a notation, am I > actually signing *all* the identities associated with that key? Or > just one? All signatures are on particular UIDs, and notations are part of signatures, so you can sign as few or as many identities as you like. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From wk at gnupg.org Fri Jan 31 16:30:34 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Jan 2014 16:30:34 +0100 Subject: cryptanalysis question: Does knowing some of the content of the message make the full message vulnerable to decryption? In-Reply-To: <1391153947.7050.42.camel@micha137-myAMD-CM1740> (Michael Anders's message of "Fri, 31 Jan 2014 08:39:07 +0100") References: <1391153947.7050.42.camel@micha137-myAMD-CM1740> Message-ID: <87sis4w4md.fsf@vigenere.g10code.de> On Fri, 31 Jan 2014 08:39, micha137 at gmx.de said: > you are a legitimate sender. I don't know how gpg does it, in academic > signature I use an hmac to protect solely symmetrically enciphered OpenPGP defines a MDC feature to detect tampering with the encrypted message. It works by appending the SHA-1 digest to the plaintext and include it in the encryption process. On decryption the decrypted plaintext is hashed again and the digest compared to the just decrypted digest. This deliberately works without a key (as in a MAC) to provide deniability for a encrypted-only message. The MDC feature is in use for about 14 years. RFC-4880 has alo the details. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From david at systemoverlord.com Fri Jan 31 16:42:48 2014 From: david at systemoverlord.com (David Tomaschik) Date: Fri, 31 Jan 2014 07:42:48 -0800 Subject: cryptanalysis question: Does knowing some of the content of the message make the full message vulnerable to decryption? In-Reply-To: References: Message-ID: Assuming you're talking about encryption algorithms used by GnuPG, the answer is "no, these algorithms do not have publicly known known-plaintext attacks." Messages encrypted with GnuPG are always symmetrically encrypted -- when using keys, it just encrypts the random file key using RSA/DSA to allow the recipient to decrypt the message. On Thu, Jan 30, 2014 at 1:15 PM, Donald Morgan Jr. wrote: > If you know a user has a signature that they use to always end a message > with, does that data aid in the decryption of the file? Would this exploit > be applicable to symmetric encryption methods as well? > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- David Tomaschik OpenPGP: 0x5DEA789B http://systemoverlord.com david at systemoverlord.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwood at IUPUI.Edu Fri Jan 31 16:54:50 2014 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Fri, 31 Jan 2014 10:54:50 -0500 Subject: cryptanalysis question: Does knowing some of the content of the message make the full message vulnerable to decryption? In-Reply-To: References: Message-ID: <20140131155450.GC19410@IUPUI.Edu> On Thu, Jan 30, 2014 at 11:48:13PM -0800, Paul R. Ramer wrote: [snip] > Just know that no one is going to attack to the cipher itself to get to your messages. There are much easier methods such as installing a key logger. Why beat the door down if you can open the window? Well...that depends on the value of the information, the assets of the adversary, and the cost of failure. Passively capturing and analyzing your traffic from 1000km away offers little hope but also little risk. Active measures like remotely installing a software keylogger can be detected and resisted or undone. Active measures like installing a hardware keylogger can get the adversary shot dead in the act, or result in exposure that would be far more costly to his employers than the failure of his individual mission. I would likely agree that nobody is going to attack the cipher to get *my* secrets. Most people haven't got anything worth that much time and effort. The greatest expectation of reward probably lies in waiting for me to make a misteak. -- 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 steve at secretvolcanobase.org Fri Jan 31 17:09:39 2014 From: steve at secretvolcanobase.org (Steve Jones) Date: Fri, 31 Jan 2014 16:09:39 +0000 Subject: MUA "automatically signs keys"? In-Reply-To: <2827335.8JH1iAiQW2@mani> References: <20140123225023.3dcbe4dd@steves-laptop> <327164260.20140131012820@my_localhost> <1474503.5seCfWejBJ@mani> <2827335.8JH1iAiQW2@mani> Message-ID: <20140131160939.463b61ae@steves-laptop> On Fri, 31 Jan 2014 16:37:28 +0100 Johannes Zarl wrote: > As far as I understood the original idea, it would use local > signatures only (preferably done with a special purpose local key > only used for these signatures). > > If one would export these signatures, that would just DDoS the key > server infrastructure for no gain. Well I was thinking of exporting at first, but it's too fraught with problems. I would in general like to see more use of persona signatures as certifying keys as good enough. Essentially I see the requirements for certifying keys as a massive barrier to entry for common use. Greater integration of local signatures into mail clients would be great though, essentially you could use your public key ring as an address book. Currently none (AFAIK) even offer the security of the SSH known hosts file of ensuring the same key is used as from the first contact. -- Steve Jones Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From johannes at zarl.at Fri Jan 31 20:26:03 2014 From: johannes at zarl.at (Johannes Zarl) Date: Fri, 31 Jan 2014 20:26:03 +0100 Subject: MUA "automatically signs keys"? In-Reply-To: <20140131160939.463b61ae@steves-laptop> References: <20140123225023.3dcbe4dd@steves-laptop> <2827335.8JH1iAiQW2@mani> <20140131160939.463b61ae@steves-laptop> Message-ID: <1973209.QJTrt2OCcs@mani> On Friday 31 January 2014 16:09:39 Steve Jones wrote: > Well I was thinking of exporting at first, but it's too fraught with > problems. I would in general like to see more use of persona > signatures as certifying keys as good enough. Essentially I see the > requirements for certifying keys as a massive barrier to entry for > common use. My thoughts, exactly. After I tried out gpg for the first time I abandoned it mostly because there was no way I could establish a trust path between me and anyone outside my immediate physical neighborhood. Johannes