From oliver at wps-verlinden.de Tue Oct 1 19:50:26 2013 From: oliver at wps-verlinden.de (Oliver Verlinden) Date: Tue, 1 Oct 2013 19:50:26 +0200 Subject: CryptoList - Looking for beta testers In-Reply-To: <201309221911.12744.oliver@wps-verlinden.de> References: <201309221911.12744.oliver@wps-verlinden.de> Message-ID: <201310011950.26770.oliver@wps-verlinden.de> Hey guys, some days passed and I used the chance to implement further functionalities for the cryptolist software. Some minutes ago I uploaded the source code at GitHub. So you are invited to participate in this project and help in further developement and testing. ;) You can find the repository here: http://github.com/overlinden/CryptoList Best regards Oliver Verlinden -------------- 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 attila.lendvai at gmail.com Tue Oct 1 10:43:42 2013 From: attila.lendvai at gmail.com (attila lendvai) Date: Tue, 1 Oct 2013 01:43:42 -0700 (PDT) Subject: Transfer subkey to other keyring In-Reply-To: <51C9DD9A.3060707@nottheoilrig.com> References: <51C9DD9A.3060707@nottheoilrig.com> Message-ID: <1380617022445-32778.post@n7.nabble.com> FYI, i've filed a bug report: https://bugs.g10code.com/gnupg/issue1543 and got a reply that: "Merging of secret keys has never been not supported. GnuPG 2.1 has a architecture redesign which supports secret key merging. There won't be any backport." -- ? attila lendvai ? PGP: 963F 5D5F 45C7 DFCD 0A39 -- ?The more real you get the more unreal the world gets.? ? John Lennon (1940?1980) -- View this message in context: http://gnupg.10057.n7.nabble.com/Transfer-subkey-to-other-keyring-tp31272p32778.html Sent from the GnuPG - User mailing list archive at Nabble.com. From JDiaz at azdes.gov Tue Oct 1 15:01:23 2013 From: JDiaz at azdes.gov (Diaz, John, A) Date: Tue, 1 Oct 2013 13:01:23 +0000 Subject: Decrypt Issue In-Reply-To: <5244F2E4.8080309@gmail.com> References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> <522B98F4.6080108@gmail.com> <30e043faf8154cfcab7f4a63ba84b8dc@MBX03.azdes.gov> <3feb006e-b5c3-4b70-88c0-224136a3ced5@email.android.com> <7313d4e9fac54e708424d495bbc7a0c0@MBX01.azdes.gov> <5244F2E4.8080309@gmail.com> Message-ID: <9a484799368a42c08f5939443f264624@MBX01.azdes.gov> Good morning Paul. Instead of having the mainframe run a process to call the script on the server, I was able to get an answer from 'them' regarding when the file would be available, and I've scheduled the process to run on the server. All is well now. John Diaz 602-274-5359 x1284 jdiaz at azdes.gov -----Original Message----- From: Paul R. Ramer [mailto:free10pro at gmail.com] Sent: Thursday, September 26, 2013 7:52 PM To: Diaz, John, A Cc: gnupg-users at gnupg.org Subject: Re: Decrypt Issue On 09/25/2013 09:36 AM, Diaz, John, A wrote: > Spoke too soon. The wrong path was part of the problem, but I?m still having the issue: > > > Mainframe calls .bat file that calls C# application that calls second .bat file to call GnuPG to decrypt a file. Once decrypted, other stuff happens, e-mails are sent, blah, blah, blah. > > Here's the issue: When the mainframe calls the .bat file to start the process, the decryption returns: > Decrypt error :gpg: armor header: Version: GnuPG v1.4.9 (AIX) > gpg: public key is 07F7097A > gpg: encrypted with ELG-E key, ID 07F7097A > gpg: decryption failed: secret key not available > > > > If I RDP into the server with the credentials specified in the mainframe JCL, I see this from the decrypt: > > gpg: armor header: Version: GnuPG v1.4.9 (AIX) > > > > gpg: public key is 07F7097A > > gpg: using subkey 07F7097A instead of primary key AB96877A > > gpg: using subkey 07F7097A instead of primary key AB96877A > > gpg: encrypted with 2048-bit ELG key, ID 07F7097A, created 2007-05-25 > > "FMCSFTPKey " > > gpg: AES256 encrypted data > > gpg: original file name='DE-ETE-090313' > > > > What do I need to do, or have the owners of the encrypted data do, to resolve this? I do believe that your issue is caused by your script being run by your client system, and gpg is looking for the secret key on your *client* system. I think it is further indicative of this given that when you connect to server with Remote Desktop, it works. If the key is on the server and script is being run on the client, the reference to gpg in script will need to use gpg --homedir gnupg_directory_on_server. To test this, if you can edit the script that calls gpg, put a line in it to print out the value of the GNUPGHOME environment variable. Another way that you could do this is make gpg list its secret keys with gpg -v --list-secret-keys. By using -v option the first line of gpg's output will print the location of the secret keyring that is being listed. If it does not match the location of the secret key you have on your server, you have found your problem. If you do not have permission to edit the script, convince the responsible party to do himself. It is the only way you are going to know if gpg is looking in right place. When you get "secret key not available", your first recourse should be to determine if secret key you want is in your gnupg directory or if gpg is using the correct home directory. HTH. Cheers, --Paul -- PGP: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 ________________________________ NOTICE: This e-mail (and any attachments) may contain PRIVILEGED OR CONFIDENTIAL information and is intended only for the use of the specific individual(s) to whom it is addressed. It may contain information that is privileged and confidential under state and federal law. This information may be used or disclosed only in accordance with law, and you may be subject to penalties under law for improper use or further disclosure of the information in this e-mail and its attachments. If you have received this e-mail in error, please immediately notify the person named above by reply e-mail, and then delete the original e-mail. Thank you. From vedaal at nym.hush.com Tue Oct 1 19:23:33 2013 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 01 Oct 2013 13:23:33 -0400 Subject: Encrypting to a sign-only key // Is decryption possible? Message-ID: <20131001172333.AD35A20360@smtp.hushmail.com> I remember once doing this by mistake, using one of the old pgp command lines (? 6.x), where it allowed me to encrypt to a person's signing key. In the event that such a thing occurs, could gnupg decrypt it? (Is there a way for gnupg to make one's signing key, a sign and encrypt key, AFTER it was generated as 'only-sign' ? ) TIA, vedaal From peter at digitalbrains.com Tue Oct 1 19:48:16 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 01 Oct 2013 19:48:16 +0200 Subject: OpenPGP Smartcard + signing email = two signatures? In-Reply-To: <5249E8BF.3090802@heypete.com> References: <5249E8BF.3090802@heypete.com> Message-ID: <524B0AE0.3000207@digitalbrains.com> On 30/09/13 23:10, Pete Stephenson wrote: > Has anyone else observed this behavior? If so, is there an explanation? It's probably a benign bug, but it would obviously also be a reasonably good way to get signatures if somebody had compromised your PC. Put a payload in GnuPG such that when you try to sign something, it will first sign the attackers message with your first pinentry prompt, and then just prompt again for your signature. People who work with computers generally just try again if the first time mysteriously failed. This does presume that you enter your PIN on the cardreader, because otherwise it would be simpler to just use the PIN you give to the PC :). But I think it's more likely there's a little bug somewhere that loses the message. 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 free10pro at gmail.com Tue Oct 1 18:45:44 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Tue, 01 Oct 2013 09:45:44 -0700 Subject: Decrypt Issue In-Reply-To: <9a484799368a42c08f5939443f264624@MBX01.azdes.gov> References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> <522B98F4.6080108@gmail.com> <30e043faf8154cfcab7f4a63ba84b8dc@MBX03.azdes.gov> <3feb006e-b5c3-4b70-88c0-224136a3ced5@email.android.com> <7313d4e9fac54e708424d495bbc7a0c0@MBX01.azdes.gov> <5244F2E4.8080309@gmail.com> <9a484799368a42c08f5939443f264624@MBX01.azdes.gov> Message-ID: <1253ce55-0454-4226-8dbd-3ce40c4ed0df@email.android.com> "Diaz, John, A" wrote: >Good morning Paul. Instead of having the mainframe run a process to >call the script on the server, I was able to get an answer from 'them' >regarding when the file would be available, and I've scheduled the >process to run on the server. All is well now. Well, that is good to hear. I am glad your problem has been resolved. Good luck with everything else. Cheers, --Paul -- PGP: 3DB6D884 From fabio.coatti at gmail.com Wed Oct 2 15:18:44 2013 From: fabio.coatti at gmail.com (Fabio Coatti) Date: Wed, 02 Oct 2013 15:18:44 +0200 Subject: Issues when switching between smartcards Message-ID: <3423473.umbEOA4I1j@calvin> Hi all, I'm recently facing an issue: simply put, I'm unable to switch smarcards. The scenario is the followig: I have two different cards with two different set of keys. (E,S,A) I have card A inserted in smartcard reader (HP Folio 9470m build in reader) ============== [mer ott 2 14:41:28 2013] usb 2-1.8: New USB device found, idVendor=058f, idProduct=9540 [mer ott 2 14:41:28 2013] usb 2-1.8: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [mer ott 2 14:41:28 2013] usb 2-1.8: Product: EMV Smartcard Reader ============== The card is working fine. Now I get an email signed with a different card (B) and a popup tells me to switch cards. I do that, a popup appears requesting the PIN, but once entered kmail complains that it is unable to decrypt the message. after that, gpg --card-status reports "card not present" but the card is inserted. (card B) pcscd is crashed, looking at dmesg I see this: pcscd[10595]: segfault at 7f00beef8026 ip 00007f00beef8026 sp 00007f00beee7f30 error 14 in libc-2.17.so[7f00bf319000+1a0000] So I restart pcscd, then I have to kill scdaemon ... but it requires a kill -9, it seems scdaemon gets stuck. After that, a gpg --card-status works again, but if I try to decrypt again the message the decryption fails in the same way, scdaemon stuck and so on. The only effective way to get the system working again is to reboot the laptop... quite a invasive one. admittedly, it could be a hardware glitch, but this does not accounts for scdaemon lock and pcscd segfault. Tech infos: distro: gentoo Linux 3.11.3 glibc 2.17 pcscd from sys-apps/pcsc-lite-1.8.8-r1 (pcsc-lite version 1.8.8) app-crypt/gnupg-2.0.21 (gpg (GnuPG) 2.0.21 libgcrypt 1.5.3 ) Any help will be appreciated; for more information or debug just ask (with some suggestion, I'm a bit stuck here :) ) Many thanks for any answer. -- Fabio From wk at gnupg.org Wed Oct 2 17:29:30 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Oct 2013 17:29:30 +0200 Subject: key generation fails with Crypto Stick and MacOS X In-Reply-To: <524BE966.2060102@dotplex.de> ("Jan-Kaspar =?utf-8?Q?M=C3=BCn?= =?utf-8?Q?nich=22's?= message of "Wed, 02 Oct 2013 11:37:42 +0200") References: <5EC69275-FD41-4919-B49A-DEEEA1351B63@dotplex.de> <5245A48D.9050008@privacyfoundation.de> <87txh6e00a.fsf@vigenere.g10code.de> <524BE966.2060102@dotplex.de> Message-ID: <8738oj8zdx.fsf@vigenere.g10code.de> On Wed, 2 Oct 2013 11:37, jan at dotplex.de said: [I stripped date and hour from the log.] > 15:47 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 > 15:47 scdaemon[1604] DBG: response: sw=6285 datalen=0 > 15:47 scdaemon[1604] can't select application `openpgp': Not supported sw=6285 means that your card is in termination state. > 15:53 scdaemon[1604] can't select application `openpgp': Not supported > 21:01 scdaemon[1604] reader slot 0: using ccid driver You inserted the right card during these 5 minutes, right? > 21:01 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 > 21:01 scdaemon[1604] DBG: response: sw=9000 datalen=0 Now the OpenPGP application has been selected. > 21:02 scdaemon[1604] Version-2 ......: yes > 21:02 scdaemon[1604] Get-Challenge ..: yes (2048 bytes max) [...] Card info hast been gathered. > 21:03 scdaemon[1604] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=2048 em=1 > 21:03 scdaemon[1604] DBG: raw apdu: 00 47 81 00 00 00 02 B6 00 08 00 > 21:03 scdaemon[1604] DBG: response: sw=6A88 datalen=0 > 21:03 scdaemon[1604] reading public key failed: Missing item in object Running the key generation failed. The problem seems to be your card reader or the OS X USB stack. You may want to check that the card works on a Linux or Windows box. > 28:16 scdaemon[1604] reader slot 0: using ccid driver > 28:16 scdaemon[1604] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 You tried again - that does not help - there is already a problem. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jan at dotplex.de Wed Oct 2 11:37:42 2013 From: jan at dotplex.de (=?UTF-8?B?SmFuLUthc3BhciBNw7xubmljaA==?=) Date: Wed, 02 Oct 2013 11:37:42 +0200 Subject: key generation fails with Crypto Stick and MacOS X In-Reply-To: <87txh6e00a.fsf@vigenere.g10code.de> References: <5EC69275-FD41-4919-B49A-DEEEA1351B63@dotplex.de> <5245A48D.9050008@privacyfoundation.de> <87txh6e00a.fsf@vigenere.g10code.de> Message-ID: <524BE966.2060102@dotplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27.09.13 17:51, Werner Koch wrote: >> Generating keys on a Crypto Stick with GnuPG 2.0.20 and latest >> MacOS X >>> fails with an error. Attached are the logs of running scdaemon >>> with option "debug 2048". Any idea what's wrong? > Sorry, I can't see any log from scdaemon - you provided a gpg-agent > log. I've just reproduced the issue with scdaemon logging on. Please find the console input in log2.txt and the scdaemon1.log attached. Thanks, Jan-Kaspar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSS+llAAoJEOgoJPrKhpN6sScP/0Y69Wijgs6c9CQrqgA9GPMs DIz0v6UEmeXNcslMTNSNeOMmNmxoLfZH1/d8sCuBQieUb4hvWjZfbPlbhvkZDaHN NUyZ6gJnAxFPhPylH8waPu+KsTeoC9E5OHLKVqQerzoUN2dGlZokmAIc0FVmGQJ/ PtxcM0hNswSwBxOH7o6or35Qb/9b1g/PC1r4UjoS0yYD8rMcCXvcemxgTmg1H0X/ R1ySGFWN7XS+6EzcSH+U4PrjMfeYXEpqR9Gq/HDRp3EKGoCNsIbe412CVRetqyf0 a6DN8qSZtZrNKoROEuMolz9xnHbb1lCL4iheuujHirj3zgUDuHtndZ31vbrN5k5U y9/etrwEIw/GfS0ZYAFNCxFMXWoBh+waYv1CPyHNLZNDVzrD3Uw/QITHwjXc/TAG NCsI977W07uQ8VgkigSq+ELmSO+aldVYFbzQ3ABP3mP76+kM3lvgqio8ICF5POcg qnNGlZSNBNVfKbHdRlb8U02OgctyP1biJqc9Xwb75BdSFzOjTLy1FguWYyKn9DUg C/TB/x8whvbrtD3XJRLCzx4+NH17XvrOsUu1KbJdCqP/eqw8oDkB5uJO2Bq0sGj2 vhHX37TtgUqApPPSP9t/McTk2pwPs08GGkv0AY/OAV5yVkLwDPR8RUOWdsodyYXR 72H3FlHoS5RWKS6tIWk3 =rUCs -----END PGP SIGNATURE----- -------------- next part -------------- xenon:~ jan$ gpg --card-edit Application ID ...: D2760001240102000005000015FD0000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 000015FD Name of cardholder: [nicht gesetzt] Language prefs ...: de Sex ..............: unbestimmt URL of public key : [nicht gesetzt] Login data .......: [nicht gesetzt] Signature PIN ....: zwingend Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] gpg/card> admin Admin-Befehle sind erlaubt gpg/card> generate Sicherung des Verschl?sselungsschl?ssel au?erhalb der Karte erstellen? (J/n) n Bitte beachten: Die Werkseinstellung der PINs sind PIN = `123456' Admin-PIN = `12345678' Sie sollten sie mittels des Befehls --change-pin ?ndern Welche Schl?ssell?nge w?nschen Sie f?r den Signatur-Schl?ssel? (2048) Welche Schl?ssell?nge w?nschen Sie f?r den Verschl?sselungs-Schl?ssel? (2048) Welche Schl?ssell?nge w?nschen Sie f?r den Authentisierungs-Schl?ssel? (2048) Bitte w?hlen Sie, wie lange der Schl?ssel g?ltig bleiben soll. 0 = Schl?ssel verf?llt nie = Schl?ssel verf?llt nach n Tagen w = Schl?ssel verf?llt nach n Wochen m = Schl?ssel verf?llt nach n Monaten y = Schl?ssel verf?llt nach n Jahren Wie lange bleibt der Schl?ssel g?ltig? (0) Schl?ssel verf?llt nie Ist dies richtig? (j/N) j GnuPG erstellt eine User-ID um Ihren Schl?ssel identifizierbar zu machen. Ihr Name ("Vorname Nachname"): Test User Email-Adresse: test at example.org Kommentar: Sie haben diese User-ID gew?hlt: "Test User " ?ndern: (N)ame, (K)ommentar, (E)-Mail oder (F)ertig/(A)bbrechen? f gpg: key generation failed: Card error Schl?sselerzeugung fehlgeschlagen: Card error gpg: error setting forced signature PIN flag: Input/output error gpg/card> quit -------------- next part -------------- 2013-10-02 11:15:37 scdaemon[1604] listening on socket `/tmp/gpg-8UdhCE/S.scdaemon' 2013-10-02 11:15:37 scdaemon[1604] handler for fd -1 started 2013-10-02 11:15:46 scdaemon[1604] reader slot 0: using ccid driver 2013-10-02 11:15:46 scdaemon[1604] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2013-10-02 11:15:46 scdaemon[1604] updating slot 0 status: 0x0000->0x0007 (0->1) 2013-10-02 11:15:46 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-02 11:15:47 scdaemon[1604] reader slot 0: using ccid driver 2013-10-02 11:15:47 scdaemon[1604] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2013-10-02 11:15:47 scdaemon[1604] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2013-10-02 11:15:47 scdaemon[1604] DBG: response: sw=6B00 datalen=0 2013-10-02 11:15:47 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-02 11:15:47 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-02 11:15:47 scdaemon[1604] DBG: response: sw=6285 datalen=0 2013-10-02 11:15:47 scdaemon[1604] can't select application `openpgp': Not supported 2013-10-02 11:15:50 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-02 11:15:50 scdaemon[1604] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2013-10-02 11:15:50 scdaemon[1604] DBG: response: sw=6B00 datalen=0 2013-10-02 11:15:50 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-02 11:15:50 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-02 11:15:50 scdaemon[1604] DBG: response: sw=6285 datalen=0 2013-10-02 11:15:50 scdaemon[1604] can't select application `openpgp': Not supported 2013-10-02 11:15:51 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-02 11:15:51 scdaemon[1604] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2013-10-02 11:15:51 scdaemon[1604] DBG: response: sw=6B00 datalen=0 2013-10-02 11:15:51 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-02 11:15:51 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-02 11:15:51 scdaemon[1604] DBG: response: sw=6285 datalen=0 2013-10-02 11:15:51 scdaemon[1604] can't select application `openpgp': Not supported 2013-10-02 11:15:52 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-02 11:15:52 scdaemon[1604] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2013-10-02 11:15:52 scdaemon[1604] DBG: response: sw=6B00 datalen=0 2013-10-02 11:15:52 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-02 11:15:52 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-02 11:15:52 scdaemon[1604] DBG: response: sw=6285 datalen=0 2013-10-02 11:15:52 scdaemon[1604] can't select application `openpgp': Not supported 2013-10-02 11:15:52 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-02 11:15:52 scdaemon[1604] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2013-10-02 11:15:52 scdaemon[1604] DBG: response: sw=6B00 datalen=0 2013-10-02 11:15:52 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-02 11:15:52 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-02 11:15:52 scdaemon[1604] DBG: response: sw=6285 datalen=0 2013-10-02 11:15:52 scdaemon[1604] can't select application `openpgp': Not supported 2013-10-02 11:15:53 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-02 11:15:53 scdaemon[1604] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2013-10-02 11:15:53 scdaemon[1604] DBG: response: sw=6B00 datalen=0 2013-10-02 11:15:53 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-02 11:15:53 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-02 11:15:53 scdaemon[1604] DBG: response: sw=6285 datalen=0 2013-10-02 11:15:53 scdaemon[1604] can't select application `openpgp': Not supported 2013-10-02 11:21:01 scdaemon[1604] reader slot 0: using ccid driver 2013-10-02 11:21:01 scdaemon[1604] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2013-10-02 11:21:01 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-02 11:21:01 scdaemon[1604] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2013-10-02 11:21:01 scdaemon[1604] DBG: response: sw=6B00 datalen=0 2013-10-02 11:21:01 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-02 11:21:01 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-02 11:21:01 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:21:01 scdaemon[1604] DBG: dump: 2013-10-02 11:21:01 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2013-10-02 11:21:01 scdaemon[1604] DBG: raw apdu: 00 CA 00 4F 00 2013-10-02 11:21:01 scdaemon[1604] DBG: response: sw=9000 datalen=16 2013-10-02 11:21:01 scdaemon[1604] DBG: dump: D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 2013-10-02 11:21:01 scdaemon[1604] AID: D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 2013-10-02 11:21:01 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2013-10-02 11:21:01 scdaemon[1604] DBG: raw apdu: 00 CA 5F 52 00 2013-10-02 11:21:01 scdaemon[1604] DBG: response: sw=9000 datalen=10 2013-10-02 11:21:01 scdaemon[1604] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2013-10-02 11:21:01 scdaemon[1604] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2013-10-02 11:21:01 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-02 11:21:01 scdaemon[1604] DBG: raw apdu: 00 CA 00 C4 00 2013-10-02 11:21:02 scdaemon[1604] DBG: response: sw=9000 datalen=7 2013-10-02 11:21:02 scdaemon[1604] DBG: dump: 00 20 20 20 03 00 03 2013-10-02 11:21:02 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:21:02 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:21:02 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:21:02 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:21:02 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2013-10-02 11:21:02 scdaemon[1604] DBG: raw apdu: 00 CA 00 5E 00 2013-10-02 11:21:02 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:21:02 scdaemon[1604] DBG: dump: 2013-10-02 11:21:02 scdaemon[1604] Version-2 ......: yes 2013-10-02 11:21:02 scdaemon[1604] Get-Challenge ..: yes (2048 bytes max) 2013-10-02 11:21:02 scdaemon[1604] Key-Import .....: yes 2013-10-02 11:21:02 scdaemon[1604] Change-Force-PW1: yes 2013-10-02 11:21:02 scdaemon[1604] Private-DOs ....: yes 2013-10-02 11:21:02 scdaemon[1604] Algo-Attr-Change: yes 2013-10-02 11:21:02 scdaemon[1604] SM-Support .....: no 2013-10-02 11:21:02 scdaemon[1604] Max-Cert3-Len ..: 2048 2013-10-02 11:21:02 scdaemon[1604] Max-Cmd-Data ...: 2048 2013-10-02 11:21:02 scdaemon[1604] Max-Rsp-Data ...: 2048 2013-10-02 11:21:02 scdaemon[1604] Cmd-Chaining ...: no 2013-10-02 11:21:02 scdaemon[1604] Ext-Lc-Le ......: yes 2013-10-02 11:21:02 scdaemon[1604] Status Indicator: 05 2013-10-02 11:21:02 scdaemon[1604] GnuPG-No-Sync ..: no 2013-10-02 11:21:02 scdaemon[1604] GnuPG-Def-PW2 ..: no 2013-10-02 11:21:02 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:21:02 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:21:02 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:21:02 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:21:02 scdaemon[1604] Key-Attr-sign ..: RSA, n=2048, e=32, fmt=std 2013-10-02 11:21:02 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:21:02 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:21:02 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:21:02 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:21:02 scdaemon[1604] Key-Attr-encr ..: RSA, n=2048, e=32, fmt=std 2013-10-02 11:21:02 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:21:02 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:21:02 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:21:02 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:21:02 scdaemon[1604] Key-Attr-auth ..: RSA, n=2048, e=32, fmt=std 2013-10-02 11:21:02 scdaemon[1604] updating slot 0 status: 0x0007->0x0007 (1->2) 2013-10-02 11:21:02 scdaemon[1604] sending signal 31 to client 240 2013-10-02 11:21:02 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=65 lc=-1 le=256 em=0 2013-10-02 11:21:02 scdaemon[1604] DBG: raw apdu: 00 CA 00 65 00 2013-10-02 11:21:02 scdaemon[1604] DBG: response: sw=9000 datalen=11 2013-10-02 11:21:02 scdaemon[1604] DBG: dump: 5B 00 5F 2D 02 64 65 5F 35 01 39 2013-10-02 11:21:02 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=5F p2=50 lc=-1 le=256 em=0 2013-10-02 11:21:02 scdaemon[1604] DBG: raw apdu: 00 CA 5F 50 00 2013-10-02 11:21:02 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:21:02 scdaemon[1604] DBG: dump: 2013-10-02 11:21:02 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:21:02 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:21:03 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:21:03 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:21:03 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-02 11:21:03 scdaemon[1604] DBG: raw apdu: 00 CA 00 C4 00 2013-10-02 11:21:03 scdaemon[1604] DBG: response: sw=9000 datalen=7 2013-10-02 11:21:03 scdaemon[1604] DBG: dump: 00 20 20 20 03 00 03 2013-10-02 11:21:03 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=7A lc=-1 le=256 em=0 2013-10-02 11:21:03 scdaemon[1604] DBG: raw apdu: 00 CA 00 7A 00 2013-10-02 11:21:03 scdaemon[1604] DBG: response: sw=9000 datalen=5 2013-10-02 11:21:03 scdaemon[1604] DBG: dump: 93 03 00 00 00 2013-10-02 11:21:03 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=01 p2=01 lc=-1 le=256 em=0 2013-10-02 11:21:03 scdaemon[1604] DBG: raw apdu: 00 CA 01 01 00 2013-10-02 11:21:03 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:21:03 scdaemon[1604] DBG: dump: 2013-10-02 11:21:03 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=01 p2=02 lc=-1 le=256 em=0 2013-10-02 11:21:03 scdaemon[1604] DBG: raw apdu: 00 CA 01 02 00 2013-10-02 11:21:03 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:21:03 scdaemon[1604] DBG: dump: 2013-10-02 11:21:03 scdaemon[1604] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=2048 em=1 2013-10-02 11:21:03 scdaemon[1604] DBG: raw apdu: 00 47 81 00 00 00 02 B6 00 08 00 2013-10-02 11:21:03 scdaemon[1604] DBG: response: sw=6A88 datalen=0 2013-10-02 11:21:03 scdaemon[1604] reading public key failed: Missing item in object 2013-10-02 11:21:03 scdaemon[1604] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=2048 em=1 2013-10-02 11:21:03 scdaemon[1604] DBG: raw apdu: 00 47 81 00 00 00 02 B8 00 08 00 2013-10-02 11:21:03 scdaemon[1604] DBG: response: sw=6A88 datalen=0 2013-10-02 11:21:03 scdaemon[1604] reading public key failed: Missing item in object 2013-10-02 11:21:03 scdaemon[1604] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=2048 em=1 2013-10-02 11:21:03 scdaemon[1604] DBG: raw apdu: 00 47 81 00 00 00 02 A4 00 08 00 2013-10-02 11:21:03 scdaemon[1604] DBG: response: sw=6A88 datalen=0 2013-10-02 11:21:03 scdaemon[1604] reading public key failed: Missing item in object 2013-10-02 11:28:16 scdaemon[1604] reader slot 0: using ccid driver 2013-10-02 11:28:16 scdaemon[1604] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2013-10-02 11:28:16 scdaemon[1604] DBG: response: sw=6B00 datalen=0 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-02 11:28:16 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:16 scdaemon[1604] DBG: dump: 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 CA 00 4F 00 2013-10-02 11:28:16 scdaemon[1604] DBG: response: sw=9000 datalen=16 2013-10-02 11:28:16 scdaemon[1604] DBG: dump: D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 2013-10-02 11:28:16 scdaemon[1604] AID: D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 CA 5F 52 00 2013-10-02 11:28:16 scdaemon[1604] DBG: response: sw=9000 datalen=10 2013-10-02 11:28:16 scdaemon[1604] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2013-10-02 11:28:16 scdaemon[1604] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 CA 00 C4 00 2013-10-02 11:28:16 scdaemon[1604] DBG: response: sw=9000 datalen=7 2013-10-02 11:28:16 scdaemon[1604] DBG: dump: 00 20 20 20 03 00 03 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:28:16 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:28:16 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 CA 00 5E 00 2013-10-02 11:28:16 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:16 scdaemon[1604] DBG: dump: 2013-10-02 11:28:16 scdaemon[1604] Version-2 ......: yes 2013-10-02 11:28:16 scdaemon[1604] Get-Challenge ..: yes (2048 bytes max) 2013-10-02 11:28:16 scdaemon[1604] Key-Import .....: yes 2013-10-02 11:28:16 scdaemon[1604] Change-Force-PW1: yes 2013-10-02 11:28:16 scdaemon[1604] Private-DOs ....: yes 2013-10-02 11:28:16 scdaemon[1604] Algo-Attr-Change: yes 2013-10-02 11:28:16 scdaemon[1604] SM-Support .....: no 2013-10-02 11:28:16 scdaemon[1604] Max-Cert3-Len ..: 2048 2013-10-02 11:28:16 scdaemon[1604] Max-Cmd-Data ...: 2048 2013-10-02 11:28:16 scdaemon[1604] Max-Rsp-Data ...: 2048 2013-10-02 11:28:16 scdaemon[1604] Cmd-Chaining ...: no 2013-10-02 11:28:16 scdaemon[1604] Ext-Lc-Le ......: yes 2013-10-02 11:28:16 scdaemon[1604] Status Indicator: 05 2013-10-02 11:28:16 scdaemon[1604] GnuPG-No-Sync ..: no 2013-10-02 11:28:16 scdaemon[1604] GnuPG-Def-PW2 ..: no 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:28:16 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:28:16 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:28:16 scdaemon[1604] Key-Attr-sign ..: RSA, n=2048, e=32, fmt=std 2013-10-02 11:28:16 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:28:16 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:28:17 scdaemon[1604] Key-Attr-encr ..: RSA, n=2048, e=32, fmt=std 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:28:17 scdaemon[1604] Key-Attr-auth ..: RSA, n=2048, e=32, fmt=std 2013-10-02 11:28:17 scdaemon[1604] updating slot 0 status: 0x0007->0x0007 (2->3) 2013-10-02 11:28:17 scdaemon[1604] sending signal 31 to client 240 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=65 lc=-1 le=256 em=0 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 CA 00 65 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=11 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 5B 00 5F 2D 02 64 65 5F 35 01 39 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=5F p2=50 lc=-1 le=256 em=0 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 CA 5F 50 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 CA 00 C4 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=7 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 00 20 20 20 03 00 03 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=7A lc=-1 le=256 em=0 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 CA 00 7A 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=5 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 93 03 00 00 00 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=01 p2=01 lc=-1 le=256 em=0 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 CA 01 01 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=01 p2=02 lc=-1 le=256 em=0 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 CA 01 02 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:17 scdaemon[1604] DBG: dump: 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=2048 em=1 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 47 81 00 00 00 02 B6 00 08 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=6A88 datalen=0 2013-10-02 11:28:17 scdaemon[1604] reading public key failed: Missing item in object 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=2048 em=1 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 47 81 00 00 00 02 B8 00 08 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=6A88 datalen=0 2013-10-02 11:28:17 scdaemon[1604] reading public key failed: Missing item in object 2013-10-02 11:28:17 scdaemon[1604] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=2048 em=1 2013-10-02 11:28:17 scdaemon[1604] DBG: raw apdu: 00 47 81 00 00 00 02 A4 00 08 00 2013-10-02 11:28:17 scdaemon[1604] DBG: response: sw=6A88 datalen=0 2013-10-02 11:28:17 scdaemon[1604] reading public key failed: Missing item in object 2013-10-02 11:28:26 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-02 11:28:26 scdaemon[1604] DBG: raw apdu: 00 CA 00 C4 00 2013-10-02 11:28:26 scdaemon[1604] DBG: response: sw=9000 datalen=7 2013-10-02 11:28:26 scdaemon[1604] DBG: dump: 00 20 20 20 03 00 03 2013-10-02 11:28:26 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=7A lc=-1 le=256 em=0 2013-10-02 11:28:26 scdaemon[1604] DBG: raw apdu: 00 CA 00 7A 00 2013-10-02 11:28:26 scdaemon[1604] DBG: response: sw=9000 datalen=5 2013-10-02 11:28:26 scdaemon[1604] DBG: dump: 93 03 00 00 00 2013-10-02 11:28:34 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-02 11:28:34 scdaemon[1604] DBG: raw apdu: 00 CA 00 C4 00 2013-10-02 11:28:34 scdaemon[1604] DBG: response: sw=9000 datalen=7 2013-10-02 11:28:34 scdaemon[1604] DBG: dump: 00 20 20 20 03 00 03 2013-10-02 11:28:36 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-02 11:28:36 scdaemon[1604] DBG: raw apdu: 00 CA 00 C4 00 2013-10-02 11:28:36 scdaemon[1604] DBG: response: sw=9000 datalen=7 2013-10-02 11:28:36 scdaemon[1604] DBG: dump: 00 20 20 20 03 00 03 2013-10-02 11:28:36 scdaemon[1604] 3 Admin PIN attempts remaining before card is permanently locked 2013-10-02 11:28:36 scdaemon[1604] DBG: asking for PIN '|A|Please enter the Admin PIN' 2013-10-02 11:28:40 scdaemon[1604] DBG: send apdu: c=00 i=20 p1=00 p2=83 lc=8 le=-1 em=0 2013-10-02 11:28:40 scdaemon[1604] DBG: raw apdu: 00 20 00 83 08 31 32 33 34 35 36 37 38 2013-10-02 11:28:40 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:40 scdaemon[1604] DBG: dump: 2013-10-02 11:28:40 scdaemon[1604] DBG: send apdu: c=00 i=DA p1=00 p2=C4 lc=1 le=-1 em=0 2013-10-02 11:28:40 scdaemon[1604] DBG: raw apdu: 00 DA 00 C4 01 01 2013-10-02 11:28:40 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:40 scdaemon[1604] DBG: dump: 2013-10-02 11:28:40 scdaemon[1604] DBG: asking for PIN '||Please enter the PIN' 2013-10-02 11:28:43 scdaemon[1604] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=6 le=-1 em=0 2013-10-02 11:28:43 scdaemon[1604] DBG: raw apdu: 00 20 00 82 06 31 32 33 34 35 36 2013-10-02 11:28:43 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:43 scdaemon[1604] DBG: dump: 2013-10-02 11:28:43 scdaemon[1604] DBG: send apdu: c=00 i=20 p1=00 p2=81 lc=6 le=-1 em=0 2013-10-02 11:28:43 scdaemon[1604] DBG: raw apdu: 00 20 00 81 06 31 32 33 34 35 36 2013-10-02 11:28:43 scdaemon[1604] DBG: response: sw=9000 datalen=0 2013-10-02 11:28:43 scdaemon[1604] DBG: dump: 2013-10-02 11:28:43 scdaemon[1604] operation check_pin result: Success 2013-10-02 11:29:06 scdaemon[1604] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-02 11:29:06 scdaemon[1604] DBG: raw apdu: 00 CA 00 6E 00 2013-10-02 11:29:06 scdaemon[1604] DBG: response: sw=9000 datalen=217 2013-10-02 11:29:06 scdaemon[1604] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 15 FD 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 01 20 20 20 03 00 03 C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 00 00 00 00 00 00 00 00 00 00 00 00 2013-10-02 11:29:06 scdaemon[1604] generating new key 2013-10-02 11:29:06 scdaemon[1604] please wait while key is being generated ... 2013-10-02 11:29:06 scdaemon[1604] DBG: send apdu: c=00 i=47 p1=80 p2=00 lc=2 le=2048 em=1 2013-10-02 11:29:06 scdaemon[1604] DBG: raw apdu: 00 47 80 00 00 00 02 B6 00 08 00 2013-10-02 11:29:12 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:29:12 scdaemon[1604] apdu_send_simple(0) failed: card I/O error 2013-10-02 11:29:12 scdaemon[1604] generating key failed 2013-10-02 11:29:12 scdaemon[1604] operation genkey result: Card error 2013-10-02 11:29:12 scdaemon[1604] DBG: send apdu: c=00 i=DA p1=00 p2=C4 lc=1 le=-1 em=0 2013-10-02 11:29:12 scdaemon[1604] DBG: raw apdu: 00 DA 00 C4 01 00 2013-10-02 11:29:23 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:29:23 scdaemon[1604] apdu_send_simple(0) failed: card I/O error 2013-10-02 11:29:23 scdaemon[1604] failed to set `CHV-STATUS-1': Input/output error 2013-10-02 11:31:37 scdaemon[1604] DBG: raw apdu: 00 20 00 81 08 40 40 40 40 40 40 40 40 2013-10-02 11:31:43 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:31:43 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:31:43 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:31:49 scdaemon[1604] DBG: raw apdu: 00 20 00 81 08 40 40 40 40 40 40 40 40 2013-10-02 11:31:56 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:31:56 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:31:56 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:32:04 scdaemon[1604] DBG: raw apdu: 00 20 00 81 08 40 40 40 40 40 40 40 40 2013-10-02 11:32:12 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:32:12 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:32:12 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:32:19 scdaemon[1604] DBG: raw apdu: 00 20 00 81 08 40 40 40 40 40 40 40 40 2013-10-02 11:32:26 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:32:26 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:32:26 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:32:33 scdaemon[1604] DBG: raw apdu: 00 20 00 83 08 40 40 40 40 40 40 40 40 2013-10-02 11:32:40 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:32:40 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:32:40 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:32:47 scdaemon[1604] DBG: raw apdu: 00 20 00 83 08 40 40 40 40 40 40 40 40 2013-10-02 11:32:54 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:32:54 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:32:54 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:33:01 scdaemon[1604] DBG: raw apdu: 00 20 00 83 08 40 40 40 40 40 40 40 40 2013-10-02 11:33:09 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:33:09 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:33:09 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:33:16 scdaemon[1604] DBG: raw apdu: 00 20 00 83 08 40 40 40 40 40 40 40 40 2013-10-02 11:33:23 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:33:23 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:33:23 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:33:30 scdaemon[1604] DBG: raw apdu: 00 44 00 00 2013-10-02 11:33:37 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:33:37 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:33:37 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:33:44 scdaemon[1604] DBG: raw apdu: 00 E6 00 00 2013-10-02 11:33:51 scdaemon[1604] ccid_transceive failed: (0x1000a) 2013-10-02 11:33:51 scdaemon[1604] apdu_send_direct(0) failed: card I/O error 2013-10-02 11:33:51 scdaemon[1604] apdu_send_direct failed: Checksum error 2013-10-02 11:34:30 scdaemon[1604] updating slot 0 status: 0x0007->0x0007 (3->4) 2013-10-02 11:34:30 scdaemon[1604] sending signal 31 to client 240 -------------- next part -------------- A non-text attachment was scrubbed... Name: log2.txt.sig Type: application/octet-stream Size: 543 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scdaemon1.log.sig Type: application/octet-stream Size: 543 bytes Desc: not available URL: From jan at dotplex.de Wed Oct 2 17:57:14 2013 From: jan at dotplex.de (=?iso-8859-1?Q?Jan-Kaspar_M=FCnnich?=) Date: Wed, 2 Oct 2013 17:57:14 +0200 Subject: key generation fails with Crypto Stick and MacOS X In-Reply-To: <8738oj8zdx.fsf@vigenere.g10code.de> References: <5EC69275-FD41-4919-B49A-DEEEA1351B63@dotplex.de> <5245A48D.9050008@privacyfoundation.de> <87txh6e00a.fsf@vigenere.g10code.de> <524BE966.2060102@dotplex.de> <8738oj8zdx.fsf@vigenere.g10code.de> Message-ID: <24C360FB-257E-4869-8979-A0C737890177@dotplex.de> Thanks for looking at the log! On 02.10.2013, at 17:29, Werner Koch wrote: > Running the key generation failed. The problem seems to be your card > reader or the OS X USB stack. > > You may want to check that the card works on a Linux or Windows box. It does work on on Linux and it did on earlier versions of Mac OS. But it doesn't work with 10.8 (tried it with two Macs). So is there anything I can do? Jan-Kaspar -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4145 bytes Desc: not available URL: From o.jasper at gmail.com Wed Oct 2 21:40:40 2013 From: o.jasper at gmail.com (Jasper den Ouden) Date: Wed, 02 Oct 2013 21:40:40 +0200 Subject: gpgshare; have files and a tool that sorts files by gpg alias for the purpose of serving social-network -like applications Message-ID: <524C76B8.1050001@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I feel that using overly centralized servers and organizations is a bad idea in the long run.(http://techcrunch.com/2013/08/18/the-internet-were-doing-it-wrong/) I am not the only one, there are projects like https://citizenweb.is/ However, not everyone can run servers, doing so you have to mess with routers sometimes. A requirement of a social network application is being able to communicate, and to identify aliasses. GnuPG can do the latter, and also encrypt and stuff too. So it makes sense to combine the two which other applications can use to implement some facet of a social network. I also think 'the file' should be a unit of sending data. People should be able to easily add other techniques of transferring those files like autodetecting email attachments for it, pigeons with usb sticks. I have some simple bash source code that demonstrates the idea.(I will change the name if relevant people object) https://github.com/o-jasper/gpgshare (There are descriptions on `readme.md`s there) _All it does_ is sort by gpg identity and verify/decrypt&extract into a file system. If an application is happy not being able to initiate a fetch.send of data, all it has to do is look at its directory and incorporate the news there. In addition, it might need more capability to compose data to send, putting different in different files.(different levels of private/public) The first thing i will try to use it,(and i have started figuring how to place it alongside a website) is a make system to comment/take notes and reply to them anywhere,(and specify who gets access to it) with minimum threshold-to-use -right on web pages.('anywhere' is bigger than that, but websites is a good start) Note that i tried to suggest something similar before(FTR) http://lists.gnupg.org/pipermail/gcrypt-devel/2013-July/002237.html This email is meant to get some feedback, collaborators, and maybe ideas/a start on how to actually popularize the programs that will use the system. It would be useless without co-users. However, i am open to changing the form this might be done as wel, for instance the sort-by-gpg identity is so simple that maybe it could be incorporated into the existing gpg project(and associated libraries) itself.(It doesnt really increase dependencies either, just tar) Or you might want to start the project from your side and i join you instead of vice versa.(I do think the 'just put files', and minimal touching of the distributing system of subject matters of social networking is important though) In that case i'll change the linked github to be just the comment anywhere stuff. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJSTHa4AAoJEJyFfbXiRwmSERQQAJEVLEgHHqK6GI7bww5foVtE e5pyPi7V2UQikFqhWYxDde5VCC2m7Cv8Go8CodLWiI8eTqyHJ6lRU9aBlomzOPaQ OQ8UtXZMPq5qprjTaoMEZHujFxoy4prF+erFmWeYmgFopq6F9FYsEZvJj+cX2rFy DFzouUM5n5Dqhb3zmYPW5FtISogwVwmE1tHDbLub1qtB9Tmo5J56Fe8Wr6moW8LA +yUFLwdG3lw9+qtrqA1TC5elk9QQgpIZ0utFxYrOuq7VGHcNpIksgtMkPosd2RMk eQdKLwVn9LHKJFCqwQ0PGoaZQ1Rs/CALsutByFXh49/MQEHpmmkLC9yAPKwjHKlt wbo+tXL/h7dR+bf1LgG4sGKDcyt6DYSkp09XNcH6AQbUm9IEqjrjLvH4shWUipnJ QMt3DYRpyiJ2cpVNR1BByB2VgXqD3cJqmsTrKo+YNeyBb1XVrl6wTqvtYUEkO5jf vSFUxCbiNDzEOHMRcTBNtkW5nDlOUVscm1j7GbWR0JfzKu1Fxw5dNNLwvUD3ShBU ZW0z7Dk//LCojJjLFAr69CXALE70i+ut6dOZ+NkjUxPrVKh7syhj3/HyJTa7Wg1c QTcqyMcSqdQRBcEnfDlqzxD8MpM/dDO97DQ0QUP0iKqd7WSgFzE3z2nZOUcMFdeg tKo3z1b9KxZwp5JZBU7n =+JO2 -----END PGP SIGNATURE----- From eagleeyes426 at yahoo.com Thu Oct 3 06:46:24 2013 From: eagleeyes426 at yahoo.com (mightymouse2045) Date: Wed, 2 Oct 2013 21:46:24 -0700 (PDT) Subject: GPG2 encryption options Message-ID: <1380775584103-32819.post@n7.nabble.com> Hi there, I'm wondering if gpg2 can be used to encrypt a file using a keyfile. The term keyfile is used to refer to a static file where the contents are read into gpg2 to be used as the passphrase for the encryption process. for example: ccrypt -e --keyfile ~/.somefile ~/the_file_to_be_encrypted.doc So the above ccrypt command encrypts the file_to_be_encrypted.doc with the first line take from .somefile ccrypt -d --keyfile ~/.somefile ~/the_file_to_be_encrypted.doc.ctd and the above command decrypts it.... Is this possible with gpg2? I like this because I can use random files taken from the 100,000's+ static non-changing files on my system as passwords for encrypting and decrypting files etc. I'd just prefer to be using gpg2 as I can then specify algo's hash's etc instead of being stuck with AES. There are some files I don't like having to enter a passphrase for each time due to them be accessed very frequently, but I don't want the contents of them being stored plaintext either. Regards, Peter -- View this message in context: http://gnupg.10057.n7.nabble.com/GPG2-encryption-options-tp32819.html Sent from the GnuPG - User mailing list archive at Nabble.com. From peter at digitalbrains.com Thu Oct 3 13:26:56 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 03 Oct 2013 13:26:56 +0200 Subject: GPG2 encryption options In-Reply-To: <1380775584103-32819.post@n7.nabble.com> References: <1380775584103-32819.post@n7.nabble.com> Message-ID: <524D5480.7000809@digitalbrains.com> On 03/10/13 06:46, mightymouse2045 wrote: > Is this possible with gpg2? I like this because I can use random files taken > from the 100,000's+ static non-changing files 100,000 tries for an attacker amounts to 17 bits of security. This is as little as nothing at all. > There are some files I don't like having to enter a passphrase for each time > due to them be accessed very frequently gpg-agent can remember passphrases for you. You could also look into using a smartcard. With a conventional, on-disk key, the passphrase cryptographically protects the secret key material, so it needs to be complicated to have enough entropy. With a smartcard, you only use a PIN, say 8 digits. 8 numerical digits is 27 bits of entropy, again nothing. But that's not a problem because the card locks after 3 tries; the PIN is not used as a cryptographic key. Entering an 8 digit PIN is much less work than entering a good passphrase. 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 roam at ringlet.net Thu Oct 3 13:33:32 2013 From: roam at ringlet.net (Peter Pentchev) Date: Thu, 3 Oct 2013 14:33:32 +0300 Subject: GPG2 encryption options In-Reply-To: <1380775584103-32819.post@n7.nabble.com> References: <1380775584103-32819.post@n7.nabble.com> Message-ID: <20131003113332.GA5546@straylight.m.ringlet.net> On Wed, Oct 02, 2013 at 09:46:24PM -0700, mightymouse2045 wrote: > Hi there, > > I'm wondering if gpg2 can be used to encrypt a file using a keyfile. The > term keyfile is used to refer to a static file where the contents are read > into gpg2 to be used as the passphrase for the encryption process. > > for example: > > ccrypt -e --keyfile ~/.somefile ~/the_file_to_be_encrypted.doc > > So the above ccrypt command encrypts the file_to_be_encrypted.doc with the > first line take from .somefile > > ccrypt -d --keyfile ~/.somefile ~/the_file_to_be_encrypted.doc.ctd > > and the above command decrypts it.... > > Is this possible with gpg2? I like this because I can use random files taken > from the 100,000's+ static non-changing files on my system as passwords for > encrypting and decrypting files etc. I'd just prefer to be using gpg2 as I > can then specify algo's hash's etc instead of being stuck with AES. > > There are some files I don't like having to enter a passphrase for each time > due to them be accessed very frequently, but I don't want the contents of > them being stored plaintext either. If the contents of the keyfile "looks like" a single line of text (e.g. a passphrase), then you can use gpg --symmetric (or -c for short) and pass the file in using the --passphrase-fd option. The simplest way to do it is to pass the file on the standard input and specify 0 as the number of the file descriptor for the passphrase: gpg -c --passphrase-fd 0 somefile.doc < keyfile.txt This command should create a somefile.doc.gpg file that you may later decrypt by: gpg -d --passphrase-fd 0 somefile.doc.gpg < keyfile.txt Of course, you do not have to use the standard input for this; some shells will allow you to open a new file descriptor for reading from a file: gpg -d --passphrase-fd 7 somefile.doc.gpg 7< keyfile.txt Hope this helps! 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 this sentence didn't exist, somebody would have invented it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From roam at ringlet.net Thu Oct 3 13:35:34 2013 From: roam at ringlet.net (Peter Pentchev) Date: Thu, 3 Oct 2013 14:35:34 +0300 Subject: GPG2 encryption options In-Reply-To: <20131003113332.GA5546@straylight.m.ringlet.net> References: <1380775584103-32819.post@n7.nabble.com> <20131003113332.GA5546@straylight.m.ringlet.net> Message-ID: <20131003113534.GB5546@straylight.m.ringlet.net> On Thu, Oct 03, 2013 at 02:33:32PM +0300, Peter Pentchev wrote: > On Wed, Oct 02, 2013 at 09:46:24PM -0700, mightymouse2045 wrote: > > Hi there, > > > > I'm wondering if gpg2 can be used to encrypt a file using a keyfile. The > > term keyfile is used to refer to a static file where the contents are read > > into gpg2 to be used as the passphrase for the encryption process. > > > > for example: > > > > ccrypt -e --keyfile ~/.somefile ~/the_file_to_be_encrypted.doc > > > > So the above ccrypt command encrypts the file_to_be_encrypted.doc with the > > first line take from .somefile > > > > ccrypt -d --keyfile ~/.somefile ~/the_file_to_be_encrypted.doc.ctd > > > > and the above command decrypts it.... > > > > Is this possible with gpg2? I like this because I can use random files taken > > from the 100,000's+ static non-changing files on my system as passwords for > > encrypting and decrypting files etc. I'd just prefer to be using gpg2 as I > > can then specify algo's hash's etc instead of being stuck with AES. > > > > There are some files I don't like having to enter a passphrase for each time > > due to them be accessed very frequently, but I don't want the contents of > > them being stored plaintext either. > > If the contents of the keyfile "looks like" a single line of text (e.g. > a passphrase), then you can use gpg --symmetric (or -c for short) and > pass the file in using the --passphrase-fd option. But then, of course, everything that Peter Lebbing said about caching the passphrase or using a smartcard that caches the PIN for a limited amount of time is true. I personally have never found it much trouble to have gpg-agent prompt me for my passphrase after a couple of minutes. 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 I am jealous of the first word in 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 peter at digitalbrains.com Thu Oct 3 14:09:59 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 03 Oct 2013 14:09:59 +0200 Subject: GPG2 encryption options In-Reply-To: <20131003113534.GB5546@straylight.m.ringlet.net> References: <1380775584103-32819.post@n7.nabble.com> <20131003113332.GA5546@straylight.m.ringlet.net> <20131003113534.GB5546@straylight.m.ringlet.net> Message-ID: <524D5E97.5040108@digitalbrains.com> On 03/10/13 13:35, Peter Pentchev wrote: > a smartcard that caches the PIN for a limited > amount of time Small detail: this feature is not working in the current stable versions. GnuPG 2.1 will support this. I use the following script to make the card forget its PIN: ----------8<------------------------------------>8---------- #!/bin/sh gpg-connect-agent 'SCD RESET' /bye ----------8<------------------------------------>8---------- I created this based on a message of Werner Koch to this list. Earlier, I killed the scdaemon. 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 bd9439 at att.com Thu Oct 3 18:42:08 2013 From: bd9439 at att.com (DUELL, BOB) Date: Thu, 3 Oct 2013 16:42:08 +0000 Subject: Installing new gpg versions Message-ID: Hi, I have a likely na?ve question about upgrading gpg on my UNIX (Solaris SPARC) server. Let's suppose I have an "old" version of gpg installed here: /opt/app/p1sas1c1/apps/gnupg. I installed the software using my "application" account and had my SA execute these commands as "root": ln -s /opt/app/p1sas1c1/apps/gnupg/bin/gpg /usr/local/bin/gpg; ln -s /opt/app/p1sas1c1/apps/gnupg/gpg-zip /usr/local/bin/gpg-zip; ln -s /opt/app/p1sas1c1/apps/gnupg/bin/gpgsplit /usr/local/bin/gpgsplit; ln -s /opt/app/p1sas1c1/apps/gnupg/bin/gpgv /usr/local/bin/gpgv cp -p /opt/app/p1sas1c1/apps/gnupg/share/man/man1/* /usr/local/man/man1 Now, suppose I want to upgrade to a new version. I download the source and read the INSTALL and README files on how to proceed. All good so far. My question: if I use these commands: ./configure --prefix=/opt/app/p1sas1c1/apps/gnupg make make install Should I first delete the contents of the existing target directory or will "make install" install everything correctly? It's not a big deal for me right now, because I'm building a new server for our team. I'm just writing up some simple install instructions for future reference. As a side comment, I discovered that I need to define the "umask" properly during the install process; the default value denied "read and execute" permissions to "other". I used "umask 002" to overcome this issue. If this is generally useful, perhaps the INSTALL document can be revised. Thanks, Bob From dougb at dougbarton.us Thu Oct 3 21:04:32 2013 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 03 Oct 2013 12:04:32 -0700 Subject: Installing new gpg versions In-Reply-To: References: Message-ID: <524DBFC0.7060501@dougbarton.us> On 10/03/2013 09:42 AM, DUELL, BOB wrote: > Hi, > > I have a likely na?ve question about upgrading gpg on my UNIX (Solaris SPARC) server. > > Let's suppose I have an "old" version of gpg installed here: /opt/app/p1sas1c1/apps/gnupg. I installed the software using my "application" account and had my SA execute these commands as "root": > > ln -s /opt/app/p1sas1c1/apps/gnupg/bin/gpg /usr/local/bin/gpg; > ln -s /opt/app/p1sas1c1/apps/gnupg/gpg-zip /usr/local/bin/gpg-zip; > ln -s /opt/app/p1sas1c1/apps/gnupg/bin/gpgsplit /usr/local/bin/gpgsplit; > ln -s /opt/app/p1sas1c1/apps/gnupg/bin/gpgv /usr/local/bin/gpgv > cp -p /opt/app/p1sas1c1/apps/gnupg/share/man/man1/* /usr/local/man/man1 > > Now, suppose I want to upgrade to a new version. I download the source and read the INSTALL and README files on how to proceed. All good so far. > > My question: if I use these commands: > > ./configure --prefix=/opt/app/p1sas1c1/apps/gnupg > make > make install > > Should I first delete the contents of the existing target directory Yes. > As a side comment, I discovered that I need to define the "umask" properly during the install process; the default value denied "read and execute" permissions to "other". I used "umask 002" to overcome this issue. If this is generally useful, perhaps the INSTALL document can be revised. 002 has been the default basically since day 1. People who use other than the default are expected to deal with the consequences. Doug From dougb at dougbarton.us Thu Oct 3 21:21:12 2013 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 03 Oct 2013 12:21:12 -0700 Subject: Installing new gpg versions In-Reply-To: <524DBFC0.7060501@dougbarton.us> References: <524DBFC0.7060501@dougbarton.us> Message-ID: <524DC3A8.8080004@dougbarton.us> On 10/03/2013 12:04 PM, Doug Barton wrote: > 002 has been the default basically since day 1 ... or 022, depending on who you ask. Either one should have worked for your purpose. From bd9439 at att.com Thu Oct 3 21:29:40 2013 From: bd9439 at att.com (DUELL, BOB) Date: Thu, 3 Oct 2013 19:29:40 +0000 Subject: Installing new gpg versions In-Reply-To: <524DC3A8.8080004@dougbarton.us> References: <524DBFC0.7060501@dougbarton.us> <524DC3A8.8080004@dougbarton.us> Message-ID: Well, I cannot speak about "defaults", but on my system the umask is set to 027 when I log on because I am not a "privileged user" (assigned by the /etc/profile script). I'm sure this is something special our sometimes over-zealous security people have deemed useful. I was just thinking a note about this would be useful in the INSTALL doc, but maybe it's not a big deal. Thanks much on confirming that I need to delete that target directory! Bob -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Thursday, October 03, 2013 12:21 PM To: DUELL, BOB; gnupg-users at gnupg.org Subject: Re: Installing new gpg versions On 10/03/2013 12:04 PM, Doug Barton wrote: > 002 has been the default basically since day 1 ... or 022, depending on who you ask. Either one should have worked for your purpose. From eagleeyes426 at yahoo.com Thu Oct 3 18:28:32 2013 From: eagleeyes426 at yahoo.com (Peter Humphreys) Date: Thu, 3 Oct 2013 09:28:32 -0700 (PDT) Subject: GPG2 encryption options In-Reply-To: <524D5E97.5040108@digitalbrains.com> References: <1380775584103-32819.post@n7.nabble.com> <20131003113332.GA5546@straylight.m.ringlet.net> <20131003113534.GB5546@straylight.m.ringlet.net> <524D5E97.5040108@digitalbrains.com> Message-ID: <1380817712.36897.YahooMailNeo@web140703.mail.bf1.yahoo.com> Hi Guys, Thanks for the response. I had been doing a lot more reading since posting this query and came across gpg-agent. I think that's a nice option. I've been having fun since then building the latest libgcrypt and gnupg 2.0.21 stable build, because while Ubuntu includes the 2.0.21 package, it's broken against the new version of libgcrypt (Ubuntu's libgcrypt is from 2011). So I now have gpg-agent running and I'll try that out as it can cache my passphrase which will help considerably. I also like the other option Mr Pentchev provided, and will try that out if I can successfully finish the script I'm writing to randomise it enough for my satisfaction :P With shuf I can get random bits from those 100,000+ files, taken from random directories and random files each time, the issue is of course for decryption I would have to store that passphrase the script creates somewhere to enable it to be pulled for decryption before re-encrypting it with another random passphrase. But I could definitely store that in a gpg file that's signed and encrypted against my key, that I decrypt once per session or however long gpg-agent caches my passphrase for. Is that something that I can configure on the command line for gpg-agent or the options file? Regards, Peter ________________________________ From: Peter Lebbing To: Peter Pentchev Cc: mightymouse2045 ; gnupg-users at gnupg.org Sent: Thursday, 3 October 2013 8:09 PM Subject: Re: GPG2 encryption options On 03/10/13 13:35, Peter Pentchev wrote: > a smartcard that caches the PIN for a limited > amount of time Small detail: this feature is not working in the current stable versions. GnuPG 2.1 will support this. I use the following script to make the card forget its PIN: ----------8<------------------------------------>8---------- #!/bin/sh gpg-connect-agent 'SCD RESET' /bye ----------8<------------------------------------>8---------- I created this based on a message of Werner Koch to this list. Earlier, I killed the scdaemon. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailingspublications at earthlink.net Thu Oct 3 22:48:16 2013 From: mailingspublications at earthlink.net (Alejandro Szita) Date: Thu, 3 Oct 2013 13:48:16 -0700 Subject: Customizing GPG Tools Keychain Message-ID: Dear All, I am a new member to this list, so first of all thank you so much for your time and consideration in helping me out, I hope I can return the favour in the near future. My system runs MAC OS 10.7.5, I have the GPG Tools Package installed and I am able to sign & encrypt e-mails. My question is about how to customize this package. I read somewhere else that you can remove your Private Master Key altogether from your system and use only the subkeys. Moreover, you can specialize each subkey for a particular use, such as for example: only encrypt an e-mail, only validate a code, etc... Could you please point me to a resource or article that explains in detail how to do that? Again, thanks so much for your time and consideration. Best regards, Alejandro From wk at gnupg.org Sat Oct 5 10:46:39 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2013 10:46:39 +0200 Subject: [Announce] [security fix] GnuPG 2.0.22 released Message-ID: <87eh803y1c.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.22. This is a *security fix* release and all users are advised to updated to this version. See below for the impact of the problem. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.14) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPLv3+). GnuPG-2 works best on GNU/Linux and *BSD systems but is also available for other Unices, Microsoft Windows and Mac OS X. What's New in 2.0.22 ==================== * Fixed possible infinite recursion in the compressed packet parser. [CVE-2013-4402] * Improved support for some card readers. * Prepared building with the forthcoming Libgcrypt 1.6. * Protect against rogue keyservers sending secret keys. Impact of the security problem ============================== Special crafted input data may be used to cause a denial of service against GPG (GnuPG's OpenPGP part) and some other OpenPGP implementations. All systems using GPG to process incoming data are affected. Taylor R. Campbell invented a neat trick to generate OpenPGP packages to force GPG to recursively parse certain parts of OpenPGP messages ad infinitum. As a workaround a tight "ulimit -v" setting may be used to mitigate the problem. Sample input data to trigger this problem has not yet been seen in the wild. Details of the attack will eventually be published by its inventor. A fixed release of the GnuPG 1.4 series has also been released. An updated vesion of gpg4win will be released next week. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.22 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.22.tar.bz2 (4200k) gnupg-2.0.22.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.20-2.0.22.diff.bz2 (39k) A patch file to upgrade a 2.0.20 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.22.tar.bz2 you would use this command: gpg --verify gnupg-2.0.22.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --keyserver keys.gnupg.net --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.22.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.22.tar.bz2 and check that the output matches the first line from the following list: 9ba9ee288e9bf813e0f1e25cbe06b58d3072d8b8 gnupg-2.0.22.tar.bz2 6cc51b14ed652fe7eadae25ec7cdaa6f63377525 gnupg-2.0.21-2.0.22.diff.bz2 Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Almost all mail clients support GnuPG-2. Mutt users may want to use the configure option "--enable-gpgme" during build time and put a "set use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the reworked OpenPGP support. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory at: http://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Sat Oct 5 10:56:32 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2013 10:56:32 +0200 Subject: [Announce] [security fix] GnuPG 1.4.15 released Message-ID: <877gds3xkv.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.15. This is a *security fix* release and all users are advised to updated to this version. See below for the impact of the problem. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, smartcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build, and also better portable to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.22) it comes with no support for S/MIME, Secure Shell, or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New =========== * Fixed possible infinite recursion in the compressed packet parser. [CVE-2013-4402] * Protect against rogue keyservers sending secret keys. * Use 2048 bit also as default for batch key generation. * Minor bug fixes. Impact of the security problem ============================== Special crafted input data may be used to cause a denial of service against GPG (GnuPG's OpenPGP part) and some other OpenPGP implementations. All systems using GPG to process incoming data are affected. Taylor R. Campbell invented a neat trick to generate OpenPGP packages to force GPG to recursively parse certain parts of OpenPGP messages ad infinitum. As a workaround a tight "ulimit -v" setting may be used to mitigate the problem. Sample input data to trigger this problem has not yet been seen in the wild. Details of the attack will eventually be published by its inventor. A fixed release of the GnuPG 2.0 series has also been released. Getting the Software ==================== First of all, decide whether you really need GnuPG version 1.4.x - most users are better off with the modern GnuPG 2.0.x version. Then follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.15 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.15.tar.bz2 (3569k) gnupg-1.4.15.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.15.tar.gz (4948k) gnupg-1.4.15.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.14-1.4.15.diff.bz2 (37k) A patch file to upgrade a 1.4.14 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.15.exe (1568k) gnupg-w32cli-1.4.15.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . An updated version of gpg4win is scheduled for next week. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.15.tar.bz2 you would use this command: gpg --verify gnupg-1.4.15.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com | gpg --import or using a keyserver like gpg --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.14.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.15.tar.bz2 and check that the output matches the first line from the following list: 63ebf0ab375150903c65738070e4105200197fd4 gnupg-1.4.15.tar.bz2 2881c8174c15bb86ecf2e879cb7ca22c91fbcf93 gnupg-1.4.15.tar.gz 0e3a593da55be0fb9a556513ce034e13677e5ebc gnupg-1.4.14-1.4.15.diff.bz2 1adda83f3eda5a2ac6d362c294e31fbb529a03e4 gnupg-w32cli-1.4.15.exe Internationalization ==================== GnuPG comes with support for 29 languages. The Chinese (Simple and Traditional), Czech, Danish, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish, Ukrainian, and Turkish translations are close to be complete. Support ======= A listing with commercial support offers for GnuPG is available at: http://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software take up a most of their resources. To allow them continue their work they ask to either purchase a support contract, engage them for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, donating money, spreading the word, or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From shavital at gmail.com Sat Oct 5 13:53:08 2013 From: shavital at gmail.com (Charly Avital) Date: Sat, 05 Oct 2013 14:53:08 +0300 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <877gds3xkv.fsf@vigenere.g10code.de> References: <877gds3xkv.fsf@vigenere.g10code.de> Message-ID: <524FFDA4.3050107@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Werner Koch wrote on 10/5/13 11:56 AM: > Hello! > > We are pleased to announce the availability of a new stable > GnuPG-1 release: Version 1.4.15. This is a *security fix* release > and all users are advised to updated to this version. See below > for the impact of the problem. [...] > Happy Hacking, > > The GnuPG Team Hi, "Version info: gnupg 1.4.15 Configured for: Darwin (x86_64-apple-darwin12.5.0)" Thanks Werner and the GnuPG team. Charly 0x15E4F2EA Mac OS X 10.8.5 (12F37) MacBook Intel C2Duo 2GHz 13-inch, Aluminum, Late 2008 . (GnuPG/MacGPG2) 2.0.20 - gpg (GnuPG) 1.4.15 TB 24.0 Enigmail version 1.5.2 (20130703-1322) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJST/2aAAoJEPPf0YAV5PLqYDsQAJeuhBsgniHwYWyu1/GAtcLy YrYUK5xQzk+OJgrzytdfmBfz/dD+VpZz4spSTKhe1BHcnq5Ar9VBJX91UnngR6En /L0+pK/np0AGXfwyhzisYntjDSt8jQl31qhDYthPjkAUL3vnUAPtQRN5m1HKuw9H AtCUvjfIXAXKBZAqlque3CpeMA2j5279KI5oyMpvQnzeV+Y8yhcs9RPiY+NLnQQ8 Iee069oVDVmnwJjU7GiusD/z+poR1THapAu31EuNVCkFSZclXZd/d5+mrHPdDjUH fN1Te+4GqXRBJV4PZNuXZV9IvFnSwJ5FaT+6vySMMB0UHxbNIgosVQpqZX8AW3Fu UeWv6imcCGpsj9KpZSP8laAo5s/t3765nbVCczxzF8YrREO7+y9XP1xHNBt+awPK anCmpfpzB+gJkvUmXaaVizDQEFiOVZX1xdknkO/XVSZU9tnWfm+m1h8xQyOqsed9 YERBj5vU3LT3Ldd8ykaSNsqFazuXTVAA9R/II9cRlc7NMeuiicFWM1JLmOCRp+Zy gXjhnBNk+1dhj5OSujMyNi6pP1ASFAAIm3DKYZC9umC5+L3YPeMkOvVC4VeZl/VH twhb0zxiOZ+VK5g4WVhh8qD6CpkOI9f4uRWcyU6mDmvm19WbXOSxCtEBH3LMPy4N PQazHVPgFVvlRIL2cVUF =08bX -----END PGP SIGNATURE----- From sonic at dersonic.org Sat Oct 5 14:58:27 2013 From: sonic at dersonic.org (Michael) Date: Sat, 5 Oct 2013 14:58:27 +0200 Subject: GnuPG 2.0.22 compiling on Mac OS X fails Message-ID: <6D8F01AA-1D2B-40BA-887E-F185A84A1FF5@dersonic.org> Hi, i just tried to compile the 2.0.22 version on Mac OS X 10.8.5 with XCode 5.0. But it fails : #pragma weak pth_waitpid ^ exechelp.c:68:14: warning: weak identifier 'pth_fork' never declared #pragma weak pth_fork ^ signal.c:125:41: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] write (2, "0123456789"+(value/i), 1); ~~~~~~~~~~~~^~~~~~~~~~ signal.c:125:41: note: use array indexing to silence this warning write (2, "0123456789"+(value/i), 1); ^ & [ ] ///Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/include/stdint.h:32:36: warning: #include_next with absolute path defined(__has_include_next) && __has_include_next() ^ ///Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/include/stdint.h:33:3: warning: #include_next with absolute path # include_next ^ In file included from estream-printf.c:54: In file included from ../gl/stdint.h:66: /usr/include/inttypes.h:238:10: error: unknown type name 'intmax_t' extern intmax_t imaxabs(intmax_t j); ^ /usr/include/inttypes.h:238:27: error: unknown type name 'intmax_t' extern intmax_t imaxabs(intmax_t j); ^ /usr/include/inttypes.h:242:9: error: unknown type name 'intmax_t' intmax_t quot; ^ /usr/include/inttypes.h:243:9: error: unknown type name 'intmax_t' intmax_t rem; ^ /usr/include/inttypes.h:246:28: error: unknown type name 'intmax_t' extern imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); ^ /usr/include/inttypes.h:246:44: error: unknown type name 'intmax_t' extern imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); ^ /usr/include/inttypes.h:249:10: error: unknown type name 'intmax_t' extern intmax_t strtoimax(const char * restrict nptr, char ** restric... ^ /usr/include/inttypes.h:250:10: error: unknown type name 'uintmax_t'; did you mean 'uintptr_t'? extern uintmax_t strtoumax(const char * restrict nptr, char ** restric... ^ /usr/include/i386/types.h:109:24: note: 'uintptr_t' declared here typedef unsigned long uintptr_t; ^ In file included from estream-printf.c:54: In file included from ../gl/stdint.h:66: /usr/include/inttypes.h:260:10: error: unknown type name 'intmax_t' extern intmax_t wcstoimax(const wchar_t * restrict nptr, wchar_t ** re... ^ /usr/include/inttypes.h:261:10: error: unknown type name 'uintmax_t'; did you mean 'uintptr_t'? extern uintmax_t wcstoumax(const wchar_t * restrict nptr, wchar_t ** r... ^ /usr/include/i386/types.h:109:24: note: 'uintptr_t' declared here typedef unsigned long uintptr_t; ^ Best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1590 bytes Desc: not available URL: From wk at gnupg.org Sat Oct 5 17:08:15 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Oct 2013 17:08:15 +0200 Subject: GnuPG 2.0.22 compiling on Mac OS X fails In-Reply-To: <6D8F01AA-1D2B-40BA-887E-F185A84A1FF5@dersonic.org> (Michael's message of "Sat, 5 Oct 2013 14:58:27 +0200") References: <6D8F01AA-1D2B-40BA-887E-F185A84A1FF5@dersonic.org> Message-ID: <87d2nj3gdc.fsf@vigenere.g10code.de> On Sat, 5 Oct 2013 14:58, sonic at dersonic.org said: > i just tried to compile the 2.0.22 version on Mac OS X 10.8.5 with XCode 5.0. This is known. See for example bug 1541. Sorry, I can't do anything about it until someone provides a tested solution. > signal.c:125:41: warning: adding 'int' to a string does not append to the string > [-Wstring-plus-int] > write (2, "0123456789"+(value/i), 1); > ~~~~~~~~~~~~^~~~~~~~~~ > signal.c:125:41: note: use array indexing to silence this warning Surely, it does not. "Syntactic sugar is required to drink from this source" - stupid warning. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jharris at widomaker.com Sat Oct 5 17:44:28 2013 From: jharris at widomaker.com (Jason Harris) Date: Sat, 5 Oct 2013 11:44:28 -0400 Subject: GnuPG mirrors In-Reply-To: <87eh803y1c.fsf@vigenere.g10code.de> References: <87eh803y1c.fsf@vigenere.g10code.de> Message-ID: <20131005154428.GA69682@wave> On Sat, Oct 05, 2013 at 10:46:39AM +0200, Werner Koch wrote: > direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors > can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG The list has some dead/stale entries. I found the following mirrors to be viable and current: ftp://ftp.crysys.hu/pub/gnupg/gnupg/ ftp://ftp.franken.de/pub/crypt/mirror/ftp.gnupg.org/gcrypt/gnupg/ ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/gnupg/ ftp://ftp.hi.is/pub/mirrors/gnupg/gnupg/ ftp://ftp.sunet.se/pub/security/gnupg/gnupg/ ftp://gd.tuwien.ac.at/privacy/gnupg/gnupg/ ftp://mirror.switch.ch/mirror/gnupg/gnupg/ http://artfiles.org/gnupg.org/gnupg/ http://ftp.heanet.ie/mirrors/ftp.gnupg.org/gcrypt/gnupg/ http://mirror.tje.me.uk/pub/mirrors/ftp.gnupg.org/gnupg/ http://www.mirrorservice.org/sites/ftp.gnupg.org/gcrypt/gnupg/ http://mirrors.dotsrc.org/gcrypt/gnupg/ http://mirrors.dotsrc.org/gnupg/gnupg/ Thanks. -- Jason Harris | PGP: This _is_ PGP-signed, isn't it? jharris at widomaker.com _|_ Got photons? (TM), (C) 2004 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 314 bytes Desc: not available URL: From pneukom at gmail.com Sat Oct 5 18:56:48 2013 From: pneukom at gmail.com (Philip Neukom) Date: Sat, 05 Oct 2013 12:56:48 -0400 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: References: Message-ID: <525044D0.4060508@gmail.com> On 5.10.2013 9:53 , gnupg-users-request at gnupg.org wrote: > From: Charly Avital To: > Subject: Re: [Announce] [security fix] GnuPG > 1.4.15 released > > [...] > Hi, > > "Version info: gnupg 1.4.15 > Configured for: Darwin (x86_64-apple-darwin12.5.0)" > > Thanks Werner and the GnuPG team. > Charly Charly, did you compile with Xcode 5? I just tried and get an error: > Undefined symbols for architecture x86_64: > "_iconv", referenced from: > _native_to_utf8 in libutil.a(strgutil.o) > _utf8_to_native in libutil.a(strgutil.o) > __nl_find_msg in libintl.a(dcigettext.o) > "_iconv_close", referenced from: > _native_to_utf8 in libutil.a(strgutil.o) > _set_native_charset in libutil.a(strgutil.o) > _utf8_to_native in libutil.a(strgutil.o) > "_iconv_open", referenced from: > _native_to_utf8 in libutil.a(strgutil.o) > _set_native_charset in libutil.a(strgutil.o) > _utf8_to_native in libutil.a(strgutil.o) > __nl_find_msg in libintl.a(dcigettext.o) > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) > make[2]: *** [gpg] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 Any suggestions to fix would be appreciated. Thanks Philip. From shavital at gmail.com Sat Oct 5 21:31:54 2013 From: shavital at gmail.com (Charly Avital) Date: Sat, 05 Oct 2013 22:31:54 +0300 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <525044D0.4060508@gmail.com> References: <525044D0.4060508@gmail.com> Message-ID: <5250692A.4070308@gmail.com> Philip Neukom wrote on 10/5/13 7:56 PM: > > > On 5.10.2013 9:53 , gnupg-users-request at gnupg.org wrote: >> From: Charly Avital To: >> Subject: Re: [Announce] [security fix] GnuPG >> 1.4.15 released >> >> [...] >> Hi, >> >> "Version info: gnupg 1.4.15 >> Configured for: Darwin (x86_64-apple-darwin12.5.0)" >> >> Thanks Werner and the GnuPG team. >> Charly > > Charly, did you compile with Xcode 5? No, I used the Terminal: 1. Download and verify the source code. 2. cd to expanded source code. 3. ./configure 4. make 5. sudo make install. Hope this helps. Charly 0x15E4F2EA Mac OS X 10.8.5 (12F37) MacBook Intel C2Duo 2GHz 13-inch, Aluminum, Late 2008 . (GnuPG/MacGPG2) 2.0.20 - gpg (GnuPG) 1.4.15 TB 24.0 Enigmail version 1.5.2 (20130703-1322) From mlisten at hammernoch.net Sat Oct 5 21:38:41 2013 From: mlisten at hammernoch.net (=?ISO-8859-1?Q?Ludwig_H=FCgelsch=E4fer?=) Date: Sat, 05 Oct 2013 21:38:41 +0200 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <525044D0.4060508@gmail.com> References: <525044D0.4060508@gmail.com> Message-ID: <52506AC1.2050208@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Philip, On 05.10.13 18:56, Philip Neukom wrote: > Charly, did you compile with Xcode 5? > > I just tried and get an error: >> Undefined symbols for architecture x86_64: "_iconv", referenced >> from: (...) > Any suggestions to fix would be appreciated. Do you have software installed by macports, homebrew or fink? If yes, try moving the /opt/local (or whereever homebrew or fink install their stuff) out of the way while building gpg. HTH Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSUGrBAAoJEA52XAUJWdLjMjkH/1UDSjsoDb9K1BceSNpaGmxW 2UppKkUVu6RLvdcl3GT8T+CufmAFbkODm2c7wRW99oTcGv1kknjE46o4FEWXJdv4 lW8IwkngN8iA1VSy2Ixs66DPGsr2G/MUKTkwm0cGrrtPCd0uwV6MLdN8RVY/ze7N sNMMrgmXba250LfPQuj56JAy6nQ1iqdOMTfVOyZQyRVQyEOw55ilRJDpYJ3N4Chj Peb7wHcAgS+bIKH4iS0K5zjlmv3KLvPvLGjB0MlOXBN8+meJqp43Sm9zq0OiV50o bVGlLw1/wUVt08Weq0I/V3M07CaaDLbyfjGATKMeC4P6pHReiDHM/mnEPFSSuLs= =b6/O -----END PGP SIGNATURE----- From pneukom at gmail.com Sat Oct 5 21:50:57 2013 From: pneukom at gmail.com (Philip Neukom) Date: Sat, 05 Oct 2013 15:50:57 -0400 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <5250692A.4070308@gmail.com> References: <525044D0.4060508@gmail.com> <5250692A.4070308@gmail.com> Message-ID: <52506DA1.9060508@gmail.com> On 5.10.2013 15:31 , Charly Avital wrote: > Philip Neukom wrote on 10/5/13 7:56 PM: >> >> >> On 5.10.2013 9:53 , gnupg-users-request at gnupg.org wrote: >>> From: Charly Avital To: >>> Subject: Re: [Announce] [security fix] GnuPG >>> 1.4.15 released >>> >>> [...] >>> Hi, >>> >>> "Version info: gnupg 1.4.15 >>> Configured for: Darwin (x86_64-apple-darwin12.5.0)" >>> >>> Thanks Werner and the GnuPG team. >>> Charly >> >> Charly, did you compile with Xcode 5? > > No, I used the Terminal: > 1. Download and verify the source code. > 2. cd to expanded source code. > 3. ./configure > 4. make > 5. sudo make install. > > Hope this helps. > Charly > 0x15E4F2EA > Mac OS X 10.8.5 (12F37) > MacBook Intel C2Duo 2GHz 13-inch, Aluminum, Late 2008 . > (GnuPG/MacGPG2) 2.0.20 - gpg (GnuPG) 1.4.15 > TB 24.0 Enigmail version 1.5.2 (20130703-1322) > Thanks for the quick reply, Charly. Hmmm. Yes I used the terminal also. With the update to 10.8.5, there was an update to Xcode and the Command Line Tools that you use to compile, make & install. So that is the only thing that I can think of that changed on my system. Michael also replied and he has no problems while using the newer command line tools from Xcode 5. For me the compile step works. But I have no idea why the make step give so many warnings and then craps out. Any suggestions of what to try is appreciated. P. From mirimir at riseup.net Sun Oct 6 04:09:33 2013 From: mirimir at riseup.net (mirimir) Date: Sun, 06 Oct 2013 02:09:33 +0000 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <877gds3xkv.fsf@vigenere.g10code.de> References: <877gds3xkv.fsf@vigenere.g10code.de> Message-ID: <5250C65D.3090906@riseup.net> On 10/05/2013 08:56 AM, Werner Koch wrote: > Hello! > > We are pleased to announce the availability of a new stable GnuPG-1 > release: Version 1.4.15. This is a *security fix* release and all users > are advised to updated to this version. See below for the impact of the > problem. I'm using Thunderbird with Enigmail. Enigmail is at 1.5.2 (20130913-2148) and gpg is at 1.4.11. Is it best to wait for Enigmail to update, or to update gpg manually? > The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication > and data storage. It is a complete and free replacement of PGP and > can be used to encrypt data and to create digital signatures. It > includes an advanced key management facility, smartcard support and is > compliant with the OpenPGP Internet standard as described by RFC-4880. > > Note that this version is from the GnuPG-1 series and thus smaller than > those from the GnuPG-2 series, easier to build, and also better portable > to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.22) it > comes with no support for S/MIME, Secure Shell, or other tools useful > for desktop environments. Fortunately you may install both versions > alongside on the same system without any conflict. > > > What's New > =========== > > * Fixed possible infinite recursion in the compressed packet > parser. [CVE-2013-4402] > > * Protect against rogue keyservers sending secret keys. > > * Use 2048 bit also as default for batch key generation. > > * Minor bug fixes. > > > Impact of the security problem > ============================== > > Special crafted input data may be used to cause a denial of service > against GPG (GnuPG's OpenPGP part) and some other OpenPGP > implementations. All systems using GPG to process incoming data are > affected. > > Taylor R. Campbell invented a neat trick to generate OpenPGP packages > to force GPG to recursively parse certain parts of OpenPGP messages ad > infinitum. As a workaround a tight "ulimit -v" setting may be used to > mitigate the problem. Sample input data to trigger this problem has > not yet been seen in the wild. Details of the attack will eventually > be published by its inventor. > > A fixed release of the GnuPG 2.0 series has also been released. > > > Getting the Software > ==================== > > First of all, decide whether you really need GnuPG version 1.4.x - most > users are better off with the modern GnuPG 2.0.x version. Then follow > the instructions found at http://www.gnupg.org/download/ or read on: > > GnuPG 1.4.15 may be downloaded from one of the GnuPG mirror sites or > direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be > found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not > available at ftp.gnu.org. > > On the mirrors you should find the following files in the *gnupg* > directory: > > gnupg-1.4.15.tar.bz2 (3569k) > gnupg-1.4.15.tar.bz2.sig > > GnuPG source compressed using BZIP2 and OpenPGP signature. > > gnupg-1.4.15.tar.gz (4948k) > gnupg-1.4.15.tar.gz.sig > > GnuPG source compressed using GZIP and OpenPGP signature. > > gnupg-1.4.14-1.4.15.diff.bz2 (37k) > > A patch file to upgrade a 1.4.14 GnuPG source tree. This patch > does not include updates of the language files. > > Select one of them. To shorten the download time, you probably want to > get the BZIP2 compressed file. Please try another mirror if exceptional > your mirror is not yet up to date. > > In the *binary* directory, you should find these files: > > gnupg-w32cli-1.4.15.exe (1568k) > gnupg-w32cli-1.4.15.exe.sig > > GnuPG compiled for Microsoft Windows and OpenPGP signature. > This is a command line only version; the source files are the > same as given above. Note, that this is a minimal installer and > unless you are just in need for the gpg binary, you are better > off using the full featured installer at http://www.gpg4win.org . > An updated version of gpg4win is scheduled for next week. > > > Checking the Integrity > ====================== > > In order to check that the version of GnuPG which you are going to > install is an original and unmodified one, you can do it in one of > the following ways: > > * If you already have a trusted version of GnuPG installed, you > can simply check the supplied signature. For example to check the > signature of the file gnupg-1.4.15.tar.bz2 you would use this command: > > gpg --verify gnupg-1.4.15.tar.bz2.sig > > This checks whether the signature file matches the source file. > You should see a message indicating that the signature is good and > made by that signing key. Make sure that you have the right key, > either by checking the fingerprint of that key with other sources > or by checking that the key has been signed by a trustworthy other > key. Note, that you can retrieve the signing key using the command > > finger wk ,at' g10code.com | gpg --import > > or using a keyserver like > > gpg --recv-key 4F25E3B6 > > The distribution key 4F25E3B6 is signed by the well known key > 1E42B367. If you get an key expired message, you should retrieve a > fresh copy as the expiration date might have been prolonged. > > NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE > INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! > > * If you are not able to use an old version of GnuPG, you have to verify > the SHA-1 checksum. Assuming you downloaded the file > gnupg-1.4.14.tar.bz2, you would run the sha1sum command like this: > > sha1sum gnupg-1.4.15.tar.bz2 > > and check that the output matches the first line from the > following list: > > 63ebf0ab375150903c65738070e4105200197fd4 gnupg-1.4.15.tar.bz2 > 2881c8174c15bb86ecf2e879cb7ca22c91fbcf93 gnupg-1.4.15.tar.gz > 0e3a593da55be0fb9a556513ce034e13677e5ebc gnupg-1.4.14-1.4.15.diff.bz2 > 1adda83f3eda5a2ac6d362c294e31fbb529a03e4 gnupg-w32cli-1.4.15.exe > > > Internationalization > ==================== > > GnuPG comes with support for 29 languages. The Chinese (Simple and > Traditional), Czech, Danish, Dutch, French, German, Norwegian, Polish, > Romanian, Russian, Spanish, Swedish, Ukrainian, and Turkish translations > are close to be complete. > > > Support > ======= > > A listing with commercial support offers for GnuPG is available at: > > http://www.gnupg.org/service.html > > The driving force behind the development of GnuPG is the company of its > principal author, Werner Koch. Maintenance and improvement of GnuPG and > related software take up a most of their resources. To allow them > continue their work they ask to either purchase a support contract, > engage them for custom enhancements, or to donate money: > > http://g10code.com/gnupg-donation.html > > > > Thanks > ====== > > We have to thank all the people who helped with this release, be it > testing, coding, translating, suggesting, auditing, donating money, > spreading the word, or answering questions on the mailing lists. > > > > Happy Hacking, > > The GnuPG Team > > > > > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From dkg at fifthhorseman.net Sun Oct 6 04:21:47 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 05 Oct 2013 22:21:47 -0400 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <5250C65D.3090906@riseup.net> References: <877gds3xkv.fsf@vigenere.g10code.de> <5250C65D.3090906@riseup.net> Message-ID: <5250C93B.7030906@fifthhorseman.net> On 10/05/2013 10:09 PM, mirimir wrote: > On 10/05/2013 08:56 AM, Werner Koch wrote: > >> We are pleased to announce the availability of a new stable GnuPG-1 >> release: Version 1.4.15. This is a *security fix* release and all users >> are advised to updated to this version. See below for the impact of the >> problem. > > I'm using Thunderbird with Enigmail. Enigmail is at 1.5.2 > (20130913-2148) and gpg is at 1.4.11. Is it best to wait for Enigmail to > update, or to update gpg manually? My understanding is that enigmail does not update gpg on its own. The version number of enigmail is not tied to the version number of gpg at all. You should update gpg manually. hth, --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 laurent.jumet at skynet.be Sun Oct 6 08:58:36 2013 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sun, 06 Oct 2013 08:58:36 +0200 Subject: GnuPG 1.4.15 released In-Reply-To: <5250C65D.3090906@riseup.net> Message-ID: Hello mirimir ! mirimir wrote: > I'm using Thunderbird with Enigmail. Enigmail is at 1.5.2 > (20130913-2148) and gpg is at 1.4.11. Is it best to wait for Enigmail to > update, or to update gpg manually? Enigmail has no cryptographic code itself, it only passes the commands to GPG. So the question is: are 1.4.15 and 1.4.11 self compatible, and answer (for me) is yes. -- Laurent Jumet KeyID: 0xCFAF704C From mirimir at riseup.net Sun Oct 6 10:44:48 2013 From: mirimir at riseup.net (mirimir) Date: Sun, 06 Oct 2013 08:44:48 +0000 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <5250C93B.7030906@fifthhorseman.net> References: <877gds3xkv.fsf@vigenere.g10code.de> <5250C65D.3090906@riseup.net> <5250C93B.7030906@fifthhorseman.net> Message-ID: <52512300.1040706@riseup.net> On 10/06/2013 02:21 AM, Daniel Kahn Gillmor wrote: > On 10/05/2013 10:09 PM, mirimir wrote: >> On 10/05/2013 08:56 AM, Werner Koch wrote: >> >>> We are pleased to announce the availability of a new stable GnuPG-1 >>> release: Version 1.4.15. This is a *security fix* release and all users >>> are advised to updated to this version. See below for the impact of the >>> problem. >> >> I'm using Thunderbird with Enigmail. Enigmail is at 1.5.2 >> (20130913-2148) and gpg is at 1.4.11. Is it best to wait for Enigmail to >> update, or to update gpg manually? > > My understanding is that enigmail does not update gpg on its own. The > version number of enigmail is not tied to the version number of gpg at all. > > You should update gpg manually. > > hth, > > --dkg Thank you. I see at https://www.enigmail.net/documentation/quickstart-ch1.php that GnuPG 2.0 is apparently recommended (at least for Windows). Is upgrading to gpg 2.0.22 recommended vs 1.4.15? From olav at enigmail.net Sun Oct 6 10:54:21 2013 From: olav at enigmail.net (Olav Seyfarth) Date: Sun, 06 Oct 2013 10:54:21 +0200 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <52512300.1040706@riseup.net> References: <877gds3xkv.fsf@vigenere.g10code.de> <5250C65D.3090906@riseup.net> <5250C93B.7030906@fifthhorseman.net> <52512300.1040706@riseup.net> Message-ID: <5251253D.6030405@enigmail.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hi GnuPG users, > I see at https://www.enigmail.net/documentation/quickstart-ch1.php that > GnuPG 2.0 is apparently recommended (at least for Windows). You may use Enigmail with either GnuPG 1.4 or 2.0. The reasons for the recommendation are that - - there is a proper Windows installer for 2.0 and - - gpgagent allows to cache multiple passphrases. With just GnuPG 1.4 installed, Enigmail reverts to its old behavior and allows to cache passphrases itself. While this allows to control within the GUI how long a passphrase is cached, only one passprease is supported for all keys and uses (sign, decrypt). Therefore, we urge people to use GnuPG 2.0 / gpgagent. > Is upgrading to gpg 2.0.22 recommended vs 1.4.15? If you're happy with just one passphrase, no. Never touch a running system ;-) Olav - -- The Enigmail Project - OpenPGP Email Security For Mozilla Applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (MingW32) Comment: Dies ist eine elektronische Signatur - http://www.enigmail.net/ iQGcBAEBAwAGBQJSUSU5AAoJEKGX32tq4e9WQugL/iVgifXVR50U+0HBlyK/jsK7 4qHlNOsUS9mih/UTmS0W9FjUVHaYK8/2sHyKPxpqw8xtU8VhAiumtBWaMFzleG+V ap67bi36H6kNG3OqEU6gm0fvrOPg+dDoUorEakGECaPsxeKBGuNzWF7y/B4iniEI 8Y8tp1VvJokukFXEV0/lV1XbSXipf44gm75sM9Hq17EYqhEi0RiotADLQ92EcSmW lSEteMNtgTMORUKp0EjTjUSrNLM4fR+uJONIvPVWZX9kfOY02awnBL6Yb4laAYXO a3lejahIQOwFIqEi3e7chkACivXWA8fZPoKq9G62hLDWBuV8IcGCwAmjd71cfMAD lZwjGyBrwLYkK7P6O+ld4B472oV6clPjkbaWMOVkyWAPcFVmyTIaTMDQQa7Dox30 62+dey5iVPFvg+UlN6ZR8oUsRdmpJG5gsSnmE0frC2lmFyg3y4yMy8jp+MQmCbQD XGhmGtQ+alOx1eim8W4qKuiZVdiHPeYLWhViMP1tTQ== =SB0V -----END PGP SIGNATURE----- From sonic at dersonic.org Sun Oct 6 16:38:13 2013 From: sonic at dersonic.org (Michael) Date: Sun, 6 Oct 2013 16:38:13 +0200 Subject: GnuPG 2.0.22 compiling on Mac OS X fails In-Reply-To: <87d2nj3gdc.fsf@vigenere.g10code.de> References: <6D8F01AA-1D2B-40BA-887E-F185A84A1FF5@dersonic.org> <87d2nj3gdc.fsf@vigenere.g10code.de> Message-ID: Am 05.10.2013 um 17:08 schrieb Werner Koch : > On Sat, 5 Oct 2013 14:58, sonic at dersonic.org said: > >> i just tried to compile the 2.0.22 version on Mac OS X 10.8.5 with XCode 5.0. > > This is known. See for example bug 1541. Sorry, I can't do anything > about it until someone provides a tested solution. I tryed the workaround described in the bug report. But i use gl/stdint.h instead of sm/stdint.h. The workaround works well so far. # include "///Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/include/stdint.h" typedef long intptr_t; typedef long long intmax_t; typedef unsigned long uintptr_t; typedef unsigned long long uintmax_t; -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1590 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Sun Oct 6 23:30:32 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 06 Oct 2013 23:30:32 +0200 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <877gds3xkv.fsf@vigenere.g10code.de> References: <877gds3xkv.fsf@vigenere.g10code.de> Message-ID: <5251D678.1050608@vulcan.xs4all.nl> On 05-10-2013 10:56, Werner Koch wrote: The README in the source bzip2 file still states 1.4.14. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wk at gnupg.org Mon Oct 7 08:30:50 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Oct 2013 08:30:50 +0200 Subject: [Announce] [security fix] GnuPG 1.4.15 released In-Reply-To: <5251D678.1050608@vulcan.xs4all.nl> (Johan Wevers's message of "Sun, 06 Oct 2013 23:30:32 +0200") References: <877gds3xkv.fsf@vigenere.g10code.de> <5251D678.1050608@vulcan.xs4all.nl> Message-ID: <87d2nh1tk5.fsf@vigenere.g10code.de> On Sun, 6 Oct 2013 23:30, johanw at vulcan.xs4all.nl said: > The README in the source bzip2 file still states 1.4.14. Ah well, I should have not mentioned the exact version number there. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Tue Oct 8 10:45:56 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 08 Oct 2013 10:45:56 +0200 Subject: GPG2 encryption options In-Reply-To: <1381171467.74890.YahooMailNeo@web140704.mail.bf1.yahoo.com> References: <1380775584103-32819.post@n7.nabble.com> <20131003113332.GA5546@straylight.m.ringlet.net> <20131003113534.GB5546@straylight.m.ringlet.net> <524D5E97.5040108@digitalbrains.com> <1381171467.74890.YahooMailNeo@web140704.mail.bf1.yahoo.com> Message-ID: <5253C644.2060703@digitalbrains.com> On 07/10/13 20:44, Peter Humphreys wrote: > Firstly I'm not 100% sure your getting my replies if I reply directly from > my mail client (new to mailing lists). As long as you send it to gnupg-users at gnupg.org, people on the list will get the mail. Additionally, you can add specific people to To: and Cc: who you want to mail directly. The only thing is the Reply-To: header you set. It doesn't always do what you'd expect for a mailing list. For instance, I had your yahoo address in Cc: when I pressed reply for this mail. I removed it manually. > My attempt at creating random passphrases is finished. I now have a script > which generates these randomly and passing these through thanks to your > previous advice is working nicely to encrypt and decrypt files. Can you describe what you are trying to achieve? Not how, but what, or perhaps how you intend to use it. Because I don't think you're going about it the right way, but I'm not sure what you're trying to do anyway. I don't think it's a good idea to generate random passphrases or something like that. If your use case is this: - You have a lot of files you wish to use often - You don't want them to be in plaintext, because you're afraid someone might be able to get at your backups - You don't want to enter a passphrase each time Then I think this scenario is best met by using public-key encryption and having gpg-agent store the passphrase after you enter it the first time after you booted the system and use one of the files. In this case, you're not using public-key crypto because you want to give your key to the public, but because it is a good way to gave gpg-agent keep the passphrase for you. If it weren't for your requirement that you don't want to enter those passphrases, you could also use symmetric crypto, but then gpg-agent doesn't know that it should have the passphrase for a file. By using public-key crypto, gpg-agent sees that the file is encrypted to that key, and it knows the passphrase, so it can just unlock the file without bothering you any further. If you so wish, you could create a keypair specifically for this purpose, and not give the public key to anyone or send it to a keyserver. I'm not saying it gives some extra layer of protection, and I'm not suggesting you do. I'm simply saying it's a possibility should you want to. Note that the second point of the scenario I give ("you're worried about people having access to your backups") is part of a very important thing you should consider: what is your threat model? What do you want to protect against? If you just go and blindly encrypt stuff because it feels safe, you're not going to end up with something that is actually helpful. > What I would now like to know is how to securely store and access the > passphrase file for decrypting files. A passphrase is something you know. You store it in your mind and access it through neurons. If you store it on your harddrive, I wouldn't consider it a passphrase anymore. Surely, you can build some wrapper around GnuPG, but you're changing the concept from a passphrase to key material. But, gpg-agent can cache a passphrase for you. It doesn't store it unencrypted on the hard disk. I think it keeps it in a piece of main memory that it told the operating system about to keep the OS from writing it to swap, so it stays off your disk. > Also how do I go about setting up the gpg-agent to cache my main passphrase > for X number of minutes for example? $ man gpg-agent [...] --default-cache-ttl n Set the time a cache entry is valid to n seconds. The default is 600 seconds. You would put this without the two dashes on a single line in your gpg-agent.conf: default-cache-ttl 1800 to cache it for half an hour. Also see max-cache-ttl; they probably need to be consistent. 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 eagleeyes426 at yahoo.com Mon Oct 7 20:44:27 2013 From: eagleeyes426 at yahoo.com (Peter Humphreys) Date: Mon, 7 Oct 2013 11:44:27 -0700 (PDT) Subject: GPG2 encryption options In-Reply-To: <524D5E97.5040108@digitalbrains.com> References: <1380775584103-32819.post@n7.nabble.com> <20131003113332.GA5546@straylight.m.ringlet.net> <20131003113534.GB5546@straylight.m.ringlet.net> <524D5E97.5040108@digitalbrains.com> Message-ID: <1381171467.74890.YahooMailNeo@web140704.mail.bf1.yahoo.com> Hi guys, Firstly I'm not 100% sure your getting my replies if I reply directly from my mail client (new to mailing lists). But here goes anyways. My attempt at creating random passphrases is finished. I now have a script which generates these randomly and passing these through thanks to your previous advice is working nicely to encrypt and decrypt files. What I would now like to know is how to securely store and access the passphrase file for decrypting files. My idea is to sign and encrypt the passphrase.txt file (all good), but is there a way that I can access the file without having to decrypt it fully back to it's .txt state and search it to get the passphrases out of it for example? or I just have to encrypt\decrypt each time i want to pipe passphrases out of it? Also how do I go about setting up the gpg-agent to cache my main passphrase for X number of minutes for example? Kind Regards, Peter Humphreys ________________________________ From: Peter Lebbing To: Peter Pentchev Cc: mightymouse2045 ; gnupg-users at gnupg.org Sent: Thursday, 3 October 2013 8:09 PM Subject: Re: GPG2 encryption options On 03/10/13 13:35, Peter Pentchev wrote: > a smartcard that caches the PIN for a limited > amount of time Small detail: this feature is not working in the current stable versions. GnuPG 2.1 will support this. I use the following script to make the card forget its PIN: ----------8<------------------------------------>8---------- #!/bin/sh gpg-connect-agent 'SCD RESET' /bye ----------8<------------------------------------>8---------- I created this based on a message of Werner Koch to this list. Earlier, I killed the scdaemon. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From expires2013 at ymail.com Wed Oct 9 01:15:32 2013 From: expires2013 at ymail.com (MFPA) Date: Wed, 9 Oct 2013 00:15:32 +0100 Subject: GPG2 encryption options In-Reply-To: <1380775584103-32819.post@n7.nabble.com> References: <1380775584103-32819.post@n7.nabble.com> Message-ID: <16910596226.20131009001532@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 3 October 2013 at 5:46:24 AM, in , mightymouse2045 wrote: > There are some files I don't like having to enter a > passphrase for each time due to them be accessed very > frequently, but I don't want the contents of them being > stored plaintext either. Depending on your threat model, these suggestions may be completely inappropriate. You want the files encrypted but but don't want to keep entering a passphrase to decrypt them. One way to achieve this is to encrypt them to an OpenPGP key that has an empty passphrase. Another suggestion is to store the files on an encrypted disk instead of using GnuPG. This would require disk encryption software, of which one example is TrueCrypt (see ). - -- Best regards MFPA mailto:expires2013 at ymail.com Never lean forward to push an invisible object. -----BEGIN PGP SIGNATURE----- iQCVAwUBUlSSJaipC46tDG5pAQqWKAQAl6gYWtYoBB2XStCO3YCiTEcIftXKPUgc eodGsHLhjEViJT2NMEp8QW/6XZbn7iJ87Fvb3u/nDZyX4jaibIY4v3S2k/0haNSS ycSfQvhjuEdlvEqkx/QuDoZPSDHjfviE24fw17E/qj4jmcN+sfMQjL0819fQ2L/S 0LlkLstBgIs= =aauH -----END PGP SIGNATURE----- From peter at digitalbrains.com Wed Oct 9 11:17:22 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 09 Oct 2013 11:17:22 +0200 Subject: GPG2 encryption options In-Reply-To: <16910596226.20131009001532@my_localhost> References: <1380775584103-32819.post@n7.nabble.com> <16910596226.20131009001532@my_localhost> Message-ID: <52551F22.8030606@digitalbrains.com> On 09/10/13 01:15, MFPA wrote: > Another suggestion is to store the files on an encrypted disk instead of > using GnuPG. This would require disk encryption software, of which one > example is TrueCrypt (see ). I think this is the best suggestion so far, if I understand the use case correctly. I had a case of tunnel vision restricting me to GnuPG as the tool to use, when a different tool might be the better solution. 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 johannes at zarl.at Wed Oct 9 19:50:20 2013 From: johannes at zarl.at (Johannes Zarl) Date: Wed, 09 Oct 2013 19:50:20 +0200 Subject: Problems with keypad on Cherry ST-2000U card reader In-Reply-To: <4317661.qAaK70T4lr@mani> References: <4317661.qAaK70T4lr@mani> Message-ID: <1408073.JzB2RS4Wuc@mani> Hello again, I'm just pushing this thread so it might get some attention. I'm not quite sure whether the lack of replies means that I did not formulate my question clearly or that nobody knows an answer. If it's the former: I'll gladly try to refine my question once I know what part is unclear. If it's the latter: What is the right place to ask questions regarding card reader support in gpg? Kind regards, Johannes P.S.: I did try again with gpg version 2.0.22, but the results are the same. On Friday 27 September 2013 13:36:44 Johannes Zarl wrote: > Hi, > > I recently got my fellowship card and now try to get a working setup. My > first tries with a ReinerSCT cyberjack that I had lying around did not get > me anywhere, so I bought a Cherry ST-2000U which looked like it should work > with the internal CCID driver. The reader is "mostly" working, i.e. I can't > get the pin entry via internal keypad to work. > > Symptoms: > Using pcscd (and therefore pinentry on my pc), the reader works flawlessly. > Using the internal driver (after stopping pcscd), "gpg --card-status" works > fine. > When an operation needs the pin, the reader switches correctly into pin > entry mode (judging by the leds). Regardless of whether I enter the correct > pin or an incorrect one, after pressing the "ok"/green key, the operation > is aborted. > > Using gpg (not gpg2), I get the following message after hitting "ok": > > gpg: sending command `SCD PKDECRYPT' to agent failed: ec=6.55 > > Except for this additional message, gpg and gpg2 behave exactly the same. > > I'm using the following versions (on Debian sid): > gpg (GnuPG) 1.4.14 > gpg (GnuPG) 2.0.21 > libgcrypt 1.5.3 > > Card info: > Version ..........: 2.0 > Manufacturer .....: ZeitControl > > Card reader (lsusb): > Bus 006 Device 003: ID 046a:003e Cherry GmbH SmartTerminal ST-2xx > > Any idea what could be the problem or how I can debug the issue? > > Thanks, > Johannes > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From brian at interlinx.bc.ca Thu Oct 10 19:45:07 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 10 Oct 2013 13:45:07 -0400 Subject: my gpg key does not conform to rfc4880? Message-ID: I was told by a developer of a piece of software that my key does not conform to rfc4800. He said: According to http://tools.ietf.org/html/rfc4880#section-5.2.2 signatures of version 3 don't have subpackets, which are only available in version 4. Looks like your key from 1998 is not compliant to RFC4880. Do I have any recourse other than to generate a new key? Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Oct 10 20:02:39 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 10 Oct 2013 14:02:39 -0400 Subject: my gpg key does not conform to rfc4880? In-Reply-To: References: Message-ID: <5256EBBF.7050505@fifthhorseman.net> On 10/10/2013 01:45 PM, Brian J. Murrell wrote: > I was told by a developer of a piece of software that my key does not > conform to rfc4800. He said: > > According to http://tools.ietf.org/html/rfc4880#section-5.2.2 > signatures of version 3 don't have subpackets, which are only > available in version 4. > > Looks like your key from 1998 is not compliant to RFC4880. > > Do I have any recourse other than to generate a new key? your key 0x9771109462F2B970 appears to be an OpenPGPv4 key, not an OpenPGPv3 key, so i'm not sure what the person you were talking to was talking about. that said, 0x9771109462F2B970 claims to have been generated on 1998-02-16, and is a 1024-bit DSA key. This is a weak key by today's standards, and the fact that it has been in use for over 15 years makes me think that you should probably generate a new primary key anyway. You don't have to revoke your old key immediately, of course, but you probably want to move to something stronger sooner rather than later. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Oct 10 20:10:37 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 10 Oct 2013 14:10:37 -0400 Subject: my gpg key does not conform to rfc4880? In-Reply-To: References: Message-ID: On Oct 10, 2013, at 1:45 PM, "Brian J. Murrell" wrote: > I was told by a developer of a piece of software that my key does not > conform to rfc4800. He said: > > According to http://tools.ietf.org/html/rfc4880#section-5.2.2 > signatures of version 3 don't have subpackets, which are only > available in version 4. > > Looks like your key from 1998 is not compliant to RFC4880. > > Do I have any recourse other than to generate a new key? Probably, but without seeing the key it is hard to be completely sure. Most likely, you could just strip the poison signature from your key and keep using it. If it's a self-signature, you'll have to make another one. If it's a signature from someone else, you can either disregard it, or ask them to re-sign your key. Can you say what the software that rejected your key is? If you think about it, rejecting a key because of a bad signature could lead to an denial of service attack - just upload a signature that is noncompliant enough to cause the key to be rejected, but compliant enough to make it onto a keyserver. Is your key with the bad signature on a keyserver? David From brian at interlinx.bc.ca Thu Oct 10 21:12:35 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 10 Oct 2013 15:12:35 -0400 Subject: my gpg key does not conform to rfc4880? In-Reply-To: <5256EBBF.7050505@fifthhorseman.net> References: <5256EBBF.7050505@fifthhorseman.net> Message-ID: <5256FC23.5070004@interlinx.bc.ca> On 13-10-10 02:02 PM, Daniel Kahn Gillmor wrote: > > your key 0x9771109462F2B970 appears to be an OpenPGPv4 key, not an > OpenPGPv3 key, so i'm not sure what the person you were talking to was > talking about. Ahh. Interesting. I will point that out to him. > that said, 0x9771109462F2B970 claims to have been generated on > 1998-02-16, and is a 1024-bit DSA key. This is a weak key by today's > standards, and the fact that it has been in use for over 15 years makes > me think that you should probably generate a new primary key anyway. Yeah. I have considered both of those things also. I guess the only thing that was holding me back was that the existing key has an investment in signatures on it though. What I am unclear about is how the authenticity and trustibility of my new key will be regarded in relation to the existing key with all of the signatures on it. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Oct 10 21:22:46 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 10 Oct 2013 15:22:46 -0400 Subject: my gpg key does not conform to rfc4880? In-Reply-To: <5256FC23.5070004@interlinx.bc.ca> References: <5256EBBF.7050505@fifthhorseman.net> <5256FC23.5070004@interlinx.bc.ca> Message-ID: <5256FE86.1070406@fifthhorseman.net> On 10/10/2013 03:12 PM, Brian J. Murrell wrote: > Yeah. I have considered both of those things also. I guess the only > thing that was holding me back was that the existing key has an > investment in signatures on it though. What I am unclear about is how > the authenticity and trustibility of my new key will be regarded in > relation to the existing key with all of the signatures on it. none of the above concerns should keep you from creating a new, stronger key and starting to gather certifications on it. You can still keep your old key for places where more certifications matter, and start using your new key in places where stronger keys matter. Do this until you feel comfortable that your new key has gathered enough certifications to be useful in both places, at which point you can revoke your old key. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From mlists at robin-kipp.net Fri Oct 11 01:25:50 2013 From: mlists at robin-kipp.net (Robin Kipp) Date: Fri, 11 Oct 2013 01:25:50 +0200 Subject: First steps with GPG, am I off to a good start? Message-ID: Hello all, I'd like to get started using GPG on a regular basis, e.g. to sign my EMail messages and exchange encrypted messages with a few people. So, I just generated my first keys in this manner: 1. Booted to a secure system. 2. invoked GPG using the following command: gpg --expert --gen-key 3. Generated an RSA key with signing and certification capabilities and 2048 bits in length. 4. Edited the key using gpg --edit-key in order to add all required UIDs. 5. Invoked addkey to generate a 2048 bit RSA sub key, with encryption and signing capabilities. 6. Exported all secret and public keys to a secure medium, also exported the secret sub keys. 7. Rebooted to my production system, imported the public keys and the secret subkeys. The listing now looks as follows. For public keys: MacBook-Pro:~ robin$ gpg --list-keys DC329876 pub 2048R/DC329876 2013-10-10 uid Robin Kipp uid Robin Kipp uid Robin Kipp sub 2048R/77DFFF08 2013-10-10 [expires: 2013-11-09] For secret keys: MacBook-Pro:~ robin$ gpg --list-secret-keys DC329876 sec# 2048R/DC329876 2013-10-10 uid Robin Kipp uid Robin Kipp uid Robin Kipp ssb 2048R/77DFFF08 2013-10-10 [expires: 2013-11-09] I'm signing this message using this subkey - and since this may not be widely available on keyservers just yet, the public key is at the end of this message. Could someone on this list perhaps be so kind and see if I've made any mistakes? I set the subkey to expire in a month just incase something went wrong with it, as I'd like to get it right before starting to effectively use it? Many thanks for any help! Robin -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org mQENBFJXKMwBCAC8DIDNqCRRdF9EqNJk5612/wsoUCTjC3D6Ipt1lDnR4NrI2VYm JjhnxBhmnsKP2M7Sco0zXycaygaNAEA+GBdAR1s1XxD85GRjTWToMf4DsVfuZPUM Kk20MqG2TOq9aSqEsoljCuu0M+pcPjALeCztf7GuC8fEbXKUAtQ3m01achYc22q0 IFkahEk/EPjvOPujO/T/+jqpt7OWyBtYPKkfnGsWqfUkWE0fEJl1xj28JyrT7ajU QSYVbVyJFTxTNMiD6gQwt0LVcibCFoYDil8BQEwrZX8I3r1azJoI2cRV33AmFaf+ Kc3fbMX45pA+wIUTOgtQqz01wjuLBYkRKwxVABEBAAG0IlJvYmluIEtpcHAgPG1s aXN0c0Byb2Jpbi1raXBwLm5ldD6JATcEEwEKACEFAlJXKwwCGwMFCwkIBwMFFQoJ CAsFFgIDAQACHgECF4AACgkQIlgbptwymHaJXQf9FpB3hB+frM7e2qP5rAR7ZJn3 Y0FSRslYXc+c0MirYK+K3NI6Anj8byT2G6C6OiKPE13glePGQEgNRg8v7X+k/ggD LaiQqYmfcAgIGuSIDBB+ZwmZVvErubDWtCzAEdzSIaS3VV+cT8gg+JTBJ6q/aZV7 bKPSRDyFlsmgUst55F1Amm1uoXlbdb3o8JXVZR4tYM4XDh0HcBwDeDIduN0NoSw+ JGYIX1CgIie5T418uUMVqB8sOvGDl8QeqSsOwpxTTCSCj667QqFjTaPdk4ZNAsZ1 8C4zgtBgw89fgMKImx8wez7vnV/VB+gv7P/YgAhMY2e8OF1ELyYnzo3xHATqAbQh Um9iaW4gS2lwcCA8cm9iaW5Acm9iaW4ta2lwcC5uZXQ+iQE6BBMBCgAkAhsDBQsJ CAcDBRUKCQgLBRYCAwEAAh4BAheABQJSVyshAhkBAAoJECJYG6bcMph2vCUH/1H4 SeiF/OkOyJxQW5o1fBmzUfjVwptIitNWbjzhKQw+2QPlLRfiO6rqMW0U/loEM4O0 d1uxCmhguvusKGA3O/mAAZTicnnWcqzlkNNcvoycNavSAI8aaqGPjHPyzDuzYqJD /UREwRvknH5JWlyb1LaZvT3ynKDxgY+wkQHAQLLEHmhFyPk80egSjFMdI8WTmCVl +X3nPimME5UDcPO2M1YJ0pwHuMO/lC6vIJXCBPH9ljwIRWZ6fT7L4g5HEzN8yJ0h RbWrdSuPmgStiFT5wSts5K/BLHBGsPYqL1/0kiJNO+bz32Ob0dfIYDMXoiPAyYJ9 85K+ozRGkYQa/AJr/0GJATcEEwEKACEFAlJXKMwCGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4AACgkQIlgbptwymHaFgQf+Jb7PfrZvt4glWNxUKh1+lkdXMLas9gl8 4Nsyc9s/biqqfD6iOSVpi4jQZJ93uhuBW8yKxOCcrI26jzVssSZHiP+8ZO7eDWx7 G5GbKal41FkE70AnP2lzCyovxeV/ozSnpHaopiQF6HRSvpikvKE8M6xeEN+9UgNv PfePYpO+lUdr7Rps5CNSEgtXgTX3IWt8QOJ7Q1jAbzaUNyz/kB9PuD31d4MLr0IV 8kMCvJ0c/qoF6DCatliEh0RLvWxig+ycScB0G0MOzgALpHHwzdBJnKYbR5PHWJnu KCCOwhsUTagNj+vIcVK8jbY6kyYa6tozvxzHUHpQPOzlgz86O/WkqbQfUm9iaW4g S2lwcCA8cm9iaW5AZGVic3BhY2Uub3JnPokBNwQTAQoAIQUCUlcp8gIbAwULCQgH AwUVCgkICwUWAgMBAAIeAQIXgAAKCRAiWBum3DKYdnCxB/9SH9YLIQAg6gBWgLCB kEocbCoY+62w89PHQksjUMGi3sICweZhth8HLHDTXhTnGLAE5d4dWZzQ7l5zSOI6 Fqu/ATCrKVOol5S27V0N2KGaeaY6TY2cSVq3RFVDwXVQxJgAfIY4+Pc6lYLk2trB 86xXuprZ2opRCRkHXX0Wxxu/bpM3cquNxkGs1XcT6ipKoGMB3NxXjj1xYR7qLW/+ wquFVA+bdAjvRSdeJT9UwuF9XQgv+dK1CN4OFgj3Cc8eOzOy/e74X7x6w4ygBCJW uC5LVqPC9/F/Vi3ktXmfXauoQ2NbSCFyJBd561odOe88d97Hpqu/aNMo+wE63Kpg UAoDuQENBFJXKY8BCADdCRlCh2Gc3ULtspU+fd/i9G0Dzv8J26cSqshD74RVqVtS IQCQ6D79rUe6/Tdy3BYVXGsxmWYkBlnyocoITgPiz8j8LrsCLZq+kVZ1qCFonWv7 nErMnVDfdyfJAZ99bG9D1lhCVj1J7Q0wGgN8Af2Xv5W/ZRerW7p8VuLf64SR1bdE sUASz0FyLwfa6GTlvjRIjZxOSpxfjduo9BewVL+tAKMjQjLVPeccqNf5piB8i4yw PklnXnNrbRL5m4Sk+nBTIK1+Sb4/RR7AQPLzahV2ePZ+41hrsUmZFtxtSHgSUX0+ QxdNW10TPF+D4yInB2gOytaFszSvyNd385+VgJA7ABEBAAGJAkQEGAEKAA8FAlJX KY8CGw4FCQAnjQABKQkQIlgbptwymHbAXSAEGQEKAAYFAlJXKY8ACgkQ9IrvKXff /wiqwwf+Omp3pRzeunMxJ3SqE3LZcAIaBncFp1UYIGvjdXKgPp6taMj54X7PcU6j 84iyTvYDC1pZaB+WQoxx+0uWfUJwXgs62aufu5pWowEPvpxXcbZN1TMo6SNcfPVq wScXwTyzimkX/I7EnmhmzihXl8Em+9fDoF0VNMmoXdXoEDSLaLhNR3ALBtmyEg9E 4WDitqbYha9L1JKv/hqYubyicWIPaZITF6LdIpKTIQhZn8vVc3xHDHPw9Ss9a+Rn UQlYOxQhfHOo8jzKQOxJKgRoTiWsi/PSbC3umrmKtamhK1rmuc6jtkY48QoDfviC IVwmO4XyVsJrmWBrYAFdcNJktTcK7Y1+B/95nNOrFhYe67JWnmMLqzLJq9e/G0bs lSBpr9iSGpNGr+NqdMcviHgN/DaqoJ7aLfqIp2z3QH/LLC8wDAmfKLPBJFNQdiwO B2oWTFE0lmBqMGx5N8wdg4BmSscomWfSDFE0WxSK4p8dVP9AIIUYUQycBJxuHtgx AVwqxPerHcoTatQZF6uQNSpMsW+W00FGpjo8iQhOjjsZBZi92wFpta/LMPMWZlrD 9AF4zDDuz7RW8rXP2hpP5Pf/zw3hVvtuzSGKQ2hW+kyV2ITRBOnuRiW/Tew9ksg7 kyPGCRIgbvEpodMVs3ZpWCP1bCSBPMRpnWZzHsVs+AXrgsJn/uKmZvct =39O2 -----END PGP PUBLIC KEY BLOCK----- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mailinglisten at hauke-laging.de Fri Oct 11 03:32:11 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 11 Oct 2013 03:32:11 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: References: Message-ID: <7636240.8X7SKMvsXs@inno.berlin.laging.de> Am Fr 11.10.2013, 01:25:50 schrieb Robin Kipp: > Invoked addkey to generate a 2048 bit RSA sub key, with > encryption and signing capabilities. It seems to me that the more accepted recommendation here is to have separate subkeys for signing and encryption. > 6. Exported all secret and public keys > to a secure medium, also exported the secret sub keys. 7. Rebooted to my > production system, imported the public keys and the secret subkeys. > For public keys: > MacBook-Pro:~ robin$ gpg --list-keys DC329876 > pub 2048R/DC329876 2013-10-10 > uid Robin Kipp > uid Robin Kipp > uid Robin Kipp > sub 2048R/77DFFF08 2013-10-10 [expires: 2013-11-09] I know of no good reason for creating a mainkey without expiration date. Furthermore it would be nice to have a UID without email address but with a comment which explains the security of the key. Something like "Robin Kipp (normal security level subkeys with offline mainkey)" This should be explained in more detail in a key policy which you should make publicly available and put its URL into the self signatures (see --set-policy- url) for the UIDs (and maybe even the subkeys). You should also set your preferred key server in the selfsigs (--default-keyserver-url). > since this may not be widely available on keyservers just yet > Could someone on this list perhaps be so kind and see if I've > made any mistakes? One may call that the best sequence of steps but one... ;-) Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Fri Oct 11 03:35:49 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 10 Oct 2013 21:35:49 -0400 Subject: First steps with GPG, am I off to a good start? In-Reply-To: References: Message-ID: <525755F5.1050805@sixdemonbag.org> On 10/10/2013 7:25 PM, Robin Kipp wrote: > 2. invoked GPG using the following command: > gpg --expert --gen-key Leave off the 'expert' flag and just use the defaults. Seriously, the defaults are reasonable and don't need tweaking. :) From dkg at fifthhorseman.net Fri Oct 11 05:25:48 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 10 Oct 2013 23:25:48 -0400 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <7636240.8X7SKMvsXs@inno.berlin.laging.de> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> Message-ID: <52576FBC.9030300@fifthhorseman.net> On 10/10/2013 09:32 PM, Hauke Laging wrote: > Am Fr 11.10.2013, 01:25:50 schrieb Robin Kipp: > >> Invoked addkey to generate a 2048 bit RSA sub key, with >> encryption and signing capabilities. > > It seems to me that the more accepted recommendation here is to have separate > subkeys for signing and encryption. This is absolutely correct. You should not be re-using the same RSA key for two different usages if at all possible. See, for example https://www.schneier.com/paper-chosen-protocol.html You can fix this by simply revoking this subkey and adding two new subkeys, one for encryption and one for signing. GnuPG will automatically select the right one to use for whichever purpose. > I know of no good reason for creating a mainkey without expiration date. I also agree with this. An expiration date of 3 years is reasonable. If you're using the key actively and you do not believe it has been compromised two years later, it should not be much extra work to extend your expiration date for another two years. The expiration date on your primary key gives you a failsafe endpoint in the event that you lose all copies of your secret key material and your revocation certificate. (you do have a revocation certificate generated and stored someplace safe, right? i didn't notice that in your list of steps) You can resolve the lack of expiry on your primary key just by setting an expiration date directly with: gpg --edit-key 0x22581BA6DC329876 expire You can make your revocation certification with: gpg --gen-revoke 0x22581BA6DC329876 store it in a safe place! > Furthermore it would be nice to have a UID without email address but with a > comment which explains the security of the key. Something like > > "Robin Kipp (normal security level subkeys with offline mainkey)" > > This should be explained in more detail in a key policy which you should make > publicly available and put its URL into the self signatures (see --set-policy- > url) for the UIDs (and maybe even the subkeys). You should also set your > preferred key server in the selfsigs (--default-keyserver-url). I disagree with these last recommendations from hauke. Take that as you will. I don't think such policy information in the User ID is particularly useful to other people (i'd be interested to hear of a situation where that communication actually changes peoples actions and where it can only be made through the User ID as opposed to, say, on a web page, a blog post, in-person communication during keysigning, etc), and adding comments like this to the User ID makes it more difficult for others to decide whether to certify your key (since they may not be able to verify the claim you're asking them to assert). Implementing and abiding by nuanced policy documents that you set forward in your policy-url also doesn't seem worth the labor, complexity and maintenance involved, since the advantages it provides (either for yourself or for others) are not clear. Questions to ask yourself: Have you ever checked someone else's policy URLs? what would you do differently if you could check them? have you ever audited the claims of someone's policy URL in any way? Lastly, do you even have a preferred keyserver? if not, setting --default-keyserver-url doesn't make any sense in the first place, and you should just use the global pool. Even if you do have a preferred keyserver, including such a keyserver URL in your self-sig is in some senses equivalent to a "web bug": you're asking the user of the key to make a call to your preferred server when they access your key. People who do not want to have their activity tracked will probably set no-honor-keyserver-url in their ~/.gnupg/gpg.conf, and will expect to get updates from arbitrary members of the public keyserver network, or from their own preferred private, non-logging or otherwise privacy-preserving server that is peered to the public keyserver network. i hope this analysis is helpful, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Oct 11 05:32:20 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 10 Oct 2013 23:32:20 -0400 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <52576FBC.9030300@fifthhorseman.net> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> <52576FBC.9030300@fifthhorseman.net> Message-ID: <52577144.4040101@sixdemonbag.org> On 10/10/2013 11:25 PM, Daniel Kahn Gillmor wrote: > > (a lot of stuff snipped) > ... Or, you know, you could just stick with the defaults. :) IMO, new users should be encouraged to use the defaults. This gets them using GnuPG and developing their skills with it. If, once they develop their skills, they decide that their needs are not well-met by the defaults they can always create a new certificate that's fine-tuned how they like. GnuPG already has a learning curve like the Matterhorn. Let's give some thought to that before we start advising new users to tweak every knob and dial on GnuPG's controls. :) From mailinglisten at hauke-laging.de Fri Oct 11 07:24:14 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 11 Oct 2013 07:24:14 +0200 Subject: standardized security levels Message-ID: <1709409.7fpHdx5CBh@inno.berlin.laging.de> Hello, a few mails ago dkg asked what the use of key policy documents was. That is obviously limited for several reasons. But the conclusion cannot be that we do completely without anything like that. It must be that we solve the problem in a reasonable way. If we don't then we seriously limit the quantity and quality of crypto usage. I have been considering this a problem for years and yesterday I finally made my first step in solving it: http://www.crypto-fuer-alle.de/wishlist/securitylevel/ The text is in German, though. But have some fun with the Google translator if you like... :-) http://translate.google.com/translate?sl=de&tl=en&js=n&prev=_t&hl=de&ie=UTF-8&u=http%3A%2F%2Fwww.crypto-fuer-alle.de%2Fwishlist%2Fsecuritylevel%2F&act=url The idea is to reduce the complex multi-dimensional security of a system to a limited number (about 10) of typical and useful cases. This should allow people who do not consider IT as one of their hobbies to much better assess the situation of their IT and their data. My OpenPGP specific aim is that such a standardized list would be implemented in OpenPGP applications, probably as a signature notation. The typical user would have several keys (for the same address) at different security levels. Thus the sender could select the security need of the data to be sent and the system could automatically select the most suitable key (or fail if none such is available). This may sound like making IT even more complex but I am convinced that the opposite it true. Achieving the same situation is much more difficult today. In fact these considerations are simply ignored by most people today. And then they are surprised that their money is stolen via online banking... Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From ml-gpg at m-privacy.de Fri Oct 11 09:20:45 2013 From: ml-gpg at m-privacy.de (Roman) Date: Fri, 11 Oct 2013 09:20:45 +0200 Subject: Problems with keypad on Cherry ST-2000U card reader In-Reply-To: <1408073.JzB2RS4Wuc@mani> References: <4317661.qAaK70T4lr@mani> <1408073.JzB2RS4Wuc@mani> Message-ID: <5257A6CD.4000208@m-privacy.de> Hello Johannes, I have the exact same setting with the same card reader ST-2000U (which I think is one of the best to be used with the OpenPGP card) on Debian (also testet on different flavours of Ubuntu makes no difference). I'm willing to help evaluate on this issue if someone could lead me through debugging it. Or has anybody success using the card readers pinpad? Roman Am 09.10.2013 19:50, schrieb Johannes Zarl: > Hello again, > > I'm just pushing this thread so it might get some attention. I'm not quite > sure whether the lack of replies means that I did not formulate my question > clearly or that nobody knows an answer. > > If it's the former: I'll gladly try to refine my question once I know what > part is unclear. > > If it's the latter: What is the right place to ask questions regarding card > reader support in gpg? > > Kind regards, > Johannes > > > P.S.: I did try again with gpg version 2.0.22, but the results are the same. > > > On Friday 27 September 2013 13:36:44 Johannes Zarl wrote: >> Hi, >> >> I recently got my fellowship card and now try to get a working setup. My >> first tries with a ReinerSCT cyberjack that I had lying around did not get >> me anywhere, so I bought a Cherry ST-2000U which looked like it should work >> with the internal CCID driver. The reader is "mostly" working, i.e. I can't >> get the pin entry via internal keypad to work. >> >> Symptoms: >> Using pcscd (and therefore pinentry on my pc), the reader works flawlessly. >> Using the internal driver (after stopping pcscd), "gpg --card-status" works >> fine. >> When an operation needs the pin, the reader switches correctly into pin >> entry mode (judging by the leds). Regardless of whether I enter the correct >> pin or an incorrect one, after pressing the "ok"/green key, the operation >> is aborted. >> >> Using gpg (not gpg2), I get the following message after hitting "ok": >> >> gpg: sending command `SCD PKDECRYPT' to agent failed: ec=6.55 >> >> Except for this additional message, gpg and gpg2 behave exactly the same. >> >> I'm using the following versions (on Debian sid): >> gpg (GnuPG) 1.4.14 >> gpg (GnuPG) 2.0.21 >> libgcrypt 1.5.3 >> >> Card info: >> Version ..........: 2.0 >> Manufacturer .....: ZeitControl >> >> Card reader (lsusb): >> Bus 006 Device 003: ID 046a:003e Cherry GmbH SmartTerminal ST-2xx >> >> Any idea what could be the problem or how I can debug the issue? >> >> Thanks, >> Johannes >> >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From pete at heypete.com Fri Oct 11 14:03:44 2013 From: pete at heypete.com (Pete Stephenson) Date: Fri, 11 Oct 2013 14:03:44 +0200 Subject: OpenPGP Smartcard + signing email = two signatures? In-Reply-To: <524B0AE0.3000207@digitalbrains.com> References: <5249E8BF.3090802@heypete.com> <524B0AE0.3000207@digitalbrains.com> Message-ID: <5257E920.50707@heypete.com> On 10/1/2013 7:48 PM, Peter Lebbing wrote: > On 30/09/13 23:10, Pete Stephenson wrote: >> Has anyone else observed this behavior? If so, is there an explanation? > > It's probably a benign bug, but it would obviously also be a reasonably good way > to get signatures if somebody had compromised your PC. Put a payload in GnuPG > such that when you try to sign something, it will first sign the attackers > message with your first pinentry prompt, and then just prompt again for your > signature. People who work with computers generally just try again if the first > time mysteriously failed. Indeed. I assumed it was merely a bug rather than something with malicious intent, as it occurred even with fresh-from-the-CD VMs that I was testing. I assume the bug also occurs without the "force signature PIN" bit enabled on the smartcard and with non-smartcard based keys. I've been in touch with Olav at Engimail and provided him with debugging information that might help. And yes, if one's computer was compromised then this is a good way for a bad guy to get signatures. In my case, I take reasonable precautions to prevent compromise and, while I can't prove it, I am reasonably certain that my systems are clean. (Let's hop!) > This does presume that you enter your PIN on the cardreader, because otherwise > it would be simpler to just use the PIN you give to the PC :). In this particular case, I'm using card readers without built-in PINpads (one is USB and connected to a desktop system, the other is integrated into a laptop) -- I'm being prompted for the pin by PINentry, which comes with GnuPG2. > But I think it's more likely there's a little bug somewhere that loses the message. That's my thought too. I'll post any updates to this thread. Cheers! -Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From John at enigmail.net Fri Oct 11 22:40:00 2013 From: John at enigmail.net (John Clizbe) Date: Fri, 11 Oct 2013 15:40:00 -0500 Subject: OpenPGP Smartcard + signing email = two signatures? In-Reply-To: <5249E8BF.3090802@heypete.com> References: <5249E8BF.3090802@heypete.com> Message-ID: <52586220.8010402@enigmail.net> Pete Stephenson wrote: > Hi all, > > I use Thunderbird, Enigmail, and GnuPG on Windows 7 (among others). > > I have my primary cert/sign key on one smartcard and two subkeys > (signature + encryption) on another. I have the "force signature PIN" > option enabled for both cards. > > Tonight I was using the card with the subkeys to sign an email message > that I was sending. As expected I was prompted by pinentry to enter the > card PIN and that the card had made N signatures before. I entered the > PIN and immediately pinentry popped up again asking for me to re-enter > the PIN and indicated that N+1 signatures had been made before, > suggesting that it had made the previous signature. Again, I entered the > PIN and the message was correctly signed and everything seems to work > normally. There is only one signature on the message -- it seems that > one of the signatures goes missing. > > I've noticed this happening intermittently over the past few months, but > only when using Enigmail and Thunderbird -- if my memory serves me right > it also happens intermittently when I use Ubuntu Linux on a different > computer, Thunderbird, and Enigmail so it doesn't seem to be a > Windows-specific problem. > > Although this has happened for a while, it's only happened > intermittently and I can't reproduce it on demand (e.g. it happened to > the first signed message I sent today, but not the second. It occurred > when I tried signing this message.) Has anyone else observed this > behavior? If so, is there an explanation? Nothing nefarious going on, nor is it a bug. Take a look at the source of your PGP/MIME signed email. > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --===============0134039850== > Content-Type: multipart/signed; micalg=pgp-sha512; ----------------------------------^^^^^^^^^^^^^^^^^ > protocol="application/pgp-signature"; > boundary="hORQu9nh08cKrD0xFen8m9Kf4P5mAgQLH" > > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --hORQu9nh08cKrD0xFen8m9Kf4P5mAgQLH > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > --===============0134039850== In order for Enigmail to generate the outside email header (multipart/signed...), it has to know the digest that will be used later to construct the signature part, in this case SHA-512, but all the message processing happens in a single pass with the signature part at the end. To do this, a small test message is signed and then examined for the digest that was used. This is the first time you are asked for your PIN. The second is when the message signature part is being generated. We used to see this on the Enigmail list a lot as folks started using gpg-agent instead of Enigmail's more limited internal passphrase caching. With no PIN/passphrase caching in effect, I'd expect you to be asked twice on PGP/MIME messages, but only once on inline OpenPGP. HTH, -John -- 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: 520 bytes Desc: OpenPGP digital signature URL: From mlists at robin-kipp.net Sat Oct 12 00:22:05 2013 From: mlists at robin-kipp.net (Robin Kipp) Date: Sat, 12 Oct 2013 00:22:05 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <525755F5.1050805@sixdemonbag.org> References: <525755F5.1050805@sixdemonbag.org> Message-ID: Hi Robert, many thanks for your reply! Am 11.10.2013 um 03:35 schrieb Robert J. Hansen : > Leave off the 'expert' flag and just use the defaults. Seriously, the > defaults are reasonable and don't need tweaking. :) I only put the --expert flag because I wanted to take advantage of having a main key that can only sign and certify, and which I can then store offline. I know it's perhaps easier for a beginner to start out with a single key for everything, but since I think I understood the reason one should have several subkeys, I thought it would be best to start out as such and (hopefully) not have to revoke the main key because of any stupid mistakes? Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mlists at robin-kipp.net Sat Oct 12 00:53:30 2013 From: mlists at robin-kipp.net (Robin Kipp) Date: Sat, 12 Oct 2013 00:53:30 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <7636240.8X7SKMvsXs@inno.berlin.laging.de> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> Message-ID: Hi Hauke, Am 11.10.2013 um 03:32 schrieb Hauke Laging : > > It seems to me that the more accepted recommendation here is to have separate > subkeys for signing and encryption. That's something I simply wasn't sure about, but now I have revoked the old subkey, generated 2 new ones and submitted the new key to a keyserver. I will append the new public key at the end as well. > I know of no good reason for creating a mainkey without expiration date. Thanks! I changed that to something more reasonable for the main key now as well. > > Furthermore it would be nice to have a UID without email address but with a > comment which explains the security of the key. Something like > > "Robin Kipp (normal security level subkeys with offline mainkey)" This is something I'm not really sure about, for the reasons that Daniel pointed out in his reply - putting in such a 'dummy UID' might confuse someone wanting to sign my key, as it cannot be verified. > > This should be explained in more detail in a key policy which you should make > publicly available and put its URL into the self signatures (see --set-policy- > url) for the UIDs (and maybe even the subkeys). You should also set your > preferred key server in the selfsigs (--default-keyserver-url). As for the key policy, I'm still considering what to put in there. Right now, I'm just more concerned about my knowledge of GPG in general and getting my keys right, as I wouldn't want to sign someone else's key before my knowledge and understanding is more mature. As for the preferred keyserver, I think Daniel's comment on that makes sense. For example, I use eu.pool.sks-keyservers.net, which links to a pool of servers rather than just a single server. I'm not sure if putting in an address like that would make sense at all? Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mlists at robin-kipp.net Sat Oct 12 00:57:57 2013 From: mlists at robin-kipp.net (Robin Kipp) Date: Sat, 12 Oct 2013 00:57:57 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <7636240.8X7SKMvsXs@inno.berlin.laging.de> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> Message-ID: Hi Hauke, sorry? Forgot to append the key before sending the message, so here it is? -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org mQENBFJXKMwBCAC8DIDNqCRRdF9EqNJk5612/wsoUCTjC3D6Ipt1lDnR4NrI2VYm JjhnxBhmnsKP2M7Sco0zXycaygaNAEA+GBdAR1s1XxD85GRjTWToMf4DsVfuZPUM Kk20MqG2TOq9aSqEsoljCuu0M+pcPjALeCztf7GuC8fEbXKUAtQ3m01achYc22q0 IFkahEk/EPjvOPujO/T/+jqpt7OWyBtYPKkfnGsWqfUkWE0fEJl1xj28JyrT7ajU QSYVbVyJFTxTNMiD6gQwt0LVcibCFoYDil8BQEwrZX8I3r1azJoI2cRV33AmFaf+ Kc3fbMX45pA+wIUTOgtQqz01wjuLBYkRKwxVABEBAAG0IVJvYmluIEtpcHAgPHJv YmluQHJvYmluLWtpcHAubmV0PokBQAQTAQoAKgIbAwULCQgHAwUVCgkICwUWAgMB AAIeAQIXgAIZAQUCUlhzvQUJBaTlcQAKCRAiWBum3DKYdpWHB/9VAZPD7YuFJUWk Kx5Ey754faZqEjEvztxhcdVLNdwgH++o/q3zIlUipEmA9STe2PGY4pu1CDyTJOyQ NGKRkWowhC6lGYLvEeAEGaP0P01kCaLLwn8+5rtl94o3hdlJlEyPt690DHfBoEH6 zrUON73ie6ekQIr9YdMALU5U9lkSx6we7mMYgax8UijI9KlkOyxSRix2FWKP9VPa kYicWMf8wHMr1ypk7WVE1qpMkSUDFw/zmclWaDtIm4FxLVbeNsTqlL5iIfQYhTPC mXHm44JJOzXbwnA8stPYLXx1WbHmcit82NueQcdlCKGhH6z09o6x/Gp6rfQ6EkEG ROuEVUIHiQE3BBMBCgAhBQJSVyjMAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheA AAoJECJYG6bcMph2hYEH/iW+z362b7eIJVjcVCodfpZHVzC2rPYJfODbMnPbP24q qnw+ojklaYuI0GSfd7obgVvMisTgnKyNuo81bLEmR4j/vGTu3g1sexuRmympeNRZ BO9AJz9pcwsqL8Xlf6M0p6R2qKYkBeh0Ur6YpLyhPDOsXhDfvVIDbz33j2KTvpVH a+0abOQjUhILV4E19yFrfEDie0NYwG82lDcs/5AfT7g99XeDC69CFfJDArydHP6q BegwmrZYhIdES71sYoPsnEnAdBtDDs4AC6Rx8M3QSZymG0eTx1iZ7iggjsIbFE2o DY/ryHFSvI22OpMmGuraM78cx1B6UDzs5YM/Ojv1pKm0IlJvYmluIEtpcHAgPG1s aXN0c0Byb2Jpbi1raXBwLm5ldD6JAT0EEwEKACcCGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4AFAlJYc70FCQWk5XEACgkQIlgbptwymHZUdQgAhSNVeGi1slgWUSVI YL2nZ1vCqu/Iz0VySH0nzoVOCgN7d69Wb5MU/B2HiY66yh5z4uUHplN9DVjfvywx egS2WlvZ+ka6flS4d5av4LjNr3wOW7ywetFo4JFjC8VkscYxKkLwXiC8RrE10B5v vslkvZMcvOfjEribVmyjGhwfSyYJgucpGUV7cteG22XW2DaOKVTcYkKCUBXyInD9 P1A2ZIQXU80HtmdrVX7RflBwoW/YR9DBXP8y6wuIhCMZVhO1TG/r+mzmqpDAk2mP weF+nO3Ec1mq1CSpgpUpSUdyoiiXC1CpCuc59BkJ5b7JZmIRTJ603Kalxiwdv0WD Ux1ribQfUm9iaW4gS2lwcCA8cm9iaW5AZGVic3BhY2Uub3JnPokBPQQTAQoAJwIb AwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAUCUlhzvQUJBaTlcQAKCRAiWBum3DKY dmxDCACLoXgc7tITyvxj3YOY04diGyEqoob3XILTOyDOT+mNWoE9X5QTxXxoD8Fd KRyyZc8cBg0kAHHM3l0PCe9tFu7nXB0ahkvPN8SR/3bkJkGItDq/Nfd3HaASVKfg PTd68uP4DcuSuUggqHq3koGXNOdNTEtD6YbsQxbuzDoMjmCm6z4IFOe9aPCoC/Ld 7PwDbR7zfpsVbNHJqd7XrZoEveF/m/BPItMjgeV2sDRQ9csLheZLWhwJlH6DJAJt U+qv00moL1kXiQ7Ic7eWi56JxRmr++0N5uNws9vXIYmW92fndiaKtJYcTE9lD+Yz BjyLQADKXn0WGQwyDnMR1s2DXgSnuQENBFJXKY8BCADdCRlCh2Gc3ULtspU+fd/i 9G0Dzv8J26cSqshD74RVqVtSIQCQ6D79rUe6/Tdy3BYVXGsxmWYkBlnyocoITgPi z8j8LrsCLZq+kVZ1qCFonWv7nErMnVDfdyfJAZ99bG9D1lhCVj1J7Q0wGgN8Af2X v5W/ZRerW7p8VuLf64SR1bdEsUASz0FyLwfa6GTlvjRIjZxOSpxfjduo9BewVL+t AKMjQjLVPeccqNf5piB8i4ywPklnXnNrbRL5m4Sk+nBTIK1+Sb4/RR7AQPLzahV2 ePZ+41hrsUmZFtxtSHgSUX0+QxdNW10TPF+D4yInB2gOytaFszSvyNd385+VgJA7 ABEBAAGJAWAEKAEKAEoFAlJYc0NDHQFUd28gc2VwYXJhdGUga2V5cyBmb3Igc2ln bmluZyBhbmQgZW5jcnlwdGluZyBoYXZlIGJlZW4gZ2VuZXJhdGVkLgAKCRAiWBum 3DKYdg21CACkCt56M6QgIeE47TSFQTo7Q4oH7B85dWmJzD9IbP00554oioVony9u +yk/Q6U3hZPZh1DEg2/EEX6/UOaeWMmWcVUfgvgkS5oaTRodrdjLET7k6bv0Y+mi Osgiwid6wtLEv6EjRc4a+BPkOPtlyVt0M8TJKVDPMRqBKqXJz3uiHdUXmXEmxaHY 7nyrFoWZNUsN6KtdpeLRT3oM8J+JhHxb2iwuF7JvGkEAjDVfItA7qPOzV2MEH/L1 Yb98UUTuUWVFddDrwcZqd6GzjsAq9ZLwGZU0t3X0X/U4hARu+PSGzqxKViImcl1R aTSb3JmghJlLFCKLnhRjUk/Dw43iX1HliQJEBBgBCgAPBQJSVymPAhsOBQkAJ40A ASkJECJYG6bcMph2wF0gBBkBCgAGBQJSVymPAAoJEPSK7yl33/8IqsMH/jpqd6Uc 3rpzMSd0qhNy2XACGgZ3BadVGCBr43VyoD6erWjI+eF+z3FOo/OIsk72AwtaWWgf lkKMcftLln1CcF4LOtmrn7uaVqMBD76cV3G2TdUzKOkjXHz1asEnF8E8s4ppF/yO xJ5oZs4oV5fBJvvXw6BdFTTJqF3V6BA0i2i4TUdwCwbZshIPROFg4ram2IWvS9SS r/4amLm8onFiD2mSExei3SKSkyEIWZ/L1XN8Rwxz8PUrPWvkZ1EJWDsUIXxzqPI8 ykDsSSoEaE4lrIvz0mwt7pq5irWpoSta5rnOo7ZGOPEKA374giFcJjuF8lbCa5lg a2ABXXDSZLU3Cu2Nfgf/eZzTqxYWHuuyVp5jC6syyavXvxtG7JUgaa/YkhqTRq/j anTHL4h4Dfw2qqCe2i36iKds90B/yywvMAwJnyizwSRTUHYsDgdqFkxRNJZgajBs eTfMHYOAZkrHKJln0gxRNFsUiuKfHVT/QCCFGFEMnAScbh7YMQFcKsT3qx3KE2rU GRerkDUqTLFvltNBRqY6PIkITo47GQWYvdsBabWvyzDzFmZaw/QBeMww7s+0VvK1 z9oaT+T3/88N4Vb7bs0hikNoVvpMldiE0QTp7kYlv03sPZLIO5MjxgkSIG7xKaHT FbN2aVgj9WwkgTzEaZ1mcx7FbPgF64LCZ/7ipmb3LbkBDQRSWHPXAQgA3GTV+PEw gtmo+D7/yCwjlUl9zke4WaEZweTtWdvUKMz8IuLsWCzD4iDybeBbeH5WQAmIH/l0 qBXaOl3By9+GuR+b8VFDK/JOIqV5O0T1hhdrSDO4G5V4xjgyGfryiWKSAoEi7Mxs aDwOj4TogguPzTjYR2vRALjG3wylEN7QVDy3DhxzuZg4lQHfiVphn42Lf36rHuyO 2bYQVewvPy1gnU4r0yt7/PYO/ofnPJ7xEm5iLMyz7r5sUnEDl1IuubRaSP6i7bS1 IbcnoEwqUKPLcT2mc+TQJxC3wqzAE3t0LHFHF9k4BQaTh5vzBSZeTYEsNX8aWBKV c4gxG5QlKkCZ4QARAQABiQJEBBgBCgAPBQJSWHPXAhsCBQkB4TOAASkJECJYG6bc Mph2wF0gBBkBCgAGBQJSWHPXAAoJEOj7Ygo756DDAbcH/ifeBffM0LRdB0YE0yX3 4cJg4MmcAE6Cs/DfOnFp4c3mGnt7/BLGuzxTQ/DhkUxuTcGfr/VvPnkY0sqmziJQ tHPnehjsv5qC291Enbv7ZuGmQhZ6EvHFJgWo/JKlCktKUmoqqJoOD4Pjd6SQRwMU izw675LyvATEmaompRtOwp8HIWyXx7oH6L5tiEJ9Ck54VEna3drCzDU5cHqYbLGz sCl7YpgsF/i1ZHQ1gabxqwfc0ACX5vaQM05qWteS3bQeLEOS9r1HMXEx/4d4ztz4 OBd3ZC+yK9hNKI9QM9ARUO3rT73IyJJW7E9vOEBgNHpGA1zZh/3d9JOXl2nGWKF1 iG0iSggAuq0KwoTf0XvZ5gQXWo0Uc1I3+Px/N800QKtX2w5FXQQl+XVsfCOlj7Lj b3huQ6Sn0mtZKWt47n9SEaCqnR5Xd9c1u3WWOz1yTUElgwtMIPX41jGZLY3kwbe1 ZDVH+BPc9ApRCtt0I5oER72pypIJhvTKi0/Py+8ioNSAZBpmJsin1VdOe7XHp9bd qtPTrLcM0VQVv5N7AQrnFxUDu09LW9a2GL15Gm+x5F4BY7ax90SXHjHgHcUQT2lx jA9CBu1OU854fO8+6sPiZUsDLVuztNk3PKZDImwFbk+QgXbBWf3zHwCnEOMNYoKi Lty4Et1/zIwIB3c+kIBaAMU15dnIPbkBDQRSWHQ7AQgAwSlhqwn6dWR1YRYuMgeb 6iq60J4NLUbIqPE5d01tkQodh+dlRtkaq4qIfsY2XXVGE4AuyG/Cc27w0tKFtfiu 6Vk+/1G8UkAHtDVQhspcItTXjx2phbQYXG2c0Y+NV9vrzP9azmzpWI13UEhsqPOf 9FBGUa6XNu1hd50aDwNzv6FIutYcrNqhTWQJvF2yvUN0ofWYNbvC7+Fk9aAtUyzN 6l/a0qjdVJaqNCiTgpc8Itn9PSYd4d28+YT7cLRmjvmTZeE36CYxePy7LyEE1dhY ZqwmbRe5AhnaHdYRuCsQ58aN+frb4JqtQPBeXnf07Y3NdlD30Ik3olUZS2eVJ/lI RwARAQABiQElBBgBCgAPBQJSWHQ7AhsMBQkB4TOAAAoJECJYG6bcMph2excIAKx4 R4rznTEs8WRmV4/X+Dn+UAGGy7ACY9IdsNhpBVF7COcEJqwAH9T8+Vmd6pJacusg 3mztvS2ufmL4d9D4W+COAHxkGaR1eahOc8pSM7yPV3c3MEaOOlmfIza6m3ad3eee ZDi1UvAJJ0+ucrp4Otbnj1YXaXXX8NkRuNIcb6bYhT2CuM3DJKzvwep6J5SADXrB PaTRf5H5Jh3AkAa+ZDPBV/1T9vFIG/zwKqeqv7HcPhSWBAHaPgsYBgtB5u4J0nri 1hPpbUC1FgN3kXwHHi9cZ0GIY98iDhB/q9BzZYpVBbyQXKqNtRJ2maPNmuMSAE4a ISAAEWq2K+rwKxFZmQo= =t5+4 -----END PGP PUBLIC KEY BLOCK----- Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mailinglisten at hauke-laging.de Sat Oct 12 01:10:16 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 12 Oct 2013 01:10:16 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> Message-ID: <6877190.vANIcmFNIe@inno.berlin.laging.de> Am Sa 12.10.2013, 00:53:30 schrieb Robin Kipp: > > "Robin Kipp (normal security level subkeys with offline mainkey)" > > This is something I'm not really sure about, for the reasons that Daniel > pointed out in his reply - putting in such a 'dummy UID' might confuse > someone wanting to sign my key, as it cannot be verified. It is a very strange assumption that only such things should be certified that can be "verified". The certifier makes a statement. This is a) "I have seen a passport or similar document and compared that to the person I met" or b) "The person I met has claimed that the mainkey of this certificate is used in a secure offline environment only" What makes the one statement better than the other? You usually cannot prove that a certain person has shown you a certain passport-like document. And without a manual signature you cannot even prove that the person has claimed that a certain key belongs to him or her. The WoT will stay close to useless if we do not get a system for certifying such status information. And what do you lose if someone does not certify this UID? Nothing. On the other hand many people who were not aware of the feature learn that there is something called an "offline mainkey" and thus may learn something very important about crypto keys. > as I wouldn't want to sign someone else's key before > my knowledge and understanding is more mature. For that problem the local signature (lsign) was invented. > As for the preferred > keyserver, I think Daniel's comment on that makes sense. For example, I use > eu.pool.sks-keyservers.net, which links to a pool of servers rather than > just a single server. I'm not sure if putting in an address like that would > make sense at all? Robin I set eu.pool.sks-keyservers.net as the preferred keyserver for all keys which I create or help create. Why should that be a problem? Because we don't know whether some technical failure may occur? Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From mlists at robin-kipp.net Sat Oct 12 01:11:48 2013 From: mlists at robin-kipp.net (Robin Kipp) Date: Sat, 12 Oct 2013 01:11:48 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <52576FBC.9030300@fifthhorseman.net> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> <52576FBC.9030300@fifthhorseman.net> Message-ID: <4D67A010-4421-4981-BF17-DEEF2C249E97@robin-kipp.net> Hi Daniel, Am 11.10.2013 um 05:25 schrieb Daniel Kahn Gillmor : > This is absolutely correct. You should not be re-using the same RSA key > for two different usages if at all possible. See, for example > https://www.schneier.com/paper-chosen-protocol.html Many thanks for that advice and the link! As I said in my previous message, I've now revoked the subkey and generated 2 new ones. > > You can fix this by simply revoking this subkey and adding two new > subkeys, one for encryption and one for signing. GnuPG will > automatically select the right one to use for whichever purpose. I did just that, and now have 3 subkeys: the revoked one, one for signing and one for encrypting. However, after checking my last couple signatures, it appears GPG is now using the revoked subkey for signatures, which, of course, is not good at all! What do I do now, do I have to delete that subkey? > >> I know of no good reason for creating a mainkey without expiration date. > > I also agree with this. An expiration date of 3 years is reasonable. > If you're using the key actively and you do not believe it has been > compromised two years later, it should not be much extra work to extend > your expiration date for another two years. > > The expiration date on your primary key gives you a failsafe endpoint in > the event that you lose all copies of your secret key material and your > revocation certificate. (you do have a revocation certificate generated > and stored someplace safe, right? i didn't notice that in your list of > steps) Many thanks for the great explanation! I now edited the expiration date of the main key? As for the revocation certificate, I have to admit that I didn't generate that right away. To be honest, I kind of skipped over that option, as I suspected that this would immediately revoke the key? Well, I do have it now, and it's stored in a safe place as well :-) > > I disagree with these last recommendations from hauke. Take that as you > will. Well? This may be a question of personal preference, and I could well imagine that religious battles have already been fought over questions like that... > > I don't think such policy information in the User ID is particularly > useful to other people (i'd be interested to hear of a situation where > that communication actually changes peoples actions and where it can > only be made through the User ID as opposed to, say, on a web page, a > blog post, in-person communication during keysigning, etc), and adding > comments like this to the User ID makes it more difficult for others to > decide whether to certify your key (since they may not be able to verify > the claim you're asking them to assert). Very true. I think that a user ID should perhaps always contain a verifiable component, such as an EMail address - well, I guess someone could even put in their phone number or street address if they so desired, right? > > i hope this analysis is helpful, Yes, thanks a lot for the effort - greatly appreciated! :-) Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dougb at dougbarton.us Sat Oct 12 04:02:37 2013 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 11 Oct 2013 19:02:37 -0700 Subject: First steps with GPG, am I off to a good start? In-Reply-To: References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> Message-ID: <5258ADBD.9070907@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/11/2013 03:57 PM, Robin Kipp wrote: | sorry? Forgot to append the key before sending the message, so here | it is? Please stop sending keys to the list. That's what key servers are for. :) Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSWK29AAoJEFzGhvEaGryEsBwIAInWyJUnfYiNFQvVhIh7hkXa 9TU0PfCuwb8PVqxmO10GgbqMGkxn9FrjeYTQZUUdB6XdWOOnQMPqCs0Cb2zWMO9u GZR6VuD/5bE2uhwrQIn3YOuvVmZ5dnhZAgwINhSjtbuhqf70UqrzsGj7n9vbsYLs ND/lWti0T2XGAxp2Bfi1yycL313t3HFIhy8kwLJ55hTQWBfzN9wOLBRnk5+1XRp2 Zk2VMtGqpGNUV0JKsf8K099VeKt20XbnZ93d3QHACAd19tm0XpcnfpHDe6QPXzRS sMiFwApSPqsI+B9qYsnpOOF0zbI+AyoKm8DeVdyxlyPp4gOVXtUMAqPKnQhZwgU= =dpZS -----END PGP SIGNATURE----- From dougb at dougbarton.us Sat Oct 12 04:09:19 2013 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 11 Oct 2013 19:09:19 -0700 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <7636240.8X7SKMvsXs@inno.berlin.laging.de> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> Message-ID: <5258AF4F.1080809@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/10/2013 06:32 PM, Hauke Laging wrote: | I know of no good reason for creating a mainkey without expiration date. I know of no good reason to use expiration dates at all. Most end users don't know how to properly refresh their key rings, so if you extend the expiration date you will simply inconvenience anyone who is trying to communicate with you via encryption, and likely generate questions about why your messages are signed with an expired key. And what is the threat model that expirations are supposed to cover anyway? That the person loses control of the key, and any revocation certificates that they may or may not have generated? What is the practical effect to me, as someone with that key on my key ring? A responsible person who lost control of their key could still send messages to those that they correspond with and/or have signed their key saying "Hey, I'm an idiot, and I lost control of my key." But then again, such a person probably would not have lost control of the key in the first place. So if there is actually a threat model that expiration dates on keys helps with, please educate me. Otherwise can we stop recommending them? Especially to new users? Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSWK9PAAoJEFzGhvEaGryEZwcH/0DBHqon4JaS0lXZ7py0Qngp GQxnrBollk+B4/BEswHYdDvTYWA7mekRUkKDjyy6NPDd1AlNsWiZZw6KgRolRDAK g/R+qF4c0jKkBfpYgEXzjAkiyrVy894KEcWbNOlJ/u3stwIfVfKyN70pl1tfCR85 1Qi66OFloCanKNUy8P+aCoUrGKcUozSgEtXOkfXBbKWz7uOXHCg9EAl7eAmNBMuj KKK5JKzqzMqHsSmz3G3A94mp/9iPEYVgkbuXMQoRiF/0R5CbwTVxmeXuSi5S8QtL lNZtLmcpk8FJhccwSycCAxj6kDhiNXxuoEMRVmnQ6cEvjOQg8nGzg0WcAnj0PB8= =gE6T -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Sat Oct 12 04:22:29 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 12 Oct 2013 04:22:29 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <5258AF4F.1080809@dougbarton.us> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> <5258AF4F.1080809@dougbarton.us> Message-ID: <5083099.I3iosbLdh5@inno.berlin.laging.de> Am Fr 11.10.2013, 19:09:19 schrieb Doug Barton: > On 10/10/2013 06:32 PM, Hauke Laging wrote: > | I know of no good reason for creating a mainkey without expiration date. > > I know of no good reason to use expiration dates at all. > > Most end users don't know how to properly refresh their key rings, So avoiding the "I'm an idiot" message is not a good idea but not teaching people simple tasks is. I beg to differ. > you extend the expiration date you will simply inconvenience anyone who > is trying to communicate with you via encryption, I don't care much about people who are not willing to learn how to use the tools right. The tools can be made easier, information can be made easier to access, the number of people who can be asked should anyway be increased by orders of magnitude (unfortunately, that's the hard part). If someone is neither willing to do it right nor willing to ask somebody then I will certainly not reduce security or convenience for the other ones just to do him a favor. The aim of my recommendations is to make the whole crypto environment better not to please single people. > And what is the threat model that expirations are supposed to cover > anyway? If there is a real threat then it is probably rarely going to happen. But the point is: Threats are not the only argument for crypto recommendations. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From dougb at dougbarton.us Sat Oct 12 04:47:38 2013 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 11 Oct 2013 19:47:38 -0700 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <5083099.I3iosbLdh5@inno.berlin.laging.de> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> <5258AF4F.1080809@dougbarton.us> <5083099.I3iosbLdh5@inno.berlin.laging.de> Message-ID: <5258B84A.1060803@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/11/2013 07:22 PM, Hauke Laging wrote: | Am Fr 11.10.2013, 19:09:19 schrieb Doug Barton: |> On 10/10/2013 06:32 PM, Hauke Laging wrote: | I know of no good |> reason for creating a mainkey without expiration date. |> |> I know of no good reason to use expiration dates at all. |> |> Most end users don't know how to properly refresh their key |> rings, | | So avoiding the "I'm an idiot" message is not a good idea but not | teaching people simple tasks is. I beg to differ. Twenty years of experience shows us that it's a lost cause. PGP is simply too hard for "average" computer users. Even those who use PGP, which by definition makes them "above average" commonly don't refresh their key rings. So whether either of us like it or not, any plan that requires users to refresh their key rings for it to work is simply impractical. ... and I left out another problem with expiration dates, users that set them on their keys and are not aware that they can be extended. Robert's right, the defaults are what the vast majority of users should use. |> And what is the threat model that expirations are supposed to |> cover anyway? | | If there is a real threat then it is probably rarely going to | happen. But the point is: Threats are not the only argument for | crypto recommendations. Um, of course they are. Otherwise you're just participating in "security theater" and wasting everyone's time. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSWLhJAAoJEFzGhvEaGryEZm4H/RV4Fg8cM1ycMH9OYU9U+RXh vZNE+r3qFXI6O1QW/gaiADEvSc000x4Di6oBH7UYgtPB28a/5MOw+koOCtPMnMSz UBEFGlxVv91+W+qIY4Pqc8oWOUQT13GcFWC8lGqbArX6gzXB9aQR7dzD9Y5bcuB8 Q6bR1J/Et4WVLKZsjnLs50v/bv+B4KfqlHU+i7kzVrlGog+rfspe1ogLw7IT+fWU sK4buQYoyDT4basFcz+ypXKF3LVqbP9JfJbp2DUswoN5NgC84RQqjrxpKxMG4SEv Uj/NYqgh1ZXTLmoL4nCepCCtqv6yGcsVJHTrY3Mcf6sKgSfO1TtBXH1PumUAPjk= =aRav -----END PGP SIGNATURE----- From lunar at debian.org Sat Oct 12 05:25:45 2013 From: lunar at debian.org (=?iso-8859-1?B?Suly6W15?= Bobbio) Date: Sat, 12 Oct 2013 05:25:45 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <5258B84A.1060803@dougbarton.us> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> <5258AF4F.1080809@dougbarton.us> <5083099.I3iosbLdh5@inno.berlin.laging.de> <5258B84A.1060803@dougbarton.us> Message-ID: <20131012032545.GC6390@loar> Doug Barton: > Twenty years of experience shows us that it's a lost cause. PGP is > simply too hard for "average" computer users. Even those who use PGP, > which by definition makes them "above average" commonly don't refresh > their key rings. So whether either of us like it or not, any plan that > requires users to refresh their key rings for it to work is simply > impractical. Yet, no one came up with a tool as straightforward as parcimonie?[1] before two years ago. My keyring has been fresh ever since I could `apt-get install` it. Easy to use public key cryptography is a hard problem. Maybe PGP has some issues that can't be solved, but I believe we are making progress in understanding how to make the whole experience more enjoyable. [1]?http://packages.debian.org/wheezy/parcimonie -- Lunar .''`. lunar at debian.org : :? : # apt-get install anarchism `. `'` `- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rjh at sixdemonbag.org Sat Oct 12 05:59:55 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 11 Oct 2013 23:59:55 -0400 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <5258B84A.1060803@dougbarton.us> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> <5258AF4F.1080809@dougbarton.us> <5083099.I3iosbLdh5@inno.berlin.laging.de> <5258B84A.1060803@dougbarton.us> Message-ID: <5258C93B.8060104@sixdemonbag.org> On 10/11/2013 10:47 PM, Doug Barton wrote: > Twenty years of experience shows us that it's a lost cause. (Please don't read this as disagreement with Doug. Rather violent agreement, in fact...) I have told this story several times on-list: apparently it's time to tell it again. ===== Some years ago during grad school, my colleague Peter Likarish came up with an interesting phishing-detection technology. He turned it into a Firefox plugin. Whenever the engine thought you were on a phishing site it would put a small red banner over the top of the page with text reading, "This may be a phishing site." During human trials he got a number of "real users" to experiment with his plugin in a controlled laboratory environment. Amazingly, despite his detection engine working perfectly not one single user managed to avoid giving data to a (simulated) phishing site. Peter figured the problem was the banner was too unobtrusive. In version 2 the banner would start off as a thin ribbon over the top of the page and would gradually grow until it took up about a third of the page. If the user clicked a "Dismiss" button the ribbon would vanish. In the next round of human trials the clear majority of users clicked "Dismiss", and yet not one single user managed to avoid giving data to a simulated phishing site. Finally, Peter did one-on-one guided walkthroughs of the plugin. He would sit there beside a user, watch, and ask questions directly as the user was doing actions. The first time someone clicked "Dismiss," he asked, "So what did that banner say?" "I dunno," the user answered with a shrug. "I don't read Flash ads." ===== There are two types of people on this list: the ones who know that on some level they're Real Users just like everyone else, and the ones who believe they're part of some anointed geek elite that's immune to such pedestrian mistakes and thereby have just made a Real User mistake. We literally cannot make GnuPG simple enough. The more we use agreed-upon default behavior, the fewer opportunities there are for us to go all Real User on ourselves. > PGP is simply too hard for "average" computer users. My only objection here is the use of the word 'average'. > So whether either of us like it or not, any plan that requires users > to refresh their key rings for it to work is simply impractical. More than that: if the enforcement of *your* security model ("I've got an expiration date in order to...") depends on *other people* cooperating with it, then you don't have a security mechanism at all. I have a security model: my email should not be read in transit. I'm cheerfully depending on all parties interested in my email to understand this and to respect my policy and help me enforce it by cooperating and voluntarily choosing to not read my email. Sounds kind of silly, no? My key expirations should be respected. I'm cheerfully depending on all parties who use my keys to understand this and to respect my policy and help me enforce it by cooperating and voluntarily choosing to refresh my key at periodic intervals. It's the same thing, and the same level of silliness. > Robert's right And I am enough of an egotistical S.O.B. to love hearing this. :) From rjh at sixdemonbag.org Sat Oct 12 06:04:28 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 12 Oct 2013 00:04:28 -0400 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <20131012032545.GC6390@loar> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> <5258AF4F.1080809@dougbarton.us> <5083099.I3iosbLdh5@inno.berlin.laging.de> <5258B84A.1060803@dougbarton.us> <20131012032545.GC6390@loar> Message-ID: <5258CA4C.6080102@sixdemonbag.org> On 10/11/2013 11:25 PM, J?r?my Bobbio wrote: > Yet, no one came up with a tool as straightforward as parcimonie [1] > before two years ago. My keyring has been fresh ever since I could > `apt-get install` it. I've been refreshing my keyrings via cronjobs since 1996. One single shellcode statement and bang, at 0400 each morning my keyring gets updated, and... ... well, wait. Hmm. Guess since it uses a shell statement I can't call it 'straightforward,' since it requires a level of skill beyond that possessed by the vast majority of the populace. Just like using Debian, period, requires a level of skill beyond that possessed by the vast majority of the populace. I'm glad you love parcimonie and I'm glad that it fits your needs, but let's not confuse "it is aimed at my skill level and I do not find it challenging to use" with "it is a straightforward tool for everyday users". :) From peter at digitalbrains.com Sat Oct 12 11:43:15 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 12 Oct 2013 11:43:15 +0200 Subject: First steps with GPG, am I off to a good start? In-Reply-To: References: <525755F5.1050805@sixdemonbag.org> Message-ID: <525919B3.1000809@digitalbrains.com> On 12/10/13 00:22, Robin Kipp wrote: > I only put the --expert flag because I wanted to take advantage of having a > main key that can only sign and certify, and which I can then store offline. The defaults are an RSA primary key for certification and signing, and an RSA subkey for encryption. Even without the --expert flag, you can also choose to generate a primary key just for certification and signing, and then in a second step add more subkeys. The choices of keys you get without --expert are: > Please select what kind of key you want: > (1) RSA and RSA (default) > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) So you don't need the --expert flag for that. 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 pete at heypete.com Sun Oct 13 15:32:20 2013 From: pete at heypete.com (Pete Stephenson) Date: Sun, 13 Oct 2013 15:32:20 +0200 Subject: OpenPGP Smartcard + signing email = two signatures? In-Reply-To: <52586220.8010402@enigmail.net> References: <5249E8BF.3090802@heypete.com> <52586220.8010402@enigmail.net> Message-ID: <525AA0E4.6080000@heypete.com> On 10/11/2013 10:40 PM, John Clizbe wrote: > Nothing nefarious going on, nor is it a bug. Take a look at the source of your > PGP/MIME signed email. > >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --===============0134039850== >> Content-Type: multipart/signed; micalg=pgp-sha512; > ----------------------------------^^^^^^^^^^^^^^^^^ >> protocol="application/pgp-signature"; >> boundary="hORQu9nh08cKrD0xFen8m9Kf4P5mAgQLH" >> >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --hORQu9nh08cKrD0xFen8m9Kf4P5mAgQLH >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> > > > > >> --===============0134039850== > > In order for Enigmail to generate the outside email header > (multipart/signed...), it has to know the digest that will be used later to > construct the signature part, in this case SHA-512, but all the message > processing happens in a single pass with the signature part at the end. > > To do this, a small test message is signed and then examined for the digest > that was used. This is the first time you are asked for your PIN. The second > is when the message signature part is being generated. Aha, that explains it! Many thanks. I never really made the connection between that section in RFC 3156 and this behavior. > We used to see this on the Enigmail list a lot as folks started using > gpg-agent instead of Enigmail's more limited internal passphrase caching. > With no PIN/passphrase caching in effect, I'd expect you to be asked twice on > PGP/MIME messages, but only once on inline OpenPGP. Oddly, this doesn't always happen, even with the "force signature PIN" bit set on the smartcard. That is, in-line signing only requires one PIN entry. PGP/MIME often requires the PIN to be entered twice, but not always. Some informal testing over the last few minutes seems to suggest that I'll be prompted for the signature PIN twice when sending the first PGP/MIME message of a particular Thunderbird session. If I don't exit Thunderbird and send other PGP/MIME messages then I will only be prompted once for each signed message. Exiting Thunderbird and re-opening it resets stuff, so I'm again prompted for two signature PINs on the first PGP/MIME message but only one on following messages. Does Enigmail cache the hash type used for the signature for a length of time (say, the duration that Thunderbird remains open) so it doesn't need to prompt for two signature PINs? > HTH, > > -John It does indeed. Thank you. Cheers! -Pete From expires2013 at ymail.com Sun Oct 13 16:48:09 2013 From: expires2013 at ymail.com (MFPA) Date: Sun, 13 Oct 2013 15:48:09 +0100 Subject: First steps with GPG, am I off to a good start? In-Reply-To: <6877190.vANIcmFNIe@inno.berlin.laging.de> References: <7636240.8X7SKMvsXs@inno.berlin.laging.de> <6877190.vANIcmFNIe@inno.berlin.laging.de> Message-ID: <1279823608.20131013154809@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 12 October 2013 at 12:10:16 AM, in , Hauke Laging wrote: > What makes the one statement better than the other? You > usually cannot prove that a certain person has shown > you a certain passport-like document. And without a > manual signature you cannot even prove that the person > has claimed that a certain key belongs to him or her. It all just boils down to whether you believe the person making the statement. > And what > do you lose if someone does not certify this UID? > Nothing. Indeed. So long as one UID is certified, the certification can be counted by GnuPG when calculating trust or validity for the whole key. - -- Best regards MFPA mailto:expires2013 at ymail.com The secret to creativity is knowing how to hide your sources. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlJasq5XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pDEgD/i5aip1eR4S7UXhBN6/gH19YqDiebV0XJwFC O4j8bg6uKbfTXeetpi0ivUkpiT+pNTiJjpkjlsdQZCSk0BV7nt+OcVDXDbxuFA6l V75KsW5wFC82FaXwytxFyk8sWcFEXSHebwQvimyTEYPiq8mKjtqvnQLhAZScWQTl NV0BImfx =3J8h -----END PGP SIGNATURE----- From ndk.clanbo at gmail.com Mon Oct 14 06:41:25 2013 From: ndk.clanbo at gmail.com (NdK) Date: Mon, 14 Oct 2013 06:41:25 +0200 Subject: standardized security levels In-Reply-To: <1709409.7fpHdx5CBh@inno.berlin.laging.de> References: <1709409.7fpHdx5CBh@inno.berlin.laging.de> Message-ID: <525B75F5.1000708@gmail.com> Il 11/10/2013 07:24, Hauke Laging ha scritto: > My OpenPGP specific aim is that such a standardized list would be implemented > in OpenPGP applications, probably as a signature notation. The typical user > would have several keys (for the same address) at different security levels. > Thus the sender could select the security need of the data to be sent and the > system could automatically select the most suitable key (or fail if none such > is available). What I still couldn't understand is how I can sign a key saying "I'm really sure of the owner's identity, but I don't really trust him properly handling other signatures" (the typical example is "parents" :) , but the same applies to a signing party... ). IIUC your proposal doesn't address that aspect. BYtE, Diego. From mailinglisten at hauke-laging.de Mon Oct 14 07:12:15 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 14 Oct 2013 07:12:15 +0200 Subject: standardized security levels In-Reply-To: <525B75F5.1000708@gmail.com> References: <1709409.7fpHdx5CBh@inno.berlin.laging.de> <525B75F5.1000708@gmail.com> Message-ID: <19742856.HGrcB3lU5a@inno.berlin.laging.de> Am Mo 14.10.2013, 06:41:25 schrieb NdK: > What I still couldn't understand is how I can sign a key saying "I'm > really sure of the owner's identity, but I don't really trust him > properly handling other signatures" That is a strange question because normal certifications do not include any statement about how much you trust the key's certifications. Two reasons for that come to my mind immediately: 1) Public information may create social pressure. Nobody wants "Why don't you trust my certifications???" discussions. 2) Why should others care about your assessment in this category? There is no need for what you want. And AFAIK it is not possible. The closest feature to that are trust signatures but they carry positive trust only. > IIUC your proposal doesn't address that aspect. That is correct. My proposal does not affect trust. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From c6.321197185 at gmail.com Tue Oct 15 07:42:04 2013 From: c6.321197185 at gmail.com (Ann O'nymous) Date: Mon, 14 Oct 2013 22:42:04 -0700 Subject: New GPLv3 OpenPGP card implementation (on a java card). Message-ID: If anyone is interested I wrote a java card implementation of the OpenPGP card and released it under the GPLv3 Features and limitations: - 2048 bit RSA keys only - On card key generation - RSA keys can be imported onto the card (if using GnuPG v2.0.22 or above, previous versions did not support writing RSA private keys in the CRT format to the card). - On card random number generation - No secure messaging or card clean-up yet. - Tested with gpg2, OpenSC will need a few patches to select the applet by AID. Link to the code: https://github.com/FluffyKaon/OpenPGP-Card There will be a test suite to go with it once I clean the code a bit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at heypete.com Tue Oct 15 11:41:28 2013 From: pete at heypete.com (Pete Stephenson) Date: Tue, 15 Oct 2013 11:41:28 +0200 Subject: New GPLv3 OpenPGP card implementation (on a java card). In-Reply-To: References: Message-ID: On Tue, Oct 15, 2013 at 7:42 AM, Ann O'nymous wrote: > If anyone is interested I wrote a java card implementation of the OpenPGP > card and released it under the GPLv3 Excellent! > Features and limitations: > - 2048 bit RSA keys only Is this a hardware limitation, or could it be increased in the future? Also, are there any smartcards out there that would support DSA/ELG keys? All the cards I've seen and used support RSA only. Cheers! -Pete From ndk.clanbo at gmail.com Tue Oct 15 14:29:17 2013 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 15 Oct 2013 14:29:17 +0200 Subject: New GPLv3 OpenPGP card implementation (on a java card). In-Reply-To: References: Message-ID: <525D351D.70907@gmail.com> Il 15/10/2013 11:41, Pete Stephenson ha scritto: > On Tue, Oct 15, 2013 at 7:42 AM, Ann O'nymous wrote: >> If anyone is interested I wrote a java card implementation of the OpenPGP >> card and released it under the GPLv3 I'm 'more or less' (no time ATM :( ) working on extending standard GPG card protocol to support user-controlled export of keys and ability to keep 'n' old enc keys on the same card. > Is this a hardware limitation, or could it be increased in the future? Try to find a Java card that supports longer keys... > Also, are there any smartcards out there that would support DSA/ELG > keys? All the cards I've seen and used support RSA only. I've only seen RSA (up to 2048bit) and ECC (some "small" fields only) support in Java cards. Some BasicCards should support up to 4096bit (and they're the ones used by offical GPG card, IIUC). BYtE, Diego. From mailinglisten at hauke-laging.de Wed Oct 16 01:30:32 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 16 Oct 2013 01:30:32 +0200 Subject: better handling of importing local signatures Message-ID: <2530180.VGNHtB1MA4@inno.berlin.laging.de> Hello, I think it would be a good idea to change the handling of local signatures. I suggest to import local signatures even without --import-options import-local-sigs if the local signature is by one of the secret keys in the local keyring. That would make the handling of offline mainkeys easier: It would allow the user to avoid putting "import-options import-local-sigs" in the config file (which he is otherwise heavily tempted to do in order to avoid problems). I do not see any reason why the import filter should affect your own signatures. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Wed Oct 16 03:43:14 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Oct 2013 21:43:14 -0400 Subject: better handling of importing local signatures In-Reply-To: <2530180.VGNHtB1MA4@inno.berlin.laging.de> References: <2530180.VGNHtB1MA4@inno.berlin.laging.de> Message-ID: <02DE44D8-E188-4E39-A848-C3793CE724C6@jabberwocky.com> On Oct 15, 2013, at 7:30 PM, Hauke Laging wrote: > Hello, > > I think it would be a good idea to change the handling of local signatures. I > suggest to import local signatures even without > --import-options import-local-sigs > if the local signature is by one of the secret keys in the local keyring. That > would make the handling of offline mainkeys easier: It would allow the user to > avoid putting "import-options import-local-sigs" in the config file (which he > is otherwise heavily tempted to do in order to avoid problems). Have you tried doing this? The code (at least in 1.4.x) already works this way. David From mailinglisten at hauke-laging.de Wed Oct 16 03:52:16 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 16 Oct 2013 03:52:16 +0200 Subject: better handling of importing local signatures In-Reply-To: <02DE44D8-E188-4E39-A848-C3793CE724C6@jabberwocky.com> References: <2530180.VGNHtB1MA4@inno.berlin.laging.de> <02DE44D8-E188-4E39-A848-C3793CE724C6@jabberwocky.com> Message-ID: <2919268.I3TIVHc5ju@inno.berlin.laging.de> Am Di 15.10.2013, 21:43:14 schrieb David Shaw: > Have you tried doing this? Great, once again solving problems I invented. Then I would like to change my request to adapting the documentation accordingly... Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From faustus at fastmail.net Tue Oct 15 22:16:48 2013 From: faustus at fastmail.net (Kevin) Date: Tue, 15 Oct 2013 16:16:48 -0400 Subject: Issues when switching between smartcards In-Reply-To: <3423473.umbEOA4I1j@calvin> References: <3423473.umbEOA4I1j@calvin> Message-ID: <20131015201648.GE20130@beastie.smellysneakers.net> Personally, I have found that "killall gpg-agent" works for me in these cases, without much fuss. However, since you have a different reader, and most probably different OS, etc, YMMV. From wk at gnupg.org Wed Oct 16 11:40:05 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Oct 2013 11:40:05 +0200 Subject: New GPLv3 OpenPGP card implementation (on a java card). In-Reply-To: (Pete Stephenson's message of "Tue, 15 Oct 2013 11:41:28 +0200") References: Message-ID: <87a9i9lfka.fsf@vigenere.g10code.de> On Tue, 15 Oct 2013 11:41, pete at heypete.com said: > Also, are there any smartcards out there that would support DSA/ELG > keys? All the cards I've seen and used support RSA only. You don't want DSA on smartcards - at least not until they are able to do deterministic DSA (rfc-6979). ECC on smartcards is available for a very long time because that used to be the only method to do pubkey crypto with reasonable performance on cards without a hardware exponentiation circuit. The ZeitControl cards have support for some NIST curves but it is not yet supported by by the OpenPGP card application. I am not sure whether it is a good idea to go with the NIST curves because ECDSA suffers from the same problem has DSA. What about trying to implement Ed25519 on a Java card? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From pete at heypete.com Wed Oct 16 12:01:56 2013 From: pete at heypete.com (Pete Stephenson) Date: Wed, 16 Oct 2013 12:01:56 +0200 Subject: New GPLv3 OpenPGP card implementation (on a java card). In-Reply-To: <87a9i9lfka.fsf@vigenere.g10code.de> References: <87a9i9lfka.fsf@vigenere.g10code.de> Message-ID: On Wed, Oct 16, 2013 at 11:40 AM, Werner Koch wrote: > On Tue, 15 Oct 2013 11:41, pete at heypete.com said: > >> Also, are there any smartcards out there that would support DSA/ELG >> keys? All the cards I've seen and used support RSA only. > > You don't want DSA on smartcards - at least not until they are able to > do deterministic DSA (rfc-6979). I knew that DSA fails catastrophically with low entropy (where "catastrophically" = "leaking the private key"), but I would hope that any DSA-capable smartcard would have a decent hardware RNG built in. I'm not familiar with RFC 6979. Thanks for the link. It's good to see people taking that issue into account. Cheers! -Pete From fabio.coatti at gmail.com Wed Oct 16 11:59:37 2013 From: fabio.coatti at gmail.com (Fabio Coatti) Date: Wed, 16 Oct 2013 11:59:37 +0200 Subject: Issues when switching between smartcards In-Reply-To: <20131015201648.GE20130@beastie.smellysneakers.net> References: <3423473.umbEOA4I1j@calvin> <20131015201648.GE20130@beastie.smellysneakers.net> Message-ID: <1599383.XH4ddPYJpO@calvin> In data marted? 15 ottobre 2013 16:16:48, Kevin ha scritto: > Personally, I have found that "killall gpg-agent" works for me in these > cases, without much fuss. However, since you have a different reader, > and most probably different OS, etc, YMMV. After some mail exchange with Ludovic Rousseau (many thanks for his help and patience) , I solved the issues upgrading ccid to 1.4.13, but mainly looking at the bios setup where I found that the laptop was configured to power on and off the reader according to the fact that the card was inserted or not. It seems that this confuses smart card driver (basically, when powered off the reader is not even visible in lsusb). I don't konw if this is an issue that can be dealt with changin something in driver code (probably it should handle this behaviour more nicely), but telling bios to always keep reader powered solved my issue (basically now I'm relying on linux usb power management to avoid waste when card is not inserted) -- Fabio From brian at interlinx.bc.ca Wed Oct 16 14:04:39 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 16 Oct 2013 08:04:39 -0400 Subject: trust your corporation for keyowner identification? Message-ID: If you worked in a corporate environment, would you trust the HR department there to have verified the identity of employees well enough to leverage that into signing a GPG key? Let's say such an environment had an messaging system where employees had to authenticate with their corporate IT credentials in order to use the system. Would that, and the assertion by HR/IT that a message that I get from Bob really did come from the employee HR verified as Bob (i.e. when they hired him) be enough for you trust the key you get from Bob enough to sign it that it really is really Bob's? I guess what I am describing is a virtual key signing party where the verification of IDs is being done by the corporation instead of the individuals. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From pete at heypete.com Wed Oct 16 15:28:47 2013 From: pete at heypete.com (Pete Stephenson) Date: Wed, 16 Oct 2013 15:28:47 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: References: Message-ID: On Wed, Oct 16, 2013 at 2:04 PM, Brian J. Murrell wrote: > If you worked in a corporate environment, would you trust the HR > department there to have verified the identity of employees well enough > to leverage that into signing a GPG key? In general, I'd be fine with that. Corporations generally need a fairly large amount of information about their employees (e.g. for tax purposes) and so should be able to verify the identity of employees with a high degree of confidence. > Let's say such an environment had an messaging system where employees > had to authenticate with their corporate IT credentials in order to use > the system. Would that, and the assertion by HR/IT that a message that > I get from Bob really did come from the employee HR verified as Bob > (i.e. when they hired him) be enough for you trust the key you get from > Bob enough to sign it that it really is really Bob's? > > I guess what I am describing is a virtual key signing party where the > verification of IDs is being done by the corporation instead of the > individuals. In my specific case, I only publicly sign (as opposed to locally sign) keys when I have (a) personally met a person and verified their ID and key fingerprint/details or (b) a person is well-known to me (e.g. a family member, long time friend, etc.) and they provide me their key fingerprint and communicate in a way that I can verify who they are (e.g. I call them on the phone, recognize their voice, and they read me their key fingerprint). I would be reasonably sure that a key signed by an HR department actually belongs to the named person, but I wouldn't publicly assert that by signing their key. Your mileage may vary. :) Cheers! -Pete From mwood at IUPUI.Edu Wed Oct 16 15:37:37 2013 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 16 Oct 2013 09:37:37 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: References: Message-ID: <20131016133737.GB9869@IUPUI.Edu> On Wed, Oct 16, 2013 at 08:04:39AM -0400, Brian J. Murrell wrote: > If you worked in a corporate environment, would you trust the HR > department there to have verified the identity of employees well enough > to leverage that into signing a GPG key? Not without investigating their procedures. > Let's say such an environment had an messaging system where employees > had to authenticate with their corporate IT credentials in order to use > the system. Would that, and the assertion by HR/IT that a message that > I get from Bob really did come from the employee HR verified as Bob > (i.e. when they hired him) be enough for you trust the key you get from > Bob enough to sign it that it really is really Bob's? > > I guess what I am describing is a virtual key signing party where the > verification of IDs is being done by the corporation instead of the > individuals. Then let the corporation (i.e. HR) do the signing and you decide whether to trust HR's signatures. Really this should be designed into the corporation rather than pasted on. The chief security officer should somehow determine what would be satisfactory procedures for verifying identity for the purpose of issuing such signatures and get it accepted as a requirement for HR. Probably this will be designed in consultation with HR so that it will actually be implemented properly and not be a constant source of pushback. The meaning of such signatures should be documented and published internally, so that relying parties know what they are getting and can decide for what and how far they are willing to rely on them. Part of the determination should be the purpose and scope of such signatures. One factor in the steady drizzle of corporate security failures is the notion that one can buy a box of security off the shelf and thereafter be secure, without thinking about what one is doing. It seems to me that designing secure processes for your specific needs should work better and be cheaper in the end. -- 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 dshaw at jabberwocky.com Wed Oct 16 15:51:59 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 16 Oct 2013 09:51:59 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: References: Message-ID: On Oct 16, 2013, at 8:04 AM, "Brian J. Murrell" wrote: > If you worked in a corporate environment, would you trust the HR > department there to have verified the identity of employees well enough > to leverage that into signing a GPG key? > > Let's say such an environment had an messaging system where employees > had to authenticate with their corporate IT credentials in order to use > the system. Would that, and the assertion by HR/IT that a message that > I get from Bob really did come from the employee HR verified as Bob > (i.e. when they hired him) be enough for you trust the key you get from > Bob enough to sign it that it really is really Bob's? > > I guess what I am describing is a virtual key signing party where the > verification of IDs is being done by the corporation instead of the > individuals. It's an interesting question, but it would not be enough for me. If you think about it, this is effectively the same as Alice signing Baker's key, and then Charlie signing Baker's key because Charlie knows Alice (and not necessarily Baker). If I were Charlie, I would not be willing to sign Baker's key, even if I knew and trusted Alice, without verifying Baker myself. A somewhat related case would be when the corporation itself has a corporate signing key and on HR/IT approval, signs employee keys. (This sort of thing is one of the classic uses for trust signatures). In that case, you can either trust the corporate signing key or not, as you like. David From johanw at vulcan.xs4all.nl Wed Oct 16 16:20:00 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 16 Oct 2013 16:20:00 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: References: Message-ID: <525EA090.7030005@vulcan.xs4all.nl> On 16-10-2013 15:28, Pete Stephenson wrote: > I would be reasonably sure that a key signed by an HR department > actually belongs to the named person, Although I would certainly NOT assume that that person would be the only one with access to the secret key. Most companies would keep a copy. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From pete at heypete.com Wed Oct 16 16:36:33 2013 From: pete at heypete.com (Pete Stephenson) Date: Wed, 16 Oct 2013 16:36:33 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <525EA090.7030005@vulcan.xs4all.nl> References: <525EA090.7030005@vulcan.xs4all.nl> Message-ID: On Wed, Oct 16, 2013 at 4:20 PM, Johan Wevers wrote: > On 16-10-2013 15:28, Pete Stephenson wrote: > >> I would be reasonably sure that a key signed by an HR department >> actually belongs to the named person, > > Although I would certainly NOT assume that that person would be the only > one with access to the secret key. Most companies would keep a copy. Good point. That would definitely throw a wrench in the system. Cheers! -Pete From rjh at sixdemonbag.org Wed Oct 16 20:10:51 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 16 Oct 2013 11:10:51 -0700 Subject: trust your corporation for keyowner identification? In-Reply-To: References: Message-ID: <20131016111051.Horde.12nBdR_p7rsHul5Ih2syxw5@mail.sixdemonbag.org> > If you worked in a corporate environment, would you trust the HR > department there to have verified the identity of employees well enough > to leverage that into signing a GPG key? This is the wrong question, really. HR is pretty good about verifying identity documents. HR gets specialized training in what proper identity documents look like and HR typically has ways to check those documents with the government. Even small firms do a lot of identity verification -- in the United States you can't legally work without presenting your employer with a passport (or, alternately, a driver's license and Social Security card). Not even a McDonald's or a 7-11 will let you work there without providing them with those documents. But HR is probably really bad about understanding the nuances of the Web of Trust, what it means to make a certification, whether a certification should be made at all, what level of certification should be made, and so forth. The limiting factor here is technological skill, not document verification. That said, I've worked for two companies that did this and did it quite competently. I haven't kept up with PGP since they got bought out by Symantec, but I know that from at least '95 to '05 they would issue corporate signatures to employee certificates, if the employee requested it. They did this so that other users could be confident in who was really an employee of PGP Security and who wasn't. From dougb at dougbarton.us Wed Oct 16 21:51:15 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 16 Oct 2013 12:51:15 -0700 Subject: trust your corporation for keyowner identification? In-Reply-To: References: Message-ID: <525EEE33.1060304@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/16/2013 05:04 AM, Brian J. Murrell wrote: | If you worked in a corporate environment, would you trust the HR | department there to have verified the identity of employees well | enough to leverage that into signing a GPG key? | | Let's say such an environment had an messaging system where | employees had to authenticate with their corporate IT credentials | in order to use the system. Would that, and the assertion by HR/IT | that a message that I get from Bob really did come from the | employee HR verified as Bob (i.e. when they hired him) be enough | for you trust the key you get from Bob enough to sign it that it | really is really Bob's? What would the purpose of such a signature be? Would you be distributing your signature, or would it be local to your key ring? If you're distributing the signature, would you distribute it only within the company, or outside too? Are you talking about signing with your personal key, or signing with your company key? If the latter, does that key ever see the light of day outside the company? Just to be clear, I'm not being snarky here. As others have said you have asked an interesting question, but there are not enough details (for me at least) to give you an answer. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSXu4zAAoJEFzGhvEaGryEzs0IALynXU0C9+oH9brK4LBwbKWJ FHGnQC7HPnPUYS/S7kbMWV4DID9L8x4xV9KJxDoPZ9MaFFLY3d5OGhDpj5IoHJ8T ehLXbqsHto6sKiZ0un3uWAYowS8TyIhk3UwR5tyzJIJRhP6kvfJpvKRmtjfHaymV 1K6xgVnXv9PfoCVsFQiN7Q/L30fnzWoIdIJbAJ+M5kbKvXdqWRFgTUBLLrdyqJUA wA022xB+RA9glk1Kb8gDAZohMBcPz9oLEdDs0z/hnSOU4T5BBQi+O5Xu/4/uAjjw 8qtNWUuITOJtvkYxp2we209Dt/H2YzYnZttRZnjo/vmInQiWFDO6dBc+yo3rjYc= =Hgba -----END PGP SIGNATURE----- From brian at interlinx.bc.ca Wed Oct 16 22:19:19 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 16 Oct 2013 16:19:19 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> Message-ID: On 13-10-16 03:51 PM, Doug Barton wrote: > On 10/16/2013 05:04 AM, Brian J. Murrell wrote: > | If you worked in a corporate environment, would you trust the HR > | department there to have verified the identity of employees well > | enough to leverage that into signing a GPG key? > | > | Let's say such an environment had an messaging system where > | employees had to authenticate with their corporate IT credentials > | in order to use the system. Would that, and the assertion by HR/IT > | that a message that I get from Bob really did come from the > | employee HR verified as Bob (i.e. when they hired him) be enough > | for you trust the key you get from Bob enough to sign it that it > | really is really Bob's? So yeah. The parameters were a big vague, in retrospect. So to set some... The corporation itself does not use GPG and thus is not signing any GPG keys for their employees. I'd be surprised if many corporations were using GPG in preference to SSL (i.e. S/MIME). To be honest, I'd imagine "certificates" and "SSL PKI", etc., all bundled up into shrink-wrapped software that runs on Windows servers, bought from companies that can be sued, etc. just seems so much more "corporate"-friendly than GPG. So that said, the corporate infrastructure (i.e. being satisfied enough that Bob is Bob to hire him and put him on payroll and deduct and remit income taxes to the government and provide benefits and insurance to, etc.) would be nothing more than a proxy for meeting an individual and seeing their "government issued" ID in order to be happy enough that Bob is Bob for you to sign his key saying as much -- assuming you have a secure channel to verify that the key you are signing is Bob's. So to answer previous questions/suggestions, there is no corporate GPG key to sign Bob's key for other GPG users (employees or otherwise) to put trust into. The corporation would not have a copy of the private key since the corporation is completely uninvolved other than (unknowingly) being the identity-checker and providing the means to authoritatively communicate with Bob (i.e. when I "message" bob at corporate.domain I know it's Bob that I am talking to -- somebody in IT doing a MITM attack aside -- but maybe that's enough of a risk to make this infeasible). You would have the same trust that only Bob has Bob's secret key as you would any other GPG user whose key you signed. Any given GPG user's competency in using GPG (i.e. keeping secret keys secret, trusting other, etc.) is up to you, as it always is. The misunderstanding that the corporation is somehow involved with keys and signing I think was the biggest misunderstanding. They are not. They provide nothing more than asserting that Bob is Bob and providing a means of ensuring that I am communicating with Bob when I think I am communicating with Bob -- again, IT launching a MITM attack aside). Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From expires2013 at ymail.com Wed Oct 16 23:28:07 2013 From: expires2013 at ymail.com (MFPA) Date: Wed, 16 Oct 2013 22:28:07 +0100 Subject: trust your corporation for keyowner identification? In-Reply-To: References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> Message-ID: <109563160.20131016222807@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 16 October 2013 at 9:19:19 PM, in , Brian J. Murrell wrote: > The corporation would not have a copy of the private > key since the corporation is completely uninvolved > other than (unknowingly) being the identity-checker and > providing the means to authoritatively communicate with > Bob (i.e. when I "message" bob at corporate.domain I know > it's Bob that I am talking to -- somebody in IT doing a > MITM attack aside -- but maybe that's enough of a risk > to make this infeasible). You would have the same > trust that only Bob has Bob's secret key as you would > any other GPG user whose key you signed. Any given GPG > user's competency in using GPG (i.e. keeping secret > keys secret, trusting other, etc.) is up to you, as it > always is. If the key was generated, stored, or used on the company's computer, all bets are off regarding Bob being the only one with access to a copy. - -- Best regards MFPA mailto:expires2013 at ymail.com A wise man once said ..."I don't know." -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlJfBPtXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pZqwD/RsaAhIQ++BVj0kdmctZOhSaN9fooa9zUM2R 6ZPj0mdIzD8yLriWXBf+LjJJH0DQTDdjQFsh7XTE/4E3K8bGybRyciOzD4WcVHNn Y4kV/kYFX+uo/bjPsTX4h4XxkyfXeKmFti5ou1yxYPVsnNk6vFz1qHqh4EibwDI2 S0ratbwE =loQ1 -----END PGP SIGNATURE----- From luissuzuki at live.com Thu Oct 17 03:48:46 2013 From: luissuzuki at live.com (Luis Suzuki) Date: Thu, 17 Oct 2013 02:48:46 +0100 Subject: GnuPG 1.4.15 RAM EATER? Or just a bug? Message-ID: I noticed that this 1.4.15 version consumes much more RAM than previous versions.My Linux desktop background wallpaper turns blank(dark) when encrypting/decrypting operations (which is a novelty,and that is why I detected this "problem") and when I execute the free command to analyse RAM the used RAM reaches the maximum level of my system(from a relatively low level).Is it a bug? Does it have any implications to the encryption effectiveness? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at epy.co.at Thu Oct 17 08:07:27 2013 From: stefan at epy.co.at (Stefan H. Holek) Date: Thu, 17 Oct 2013 08:07:27 +0200 Subject: my gpg key does not conform to rfc4880? In-Reply-To: <5256FC23.5070004@interlinx.bc.ca> References: <5256EBBF.7050505@fifthhorseman.net> <5256FC23.5070004@interlinx.bc.ca> Message-ID: <8DD5DFFC-4A03-496B-9684-C92D0DD42BE4@epy.co.at> Make sure to sign the new key with your old key to introduce it to your web of trust. Stefan On 10.10.2013, at 21:12, Brian J. Murrell wrote: > Yeah. I have considered both of those things also. I guess the only > thing that was holding me back was that the existing key has an > investment in signatures on it though. What I am unclear about is how > the authenticity and trustibility of my new key will be regarded in > relation to the existing key with all of the signatures on it. -- Stefan H. Holek stefan at epy.co.at From bernhard at intevation.de Thu Oct 17 10:41:36 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 17 Oct 2013 10:41:36 +0200 Subject: GnuPG 1.4.15 RAM EATER? Or just a bug? In-Reply-To: References: Message-ID: <201310171041.42300.bernhard@intevation.de> Luis, On Thursday 17 October 2013 at 03:48:46, Luis Suzuki wrote: > I noticed that this 1.4.15 version consumes much more RAM than previous > versions.My Linux desktop background wallpaper turns blank(dark) when > encrypting/decrypting operations (which is a novelty,and that is why I > detected this "problem") and when I execute the free command to analyse RAM > the used RAM reaches the maximum level of my system(from a relatively low > level).Is it a bug? Does it have any implications to the encryption > effectiveness? thanks for reporting your issue! The changes from 1.4.14 to 1.4.15 should probably not affect memory usage. So you would also look into other potential causes like different build circumstances (different compiler, library versions, parameters, machine target). So in order to get a good hint about your specific issue you should give more infos about the two builds you are using. (Just out of curiosity: is there a specific reason why you are not using Gnupg 2.0 which is the generally recommended version?) Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From brian at interlinx.bc.ca Thu Oct 17 12:37:35 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 17 Oct 2013 06:37:35 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> Message-ID: On 13-10-16 05:28 PM, MFPA wrote: > > If the key was generated, stored, or used on the company's computer, > all bets are off regarding Bob being the only one with access to a > copy. Why would it be? There is no reason, with this verification scheme that anyone's private keys (or public keys for that matter) go anywhere near the company's computer. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Thu Oct 17 15:07:54 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 17 Oct 2013 15:07:54 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> Message-ID: <525FE12A.5040307@vulcan.xs4all.nl> On 17-10-2013 12:37, Brian J. Murrell wrote: >> If the key was generated, stored, or used on the company's computer, >> all bets are off regarding Bob being the only one with access to a >> copy. > Why would it be? There is no reason, with this verification scheme that > anyone's private keys (or public keys for that matter) go anywhere near > the company's computer. Yes there is: the practical point of using those keys. Why would a HR department sign employees keys? I assume to have the employee use it in encrypted communications with collegues / customers / whoever. To do that, the key needs to be on a company computer in most cases. There are exceptions of cource (like working at home on your own hardware) but they are not the norm so I wouldn't blindly assume that to be the case. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From christian.weinz at gmail.com Thu Oct 17 17:55:29 2013 From: christian.weinz at gmail.com (Christian Weinz) Date: Thu, 17 Oct 2013 17:55:29 +0200 Subject: Smart card reader security Message-ID: <1382025329.2267.15.camel@mars.weinz> Hello, I bought a cyberJack go [1] to use it with my openPGP smart card for authentification. Since the firmware of that device is upgradeable and is capable of saving atleast 2 GB of data, how can I be sure it is not a security threat by saving sensitive data? Best regards, Christian Weinz [1] http://www.scm-pc-card.de/index.php?page=product&function=show_product&lang=en&category_id=46&p=cyberJack%20go&c=SmartCard%20%20%28SCR%29&product_id=825 From rjh at sixdemonbag.org Thu Oct 17 21:26:46 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 17 Oct 2013 12:26:46 -0700 Subject: Differences in --list-packets between 1.4 and 2.0 Message-ID: <20131017122646.Horde.6xqpVeWyijVzjY82ueflJA1@mail.sixdemonbag.org> Under GnuPG 2.0, calling --list-packets on a GnuPG keyring file will list key IDs as part of the public key packets. Under GnuPG 1.4, the key ID information is suppressed. Is there any way to make GnuPG 1.4 behave like 2.0 in this regard? From brian at interlinx.bc.ca Thu Oct 17 21:42:37 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 17 Oct 2013 15:42:37 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> Message-ID: On 13-10-17 09:07 AM, Johan Wevers wrote: > > Yes there is: the practical point of using those keys. Why would a HR > department sign employees keys? Look at my update to this thread yesterday. I already said in that message that the HR department is NOT signing keys and that the corporation in fact is not even involved with GPG in any way whatsoever. > I assume to have the employee use it in > encrypted communications with collegues / customers / whoever. No. This has nothing to do with corporate key use. This is merely a way for individuals, as individuals to enhance the certification of their keys by having a "virtual keysigning party" within their company. This is no different than going to your LUG and having a keysigning party there. The LUG itself does not participate in any way (i.e. signing keys, etc.) other than to provide a venue for the people to meet. In my proposed scenario, the corporation 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. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Oct 17 22:54:54 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 17 Oct 2013 13:54:54 -0700 Subject: trust your corporation for keyowner identification? In-Reply-To: References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> Message-ID: <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> > In my proposed scenario, the corporation 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? From harningt at gmail.com Fri Oct 18 01:56:27 2013 From: harningt at gmail.com (Thomas Harning Jr.) Date: Thu, 17 Oct 2013 19:56:27 -0400 Subject: Smart card reader security In-Reply-To: <1382025329.2267.15.camel@mars.weinz> References: <1382025329.2267.15.camel@mars.weinz> Message-ID: Wow, that's a lot of firmware space for something that looks so simple. Hopefully they open-source the firmware (though I suppose they should shove unsightly decryption key absconding code in the firmware that runs the firmware). One could also be concerned about regular readers... there's alot of space they "could" be putting storage space for decryption keys so that if the device is "lost" or "shipped for manufacturer servicing" they can pull them off. In short, it's really hard to be sure that anything is safe. You have to start somewhere. On Thu, Oct 17, 2013 at 11:55 AM, Christian Weinz wrote: > Hello, > > I bought a cyberJack go [1] to use it with my openPGP smart card for > authentification. Since the firmware of that device is upgradeable and > is capable of saving atleast 2 GB of data, how can I be sure it is not a > security threat by saving sensitive data? > > Best regards, > Christian Weinz > > [1] > http://www.scm-pc-card.de/index.php?page=product&function=show_product&lang=en&category_id=46&p=cyberJack%20go&c=SmartCard%20%20%28SCR%29&product_id=825 > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Thomas Harning Jr. (http://about.me/harningt) From harningt at gmail.com Fri Oct 18 02:00:59 2013 From: harningt at gmail.com (Thomas Harning Jr.) Date: Thu, 17 Oct 2013 20:00:59 -0400 Subject: Smart card reader security In-Reply-To: <1382025329.2267.15.camel@mars.weinz> References: <1382025329.2267.15.camel@mars.weinz> Message-ID: Wow, that's a lot of firmware space for something that looks so simple. Hopefully they open-source the firmware (though I suppose they should shove unsightly decryption key absconding code in the firmware that runs the firmware). One could also be concerned about regular readers... there's alot of space they "could" be putting storage space for decryption keys so that if the device is "lost" or "shipped for manufacturer servicing" they can pull them off. In short, it's really hard to be sure that anything is safe. You have to start somewhere. On Thu, Oct 17, 2013 at 11:55 AM, Christian Weinz wrote: > Hello, > > I bought a cyberJack go [1] to use it with my openPGP smart card for > authentification. Since the firmware of that device is upgradeable and > is capable of saving atleast 2 GB of data, how can I be sure it is not a > security threat by saving sensitive data? > > Best regards, > Christian Weinz > > [1] > http://www.scm-pc-card.de/index.php?page=product&function=show_product&lang=en&category_id=46&p=cyberJack%20go&c=SmartCard%20%20%28SCR%29&product_id=825 > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -- Thomas Harning Jr. (http://about.me/harningt) From werewolf6851 at gmail.com Fri Oct 18 08:41:17 2013 From: werewolf6851 at gmail.com (Werewolf) Date: Fri, 18 Oct 2013 01:41:17 -0500 Subject: trust your corporation for keyowner identification? In-Reply-To: <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> Message-ID: <20131018064117.GA9954@Vixen> On Thu, Oct 17, 2013 at 01:54:54PM -0700, Robert J. Hansen wrote: > >In my proposed scenario, the corporation 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? Now what if the Company/HR department had a Notary public, for their documents, and this same Notary had a gpg key he/she treated same his/her stamp equipment, and used the same standards before signing a gpgkey? Wolf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From wk at gnupg.org Fri Oct 18 10:13:03 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Oct 2013 10:13:03 +0200 Subject: Smart card reader security In-Reply-To: <1382025329.2267.15.camel@mars.weinz> (Christian Weinz's message of "Thu, 17 Oct 2013 17:55:29 +0200") References: <1382025329.2267.15.camel@mars.weinz> Message-ID: <877gdbgfow.fsf@vigenere.g10code.de> On Thu, 17 Oct 2013 17:55, christian.weinz at gmail.com said: > I bought a cyberJack go [1] to use it with my openPGP smart card for > authentification. Since the firmware of that device is upgradeable and > is capable of saving atleast 2 GB of data, how can I be sure it is not a This is not just a reader but an identification token with lots of embedded and upgradable software. It has already been shown that such smart cards readers are fun to play with. IIRC, there have been demonstrations turning the doctors health card terminals and PIN+chip terminals into space invaders consoles. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Oct 18 10:21:11 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Oct 2013 10:21:11 +0200 Subject: Differences in --list-packets between 1.4 and 2.0 In-Reply-To: <20131017122646.Horde.6xqpVeWyijVzjY82ueflJA1@mail.sixdemonbag.org> (Robert J. Hansen's message of "Thu, 17 Oct 2013 12:26:46 -0700") References: <20131017122646.Horde.6xqpVeWyijVzjY82ueflJA1@mail.sixdemonbag.org> Message-ID: <87zjq7f0p8.fsf@vigenere.g10code.de> On Thu, 17 Oct 2013 21:26, rjh at sixdemonbag.org said: > Is there any way to make GnuPG 1.4 behave like 2.0 in this regard? Yes. See commit 0bdf121 which will be included into 1.4.16. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Fri Oct 18 11:37:00 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 18 Oct 2013 11:37:00 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <20131018064117.GA9954@Vixen> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <20131018064117.GA9954@Vixen> Message-ID: <5261013C.1010301@digitalbrains.com> On 18/10/13 08:41, Werewolf wrote: > Now what if the Company/HR department had a Notary public, for their > documents, and this same Notary had a gpg key he/she treated same his/her > stamp equipment, and used the same standards before signing a gpgkey? Then you could simply sign the notary's key and assign it full ownertrust. No need to sign keys you verified by checking the notary's signature. In fact, if I found out someone was uploading signatures to the keyserver for which they did no more verification than checking the signatures made by people they trust, I would immediately assign that person "I do NOT trust" in my trust database. They are poisoning my Web of Trust! If I trust the notary as well, I can also assign that person ownertrust and get valid keys through his or her signatures. But if other people are signing keys purely based on the notary's signature, they are meddling with my parameters "marginals needed", "completes needed" and "max cert depth". Suppose I have "marginals needed" set to 3. And 3 people I assigned marginal trust did no more than verify the signature by the notary before signing some key themselves. All the verification that has been done on the identity of the person holding that key is done by a single person, the notary. But I see 3 people who supposedly have verified the identity. Also, if the signature path to the notary is longer than the signature path to these 3 people, they have just artificially altered my "max cert depth" by shortcutting the route that would otherwise have gone through the notary, who actually did the verification. The moral: I think it is a really bad idea to sign keys because you trust already made signatures. That's what your trust database is for, use that. You should sign keys because you verified the identity *outside* the Web of Trust. All this only applies to exportable signatures. If you wish to make a local signature on some key to make it valid, go right ahead. You're not meddling with my Web of Trust that way. You might inadvertently meddle with your own, 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 peter at digitalbrains.com Fri Oct 18 11:59:15 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 18 Oct 2013 11:59:15 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <5261013C.1010301@digitalbrains.com> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <20131018064117.GA9954@Vixen> <5261013C.1010301@digitalbrains.com> Message-ID: <52610673.5080903@digitalbrains.com> On 18/10/13 11:37, Peter Lebbing wrote: > The moral: I think it is a really bad idea to sign keys because you trust > already made signatures. That's what your trust database is for, use that. You > should sign keys because you verified the identity *outside* the Web of Trust. However, here an interesting dichotomy surfaces: the scenario the OP painted was that the HR person or notary did not use OpenPGP or key signatures, but that you still rely on the identity verification done by the HR person. This would thus constitute identity verification outside the Web of Trust, and I suppose I would find that acceptable. Although I'm a bit unclear on how this "virtual keysigning party" would in practice be held: how does the notary state he trusts the identity? Where does the fingerprint of the key come in to play? You are asserting that a certain person holds a certain key, the key has to be part of the verification. But the notary wasn't using OpenPGP. The dichotomy is thus: if the notary does not sign keys, I would be okay with people signing keys based on the notary's verification efforts. But if that same notary did everything he or she did before *and* did something extra, namely signing keys, suddenly I'm not okay with people signing keys based on the notary's verification efforts. That's odd. But the dichotomy doesn't change my position on this. Perhaps a clear answer to how the key fingerprint comes into play would take away the oddity, because perhaps then suddenly there /is/ a verification effort by the people signing the key: that the key belongs to the owner. That the owner is who they say they are, is then left to the notary. 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 rjh at sixdemonbag.org Fri Oct 18 14:54:03 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 18 Oct 2013 08:54:03 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: <20131018064117.GA9954@Vixen> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <20131018064117.GA9954@Vixen> Message-ID: <52612F6B.5020608@sixdemonbag.org> On 10/18/2013 2:41 AM, Werewolf wrote: > Now what if the Company/HR department had a Notary public, for their > documents, and this same Notary had a gpg key he/she treated same > his/her stamp equipment, and used the same standards before signing a > gpgkey? Forgive a nonanswer here, but this isn't a question. You're positing a particular set of facts to be in existence. Okay, fine, let's assume those facts. What's the question? From brian at interlinx.bc.ca Fri Oct 18 22:26:43 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Fri, 18 Oct 2013 16:26:43 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: <52610673.5080903__709.693498402153$1382090442$gmane$org@digitalbrains.com> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <20131018064117.GA9954@Vixen> <5261013C.1010301@digitalbrains.com> <52610673.5080903__709.693498402153$1382090442$gmane$org@digitalbrains.com> Message-ID: On 13-10-18 05:59 AM, Peter Lebbing wrote: > > However, here an interesting dichotomy surfaces: the scenario the OP painted was > that the HR person or notary did not use OpenPGP or key signatures, but that you > still rely on the identity verification done by the HR person. That's correct. > This would thus > constitute identity verification outside the Web of Trust, Indeed! I completely agree with your prior opposition to people signing keys just because somebody they trust signed one and how trust relationships work to avoid the need to do that. > and I suppose I would > find that acceptable. I'm still not convinced, but that is why I brought it up for discussion. :-) > Although I'm a bit unclear on how this "virtual keysigning > party" would in practice be held: how does the notary state he trusts the > identity? Where does the fingerprint of the key come in to play? You are > asserting that a certain person holds a certain key, the key has to be part of > the verification. But the notary wasn't using OpenPGP. Right. They key signing party relies on a means of communication that can be considered authenticated. It could be e-mail (closed corporate e-mail system, not an "across the Internet e-mail) or it could be "credentials required" (again, closed, corproate) instant messaging for example. So that is, account compromise aside, you know that when Bob sends you an e-mail or an instant message, it did come from Bob because only Bob knows the credentials to be able to send messages in the messaging system from his account. Indeed, corporate messaging account compromise, or IT black-hats are a risk here. I guess it would be up to the individuals to assess the risk of such a thing just like one has to asses the risk that the ID that one is verifying at a traditional key-signing party is fraudulent or not. > The dichotomy is thus: if the notary does not sign keys, I would be okay with > people signing keys based on the notary's verification efforts. But if that same > notary did everything he or she did before *and* did something extra, namely > signing keys, suddenly I'm not okay with people signing keys based on the > notary's verification efforts. That's odd. It is odd. But I understand it. > But the dichotomy doesn't change my position on this. Perhaps a clear answer to > how the key fingerprint comes into play would take away the oddity, because > perhaps then suddenly there /is/ a verification effort by the people signing the > key: that the key belongs to the owner. That the owner is who they say they are, > is then left to the notary. Interesting perspectives, indeed. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sat Oct 19 13:17:02 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 19 Oct 2013 13:17:02 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <20131018064117.GA9954@Vixen> <5261013C.1010301@digitalbrains.com> <52610673.5080903__709.693498402153$1382090442$gmane$org@digitalbrains.com> Message-ID: <52626A2E.4030207@digitalbrains.com> On 18/10/13 22:26, Brian J. Murrell wrote: > Right. They key signing party relies on a means of communication that > can be considered authenticated. It could be e-mail (closed corporate > e-mail system, not an "across the Internet e-mail) or it could be > "credentials required" (again, closed, corproate) instant messaging for > example. I don't think I myself would consider that enough verification to sign a key. Too many other communication components involved. I was more thinking along the line of a Zimmerman-Sassaman protocol key signing party where the HR person is present and every line on the list is done as follows: Person on list: "Yes, entry 42 is indeed the fingerprint of my key" HR person: "Yes, this person is indeed the person listed at entry 42" This would be a considerable speedup for the ID verification stage, still presuming that you trust HR to properly verify someone's identity. I don't think this would still be a "virtual" keysigning party, 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 vivarto at gmail.com Mon Oct 21 06:28:34 2013 From: vivarto at gmail.com (Veet Vivarto) Date: Sun, 20 Oct 2013 18:28:34 -1000 Subject: How to add only specified public key from an asc file containing many keys? Message-ID: Hi, Please consider this situation. The user has a file containing some 30 public keys. He/she lists the keys and only wants to import only 2 of these keys. How can he/she do that? Is there a command that allows to specify the keys to import? Also, would the same method work with adding keys from a public keyring file? Thank you in advance for you assistance. Vivarto -------------- next part -------------- An HTML attachment was scrubbed... URL: From mirimir at riseup.net Tue Oct 22 11:57:02 2013 From: mirimir at riseup.net (Mirimir) Date: Tue, 22 Oct 2013 03:57:02 -0600 Subject: How to add only specified public key from an asc file containing many keys? In-Reply-To: References: Message-ID: <52664BEE.7070108@riseup.net> On 10/20/2013 10:28 PM, Veet Vivarto wrote: > Hi, > > Please consider this situation. The user has a file containing some > 30 public keys. He/she lists the keys and only wants to import only 2 > of these keys. How can he/she do that? > > Is there a command that allows to specify the keys to import? Also, > would the same method work with adding keys from a public keyring > file? > > Thank you in advance for you assistance. Vivarto If the keys are ASCII armored, I'd just copy the file, and delete the unwanted 28. From sttob at privatdemail.net Tue Oct 22 17:01:28 2013 From: sttob at privatdemail.net (Stan Tobias) Date: Tue, 22 Oct 2013 17:01:28 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> Message-ID: <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> "Robert J. Hansen" wrote: > > In my proposed scenario, the corporation 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? I somewhat disagree. I think we deal with two separate problems here: 1. identification of a person, and 2. certification of the key. The latter is about the person claiming use of the key, i.e. you vouch that the person told you "This is my key". Making a certification is *not* a confirmation of an identity. At key-signing parties you "identify" a person by looking into his documents. But this is not a real identification - almost none of us has means to confirm an identity, which is a job for a detective. By looking into someone's documents we only check the person has a title to use a particular name (i.e. is known by this name to others). (The person remains as anonymous as he was before showing his ID.) So my conclusion with regard to the OP's question is that an identification performed by a corporation is good enough to believe that X is X. However, a certification signature by a corporation on X's key (which by itself does not state anything about X's identity) is not enough to know X claims that key - you have to hear it from X himself (in order to leave your certificate). Stan T. P.S.1 I've presented my position as a set of assertions, but I don't mean to stand entirely by their correctness; I humbly await comments. P.S.2 Sorry to be a late-comer to the discussion - initially I had some difficulty to formulate the problem; this is my second writing. From Nikola.Radovanovic at seavus.com Tue Oct 22 14:06:16 2013 From: Nikola.Radovanovic at seavus.com (Nikola Radovanovic) Date: Tue, 22 Oct 2013 12:06:16 +0000 Subject: Building pinentry on Windows 7 Message-ID: Hello, I couldn't find any manual for building pinentry executables for Windows (specifically Windows 7/8). Also for Gpg4Win 2 in general. I know it should be cross-compiled, but there is not some up to date manual on internet, or I couldn't find it. Can you please give some detailed instructions on how to do it on Windows 7. Since I am not subsribed to this mailing list, please add me to CC. Best regards, Nikola Radovanovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From expires2013 at ymail.com Tue Oct 22 22:57:17 2013 From: expires2013 at ymail.com (MFPA) Date: Tue, 22 Oct 2013 21:57:17 +0100 Subject: trust your corporation for keyowner identification? In-Reply-To: References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> Message-ID: <1422635312.20131022215717@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 17 October 2013 at 11:37:35 AM, in , Brian J. Murrell wrote: > On 13-10-16 05:28 PM, MFPA wrote: >> If the key was generated, stored, or used on the >> company's computer, all bets are off regarding Bob >> being the only one with access to a copy. > Why would it be? There is no reason, with this > verification scheme that anyone's private keys (or > public keys for that matter) go anywhere near the > company's computer. > Cheers, b. When you said you would be messaging "bob at corporate.domain" I interpreted that in the context of a discussion about OpenPGP keys to mean you were exchanging encrypted communications with that email address. It appears you probably meant the communication with "bob at corporate.domain" was the out-of-band channel by which you and Bob told each other your OpenPGP key fingerprints, and that being able to send emails from those corporate accounts also doubled as identity verification (because only the individual knows the relevant credentials to send from "their" corporate email address, and the company is required to verify government-issued ID documents when engaging staff). The bit about the employer having to verify people's ID may lead me to accept a corporate ID card as an alternative to government-issued ID. As for use of a corporate email address, could I be sure that Bob locked his computer every time he left his desk? Or that nobody else would ever have access to a written record of Bob's passwords? Or that, in Bob's absence, a substitute would never use Bob's email address when covering his work? - -- Best regards MFPA mailto:expires2013 at ymail.com If at first you don't succeed, destroy all evidence that you tried. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlJm5sBXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pyTID/iiqs8VQquGq9VxkJK2hGhTgksU0GhK4kREm TAjhg1184ls4RNPjUkErlcvaGU3R2FOnIfYUufEz8hV71Qsi/QJ7oMH+/qKWsFZ+ kQVrvzr53UGEF2OOmF6khn6naYX3d1Ueke3Gaq4jUTjlJOhN2VcKTJl8Ayl1aoiJ PWmL07ma =hdmI -----END PGP SIGNATURE----- From johanw at vulcan.xs4all.nl Tue Oct 22 23:21:28 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 22 Oct 2013 23:21:28 +0200 Subject: Selecting your own key with Enigmail In-Reply-To: References: Message-ID: <5266EC58.10702@vulcan.xs4all.nl> Hello, I have 2 active keys (a v3 2048 bit RSA and a v3 3072 bit DSA), and when I send encrypted mail via Thunderbird 3.1.20 it uses always the RSA keyt for encrypt to self but I want to use the other. I can define rules which keys to use for other recipients but not for myself, at least not where I can find it. I have put the DSA key in gpg.conf in the default-key and encrypt-to sections but that doesn't seem to help. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wolters.mar at googlemail.com Tue Oct 22 23:37:39 2013 From: wolters.mar at googlemail.com (Martin Wolters) Date: Tue, 22 Oct 2013 23:37:39 +0200 Subject: gpg4win pinentry ignores PIN-pad Message-ID: <5266F023.5030202@gmail.com> Hi, I am using gpg4win 2.2.1, which according to the change log supports the SPR332 PIN-pad, but pinentry requests the PIN from the keyboard. Is there anything I need to configure to enforce the entry from the card reader? In GNU/Linux, pinentry only opens a window telling me to enter the PIN on the card reader and I don't even get the opportunity to enter it from my keyboard by mistake. This is the way I want it. Since I don't know where to start, I attached a log from scdaemon. If you need any additional information, I will be happy to provide it. Have a good time, Martin scdaemon[15820]: chan_00000138 -> OK GNU Privacy Guard's Smartcard server ready scdaemon[15820]: chan_00000138 <- GETINFO socket_name scdaemon[15820]: chan_00000138 -> D C:UsersasdfAppDataRoaminggnupgS.scdaemon scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- OPTION event-signal=f8 scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- SERIALNO openpgp 2013-10-22 19:53:07 scdaemon[15820] reader slot 0: active protocol: T1 2013-10-22 19:53:07 scdaemon[15820] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 A4 00 0C 02 3F 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=6B00 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 A4 04 00 06 D2 76 00 01 24 01 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 4F 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=16 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 2013-10-22 19:53:07 scdaemon[15820] AID: D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 5F 52 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=10 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2013-10-22 19:53:07 scdaemon[15820] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 C4 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=7 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 00 20 20 20 03 00 03 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 5E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 2013-10-22 19:53:07 scdaemon[15820] Version-2 ......: yes 2013-10-22 19:53:07 scdaemon[15820] Get-Challenge ..: yes (2048 bytes max) 2013-10-22 19:53:07 scdaemon[15820] Key-Import .....: yes 2013-10-22 19:53:07 scdaemon[15820] Change-Force-PW1: yes 2013-10-22 19:53:07 scdaemon[15820] Private-DOs ....: yes 2013-10-22 19:53:07 scdaemon[15820] Algo-Attr-Change: yes 2013-10-22 19:53:07 scdaemon[15820] SM-Support .....: no 2013-10-22 19:53:07 scdaemon[15820] Max-Cert3-Len ..: 2048 2013-10-22 19:53:07 scdaemon[15820] Max-Cmd-Data ...: 2048 2013-10-22 19:53:07 scdaemon[15820] Max-Rsp-Data ...: 2048 2013-10-22 19:53:07 scdaemon[15820] Cmd-Chaining ...: no 2013-10-22 19:53:07 scdaemon[15820] Ext-Lc-Le ......: yes 2013-10-22 19:53:07 scdaemon[15820] Status Indicator: 05 2013-10-22 19:53:07 scdaemon[15820] GnuPG-No-Sync ..: no 2013-10-22 19:53:07 scdaemon[15820] GnuPG-Def-PW2 ..: no 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:07 scdaemon[15820] Key-Attr-sign ..: RSA, n=4096, e=32, fmt=std 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:07 scdaemon[15820] Key-Attr-encr ..: RSA, n=4096, e=32, fmt=std 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:07 scdaemon[15820] Key-Attr-auth ..: RSA, n=4096, e=32, fmt=std 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 5E 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 2013-10-22 19:53:07 scdaemon[15820] DO `Login Data': 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=5F p2=50 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 5F 50 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 2013-10-22 19:53:07 scdaemon[15820] DO `URL': `' 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 5F 52 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=10 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2013-10-22 19:53:07 scdaemon[15820] DO `Historical Bytes': 00 31 C5 73 C0 01 40 05 90 00 2013-10-22 19:53:07 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=65 lc=-1 le=256 em=0 2013-10-22 19:53:07 scdaemon[15820] DBG: PCSC_data: 00 CA 00 65 00 2013-10-22 19:53:07 scdaemon[15820] DBG: response: sw=9000 datalen=26 2013-10-22 19:53:07 scdaemon[15820] DBG: dump: 5B 0F 57 6F 6C 74 65 72 73 3C 3C 4D 61 72 74 69 6E 5F 2D 02 64 65 5F 35 01 31 2013-10-22 19:53:07 scdaemon[15820] DO `Cardholder Related Data': 5B 0F 57 6F 6C 74 65 72 73 3C 3C 4D 61 72 74 69 6E 5F 2D 02 64 65 5F 35 01 31 2013-10-22 19:53:07 scdaemon[15820] DO `Name': `Wolters< S SERIALNO D2760001240102000005000004890000 0 scdaemon[15820]: chan_00000138 -> OK 2013-10-22 19:53:08 scdaemon[15820] updating slot 0 status: 0x0000->0x0007 (0->1) 2013-10-22 19:53:08 scdaemon[15820] triggering event f8 (000000F8) for client -1 scdaemon[15820]: chan_00000138 <- SERIALNO openpgp scdaemon[15820]: chan_00000138 -> S SERIALNO D2760001240102000005000004890000 0 scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- SETDATA 0D9E9F4BABF6EB5726CF901C6019C866912290C9162F6B9569A3BF354A01DB8850CA74E9FCE8541F799F5E4B744C69C7BE67347782BE5BA3F6FD83AF7FF9AF88BA2DC0E1A1C91BFF5D68A1C772FF955BC6359FEBE2C37EE9978111C39E78A9C24FCA4347D5208F64BF2BE5CCD71BF4BCDAA0057FA06D37405D238CF3C9BC085254D6ED534DC0407B3035C10F897F75E8096C3CD0E2FBDCF5D7106C9DEB5626C82B40689C3E6C17CE4EAE8F49BA479AE9F6103448DAD452BC8A6DA849E6FC172A522262DE3E9421112BCA60C924063E1994EA9B6D808C118CB423548F8430421163166052ED3ED4DBF5F104F94D9C6D3A486B6B30F114F745CFABAAFBAEB09D857E7136F038165D9FF829B297B626F791421119AD311B5B5E74F22066D80129BFE3BB4A07ECE75175FB63B073240FE0D3BA1043AD84599761DD9600D0E5ABA667E51DD32B83B908846B01C28A10B5CD9740D7514D83F657C3C954BFE7C2D53C832940E4490A6509E4C1592333872BC71ED6D2C6814DF6ED4E2C7A56C93DF159807D1829DA531DEE5AB35D6F536919584F099C6D32E16BCD9740F8E91C4612F60DE050A6A4BF95CEC9A0D277BACECE4511118ABD2059F15695A23B7124846A6831D49EC57FA3DFA907406F60B6BD37078E817E108069C88264A18C22AF scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- SETDATA --append B9EE67BE9D48AF9E285BB25C391C83E4E96251D9D41AB372D61498B75A907E6C0059250B scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- PKDECRYPT D2760001240102000005000004890000/79C0D2346E0409AB89B5ED108D1F92D24AE60BAF 2013-10-22 19:53:08 scdaemon[15820] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2013-10-22 19:53:08 scdaemon[15820] DBG: PCSC_data: 00 CA 00 6E 00 2013-10-22 19:53:08 scdaemon[15820] DBG: response: sw=9000 datalen=217 2013-10-22 19:53:08 scdaemon[15820] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 04 89 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 10 00 00 20 00 C2 06 01 10 00 00 20 00 C3 06 01 10 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C CC 19 5D 23 92 34 85 8F E0 25 31 DB A9 F0 CC F3 EA 7E F1 4F 79 C0 D2 34 6E 04 09 AB 89 B5 ED 10 8D 1F 92 D2 4A E6 0B AF 7A F7 D8 1C 32 87 D5 E3 D5 A0 F1 BA 75 29 9B 20 95 6A 3C EC C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 52 5D 88 A3 52 5D 88 A3 52 5D 88 A3 2013-10-22 19:53:08 scdaemon[15820] DBG: check_pcsc_pinpad: command=20, r=27265 2013-10-22 19:53:08 scdaemon[15820] DBG: asking for PIN '||Bitte die PIN eingeben' scdaemon[15820]: chan_00000138 -> INQUIRE NEEDPIN ||Bitte die PIN eingeben scdaemon[15820]: chan_00000138 <- [ 44 20 PI NP IN PI NP IN 00 00 00 00 00 00 00 00 ...(76 byte(s) skipped) ] scdaemon[15820]: chan_00000138 <- END 2013-10-22 19:53:12 scdaemon[15820] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=6 le=-1 em=0 2013-10-22 19:53:12 scdaemon[15820] DBG: PCSC_data: 00 20 00 82 06 PI NP IN PI NP IN 2013-10-22 19:53:12 scdaemon[15820] DBG: response: sw=9000 datalen=0 2013-10-22 19:53:12 scdaemon[15820] DBG: dump: 2013-10-22 19:53:12 scdaemon[15820] DBG: send apdu: c=00 i=2A p1=80 p2=86 lc=513 le=2048 em=1 2013-10-22 19:53:12 scdaemon[15820] DBG: PCSC_data: 00 2A 80 86 00 02 01 00 0D 9E 9F 4B AB F6 EB 57 26 CF 90 1C 60 19 C8 66 91 22 90 C9 16 2F 6B 95 69 A3 BF 35 4A 01 DB 88 50 CA 74 E9 FC E8 54 1F 79 9F 5E 4B 74 4C 69 C7 BE 67 34 77 82 BE 5B A3 F6 FD 83 AF 7F F9 AF 88 BA 2D C0 E1 A1 C9 1B FF 5D 68 A1 C7 72 FF 95 5B C6 35 9F EB E2 C3 7E E9 97 81 11 C3 9E 78 A9 C2 4F CA 43 47 D5 20 8F 64 BF 2B E5 CC D7 1B F4 BC DA A0 05 7F A0 6D 37 40 5D 23 8C F3 C9 BC 08 52 54 D6 ED 53 4D C0 40 7B 30 35 C1 0F 89 7F 75 E8 09 6C 3C D0 E2 FB DC F5 D7 10 6C 9D EB 56 26 C8 2B 40 68 9C 3E 6C 17 CE 4E AE 8F 49 BA 47 9A E9 F6 10 34 48 DA D4 52 BC 8A 6D A8 49 E6 FC 17 2A 52 22 62 DE 3E 94 21 11 2B CA 60 C9 24 06 3E 19 94 EA 9B 6D 80 8C 11 8C B4 23 54 8F 84 30 42 11 63 16 60 52 ED 3E D4 DB F5 F1 04 F9 4D 9C 6D 3A 48 6B 6B 30 F1 14 F7 45 CF AB AA FB AE B0 9D 85 7E 71 36 F0 38 16 5D 9F F8 29 B2 97 B6 26 F7 91 42 11 19 AD 31 1B 5B 5E 74 F2 20 66 D8 01 29 BF E3 BB 4A 07 EC E7 51 75 FB 63 B0 73 24 0F E0 D3 BA 10 43 AD 84 59 97 61 DD 96 00 D0 E5 AB A6 67 E5 1D D3 2B 83 B9 08 84 6B 01 C2 8A 10 B5 CD 97 40 D7 51 4D 83 F6 57 C3 C9 54 BF E7 C2 D5 3C 83 29 40 E4 49 0A 65 09 E4 C1 59 23 33 87 2B C7 1E D6 D2 C6 81 4D F6 ED 4E 2C 7A 56 C9 3D F1 59 80 7D 18 29 DA 53 1D EE 5A B3 5D 6F 53 69 19 58 4F 09 9C 6D 32 E1 6B CD 97 40 F8 E9 1C 46 12 F6 0D E0 50 A6 A4 BF 95 CE C9 A0 D2 77 BA CE CE 45 11 11 8A BD 20 59 F1 56 95 A2 3B 71 24 84 6A 68 31 D4 9E C5 7F A3 DF A9 07 40 6F 60 B6 BD 37 07 8E 81 7E 10 80 69 C8 82 64 A1 8C 22 AF B9 EE 67 BE 9D 48 AF 9E 28 5B B2 5C 39 1C 83 E4 E9 62 51 D9 D4 1A B3 72 D6 14 98 B7 5A 90 7E 6C 00 59 25 0B 08 00 2013-10-22 19:53:15 scdaemon[15820] DBG: response: sw=9000 datalen=35 2013-10-22 19:53:15 scdaemon[15820] DBG: dump: 09 2A F3 4A 7E 82 3B 0E E9 80 2A 11 69 1F CF 2D 27 85 AF FA 4C 31 A3 0E 5D 72 58 B3 85 38 2F FF 5A 0D 7A 2013-10-22 19:53:15 scdaemon[15820] operation decipher result: Erfolg scdaemon[15820]: chan_00000138 -> [ 44 20 09 2a f3 4a 7e 82 3b 0e e9 80 2a 11 69 1f ...(23 byte(s) skipped) ] scdaemon[15820]: chan_00000138 -> OK scdaemon[15820]: chan_00000138 <- RESTART scdaemon[15820]: chan_00000138 -> OK From mailinglisten at hauke-laging.de Tue Oct 22 23:38:48 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 22 Oct 2013 23:38:48 +0200 Subject: Selecting your own key with Enigmail In-Reply-To: <5266EC58.10702@vulcan.xs4all.nl> References: <5266EC58.10702@vulcan.xs4all.nl> Message-ID: <1532467.TF4MRtsMGf@inno.berlin.laging.de> Am Di 22.10.2013, 23:21:28 schrieb Johan Wevers: > I have 2 active keys (a v3 2048 bit RSA and a v3 3072 bit DSA), and when > I send encrypted mail via Thunderbird 3.1.20 it uses always the RSA keyt > for encrypt to self but I want to use the other. DSA cannot encrypt. gpg --edit-key 0x12345678 quit shows you the keys' capability flags. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From johanw at vulcan.xs4all.nl Tue Oct 22 23:45:28 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 22 Oct 2013 23:45:28 +0200 Subject: Selecting your own key with Enigmail In-Reply-To: <1532467.TF4MRtsMGf@inno.berlin.laging.de> References: <5266EC58.10702@vulcan.xs4all.nl> <1532467.TF4MRtsMGf@inno.berlin.laging.de> Message-ID: <5266F1F8.9010600@vulcan.xs4all.nl> On 22-10-2013 23:38, Hauke Laging wrote: >> I have 2 active keys (a v3 2048 bit RSA and a v3 3072 bit DSA), and when >> I send encrypted mail via Thunderbird 3.1.20 it uses always the RSA keyt >> for encrypt to self but I want to use the other. > > DSA cannot encrypt. I was incomplete, it is a 1024 DSA key with a 3072 bit ElGamal encryption subkey: gpg --edit-key 9e8c5ddf gpg (GnuPG) 1.4.15; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 1024D/9E8C5DDF created: 2000-08-11 expires: never usage: SCA trust: ultimate validity: ultimate sub 3072g/7A3FE18C created: 2000-08-11 expires: never usage: E [ultimate] (1). Johan Wevers [ultimate] (2) Johan Wevers Should I put the 7A3FE18C in encrypt-to instead of 9E8C5DDF? When I encrypt files on the command line with gpg -e it uses the correct key. The RSA key is only kept for pgp 2.x compatibility. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Wed Oct 23 00:01:46 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 22 Oct 2013 18:01:46 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> Message-ID: <5266F5CA.80509@sixdemonbag.org> On 10/22/2013 11:01 AM, Stan Tobias wrote: > But this is not a real identification - almost none of us > has means to confirm an identity, which is a job for a detective. Last time I walked into a courthouse to speak with a judge the marshal asked for my driver's license -- he checked the photograph to make sure it was me, held it up to the light to check for a hologram, then checked the logbook to see if I was an expected visitor. Once he saw my name listed in the logbook he gave my driver's license back and buzzed me in. As far as the U.S. Marshal was concerned, my identity had been proven to a sufficient degree. He certainly didn't conduct a background check on me. (My father and cousin are both judges, if you're wondering why I visit courthouses so often.) That phrase, "to a sufficient degree," is important. You cannot ever verify someone's identity 100%, not even with DNA testing -- it's always possible they have an identical twin, always possible the lab work was sloppy and done in error, etc. What you want to do instead is have a certain level of confidence in someone's identity. For some people, that level of confidence is "this person says they are so-and-so." For other people, that level of confidence is "this person has a passport saying they are so-and-so." OpenPGP is completely silent about what level of confidence you should have for a certification. It only says that when you sign a certificate, you are making an assertion about identity: that, to a level exceeding your threshold of certainty, such-and-such an identifier is an accurate descriptor for the individual or agency who controls the private part of a certificate. From mailinglisten at hauke-laging.de Wed Oct 23 00:17:10 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 23 Oct 2013 00:17:10 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <5266F5CA.80509@sixdemonbag.org> References: <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> Message-ID: <4168965.UghD8aZBYv@inno.berlin.laging.de> Am Di 22.10.2013, 18:01:46 schrieb Robert J. Hansen: > certificate, you are making an assertion about identity: that, to a > level exceeding your threshold of certainty, Even worse: "exceeding your threshold of certainty in that moment" I am afraid this assessment changes for most users over time (which is not bad per se; the problem is the lack of transparency about that). Thus I demand a standardized scale for that so that we can easily know what the others are talking about. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Wed Oct 23 00:34:35 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 23 Oct 2013 00:34:35 +0200 Subject: Selecting your own key with Enigmail In-Reply-To: <5266F1F8.9010600@vulcan.xs4all.nl> References: <1532467.TF4MRtsMGf@inno.berlin.laging.de> <5266F1F8.9010600@vulcan.xs4all.nl> Message-ID: <3802893.ezxSy0sFGc@inno.berlin.laging.de> Am Di 22.10.2013, 23:45:28 schrieb Johan Wevers: > pub 1024D/9E8C5DDF created: 2000-08-11 expires: never usage: SCA > trust: ultimate validity: ultimate > sub 3072g/7A3FE18C created: 2000-08-11 expires: never usage: E > [ultimate] (1). Johan Wevers > [ultimate] (2) Johan Wevers > > Should I put the 7A3FE18C in encrypt-to instead of 9E8C5DDF? No. > When I > encrypt files on the command line with gpg -e it uses the correct key. It seems to me that this is an EnigMail problem and not a gpg problem. Probably you have configured the wrong key there. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Oct 23 10:14:37 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Oct 2013 10:14:37 +0200 Subject: Building pinentry on Windows 7 In-Reply-To: (Nikola Radovanovic's message of "Tue, 22 Oct 2013 12:06:16 +0000") References: Message-ID: <87ob6g5rpu.fsf@vigenere.g10code.de> On Tue, 22 Oct 2013 14:06, Nikola.Radovanovic at seavus.com said: > I couldn't find any manual for building pinentry executables for > Windows (specifically Windows 7/8). Also for Gpg4Win 2 in general. I The easiest way to do this is to follow the README of the gpg4win installer source. It is best to use a decent Debian systems. Although the configure script of the installer checks for required software, some checks are missing and you may run in to errors if you have not installed, for example the transfig package. Let us know what you had to install so we can add the checks. If you just want to build pinentry, you download the tarball and mkdir ~/w32root cd somewhere tar xjvf pinentry-0.8.3.tar.bz2 cd pinentry-0.8.3 ./autogen.sh --build-w32 make make install cp ~/w32root/bin/pinentry-*.exe /cifs/windows7-box/.../../ However, unless you only want the really ugly native pinentry you need to install lots of libraries first. Thus using the gpg4win installer framework is easier. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From johanw at vulcan.xs4all.nl Wed Oct 23 11:01:57 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 23 Oct 2013 11:01:57 +0200 Subject: Selecting your own key with Enigmail In-Reply-To: <526717B5.5050908@enigmail.net> References: <5266EC58.10702@vulcan.xs4all.nl> <526717B5.5050908@enigmail.net> Message-ID: <52679085.9070700@vulcan.xs4all.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23-10-2013 2:26, Olav Seyfarth wrote: > have you set your key HERE : > https://www.enigmail.net/documentation/per-account.php ? Ah, not for this mail address. Thanks, I had not found this option. Testing the signature now. - -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFSZ5CFbVOviZ6MXd8RAiBKAJ9PjE8GYgwRbK7iwlGcMx1CIR6UigCeIdnp IUzD1LCzI+52SdwxIP+1Rzc= =0maE -----END PGP SIGNATURE----- From aheinecke at intevation.de Wed Oct 23 12:18:38 2013 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 23 Oct 2013 12:18:38 +0200 Subject: Building pinentry on Windows 7 Message-ID: <201310231218.43582.aheinecke@intevation.de> Hi, On Wednesday 23 October 2013 10:14:37 Werner Koch wrote: > However, unless you only want the really ugly native pinentry you need > to install lots of libraries first. Thus using the gpg4win installer > framework is easier. I've recently played around with MXE ( http://mxe.cc/ ) which is another cross compilation environment that aims to provide an easy way to handle dependencys for Windows. To build a static pinentry-qt4 with it you can just set it up as documented on their homepage. Drop the attached pinentry.mk in mxe/src/ and do "make pinentry" Worked like a charm for me on a debian wheezy system. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- PKG := pinentry $(PKG)_IGNORE := $(PKG)_VERSION := 0.8.3 $(PKG)_CHECKSUM := fc0efe5d375568f90ddbb23ee68e173411a49d4a $(PKG)_SUBDIR := pinentry-$($(PKG)_VERSION) $(PKG)_FILE := pinentry-$($(PKG)_VERSION).tar.bz2 $(PKG)_URL := ftp://ftp.gnupg.org/gcrypt/pinentry/$($(PKG)_FILE) $(PKG)_DEPS := gcc qt define $(PKG)_UPDATE $(WGET) -q -O- 'ftp://ftp.gnupg.org/gcrypt/pinentry/' | \ $(SED) -n 's,.*pinentry-\([1-9]\.[1-9][0-9][^>]*\)\.tar.*,\1,p' | \ tail -1 endef define $(PKG)_BUILD cd '$(1)' && ./configure \ --host='$(TARGET)' \ --build="`config.guess`" \ --disable-shared \ --prefix='$(PREFIX)/$(TARGET)' \ --disable-pinentry-qt \ --disable-ncurses \ --disable-pinentry-gtk2 \ --disable-glibtest \ --disable-gtktest \ --enable-pinentry-qt4 \ --enable-pinentry-qt4-clipboard $(MAKE) -C '$(1)' -j '$(JOBS)' $(MAKE) -C '$(1)' -j 1 install endef From sttob at privatdemail.net Wed Oct 23 19:26:58 2013 From: sttob at privatdemail.net (Stan Tobias) Date: Wed, 23 Oct 2013 19:26:58 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <5266F5CA.80509@sixdemonbag.org> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> Message-ID: <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> "Robert J. Hansen" wrote: > On 10/22/2013 11:01 AM, Stan Tobias wrote: > > But this is not a real identification - almost none of us > > has means to confirm an identity, which is a job for a detective. [...] > As far as the U.S. Marshal was concerned, my identity had been proven > to a sufficient degree. He certainly didn't conduct a background check > on me. Then by checking your documents he casually confirmed your identity with some low probability of error (taking some assumptions). But if I were him, I wouldn't tell I could _vouch_ for it (your identity, that is; documents are no proof). > That phrase, "to a sufficient degree," is important. You cannot ever > verify someone's identity 100%, [...] > OpenPGP is completely silent about what level of confidence you should > have for a certification. It only says that when you sign a > certificate, you are making an assertion about identity: that, to a > level exceeding your threshold of certainty, (I believe you, but where does it say so? I couldn't find it in rfc4880.) > such-and-such an identifier > is an accurate descriptor for the individual or agency who controls the > private part of a certificate. Then I probably should never sign any key. I'm only certain of what I can prove, and then I can merely believe my logic didn't have any flaws. I was triggered by your earlier statement "I am vouching for the identity of X." This is one of the points I made: we can only establish a belief in someone's identity. What we vouch for is that the person is willing to use the key (we might call it "identifying the owner", which is not the same as establishing that X is really X). That's probably not everything we vouch for, if you care to read to the end. Later someone discussed a paradox (they used the word "dichotomy", but I think it's a wrong word here - maybe they wanted "dissonance"): Peter Lebbing wrote: > The dichotomy is thus: if the notary does not sign keys, I would be okay > with people signing keys based on the notary's verification efforts. But > if that same notary did everything he or she did before *and* did > something extra, namely signing keys, suddenly I'm not okay with people > signing keys based on the notary's verification efforts. That's odd. The paradox is removed when we realize that the notary's signature is not a statement about the identity of the person. One may assume the corporation's proper personal identification, but one cannot derive from the notary's signature the person's willingness to use the key (iow - ownership of the key). That is what only that person may communicate to you (and by making a cert you become a witness to the fact). I've thought up these similar cases, where the will of the person is communicated through a signed e-mail: 1. Corporation establishes identity and signs the X's key. Then, X e-mails you "I use key 0xABCDEFGH". The message is signed with the same key. Can you sign his key? There's no reason to disbelieve the identity (established by the corporation). The question whether to believe the authenticity of the message seems to hinge on the truthfulness of the corporation's certification (Have they signed the right key? Are they pulling some joke?). 2. Same as 1., but X's key is also signed by a few of your good friends, who have personally checked X's ownership of the key - the probability of foul play is infinitesimal. Would you sign now? 3. Your own cert is involved. You sign X's key K1. Then X sends you "I also use key K2" signed with K1. Will you certify K2? Signing X's key would feel to me a bit like proving a theorem by assuming it is true, but then I don't see where exactly it would be wrong to sign in the last case. It seems that in vouching for the X's will having been communicated to us, we also want to include the fact that the communication channel is independent - but of what? Stan. From Nikola.Radovanovic at seavus.com Wed Oct 23 13:26:45 2013 From: Nikola.Radovanovic at seavus.com (Nikola Radovanovic) Date: Wed, 23 Oct 2013 11:26:45 +0000 Subject: Building pinentry on Windows 7 In-Reply-To: <201310231046.38696.andre.heinecke@intevation.de> References: <87ob6g5rpu.fsf@vigenere.g10code.de> <201310231046.38696.andre.heinecke@intevation.de> Message-ID: Thank you very much for your answers, I will try all solutions and after that let you know of the outcome. Best regards, Nikola -----Original Message----- From: Andre Heinecke [mailto:andre.heinecke at intevation.de] Sent: Wednesday, October 23, 2013 10:47 AM To: gnupg-users at gnupg.org Cc: Werner Koch; Nikola Radovanovic Subject: Re: Building pinentry on Windows 7 Hi, On Wednesday 23 October 2013 10:14:37 Werner Koch wrote: > However, unless you only want the really ugly native pinentry you need > to install lots of libraries first. Thus using the gpg4win installer > framework is easier. I've recently played around with MXE ( http://mxe.cc/ ) which is another cross compilation environment that aims to provide an easy way to handle dependencys for Windows. To build a static pinentry-qt4 with it you can just set it up as documented on their homepage. Drop the attached pinentry.mk in mxe/src/ and do "make pinentry" Worked like a charm for me on a debian wheezy system. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From peter at digitalbrains.com Wed Oct 23 20:52:42 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 23 Oct 2013 20:52:42 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> Message-ID: <52681AFA.2060102@digitalbrains.com> On 23/10/13 19:26, Stan Tobias wrote: > Later someone discussed a paradox (they used the word "dichotomy", > but I think it's a wrong word here - maybe they wanted "dissonance"): Paradox would be the best and is what I should have used. Not dissonance. > The paradox is removed when we realize that the notary's signature is > not a statement about the identity of the person. I strongly disagree. The paradox is created by the fact that you screw up my Web of Trust parameters by signing stuff based on other people's OpenPGP signatures. > One may assume the > corporation's proper personal identification, but one cannot derive from > the notary's signature the person's willingness to use the key (iow - > ownership of the key). I don't see how willingness is ownership in other words. The concepts seem rather dichotomous, oh sorry, disjoint to me :). But since I wouldn't sign a key where the owner didn't give me the Key ID theirself, it would indicate willingness. Even stronger, it wouldn't even indicate ownership: they could have given me the Key ID of a key where somebody else, the real owner of the key, made a User ID with their name in it. I can't verify ownership: even if I see them making a signature right before my eyes, they could secretly be talking to an automated service somewhere that actually makes the signatures, and they might not have access to the key at all. I wouldn't go so far as to stick them in a Faraday's cage to ensure they can't communicate with the real owner of the key. > I've thought up these similar cases, where the will of the person is > communicated through a signed e-mail: > > 1. Corporation establishes identity and signs the X's key. Then, X > e-mails you "I use key 0xABCDEFGH". The message is signed with the > same key. Can you sign his key? There's no reason to disbelieve > the identity (established by the corporation). The question whether > to believe the authenticity of the message seems to hinge on the > truthfulness of the corporation's certification (Have they signed > the right key? Are they pulling some joke?). > > 2. Same as 1., but X's key is also signed by a few of your good friends, > who have personally checked X's ownership of the key - the probability > of foul play is infinitesimal. Would you sign now? > > 3. Your own cert is involved. You sign X's key K1. Then X sends you > "I also use key K2" signed with K1. Will you certify K2? Only 3. would perhaps qualify for a signature, in my opinion. The other 2 are food for your trust database or perhaps local signatures, not for exportable signatures. I should add that signing a message that says "I use 0xABCDEFGH" with that same key is a bit silly. (By the way, hex goes to F ;P). You use OpenPGP signatures to add authentication to messages that can be forged otherwise. Those signatures are only credible if you have verified that you have the correct key of that person. It's not the other way around: the signature does not prove it's the correct key, since the message could have been forged. You need a secure channel to establish that it's the correct key, such as a face-to-face meeting. Or you need to trust the corporation's signing key, but that belongs in your trust database, not your exportable signatures. 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 tapio.sokura at iki.fi Wed Oct 23 23:41:53 2013 From: tapio.sokura at iki.fi (Tapio Sokura) Date: Thu, 24 Oct 2013 00:41:53 +0300 Subject: gpg4win pinentry ignores PIN-pad In-Reply-To: <5266F023.5030202@gmail.com> References: <5266F023.5030202@gmail.com> Message-ID: <526842A1.8020900@iki.fi> Hello, On 23.10.2013 0:37, Martin Wolters wrote: > I am using gpg4win 2.2.1, which according to the change log supports > the SPR332 PIN-pad, but pinentry requests the PIN from the keyboard. > Is there anything I need to configure to enforce the entry from the > card reader? I'm having the exact same problem in gpg4win 2.2.1 with SPR 532 (firmware 5.10), Windows 7 64-bit. In Linux the pinpad worked by default just fine, no separate configuration needed. I have not done any special configuration of gpg4win related to pinpad usage, but I have installed the regular drivers provided by SCM. When I plug my openpgp v2 card into the reader slot, Windows pops up a notification "Device driver software was not successfully installed", but I'm assuming it's normal and due to Windows itself not understanding openpgp cards? Here are a few excerpts from my scdaemon log that might or might not be relevant. This is from logging into an ssh server using putty and a key stored in the authentication slot, pin input via pinentry/keyboard. If you need something more verbose, let me know. (BTW it would be nice to be able to export the ssh-compatible authorized_keys pubkey line directly via some more integrated way, gpgkey2ssh isn't supplied in gpg4win. Is there something similar?) 2013-10-23 23:43:05 scdaemon[792] listening on socket `C:\Users\username\AppData\Roaming\gnupg\S.scdaemon' 2013-10-23 23:43:05 scdaemon[792] handler for fd -1 started 2013-10-23 23:43:05 scdaemon[792] detected reader `SCM Microsystems Inc. SPRx32 USB Smart Card Reader 0' 2013-10-23 23:43:05 scdaemon[792] pcsc_control failed: invalid PC/SC error code (0x6) 2013-10-23 23:43:05 scdaemon[792] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65547 2013-10-23 23:43:05 scdaemon[792] reader slot 0: not connected 2013-10-23 23:43:06 scdaemon[792] reader slot 0: active protocol: T1 2013-10-23 23:43:06 scdaemon[792] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2013-10-23 23:43:06 scdaemon[792] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2013-10-23 23:43:06 scdaemon[792] Version-2 ......: yes 2013-10-23 23:43:06 scdaemon[792] Get-Challenge ..: yes (2048 bytes max) 2013-10-23 23:43:06 scdaemon[792] Key-Import .....: yes 2013-10-23 23:43:06 scdaemon[792] Change-Force-PW1: yes 2013-10-23 23:43:06 scdaemon[792] Private-DOs ....: yes 2013-10-23 23:43:06 scdaemon[792] Algo-Attr-Change: yes 2013-10-23 23:43:06 scdaemon[792] SM-Support .....: no 2013-10-23 23:43:06 scdaemon[792] Max-Cert3-Len ..: 2048 2013-10-23 23:43:06 scdaemon[792] Max-Cmd-Data ...: 2048 2013-10-23 23:43:06 scdaemon[792] Max-Rsp-Data ...: 2048 2013-10-23 23:43:06 scdaemon[792] Cmd-Chaining ...: no 2013-10-23 23:43:06 scdaemon[792] Ext-Lc-Le ......: yes 2013-10-23 23:43:06 scdaemon[792] Status Indicator: 05 2013-10-23 23:43:06 scdaemon[792] GnuPG-No-Sync ..: no 2013-10-23 23:43:06 scdaemon[792] GnuPG-Def-PW2 ..: no 2013-10-23 23:43:06 scdaemon[792] Key-Attr-sign ..: RSA, n=4096, e=32, fmt=std 2013-10-23 23:43:06 scdaemon[792] Key-Attr-encr ..: RSA, n=4096, e=32, fmt=std 2013-10-23 23:43:06 scdaemon[792] Key-Attr-auth ..: RSA, n=4096, e=32, fmt=std 2013-10-23 23:43:06 scdaemon[792] updating slot 0 status: 0x0000->0x0007 (0->1) 2013-10-23 23:43:06 scdaemon[792] triggering event 100 (00000100) for client -1 2013-10-23 23:43:10 scdaemon[792] DBG: check_pcsc_pinpad: command=20, r=27265 2013-10-23 23:43:10 scdaemon[792] DBG: asking for PIN '||Please enter the PIN' 2013-10-23 23:43:21 scdaemon[792] operation auth result: Success Tapio From sttob at privatdemail.net Thu Oct 24 01:15:04 2013 From: sttob at privatdemail.net (Stan Tobias) Date: Thu, 24 Oct 2013 01:15:04 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <52681AFA.2060102@digitalbrains.com> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> <52681AFA.2060102@digitalbrains.com> Message-ID: <52685878.6AXcxDzMhOJmhsWU%sttob@privatdemail.net> Peter Lebbing wrote: > On 23/10/13 19:26, Stan Tobias wrote: > > The paradox is removed when we realize that the notary's signature is > > not a statement about the identity of the person. > > I strongly disagree. The paradox is created by the fact that you screw > up my Web of Trust parameters by signing stuff based on other people's > OpenPGP signatures. No, there's no paradox. Any liar will screw your parameters. Notary's signature is only accidental; it doesn't matter whether someone bases his certification on tarot, clairvoyance, dowsing rod or some else's signature - neither of these allow to draw conclusions about the usage of the key. > > One may assume the > > corporation's proper personal identification, but one cannot derive from > > the notary's signature the person's willingness to use the key (iow - > > ownership of the key). > > I don't see how willingness is ownership in other words. I use these interchangeably. A user of a key is normally called "key owner" (I think). You become a key owner when you create a key (pair) and decide to use it (where using implies protection of secret part, appropriate uids, etc). You may create a key pair for fun, but without your will to use it that key does not "represent" you, iow you're not the "owner" of the key. > But since I wouldn't sign a key where the owner didn't give me the > Key ID theirself, it would indicate willingness. Even stronger, it > wouldn't even indicate ownership: they could have given me the Key ID > of a key where somebody else, the real owner of the key, made a User > ID with their name in it. I can't verify ownership: even if I see them > making a signature right before my eyes, they could secretly be talking > to an automated service somewhere that actually makes the signatures, > and they might not have access to the key at all. I wouldn't go so far > as to stick them in a Faraday's cage to ensure they can't communicate > with the real owner of the key. I don't quite follow your thoughts. But maybe this will better clarify mine: If I saw X create a key pair right before my eyes, with appropriate uid "Mr X", with a long password, with evidence he can encrypt/decrypt/sign, on a disconnected computer, and in a Faraday's cage, in an underground bunker; but if he didn't express to me his *will* to use the key, I would *not* sign it. Whether a key owner "shares" his key with someone or something else, is irrelevant. You cannot prove it, he may start "sharing" later, you have no control over it. I'd say it's his responsibility and his fault. Anyway, this information is not part of your certification (you don't certify that he uses his key correctly). (Below is an extension to the above discussion, and a kind of counterpoint, where I actually do try to find a paradox. I like to argue with myself.) > > 1. Corporation establishes identity and signs the X's key. Then, X > > e-mails you "I use key 0xABCDEFGH". The message is signed with the > > same key. Can you sign his key? There's no reason to disbelieve > > the identity (established by the corporation). The question whether > > to believe the authenticity of the message seems to hinge on the > > truthfulness of the corporation's certification (Have they signed > > the right key? Are they pulling some joke?). > > > > 2. Same as 1., but X's key is also signed by a few of your good friends, > > who have personally checked X's ownership of the key - the probability > > of foul play is infinitesimal. Would you sign now? > > > > 3. Your own cert is involved. You sign X's key K1. Then X sends you > > "I also use key K2" signed with K1. Will you certify K2? > > Only 3. would perhaps qualify for a signature, in my opinion. :-| Hmm... I dunno. > The other 2 are > food for your trust database or perhaps local signatures, not for exportable > signatures. > I should add that signing a message that says "I use 0xABCDEFGH" with > that same key is a bit silly. The common thread behind these cases is that X announces (more-or-less directly) to you his usage of a key, but his communication is authenticated only by WoT. In case 2. signing his key is somewhat similar to what we were discussing above: the certs are not actually the reason for you to sign, but they are the reason why you believe it is X who is communicating with you, and the *only* reason. If you don't think it's enough to certify his key (at which point does it happen?), then why do we believe WoT authenticates anything? Why do we accept, for example, a conversation by telephone to validate a key fingerprint? But then cases 2. (2a) and 3. differ basically by your cert being included in the set. If you wouldn't certify in case 2., why would you in case 3? But then again if you wouldn't certify in case 3., then don't you believe your own certification? Or the safety of the communication? So what do we sign messages for in the first place? Case 3. is unlike the others in that two X's keys are present (it couldn't be constructed any other way); for completeness, it might be worth formulating one more intermediate case: 2a. Same as 1., but X's key (K1) is also signed by a few of your good friends, who have personally checked X's ownership of the key, and X sends you "I use K2" signed with K1. Would you certify K2? If for some reason you would sign in cases 2a and 3, but not in case 2, X could trick you: sends you "I use K2" signed by K1 (K1 certed by friends which you trust), and you sign K2. Then X sends you "I use K1" signed by K2 (certed only by you yourself), and you sign K1 (case 3). K2 may be revoked now. >(By the way, hex goes to F ;P). I know. No keys were harmed in the making of my post. :-) Too long - sorry. Stan. From John at enigmail.net Thu Oct 24 02:43:58 2013 From: John at enigmail.net (John Clizbe) Date: Wed, 23 Oct 2013 19:43:58 -0500 Subject: Selecting your own key with Enigmail In-Reply-To: <52679085.9070700@vulcan.xs4all.nl> References: <5266EC58.10702@vulcan.xs4all.nl> <526717B5.5050908@enigmail.net> <52679085.9070700@vulcan.xs4all.nl> Message-ID: <52686D4E.7000800@enigmail.net> Johan Wevers wrote: > On 23-10-2013 2:26, Olav Seyfarth wrote: > >> have you set your key HERE : >> https://www.enigmail.net/documentation/per-account.php ? > > Ah, not for this mail address. Thanks, I had not found this option. > Testing the signature now. OpenPGP menu --> Preferences. Click [Display Expert Settings] button if only the Basic tab is shown. On Sending tab. Check 'Add my own key to the recipients list' [OK] to save. -John -- 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 mailinglisten at hauke-laging.de Thu Oct 24 03:44:50 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 24 Oct 2013 03:44:50 +0200 Subject: add a request for advocating crypto to the crypto tools Message-ID: <1524185.Rkb8MydCvq@inno.berlin.laging.de> Hello, due to its rather little visibility for the average user this affects GnuPG less than its GUIs (the mail clients in particular). It may well be used in the GnuPG documentation (man, info, www). But I assume that many GUI (or more general: crypto tool) developers are on these lists. We need everyone we can get for help in advocating the usage of crypto tools. Currently probably even most crypto users are not aware of the opportunities they have for doing that (even at nearly no effort). Thus I suggest that the crypto tools get somewhere (configuration windows) a link to a page which tells them. I created a page in the KDE userbase wiki (which has the advantage that it is going to be translated) for this purpose (based on my German page http://www.openpgp-schulungen.de/fuer/unterstuetzer/): http://userbase.kde.org/Concepts/OpenPGP_Help_Spread And I have created according wishlist entries (PLEASE feel free to vote for them ;-) ) in the bug tracker for KMail and KGpg: https://bugs.kde.org/show_bug.cgi?id=326476 (KMail) https://bugs.kde.org/show_bug.cgi?id=326477 (KGpg) This may not just raise the interest in crypto but also the donations for the tools. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ 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 John at enigmail.net Thu Oct 24 04:20:24 2013 From: John at enigmail.net (John Clizbe) Date: Wed, 23 Oct 2013 21:20:24 -0500 Subject: add a request for advocating crypto to the crypto tools In-Reply-To: <1524185.Rkb8MydCvq@inno.berlin.laging.de> References: <1524185.Rkb8MydCvq@inno.berlin.laging.de> Message-ID: <526883E8.9010409@enigmail.net> Hauke Laging wrote: > Hello, > > due to its rather little visibility for the average user this affects GnuPG > less than its GUIs (the mail clients in particular). It may well be used in > the GnuPG documentation (man, info, www). But I assume that many GUI (or more > general: crypto tool) developers are on these lists. > > We need everyone we can get for help in advocating the usage of crypto tools. > Currently probably even most crypto users are not aware of the opportunities > they have for doing that (even at nearly no effort). Thus I suggest that the > crypto tools get somewhere (configuration windows) a link to a page which > tells them. Enigmail has long been a featured extension on Thunderbird's page https://addons.mozilla.org/en-US/thunderbird/ I just checked and it is also featured on Seamonkey's https://addons.mozilla.org/en-US/seamonkey/ -- 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 mailinglisten at hauke-laging.de Thu Oct 24 04:36:14 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 24 Oct 2013 04:36:14 +0200 Subject: add a request for advocating crypto to the crypto tools In-Reply-To: <526883E8.9010409@enigmail.net> References: <1524185.Rkb8MydCvq@inno.berlin.laging.de> <526883E8.9010409@enigmail.net> Message-ID: <3344438.ruWq4YLqCh@inno.berlin.laging.de> Am Mi 23.10.2013, 21:20:24 schrieb John Clizbe: > Enigmail has long been a featured extension on Thunderbird's page > https://addons.mozilla.org/en-US/thunderbird/ That's nice but not what I was talking about (sorry if I didn't manage to make myself clear enough). That is "Use non-crypto tools to advertise crypto"; important, too, and I had this idea some time ago (probably even mentioned it here on the list), not limited to web sites but the applications themselves: https://bugs.kde.org/show_bug.cgi?id=318005 Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From tristan.santore at internexusconnect.net Thu Oct 24 07:48:14 2013 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Thu, 24 Oct 2013 06:48:14 +0100 Subject: Omnikey 3821 with OpenPGP Card and Pin Pad Entry Message-ID: <5268B49E.9050502@internexusconnect.net> Dear All, I have finally had time to play with the Omnikey 3821 and my OpenPGP cards. Yesterday, I somehow managed to get the Omnikey reader to accept pinpad entries. I suspect it was the enable-pinpad-varlen option in ~/.gnupg/scdaemon.conf, which did this. This worked for setting the password on card, but would not accept the password for an Auth Key I generated, that is expert mode then deselect (E) and (S) to leave the (A)uthentication bit. When I now set the enable-pinpad-varlen I keep getting: debug1: Offering RSA public key: cardno:00050XXXXXXXX debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 535 debug2: input_userauth_pk_ok: fp da:c6:79:b0:59:46:ba:15:e2:9c:ea:4b:a7:50:fa:75 debug3: sign_and_send_pubkey: RSA da:c6:79:b0:59:46:ba:15:e2:9c:ea:4b:a7:50:fa:75 Agent admitted failure to sign using the key. debug1: Trying private key: /home/blah..... Also, when I try gpg2 --card-edit, pinentry does not ask me to enter the pin, with the pinpad showing the request on the Omnikey's LCD screen. When I remove the enable-pinpad-varlen option from ~/gnupg/scdaemon.conf, pinpad-gtk pops up and asks me to enter the password. Is there something I missed ? It worked fine yesterday, minus the Auth pin issue. I was hoping to finally get there with the setup and be able to use the pinpad for pin entries. Any insights of you all, would be most appreciated. If I can provide you with any further output, which might help, let me know how and what you need, and I will be most happy to oblige. Thank you in advance. 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 tristan.santore at internexusconnect.net Thu Oct 24 09:22:23 2013 From: tristan.santore at internexusconnect.net (Tristan Santore) Date: Thu, 24 Oct 2013 08:22:23 +0100 Subject: Omnikey 3821 with OpenPGP Card and Pin Pad Entry In-Reply-To: <5268B49E.9050502@internexusconnect.net> References: <5268B49E.9050502@internexusconnect.net> Message-ID: <5268CAAF.2000301@internexusconnect.net> On 24/10/13 06:48, Tristan Santore wrote: > Dear All, > > I have finally had time to play with the Omnikey 3821 and my OpenPGP > cards. Yesterday, I somehow managed to get the Omnikey reader to accept > pinpad entries. I suspect it was the enable-pinpad-varlen option in > ~/.gnupg/scdaemon.conf, which did this. This worked for setting the > password on card, but would not accept the password for an Auth Key I > generated, that is expert mode then deselect (E) and (S) to leave the > (A)uthentication bit. > > When I now set the enable-pinpad-varlen I keep getting: > > > debug1: Offering RSA public key: cardno:00050XXXXXXXX > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Server accepts key: pkalg ssh-rsa blen 535 > debug2: input_userauth_pk_ok: fp > da:c6:79:b0:59:46:ba:15:e2:9c:ea:4b:a7:50:fa:75 > debug3: sign_and_send_pubkey: RSA > da:c6:79:b0:59:46:ba:15:e2:9c:ea:4b:a7:50:fa:75 > Agent admitted failure to sign using the key. > debug1: Trying private key: /home/blah..... > > Also, when I try gpg2 --card-edit, pinentry does not ask me to enter the > pin, with the pinpad showing the request on the Omnikey's LCD screen. > > When I remove the enable-pinpad-varlen option from > ~/gnupg/scdaemon.conf, pinpad-gtk pops up and asks me to enter the password. > > Is there something I missed ? It worked fine yesterday, minus the Auth > pin issue. I was hoping to finally get there with the setup and be able > to use the pinpad for pin entries. > > Any insights of you all, would be most appreciated. > > If I can provide you with any further output, which might help, let me > know how and what you need, and I will be most happy to oblige. > > Thank you in advance. > > Regards, > > Tristan > To answer my own question! After prodding around and searching for answers, this appears to be an issue with gnupg2.0.22. There is also a bug filed for it. I reverted back to an older version, albeit this one does something weird too. I will keep prodding that, until I get the error I had earlier, then send a new email about the issue, or file a bug, depending on what my findings are. So, for now please ignore my previous email. Thank you. 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 peter at digitalbrains.com Thu Oct 24 11:35:46 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Oct 2013 11:35:46 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <52685878.6AXcxDzMhOJmhsWU%sttob@privatdemail.net> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> <52681AFA.2060102@digitalbrains.com> <52685878.6AXcxDzMhOJmhsWU%sttob@privatdemail.net> Message-ID: <5268E9F2.1050108@digitalbrains.com> On 24/10/13 01:15, Stan Tobias wrote: > No, there's no paradox. Any liar will screw your parameters. The paradox was very clear in my post where I still called it a dichotomy. There was a paradox in my thoughts and conclusions, why do you suddenly state there is no paradox? And my original statement included: the moment I find out people sign keys purely based on OpenPGP signatures they trust, they get an "I do NOT trust" in my trust database. Obviously you also try to do this for liars, so this is no different: when you find out someone's a liar, you give them negative trust in your trust database. > If you don't think it's enough to certify his key (at which point does it > happen?) The moment the verification is outside the Web Of Trust, it can start to be enough. For an explanation I refer to my mail of 18 October, 11:37 CEST. You are skewing my parameters "marginals needed", "completes needed" and "max cert depth". If I trust the notary just like you do, I give that person full ownertrust, and the keys they signed will become valid by that. I don't need nor want your signature for that if it's just based on the fact you trust the notary. > , then why do we believe WoT authenticates anything? Why do we accept, for > example, a conversation by telephone to validate a key fingerprint? Because these are verifications outside the Web of Trust. > But then cases 2. (2a) and 3. differ basically by your cert being included in > the set. No, the difference is that in case 3., you (hopefully) actually did the verification yourself for key K1, an you extend this verification you did yourself to key K2. In the other cases, I can get validity for the keys in question by assigning trust to the same signers that you trust. In case 3., you are actually adding information to the Web of Trust, just like in the case where the notary did not create OpenPGP signatures themselves. > But then again if you wouldn't certify in case 3., then don't you believe > your own certification? Or the safety of the communication? So what do we > sign messages for in the first place? That's correct, you could be so demanding that you say that you insist on seeing the person face-to-face before you signed their key, because key K1 could have been stolen and you don't want to make /new/ certifications based solely on a signed message. It's a personal decision. You could have higher standards for certifications than for other communication (for which you would trust the signature). And these higher standards aren't prohibitive, because certifications are rare. You can spend a little effort on them that you don't want to spend for other communication. > 2a. Same as 1., but X's key (K1) is also signed by a few of your good > friends, who have personally checked X's ownership of the key, and X sends > you "I use K2" signed with K1. Would you certify K2? I wouldn't sign K1 in this case (I'd assign ownertrust to my friends so the key becomes valid), so if I would sign K2, I think that would be beyond a paradox and just downright inconsequent. So no, I wouldn't sign K2. I never did any verification of the identity of this person. They should ask my friends to sign this key if they don't want to do a face-to-face. > If for some reason you would sign in cases 2a and 3, but not in case 2, X > could trick you: sends you "I use K2" signed by K1 (K1 certed by friends > which you trust), and you sign K2. Then X sends you "I use K1" signed by K2 > (certed only by you yourself), and you sign K1 (case 3). K2 may be revoked > now. Sounds to me like you give a good point why you shouldn't sign in case 2a. > I know. No keys were harmed in the making of my post. :-) Hehehe :) > Too long - sorry. I don't think it was. Too short, and you might not make your point properly. Cheers, 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 johanw at vulcan.xs4all.nl Thu Oct 24 12:18:40 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 24 Oct 2013 12:18:40 +0200 Subject: Selecting your own key with Enigmail In-Reply-To: <52686D4E.7000800@enigmail.net> References: <5266EC58.10702@vulcan.xs4all.nl> <526717B5.5050908@enigmail.net> <52679085.9070700@vulcan.xs4all.nl> <52686D4E.7000800@enigmail.net> Message-ID: <5268F400.7080808@vulcan.xs4all.nl> On 24-10-2013 2:43, John Clizbe wrote: > OpenPGP menu --> Preferences. > > Click [Display Expert Settings] button if only the Basic tab is shown. > > On Sending tab. Check 'Add my own key to the recipients list' I already did that, but I have more than 1 active key and it selected the one I didn't want to use (the key I keep for pgp 2 compatibility). I forgot I could select the key in the account settings (I did select it once for my other mail address). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From sttob at privatdemail.net Thu Oct 24 19:27:42 2013 From: sttob at privatdemail.net (Stan Tobias) Date: Thu, 24 Oct 2013 19:27:42 +0200 Subject: trust your corporation for keyowner identification? In-Reply-To: <5268E9F2.1050108@digitalbrains.com> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> <52681AFA.2060102@digitalbrains.com> <52685878.6AXcxDzMhOJmhsWU%sttob@privatdemail.net> <5268E9F2.1050108@digitalbrains.com> Message-ID: <5269588e.wAXyOS+XkCb/A4Oa%sttob@privatdemail.net> Peter Lebbing wrote: > On 24/10/13 01:15, Stan Tobias wrote: > > , then why do we believe WoT authenticates anything? Why do we accept, for > > example, a conversation by telephone to validate a key fingerprint? > > Because these are verifications outside the Web of Trust. Is that the only requirement? Then I have fantastic news for you! You'll no longer have to visit your friends around Alpha Centauri to be able to certify their keys. A new system will be developed, called ClosedGPG (Galactic Privacy Guarantee). It will provide services such as signatures (for authentication) and key certificates. The certificates will be backed by LoH (Line of Hope) scheme (can't give you specifics - not been invented yet). It works like this: When your distant friend creates a new OpenPGP key, he only needs to send you the message "I use this key: [base64 OpenPGP key snipped]" signed with his ClosedGPG key. By invoking LoH system you validate his ClosedGPG signature and convince yourself the message is authentic, all entirely outside of WoT. Now you can safely sign his OpenPGP key with yours, and send it from your cottage on Mars to your friends working on Titan. All in measly four years! (If you wondered - of course, certifications of ClosedGPG keys have a requirement to be done outside of LoH. For this purpose you employ OpenPGP backed by WoT scheme.) Best regards, allow me some time for answering other parts, Stan. From todd.hesla at gmail.com Thu Oct 24 18:40:32 2013 From: todd.hesla at gmail.com (Todd Hesla) Date: Thu, 24 Oct 2013 11:40:32 -0500 Subject: Gpg-agent won't add SSH keys Message-ID: <20131024164031.GB1877@gmail.com> Dear fellow GnuPG users: I'm running gpg-agent with SSH support enabled, but ssh-add doesn't work as expected. The documentation for the "enable-ssh-support" option says that ssh-add will ask for my SSH passphrase (it does), and that then gpg-agent will ask for my GPG passphrase, and use it to encrypt my SSH key and store it in a "gpg-agent specific directory". The second step doesn't happen. Not only am I not asked for my (GPG) passphrase, but the "sshcontrol" file is not updated. (I assume that this is the "gpg-agent specific directory" referred to in the docs.) The end result is that each day (or each time I start gpg-agent in a new session), I need to enter my SSH passphrase the first time I run one of the SSH utilities. The documentation for the "enable-ssh-support" option implies that this shouldn't be necessary--that once I enter my GPG passphrase at the beginning of the session, the agent should perform all further requests (involving either my GPG key, or my SSH key) without asking for a passphrase. Or am I just misunderstanding how things are supposed to work? I've checked the SSH_AUTH_SOCK environment variable, and it appears to be set correctly. I'm running GnuPG 2.0.19 (and OpenSSH_6.1p1) on a recently installed Fedora 18 system. Thanks for your help. -- Todd Hesla From peter at digitalbrains.com Thu Oct 24 20:52:10 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 24 Oct 2013 20:52:10 +0200 Subject: trust your corporation for keyowner =?UTF-8?Q?identification?= =?UTF-8?Q?=3F?= In-Reply-To: <5269588e.wAXyOS+XkCb/A4Oa%sttob@privatdemail.net> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> <52681AFA.2060102@digitalbrains.com> <52685878.6AXcxDzMhOJmhsWU%sttob@privatdemail.net> <5268E9F2.1050108@digitalbrains.com> <5269588e.wAXyOS+XkCb/A4Oa%sttob@privatdemail.net> Message-ID: On 2013-10-24 19:27, Stan Tobias wrote: >> Because these are verifications outside the Web of Trust. > > Is that the only requirement? *Sigh*. No, it's the other way around. The Web Of Trust should never be a basis for your signature, because anyone else can simply trust the people who already made signatures to make keys valid, and you only muddle the view when you sign keys without verifying someone's identity. But I get the sense I'm not coming through to you, so maybe we can just agree to disagree, or at least agree to not understand eachother. I get the sense I've made my point already and I'm just rehashing old material by now. > allow me some time for answering other parts, Sure, if you like to. I never pressed you for an answer anyway. You don't have to convince me; I'm quite happy being stubborn. Cheers, 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 beuc at beuc.net Thu Oct 24 21:05:45 2013 From: beuc at beuc.net (Sylvain) Date: Thu, 24 Oct 2013 21:05:45 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian Message-ID: <20131024190545.GA20255@mail.beuc.net> Hi, I saw a lot of activity in the Debian project about upgrading to a 4096 RSA key, e.g. http://lists.debian.org/debian-devel-announce/2010/09/msg00003.html However GnuPG's default is 2048. Is this zealotry on the Debian front, or something to update in gnupg? Cheers! Sylvain From VINEETA_DESHMUKH at CRGL-THIRDPARTY.COM Thu Oct 24 22:47:41 2013 From: VINEETA_DESHMUKH at CRGL-THIRDPARTY.COM (VINEETA DESHMUKH (CRGL-THIRDPARTY.COM)) Date: Thu, 24 Oct 2013 20:47:41 +0000 Subject: (GnuPG) 1.4.2 - Signature Verification Issue Message-ID: <21712480B76C974DA50F5DFC0F397680027B6776@MEUSNORW421.Na.Corp.Cargill.com> Hello, I am facing an issue with the Signature verification from one of our clients - JP Morgan. We currently have FTP+encryption+signature of all the files which they send to us. However, they recently have migrated their FTP servers to connect through secure FTP with SSH keys. This is where we are facing problems when it comes to signature verification to a few files which are placed through their automated process. I am pasting successful and failed logs for your reference. SUCCESS LOGS: [GNUPG:] ENC_TO F3F4E3D4F37Cxxxx 1 0 [GNUPG:] GOOD_PASSPHRASE gpg: encrypted with 2048-bit RSA key, ID F37Cxxxx, created 2013-09-06 "Cargill, Incorporated (For JP Morgan) " [GNUPG:] BEGIN_DECRYPTION [GNUPG:] PLAINTEXT 74 1382033372 test.txt [GNUPG:] PLAINTEXT_LENGTH 661 gpg: Signature made Thu Oct 17 13:09:33 2013 CDT using RSA key ID DC66xxxx [GNUPG:] SIG_ID +HaM3M1Nwxxxxxxxxxxxxx 2013-10-17 1382033373 [GNUPG:] GOODSIG F1E1C0B8DC66xxxx JPMC_xxxxxx gpg: Good signature from "JPMC_xxxxxx " [GNUPG:] VALIDSIG xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [GNUPG:] TRUST_ULTIMATE [GNUPG:] DECRYPTION_OKAY [GNUPG:] GOODMDC [GNUPG:] END_DECRYPTION FAILED LOGS: [GNUPG:] ENC_TO F3F4E3D4F37Cxxxx 1 0 [GNUPG:] GOOD_PASSPHRASE gpg: encrypted with 2048-bit RSA key, ID F37Cxxxx, created 2013-09-06 "Cargill, Incorporated (For JP Morgan) " [GNUPG:] BEGIN_DECRYPTION [GNUPG:] PLAINTEXT 74 1382033701 test.csv gpg: Signature made Thu Oct 17 13:15:03 2013 CDT using RSA key ID DC66xxxx [GNUPG:] BADSIG F1E1C0B8DC66xxxx JPMC_xxxxxxx gpg: BAD signature from "JPMC_xxxxxxx " Any kind of help and suggestions will be appreciated. Regards, Vineeta Deshmukh Cargill Desk:- (952)-984-5812 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Oct 25 01:46:20 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 24 Oct 2013 19:46:20 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <20131024190545.GA20255@mail.beuc.net> References: <20131024190545.GA20255@mail.beuc.net> Message-ID: <5269B14C.4020102@sixdemonbag.org> > Is this zealotry on the Debian front, or something to update in gnupg? Mostly zealotry. According to NIST, RSA-2048 is expected to be secure for about the next 25 years. From dshaw at jabberwocky.com Fri Oct 25 02:07:20 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 24 Oct 2013 20:07:20 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <20131024190545.GA20255@mail.beuc.net> References: <20131024190545.GA20255@mail.beuc.net> Message-ID: <0FCF152F-41C1-4E21-A337-B7A7B55CEE06@jabberwocky.com> On Oct 24, 2013, at 3:05 PM, Sylvain wrote: > Hi, > > I saw a lot of activity in the Debian project about upgrading to a > 4096 RSA key, > e.g. http://lists.debian.org/debian-devel-announce/2010/09/msg00003.html > > However GnuPG's default is 2048. > > Is this zealotry on the Debian front, or something to update in gnupg? Heh, you might dig through the mail archives from this list from around that time. In short, some people will call it zealotry. Some people will call it necessary. Some people are in the middle. Reasonable people can disagree about these things, and there isn't one right answer for everyone. However, in regards to the GnuPG default, that isn't an oversight. David From dshaw at jabberwocky.com Fri Oct 25 02:10:44 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 24 Oct 2013 20:10:44 -0400 Subject: (GnuPG) 1.4.2 - Signature Verification Issue In-Reply-To: <21712480B76C974DA50F5DFC0F397680027B6776@MEUSNORW421.Na.Corp.Cargill.com> References: <21712480B76C974DA50F5DFC0F397680027B6776@MEUSNORW421.Na.Corp.Cargill.com> Message-ID: On Oct 24, 2013, at 4:47 PM, "VINEETA DESHMUKH (CRGL-THIRDPARTY.COM)" wrote: > Hello, > > I am facing an issue with the Signature verification from one of our clients ? JP Morgan. We currently have FTP+encryption+signature of all the files which they send to us. However, they recently have migrated their FTP servers to connect through secure FTP with SSH keys. This is where we are facing problems when it comes to signature verification to a few files which are placed through their automated process. I am pasting successful and failed logs for your reference. The first thing to ask whenever people put FTP and signatures together is whether the files are transferred via ascii or binary mode in FTP, and the related question of whether the files you are transferring are in ascii armor or not. Transferring non-armored files via ascii mode in FTP can cause various corruption problems. David From free10pro at gmail.com Fri Oct 25 01:21:01 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Thu, 24 Oct 2013 16:21:01 -0700 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <20131024190545.GA20255@mail.beuc.net> References: <20131024190545.GA20255@mail.beuc.net> Message-ID: <75b360b0-5331-410f-8c95-7ba133189dd4@email.android.com> Sylvain wrote: >Hi, > >I saw a lot of activity in the Debian project about upgrading to a >4096 RSA key, >e.g. >http://lists.debian.org/debian-devel-announce/2010/09/msg00003.html > >However GnuPG's default is 2048. > >Is this zealotry on the Debian front, or something to update in gnupg? Hi, If someone or a group is considering a change to a larger key such as a 4096 bit key, it is a personal choice. It does not mean that the defaults are not sensible. There have been several discussions about using 4096 bits instead of 2048 bit keys over the years. Reading those threads may help. HTH. Cheers, --Paul -- PGP: 3DB6D884 From free10pro at gmail.com Fri Oct 25 02:44:35 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Thu, 24 Oct 2013 17:44:35 -0700 Subject: trust your corporation for keyowner identification? In-Reply-To: <5266F5CA.80509@sixdemonbag.org> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> Message-ID: "Robert J. Hansen" wrote: >On 10/22/2013 11:01 AM, Stan Tobias wrote: >That phrase, "to a sufficient degree," is important. You cannot ever >verify someone's identity 100%, not even with DNA testing -- it's >always >possible they have an identical twin, always possible the lab work was >sloppy and done in error, etc. What you want to do instead is have a >certain level of confidence in someone's identity. > >For some people, that level of confidence is "this person says they are >so-and-so." For other people, that level of confidence is "this person >has a passport saying they are so-and-so." This is the point. Every person using OpenPGP needs to make their own decisions about what constitutes an acceptable level of certainty that the person who's identity is being verified and checked against the UIDs on his purported key are valid. >OpenPGP is completely silent about what level of confidence you should >have for a certification. It only says that when you sign a >certificate, you are making an assertion about identity: that, to a >level exceeding your threshold of certainty, such-and-such an >identifier >is an accurate descriptor for the individual or agency who controls the >private part of a certificate. Even if OpenPGP were not silent on this matter. You would still need to know how someone (even someone you know very well) verifies another person's identity and keys. Assumptions are for fools. You can't blindly believe that the verifying individual is doing it "right". Cheers, --Paul -- PGP: 3DB6D884 From free10pro at gmail.com Fri Oct 25 02:28:23 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Thu, 24 Oct 2013 17:28:23 -0700 Subject: trust your corporation for keyowner identification? In-Reply-To: <5269588e.wAXyOS+XkCb/A4Oa%sttob@privatdemail.net> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> <52681AFA.2060102@digitalbrains.com> <52685878.6AXcxDzMhOJmhsWU%sttob@privatdemail.net> <5268E9F2.1050108@digitalbrains.com> <5269588e.wAXyOS+XkCb/A4Oa%sttob@privatdemail.net> Message-ID: <394703c2-751b-409e-b60f-0c7831b24839@email.android.com> Stan Tobias wrote: >Peter Lebbing wrote: >> On 24/10/13 01:15, Stan Tobias wrote: >> > , then why do we believe WoT authenticates anything? Why do we >accept, for >> > example, a conversation by telephone to validate a key fingerprint? >> >> Because these are verifications outside the Web of Trust. > >Is that the only requirement? Then I have fantastic news for you! The idea of using a different channel for confirming key details such as a key fingerprint is really a way of trying to avoid a man-in-the-middle attack on the verification of the key and its UIDs. It is not entirely foolproof--nothing is. It isn't any more complicated or foreign than if your friend sends you an attachment in an email and you call him, send him an SMS message, or talk to him face-to-face to confirm that the message was him before you open it. Cheers, --Paul -- PGP: 3DB6D884 From system at ioioioio.eu Fri Oct 25 02:47:54 2013 From: system at ioioioio.eu (system at ioioioio.eu) Date: Fri, 25 Oct 2013 02:47:54 +0200 Subject: gnu-pg mechanics Message-ID: <5269BFBA.5020608@ioioioio.eu> dear group-members, due to the necessity keeping user data save, iam working secondarily on the mechanic to implement such behaviour (gnupg) to a service, iam currently working on. http://ioioioio.eu/xml/concept.-.progress-files.html iam still using sha3.keccak to build hashes in the frontend with compiled javascript ( with google window toolkit ), but as ive read, the keccak-algorithm is still not save to be enough. i was wondering, why they didnt implemented larger hashes then 224/256 bit within that logic, i was expecting something like 2k or 4k at least, beside performance aspects, but my brain is obviously to small to enhance the keccak saveley to a larger keylength. anyhow. hashing the password is a one-way solution, but i want to encrypt/decrypt the whole communication between the browser-frontend and the server-remote-procedure call with something like gnupg, but to be honest, my knowledge in math and stuff like that is to poor to do it on my own. i wont build shity services, just claiming buzzwords, so my question is: /is someone able to paint the general mechanic of the procedure down or is there a documentation regarding that topic?/ to make it clear, iam using java as domain language, as i had excellent results, using these technology. one will smile about it at and bring some prejudice into that talking, but dont be afraid, iam working with a stop-watch during the development. as reward, i would build a small search engine to index the papers on the site with nosql techniques. another topic would be, to serve a open-source-framework with these results on github or somewhere else. i know, its a huge workload to bring such idea to life, but as i droped a lot of time into that project, these forecase would make it for me, to ensure the service to any other ( customer ). thanks in advance and TGIF tet -------------- next part -------------- An HTML attachment was scrubbed... URL: From aheinecke at intevation.de Fri Oct 25 09:28:45 2013 From: aheinecke at intevation.de (Andre Heinecke) Date: Fri, 25 Oct 2013 09:28:45 +0200 Subject: Building Pinentry for Windows In-Reply-To: References: Message-ID: <201310250928.47181.aheinecke@intevation.de> Hi, On Thursday 24 October 2013 20:49:09 Nikola Radovanovic wrote: > 1) When trying to build whole Gpg4Win i ran into several problems. Package > for gtkhtmlviewer2 couldn't be found, but i have resolved it. This archive > is now moved to plugins_obsolete folder (instead plugins) on a target url. Ah, such things happen, i'll see to it that the download url is updated. > Then stow was not installed on a system, and i have installed it with > apt-get install stow. But makensis, which is missing, must be installed > also. And it cannot be installed with apt-get. It requires python, scons, > zlib and gcc to be installed already, so it is a more complicated process. > Werner, if you can give me some hints about installing makensis it would be > great, but anyway i must analyze manual for installing makensis and all > dependent components in order to proceed further. makensis is part of the package nsis, which can be installed with "apt-get install nsis" > 2) As far as MXE is concerned, i have built and set successfully all > required packages, and built gcc and qt successfully. And finally when it > came to build pinentry it failed with message : 'No rule to make target > 'pinentry'. Stop.' And that's it. I have downloaded the package and tried > to build it manually with commands just like in .mk file, but with no > success. Yes pinentry is not included in mxe. I have written a .mk file for it and attached it In my Mail from Wednesday. You should have dropped that pinentry.mk file into the src directory of mxe. Godspeed, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From htd at fritha.org Fri Oct 25 15:53:25 2013 From: htd at fritha.org (Heinz Diehl) Date: Fri, 25 Oct 2013 15:53:25 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <20131024190545.GA20255@mail.beuc.net> References: <20131024190545.GA20255@mail.beuc.net> Message-ID: <20131025135325.GA1710@fritha.org> On 25.10.2013, Sylvain wrote: > Is this zealotry on the Debian front, or something to update in gnupg? It's a matter of taste, and there are arguments both for and against. In my case, having a 4096 bit key has no major drawbacks, so I'm using one. If you trust gpg, you can safely trust the standards Werner and the other developers have pre-defined for us. From wk at gnupg.org Fri Oct 25 15:50:35 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Oct 2013 15:50:35 +0200 Subject: Building Pinentry for Windows In-Reply-To: (Nikola Radovanovic's message of "Fri, 25 Oct 2013 11:53:04 +0000") References: <201310250928.47181.aheinecke@intevation.de> Message-ID: <87vc0l1mtw.fsf@vigenere.g10code.de> On Fri, 25 Oct 2013 13:53, Nikola.Radovanovic at seavus.com said: > Right now, by building the whole gpg4win i have succeeded in what i wanted, but i will certainly try again with MXE to see what is the problem there. I am glad to hear that. I will add some more tests to the installer. Just for the records: It is strongly suggested to use the gpg4win installer framework or (if necessary) the related "./autogen.sh --build-32" method for building GnuPG and related stuff for Windows. The reasons for this this suggestion is that we can't maintain the set of required options and dependencies in all kind of frameworks. I also don't want to follow up on bugs due to the use of other build systems. The reported problems with the OSX Homebrew build systems are an example of such events. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Oct 25 16:08:16 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Oct 2013 16:08:16 +0200 Subject: none In-Reply-To: (Nikola Radovanovic's message of "Thu, 24 Oct 2013 18:49:09 +0000") References: Message-ID: <87r4b91m0f.fsf@vigenere.g10code.de> On Thu, 24 Oct 2013 20:49, Nikola.Radovanovic at seavus.com said: > 1) When trying to build whole Gpg4Win i ran into several > problems. Package for gtkhtmlviewer2 couldn't be found, but i have Unfortunately this kind of problems happen from time to time. You may delete the claws-mail tar package from the packages directory to avoid all the Claws dependencies. > (instead plugins) on a target url. Then stow was not installed on a > system, and i have installed it with apt-get install stow. But Configure should have listed stow as missing, or am I wrong. > makensis, which is missing, must be installed also. And it cannot be Under Debian the package is "nsis". > installed with apt-get. It requires python, scons, zlib and gcc to be > installed already, so it is a more complicated process. Werner, if you Sure, that is due to NSIS? If so it would be a Debian packaging bug. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From brian at interlinx.bc.ca Fri Oct 25 18:54:19 2013 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Fri, 25 Oct 2013 12:54:19 -0400 Subject: trust your corporation for keyowner identification? In-Reply-To: <1422635312.20131022215717__3934.22178826786$1382475593$gmane$org@my_localhost> References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <1422635312.20131022215717__3934.22178826786$1382475593$gmane$org@my_localhost> Message-ID: On 13-10-22 04:57 PM, MFPA wrote: > Hi Hi, > It appears you probably meant the communication with > "bob at corporate.domain" was the out-of-band channel by which you and > Bob told each other your OpenPGP key fingerprints, and that being able > to send emails from those corporate accounts also doubled as identity > verification (because only the individual knows the relevant > credentials to send from "their" corporate email address, and the > company is required to verify government-issued ID documents when > engaging staff). Indeed. You have it exactly. Sorry I was not more clear about these details in the beginning. > As for use of a corporate email address, could I be sure that Bob > locked his computer every time he left his desk? Or that nobody else > would ever have access to a written record of Bob's passwords? Or > that, in Bob's absence, a substitute would never use Bob's email > address when covering his work? Indeed. Those are all things you'd have to take into account, just like having to take into account the risk of IT being involved in a black-hat role in all of this. I have to admit that any/all of those possibilities make me wary of such a scheme. I think I'd have to be able to "test" Bob on the other end of the OOB comms channel to use such a scheme. That seems to imply some level of familiarity with Bob, which might not be unreasonable considering we might work together. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From christoph.anton.mitterer at lmu.de Fri Oct 25 02:19:08 2013 From: christoph.anton.mitterer at lmu.de (Christoph Anton Mitterer) Date: Fri, 25 Oct 2013 02:19:08 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <20131024190545.GA20255@mail.beuc.net> References: <20131024190545.GA20255@mail.beuc.net> Message-ID: <1382660348.1296.62.camel@heisenberg.scientia.net> On Thu, 2013-10-24 at 21:05 +0200, Sylvain wrote: > Is this zealotry on the Debian front, or something to update in gnupg? As they write,... they don't see a specific (i.e. technical or performance) reason not to do so. Some people may argue that 2048 is secure enough for many many years to come. Similar things have been said for 1024 not so many years ago. And especially under the light of the NSA/friends scandal,... why using less when you have no strong reasons to do so? Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3811 bytes Desc: not available URL: From Nikola.Radovanovic at seavus.com Fri Oct 25 13:53:04 2013 From: Nikola.Radovanovic at seavus.com (Nikola Radovanovic) Date: Fri, 25 Oct 2013 11:53:04 +0000 Subject: Building Pinentry for Windows In-Reply-To: <201310250928.47181.aheinecke@intevation.de> References: , <201310250928.47181.aheinecke@intevation.de> Message-ID: Hello, Thanks for reply. I have did all that you wrote in the previous mail. I have dropped the pinentry.mk that you attached in the email to the mxe/src folder, but it won't work. But, just some moments ago i have successfully built the whole Gpg4Win :), by following the instructions from the README file from the source code. I figured out that the package name for installer is nsis, and not makensis, it is also mentioned in the Basic requirements section of the README file. Right now, by building the whole gpg4win i have succeeded in what i wanted, but i will certainly try again with MXE to see what is the problem there. Thanks for your kind responses. Best regards and cheers to all. Nikola. ________________________________________ From: Andre Heinecke [aheinecke at intevation.de] Sent: Friday, October 25, 2013 9:28 AM To: Nikola Radovanovic Cc: Werner Koch; gnupg-users at gnupg.org Subject: Re: Building Pinentry for Windows Hi, On Thursday 24 October 2013 20:49:09 Nikola Radovanovic wrote: > 1) When trying to build whole Gpg4Win i ran into several problems. Package > for gtkhtmlviewer2 couldn't be found, but i have resolved it. This archive > is now moved to plugins_obsolete folder (instead plugins) on a target url. Ah, such things happen, i'll see to it that the download url is updated. > Then stow was not installed on a system, and i have installed it with > apt-get install stow. But makensis, which is missing, must be installed > also. And it cannot be installed with apt-get. It requires python, scons, > zlib and gcc to be installed already, so it is a more complicated process. > Werner, if you can give me some hints about installing makensis it would be > great, but anyway i must analyze manual for installing makensis and all > dependent components in order to proceed further. makensis is part of the package nsis, which can be installed with "apt-get install nsis" > 2) As far as MXE is concerned, i have built and set successfully all > required packages, and built gcc and qt successfully. And finally when it > came to build pinentry it failed with message : 'No rule to make target > 'pinentry'. Stop.' And that's it. I have downloaded the package and tried > to build it manually with commands just like in .mk file, but with no > success. Yes pinentry is not included in mxe. I have written a .mk file for it and attached it In my Mail from Wednesday. You should have dropped that pinentry.mk file into the src directory of mxe. Godspeed, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From VINEETA_DESHMUKH at CRGL-THIRDPARTY.COM Fri Oct 25 16:53:05 2013 From: VINEETA_DESHMUKH at CRGL-THIRDPARTY.COM (VINEETA DESHMUKH (CRGL-THIRDPARTY.COM)) Date: Fri, 25 Oct 2013 14:53:05 +0000 Subject: (GnuPG) 1.4.2 - Signature Verification Issue In-Reply-To: References: <21712480B76C974DA50F5DFC0F397680027B6776@MEUSNORW421.Na.Corp.Cargill.com> Message-ID: <21712480B76C974DA50F5DFC0F397680027BCBBD@MEUSELKG421.Na.Corp.Cargill.com> Hi David, Thank you for your prompt response. The files which are sent by JP Morgan are using ascii mode of transfer and the files are ascii armored as well. Let me know if you have any other questions. Thanks, Vineeta -----Original Message----- From: David Shaw [mailto:dshaw at jabberwocky.com] Sent: Thursday, October 24, 2013 7:11 PM To: VINEETA DESHMUKH (CRGL-THIRDPARTY.COM) Cc: gnupg-users at gnupg.org; Kari Ingebritsen Subject: Re: (GnuPG) 1.4.2 - Signature Verification Issue On Oct 24, 2013, at 4:47 PM, "VINEETA DESHMUKH (CRGL-THIRDPARTY.COM)" wrote: > Hello, > > I am facing an issue with the Signature verification from one of our clients - JP Morgan. We currently have FTP+encryption+signature of all the files which they send to us. However, they recently have migrated their FTP servers to connect through secure FTP with SSH keys. This is where we are facing problems when it comes to signature verification to a few files which are placed through their automated process. I am pasting successful and failed logs for your reference. The first thing to ask whenever people put FTP and signatures together is whether the files are transferred via ascii or binary mode in FTP, and the related question of whether the files you are transferring are in ascii armor or not. Transferring non-armored files via ascii mode in FTP can cause various corruption problems. David From pete at heypete.com Fri Oct 25 23:33:14 2013 From: pete at heypete.com (Pete Stephenson) Date: Fri, 25 Oct 2013 23:33:14 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <1382660348.1296.62.camel@heisenberg.scientia.net> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> Message-ID: On Fri, Oct 25, 2013 at 2:19 AM, Christoph Anton Mitterer wrote: > On Thu, 2013-10-24 at 21:05 +0200, Sylvain wrote: >> Is this zealotry on the Debian front, or something to update in gnupg? > As they write,... they don't see a specific (i.e. technical or > performance) reason not to do so. > > Some people may argue that 2048 is secure enough for many many years to > come. Similar things have been said for 1024 not so many years ago. > > And especially under the light of the NSA/friends scandal,... why using > less when you have no strong reasons to do so? In my particular case, I mainly use GnuPG with emails and RSA signatures tend to be quite large and unwieldy for non-GnuPG-using users, mailing lists, etc. when one uses 4096-bit keys. As a compromise, I use a 4096-bit primary key (used only for certifying keys) and 2048-bit subkeys for encryption and signing, thus keeping signature sizes a bit more manageable. This also lets me periodically rotate subkeys as needed. For Debian devs, the signatures are (mostly?) used for package signing and so an extra few hundred bytes isn't really a big deal as it's rare for anyone to actually see the signature itself as it's processed automatically by the package manager. In their case, there's no specific reason to *not* use 4096-bit keys. It all depends on your use case, I suppose. Cheers! -Pete -- Pete Stephenson From johanw at vulcan.xs4all.nl Fri Oct 25 23:45:50 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 25 Oct 2013 23:45:50 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <5269B14C.4020102@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> Message-ID: <526AE68E.1060903@vulcan.xs4all.nl> On 25-10-2013 1:46, Robert J. Hansen wrote: > Mostly zealotry. According to NIST, RSA-2048 is expected to be secure > for about the next 25 years. The authority of NIST is of course severely reduced since the Snowden revelations and their own suspicious behaviour with the Dual EC PRNG. Further, if they expect it to be secure for only 25 years, that is sufficient for people to upgrade if they expect to remain alive over 25 years (although in this case it might not apply since the key is only used for signatures and adding backdoors in a 25 year old OS will not be very usefull). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From free10pro at gmail.com Sat Oct 26 02:39:58 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Fri, 25 Oct 2013 17:39:58 -0700 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526AE68E.1060903@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526AE68E.1060903@vulcan.xs4all.nl> Message-ID: <910f3581-eba2-49b1-89b4-655718ad396b@email.android.com> Johan Wevers wrote: >On 25-10-2013 1:46, Robert J. Hansen wrote: > >> Mostly zealotry. According to NIST, RSA-2048 is expected to be >secure >> for about the next 25 years. > >The authority of NIST is of course severely reduced since the Snowden >revelations and their own suspicious behaviour with the Dual EC PRNG. > >Further, if they expect it to be secure for only 25 years, that is >sufficient for people to upgrade if they expect to remain alive over 25 >years (although in this case it might not apply since the key is only >used for signatures and adding backdoors in a 25 year old OS will not >be >very usefull). Well, this assumes that you need 25 years of security. If your messages *must* remain uncrackable for that length of time, you may want to take many more measures to ensure the secrecy of what is being communicated, e.g. physical security, intranet mediated messages versus Internet mediated messages, etc. Cheers, --Paul -- PGP: 3DB6D884 From free10pro at gmail.com Sat Oct 26 06:16:26 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Fri, 25 Oct 2013 21:16:26 -0700 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <5269B14C.4020102@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> Message-ID: <526B421A.3060008@gmail.com> On 10/24/2013 04:46 PM, Robert J. Hansen wrote: >> Is this zealotry on the Debian front, or something to update in gnupg? > > Mostly zealotry. According to NIST, RSA-2048 is expected to be secure > for about the next 25 years. To add further to this, the U.S. military uses 2048 bit RSA keys for their Common Access Cards (CAC cards), which are used for system authentication and encrypted email. The certificates that users are issued are good for three years and then they issue a new CAC card to the user. The U.S. Department of Defense (DoD) has multiple root CAs, and I know at least one of them (if not all of them) uses a 2048 bit RSA key that is to be valid through 2029. I am not saying that any one should use 2048 bit RSA because the DoD uses it. It is just a data point. That being said, I am doubtful that classified discussions are being done over email. As far as I know, they use it for sensitive but unclassified information such as personally identifiable information like Social Security Numbers. 3DES + SHA1 + 2048 bit RSA is their preference for email. It does not need to be yours. Cheers, --Paul From beuc at beuc.net Sat Oct 26 11:35:25 2013 From: beuc at beuc.net (Sylvain) Date: Sat, 26 Oct 2013 11:35:25 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <1382660348.1296.62.camel@heisenberg.scientia.net> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> Message-ID: <20131026093525.GC19250@mail.beuc.net> Hi and thanks for your answers, Would it be a good idea to update the FAQ in this regard? http://www.gnupg.org/faq/GnuPG-FAQ.html#what-is-the-recommended-key-size -> "1024 bit for DSA signatures; even for plain Elgamal signatures." Also, On Fri, Oct 25, 2013 at 02:19:08AM +0200, Christoph Anton Mitterer wrote: > Some people may argue that 2048 is secure enough for many many years to > come. Similar things have been said for 1024 not so many years ago. > > And especially under the light of the NSA/friends scandal,... why using > less when you have no strong reasons to do so? Well I've heard that in security, more bits isn't necessarily more secure, depending on the algorithm. Plus, following this principle, why doesn't gnupg default to 4096 if there isn't any reason not to? I would suppose that if gnupg defaults to 2048, the devs have a good reason to. Cheers! Sylvain From oub at mat.ucm.es Sat Oct 26 12:02:53 2013 From: oub at mat.ucm.es (Uwe Brauer) Date: Sat, 26 Oct 2013 12:02:53 +0200 Subject: gpgsm and expired certificates Message-ID: <87r4b8ic36.fsf@mat.ucm.es> Hello I use gpgsm, via gnus+Xemacs and I have installed a free certificate from Comodo. This certificate expires in a couple of weeks and I have to apply for a new one. However I need the old one to read old messages. Can gpgsm deal with this situation? 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 wk at gnupg.org Sat Oct 26 14:13:15 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Oct 2013 14:13:15 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <20131026093525.GC19250@mail.beuc.net> (Sylvain's message of "Sat, 26 Oct 2013 11:35:25 +0200") References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> Message-ID: <87sivoxmas.fsf@vigenere.g10code.de> On Sat, 26 Oct 2013 11:35, beuc at beuc.net said: > Plus, following this principle, why doesn't gnupg default to 4096 if > there isn't any reason not to? I would suppose that if gnupg defaults 4k primary RSA keys increase the size of the signatures and thus make the keyrings longer and, worse, computing the web of trust takes much longer. Yeah, not on your high end desktop machine but on old laptops and my N900 phone. It also drains the battery faster. There is no benefit of overly large keys on average computers. After all the goal is not to have large key but to protect something. Now, if you want to protect something you need to think like the attacker - what will an attacker do to get the plaintext (or fake a signature)? Spend millions on breaking a few 2k keys (assuming this is at all possible within the next decade) or buy/develop/use a zero-day? Instead of discussing these numbers the time could be much better use to audit the used software (firmware, OS, libs, apps). Salam-Shalom, Werner p.s. I would even consider bugs like below more serious than protecting against break 2k RSA. commit a7a9cdcaaf3979baa18dad51e722882581349f45 Author: Werner Koch Date: Sat Sep 7 10:06:46 2013 +0200 Fix bug in _gcry_mpi_tdiv_q_2exp. * mpi/mpi-internal.h (MPN_COPY_INCR): Make it work. -- This bug has been with us since the version 0.0.0 of GnuPG. Fortunately it only affects an optimized code path which is rarely used in practice: If the shift size matches the size of a limb (i.e.. 32 or 64); this is is_prime in primegen.c. Over there the Rabin-Miller test may fail with a probability of 2^-31 (that is if the to be tested prime - 1 has the low 32 bits cleared). In practice the probability is even much less because we first do a Fermat test on the randomly generated candidates which sorts out the majority of composite numbers. The bug in MPN_COPY_INCR was found by Sven Bjorn. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Sat Oct 26 16:30:22 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Oct 2013 10:30:22 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526AE68E.1060903@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526AE68E.1060903@vulcan.xs4all.nl> Message-ID: <526BD1FE.1070404@sixdemonbag.org> On 10/25/2013 5:45 PM, Johan Wevers wrote: > The authority of NIST is of course severely reduced since the > Snowden revelations and their own suspicious behaviour with the Dual > EC PRNG. *To you* they're severely reduced. Please don't presume to make ex cathedra statements for the rest of the world. While I agree that NIST is certainly not looking good, I'm not going to go so far as to say their authority or credibility is "severely reduced." Further, this statement of NIST's is backed by RSA Data Security, which has issued recommendations that are in much the same line, and various other consortiums as well. > Further, if they expect it to be secure for only 25 years, that is > sufficient for people to upgrade if they expect to remain alive over > 25 years Not even intelligence agencies expect to keep things secret past 25 years. If you're doing something that must remain secret for more than 25 years, I would recommend thinking about whether you should be doing those things in the first place. From rjh at sixdemonbag.org Sat Oct 26 16:36:14 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Oct 2013 10:36:14 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526B421A.3060008@gmail.com> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526B421A.3060008@gmail.com> Message-ID: <526BD35E.5000602@sixdemonbag.org> On 10/26/2013 12:16 AM, Paul R. Ramer wrote: > I am not saying that any one should use 2048 bit RSA because the DoD > uses it. It is just a data point. That being said, I am doubtful that > classified discussions are being done over email. CAC is used for encrypted email, at least according to Wikipedia. Not having a CAC myself, I'm not in a position to know further. If people are interested, I'll ask a couple of CAC-carrying friends and see what they say. From mailinglisten at hauke-laging.de Sat Oct 26 18:16:32 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 26 Oct 2013 18:16:32 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526AE68E.1060903@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526AE68E.1060903@vulcan.xs4all.nl> Message-ID: <3010964.cdGcmZlhMs@inno.berlin.laging.de> Am Fr 25.10.2013, 23:45:50 schrieb Johan Wevers: > Further, if they expect it to be secure for only 25 years, This means that every single key is secure over that time. It means that after 25 years organizations with huge resources may be able to crack a *single* key in a lot of time (rather a year than a day). So even within the next 35 years THEY have to make a very small selection which keys they want to break as then there will be a few million 2048-bit keys around. And that requires that the law doesn't change within that time, forcing the agencies to delete most of the stored encrypted data. The US government is just realizing that their current approach causes costs beside those in the budget. And we have not even talked about the different security levels of keys. The default setting of gpg should be suitable for normal keys i.e. keys for everyday communication. If you need a high security key then you need to know a lot about IT security anyway because the keys are the strongest part of the system. Those who know how to do the rest right obviously know whether and how to increase the key size. Why should anyone 25+ years from now spend a huge amount of resources in order to read a tiny part of today's everyday communication (or a big part in 40 years)? That makes absolutely no sense. How do you want to explain that in a democracy, "hunting terrorists"? Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ 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 Sat Oct 26 21:11:44 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Oct 2013 21:11:44 +0200 Subject: gpgsm and expired certificates In-Reply-To: <87r4b8ic36.fsf@mat.ucm.es> (Uwe Brauer's message of "Sat, 26 Oct 2013 12:02:53 +0200") References: <87r4b8ic36.fsf@mat.ucm.es> Message-ID: <87k3gzyhhr.fsf@vigenere.g10code.de> On Sat, 26 Oct 2013 12:02, oub at mat.ucm.es said: > Can gpgsm deal with this situation? Sure. That is a very common situation. Although I am myself not using gpgsm for mail encryption, I use it to maintain all kind of X.509 certificates. FWIW, gpgsm passed several conformance tests with quite good results [1] and was recently approved for secret communication (at the Germany's entry level VS/NfD). Salam-Shalom, Werner [1] Watch out for Aegypten, which included GnuPG, in https://www.bsi.bund.de/DE/Themen/weitereThemen/VerwaltungsPKIVPKI/Interoperabilitaetstest/Testberichte/testberichte_node.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From beuc at beuc.net Sat Oct 26 21:40:09 2013 From: beuc at beuc.net (Sylvain) Date: Sat, 26 Oct 2013 21:40:09 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian [doc patch] In-Reply-To: <87sivoxmas.fsf@vigenere.g10code.de> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> Message-ID: <20131026194009.GD29314@mail.beuc.net> Hi Werner, On Sat, Oct 26, 2013 at 02:13:15PM +0200, Werner Koch wrote: > Instead of discussing these numbers the time could be much better use to > audit the used software (firmware, OS, libs, apps). Thanks for your answer. To foster spending less time on these discussions, how about this? :) --- faq.org.orig 2013-10-26 21:37:35.500209973 +0200 +++ faq.org 2013-10-26 21:37:25.340945491 +0200 @@ -244,22 +244,27 @@ :CUSTOM_ID: what-is-the-recommended-key-size :END: - 1024 bit for DSA signatures; even for plain Elgamal signatures. - This is sufficient as the size of the hash is probably the weakest - link if the key size is larger than 1024 bits. Encryption keys may - have greater sizes, but you should then check the fingerprint of - this key: + GnuPG comes with a default recommended preset, which 2048 bits + primary RSA key as of 2013. - : $ gpg --fingerprint + There are regularly discussions about using 4096 primary RSA keys. + Well, there is no benefit of overly large keys on average + computers. After all the goal is not to have large key but to + protect something. Now, if you want to protect something you need + to think like the attacker - what will an attacker do to get the + plaintext (or fake a signature)? Spend millions on breaking a few + 2k keys (assuming this is at all possible within the next decade) + or buy/develop/use a zero-day exploit? - As for the key algorithms, you should stick with the default (i.e., - DSA signature and Elgamal encryption). An Elgamal signing key has - the following disadvantages: the signature is larger, it is hard - to create such a key useful for signatures which can withstand some - real world attacks, you don't get any extra security compared to - DSA, and there might be compatibility problems with certain PGP - versions. It has only been introduced because at the time it was - not clear whether there was a patent on DSA. + Also, 4096 keys have a few inconveniences: they increase the size + of the signatures and thus make the keyrings longer and, worse, + computing the web of trust takes much longer - not on your high + end desktop machine but on old laptops, and phones where it drains + the battery faster. + + Instead of discussing these numbers the time could be much better + use to audit the used software (firmware, OS, libs, apps), which + often are the weak link of the security chain. ** Why does it sometimes take so long to create keys? :PROPERTIES: Cheers! Sylvain From oub at mat.ucm.es Sat Oct 26 22:03:37 2013 From: oub at mat.ucm.es (Uwe Brauer) Date: Sat, 26 Oct 2013 22:03:37 +0200 Subject: gpgsm and expired certificates References: <87r4b8ic36.fsf@mat.ucm.es> <87k3gzyhhr.fsf__27502.296298235$1382815337$gmane$org@vigenere.g10code.de> Message-ID: <87ppqriyue.fsf@mat.ucm.es> >> "Werner" == Werner Koch writes: > On Sat, 26 Oct 2013 12:02, oub at mat.ucm.es said: >> Can gpgsm deal with this situation? > Sure. That is a very common situation. > Although I am myself not using gpgsm for mail encryption, I use it to > maintain all kind of X.509 certificates. FWIW, gpgsm passed several > conformance tests with quite good results [1] and was recently approved > for secret communication (at the Germany's entry level VS/NfD). Good, so if I understand that correctly once I have the new certificate then I only have to import it into gpgsm and gpgsm will know by the date of the certificate which certificate to use for which message? - old for old messages - the new for the new messages 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 rjh at sixdemonbag.org Sun Oct 27 00:29:26 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Oct 2013 18:29:26 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian [doc patch] In-Reply-To: <20131026194009.GD29314@mail.beuc.net> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <20131026194009.GD29314@mail.beuc.net> Message-ID: <526C4246.8010505@sixdemonbag.org> On 10/26/2013 3:40 PM, Sylvain wrote: > Thanks for your answer. To foster spending less time on these > discussions, how about this? :) Hi! I'm the quasi-official FAQ maintainer. You can read the current text of the FAQ at: https://github.com/rjhansen/gpgfaq/blob/master/gpgfaq.xml Excerpting from it: Q: How large should my key be? A: The overwhelming majority of users will be well-served by generating 2048-bit RSA keys. This is the default behavior for GnuPG. Although we appreciate your patch for the FAQ, it would probably be better to submit a patch against the in-development FAQ as opposed to the old one, which is no longer being maintained. :) From calestyo at scientia.net Sat Oct 26 23:44:38 2013 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 26 Oct 2013 23:44:38 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <87sivoxmas.fsf@vigenere.g10code.de> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> Message-ID: <1382823878.29041.23.camel@heisenberg.scientia.net> On Sat, 2013-10-26 at 14:13 +0200, Werner Koch wrote: > Now, if > you want to protect something you need to think like the attacker - what > will an attacker do to get the plaintext (or fake a signature)? Spend > millions on breaking a few 2k keys (assuming this is at all possible > within the next decade) or buy/develop/use a zero-day? Well with that "argument" you can always defeat any crypto... a "real attacker" will not care whether you use 786 bit RSA keys or 16k bit keys... he comes for you and tortures you until you happily give him anything he wants... Cheers, Chris. From rjh at sixdemonbag.org Sun Oct 27 01:09:08 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Oct 2013 19:09:08 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <1382823878.29041.23.camel@heisenberg.scientia.net> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <1382823878.29041.23.camel@heisenberg.scientia.net> Message-ID: <526C4B94.6090301@sixdemonbag.org> On 10/26/2013 5:44 PM, Christoph Anton Mitterer wrote: > Well with that "argument" you can always defeat any crypto... a "real > attacker" will not care whether you use 786 bit RSA keys or 16k bit > keys... he comes for you and tortures you until you happily give him > anything he wants... The name of the game is economics. How much is the secret worth? If it's worth $50,000 of computer equipment and cryptanalysis, then it's also worth a $50,000 bribe, a $50,000 payment to a professional thief to break in and plant keyloggers, $50,000 in hookers and blow, $50,000 of... Note that I'm not disagreeing with Christoph. I'm only pointing out the world is a big place and there are a *lot* of ways to acquire secrets, not just "break the crypto" and "break the kneecap". From free10pro at gmail.com Sun Oct 27 04:52:52 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Sat, 26 Oct 2013 20:52:52 -0700 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526BD35E.5000602@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526B421A.3060008@gmail.com> <526BD35E.5000602@sixdemonbag.org> Message-ID: <526C8E14.6050706@gmail.com> On 10/26/2013 07:36 AM, Robert J. Hansen wrote: > On 10/26/2013 12:16 AM, Paul R. Ramer wrote: >> I am not saying that any one should use 2048 bit RSA because the DoD >> uses it. It is just a data point. That being said, I am doubtful that >> classified discussions are being done over email. > > CAC is used for encrypted email, at least according to Wikipedia. Not > having a CAC myself, I'm not in a position to know further. If people > are interested, I'll ask a couple of CAC-carrying friends and see what > they say. That is correct. It is used for encrypted email, but it does not mean that is is used to secure classified discussions or transmit classified documents. The CAC serves more as an identity card and authentication token more than anything else in my experience. If the CAC card is used to encrypt anthing beyond unclassified, for oficial use only, or PII-sensitive (containing personally identifiable information) documents and information is unknown to me. Even if it were, knowledge of the fact would likely be restricted. But do ask. I would like to hear what other people's experiences have been. :-) Cheers, --Paul From tapio.sokura at iki.fi Sun Oct 27 07:12:52 2013 From: tapio.sokura at iki.fi (Tapio Sokura) Date: Sun, 27 Oct 2013 08:12:52 +0200 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526C4B94.6090301@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <1382823878.29041.23.camel@heisenberg.scientia.net> <526C4B94.6090301@sixdemonbag.org> Message-ID: <526CAEE4.3060806@iki.fi> On 27.10.2013 2:09, Robert J. Hansen wrote: > The name of the game is economics. How much is the secret worth? If > it's worth $50,000 of computer equipment and cryptanalysis, then it's > also worth a $50,000 bribe, a $50,000 payment to a professional thief to > break in and plant keyloggers, $50,000 in hookers and blow, $50,000 of... Often there is also value in breaking crypto so that the targeted crypto users don't know it has been broken and thus continue to use it (the algorithm and/or the specific key). If a big government organization (take your pick) had broken algorithm/keysize xyz, would they tell anybody? Tapio From rjh at sixdemonbag.org Sun Oct 27 07:42:31 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Oct 2013 02:42:31 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526CAEE4.3060806@iki.fi> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <1382823878.29041.23.camel@heisenberg.scientia.net> <526C4B94.6090301@sixdemonbag.org> <526CAEE4.3060806@iki.fi> Message-ID: <526CB5D7.1000802@sixdemonbag.org> > Often there is also value in breaking crypto so that the targeted > crypto users don't know it has been broken and thus continue to use > it (the algorithm and/or the specific key). If a big government > organization (take your pick) had broken algorithm/keysize xyz, would > they tell anybody? Hard to say. Quite possibly, yes, they'd tell the entire world. Take AES as an example: if AES had a serious flaw that could be exploited to recover ciphertext, it's quite possible the people who discovered it would decide the risk to the world's financial systems from keeping it secret far outweighed any benefit that might be had. As a real-world example, look at the history of SHA. The original SHA (just called SHA, although sometimes [inaccurately] called SHA-0) was designed by the NSA and published as a government standard in 1993. In 1995 the NSA announced there were flaws in SHA and issued a new standard, SHA-1, that addressed these problems. The NSA never went public with the precise vulnerability in SHA that caused them to develop and release SHA-1, but they were quite open and public about SHA being insecure and needing to be replaced as soon as possible. From wk at gnupg.org Sun Oct 27 08:07:41 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Oct 2013 08:07:41 +0100 Subject: gpgsm and expired certificates In-Reply-To: <87ppqriyue.fsf@mat.ucm.es> (Uwe Brauer's message of "Sat, 26 Oct 2013 22:03:37 +0200") References: <87r4b8ic36.fsf@mat.ucm.es> <87k3gzyhhr.fsf__27502.296298235$1382815337$gmane$org@vigenere.g10code.de> <87ppqriyue.fsf@mat.ucm.es> Message-ID: <87fvrnxkci.fsf@vigenere.g10code.de> On Sat, 26 Oct 2013 22:03, oub at mat.ucm.es said: > know by the date of the certificate which certificate to use for which > message? > > - old for old messages Note, that there is no need for a certificate for decryption - only the private key is required. The certificate is only used to show some meta information. > - the new for the new messages Expired certificates are not used and thus a now valid one will be used. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun Oct 27 08:09:59 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Oct 2013 08:09:59 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian [doc patch] In-Reply-To: <526C4246.8010505@sixdemonbag.org> (Robert J. Hansen's message of "Sat, 26 Oct 2013 18:29:26 -0400") References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <20131026194009.GD29314@mail.beuc.net> <526C4246.8010505@sixdemonbag.org> Message-ID: <87bo2bxk8o.fsf@vigenere.g10code.de> On Sun, 27 Oct 2013 00:29, rjh at sixdemonbag.org said: > Hi! I'm the quasi-official FAQ maintainer. You can read the current > text of the FAQ at: While we are at it. What about making it the official one, i.e. change the licenses to CC-by-ca/GPL? Given the importance of a FAQ I think we should not longer delay it - even if old links to certain questions won't any longer work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From beuc at beuc.net Sun Oct 27 08:26:43 2013 From: beuc at beuc.net (Sylvain) Date: Sun, 27 Oct 2013 08:26:43 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian [doc patch] In-Reply-To: <526C4246.8010505@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <20131026194009.GD29314@mail.beuc.net> <526C4246.8010505@sixdemonbag.org> Message-ID: <20131027072643.GA8236@mail.beuc.net> Hi, On Sat, Oct 26, 2013 at 06:29:26PM -0400, Robert J. Hansen wrote: > On 10/26/2013 3:40 PM, Sylvain wrote: > > Thanks for your answer. To foster spending less time on these > > discussions, how about this? :) > > Hi! I'm the quasi-official FAQ maintainer. You can read the current > text of the FAQ at: > > https://github.com/rjhansen/gpgfaq/blob/master/gpgfaq.xml > > Excerpting from it: > > Q: How large should my key be? > A: The overwhelming majority of users will be well-served > by generating 2048-bit RSA keys. This is the default > behavior for GnuPG. > > Although we appreciate your patch for the FAQ, it would probably be > better to submit a patch against the in-development FAQ as opposed to > the old one, which is no longer being maintained. :) Since it's the 3rd or 4th format of the FAQ that I come accross in the past 24h, I'm just giving the full text, adapt it however you like :) GnuPG comes with a default recommended preset, which 2048 bits primary RSA key as of 2013. There are regularly discussions about using 4096 primary RSA keys. Well, there is no benefit of overly large keys on average computers. After all the goal is not to have large key but to protect something. Now, if you want to protect something you need to think like the attacker - what will an attacker do to get the plaintext (or fake a signature)? Spend millions on breaking a few 2k keys (assuming this is at all possible within the next decade) or buy/develop/use a zero-day exploit? Also, 4096 keys have a few inconveniences: they increase the size of the signatures and thus make the keyrings longer and, worse, computing the web of trust takes much longer - not on your high end desktop machine but on old laptops, and phones where it drains the battery faster. Instead of discussing these numbers the time could be much better use to audit the used software (firmware, OS, libs, apps), which often are the weak link of the security chain. Cheers! Sylvain From oub at mat.ucm.es Sun Oct 27 09:53:00 2013 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 27 Oct 2013 09:53:00 +0100 Subject: gpgsm and expired certificates References: <87r4b8ic36.fsf@mat.ucm.es> <87k3gzyhhr.fsf__27502.296298235$1382815337$gmane$org@vigenere.g10code.de> <87ppqriyue.fsf@mat.ucm.es> <87fvrnxkci.fsf__38096.124205231$1382858228$gmane$org@vigenere.g10code.de> Message-ID: <87li1fhz83.fsf@mat.ucm.es> >> "Werner" == Werner Koch writes: > On Sat, 26 Oct 2013 22:03, oub at mat.ucm.es said: >> know by the date of the certificate which certificate to use for which >> message? >> >> - old for old messages > Note, that there is no need for a certificate for decryption - only the > private key is required. The certificate is only used to show some meta > information. Now I am confused. Most likely my knowledge of certificates is not correct. (I played around with openssl to generate my own, useless, certificates). I thought a certificate consists of a key pair (private/public) which is signed by the Authority (here comodo). When I apply for a certificate, the keypair is generated by the crypto module of the browser and then signed. So I thought when I apply for a new certificate a new key pair is generated which gets signed again. But your comment above seems to indicate that the old pair gets a new signature. Is this correct? But what if I apply with a different browser I applied the last time. 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 pete at heypete.com Sun Oct 27 10:23:28 2013 From: pete at heypete.com (Pete Stephenson) Date: Sun, 27 Oct 2013 10:23:28 +0100 Subject: gpgsm and expired certificates In-Reply-To: <87li1fhz83.fsf@mat.ucm.es> References: <87r4b8ic36.fsf@mat.ucm.es> <87k3gzyhhr.fsf__27502.296298235$1382815337$gmane$org@vigenere.g10code.de> <87ppqriyue.fsf@mat.ucm.es> <87fvrnxkci.fsf__38096.124205231$1382858228$gmane$org@vigenere.g10code.de> <87li1fhz83.fsf@mat.ucm.es> Message-ID: On Sun, Oct 27, 2013 at 9:53 AM, Uwe Brauer wrote: >>> "Werner" == Werner Koch writes: > > > On Sat, 26 Oct 2013 22:03, oub at mat.ucm.es said: > >> know by the date of the certificate which certificate to use for which > >> message? > >> > >> - old for old messages > > > Note, that there is no need for a certificate for decryption - only the > > private key is required. The certificate is only used to show some meta > > information. > > Now I am confused. Most likely my knowledge of certificates is not > correct. (I played around with openssl to generate my own, useless, > certificates). > > I thought a certificate consists of a key pair (private/public) which is > signed by the Authority (here comodo). Mostly correct. All that is needed to encrypt/decrypt/sign/verify messages is the public/private keys themselves. The certificate is a signed, structured format that binds a particular public key to an identity (be it an email address, a name, a website, etc.). The certificate is for public consumption: Comodo is asserting to the world that this particular public key (and it's corresponding private key, which only you know) belongs to you (or your website, email, etc.). On your end, all you need is the private key to decrypt messages encrypted to your public key. You don't need a certificate to decrypt messages that had already been encrypted to that public key -- a certificate may expire at a certain time, but the private key has no baked-in expiration date. > When I apply for a certificate, the keypair is generated by the crypto > module of the browser and then signed. Correct. > So I thought when I apply for a new certificate a new key pair > is generated which gets signed again. Correct, though it is possible (but usually recommend against) to create a new certificate using the same private keypair as before. In general, you should create a new keypair when applying for a new certificate. > But your comment above seems to indicate that the old pair gets a new > signature. Is this correct? But what if I apply with a different > browser I applied the last time. I interpreted Werner's comment to mean "In order to decrypt messages encrypted to you, you only need a private key. You don't need a valid certificate to decrypt old messages that were encrypted to a now-expired certificate." If you generate a new keypair for the new certificate (which is probably a good idea) then gpgsm (and presumably any other certificate-using software) will figure out what private key will be needed to decrypt a particular message and, so long as you still have the private key on your system, will use it as needed even if the corresponding certificate has expired. Cheers! -Pete -- Pete Stephenson From oub at mat.ucm.es Sun Oct 27 11:01:39 2013 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 27 Oct 2013 11:01:39 +0100 Subject: gpgsm and expired certificates References: <87r4b8ic36.fsf@mat.ucm.es> <87k3gzyhhr.fsf__27502.296298235$1382815337$gmane$org@vigenere.g10code.de> <87ppqriyue.fsf@mat.ucm.es> <87fvrnxkci.fsf__38096.124205231$1382858228$gmane$org@vigenere.g10code.de> <87li1fhz83.fsf@mat.ucm.es> Message-ID: <87zjpvghh8.fsf@mat.ucm.es> > If you generate a new keypair for the new certificate (which is > probably a good idea) then gpgsm (and presumably any other > certificate-using software) will figure out what private key will be > needed to decrypt a particular message and, so long as you still have > the private key on your system, will use it as needed even if the > corresponding certificate has expired. So gpgsm (and others) will also figure out which private key to use for signing: that is the new one, once the old certificate is expired? Which means in the case of smime, also to embedd the corresponding new public key in the signature. 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 pete at heypete.com Sun Oct 27 11:13:22 2013 From: pete at heypete.com (Pete Stephenson) Date: Sun, 27 Oct 2013 11:13:22 +0100 Subject: gpgsm and expired certificates In-Reply-To: <87zjpvghh8.fsf@mat.ucm.es> References: <87r4b8ic36.fsf@mat.ucm.es> <87k3gzyhhr.fsf__27502.296298235$1382815337$gmane$org@vigenere.g10code.de> <87ppqriyue.fsf@mat.ucm.es> <87fvrnxkci.fsf__38096.124205231$1382858228$gmane$org@vigenere.g10code.de> <87li1fhz83.fsf@mat.ucm.es> <87zjpvghh8.fsf@mat.ucm.es> Message-ID: On Sun, Oct 27, 2013 at 11:01 AM, Uwe Brauer wrote: > > > If you generate a new keypair for the new certificate (which is > > probably a good idea) then gpgsm (and presumably any other > > certificate-using software) will figure out what private key will be > > needed to decrypt a particular message and, so long as you still have > > the private key on your system, will use it as needed even if the > > corresponding certificate has expired. > > So gpgsm (and others) will also figure out which private key to use for > signing: that is the new one, once the old certificate is expired? > > Which means in the case of smime, also to embedd the corresponding > new public key in the signature. I can't speak specifically for gpgsm, as I only use GPG with OpenPGP keys and not x.509 certs, but I would venture that the answer to your question is "yes, gpgsm will select the correct private key for signing" as that's standard behavior for such software. Werner or others could answer authoritatively. -- Pete Stephenson From wk at gnupg.org Sun Oct 27 11:13:32 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Oct 2013 11:13:32 +0100 Subject: gpgsm and expired certificates In-Reply-To: (Pete Stephenson's message of "Sun, 27 Oct 2013 10:23:28 +0100") References: <87r4b8ic36.fsf@mat.ucm.es> <87k3gzyhhr.fsf__27502.296298235$1382815337$gmane$org@vigenere.g10code.de> <87ppqriyue.fsf@mat.ucm.es> <87fvrnxkci.fsf__38096.124205231$1382858228$gmane$org@vigenere.g10code.de> <87li1fhz83.fsf@mat.ucm.es> Message-ID: <871u37xbqr.fsf@vigenere.g10code.de> On Sun, 27 Oct 2013 10:23, pete at heypete.com said: > Correct, though it is possible (but usually recommend against) to > create a new certificate using the same private keypair as before. In The business model of most CAs is to sell you a subscription by setting the expiration time very low so that they can ask after a year for another fee to create a new certificate. Here it does not make sense to create a new private key every year. GnuPG basically does the same by allowing you to prolong the expiration time. > I interpreted Werner's comment to mean "In order to decrypt messages > encrypted to you, you only need a private key. You don't need a valid > certificate to decrypt old messages that were encrypted to a > now-expired certificate." Correct. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From johanw at vulcan.xs4all.nl Sun Oct 27 12:15:19 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 27 Oct 2013 12:15:19 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <87sivoxmas.fsf@vigenere.g10code.de> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> Message-ID: <526CF5C7.3090809@vulcan.xs4all.nl> On 26-10-2013 14:13, Werner Koch wrote: > 4k primary RSA keys increase the size of the signatures and thus make > the keyrings longer and, worse, computing the web of trust takes much > longer. Yes, which leads to another question: why has the default switched from ElGamal/DSA to RSA after the RSA patent expired? Does RSA have any advantages over ElGamal/DSA? The only one I can think of is less dependence of a correctly functioning RNG. -- Met vriendelijke groet / With kind regards, Johan Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From peter at digitalbrains.com Sun Oct 27 12:30:34 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Oct 2013 12:30:34 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526CF5C7.3090809@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> Message-ID: <526CF95A.9070505@digitalbrains.com> On 27/10/13 12:15, Johan Wevers wrote: > The only one I can think of is less dependence of a correctly functioning > RNG. I think this is a very important one, as we've seen with the debacle with OpenSSL in Debian where DSA keys were compromised even when just used to create a signature[1]. But I can think of another one: much more hardware support. Both smartcards and crypto-accelerators either in a general purpose CPU or as a module in a computer. HTH, Peter. [1] -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun Oct 27 12:34:24 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Oct 2013 12:34:24 +0100 Subject: 2048 or 4096 for new =?UTF-8?Q?keys=3F=20aka=20defaults=20vs?= =?UTF-8?Q?=2E=20Debian?= In-Reply-To: <526CF95A.9070505@digitalbrains.com> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> <526CF95A.9070505@digitalbrains.com> Message-ID: On 2013-10-27 12:30, Peter Lebbing wrote: > I think this is a very important one Hmmm you press Send and you think: I might have overstated that. Where's unsend? I think it's a real advantage of RSA. I don't think it's a very important one, because other broken parts can compromise stuff just as well. Your stuff shouldn't be broken. Broken is bad, m'kay? 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 johanw at vulcan.xs4all.nl Sun Oct 27 12:53:22 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 27 Oct 2013 12:53:22 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526CF95A.9070505@digitalbrains.com> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> <526CF95A.9070505@digitalbrains.com> Message-ID: <526CFEB2.7080800@vulcan.xs4all.nl> On 27-10-2013 12:30, Peter Lebbing wrote: > But I can think of another one: much more hardware support. Both smartcards and > crypto-accelerators either in a general purpose CPU or as a module in a computer. I had not thought of the crypto cards, but the only crypto hardware acceleration in general purpose CPU's I know of are the AES functions in the newer intel CPU's, which are gladly used by TrueCrypt. And I see the advantage in using that in TrueCrypt, which is constantly busy. But the few encrypted messages people get via email can easily be handled by a much slower CPU than I have now. My reading speed is the limiting factor there, not the computers decrypting speed. -- Met vriendelijke groet / With kind regards, Johan Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From peter at digitalbrains.com Sun Oct 27 12:59:26 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Oct 2013 12:59:26 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526CFEB2.7080800@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> <526CF95A.9070505@digitalbrains.com> <526CFEB2.7080800@vulcan.xs4all.nl> Message-ID: <526D001E.4000505@digitalbrains.com> On 27/10/13 12:53, Johan Wevers wrote: > But the few encrypted messages people get via email can easily be handled by > a much slower CPU than I have now. My reading speed is the limiting factor > there, not the computers decrypting speed. I was thinking of automated systems doing verifications, not end users. But the smartcard thing is the biggest advantage of hardware support. 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 Oct 27 13:04:07 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Oct 2013 13:04:07 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526CF5C7.3090809@vulcan.xs4all.nl> (Johan Wevers's message of "Sun, 27 Oct 2013 12:15:19 +0100") References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> Message-ID: <87wqkyx6mg.fsf@vigenere.g10code.de> On Sun, 27 Oct 2013 12:15, johanw at vulcan.xs4all.nl said: > ElGamal/DSA to RSA after the RSA patent expired? Does RSA have any > advantages over ElGamal/DSA? The only one I can think of is less It is in general faster and there are OpenPGP implementations which only support RSA (despite that the standard requires DSA and Elgamal). The drawback is that RSA signatures are larger than those made with DSA. IIRC, we discussed that back then and you may find something in the mailing list archives. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From peter at digitalbrains.com Sun Oct 27 13:11:16 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Oct 2013 13:11:16 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526CF5C7.3090809@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> Message-ID: <526D02E4.8020504@digitalbrains.com> > Yes, which leads to another question: why has the default switched from > ElGamal/DSA to RSA after the RSA patent expired? Okay, first of all, I'm doing something wrong here, I should group my responses and think a little longer about it. This is mail, not chat. My apologies. I think RSA has seen more cryptanalysis than DSA and ElGamal, which is in favour of RSA. Also, RSA allows hashes other than SHA-1, whereas with DSA you need to switch to DSA2. So to get support for other hashes, a switch would be necessary anyway, and less applications supported DSA2 at the time I believe. A signature by a 2048-bit DSA key is twice as large as a signature by a 2048-bit RSA key, but offers the same order of strength. I think there were discussions about this on the mailing list around the time of the switch as well, so you could browse through that. Other than that, obviously only the people who made the switch can tell you exactly why they did that. My guess is, Werner commented on that when there were discussions here around the time GnuPG switched from DSA/ElGamal to RSA. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Sun Oct 27 13:20:26 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Oct 2013 13:20:26 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D02E4.8020504@digitalbrains.com> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> <526D02E4.8020504@digitalbrains.com> Message-ID: <526D050A.7090509@digitalbrains.com> On 27/10/13 13:11, Peter Lebbing wrote: > A signature by a 2048-bit DSA key is twice as large as a signature by a 2048-bit > RSA key, but offers the same order of strength. Oops. I just read Werners message, and I had it reversed :). Taking a look at RFC 4880, I see that a 2048-bit key has a 256-bit parameter q, and the signature is two values mod q, so 512 bits. By the way, q limits the hash size. 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 johanw at vulcan.xs4all.nl Sun Oct 27 13:21:23 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 27 Oct 2013 13:21:23 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D02E4.8020504@digitalbrains.com> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> <526D02E4.8020504@digitalbrains.com> Message-ID: <526D0543.3010407@vulcan.xs4all.nl> On 27-10-2013 13:11, Peter Lebbing wrote: > I think RSA has seen more cryptanalysis than DSA and ElGamal, which is in favour > of RSA. Well, both are not broken after substantial research. Further, a break of ElGamal would also break RSA but not the other way around. The rest of the arguments are only centered about signatures (even the RNG argument is about signatures). Considering my personal use case, where signing messages is not very important but encryption is and since I don't have a keycard, I chose to use ElGamal for my day to day key. Which makes me think, is it possible to generate a 2048 bit RSA signing key combined with a 3072 or 4096 bit encryption key? -- Met vriendelijke groet / With kind regards, Johan Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From peter at digitalbrains.com Sun Oct 27 13:32:12 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Oct 2013 13:32:12 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D0543.3010407@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> <526D02E4.8020504@digitalbrains.com> <526D0543.3010407@vulcan.xs4all.nl> Message-ID: <526D07CC.8080203@digitalbrains.com> On 27/10/13 13:21, Johan Wevers wrote: > Which makes me think, is it possible to generate a 2048 bit RSA signing > key combined with a 3072 or 4096 bit encryption key? Yes, although I don't think it makes sense to create an X-bit primary key with a Y-bit subkey if X is smaller than Y as the attacker can "simply" crack the primary key and attach a new subkey which will be preferred because it is newer. Optionally he can revoke the old encryption subkey. But the following layout is sensible on some level: 3072-bit RSA primary for certification (C) 2048-bit RSA subkey for data signatures (S) 3072-bit RSA subkey for encryption (E) Note that I'm not going into the discussion whether any protection beyond 2048 is sensible or whether it is already impossible to crack an X-bit primary key for useful X's. If signatures aren't that important to you anyway, you can wonder if it is useful to spend time on making it more efficient by lowering the length. 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 expires2013 at ymail.com Sun Oct 27 15:04:25 2013 From: expires2013 at ymail.com (MFPA) Date: Sun, 27 Oct 2013 14:04:25 +0000 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526CB5D7.1000802@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <1382823878.29041.23.camel@heisenberg.scientia.net> <526C4B94.6090301@sixdemonbag.org> <526CAEE4.3060806@iki.fi> <526CB5D7.1000802@sixdemonbag.org> Message-ID: <1489452037.20131027140425@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 27 October 2013 at 6:42:31 AM, in , Robert J. Hansen wrote: > The NSA never went public with the precise > vulnerability in SHA that caused them to develop and > release SHA-1, but they were quite open and public > about SHA being insecure and needing to be replaced as > soon as possible. Which raises the question in my mind: was SHA really flawed, or was it advantageous to NSA's purposes to have people use SHA-1 instead? - -- Best regards MFPA mailto:expires2013 at ymail.com When it comes to humility, I'm the greatest. -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlJtHXFXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pHnID/24t3djRhgG9pu/8jVkDw+noV7ePOohzjNnx NM0r3Aj0uKUBQn6/5cCvfTzUHh7CB942wmeXuE7tAV5nUsRzQ1yGZxRCKcXTBPsO +tF00uK05ja2PWk4HzXbtrrdniOKipbgt3wQVqNFxbWRYevkdBJJlj3cILpptg0+ KW83g2dG =WXTB -----END PGP SIGNATURE----- From expires2013 at ymail.com Sun Oct 27 15:17:13 2013 From: expires2013 at ymail.com (MFPA) Date: Sun, 27 Oct 2013 14:17:13 +0000 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <3010964.cdGcmZlhMs@inno.berlin.laging.de> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526AE68E.1060903@vulcan.xs4all.nl> <3010964.cdGcmZlhMs@inno.berlin.laging.de> Message-ID: <619384800.20131027141713@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 26 October 2013 at 4:16:32 PM, in , Hauke Laging wrote: > Why should anyone 25+ years from now spend a huge > amount of resources in order to read a tiny part of > today's everyday communication (or a big part in 40 > years)? That makes absolutely no sense. How do you want > to explain that in a democracy, "hunting terrorists"? Well, "hunting terrorists" is the excuse for an awful lot of surveillance and snooping by the authorities. It is also the excuse for inconveniencing the travelling public at airports by enforcing their participation in security theatre. - -- Best regards MFPA mailto:expires2013 at ymail.com He's an environmentalist - his arguments are 100% recycled -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlJtIG1XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5p5pIEAKXYbkCRUuY5LkGBow9rC/rTjDHJGHrEvuR/ nYY5aWARMZ05tblqmLLS9bGAYmJscqB1j4FaxsYTbVH/FYV3xDOsCBDi7DVH35iI 6i/CChi/dpYy3yecoQEp1BLECg2zfT+FkAafJYvqG0n9jq5GgSy1dUe0AsH+dk/z HS55eUyO =I993 -----END PGP SIGNATURE----- From expires2013 at ymail.com Sun Oct 27 15:41:11 2013 From: expires2013 at ymail.com (MFPA) Date: Sun, 27 Oct 2013 14:41:11 +0000 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <910f3581-eba2-49b1-89b4-655718ad396b@email.android.com> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526AE68E.1060903@vulcan.xs4all.nl> <910f3581-eba2-49b1-89b4-655718ad396b@email.android.com> Message-ID: <1921308083.20131027144111@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 26 October 2013 at 12:39:58 AM, in , Paul R. Ramer wrote: > Well, this assumes that you need 25 years of security. > If your messages *must* remain uncrackable for that > length of time, you may want to take many more measures > to ensure the secrecy of what is being communicated, > e.g. physical security, intranet mediated messages > versus Internet mediated messages, etc. Couldn't a cryptographically broken algorithm also raise the problem of forged digital signatures? - -- Best regards MFPA mailto:expires2013 at ymail.com Confusion is always the most honest response -----BEGIN PGP SIGNATURE----- iPQEAQEKAF4FAlJtJhFXFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0 N0VDQTAzAAoJEKipC46tDG5pfhID/RxYUopuYpvqIpwYZpXsR12WUshjqFFzn1ry Z7tL5S43X3gTULqiQnnhYbepaB0qcdueEAkZt0jAgNu8Qw8oYrfhefgLLU95ufAX AiE09CtNnHLw3z6rjOv8k00T8naD+wbetVtwC+7Dm8ltwpn02Ls7uOk9OssHGPTD jNL0UTXG =sAE6 -----END PGP SIGNATURE----- From oub at mat.ucm.es Sun Oct 27 15:46:05 2013 From: oub at mat.ucm.es (Uwe Brauer) Date: Sun, 27 Oct 2013 15:46:05 +0100 Subject: gpgsm and expired certificates References: <87r4b8ic36.fsf@mat.ucm.es> <87k3gzyhhr.fsf__27502.296298235$1382815337$gmane$org@vigenere.g10code.de> <87ppqriyue.fsf@mat.ucm.es> <87fvrnxkci.fsf__38096.124205231$1382858228$gmane$org@vigenere.g10code.de> <87li1fhz83.fsf@mat.ucm.es> <871u37xbqr.fsf__23314.7300001749$1382869296$gmane$org@vigenere.g10code.de> Message-ID: <8761si4vrm.fsf@mat.ucm.es> >> "Werner" == Werner Koch writes: > On Sun, 27 Oct 2013 10:23, pete at heypete.com said: >> Correct, though it is possible (but usually recommend against) to >> create a new certificate using the same private keypair as before. In > The business model of most CAs is to sell you a subscription by > setting the expiration time very low so that they can ask after a > year for another fee to create a new certificate. Here it does not > make sense to create a new private key every year. Well comodo is free (still) and to prolong the certificate seems free to for the moment, but I agree I would prefer a government based organisation which provides this service to its citizen (especially because of all which was lately revealed about the NSA) > GnuPG basically does the same by allowing you to prolong the expiration > time. I don't want to enter a flame war here and in principle I'd prefer gpg over smime but in reality I have to use smime, because - it is implemented in almost all MUA while gpg is not[1] - it is so much easier to install for the people I communicate with than gpg. I recall that I tried to convince gpg and after some hours he almost yelled at me, while he was able to set up smime in 5 minutes. The reasons for this are the following. - As I said smime is already installed in almost all MUA, so no need to install gpg and to install a plugin for the MUA - the user does not have to generate a keypair. Well this is not entirely true, as we mentioned earlier, but the user applies for a certificate picks it up and he is set. - the user does not have to exchange public keys, he just sends a signed message which includes his public key. So if the big MUAS and not only thunderbird, but at least outlook apple mail, and iOS mail, would - support gpg natively - when use gpg in the mailreader for the first time, it would silently generate a key pair - when sending a signed message it would always embed the public key in the signature Then a think gpg would be as easy to use as smime, but till then.... Uwe Brauer Footnotes: [1] I tried to use gpg on a non jailbroken iPhone and it is honestly a hassle. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5556 bytes Desc: not available URL: From mailinglisten at hauke-laging.de Sun Oct 27 15:54:49 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 27 Oct 2013 15:54:49 +0100 Subject: thread links in the FAQ Message-ID: <4477893.ZfWqo8gBCP@inno.berlin.laging.de> The two curerent discussions ? one about the FAQ, the other one with "we discussed that back then" statements ? make me guess whether it makes sense to link such threads in the FAQ. BTW: Where is the FAQ? I hope this question does not seem too stupid... The one one gnupg.org calls itself outdated. Some search engine pointed me at the mailing list archive where http://keyservers.org/~rjh/gnupgfaq.xhtml is mentioned (2012) but that does not load here. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ 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 gnupg at oneiroi.net Sun Oct 27 17:47:44 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sun, 27 Oct 2013 17:47:44 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <87sivoxmas.fsf@vigenere.g10code.de> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> Message-ID: <526D43B0.9090103@oneiroi.net> Hi, On 10/26/2013 02:13 PM, Werner Koch wrote: > On Sat, 26 Oct 2013 11:35, beuc at beuc.net said: > >> Plus, following this principle, why doesn't gnupg default to 4096 if >> there isn't any reason not to? I would suppose that if gnupg defaults > > 4k primary RSA keys increase the size of the signatures and thus make > the keyrings longer and, worse, computing the web of trust takes much > longer. Yeah, not on your high end desktop machine but on old laptops > and my N900 phone. It also drains the battery faster. Numbers please? Or are you talking about personal/subjective impressions? Seems to be that one of the main ideas behind modern consumer computing is to address increasing need of processing capability and storage space (despite hype surrounding cloud products). Software is growing and is becoming more complicated, less care and effort is given to manual craftsmanship in this field, higher level languages and frameworks are more common. All this comes with a price of increased processing power requirement and most of the hardware vendors are doing really good here (really happily). Also making an imperative from supporting ancient and legacy devices (and I'm not saying N900 is ancient) is somehow controversial. > There is no benefit of overly large keys on average computers. After > all the goal is not to have large key but to protect something. Now, if > you want to protect something you need to think like the attacker - what > will an attacker do to get the plaintext (or fake a signature)? Spend > millions on breaking a few 2k keys (assuming this is at all possible > within the next decade) or buy/develop/use a zero-day? On the other hand, one of the conclusions that Mr Schneier presented was that in case of doubt increasing length of the key is easy and nice approach. So looks like definition of "overly large" could be somehow subjective. > Instead of discussing these numbers the time could be much better use to > audit the used software (firmware, OS, libs, apps). I would say it would be good to do that in addition/in parallel, not instead. Cheers, Filip From gnupg at oneiroi.net Sun Oct 27 18:00:58 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sun, 27 Oct 2013 18:00:58 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D07CC.8080203@digitalbrains.com> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> <526D02E4.8020504@digitalbrains.com> <526D0543.3010407@vulcan.xs4all.nl> <526D07CC.8080203@digitalbrains.com> Message-ID: <526D46CA.7010309@oneiroi.net> On 10/27/2013 01:32 PM, Peter Lebbing wrote: > (...) > But the following layout is sensible on some level: Which more or less means exactly nothing. > 3072-bit RSA primary for certification (C) > 2048-bit RSA subkey for data signatures (S) > 3072-bit RSA subkey for encryption (E) > > (...) Cheers, Filip From rjh at sixdemonbag.org Sun Oct 27 18:13:29 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Oct 2013 13:13:29 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526CF5C7.3090809@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> Message-ID: <526D49B9.7000907@sixdemonbag.org> On 10/27/2013 7:15 AM, Johan Wevers wrote: > Does RSA have any advantages over ElGamal/DSA? It's simpler to implement. That's a nontrivial benefit. From rjh at sixdemonbag.org Sun Oct 27 18:17:18 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Oct 2013 13:17:18 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D0543.3010407@vulcan.xs4all.nl> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526CF5C7.3090809@vulcan.xs4all.nl> <526D02E4.8020504@digitalbrains.com> <526D0543.3010407@vulcan.xs4all.nl> Message-ID: <526D4A9E.8030900@sixdemonbag.org> On 10/27/2013 8:21 AM, Johan Wevers wrote: > Well, both are not broken after substantial research. Further, a break > of ElGamal would also break RSA but not the other way around. If you can compute discrete logs in a finite field, then you can factor, yes, and the reverse is not guaranteed to be true. However, Elgamal is not necessarily the same as the discrete log problem, much in the same way that RSA is probably not the same as the integer factorization problem. From rjh at sixdemonbag.org Sun Oct 27 18:21:12 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Oct 2013 13:21:12 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <1489452037.20131027140425@my_localhost> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <1382823878.29041.23.camel@heisenberg.scientia.net> <526C4B94.6090301@sixdemonbag.org> <526CAEE4.3060806@iki.fi> <526CB5D7.1000802@sixdemonbag.org> <1489452037.20131027140425@my_localhost> Message-ID: <526D4B88.1070404@sixdemonbag.org> On 10/27/2013 10:04 AM, MFPA wrote: > Which raises the question in my mind: was SHA really flawed, or was it > advantageous to NSA's purposes to have people use SHA-1 instead? It's amazing what you can discover by checking Wikipedia. SHA was deeply flawed. The civilian cryptanalytic community broke SHA wide open. We don't know if the flaws the civilian cryptanalytic community discovered are the same ones as what the NSA discovered that caused them to urge SHA be replaced with SHA-1; however, SHA being a flawed algorithm is beyond question. In the future, let's please not engage in paranoid speculation without doing a little research first. There is already plenty enough fear, uncertainty and doubt in the air regarding the NSA without us contributing needlessly to it. From rjh at sixdemonbag.org Sun Oct 27 18:27:26 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Oct 2013 13:27:26 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <1921308083.20131027144111@my_localhost> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526AE68E.1060903@vulcan.xs4all.nl> <910f3581-eba2-49b1-89b4-655718ad396b@email.android.com> <1921308083.20131027144111@my_localhost> Message-ID: <526D4CFE.9030306@sixdemonbag.org> On 10/27/2013 10:41 AM, MFPA wrote: > Couldn't a cryptographically broken algorithm also raise the problem > of forged digital signatures? Yes and no. The mistake people make when discussing digital signatures is to treat them as a purely mathematical exercise rather than as something that exists within a legal framework. Let's say that tomorrow I lose my passphrase and make a new keypair. Then in 25 years someone approaches me with a signed OpenPGP message dated Christmas 2013, saying "I agree to pay you one million dollars at Christmas 2038." I scream it's a forgery, they scream it's valid, we go to trial. Who do you think the judge will believe -- that this message, which nobody can produce any evidence existed prior to 2038, is real? Or that it's some clever shenanigans made possible by newly-developed technology which made my old keypair vulnerable? Just because a digital signature can be forged *mathematically* is no guarantee the signature can be forged *in actuality*. From rjh at sixdemonbag.org Sun Oct 27 18:28:59 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Oct 2013 13:28:59 -0400 Subject: thread links in the FAQ In-Reply-To: <4477893.ZfWqo8gBCP@inno.berlin.laging.de> References: <4477893.ZfWqo8gBCP@inno.berlin.laging.de> Message-ID: <526D4D5B.4050204@sixdemonbag.org> On 10/27/2013 10:54 AM, Hauke Laging wrote: > BTW: Where is the FAQ? I hope this question does not seem too stupid... I posted a link to it yesterday. https://github.com/rjhansen/gpgfaq/blob/master/gpgfaq.xml From rjh at sixdemonbag.org Sun Oct 27 18:36:25 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Oct 2013 13:36:25 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D43B0.9090103@oneiroi.net> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> Message-ID: <526D4F19.3080508@sixdemonbag.org> On 10/27/2013 12:47 PM, Filip M. Nowak wrote: > All this comes with a price of > increased processing power requirement and most of the hardware vendors > are doing really good here (really happily). In the embedded space it's still quite common to see 8-bit processors used as PICs. We're just beginning to make the migration to 32-bit processors, but it's going to be a long, long transition: there's a huge installed base that will only get replaced when old chips fry and burn out. Consumer-grade hardware is a decadent Garden of Eden. However, the tiny little processor that monitors chemical levels at your local water treatment plant is going to be embarrassingly low-powered. Given GnuPG aims to support even some of those bits of hardware (and I'm glad of it -- some of those installations need confidentiality, integrity and assurance even more than I do!), I'm happy the GnuPG defaults are the way they are. > On the other hand, one of the conclusions that Mr Schneier... Just once, I'd love to hear someone say "Kelsey advises" or "Boneh thinks" or "Ferguson has opined that..." The world of computer security is a lot larger than Bruce Schneier. He's good, absolutely, but really. Open your eyes a little and read more of the literature. There's a ton of good stuff out there, and a lot of it disagrees with Bruce. From gnupg at oneiroi.net Sun Oct 27 19:09:34 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sun, 27 Oct 2013 19:09:34 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D4F19.3080508@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <526D4F19.3080508@sixdemonbag.org> Message-ID: <526D56DE.5070609@oneiroi.net> List, Robert. On 10/27/2013 06:36 PM, Robert J. Hansen wrote: > On 10/27/2013 12:47 PM, Filip M. Nowak wrote: >> All this comes with a price of >> increased processing power requirement and most of the hardware vendors >> are doing really good here (really happily). > > In the embedded space it's still quite common to see 8-bit processors > used as PICs. We're just beginning to make the migration to 32-bit > processors, but it's going to be a long, long transition: there's a huge > installed base that will only get replaced when old chips fry and burn out. That's correct but: 1) Specialized microcontrollers with crypto capabilities are available and used for years now (AVR XMEGA which is 8 bit for example) 2) Stuff you are mentioning in most cases isn't used alone - in case of need they are used with other chips, this is more or less idea behind microcontrollers application. > Consumer-grade hardware is a decadent Garden of Eden. Whatever poetic comparison or description fits here, this is a fact. Also it's worth to mention that it's not only about consumer computing hardware: enterprise computing market is overshadowing things are happening with consumer-grade stuff much. > However, the tiny > little processor that monitors chemical levels at your local water > treatment plant is going to be embarrassingly low-powered. I don't expect them to be required to do crypto on their own any soon. SoC thingies are other story but they have power as well as cryptographic engines quite often (trust to the vendor and/or hw implementation of the crypto, is other topic). > Given GnuPG aims to support even some of those bits of hardware (and I'm > glad of it -- some of those installations need confidentiality, > integrity and assurance even more than I do!), I'm happy the GnuPG > defaults are the way they are. This is your holy right I think. I would say exactly the same to the people who are dissatisfied with those settings or hardwired limits. >> On the other hand, one of the conclusions that Mr Schneier... > > Just once, I'd love to hear someone say "Kelsey advises" or "Boneh > thinks" or "Ferguson has opined that..." > > The world of computer security is a lot larger than Bruce Schneier. > He's good, absolutely, but really. Open your eyes a little and read > more of the literature. There's a ton of good stuff out there, and a > lot of it disagrees with Bruce. While unintentionally you just made my point which I was trying to share by this citation - and point is Werner isn't only guy with authority and opinions can vary. P.S. Please stop suggesting level of education and literacy to fellow list-contributors; focus on discussion. Kind regards, Filip From johanw at vulcan.xs4all.nl Sun Oct 27 19:39:04 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 27 Oct 2013 19:39:04 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D4F19.3080508@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <526D4F19.3080508@sixdemonbag.org> Message-ID: <526D5DC8.6090602@vulcan.xs4all.nl> On 27-10-2013 18:36, Robert J. Hansen wrote: > Consumer-grade hardware is a decadent Garden of Eden. However, the tiny > little processor that monitors chemical levels at your local water > treatment plant is going to be embarrassingly low-powered. That's fine, but I doubt I'll ever email such a system. Keys used for such systems, e.g. to sign firmware updates, will be created specifically for that purpose and their parameters can be chosen to work with such systems. I don't need to care wether my email key would work fluently on such a system or not. Cryptocards will probably aso have little processing capacity but they are usually not used for bulk processing. > The world of computer security is a lot larger than Bruce Schneier. Of course, but he is someone who vents his opinions for a large public. The non-crypto expert will probably not read (and understand) the research papers from Adi Shamir. But it's always nice to understand why certain things are advised. Accepting authority blindly is bad security practice. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From peter at digitalbrains.com Sun Oct 27 19:47:31 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 27 Oct 2013 19:47:31 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D56DE.5070609@oneiroi.net> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <526D4F19.3080508@sixdemonbag.org> <526D56DE.5070609@oneiroi.net> Message-ID: <526D5FC3.4000800@digitalbrains.com> On 27/10/13 19:09, Filip M. Nowak wrote: > 1) Specialized microcontrollers with crypto capabilities are available > and used for years now (AVR XMEGA which is 8 bit for example) AVR XMEGA has DES and AES, no asymmetric acceleration. Also, I think the market of XMEGA is phenomenally tiny compared to regular AVR/PIC (personally, I would go to ARM if megaAVR isn't enough). Are there 8-bit microcontrollers with RSA acceleration? 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 gnupg at oneiroi.net Sun Oct 27 20:05:27 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sun, 27 Oct 2013 20:05:27 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D5FC3.4000800@digitalbrains.com> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <526D4F19.3080508@sixdemonbag.org> <526D56DE.5070609@oneiroi.net> <526D5FC3.4000800@digitalbrains.com> Message-ID: <526D63F7.5000006@oneiroi.net> Hi, On 10/27/2013 07:47 PM, Peter Lebbing wrote: > On 27/10/13 19:09, Filip M. Nowak wrote: >> 1) Specialized microcontrollers with crypto capabilities are available >> and used for years now (AVR XMEGA which is 8 bit for example) > > AVR XMEGA has DES and AES, no asymmetric acceleration. Also, I think the market > of XMEGA is phenomenally tiny compared to regular AVR/PIC (personally, I would > go to ARM if megaAVR isn't enough). Well, market for them is tiny, I think this is true. Reason could be that it's all about cost cutting nowadays and not much vendors views crypto as necessary feature or good selling point within customer-oriented market. So it seems to be less about availability of the technology and more about market trends and people's mindset. Anyway - perhaps Robert will pick up this topic as he mentioned microcontrollers first. > Are there 8-bit microcontrollers with RSA acceleration? Not sure. From my experience FPGAs are used for this purpose quite often (for example in security accelerator cards and appliances). I have really limited awareness of software implementations of asymmetric crypto for microcontrollers and I don't know their quality, standards implemented and completeness. > HTH, > > Peter. > Best regards, Filip From wk at gnupg.org Sun Oct 27 20:41:19 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 27 Oct 2013 20:41:19 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D43B0.9090103@oneiroi.net> (Filip M. Nowak's message of "Sun, 27 Oct 2013 17:47:44 +0100") References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> Message-ID: <87sivmwlgg.fsf@vigenere.g10code.de> On Sun, 27 Oct 2013 17:47, gnupg at oneiroi.net said: > Numbers please? Or are you talking about personal/subjective impressions? What about you running some benchmarks for us? Let's say: a 4k RSA key signed by 90 other 4k RSA keys, 8 2k RSA keys, and one 8k RSA key. For security reasons key signature chaching has been disabled (--no-sig-cache) because you obviously can't accept that in this high security theater. Run encryption+signature tests for 2 recipienst out of the set of these 100 keys. Compare that do a set of 2k keys with only one 4k key. Run these tests again on an average netbook. Shalom-Salam, Werner p.s. Once I did tests with off-the self smartcards. Signing a mail with 1k RSA key using these smartcards took more than one second - it was barely unusable for every days mail processing. Only when we moved to our own smartcards (the old AVR based 1k RSA keys) using a smartcards was actually usable (<100ms). You don't want to wait 10 seconds to decrypt a thread of 10 mails just to notice that it was only CCed office chitchat. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg at oneiroi.net Sun Oct 27 21:28:30 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sun, 27 Oct 2013 21:28:30 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <87sivmwlgg.fsf@vigenere.g10code.de> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <87sivmwlgg.fsf@vigenere.g10code.de> Message-ID: <526D776E.6010003@oneiroi.net> Hello, On 10/27/2013 08:41 PM, Werner Koch wrote: > On Sun, 27 Oct 2013 17:47, gnupg at oneiroi.net said: > >> Numbers please? Or are you talking about personal/subjective impressions? > > What about you running some benchmarks for us? Let's say: a 4k RSA key > signed by 90 other 4k RSA keys, 8 2k RSA keys, and one 8k RSA key. For > security reasons key signature chaching has been disabled > (--no-sig-cache) because you obviously can't accept that in this high > security theater. Run encryption+signature tests for 2 recipienst out > of the set of these 100 keys. Constructive request; from OS perspective I would rather separate user which is requesting signature verification from keyring owner so I don't think that --no-sig-cache is only reasonable option in case of "high security theater" (this makes setup or creation of a proper service more cumbersome but still - it's possible). Actually it's hard to call setup in which one user runs MUA or web browser and owns keyring a "high security theater". > Compare that do a set of 2k keys with only one 4k key. > > Run these tests again on an average netbook. Suggested specs? > (...) > > > p.s. > Once I did tests with off-the self smartcards. Signing a mail with 1k > RSA key using these smartcards took more than one second - it was barely > unusable for every days mail processing. Only when we moved to our own > smartcards (the old AVR based 1k RSA keys) using a smartcards was > actually usable (<100ms). You don't want to wait 10 seconds to decrypt > a thread of 10 mails just to notice that it was only CCed office > chitchat. I don't think 1 second threshold is real no-go here. I would say you have quite high requirements. Also some MUAs can contribute to such delays visibly - but I don't know to which part of this setup you hooked-up to measure. Cheers, Filip From free10pro at gmail.com Sun Oct 27 21:49:26 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Sun, 27 Oct 2013 13:49:26 -0700 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D4CFE.9030306@sixdemonbag.org> References: <20131024190545.GA20255@mail.beuc.net> <5269B14C.4020102@sixdemonbag.org> <526AE68E.1060903@vulcan.xs4all.nl> <910f3581-eba2-49b1-89b4-655718ad396b@email.android.com> <1921308083.20131027144111@my_localhost> <526D4CFE.9030306@sixdemonbag.org> Message-ID: <21a4a153-771f-4033-a239-46ff5c6337b9@email.android.com> "Robert J. Hansen" wrote: >Let's say that tomorrow I lose my passphrase and make a new keypair. >Then in 25 years someone approaches me with a signed OpenPGP message >dated Christmas 2013, saying "I agree to pay you one million dollars at >Christmas 2038." I scream it's a forgery, they scream it's valid, we >go >to trial. > >Who do you think the judge will believe -- that this message, which >nobody can produce any evidence existed prior to 2038, is real? Or >that >it's some clever shenanigans made possible by newly-developed >technology >which made my old keypair vulnerable? > >Just because a digital signature can be forged *mathematically* is no >guarantee the signature can be forged *in actuality*. Quite right. This what we sometimes forget about when discussing things like key length, signatures, and projected viability of algorithms. The law is not the same as the crypto. This is similar to the topic of deniability in which the crypto is said to make it so that the user can plausibly deny that he has the encryption key, for example. But if the law, or the court, does not accept that as a valid defense, the user is screwed. The cryptography gives us capabilities, but it is not the deciding factor where the law is concerned. Cheers, --Paul -- PGP: 3DB6D884 From ms at it-infrastrukturen.org Sun Oct 27 21:21:00 2013 From: ms at it-infrastrukturen.org (Mark Schneider) Date: Sun, 27 Oct 2013 21:21:00 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <87sivmwlgg.fsf@vigenere.g10code.de> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <87sivmwlgg.fsf@vigenere.g10code.de> Message-ID: <526D75AC.8060006@it-infrastrukturen.org> Am 27.10.2013 20:41, schrieb Werner Koch: > On Sun, 27 Oct 2013 17:47, gnupg at oneiroi.net said: > >> Numbers please? Or are you talking about personal/subjective impressions? > What about you running some benchmarks for us? Let's say: a 4k RSA key > signed by 90 other 4k RSA keys, 8 2k RSA keys, and one 8k RSA key. For > security reasons key signature chaching has been disabled > (--no-sig-cache) because you obviously can't accept that in this high > security theater. Run encryption+signature tests for 2 recipienst out > of the set of these 100 keys. > > Compare that do a set of 2k keys with only one 4k key. > > Run these tests again on an average netbook. Are there formal reasons why the max length of the RSA key is limited in gnupg[2] linux packages to 4096 Bits only? One thing are the available performance and sane defaults, the other one the available security. (without patching the source code and rebuilding packages) The max length of the key does not have anything to do with zero-exploits. When collecting tons of data there is only this data .. nothing else to break in. I don't trus NIST myself and I guess most of you know why. The question is if similar institution in Europe, Asia, Africa or Australia cen be trusted more. > Shalom-Salam, > > Werner > > > p.s. > Once I did tests with off-the self smartcards. Signing a mail with 1k > RSA key using these smartcards took more than one second - it was barely > unusable for every days mail processing. Only when we moved to our own > smartcards (the old AVR based 1k RSA keys) using a smartcards was > actually usable (<100ms). You don't want to wait 10 seconds to decrypt > a thread of 10 mails just to notice that it was only CCed office > chitchat. Kind regards, Mark -- ms at it-infrastrukturen.org http://rsync.it-infrastrukturen.org From rjh at sixdemonbag.org Sun Oct 27 23:00:00 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 27 Oct 2013 18:00:00 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D75AC.8060006@it-infrastrukturen.org> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <87sivmwlgg.fsf@vigenere.g10code.de> <526D75AC.8060006@it-infrastrukturen.org> Message-ID: <526D8CE0.7030103@sixdemonbag.org> On 10/27/2013 4:21 PM, Mark Schneider wrote: > Are there formal reasons why the max length of the RSA key is limited in > gnupg[2] linux packages to 4096 Bits only? Yes; because past 3072 bits it's time to go to something other than RSA. Several respectable organizations (not only NIST) have done their best to come up with equivalencies between symmetric keys and asymmetric keys. They all seem to converge on the following: A 1024-bit RSA key is equivalent to an 80-bit symmetric key A 2048-bit RSA key is equivalent to a 112-bit symmetric key A 3072-bit RSA key is equivalent to a 128-bit symmetric key A 15,000-bit RSA key is equivalent to a 256-bit symmetric key Each additional bit in an RSA key yields less resistance to cryptanalysis than the one before it. Moving from 1024 bits to 2048 bits gives you an additional 32 bits of entropy; moving from 2048 to 3072 only gives 16 bits of entropy. If someone is able to successfully factor a 3072-bit key, they're quite probably also going to be able to successfully factor a 4096-bit key. PGP 5.0, way back in the day, introduced 4096 bits as the cap on RSA key lengths. This was before we'd put asymmetric and symmetric key lengths on a firm mathematical basis. Nowadays, there's really no reason to go past RSA-3072 (and me, I think there's no reason to go past RSA-2048). If you need more than that, you should be looking into elliptical curve cryptography rather than a longer RSA key. From ricul77 at gmail.com Sun Oct 27 21:33:58 2013 From: ricul77 at gmail.com (Richard Ulrich) Date: Sun, 27 Oct 2013 21:33:58 +0100 Subject: enable-ssh-support not enabled after upgrade to ubuntu saucy (gpg 1.4.14) Message-ID: <1382906038.7006.13.camel@quadulrich> I set up ssh authentication a long time ago according to the second half of this guide (with smartcard): http://www.programmierecke.net/howto/gpg-ssh.html It worked without an issue until I recently upgraded to Ubuntu 13.10. After the upgrade I had to disable the gnome-keyring-ssh and gnome-keyring-gpg as well as ssh-agent again, as I did after previous upgrades. The configuration for enable-ssh-support in ~/.gnupg/gpg-agent.conf was still intact. On another system where the whole stuff still works, ps aux | grep gpg-agent shows only one instance with lots of options: /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/richi/.gnupg/gpg-agent-info-quadulrich /usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch gnome-session --session=ubuntu But on this system, it shows 5 instances 4 with only --daemon and the fifth with an additional --sh. If I type "gpg-agent --daemon --enable-ssh-support" and execute the output in a terminal, I get an instance that works and handles the ssh key authentication. Is anybody here aware of some changes in this area, and knows how I need to configure my system, to have it as seamless as before? More specifically, what I need to do to have the gpg-agent started with all these options? Rgds Richard From faramir.cl at gmail.com Sun Oct 27 23:40:40 2013 From: faramir.cl at gmail.com (Faramir) Date: Sun, 27 Oct 2013 19:40:40 -0300 Subject: Customizing GPG Tools Keychain In-Reply-To: References: Message-ID: <526D9668.6000200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 03-10-2013 17:48, Alejandro Szita escribi?: > Dear All, > > I am a new member to this list, so first of all thank you so much > for your time and consideration in helping me out, I hope I can > return the favour in the near future. > > My system runs MAC OS 10.7.5, I have the GPG Tools Package > installed and I am able to sign & encrypt e-mails. > > My question is about how to customize this package. I read > somewhere else that you can remove your Private Master Key > altogether from your system and use only the subkeys. Moreover, you > can specialize each subkey for a particular use, such as for > example: only encrypt an e-mail, only validate a code, etc... > > Could you please point me to a resource or article that explains in > detail how to do that? Yes, there is a tutorial here http://tjl73.altervista.org/HTML_sign_tutorial/tutorial_en.html Hummmm... I think this is not the first time I read your name, could it have been at fidonet, many years ago? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSbZZoAAoJEMV4f6PvczxAE/gH/i80XxtVZdJwLMP88es40bWj EWSPNUuevXf4s/Qxx4aJ44NaaauybDKjBX3IAH8pme1birgQs9LgPWQr52ddOBFL UyjszOFBlESKSMyUIskX2dOc7Iuq5fqK7zdEpWaF+m/owVV+fjk1ktH76X4NX05Q 3cID+e9QDim9TVZkAZMC348LKRJb0uUi/TkopTtNKs4u6gZi1Q2l79C25Dkr/0u5 dueV7fLVWmWIx0BqqD6pgQNYVkZ52XwzVkSE5s7oFmIzkO2MufQ7yqFQtSGUWiej 0dj19Iq2DxGcedDgrxhJ0Rkahcg3RQuZ42R5DM8cYw6mrx4QkQXqIhLF1lYnAz8= =BJA7 -----END PGP SIGNATURE----- From wk at gnupg.org Mon Oct 28 07:34:16 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Oct 2013 07:34:16 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D776E.6010003@oneiroi.net> (Filip M. Nowak's message of "Sun, 27 Oct 2013 21:28:30 +0100") References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <87sivmwlgg.fsf@vigenere.g10code.de> <526D776E.6010003@oneiroi.net> Message-ID: <87bo29x5sn.fsf@vigenere.g10code.de> On Sun, 27 Oct 2013 21:28, gnupg at oneiroi.net said: > I don't think 1 second threshold is real no-go here. I would say you > have quite high requirements. Also some MUAs can contribute to such Start working with encrypted mails and slow smartcards on a regular base and you would soon see what I mean. Communicating with recipients with some of them using --throw-keyids (i.e. lots of trial decryption) will immediately show up what I mean. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sttob at privatdemail.net Mon Oct 28 09:51:30 2013 From: sttob at privatdemail.net (Stan Tobias) Date: Mon, 28 Oct 2013 09:51:30 +0100 Subject: trust your corporation for keyowner identification? In-Reply-To: References: <525EEE33.1060304__39450.1849696555$1381953182$gmane$org@dougbarton.us> <109563160.20131016222807__37584.6967836425$1381959035$gmane$org@my_localhost> <525FE12A.5040307__21646.6946680614$1382015420$gmane$org@vulcan.xs4all.nl> <20131017135454.Horde.PF7HtsAisFNCiofjRFOv2w7@mail.sixdemonbag.org> <52669348.+eLRL6ulbwvCCmiJ%sttob@privatdemail.net> <5266F5CA.80509@sixdemonbag.org> <526806e2.PnylUKoa89KDX8qO%sttob@privatdemail.net> <52681AFA.2060102@digitalbrains.com> <52685878.6AXcxDzMhOJmhsWU%sttob@privatdemail.net> <5268E9F2.1050108@digitalbrains.com> <5269588e.wAXyOS+XkCb/A4Oa%sttob@privatdemail.net> Message-ID: <526e2592.vizyzHwEGhmqqHhK%sttob@privatdemail.net> Peter Lebbing wrote: > On 24/10/13 01:15, Stan Tobias wrote: > > No, there's no paradox. Any liar will screw your parameters. > > The paradox was very clear in my post where I still called it a dichotomy. There > was a paradox in my thoughts and conclusions, why do you suddenly state there is > no paradox? Because you said that the presence of notary's cert-sig diminished the trust in someone else's certificate: > The dichotomy is thus: if the notary does not sign keys, I would be okay > with people signing keys based on the notary's verification efforts. But > if that same notary did everything he or she did before *and* did > something extra, namely signing keys, suddenly I'm not okay with people > signing keys based on the notary's verification efforts. That's odd. I say it does not, because basing one's certification on that of the notary is not [the same as] basing one's certification on the notary's verification efforts. > And my original statement included: the moment I find out people sign keys > purely based on OpenPGP signatures they trust, they get an "I do NOT trust" in > my trust database. Obviously you also try to do this for liars, Someone who bases his certification on someone else's, *is* a liar. The notary's certification says "X has told me he uses this key". One cannot just look at it and honestly state the same without consulting X. An interesting question is if it is allowable for someone to certify X's signature (while contacting him personally), but where the personal verification (X is really X) is performed by the notary, but the said someone only has seen a signed (normal sig) statement by the notary, while not having actually contacted the notary. (In short: ownership verification in Real World, but personal verification done remotely.) > >Why do we accept, for > > example, a conversation by telephone to validate a key fingerprint? > > Because these are verifications outside the Web of Trust. I don't mean to argue against it, but I just don't see it. Can you show me, or point me to where it is shown, why recursive reliance on valid certificates (or in general, signatures, WoT or not), for purpose of certifications, can lead to undesirable effects? > > But then cases 2. (2a) and 3. differ basically by your cert being included in > > the set. > > No, the difference is that in case 3., you (hopefully) actually did the > verification yourself for key K1, Yes, that's what I've assumed: the WoT is "booted" correctly, in the real world. > an you extend this verification you did yourself to key K2. Yes, but by remote communication. The reasoning goes like this: The signature is validated by my certificate (or, in case 2a, by my friends' whom I trust fully). The message is authenticated by X's valid signature, therefore the message has not been tampered with and its author is X. X says he uses a new key K2. Because I've got this message from X, I have verified the ownership of K2, so I can sign it. What's wrong with this reasoning? Besides that, I don't see why I should distinguish my certificate from the ones of my friends, if I trust them all equally? My owner verification of K1 was only relevant for making proper certification; after that it's just another certificate. (It might be worth considering a case where my friends are nodes of a distributed machine, which were programmed by myself to trust each other ultimately.) [...] > That's correct, you could be so demanding that you say that you > insist on seeing the person face-to-face before you signed their key, > because key K1 could have been stolen and you don't want to make /new/ > certifications based solely on a signed message. I was rather assuming perfect host security (for simplicity), but allowed human errors, and, of course, dishonest attackers. Possibility of stealing a key means we can no longer trust any communication. (In particular, case 3 is no longer permissible, because I cannot be sure it is actually X who is sending me the message). > > If for some reason you would sign in cases 2a and 3, but not in case 2, X > > could trick you: [...] > Sounds to me like you give a good point why you shouldn't sign in case 2a. Or, if you don't mind 2a, then you shouldn't mind 2 either - essentailly it's a proof they're equivalent. "Paul R. Ramer" wrote: > Stan Tobias wrote: > >Peter Lebbing wrote: > >> On 24/10/13 01:15, Stan Tobias wrote: > >> > , then why do we believe WoT authenticates anything? Why do we > >accept, for > >> > example, a conversation by telephone to validate a key fingerprint? > >> Because these are verifications outside the Web of Trust. > >Is that the only requirement? Then I have fantastic news for you! My tongue-in-cheek answer was meant as a reflection over two things: all crypto systems are essensially equivalent in sense they offer the same primitives, and they don't open a different channel for communication. We build our beliefs either on our own experience, or we trust what others say. WoT is just another technical realization of the latter, and communication authenticated through ClosedGPG did not offer any more advantages than through OpenPGP. As to phone conversation, this is just another means of exchanging information. In my understanding, a second channel is opened only when we can recognize someone by voice and we can get additional clues about who we speak to. So, for example, calling my bank if I don't know the person I speak to is no different than sending an e-mail. > The idea of using a different channel for confirming key details such as > a key fingerprint is really a way of trying to avoid a man-in-the-middle > attack on the verification of the key and its UIDs. It is not entirely > foolproof--nothing is. I don't understand how man-in-the-middle fits here, I was explorig an idea if a trust (belief) once correctly initiated could later be transferred purely remotely (electronically), without physical contact. Documents (e.g. a passport) are just a paper medium of communication (as in: "Never underestimate the bandwidth of a station wagon full of paper"), authenticated by some unique features of hand written signature, rubber stamp, prints on the paper etc. One thing I cannot grasp is why some seem to think it's sufficient when I compare the photo, but not when I rely on electronic signatures. Stan. From Nikola.Radovanovic at seavus.com Mon Oct 28 10:23:24 2013 From: Nikola.Radovanovic at seavus.com (Nikola Radovanovic) Date: Mon, 28 Oct 2013 09:23:24 +0000 Subject: none Message-ID: Hello, There are no problems in building the whole Gpg4win installer. It was my mistake, i thought the name of the package was makensis as reported from Terminal, because at first i didn't look at the 'Basic requirements' section in README file. So, i installed all needed packages, and after that, successfully built the Gpg4win installer on Debian 7.2. I have tested the installer on Windows 7 and it works like a charm. Best regards, Nikola ________________________________________ From: Werner Koch [wk at gnupg.org] Sent: Friday, October 25, 2013 4:08 PM To: Nikola Radovanovic Cc: Andre Heinecke; gnupg-users at gnupg.org Subject: Re: none On Thu, 24 Oct 2013 20:49, Nikola.Radovanovic at seavus.com said: > 1) When trying to build whole Gpg4Win i ran into several > problems. Package for gtkhtmlviewer2 couldn't be found, but i have Unfortunately this kind of problems happen from time to time. You may delete the claws-mail tar package from the packages directory to avoid all the Claws dependencies. > (instead plugins) on a target url. Then stow was not installed on a > system, and i have installed it with apt-get install stow. But Configure should have listed stow as missing, or am I wrong. > makensis, which is missing, must be installed also. And it cannot be Under Debian the package is "nsis". > installed with apt-get. It requires python, scons, zlib and gcc to be > installed already, so it is a more complicated process. Werner, if you Sure, that is due to NSIS? If so it would be a Debian packaging bug. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Oct 28 18:58:11 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Oct 2013 18:58:11 +0100 Subject: Why trust gpg4win? In-Reply-To: <522F1C3B.9030306@gmail.com> (NdK's message of "Tue, 10 Sep 2013 15:18:51 +0200") References: <201307252214.r6PME8tp031462@fire.js.berklix.net> <521656E1.9010608@gmail.com> <52167D43.8050801@securemecca.net> <52198251.6080404@sixdemonbag.org> <522E3FFA.60201@sixdemonbag.org> <522ECF2C.5030307@gmail.com> <87ob807tsx.fsf@vigenere.g10code.de> <522F1C3B.9030306@gmail.com> Message-ID: <87mwltqnv0.fsf@vigenere.g10code.de> On Tue, 10 Sep 2013 15:18, ndk.clanbo at gmail.com said: >> way to connect about anything to a computer. Emulated keyboard which >> sends ANSI control codes to take over your box without you noticing? > Uh? "Whithout you noticing"? For sure you know more than me, but to my > knowledge an USB keyboard only sends key scan-codes (not ANSI sequences, > that's why you need to set the keyboard language). And if you have an And that key strokes may for example represent " ping -c1 SOMEHOST; exit" and the attacker will know the time you inserted the USB stick. Now start doing some real thing. > Pete proposed to use an USB-to-Serial interface to avoid attacks against > the USB stack on the PC. Why should an AVR be used to implement a flash > device? Because you wrote the USB stack and thus it is trustworthy. Implementing a backdoor in the AVR proper to detect the use of such a free software USB stack and subvert it would be much harder than to implement something into a closed source USB stack. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From fabio.coatti at gmail.com Tue Oct 29 14:18:06 2013 From: fabio.coatti at gmail.com (Fabio Coatti) Date: Tue, 29 Oct 2013 14:18:06 +0100 Subject: Public algos list Message-ID: Hi all, I just spotted this asking for gnupg version: ========== gpg (GnuPG) 2.0.22 libgcrypt 1.5.3 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, ?, ? Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ========== The part that I don't understand is the two question marks in pubkey algos. Pubkey: RSA, ELG, DSA, ?, ? Can someone point me to some documentation about this or give me an hint? I'm sure I missed something, but I read documentation and googled without success... and I'd like to know what thos question marks stands for . Sorry for the very likely stupid question and thanks for any hint :) -- Fabio From tahirindian at yahoo.com Tue Oct 29 14:05:24 2013 From: tahirindian at yahoo.com (Mohammed Tahir) Date: Tue, 29 Oct 2013 21:05:24 +0800 (SGT) Subject: Issues while decrypting Message-ID: <1383051924.48593.YahooMailNeo@web194001.mail.sg3.yahoo.com> Hi All, I am facing a strange issue while decrypting a file in GPG,. I get an error from command line,,, as gpg: [dont know]: Invalid packet (ctb=6b). I didnt find any reference to this issue in the past. Please help ? Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Oct 29 20:36:52 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Oct 2013 20:36:52 +0100 Subject: Public algos list In-Reply-To: (Fabio Coatti's message of "Tue, 29 Oct 2013 14:18:06 +0100") References: Message-ID: <87zjprq36z.fsf@vigenere.g10code.de> On Tue, 29 Oct 2013 14:18, fabio.coatti at gmail.com said: > The part that I don't understand is the two question marks in pubkey > algos. Pubkey: RSA, ELG, DSA, ?, ? Sorry for that buglet. That extra output (?, ?) is due to a change in preparation of ECC support. It is already fixed in the repository. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 30 11:01:52 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Oct 2013 11:01:52 +0100 Subject: Issues while decrypting In-Reply-To: <1383051924.48593.YahooMailNeo@web194001.mail.sg3.yahoo.com> (Mohammed Tahir's message of "Tue, 29 Oct 2013 21:05:24 +0800 (SGT)") References: <1383051924.48593.YahooMailNeo@web194001.mail.sg3.yahoo.com> Message-ID: <87mwlroz5b.fsf@vigenere.g10code.de> On Tue, 29 Oct 2013 14:05, tahirindian at yahoo.com said: > I am facing a strange issue while decrypting a file in GPG,. I get an error from command line,,, as > gpg: [dont know]: Invalid packet (ctb=6b). I didnt find any reference to this issue in the past. Please help The input data is corrupt or not OpenPGP data. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From samtuke at gnupg.org Wed Oct 30 11:58:56 2013 From: samtuke at gnupg.org (Sam Tuke) Date: Wed, 30 Oct 2013 11:58:56 +0100 Subject: Quotes from GPG users Message-ID: <5270E670.3070307@gnupg.org> Hi all, I'm working with Werner to promote GnuPG and raise awareness. To that end we're collecting quotes from users - endorsements from people who know and trust GPG, people like you. If you want to help us, send your own statement about why GPG is important to you. Please keep it less than or equal to 130 characters, so it can be used on social networks. I'll collect them and pick the best for use now and in future. Stimuli: You trust GPG with what? It's the only app that does what for you / your business? Without it you couldn't do what? Examples: "I can correspond with absolute comfort knowing that there was absolutely no leakage of my mail" (Steve Gibson, Gibson Research) "Since I started working with top-secret documents, I have been using GPG" (Bruce Schneier) Thanks! Sam. -- Sam Tuke Campaign Manager Gnu Privacy Guard 0044 78680 77871 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 295 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Wed Oct 30 16:34:05 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 30 Oct 2013 16:34:05 +0100 Subject: Quotes from GPG users In-Reply-To: <5270E670.3070307@gnupg.org> References: <5270E670.3070307@gnupg.org> Message-ID: <3789868.OIkc7BQGhi@inno.berlin.laging.de> Am Mi 30.10.2013, 11:58:56 schrieb Sam Tuke: > I'm working with Werner to promote GnuPG and raise awareness. I don't understand what that is supposed to be good for. Is there any serious competition between GnuPG and whatever other product? Nearly everyone who uses OpenPGP in a private environment is already using GnuPG. Or is my impression wrong? What we need is awareness for crypto, not for a certain crypto tool: https://bugs.kde.org/show_bug.cgi?id=318005 https://bugs.kde.org/show_bug.cgi?id=326476 https://bugs.kde.org/show_bug.cgi?id=326477 http://lists.gnupg.org/pipermail/gnupg-users/2013-October/047894.html https://sourceforge.net/p/enigmail/forum/feature_requests/thread/8f03a793/ https://mail.gnome.org/archives/seahorse-list/2013-October/msg00006.html Hauke -- Crypto f?r alle: 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 pkk at spth.de Wed Oct 30 18:06:11 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Oct 2013 18:06:11 +0100 Subject: The symmetric ciphers In-Reply-To: <87d2og99y3.fsf@vigenere.g10code.de> References: <522EF602.3080604@spth.de> <87d2og99y3.fsf@vigenere.g10code.de> Message-ID: <52713C83.2010404@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.09.2013 13:45, schrieb Werner Koch: > You would also need a second public keypair to protect the second > symmetric key. If you don't, the attacker would target the public > key scheme directly - ah well that is in any case the lower hanging > fruit. I wouldn't assme that: RSA is something taught in typical maths and computer science curriculums at universities. Factorization is a well-known problem. Symmetric ciphers, on the other hand are for specialists. So I would assume that RSA got much more attention and eyes looking at it than any symmetric cipher. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxPIAACgkQbtUV+xsoLpqAAACg9OF7Wa+MsoIbyEpcEqruFpgT rkUAniJ6U2sZExDoo/iFa4A1W4XXobaw =wl/M -----END PGP SIGNATURE----- From pkk at spth.de Wed Oct 30 18:19:27 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Oct 2013 18:19:27 +0100 Subject: The symmetric ciphers In-Reply-To: <522F1EE6.70308@sixdemonbag.org> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> Message-ID: <52713F9F.9000207@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.09.2013 15:30, schrieb Robert J. Hansen: > On 9/10/2013 6:35 AM, Philipp Klaus Krause wrote: >> I wonder if it would be a good idea to have an option to combine >> symmetric ciphers, e.g. users could state a preference list >> like this: > > No. This idea gets floated every few years and the answers never > change. It's not a good idea. If you look in the list archives > you can find some pretty long, detailed writeups on why. I just tried googling a bit, but the only posts I found are those that assume that the effort to break A+B would be a+b. I did not find the detailed writeups you mentoned, or even anything else about the assumption that breaking A+B takes at least effort max(a,b). >> Assuming it takes effort a to break cipher A and effort b to >> break cipher b, this should result in effort at least max(a, b) >> needed to break A+B. > > Basically, though, it's "this is a naive and unfounded > assumption." Well, here's a (rough, and maybe naive) explanation of why I assumed that the effort is at least max(a, b): First, I assume assume that the effort for breaking anything so is much more than the effort for encryption given the key, that the latter is negligible. So assume there is an attack on A+B. that allows to "break" A+B with effort e less than max(a,b). That means that at least one of e < a or e < b is true. Case 1: e < a: Well, whenever someone is using A, we can just encrypt the ciphertext using B with a key of our choice. Any attack on A+B thus immediately translates into an attack on A, contradicting the assmption e < a. The attack on A would be of the same type as the one on A+B. Case 2: e < b: Hmm, this one seems harder. If I have an attack on A+B that yields information about the key, I can get a chosen-ciphertext attack on B from it. An attack on A+B that yields information about the plaintext could be combined with an attack on A that yields information on the key to get an attack on B that yields information on the plaintext. If A happens to have a weak key, I would get an attack on B that yields information on the plaintext as well. Any way I should get an interesting result of the type b < a + e. I think there is a stronger result possible here, but I admit don't know how I could get there. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxP5wACgkQbtUV+xsoLpoIaACg8KWSjlIToJb40MzI4r+b1nT9 ySAAn0zbo5hbMReGpCycThO6Cy4BAg1H =gNuW -----END PGP SIGNATURE----- From samtuke at gnupg.org Wed Oct 30 18:26:11 2013 From: samtuke at gnupg.org (Sam Tuke) Date: Wed, 30 Oct 2013 18:26:11 +0100 Subject: Quotes from GPG users In-Reply-To: <3789868.OIkc7BQGhi@inno.berlin.laging.de> References: <5270E670.3070307@gnupg.org> <3789868.OIkc7BQGhi@inno.berlin.laging.de> Message-ID: <52714133.2030904@gnupg.org> On 30/10/13 16:34, Hauke Laging wrote: > I don't understand what that is supposed to be good for Promoting GPG is also promoting crypto. People need a particular tool to use. GnuPG also needs resources and support - especially for major new features in future, so promoting its reputation is important. If you don't agree then you can skip this thread. I realise it's an unusual one and I don't wish to disturb the usual business of supporting users here. Best, Sam. -- Sam Tuke Campaign Manager Gnu Privacy Guard 0044 78680 77871 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 295 bytes Desc: OpenPGP digital signature URL: From pkk at spth.de Wed Oct 30 18:27:47 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Oct 2013 18:27:47 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <526D5FC3.4000800@digitalbrains.com> References: <20131024190545.GA20255@mail.beuc.net> <1382660348.1296.62.camel@heisenberg.scientia.net> <20131026093525.GC19250@mail.beuc.net> <87sivoxmas.fsf@vigenere.g10code.de> <526D43B0.9090103@oneiroi.net> <526D4F19.3080508@sixdemonbag.org> <526D56DE.5070609@oneiroi.net> <526D5FC3.4000800@digitalbrains.com> Message-ID: <52714193.2060509@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 27.10.2013 19:47, schrieb Peter Lebbing: > On 27/10/13 19:09, Filip M. Nowak wrote: >> 1) Specialized microcontrollers with crypto capabilities are >> available and used for years now (AVR XMEGA which is 8 bit for >> example) > > AVR XMEGA has DES and AES, no asymmetric acceleration. Also, I > think the market of XMEGA is phenomenally tiny compared to regular > AVR/PIC (personally, I would go to ARM if megaAVR isn't enough). > > Are there 8-bit microcontrollers with RSA acceleration? Well, some, such as the Rabbit families have support for arbitrary-length multiplication that AFAIK was included mostly to make RSA implementations faster. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxQZMACgkQbtUV+xsoLprZ9wCgnfkIFzpByEwHkfC4BdZ+kEw5 3PgAmQGQ2XukmQwonj+OXmSq0EgYALGt =VoHH -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Oct 30 18:39:07 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Oct 2013 10:39:07 -0700 Subject: The symmetric ciphers In-Reply-To: <52713F9F.9000207@spth.de> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> Message-ID: <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> > Well, here's a (rough, and maybe naive) explanation of why I assumed > that the effort is at least max(a, b): If you first encrypt with ROT10 and then with ROT16, the final strength is not the maximum of (ROT10, ROT16). You may think that's a silly example, and I grant that it is, but it illuminates the point pretty well and avoids a lot of difficult math. Cryptographic algorithms are extremely subtle and interact with each other in subtle ways. As a general rule they should not be stacked unless there is (a) a clear necessity and (b) the particular stacking has been formally proven to not diminish the overall security of the system. Otherwise, much as how ROT10+ROT16 has really awful security characteristics, your stacking may be similarly awful. From pkk at spth.de Wed Oct 30 19:33:19 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Oct 2013 19:33:19 +0100 Subject: The symmetric ciphers In-Reply-To: <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> Message-ID: <527150EF.2080406@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 30.10.2013 18:39, schrieb Robert J. Hansen: >> Well, here's a (rough, and maybe naive) explanation of why I >> assumed that the effort is at least max(a, b): > > If you first encrypt with ROT10 and then with ROT16, the final > strength is not the maximum of (ROT10, ROT16). You may think > that's a silly example, and I grant that it is, but it illuminates > the point pretty well and avoids a lot of difficult math. But ROT10 and ROT16 fail the condition that breaking them should be substancially harder than applying them. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxUOwACgkQbtUV+xsoLpp/SQCgxg0xSXLXEzpazQ3TwhXv82JC HNcAnAsmU5WL/naU9LbBAY4GdrtRyoo/ =euUP -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Oct 30 19:45:31 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Oct 2013 11:45:31 -0700 Subject: The symmetric ciphers In-Reply-To: <527150EF.2080406@spth.de> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <527150EF.2080406@spth.de> Message-ID: <20131030114531.Horde.dJW5hQgKB53wr4YwXj_teA1@sixdemonbag.org> Quoting Philipp Klaus Krause : > But ROT10 and ROT16 fail the condition that breaking them should be > substancially harder than applying them. Arguing that "but that's not a real example!" is a nonstarter. It wasn't presented as a real example. It was presented as a way to illuminate the principle involved -- that algorithms can interact with each other in ways that diminish the security of both -- without needing to break out graduate-level mathematics. From pkk at spth.de Wed Oct 30 20:25:41 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Oct 2013 20:25:41 +0100 Subject: The symmetric ciphers In-Reply-To: <522EF602.3080604@spth.de> References: <522EF602.3080604@spth.de> Message-ID: <52715D35.60507@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 10.09.2013 12:35, schrieb Philipp Klaus Krause: > I wonder if it would be a good idea to have an option to combine > symmetric ciphers, e.g. users could state a preference list like > this: > > TWOFISH+AES256 3DES+BLOWFISH+AES AES 3DES > > The meaning of A+B would be to encrypt using A first, and then > encrypt the result using B with a different key. Assuming it takes > effort a to break cipher A and effort b to break cipher b, this > should result in effort at least max(a, b) needed to break A+B. And > with uncertainity about possible weaknesses in individual ciphers, > this seems like a reasonable measure to me. > > Philipp If we have plenty of randomness available, we could do this a different way: XOR the message M with a random one-time pad P to obtain N. Encrypt P with A, and N with B. The drawback is that this doubles the lenth of the message. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxXTEACgkQbtUV+xsoLpqEhwCgnb7/AFx3b8q6a/sFPfPSt4NG 8SYAn3DgDL2BXYAwdfdcTSl+tBDJ/Jwt =Hsq+ -----END PGP SIGNATURE----- From peter at digitalbrains.com Wed Oct 30 20:37:53 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Oct 2013 20:37:53 +0100 Subject: The symmetric ciphers In-Reply-To: <52715D35.60507@spth.de> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> Message-ID: <52716011.608@digitalbrains.com> On 30/10/13 20:25, Philipp Klaus Krause wrote: > If we have plenty of randomness available, we could do this a different > way: XOR the message M with a random one-time pad P to obtain N. Encrypt P > with A, and N with B. Why are you inventing new crypto primitives? Symmetric crypto is already good enough. But to immediately debunk this system: there is a strong correlation between P and N (i.e., the plaintext). This means you are encrypting strongly correlated material with two different ciphers. If you can somehow make them meet in the middle, you no longer have to completely break one of the ciphers completely but instead break both partially, which might be orders easier to do. 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 gollo at fsfe.org Wed Oct 30 19:31:59 2013 From: gollo at fsfe.org (Martin Gollowitzer) Date: Wed, 30 Oct 2013 19:31:59 +0100 Subject: Quotes from GPG users In-Reply-To: <5270E670.3070307@gnupg.org> References: <5270E670.3070307@gnupg.org> Message-ID: <20131030183159.GO3866@platinum.gollo.at> * Sam Tuke [131030 13:18, mID <5270E670.3070307 at gnupg.org>]: > Hi all, > > I'm working with Werner to promote GnuPG and raise awareness. To that end we're > collecting quotes from users - endorsements from people who know and trust GPG, > people like you. > > If you want to help us, send your own statement about why GPG is important to > you. Please keep it less than or equal to 130 characters, so it can be used on > social networks. Unfortunately, this is slightly longer (it's really hard to stick to 130 characters): GnuPG allows for both proving a message's authenticity and preventing eavesdropping. It's one of the most important tools I use every day. I'll try to come up with a better one ASAP. Best, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: Digital signature URL: From rjh at sixdemonbag.org Wed Oct 30 21:31:46 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Oct 2013 13:31:46 -0700 Subject: The symmetric ciphers In-Reply-To: <52715D35.60507@spth.de> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> Message-ID: <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> > If we have plenty of randomness available, we could do this a > different way: Dangerously naive. Meet-in-the-middle and/or miss-in-the-middle attacks could be devastating. From wk at gnupg.org Wed Oct 30 21:59:25 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Oct 2013 21:59:25 +0100 Subject: The symmetric ciphers In-Reply-To: <52715D35.60507@spth.de> (Philipp Klaus Krause's message of "Wed, 30 Oct 2013 20:25:41 +0100") References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> Message-ID: <87sivio4pe.fsf@vigenere.g10code.de> On Wed, 30 Oct 2013 20:25, pkk at spth.de said: > If we have plenty of randomness available, we could do this a Entropy (which should be at the core of every CRNG) is a scarce resource. Thus a one time pad is not going to work because you need true random at the same size of the message. > XOR the message M with a random one-time pad P to obtain N. Encrypt P > with A, and N with B. > The drawback is that this doubles the lenth of the message. And that you need a way to securely convey the OTP to the recipient. The soviets had severe problems to do that during WWII and later and resorted to double use the one time pads. That was one of the origins of the UKUSA alliance aiming and succeeding at breaking there messages (project VENONA). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Oct 30 22:03:00 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Oct 2013 22:03:00 +0100 Subject: The symmetric ciphers In-Reply-To: <52713C83.2010404@spth.de> (Philipp Klaus Krause's message of "Wed, 30 Oct 2013 18:06:11 +0100") References: <522EF602.3080604@spth.de> <87d2og99y3.fsf@vigenere.g10code.de> <52713C83.2010404@spth.de> Message-ID: <87ob66o4jf.fsf@vigenere.g10code.de> On Wed, 30 Oct 2013 18:06, pkk at spth.de said: > I wouldn't assme that: RSA is something taught in typical maths and > computer science curriculums at universities. Factorization is a > well-known problem. Using RSA in a safe way is a not easy - it took more than 20 years until most cryptographers are convinced that there are safe way of using RSA. Check out the notes section in the HAC on attacks on RSA. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From pkk at spth.de Wed Oct 30 23:33:18 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Oct 2013 23:33:18 +0100 Subject: The symmetric ciphers In-Reply-To: <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> Message-ID: <5271892E.8010301@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there a known good way to combine multiple symmetric ciphers into something that is at least as strong as the weakest of them? Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxiSkACgkQbtUV+xsoLprSJQCfSXdZW2CmWFz6+CCpRNT3nBLK El4An1psE3eEeYZU36f9Z+YXuYQBSwvD =fsr4 -----END PGP SIGNATURE----- From robertc at broadcom.com Wed Oct 30 23:51:43 2013 From: robertc at broadcom.com (Bob (Robert) Cavanaugh) Date: Wed, 30 Oct 2013 22:51:43 +0000 Subject: The symmetric ciphers In-Reply-To: <5271892E.8010301@spth.de> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> <5271892E.8010301@spth.de> Message-ID: <8F0B09FC6339FA439524099BFCABC11F04301A1B@IRVEXCHMB11.corp.ad.broadcom.com> I guess I lost track of the initial purpose of this thread. Why do you want this if you can only achieve the same cryptographic strength as one of the ciphers? What problem are you solving? Thanks, Bob Cavanaugh Broadcom Corporation 16340 West Bernardo Drive San Diego CA 92127 Work: 858-521-5562 Fax: 858-385-8810 Cell: 858-361-2068 -----Original Message----- From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Philipp Klaus Krause Sent: Wednesday, October 30, 2013 3:33 PM To: gnupg-users at gnupg.org Subject: Re: The symmetric ciphers * PGP Signed by an unknown key Is there a known good way to combine multiple symmetric ciphers into something that is at least as strong as the weakest of them? Philipp * Unknown Key * 0x1B282E9A(L) _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From pkk at spth.de Wed Oct 30 23:55:26 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Oct 2013 23:55:26 +0100 Subject: The symmetric ciphers In-Reply-To: <5271892E.8010301@spth.de> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> <5271892E.8010301@spth.de> Message-ID: <52718E5E.2040108@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 30.10.2013 23:33, schrieb Philipp Klaus Krause: > Is there a known good way to combine multiple symmetric ciphers > into something that is at least as strong as the weakest of them? > > Philipp > This should have been "... as the strongest of them?". -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxjlkACgkQbtUV+xsoLpoWVwCeN21t5LI39J9Fz4JcJfJp85fh CXQAoITjUB4H/LTVPN5yS7UlVfrgUjP7 =7eRd -----END PGP SIGNATURE----- From pkk at spth.de Wed Oct 30 23:57:07 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Oct 2013 23:57:07 +0100 Subject: The symmetric ciphers In-Reply-To: <8F0B09FC6339FA439524099BFCABC11F04301A1B@IRVEXCHMB11.corp.ad.broadcom.com> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> <5271892E.8010301@spth.de> <8F0B09FC6339FA439524099BFCABC11F04301A1B@IRVEXCHMB11.corp.ad.broadcom.com> Message-ID: <52718EC3.1030406@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 30.10.2013 23:51, schrieb Bob (Robert) Cavanaugh: > I guess I lost track of the initial purpose of this thread. Why do > you want this if you can only achieve the same cryptographic > strength as one of the ciphers? What problem are you solving? There are multiple symmetric ciphers. Any one of them might already have been broken by an adversary, but I assume that there are many among them that are not broken. I do not know which ones are which. So, if I have ciphers A, B and C, and a way to combine them into one symmetric cpher that is at least as strong as the strongest among them, I could use this combined cipher for somewhat secure communication as long as at least one of A, B, C is not broken, even if I do not know which ones are broken. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxjsMACgkQbtUV+xsoLpoM7ACfUWEYet6vVgtQH4PDJQmYIbBP i78AoIyoDEdCSzbzHTXUicuaxlwsWaD3 =5hUv -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu Oct 31 00:11:53 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Oct 2013 19:11:53 -0400 Subject: The symmetric ciphers In-Reply-To: <5271892E.8010301@spth.de> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> <5271892E.8010301@spth.de> Message-ID: <52719239.6000707@sixdemonbag.org> > Is there a known good way to combine multiple symmetric ciphers into > something that is at least as strong as the weakest of them? Not one that generalizes to all ciphers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Oct 31 00:15:28 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Oct 2013 19:15:28 -0400 Subject: The symmetric ciphers In-Reply-To: <52718EC3.1030406@spth.de> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> <5271892E.8010301@spth.de> <8F0B09FC6339FA439524099BFCABC11F04301A1B@IRVEXCHMB11.corp.ad.broadcom.com> <52718EC3.1030406@spth.de> Message-ID: <52719310.7050002@sixdemonbag.org> > So, if I have ciphers A, B and C, and a way to combine them into one > symmetric cpher that is at least as strong as the strongest among > them, I could use this combined cipher for somewhat secure > communication as long as at least one of A, B, C is not broken, even > if I do not know which ones are broken. Or you could just use 3DES. Reposted from the last time was wondering if anything had been broken in the OpenPGP suite: ===== I have said this many times in the past; apparently I need to say it again. "3DES has been turning brilliant cryptanalysts into burned-out alcoholic wrecks for over thirty years." Nothing in the OpenPGP suite comes anywhere near to the safety provided by 3DES. Nothing even comes *close*. Assuming your adversary has access to more computing power than exists in the entire world, 3DES offers "only" 112 bits of security; for realistic assumptions about computing power, 3DES offers the full 168 bits. 3DES is ugly, awkward, ungainly, slow, and it has all the aesthetic appeal of the Socialist Realism school of art. It is *awful*. And yet, it keeps on going, completely impervious to the last three decades of cryptanalysis. It reminds me quite a lot of the coelacanth -- a fish that was found in the fossil record 400 million years ago, and still can be found swimming in the oceans today. If you look at a coelacanth it just looks primitive, unevolved, and strangely frightening. It has survived the last 400 million years of Nature's attempts at killing it. It commands respect and admiration, even while at the same time giving vague feelings of revulsion. 3DES is our coelacanth. http://outlookcolumbus.com/wp-content/uploads/2013/02/coelacanth1.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Thu Oct 31 00:20:29 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 31 Oct 2013 00:20:29 +0100 Subject: The symmetric ciphers In-Reply-To: <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> Message-ID: <5271943D.9060409@vulcan.xs4all.nl> On 30-10-2013 18:39, Robert J. Hansen wrote: > If you first encrypt with ROT10 and then with ROT16, the final strength > is not the maximum of (ROT10, ROT16). You may think that's a silly > example, and I grant that it is, but it illuminates the point pretty > well and avoids a lot of difficult math. That's because ROT(N) is a group. In a way, we already use a combination cipher in the form of 3DES, which uses 3 times the same cipher (OK, 2 times and one time in the reverse) but that works because DES is not a group. I don't know wether the other symmetric ciphers are a group though, but I'm sure someone has investigated that. > Cryptographic algorithms are extremely subtle and interact with each > other in subtle ways. As a general rule they should not be stacked > unless there is (a) a clear necessity and (b) the particular stacking > has been formally proven to not diminish the overall security of the > system. Otherwise, much as how ROT10+ROT16 has really awful security > characteristics, your stacking may be similarly awful. Assuming that the same key is used for all that is. Otherwise, if an attacker knew how to make use of this, encrypting the encrypted message would help decrypting it, and since any attacker could do that it should not matterfor a decent encryption algorithm (which ROT(N) clearly is not). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Thu Oct 31 04:52:32 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 30 Oct 2013 23:52:32 -0400 Subject: The symmetric ciphers In-Reply-To: <5271943D.9060409@vulcan.xs4all.nl> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <5271943D.9060409@vulcan.xs4all.nl> Message-ID: <5271D400.6050006@sixdemonbag.org> On 10/30/2013 7:20 PM, Johan Wevers wrote: > That's because ROT(N) is a group. Yes, but good luck answering the inevitable next two questions: "what's a group?" and "how do we know if something's a group?" You very quickly run into some complicated higher-level maths, and that's something best avoided. > I don't know wether the other symmetric ciphers are a group though, > but I'm sure someone has investigated that. There is no single answer to this. The "other symmetric ciphers" need to be evaluated combinatorically: for instance, are AES128, 3DES and Camellia a group? That answer may be different from AES192, 3DES and Camellia. Given there are 11 different symmetric algorithms as of 2.0.22, figuring out all known-safe 3-cipher selections would require us to investigate 165 different combinations. Frankly, I don't feel like doing that much work. > Assuming that the same key is used for all that is. No. I'm quite happy with my blanket statement: cryptographic algorithms are subtle and should be left alone. If you're Don Coppersmith then I think you should feel free to get down with your bad self, but otherwise this entire line of inquiry is one that I think goes nowhere good. From htd at fritha.org Thu Oct 31 08:33:27 2013 From: htd at fritha.org (Heinz Diehl) Date: Thu, 31 Oct 2013 08:33:27 +0100 Subject: Quotes from GPG users In-Reply-To: <5270E670.3070307@gnupg.org> References: <5270E670.3070307@gnupg.org> Message-ID: <20131031073327.GB1855@fritha.org> On 30.10.2013, Sam Tuke wrote: > I'm working with Werner to promote GnuPG and raise awareness. Just my 5?: Raised awareness does seldom lead to change (just as knowledge and attitudes). Before developing a strategy on promoting the use of GPG, the barriers which prevent people from using it should be explored and fed back into the implementation strategy. Maybe some principles from social marketing (insight, exchange..) would fit as a good starting point for a campaign. From mwood at IUPUI.Edu Thu Oct 31 14:36:12 2013 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 31 Oct 2013 09:36:12 -0400 Subject: The symmetric ciphers In-Reply-To: <52713F9F.9000207@spth.de> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> Message-ID: <20131031133612.GA8405@IUPUI.Edu> On Wed, Oct 30, 2013 at 06:19:27PM +0100, Philipp Klaus Krause wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 10.09.2013 15:30, schrieb Robert J. Hansen: > > On 9/10/2013 6:35 AM, Philipp Klaus Krause wrote: > >> I wonder if it would be a good idea to have an option to combine > >> symmetric ciphers, e.g. users could state a preference list > >> like this: > > > > No. This idea gets floated every few years and the answers never > > change. It's not a good idea. If you look in the list archives > > you can find some pretty long, detailed writeups on why. > > I just tried googling a bit, but the only posts I found are those that > assume that the effort to break A+B would be a+b. I did not find the > detailed writeups you mentoned, or even anything else about the > assumption that breaking A+B takes at least effort max(a,b). I often worry about the assumption that there are no unfortunate interactions between the structures of A and B such that the effort to break A+B < min(a,b). Consider a composition of *three* ciphers: A := ROT13 B := ROT10 C := ROT3 Each different from the others, though similar in operation. But (when the symbol set is the Roman alphabet) A(B(C(x))) = x. Composing these three ciphers produces a cipher worse than any of its components. Any order of composition will do the same. Compose any two of them and the result is no stronger than any single one. Obviously this should not be assumed to hold true for all possible functions, but it provides a counterexample: composing ciphers does not necessarily produce a stronger cipher. -- 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 mwood at IUPUI.Edu Thu Oct 31 14:41:00 2013 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 31 Oct 2013 09:41:00 -0400 Subject: The symmetric ciphers In-Reply-To: <20131031133612.GA8405@IUPUI.Edu> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131031133612.GA8405@IUPUI.Edu> Message-ID: <20131031134100.GB8405@IUPUI.Edu> Having not read far enough down the thread, Mark H. Wood wishes to recall a completely redundant message: > Consider a composition of *three* ciphers: > > A := ROT13 > B := ROT10 > C := ROT3 -- Mark H. Wood, hasty poster 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 mwood at IUPUI.Edu Thu Oct 31 15:00:36 2013 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 31 Oct 2013 10:00:36 -0400 Subject: The symmetric ciphers In-Reply-To: <5271892E.8010301@spth.de> References: <522EF602.3080604@spth.de> <52715D35.60507@spth.de> <20131030133146.Horde.UzPLK1yMaFjhtM1r7_cxgg2@sixdemonbag.org> <5271892E.8010301@spth.de> Message-ID: <20131031140036.GC8405@IUPUI.Edu> On Wed, Oct 30, 2013 at 11:33:18PM +0100, Philipp Klaus Krause wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is there a known good way to combine multiple symmetric ciphers into > something that is at least as strong as the weakest of them? I sincerely doubt that there is, in the general case. That's the point: you have to analyze each combination as if it were a new, untried cipher. It seems useless to ask whether one can benefit from composing multiple unspecified symmetric ciphers; much more useful to ask whether e.g. AES+BLOWFISH is at least as strong as, or stronger than, either AES or BLOWFISH alone. Then ask the same question for each composition you think promising. You will wind up doing quite a LOT of math. You could probably get a book out of it, if you do a thorough job. -- 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 johanw at vulcan.xs4all.nl Thu Oct 31 15:00:38 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 31 Oct 2013 15:00:38 +0100 Subject: The symmetric ciphers In-Reply-To: <5271D400.6050006@sixdemonbag.org> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <5271943D.9060409@vulcan.xs4all.nl> <5271D400.6050006@sixdemonbag.org> Message-ID: <52726286.80508@vulcan.xs4all.nl> On 31-10-2013 4:52, Robert J. Hansen wrote: >> That's because ROT(N) is a group. > > Yes, but good luck answering the inevitable next two questions: "what's > a group?" Playing Captain Obvious: G is a group for the operation X if: - \forall {A,B \in G} --> A X B \in G: G is closed. - \forall {A,B,C\in G} --> (A X B) X C = A X (B X C): G obeys the associative law. - \exists {E\in G} so that \forall {A\in G} A X E = E X A = A: G has a unit element. - \forall {A\in G} \exists {A^{-1}\in G} so that A X A^{-1} = E: Each element in G has an inverse. If also holds: \forall {A,B\in G} --> A X B = B X A the group is called Abelian or commutative. > and "how do we know if something's a group?" You very quickly > run into some complicated higher-level maths, and that's something best > avoided. I don't doubt that. I assumed (yes I know, assumption is the mother of all fuckups) that these things were analyzed during the long cryptanalysis the algorithms in gpg have had. From DES I know it is not a group (otherwise 3DES would indeed not be more secure than single DES), I admid that a quick Google about AES didn't turn up any information one way or the other. Is that not determined yet? Did noone researched something like 3AES yet? > There is no single answer to this. The "other symmetric ciphers" need > to be evaluated combinatorically: for instance, are AES128, 3DES and > Camellia a group? That answer may be different from AES192, 3DES and > Camellia. However, encrypting a message with AES with key1 and then encrypting it again with key2 (key1 unrelated to key2) can't make it less secure since any attacker can encrypt the intercepted encrypted message again with little effort. That would be like saying that base-64 encoding the message would reduce security. Of course there is one well-known encryption product that offers this option: TrueCrypt allows one to stack encryption algorithms. But then, the design decisions of TrueCrypt are not really known. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From vedaal at nym.hush.com Thu Oct 31 16:37:25 2013 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Thu, 31 Oct 2013 11:37:25 -0400 Subject: The symmetric ciphers In-Reply-To: <52726286.80508@vulcan.xs4all.nl> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <5271943D.9060409@vulcan.xs4all.nl> <5271D400.6050006@sixdemonbag.org> <52726286.80508@vulcan.xs4all.nl> Message-ID: <20131031153725.91FF8C0617@smtp.hushmail.com> On Thursday, October 31, 2013 at 10:06 AM, "Johan Wevers" wrote: >However, encrypting a message with AES with key1 and then >encrypting it again with key2 (key1 unrelated to key2) can't make it less secure >since any attacker can encrypt the intercepted encrypted message again >with little effort. That would be like saying that base-64 encoding the >message would reduce security. ===== If the keys are different, and the algorithms different, then it would seem that there is a major advantage to re-encrypting the ciphertext, ('cascading' is the term Truecrypt uses for this.) The advantage is, that if it should ever be possible to brute force the keyspace of one key, then NONE of the possible elements of the keyspace (including the *correct* key) will result in an identifiable *correct* plaintext. It will only result in random ciphertext. (This is different than ROT(10) followed by ROT(16), because it can be broken by brute forcing ROT(x, ; 0Of course there is one well-known encryption product that offers >this option: TrueCrypt allows one to stack encryption algorithms. But >then, the design decisions of TrueCrypt are not really known. ===== Truecrypt allows only AES, Twofish, and Serpent for encryption and cascading. (Whether this is because there is a potential flaw in using other algorithms, or whether it is simply too much work for the developers to provide cascading for all algortihms, I do not know.) Here is the description in the Truecrypt documentation: http://www.truecrypt.org/docs/cascades#Y0 =====[begin quote]===== AES-Twofish-Serpent Three ciphers in a cascade [15, 16] operating in XTS mode (see the section Modes of Operation). Each 128-bit block is first encrypted with Serpent (256-bit key) in XTS mode, then with Twofish (256-bit key) in XTS mode, and finally with AES (256-bit key) in XTS mode. Each of the cascaded ciphers uses its own key. All encryption keys are mutually independent (note that header keys are independent too, even though they are derived from a single password ? see the section Header Key Derivation, Salt, and Iteration Count). See above for information on the individual cascaded ciphers. Serpent-AES Two ciphers in a cascade [15, 16] operating in XTS mode (see the section Modes of Operation). Each 128-bit block is first encrypted with AES (256-bit key) in XTS mode and then with Serpent (256-bit key) in XTS mode. Each of the cascaded ciphers uses its own key. All encryption keys are mutually independent (note that header keys are independent too, even though they are derived from a single password ? see the section Header Key Derivation, Salt, and Iteration Count). See above for information on the individual cascaded ciphers. Serpent-Twofish-AES Three ciphers in a cascade [15, 16] operating in XTS mode (see the section Modes of Operation). Each 128-bit block is first encrypted with AES (256-bit key) in XTS mode, then with Twofish (256-bit key) in XTS mode, and finally with Serpent (256-bit key) in XTS mode. Each of the cascaded ciphers uses its own key. All encryption keys are mutually independent (note that header keys are independent too, even though they are derived from a single password ? see the section Header Key Derivation, Salt, and Iteration Count). See above for information on the individual cascaded ciphers. Twofish-Serpent Two ciphers in a cascade [15, 16] operating in XTS mode (see the section Modes of Operation). Each 128-bit block is first encrypted with Serpent (256-bit key) in XTS mode and then with Twofish (256-bit key) in XTS mode. Each of the cascaded ciphers uses its own key. All encryption keys are mutually independent (note that header keys are independent too, even though they are derived from a single password ? see the section Header Key Derivation, Salt, and Iteration Count). See above for information on the individual cascaded ciphers. =====[end quote]===== A potentially discomforting point in how Truecrypt does this, is that they state, that the different cascaded header keys are derived from a single password. It may well be that, as Robert intuitively felt, an avenue of attack on the password and subsequently derived keys, might be far more feasible than trying to brute force a keyspace, and therefore rendering the resulting ciphertext more vulnerable than if it were encrypted only once. vedaal From peter at digitalbrains.com Thu Oct 31 20:23:10 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 31 Oct 2013 20:23:10 +0100 Subject: The symmetric ciphers In-Reply-To: <20131031153725.91FF8C0617@smtp.hushmail.com> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <5271943D.9060409@vulcan.xs4all.nl> <5271D400.6050006@sixdemonbag.org> <52726286.80508@vulcan.xs4all.nl> <20131031153725.91FF8C0617@smtp.hushmail.com> Message-ID: <5272AE1E.6060100@digitalbrains.com> On 31/10/13 16:37, vedaal at nym.hush.com wrote: > The advantage is, that if it should ever be possible to brute force the > keyspace of one key, then NONE of the possible elements of the keyspace > (including the *correct* key) will result in an identifiable *correct* > plaintext. It will only result in random ciphertext. Then again: If brute forcing a key costs you all the energy in this solar system, you don't have any light to read the decrypted message by. And that's what we're talking about here. So: forget about brute-forcing. 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 dkg at fifthhorseman.net Thu Oct 31 21:31:02 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 31 Oct 2013 16:31:02 -0400 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <20131024190545.GA20255@mail.beuc.net> References: <20131024190545.GA20255@mail.beuc.net> Message-ID: <877gct41yx.fsf@alice.fifthhorseman.net> On Thu 2013-10-24 15:05:45 -0400, Sylvain wrote: > I saw a lot of activity in the Debian project about upgrading to a > 4096 RSA key, > e.g. http://lists.debian.org/debian-devel-announce/2010/09/msg00003.html > > However GnuPG's default is 2048. ENISA (the European Union Agency for Network and Information Security) recently issued a report recommending that non-legacy systems using RSA start with keys that are >= 3072 bits (see page 30 of the PDF): http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report Clearly, any OpenPGP implementation needs to deal with legacy systems, so being able to interact with older, shorter keys is a necessity. But the authors of that report do seem to suggest that the default for RSA keys should be 3072-bits going forward (though they don't mention OpenPGP explicitly at all). The fact that the report comes from a fancy governmental web site doesn't mean it's correct, of course. I'm just offering it as a data point in the discussion :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From mailinglisten at hauke-laging.de Thu Oct 31 22:02:53 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 31 Oct 2013 22:02:53 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <877gct41yx.fsf@alice.fifthhorseman.net> References: <20131024190545.GA20255@mail.beuc.net> <877gct41yx.fsf@alice.fifthhorseman.net> Message-ID: <2108273.tvUIOKmUu6@inno.berlin.laging.de> Am Do 31.10.2013, 16:31:02 schrieb Daniel Kahn Gillmor: > http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverable > s/algorithms-key-sizes-and-parameters-report There is one point I don't understand: [3.6 Recommendations] "there is general agreement this should be above the 100-bit level" "for long term use AES-256" But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia article for AES) claims that AES-256 was down to 99.5 bits. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Thu Oct 31 22:17:39 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 31 Oct 2013 22:17:39 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <2108273.tvUIOKmUu6@inno.berlin.laging.de> References: <20131024190545.GA20255@mail.beuc.net> <877gct41yx.fsf@alice.fifthhorseman.net> <2108273.tvUIOKmUu6@inno.berlin.laging.de> Message-ID: <5272C8F3.3090405@digitalbrains.com> On 31/10/13 22:02, Hauke Laging wrote: > But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia > article for AES) claims that AES-256 was down to 99.5 bits. I just glanced over the abstract, but didn't you glance over the term "related key"? I.e., not generally applicable. 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 pete at heypete.com Thu Oct 31 22:17:42 2013 From: pete at heypete.com (Pete Stephenson) Date: Thu, 31 Oct 2013 22:17:42 +0100 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <2108273.tvUIOKmUu6@inno.berlin.laging.de> References: <20131024190545.GA20255@mail.beuc.net> <877gct41yx.fsf@alice.fifthhorseman.net> <2108273.tvUIOKmUu6@inno.berlin.laging.de> Message-ID: On Thu, Oct 31, 2013 at 10:02 PM, Hauke Laging wrote: > Am Do 31.10.2013, 16:31:02 schrieb Daniel Kahn Gillmor: > >> http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverable >> s/algorithms-key-sizes-and-parameters-report > > There is one point I don't understand: > > [3.6 Recommendations] > > "there is general agreement this should be above the 100-bit level" > > "for long term use AES-256" > > But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia > article for AES) claims that AES-256 was down to 99.5 bits. That attack is only valid if different messages have related keys. If the keys are chosen randomly, the attack does not apply. I'm not aware of any crypto system that implements AES with related keys (though if anyone knows of some, I'd like to know so I can avoid it). See https://en.wikipedia.org/wiki/Related-key_attack and https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security for details . According to the Wiki, the best attack on full-round AES-256 not using related keys requires 254.4 operations (see https://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf ). Cheers! -Pete -- Pete Stephenson From rjh at sixdemonbag.org Thu Oct 31 22:36:08 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 31 Oct 2013 14:36:08 -0700 Subject: The symmetric ciphers In-Reply-To: <52726286.80508@vulcan.xs4all.nl> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <5271943D.9060409@vulcan.xs4all.nl> <5271D400.6050006@sixdemonbag.org> <52726286.80508@vulcan.xs4all.nl> Message-ID: <20131031143608.Horde.s6jAFhmC7BMfti6Tq2kSdw9@mail.sixdemonbag.org> > Playing Captain Obvious: Excellent! Let's play more. > - \forall {A,B \in G} --> A X B \in G: G is closed. What's this "\forall" and "\in"? I don't understand. Are those HTML entity codes that my email client isn't presenting properly? ... Or, in other words, your very first line assumes a level of mathematical knowledge that the overwhelming majority of people lack: namely, the abilities of understanding mathematical notion and TeX. Likewise with your answer about how it must uphold the associative property: a lot of people are going to conflate associativity with commutativity. Abstract mathematics is the sort of thing that needs to be avoided at all costs when giving explanations to non-specialists. It just doesn't work. > I don't doubt that. I assumed (yes I know, assumption is the mother of > all fuckups) that these things were analyzed during the long > cryptanalysis the algorithms in gpg have had. Quite possibly not, as whether AES is a group has absolutely no bearing on how easy it is to break AES -- only on whether AES can be used in composition, which is not particularly high priority. The reason why the cryptanalytic community looked into whether DES forms a group is because the 56-bit keyspace was too short and we critically needed a way to compose DES into a stronger algorithm. That's not the case with AES. A quick search of Google Scholar does not turn up any articles about whether AES forms a group. I don't know one way or another. My suspicion is that it does not, but I'm not willing to trust that suspicion. > Did noone researched something like 3AES yet? Not to my knowledge. > However, encrypting a message with AES with key1 and then encrypting it > again with key2 (key1 unrelated to key2) can't make it less secure since > any attacker can encrypt the intercepted encrypted message again with > little effort. Beware of saying "can't" unless you've got a formal mathematical proof in your hands. Even then, salt your pronouncements with "at our present level of ignorance." It is true that one of AES's design goals was exactly as you say above. However, there is no proof that they succeeded. A lot of eminent mathematicians think it's overwhelmingly probable they succeeded, but I'm unaware of anyone who believes this has been proven. From rjh at sixdemonbag.org Thu Oct 31 22:38:37 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 31 Oct 2013 14:38:37 -0700 Subject: The symmetric ciphers In-Reply-To: <20131031153725.91FF8C0617@smtp.hushmail.com> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <5271943D.9060409@vulcan.xs4all.nl> <5271D400.6050006@sixdemonbag.org> <52726286.80508@vulcan.xs4all.nl> <20131031153725.91FF8C0617@smtp.hushmail.com> Message-ID: <20131031143837.Horde.jo4RWMWERi0cQkOrYHSYLA6@mail.sixdemonbag.org> > The advantage is, > that if it should ever be possible to brute force the keyspace of one key No one will ever be able to brute-force a 128-bit key until such time as we have quantum computers with 256-bit ensembles running at 3.2 kelvins and powered by stars. Consequentially, I don't think this is any advantage at all. From rjh at sixdemonbag.org Thu Oct 31 22:42:57 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 31 Oct 2013 14:42:57 -0700 Subject: 2048 or 4096 for new keys? aka defaults vs. Debian In-Reply-To: <2108273.tvUIOKmUu6@inno.berlin.laging.de> References: <20131024190545.GA20255@mail.beuc.net> <877gct41yx.fsf@alice.fifthhorseman.net> <2108273.tvUIOKmUu6@inno.berlin.laging.de> Message-ID: <20131031144257.Horde.T-dFZnyvVQIMx-c47-mphA1@mail.sixdemonbag.org> > But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia > article for AES) claims that AES-256 was down to 99.5 bits. If memory serves that's a related-key attack. (Hmm. When you've gotten to the point where you can recognize academic papers by their URLs, maybe that's a sign you need to get a hobby... sigh. Time to take up needlepoint, I guess.) Anyway. Although there's some really neat theoretical cryptanalysis against AES-256, in reality AES-256 is as solid as the Rock of Gibraltar. From free10pro at gmail.com Thu Oct 31 22:47:27 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Thu, 31 Oct 2013 14:47:27 -0700 Subject: Quotes from GPG users In-Reply-To: <5270E670.3070307@gnupg.org> References: <5270E670.3070307@gnupg.org> Message-ID: <22329476-9653-4023-ad11-20ab386bda6a@email.android.com> Sam Tuke wrote: >Hi all, > >I'm working with Werner to promote GnuPG and raise awareness. To that >end we're >collecting quotes from users - endorsements from people who know and >trust GPG, >people like you. > >If you want to help us, send your own statement about why GPG is >important to >you. Please keep it less than or equal to 130 characters, so it can be >used on >social networks. > >I'll collect them and pick the best for use now and in future. Well, here is my input for your project. I wouldn't be able to communicate sensitive documents without it. Cheers, --Paul -- PGP: 3DB6D884 From johanw at vulcan.xs4all.nl Thu Oct 31 23:00:26 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Thu, 31 Oct 2013 23:00:26 +0100 Subject: The symmetric ciphers In-Reply-To: <20131031143608.Horde.s6jAFhmC7BMfti6Tq2kSdw9@mail.sixdemonbag.org> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <5271943D.9060409@vulcan.xs4all.nl> <5271D400.6050006@sixdemonbag.org> <52726286.80508@vulcan.xs4all.nl> <20131031143608.Horde.s6jAFhmC7BMfti6Tq2kSdw9@mail.sixdemonbag.org> Message-ID: <5272D2FA.2040904@vulcan.xs4all.nl> On 31-10-2013 22:36, Robert J. Hansen wrote: > ... Or, in other words, your very first line assumes a level of > mathematical knowledge that the overwhelming majority of people lack: > namely, the abilities of understanding mathematical notion and TeX. I am quite confident the majority of the people don't understand this, but they don't need to. Someone can prove wether AES / Twofish / ... / combinations of them is a group or not, and can then explain that combinations are safer / at least as safe / less safe. Since I majored in physics and didn't get that much discrete math, I may could not even understand such a proof myself completely. But assuming the conclusion is accepted by knowledgable people I would trust the reasoning. I also didn't check the proof that DES is not a group, but I trust that if it was incorrect I would heve heard about that. The same mechanism as why I trust gpg does not contain any deliberate backdoor, even when I didn't check the entire soucre myself. > Abstract mathematics is the sort of thing that needs to be avoided at > all costs when giving explanations to non-specialists. It just doesn't > work. For non-speciallists you can stick with the conclusion: it has been proven that X is true of not true without giving details about the proof. > A quick search of Google Scholar does not turn up any articles about > whether AES forms a group. I don't know one way or another. My > suspicion is that it does not, but I'm not willing to trust that suspicion. OK, I assumed someone would have checkeds that by now. Probably I was wrong about that. >> However, encrypting a message with AES with key1 and then encrypting it >> again with key2 (key1 unrelated to key2) can't make it less secure since >> any attacker can encrypt the intercepted encrypted message again with >> little effort. > Beware of saying "can't" unless you've got a formal mathematical proof > in your hands. Any attacker can encrypt my message again with a nonrelated key (and only with a nonrelated key since they don't know the key I used). If that would make it easier to break AES then re-encrypting the message that would be a better than pure brute force attack on AES. > It is true that one of AES's design goals was exactly as you say above. > However, there is no proof that they succeeded. A lot of eminent > mathematicians think it's overwhelmingly probable they succeeded, but > I'm unaware of anyone who believes this has been proven. My argument is that even if it turns out to be not the case, that method would just be an attack on AES. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From rjh at sixdemonbag.org Thu Oct 31 23:16:07 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 31 Oct 2013 15:16:07 -0700 Subject: The symmetric ciphers In-Reply-To: <5272D2FA.2040904@vulcan.xs4all.nl> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> <52713F9F.9000207@spth.de> <20131030103907.Horde._UjoNd-rJLtK_uz3b5l8Zg5@sixdemonbag.org> <5271943D.9060409@vulcan.xs4all.nl> <5271D400.6050006@sixdemonbag.org> <52726286.80508@vulcan.xs4all.nl> <20131031143608.Horde.s6jAFhmC7BMfti6Tq2kSdw9@mail.sixdemonbag.org> <5272D2FA.2040904@vulcan.xs4all.nl> Message-ID: <20131031151607.Horde.Yk7Djt4bCkh-nfeFp6ZZDg1@mail.sixdemonbag.org> > I am quite confident the majority of the people don't understand this, > but they don't need to. Someone can prove wether AES / Twofish / ... / > combinations of them is a group or not, and can then explain that > combinations are safer / at least as safe / less safe. Yes. But please remember how this entire subthread started. Someone proposed stacking ciphers. I answered that was not guaranteed to work, and used ROT as an example. You responded that the only reason it fails with ROT is because ROT forms a group. To which I responded with: so what? To my knowledge nobody's proven AES does not form a group, either, and incidentally, let's avoid talk about abstract mathematics because it's unnecessary to the discussion and only serves to make our conversation opaque to people who are not mathematicians. > For non-speciallists you can stick with the conclusion: it has been > proven that X is true of not true without giving details about the proof. Yes. And I repeat: you cannot blithely stack ciphers together because doing so may be harmful to the overall security of the system. And that's all that most people on the list need to know, really, without a side discussion about group theory. > Any attacker can encrypt my message again with a nonrelated key (and > only with a nonrelated key since they don't know the key I used). If > that would make it easier to break AES then re-encrypting the message > that would be a better than pure brute force attack on AES. Yes, I know. Even if I didn't, you explained it quite well in your message and I would've learned. I don't disagree with your conclusion. I disagree with your *certainty*.