From hhhobbit at securemecca.net Sun Sep 1 01:24:43 2013 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Sat, 31 Aug 2013 23:24:43 +0000 Subject: Recommended key size for life long key In-Reply-To: References: Message-ID: <52227B3B.1020708@securemecca.net> On 08/31/2013 08:27 PM, Anthony Papillion wrote: > Personally, I trust my 4096 bit key for now until ECC is integrated > into GnuPG. Then, I'll recreate my keys. Looking for a key that will > never be broken is like looking for the fountain of youth: it's a nice > idea but not realistic to plan your life around. Security is always > moving. You have to be prepared to move with it. And I was flamed for suggesting a 4096 bit key just a short six years ago. Currently I am using 2048R/2048R but I don't have top-secret needs. You should tailor your keys lengths and other factors to both yours AND OTHERS needs. The last time I checked I wasn't enciphering top-secret level embassy communiques. Make your keys to match their intended uses and part of that is what others can handle. But other than your key size maybe being too large for an iPhone (currently) all the rest of the advice you have given here is good. I noticed my previous 4096R/4096R did take a little bit of time and would not be appropriate for a person with s single core CPU so my current keys are 2048R/2048R so they can handle it. I especially like your fountain of youth analogy. It lets people know that there is no totally secure. There is only what is currently best for yours and others you communicate with needs. My main concern is that they don't upload those keys instantly to the key-servers after creating them. Play around with them for a while. Many people create keys with the following factors - no expire date - my current ones were for ten years but I can always revoke them if the key sizes finally become too small. They have lasted 2+ years now and I see no reason for them not to last at least another 3-5 years. But the day will come when they will no longer be adequate. There is no such thing as keys that can be used forever. - key sizes too large for THEIR needs and most especially for other people's needs. The key size really should be created to match OTHER people's needs more than yours. - passphrases that are either too short and simple or the opposite of being so long and and convoluted that even a top Jeopardy champion couldn't remember them. - no thought or knowledge of changing the preferences of their ciphers, digests and other factors. It isn't just the key sizes. http://www.securemecca.com/public/GnuPG/GnuPG_Prefs.txt - uploaded WAY too soon to the key-servers without playing around with them for a while. This last issue is CRITICAL. They just don't understand the need to play and think for a sufficiently long time. They want to use what they have with others immmediately. LEARN PATIENCE! - don't immediately generate a key revoke and encipher the revoke file. I think most beginners would actually be better off with writing down their pass-phrase and storing it in a safety box but at the same time giving their keys a reasonable expire date. That is better than a key that they don't use enough, forget the pass-phrase, and then their key is lodged on the key-servers forever with no expration date and no chance for it to gracefully expire and pass on into history. It would also give them the opportunity to revoke the keylater on. I know. I said they should generate a revoke key file but they didn't do it. But at least with with the pass-phrase in a strong box they have the opportunity to revoke and upload the revoked keys to the key-servers. The 10K bit key size being spoken should be a play-toy to find out why it should NOT be used. That ten minutes to generate with the hottest CPU out there would probably be a pain for me even with my dual-core and lower level quad-core systems. I suspect it may take as long as ten seconds to verify a signed message. They would have no problems sending me an enciphered message with my shorter 2048R key and even a TWOFISH cipher. But I would suspect me sending them a PK enciphered message even with a CAST5 symmetric cipher as their first choice would take a LONG time. For an iPhone user it would be utterly impossible. PITA my foot! Just remember there are probably more iPhone users now than there are PC owners. HHH -------------- 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 Sun Sep 1 02:43:15 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 31 Aug 2013 20:43:15 -0400 Subject: Recommended key size for life long key In-Reply-To: References: Message-ID: <52228DA3.3090103@sixdemonbag.org> On 08/31/2013 05:46 AM, Ole Tange wrote: > The FAQ http://www.gnupg.org/faq/GnuPG-FAQ.html#what-is-the-recommended-key-size > recommends a key size of 1024 bits. > > Reading http://www.keylength.com/en/4/ I am puzzled why GnuPG recommends that. It shouldn't; NIST recommends 2048 bits for 20 years of security. NIST notably makes no recommendations past 20 years, as they are deeply skeptical of their ability to forecast out that far. I suspect your ability is no greater than theirs is, so I'd be very careful about declaring a 10K key to be greater than your natural lifespan. Per NIST, a 2048-bit key is of comparable difficulty to breaking 3DES. Given the tremendous level of confidence people have in the long-term suitability of 3DES, I am convinced a 2048-bit key will outlast my ability to remember the passphrase to it. From josef at netpage.dk Sun Sep 1 13:12:20 2013 From: josef at netpage.dk (Josef Schneider) Date: Sun, 1 Sep 2013 13:12:20 +0200 Subject: Recommended key size for life long key In-Reply-To: <52228DA3.3090103@sixdemonbag.org> References: <52228DA3.3090103@sixdemonbag.org> Message-ID: I just use 4096 bit because that is the biggest size my OpenPGP Cards can handle. In my opinion using a smart card instead of online keys increase security far more than strange large key sizes! I also see no point using less than 4096 because modern hardware is fast enough. Maybe my keys last longer that way. Am 01.09.2013 02:43 schrieb "Robert J. Hansen" : > On 08/31/2013 05:46 AM, Ole Tange wrote: > > The FAQ > http://www.gnupg.org/faq/GnuPG-FAQ.html#what-is-the-recommended-key-size > > recommends a key size of 1024 bits. > > > > Reading http://www.keylength.com/en/4/ I am puzzled why GnuPG > recommends that. > > It shouldn't; NIST recommends 2048 bits for 20 years of security. > > NIST notably makes no recommendations past 20 years, as they are deeply > skeptical of their ability to forecast out that far. I suspect your > ability is no greater than theirs is, so I'd be very careful about > declaring a 10K key to be greater than your natural lifespan. > > Per NIST, a 2048-bit key is of comparable difficulty to breaking 3DES. > Given the tremendous level of confidence people have in the long-term > suitability of 3DES, I am convinced a 2048-bit key will outlast my > ability to remember the passphrase to it. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas.cole at gmail.com Sun Sep 1 14:18:12 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 1 Sep 2013 13:18:12 +0100 Subject: Recommended key size for life long key In-Reply-To: References: <52228DA3.3090103@sixdemonbag.org> Message-ID: On Sun, Sep 1, 2013 at 12:12 PM, Josef Schneider wrote: > I just use 4096 bit because that is the biggest size my OpenPGP Cards can > handle. In my opinion using a smart card instead of online keys increase > security far more than strange large key sizes! > I also see no point using less than 4096 because modern hardware is fast > enough. Maybe my keys last longer that way. > > One of the problems that this kind of discussion highlights is that moving to new keys is a real pest. People keep keys long after they really should and are reluctant to change keys because getting a given key certified and trusted is a pain - even with the web of trust. In a more ideal world, no one would want a key to last longer than a few years, and replacing keys at regular intervals would be the norm. -------------- next part -------------- An HTML attachment was scrubbed... URL: From werewolf6851 at gmail.com Sun Sep 1 19:12:33 2013 From: werewolf6851 at gmail.com (Werewolf) Date: Sun, 1 Sep 2013 12:12:33 -0500 Subject: Recommended key size for life long key In-Reply-To: References: <52228DA3.3090103@sixdemonbag.org> Message-ID: <20130901171233.GA3554@Vixen> On Sun, Sep 01, 2013 at 01:18:12PM +0100, Nicholas Cole wrote: > On Sun, Sep 1, 2013 at 12:12 PM, Josef Schneider wrote: > > > I just use 4096 bit because that is the biggest size my OpenPGP Cards can > > handle. In my opinion using a smart card instead of online keys increase > > security far more than strange large key sizes! > > I also see no point using less than 4096 because modern hardware is fast > > enough. Maybe my keys last longer that way. > > > > > One of the problems that this kind of discussion highlights is that moving > to new keys is a real pest. People keep keys long after they really should > and are reluctant to change keys because getting a given key certified and > trusted is a pain - even with the web of trust. > > In a more ideal world, no one would want a key to last longer than a few > years, and replacing keys at regular intervals would be the norm. I carried a 1024 bit key for 5 years (2004-2009). For me it was easy to change over to newer size in 2009 because never been able to get my key signed. Next set made use of sub keys, in hopes of futur getting them signed, and just using bigger/better sub keys as need arose. Alas, 5 years later and still not found any other gpg uses so no signatures. Wolf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From johanw at vulcan.xs4all.nl Sun Sep 1 21:45:07 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 01 Sep 2013 21:45:07 +0200 Subject: Recommended key size for life long key In-Reply-To: References: <52228DA3.3090103@sixdemonbag.org> Message-ID: <52239943.7020404@vulcan.xs4all.nl> On 1-9-2013 14:18, Nicholas Cole wrote: > In a more ideal world, no one would want a key to last longer than a few > years, and replacing keys at regular intervals would be the norm. Why? What's the advantage of that? I replace keys after I they have a chance of being compromised, but not before. Same for my mail domain - I created a ssh certificate that is valid for 50 years (unlimited was not an option) and I'll replace it whan I fear intrusions or crypto breakthroughs make it unsecure. Not before. Your advice makes me think of company password policies where you have to change it every month, leading to 01, 02, ..., 12. Complete waste of effort. -- Met vriendelijke groet / With kind regards, Johan Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From ivangrunt09 at gmail.com Sun Sep 1 21:51:25 2013 From: ivangrunt09 at gmail.com (Larry Brower) Date: Sun, 01 Sep 2013 14:51:25 -0500 Subject: Recommended key size for life long key In-Reply-To: <52239943.7020404@vulcan.xs4all.nl> References: <52228DA3.3090103@sixdemonbag.org> <52239943.7020404@vulcan.xs4all.nl> Message-ID: <52239ABD.6040506@gmail.com> On 09/01/2013 02:45 PM, Johan Wevers wrote: > Why? What's the advantage of that? I replace keys after I they have a > chance of being compromised, but not before. Same for my mail domain - I > created a ssh certificate that is valid for 50 years (unlimited was not > an option) and I'll replace it whan I fear intrusions or crypto > breakthroughs make it unsecure. Not before. > The longer a key is in use the greater the chance of compromise. Just because you believe it has not been compromised doesn't make it so. By regenerating keys every so often you drastically lessen the chances of a key being compromised or of a possible compromise having as much effect on you. There is a reason things like IPSEC keys are renegotiated after so many minutes or after so many bytes are transmitted. :) -- Larry Brower, CCNA Fedora Ambassador - North America Fedora Quality Assurance lbrower at fedoraproject.org http://www.fedoraproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x0806CF8B.asc Type: application/pgp-keys Size: 3167 bytes Desc: not available URL: From martin at hvidberg.net Sun Sep 1 14:57:57 2013 From: martin at hvidberg.net (MartinHvidberg) Date: Sun, 1 Sep 2013 05:57:57 -0700 (PDT) Subject: Can I revitalise an old key-pair? Message-ID: <1378040277596-32165.post@n7.nabble.com> I'm returning to GPG, and Enigmail, and not for the first time. This means that I have earlier generated key-pairs and uploaded them to servers like keys.pgp.net or something like that. I did this first time in 1999 and have done several new attempts later, and now have seven key-pairs on the server. Latest I have generated a key-pair in 2011. Unfortunately, every time my use of GPG fades out, because non of my contacts really join in. And it's not much fun exchanging signed and encrypted mails with myself :-) This time, with all the media on governments peeping into peoples private mails, I think I have a better chance to get many of my friends to jump on-bord. My problem: I stead of generating yet another key-pair, how do I revitalise on of my existing key-pairs. This said, I have only what I can download from a key-server, and I do in fact remember the password, for some of them. Do the key-server have all the information I need to re-use an existing key-pair (provided I remember the password)? Or do I need to get one of my old computers up and running, hoping to find some sort of key file there. If you can point to any online material, tutorial or the likes, that do not start with 'Generate a key-pair' then I would appreciate the a lot... :-) Best regards Martin Hvidberg Latest fingerprint: D3DA 61B7 610C E8A1 75C7 1DA1 0B24 7DB3 4AF0 1B83 -- View this message in context: http://gnupg.10057.n7.nabble.com/Can-I-revitalise-an-old-key-pair-tp32165.html Sent from the GnuPG - User mailing list archive at Nabble.com. From pete at heypete.com Sun Sep 1 23:15:35 2013 From: pete at heypete.com (Pete Stephenson) Date: Sun, 1 Sep 2013 23:15:35 +0200 Subject: Can I revitalise an old key-pair? In-Reply-To: <1378040277596-32165.post@n7.nabble.com> References: <1378040277596-32165.post@n7.nabble.com> Message-ID: On Sun, Sep 1, 2013 at 2:57 PM, MartinHvidberg wrote: > I'm returning to GPG, and Enigmail, and not for the first time. This means > that I have earlier generated key-pairs and uploaded them to servers like > keys.pgp.net or something like that. I did this first time in 1999 and have > done several new attempts later, and now have seven key-pairs on the server. > Latest I have generated a key-pair in 2011. While it can be tempting to use particularly old keys (such as those made in 1999), the maximum length at the time (1024-bit DSA keys) makes them borderline too-short for modern usage. Even if you regain access to your 1999-era secret key, you should probably consider transitioning to a new, stronger keypair. See http://www.debian-administration.org/users/dkg/weblog/48 for some useful information on the subject. > My problem: > I stead of generating yet another key-pair, how do I revitalise on of my > existing key-pairs. > This said, I have only what I can download from a key-server, and I do in > fact remember the password, for some of them. The keyservers only store the public part of your key. This is not sufficient to derive the secret key (if it was, that'd be a Bad Thing). If you do not have your secret key that corresponds to the public key you wish to, as you say, revitalize, then there's nothing you can do except create a new keypair. That, or develop some major advancements in the field of mathematics that would allow you to derive the secret key from the public key (which would break the whole system, rendering the exercise moot). > Do the key-server have all the information I need to re-use an existing > key-pair (provided I remember the password)? Unfortunately not. > Or do I need to get one of my old computers up and running, hoping to find > some sort of key file there. If you go through your old systems and are able to find the relevant secret key files or the GPG/PGP keyring files, then you can continue using that keypair. If you cannot find the secret key, you'll need to create a new keypair. :/ > If you can point to any online material, tutorial or the likes, that do not > start with 'Generate a key-pair' then I would appreciate the a lot... :-) I suppose the only step that'd come before that would be "find your secret key". If you can't do that, you're sort of hosed. :) From johanw at vulcan.xs4all.nl Sun Sep 1 23:47:24 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 01 Sep 2013 23:47:24 +0200 Subject: Can I revitalise an old key-pair? In-Reply-To: References: <1378040277596-32165.post@n7.nabble.com> Message-ID: <5223B5EC.1090801@vulcan.xs4all.nl> On 01-09-2013 23:15, Pete Stephenson wrote: > While it can be tempting to use particularly old keys (such as those > made in 1999), the maximum length at the time (1024-bit DSA keys) PGP 2.6 existed already in that time, with a maximum keysize of 2048 bit RSA. Those were v3 keys but still perfectly usable. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From John at enigmail.net Mon Sep 2 00:06:04 2013 From: John at enigmail.net (John Clizbe) Date: Sun, 01 Sep 2013 17:06:04 -0500 Subject: Can I revitalise an old key-pair? In-Reply-To: References: <1378040277596-32165.post@n7.nabble.com> Message-ID: <5223BA4C.7060600@enigmail.net> Pete Stephenson wrote: > On Sun, Sep 1, 2013 at 2:57 PM, MartinHvidberg wrote: >> Or do I need to get one of my old computers up and running, hoping to find >> some sort of key file there. > > If you go through your old systems and are able to find the relevant > secret key files or the GPG/PGP keyring files, then you can continue > using that keypair. If you cannot find the secret key, you'll need to > create a new keypair. :/ > On *nix and similar systems (MacOSX, Cygwin) GnuPG stores keyring files in ~/.gnupg (~ = your login directory: /home/ or /Users/) On Windows XP and older, keyring files were stored in :\Documents and Settings\\Application Data\Gnupg Windows Vista and newer versions use :\Users\\AppData\Roaming\gnupg You'll want the contents for all of the directories you can find. A tool such as the linux-based SystemRescueCD [http://www.sysresccd.org/? ] makes this task somewhat easier. You should be able to use the newest set of keyring files directly. The keys in the older keyring files may be imported later. -- 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: 865 bytes Desc: OpenPGP digital signature URL: From werewolf6851 at gmail.com Mon Sep 2 04:17:55 2013 From: werewolf6851 at gmail.com (Werewolf) Date: Sun, 1 Sep 2013 21:17:55 -0500 Subject: Can I revitalise an old key-pair? In-Reply-To: <1378040277596-32165.post@n7.nabble.com> References: <1378040277596-32165.post@n7.nabble.com> Message-ID: <20130902021755.GA14818@Vixen> On Sun, Sep 01, 2013 at 05:57:57AM -0700, MartinHvidberg wrote: > I'm returning to GPG, and Enigmail, and not for the first time. This means > that I have earlier generated key-pairs and uploaded them to servers like > keys.pgp.net or something like that. I did this first time in 1999 and have > done several new attempts later, and now have seven key-pairs on the server. > Latest I have generated a key-pair in 2011. > > Unfortunately, every time my use of GPG fades out, because non of my > contacts really join in. And it's not much fun exchanging signed and > encrypted mails with myself :-) > > This time, with all the media on governments peeping into peoples private > mails, I think I have a better chance to get many of my friends to jump > on-bord. > > My problem: > I stead of generating yet another key-pair, how do I revitalise on of my > existing key-pairs. > This said, I have only what I can download from a key-server, and I do in > fact remember the password, for some of them. > Do the key-server have all the information I need to re-use an existing > key-pair (provided I remember the password)? > > Or do I need to get one of my old computers up and running, hoping to find > some sort of key file there. > > If you can point to any online material, tutorial or the likes, that do not > start with 'Generate a key-pair' then I would appreciate the a lot... :-) > > Best regards > Martin Hvidberg > > Latest fingerprint: D3DA 61B7 610C E8A1 75C7 1DA1 0B24 7DB3 4AF0 1B83 Cheers Martin. You will have to find your old keys on one of your machines. Otherwise make a new pair. hint if make new pair, make a revoke cert for it, but saved in a safe place. So you can revoke it if you lose the secret key/passphrase. And for more paraniod leaning about key stubs (secret key without main key, just the sub keys) http://tjl73.altervista.org/secure_keygen/keygen_frame_en.html Wolf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From hhhobbit at securemecca.net Mon Sep 2 06:04:23 2013 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Mon, 02 Sep 2013 04:04:23 +0000 Subject: Can I revitalise an old key-pair? In-Reply-To: References: <1378040277596-32165.post@n7.nabble.com> Message-ID: <52240E47.1090402@securemecca.net> On 09/01/2013 09:15 PM, Pete Stephenson wrote: > On Sun, Sep 1, 2013 at 2:57 PM, MartinHvidberg wrote: >> I'm returning to GPG, and Enigmail, and not for the first time. This means >> that I have earlier generated key-pairs and uploaded them to servers like >> keys.pgp.net or something like that. I did this first time in 1999 and have >> done several new attempts later, and now have seven key-pairs on the server. >> Latest I have generated a key-pair in 2011. > > While it can be tempting to use particularly old keys (such as those > made in 1999), the maximum length at the time (1024-bit DSA keys) > makes them borderline too-short for modern usage. Even if you regain > access to your 1999-era secret key, you should probably consider > transitioning to a new, stronger keypair. See > http://www.debian-administration.org/users/dkg/weblog/48 for some > useful information on the subject. Pete, it is not your advice which I agree with whole-heartedly but Debian's choice of order for their digests and to a certain extent their symmetric ciphers where they made the unwarranted assumption that bigger is better and biggest is best. Remember the person on the other side may NOT have your latest and greatest umpteen-core machine. Taking those people into account this may be better choice (and is NOT what I use but is close): setpref SHA256 SHA512 SHA384 SHA224 Actually I have SHA1 as the option before SHA384 and don't have SHA224 due to some statements that lead me to believe it could cause problem. Maybe there wouldn't be problems. But what if SHA1 is all they can do? Okay, you can do it but I don't like it. But SHA1 is better than nothing especially if it is for just a one-off message. The reason why is if you pick SHA512 first, while more secure (unless the argument that they are all vulnerable to the same attack since they are all the same family) your detached signatures will be awfully large. SHA384 and SHA224 may have limited or no support. Paradoxically, AES256 & AES192 had weaknesses that made them less safe than AES (AES-128) several years back. May I humbly suggest TWOFISH or one of the CAMELLLIA ciphers as a first choice UNTIL you determine whether or not the fixes for AES-256 and AES-192 are retroactive? DID THEY GET THEM FIXED? I am just assuming they did but that means I HOPE the older implementation and the newer one can easily be discerned when you do the decipher. If that can not be done then you would have needed to decipher the old style AES-256 before the change happened and will be hosed if time rolls on and that was not done. CAST5 is a good last choice because some of the time that is all others can handle. Make sure CAST5 is always a last or next to last choice because that may be all that they can do with a limited horsepower box. You may even want 3DES as a last option for those that got stuck there for some reason. IDEA? Your call. I assume everybody can handle CAST5. http://www.securemecca.com/public/GnuPG/GnuPG_Prefs.txt Compression? The symmetric ciphers seem to always have better compression than either zlib (gzip) or zip. They are on par with either bzip2 or 7-zip (7-zip is not available in OpenPGP). I would just use and do use "Uncompressed". Even if the orginal writer can dig up their old keys (the key-servers have only the public side), do they remember their pass-phrase? I know others will disagree with me on this but that is why I say you should have (unless you work for Amnesty International, a government attache, high levels of a company with confidential data, etcetera): 1. Keys created with a time to expire. I know my 10 year lifetime is ambitious and they will probably have to be revoked before then. But keys with no expire dates are just crazy. If for no other reason a reasonable time-span (10 years is really stretching it) allows people to walk away and their old keys on the key servers will gracefully and mercifully expire. What happens if you got struck by a Peterbilt and were killed? But even if you didn't get killed you can NOT use them forever. Time marches on and what was good 10+ years ago (3DES) is no match for modern CPU power. Actually all those top-secret places should be creating keys that expire as well. Keys that last forever are an impossible hope. 2. A revoke file created with --gen-revoke redirected to a file and then the file enciphered. See number 4. 3. The pass-phrase written down on a sheet of paper and stored in a safe place. Remember this is advice for "normal" people. Did I do this with mine? No, but that is because I use them almost every day. Store this in a DIFFERENT LOCATION than where the backup of the keys and the backup of revoke are stored (see next). Ditto for the passwords of the zips. Store them with the pass-phrase, NOT with the zips. But be sure to store both where you can get them later. 4. If possible, the backup of the keys themselves in an an enciphered file, along with the enciphered revoke all put in a safety deposit box where if somebody wants to get them later and use them they can. Backups of the keys on 'nix use an xterm or some sort of terminal can use my crypt script available here (or some equivalent): http://www.securemecca.com/public/GnuPG/crypt.txt http://www.securemecca.com/public/GnuPG/decrypt.txt http://www.securemecca.com/public/GnuPG/ $ cd ; umask 077 $ tar -cf gnupg.tar ./.gnupg # the equivalent of my: $ crypt gnupg.tar # this will give you a gnupg.tar.gpg file which is what # you want to put into safe storage. # undoing, put gnupg.tar.gpg in home folder and # cd ; umask 077 $ if [ -s gnupg.tar.gpg ] then rm -f gnupg.tar decrypt gnupg.tar if [ -s gnupg.tar ] then rm -fr .gnupg # move previous .gnupg to old.gnupg tar -xvf gnupg.tar fi fi Alternatively, 7-zip could be used with its built-in AES128 bit cipher which MAY avoid a chicken versus egg problem (you are deciphering a ~/.gnupg folder which should already exist or will be created when you decipher if you use gpg or gpg2 which is not an issue if you use 7-zip): $ cd ; umask 077 $ 7za a -p gnupg.7z ./.gnupg # to undo: $ cd ; umask 077 $ if [ -s gnupg.7z ] then rm -fr .gnupg # move previous .gnupg to old.gnupg 7za x gnupg.7z fi Was any of that done? NO? Then you didn't look ahead. Do it when you generate your new keys and especially point 1. An even better option if you had done this with all your previous keys is to just revoke all your old keys one by one and upload the revoked keys to the key-servers. Then generate some new keys with reasonable (REMEMBER THE OTHERS YOU WILL INTERACT WITH) defaults. Make sure you do all of the foregoing with the new and create the backups. Put the hand-written pass-phrase and passwords for the zips some some place other than where the zips are stored but all of them in a safe place. All I know is there are a LOT of keys that will never die and NOBODY knows their pass-phrase that are on the key-servers. Actually top-secret types should decipher their stuff regularly with the old keys right before the old keys expire, revooke the keys, create new keys and then re-encipher everyting with the new keys. You just cannot expect keys created ten years ago to be sufficient for todays needs. Making huge sized keys while tantalizing just makes it a royal pain interacting with you now. 4096R/4096R is about the upper limit for now and I considered them too large when I went back to 2048R/2048R about two years ago. I could handle the 4096R pair but could others? HHH From laurent.jumet at skynet.be Mon Sep 2 05:56:47 2013 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Mon, 02 Sep 2013 05:56:47 +0200 Subject: Can I revitalise an old key-pair? In-Reply-To: <1378040277596-32165.post@n7.nabble.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello MartinHvidberg ! MartinHvidberg wrote: > My problem: > I stead of generating yet another key-pair, how do I revitalise on of my > existing key-pairs. > This said, I have only what I can download from a key-server, and I do in > fact remember the password, for some of them. > Do the key-server have all the information I need to re-use an existing > key-pair (provided I remember the password)? The keyserver holds only your public key; obviously you need the secret key at home. What you should do in my opinion, is recover all the old key pairs you are able to get (with the passphrase), and revoque them but keep them (for the case you still get a message encrypted with one of those so you can read it anyway), and send them to the servers. You can choose one existing key pair (or create a new one), with a signing (main) key allowing use of most recent signing algorithms (with a 1024 signing key you'll reach RIPEMD160 as a maximum Digest-Algo) And create subkeys from time to time, depending on the risk (keyloggers if you are using non safe PC, USB stealing), and uploading to servers. - -- Laurent Jumet KeyID: 0xCFAF704C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (MingW32) iHEEAREDADEFAlIkEB0qGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB RjcwNEMuYXNjAAoJEPUdbaDPr3BMD5gAoKJ6lC78nTGYQjyCiR+b8h02ifjlAKD4 TGa9YWsfGbGY2/JsKTKhzjSzHg== =Gl2l -----END PGP SIGNATURE----- From johanw at vulcan.xs4all.nl Mon Sep 2 11:37:08 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Mon, 02 Sep 2013 11:37:08 +0200 Subject: Can I revitalise an old key-pair? In-Reply-To: <52240E47.1090402@securemecca.net> References: <1378040277596-32165.post@n7.nabble.com> <52240E47.1090402@securemecca.net> Message-ID: <52245C44.2060208@vulcan.xs4all.nl> On 02-09-2013 6:04, Henry Hertz Hobbit wrote: > Compression? The symmetric ciphers seem to always have better > compression than either zlib (gzip) or zip. Ciphers don't compress, the data is compressed before encrypting because after encrypting it is not compressible anymore. > 1. Keys created with a time to expire. No, you can set the lifetime to infinite. Pgp v3 key's don't expire anyway. However, since the OP talks about keys from 1999, he should check wether they were made by pgp 5 for Unix (hints that this could be the case are ElGamal keys of that age). If so, a weak PRNG might be used and it might be wise to replace the keys. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From attila.lendvai at gmail.com Mon Sep 2 16:13:51 2013 From: attila.lendvai at gmail.com (attila lendvai) Date: Mon, 2 Sep 2013 07:13:51 -0700 (PDT) Subject: Transfer subkey to other keyring In-Reply-To: <51CC6E7D.4080709@nottheoilrig.com> References: <51C9DD9A.3060707@nottheoilrig.com> <87ppv9gqx1.fsf@vigenere.g10code.de> <51CB2C48.4070809@nottheoilrig.com> <87hagkdmca.fsf@vigenere.g10code.de> <51CC6E7D.4080709@nottheoilrig.com> Message-ID: <1378131231250-32188.post@n7.nabble.com> hi Jack! i think i'm struggling with the same issue. i've done this before a couple of years ago and it worked as expected... but this time i get the same results as described before me in this thread. to the best of my knowledge the secret subkeys get exported into the file properly, but import seems to ignore them. i've made sure that the public keys are there in the receiving keyring, but that wasn't the problem. any luck since then? or anything i could try? - attila -- View this message in context: http://gnupg.10057.n7.nabble.com/Transfer-subkey-to-other-keyring-tp31272p32188.html Sent from the GnuPG - User mailing list archive at Nabble.com. From nicholas.cole at gmail.com Mon Sep 2 20:28:09 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 2 Sep 2013 19:28:09 +0100 Subject: AES256 & AES192. (Was: Can I revitalise an old key-pair?) Message-ID: On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit wrote: [snip] > > Paradoxically, AES256 & AES192 had > weaknesses that made them less safe than AES (AES-128) several > years back. May I humbly suggest TWOFISH or one of the > CAMELLLIA ciphers as a first choice UNTIL you determine whether > or not the fixes for AES-256 and AES-192 are retroactive? DID > THEY GET THEM FIXED? I am just assuming they did but that means > I HOPE the older implementation and the newer one can easily be > discerned when you do the decipher. [snip] I was curious about this. The wikipedia page mentions the "Related Key Attack" on these cyphers, but is vague about whether they were ever fixed. Does anyone know? And did fixes make it into the version used by Gnupg? From Martin at Hvidberg.net Mon Sep 2 20:33:44 2013 From: Martin at Hvidberg.net (Martin Hvidberg) Date: Mon, 02 Sep 2013 20:33:44 +0200 Subject: Can I revitalise an old key-pair? In-Reply-To: <52245C44.2060208@vulcan.xs4all.nl> References: <1378040277596-32165.post@n7.nabble.com> <52240E47.1090402@securemecca.net> <52245C44.2060208@vulcan.xs4all.nl> Message-ID: <5224DA08.7070209@Hvidberg.net> Thanks all I won't get any of my old keys back, I see that :-( I can only re-establish the secret key for two of them. One I have earlier revoked (for good reasons), and another for which I no longer remember the paraphrase. Good thing is I have learned a lot about keys. I'll soon make yet a new key-set, and this time I'll be more organised and make a revoke certificate, that I'll keep in a safe place, together with the secret key, and the paraphrase. Again - thanks all, your a grate group. :-) Martin From hhhobbit at securemecca.net Tue Sep 3 00:36:28 2013 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Mon, 02 Sep 2013 22:36:28 +0000 Subject: AES256 & AES192. (Was: Can I revitalise an old key-pair?) In-Reply-To: References: Message-ID: <522512EC.8080509@securemecca.net> On 09/02/2013 06:28 PM, Nicholas Cole wrote: > On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit > wrote: > > [snip] > >> >> Paradoxically, AES256 & AES192 had >> weaknesses that made them less safe than AES (AES-128) several >> years back. May I humbly suggest TWOFISH or one of the >> CAMELLLIA ciphers as a first choice UNTIL you determine whether >> or not the fixes for AES-256 and AES-192 are retroactive? DID >> THEY GET THEM FIXED? I am just assuming they did but that means >> I HOPE the older implementation and the newer one can easily be >> discerned when you do the decipher. > > > [snip] > > I was curious about this. The wikipedia page mentions the "Related Key > Attack" on these cyphers, but is vague about whether they were ever > fixed. > > Does anyone know? > > And did fixes make it into the version used by Gnupg? Short answer - it wasn't changed and Bruce Schneier still considers AES-128 to be more secure than AES-256. Now you can tap delete. It is time for Werner, Robert, and the others to speak up. I usually tailor my statements to novices just getting started. It is just that AES-256 is NOT necessarily twice as secure as AES-128. In fact going up in bits sometimes gets you only marginal improvements that are closer to logarithmic than straight line. But this time it seems AES-256 is STILL not as secure as AES (AES-128): First of Schneier's blogs: http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html Second of Schneier's blogs: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html [Note that Serpent is referenced as a backup plan. If you look at Bruce's 1:22 PM comment he recommends AES-128 (AES) over AES-256 due to the poor key-schedule for AES-256. I changed my cipher order several weeks later with no evidence to the contrary. For novices you can do that any time you change your mind - but I have always had TWOFISH first despite his deprecating remarks about his own 32-bit world cipher.] Note the figures at the start of "Abstract". Even those are practically unbreakable. The quick fix was to use more rounds but my research is drawing a blank so I suspect nothing was done. Even so, infecting your machine or hacking into it somehow which may include personal visits and real world physical lock-picking is more likely to get them what they want than attacking any of these ciphers with ANY sort of cipher attack. There are also different ways for doing the AES family depending on where they are used with some being weaker implementations than others. E.g., in OpenSSL you cannot afford the luxury of a single machine munching away like it is in GnuPG which means GnuPG most likely has the strongest implementation of the AES family. It will be what ever is in the RFC: https://www.ietf.org/rfc/rfc4880.txt All I was pointing out was that AES-256 versus AES-128 does NOT imply AES-256 is twice as secure as AES-128. The idea that just because it is twice the size then it must be twice as secure is just a novice point of view. The quick fix was to use more rounds and I just assumed that may have been done. Evidently I assumed wrong. Most ciphers have known weaknesses. But there are lots of crypto people that work over-time on analyzing them for weaknesses. That includes a lot of people here who should speak up because they know more than me. I am too busy processing the three variants of the mini-downloader trojans and wondering why they delivered the almost same code all at once. They do a lot of experiments so it is probably to measure how much the same time reduces their effectivenes over spreading them out with as little as 8 hours or as much as 48 hours between each release. Only 1-2/47 of the AV at VirusTotal were detecting both the the zips and the exes. It takes a week or longer for detection to reach the halfway mark. Even after a month about 10-25% of the AV still won't detect and probably never will - Zeus variant mini-downloader. HHH From rjh at sixdemonbag.org Tue Sep 3 03:51:01 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 02 Sep 2013 21:51:01 -0400 Subject: AES256 & AES192. (Was: Can I revitalise an old key-pair?) In-Reply-To: <522512EC.8080509@securemecca.net> References: <522512EC.8080509@securemecca.net> Message-ID: <52254085.4010606@sixdemonbag.org> > It is time for Werner, Robert, and the others to speak up. I don't know why I need to speak up. I haven't done any serious crypto work in almost a decade now. I am not an authority on these matters. At best, I can give a semi-informed perspective on things -- but that's about it. > http://www.schneier.com/blog/archives/2009/07/another_new_aes.html > [Note that Serpent is referenced as a backup plan. If you look > at Bruce's 1:22 PM comment he recommends AES-128 (AES) over > AES-256 due to the poor key-schedule for AES-256. You're misquoting him. "For new applications I suggest that people don't use AES-256. AES-128 provides more than enough security margin for the forseeable future. But if you're already using AES-256, there's no reason to change." So, my response to this is a shrug. If you're already using AES-256, go on and keep using it: there's no reason to change. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From johanw at vulcan.xs4all.nl Tue Sep 3 05:21:24 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 03 Sep 2013 05:21:24 +0200 Subject: AES256 & AES192. (Was: Can I revitalise an old key-pair?) In-Reply-To: <522512EC.8080509@securemecca.net> References: <522512EC.8080509@securemecca.net> Message-ID: <522555B4.9090108@vulcan.xs4all.nl> On 03-09-2013 0:36, Henry Hertz Hobbit wrote: > started. It is just that AES-256 is NOT necessarily twice > as secure as AES-128. That would be really strange - if you define "twice as secure" as meaning "it will take on avarage twice as long to crack the crypto", than adding one byte to the keylength should do that for symetric algorithms (for pubkey algorighms like RSA / ElGamal / ECC it works differently). If there were no algorithmic weaknesses AES256 would be 2^128 times as secure as AES128. In this case I read is that this number is less, but I assume still very, very large. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From kententen at me.com Tue Sep 3 04:27:36 2013 From: kententen at me.com (Kenneth Jones) Date: Tue, 03 Sep 2013 10:27:36 +0800 Subject: Can I revitalise an old key-pair? In-Reply-To: <5224DA08.7070209@Hvidberg.net> References: <1378040277596-32165.post@n7.nabble.com> <52240E47.1090402@securemecca.net> <52245C44.2060208@vulcan.xs4all.nl> <5224DA08.7070209@Hvidberg.net> Message-ID: <0117DE91-6C7F-4FC0-9B0A-379DB33242FB@me.com> That was one of the troubles with us humans and PGP. We'd be all excited about creating a new key pair and testing it and stuff, but the admonition to choose a good passphrase was too well delivered, at least for me. Reminds me of that sign above the desk "My work is so secret, even I don't know what I'm doing." And since the only way to convince a key server that you were you was to possess the secret key (and it's passphrase), having forgotten the key to the key, so to speak, there are several (?!?) keys on the various keyservers that no longer can be used...or revoked. Which is why I have keys going back to the nineties, just gathering dust. I think PGP dot com has (had?) a verification arrangement, whereby if you didn't confirm that the key was your and you still wanted to list it, they would remove it from the server...housecleaning. -- I use openPGP encryption when possible. My current KeyID is: 0xE255 7AA7. I encourage you to use encrypted mail. Search "Open PGP, GPG, or GnuPG" for details. No third party has a right to my communication. On Sep 3, 2013, at 2:33 AM, Martin Hvidberg wrote: > Thanks all > > I won't get any of my old keys back, I see that :-( <> From pete at heypete.com Tue Sep 3 11:07:24 2013 From: pete at heypete.com (Pete Stephenson) Date: Tue, 3 Sep 2013 11:07:24 +0200 Subject: AES256 & AES192. (Was: Can I revitalise an old key-pair?) In-Reply-To: References: Message-ID: On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole wrote: > On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit > wrote: > > [snip] > >> >> Paradoxically, AES256 & AES192 had >> weaknesses that made them less safe than AES (AES-128) several >> years back. May I humbly suggest TWOFISH or one of the >> CAMELLLIA ciphers as a first choice UNTIL you determine whether >> or not the fixes for AES-256 and AES-192 are retroactive? DID >> THEY GET THEM FIXED? I am just assuming they did but that means >> I HOPE the older implementation and the newer one can easily be >> discerned when you do the decipher. > > > [snip] > > I was curious about this. The wikipedia page mentions the "Related Key > Attack" on these cyphers, but is vague about whether they were ever > fixed. > > Does anyone know? > > And did fixes make it into the version used by Gnupg? Even more importantly, were they ever an issue with GnuPG in the first place? That is, does GnuPG generate related keys? I was always under the impression that GnuPG randomly generated session keys rather than creating related session keys; if true, wouldn't this mean that the related-key attack doesn't apply? In regards to fixing the cipher, I'm not really sure that one can just issue a patch that would update the cipher itself (as opposed to a specific implementation of it): the cipher is standardized and is implemented in both hardware and software in zillions of devices and programs around the world. Adding more rounds or changing its functionality in some way to counter this attack would cause that changed version to diverge from the standard and it presumably not interoperate with standard AES. Cheers! -Pete -- Pete Stephenson From nicholas.cole at gmail.com Tue Sep 3 15:39:40 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 3 Sep 2013 14:39:40 +0100 Subject: AES256 & AES192. (Was: Can I revitalise an old key-pair?) In-Reply-To: References: Message-ID: On Tue, Sep 3, 2013 at 10:07 AM, Pete Stephenson wrote: > On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole wrote: >> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit >> wrote: >> >> [snip] >> >>> >>> Paradoxically, AES256 & AES192 had >>> weaknesses that made them less safe than AES (AES-128) several >>> years back. May I humbly suggest TWOFISH or one of the >>> CAMELLLIA ciphers as a first choice UNTIL you determine whether >>> or not the fixes for AES-256 and AES-192 are retroactive? DID >>> THEY GET THEM FIXED? I am just assuming they did but that means >>> I HOPE the older implementation and the newer one can easily be >>> discerned when you do the decipher. >> >> >> [snip] >> >> I was curious about this. The wikipedia page mentions the "Related Key >> Attack" on these cyphers, but is vague about whether they were ever >> fixed. >> >> Does anyone know? >> >> And did fixes make it into the version used by Gnupg? > > Even more importantly, were they ever an issue with GnuPG in the first place? > > That is, does GnuPG generate related keys? > > I was always under the impression that GnuPG randomly generated > session keys rather than creating related session keys; if true, > wouldn't this mean that the related-key attack doesn't apply? And if that were true, I presume that would mean that the "AES is stronger than AES256" argument would also fall. Or have I misunderstood? N. From peter at digitalbrains.com Tue Sep 3 18:49:07 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 03 Sep 2013 18:49:07 +0200 Subject: Security of 3DES In-Reply-To: <52240E47.1090402@securemecca.net> References: <1378040277596-32165.post@n7.nabble.com> <52240E47.1090402@securemecca.net> Message-ID: <52261303.1030303@digitalbrains.com> My main point is furtheron because I reply inline On 02/09/13 06:04, Henry Hertz Hobbit wrote: > CAST5 is a good last choice because some of the time that is all others can > handle. Make sure CAST5 is always a last or next to last choice because that > may be all that they can do with a limited horsepower box. I have to assume "can handle" here means: get good encryption speed. Because: > You may even want 3DES as a last option for those that got stuck there for > some reason. We /are/ talking OpenPGP here, so any implementation is required to be able to handle 3DES. There is no OpenPGP-conformant implementation that will do CAST5 but not 3DES. Also, 3DES is always in your preference list; if not explicitly, it's implicitly added as the least-preferred algorithm (i.e., at the end of the list). > Compression? The symmetric ciphers seem to always have better compression > than either zlib (gzip) or zip. To expand on what Johan Wevers said: symmetric ciphers do not change the length of the encrypted text (by more than the block size). They certainly do not compress. Usually, data is compressed before encrypting it (compressing it after is pretty useless). If you set your key preferences to not allow compression, files encrypted to your key will not be smaller than the original files. > Time marches on and what was good 10+ years ago (3DES) is no match for modern > CPU power. *Here is my main point* which made me decide to reply. 3DES is safe. It's incredibly safe! How is it no match for modern CPU power? There are no practical attacks on 3DES. What are you trying to say? > 4. If possible, the backup of the keys themselves in an an enciphered file A passphrase on a key is already encryption and it is useless to encrypt it more beyond that. > Alternatively, 7-zip could be used with its built-in AES128 bit cipher ... which just creates a useless dependency on a piece of software you might not be able to get for your computer in 10 or 20 years, IMHO. Put a passphrase on the key and presto, nothing more needed. 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 mustrum at mustrum.net Tue Sep 3 11:46:43 2013 From: mustrum at mustrum.net (Mustrum) Date: Tue, 03 Sep 2013 11:46:43 +0200 Subject: No subject Message-ID: <9defccbb-83e1-4840-8d4a-79388b9d5d85@email.android.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone. The last gpg-agent supports ECDSA and putty's pageant. But, does it support ECDSA for putty/pageant ? Regards. -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQI7BAEBCAAlBQJSJbADHhxNdXN0cnVtIDxNdXN0cnVtQE11c3RydW0ubmV0PgAK CRBMuv2GX9WDnh40D/9Zf8Mho4GYBedjrKBhPq6CXLr+fBmla/VFbKa08NNDJ+Jg kA0cD/CWo/3N5QgY7bSzkzHPHFz3X3zleL/+glGci7ILgybtow8d8M6TEaxg5uUk kAsxd6As9sdTGVJqhSHwX4f6o214izkjNFl710YWqwzXqIyyf5N40jnhrNBwodvN RGIYaqIgFULRUqC8G6FOnMqGv4Oz+JOwJuwbNu/qoYDMMZ8FckOdaM0CUnpOswyY SwZTYoArFKYnzwTiEr8OEtmqEczybdgkQzeeay25cbCqZncEC0lFXizfRZl1/mBS wW4m9WrTaMuBlbJ/maHy6twAxL6PxZiQaDg8065tK060PUM1MtunTJcjZbgtRpMj culIrtlKi68rwhvVGaEp1MOSgdBKdv1gIlSizyyGwtxTZd3ZzF1QLX42JFdftNvu H5YzfG1EVTamIn7Vz0JC+cJmjnrZ54dTIDqnBe5zXc+5EFXbmIkWIOjScZzbmkcc BtyUonwFM876SGp8i0FQNgdL2ugLi4Az5yBSzNsSQqkFEbn5i0ZrEXA6ANcLBepJ mgfT3N7SuB2MygdUSVSqLCINO+LoPvAhOotsDoBuI5+H5KaaLRbSfk0nvjbhrECV 8kWpZn54BO7LgHx3YDDK5ZZBGWRLMHqNEGuYtVsoDr/G8eFDt7DeXH+2JsiNcA== =ZwEs -----END PGP SIGNATURE----- From nicholas.cole at gmail.com Tue Sep 3 21:38:23 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 3 Sep 2013 20:38:23 +0100 Subject: AES256 & AES192. (Was: Can I revitalise an old key-pair?) In-Reply-To: References: Message-ID: On Tuesday, 3 September 2013, Nicholas Cole wrote: > On Tue, Sep 3, 2013 at 10:07 AM, Pete Stephenson > > wrote: > > On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole > > wrote: > >> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit > >> > wrote: > >> > >> [snip] > >> > >>> > >>> Paradoxically, AES256 & AES192 had > >>> weaknesses that made them less safe than AES (AES-128) several > >>> years back. May I humbly suggest TWOFISH or one of the > >>> CAMELLLIA ciphers as a first choice UNTIL you determine whether > >>> or not the fixes for AES-256 and AES-192 are retroactive? DID > >>> THEY GET THEM FIXED? I am just assuming they did but that means > >>> I HOPE the older implementation and the newer one can easily be > >>> discerned when you do the decipher. > >> > >> > >> [snip] > >> > >> I was curious about this. The wikipedia page mentions the "Related Key > >> Attack" on these cyphers, but is vague about whether they were ever > >> fixed. > >> > >> Does anyone know? > >> > >> And did fixes make it into the version used by Gnupg? > > > > Even more importantly, were they ever an issue with GnuPG in the first > place? > > > > That is, does GnuPG generate related keys? > > > > I was always under the impression that GnuPG randomly generated > > session keys rather than creating related session keys; if true, > > wouldn't this mean that the related-key attack doesn't apply? > > And if that were true, I presume that would mean that the "AES is > stronger than AES256" argument would also fall. Or have I > misunderstood? > While reading up on all of this I found this piece (concerning a very widely used piece of software for Mac OS and iOS) on the switch to AES256. I thought others would find it useful. http://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Sep 3 22:47:47 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 03 Sep 2013 16:47:47 -0400 Subject: Security of 3DES In-Reply-To: <52261303.1030303@digitalbrains.com> References: <1378040277596-32165.post@n7.nabble.com> <52240E47.1090402@securemecca.net> <52261303.1030303@digitalbrains.com> Message-ID: <52264AF3.3050009@sixdemonbag.org> On 9/3/2013 12:49 PM, Peter Lebbing wrote: > 3DES is safe. It's incredibly safe! How is it no match for modern CPU > power? There are no practical attacks on 3DES. What are you trying to > say? 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: smime.p7s Type: application/pkcs7-signature Size: 3744 bytes Desc: S/MIME Cryptographic Signature URL: From mustrum at mustrum.net Tue Sep 3 12:51:44 2013 From: mustrum at mustrum.net (Mustrum) Date: Tue, 03 Sep 2013 12:51:44 +0200 Subject: Gpg-agent ECDSA and pageant Message-ID: <8b65df5f-1b90-4f7e-94e6-aa8cad9c55f7@email.android.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone. The last gpg-agent supports ECDSA and putty's pageant. But, does it support ECDSA for putty/pageant ? Regards. Ps: oups, sorry for my last message without any subject, bad clicking... -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQI7BAEBCAAlBQJSJb9AHhxNdXN0cnVtIDxNdXN0cnVtQE11c3RydW0ubmV0PgAK CRBMuv2GX9WDniPlD/kBMS7njhxHUrogbL30GonJZcUqiuhAHdgkg+mOSXbtOGqR 8g7JTb30oFka99KRB1xKRhiJwhIUKWpb1NAdrhjPirCGpxmpUctw7Ds6o1KfrdpZ 8gcIffQvs/3gSmfcOSI9gO4ycAW+uGxxpAJDKst4i0+RqJJxQproLivjzwPSs2hv jTcT3mKQJ0JA8tTfzwL2iU4Ac74xAgeFeCnjlwSHMveuQtl/xhjlrBMDyFVx/CzY VUHRb7/0jBmRkx4DnxhL80XaECUzo5hS5LV40mzBw9sj2+GIVxmw850/F084JORe p84ypaAzkMKMPvVZszGVx7eaFR8TwVqZB0lvZrnDpTZr+sRdqGu00mRAHbv4PAou ispe8o1fQpYO5/zTx+5gqyTQaspbPyTthvCXUxygyRpLhqGeZIGySRoWL/cfodfU EJ7J9ZxbXBCAGuRXu+F/B7Z9inVR1FHFqPupXoTdJDgd4KDMwey4YH3O71djLwhC LhG535G8dALkmYMy9K8FDGjFxP7SsOIe+2DkULyEZebmgPvIiBYdCarJj6IdNfCS MvdOl0KTWXuxiLhhpD2UolCaNltJr6QFxNgUVTbL0yg62BwJgKH8yQ3ZAaQOzNWR 5Rw2/y5ROtD9J8Gq+Y6DqVsBfx8RviIxkBTUN6uGjEs/BjdfWl3Muu+92JnAaw== =cZaO -----END PGP SIGNATURE----- From hhhobbit at securemecca.net Wed Sep 4 05:37:28 2013 From: hhhobbit at securemecca.net (Henry Hertz Hobbit) Date: Wed, 04 Sep 2013 03:37:28 +0000 Subject: my statements were twisted (was Security of 3DES) In-Reply-To: <52261303.1030303@digitalbrains.com> References: <1378040277596-32165.post@n7.nabble.com> <52240E47.1090402@securemecca.net> <52261303.1030303@digitalbrains.com> Message-ID: <5226AAF8.9040306@securemecca.net> On 09/03/2013 04:49 PM, Peter Lebbing wrote: > To expand on what Johan Wevers said: symmetric ciphers do not change the length > of the encrypted text (by more than the block size). They certainly do not > compress. Usually, data is compressed before encrypting it (compressing it after > is pretty useless). If you set your key preferences to not allow compression, > files encrypted to your key will not be smaller than the original files. NO TWO PEOPLE ARE THE SAME! The main thing I am saying is to make choices work for you but at the same time consider the others you interact with. Taking my choices is NOT any better than the ones on the Debian page. You have to find your own. If you have a problem with that I will don my Psychologist cap and do analysis instead. I won't answer the other questions because you have grossly misinterpreted me. My major point was that what was picked in that list had the idea that bigger is better and biggest is best. Zipping was required. I dropped my 4096R keys and went from them to 2048R more not from the point of view of which is safer but more from the point of view of being reasonable for others. Ditto for going from the SHA512 hash down to SHA256. Now I realize that there is a lot more going on in GnuPG than just using sha256sum and sha512sum. Nevertheless, doing tests on creating the hashes on 1000 files made it quite evident that SHA256 wasn't that much of a burden over SHA1. But sha512sum consumed gobs more time than using sha256sum. So I switched not only the key sizes but the DIGEST to SHA256 as my first choice. How bad was SHA512 in other ways? There were some times the detached ".sig" files were as large as or even larger than the base files! But it was NOT what ever I thought was the best for me security-wise driving the decision. It was the needs and desires of others. You don't live in a vacuum. Having that much extra for the task at hand was gross over-kill. There is nothing wrong with 3DES from my point of view. There may be from other people's point of view and that includes people making government specifications that ignore the fact that CAST5 has not had as much crypton-analysis done on it than has been done with 3DES. Have you ever heard the statement "there is the right way, the wrong way, and the Navy way"? In that case it is NOT your choice driving the decision. If you were not supposed to use 3DES then by golly you better not use it. Didn't I make the statement that you are far more likely to lose your secret documents via a hacker infecting your machine and stealing them that way than attacking any of these ciphers? Didn't I say you are more likely to have somebody go into your house and attach a key-logger to the end of your keyboard than by them attacking any of these ciphers directly? Why did you ignore these statements? I only mentioned that 3DES should be considered for low powered machines. That statement stands. If you want 3DES as your first choice on an umpteen core machine go ahead. Other people with lower powered machines will be delighted with your choice. I will get it implicitly only when that is all they can do but choose not to add it to my list of ciphers. Don't feel people have to pick what you picked. I hope they pick what works best for them and the others they interact with. My whole point is that they lined up things with a bigger is better and biggest is best mentality. There are times when other factors are just as important as the security is. There are also the times as in AES vs. AES-256 where bigger doesn't always mean better - at least according to Bruce Schneier's thinking. If you want to argue that point argue it with Bruce, not me. Me? I took his advice and moved the AES to the head of the AES line-up. I was about to drop the AES-192 for one of the Camellia ciphers (see my PS at the end). It is called free choice but I will make it considering the needs of others, not just slap down the biggest one or the smallest one. As for the zip algorithms I was thinking more along the lines of what is going on in email and the fact that I much prefer 7-zip over all the zip algorithms you can specify. You will NEVER get 7-zip in GnuPG. Now please don't misunderstand me on that as well! All I am saying is that 7-zip will never be added to GnuPG and I prefer 7-zip. So I will do my compressing outside of GnuPG. But there is more going on. First for what is going on in email using one of the malware I got yesterday pretending to come from the Royal Bank of Scotland: 8859 Sep 4 01:26 base64.zip 11978 Sep 4 01:25 DOC_Sue_Wagner.bin 16870 Sep 4 01:21 DOC_Sue_Wagner.eml 8859 Sep 4 01:18 DOC_Sue_Wagner.zip The DOC_Sue_Wagner.eml was the email saved as is from Thunderbird. In adddition to the ASCII-fied zip it has a fair sized headers, MIME markings and other things. The file named DOC_Sue_Wagner.bin was the eml file stripped down to just the ASCII zip. The base64.zip was the conversion from the bin file to a zip file using base64 -i -d. The DOC_Sue_Wagner.zip file was saved as is from Thunderbird. DOC_Sue_Wagner.zip and base64.zip are the same: $ sha1sum base64.zip DOC_Sue_Wagner.zip 1a060a72519e5bf171a45fd642f9a83bc9a6a64d base64.zip 1a060a72519e5bf171a45fd642f9a83bc9a6a64d DOC_Sue_Wagner.zip $ hexcmp base64.zip DOC_Sue_Wagner.zip # nothing spit out and zero returned which means all of the # nth bytes are always the same. But in this case it is a wash. Whether zipped or not there just isn't that much more of saving when things go to ASCII so why bother? All that does is slow both you and them down. If it is a super huge file then I just zip it on the outside with 7-zip. Both 7-zip and bzip2 beat gzip and zip although there are times when the orders are different. On average bzip2 usually is about 10% to 15% larger than 7-zip, gzip is larger than bzip2 and zip is the largest of all. But one more thing 7-zip does for me is throw out the UID:GID. Thus due to the email considerations and what I said pick your own zip poison for GnuPG. For me it will continue to be nothing. Like I said, there is no one BEST choice for everybody. If you disagree with somebody else's choice do it without being disagreeable. HHH PS I think I am going to revoke my keys and just say to hell with OpenPG encryption. It isn't worth it. From frase at frase.id.au Wed Sep 4 14:53:47 2013 From: frase at frase.id.au (Fraser Tweedale) Date: Wed, 4 Sep 2013 22:53:47 +1000 Subject: gcaff-0.2 now available; graphical signing assistant Message-ID: <20130904125346.GX1617@bacardi.hollandpark.frase.id.au> Hi gnupg-users, gcaff-0.2 is available immediately on PyPI[1] and GitHub[2]. [1] https://pypi.python.org/pypi/gcaff [2] https://github.com/frasertweedale/gcaff Release highlights: * fixed a crash bug on platforms where pipes are unidirectional (e.g. Linux) * fixed a bug that caused the first uid to be dropped when using GnuPG v1 * removed the arbitrary limit on the number of keys (whups!) * supply --use-agent in case GnuPG (v1) is not configured to use the agent * test for gpg-agent and local mailer connectivity on startup gcaff is a graphical tool for signing OpenPGP keys, inspired by caff. Features include: * display and sign photo UIDs * sign with multiple signing keys in one pass * choose the certification level on a per-key basis * email each signature separately, only to the associated email address Regards, Fraser -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available URL: From wk at gnupg.org Wed Sep 4 15:01:59 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Sep 2013 15:01:59 +0200 Subject: Gpg-agent ECDSA and pageant In-Reply-To: <8b65df5f-1b90-4f7e-94e6-aa8cad9c55f7@email.android.com> (mustrum@mustrum.net's message of "Tue, 03 Sep 2013 12:51:44 +0200") References: <8b65df5f-1b90-4f7e-94e6-aa8cad9c55f7@email.android.com> Message-ID: <8738pklozc.fsf@vigenere.g10code.de> On Tue, 3 Sep 2013 12:51, mustrum at mustrum.net said: > But, does it support ECDSA for putty/pageant ? If putty supports it, gpg-agent supports it as well. Pageant implements the ssh-agent protocol which is what gpg-agent implements as well. The only difference in Pageant is that it uses the Windows message queue for transport which tunnels the standard Unix ssh-agent protocol. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From JDiaz at azdes.gov Wed Sep 4 22:54:38 2013 From: JDiaz at azdes.gov (Diaz, John, A) Date: Wed, 4 Sep 2013 20:54:38 +0000 Subject: Decrypt Issue Message-ID: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> Hello. Long story, short: 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 list the keys on the server that this is running I see the key listed. Here's the goofy part: If I login to the server with the credentials that the mainframe uses to call the first .bat file, and manually run the .bat file that starts the whole process, it runs correctly. Thoughts? John Diaz 602-274-5359 x1284 jdiaz at azdes.gov ________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From md123 at nycap.rr.com Thu Sep 5 07:05:56 2013 From: md123 at nycap.rr.com (Matt D) Date: Thu, 05 Sep 2013 01:05:56 -0400 Subject: cant open public keyring file Message-ID: <52281134.1020605@nycap.rr.com> my open pgp wont work. i cant get keys. using ubuntu 12.10. latest version of gpg. OpenPGP Security Info Unverified signature gpg command line and output: gpg gpg: Signature made Wed 14 Aug 2013 07:32:07 AM EDT gpg: using DSA key 0x5BB6809BAE445B2E gpg: can't open `/home/matt/.gnupg/pubring.gpg' gpg: keydb_search failed: file open error gpg: Can't check signature: public key not found gpg: Signature made Wed 14 Aug 2013 07:32:07 AM EDT gpg: using RSA key 0xAE2FF2140E7A0087 gpg: can't open `/home/matt/.gnupg/pubring.gpg' gpg: keydb_search failed: file open error gpg: Can't check signature: public key not found -- ------ Matt D ------------ From ben at adversary.org Thu Sep 5 13:16:37 2013 From: ben at adversary.org (Ben McGinnes) Date: Thu, 05 Sep 2013 21:16:37 +1000 Subject: cant open public keyring file In-Reply-To: <52281134.1020605@nycap.rr.com> References: <52281134.1020605@nycap.rr.com> Message-ID: <52286815.2010305@adversary.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 5/09/13 3:05 PM, Matt D wrote: > my open pgp wont work. i cant get keys. using ubuntu 12.10. > latest version of gpg. > > OpenPGP Security Info > > Unverified signature > > gpg command line and output: gpg gpg: Signature made Wed 14 Aug > 2013 07:32:07 AM EDT gpg: using DSA key > 0x5BB6809BAE445B2E gpg: can't open `/home/matt/.gnupg/pubring.gpg' > gpg: keydb_search failed: file open error gpg: Can't check > signature: public key not found gpg: Signature made Wed 14 Aug 2013 > 07:32:07 AM EDT gpg: using RSA key > 0xAE2FF2140E7A0087 gpg: can't open `/home/matt/.gnupg/pubring.gpg' > gpg: keydb_search failed: file open error gpg: Can't check > signature: public key not found What's the output of: ls -l /home/matt/.gnupg/pubring.gpg It needs to be at least 600 and owned by your account. Regards, Ben -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJSKGgUAAoJEH/y03E1x1U8CQ8L/R6GUUnTv4rW/1cWnh5c4WNA k2tdBKP3Fxhw3ZOrw1a6i+fg8Nu1LszT3L1uPA88845MNcWevE5NRaSD9vjzLYd9 ec8YUfPef3q/gbRMWuO43/d7V5YaQ3cTnv74rRBVuH0N6YTA+s902SuZRuw5MhRt sCz6WhPdNrwALnmm3IpLdkpE/HiM0E3zQauxnK21KTcMODaO3ZhKmUjHnIOna2uW fkUyEmFPeMK9lQFTe4Oj6+YzTM+qgRczgHfU9NwaG7yzrWV30XCutZftyye2A/ue wPErt++JT8Z3KjISmrj5fKnZc7rxnZT/8Js+M5wf1btw+06RHAfroeZdGRsySj3R /hovghtk2RRSenVnbIChMmUFptKUvfWZbsLdFwWh3MFR1AK7SI7M14MALSV4f2tZ jn4JyxxRMzn7d5NIHmpJfzllNqr8xzJ+c0BLXTKvODqPlZQedCab7DILhWrDI8MC Hq5CqnLUykViWbIf+yKVrOj7+0IQg2TYjkf1f71SgA== =ISVL -----END PGP SIGNATURE----- From pete at heypete.com Thu Sep 5 20:35:21 2013 From: pete at heypete.com (Pete Stephenson) Date: Thu, 5 Sep 2013 20:35:21 +0200 Subject: Issues with primary key & subkeys on different smartcards Message-ID: Hi everyone, I'm writing in regards to an issue I've run into using GnuPG 2.0.21 on Windows (the same issue occurs with 2.0.19 in Debian 7 and Ubuntu Linux 13.04, and I performed the same steps on all three systems to verify that this wasn't an OS-specific issue). I apologize in advance for the length of this message, but I thought it better to be more detailed than less. Brief background: I have loaded a primary RSA signing key onto a smartcard ("smartcard #1"). I have created two RSA subkeys, one for signing and the other for encrypting, and loaded them onto a second smartcard ("smartcard #2"). The primary key and its subkeys were generated on the computer and were later loaded onto the card; they were not generated internally on the card (I keep a secure, offline backup of the private keys in case the cards are damaged or lost.). I wish to have a single private key file in my GnuPG keyring that includes stubs to the primary key on smartcard #1 and the subkeys on smartcard #2. This way, if I need to certify a public key belonging to someone else I will be prompted to insert smartcard #1. If I wish to sign a message or decrypt an encrypted message sent to me I will be prompted to insert smartcard #2. ========== First attempt: Initial conditions: 1. The public key that contains details about my primary and subkeys is present in my GnuPG keyring. The private keys are not present in the GnuPG keyring; they exist only in the offline backup and on the smartcards. 2. Primary key is on smartcard #1, both subkeys (encryption and signing) are on smartcard #2. Expected behavior: 1. I insert smartcard #1, then run "gpg2 --card-status". 2. The details of smartcard #1 is displayed. 3. GnuPG adds a private key stub pointing to smartcard #1. 4. I remove smartcard #1 and insert smartcard #2, then run "gpg2 --card-status". 5. The details of smartcard #2 is displayed. 6. GnuPG adds private key stubs pointing to smartcard #2. 7. Certifying ("signing") someone else's public key requires that I insert smartcard #1. Signing a message or decrypting an encrypted message requires that I insert smartcard #2. Observed behavior: 1. Same as above. 2. Same as above. 3. Same as above. 4. Same as above. 5. Same as above. 6. GnuPG does *not* add private key stubs pointing to smartcard #2. 7. Certifying someone else's public key requires that I insert smartcard #1, as expected. Signing a message or decrypting an encrypted message does not prompt for smartcard #2, but instead results in the following error message: gpg: secret key parts are not available gpg: skipped "KEYID": Unusable secret key gpg: [stdin]: clearsign failed: Unusable secret key If I start over from the initial conditions and reverse the order of the cards (i.e. insert smartcard #2 first and run "gpg2 --card-status"), then the stubs for the subkeys get generated but when I later insert smartcard #1 and run "gpg2 --card-status" then the stub for the primary key is not created. ========== Second attempt: Expected behavior: 1. Add the primary key stub (steps 1-3 from above). This successfully adds the primary key stub. 2. Run "gpg2 --export-secret-keys KEYID > primary-stub.key" 3. Run "gpg2 --delete-secret-keys KEYID" to delete the private key component (that is, the stub) from the keyring. 4. Add the subkey stubs (steps 4-6 as above). This successfully adds the subkey stubs. 5. Run "gpg2 --import primary-stub.key". 6. GnuPG imports the primary key stub, resulting in a private key containing stubs to the primary and subkeys on their respective cards. Observed behavior. 1. Same as above. 2. Same as above. 3. Same as above. 4. Same as above. 5. Same as above. 6. GnuPG does *not* import the primary key stub. Rather it says: gpg: key KEYID: already in secret keyring gpg: Total number processed: 1 gpg: secret keys read: 1 gpg: secret keys unchanged: 1 Starting over and reversing the order (creating the subkey stubs, exporting them to a file, deleting the subkey stubs from the keyring, adding the primary key stub, and trying to import the subkey stubs) produces the same, unsuccessful result. ========== Is this intentional or a bug? If it is intentional, how can one easily add stubs pointing to different smartcards for different private key components? ========== Addendum: I was able to successfully create a private key with stubs pointing to both cards as follows (since Gpg4Win does not include the gpgsplit utility but Debian's gnupg2 package does, I performed these steps in Debian. I presume they'd also work in Debian derivatives like Ubuntu.): 1. Insert smartcard #1, run "gpg2 --card-status". This creates a stub for the primary key. 2. Run "gpg2 --export-secret-keys KEYID > primary-stub.key" to export a private key file containing the stub of the primary key. 3. Run "gpg2 --delete-secret-keys KEYID" to delete the private key stub from the keyring. Only the public key remains in the keyring. 4. Insert smartcard #2, run "gpg2 --card-status". This creates a stub for the subkeys. 5. Run "gpg2 --export-secret-keys KEYID > subkeys-stub.key" to export a private key file containing the stubs of the subkey. 6. Run "gpg2 --delete-secret-keys KEYID" to delete the subkey stubs from the keyring. Only the public key remains in the keyring. 7. Put each exported key file into a separate directory, then run "cat primary-stub.key | gpgsplit" and "cat subkeys-stub.key | gpgsplit" in the respective directories to separate the keys into packets. 8. Move the subkey stub packets from their directory into the primary key directory, overwriting the subkey packets in the primary key directory. 9. Run "cat * > complete.key" in the primary key directory to reassemble the key file. 10. Run "gpg2 --import complete.key" to import the reassembled key file. 11. Success! Everything works as expected: running "gpg2 --edit-key KEYID", then "toggle" shows that the primary key and the subkey stubs exist and point at their respective cards. Certifying a key requires smartcard #1 and signing/decrypting messages requires smartcard #2. Although this was successful, I think that it's something that should be doable within GnuPG itself rather than by splitting keys and working manually on packets. Cheers! -Pete -- Pete Stephenson From marcio.barbado at gmail.com Thu Sep 5 22:22:29 2013 From: marcio.barbado at gmail.com (Marcio B. Jr.) Date: Thu, 5 Sep 2013 17:22:29 -0300 Subject: Fedora GPG Key Server Message-ID: https://lists.fedoraproject.org/pipermail/announce/2013-September/003180.html Marcio Barbado, Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From md123 at nycap.rr.com Fri Sep 6 03:35:32 2013 From: md123 at nycap.rr.com (Matt D) Date: Thu, 05 Sep 2013 21:35:32 -0400 Subject: problems opening .asc file Message-ID: <52293164.9070709@nycap.rr.com> Hey, i was sent a .asc file as an attachment. when i try to open it it says "Couldn't decrypt file: No data" and on the signature part of another email i get this: OpenPGP Security Info Error - signature verification failed gpg command line and output: gpg gpg: Signature made Wed 14 Aug 2013 07:32:07 AM EDT using DSA key ID xxxxxxxx gpg: BAD signature from "xxxxxxxxxxx.com>" however when i do: gpg --sign-key xxxxxxxx it tells me it is signed by my key. What am i doing wrong here? Thanks! -- ------ Matt D ------------ From peter at digitalbrains.com Fri Sep 6 10:29:08 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 06 Sep 2013 10:29:08 +0200 Subject: my statements were twisted In-Reply-To: <5226AAF8.9040306@securemecca.net> References: <1378040277596-32165.post@n7.nabble.com> <52240E47.1090402@securemecca.net> <52261303.1030303@digitalbrains.com> <5226AAF8.9040306@securemecca.net> Message-ID: <52299254.8060804@digitalbrains.com> On 04/09/13 05:37, Henry Hertz Hobbit wrote: > I won't answer the other questions because you have grossly misinterpreted > me. I never deliberately twist people's words, I hate that[1]. I always try to see what the person means to say, even if it's not literally what they wrote. But I often find your walls of text hard to follow, so I'll probably sometimes misinterpret it. It could be me, or maybe you could phrase better what you intend to say. > If you disagree with somebody else's choice do it without being > disagreeable. It was an honest misunderstanding, there is no need to get angry. I'm sorry that my reply upset you. Peter. [1] Perhaps I might be nasty in different ways if grumpy and stroked the wrong way, but twisting words is not my thing. -- 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 Fri Sep 6 15:44:35 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 06 Sep 2013 09:44:35 -0400 Subject: problems opening .asc file In-Reply-To: <52293164.9070709@nycap.rr.com> References: <52293164.9070709@nycap.rr.com> Message-ID: <5229DC43.3090005@fifthhorseman.net> Hi Matt-- On 09/05/2013 09:35 PM, Matt D wrote: > i was sent a .asc file as an attachment. It sounds like you may have been sent a PGP/MIME-signed message. The message i'm sending now is PGP/MIME-signed. These kinds of messages show up in some Mail User Agents that don't know about PGP/MIME as though it is a message with an attachment, instead of a single signed message. In fact, the signature part is not an "attachment" in the traditional sense of the word, and it can only be evaluated in the context of the message it was sent with. For more detail on PGP/MIME, see https://tools.ietf.org/html/rfc3156 > when i try to open it it says > "Couldn't decrypt file: No data" this is probably because the data it is signing is missing (i.e. you are evaluating the signature without the message body itself) > What am i doing wrong here? If you want to be able to verify these message signatures, you should set yourself up with a Mail User Agent that can handle PGP/MIME-signed messages. Some examples are: * thunderbird with the enigmail plugin * evolution * claws mail * outlook with gpgOL (http://gpg4win.org/about.html) * notmuch 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 md123 at nycap.rr.com Fri Sep 6 23:08:15 2013 From: md123 at nycap.rr.com (Matt D) Date: Fri, 06 Sep 2013 17:08:15 -0400 Subject: problems opening .asc file In-Reply-To: <5229DC43.3090005@fifthhorseman.net> References: <52293164.9070709@nycap.rr.com> <5229DC43.3090005@fifthhorseman.net> Message-ID: <522A443F.3070307@nycap.rr.com> > If you want to be able to verify these message signatures, you > should set yourself up with a Mail User Agent that can handle > PGP/MIME-signed messages. Some examples are: > > * thunderbird with the enigmail plugin * evolution * claws mail * > outlook with gpgOL (http://gpg4win.org/about.html) * notmuch > > hth, > > --dkg > right. for this email address i use thunderbird and everything seems to work. however i cant get my thunderbird to work with hush.com From pete at heypete.com Sat Sep 7 00:08:43 2013 From: pete at heypete.com (Pete Stephenson) Date: Sat, 7 Sep 2013 00:08:43 +0200 Subject: Issues with primary key & subkeys on different smartcards In-Reply-To: References: Message-ID: On Thu, Sep 5, 2013 at 8:35 PM, Pete Stephenson wrote: [snip] > I wish to have a single private key file in my GnuPG keyring that > includes stubs to the primary key on smartcard #1 and the subkeys on > smartcard #2. This way, if I need to certify a public key belonging to > someone else I will be prompted to insert smartcard #1. If I wish to > sign a message or decrypt an encrypted message sent to me I will be > prompted to insert smartcard #2. [snip] Hi all, Quick followup: I was also able to create the correct private key with stubs pointing at both smartcards by loading the actual private keys onto the smartcard using "keytocard", as expected. However, I'm unable to re-create this file starting only with the public key and running "gpg2 --card-status" for each card. It seems like running "gpg2 --card-status" for each card should be able to create the stubs, but if there's already a stub associated with a particular smartcard, then running "gpg2 --card-status" doesn't seem to have any effect other than to display the card info. Put simply: running "gpg2 --card-status" will create one stub pointing at the card, but running that command again with a different card only displays the card info and doesn't add any additional stubs. This seems inconsistent and not what I would expect. Sorry again for the really long previous message. Cheers! -Pete -- Pete Stephenson From free10pro at gmail.com Sat Sep 7 09:45:28 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Sat, 07 Sep 2013 00:45:28 -0700 Subject: Issues with primary key & subkeys on different smartcards In-Reply-To: References: Message-ID: <522AD998.8040500@gmail.com> On 09/06/2013 03:08 PM, Pete Stephenson wrote: > On Thu, Sep 5, 2013 at 8:35 PM, Pete Stephenson wrote: > Quick followup: I was also able to create the correct private key with > stubs pointing at both smartcards by loading the actual private keys > onto the smartcard using "keytocard", as expected. > > However, I'm unable to re-create this file starting only with the > public key and running "gpg2 --card-status" for each card. It seems > like running "gpg2 --card-status" for each card should be able to > create the stubs, but if there's already a stub associated with a > particular smartcard, then running "gpg2 --card-status" doesn't seem > to have any effect other than to display the card info. > > Put simply: running "gpg2 --card-status" will create one stub pointing > at the card, but running that command again with a different card only > displays the card info and doesn't add any additional stubs. This > seems inconsistent and not what I would expect. Hello Pete, It seems that the keytocard command is the way to correctly load the subkeys and primary key onto the smartcards. I had not thought about splitting the primary and subkeys across the two smartcards, but it works quite easily by using the keytocard command. I tested it to see how it works, and I feel certain that the keytocard method that you used is the correct way to do it. For those who may be reading, I found loading one OpenPGP card with the primary key and a second with the subkey to work as the following example demonstrates: $ gpg2 --edit-key Joe gpg (GnuPG) 2.0.17; Copyright (C) 2011 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 2048R/123B9C22 created: 2013-09-07 expires: 2018-09-06 usage: SC trust: ultimate validity: ultimate sub 2048R/972C7E79 created: 2013-09-07 expires: 2018-09-06 usage: E [ultimate] (1). Joe gpg> toggle sec 2048R/123B9C22 created: 2013-09-07 expires: 2018-09-06 ssb 2048R/972C7E79 created: 2013-09-07 expires: never (1) Joe gpg> keytocard Really move the primary key? (y/N) y Signature key ....: [none] Encryption key....: [none] Authentication key: [none] Please select where to store the key: (1) Signature key (3) Authentication key Your selection? 1 You need a passphrase to unlock the secret key for user: "Joe " 2048-bit RSA key, ID 123B9C22, created 2013-09-07 sec 2048R/123B9C22 created: 2013-09-07 expires: 2018-09-06 card-no: 0005 DECAFBAD ssb 2048R/972C7E79 created: 2013-09-07 expires: never (1) Joe gpg> key 1 sec 2048R/123B9C22 created: 2013-09-07 expires: 2018-09-06 card-no: 0005 DECAFBAD ssb* 2048R/972C7E79 created: 2013-09-07 expires: never (1) Joe gpg> keytocard Signature key ....: [none] Encryption key....: [none] Authentication key: [none] Please select where to store the key: (2) Encryption key Your selection? 2 You need a passphrase to unlock the secret key for user: "Joe " 2048-bit RSA key, ID 972C7E79, created 2013-09-07 sec 2048R/123B9C22 created: 2013-09-07 expires: 2018-09-06 card-no: 0005 DECAFBAD ssb* 2048R/972C7E79 created: 2013-09-07 expires: never card-no: 0005 DEADBEEF (1) Joe gpg> save Now you are done, and the cards work great. If you need either the primary key or subkey, pinentry will prompt you to insert the appropriate card. The only thing is that if you need a backup of the secret keys before moving them to the smartcards, you need to do that before following the example above. Anyway, Pete, thank you for bringing this subject up and experimenting with it and helping make us all a little smarter. I can't answer the question as to whether it was designed to work that way, but I don't feel there is any doubt. Cheers, --Paul -- PGP: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 From wk at gnupg.org Sat Sep 7 12:28:45 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 07 Sep 2013 12:28:45 +0200 Subject: Fedora GPG Key Server In-Reply-To: (Marcio B., Jr.'s message of "Thu, 5 Sep 2013 17:22:29 -0300") References: Message-ID: <877getgc2q.fsf@vigenere.g10code.de> On Thu, 5 Sep 2013 22:22, marcio.barbado at gmail.com said: > https://lists.fedoraproject.org/pipermail/announce/2013-September/003180.html Please do not post a mere link. This assume that everyone is online and able to read a web page. At least an excerpt from the page would be useful. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From pete at heypete.com Sat Sep 7 12:36:18 2013 From: pete at heypete.com (Pete Stephenson) Date: Sat, 7 Sep 2013 12:36:18 +0200 Subject: Issues with primary key & subkeys on different smartcards In-Reply-To: <522AD998.8040500@gmail.com> References: <522AD998.8040500@gmail.com> Message-ID: On Sat, Sep 7, 2013 at 9:45 AM, Paul R. Ramer wrote: [snip] > It seems that the keytocard command is the way to correctly load the > subkeys and primary key onto the smartcards. I had not thought about > splitting the primary and subkeys across the two smartcards, but it > works quite easily by using the keytocard command. I tested it to see > how it works, and I feel certain that the keytocard method that you used > is the correct way to do it. [snip] Hi Paul, Indeed, the keytocard command is the correct way to load the keys onto the cards and to generate the stubs initially. As you mention, that works as expected and generates the correct stubs pointing at both cards. The issue I'm running into is not the initial loading of the private keys onto the cards, but rather if I'm trying to use the cards on a computer that does not already have the private keys. If I start on that new computer with only my public key, insert one of the two cards (e.g. the card containing my primary key) and run "gpg2 --card-status", GnuPG will generate a private key stub that points at that card. That's fine and works as expected. However, if I try doing the same thing with the second card (the one with my subkeys), the stub is not added. Only the details of the second card are displayed, but the stub pointing to that card is not added. This is not what I expected: I expect that GnuPG will add a stub for each of the cards after I run "--card-status" for each card, but this doesn't happen and only the stub for the first card (i.e. whichever one I use with "--card-status" first) is added. In short, I expect to be able to get the same result using "--card-status" and both cards as I do when I use "keytocard" to initially move the keys to the cards, but this does not occur. > Now you are done, and the cards work great. If you need either the > primary key or subkey, pinentry will prompt you to insert the > appropriate card. The only thing is that if you need a backup of the > secret keys before moving them to the smartcards, you need to do that > before following the example above. Right, I definitely have backups, but it's always a good thing to remind people. :) > Anyway, Pete, thank you for bringing this subject up and experimenting > with it and helping make us all a little smarter. I can't answer the > question as to whether it was designed to work that way, but I don't > feel there is any doubt. You're welcome. If it is designed to work that way, I respectfully ask that the developers consider changing how it works so that "keytocard" and "--card-status" both produce the same key with stubs pointing to each respective card. The way it currently works, where --card-status will only add one stub to a key, is not what I would expect to happen. As my programming abilities are not sufficient to make a patch to change this behavior, I'd be happy to offer a financial contribution if someone with more skill were to give it a shot. Cheers! -Pete -- Pete Stephenson From peter at digitalbrains.com Sat Sep 7 16:10:11 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 07 Sep 2013 16:10:11 +0200 Subject: Transfer subkey to other keyring In-Reply-To: <51CC6E7D.4080709@nottheoilrig.com> References: <51C9DD9A.3060707@nottheoilrig.com> <87ppv9gqx1.fsf@vigenere.g10code.de> <51CB2C48.4070809@nottheoilrig.com> <87hagkdmca.fsf@vigenere.g10code.de> <51CC6E7D.4080709@nottheoilrig.com> Message-ID: <522B33C3.4090408@digitalbrains.com> On 27/06/13 18:55, Jack Bates wrote: > except that I am using the key id of a subkey, with an exclamation > mark, to export just one subkey instead of all the subkeys belonging to the > primary key. The subkey with that key id definitely doesn't already exist in the > destination keyring, although the destination keyring does already contain a > different subkey. I believe once GnuPG has a secret key, it won't update it anymore with any subsequent imports. So to get the additional subkey, re-export the whole thing, delete the existing one on the other system and import your re-exported whole thing. I'm also wondering why you're being so explicit about it in the first place, with transferring little chunks at a time using the exclamation mark instead of the whole thing. Is there something specific you're trying to achieve? > gpg: secret keys unchanged: 1 This message to me implies it is actually possible to change something about a secret key. I haven't figured out what yet. 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 Sat Sep 7 16:11:57 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 07 Sep 2013 16:11:57 +0200 Subject: Issues with primary key & subkeys on different smartcards In-Reply-To: References: <522AD998.8040500@gmail.com> Message-ID: <522B342D.9000209@digitalbrains.com> (from the first mail) > I was able to successfully create a private key with stubs pointing to > both cards as follows Yes, that is how I ended up doing it back when I started using the same setup years ago (two smartcards, certifying key on one, signing on another). Only shortly ago, I got the impression from someone's mail to gnupg-users that GnuPG these days did it as we both expected it would do: upon inserting the second smartcard, replace the dummy S2K stubs with divert-to-card S2K's for the second card. Apparently it does not... Once GnuPG has a secret key, I think it won't update it with new data. It didn't use to AFAIK, and apparently still doesn't. Somebody else recently tried exporting and importing a new subkey, and the import didn't work either. I just thought of that thread and replied to it as well. > As my programming abilities are not sufficient to make a patch to > change this behavior, I'd be happy to offer a financial contribution > if someone with more skill were to give it a shot. I commend your spirit. Werner Koch does paid feature development for GnuPG as well, although I am in no position to judge whether your financial contribution can pay for the whole feature. I'm also willing to contribute, but don't hold your breath over the amount of money ;). I've offered payment for a feature before, can't exactly remember what right now, but it was worth to me more than this particular one. Come to think of it, I've never seen any mention of people paying for features and/or features made possible by paying users. Perhaps an interesting subthread to spawn, if Werner is comfortable discussing it? Anyway, back to the topic: maybe there are situations where you don't want to update a secret key with new subkeys or new "key material" (let's consider a divert-to-card S2K as key material, and a dummy S2K as absence of it). But an option "--import-options update-secret-key" or something seems like a useful thing, and gives people the choice without resorting to gpgsplitting. 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 mike_acker at charter.net Sat Sep 7 14:11:25 2013 From: mike_acker at charter.net (Mike Acker) Date: Sat, 07 Sep 2013 08:11:25 -0400 Subject: NSA backdoors and Set Preferred Cipher Message-ID: <522B17ED.5030008@charter.net> a lot of information has been reported recently regarding NSA an back-door entries behind digital encryption attached are some notes I offered recently on the MINT forum i have altered my cipher preference list as follows TWOFISH CAST5 BLOWFISH 3DES AES AES192 AES256 CAMELLIA128 CAMELLIA192 CAMELLIA256 based on recent revelations we should probably not use any commercially offered cipher -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NSA backdoors and TwoFish.odt Type: application/vnd.oasis.opendocument.text Size: 36375 bytes Desc: not available URL: -------------- 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 Sat Sep 7 22:30:07 2013 From: pete at heypete.com (Pete Stephenson) Date: Sat, 7 Sep 2013 22:30:07 +0200 Subject: NSA backdoors and Set Preferred Cipher In-Reply-To: <522B17ED.5030008@charter.net> References: <522B17ED.5030008@charter.net> Message-ID: On Sat, Sep 7, 2013 at 2:11 PM, Mike Acker wrote: > a lot of information has been reported recently regarding NSA an back-door > entries behind digital encryption > > attached are some notes I offered recently on the MINT forum > > i have altered my cipher preference list as follows > > TWOFISH CAST5 BLOWFISH 3DES AES AES192 AES256 CAMELLIA128 CAMELLIA192 > CAMELLIA256 > > based on recent revelations we should probably not use any commercially > offered cipher Hi Mike, Interesting. Would you care to explain your logic as to why you set the preferences in that particular order? In particular, why did you prioritize 3DES over the three AES variants? I can understand being skeptical of CAMELLIA, as it was developed commercially, though it has been approved for use by both the Japanese CRYPTREC project and the European NESSIE project and is widely available to researchers and cryptographers. That is, it's not a black box. Similarly, AES is an open standard and went through rigorous review by both government and the public cryptographic community. As far as I'm aware, all the ciphers used in GnuPG have no major, publicly-known cryptographic weaknesses so the choice as to which ones to use comes down more to a matter of personal preference and compatibility reasons. -- Pete Stephenson From free10pro at gmail.com Sat Sep 7 23:21:56 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Sat, 07 Sep 2013 14:21:56 -0700 Subject: Decrypt Issue In-Reply-To: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> Message-ID: <522B98F4.6080108@gmail.com> On 09/04/2013 01:54 PM, Diaz, John, A wrote: > 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 list the keys on the server that this is running I see the key listed. > > Here's the goofy part: If I login to the server with the credentials that the mainframe uses to call the first .bat file, and manually run the .bat file that starts the whole process, it runs correctly. Hello John, When you say that you log in to the server, are you logging into a user account on the server? And do you get a command prompt (i.e. you are ssh-ing into your server)? Cheers, --Paul -- PGP: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 From htd at fritha.org Sat Sep 7 23:23:52 2013 From: htd at fritha.org (Heinz Diehl) Date: Sat, 7 Sep 2013 23:23:52 +0200 Subject: NSA backdoors and Set Preferred Cipher In-Reply-To: <522B17ED.5030008@charter.net> References: <522B17ED.5030008@charter.net> Message-ID: <20130907212352.GA14397@fritha.org> On 07.09.2013, Mike Acker wrote: > based on recent revelations we should probably not use any commercially > offered cipher Define "commercially used cipher". I don't think the crypto ist the problem or the solution. Prism is mostly about traffic analysis, which is not significantly affected by encryption. The weakest link is most probably a flaw in the crypto environment which can be exploited, or backdoors already placed in the binaries/source code. From tange at gnu.org Sat Sep 7 23:35:08 2013 From: tange at gnu.org (Ole Tange) Date: Sat, 7 Sep 2013 23:35:08 +0200 Subject: Recommended key size for life long key In-Reply-To: References: Message-ID: On Sat, Aug 31, 2013 at 11:46 AM, Ole Tange wrote: : > Why not recommend a key size that will not be broken for the rest of > your natural life? Thanks for all your feed back on the list. I have now summed up the concerns raised on the list on http://oletange.blogspot.dk/2013/09/life-long-key-size.html Feel free to let me know if you feel I have left out important concerns. /Ole From gnupg at oneiroi.net Sat Sep 7 22:59:20 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sat, 07 Sep 2013 22:59:20 +0200 Subject: NSA backdoors and Set Preferred Cipher In-Reply-To: <522B17ED.5030008@charter.net> References: <522B17ED.5030008@charter.net> Message-ID: <522B93A8.1040402@oneiroi.net> Hello On 09/07/2013 02:11 PM, Mike Acker wrote: > a lot of information has been reported recently > > regarding NSA an back-door entries behind digital encryption > > attached are some notes I offered recently on the MINT forum > > i have altered my cipher preference list as follows > > TWOFISH CAST5 BLOWFISH 3DES AES AES192 AES256 CAMELLIA128 CAMELLIA192 > CAMELLIA256 > > based on recent revelations we should probably not use any commercially > offered cipher Is CAMELLIA's pick as least preferred cipher - omitted/disregarded by NIST (US) but certified by NESSIE (EU) and CRYPTREC (Japan) - is somehow related to those revelations? Regards, Filip M. Nowak From kloecker at kde.org Sun Sep 8 00:06:48 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 08 Sep 2013 00:06:48 +0200 Subject: Recommended key size for life long key In-Reply-To: References: Message-ID: <1893947.xO5ZYBzj2V@thufir.ingo-kloecker.de> On Saturday 07 September 2013 23:35:08 Ole Tange wrote: > On Sat, Aug 31, 2013 at 11:46 AM, Ole Tange wrote: > > Why not recommend a key size that will not be broken for the rest of > > your natural life? > > Thanks for all your feed back on the list. I have now summed up the > concerns raised on the list on > http://oletange.blogspot.dk/2013/09/life-long-key-size.html > > Feel free to let me know if you feel I have left out important > concerns. I see you have checked the influence of large keys on the CPU time needed to do key operations on different hardware. But key operations with large keys not only cost lots of time (see your numbers on low end hardware), but also energy. The additional energy consumption might not be relevant ecologically, but I'm pretty sure it's relevant for the battery life of your and your communication partners' smart phones. In particular, if you and your communication partners use equally large keys and encrypt each and every email, SMS, chat message, etc. Obviously, those concerns might be irrelevant in pratice (e.g. because nobody uses encryption anyway). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dougb at dougbarton.us Sun Sep 8 00:57:39 2013 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 07 Sep 2013 15:57:39 -0700 Subject: group and pgp-hooks In-Reply-To: <20130827071316.GA8065@Vixen> References: <20130827071316.GA8065@Vixen> Message-ID: <522BAF63.2020904@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/27/2013 12:13 AM, Werewolf wrote: | anyone gotten gpg groups option to work with mutt? | | seems all searchs I find come across the same headaches. No specific mutt experience but I've had them working in tbird and alpine. If you're trying to use a group as a substitute for a specific e-mail address then obviously the address needs to be the group name. You can also try with and without around the address. hth, Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSK69jAAoJEFzGhvEaGryEFu0IAJ74k2HyXGvOXlvKO1JQQo7Z u098ytcO+9drmIgpRK3iVI+G3W3pbDmpHvhMTJ3rGUsiBWPRBeAG66HHOrgkxX5B CYfPsjaY4Ujj2ocu6wNjqYRCNzP8dr6uabANw8Zd20IoqkbA3rj8wum9Ucb1JrD2 0cePkFYFHOqQ6M93vF4M7bJ8ssY2xjB6mKRd8NX3vupF90Zr5iR9ELPMoft+QPda rTj8sYQhXv5Ybi9Uqm0/u/2lu5loWBSsHwaqTX+h7w7+zJGqLEOOi5RUMIFi6vOg fU5KLo95Ov2uLKYGwabC6Yqsaf3D3mv27F3qBMPiTnWqwJhHJFVHzPcaskCSxwo= =7rUz -----END PGP SIGNATURE----- From dougb at dougbarton.us Sun Sep 8 01:03:14 2013 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 07 Sep 2013 16:03:14 -0700 Subject: Why trust gpg4win? In-Reply-To: <521A170C.3090503@gmail.com> References: <201307252214.r6PME8tp031462@fire.js.berklix.net> <521656E1.9010608@gmail.com> <521A170C.3090503@gmail.com> Message-ID: <522BB0B2.7010403@dougbarton.us> On 08/25/2013 07:39 AM, Larry Brower wrote: > BSD might have too high a learning curve for most ordinary people. A > custom BSD distro targeted at non-technical people would be useful here. > Perhaps one which took Security and Privacy into account as design goal. http://www.pcbsd.org/ From dougb at dougbarton.us Sun Sep 8 01:15:08 2013 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 07 Sep 2013 16:15:08 -0700 Subject: Why trust gpg4win? In-Reply-To: <521656E1.9010608@gmail.com> References: <201307252214.r6PME8tp031462@fire.js.berklix.net> <521656E1.9010608@gmail.com> Message-ID: <522BB37C.4020507@dougbarton.us> On 08/22/2013 11:22 AM, Jasper den Ouden wrote: > Compiling your own fixes the issue of the sources not corresponding > to binaries. Only if you're sophisticated enough to be able to understand the compiler itself, all of the libraries that are linked in, etc. etc. Even in open source software you compile yourself there are still a lot of attack vectors. The real value of open source software is the community. Doug From rjh at sixdemonbag.org Sun Sep 8 01:38:16 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 07 Sep 2013 19:38:16 -0400 Subject: NSA backdoors and Set Preferred Cipher In-Reply-To: <522B17ED.5030008@charter.net> References: <522B17ED.5030008@charter.net> Message-ID: <522BB8E8.2040307@sixdemonbag.org> On 9/7/2013 8:11 AM, Mike Acker wrote: > i have altered my cipher preference list as follows Why? Your preference list makes no sense. > TWOFISH CAST5 BLOWFISH 3DES AES AES192 AES256 CAMELLIA128 > CAMELLIA192 CAMELLIA256 GnuPG and PGP will stop as soon as they hit 3DES. They won't even look at the rest of the ciphers in your preference list. "Okay, Mike likes Twofish, but the recipient doesn't support it... then CAST5, but that's not supported... then Blowfish, again not supported... hey, 3DES. 3DES is *guaranteed* to be supported. The recipient has to speak 3DES. Cool. We'll choose 3DES and not even bother with the rest of the list." > based on recent revelations we should probably not use any > commercially offered cipher Which means what, exactly? 3DES came out of IBM in the 1970s, but it's not a "commercial product" in any sense I can imagine. CAMELLIA came out of a Japanese telecommunications firm, but it's likewise not a "commercial product." There are no "commercially offered ciphers" in GnuPG. From rjh at sixdemonbag.org Sun Sep 8 01:45:50 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 07 Sep 2013 19:45:50 -0400 Subject: NSA backdoors and Set Preferred Cipher In-Reply-To: <522B93A8.1040402@oneiroi.net> References: <522B17ED.5030008@charter.net> <522B93A8.1040402@oneiroi.net> Message-ID: <522BBAAE.9070202@sixdemonbag.org> On 9/7/2013 4:59 PM, Filip M. Nowak wrote: > Is CAMELLIA's pick as least preferred cipher - omitted/disregarded by > NIST (US) but certified by NESSIE (EU) and CRYPTREC (Japan) - is somehow > related to those revelations? NIST couldn't consider it for an AES candidate because it hadn't been invented yet. A brief timeline: 1997: NIST begins the AES selection process 1998: Rijndael is published 2000: Camellia is published too late to be considered for AES 2000: NESSIE begins evaluating new algorithms 2000: CRYPTREC begins evaluating new algorithms 2001: Rijndael is selected to become the Advanced Encryption Standard 2003: CRYPTREC and NESSIE each select Camellia From rjh at sixdemonbag.org Sun Sep 8 01:53:51 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 07 Sep 2013 19:53:51 -0400 Subject: Recommended key size for life long key In-Reply-To: References: Message-ID: <522BBC8F.7060607@sixdemonbag.org> On 9/7/2013 5:35 PM, Ole Tange wrote: > Feel free to let me know if you feel I have left out important concerns. The good news is that you are not your ideas. Whether your ideas are good or bad has nothing to do with your worth as a person. A great paper won't make you a good human being -- I've known some true geniuses who are terrible people -- and a bad paper doesn't make you stupid, inferior, or bad. Now for the bad news: it's rubbish. NIST, RSA Data Security, Lenstra and Schneier (just to name four) have been extraordinarily careful about their long-term recommendations. None of them have been willing to project beyond about 25 years in the future. They have all shared their reasoning for their circumspection and detailed the factors that make long-term prediction difficult. You're projecting 87 years into the future. Why should we have any confidence in your analysis? In my opinion, you very much need to address two questions right off: 1. What factors have prevented NIST, RSA Data Security, Lenstra, Schneier, et al., from being able to make an 87-year prediction? 2. Why do these factors not apply to your analysis? Without those two questions being raised directly and immediately, there is no reason for a reader to have any confidence in what you've written. It is far more likely that you are limited by the same factors that have limited NIST, RSA Data Security, Lenstra, Schneier, et al., and are simply not aware of how those factors are confounding your analysis. There are a large number of other errors in your write-up, but those two questions above are the most critical shortcomings. Without answers to those two questions I can see no reason for anyone to take your writeup seriously. From wk at gnupg.org Sun Sep 8 08:43:22 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 08 Sep 2013 08:43:22 +0200 Subject: NSA backdoors and Set Preferred Cipher In-Reply-To: <522BB8E8.2040307@sixdemonbag.org> (Robert J. Hansen's message of "Sat, 07 Sep 2013 19:38:16 -0400") References: <522B17ED.5030008@charter.net> <522BB8E8.2040307@sixdemonbag.org> Message-ID: <878uz7erud.fsf@vigenere.g10code.de> On Sun, 8 Sep 2013 01:38, rjh at sixdemonbag.org said: > Twofish, but the recipient doesn't support it... then CAST5, but that's > not supported... then Blowfish, again not supported... hey, 3DES. 3DES Nitpicking: CAST5 is a SHOULD algorithm Implementations MUST implement TripleDES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate [...] thus most applications will actually stop right here. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg at oneiroi.net Sun Sep 8 09:04:06 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sun, 08 Sep 2013 09:04:06 +0200 Subject: NSA backdoors and Set Preferred Cipher In-Reply-To: <522BBAAE.9070202@sixdemonbag.org> References: <522B17ED.5030008@charter.net> <522B93A8.1040402@oneiroi.net> <522BBAAE.9070202@sixdemonbag.org> Message-ID: <522C2166.306@oneiroi.net> On 09/08/2013 01:45 AM, Robert J. Hansen wrote: > On 9/7/2013 4:59 PM, Filip M. Nowak wrote: >> Is CAMELLIA's pick as least preferred cipher - omitted/disregarded by >> NIST (US) but certified by NESSIE (EU) and CRYPTREC (Japan) - is somehow >> related to those revelations? > > NIST couldn't consider it for an AES candidate because it hadn't been > invented yet. > > A brief timeline: > > 1997: NIST begins the AES selection process > 1998: Rijndael is published > 2000: Camellia is published too late to be considered for AES > 2000: NESSIE begins evaluating new algorithms > 2000: CRYPTREC begins evaluating new algorithms > 2001: Rijndael is selected to become the Advanced Encryption Standard > 2003: CRYPTREC and NESSIE each select Camellia > Good point! Regards, Filip M. Nowak From tange at gnu.org Sun Sep 8 10:29:18 2013 From: tange at gnu.org (Ole Tange) Date: Sun, 8 Sep 2013 10:29:18 +0200 Subject: Recommended key size for life long key In-Reply-To: <1893947.xO5ZYBzj2V@thufir.ingo-kloecker.de> References: <1893947.xO5ZYBzj2V@thufir.ingo-kloecker.de> Message-ID: On Sun, Sep 8, 2013 at 12:06 AM, Ingo Kl?cker wrote: > On Saturday 07 September 2013 23:35:08 Ole Tange wrote: >> On Sat, Aug 31, 2013 at 11:46 AM, Ole Tange wrote: : >> http://oletange.blogspot.dk/2013/09/life-long-key-size.html : > but I'm pretty sure it's relevant for the > battery life of your and your communication partners' smart phones. In > particular, if you and your communication partners use equally large > keys and encrypt each and every email, SMS, chat message, etc. Assuming a new smartphone runs at 1 GHz with GnuPG 2.0 then decryption+verify or sign+encryption will be in the order of 10 seconds if both sender and receiver use 10kbit keys. So we are talking about 10 seconds per RSA encrypted message. Potentially lower if the phone is multicore and GnuPG's RSA implementation supports parallelized RSA operations. If RSA is only used to negotiate the initial session key, then I would reckon the 10 seconds is hardly noticeable from a battery perspective. My old Nokia N900 with wifi on will let you sign+encryption 657 messages with 10kbit keys on a full battery using GnuPG 1.4.6. With GnuPG 2.0 that would be in the order of 1000 messages per charge. So where your concern really matters would be for high volume messages (100 per day or more) that are all RSA encrypted and are used on battery operated slow devices. Apart from email, can you mention any app that works like that today? If I am to include the battery perspective and speculations on what apps that _could_ be made, I should probably also include what would happen if smartphones get a cryptochip included (which would bring RSA operations into the millisecond range - thus rendering the battery concern moot). /Ole From anything.everything83 at gmail.com Sun Sep 8 08:37:34 2013 From: anything.everything83 at gmail.com (Francesco C.) Date: Sun, 8 Sep 2013 08:37:34 +0200 Subject: How can I send a public key exported with --armour option? Message-ID: Hello everybody, I'm a beginner of Gpg and encryption's world in general, so I apologize if my questions will be so banal. I created a new pair of public-private keys and now I'm trying to export the public one. I read the "How-To" and it describe the more useful option --armour. I can't understand how to send a ASCII text print on my screen to an other user. Is not more useful the --output options? Thanks a lot to everybody! -- Francesco -------------- next part -------------- An HTML attachment was scrubbed... URL: From tange at gnu.org Sun Sep 8 10:32:50 2013 From: tange at gnu.org (Ole Tange) Date: Sun, 8 Sep 2013 10:32:50 +0200 Subject: Recommended key size for life long key In-Reply-To: <522BBC8F.7060607@sixdemonbag.org> References: <522BBC8F.7060607@sixdemonbag.org> Message-ID: On Sun, Sep 8, 2013 at 1:53 AM, Robert J. Hansen wrote: > On 9/7/2013 5:35 PM, Ole Tange wrote: >> Feel free to let me know if you feel I have left out important concerns. : > You're projecting 87 years into the future. Why should we have any > confidence in your analysis? The short answer: You do not have to trust projection to use the other findings. If you have a better projection, use that instead. The projection is based on www.win.tue.nl/~klenstra/key.pdf but I think you are completely missing the point: The projection is not some sort of guarantee that 10kbit keys will not be broken before 2100 (which is stressed by using the phrase 'It should be stressed that this is only a guess'), but simply to give an estimate on what key size we cannot given our knowledge _today_ say will be broken for sure. Even if the guess proves to be wrong it will still be better than 4kbit which seems fairly likely to be broken by 2100 (at least if no attack is found that renders RSA completely useless). If you can come with a better supported guess for the key length, that would be great. Based on the guess that 10kbit has the potential of not being broken within a person's life span: What problems would you experience if you chose to use a 10kbit key today instead of a 4kbit key (which seems to be the common choice - but which we are fairly certain will be broken before 2100)? THIS (i.e. the problems by using 10kbit today instead of 4kbit) being the focus of the document. So if you are focusing on the projection of the key size, help me rephrase the text so you do not focus on that, because that has never been the intended focus of the document. > There are a large number of other errors in your write-up, but those two > questions above are the most critical shortcomings. Having now addressed that question, please elaborate what other errors you find. /Ole From pete at heypete.com Sun Sep 8 10:57:49 2013 From: pete at heypete.com (Pete Stephenson) Date: Sun, 8 Sep 2013 10:57:49 +0200 Subject: How can I send a public key exported with --armour option? In-Reply-To: References: Message-ID: On Sun, Sep 8, 2013 at 8:37 AM, Francesco C. wrote: > Hello everybody, I'm a beginner of Gpg and encryption's world in general, so > I apologize if my questions will be so banal. Hi Francesco, Welcome! No need to apologize! We're all pretty friendly here. :) > I created a new pair of public-private keys and now I'm trying to export the > public one. Excellent. > I read the "How-To" and it describe the more useful option --armour. I can't > understand how to send a ASCII text print on my screen to an other user. > > Is not more useful the --output options? You can add "--armor" (or "--armour", I had no idea that GnuPG supported the British spelling of the word. Interesting!) to essentially any command that involves data being output. For consistency I will use the spelling without the "u", but both are equivalent. For example, if you created a key with the KeyID of "KEYID", you could export the public key for it to the terminal using "gpg --export --armor KEYID". If you wish to export the public key to a text file which you can then include in an email, post on the web, etc., you could use "gpg --export --armor KEYID > filename.txt" where 'filename' is whatever you wish the file to be called. The armor feature is indeed quite useful, but it comes at a slight cost: armored files/messages are slightly larger than their unarmored, binary counterparts. Cheers! -Pete From anything.everything83 at gmail.com Sun Sep 8 13:47:44 2013 From: anything.everything83 at gmail.com (Francesco S.) Date: Sun, 08 Sep 2013 13:47:44 +0200 Subject: How can I send a public key exported with --armour option? In-Reply-To: References: Message-ID: <2c99618e-94c6-42c5-b94f-fbb5a938409e@email.android.com> Pete Stephenson wrote: >On Sun, Sep 8, 2013 at 8:37 AM, Francesco C. > > >Hi Francesco, > >Welcome! No need to apologize! We're all pretty friendly here. :) > I'm glad to know that. :-) >You can add "--armor" (or "--armour", I had no idea that GnuPG >supported the British spelling of the word. Interesting!) to >essentially any command that involves data being output. For >consistency I will use the spelling without the "u", but both are >equivalent. > Yep, another thing... My English is scholastic, so not always I will be clear in my exposition, I also apologize of that. Anyway you are right, Gnupg recognize only "armor" :-) >For example, if you created a key with the KeyID of "KEYID", you could >export the public key for it to the terminal using "gpg --export >--armor KEYID". > >If you wish to export the public key to a text file which you can then >include in an email, post on the web, etc., you could use "gpg >--export --armor KEYID > filename.txt" where 'filename' is whatever >you wish the file to be called. > Perfect, this is what I needed! >The armor feature is indeed quite useful, but it comes at a slight >cost: armored files/messages are slightly larger than their unarmored, >binary counterparts. We are talking of some Kbytes, I think this cost will be absolutely sosteinable ;-) >Cheers! >-Pete Thank you for All Francesco -- Sent with my mobile phone & Android with K-9 Mail. From rjh at sixdemonbag.org Sun Sep 8 17:07:21 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 08 Sep 2013 11:07:21 -0400 Subject: Recommended key size for life long key In-Reply-To: References: <522BBC8F.7060607@sixdemonbag.org> Message-ID: <522C92A9.5010908@sixdemonbag.org> On 9/8/2013 4:32 AM, Ole Tange wrote: > The short answer: You do not have to trust projection to use the > other findings. If you have a better projection, use that instead. I do, actually. If I see that a major part of your write-up is seriously lacking in rigor, that causes me to suspect the rest of your write-up is similarly lacking. > this is only a guess'), but simply to give an estimate on what key > size we cannot given our knowledge _today_ say will be broken for > sure. We can't be sure 2048-bit keys will be broken by 2100. Likewise, it's within the realm of possibility 4096-bit keys will be broken tomorrow. Factoring/discrete-log technology has stalled out for the last 20-odd years after some very promising periods in the late-80s and early-90s. The dominant technology used today is the General Number Field Sieve, which was first developed around 1993. This shouldn't really surprise us. Factoring is *hard*. It's provably an NP problem, which means that (assuming P!=NP) there will never, ever, ever, be an efficient algorithm for it [1]. We've been looking for efficient ways to factor ever since Eratosthenes; it is quite likely there simply isn't one. So on the one hand, focusing on advances in factoring technology is suspect. And on the other hand, you're completely ignoring the possibility of vast advances in other areas of number theory. A couple of years ago Dan Boneh published a paper that rocked a lot of people's worlds to the core: he proved that *breaking RSA is not equivalent to factoring* [2]. The RSA Conjecture ("breaking RSA is equivalent to factoring") is *false*. Wow. And since the long-term security of RSA is predicated on the RSA Conjecture, and the idea there's no other way to attack RSA than by factoring... along comes Dan Boneh and opens the door to the possibility of there existing many other mathematical ways to attack RSA. Some of them will undoubtedly be worse than factoring. Some of them may be better. It's possible one of them might even be in P. And how do we project for the future when we cannot predict if, when, one of these Boneh approaches will be developed? I am not even scratching the surface of the difficulties involved in long-term prediction. I know exactly where my limitations lie in making long-term predictions. I doubt you have a better look on the future than I do -- and given your write-up doesn't even address the factors that make long-term prediction difficult, I have no confidence whatsoever in your 87-year projection. [1] An efficient *classical* algorithm for it. Although factoring is in NP, it's also in BQP, which means efficient quantum algorithms exist. [2] http://crypto.stanford.edu/~dabo/abstracts/no_rsa_red.html Further: By 2100, I expect some kind of quantum computation to exist. 87 years is a long time for technology: it took us fewer than seventy years to go from the first airplane flight to Armstrong's first steps on the Moon. It took fewer than thirty-five years to go from ENIAC to the Apple II. Quantum computing, if-and-when it appears in a large scale (hundreds or more of qubits in an ensemble), will transform our society in ways that are hard to imagine. It is literally science fiction technology. Right now, two of the few things we know for a fact is that quantum computers will be able to efficiently factor large composites and compute discrete logarithms in finite fields. That means RSA and Elgamal are both out the window the instant quantum computing becomes a possibility. Your write-up barely mentions the possibility of quantum computing, and says nothing of the consequences should it come to pass. Even just an "I arbitrarily project that quantum computing will become possible in 2050 and mainstream by 2060" would be better, because at least you've drawn a line on the map and said "beyond 2060 there be dragons, and the world will be radically unpredictable." What do I mean by "radically unpredictable"? Imagine that you're an academic in the early 1930s, and you're working on an estimate of how much computation humanity has done. You bury yourself in studies of how many computers (remember, in the 1930s, "computer" was an occupation) there are today, how much growth there has been for the field, how many there were in the past, and you project dramatic exponential growth for the profession of computing. Then along comes ENIAC which, in the first fifteen minutes of its operation, did more computing than had been performed in the whole of human history up to that point. All of your estimates are immediately null and void because the future has bushwhacked you. *The very first quantum computer with more than two hundred qubits will, in its very first calculation, do more computation than has been done by all the world's computers from 1945 to the present.* Anyone who attempts to predict the future of computing past the introduction of quantum elements is either (a) a science fiction author or (b) living in sin. Your write-up also doesn't mention thermodynamic limits on computing. The Landauer bound and the Margolus-Levitin limit are well-known physical constraints on how much energy is used to flip a bit and how much time it takes, at a given energy level, to flip a bit. Past RSA-3072 (which, per NIST, is conjectured to have a 128-bit keyspace), these physical limits require you to release a level of heat comparable to a nuclear blast. The only way to get around these limits is to reduce the effective keyspace of factoring the composite (which, as mentioned above, we might never be able to do due to factoring being solidly in NP) or to find completely new mathematical ways of attacking the RSA Problem (which, although Boneh demonstrated probably existed, we have no idea how to do, and if/when we do will possibly completely invalidate RSA as an algorithm). > Based on the guess that 10kbit has the potential of not being broken > within a person's life span: What problems would you experience if > you chose to use a 10kbit key today instead of a 4kbit key (which > seems to be the common choice - but which we are fairly certain will > be broken before 2100)? THIS (i.e. the problems by using 10kbit > today instead of 4kbit) being the focus of the document. Then you're putting the cart before the horse. If you're basing that on a *guess*, then my guess is for RSA-16k and Werner's guess is for RSA-8k and Phil Stracchino's guess is for RSA-4k and... [3] You first need to provide evidence that your RSA-10k projection has a good chance of being correct in 87 years. Once you do that, *then* it will be time to start looking at timing data and thinking about how best to adopt RSA-10k today. But before you do that, your guess is no more valid than mine, Werner's, or Phil Stracchino's. And we could all come up with our own timing data and talk about the need to adopt our guesses, and the ultimate result would be an awful lot of confusion. A great deal of heat and very little light. [3] These guesses are completely made up, and I'm just using the names of random people within the community. > So if you are focusing on the projection of the key size, help me > rephrase the text so you do not focus on that, because that has never > been the intended focus of the document. That is a necessary precondition to taking the rest of your document seriously. Otherwise you're left with just a table of, "hi, I did some timings on RSA-10k and here's what I found." It's not very useful. > Having now addressed that question, please elaborate what other > errors you find. You have not addressed those two questions. From kloecker at kde.org Sun Sep 8 18:05:29 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 08 Sep 2013 18:05:29 +0200 Subject: Recommended key size for life long key In-Reply-To: References: <1893947.xO5ZYBzj2V@thufir.ingo-kloecker.de> Message-ID: <1520526.ZLUfSxf362@thufir.ingo-kloecker.de> On Sunday 08 September 2013 10:29:18 Ole Tange wrote: > On Sun, Sep 8, 2013 at 12:06 AM, Ingo Kl?cker wrote: > > On Saturday 07 September 2013 23:35:08 Ole Tange wrote: > >> On Sat, Aug 31, 2013 at 11:46 AM, Ole Tange wrote: > >> > >> http://oletange.blogspot.dk/2013/09/life-long-key-size.html > > > > but I'm pretty sure it's relevant for the > > battery life of your and your communication partners' smart phones. > > In particular, if you and your communication partners use equally > > large keys and encrypt each and every email, SMS, chat message, > > etc. > Assuming a new smartphone runs at 1 GHz with GnuPG 2.0 then > decryption+verify or sign+encryption will be in the order of 10 > seconds if both sender and receiver use 10kbit keys. So we are talking > about 10 seconds per RSA encrypted message. Potentially lower if the > phone is multicore and GnuPG's RSA implementation supports > parallelized RSA operations. > > If RSA is only used to negotiate the initial session key, then I would > reckon the 10 seconds is hardly noticeable from a battery > perspective. My old Nokia N900 with wifi on will let you > sign+encryption 657 messages with 10kbit keys on a full battery using > GnuPG 1.4.6. With GnuPG 2.0 that would be in the order of 1000 > messages per charge. > > So where your concern really matters would be for high volume messages > (100 per day or more) that are all RSA encrypted and are used on > battery operated slow devices. Apart from email, can you mention any > app that works like that today? Some chat software (on PCs) uses GnuPG for encryption, but I'm not sure whether they use RSA only for the initial key exchange or for every chat message. Not having a smart phone I have no idea whether there are similar apps for smart phones. Having said this, in view of Snowden's disclosures, there's definitely a need for such apps. > If I am to include the battery perspective and speculations on what > apps that _could_ be made, I should probably also include what would > happen if smartphones get a cryptochip included (which would bring RSA > operations into the millisecond range - thus rendering the battery > concern moot). Using a cryptochip might not only render the battery concern moot, but this whole discussion about life long keys because even a 1mbit RSA key is useless if the session keys created by the cryptochip are easily guessable by the NSA. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Sun Sep 8 18:55:15 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 08 Sep 2013 18:55:15 +0200 Subject: Recommended key size for life long key In-Reply-To: <522C92A9.5010908@sixdemonbag.org> References: <522C92A9.5010908@sixdemonbag.org> Message-ID: <1404847.cI8id9khTC@inno.berlin.laging.de> Am So 08.09.2013, 11:07:21 schrieb Robert J. Hansen: Once more I feel enlightened (and I am sure I am not the only one). From time to time it seems appropriate to me that someone says thank you. So this time I do that. -- 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 werewolf6851 at gmail.com Sun Sep 8 20:43:51 2013 From: werewolf6851 at gmail.com (Werewolf) Date: Sun, 8 Sep 2013 13:43:51 -0500 Subject: How can I send a public key exported with --armour option? In-Reply-To: <2c99618e-94c6-42c5-b94f-fbb5a938409e@email.android.com> References: <2c99618e-94c6-42c5-b94f-fbb5a938409e@email.android.com> Message-ID: <20130908184351.GA3346@Vixen> On Sun, Sep 08, 2013 at 01:47:44PM +0200, Francesco S. wrote: > > > Pete Stephenson wrote: > >On Sun, Sep 8, 2013 at 8:37 AM, Francesco C. > > > > > >Hi Francesco, > > > >Welcome! No need to apologize! We're all pretty friendly here. :) > > > > I'm glad to know that. :-) > > >You can add "--armor" (or "--armour", I had no idea that GnuPG > >supported the British spelling of the word. Interesting!) to > >essentially any command that involves data being output. For > >consistency I will use the spelling without the "u", but both are > >equivalent. > > > > Yep, another thing... My English is scholastic, so not always I will be clear in my exposition, I also apologize of that. > Anyway you are right, Gnupg recognize only "armor" :-) > > >For example, if you created a key with the KeyID of "KEYID", you could > >export the public key for it to the terminal using "gpg --export > >--armor KEYID". > > > >If you wish to export the public key to a text file which you can then > >include in an email, post on the web, etc., you could use "gpg > >--export --armor KEYID > filename.txt" where 'filename' is whatever > >you wish the file to be called. > > > Perfect, this is what I needed! > > >The armor feature is indeed quite useful, but it comes at a slight > >cost: armored files/messages are slightly larger than their unarmored, > >binary counterparts. > > We are talking of some Kbytes, I think this cost will be absolutely sosteinable ;-) > > >Cheers! > >-Pete > > Thank you for All > > Francesco With a new key, wouldn't be that bad. There's a 3k difference between my public key export and public key export with ascii armor. Part of that is because it has 6 subkeys. (4 of which have expired) Wolf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From gnupg at oneiroi.net Sun Sep 8 22:02:39 2013 From: gnupg at oneiroi.net (Filip M. Nowak) Date: Sun, 08 Sep 2013 22:02:39 +0200 Subject: Recommended key size for life long key In-Reply-To: <522C92A9.5010908@sixdemonbag.org> References: <522BBC8F.7060607@sixdemonbag.org> <522C92A9.5010908@sixdemonbag.org> Message-ID: <522CD7DF.8050300@oneiroi.net> Hi On 09/08/2013 05:07 PM, Robert J. Hansen wrote: > On 9/8/2013 4:32 AM, Ole Tange wrote: >> The short answer: You do not have to trust projection to use the >> other findings. If you have a better projection, use that instead. > > (...) > We can't be sure 2048-bit keys will be broken by 2100. Likewise, it's > within the realm of possibility 4096-bit keys will be broken tomorrow. Interesting comment for a sworn enemy of longer then default/hardcoded key length :) (no provocation or trolling intended Robert) Citing B. Schneier: "(...) If we think that's the case, the fix is easy: increase the key lengths."* > Factoring/discrete-log technology has stalled out for the last 20-odd > years after some very promising periods in the late-80s and early-90s. > The dominant technology used today is the General Number Field Sieve, > which was first developed around 1993. > > This shouldn't really surprise us. Factoring is *hard*. It's provably > an NP problem, which means that (assuming P!=NP) there will never, ever, > ever, be an efficient algorithm for it [1]. We've been looking for > efficient ways to factor ever since Eratosthenes; it is quite likely > there simply isn't one. > (...) After Mr Schneier again: "Breakthroughs in factoring have occurred regularly over the past several decades, allowing us to break ever-larger public keys. Much of the public-key cryptography we use today involves elliptic curves, something that is even more ripe for mathematical breakthroughs. It is not unreasonable to assume that the NSA has some techniques in this area that we in the academic world do not. Certainly the fact that the NSA is pushing elliptic-curve cryptography is some indication that it can break them more easily."** And one more time: "If we think that's the case, the fix is easy: increase the key lengths."* *, ** - https://www.schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html Regards, Filip M. Nowak From avi.wiki at gmail.com Sun Sep 8 21:15:24 2013 From: avi.wiki at gmail.com (Avi) Date: Sun, 8 Sep 2013 15:15:24 -0400 Subject: Recommended key size for life long key In-Reply-To: <1404847.cI8id9khTC@inno.berlin.laging.de> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 As must I. Robert has one of the clearest modes of exposition from which I have ever been fortunate to benefit. - --Avi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (MingW32) Comment: Most recent key: Click show in box @ http://is.gd/4xJrs iL4EAREIAGYFAlIszFZfGGh0dHA6Ly9rZXlzZXJ2ZXIudWJ1bnR1LmNvbS9wa3Mv bG9va3VwP29wPWdldCZoYXNoPW9uJmZpbmdlcnByaW50PW9uJnNlYXJjaD0weDBE NjJCMDE5RjgwRTI5RjkACgkQDWKwGfgOKflqQgD/cj8FdidQyWj3UqZ9kEjPnzTd bzXp1b3hIAgpeUiGV7oA/jIQoveP0PBnNG773wyN/WaQtATIbKHKDyV9B9wUHTwu =+VfZ -----END PGP SIGNATURE----- ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 On Sun, Sep 8, 2013 at 12:55 PM, Hauke Laging wrote: > Am So 08.09.2013, 11:07:21 schrieb Robert J. Hansen: > > Once more I feel enlightened (and I am sure I am not the only one). From time > to time it seems appropriate to me that someone says thank you. So this time I > do that. > > -- > Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ > OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From jeandavid8 at verizon.net Sun Sep 8 23:11:26 2013 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Sun, 08 Sep 2013 17:11:26 -0400 Subject: Recommended key size for life long key In-Reply-To: <522CD7DF.8050300@oneiroi.net> References: <522BBC8F.7060607@sixdemonbag.org> <522C92A9.5010908@sixdemonbag.org> <522CD7DF.8050300@oneiroi.net> Message-ID: <522CE7FE.8050709@verizon.net> On 09/08/2013 04:02 PM, Filip M. Nowak wrote: [snip] > "Breakthroughs in factoring have occurred regularly over the past > several decades, allowing us to break ever-larger public keys. Much of > the public-key cryptography we use today involves elliptic curves, > something that is even more ripe for mathematical breakthroughs. It is > not unreasonable to assume that the NSA has some techniques in this area > that we in the academic world do not. Certainly the fact that the NSA is > pushing elliptic-curve cryptography is some indication that it can break > them more easily."** > I would think the NSA would have two teams, that might work together at times. One is interested in breaking the encryption of those they deem to be enemies. The other is making encryption mechanisms that are as difficult to break as they know how, for the use of our own secret services, state department, and so on. So perhaps the snooping division is pushing elliptic curve technology because they have a technique for breaking those that they have not published and that has not yet been leaked. But the other division is developing some superior technique, such as hyperbolic curves (I made that name up; it has nothing to do with reality) that is at least an order of magnitude more difficult to break. For use by any government agency that has secrets to keep but must communicate from place to place, or from time to time. Some might need public key encryption methods, some might manage with symmetric key methods. -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key:166D840A 0C610C8B Registered Machine 1935521. /( )\ Shrewsbury, New Jersey http://counter.li.org ^^-^^ 16:55:01 up 10 days, 23:40, 3 users, load average: 4.76, 4.43, 4.30 From ekleog at gmail.com Sun Sep 8 23:00:16 2013 From: ekleog at gmail.com (Leo Gaspard) Date: Sun, 8 Sep 2013 23:00:16 +0200 Subject: Recommended key size for life long key In-Reply-To: References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> Message-ID: <20130908210016.GA432@leortable> On Sun, Sep 08, 2013 at 03:15:24PM -0400, Avi wrote: > As must I. Robert has one of the clearest modes of exposition from > which I have ever been fortunate to benefit. I have to agree on this point. The issue is that I disagree with him on his stance : in my opinion, having a schedule stating when the keylengths will become insecure is useless : we just have to be able to predict that longer keys will most likely be at least as hard to crack. And this means that, as long as the drawbacks associated with the use of the key are assumed by the key owner only (as the tables state, encrypt and verify operations being almost unchanged in time), preconizing 10kbit RSA keys is no issue, and can only improve overall security, to the key owner's usability's detriment at most. And each key owner might choose whatever keylength they feel best suits them, according to their usability / security needs ; as long as these choices do not impede other keyholders' usability or security. BTW, the statement "[Dan Boneh] proved that breaking RSA is not equivalent to factoring" is wrong : he did not prove that breaking RSA is easier than factoring numbers ; only that a whole ways of proving that breaking RSA is as hard as factoring numbers are ineffective ; thereby reducing the search space for potential valid ways of proving the conjecture. Hence the title of the article : "Breaking RSA *may* not be equivalent to factoring". Please pardon me if I misunderstood the english used in the abstract. Oh, and... Please correct me if I am mistaken, but I believe the best we can do at the moment, even with a quantum computer is Shor's algorithm, taking a time of O(log^3 n). Thus, going from 2k keys to 10k keys makes if approx. 125 times harder to break. Sure, not so wonderful as what it is today, but if the constant is large enough (which, AFAIK, we do not know yet), it might be a practical attack infeasible for a few more years. So, back to the initial question, I do not understand why the article should be judged so poor. No, to me the article is not about predicting 87 years in front of us. To me, the article is about stating that using 10k RSA keys is not as bad as one might think at first. The gist of the article is, to me, precisely this set of tables. And the first part is, still in my opinion, only here to explain why 10k RSA keys were chosen for the experiment. Explaining that, according to our current estimates, they might potentially resist until 2100, assuming no major breakthrough is made until then in the cryptanalysis field. You might notice that such precautions are taken in the article too. So... I find the article interesting. I would not have thought "everyday" use of a 10k key would have so little drawbacks. And, finally, I want to recall that signing keys need not be the same as certifying key, thus allowing us to lose the signature time only for certifications, and use "normal" keys the rest of the time ; thus getting the best of both worlds, by being able to upgrade signing keys to stronger ones without losing one's WoT. The only remaining drawback being when others certify our master key. Cheers, Leo From dougb at dougbarton.us Mon Sep 9 00:25:29 2013 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 08 Sep 2013 15:25:29 -0700 Subject: Recommended key size for life long key In-Reply-To: <20130908210016.GA432@leortable> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> Message-ID: <522CF959.8000106@dougbarton.us> On 09/08/2013 02:00 PM, Leo Gaspard wrote: > And this means that, as long as the drawbacks associated with the use of the key > are assumed by the key owner only (as the tables state, encrypt and verify > operations being almost unchanged in time), preconizing 10kbit RSA keys is no > issue, and can only improve overall security, to the key owner's usability's > detriment at most. The problem here is the "knowledge sieve" issue. Ole asked some questions and did some research, then filtered what he got back through a mixture of his preconceived notions, desires, etc. I'm not saying that he picked only the data that agreed with his desired conclusion, but he seems to have studiously ignored all of the facts that point to why what he's trying to do is a bad idea. Now the next reader is going to come along, very likely someone who is more naive about encryption than Ole is, and filter that blog post through his own preconceptions, impatience, etc.; and come to the conclusion, "If I make a 10k key it'll be safe for life!" Has Ole done this reader a disservice? I think the biggest disservice is a false sense of security. If your attacker can only pole vault 10 meters, and you already have a fence 1,000 meters high, does a 100,000 meter fence make you any more secure? And what happens if your attacker develops a technique that is universally effective against all fences, no matter the height? The flip side question is, "What harm is there to using a 10k key?" Aside from CPU and storage for the user of the key, everyone else in the community bears part of the "cost" when they have to verify a signature on an e-mail, for example. Is that a serious enough problem to cause us to wish no one would suggest the use of 10k keys? I don't know. ... and all of this is presupposing that his "only a guess" has any validity to it at all. I don't know the work by Arjen K. Lenstra and Eric R. Verheul that he based his graph on, and I have no idea if Ole's method of projecting key sizes out into the future is valid. What I DO know (and Robert emphasized this point in his first post), is that those authors, and other serious heavyweights in the crypto community have not felt comfortable doing what Ole has done. That fact alone should be enough reason for anyone not to take Ole's blog post seriously. Doug From rjh at sixdemonbag.org Mon Sep 9 00:29:01 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 08 Sep 2013 18:29:01 -0400 Subject: Recommended key size for life long key In-Reply-To: <20130908210016.GA432@leortable> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> Message-ID: <522CFA2D.6090904@sixdemonbag.org> On 9/8/2013 5:00 PM, Leo Gaspard wrote: > BTW, the statement "[Dan Boneh] proved that breaking RSA is not > equivalent to factoring" is wrong : he did not prove that breaking > RSA is easier than factoring numbers ; only that a whole ways of > proving that breaking RSA is as hard as factoring numbers are > ineffective ; thereby reducing the search space for potential valid > ways of proving the conjecture. Hence the title of the article : > "Breaking RSA *may* not be equivalent to factoring". Please pardon > me if I misunderstood the english used in the abstract. >From the abstract, "We provide evidence that breaking low-exponent RSA cannot be equivalent to factoring integers ... an oracle for breaking RSA does not help in factoring integers." The title involves the word 'may' out of an abundance of caution and a decent respect for the opinions of the mathematical community. Whether he's proven it or not is not really for him to claim, but for the mathematical community. He's provided a conjecture and strong evidence to support it, and I feel his conjecture is well-proven. Your mileage may vary. :) > Oh, and... Please correct me if I am mistaken, but I believe the > best we can do at the moment, even with a quantum computer is Shor's > algorithm, taking a time of O(log^3 n). Thus, going from 2k keys to > 10k keys makes if approx. 125 times harder to break. A factor of 125 is so small as to be irrelevant. The real obstacle is that Shor's algorithm requires 2n qubits to be formed in an ensemble, so you'd be going from requiring a 4k quantum computer to a 20k quantum computer. Given decoherence, that might amount to a much more insurmountable obstacle. Still, my money is on QC. > And the first part is, still in my opinion, only here to explain why > 10k RSA keys were chosen for the experiment. Explaining that, > according to our current estimates, they might potentially resist > until 2100, assuming no major breakthrough is made until then in the > cryptanalysis field. The problem is the exact same thing can be said for RSA-2048. RSA-2048 is expected to last at least the next 25 years; it may last for the next century. Hard to say. Depends a lot on the progression of science fiction level technologies, like quantum computation. And again, anyone trying to predict out past about 25 years needs to explain why they are able to do this where NIST, RSA Data Security, and so many others have failed to be able to do this. From ekleog at gmail.com Mon Sep 9 00:54:28 2013 From: ekleog at gmail.com (Leo Gaspard) Date: Mon, 9 Sep 2013 00:54:28 +0200 Subject: Recommended key size for life long key In-Reply-To: <522CFA2D.6090904@sixdemonbag.org> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> <522CFA2D.6090904@sixdemonbag.org> Message-ID: <20130908225428.GB432@leortable> On Sun, Sep 08, 2013 at 06:29:01PM -0400, Robert J. Hansen wrote: > A factor of 125 is so small as to be irrelevant. Well... If factoring takes a month, with the factor of 125, it takes ten years. Seems not that irrelevant to me. Of course, this is made using completely made up numbers, as I do not at all know how fast QC will be able to do the factoring. > The real obstacle is that Shor's algorithm requires 2n qubits to be > formed in an ensemble, so you'd be going from requiring a 4k quantum > computer to a 20k quantum computer. Given decoherence, that might > amount to a much more insurmountable obstacle. Still, my money is on QC. Strangely enough, I would have thought 4k qubits would be quite a huge need, thus meaning we would have overcome the major problems with decoherence. But, again, not being a quantum physicist, I cannot be relied upon on that subject. > The problem is the exact same thing can be said for RSA-2048. RSA-2048 > is expected to last at least the next 25 years; it may last for the next > century. Hard to say. Depends a lot on the progression of science > fiction level technologies, like quantum computation. And again, anyone > trying to predict out past about 25 years needs to explain why they are > able to do this where NIST, RSA Data Security, and so many others have > failed to be able to do this. You are right, we do not know whether RSA-2048 will hold or not. The only point I was saying was that RSA-10k will quite likely (even more likely than NIST's predictions, IMHO) resist at least as long as RSA-2048. That said, everything is a matter of preference. The only reason I would see for using a 10k key would be in order to encrypt or sign documents that should be valid for years -- more years than what we are able to forecast. Because, unfortunately (or not, depending on the viewpoint), cryptanalysis is retroactive. That said, cheers ! Leo From rjh at sixdemonbag.org Mon Sep 9 04:04:07 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 08 Sep 2013 22:04:07 -0400 Subject: Recommended key size for life long key In-Reply-To: <20130908225428.GB432@leortable> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> <522CFA2D.6090904@sixdemonbag.org> <20130908225428.GB432@leortable> Message-ID: <522D2C97.2070400@sixdemonbag.org> On 09/08/2013 06:54 PM, Leo Gaspard wrote: > Well... If factoring takes a month, with the factor of 125, it takes > ten years. Seems not that irrelevant to me. Or you wait three years and let technological progression reduce the work factor for you. Or you throw 125 machines at it instead of one. Or... etc. If something is unsafe at work level X, it won't be safe at work level 125X. > Strangely enough, I would have thought 4k qubits would be quite a > huge need, thus meaning we would have overcome the major problems > with decoherence. There's a big difference between physics and engineering. For an example, look at the history of aviation. During the era of propeller-driven aircraft we were limited by the engineering constraints of piston-driven propellers. People said, "ah, but if we could only perfect jet propulsion we could accelerate as fast as we wanted!" Well-respected engineers like Buckminster Fuller talked about doing space launches with jet aircraft -- accelerating up to orbital velocity, releasing the satellite, and landing the delivery aircraft again. Once we invented jet engines we discovered those were pipe dreams. There was a new limitation that no one had considered prior to the perfection of jet engines: since the air in the engine must be slowed to subsonic velocities, that sharply limits just how far supersonic a jet engine can go. There was a new speed limit to replace the old speed limit -- and a speed limit we didn't foresee until we actually had the new technology to play with. Nowadays people are talking about developing scramjets to overcome the limitations of jet engines -- supersonic combustion within the engine. And the old ideas from the 1920s are coming back around again, of using scramjets to deliver satellites (or bombs, if you're working on defense contracts). And I have no doubt that if/when we perfect scramjet technology we'll discover a new limitation, one we couldn't have foreseen before we had working scramjets to play with. So, yeah. A 4k ensemble would mean we'd overcome the decoherence problem, but really, so would a 200-qubit ensemble, or even a 50-bit ensemble. I'm not skeptical about our ability to overcome decoherence; Bill Unruh tells me that we know how to do it in a physics level and it's only a matter of time until engineering catches up. I'm skeptical about our ability to overcome the new limits which will arise, limits we are at present unaware of. > But, again, not being a quantum physicist, I cannot be relied upon > on that subject. Nor am I, but Bill Unruh is. :) I also attended grad school with Ben Moehlmann, who has since received his Ph.D. in quantum computation. Ben's been a great resource over the years for this stuff. I never have a conversation with him without walking away staggering under the weight of the new knowledge. I am not a quantum computation expert, but I hang out with some really cool nerds. :) From John at enigmail.net Mon Sep 9 09:03:45 2013 From: John at enigmail.net (John Clizbe) Date: Mon, 09 Sep 2013 02:03:45 -0500 Subject: Recommended key size for life long key In-Reply-To: <522C92A9.5010908@sixdemonbag.org> References: <522BBC8F.7060607@sixdemonbag.org> <522C92A9.5010908@sixdemonbag.org> Message-ID: <522D72D1.3090802@enigmail.net> Robert J. Hansen wrote: > >> Based on the guess that 10kbit has the potential of not being broken >> within a person's life span: What problems would you experience if >> you chose to use a 10kbit key today instead of a 4kbit key (which >> seems to be the common choice - but which we are fairly certain will >> be broken before 2100)? THIS (i.e. the problems by using 10kbit >> today instead of 4kbit) being the focus of the document. > > Then you're putting the cart before the horse. If you're basing that on > a *guess*, then my guess is for RSA-16k and Werner's guess is for RSA-8k > and Phil Stracchino's guess is for RSA-4k and... [3] > > You first need to provide evidence that your RSA-10k projection has a > good chance of being correct in 87 years. Once you do that, *then* it > will be time to start looking at timing data and thinking about how best > to adopt RSA-10k today. But before you do that, your guess is no more > valid than mine, Werner's, or Phil Stracchino's. And we could all come > up with our own timing data and talk about the need to adopt our > guesses, and the ultimate result would be an awful lot of confusion. A > great deal of heat and very little light. > > > [3] These guesses are completely made up, and I'm just using the names > of random people within the community. And Rob's friend, John Clizbe, hasn't even made a projection for RSA, because if he wants anything past 3072 bit RSA, he's going to switch to ECC. But honestly, I think that even switching to ECC is no guarantee we'll have more than 25 years or so of security. Frankly, predicting tech progression is the worst kind of voodoo. Over the summer of 2010, readers of the [Cryptography] mailing list were reminded that in 1993, the "experts" thought that 1024-bit RSA 'should be ok (safe from key-factoring attacks) for "a few decades".' 1.75 decades later it's essentially history. [few>=3] There /IS/ a reason NIST and the TLAs aren't pushing 4k and higher RSA, it's inefficient. For multiple senses of "inefficient". RSA-3072 has a 128-bit keyspace, RSA-4096 has only about a 140-bit keyspace. That's a lot of additional time/energy for crypto operations for only another, what, 12 bits? Past RSA-3072, RSA becomes a phenomenally inefficient way of adding keyspace. It just gets exponentially more ridiculous as key sizes increase. Several minutes to verify a signature makes such large key sizes non-starters. Folks using a baseline of a 1GHz cellphone seem to have no idea of the lifetimes involved in MIL-SPEC equipment. I'm sure there are some 1 MIPS VAX 11/780s still in military service somewhere. /MAYBE/ the 233Mhz hardened Pentium chips have been decommissioned by now. I should do a rebuild of libgcrypt on a 500MHz 64-bit uSPARCii. The timings from the make test phase ARE NOT pretty. At least it would be better than pulling numbers out of /dev/ass. -- 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 chd at chud.net Mon Sep 9 08:00:30 2013 From: chd at chud.net (Chris De Young) Date: Sun, 08 Sep 2013 23:00:30 -0700 Subject: GPG and Outlook revisited Message-ID: <522D63FE.50104@chud.net> Hello, It's been some time since I looked at options for integrating GPG and Outlook on Windows, and at the time there seemed to be no particularly good solutions. GPG4Win/Enigmail/Thunderbird works great for my personal use, but work mandates Outlook, and in light of the latest NSA-related info it seems a good time to revisit the options for reliable encryption in an Outlook/Exchange environment - if any. (Yes, one make the argument that there are probably NSA backdoors in Windows itself and so nothing I do here matters - but it still seems like a reasonable effort is probably better than throwing my hands in the air. :) ) Thanks! -Chris From rjh at sixdemonbag.org Mon Sep 9 09:42:16 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 09 Sep 2013 03:42:16 -0400 Subject: Recommended key size for life long key In-Reply-To: <522D72D1.3090802@enigmail.net> References: <522BBC8F.7060607@sixdemonbag.org> <522C92A9.5010908@sixdemonbag.org> <522D72D1.3090802@enigmail.net> Message-ID: <522D7BD8.5020000@sixdemonbag.org> On 9/9/2013 3:03 AM, John Clizbe wrote: > Several minutes to verify a signature makes such large key sizes non-starters. > Folks using a baseline of a 1GHz cellphone seem to have no idea of the > lifetimes involved in MIL-SPEC equipment. I'm sure there are some 1 MIPS VAX > 11/780s still in military service somewhere. /MAYBE/ the 233Mhz hardened > Pentium chips have been decommissioned by now. As a data point on that one: the 80386 production line shut down in 2007 after 22 years of production. It ran at a top speed of 25MHz, but was more frequently undervolted to enhance lifetime at the cost of reducing it to 16MHz. Today it's still a commonly embedded processor. For those who wonder why the 386 has survived even into the present day, it mostly has to do with legacy support and recertification costs. If you have a piece of Assembly from '86 that works just fine and which you paid a lot of money to develop and get certified for use in a certain environment running on x86 hardware, you will probably be very reluctant to hire the developers, pay for the re-engineering expense, and pay for the recertification expense, in order to get your application to run on a modern-day StrongARM. The embedded 80386 may be slow and antiquated, but it's *cheap*, and lets you leverage your existing resources. From rjh at sixdemonbag.org Mon Sep 9 09:49:08 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 09 Sep 2013 03:49:08 -0400 Subject: Recommended key size for life long key In-Reply-To: <522CF959.8000106@dougbarton.us> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> <522CF959.8000106@dougbarton.us> Message-ID: <522D7D74.3080206@sixdemonbag.org> On 9/8/2013 6:25 PM, Doug Barton wrote: > he seems to have studiously ignored all of the facts that point to > why what he's trying to do is a bad idea. Nitpick: I think what he's trying to do (make credible, accurate long-term projections) is a good idea. I just think he's going about it in a way that will not give credible or accurate answers, and that as a result his write-up is rubbish. From John at enigmail.net Mon Sep 9 09:52:18 2013 From: John at enigmail.net (John Clizbe) Date: Mon, 09 Sep 2013 02:52:18 -0500 Subject: GPG and Outlook revisited In-Reply-To: <522D63FE.50104@chud.net> References: <522D63FE.50104@chud.net> Message-ID: <522D7E32.70805@enigmail.net> Chris De Young wrote: > Hello, > > It's been some time since I looked at options for integrating GPG and > Outlook on Windows, and at the time there seemed to be no particularly > good solutions. GPG4Win/Enigmail/Thunderbird works great for my personal > use, but work mandates Outlook, and in light of the latest NSA-related > info it seems a good time to revisit the options for reliable encryption > in an Outlook/Exchange environment - if any. If you're already using the GPG4Win package, install the PGPOL Outlook plugin that ships with it. It should work with Outlook 2003/2007. -- 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 laurent.jumet at skynet.be Mon Sep 9 09:55:19 2013 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Mon, 09 Sep 2013 09:55:19 +0200 Subject: GPG and Outlook revisited In-Reply-To: <522D63FE.50104@chud.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello Chris ! Chris De Young wrote: > It's been some time since I looked at options for integrating GPG and > Outlook on Windows, and at the time there seemed to be no particularly > good solutions. GPG4Win/Enigmail/Thunderbird works great for my personal > use, but work mandates Outlook, and in light of the latest NSA-related > info it seems a good time to revisit the options for reliable encryption > in an Outlook/Exchange environment - if any. You can use GPGShell that has a non-specific utility to encrypt-decrypt-sign windows. While you are working in a program, ensure that its window is the active one, and right click on the Window/Encrypt function of GPGShell. - -- Laurent Jumet KeyID: 0xCFAF704C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (MingW32) iHEEAREDADEFAlItf/QqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB RjcwNEMuYXNjAAoJEPUdbaDPr3BMF+kAni2Q5wYLQz5mTe98TvrYuymrmhSYAJ0Y JM25VhphhedKpVHl+0NnCOnl7Q== =t99/ -----END PGP SIGNATURE----- From dougb at dougbarton.us Mon Sep 9 10:27:58 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 09 Sep 2013 01:27:58 -0700 Subject: Recommended key size for life long key In-Reply-To: <522D7D74.3080206@sixdemonbag.org> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> <522CF959.8000106@dougbarton.us> <522D7D74.3080206@sixdemonbag.org> Message-ID: <522D868E.3050206@dougbarton.us> On 09/09/2013 12:49 AM, Robert J. Hansen wrote: > On 9/8/2013 6:25 PM, Doug Barton wrote: >> he seems to have studiously ignored all of the facts that point to >> why what he's trying to do is a bad idea. > > Nitpick: I think what he's trying to do (make credible, accurate > long-term projections) is a good idea. I just think he's going about it > in a way that will not give credible or accurate answers, and that as a > result his write-up is rubbish. I was (sort of) trying to be kind, and I think I made the point at least obliquely in context; but I'm not sure that someone who doesn't seem to understand cryptography trying to make long term projections that people who DO understand it won't make actually IS a good idea. :) If what you meant was, "It's important for knowledgeable people to examine how long various key sizes can be expected to remain secure" then we're in agreement of course. But the blind leading the blind is never a good idea, and particularly dangerous where complex topics like crypto are concerned. Doug From christophe.brocas at cnamts.fr Mon Sep 9 09:31:08 2013 From: christophe.brocas at cnamts.fr (Christophe Brocas) Date: Mon, 09 Sep 2013 09:31:08 +0200 Subject: GPG and Outlook revisited In-Reply-To: <522D63FE.50104@chud.net> References: <522D63FE.50104@chud.net> Message-ID: <522D793C.9020802@cnamts.fr> Le 09/09/2013 08:00, Chris De Young a ?crit : > Hello, > > It's been some time since I looked at options for integrating GPG and > Outlook on Windows, and at the time there seemed to be no particularly > good solutions. GPG4Win/Enigmail/Thunderbird works great for my personal > use, but work mandates Outlook, and in light of the latest NSA-related > info it seems a good time to revisit the options for reliable encryption > in an Outlook/Exchange environment - if any. Hi Same concern for me, if somebody could do a report about working efficiently with GnuPG and Outlook/Exchange, it would be very valuable for a lot of people I think :) Cheers Christophe > (Yes, one make the argument that there are probably NSA backdoors in > Windows itself and so nothing I do here matters - but it still seems > like a reasonable effort is probably better than throwing my hands in > the air. :) ) > > Thanks! > -Chris > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users ***************************************************** "Le contenu de ce courriel et ses eventuelles pi?ces jointes sont confidentiels. Ils s'adressent exclusivement ? la personne destinataire. Si cet envoi ne vous est pas destin?, ou si vous l'avez re?u par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre ? d'autres personnes ni le reproduire. Merci de le renvoyer ? l'?metteur et de le d?truire. Attention : L'Organisme de l'?metteur du message ne pourra ?tre tenu responsable de l'alt?ration du pr?sent courriel. Il appartient au destinataire de v?rifier que les messages et pi?ces jointes re?us ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses ?ventuelles pi?ces jointes sont celles de l'?metteur. Elles ne refl?tent pas la position de l'Organisme sauf s'il en est dispos? autrement dans le pr?sent courriel." ****************************************************** From anything.everything83 at gmail.com Mon Sep 9 10:42:06 2013 From: anything.everything83 at gmail.com (Francesco C.) Date: Mon, 9 Sep 2013 10:42:06 +0200 Subject: Some doubts about signature procedure Message-ID: Hi, here I come back to ask you some clarification about the signature procedure. The purpose of signature procedure is making sure of anybody can't modify the file you're trying to send. Many times they use also the check of Md5sum or SHA512Sum, but anyway my question is: if any spiteful person succeed in tapping a file transmission of mine, he surely succeed in signing the modified file. So how can my addressee realize of that? In other words, if this spiteful person succeed in replacing a modified file in a server he also succeed in replacing also the signature file, doesnt' he? In this case I can't understand the benefit of signing procedure. I'm sorry if my exposure was not as good as an english professor :p but I promise next times it wil be better and better. Thank you for your patience. -- Francesco -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Mon Sep 9 11:27:58 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 09 Sep 2013 11:27:58 +0200 Subject: Recommended key size for life long key In-Reply-To: <522D2C97.2070400@sixdemonbag.org> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> <522CFA2D.6090904@sixdemonbag.org> <20130908225428.GB432@leortable> <522D2C97.2070400@sixdemonbag.org> Message-ID: <522D949E.9070200@digitalbrains.com> On 09/09/13 04:04, Robert J. Hansen wrote: > Or you throw 125 machines at it instead of one. Or... etc. If something is > unsafe at work level X, it won't be safe at work level 125X. You've just proven that all RSA is unsafe! Repeated application (bald man paradox[1]) of your indeed valid premise can only lead to that conclusion! Quick, let's switch to a one-time pad! (No, I'm not serious ;) Peter. [1] https://en.wikipedia.org/wiki/Bald_man_paradox -- 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 Mon Sep 9 11:39:46 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 09 Sep 2013 05:39:46 -0400 Subject: RSA Conjectures Message-ID: <522D9762.3070707@sixdemonbag.org> tl;dr version -- RSA has not been damaged. RSA is still believed to be a safe algorithm. The world is not ending. Do not panic. Anyone who tries to use what I've written here to fearmonger about the future will make me Distinctly Displeased. ===== Some people have been asking me to explain what the significance of Boneh's paper is -- "he only proved that breaking low-exponent RSA may not be equivalent to factoring and he explicitly says it doesn't affect the security of RSA; why does this make you so concerned?" First, "concerned" is the wrong word to use. "Excited" is the right word to use. Why am I so excited? RSA is built on several different ideas. Let's enumerate them: The RSA Conjecture: "Breaking the RSA algorithm is equivalent to factoring." The IFP Conjecture: "Barring quantum computation, it will never be feasible to factor large composites except those that have some unusual and exotic properties." The RSA Conclusion: "Barring quantum computation, it will never be feasible to break RSA given a sufficiently large key that lacks unusual and exotic properties." The Ole Conjecture: "The sufficiently-large point is RSA-10k." Boneh's Commentary: "Y'all know the RSA Conjecture is false, right?" Dan Boneh's paper establishes -- IMO, pretty solidly -- that the RSA Conjecture is false, which means the RSA Conclusion is no longer logically sound. *That doesn't mean it's wrong*. If you think that things fall to the earth because invisible pixies seek to pull everything Underhill, proving that there are no invisible pixies doesn't mean you've taken gravity offline. If you make an arithmetic error while deriving Einstein's Theory of General Relativity, it doesn't follow that you can now drive to the grocery store at Warp 3. Proving the RSA Conclusion is no longer logically sound doesn't mean that it's false -- it only means we can't be sure it's true. RSA is still a strong, well-regarded cipher. Dan Boneh didn't damage RSA; he just revealed there was a great mystery here waiting to be solved. "There are ways to attack RSA that don't involve factoring. What are they, and are any of them easier than factoring?" The relevance of Boneh's work to long-term predictions about RSA should now be clear. In order to predict how long RSA will last, you have to come up with some guesses about what research will develop. If you guess that "no efficient non-factoring approaches will be discovered in the next 100 years," you might be able to have long-term confidence in even small (3072-bit) RSA keys. If you guess that "efficient non-factoring approaches to RSA will be discovered within 25 years," you might not be so sanguine. It is a *fascinating* time to be a crypto nerd. There are such amazing, intriguing, and -- yes, I'm nerdy enough to say it -- such drop dead *sexy* problems out there just waiting to be solved. This is just one of many! From rjh at sixdemonbag.org Mon Sep 9 11:44:15 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 09 Sep 2013 05:44:15 -0400 Subject: Recommended key size for life long key In-Reply-To: <522D949E.9070200@digitalbrains.com> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> <522CFA2D.6090904@sixdemonbag.org> <20130908225428.GB432@leortable> <522D2C97.2070400@sixdemonbag.org> <522D949E.9070200@digitalbrains.com> Message-ID: <522D986F.8040008@sixdemonbag.org> On 9/9/2013 5:27 AM, Peter Lebbing wrote: > [1] https://en.wikipedia.org/wiki/Bald_man_paradox Heh. I always heard that as the "beard paradox." Same basic idea, except the example given involves beards instead of full heads of hair. :) At age thirty-eight, I'm beginning to develop a bit of gray in my facial hair. I guess that I can now legitimately call myself a graybeard... From rjh at sixdemonbag.org Mon Sep 9 11:55:28 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 09 Sep 2013 05:55:28 -0400 Subject: Recommended key size for life long key In-Reply-To: <522D868E.3050206@dougbarton.us> References: <522C92A9.5010908@sixdemonbag.org> <1404847.cI8id9khTC@inno.berlin.laging.de> <20130908210016.GA432@leortable> <522CF959.8000106@dougbarton.us> <522D7D74.3080206@sixdemonbag.org> <522D868E.3050206@dougbarton.us> Message-ID: <522D9B10.9030000@sixdemonbag.org> On 9/9/2013 4:27 AM, Doug Barton wrote: > If what you meant was, "It's important for knowledgeable people to > examine how long various key sizes can be expected to remain secure" More like, "it is good that key lengths and their expected lifetimes be subjected to rigorous study," with a soupcon of "but that write-up is very much lacking in rigor." I personally don't like phrasing things in terms of "knowledgeable people". There's a joke I like to tell -- === A mathematician, an economist and a physicist are traveling through Great Britain via rail. The physicist looks out the window and sees an animal grazing in a meadow. "Look!" the physicist exclaims. "In Scotland, sheep are brown!" The economist pooh-poohs this. "You're generalizing. All you've proven is that in Scotland there exists at least one brown sheep." The mathematician rolls his eyes. "Not even that. All he's proven is that in Scotland there exists at least one sheep that has at least one brown side." A fellow passenger on the train looks quizzically at the three, then shares: "We're in Wales, and around here we call them 'cattle'." === Knowledgeable people get things wrong all the time, and especially when they say "trust me, I'm knowledgeable." I trust in process instead -- I trust in rigor and logical development of thoughts and ideas to reach a conclusion. If I review the process and feel that it's valid, then it doesn't matter if the person presenting the idea is a Ph.D. or is in the eighth grade. :) I suspect, though, that we are overall in violent agreement. :) From pete at heypete.com Mon Sep 9 12:03:04 2013 From: pete at heypete.com (Pete Stephenson) Date: Mon, 9 Sep 2013 12:03:04 +0200 Subject: Some doubts about signature procedure In-Reply-To: References: Message-ID: On Mon, Sep 9, 2013 at 10:42 AM, Francesco C. wrote: > Hi, here I come back to ask you some clarification about the signature > procedure. > The purpose of signature procedure is making sure of anybody can't modify > the file you're trying to send. > > Many times they use also the check of Md5sum or SHA512Sum, but anyway my > question is: > > if any spiteful person succeed in tapping a file transmission of mine, he > surely succeed in signing the modified file. So how can my addressee realize > of that? > > In other words, if this spiteful person succeed in replacing a modified file > in a server he also succeed in replacing also the signature file, doesnt' > he? Hi Francesco, That's a good question! The short answer to the question is "there's more to a PGP signature than just the hash of the file". In the situation you propose where a file and a hash (for example, the sha512sum) are publish on a server, an adversary with access to that system could modify the file and simply add a new, correct sha512sum for the modified file. There's no way to bind the hash of the file to the identity of the person who produced the hash. Put another way, there's no way to tell if the hash was produced by the proper person or a bad guy. However, PGP signatures have more than merely the hash of the file -- when PGP (or GnuPG or any other program that implements the OpenPGP standard) produces a signature, it produces a hash of the file and encrypts the hash with the signer's private key. The signature is then included with the file. (Of course, this is a very simple, general description of what happens. There's a lot more details but this simple explanation should suffice for now.) This binds someone's identity to the signature. Let's say that Alice wants to sign a file. She calculates a hash of the file, then encrypts the hash with her private key. Bob downloads the file and wants to verify the signature. He calculates the hash of the file. Next, he uses Alice's public key (which is widely available) to decrypt the hash. If the decrypted hash from Alice and the hash he calculated himself match, then he knows that the file has not been modified since Alice signed it. Additionally, since only Alice's public key can decrypt a message signed with Alice's private key, he knows that only Alice (or, more generally, someone with Alice's private key) could have produced the signature. Unless he has Alice's private key a bad guy cannot forge signatures to appear to come from Alice. Put very simply, a hash can show that a file has not been altered since the hash was generated but it provides no assurance as to *who* produced the hash. A signature provides assurance of both integrity and authentication: someone verifying the signature can check that the file has not been altered but also that the signature was produced by a specific person. Of course, this assumes that Bob has the public key that actually belongs to Alice. This can be accomplished by meeting in person, exchanging public key details over the phone (if they recognize each other's voices), etc. It's not uncommon for people to meet up at a "keysigning party" (see https://en.wikipedia.org/wiki/Key_signing_party ), verify each other's identity and public key details, and then digitally sign each other's keys. In such a way, people establish a "Web of Trust" where different people vouch for the identity of each other. You might find more details about digital signatures at https://en.wikipedia.org/wiki/Digital_signature . There may also be a Wikipedia article that describes signatures in your own language. > In this case I can't understand the benefit of signing procedure. > I'm sorry if my exposure was not as good as an english professor :p but I > promise next times it wil be better and better. Your English is quite good. Cheers! -Pete -- Pete Stephenson From Dave.Smith at st.com Mon Sep 9 12:11:08 2013 From: Dave.Smith at st.com (David Smith) Date: Mon, 9 Sep 2013 11:11:08 +0100 Subject: Some doubts about signature procedure In-Reply-To: References: Message-ID: <522D9EBC.20404@st.com> On 09/09/13 09:42, Francesco C. wrote: > Hi, here I come back to ask you some clarification about the signature > procedure. > The purpose of signature procedure is making sure of anybody can't > modify the file you're trying to send. > > Many times they use also the check of Md5sum or SHA512Sum, but anyway my > question is: > > if any spiteful person succeed in tapping a file transmission of mine, > he surely succeed in signing the modified file. So how can my addressee > realize of that? > > In other words, if this spiteful person succeed in replacing a modified > file in a server he also succeed in replacing also the signature file, > doesnt' he? The signature is more than just the hash of the message. The signing process consists of two steps. Firstly, the message being signed is run through a hashing algorithm like MD5 or SHA. The second step is that the output of the hashing algorithm is encrypted using your secret key. Anyone wishing to check the signature can then decrypt the hash using your public key, run the same hashing algorithm over the message, and check that the hash of the message is the same as the unencrypted hash from the signature. You are correct that an attacker can generate a hash of the modified message, but they cannot encrypt it with your secret key, unless they also have a copy of that key. I've simplified the process somewhat for ease of explaining it, but that's the general gist of the way it works. So, provided your secret key is kept secret, and your addressees verify that the public keys they have really do belong to you, you can be confident that the signature mechanism is safe. -- David Smith Work Email: Dave.Smith at st.com STMicroelectronics Home Email: David.Smith at ds-electronics.co.uk Bristol, England GPG Key: 0xF13192F2 From ghostbar38 at gmail.com Mon Sep 9 04:06:02 2013 From: ghostbar38 at gmail.com (Jose Luis Rivas) Date: Sun, 08 Sep 2013 21:36:02 -0430 Subject: SSL on gnupg.org Message-ID: <522D2D0A.6090003@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, Are there any chances that gnupg.org could use SSL? I have seen some worrisome about downloading stuff from a site without a proper SSL certificate, specially nowadays with the NSA issues which include them in the middle of the internet pipes. Kind regards. - -- Jose Luis Rivas http://joseluisrivas.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSLS0KAAoJEBPsQ+65rIxDN68QAILKlMvW5QC5PFBQjI2z/AEz Am6y9ra9jHuwRwyRIW3UQ7fwxzBEXwXBK/lJ4c2oxYWAe0uOoLgwLQ4hbA+MmtSE z2NdxhOuGntzFtJxKys/c348nYdRv5cDvABrFA7HAWwN8xyhINKoXcgKSJEDqV4I BbovtCMCV9C2Xp0kMkuezBPquOBJG6ELjQ8pjuP7NJl+zMesyYGyiPizfqBQ4jNQ DAjzddJyo3J6sgVq3Nr9aqt3Trjm02jzrglCvkp1xrr17ve8sFBJ3h84kEwpNjXH 9rc/bz+YwRq1ZJTrIlUeHaz44Q6T8jHjvEjz4ynqTqvVkIaXa53OO7dzuWmJly76 YnaX1UjPdh7wFFr+jNf800H0kfTN5Bc7myfEY8Z+FsEIjxf/LbPdtFVkZgpJqA+9 KELEsB9YwOvey/lDhnXO0x5ndF0+c4BNuV2Dq28dnJ8qGX9cY2fuFcjmWCLoyJEb 1ggbDr1/3iw/g34QQtoP3nbjZGM0t54OM7TmggBvFa2B46dbkW1kA0c3Kc5hg4E3 XPkD34QxJC48txcC/8TdlCMowTwFmc2Y+lTWtL4MMJBD4o9DscIJQnmYSnvfAqVj HvkoJG53kJHPRBWkG3E6MDZD2P7V6/aspIkioyhVA27+eUSDppWABz6VioRqJapW kO/IA6v5PXqSASeoGqny =6l5O -----END PGP SIGNATURE----- From peter at digitalbrains.com Mon Sep 9 12:54:49 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 09 Sep 2013 12:54:49 +0200 Subject: SSL on gnupg.org In-Reply-To: <522D2D0A.6090003@gmail.com> References: <522D2D0A.6090003@gmail.com> Message-ID: <522DA8F9.1040102@digitalbrains.com> On 09/09/13 04:06, Jose Luis Rivas wrote: > I have seen some worrisome about downloading stuff from a site without a > proper SSL certificate, specially nowadays with the NSA issues which > include them in the middle of the internet pipes. SSL is precisely /not/ the technology to use to escape the NSA (more specifically, the Certificate Authority structure of the validation, I'm not talking about the SSL session itself). If there is /an/ organization that can spoof the authenticity of an SSL website, it'll be the NSA. I will eat my hat[1] if they don't have access to a few certificate authorities. If you want to verify authenticity of a downloaded GnuPG, verify it with GnuPG. Yes, I know, there's a problem there :). HTH, Peter. [1] Luckily, the washing label says "AZO free". I have no idea what that is, though. -- 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 nils.faerber at kernelconcepts.de Mon Sep 9 13:21:31 2013 From: nils.faerber at kernelconcepts.de (Nils Faerber) Date: Mon, 09 Sep 2013 13:21:31 +0200 Subject: SSL on gnupg.org In-Reply-To: <522DA8F9.1040102@digitalbrains.com> References: <522D2D0A.6090003@gmail.com> <522DA8F9.1040102@digitalbrains.com> Message-ID: <522DAF3B.5020309@kernelconcepts.de> Am 09.09.2013 12:54, schrieb Peter Lebbing: > [1] Luckily, the washing label says "AZO free". I have no idea what that is, > though. OT: AZO colours make up the majority of artificial colours used for all kinds of stuff. They are known to have negative side effects on their own especially on special types of sensitive people (like ADHS) and are especially dangerous when they degrade. So no AZO colours would mean that your stomach will not hurt because of the colours after having finished your hat :) [1] https://en.wikipedia.org/wiki/Azo_compound Cheers nils -- kernel concepts GmbH Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From avi.wiki at gmail.com Mon Sep 9 14:48:05 2013 From: avi.wiki at gmail.com (Avi) Date: Mon, 9 Sep 2013 08:48:05 -0400 Subject: GPG and Outlook revisited In-Reply-To: References: <522D63FE.50104@chud.net> Message-ID: I use GPGShell too, but Werner has requested that we focus on open source software on this list, and GPGShell is closed source. As we all owe an enormous debt of gratitude to Werner and his team, the least we can do is honor his request on the list he maintains about the program he almost single-handedly supports and gives to us for free :-) --Avi Please excuse any spelling or grammar errors as this was sent from a Nexus 7 tablet. Thank you. On Sep 9, 2013 4:01 AM, "Laurent Jumet" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > Hello Chris ! > > Chris De Young wrote: > > > It's been some time since I looked at options for integrating GPG and > > Outlook on Windows, and at the time there seemed to be no particularly > > good solutions. GPG4Win/Enigmail/Thunderbird works great for my personal > > use, but work mandates Outlook, and in light of the latest NSA-related > > info it seems a good time to revisit the options for reliable encryption > > in an Outlook/Exchange environment - if any. > > You can use GPGShell that has a non-specific utility to > encrypt-decrypt-sign windows. > While you are working in a program, ensure that its window is the > active > one, and right click on the Window/Encrypt function of GPGShell. > > - -- > Laurent Jumet > KeyID: 0xCFAF704C > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (MingW32) > > iHEEAREDADEFAlItf/QqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB > RjcwNEMuYXNjAAoJEPUdbaDPr3BMF+kAni2Q5wYLQz5mTe98TvrYuymrmhSYAJ0Y > JM25VhphhedKpVHl+0NnCOnl7Q== > =t99/ > -----END PGP SIGNATURE----- > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axel.braun at gmx.de Mon Sep 9 14:52:26 2013 From: axel.braun at gmx.de (Axel Braun) Date: Mon, 09 Sep 2013 14:52:26 +0200 Subject: SSL on gnupg.org In-Reply-To: <522DA8F9.1040102@digitalbrains.com> References: <522D2D0A.6090003@gmail.com> <522DA8F9.1040102@digitalbrains.com> Message-ID: <9258906.7QiO5ff8Ny@t520.axxite.internal> Am Montag, 9. September 2013, 12:54:49 schrieb Peter Lebbing: > If there is /an/ organization that can spoof the authenticity of an SSL > website, it'll be the NSA. I will eat my hat[1] if they don't have access to > a few certificate authorities. > > If you want to verify authenticity of a downloaded GnuPG, verify it with > GnuPG. Yes, I know, there's a problem there :). > > [1] Luckily, the washing label says "AZO free". I have no idea what that is, > though. https://en.wikipedia.org/wiki/Azo_compound -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Sep 9 15:19:56 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Sep 2013 15:19:56 +0200 Subject: SSL on gnupg.org In-Reply-To: <522D2D0A.6090003@gmail.com> (Jose Luis Rivas's message of "Sun, 08 Sep 2013 21:36:02 -0430") References: <522D2D0A.6090003@gmail.com> Message-ID: <87hadub08z.fsf@vigenere.g10code.de> On Mon, 9 Sep 2013 04:06, ghostbar38 at gmail.com said: > Are there any chances that gnupg.org could use SSL? I have seen some Due to public demand I enabled https for www.gnupg.org on v4 and v6. IT is a 2048 bit CaCert certificate, so you need to install the cacert root certificate. Note also that recent Mozilla browsers tell you in the certificate details that they can't verify the certificate because it uses an insecure algorithm - which seems to be SHA-1. Now if SHA-1 would be the weakest link in the whole web security domain we could easily solve all problems. It is just funny how they try to fix a broken infrastructure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kententen at me.com Mon Sep 9 15:27:13 2013 From: kententen at me.com (Kenneth Jones) Date: Mon, 09 Sep 2013 21:27:13 +0800 Subject: Some doubts about signature procedure In-Reply-To: References: Message-ID: <522DCCB1.50602@Me.com> Hi Francesco, Let me review something about signing and what happens when you do it. Signing a signed email with PGP (or GPG, GnuPG or whatever) means that the message text is inspected by the PGP program and a small additional data file is produced that has a specific relationship to the message. Both your message and this extra file are sent to the other guy. The inspection and manipulation is called hashing. A hash (that's what what the small data file is called) is related to the original message in such a way that if even one small part of the original message is changed, the hash will almost always be completely different than it was originally. So the first thing that happens is that your message text is hashed and the hash is produced. Now, at the other end of the line, your recipient's PGP program will also hash your message and will compare the hash you sent with the hash it just produced. If the two hashes are identical, it's a proof that the message hasn't changed (or been changed) since it was hashed. Identical hash results mean identical messages. But... But anybody can hash a message. Even the bad guy in the middle, between you and your recipient. You send a letter and its hash, bad guy intercepts it, changes the message, rehashes it, sends it along to your recipient. Your recipient hashes and compares, finds the two hashes match and thinks it's okay. But he's comparing his to the bad guy's, not comparing your hash to his...and he doesn't know any better...so this can't be secure from what's called a man-in-the-middle attack. How to fix? Your PGP program not only makes the hash, but it encrypts your hash with your private key before sending it along with your message. Note that the message is not encrypted, it's still clear text. Only the hash is encrypted. The recipient will use PGP and your public key to decrypt the hash before comparing it to the hash it just made. Now then if the two hashes match we know two things: one, the message is exactly as it was written by the user of the private key, and the user of the private key is the one who wrote it. If you have maintained possession of your private key, no one else could have produced the message this way. So, keeping your private key in a safe place and protecting it with a good passphrase is important. That's how we can tell that what we receive is precisely what you (and only you) have sent. I hope that helps, but sometimes I make things more complex than they really need to be for good understanding. Please write again with your questions. Cheers, Ken Jones 0xE2557AA7 On 2013-09-09 16:42, Francesco C. wrote: > Hi, here I come back to ask you some clarification about the signature > procedure. > The purpose of signature procedure is making sure of anybody can't modify > the file you're trying to send. > > Many times they use also the check of Md5sum or SHA512Sum, but anyway my > question is: > > if any spiteful person succeed in tapping a file transmission of mine, he > surely succeed in signing the modified file. So how can my addressee > realize of that? > > In other words, if this spiteful person succeed in replacing a modified > file in a server he also succeed in replacing also the signature file, > doesnt' he? > > In this case I can't understand the benefit of signing procedure. > I'm sorry if my exposure was not as good as an english professor :p but I > promise next times it wil be better and better. > > Thank you for your patience. > > -- > Francesco > From wk at gnupg.org Mon Sep 9 15:32:01 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Sep 2013 15:32:01 +0200 Subject: GPG and Outlook revisited In-Reply-To: <522D7E32.70805@enigmail.net> (John Clizbe's message of "Mon, 09 Sep 2013 02:52:18 -0500") References: <522D63FE.50104@chud.net> <522D7E32.70805@enigmail.net> Message-ID: <87d2oiazou.fsf@vigenere.g10code.de> On Mon, 9 Sep 2013 09:52, John at enigmail.net said: > If you're already using the GPG4Win package, install the PGPOL Outlook plugin > that ships with it. It should work with Outlook 2003/2007. In fact we put quite some work into enabling it for OL2010 - no MIME stuff there, but at least we have options to handle attachments. Frankly, I am pretty sure we could add MIME support the same way we did it for OL2003 but it needs quite some research and work, meaning we need to get a sponsor for that. BTW, given that Lotus Notes has been found bugged by the NSA as early as 1997 [1], it is wishful thinking that Outlook has no such feature. Better assume that there is way to remotely install extra features into Outlook so to scan the drive for private keys. In case Gpg4win would get in wide use [2] dedicated spying code may be deployed at one of the next patch days. Salam-Shalom, Werner [1] http://www.heise.de/tp/artikel/2/2898/1.html [2] We currently have (only) ~4000 downloads a day -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marcio.barbado at gmail.com Mon Sep 9 15:44:07 2013 From: marcio.barbado at gmail.com (Marcio B. Jr.) Date: Mon, 9 Sep 2013 10:44:07 -0300 Subject: Fedora GPG Key Server In-Reply-To: <877getgc2q.fsf@vigenere.g10code.de> References: <877getgc2q.fsf@vigenere.g10code.de> Message-ID: This whole NSA blackmailing situation is causing strange reactions in you, sir. Marcio Barbado, Jr. On Sat, Sep 7, 2013 at 7:28 AM, Werner Koch wrote: > On Thu, 5 Sep 2013 22:22, marcio.barbado at gmail.com said: >> https://lists.fedoraproject.org/pipermail/announce/2013-September/003180.html > > Please do not post a mere link. This assume that everyone is online and > able to read a web page. At least an excerpt from the page would be > useful. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From wk at gnupg.org Mon Sep 9 15:38:35 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Sep 2013 15:38:35 +0200 Subject: GPG and Outlook revisited In-Reply-To: (Laurent Jumet's message of "Mon, 09 Sep 2013 09:55:19 +0200") References: Message-ID: <878uz6azdw.fsf@vigenere.g10code.de> On Mon, 9 Sep 2013 09:55, laurent.jumet at skynet.be said: > You can use GPGShell that has a non-specific utility to Are you sure that such a closed source software is not on the list of the Bullrun program? Why does the author stick to closed-source despite that it is freeware he won't make a fortune with it? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From JDiaz at azdes.gov Mon Sep 9 15:01:32 2013 From: JDiaz at azdes.gov (Diaz, John, A) Date: Mon, 9 Sep 2013 13:01:32 +0000 Subject: Decrypt Issue In-Reply-To: <522B98F4.6080108@gmail.com> References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> <522B98F4.6080108@gmail.com> Message-ID: <4c0e67c23ee84880835971bee0d5a893@MBX03.azdes.gov> I'm logging in with the service account, which is the same account that the mainframe JCL uses. -----Original Message----- From: Paul R. Ramer [mailto:free10pro at gmail.com] Sent: Saturday, September 07, 2013 2:22 PM To: Diaz, John, A Cc: gnupg-users at gnupg.org Subject: Re: Decrypt Issue On 09/04/2013 01:54 PM, Diaz, John, A wrote: > 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 list the keys on the server that this is running I see the key listed. > > Here's the goofy part: If I login to the server with the credentials that the mainframe uses to call the first .bat file, and manually run the .bat file that starts the whole process, it runs correctly. Hello John, When you say that you log in to the server, are you logging into a user account on the server? And do you get a command prompt (i.e. you are ssh-ing into your server)? 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 pete at heypete.com Mon Sep 9 15:58:14 2013 From: pete at heypete.com (Pete Stephenson) Date: Mon, 9 Sep 2013 15:58:14 +0200 Subject: SSL on gnupg.org In-Reply-To: <87hadub08z.fsf@vigenere.g10code.de> References: <522D2D0A.6090003@gmail.com> <87hadub08z.fsf@vigenere.g10code.de> Message-ID: On Mon, Sep 9, 2013 at 3:19 PM, Werner Koch wrote: > Due to public demand I enabled https for www.gnupg.org on v4 and v6. IT > is a 2048 bit CaCert certificate, so you need to install the cacert root > certificate. Excellent. > Note also that recent Mozilla browsers tell you in the certificate > details that they can't verify the certificate because it uses an > insecure algorithm - which seems to be SHA-1. Now if SHA-1 would be the > weakest link in the whole web security domain we could easily solve all > problems. It is just funny how they try to fix a broken infrastructure. According to https://www.ssllabs.com/ssltest/analyze.html?d=www.gnupg.org&hideResults=on that's because the CAcert Class 3 intermediate cert was signed using MD5, which is indeed insecure for such purposes. See http://www.win.tue.nl/hashclash/rogue-ca/ They have a newer Class 3 intermediate cert at http://www.cacert.org/index.php?id=3 that is signed by the CAcert root using SHA256. Simply swapping out the intermediates should solve the issue. Personally, I prefer the free certs issued by StartSSL as their root is installed by default in most systems/browsers. The CAcert root isn't (yet -- there's a bunch of work needed to be done to get the CAcert root to pass an audit and be included). Your mileage, of course, may vary. -- Pete Stephenson From John at enigmail.net Mon Sep 9 16:12:25 2013 From: John at enigmail.net (John Clizbe) Date: Mon, 09 Sep 2013 09:12:25 -0500 Subject: Fedora GPG Key Server In-Reply-To: References: <877getgc2q.fsf@vigenere.g10code.de> Message-ID: <522DD749.20306@enigmail.net> Marcio B. Jr. wrote: > On Sat, Sep 7, 2013 at 7:28 AM, Werner Koch wrote: >> On Thu, 5 Sep 2013 22:22, marcio.barbado at gmail.com said: >>> https://lists.fedoraproject.org/pipermail/announce/2013-September/003180.html >> >> Please do not post a mere link. This assume that everyone is online and >> able to read a web page. At least an excerpt from the page would be >> useful. > This whole NSA blackmailing situation is causing strange reactions in you, sir. Not at all. Nick's message was short enough, you could have easily copied the entire message with a link to the original list posting. To wit: > The Fedora Infrastructure team is pleased to announce that > keys.fedoraproject.org is now up and running as a GPG keyserver. We are > also part of the sks-keyservers.net pool, which means that some people > using pool.sks-keyservers.net will be directed to our server. We have a > very nice web interface, which was designed by Maria 'tatica' Leandro > Lombardo. This will also in some ways work to promote Fedora, since some > users using the pool will be directed to our server, which prominently > features the Fedora logo and branding. > > This server may be accessed in the following ways: Web interface at > http://keys.fedoraproject.org or https://keys.fedoraproject.org HKP > (keyserver protocol) by doing "gpg --keyserver keys.fedoraproject.org > --recv-keys 0x110810E9" (just an example) > > You could also put in ~/.gnupg/gpg.conf: > keyserver hkp://keys.fedoraproject.org > > -- Nick Bebout > Fedora Project > https://lists.fedoraproject.org/pipermail/announce/2013-September/003180.html When posting a news article, the entire point of the post should be to get readers to click through to your page. Your original post of a single link gave absolutely zero incentive for any readers of this list to click your link. NONE. As a P-R effort it was very poorly executed. There were probably two subsets of list readers who knew what your link concerned: 1) Fedora users who already read the post, and 2) SKS keyserver operators who have been aware of Nick's work bringing the keyserver back online since early August. -- 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 JDiaz at azdes.gov Mon Sep 9 18:01:54 2013 From: JDiaz at azdes.gov (Diaz, John, A) Date: Mon, 9 Sep 2013 16:01:54 +0000 Subject: Decrypt Issue In-Reply-To: <522B98F4.6080108@gmail.com> References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> <522B98F4.6080108@gmail.com> Message-ID: <30e043faf8154cfcab7f4a63ba84b8dc@MBX03.azdes.gov> Paul, got it figured out. Programmer too stupid. The path to gpg.exe had changed, and I didn't catch it. -----Original Message----- From: Paul R. Ramer [mailto:free10pro at gmail.com] Sent: Saturday, September 07, 2013 2:22 PM To: Diaz, John, A Cc: gnupg-users at gnupg.org Subject: Re: Decrypt Issue On 09/04/2013 01:54 PM, Diaz, John, A wrote: > 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 list the keys on the server that this is running I see the key listed. > > Here's the goofy part: If I login to the server with the credentials that the mainframe uses to call the first .bat file, and manually run the .bat file that starts the whole process, it runs correctly. Hello John, When you say that you log in to the server, are you logging into a user account on the server? And do you get a command prompt (i.e. you are ssh-ing into your server)? 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 avi.wiki at gmail.com Mon Sep 9 19:49:11 2013 From: avi.wiki at gmail.com (Avi) Date: Mon, 9 Sep 2013 13:49:11 -0400 Subject: GPG and Outlook revisited In-Reply-To: <878uz6azdw.fsf@vigenere.g10code.de> References: <878uz6azdw.fsf@vigenere.g10code.de> Message-ID: All he says on the matter is : General: Do you publish your source-codes? > > No! But when you've got the source-code for Windows, you can ask me again. > > > General: Do you sell your source-codes? > > Yes! It's just a matter of price. Send me an offer. :-) > --Avi ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 On Mon, Sep 9, 2013 at 9:38 AM, Werner Koch wrote: > On Mon, 9 Sep 2013 09:55, laurent.jumet at skynet.be said: > >> You can use GPGShell that has a non-specific utility to > > Are you sure that such a closed source software is not on the list of > the Bullrun program? Why does the author stick to closed-source > despite that it is freeware he won't make a fortune with it? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Mon Sep 9 18:48:05 2013 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 09 Sep 2013 12:48:05 -0400 Subject: adding subkeys in gpg4 win Message-ID: <20130909164806.1F596A0122@smtp.hushmail.com> Was trying out gpg4win 2.2.0, and couldn't see how to add a subkey from either Kleopatra or GPA (was able to add it easily from the command line gnupg 2.0.21 that installs with gpg4win) Couldn't find anything about adding subkeys in the compendium. Is there something really basic that I missed? TIA, vedaal From wk at gnupg.org Mon Sep 9 20:36:53 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Sep 2013 20:36:53 +0200 Subject: GPG and Outlook revisited In-Reply-To: (Avi's message of "Mon, 9 Sep 2013 08:48:05 -0400") References: <522D63FE.50104@chud.net> Message-ID: <8738pdc056.fsf@vigenere.g10code.de> On Mon, 9 Sep 2013 14:48, avi.wiki at gmail.com said: > I use GPGShell too, but Werner has requested that we focus on open source > software on this list, and GPGShell is closed source. As we all owe an Well, my point was just that many folks are trying to improve security be using 4k or 10k keys while other suggest to use close-source software like Outlook or GPGShell. Guess, what is easier to attack for the NSA. If proprietary software is mentioned once in a while I don't care to much. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ole at tange.dk Mon Sep 9 12:28:53 2013 From: ole at tange.dk (Ole Tange) Date: Mon, 9 Sep 2013 12:28:53 +0200 Subject: Problems using 10kbit keys in GnuPG instead of 4kbit keys Message-ID: I am really happy that no one so far shown any problems in the part on using 10kbit keys today (only the justification for using 10kbit keys seems to be controversial). I have therefore extracted the non-controversial part as a separate document: http://oletange.blogspot.dk/2013/09/problems-using-10kbit-keys-in-gnupg.html That in itself should show that the problems of using 10kbit keys is limited to the user self - the communication partners are not (noticeably) affected by this. Hopefully that will stop people from recommending against 10kbit keys for the sake of the communication partners. /Ole From peter at digitalbrains.com Mon Sep 9 21:17:16 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 09 Sep 2013 21:17:16 +0200 Subject: GPG and Outlook revisited In-Reply-To: References: <878uz6azdw.fsf@vigenere.g10code.de> Message-ID: <522E1EBC.2020409@digitalbrains.com> On 09/09/13 19:49, Avi wrote: > All he says on the matter is : > [...] > General: Do you sell your source-codes? > > Yes! It's just a matter of price. Send me an offer. :-) Remember that this would make it open source[1], but not free software. It can come with some provision that you do not offer binaries built from that source or modify the code. So then how do you know that the binaries he provides are built from the source that you bought? The only way I think is to use the exact same build setup he uses and then compare assembly (not full binaries, those differ each build). Anyway, his reasons not to make it free software remain rather shrouded in mystery. I'm with Werner on being suspicious of mystery surrounding crypto software[2]. His comparison to Windows is moot, because Windows is not freeware by a long shot. Cheers, Peter. [1] As I see it being formulated, you might not even be allowed to share the source you bought with others. [2] My words, not his. -- 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 Mon Sep 9 21:41:42 2013 From: pete at heypete.com (Pete Stephenson) Date: Mon, 9 Sep 2013 21:41:42 +0200 Subject: Problems using 10kbit keys in GnuPG instead of 4kbit keys In-Reply-To: References: Message-ID: On Mon, Sep 9, 2013 at 12:28 PM, Ole Tange wrote: [snip] > Hopefully that will stop people from recommending against 10kbit keys > for the sake of the communication partners. While it certainly seems that 10kbit keys offer reasonable performance even for slow systems (thanks for doing the benchmarks on those systems), there's also some practical concerns: 1. Most smartcards these days support 2048-bit keys, while OpenPGP smartcards support 4096-bit keys. I'm not aware of any smartcard that supports >4096-bits. It'd be nice to see hardware vendors offer cards that can handle larger keys. I'm not sure what the demand for larger keys is, but I imagine that smartcard support for larger keys would be a long time coming. 2. How compatible are >4096-bit keys with various OpenPGP implementations? It's nice to have a (presumably) secure key, but if other people's software only support 4096-bit keys as a maximum then you can't really communicate with them. New features are slow to add to both the standard and to various implementations: even though RFC 4880 says that OpenPGP implementations MAY implement hashes other than SHA1, I've read some concern about compatibility with SHA256 and SHA512 signatures and key certifications (I've not observed any such issues, but I rarely interact with people using older software versions that are unlikely to support it). I'm not sure what other programs implement the standard or how well-supported extra large keys would be. 3. Generating large keys with GnuPG requires that one patch the source and recompile. This limits the creation of extra-large keys to those who feel comfortable with doing this. It'd be interesting to see if Werner would change the hard-coded maximum keysize from the current 4096 to, say 8192 (or 15,360 or 16,384) bits so that users who desired such keys could create them easily. (It'd probably be best to require an "--expert" flag to expose such options, at least for a while.) Thanks again for the interesting benchmarks and measurements. Cheers! -Pete -- Pete Stephenson From takethebus at gmx.de Mon Sep 9 22:52:48 2013 From: takethebus at gmx.de (Jan) Date: Mon, 9 Sep 2013 22:52:48 +0200 Subject: Why trust gpg4win? References: <201307252214.r6PME8tp031462@fire.js.berklix.net> <521656E1.9010608@gmail.com> <52167D43.8050801@securemecca.net> <52198251.6080404@sixdemonbag.org> Message-ID: >> 24.08.2013 23:14, Jan (takethebus at gmx.de) worte: >> It seems quite easy to advice people to have an offline windows PC >> with gpg4win on it and all their private stuff and a windows(?) >> online PC next to it. They could transfer encrypted messages with an >> USB stick from one PC to the other. I think this is a vector for an >> attacker, but how serious is this problem? >25.08.2013 06:04, Robert J. Hansen wrote: >Very serious. USB tokens are great tools for propagating malware. >Compromise the box that's connected to the net, and as soon as someone >plugs a flash drive into it, compromise the flash drive. Bring it over >to the new computer, plug in there, and bang, you've spanned the air >gap. This is not a new attack: it's been known about for many years and >has been demonstrated in real-world environments. Imagine an intact offline PC without "auto play" enabled for USB drives. Now an USB drive is plugged in with an encrypted file on it. The file is decrypted with gnupg and turns out to be a jpg file. Let's assume it contains maleware. Even in this case, the offline PC is not infected yet(?). Next we would want to view the jpg picture using a secure small tool which is so simple that it does not evoke the maleware contained in the file. If there is such a tool the offline PC is still intact. No information or private key could secretly be copied on an USB drive which we plug in the offline PC. Thus no such information could be transfered to the online PC, no matter how infected the online PC is. The point is perhaps to only view files of simple formats on the offline PC, like(?) jpg files. Word files seem too dangerous for me for example, since they can contain scripts. Are my thoughts correct? The simple file formats I'm thinking of are plain text, jpg, RTF, a simple spread sheetformat (which?), pdf, mp3. Are there any secure tools for those types? Jasper den Ouden (22.08.2013 20:22) asked for a "pdf tool for extra security" in a similar context. It also might be a good idea to have a program which checks whether the considered file is for instance a "normal" jpg file according to the jpg definition. If it is not we could avoid loading it in a jpg tool. Are there such programs under linux? >25.08.2013 10:28, Pete Stephenson wrote: >The easiest and least-expensive solution to this situation is using >smartcards: http://g10code.com/p-card.html -- the private key is kept >securely on the smartcard. My problem with smartcards is that they protect the private key but not the sensitive data I'm keeping on my offline PC, since once in a while I need to decrypt it in order to work with it. Nevertheless an attacker would certainly first try to steel the private key out of the offline PC, so smatcards are a good additional defense. Best regards, Jan From chd at chud.net Mon Sep 9 22:27:02 2013 From: chd at chud.net (Chris De Young) Date: Mon, 09 Sep 2013 13:27:02 -0700 Subject: GPG and Outlook revisited In-Reply-To: <87d2oiazou.fsf@vigenere.g10code.de> References: <522D63FE.50104@chud.net> <522D7E32.70805@enigmail.net> <87d2oiazou.fsf@vigenere.g10code.de> Message-ID: <522E2F16.8050104@chud.net> Thanks all - alas we are on Outlook 2013, and given Outlook's market share it does seem pretty likely that the NSA would have poked into it as well. Maybe I can get them to let me speak IMAP to the mail store, and use Thunderbird for work too... Thanks! On 9/9/2013 6:32 AM, Werner Koch wrote: > On Mon, 9 Sep 2013 09:52, John at enigmail.net said: > >> If you're already using the GPG4Win package, install the PGPOL Outlook plugin >> that ships with it. It should work with Outlook 2003/2007. > > In fact we put quite some work into enabling it for OL2010 - no MIME > stuff there, but at least we have options to handle attachments. > > Frankly, I am pretty sure we could add MIME support the same way we did > it for OL2003 but it needs quite some research and work, meaning we need > to get a sponsor for that. > > BTW, given that Lotus Notes has been found bugged by the NSA as early as > 1997 [1], it is wishful thinking that Outlook has no such feature. > Better assume that there is way to remotely install extra features into > Outlook so to scan the drive for private keys. In case Gpg4win would > get in wide use [2] dedicated spying code may be deployed at one of the > next patch days. > > > Salam-Shalom, > > Werner > > > > [1] http://www.heise.de/tp/artikel/2/2898/1.html > [2] We currently have (only) ~4000 downloads a day > From dougb at dougbarton.us Mon Sep 9 23:38:33 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 09 Sep 2013 14:38:33 -0700 Subject: GPG and Outlook revisited In-Reply-To: <522E1EBC.2020409@digitalbrains.com> References: <878uz6azdw.fsf@vigenere.g10code.de> <522E1EBC.2020409@digitalbrains.com> Message-ID: <522E3FD9.8080306@dougbarton.us> On 09/09/2013 12:17 PM, Peter Lebbing wrote: > Remember that this would make it open source[1], but not free software. It can > come with some provision that you do not offer binaries built from that source > or modify the code. So then how do you know that the binaries he provides are > built from the source that you bought? The only way I think is to use the exact > same build setup he uses and then compare assembly (not full binaries, those > differ each build). It's worth noting for sake of argument that the same exact concerns apply to the pre-packaged binaries of GnuPG for Windows. From rjh at sixdemonbag.org Mon Sep 9 23:39:06 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 09 Sep 2013 17:39:06 -0400 Subject: Why trust gpg4win? In-Reply-To: References: <201307252214.r6PME8tp031462@fire.js.berklix.net> <521656E1.9010608@gmail.com> <52167D43.8050801@securemecca.net> <52198251.6080404@sixdemonbag.org> Message-ID: <522E3FFA.60201@sixdemonbag.org> On 9/9/2013 4:52 PM, Jan wrote: > Imagine an intact offline PC without "auto play" enabled for USB drives. Can't. USB is a peer protocol. There's an astonishing amount of computational power on both sides of that USB cable. Protocol negotiation is complex. Put it all together and you get a peer-to-peer protocol which you *cannot* secure because (a) there are too many computational resources available to an attacker and (b) the protocol itself is too complicated and there are many ways a malicious token could compromise the remote system even without autoplay installed. Don't get me started on Firewire, which is even worse. Oh, yeah, I just love the idea of random dongles I can plug into my machine which get root-level read-write access to RAM *as part of normal operations*. From pete at heypete.com Tue Sep 10 00:29:43 2013 From: pete at heypete.com (Pete Stephenson) Date: Tue, 10 Sep 2013 00:29:43 +0200 Subject: Why trust gpg4win? In-Reply-To: <522E3FFA.60201@sixdemonbag.org> References: <201307252214.r6PME8tp031462@fire.js.berklix.net> <521656E1.9010608@gmail.com> <52167D43.8050801@securemecca.net> <52198251.6080404@sixdemonbag.org> <522E3FFA.60201@sixdemonbag.org> Message-ID: On Mon, Sep 9, 2013 at 11:39 PM, Robert J. Hansen wrote: > On 9/9/2013 4:52 PM, Jan wrote: >> Imagine an intact offline PC without "auto play" enabled for USB drives. > > Can't. > > USB is a peer protocol. There's an astonishing amount of computational > power on both sides of that USB cable. Protocol negotiation is complex. > Put it all together and you get a peer-to-peer protocol which you > *cannot* secure because (a) there are too many computational resources > available to an attacker and (b) the protocol itself is too complicated > and there are many ways a malicious token could compromise the remote > system even without autoplay installed. I'm sure we've all seen serial-to-USB adapters. Now I wonder if it'd be possible to do something in reverse: USB-to-serial. Serial connections are pretty well-understood, well-documented, and (hopefully) less likely/able to be an attack vector. It'd be interesting to see if one could have a USB hub or something to which one could connect a USB flash drive or other device, have the hub negotiate the connection with the device, and then send serial data to the computer where a relatively simple (and presumably easier-to-secure) program could interpret it. Sure, speeds wouldn't be anywhere near the same as with USB and one would have to do some hackery to mount volumes (perhaps a USB-to-serial-to-FUSE interface for common file systems?) but it might work for relatively small file transfers (or for those willing to wait). Is such a thing even possible? -- Pete Stephenson From anthony at cajuntechie.org Tue Sep 10 10:31:04 2013 From: anthony at cajuntechie.org (Anthony Papillion) Date: Tue, 10 Sep 2013 03:31:04 -0500 Subject: How to add authentication capabilities to an existing key? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Is there a good way to add authentication capabilities to an existing RSA key? I see how to toggle it if I create a new subkey but not how to add it to an existing key. Thanks, Anthony - -- Anthony Papillion XMPP/Jabber: cypherpunk at patts.us OTR Fingerprint: 4F5CE6C07F5DCE4A2569B72606E5C00A21DA24FA SIP: 17772471988 at callcentric.com PGP Key: 0x53B04B15 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSLtjIAAoJEAKK33RTsEsVjJEP/0XmQOb07JC07DrorJDlX892 FRGJDvHD/OfKQNAzEhIZFlGBvn844HxvY+CXoOV4cDX6MPNNv/KUvrByoa8C23Hp 2MCWNu4Po+CbV1nLS1FjzATgwGbQb4BdcaH5RxB8mr9BRg2OIQIktFCDi4jWhdPu We1Cq/FN69YduQi1WeGhgbFsMIXBFIBpPYmwaiu1CXJ/31yeqAkcggNkX4zV9jQ/ X2ru3RpZCJRd74tc71GGgIz1O1Y5kKVePyt5YfACe+WHo6f9K+N6oNTB/UQQGIWb 709PY9mKHywRPpQN/Rq1ZXYYWJFR4+Ef2m6ZHgxdUBwkTsXExxvKBBDilluWcokw wHW4ymrZCReeZ2OYeUtMNAYRa3QlmXIMXG07YQ9+EL1jW2aJi7Q+RKbgP8xQ6VMS RIAPuKfgw52z6MRzg1jyiAX4MOb0gxuqdFj+pvwzgGS/x7ePBMaEzVWTpSZRvu72 baGQzKLWMVgFr6QiLJryWBaWV01gXcs3XTK7dpFgZd3YDfuICRr6agX/zSKPxzx1 TFR3K9dEA5f2+8L1P+oFSatV6QnmimvjpM9CVSC6x5bDRmDUh0LelhMLutwVOCrc dglRUD43VTMApPrYeoyH+xchZwpFO9kL7zawxQ6LH9tI5ClbjZm/ed9PnfBBFuyC BETWJAKRTvI/sqvqBn0B =Q7fI -----END PGP SIGNATURE----- From free10pro at gmail.com Tue Sep 10 09:45:48 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Tue, 10 Sep 2013 00:45:48 -0700 Subject: Decrypt Issue In-Reply-To: <30e043faf8154cfcab7f4a63ba84b8dc@MBX03.azdes.gov> References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> <522B98F4.6080108@gmail.com> <30e043faf8154cfcab7f4a63ba84b8dc@MBX03.azdes.gov> Message-ID: <3feb006e-b5c3-4b70-88c0-224136a3ced5@email.android.com> "Diaz, John, A" wrote: >Paul, got it figured out. Programmer too stupid. The path to gpg.exe >had changed, and I didn't catch it. > >-----Original Message----- >From: Paul R. Ramer [mailto:free10pro at gmail.com] >Sent: Saturday, September 07, 2013 2:22 PM >To: Diaz, John, A >Cc: gnupg-users at gnupg.org >Subject: Re: Decrypt Issue > >On 09/04/2013 01:54 PM, Diaz, John, A wrote: >> 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 list the keys on the server that this is running I see the key >listed. >> >> Here's the goofy part: If I login to the server with the credentials >that the mainframe uses to call the first .bat file, and manually run >the .bat file that starts the whole process, it runs correctly. > >Hello John, > >When you say that you log in to the server, are you logging into a >user account on the server? And do you get a command prompt (i.e. you >are ssh-ing into your server)? > >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. Well, I am glad you figured it out. :-) Cheers, --Paul -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndk.clanbo at gmail.com Tue Sep 10 09:50:04 2013 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 10 Sep 2013 09:50:04 +0200 Subject: Why trust gpg4win? In-Reply-To: References: <201307252214.r6PME8tp031462@fire.js.berklix.net> <521656E1.9010608@gmail.com> <52167D43.8050801@securemecca.net> <52198251.6080404@sixdemonbag.org> <522E3FFA.60201@sixdemonbag.org> Message-ID: <522ECF2C.5030307@gmail.com> Il 10/09/2013 00:29, Pete Stephenson ha scritto: >> USB is a peer protocol. There's an astonishing amount of computational >> power on both sides of that USB cable. Protocol negotiation is complex. >> Put it all together and you get a peer-to-peer protocol which you >> *cannot* secure because (a) there are too many computational resources >> available to an attacker and (b) the protocol itself is too complicated >> and there are many ways a malicious token could compromise the remote >> system even without autoplay installed. I strongly disagree here. First error: USB is *not* a peer protocol. It's master-slave. FireWire is a peer protocol. > I'm sure we've all seen serial-to-USB adapters. Now I wonder if it'd > be possible to do something in reverse: USB-to-serial. [...] > Is such a thing even possible? Possible yes. Useful no. You'd be exposed nearly to the same attack vectors. Plus some more (the ones that handle the extra layer), so you'd have to check more code. BYtE, Diego. From wk at gnupg.org Tue Sep 10 11:07:12 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2013 11:07:12 +0200 Subject: Problems using 10kbit keys in GnuPG instead of 4kbit keys In-Reply-To: (Pete Stephenson's message of "Mon, 9 Sep 2013 21:41:42 +0200") References: Message-ID: <87y57582pr.fsf@vigenere.g10code.de> On Mon, 9 Sep 2013 21:41, pete at heypete.com said: > Werner would change the hard-coded maximum keysize from the current > 4096 to, say 8192 (or 15,360 or 16,384) bits so that users who desired As of now I see no reason at all to lift this limit. It is there for a good reason, namely making crypti accessible to all people. There are several problems with overlong encryption keys, to name just two: - If you use an 8k encryption key you should also use an 8k primary certification key because that is the key which is used to keep the parts of an OpenPGP keyblob together. Without that it is easy to slip in another encryption key. Now, 8k RSA signatures are a pain in the registers. It takes too long to verify the hundreds of signatures people have on their keyrings - even on fast machines. - Some MUA decrypt messages on the fly while you are browsing through all the new mails - if that takes too long due to the many 8k keys, it makes the MUA unusable. But thank you, Ole, that you trust our coding capabilities more than the strong math of an 2K RSA key. I am not sure whether this is justified, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From yyy at yyy.id.lv Tue Sep 10 11:26:12 2013 From: yyy at yyy.id.lv (yyy) Date: Tue, 10 Sep 2013 12:26:12 +0300 Subject: Problems using 10kbit keys in GnuPG instead of 4kbit keys References: <87y57582pr.fsf@vigenere.g10code.de> Message-ID: <9C1DB560688544B9B9BDCA9DA95D4E8A@ktf.rtu.lv> ----- Original Message ----- From: "Werner Koch" To: "Pete Stephenson" Cc: "GnuPG Users Mailing List" Sent: Tuesday, September 10, 2013 12:07 PM Subject: Re: Problems using 10kbit keys in GnuPG instead of 4kbit keys > > - Some MUA decrypt messages on the fly while you are browsing through > all the new mails - if that takes too long due to the many 8k keys, > it makes the MUA unusable. This is only a problem to user who choose to use 8k key, not to anyone else. From pkk at spth.de Tue Sep 10 12:35:46 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Tue, 10 Sep 2013 12:35:46 +0200 Subject: The symmetric ciphers Message-ID: <522EF602.3080604@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIu9f8ACgkQbtUV+xsoLpr7hgCglipmlV07D+wh0ylVgs+7MX1E d+wAnREuQlhGEEg6IbcHXRb+L/d/hIBS =T5GL -----END PGP SIGNATURE----- From free10pro at gmail.com Tue Sep 10 12:35:59 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Tue, 10 Sep 2013 03:35:59 -0700 Subject: How to add authentication capabilities to an existing key? In-Reply-To: References: Message-ID: <6b07fb22-843a-476d-9778-37959915be16@email.android.com> Anthony Papillion wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA512 > >Is there a good way to add authentication capabilities to an existing >RSA key? I see how to toggle it if I create a new subkey but not how >to add it to an existing key. [snip] Hello Anthony, As far as I know, there is no such capability to do that with gpg. You have to set that capability when you create the key. HTH. Cheers, --Paul From free10pro at gmail.com Tue Sep 10 12:58:13 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Tue, 10 Sep 2013 03:58:13 -0700 Subject: The symmetric ciphers In-Reply-To: <522EF602.3080604@spth.de> References: <522EF602.3080604@spth.de> Message-ID: <70e13496-6e7c-4152-8326-c9b1ea955cd5@email.android.com> 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: > >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. You may just prefer to use a key with a larger size and a better password. But if you do want to do this, I am sure that you could write a script or program that could take advantage of GnuPG for this purpose. Cheers, --Paul -- PGP: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Sep 10 13:30:01 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2013 13:30:01 +0200 Subject: Problems using 10kbit keys in GnuPG instead of 4kbit keys In-Reply-To: <9C1DB560688544B9B9BDCA9DA95D4E8A@ktf.rtu.lv> (yyy@yyy.id.lv's message of "Tue, 10 Sep 2013 12:26:12 +0300") References: <87y57582pr.fsf@vigenere.g10code.de> <9C1DB560688544B9B9BDCA9DA95D4E8A@ktf.rtu.lv> Message-ID: <87hads9ao6.fsf@vigenere.g10code.de> On Tue, 10 Sep 2013 11:26, yyy at yyy.id.lv said: > This is only a problem to user who choose to use 8k key, not to anyone else. Given that it is related two my second point, it is a problem for everyone - as long as we use some kind of multi party trust evaluation. With a simple TOFC scheme (locally tacking the use of seen keys) this won't be a problem, though Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 10 13:45:40 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2013 13:45:40 +0200 Subject: The symmetric ciphers In-Reply-To: <522EF602.3080604@spth.de> (Philipp Klaus Krause's message of "Tue, 10 Sep 2013 12:35:46 +0200") References: <522EF602.3080604@spth.de> Message-ID: <87d2og99y3.fsf@vigenere.g10code.de> On Tue, 10 Sep 2013 12:35, pkk at spth.de said: > 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: Which requires more entropy for the two keys and thus creating an incentive to use a faster and more insure RNG. Although this complicates the code a lot and thus creates more opportunities for exploits. To rephrase Brooks: Adding too many bits to an already suitable key makes the security worse. 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. Again: Nobody is breaking an algorithm (public or symmetric) - they are going for the code and then maybe for the RNG. That whole debate about key lengths is missing the point. As Robert pointed out, we can't make any long term estimation on the progress on cipher breaking and new cipher systems. Also: Consider what damage may happen if information leaks in 10 minutes, 10 weeks, or 10 years. If you are concerned about 10 years, you may better not use a networked computer in the first place. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 10 13:49:13 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2013 13:49:13 +0200 Subject: adding subkeys in gpg4 win In-Reply-To: <20130909164806.1F596A0122@smtp.hushmail.com> (vedaal@nym.hush.com's message of "Mon, 09 Sep 2013 12:48:05 -0400") References: <20130909164806.1F596A0122@smtp.hushmail.com> Message-ID: <871u4w99s6.fsf@vigenere.g10code.de> On Mon, 9 Sep 2013 18:48, vedaal at nym.hush.com said: > Is there something really basic that I missed? No. Use the command line for such tasks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 10 13:47:55 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2013 13:47:55 +0200 Subject: How to add authentication capabilities to an existing key? In-Reply-To: <6b07fb22-843a-476d-9778-37959915be16@email.android.com> (Paul R. Ramer's message of "Tue, 10 Sep 2013 03:35:59 -0700") References: <6b07fb22-843a-476d-9778-37959915be16@email.android.com> Message-ID: <8761u899uc.fsf@vigenere.g10code.de> On Tue, 10 Sep 2013 12:35, free10pro at gmail.com said: > As far as I know, there is no such capability to do that with gpg. You have to set that capability when you create the key. HTH. Right, you need to change the source to add such a feature. I agree that adding a way to add an authentication capability to a key might make sense in some cases. As soon as this emerges as a real world use case, I am pretty sure it will be added. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From anthony at cajuntechie.org Tue Sep 10 14:06:29 2013 From: anthony at cajuntechie.org (Anthony Papillion) Date: Tue, 10 Sep 2013 07:06:29 -0500 Subject: How to add authentication capabilities to an existing key? In-Reply-To: <6b07fb22-843a-476d-9778-37959915be16@email.android.com> References: <6b07fb22-843a-476d-9778-37959915be16@email.android.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/10/2013 05:35 AM, Paul R. Ramer wrote: > Anthony Papillion wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> Is there a good way to add authentication capabilities to an >> existing RSA key? I see how to toggle it if I create a new subkey >> but not how to add it to an existing key. > [snip] > > Hello Anthony, > > As far as I know, there is no such capability to do that with gpg. > You have to set that capability when you create the key. HTH. Thanks, Paul! I don't really need the "feature" anyway, I just read about it and figured 'why not?" Plus I wanted to investigate what it was for. After the responses from both you and Werner, I'm not that concerned about it. Thanks! Anthony - -- Anthony Papillion XMPP/Jabber: cypherpunk at patts.us OTR Fingerprint: 4F5CE6C07F5DCE4A2569B72606E5C00A21DA24FA SIP: 17772471988 at callcentric.com PGP Key: 0x53B04B15 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSLwtFAAoJEAKK33RTsEsVKgwQAIgMjM8PHI6cunj4YE7afS9e H07YkZ+Jp3JPo9GL/O9Tubs20yjQX/iQ1HdPexAIJdI2uww1S2EN3//JNen97Ypf VVDGfC4SZopy0QkP/UUVJd4sdcqBNoChA8kFhNHcMJg+e698uersLtjLH9CDKH1C x3LAZMdTkdLGYGG3QbQAufF323Cw5Z6WqmABnJVbhZPuFdLyg9cxH8+bHqennBY4 QDV8fI847ct4rLLLlMieY9haMzBc+8ObarLFLG9d5y4Zhke7UvhbQuzzN8HyufT9 use3Xvp2wWqJ5/DBEiehuJsvQ/ZbOCxiRkNaydivBxyS8pMvbKlkXM7Z/iCEcPlM kC/Po5Ft/xQMrkgh87s/+Fmg5JKFvYHFPurOMUY3+ly7k3b97dwcyCFhf9Yw9Mhf ESNQ2VLLAnw2j0PvRJgKhTXUjPFFqrBv6yfEZwSpd0aKq1dG4F3fSK8qlgYVYOa2 HsV+xKJzTWcpfKrvx4Sw4e80+Qv5Pr5cXRhtNPP4FNOw5dy5kvyMt2u6pLmejkNk em53OMWwnvoFWCjFEMaZfVmY1JMtD9KDK5cVxSTbucwte5OmsGZbLb06KKgudrxu z/qMjcT0idb56Fg6yx9/vLfWEoBUMgr2fgpGXerZHZHoxIQjCIQwNiY+HrzupQbJ 5Z4Uexa7L/WQl1yqVvcT =vQti -----END PGP SIGNATURE----- From wk at gnupg.org Tue Sep 10 14:02:47 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2013 14:02:47 +0200 Subject: Fedora GPG Key Server In-Reply-To: (Marcio B., Jr.'s message of "Mon, 9 Sep 2013 10:44:07 -0300") References: <877getgc2q.fsf@vigenere.g10code.de> Message-ID: <87wqmo7ul4.fsf@vigenere.g10code.de> On Mon, 9 Sep 2013 15:44, marcio.barbado at gmail.com said: > This whole NSA blackmailing situation is causing strange reactions in you, sir. This has nothing to do with the NSA. There are two reasons: I don't like to switch tasks too often. My main way of communication is by mail and I I read and reply to a bunch of mails at once. Switching between Emacs and Conkeror is just disturbing and loading web pages often takes several seconds. Further, I am often offline (think train or hammock in the garden) and thus have no way or incentive to read online stuff. Shalom-Salam, Werner p.s. Right, I am not a digital native. I grew up mostly with analog communication; for example mobile using the SSB ?protocol? with an IC202. But to some extend also digital with a T37 for RTTY up in the shack. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 10 14:07:36 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2013 14:07:36 +0200 Subject: GPG and Outlook revisited In-Reply-To: <522E3FD9.8080306@dougbarton.us> (Doug Barton's message of "Mon, 09 Sep 2013 14:38:33 -0700") References: <878uz6azdw.fsf@vigenere.g10code.de> <522E1EBC.2020409@digitalbrains.com> <522E3FD9.8080306@dougbarton.us> Message-ID: <87sixc7ud3.fsf@vigenere.g10code.de> On Mon, 9 Sep 2013 23:38, dougb at dougbarton.us said: > It's worth noting for sake of argument that the same exact concerns > apply to the pre-packaged binaries of GnuPG for Windows. The difference is that it is possible to build it on your own. If you are concerened, please do that. I would be more concerned about all the open source libaries we use - I am not able to check them for backdoors. But at least there is a chance that such a backdoor will be revealed and may even be tracked down to that innocent hackers whos development box has been bugged by a TLA :-( Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 10 14:19:42 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Sep 2013 14:19:42 +0200 Subject: Why trust gpg4win? In-Reply-To: <522ECF2C.5030307@gmail.com> (NdK's message of "Tue, 10 Sep 2013 09:50:04 +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> Message-ID: <87ob807tsx.fsf@vigenere.g10code.de> On Tue, 10 Sep 2013 09:50, ndk.clanbo at gmail.com said: > First error: USB is *not* a peer protocol. It's master-slave. FireWire > is a peer protocol. However, that is implemented by computers at boths ends and the software there may have backdoors or explotable code which coult be used for all kind of tricks. Look only at the trend to use HID as simple driver-less way to connect about anything to a computer. Emulated keyboard which sends ANSI control codes to take over your box without you noticing? > You'd be exposed nearly to the same attack vectors. Plus some more (the > ones that handle the extra layer), so you'd have to check more code. So what about using that free USB stack for AVR's to implement a flash device? You would be able to audit about everything; flylogic even has these nice pictures of the ATmega88 masks... Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Tue Sep 10 15:30:14 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Sep 2013 09:30:14 -0400 Subject: The symmetric ciphers In-Reply-To: <522EF602.3080604@spth.de> References: <522EF602.3080604@spth.de> Message-ID: <522F1EE6.70308@sixdemonbag.org> 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. > 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." From tange at gnu.org Tue Sep 10 15:31:51 2013 From: tange at gnu.org (Ole Tange) Date: Tue, 10 Sep 2013 15:31:51 +0200 Subject: Problems using 10kbit keys in GnuPG instead of 4kbit keys In-Reply-To: <87y57582pr.fsf@vigenere.g10code.de> References: <87y57582pr.fsf@vigenere.g10code.de> Message-ID: On Tue, Sep 10, 2013 at 11:07 AM, Werner Koch wrote: > > There are several problems with overlong encryption keys, to name just > two: > > - If you use an 8k encryption key you should also use an 8k primary > certification key because that is the key which is used to keep the > parts of an OpenPGP keyblob together. Without that it is easy to > slip in another encryption key. I have not heard of the primary certification key before. Is it the 'C' in 'usage: SCEA'? Can that be changed without losing signatures on the public key? If so, then the size of that can be increased slowly when needed. My goal with the 10kbit key is not to have 10kbit security today, but to be able to ramp up the effective key length without loosing the signatures on my public key. > Now, 8k RSA signatures are a pain in > the registers. It takes too long to verify the hundreds of > signatures people have on their keyrings - even on fast machines. I have now generated a test 10kbit key with 200 10kbit signatures. Adding signature 200 is not measurably slower than adding the first (in the order of 1.7 sec). I can verify a message signed with the key with 200 sigs just as fast as a message signed with a key without the signatures. If it is something else you mean, can you give an example command line that shows the long time? Is it something that can be done in parallel and/or be done in the background and/or be cached? Does it happen often? Does it happen to a lot of people? > - Some MUA decrypt messages on the fly while you are browsing through > all the new mails - if that takes too long due to the many 8k keys, > it makes the MUA unusable. In my test the decryption of message encrypted and signed by a 10 kbit key takes 1.7 seconds, and only on the 10 kbit key holder's machine. Will you consider this unusable? /Ole From JDiaz at azdes.gov Tue Sep 10 15:41:47 2013 From: JDiaz at azdes.gov (Diaz, John, A) Date: Tue, 10 Sep 2013 13:41:47 +0000 Subject: Decrypt Issue In-Reply-To: <3feb006e-b5c3-4b70-88c0-224136a3ced5@email.android.com> References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> <522B98F4.6080108@gmail.com> <30e043faf8154cfcab7f4a63ba84b8dc@MBX03.azdes.gov> <3feb006e-b5c3-4b70-88c0-224136a3ced5@email.android.com> Message-ID: 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? From: Paul R. Ramer [mailto:free10pro at gmail.com] Sent: Tuesday, September 10, 2013 12:46 AM To: Diaz, John, A Cc: gnupg-users at gnupg.org Subject: RE: Decrypt Issue "Diaz, John, A" > wrote: Paul, got it figured out. Programmer too stupid. The path to gpg.exe had changed, and I didn't catch it. -----Original Message----- From: Paul R. Ramer [mailto:free10pro at gmail.com] Sent: Saturday, September 07, 2013 2:22 PM To: Diaz, John, A Cc: gnupg-users at gnupg.org Subject: Re: Decrypt Issue On 09/04/2013 01:54 PM, Diaz, John, A wrote: 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 list the keys on the server that this is running I see the key listed. Here's the goofy part: If I login to the server with the credentials that the mainframe uses to call the first .bat file, and manually run the .bat file that starts the whole process, it runs correctly. Hello John, When you say that you log in to the server, are you logging into a user account on the server? And do you get a command prompt (i.e. you are ssh-ing into your server)? 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. Well, I am glad you figured it out. :-) Cheers, --Paul -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at heypete.com Tue Sep 10 15:42:53 2013 From: pete at heypete.com (Pete Stephenson) Date: Tue, 10 Sep 2013 15:42:53 +0200 Subject: Problems using 10kbit keys in GnuPG instead of 4kbit keys In-Reply-To: References: <87y57582pr.fsf@vigenere.g10code.de> Message-ID: On Tue, Sep 10, 2013 at 3:31 PM, Ole Tange wrote: > I have not heard of the primary certification key before. Is it the > 'C' in 'usage: SCEA'? Yes. The certification key is used when signing (more properly, "certifying") other people's public keys. A signing key can be used for signing files or messages but the certification key is used for signing other people's keys. In short, it's the "primary" key. > Can that be changed without losing signatures on the public key? If > so, then the size of that can be increased slowly when needed. Unfortunately not. It is the primary key and its properties (e.g. key length) cannot be changed. Cheers! -Pete From takethebus at gmx.de Tue Sep 10 16:16:12 2013 From: takethebus at gmx.de (Jan) Date: Tue, 10 Sep 2013 16:16:12 +0200 Subject: Why trust gpg4win? 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> Message-ID: <5707B6141E374A519D00A6C238849EE5@neinpc> On 10/9/2013 14:19, Werner Koch wrote : >However, [USB] is implemented by computers at boths ends and the software >there may have backdoors or explotable code which coult be used for all >kind of tricks [...] I am shocked! Why was USB constructed that insecure?! On 10/9/2013 14:19, Werner Koch wrote : >So what about using that free USB stack for AVR's to implement a flash >device? You would be able to audit about everything; flylogic even has >these nice pictures of the ATmega88 masks... I don't understand this, what does AVR etc. mean? Is there a substituion for USB? I'd be grateful for an explanation. Kind regards, Jan From ndk.clanbo at gmail.com Tue Sep 10 15:18:51 2013 From: ndk.clanbo at gmail.com (NdK) Date: Tue, 10 Sep 2013 15:18:51 +0200 Subject: Why trust gpg4win? In-Reply-To: <87ob807tsx.fsf@vigenere.g10code.de> 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> Message-ID: <522F1C3B.9030306@gmail.com> Il 10/09/2013 14:19, Werner Koch ha scritto: >> First error: USB is *not* a peer protocol. It's master-slave. FireWire >> is a peer protocol. > However, that is implemented by computers at boths ends and the software > there may have backdoors or explotable code which coult be used for all > kind of tricks. Look only at the trend to use HID as simple driver-less > 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 open app chances are that you will see keystrokes there. Sure, it could send a 'win' keypress+release event, but that wouldn't work (or at least it wouldn't be "unnoticed") in every other SO. Probably it's "easier" (or at least more effective and less user-noticeable) to target the USB stack using non-conformant packets (where buffer overflows might eist). That would give much more time to try different vulnerabilities before getting caught. PS: one of the ideas that could "easily" be implemented on FST-01 is a TOTP password generator that auto-types the code when you press its button. >> You'd be exposed nearly to the same attack vectors. Plus some more (the >> ones that handle the extra layer), so you'd have to check more code. > So what about using that free USB stack for AVR's to implement a flash > device? You would be able to audit about everything; flylogic even has > these nice pictures of the ATmega88 masks... Sorry, I don't follow your reasoning here. 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? BYtE, Diego. From awg1 at gmx.com Tue Sep 10 15:12:02 2013 From: awg1 at gmx.com (Adam Gold) Date: Tue, 10 Sep 2013 14:12:02 +0100 Subject: message digest for signed emails Message-ID: <013101ceae27$582e4cf0$088ae6d0$@gmx.com> I apologise in advance if this is a repeat question (I have consulted the archives although not exhaustively) but I've been trying to get this right for two days now to no avail. I want the message digest for my emails to be SHA512 (or SHA256) but I can't seem to change it from SHA1. I have tried generating new keys, changing email clients and/or key management programs but nothing seems to work. My gpg.conf contains the following lines: default-preference-list SHA512 SHA256 SHA384 SHA224 SHA1 AES256 AES192 AES CAST5 3DES ZLIB BZIP2 ZIP Uncompressed personal-cipher-preferences AES256 AES192 AES CAST5 3DES personal-digest-preferences SHA512 SHA256 SHA384 SHA224 SHA1 personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed cert-digest-algo SHA512 s2k-cipher-algo AES256 s2k-digest-algo SHA512 s2k-count 65011712 I appreciate there are some lines there not directly related to email signature message digests but at least lines 1 and 3 should set the default order as specified. If I generate a new key and then check the preferences (--edit-key ID, showpref) it does indeed reflect the above order. However if I send a signed email, it always starts with 'Hash: SHA1'. One additional point: if I use --clearsign for a non-email related document, this will employ the SHA512 digest. Why the discrepancy? What do I need to do to change it on my email? From Dave.Smith at st.com Tue Sep 10 16:33:38 2013 From: Dave.Smith at st.com (David Smith) Date: Tue, 10 Sep 2013 15:33:38 +0100 Subject: Why trust gpg4win? In-Reply-To: <5707B6141E374A519D00A6C238849EE5@neinpc> 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> <5707B6141E374A519D00A6C238849EE5@neinpc> Message-ID: <522F2DC2.1090303@st.com> On 09/10/13 15:16, Jan wrote: > I don't understand this, what does AVR etc. mean? Is there a substituion for > USB? I'd be grateful for an explanation. AVR is a semiconductor manufacturer who make microcontrollers (amongst other things). From dkg at fifthhorseman.net Tue Sep 10 16:59:14 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Sep 2013 10:59:14 -0400 Subject: message digest for signed emails In-Reply-To: <013101ceae27$582e4cf0$088ae6d0$@gmx.com> References: <013101ceae27$582e4cf0$088ae6d0$@gmx.com> Message-ID: <522F33C2.8050002@fifthhorseman.net> On 09/10/2013 09:12 AM, Adam Gold wrote: > My gpg.conf contains the following lines: > > default-preference-list SHA512 SHA256 SHA384 SHA224 SHA1 AES256 AES192 AES CAST5 3DES ZLIB BZIP2 ZIP Uncompressed > personal-digest-preferences SHA512 SHA256 SHA384 SHA224 SHA1 the lines above look like they indicate your preferences as you describe them. > personal-cipher-preferences AES256 AES192 AES CAST5 3DES > personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed > cert-digest-algo SHA512 > s2k-cipher-algo AES256 > s2k-digest-algo SHA512 > s2k-count 65011712 these lines aren't relevant for data signatures. > I appreciate there are some lines there not directly related to email > signature message digests but at least lines 1 and 3 should set the default > order as specified. If I generate a new key and then check the preferences > (--edit-key ID, showpref) it does indeed reflect the above order. However > if I send a signed email, it always starts with 'Hash: SHA1'. gpg is not a mail user agent. what are you using to send mail? how is it connected to gpg? Your original message claims: X-Mailer: Microsoft Outlook 15.0 > One additional point: if I use --clearsign for a non-email related document, > this will employ the SHA512 digest. Why the discrepancy? What do I need to > do to change it on my email? You need to provide more details about your mail user agent and how it interacts with GnuPG -- it sounds like the behavior is being introduced there. --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 josef at netpage.dk Tue Sep 10 17:10:15 2013 From: josef at netpage.dk (Josef Schneider) Date: Tue, 10 Sep 2013 17:10:15 +0200 Subject: The symmetric ciphers In-Reply-To: <522F1EE6.70308@sixdemonbag.org> References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> Message-ID: On Tue, Sep 10, 2013 at 3:30 PM, Robert J. Hansen wrote: > > 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." > Why? Assuming the Keys are not related (e.g. by creating random keys and then encrypting them both with RSA) this is safer, assuming the attacker can crack one of the two symmetric ciphers but not RSA. If you use the same/related Keys for both encryptions and/or the ciphers don't interact somehow (like when using ROT-13 two times) it is indeed less secure! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kabads at gmail.com Tue Sep 10 18:47:11 2013 From: kabads at gmail.com (AdamC) Date: Tue, 10 Sep 2013 17:47:11 +0100 Subject: Upgrading keys to larger than 1024 Message-ID: I have keys that I have used (sparingly) since 2004. This is a 1024 keysize. That keypair has a few signatures through key signing. What is the best approach to upgrading keys to 4096? Is it just create a new keypair and then go to lots of key signing events again (pain), or is there a way to do this with my current keys? TIA Adam -- You back your data up on the same planet? PGP key: 0x7111B833 -------------- next part -------------- An HTML attachment was scrubbed... URL: From awg1 at gmx.com Tue Sep 10 20:23:03 2013 From: awg1 at gmx.com (Adam Gold) Date: Tue, 10 Sep 2013 19:23:03 +0100 Subject: message digest for signed emails In-Reply-To: <522F33C2.8050002@fifthhorseman.net> References: <013101ceae27$582e4cf0$088ae6d0$@gmx.com> <522F33C2.8050002@fifthhorseman.net> Message-ID: <000901ceae52$cb8fbff0$62af3fd0$@gmx.com> > -----Original Message----- > From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] > Sent: 10 September 2013 15:59 > To: Adam Gold > Cc: gnupg-users at gnupg.org > Subject: Re: message digest for signed emails > > gpg is not a mail user agent. what are you using to send mail? how is it > connected to gpg? Your original message claims: > > X-Mailer: Microsoft Outlook 15.0 > This message was sent using Outlook however my gpg mail is setup in debian wheezy. I was using the thunderbird equivalent but I've switched to mutt with gpg/MIME support as I want to use a console based app. > > One additional point: if I use --clearsign for a non-email related > > document, this will employ the SHA512 digest. Why the discrepancy? > > What do I need to do to change it on my email? > > You need to provide more details about your mail user agent and how it > interacts with GnuPG -- it sounds like the behavior is being introduced there. > > --dkg To enable gpg support in mutt I copied /usr/share/doc/mutt/examples/gpg.rc to ~/.mutt and then added 'source ~/.mutt/gpg.rc' to the mutt config file. I also added to the config a number of lines as per here: http://pastebin.com/t17HcrCS If I send a mail to myself in mutt I get the following in the received message: ======================= [-- PGP output follows (current time: Tue 10 Sep 2013 18:59:09 BST) --] gpg: Signature made Tue 10 Sep 2013 18:58:08 BST using RSA key ID 00583A4C gpg: Good signature from "Adam Gold" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: [ ] [-- End of PGP output --] [-- The following data is signed --] test [-- End of signed data --] ========================= This doesn't show what the hash is so I saved the attached signature.asc file and ran 'gpg -v' against the actual email saved in my email directory. The following was returned: =============================== gpg: Signature made Tue 10 Sep 2013 18:58:08 BST using RSA key ID gpg: using PGP trust model gpg: BAD signature from "Adam Gold" gpg: textmode signature, digest algorithm SHA1 =============================== I guess the bad signature is because the signature.asc file is not meant to be detached from the email and then checked against the email. However, as you'll see, the digest is still SHA1. Perhaps this is unreliable too but I can't see another way when viewing a signed message in mutt to ascertain the digest. FYI: it mentions here that mutt support SHA2: https://wiki.ubuntu.com/SecurityTeam/GPGMigration I really appreciate you taking the time to look at this. If there is any specific information I have omitted, please let me know. Alternatively if you don't mind, I can send you directly a signed email from my mutt account (I don't want to reveal it publicly) and you could see what digest is being used. From harningt at gmail.com Tue Sep 10 20:22:14 2013 From: harningt at gmail.com (Thomas Harning Jr.) Date: Tue, 10 Sep 2013 14:22:14 -0400 Subject: Upgrading keys to larger than 1024 In-Reply-To: References: Message-ID: If you are upgrading, I would recommend contacting those that you previously had keysigning with and see if the policy they follow allows for obtaining re-signatures based on prior information. My key signing policy [1] allows for an "Accelerated Signing" where I may opt to sign a users' key given certain conditions, such as they must show control of the prior key and it must not have been revoked due to compromise, etc... This was put in due to the understanding that keys should be recycled on occasion to keep with the times and it isn't always practical to meet up with everybody you exchanged signatures with. A better solution, hopefully useful for you, is to contact everybody you've exchanged signatures and have a grand ol' signing party, but oftentimes it isn't practical. 1: http://www.eharning.us/gpg/key-signing-policy/ On Tue, Sep 10, 2013 at 12:47 PM, AdamC wrote: > I have keys that I have used (sparingly) since 2004. This is a 1024 keysize. > That keypair has a few signatures through key signing. > > What is the best approach to upgrading keys to 4096? Is it just create a new > keypair and then go to lots of key signing events again (pain), or is there > a way to do this with my current keys? > > TIA > Adam > > -- > You back your data up on the same planet? > PGP key: 0x7111B833 > > _______________________________________________ > 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 dkg at fifthhorseman.net Tue Sep 10 20:29:51 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Sep 2013 14:29:51 -0400 Subject: Upgrading keys to larger than 1024 In-Reply-To: References: Message-ID: <522F651F.8050407@fifthhorseman.net> On 09/10/2013 12:47 PM, AdamC wrote: > I have keys that I have used (sparingly) since 2004. This is a 1024 > keysize. That keypair has a few signatures through key signing. > > What is the best approach to upgrading keys to 4096? Is it just create a > new keypair and then go to lots of key signing events again (pain), or is > there a way to do this with my current keys? There's no way to directly upgrade if your primary key is weaker than you'd like. You should create a new keypair and go out in the world and meet people who will sign your key. it doesn't have to be a pain :) Ana wrote up some good suggestions about how to do a key transition: http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ 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 dkg at fifthhorseman.net Tue Sep 10 20:35:53 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Sep 2013 14:35:53 -0400 Subject: message digest for signed emails In-Reply-To: <000901ceae52$cb8fbff0$62af3fd0$@gmx.com> References: <013101ceae27$582e4cf0$088ae6d0$@gmx.com> <522F33C2.8050002@fifthhorseman.net> <000901ceae52$cb8fbff0$62af3fd0$@gmx.com> Message-ID: <522F6689.10606@fifthhorseman.net> On 09/10/2013 02:23 PM, Adam Gold wrote: > To enable gpg support in mutt I copied /usr/share/doc/mutt/examples/gpg.rc to ~/.mutt and then added 'source ~/.mutt/gpg.rc' to the mutt config file. I also added to the config a number of lines as per here: http://pastebin.com/t17HcrCS > > If I send a mail to myself in mutt I get the following in the received message: > > ======================= > [-- PGP output follows (current time: Tue 10 Sep 2013 18:59:09 BST) --] > gpg: Signature made Tue 10 Sep 2013 18:58:08 BST using RSA key ID 00583A4C > gpg: Good signature from "Adam Gold" > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: [ ] > [-- End of PGP output --] > [-- The following data is signed --] > test > [-- End of signed data --] > ========================= > > This doesn't show what the hash is so I saved the attached signature.asc file and ran 'gpg -v' against the actual email saved in my email directory. The following was returned: > > =============================== > gpg: Signature made Tue 10 Sep 2013 18:58:08 BST using RSA key ID > gpg: using PGP trust model > gpg: BAD signature from "Adam Gold" > gpg: textmode signature, digest algorithm SHA1 > =============================== > > I guess the bad signature is because the signature.asc file is not meant to be detached from the email and then checked against the email. However, as you'll see, the digest is still SHA1. Perhaps this is unreliable too but I can't see another way when viewing a signed message in mutt to ascertain the digest. > > FYI: it mentions here that mutt support SHA2: https://wiki.ubuntu.com/SecurityTeam/GPGMigration > > I really appreciate you taking the time to look at this. If there is any specific information I have omitted, please let me know. Alternatively if you don't mind, I can send you directly a signed email from my mutt account (I don't want to reveal it publicly) and you could see what digest is being used. sorry, i don't know much about mutt or how it integrates with gpg. maybe someone else on the list can help you with that, or you could ask on a mailing list that's dedicated to mutt? --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 pkk at spth.de Tue Sep 10 21:01:30 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Tue, 10 Sep 2013 21:01:30 +0200 Subject: Should the use of multiple UID per key be discouraged? Message-ID: <522F6C8A.4040602@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GPG supports the feature of having multiple UIDs per key. However this requires special care of anyone signing such a key. AFAIK, there is no really user-friendly, and definitely no newbie-friendly way to do so. IMO this makes it much harder to expand the web of trust. Would it be a good idea to discourage people from having multiple UIDs per key, and encourage them to create a separate key per UID instead? Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIvbIYACgkQbtUV+xsoLpqLAQCgnwIrB/E/Q1tcCyG8GvjvWcOX vU8AoOElrV2BTmFg3P33dLCwvgH7H6p5 =iAg1 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Tue Sep 10 21:09:43 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Sep 2013 15:09:43 -0400 Subject: Should the use of multiple UID per key be discouraged? In-Reply-To: <522F6C8A.4040602@spth.de> References: <522F6C8A.4040602@spth.de> Message-ID: <522F6E77.9040500@fifthhorseman.net> On 09/10/2013 03:01 PM, Philipp Klaus Krause wrote: > GPG supports the feature of having multiple UIDs per key. > However this requires special care of anyone signing such a key. > AFAIK, there is no really user-friendly, and definitely no > newbie-friendly way to do so. Please try out monkeysign (version 1.0 is in debian testing right now). It targets exactly this problem: http://web.monkeysphere.info/monkeysign/ If you think it is not user-friendly enough, the developers are active and friendly folks, and they would be happy to receive suggestions for new features. > Would it be a good idea to discourage people from having multiple UIDs > per key, and encourage them to create a separate key per UID instead? I do not think this discouragement would be a good idea, since moving to multiple keys imposes other costs and difficulties. There are good reasons to use separate keys for separate identities (e.g. if you want to have key you can hand over to your job when you leave there, or if you want to operate under a pseudonym). but there are also good reasons to use one key for multiple identities (simpler key management, more direct paths through the WoT for people who know you under one alias or another). There are tradeoffs involved in key and identity management, and people need to be free to make the tradeoffs that make sense for them. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Sep 10 21:28:36 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 10 Sep 2013 15:28:36 -0400 Subject: The symmetric ciphers In-Reply-To: References: <522EF602.3080604@spth.de> <522F1EE6.70308@sixdemonbag.org> Message-ID: <522F72E4.7050402@sixdemonbag.org> On 09/10/2013 11:10 AM, Josef Schneider wrote: > Why? Assuming the Keys are not related (e.g. by creating random keys > and then encrypting them both with RSA) this is safer, assuming the > attacker can crack one of the two symmetric ciphers but not RSA. I repeat my earlier message: > If you look in the list archives you can find some pretty long, > detailed writeups on why. It takes you about thirty seconds to type a message. To fully answer your question would require me to spend about an hour crafting an answer. Since your question has been answered *at length* in the archives, I'm not going to answer your question. I'm going to refer you to the archives and save myself an hour. From takethebus at gmx.de Tue Sep 10 22:42:35 2013 From: takethebus at gmx.de (Jan) Date: Tue, 10 Sep 2013 22:42:35 +0200 Subject: Why trust gpg4win? 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> <5707B6141E374A519D00A6C238849EE5@neinpc> <522F2DC2.1090303@st.com> Message-ID: <30221243254A4BF9AC0FED95F22C7501@neinpc> 10/9/2013 14:19, Werner Koch wrote : > So what about using that free USB stack for AVR's to implement a flash > device? You would be able to audit about everything; flylogic even has > these nice pictures of the ATmega88 masks... 10/9/2013 16:33, David Smith wrote: > AVR is a semiconductor manufacturer who make microcontrollers (amongst > other things). Thanks for the answers. Did you refer to the following? http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/index.html http://www.flylogic.net/blog/?p=23 How could I implement a flash device? Do you mean I need to take some existing USB device created by AVR and replace its firmware by LUFA or something like that? Could I use that modified USB device on every PC or operation system? Kind regards, Jan From attila.lendvai at gmail.com Wed Sep 11 10:22:24 2013 From: attila.lendvai at gmail.com (attila lendvai) Date: Wed, 11 Sep 2013 01:22:24 -0700 (PDT) Subject: Transfer subkey to other keyring In-Reply-To: <522B33C3.4090408@digitalbrains.com> References: <51C9DD9A.3060707@nottheoilrig.com> <87ppv9gqx1.fsf@vigenere.g10code.de> <51CB2C48.4070809@nottheoilrig.com> <87hagkdmca.fsf@vigenere.g10code.de> <51CC6E7D.4080709@nottheoilrig.com> <522B33C3.4090408@digitalbrains.com> Message-ID: <1378887744020-32397.post@n7.nabble.com> Peter Lebbing wrote > I believe once GnuPG has a secret key, it won't update it anymore with any > subsequent imports. So to get the additional subkey, re-export the whole > thing, > delete the existing one on the other system and import your re-exported > whole thing. i can confirm this. i've deleted the entire secret key from my less protected keychain, including the previous expired subkeys, and after that gpg --import imported the subkeys i wanted (all of them that got exported with --export-secret-subkeys from the more protected keyring). Peter Lebbing wrote >> gpg: secret keys unchanged: 1 > > This message to me implies it is actually possible to change something > about a > secret key. I haven't figured out what yet. me, too. if gpg printed something like: "secret key already exists, aborting." then i would have tried your suggested method of deleting the entire secret key block on my own. shall i/we record a bug in the gpg bug tracker for this? -- ? attila lendvai ? PGP: 963F 5D5F 45C7 DFCD 0A39 -- ?I know that most men, including those at ease with problems of the greatest complexity, can seldom accept even the simplest and most obvious truth if it be such as would oblige them to admit the falsity of conclusions which they have delighted in explaining to colleagues, which they have proudly taught to others, and which they have woven, thread by thread, into the fabric of their lives.? ? Leo Tolstoy (1828?1910) Or in short: ?Science advances one funeral at a time.? ? Max Planck (1858?1947), paraphrased -- View this message in context: http://gnupg.10057.n7.nabble.com/Transfer-subkey-to-other-keyring-tp31272p32397.html Sent from the GnuPG - User mailing list archive at Nabble.com. From takethebus at gmx.de Wed Sep 11 11:01:26 2013 From: takethebus at gmx.de (Jan) Date: Wed, 11 Sep 2013 11:01:26 +0200 Subject: Why trust gpg4win? 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: <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> On 10/09/2013 15:18, NdK wrote: >>> You'd be exposed nearly to the same attack vectors. Plus some more (the >>> ones that handle the extra layer), so you'd have to check more code. >> So what about using that free USB stack for AVR's to implement a flash >> device? You would be able to audit about everything; flylogic even has >> these nice pictures of the ATmega88 masks... >Sorry, I don't follow your reasoning here. >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? Maybe Pete meant such an USB-to-Serial interface http://www.robotsimple.com/Computer_Interface/USB_to_Serial_Adapter ? Nevertheless this seems quite tricky to handel. Is it better to use a CD-RW to transfer data between an offline and an online PC than to use an ordinary USB stick? Which other medium might be good? Kind regards, Jan From pete at heypete.com Wed Sep 11 11:48:08 2013 From: pete at heypete.com (Pete Stephenson) Date: Wed, 11 Sep 2013 11:48:08 +0200 Subject: Why trust gpg4win? In-Reply-To: <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> Message-ID: On Wed, Sep 11, 2013 at 11:01 AM, Jan wrote: > On 10/09/2013 15:18, NdK wrote: > >>>> You'd be exposed nearly to the same attack vectors. Plus some more (the >>>> ones that handle the extra layer), so you'd have to check more code. >>> >>> So what about using that free USB stack for AVR's to implement a flash >>> device? You would be able to audit about everything; flylogic even has >>> these nice pictures of the ATmega88 masks... >> >> Sorry, I don't follow your reasoning here. >> 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? > > > Maybe Pete meant such an USB-to-Serial interface > http://www.robotsimple.com/Computer_Interface/USB_to_Serial_Adapter ? Actually, I was thinking of something that was the exact opposite: some device (which I don't think exists) that would allow one to connect a USB flash drive to the device, and have the device convert that into RS232 serial data for the computer, thus avoiding any USB interaction with the computer itself. The computer would then need to process the serial data to read or write files on the drive. As far as I know, nothing like that exists and I'm not sure if it'd be possible to do. Even if it was possible, it'd be immensely slower than normal USB connections. My thought was that since serial is older and simpler than USB that it would be possible to better audit and secure the connection between the flash drive and the computer using such a method. My idea was derived from one of the ways CAcert keeps their root certificate secure: the signing system is kept offline, but is connected via a serial cable to an online computer (e.g. the web server). The simple daemon that listens on the serial port of the signing system will only respond to requests for signing things but they did not implement any file-transfer-over-serial functionality so it would (presumably) be impossible to compromise the root certificate remotely. My idea would be for something similar, but with file-transfer capability over serial. The device you linked to, which is quite common, is the opposite: one can connect a serial device (say a microcontroller, a UPS, etc.) to the device, which converts it to USB and transmits that data to the computer. The device appears as a serial port on the computer. In brief, the device you linked to tunnels serial-over-USB. My thought was to do filesystem-access-over-serial. Mine is probably a very silly idea and I was basically throwing the idea at the wall to see if it'd stick. :) -- Pete Stephenson From s-y-l at gmx.net Wed Sep 11 11:27:39 2013 From: s-y-l at gmx.net (Maik Holtkamp) Date: Wed, 11 Sep 2013 11:27:39 +0200 Subject: message digest for signed emails In-Reply-To: <522F6689.10606@fifthhorseman.net> References: <013101ceae27$582e4cf0$088ae6d0$@gmx.com> <522F33C2.8050002@fifthhorseman.net> <000901ceae52$cb8fbff0$62af3fd0$@gmx.com> <522F6689.10606@fifthhorseman.net> Message-ID: <20130911092739.GA11074@work.holtkamp.priv> Hi, 0n 13/09/10 at 14:35 Daniel Kahn Gillmor told me: > On 09/10/2013 02:23 PM, Adam Gold wrote: > > > 'source ~/.mutt/gpg.rc' to the mutt config file. I also added > > sorry, i don't know much about mutt or how it integrates with gpg. > maybe someone else on the list can help you with that, or you IMHO mutt is just using gpg's CLI to sign the message. You should have a look at the command line set in pgp_sign_command (from .mutt/gpgrc). If you paste that commad on the prompt you will get the very same type of sigs mutt is using. - maik -- DISCLAIMER: If you have received this e-mail unintended, it's the senders fault. Since he sent the message unencryted trough untrusted networks, you are entitled to read or publish the content or simply delete and forget about it. From kabads at gmail.com Wed Sep 11 14:56:10 2013 From: kabads at gmail.com (AdamC) Date: Wed, 11 Sep 2013 13:56:10 +0100 Subject: Upgrading keys to larger than 1024 In-Reply-To: <522F651F.8050407@fifthhorseman.net> References: <522F651F.8050407@fifthhorseman.net> Message-ID: Thanks everyone - I will try contacting the people who have signed my keys by email and see what they say - I very rarely see them in real life. Regards, Adam On 10 September 2013 19:29, Daniel Kahn Gillmor wrote: > On 09/10/2013 12:47 PM, AdamC wrote: > > I have keys that I have used (sparingly) since 2004. This is a 1024 > > keysize. That keypair has a few signatures through key signing. > > > > What is the best approach to upgrading keys to 4096? Is it just create a > > new keypair and then go to lots of key signing events again (pain), or is > > there a way to do this with my current keys? > > There's no way to directly upgrade if your primary key is weaker than > you'd like. > > You should create a new keypair and go out in the world and meet people > who will sign your key. it doesn't have to be a pain :) > > Ana wrote up some good suggestions about how to do a key transition: > > http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/ > > Regards, > > --dkg > > -- -- You back your data up on the same planet? http://www.monkeez.org PGP key: 0x7111B833 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Sep 11 16:07:30 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Sep 2013 10:07:30 -0400 Subject: --list-options show-notations does not work with --with-colons Message-ID: <87eh8vmoyl.fsf@alice.fifthhorseman.net> I'm trying to programmatically look at the notations in all the self-sigs in an OpenPGP certificate. But: gpg --fingerprint --fingerprint --fixed-list-mode --list-options show-notations --with-colons --check-sigs "$fpr" does not show me the notations. if i omit --with-colons, then i get the notations in human-readable form, but i don't want to try to parse that. Should i be able to see the notations when using --with-colons somehow? --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 Wed Sep 11 17:56:07 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 11 Sep 2013 17:56:07 +0200 Subject: --list-options show-notations does not work with --with-colons In-Reply-To: <87eh8vmoyl.fsf@alice.fifthhorseman.net> References: <87eh8vmoyl.fsf@alice.fifthhorseman.net> Message-ID: <5110914.r4GZdB49ym@inno.berlin.laging.de> Am Mi 11.09.2013, 10:07:30 schrieb Daniel Kahn Gillmor: > Should i be able to see the notations when using --with-colons somehow? show-sig-subpackets is your friend. -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Wed Sep 11 18:38:45 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Sep 2013 12:38:45 -0400 Subject: --list-options show-notations does not work with --with-colons In-Reply-To: <5110914.r4GZdB49ym@inno.berlin.laging.de> References: <87eh8vmoyl.fsf@alice.fifthhorseman.net> <5110914.r4GZdB49ym@inno.berlin.laging.de> Message-ID: <52309C95.8070608@fifthhorseman.net> On 09/11/2013 11:56 AM, Hauke Laging wrote: > Am Mi 11.09.2013, 10:07:30 schrieb Daniel Kahn Gillmor: > >> Should i be able to see the notations when using --with-colons somehow? > > show-sig-subpackets is your friend. Thanks, that does produce a tremendous amount of info, and within it i can find the subpacket i'm interested in (though now i'll have to write another sub-parser just for that line). should we note in the documentation that show-notations doesn't work in --with-colons mode? or would folks be interested in a patch to support it? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 746 bytes Desc: OpenPGP digital signature URL: From a at foo.be Wed Sep 11 13:46:31 2013 From: a at foo.be (Alexandre Dulaunoy) Date: Wed, 11 Sep 2013 13:46:31 +0200 Subject: Support for additional ECC Curves in GnuPG (gcrypt) Message-ID: Hi Everyone, Do you know if someone is currently working to implement additional curves in ECC and especially to have an alternative to the NIST ones in gcrypt/GnuPG? and I was wondering if we are bound to the ones defined in: http://tools.ietf.org/html/rfc6637#section-11 Thank you, Cheers. -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov From philip at foolip.org Wed Sep 11 23:42:30 2013 From: philip at foolip.org (Philip =?ISO-8859-1?Q?J=E4genstedt?=) Date: Wed, 11 Sep 2013 23:42:30 +0200 Subject: Is it possible to remove capabilities from an existing key? Message-ID: <1378935750.9888.15.camel@dax> My public key has the default capabilities sign and certify. I've seen that some people have only the certify capability in order to be able to keep the main key offline most of the time. Is it technically possible to change the capabilities of an existing key, even if there's no way to do it via --edit-key? If it's not possible, what would be the consequence of adding a subkey with the sign capability, which key would be used when both are available? Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From jack at jack-brennan.com Wed Sep 11 22:46:21 2013 From: jack at jack-brennan.com (Jack Brennan) Date: Wed, 11 Sep 2013 22:46:21 +0200 Subject: Confirmation of cipher? Message-ID: <5230D69D.5090704@jack-brennan.com> Hello, When one signs a message GnuGPG will add "Hash:SHA1" or your preferred hash at the start of the message. However a similar line of text isn't available with an encrypted text block. Is the reason for this to hide as much information as possible from a possible attacker? Is there any way to confidently identify the encryption algorithm used with a GPG encrypted text block? Many thanks Jack Brennan. From dkg at fifthhorseman.net Thu Sep 12 00:07:14 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Sep 2013 18:07:14 -0400 Subject: Is it possible to remove capabilities from an existing key? In-Reply-To: <1378935750.9888.15.camel@dax> References: <1378935750.9888.15.camel@dax> Message-ID: <5230E992.4000009@fifthhorseman.net> On 09/11/2013 05:42 PM, Philip J?genstedt wrote: > My public key has the default capabilities sign and certify. I've seen > that some people have only the certify capability in order to be able to > keep the main key offline most of the time. > > Is it technically possible to change the capabilities of an existing > key, even if there's no way to do it via --edit-key? > > If it's not possible, what would be the consequence of adding a subkey > with the sign capability, which key would be used when both are > available? i believe GnuPG uses the most-recently-updated subkey that it believes to have signing capability, unless you force the subkey in question via --local-user or --default-key with a ! suffix (see the "By key Id." section in gpg(1)). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Thu Sep 12 00:16:45 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Sep 2013 00:16:45 +0200 Subject: Is it possible to remove capabilities from an existing key? In-Reply-To: <1378935750.9888.15.camel@dax> References: <1378935750.9888.15.camel@dax> Message-ID: <10530064.p44fFTiiFl@inno.berlin.laging.de> Am Mi 11.09.2013, 23:42:30 schrieb Philip J?genstedt: > My public key has the default capabilities sign and certify. I've seen > that some people have only the certify capability in order to be able to > keep the main key offline most of the time. It's of limited use to make a former online mainkey an offline mainkey. You should create a completely new key (on a secure system). > Is it technically possible to change the capabilities of an existing > key, even if there's no way to do it via --edit-key? May be possible (it surely would be with patching GnuPG) but is not necessary. It makes perfect sense to have signing (and even encryption) capability on an offline mainkey. > If it's not possible, what would be the consequence of adding a subkey > with the sign capability, which key would be used when both are > available? If there is a subkey then it is used always. I do not know though whether this is a direct effect (defined that way) or an indirect one: The creation date (and the selfsig date) of a subkey should always be after the creation date of the mainkey. 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 newton at hammet.net Thu Sep 12 05:43:45 2013 From: newton at hammet.net (Newton Hammet) Date: Wed, 11 Sep 2013 22:43:45 -0500 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: References: Message-ID: <52313871.90109@hammet.net> Hello Everyone, I dutifully did ./configure, make, sudo make install for gunupg-2.0.21 after finally doing same for all its dependencies and then ran /usr/local/lib/gpg2 --expert --gen-key and all I got was this: newton at newton-desktop:~/gpg2_0_21/gnupg-2.0.21$ /usr/local/bin/gpg2 --expert --gen-key gpg (GnuPG) 2.0.21; 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. 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) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection? ^C gpg: signal Interrupt caught ... exiting Shouldn't I be seeing 1 or more ECC choices? Was I supposed to supply some special arguments to ./configure ? Thanks, Newton From dkg at fifthhorseman.net Thu Sep 12 07:35:33 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Sep 2013 01:35:33 -0400 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <52313871.90109@hammet.net> References: <52313871.90109@hammet.net> Message-ID: <523152A5.3050704@fifthhorseman.net> On 09/11/2013 11:43 PM, Newton Hammet wrote: > Shouldn't I be seeing 1 or more ECC choices? GnuPG 2.1 (still currently in beta, afaict) is the first version to include ECC support for OpenPGP. the 2.0.x branch does not include ECC for OpenPGP. 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 ndk.clanbo at gmail.com Thu Sep 12 08:43:44 2013 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 12 Sep 2013 08:43:44 +0200 Subject: Why trust gpg4win? In-Reply-To: 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> Message-ID: <523162A0.90201@gmail.com> Il 11/09/2013 11:48, Pete Stephenson ha scritto: > Actually, I was thinking of something that was the exact opposite: > some device (which I don't think exists) that would allow one to > connect a USB flash drive to the device, and have the device convert > that into RS232 serial data for the computer, thus avoiding any USB > interaction with the computer itself. The computer would then need to > process the serial data to read or write files on the drive. As far as > I know, nothing like that exists and I'm not sure if it'd be possible > to do. Even if it was possible, it'd be immensely slower than normal > USB connections. Actually such a module exists, and is used to add flash disk access to small microcontrollers: it's VDrive2 (VNC1L module) by Vinculum http://www.ftdichip.com/Documents/DataSheets/Modules/DS_VDRIVE2.pdf I don't think it adds anything to security, but at least it's doable :) If you are *so* concerned about key security, it's better to use an HSM. BYtE, Diego. From wk at gnupg.org Thu Sep 12 09:17:16 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Sep 2013 09:17:16 +0200 Subject: message digest for signed emails In-Reply-To: <20130911092739.GA11074@work.holtkamp.priv> (Maik Holtkamp's message of "Wed, 11 Sep 2013 11:27:39 +0200") References: <013101ceae27$582e4cf0$088ae6d0$@gmx.com> <522F33C2.8050002@fifthhorseman.net> <000901ceae52$cb8fbff0$62af3fd0$@gmx.com> <522F6689.10606@fifthhorseman.net> <20130911092739.GA11074@work.holtkamp.priv> Message-ID: <8761u64igz.fsf@vigenere.g10code.de> On Wed, 11 Sep 2013 11:27, s-y-l at gmx.net said: > IMHO mutt is just using gpg's CLI to sign the message. Depends on whether you use set crypt_use_gpgme Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Sep 12 12:48:49 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Sep 2013 12:48:49 +0200 Subject: Confirmation of cipher? In-Reply-To: <5230D69D.5090704@jack-brennan.com> (Jack Brennan's message of "Wed, 11 Sep 2013 22:46:21 +0200") References: <5230D69D.5090704@jack-brennan.com> Message-ID: <87r4cu2u3y.fsf@vigenere.g10code.de> On Wed, 11 Sep 2013 22:46, jack at jack-brennan.com said: > When one signs a message GnuGPG will add "Hash:SHA1" or your preferred > hash at the start of the message. Only if you use --clearsign. This is here required so that we can implement one pass verification. We need to know in advance which hash algorithm is used. Thus this header line. Now when it comes to the signature block, the same information is there and gpg cross-checks that they match (it is a bit more complicated in reality, though). > However a similar line of text isn't available with an encrypted text > block. Is the reason for this to hide as much We sign and the encrypt. Thus the hashing algorithm for the signature is only available after decryption. > Is there any way to confidently identify the encryption algorithm used > with a GPG encrypted text block? Yes. For a quick inspection use --verbose (or -v): $ fortune | gpg2 -er alpha --always-trust 2>/dev/null| gpg2 -v [...] gpg: encrypted with 1024-bit ELG key, ID DB2405A5, created 1998-09-30 "Heinrich Heine (alpha test key)" gpg: using subkey C193565B instead of primary key 1E42B367 gpg: encrypted with 2048-bit RSA key, ID C193565B, created 2011-11-07 "Werner Koch " gpg: 3DES encrypted data gpg: original file name='' He was part of my dream, of course -- but then I was part of his dream too. -- Lewis Carroll For scripting etc use --status-fd: $ fortune | gpg2 -er alpha --always-trust 2>/dev/null| gpg2 --status-fd 2 [...] [GNUPG:] ENC_TO F7849FD4DB2405A5 16 0 [GNUPG:] ENC_TO DF7B7722C193565B 1 0 gpg: encrypted with 1024-bit ELG key, ID DB2405A5, created 1998-09-30 "Heinrich Heine (alpha test key)" [GNUPG:] NO_SECKEY F7849FD4DB2405A5 gpg: encrypted with 2048-bit RSA key, ID C193565B, created 2011-11-07 "Werner Koch " [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_INFO 0 2 [GNUPG:] PLAINTEXT 62 1378982325 [GNUPG:] PLAINTEXT_LENGTH 96 Q: What's the difference between a duck and an elephant? A: You can't get down off an elephant. [GNUPG:] DECRYPTION_OKAY gpg: WARNING: message was not integrity protected [GNUPG:] END_DECRYPTION Here the status line [GNUPG:] DECRYPTION_INFO 0 2 returns the info about the used symmetric algorithm: DECRYPTION_INFO Print information about the symmetric encryption algorithm and the MDC method. This will be emitted even if the decryption fails. Thus is our case we don't use an MDC (this is becuase the alpha test key is very old and does not have a preference for this. The symmetric encryption algorithnm is 2 which is the OpenPGP id for TripeDES. Note, that GPGME has currently no way to return that info. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From free10pro at gmail.com Thu Sep 12 14:02:08 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Thu, 12 Sep 2013 05:02:08 -0700 Subject: Decrypt Issue In-Reply-To: References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> <522B98F4.6080108@gmail.com> <30e043faf8154cfcab7f4a63ba84b8dc@MBX03.azdes.gov> <3feb006e-b5c3-4b70-88c0-224136a3ced5@email.android.com> Message-ID: <5231AD40.6000905@gmail.com> On 09/10/2013 06:41 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 [snip] You need to determine which user account and system that you are running the script from and which account and system that gpg is running under. It is mostly likely gpg is running under the wrong user or system. Determine where the secret key that you are using is located (i.e. which directory holds the GnuPG home directory). And If you can edit the script, make it print out the value of the GNUPGHOME environment variable and compare that against what the correct home directory is supposed to be. Hope that helps. Cheers, --Paul From philip at foolip.org Thu Sep 12 14:53:29 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Thu, 12 Sep 2013 14:53:29 +0200 Subject: Is it possible to remove capabilities from an existing key? In-Reply-To: <10530064.p44fFTiiFl@inno.berlin.laging.de> References: <1378935750.9888.15.camel@dax> <10530064.p44fFTiiFl@inno.berlin.laging.de> Message-ID: On Thu, Sep 12, 2013 at 12:16 AM, Hauke Laging wrote: > Am Mi 11.09.2013, 23:42:30 schrieb Philip J?genstedt: >> My public key has the default capabilities sign and certify. I've seen >> that some people have only the certify capability in order to be able to >> keep the main key offline most of the time. > > It's of limited use to make a former online mainkey an offline mainkey. You > should create a completely new key (on a secure system). Certainly, I can't take the master key offline and then pretend it has never seen a computer with a network connection. I could have used other terminology, what I'm actually considering is how to remove the private master key from my laptop, so that if it's lost/stolen I only need to revoke the subkeys. >> Is it technically possible to change the capabilities of an existing >> key, even if there's no way to do it via --edit-key? > > May be possible (it surely would be with patching GnuPG) but is not necessary. > It makes perfect sense to have signing (and even encryption) capability on an > offline mainkey. > >> If it's not possible, what would be the consequence of adding a subkey >> with the sign capability, which key would be used when both are >> available? > > If there is a subkey then it is used always. I do not know though whether this > is a direct effect (defined that way) or an indirect one: The creation date > (and the selfsig date) of a subkey should always be after the creation date of > the mainkey. On Thu, Sep 12, 2013 at 12:07 AM, Daniel Kahn Gillmor wrote: > > i believe GnuPG uses the most-recently-updated subkey that it believes > to have signing capability, unless you force the subkey in question via > --local-user or --default-key with a ! suffix (see the "By key Id." > section in gpg(1)). You're both right, I've tested simply adding a subkey with the sign capability, and that's the one that gpg used, even with the master key available. In other words, it's perfectly possible to do what I wanted without modifying the existing keys. -- Philip J?genstedt From mailinglisten at hauke-laging.de Thu Sep 12 15:07:39 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Sep 2013 15:07:39 +0200 Subject: Is it possible to remove capabilities from an existing key? In-Reply-To: References: <1378935750.9888.15.camel@dax> <10530064.p44fFTiiFl@inno.berlin.laging.de> Message-ID: <2151783.IE57xzL61D@inno.berlin.laging.de> Am Do 12.09.2013, 14:53:29 schrieb Philip J?genstedt: > what I'm actually considering is how to remove the > private master key from my laptop, so that if it's lost/stolen I only > need to revoke the subkeys. gpg --armor --export-secret-keys "$mykeyid" > key.secret-mainkey.asc gpg --armor --export-secret-subkeys "$mykeyid" > key.secret-subkeys.asc gpg --delete-secret-key "$mykeyid" gpg --import key.secret-subkeys.asc 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 takethebus at gmx.de Thu Sep 12 15:55:24 2013 From: takethebus at gmx.de (Jan) Date: Thu, 12 Sep 2013 15:55:24 +0200 Subject: Why trust gpg4win? 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> Message-ID: <4F31488109504931BE75B82817DF467D@neinpc> Hello everybody, thank you for the many answers. Actually this thread should have been called "Save use of gnuPG for everybody". From what I've learned here so far I come to the following conclusions: 1. It should be to hard for the average user to configure windows such that it is a secure system. Hence a linux/unix distribution which is trustworthy, easy to use and very secure is needed. To me debian seems like a good choice because it seems to be watched by many people and runs on almost any PC. 2.1 Most people have only one PC and windows as operating system, so the linux/unix distribution should be installed on an USB device. This device must not be plugged into the PC if windows is running, in order to avoid a manipulation. Further I would uninstall the network drivers on the USB device, so it is almost an offline PC. If the user receives an encrypted file via email, he saves it to hard disk. Then he turns off the PC, plugs in the USB drive and boots off it. He copies the file from the hard disk to the USB drive (this should cause no trouble). Only if the file is of a simple file format (jpg, RTF, mp3, PDF(?), etc.(?)) he accepts it and opens it with a secure minimalistic tool. He might even first run a program like an anti virus software(?) in order to check whether the structure of the file agrees with the official definition of the sated file format. 2.2 If the user has two PCs, he might install the linux/unix distribution on his offline PC. Files would be transferred between the two PCs by means of CD-RWs(?), not by means of insecure USB devices. Auto-Play for CDs would be disabled. Do you see any reasonable attack vectors? What do you think? Kind regards, Jan ----- Original Message ----- From: "NdK" To: Sent: Thursday, September 12, 2013 8:43 AM Subject: Re: Why trust gpg4win? > Il 11/09/2013 11:48, Pete Stephenson ha scritto: > >> Actually, I was thinking of something that was the exact opposite: >> some device (which I don't think exists) that would allow one to >> connect a USB flash drive to the device, and have the device convert >> that into RS232 serial data for the computer, thus avoiding any USB >> interaction with the computer itself. The computer would then need to >> process the serial data to read or write files on the drive. As far as >> I know, nothing like that exists and I'm not sure if it'd be possible >> to do. Even if it was possible, it'd be immensely slower than normal >> USB connections. > Actually such a module exists, and is used to add flash disk access to > small microcontrollers: it's VDrive2 (VNC1L module) by Vinculum > http://www.ftdichip.com/Documents/DataSheets/Modules/DS_VDRIVE2.pdf > > I don't think it adds anything to security, but at least it's doable :) > > If you are *so* concerned about key security, it's better to use an HSM. > > BYtE, > Diego. > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From mailinglisten at hauke-laging.de Thu Sep 12 16:29:31 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 12 Sep 2013 16:29:31 +0200 Subject: OpenPGP presence on the web Message-ID: <2750826.DuOtoLCFoz@inno.berlin.laging.de> Hello, I'd like to motivate you to do something (at least passively) I have started doing: There are some (both private and commercial) web sites which have a statement and link like this on their contact page: "And here you can download my PGP key." Most of them (at least of the German ones) do not contain any information about OpenPGP though. Neither as text nor as links. This doesn't make sense. Thus I have started searching such pages and asking their webmasters (who are usually interested in more people using OpenPGP) to add links to both informative sites and such with teaching events (this, of course, is probably much easier in Germany than elsewhere with the Cryptoparty movement having taken off that stongly here). A relevant share of them does that. (The immoral part is, of course, that I give them two example links, one of them to my site ;-) ) This way we both get more people (who have not searched for them) to good OpenPGP resources and improve the search engine ranking of them (which helps those who actively search for information). Thus: Write a short text for such cases so that you can just C&P it if you happen to encounter such a page. And if you spend some time searching for such pages ? even better. Below you find my (German) text. Feel free to copy or change it. Hauke ########################################################### Dein Beitrag zur h?heren Verbreitung von OpenPGP Moin, es ist l?blich, dass Du auf Deiner Kontaktseite darauf hinweist, dass man die Kommunikation mit Dir ?ber OpenPGP sichern kann. Es sollte deshalb in Deinem Interesse liegen, dass sehr viel mehr Leute als bisher sich diese Technik aneignen. Du kannst mit vernachl?ssigbarem Aufwand einen dauerhaften Beitrag dazu leisten: Erg?nze den Verweis auf Dein OpenPGP-Zertifikat um einen oder mehrere Links auf Seiten, die sich als Anlaufstelle f?r Leute eignen, die nicht wissen, was das ist. F?r solche Leute sind nicht nur reine Informationsseiten n?tzlich, sondern auch solche von Schulungsangeboten, insbesondere den kostenlosen der Cryptoparty-Bewegung. Linkbeispiele: Informationen: http://www.openpgp-schulungen.de/fuer/alle/ Schulungsangebote: https://www.cryptoparty.in/location#germany Weitere Anregungen, wie Du mit mehr oder weniger Aufwand OpenPGP unterst?tzen kannst, findest Du hier: http://www.openpgp-schulungen.de/fuer/unterstuetzer-personen/ Wenn Du diesen Vorschlag aufgreifst, freue ich mich ?ber eine entsprechende R?ckmeldung. Auch f?r eine Diskussion dieser Problematik stehe ich nat?rlich gern zur Verf?gung. CU Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/bekannte/ OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From peter at digitalbrains.com Thu Sep 12 19:07:07 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 12 Sep 2013 19:07:07 +0200 Subject: Attacking an offline system (was: Why trust gpg4win?) In-Reply-To: <4F31488109504931BE75B82817DF467D@neinpc> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> Message-ID: <5231F4BB.20505@digitalbrains.com> On 12/09/13 15:55, Jan wrote: > Do you see any reasonable attack vectors? What do you think? The moment someone plugs in a mass storage device and we're talking about attacking his computer, I think of a manipulated file system, exploiting an error in the file system driver of the kernel (which runs at a nice privilege level too). I missed that vector in the discussion so far, which focussed on manipulated files. The filesystem is also still there with this USB-via-serial-port thingy. And on the CD. You can avoid a filesystem by just storing a tar archive on the storage. I don't think that's very helpful under Windows, but under Linux, using a block device as tar input/output is easy. Hell, it's what tar was originally made for (tape devices) :). That only helps for the filesystem vector, though. Anybody still using laplink cables? ;) (I once blew up part of a mainboard with a laplink cable. Was on a different phase of the mains electricity than the other PC and not grounded. Gave a nice spark.) 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 ndk.clanbo at gmail.com Thu Sep 12 22:03:27 2013 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 12 Sep 2013 22:03:27 +0200 Subject: Attacking an offline system In-Reply-To: <5231F4BB.20505@digitalbrains.com> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <5231F4BB.20505@digitalbrains.com> Message-ID: <52321E0F.5030507@gmail.com> Il 12/09/2013 19:07, Peter Lebbing ha scritto: > The filesystem is also still there with this USB-via-serial-port thingy. And on > the CD. Nope. W/ Vinculum module you send it commands like "open mickey.txt" and then "read 1024". The filesystem driver is in the module and your interface only receives expected data. You really should define your "security perimeter". Start by asking yourself how much an attacker is willing to spend to access the data you're handling. Once you have an answer to this question you can choose how much you are willing to spend to defend your data. Plain old password protecting a file is usually enough. FST-01 token could be useful to have your key easily portable and (w/ a little work) even add a button to confirm signing. Smartcards are another good alternative if you need some "certification". An HSM is much less portable but needed if you need both certification and speed. And this just to keep your keys safe. Keeping the whole system safe is a careful compromise between functionality and security. But all depends on the answer to the first question. But rubberhose cryptoanalysis is usually *way* more effective :) BYtE, Diego. From markoran at eunet.rs Thu Sep 12 23:10:51 2013 From: markoran at eunet.rs (Marko Randjelovic) Date: Thu, 12 Sep 2013 23:10:51 +0200 Subject: Why trust gpg4win? In-Reply-To: <4F31488109504931BE75B82817DF467D@neinpc> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> Message-ID: <20130912231051.446b02db@eunet.rs> On Thu, 12 Sep 2013 15:55:24 +0200 "Jan" wrote: > 2.1 Most people have only one PC and windows as operating system, so > the linux/unix distribution should be installed on an USB device. > This device must not be plugged into the PC if windows is running, in > order to avoid a manipulation. Further I would uninstall the network > drivers on the USB device, so it is almost an offline PC. If the user > receives an encrypted file via email, he saves it to hard disk. Then > he turns off the PC, plugs in the USB drive and boots off it. He > copies the file from the hard disk to the USB drive (this should > cause no trouble). Only if the file is of a simple file format (jpg, > RTF, mp3, PDF(?), etc.(?)) he accepts it and opens it with a secure > minimalistic tool. He might even first run a program like an anti > virus software(?) in order to check whether the structure of the file > agrees with the official definition of the sated file format. All the time I read suggestions on using USB sticks and I must say people are crazy about USB sticks. It is more convenient to use optical media then USB stick because they are read only. Boot from Live CD, not from USB stick and use USB stick only for data. In a desktop PC you can put two CD devices and boot Live CD from CD1 and write your data to CD2. You can use write-once media or rewritable media so you do not waste to much plastic. If you write your data to CDROM, then it is much more safer to transfer data to another PC. It is much more complicated to make a virus that will insert itself into a CDROM then into a USB stick. Furthermore, such action would be odd and could be blocked by a security software like SELinux. -- Marko Ran?elovi?, B.Sc. Software Developer Ni?, Serbia markoran at eunet.rs Note: If you see a nonsense enclosed between lines BEGIN PGP SIGNATURE END PGP SIGNATURE then this message is digitally signed using OpenPGP compliant software. You need an appropriate plugin for your email client or other OpenPGP compliant software in order to verify the signature. However, the concept of computer insecurity implies digital signature is not absolute proof of identity. From dkg at fifthhorseman.net Fri Sep 13 01:22:13 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Sep 2013 19:22:13 -0400 Subject: lsign produces exportable signatures when used for self-sigs Message-ID: <878uz1mxqy.fsf@alice.fifthhorseman.net> GnuPG is currently not able to create a non-exportable self-sig. If you try to do this, it gives an error: WARNING: the signature will not be marked as non-exportable. But: some people might never want their keys to be published to the public keyservers, or have some User IDs that they keep locally that they do not want to be transmitted via the keyserver network. AIUI, keyservers should reject keys that do not have a self-signature. Keyservers should also honor the "non-exportable" marker by rejecting OpenPGP certification packets that have the "exportable" subpacket included and set to 0. So the sensible thing for a keyholder who wants their key to stay off the keyservers would be to issue a non-exportable self-signature. The attached patch (against the 1.4.x branch, since that's what i'm in a good position to test) allows a user comfortable with --expert mode to add a non-exportable self-sig. so the creation of such a key is possible with: --gen-key --expert --edit-key uid 1 # select uids that you do not want distributed lsign delsig # remove all signatures not marked non-exportable this obviously isn't a great workflow, but with this patch it is at least possible. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: enable-non-exportable-selfsigs.patch Type: text/x-diff Size: 5219 bytes Desc: enable non-exportable self-sigs (against GnuPG's STABLE-BRANCH-1-4) URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From dougb at dougbarton.us Fri Sep 13 05:08:24 2013 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 12 Sep 2013 20:08:24 -0700 Subject: message digest for signed emails In-Reply-To: <8761u64igz.fsf@vigenere.g10code.de> References: <013101ceae27$582e4cf0$088ae6d0$@gmx.com> <522F33C2.8050002@fifthhorseman.net> <000901ceae52$cb8fbff0$62af3fd0$@gmx.com> <522F6689.10606@fifthhorseman.net> <20130911092739.GA11074@work.holtkamp.priv> <8761u64igz.fsf@vigenere.g10code.de> Message-ID: <523281A8.5080802@dougbarton.us> For the OP, try with and without spaces around the = sign as well. I have heard reports that can make a difference. So try all of the following: name at exaxmple.com = key1 key2 key3 = key1 key2 key3 name at exaxmple.com=key1 key2 key3 =key1 key2 key3 hth, Doug From wk at gnupg.org Fri Sep 13 08:52:47 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Sep 2013 08:52:47 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <523152A5.3050704@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 12 Sep 2013 01:35:33 -0400") References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> Message-ID: <87fvt92oxs.fsf@vigenere.g10code.de> On Thu, 12 Sep 2013 07:35, dkg at fifthhorseman.net said: > GnuPG 2.1 (still currently in beta, afaict) is the first version to > include ECC support for OpenPGP. the 2.0.x branch does not include ECC Right. There are no plans to support it in older versions. 2.1 also has a feature to work without the pinentry, which should mitigate most concerns about switching to GnuPG-2. However, if at some time ECC would really take off, we might backport it to 1.4 if we could agree to change 1.4 to make use of Libgcrypt. The ECC support is actually ready for use but in the light of the recent news it might make sense to change the default curves. Fortunately I insisted during the specification phase that the format allows OIDs to specify the curve and not just the few Suite-B curves. The easiest way to switch to different curves would be the use of the somewhat slower Brainpool curves: We have already full support in Libgcrypt for them, thus changing it in GnuPG would be easy (it is mainly the key generation menu which maps desired key lengths to a curve). There are two other developments which should be considered: - Andrey is working on a more compact representation of keys and signatures which don't violate the compression patent (which anyway expires mid next year). - I am thinking to switch to Curve25519 based algorithms. They have been developed by Dan Bernstein et al. and are considered a sound design. I am currently working on the implementation of the signature scheme in Libgcrypt. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ndk.clanbo at gmail.com Fri Sep 13 09:19:10 2013 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 13 Sep 2013 09:19:10 +0200 Subject: Why trust gpg4win? In-Reply-To: <20130912231051.446b02db@eunet.rs> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <20130912231051.446b02db@eunet.rs> Message-ID: <5232BC6E.2090009@gmail.com> Il 12/09/2013 23:10, Marko Randjelovic ha scritto: > All the time I read suggestions on using USB sticks and I must say > people are crazy about USB sticks. It is more convenient to use optical > media then USB stick because they are read only. Boot from Live CD, not > from USB stick and use USB stick only for data. In a desktop PC you can > put two CD devices and boot Live CD from CD1 and write your data to > CD2. You can use write-once media or rewritable media so you do not > waste to much plastic. It's just a matter of trust (and speed). After all, you need to take the system image from "somewhere". That's probably the weakest link. Or, at least, it's the easiest to compromise. PS: I'll tell you a secret: there are USB keys with a "write protect" switch :) > If you write your data to CDROM, then it is much more safer to transfer > data to another PC. It is much more complicated to make a virus that > will insert itself into a CDROM then into a USB stick. Furthermore, > such action would be odd and could be blocked by a security software > like SELinux. And maybe there's a buffer overflow in the ISO9660 driver that can be exploited . Hey, we're talking of the most tested codepaths (unless you use some exotic filesystem)! Maybe technical solutions for a social problem aren't always the right answer? You can *never* be 100% sure. No way. You can be "reasonably sure". You can be "certifiably sure" (given that you define which kind of attacks you think you'll be exposed to and find a standard to certify against). I can be "reasonably sure" nobody will hack my machine just to read my mail. Obama can be "reasonably sure" that *many* attackers will try. So my scenario and Obama's one are "a bit" different, and require *greatly* different solutions. I can't afford the costs and inconveniences of a solution based on Obama's needs (and I'd be indeed quite stupid to try to adopt it), and he can't afford the risk of a solution tailored on mine. PPS: at least here in Italy a *completely offline machine* becomes illegal after 6 months. Law dictates that every computer where personal data is handled (and even a name and surname *is* "personal data") *must* be updated *at least* every 6 months. And attacking your update medium is probably easier than attacking the USB key. BYtE, Diego. From peter at digitalbrains.com Fri Sep 13 11:08:16 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 13 Sep 2013 11:08:16 +0200 Subject: Attacking an offline system In-Reply-To: <52321E0F.5030507@gmail.com> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <5231F4BB.20505@digitalbrains.com> <52321E0F.5030507@gmail.com> Message-ID: <5232D600.8070107@digitalbrains.com> On 12/09/13 22:03, NdK wrote: > Nope. W/ Vinculum module you send it commands like "open mickey.txt" and > then "read 1024". The filesystem driver is in the module and your interface > only receives expected data. I hadn't looked at the Vinculum module[1]; that would indeed be a way to remove the filesystem from the equation, although you will end up writing something similar to a filesystem driver for the PC which might itself be exploitable. You can reduce the complexity of the software, but you can't eliminate some form of driver. And I certainly wouldn't trust the module to give me only expected data :). You've only moved the complexity of the USB stack to the module, it needs to be regarded exploitable. > You really should define your "security perimeter". You mean threat model? I completely agree. All my contributions are just musings about things I notice while reading other people's contributions. I'm not contemplating actually doing any of this. If you seriously consider doing this, you need to formulate a good threat model. I use a USB stick to transfer stuff. HTH, Peter. [1] I was just thinking in general terms of bridging USB mass storage to a serial port through some driver. -- 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 Sep 13 11:11:51 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 13 Sep 2013 11:11:51 +0200 Subject: Why trust gpg4win? In-Reply-To: <5232BC6E.2090009@gmail.com> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <20130912231051.446b02db@eunet.rs> <5232BC6E.2090009@gmail.com> Message-ID: <5232D6D7.4020706@digitalbrains.com> On 13/09/13 09:19, NdK wrote: > PS: I'll tell you a secret: there are USB keys with a "write protect" > switch :) Since people were concerned about hacking the USB key, you need to define the scenario. First of all, if we are talking about hacking through a rogue firmware update for the USB key: is the write protect switch directly connected to the "Write enable" line of the flash chip or is it done in the firmware? In the latter case, it's useless. In the former case: the flash chip is reasonably intelligent, and "closed source". There could be an exploit to write to it even when the "Write enable" line is not asserted. If we're talking about hacking the USB key by getting your hands on it and physically altering it, I don't even need to explain. Although if you keep the stick next to your offline PC, the attacker will probably not bother with the stick ;). So it really depends on your threat model if that switch is useful. > And attacking your update medium is probably easier than attacking the USB > key. I think in my case, the only difference is the added possibility of attacking the package manager. I put a debian mirror on an external hard disk, connect that to my offline PC and then update the system. I think it would be difficult to remove the package manager from the equation, unless you switch distro's :). 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 takethebus at gmx.de Fri Sep 13 11:33:44 2013 From: takethebus at gmx.de (Jan) Date: Fri, 13 Sep 2013 11:33:44 +0200 Subject: Why trust gpg4win? 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <20130912231051.446b02db@eunet.rs> <5232BC6E.2090009@gmail.com> Message-ID: 09/12/2013 22:03, NdK wrote: > You really should define your "security perimeter". 09/13/2013 09:19, NdK wrote: > I can be "reasonably sure" nobody will hack my machine just to read my > mail. Obama can be "reasonably sure" that *many* attackers will try. My "security perimeter" should be "equal" to the maximum of the "security perimeters" of my usual communication partners. That is so because with their private key they protect my mail and with my private key I protect their mail. What is "usual" is not always easy to determine. Lets say I'm looking for the maximum of security an average user can achieve with common hardware. This user is willing to do some inconvenient things like reboot, burn CDs or wait. Generally I distrust certain hardware like smartcards or HSMs because they are main targets for secret services, who have a lot of money. Recently I red about this intersting (English/German) article on FBI backdoors in openBSB and scmartcards: http://www.h-online.com/open/news/item/FBI-back-door-in-IPSec-implementation-of-OpenBSD-1153297.html http://www.heise.de/newsticker/meldung/FBI-Backdoor-in-IPSec-Implementierung-von-OpenBSD-1153180.html It should be possible to create a rather secure system using "norml technoligies" (CDs, offline PCs etc.) which are harder to target by secret services. If you manage to have a rather secure file transfer between an online and an offline PC, the only security relevant technology you need to focus on is gnuPG itself. Some people read the source code to check its integrity but are there people who focus on its output? To me this is a very important point. I'm not sure how this could be done in practice, but I was thinking about someone who knows the theory of RSA etc. and who "manually" encrypted a text and would compare that with the output of gnuPG to see whether the two results match. Some other approach might be to compare the output of several versions of gnuPG, PGP etc.. This way you could check whether the information was secretly decrypted with a second "FBI key". This is even possible for someone how is no programer. Do you think checking the output in that way is useful? Kind regards, Jan From Dave.Smith at st.com Fri Sep 13 12:50:15 2013 From: Dave.Smith at st.com (David Smith) Date: Fri, 13 Sep 2013 11:50:15 +0100 Subject: Why trust gpg4win? In-Reply-To: <30221243254A4BF9AC0FED95F22C7501@neinpc> 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> <5707B6141E374A519D00A6C238849EE5@neinpc> <522F2DC2.1090303@st.com> <30221243254A4BF9AC0FED95F22C7501@neinpc> Message-ID: <5232EDE7.8090607@st.com> On 09/10/13 21:42, Jan wrote: > 10/9/2013 14:19, Werner Koch wrote : >> So what about using that free USB stack for AVR's to implement a flash >> device? You would be able to audit about everything; flylogic even has >> these nice pictures of the ATmega88 masks... > > 10/9/2013 16:33, David Smith wrote: >> AVR is a semiconductor manufacturer who make microcontrollers (amongst >> other things). > > Thanks for the answers. Did you refer to the following? [snip] No. I work for a (different) semiconductor manufacturer (you can probably work out which one from my email address...). Actually, I wasn't quite correct - AVR is a brand of microcontrollers made by semiconductor manufacturer Atmel. They are used in the Arduino project among other things. > How could I implement a flash device? Do you mean I need to take some > existing USB device created by AVR and replace its firmware by LUFA or > something like that? Could I use that modified USB device on every PC or > operation system? To answer your questions in order... 1. You've answered this question in the second question 2. Yes. 3. Yes. If you get the microcontroller to tell the PC that it's a flash drive, then the PC will believe it and treat it as such. The USB spec (and sub-specs) define how a flash drive should "look" to the host (the PC), and provided the USB device behaves like this, the host will assume that it really is a flash drive. In reality, a lot of USB devices are built this way - the low-level USB hardware interface is implemented by dedicated hardware, but the higher-level parts (like defining what "sort" of device it is, and what to do with the data that is transferred) is encoded in firmware. In fact, it wouldn't surprise me if some USB flash drives are implemented this way. From johanw at vulcan.xs4all.nl Fri Sep 13 13:25:38 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 13 Sep 2013 13:25:38 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <87fvt92oxs.fsf@vigenere.g10code.de> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> Message-ID: <5232F632.7010401@vulcan.xs4all.nl> On 9/13/2013 8:52, Werner Koch wrote: > concerns about switching to GnuPG-2. However, if at some time ECC would > really take off, we might backport it to 1.4 if we could agree to change > 1.4 to make use of Libgcrypt. Such a major change would warrant a 1.6 IMO. BTW, is there any discussion in the OpenPGP community about other public key systems, like NTRUEncrypt (see http://en.wikipedia.org/wiki/NTRUEncrypt )? Or are they too imature? IMO ECC has at least some questions about it since the NSA is pushing it. That could be because they know of weaknesses in it, or because they know of weaknesses in ElGamal and RSA. Difficult to guess. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From ndk.clanbo at gmail.com Fri Sep 13 14:05:03 2013 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 13 Sep 2013 14:05:03 +0200 Subject: Why trust gpg4win? In-Reply-To: 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <20130912231051.446b02db@eunet.rs> <5232BC6E.2090009@gmail.com> Message-ID: <5232FF6F.9070904@gmail.com> Il 13/09/2013 11:33, Jan ha scritto: > My "security perimeter" should be "equal" to the maximum of the > "security perimeters" of my usual communication partners. That is so > because with their private key they protect my mail and with my private > key I protect their mail. What is "usual" is not always easy to > determine. Lets say I'm looking for the maximum of security an average > user can achieve with common hardware. This user is willing to do some > inconvenient things like reboot, burn CDs or wait. Then you can't defend it. :) You can't even completely audit it, since it involves a lot of "things" that aren't under your control. What happens if one of your correspondents is willing to undergo the whole procedure and he's an FBI agent? :) You can be paranoid as much as you want, but you will never be paranoid enough. If FBI (or, more realistically, your wife) wants access to your data, there's nearly nothing you can do to avoid it... > Generally I distrust certain hardware like smartcards or HSMs because > they are main targets for secret services, who have a lot of money. You could use a Chinese smart card: quite sure it's not been tampered by FBI :) > Recently I red about this intersting (English/German) article on FBI > backdoors in openBSB and scmartcards: > http://www.h-online.com/open/news/item/FBI-back-door-in-IPSec-implementation-of-OpenBSD-1153297.html > http://www.heise.de/newsticker/meldung/FBI-Backdoor-in-IPSec-Implementierung-von-OpenBSD-1153180.html Well, that's one reason I don't like "random blobs" in crypto (like OAEP requires): it could be quite easy yo use such a blob as steganographic covert channel. But for OpenBSD I'd be more incline to thinking that FBI stopped funding since they couldn't have their backdoors installed. > It should be possible to create a rather secure system using "norml > technoligies" (CDs, offline PCs etc.) which are harder to target by > secret services. Never heard of TEMPEST? You boot from an accurately audited CD, decrypt your top-secret email and as soon as you display it on the monitor it gets aired to that van in front of your house :) > If you manage to have a rather secure file transfer > between an online and an offline PC, the only security relevant > technology you need to focus on is gnuPG itself. No. Side-channels are everywhere. You can't ignore 'em. If you want to certify that your security perimeter is secure, you first have to accurately define where it is and the threat model. And even then you can only certify it's secure against the attacks you could think of. > Some people read the > source code to check its integrity but are there people who focus on its > output? To me this is a very important point. I'm not sure how this > could be done in practice, but I was thinking about someone who knows > the theory of RSA etc. and who "manually" encrypted a text and would > compare that with the output of gnuPG to see whether the two results > match. Take OAEP signature as an example. *IF* the random bytes are really random the signature is secure. But since they should be random, you can't say if they are truly random or just the output of a cypher that, given the right password, is transferring your secret key chunk-by-chunk. And against that, even manually encoding is useless: the RSA encryption is done correctly, the key is the right one, the protocol is followed, but soon someone else will have your key and will be able to decrypt all your messages. IVs are another potential channel, but they're needed to make many encryption schemes secure. > Some other approach might be to compare the output of several > versions of gnuPG, PGP etc.. This way you could check whether the > information was secretly decrypted with a second "FBI key". This is even > possible for someone how is no programer. Do you think checking the > output in that way is useful? No. You can only check if the protocol is followed accurately. How can you check there isn't a weakness in RNG, for example? In other terms, how can you tell apart a TRNG from a good cypher? BYtE, Diego. From di44vq at nottheoilrig.com Fri Sep 13 01:18:32 2013 From: di44vq at nottheoilrig.com (Jack Bates) Date: Thu, 12 Sep 2013 16:18:32 -0700 Subject: Transfer subkey to other keyring In-Reply-To: <522B33C3.4090408@digitalbrains.com> References: <51C9DD9A.3060707@nottheoilrig.com> <87ppv9gqx1.fsf@vigenere.g10code.de> <51CB2C48.4070809@nottheoilrig.com> <87hagkdmca.fsf@vigenere.g10code.de> <51CC6E7D.4080709@nottheoilrig.com> <522B33C3.4090408@digitalbrains.com> Message-ID: <52324BC8.1010801@nottheoilrig.com> On 07/09/13 07:10 AM, Peter Lebbing wrote: > On 27/06/13 18:55, Jack Bates wrote: >> except that I am using the key id of a subkey, with an exclamation >> mark, to export just one subkey instead of all the subkeys belonging to the >> primary key. The subkey with that key id definitely doesn't already exist in the >> destination keyring, although the destination keyring does already contain a >> different subkey. > > I believe once GnuPG has a secret key, it won't update it anymore with any > subsequent imports. So to get the additional subkey, re-export the whole thing, > delete the existing one on the other system and import your re-exported whole thing. > > I'm also wondering why you're being so explicit about it in the first place, > with transferring little chunks at a time using the exclamation mark instead of > the whole thing. Is there something specific you're trying to achieve? > >> gpg: secret keys unchanged: 1 > > This message to me implies it is actually possible to change something about a > secret key. I haven't figured out what yet. Thank you for following up Peter, I looked again and I think it's a difference between public vs. secret subkeys. It will merge a new public subkey with existing subkeys, but it won't merge a new secret subkey with existing ones. Here is a first crack at a patch to merge new secret subkeys similar to how it already handles public ones: http://nottheoilrig.com/gnupg/201309120/merge.patch I'd love to contribute a change like this to GnuPG, would a change like this be welcome? (considered for inclusion?) If so, can anyone help me review it and get it into shape? What is the right way to submit a patch to GnuPG? Here's what GnuPG does before and after the patch: # Generate primary key $ gpg2 --gen-key pub 4096R/B575FAD1 2013-09-12 Key fingerprint = 19C1 3488 6B2A A80C E30A 6A96 4CB2 EAFB B575 FAD1 uid John Doe # Add subkey $ gpg2 --edit-key B575FAD1 addkey pub 4096R/B575FAD1 created: 2013-09-12 expires: never usage: SC trust: ultimate validity: ultimate sub 4096R/3BEA5E48 created: 2013-09-12 expires: 2013-09-13 usage: S # Export secret subkey $ gpg2 --export-secret-subkeys 3BEA5E48! > 3BEA5E48 # Add another subkey gpg2 --edit-key B575FAD1 addkey pub 4096R/B575FAD1 created: 2013-09-12 expires: never usage: SC trust: ultimate validity: ultimate sub 4096R/3BEA5E48 created: 2013-09-12 expires: 2013-09-13 usage: S sub 4096R/1F01C58C created: 2013-09-12 expires: 2013-09-13 usage: S # Export other secret subkey $ gpg2 --export-secret-subkeys 1F01C58C! > 1F01C58C # Start over with an empty keyring $ rm -r ~/.gnupg # Import first subkey $ gpg2 --import 3BEA5E48 gpg: key B575FAD1: secret key imported gpg: key B575FAD1: public key "John Doe " imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: secret keys read: 1 gpg: secret keys imported: 1 Here's what it does before the patch: # Import second subkey $ gpg2 --import 1F01C58C gpg: key B575FAD1: already in secret keyring gpg: Total number processed: 1 gpg: secret keys read: 1 gpg: secret keys unchanged: 1 $ gpg2 -K sec# 4096R/B575FAD1 2013-09-12 uid John Doe ssb 4096R/3BEA5E48 2013-09-12 And here's what happens after the patch: # Import second subkey $ gpg2 --import 1F01C58C gpg: key B575FAD1: "John Doe " 1 new signature gpg: key B575FAD1: "John Doe " 1 new subkey gpg: key B575FAD1: "John Doe " 1 new signature gpg: key B575FAD1: "John Doe " 1 new subkey gpg: Total number processed: 1 gpg: new subkeys: 2 gpg: new signatures: 2 gpg: secret keys read: 1 $ gpg2 -K sec# 4096R/B575FAD1 2013-09-12 uid John Doe ssb 4096R/3BEA5E48 2013-09-12 ssb 4096R/1F01C58C 2013-09-12 I looked at the code in gnupg/g10/import.c and when you import something, the import() procedure gets called once by import_keys_internal(), etc. The import_one() procedure gets called if import() finds a PKT_PUBLIC_KEY keyblock and import_secret_one() gets called if it finds a PKT_SECRET_KEY keyblock. After import_secret_one() imports a new secret key, it converts it to a public key with sec_to_pub_keyblock() and passes that to import_one(). import_one() and import_secret_one() both check if the key already exists in the keyring. If import_one() finds that it does, it reads the existing keyblock, calls merge_blocks(), and if anything changed it writes back the updated keyblock. However if import_secret_one() finds that the key already exists, currently it just says: 1273 else if( !rc ) 1274 { /* we can't merge secret keys */ 1275 log_error( _("key %s: already in secret keyring\n"), 1276 keystr_from_sk(sk)); 1277 stats->secret_dups++; 1278 if (is_status_enabled ()) 1279 print_import_ok (NULL, sk, 16); 1280 1281 /* TODO: if we ever do merge secret keys, make sure to handle 1282 the sec_to_pub_keyblock feature as well. */ 1283 } To make the patch, I cargo-culted a combination of code from where import_secret_one() imports new secret keys and where import_one() merges new public subkeys with existing ones. It reads the existing keyblock, calls merge_blocks(), and writes back the updated keyblock if anything changed. I am grateful for feedback or help getting the patch into shape, if this is a welcome change. Thanks! From nicholas.cole at gmail.com Fri Sep 13 14:24:12 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 13 Sep 2013 13:24:12 +0100 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: <878uz1mxqy.fsf@alice.fifthhorseman.net> References: <878uz1mxqy.fsf@alice.fifthhorseman.net> Message-ID: On Fri, Sep 13, 2013 at 12:22 AM, Daniel Kahn Gillmor wrote: > GnuPG is currently not able to create a non-exportable self-sig. If you > try to do this, it gives an error: > > WARNING: the signature will not be marked as non-exportable. > > But: some people might never want their keys to be published to the public > keyservers, or have some User IDs that they keep locally that they do > not want to be transmitted via the keyserver network. > > AIUI, keyservers should reject keys that do not have a self-signature. > Keyservers should also honor the "non-exportable" marker by rejecting > OpenPGP certification packets that have the "exportable" subpacket > included and set to 0. > > So the sensible thing for a keyholder who wants their key to stay off > the keyservers would be to issue a non-exportable self-signature. I don't think this is sensible. What is the point of a UID that cannot be used by someone else? If the UID is shared with anyone else (even privately), it must have a self-signature, and so that signature must be exportable. If gpg starts --exporting keys with non-self-signed UIDs, this will be a step backwards. I see what you are trying to achieve, but I don't think this is the right way to do it. The correct way would be to have keyservers honour the no-modify flag, or perhaps have some notation on the ID that prevents uploading to a public keyserver. I myself would favour the latter approach. N. From peter at digitalbrains.com Fri Sep 13 15:49:28 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Fri, 13 Sep 2013 15:49:28 +0200 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: References: <878uz1mxqy.fsf@alice.fifthhorseman.net> Message-ID: <9a083c74a2a71d091256d5ecdc33a57d@butters.digitalbrains.com> On 2013-09-13 14:24, Nicholas Cole wrote: > The correct way would be to have keyservers > honour the no-modify flag, or perhaps have some notation on the ID > that prevents uploading to a public keyserver. I myself would favour > the latter approach. The latter has the same problem as the no-modify flag: it can be subverted by someone as long as the keyservers do not do crypto. HTH, Peter. PS: I accidentally replied to Nicholas only. Using a different client than usually. -- 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 dshaw at jabberwocky.com Fri Sep 13 16:17:10 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 13 Sep 2013 16:17:10 +0200 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: <878uz1mxqy.fsf@alice.fifthhorseman.net> References: <878uz1mxqy.fsf@alice.fifthhorseman.net> Message-ID: On Sep 13, 2013, at 1:22 AM, Daniel Kahn Gillmor wrote: > GnuPG is currently not able to create a non-exportable self-sig. If you > try to do this, it gives an error: > > WARNING: the signature will not be marked as non-exportable. This is by design (hence the warning message), as an unsigned user ID is not really meaningful as anyone could add it against the will of the keyholder, and a locally signed user ID is effectively unsigned. David From dkg at fifthhorseman.net Fri Sep 13 16:29:03 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Sep 2013 10:29:03 -0400 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: References: <878uz1mxqy.fsf@alice.fifthhorseman.net> Message-ID: <5233212F.6000801@fifthhorseman.net> On 09/13/2013 08:24 AM, Nicholas Cole wrote: > I don't think this is sensible. What is the point of a UID that > cannot be used by someone else? If the UID is shared with anyone else > (even privately), it must have a self-signature, and so that signature > must be exportable. It is possible to share non-exportable signatures between private users. see --import-options import-local in gpg(1). I know there are GnuPG users who prefer to avoid having their keys on the public keyservers entirely, and who are willing to accept the costs of doing manual key distribution using non-exportable certifications. > If gpg starts --exporting keys with > non-self-signed UIDs, this will be a step backwards. those keys will not be accepted by anyone as valid, and users will have had to jump through hoops to create them as such, so they know what they're getting themselves into. > I see what you are trying to achieve, but I don't think this is the > right way to do it. The correct way would be to have keyservers > honour the no-modify flag, Nearly every key created by GnuPG in the last decade has had the no-modify flag set. There was never consensus about exactly what it means, or how to interpret it: does it mean that keyservers need primary key approval before publishing a third-party certification on an OpenPGP cert? if so, how does the primary keyholder express that approval? And no keyservers ever implemented it, because there was no unambiguous mechanism *to* implement. interpreting it to mean "do not publish on the keyservers at all" would mean almost no keys would be on the keyservers. > or perhaps have some notation on the ID > that prevents uploading to a public keyserver. We have that already. It's having the "exportable" subpacket included in the certification, with the content set to 0, meaning "non-exportable". That's what i'm trying to do. > I myself would favour the latter approach. great! --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 gnupg-users at wiroth.neomailbox.net Fri Sep 13 15:33:16 2013 From: gnupg-users at wiroth.neomailbox.net (Didier) Date: Fri, 13 Sep 2013 15:33:16 +0200 Subject: newbie and smartcard, I'm lost. Message-ID: <5cd911d0ff1ffa0d9a4d7db80f8f8bc5a083607e@www.neomailbox.net> Hi, I'm a newbie ... and I would like to do file and mail encryption from different PCs at different locations with gnupg. In any case I would not like to copy my private key on other pcs! As far as I understood, using a smartcard was the ideal solution as I won't have to store my private keys on each pc. I would simply have to use my smartcard f.ex. to encrypt a file with my private key on a given PC when I need to. Here is what I did so far, I generated keys on the card: a) gpg2 --card-edit, and after admin command. gpg/card> generate Make off-card backup of encryption key? (Y/n) n gpg: NOTE: keys are already stored on the card! Replace existing keys? (y/N) y What keysize do you want for the Signature key? (2048) What keysize do you want for the Encryption key? (2048) What keysize do you want for the Authentication key? (2048) Please specify how long the key should be valid. ???????? 0 = key does not expire ????? ? = key expires in n days ????? w = key expires in n weeks ????? m = key expires in n months ????? y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Test Name must be at least 5 characters long Real name: Test Test Email address: test at test.com Comment: You selected this USER-ID: ??? "Test Test " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O gpg: key 7289B2FC marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0? valid:?? 1? signed:?? 0? trust: 0-, 0q, 0n, 0m, 0f, 1u pub?? 2048R/7289B2FC 2013-09-13 ????? Key fingerprint = F699 1939 18B7 C5E1 B01D? 2D43 17D9 B703 7289 B2FC uid????????????????? Test Test sub?? 2048R/9899BBE7 2013-09-13 sub?? 2048R/9E5C75ED 2013-09-13 1) Why did gpg create a secret key file secring.gpg? in the %appdata%gnugpg directory, shouldn't the secret key file only be stored on the smarcard? here is a dir of %appdata%gnupg (the files generated at 15:00 were created with the card admin generate command???) 13-Sep-13? 14:50??? ????????? private-keys-v1.d 13-Sep-13? 15:00???????????? 1.751 pubring.bak 13-Sep-13? 15:02???????????? 1.751 pubring.gpg 13-Sep-13? 14:50???????????????? 0 pubring.gpg.lock 13-Sep-13? 14:50???????????????? 8 reader_0.status 13-Sep-13? 14:50??????????????? 22 S.gpg-agent 13-Sep-13? 14:50??????????????? 22 S.scdaemon 13-Sep-13? 15:00???????????? 1.826 secring.gpg 13-Sep-13? 14:50???????????????? 0 secring.gpg.lock 13-Sep-13? 15:02???????????? 1.280 trustdb.gpg 13-Sep-13? 14:50???????????????? 0 trustdb.gpg.lock Now I'm simulating a move to another computer and I'm renaming the %appdata%gnugp to %appdata%gnupg.old Now I'm reissuing the "gpg2 --card-status" command: gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/secring.gpg' created gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/pubring.gpg' created Application ID ...: D2760001240102000005000013B10000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 000013B1 Name of cardholder: Test Test Language prefs ...: fr Sex ..............: male URL of public key : [not set] Login data .......: [not set] Signature PIN ....: forced Key attributes ..: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 5 Signature key ....: F699 1939 18B7 C5E1 B01D? 2D43 17D9 B703 7289 B2FC ????? created ....: 2013-09-13 12:59:23 Encryption key....: E0A0 95F9 646A 95ED F3E5? 49A2 428B F92C 9E5C 75ED ????? created ....: 2013-09-13 12:59:23 Authentication key: B925 6ED8 BEF6 F17F 7A4D? 4E4E F5DC BD13 9899 BBE7 ????? created ....: 2013-09-13 12:59:23 General key info..: [none] 2) Why is "General key info" empty now? If I do a gpg2 --list-keys, no keys are listed anymore. 3) How can I encrypt a mail or file with my smartcard now on another PC without copying any files? Thank you very much for helping me!!!! Didier -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas.cole at gmail.com Fri Sep 13 16:40:26 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 13 Sep 2013 15:40:26 +0100 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: <5233212F.6000801@fifthhorseman.net> References: <878uz1mxqy.fsf@alice.fifthhorseman.net> <5233212F.6000801@fifthhorseman.net> Message-ID: On Fri, Sep 13, 2013 at 3:29 PM, Daniel Kahn Gillmor wrote: > On 09/13/2013 08:24 AM, Nicholas Cole wrote: > >> I don't think this is sensible. What is the point of a UID that >> cannot be used by someone else? If the UID is shared with anyone else >> (even privately), it must have a self-signature, and so that signature >> must be exportable. > > It is possible to share non-exportable signatures between private users. > see --import-options import-local in gpg(1). I know there are GnuPG > users who prefer to avoid having their keys on the public keyservers > entirely, and who are willing to accept the costs of doing manual key > distribution using non-exportable certifications. > >> If gpg starts --exporting keys with >> non-self-signed UIDs, this will be a step backwards. > > those keys will not be accepted by anyone as valid, and users will have > had to jump through hoops to create them as such, so they know what > they're getting themselves into. > >> I see what you are trying to achieve, but I don't think this is the >> right way to do it. The correct way would be to have keyservers >> honour the no-modify flag, > > Nearly every key created by GnuPG in the last decade has had the > no-modify flag set. There was never consensus about exactly what it > means, or how to interpret it: does it mean that keyservers need primary > key approval before publishing a third-party certification on an OpenPGP > cert? if so, how does the primary keyholder express that approval? And > no keyservers ever implemented it, because there was no unambiguous > mechanism *to* implement. > > interpreting it to mean "do not publish on the keyservers at all" would > mean almost no keys would be on the keyservers. > >> or perhaps have some notation on the ID >> that prevents uploading to a public keyserver. > > We have that already. It's having the "exportable" subpacket included > in the certification, with the content set to 0, meaning > "non-exportable". That's what i'm trying to do. > >> I myself would favour the latter approach. I'll admit your solution is ingenious. But all the same, I think you are trying to overload one clearly defined feature of the openpgp spec - a non-exportable signature - to try and force keyservers not to store UIDs. I really don't favour this approach at all. Section 5.2.3.11. (Exportable Certification) of the openpgp spec very clearly defines what "local" signatures are to be used for. Your solution works only because gpg provides a way to export even non-exportable signatures, but that is not guaranteed by the spec. If the no-modify flag is a dead-end, then (as I suggested) I think a new notation that keyservers could honour is the the way forward on this. From dkg at fifthhorseman.net Fri Sep 13 16:42:13 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Sep 2013 10:42:13 -0400 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: <9a083c74a2a71d091256d5ecdc33a57d@butters.digitalbrains.com> References: <878uz1mxqy.fsf@alice.fifthhorseman.net> <9a083c74a2a71d091256d5ecdc33a57d@butters.digitalbrains.com> Message-ID: <52332445.3090507@fifthhorseman.net> On 09/13/2013 09:49 AM, Peter Lebbing wrote: > On 2013-09-13 14:24, Nicholas Cole wrote: >> The correct way would be to have keyservers >> honour the no-modify flag, or perhaps have some notation on the ID >> that prevents uploading to a public keyserver. I myself would favour >> the latter approach. > > The latter has the same problem as the no-modify flag: it can be > subverted by someone as long as the keyservers do not do crypto. yes, pretty much anything can be published as long as the keyservers do not do crypto. That's something that the keyservers need to fix, as it would prevent other problems as well. In the meantime, we can produce certifications that won't be misinterpreted by the keyservers as they currently exist, and can be validated by any future keyservers that do proper cryptographic checks. --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 dkg at fifthhorseman.net Fri Sep 13 16:43:19 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Sep 2013 10:43:19 -0400 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: References: <878uz1mxqy.fsf@alice.fifthhorseman.net> Message-ID: <52332487.90203@fifthhorseman.net> On 09/13/2013 10:17 AM, David Shaw wrote: > On Sep 13, 2013, at 1:22 AM, Daniel Kahn Gillmor wrote: > >> GnuPG is currently not able to create a non-exportable self-sig. If you >> try to do this, it gives an error: >> >> WARNING: the signature will not be marked as non-exportable. > > This is by design (hence the warning message), as an unsigned user ID is not really meaningful as anyone could add it against the will of the keyholder, and a locally signed user ID is effectively unsigned. I'm not advocating for keyservers to traffic in (or for gpg to export or import by default) keys with unsigned user IDs. That would be a Bad Thing. What i'm asking for is to make it possible for people who do not want their key on the keyservers, ever, to be able to explicitly state it in their self-signatures. I hope this will not be a large class of users, but i know it is a non-empty set. 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 nicholas.cole at gmail.com Fri Sep 13 17:35:00 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 13 Sep 2013 16:35:00 +0100 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: <52332445.3090507@fifthhorseman.net> References: <878uz1mxqy.fsf@alice.fifthhorseman.net> <9a083c74a2a71d091256d5ecdc33a57d@butters.digitalbrains.com> <52332445.3090507@fifthhorseman.net> Message-ID: On Fri, Sep 13, 2013 at 3:42 PM, Daniel Kahn Gillmor wrote: > On 09/13/2013 09:49 AM, Peter Lebbing wrote: >> On 2013-09-13 14:24, Nicholas Cole wrote: >>> The correct way would be to have keyservers >>> honour the no-modify flag, or perhaps have some notation on the ID >>> that prevents uploading to a public keyserver. I myself would favour >>> the latter approach. >> >> The latter has the same problem as the no-modify flag: it can be >> subverted by someone as long as the keyservers do not do crypto. > > yes, pretty much anything can be published as long as the keyservers do > not do crypto. That's something that the keyservers need to fix, as it > would prevent other problems as well. > > In the meantime, we can produce certifications that won't be > misinterpreted by the keyservers as they currently exist, and can be > validated by any future keyservers that do proper cryptographic checks. Well. Why not trust your circle of contacts (because anyone using this scheme must be in a small circle) not to upload the keys to keyservers? Perhaps if there is enough demand gpg could even have a "Never send these keys to keyservers" option in the config file, taking a list of fingerprints. Just a thought. I'm against doing something that goes against the standard when there are other ways to achieve it. N. From pete at heypete.com Fri Sep 13 17:57:08 2013 From: pete at heypete.com (Pete Stephenson) Date: Fri, 13 Sep 2013 17:57:08 +0200 Subject: newbie and smartcard, I'm lost. In-Reply-To: <5cd911d0ff1ffa0d9a4d7db80f8f8bc5a083607e@www.neomailbox.net> References: <5cd911d0ff1ffa0d9a4d7db80f8f8bc5a083607e@www.neomailbox.net> Message-ID: On Fri, Sep 13, 2013 at 3:33 PM, Didier wrote: > > > Hi, > I'm a newbie ... and I would like to do file and mail encryption from > different PCs at different locations with gnupg. > In any case I would not like to copy my private key on other pcs! > As far as I understood, using a smartcard was the ideal solution as I won't > have to store my private keys on each pc. I would simply have to use my > smartcard f.ex. to encrypt a file with my private key on a given PC when I > need to. Indeed. Sounds like a good plan. > 1) Why did gpg create a secret key file secring.gpg in the %appdata%\gnugpg > directory, shouldn't the secret key file only be stored on the smarcard? GPG creates a pseudo-secret key that includes "stubs" that tell GPG that your private key is located on a card number with serial number 000013B1. This pseudo-secret key (there's not actually anything secret about it, as it's just the stubs) is stored in the secring.gpg. The private key was generated entirely on the card and cannot be exported. > Now I'm simulating a move to another computer and I'm renaming the > %appdata%\gnugp to %appdata%\gnupg.old > Now I'm reissuing the "gpg2 --card-status" command: > gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/secring.gpg' created > gpg: keyring `C:/Users/test/AppData/Roaming/gnupg/pubring.gpg' created > Application ID ..: D2760001240102000005000013B10000 > Version ..........: 2.0 > Manufacturer .....: ZeitControl > Serial number ....: 000013B1 > Name of cardholder: Test Test > Language prefs ...: fr > Sex .............: male > URL of public key : [not set] > Login data .......: [not set] > Signature PIN ....: forced > Key attributes ...: 2048R 2048R 2048R > Max. PIN lengths .: 32 32 32 > PIN retry counter : 3 0 3 > Signature counter : 5 > Signature key ....: F699 1939 18B7 C5E1 B01D 2D43 17D9 B703 7289 B2FC > created ....: 2013-09-13 12:59:23 > Encryption key....: E0A0 95F9 646A 95ED F3E5 49A2 428B F92C 9E5C 75ED > created ....: 2013-09-13 12:59:23 > Authentication key: B925 6ED8 BEF6 F17F 7A4D 4E4E F5DC BD13 9899 BBE7 > created ....: 2013-09-13 12:59:23 > General key info..: [none] > > 2) Why is "General key info" empty now? > If I do a gpg2 --list-keys, no keys are listed anymore. > 3) How can I encrypt a mail or file with my smartcard now on another PC > without copying any files? If I remember correctly, you need to import the public key (whether from the keyserver, a flash drive, or some other storage medium) to that computer, insert the card, run "gpg --card-status", the General Key Info will be correctly populated, and new pseudo-secret stubs will be created, and you'll be able to use the smartcard on that system. If you put your public key online somewhere (say on your website, by itself, in a text file) you can program that URL into your smartcard in the "URL of public key" section (gpg --card-edit, admin, url). When you get to a new computer, you can insert the card, run "gpg --card-edit", then run "fetch" and GPG will fetch the public key from that URL. If there's no URL entered then I think it will attempt to retrieve the public key from the keyserver but you might want to check. Cheers! -Pete -- Pete Stephenson From dkg at fifthhorseman.net Fri Sep 13 18:35:38 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 13 Sep 2013 12:35:38 -0400 Subject: lsign produces exportable signatures when used for self-sigs In-Reply-To: References: <878uz1mxqy.fsf@alice.fifthhorseman.net> <9a083c74a2a71d091256d5ecdc33a57d@butters.digitalbrains.com> <52332445.3090507@fifthhorseman.net> Message-ID: <52333EDA.4040601@fifthhorseman.net> On 09/13/2013 11:35 AM, Nicholas Cole wrote: > Well. Why not trust your circle of contacts (because anyone using this > scheme must be in a small circle) not to upload the keys to > keyservers? > > Perhaps if there is enough demand gpg could even have a "Never send > these keys to keyservers" option in the config file, taking a list of > fingerprints. Because I want to be able to make it clear *to the keyservers*, not to "the circle of contacts" that are using the key. People make mistakes; people change allegiances; people can be coerced. I am talking about a statement made by the keyholder, about how they want their key to propagate or not propagate. We have a standard that makes clear how to express this intent. It makes sense to embed the desired instructions in the key itself. > Just a thought. I'm against doing something that goes against the > standard when there are other ways to achieve it. I don't think anything that I have proposed here is in any way against the standard. 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 takethebus at gmx.de Fri Sep 13 20:54:28 2013 From: takethebus at gmx.de (Jan) Date: Fri, 13 Sep 2013 20:54:28 +0200 Subject: Why trust gpg4win? 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <20130912231051.446b02db@eunet.rs> <5232BC6E.2090009@gmail.com> <5232FF6F.9070904@gmail.com> Message-ID: On 09/13/2013 14:05, NdK wrote: >What happens if one of your correspondents is willing to undergo the >whole procedure and he's an FBI agent? I'd tell him confidential information, - but I did not intent to protect me against such a thread by means of gnuPG. > If you want to > certify that your security perimeter is secure, you first have to > accurately define where it is and the threat model. And even then you > can only certify it's secure against the attacks you could think of. That is a good point. On this list I learned about the existence of some vectors I did not even think of. Thank you for that information. Is there a book on thread models which list widely known attack vectors? OK, so I'll try to define two thread models. The setup: Assume there is a windows PC connected to the internet (online PC) and an USB device with debian on it where the network drives are uninstalled (offline PC). The USB device is only plugged into the machine, if windows is not running. The windows PC has a FAT partition. Encrypted emails/files downloaded with windows are stored there. After reboot the FAT partition is mounted with debian and the emails/files are decrypted. The reverse procedure (answer to the email) runs analogously. Only simple file formats are accepted. Thread models: 1. There might be a Trojan on the windows machine. 2. There might be a Trojan on the windows machine and someone might steel the USB device from my apartment. I don't care about hardware key loggers, TEMPEST, cold boot attacks or cameras installed in my apartment. In the second thread model the USB device would have an encrypted root partition. Another scenario is that instead of the USB device there is a real offline PC and file transfer between the two machines happens only via CD-RW or multisession CD-R. Kind regards, Jan From takethebus at gmx.de Fri Sep 13 21:12:36 2013 From: takethebus at gmx.de (Jan) Date: Fri, 13 Sep 2013 21:12:36 +0200 Subject: Why trust gpg4win? 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <20130912231051.446b02db@eunet.rs> <5232BC6E.2090009@gmail.com> <5232FF6F.9070904@gmail.com> Message-ID: <8D794789CBF04C1C906D6D9660800FB9@neinpc> In 09/13/2013 14:05, NdK wrote: >> > Some other approach might be to compare the output of several >> > versions of gnuPG, PGP etc.. This way you could check whether the >> > information was secretly decrypted with a second "FBI key". This is >> > even >> > possible for someone how is no programer. Do you think checking the >> > output in that way is useful? > No. You can only check if the protocol is followed accurately. > How can you check there isn't a weakness in RNG, for exampel [...] There are statistical test with which you can test whether a random number generator produces for instance uniformly distributed numbers. This in connection with the above procedure might make a good output oriented check of gnuPG. Kind regards, Jan From ndk.clanbo at gmail.com Fri Sep 13 22:13:40 2013 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 13 Sep 2013 22:13:40 +0200 Subject: Why trust gpg4win? In-Reply-To: <8D794789CBF04C1C906D6D9660800FB9@neinpc> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <20130912231051.446b02db@eunet.rs> <5232BC6E.2090009@gmail.com> <5232FF6F.9070904@gmail.com> <8D794789CBF04C1C906D6D9660800FB9@neinpc> Message-ID: <523371F4.3090608@gmail.com> Il 13/09/2013 21:12, Jan ha scritto: >> How can you check there isn't a weakness in RNG, for exampel [...] > There are statistical test with which you can test whether a random > number generator produces for instance uniformly distributed numbers. > This in connection with the above procedure might make a good output > oriented check of gnuPG. A good encryption algorithm should generate an output that you can't tell is not purely random. That's why you have to compress the data BEFORE encrypting it. Then the output is usually "decorated" with data structures to make it recognizeable and not attempt decrypting it the wrong way. BYtE, Diego. From wk at gnupg.org Sat Sep 14 00:20:05 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 14 Sep 2013 00:20:05 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <5232F632.7010401@vulcan.xs4all.nl> (Johan Wevers's message of "Fri, 13 Sep 2013 13:25:38 +0200") References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> Message-ID: <87wqmk1i0a.fsf@vigenere.g10code.de> On Fri, 13 Sep 2013 13:25, johanw at vulcan.xs4all.nl said: > Such a major change would warrant a 1.6 IMO. Sure. > BTW, is there any discussion in the OpenPGP community about other public > key systems, like NTRUEncrypt (see No, I am not aware of any discussions. QC resistant algorithms are not yet something we need to rush for. We can't predict the future, but anyway it is good to know that even with today's technologies there are ways to mitigate an eventual QC based public key break. In this light the discussions about the need for 8k RSA now is as reliable as coffee grounds reading > IMO ECC has at least some questions about it since the NSA is pushing > it. That could be because they know of weaknesses in it, or because they There are of course sound reasons why they suggest the use of ECC. With about 30 years of research, ECC has a pretty solid theoretical foundation. The reasons why the seeds for the NIST curve parameters have not been recorded should of course raise more doubts now - I don't think that the DES history has a sequel here. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From expires2013 at ymail.com Sat Sep 14 01:34:14 2013 From: expires2013 at ymail.com (MFPA) Date: Sat, 14 Sep 2013 00:34:14 +0100 Subject: Should the use of multiple UID per key be discouraged? In-Reply-To: <522F6C8A.4040602@spth.de> References: <522F6C8A.4040602@spth.de> Message-ID: <168494455.20130914003414@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 10 September 2013 at 8:01:30 PM, in , Philipp Klaus Krause wrote: > GPG supports the feature of having multiple UIDs per > key. However this requires special care of anyone > signing such a key. AFAIK, there is no really > user-friendly, and definitely no newbie-friendly way to > do so. I have often seen mention of (but not personally used) CA - Fire and Forget (CAFF) "CA Fire and Forget is a script that helps you in keysigning. It takes a list of keyids on the command line, fetches them from a keyserver and calls GnuPG so that you can sign it. It then mails each key to all its email addresses - only including the one UID that we send to in each mail, pruned from all but self sigs and sigs done by you. The mailed key is encrypted with itself as a means to verify that key belongs to the recipient." - -- Best regards MFPA mailto:expires2013 at ymail.com Never lean forward to push an invisible object. -----BEGIN PGP SIGNATURE----- iQCVAwUBUjOhB6ipC46tDG5pAQoShAP/ZFKmvB+GdDapfBdKUDDYXUH62YDI8i9K 4eAquDk0ei/zLzQ3pZXkDAKsrvAkCcvzwSZe3m6qY8DtNlxiJ1WqEg1atL5wVCwq E3QaiagGkHedaQWdMYGhjXNcwXl+N2mH5iXD/WBgEOrq+3yU7MMyhbnfi08wBfnf MbMmpttqnyc= =Xs9k -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sat Sep 14 02:17:11 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 13 Sep 2013 20:17:11 -0400 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <87wqmk1i0a.fsf@vigenere.g10code.de> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> Message-ID: <5233AB07.7040608@sixdemonbag.org> On 9/13/2013 6:20 PM, Werner Koch wrote: > No, I am not aware of any discussions. QC resistant algorithms are not > yet something we need to rush for. Although it hasn't hit the IETF WG mailing list, I know that some list participants have had intermittent off-list conversations about lattice cryptography and other QC-resistant crypto. I wouldn't say that it's a subject of active discussion within the WG, but some individual WG members are definitely keeping an eye on it. And let me give a big "d'accord!" to Werner's "we don't need to rush." From johanw at vulcan.xs4all.nl Sat Sep 14 12:56:30 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sat, 14 Sep 2013 12:56:30 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <87wqmk1i0a.fsf@vigenere.g10code.de> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> Message-ID: <523440DE.2030004@vulcan.xs4all.nl> On 9/14/2013 0:20, Werner Koch wrote: > No, I am not aware of any discussions. QC resistant algorithms are not > yet something we need to rush for. While I agree that the current algorithms are probably safe against the current attacks, encrypted messages can be stored and broken in the future. That may still be problematic since some regimes have long memories (so you were a member of that terrorist / freedom fighter(*) cell 30 years ago. Now it's about time we send you and your family to Gitmo!). (*) Pick one choice. > We can't predict the future, but > anyway it is good to know that even with today's technologies there are > ways to mitigate an eventual QC based public key break. Fortunately yes. > In this light > the discussions about the need for 8k RSA now is as reliable as coffee > grounds reading I agree completely. If RSA 4k is broken, I would not trust RSA 8k much anymore. > There are of course sound reasons why they suggest the use of ECC. With > about 30 years of research, ECC has a pretty solid theoretical > foundation. The reasons why the seeds for the NIST curve parameters > have not been recorded should of course raise more doubts now - I don't > think that the DES history has a sequel here. No, certainly not in the light of the current developments. And since the NSA research budget is probably higher than that of all academic crypto departments together they may still be ahead of academic crypto, just as when DES was developed. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From philip at foolip.org Sun Sep 15 11:33:06 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Sun, 15 Sep 2013 11:33:06 +0200 Subject: How to find and verify a trust path? Message-ID: Hi all, Let's assume that I have signed enough keys and assigned enough ownertrust so that if I had all the world's keys locally and did `gpg --list-key --list-options show-uid-validity` I would see a bunch of keys as valid via the web of trust. Is there a way to determine if a given key would be valid in this case without actually importing all the world's keys? It seems like the keyserver ought to be able to find trust paths and that the keys could then be downloaded and verified locally, but I've not found anything to do this. The practical problem I'm trying to solve is how to determine if a signed git tag is in fact from a key I can trust without a lot of manual work. -- Philip J?genstedt From markoran at eunet.rs Sun Sep 15 12:04:38 2013 From: markoran at eunet.rs (Marko Randjelovic) Date: Sun, 15 Sep 2013 12:04:38 +0200 Subject: Why trust gpg4win? In-Reply-To: <5232BC6E.2090009@gmail.com> 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> <590D0BA3771C4AFCB9C5684E58528AF4@neinpc> <523162A0.90201@gmail.com> <4F31488109504931BE75B82817DF467D@neinpc> <20130912231051.446b02db@eunet.rs> <5232BC6E.2090009@gmail.com> Message-ID: <20130915120438.25e47c45@eunet.rs> On Fri, 13 Sep 2013 09:19:10 +0200 NdK wrote: > Il 12/09/2013 23:10, Marko Randjelovic ha scritto: > > > All the time I read suggestions on using USB sticks and I must say > > people are crazy about USB sticks. It is more convenient to use > > optical media then USB stick because they are read only. Boot from > > Live CD, not from USB stick and use USB stick only for data. In a > > desktop PC you can put two CD devices and boot Live CD from CD1 and > > write your data to CD2. You can use write-once media or rewritable > > media so you do not waste to much plastic. > It's just a matter of trust (and speed). After all, you need to take > the system image from "somewhere". That's probably the weakest link. > Or, at least, it's the easiest to compromise. WOT > > PS: I'll tell you a secret: there are USB keys with a "write protect" > switch :) > > > If you write your data to CDROM, then it is much more safer to > > transfer data to another PC. It is much more complicated to make a > > virus that will insert itself into a CDROM then into a USB stick. > > Furthermore, such action would be odd and could be blocked by a > > security software like SELinux. > And maybe there's a buffer overflow in the ISO9660 driver that can be > exploited . Hey, we're talking of the most tested codepaths (unless > you use some exotic filesystem)! Bug is a bug. It is not simpler to craft the filesystem than to insert ordinary virus. > > Maybe technical solutions for a social problem aren't always the right > answer? > You can *never* be 100% sure. No way. You can be "reasonably sure". > You can be "certifiably sure" (given that you define which kind of > attacks you think you'll be exposed to and find a standard to certify > against). > > I can be "reasonably sure" nobody will hack my machine just to read my > mail. Obama can be "reasonably sure" that *many* attackers will try. > So my scenario and Obama's one are "a bit" different, and require > *greatly* different solutions. I can't afford the costs and > inconveniences of a solution based on Obama's needs (and I'd be > indeed quite stupid to try to adopt it), and he can't afford the risk > of a solution tailored on mine. The problem is in that more you have better protection, more you become interesting. That way, if you try really protect yourself, you will prevent weak/moderate players to get your data, but instead strong players, like security agencies, who otherwise wouldn't be interested, *will* get your data. That makes all our efforts to protect our privacy absurd. I think NSA and similar organizations are dangerous and even if now they do not abuse to much their information (such as destroying dissidents), it can change in future. They store all data indefinitely and it is enough that only in one moment in future someone can and would abuse it to happen disaster. > > PPS: at least here in Italy a *completely offline machine* becomes > illegal after 6 months. Law dictates that every computer where > personal data is handled (and even a name and surname *is* "personal > data") *must* be updated *at least* every 6 months. And attacking > your update medium is probably easier than attacking the USB key. WOT -- Marko Ran?elovi?, B.Sc. Software Developer Ni?, Serbia markoran at eunet.rs http://mr.flossdaily.org Note: If you see a nonsense enclosed between lines BEGIN PGP SIGNATURE END PGP SIGNATURE then this message is digitally signed using OpenPGP compliant software. You need an appropriate plugin for your email client or other OpenPGP compliant software in order to verify the signature. However, the concept of computer insecurity implies digital signature is not absolute proof of identity. From peter at digitalbrains.com Sun Sep 15 12:34:23 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 15 Sep 2013 12:34:23 +0200 Subject: How to find and verify a trust path? In-Reply-To: References: Message-ID: <52358D2F.8040700@digitalbrains.com> Hello Philip, There is no such thing as a trust path. There are signature paths, but trust is not transitive in the normal Web Of Trust. Only with trust signatures, which according to the man page "is generally only useful in distinct communities or groups". I've replied to a similar request last April: [1]. Be careful to separate the issues of trust and validity. HTH, Peter. [1] http://lists.gnupg.org/pipermail/gnupg-users/2013-April/046574.html -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From philip at foolip.org Sun Sep 15 21:11:04 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Sun, 15 Sep 2013 21:11:04 +0200 Subject: How to find and verify a trust path? In-Reply-To: <52358D2F.8040700@digitalbrains.com> References: <52358D2F.8040700@digitalbrains.com> Message-ID: On Sun, Sep 15, 2013 at 12:34 PM, Peter Lebbing wrote: > Be careful to separate the issues of trust and validity. Right, I used the wrong terminology in my question. What I'm looking for is an automatic way to find a (valid) signature path from me to another key. In very concrete terms, how can I determine which keys I need to import so that the GnuPG dist sig (4F25E3B6) has full validity? Right now I'm pretty sure that it won't matter which keys I import because it's too many steps away, but that won't be the case for every key. My current best approach is to use http://pgp.cs.uu.nl/ in order to find the shortest paths and then manually import the keys to verify that it is in fact true... -- Philip J?genstedt From jgszary at gmail.com Sun Sep 15 18:54:43 2013 From: jgszary at gmail.com (Jack Szary) Date: Sun, 15 Sep 2013 12:54:43 -0400 Subject: Pgp key Message-ID: <00E88226-14A9-4D2A-A3E9-2BD78B178692@gmail.com> I have someone's PGP key and he said to use that to send him information, how do I use his key to send him a message? From pete at heypete.com Sun Sep 15 21:37:35 2013 From: pete at heypete.com (Pete Stephenson) Date: Sun, 15 Sep 2013 21:37:35 +0200 Subject: Pgp key In-Reply-To: <00E88226-14A9-4D2A-A3E9-2BD78B178692@gmail.com> References: <00E88226-14A9-4D2A-A3E9-2BD78B178692@gmail.com> Message-ID: On Sun, Sep 15, 2013 at 6:54 PM, Jack Szary wrote: > I have someone's PGP key and he said to use that to send him information, how do I use his key to send him a message? Hi Jack, Do you have GnuPG (or some other OpenPGP-compatible software) installed? If so, do you already have your own PGP key? Cheers! -Pete -- Pete Stephenson From mike_acker at charter.net Sun Sep 15 21:40:08 2013 From: mike_acker at charter.net (Mike Acker) Date: Sun, 15 Sep 2013 15:40:08 -0400 Subject: Setting Preference for Block Cipher In-Reply-To: References: Message-ID: <52360D18.2090403@charter.net> On 09/07/2013 07:34 PM, gnupg-users-request at gnupg.org wrote: > Why? Your preference list makes no sense. > >> > TWOFISH CAST5 BLOWFISH 3DES AES AES192 AES256 CAMELLIA128 >> > CAMELLIA192 CAMELLIA256 > GnuPG and PGP will stop as soon as they hit 3DES. They won't even look > at the rest of the ciphers in your preference list. "Okay, Mike likes > Twofish, but the recipient doesn't support it... then CAST5, but that's > not supported... then Blowfish, again not supported... hey, 3DES. 3DES > is *guaranteed* to be supported. The recipient has to speak 3DES. > Cool. We'll choose 3DES and not even bother with the rest of the list." > it is important to understand that the specification i have in MY key is addressed to any party which may be sending to me. I am essentially telling the other party: use TWOFISH as my first choice. Now: if the sender encrypts the message to more than one recipient then ( if i'm reading the documention right ) the selection the first supported option common to both recipients in the light of new information about NSA and NIST this is an interesting topic new information 2013-09-13 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From mike_acker at charter.net Sun Sep 15 21:26:30 2013 From: mike_acker at charter.net (Mike Acker) Date: Sun, 15 Sep 2013 15:26:30 -0400 Subject: Preferred block cipher In-Reply-To: References: Message-ID: <523609E6.4090102@charter.net> On 09/07/2013 07:34 PM, gnupg-users-request at gnupg.org wrote: > Hi Mike, > > Interesting. Would you care to explain your logic as to why you set > the preferences in that particular order? > > In particular, why did you prioritize 3DES over the three AES > variants? I can understand being skeptical of CAMELLIA, as it was > developed commercially, though it has been approved for use by both > the Japanese CRYPTREC project and the European NESSIE project and is > widely available to researchers and cryptographers. That is, it's not > a black box. > > Similarly, AES is an open standard and went through rigorous review by > both government and the public cryptographic community. > > As far as I'm aware, all the ciphers used in GnuPG have no major, > publicly-known cryptographic weaknesses so the choice as to which ones > to use comes down more to a matter of personal preference and > compatibility reasons. > > -- Pete Stephenson Pete,-- I selected TWOFISH as first as that was developed by Bruce Schneier,-- and then not accepted by NIST -- and Bruce offers the source code. as far as the others go I just pushed the commercial ones toward the back: NEW INFO dated 2013-09-13: http://www.propublica.org/article/standards-agency-strongly-suggests-dropping-its-own-encryption-standard /mike -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 Sun Sep 15 23:08:20 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 15 Sep 2013 17:08:20 -0400 Subject: Preferred block cipher In-Reply-To: <523609E6.4090102@charter.net> References: <523609E6.4090102@charter.net> Message-ID: <523621C4.60204@sixdemonbag.org> On 09/15/2013 03:26 PM, Mike Acker wrote: > I selected TWOFISH as first as that was developed by Bruce Schneier Although Schneier is definitely one of the authors, he has in the past expressed a desire to see the other people of his research team credited. Twofish was designed by Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall and Niels Ferguson, all of whom are big names in the development of cryptographic algorithms. > and then not accepted by NIST -- and Bruce offers the source code. Although Schneier offers *an* implementation of Twofish, there is not a single canonical source representation. Twofish is an algorithm and there are many ways it can be implemented. Similarly, GnuPG only uses publicly-available algorithms. > as far as the others go I just pushed the commercial ones toward the > back: There are no proprietary algorithms in GnuPG. From rjh at sixdemonbag.org Sun Sep 15 23:09:50 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 15 Sep 2013 17:09:50 -0400 Subject: Setting Preference for Block Cipher In-Reply-To: <52360D18.2090403@charter.net> References: <52360D18.2090403@charter.net> Message-ID: <5236221E.1020704@sixdemonbag.org> On 09/15/2013 03:40 PM, Mike Acker wrote: > it is important to understand that the specification i have in MY key is > addressed to any party which may be sending to me. That's not how cipher-preference works. You are conflating the preferences listed *on the certificate* with the preferences listed in the gpg.conf file. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 518 bytes Desc: OpenPGP digital signature URL: From nicolai-gnupg at chocolatine.org Sun Sep 15 22:11:44 2013 From: nicolai-gnupg at chocolatine.org (Nicolai) Date: Sun, 15 Sep 2013 15:11:44 -0500 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <87fvt92oxs.fsf@vigenere.g10code.de> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> Message-ID: <20130915201144.GA13762@vectra.student.iastate.edu> On Fri, Sep 13, 2013 at 08:52:47AM +0200, Werner Koch wrote: > - I am thinking to switch to Curve25519 based algorithms. They have > been developed by Dan Bernstein et al. and are considered a sound > design. I am currently working on the implementation of the signature > scheme in Libgcrypt. Very nice. Support for Curve25519 would make me far more likely to use ECC in GnuPG. Doubts about NIST curves aside, it has security features not present in e.g. P-256. It's also a lot faster. Nicolai From johanw at vulcan.xs4all.nl Sun Sep 15 23:26:23 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 15 Sep 2013 23:26:23 +0200 Subject: Preferred block cipher In-Reply-To: <523609E6.4090102@charter.net> References: <523609E6.4090102@charter.net> Message-ID: <523625FF.80108@vulcan.xs4all.nl> On 9/15/2013 21:26, Mike Acker wrote: > I selected TWOFISH as first as that was developed by Bruce Schneier,-- > and then not accepted by NIST -- and Bruce offers the source code. All ciphers in GnuPG have freely available source code. How could they otherwise be implemented in a GPL program? -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From mailinglisten at hauke-laging.de Mon Sep 16 00:37:33 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 16 Sep 2013 00:37:33 +0200 Subject: How to find and verify a trust path? In-Reply-To: References: <52358D2F.8040700@digitalbrains.com> Message-ID: <7340442.Rm9S4y8ptH@inno.berlin.laging.de> Am So 15.09.2013, 21:11:04 schrieb Philip J?genstedt: > In very concrete terms, how can I determine which keys I need to > import so that the GnuPG dist sig (4F25E3B6) has full validity? > in order to find > the shortest paths and then manually import the keys to verify that it > is in fact true... The question does not make much sense IMHO because this is not only about importing keys but also about assigning certification trust to the keys along the path. In order to seriously assign certification trust to a key you have to know the key owner, the certification policy (for that key) and the security level of the mainkey. Why should you not already have imported a key if you have all these pieces of information available? Sounds to me like you are willing to assign certification trust to unknown keys just because you have to in order to advance in the signature path. 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 mike_acker at charter.net Mon Sep 16 01:23:16 2013 From: mike_acker at charter.net (Mike Acker) Date: Sun, 15 Sep 2013 19:23:16 -0400 Subject: Pgp key In-Reply-To: <00E88226-14A9-4D2A-A3E9-2BD78B178692@gmail.com> References: <00E88226-14A9-4D2A-A3E9-2BD78B178692@gmail.com> Message-ID: <52364164.4000206@charter.net> On 09/15/2013 12:54 PM, Jack Szary wrote: > I have someone's PGP key and he said to use that to send him information, how do I use his key to send him a message? > first off, are you Windows or Linux ? In Linux you should have GPG installed by deafult; in Windows you will need to go download gpg4win and install it once you have gpg in your system then get the Thunderbird e/mail client. again, in Linux (Ubuntu, or Mint at least ) -- Thunderbird will already be present. In Windows, you have to go download it and install it. setup and test your e/mail account. add your buddy to your address book Next you need to add the ENIGMAIL plug-in to Thunderbird . In Linux/Mint(15) I had to download the plug-in and install it manually; Windows or Ubuntu installed from the get -add-ons menu Next you need to generate a key-pair . use the KeyManagement option of Thunderbird from the OpenPGP drop-down Next you need to use key-management from Thunderbird to import the key that your buddy sent you now you can send a message to your buddy. after you have the message ready click the OpenPGP pull-down and check encrypt,sign,use pgp-mime, and ignore recipient rules the e/mail address you send to needs to match the e/mail address he has on his key -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike_acker at charter.net Mon Sep 16 01:07:43 2013 From: mike_acker at charter.net (Mike Acker) Date: Sun, 15 Sep 2013 19:07:43 -0400 Subject: Gnupg-users Digest, Vol 120, Issue 29 In-Reply-To: References: Message-ID: <52363DBF.5030303@charter.net> On 09/15/2013 05:05 PM, gnupg-users-request at gnupg.org wrote: > > On 09/15/2013 03:40 PM, Mike Acker wrote: >> > it is important to understand that the specification i have in MY key is >> > addressed to any party which may be sending to me. > That's not how cipher-preference works. You are conflating the > preferences listed *on the certificate* with the preferences listed in > the gpg.conf file. > > OK I'm trying to understand what the manual means: setpref string Set the list of user ID preferences to string for all (or just the selected) user IDs. Calling setpref with no arguments sets the preference list to the default (either built-in or set via --default-preference-list), and calling setpref with "none" as the argument sets an empty preference list. Use gpg2 --version to get a list of available algorithms. Note that while you can change the preferences on an attribute user ID (aka "photo ID"), GnuPG does not select keys via attribute user IDs so these preferences will not be used by GnuPG. When setting preferences, you should list the algorithms in the order which you'd like to see them used by someone else when encrypting a message to your key. If you don't include 3DES, it will be automatically added at the end. Note that there are many factors that go into choosing an algorithm (for example, your key may not be the only recipient), and so the remote OpenPGP application being used to send to you may or may not follow your exact chosen order for a given message. It will, however, only choose an algorithm that is present on the preference list of every recipient key. See also the INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS section below. the sending party will not have access to my gpg.conf file so that data cannot affect his selection of a block cipher when encrypting traffic to me. i could change gpg.conf -- but right now i don't see that that would do anything other than alter the default setting for preference -- possibly the output of --version -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 Mon Sep 16 10:00:19 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 16 Sep 2013 10:00:19 +0200 Subject: Preferred block cipher In-Reply-To: <52363DBF.5030303@charter.net> References: <52363DBF.5030303@charter.net> Message-ID: <5236BA93.509@digitalbrains.com> Hello Mike, First of all, /please/ fix your mail client. You are breaking the threads and inserting non-sensical Subject:-lines where you apparently reply to the digest instead of a mail inside the digest. Similary, lines like > On 09/15/2013 05:05 PM, gnupg-users-request at gnupg.org wrote: are confusing. When you reply to a message, it will normally refer to the mail you are replying to in its headers, such that mail clients can show the conversation in a threaded view. Your client currently does not refer to the mail you are replying to, meaning that a new thread starts where you are replying. It is then quite annoying to search for the corresponding thread to see what you're replying to. On 16/09/13 01:07, Mike Acker wrote: > I'm trying to understand what the manual means: > [...] > > the sending party will not have access to my gpg.conf file so that data cannot > affect his selection of a block cipher I'm not completely sure what Robert is referring to either, but the settings you published in the prefences on your public key are combined with the personal-cipher-preferences from the gpg.conf from the person sending you a message, along with the preferences of any other recipients. Note that setting a default-preference-list in gpg.conf will only affect any 'setpref's you do afterwards, just adding it to gpg.conf is not enough to actually set the preferences on your existing key. 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 Mon Sep 16 12:07:32 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 16 Sep 2013 12:07:32 +0200 Subject: How to find and verify a trust path? In-Reply-To: References: <52358D2F.8040700@digitalbrains.com> Message-ID: <5236D864.6040206@digitalbrains.com> On 15/09/13 21:11, Philip J?genstedt wrote: > In very concrete terms, how can I determine which keys I need to > import so that the GnuPG dist sig (4F25E3B6) has full validity? There are two ways to answer this. One: Did you read my post from April I linked to? I know it sounds like self-promotion, but it's just to avoid repeating myself too much.I think you misunderstand what makes a key valid. In order for it to be valid, it needs to be signed by one or more valid keys that you have assigned some ownertrust. Signatures themselves can chain, but ownertrust does not. You cannot make a key valid by downloading other keys. It can only become valid by being directly signed by people (keys) you trust. The second answer: > In very concrete terms, how can I determine which keys I need to > import so that the GnuPG dist sig (4F25E3B6) has full validity? As far as I can see, there are two solutions: 1) Meet with the owner of the key, satisfy yourself that he or she is indeed the owner, and sign the key. 2) In the list of signatures on the key, look for someone you know and at least marginally trust to do proper verification of key ownership. You then assign this key a certain amount of ownertrust, plus you need to make this key itself valid. To make it valid, follow this process again: either meet up with this person, or look for a signature on their key by someone you know. There is a maximum depth to the second form of the solution. It can span no more than 5 hops from your own key by default (max-cert-depth). I'm afraid there are no automated solutions[1] because ownertrust is something you decide, and the computer doesn't know who you know. The only "automated solution" is that you have the key for everyone you know and somewhat trust on your keyring: that way, GnuPG will immediately do the right thing, and compute validity for the downloaded key if it can be done. HTH, Peter. [1] Again, I don't take trust signatures into account because they are no part of the normal Web of Trust. -- 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 mwood at IUPUI.Edu Mon Sep 16 14:46:41 2013 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Mon, 16 Sep 2013 08:46:41 -0400 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <5233AB07.7040608@sixdemonbag.org> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> Message-ID: <20130916124641.GA7285@IUPUI.Edu> On Fri, Sep 13, 2013 at 08:17:11PM -0400, Robert J. Hansen wrote: > On 9/13/2013 6:20 PM, Werner Koch wrote: > > No, I am not aware of any discussions. QC resistant algorithms are not > > yet something we need to rush for. > > Although it hasn't hit the IETF WG mailing list, I know that some list > participants have had intermittent off-list conversations about lattice > cryptography and other QC-resistant crypto. I wouldn't say that it's a > subject of active discussion within the WG, but some individual WG > members are definitely keeping an eye on it. > > And let me give a big "d'accord!" to Werner's "we don't need to rush." On the one hand, we don't need to rush. On the other, it is good to see that people are thinking ahead, because I don't want to see matters come to a state in which we *do* need to rush. -- 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 rjh at sixdemonbag.org Mon Sep 16 15:17:23 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 16 Sep 2013 09:17:23 -0400 Subject: Preferred block cipher In-Reply-To: <5236BA93.509@digitalbrains.com> References: <52363DBF.5030303@charter.net> <5236BA93.509@digitalbrains.com> Message-ID: <523704E3.9060009@sixdemonbag.org> On 9/16/2013 4:00 AM, Peter Lebbing wrote: > I'm not completely sure what Robert is referring to either In Mike's original message he wrote: > i have altered my cipher preference list as follows ... which I interpreted to be his personal-cipher-preferences, not the preference set that's attached to a key. If my interpretation was in error, my apologies. From atair04 at googlemail.com Mon Sep 16 15:32:30 2013 From: atair04 at googlemail.com (atair) Date: Mon, 16 Sep 2013 13:32:30 +0000 Subject: Sign key and export for each UID Message-ID: Hi all, I'm now in the situation to sign one other's key for the first time. He signed mine some days ago and sent me an email "Your PGP key " to each UID of my key with an attached file "..signed-by-.asc". I know that I can use --sign to sign the key and then --export to export it, but I don't know how to do this for each UID (content of attached files differ). I also discovered, that there's a sign, lsign, ... in the interactive mode with --edit-key -- what are they for/how do they differ from normal --sign? To me, this seems like a standard procedure/template, is it? Where to get it? To me this looks pretty good, as it respects the signed person's freedom to publish the signature on the keyservers he/she wants to (and not me doing sth. with one others key). Thanks! From philip at foolip.org Mon Sep 16 17:45:27 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Mon, 16 Sep 2013 17:45:27 +0200 Subject: How to find and verify a trust path? In-Reply-To: <5236D864.6040206@digitalbrains.com> References: <52358D2F.8040700@digitalbrains.com> <5236D864.6040206@digitalbrains.com> Message-ID: On Mon, Sep 16, 2013 at 12:07 PM, Peter Lebbing wrote: > On 15/09/13 21:11, Philip J?genstedt wrote: >> In very concrete terms, how can I determine which keys I need to >> import so that the GnuPG dist sig (4F25E3B6) has full validity? > > As far as I can see, there are two solutions: > 1) Meet with the owner of the key, satisfy yourself that he or she is indeed the > owner, and sign the key. That would nice, yeah. > 2) In the list of signatures on the key, look for someone you know and at least > marginally trust to do proper verification of key ownership. You then assign > this key a certain amount of ownertrust, plus you need to make this key itself > valid. To make it valid, follow this process again: either meet up with this > person, or look for a signature on their key by someone you know. > > There is a maximum depth to the second form of the solution. It can span no more > than 5 hops from your own key by default (max-cert-depth). Right, I want to use the calculated validity, possibly with my own values for --completes-needed, --marginals-needed and --max-cert-depth. talks about this. I've tried (in a testing keyring) to sign and trust marginally 3 keys that have signed the GnuPG dist sig key, and it indeed results in full validity for that sig. However, it's not possible to proceed deeper than 1 step without assigning at least marginal trust in people I haven't met. Since --update-trustdb *does* ask me for ownertrust of the dist sig key in this scenario, I'm guessing that at least some people are willing to do that, and I can certainly see myself assigning marginal trust to some of these keys. > I'm afraid there are no automated solutions[1] because ownertrust is something > you decide, and the computer doesn't know who you know. The only "automated > solution" is that you have the key for everyone you know and somewhat trust on > your keyring: that way, GnuPG will immediately do the right thing, and compute > validity for the downloaded key if it can be done. What could certainly be automated is to find out if there are any signature paths, but since no one has stepped up yet I'm guessing key servers simply can't be queried for this information. http://pgp.cs.uu.nl/ can help for keys in the strong set, but requires a lot of manual work. If there are no good tools, what have others done to verify that they have a path to 4F25E3B6? -- Philip J?genstedt From peter at digitalbrains.com Mon Sep 16 20:11:52 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 16 Sep 2013 20:11:52 +0200 Subject: How to find and verify a trust path? In-Reply-To: References: <52358D2F.8040700@digitalbrains.com> <5236D864.6040206@digitalbrains.com> Message-ID: <523749E8.1050208@digitalbrains.com> On 16/09/13 17:45, Philip J?genstedt wrote: > However, it's not possible to proceed deeper than 1 step without assigning > at least marginal trust in people I haven't met. If you actually don't know these people, I'd say it would be unwise to assign them trust. Why trust a stranger? However, it is not out of the question to trust a person you haven't met, which is different from being aware who someone is. > Since --update-trustdb *does* ask me for ownertrust of the dist sig key in > this scenario, I'm guessing that at least some people are willing to do that Well, I'm not going by what some people are willing to do, but the idea is that you only assign trust for people you trust. Since you probably trust some people whose keys you haven't signed, it makes sense to ask the trust question for keys you haven't signed. Through signatures from trusted people, you can ascertain that a key belongs to a person, you don't need to sign it yourself for that. However, for that person to make other keys valid, you need to trust their judgement. The trust question is exactly that: do you trust that this person only signs keys he or she has properly verified? > I'm guessing key servers simply can't be queried for this information. I'm pretty sure they can't be directly queried for this information. > If there are no good tools, what have others done to verify that they have a > path to 4F25E3B6? Most of them probably did nothing, since it's useless other than for statistical fun. There is nothing to be gained from knowing one or more paths. Any "attacker" doesn't need to do much effort to create so many paths to that key it dwarves any other key by comparison. Is the validity of that key then somehow increased, because it has so many paths? 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 Mon Sep 16 20:23:43 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 16 Sep 2013 20:23:43 +0200 Subject: Sign key and export for each UID In-Reply-To: References: Message-ID: <52374CAF.5080402@digitalbrains.com> On 16/09/13 15:32, atair wrote: > I also discovered, that there's a sign, lsign, > ... in the interactive mode with --edit-key -- what are they for/how > do they differ from normal --sign? sign is for signatures that can be exported to other people and to keyservers. lsign is for local signatures, for which you need to be very explicit to export it. That way, the fact that you signed the key is known to you only, plus it prevents you from accidentally uploading it without the owner's consent. > To me, this seems like a standard procedure/template, is it? Where to get it? Most likely, it's caff or a derivative. caff, CA Fire and Forget, on Debian is in the package signing-party. I don't know about other distributions, and I certainly don't know about other OSes :). I think I saw two GUI derivatives coming by recently here on GnuPG-Users, but I can't find them now. 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 dougb at dougbarton.us Mon Sep 16 20:57:04 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 16 Sep 2013 11:57:04 -0700 Subject: Sign key and export for each UID In-Reply-To: References: Message-ID: <52375480.7020606@dougbarton.us> On 09/16/2013 06:32 AM, atair wrote: > Hi all, > > I'm now in the situation to sign one other's key for the first time. > He signed mine some days ago and sent me an email "Your PGP key > " to each UID of my key with an attached file > "..signed-by-.asc". > I know that I can use --sign to sign the key and then --export to > export it, but I don't know how to do this for each UID (content of > attached files differ). I also discovered, that there's a sign, lsign, > ... in the interactive mode with --edit-key -- what are they for/how > do they differ from normal --sign? > > To me, this seems like a standard procedure/template, is it? Where to get it? > To me this looks pretty good, as it respects the signed person's > freedom to publish the signature on the keyservers he/she wants to > (and not me doing sth. with one others key). The way that your signer did it is _a_ standard way to do it. CAFF is a very popular program for that, and there is another here that is also pretty good: http://www.phildev.net/pius/news.shtml I have another philosophy that works for me because I prefer not to sign uids that are not valid. I send encrypted e-mail to each uid with a pseudo-random string and ask the person to send me back the string in a signed message. That allows me to determine if the person has control of all 3 elements of the uid; the e-mail address, private, and public keys. As a pleasant side effect it also gives me a chance to judge their competence with PGP, which allows me to assign a better trust value to folks I did not previously know. I have the script to do this here: https://dougbarton.us/PGP/gen_challenges.html hope this helps, Doug From expires2013 at ymail.com Mon Sep 16 21:45:08 2013 From: expires2013 at ymail.com (MFPA) Date: Mon, 16 Sep 2013 20:45:08 +0100 Subject: Sign key and export for each UID In-Reply-To: <52375480.7020606@dougbarton.us> References: <52375480.7020606@dougbarton.us> Message-ID: <277626970.20130916204508@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 16 September 2013 at 7:57:04 PM, in , Doug Barton wrote: > I have another philosophy that works for me because I > prefer not to sign uids that are not valid. What, in your opinion, makes a UID "not valid?" > I send > encrypted e-mail to each uid with a pseudo-random > string and ask the person to send me back the string in > a signed message. That allows me to determine if the > person has control of all 3 elements of the uid; the > e-mail address, private, and public keys. I thought that as soon as a public key is published or shared, the person who created it no longer has control. - -- Best regards MFPA mailto:expires2013 at ymail.com I would like to help you out. Which way did you come in? -----BEGIN PGP SIGNATURE----- iQCVAwUBUjdf3aipC46tDG5pAQpGWAP/TKN0sQ5ouAyfFeE7PMniShbBg9ipK+Jo /DGUI6htci0tZz2c5aEYuFYfZMh3unAUltF/0UbsZQ1DQx7cn6GUrRR1IC2DiIaI JzeYC5bYKWi1Wv+MONr6686Y4ucbkC7yhJ2bNnL5kHR1Ygfv0uwoug5TXHM/AGRO GT1Y2Srukuc= =wJtK -----END PGP SIGNATURE----- From pete at heypete.com Mon Sep 16 22:20:45 2013 From: pete at heypete.com (Pete Stephenson) Date: Mon, 16 Sep 2013 22:20:45 +0200 Subject: Sign key and export for each UID In-Reply-To: <277626970.20130916204508@my_localhost> References: <52375480.7020606@dougbarton.us> <277626970.20130916204508@my_localhost> Message-ID: On Mon, Sep 16, 2013 at 9:45 PM, MFPA wrote: > On Monday 16 September 2013 at 7:57:04 PM, in > , Doug Barton wrote: >> I have another philosophy that works for me because I >> prefer not to sign uids that are not valid. > > What, in your opinion, makes a UID "not valid?" I can't speak for Doug, but I consider UIDs corresponding to no-longer-functioning email addresses to be invalid and won't sign them as I have no idea if the keyholder is the actual owner of that address. -- Pete Stephenson From dougb at dougbarton.us Mon Sep 16 22:29:10 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 16 Sep 2013 13:29:10 -0700 Subject: Sign key and export for each UID In-Reply-To: References: <52375480.7020606@dougbarton.us> <277626970.20130916204508@my_localhost> Message-ID: <52376A16.9080400@dougbarton.us> On 09/16/2013 01:20 PM, Pete Stephenson wrote: > On Mon, Sep 16, 2013 at 9:45 PM, MFPA wrote: >> On Monday 16 September 2013 at 7:57:04 PM, in >> , Doug Barton wrote: >>> I have another philosophy that works for me because I >>> prefer not to sign uids that are not valid. >> >> What, in your opinion, makes a UID "not valid?" > > I can't speak for Doug, but I consider UIDs corresponding to > no-longer-functioning email addresses to be invalid and won't sign > them as I have no idea if the keyholder is the actual owner of that > address. Yeah, failure of any of the 3 elements and I won't sign it. I take uids with no e-mail address on a case by case basis. FWIW, Doug From dougb at dougbarton.us Mon Sep 16 22:33:41 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 16 Sep 2013 13:33:41 -0700 Subject: Sign key and export for each UID In-Reply-To: <277626970.20130916204508@my_localhost> References: <52375480.7020606@dougbarton.us> <277626970.20130916204508@my_localhost> Message-ID: <52376B25.8010107@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/16/2013 12:45 PM, MFPA wrote: | Hi | | | On Monday 16 September 2013 at 7:57:04 PM, in | , Doug Barton wrote: | |> I send encrypted e-mail to each uid with a pseudo-random string |> and ask the person to send me back the string in a signed |> message. That allows me to determine if the person has control of |> all 3 elements of the uid; the e-mail address, private, and |> public keys. | | I thought that as soon as a public key is published or shared, the | person who created it no longer has control. That's one way to look at it. :) However you may be surprised at the number of people who participate in key signing parties that haven't the foggiest clue how PGP works. If I encrypt a message to their public key and they cannot read it, and/or they cannot sign a response, IMO they are not "in control" of their key; whether it is published or not. Feel free to substitute other terminology if you wish, hopefully the concept is clear. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSN2slAAoJEFzGhvEaGryEPUEH/0+Bowo2Oqp9QcylketWRQI6 ty0xyCcxdII3xLSub5A3zCNlSbKeUZCyRQKNJRtu4Oz4zbsg+V5PdrEpKqfNT9ek cTSLXP5ez7QzBZ6lbghLeSwGjoXF8mt8EjDo2yj2HRZWN/1ocbL7SAC41EtCBTC8 n04T1Xv+jcaWusHL5PisalJASS7Bk3AAgqBlNPOmJbQo1jOrUOekZ3mRivwyKTD3 Om+lgQI+xrEUqI+4HYfUtrS+E5e2HdEe9x0ZcshvB/MhAPcd18pZ16OtnVXU70uJ bAP7AW23NQNffLqrSyTenuGuXt8MxporY+asCVptk1857J1JiVRCX89X0ZekQlY= =6etn -----END PGP SIGNATURE----- From philip at foolip.org Mon Sep 16 22:37:52 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Mon, 16 Sep 2013 22:37:52 +0200 Subject: How to find and verify a trust path? In-Reply-To: <523749E8.1050208@digitalbrains.com> References: <52358D2F.8040700@digitalbrains.com> <5236D864.6040206@digitalbrains.com> <523749E8.1050208@digitalbrains.com> Message-ID: On Mon, Sep 16, 2013 at 8:11 PM, Peter Lebbing wrote: > On 16/09/13 17:45, Philip J?genstedt wrote: >> I'm guessing key servers simply can't be queried for this information. > > I'm pretty sure they can't be directly queried for this information. Too bad. I guess one could do it by starting at the destination and following signatures back using a shortest path algorithm and a lot of requests to the keyserver, though. >> If there are no good tools, what have others done to verify that they have a >> path to 4F25E3B6? > > Most of them probably did nothing, since it's useless other than for statistical > fun. There is nothing to be gained from knowing one or more paths. > > Any "attacker" doesn't need to do much effort to create so many paths to that > key it dwarves any other key by comparison. Is the validity of that key then > somehow increased, because it has so many paths? How would an attacker create n independent paths without deceiving n people? says: "At one extreme you may insist on multiple, short paths from your key to another key K in order to trust it. On the other hand, you may be satisfied with longer paths and perhaps as little as one path from your key to the other key K. Requiring multiple, short paths is a strong guarantee that K belongs to whom your think it does. The price, of course, is that it is more difficult to validate keys since you must personally sign more keys than if you accepted fewer and longer paths." Having multiple, short paths to a key would increase my confidence, even if it's not as good as face-to-face verification. When I'm about to compile some software and install it on a public server, that's useful to me. Am I doing it wrong? -- Philip J?genstedt From peter at digitalbrains.com Mon Sep 16 23:00:22 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 16 Sep 2013 23:00:22 +0200 Subject: How to find and verify a trust path? In-Reply-To: References: <52358D2F.8040700@digitalbrains.com> <5236D864.6040206@digitalbrains.com> <523749E8.1050208@digitalbrains.com> Message-ID: <52377166.9010408@digitalbrains.com> On 16/09/13 22:37, Philip J?genstedt wrote: > Too bad. I guess one could do it by starting at the destination and > following signatures back using a shortest path algorithm and a lot of > requests to the keyserver, though. Dijkstra's shortest path algorithm would amount to a breadth first search. Keyserver operators might not like that, I dunno. > How would an attacker create n independent paths without deceiving n people? Errrrr..... by creating n keys and uploading them to the keyserver? 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 kloecker at kde.org Mon Sep 16 23:18:50 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 16 Sep 2013 23:18:50 +0200 Subject: Sign key and export for each UID In-Reply-To: <52375480.7020606@dougbarton.us> References: <52375480.7020606@dougbarton.us> Message-ID: <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> On Monday 16 September 2013 11:57:04 Doug Barton wrote: > The way that your signer did it is _a_ standard way to do it. CAFF is > a very popular program for that, and there is another here that is > also pretty good: http://www.phildev.net/pius/news.shtml > > I have another philosophy that works for me because I prefer not to > sign uids that are not valid. I send encrypted e-mail to each uid > with a pseudo-random string and ask the person to send me back the > string in a signed message. That allows me to determine if the person > has control of all 3 elements of the uid; the e-mail address, > private, and public keys. CAFF (and apparently also PIUS) achieve same: A signed UID is sent encrypted to the UID's email address. The signature on the UID can only be retrieved by a person who controls the email address and the private key. What do you mean by having control of the public key? How does your workflow verify that the person has control of the public key? AFAICS the public key is not needed for anything in your workflow. > As a pleasant side effect it also gives me > a chance to judge their competence with PGP, which allows me to > assign a better trust value to folks I did not previously know. Granted, this is an advantage your workflow has over CAFF, but I'm not sure it's worth the additional work of verifying all replies and then selectively signing UIDs. I've been there and have done this, but CAFF is just a lot less of a hassle without losing much (if anything). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Mon Sep 16 23:27:36 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 16 Sep 2013 23:27:36 +0200 Subject: How to find and verify a trust path? In-Reply-To: <52377166.9010408@digitalbrains.com> References: <52377166.9010408@digitalbrains.com> Message-ID: <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> On Monday 16 September 2013 23:00:22 Peter Lebbing wrote: > On 16/09/13 22:37, Philip J?genstedt wrote: > > Too bad. I guess one could do it by starting at the destination and > > following signatures back using a shortest path algorithm and a lot > > of requests to the keyserver, though. > > Dijkstra's shortest path algorithm would amount to a breadth first > search. Keyserver operators might not like that, I dunno. > > > How would an attacker create n independent paths without deceiving n > > people? > > Errrrr..... by creating n keys and uploading them to the keyserver? I thought the same, but that won't work. The independent paths need to be completely disjoint (except for start and end point) _and_ they all need to start with Philip's key. The attacker would have to trick Philip into signing all n keys. Or he would have to trick n people whose keys Philip has signed (directly or indirectly) into signing his n keys. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dougb at dougbarton.us Mon Sep 16 23:33:59 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 16 Sep 2013 14:33:59 -0700 Subject: Sign key and export for each UID In-Reply-To: <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> References: <52375480.7020606@dougbarton.us> <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> Message-ID: <52377947.4010705@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FYI, the signature on your message did not verify for me in thunderbird, although others you have sent do. On 09/16/2013 02:18 PM, Ingo Kl?cker wrote: | On Monday 16 September 2013 11:57:04 Doug Barton wrote: |> The way that your signer did it is _a_ standard way to do it. CAFF is |> a very popular program for that, and there is another here that is |> also pretty good: http://www.phildev.net/pius/news.shtml |> |> I have another philosophy that works for me because I prefer not to |> sign uids that are not valid. I send encrypted e-mail to each uid |> with a pseudo-random string and ask the person to send me back the |> string in a signed message. That allows me to determine if the person |> has control of all 3 elements of the uid; the e-mail address, |> private, and public keys. | | CAFF (and apparently also PIUS) achieve same I'm familiar with how those tools work. However what I don't like about them is that they can either leave behind signatures that I consider bogus on my local key ring, or require that the user correctly deal with the signatures I send, and upload them to a public key server, for me to later download. I prefer to keep my personal key rings reflective of my judgement about the keys/uids, regardless of how the user chooses to deal with the signatures. But that's my choice, reasonable minds can differ. |> As a pleasant side effect it also gives me |> a chance to judge their competence with PGP, which allows me to |> assign a better trust value to folks I did not previously know. | | Granted, this is an advantage your workflow has over CAFF, but I'm not | sure it's worth the additional work of verifying all replies and then | selectively signing UIDs. Like I said, reasonable minds can differ. I personally don't find it all that burdensome to select the uids that I am willing to sign when I get the responses back. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSN3lHAAoJEFzGhvEaGryEyewIAMITKi9kTCgOHIZpGjLd9NAI Jx7Pt6xPYTK33gRhC8puOUpw8337FvXiQFH9/SiHw/gNLt9RHruIPq1nzE4UNV8P Cv0qGOJrYuhdL8ASdOfG67HP1dFkYOy4RQPGNhoZAf3bcdG67I26t7FvciIy9o+r xMx/I9W3hN9aANZ7VK5xGIcij7m19NRjjYECERRnOCNbSe+qh/4km7GYfQvB1W9c mhIpwBnpKIqAqfHLr3nyrMjgYWXjxT52Y0YaXmE5xaRq+Xd909cRNi/hdLJyf12F ILylfvSWp9k2R4kyFI/Ki0L1dEEqJLsK0k+kgI2N3+fFbcq7pQOI9utEUv8GYlY= =pvv2 -----END PGP SIGNATURE----- From pkk at spth.de Tue Sep 17 00:02:14 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Tue, 17 Sep 2013 00:02:14 +0200 Subject: Sign key and export for each UID In-Reply-To: <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> References: <52375480.7020606@dougbarton.us> <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> Message-ID: <52377FE6.1070903@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 16.09.2013 23:18, schrieb Ingo Kl?cker: > On Monday 16 September 2013 11:57:04 Doug Barton wrote: >> The way that your signer did it is _a_ standard way to do it. >> CAFF is a very popular program for that, and there is another >> here that is also pretty good: >> http://www.phildev.net/pius/news.shtml >> >> I have another philosophy that works for me because I prefer not >> to sign uids that are not valid. I send encrypted e-mail to each >> uid with a pseudo-random string and ask the person to send me >> back the string in a signed message. That allows me to determine >> if the person has control of all 3 elements of the uid; the >> e-mail address, private, and public keys. > > CAFF (and apparently also PIUS) achieve same: A signed UID is sent > encrypted to the UID's email address. The signature on the UID can > only be retrieved by a person who controls the email address and > the private key. What do you mean by having control of the public > key? How does your workflow verify that the person has control of > the public key? AFAICS the public key is not needed for anything in > your workflow. Unfortunately, tools for signing keys with multiple UIDs IMO are not user-friendly enough, tpically due to the following: 1) They require the user to be familiar with the command-line, 2) They require the user to run a unixoid OS, 3) They require the user to have configured mail for their OS. IMO, until the functionality to sign keys with multiple UIDs and send each signature to the associated UID gets integrated into mailclients or their plugins, keys with multiple UIDs should not be used. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlI3f+IACgkQbtUV+xsoLpqOiQCfd101zScXpxbkM09fw6H8j71f in4AnRWnG3YdXewXoZ5UxnLmFfWXWQRx =l165 -----END PGP SIGNATURE----- From dougb at dougbarton.us Tue Sep 17 02:09:49 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 16 Sep 2013 17:09:49 -0700 Subject: Sign key and export for each UID In-Reply-To: <52377FE6.1070903@spth.de> References: <52375480.7020606@dougbarton.us> <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> <52377FE6.1070903@spth.de> Message-ID: <52379DCD.4000300@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/16/2013 03:02 PM, Philipp Klaus Krause wrote: | Unfortunately, tools for signing keys with multiple UIDs IMO are not | user-friendly enough, tpically due to the following: | | 1) They require the user to be familiar with the command-line, | 2) They require the user to run a unixoid OS, | 3) They require the user to have configured mail for their OS. I would argue that this is true regardless of the number of uids on a key. I do use PGP with Windows, but I also use the command line there. I do not know of any software that has a competent GUI that does everything I would want it to do, or even a reasonable subset of it. I would find it interesting to be proven wrong however. :) | IMO, until the functionality to sign keys with multiple UIDs and send | each signature to the associated UID gets integrated into mailclients | or their plugins, keys with multiple UIDs should not be used. Given that your opinion is contrary to that of just about everyone else, it seems to lie with you to provide said patches for said mail clients. Frequently restating your opinion doesn't make it any more valid. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSN53NAAoJEFzGhvEaGryE3pMH/iGzeaunfsorVQrlHg4XOUJ7 f3uRPdkAzhA2MJ+36QbpW0ZHNNpsXeGvv9D3gF6qcFu14/TtPTI6Kzbgn1zJJZhD VnQ2wv1YgT06cq1X5lDeq6uZkztjerkV5KEQTi2gsMO9e3L0zECTXPnkjJ0021Oc 2FBdXgVHY6UTbRNKfl/WLQ5BYE+uqQSvJQNmL/2MUBLRWT04fw4UC8htNd05Rnuh tVt8IiKnd2PDNuuQMW+6N3GJoN9ADjuyWeyzYbjwnwBmaKy024FanXnhLmV2F9rj WDWn20ehAHCcLC1a2G0BV+MmiDz4zsOPcCLORXZxHXcyeO3LMdYoqCYxUL1S/O4= =THY8 -----END PGP SIGNATURE----- From atair04 at googlemail.com Tue Sep 17 08:23:35 2013 From: atair04 at googlemail.com (atair) Date: Tue, 17 Sep 2013 06:23:35 +0000 Subject: Sign key and export for each UID In-Reply-To: <52375480.7020606@dougbarton.us> References: <52375480.7020606@dougbarton.us> Message-ID: On 9/16/13, Doug Barton wrote: > The way that your signer did it is _a_ standard way to do it. CAFF is a > very popular program for that, and there is another here that is also > pretty good: http://www.phildev.net/pius/news.shtml Is there a way to achieve the same signatures from gpg command line? For example $ gpg -a --export exports the complete key and not just the signature. However, I understand the gpg-man pages in a way that it's possible to do a $ gpg -u --edit-key > sign > sign > ... > q Is that true? How could I export the created signature for each step? (sth like an "-a --export " but from interactive mode seems not to be present...) BTW: I'm on GNU/Linux for some years now and I'd never use Windows again ;) So personally, I don't care whether these tools exist for Windows or not... > I have another philosophy that works for me because I prefer not to sign > uids that are not valid. I send encrypted e-mail to each uid with a > pseudo-random string and ask the person to send me back the string in a > signed message. That allows me to determine if the person has control of > all 3 elements of the uid; the e-mail address, private, and public keys. > As a pleasant side effect it also gives me a chance to judge their > competence with PGP, which allows me to assign a better trust value to > folks I did not previously know. seems reasonable, although there's an overhead for this 3-way-handshake (but usually you don't sign keys on a daily basis, so that doesn't really matter :) > I have the script to do this here: > https://dougbarton.us/PGP/gen_challenges.html Probably I just overlooked it, but I could not find where the per-uid signatures are created/exported. -- atair From pkk at spth.de Tue Sep 17 08:57:16 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Tue, 17 Sep 2013 08:57:16 +0200 Subject: Sign key and export for each UID In-Reply-To: References: <52375480.7020606@dougbarton.us> Message-ID: <5237FD4C.1000803@spth.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 17.09.2013 08:23, schrieb atair: > On 9/16/13, Doug Barton wrote: >> The way that your signer did it is _a_ standard way to do it. >> CAFF is a very popular program for that, and there is another >> here that is also pretty good: >> http://www.phildev.net/pius/news.shtml > Is there a way to achieve the same signatures from gpg command > line? For example $ gpg -a --export exports the complete key > and not just the signature. However, I understand the gpg-man pages > in a way that it's possible to do a $ gpg -u --edit-key > >> sign sign ... q > Is that true? How could I export the created signature for each > step? (sth like an "-a --export " but from interactive mode > seems not to be present...) See section "Multiple-UID keys" on http://www.phildev.net/pgp/gpgsigning.html wich was written by the author of pius. > > BTW: I'm on GNU/Linux for some years now and I'd never use Windows > again ;) So personally, I don't care whether these tools exist for > Windows or not... > Independent of me using Windows or not, I still want Windows users to be able to sign my keys. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlI3/UkACgkQbtUV+xsoLppMYwCgsc13iE9hUcoBxNjX2OZ7cxhs l1sAniaDiK6XVfYEhwFaOjt2Ly0GEjXX =63e/ -----END PGP SIGNATURE----- From atair04 at googlemail.com Tue Sep 17 09:42:14 2013 From: atair04 at googlemail.com (atair) Date: Tue, 17 Sep 2013 07:42:14 +0000 Subject: Sign key and export for each UID In-Reply-To: <5237FD4C.1000803@spth.de> References: <52375480.7020606@dougbarton.us> <5237FD4C.1000803@spth.de> Message-ID: > See section "Multiple-UID keys" on > http://www.phildev.net/pgp/gpgsigning.html > wich was written by the author of pius. Thanks! That's what I looked for. >> BTW: I'm on GNU/Linux for some years now and I'd never use Windows >> again ;) So personally, I don't care whether these tools exist for >> Windows or not... > Independent of me using Windows or not, I still want Windows users to > be able to sign my keys. Sure, there should be a way to have the same functionality on all platforms. I just wanted to say that there're good reasons (handy tools, infrastructure, improvements are accessible to all users/community,...) to use GNU/linux instead of Windows. -- atair From peter at digitalbrains.com Tue Sep 17 11:07:04 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 17 Sep 2013 11:07:04 +0200 Subject: How to find and verify a trust path? In-Reply-To: <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> Message-ID: <52381BB8.5090802@digitalbrains.com> On 16/09/13 23:27, Ingo Kl?cker wrote: > The independent paths need to be completely disjoint (except for start and > end point) _and_ they all need to start with Philip's key. AFAIK, there is no such requirement in the Web of Trust. I've never heard of it. 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 Tue Sep 17 11:25:56 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 17 Sep 2013 11:25:56 +0200 Subject: Sign key and export for each UID In-Reply-To: <52377FE6.1070903@spth.de> References: <52375480.7020606@dougbarton.us> <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> <52377FE6.1070903@spth.de> Message-ID: <52382024.5000001@digitalbrains.com> On 17/09/13 00:02, Philipp Klaus Krause wrote: > 1) They require the user to be familiar with the command-line, I've "found" the GUI tool that I mentioned: http://lists.gnupg.org/pipermail/gnupg-users/2013-September/047407.html My biggest feature request for caff is Debian Bug 680136[1]: Additionally create a local signature on the user's keyring, so that you can strengthen your own Web of Trust regardless of whether the other chooses to upload your signature to the keyservers or not. I thought I saw a tool that did this a short while back... but I can't find it anymore... Peter. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680136 -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Tue Sep 17 11:38:55 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 17 Sep 2013 11:38:55 +0200 Subject: How to find and verify a trust path? In-Reply-To: <52381BB8.5090802@digitalbrains.com> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> Message-ID: <5238232F.6070400@digitalbrains.com> On 17/09/13 11:07, Peter Lebbing wrote: >> The independent paths need to be completely disjoint (except for start and >> end point) _and_ they all need to start with Philip's key. > > AFAIK, there is no such requirement in the Web of Trust. I've never heard of it. Euh... apart from the part where you said they need to start with Philip's key. I didn't trim the quote far enough :). I meant there is no requirement that the paths are independent. 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 Tue Sep 17 15:21:53 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Sep 2013 09:21:53 -0400 Subject: Sign key and export for each UID In-Reply-To: <52377FE6.1070903@spth.de> References: <52375480.7020606@dougbarton.us> <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> <52377FE6.1070903@spth.de> Message-ID: <52385771.4050809@fifthhorseman.net> On 09/16/2013 06:02 PM, Philipp Klaus Krause wrote: > Unfortunately, tools for signing keys with multiple UIDs IMO are not > user-friendly enough, tpically due to the following: > > 1) They require the user to be familiar with the command-line, > 2) They require the user to run a unixoid OS, > 3) They require the user to have configured mail for their OS. Again, please see Monkeysign [0] -- it is under active development, and it aims to address problems 1 and 3 explicitly. It is written in python, so it is possible that someone who actually uses a Windows platform and has sufficient motivation and time could sort out what is needed to port it to a non-unix OS. If you would like to help solve these problems, i'm sure the monkeysign developers would be really happy to have your help. You can follow up about monkeysign on the monkeysphere mailing list: Monkeysphere Developers Thanks for thinking about and trying to solve these critical problems. Regards, --dkg [0] http://web.monkeysphere.info/monkeysign -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From philip at foolip.org Tue Sep 17 15:56:32 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Tue, 17 Sep 2013 15:56:32 +0200 Subject: How to find and verify a trust path? In-Reply-To: <5238232F.6070400@digitalbrains.com> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> Message-ID: On Tue, Sep 17, 2013 at 11:38 AM, Peter Lebbing wrote: > On 17/09/13 11:07, Peter Lebbing wrote: >>> The independent paths need to be completely disjoint (except for start and >>> end point) _and_ they all need to start with Philip's key. >> >> AFAIK, there is no such requirement in the Web of Trust. I've never heard of it. > > Euh... apart from the part where you said they need to start with Philip's key. > I didn't trim the quote far enough :). I meant there is no requirement that the > paths are independent. Going with the GnuPG built-on model, it seems like I can get the "n people would need to be deceived" effect by (in a temporary keyring) assigning marginal trust to all keys in the world and --marginals-needed n, without requiring the paths to be independent. Does that sound right? -- Philip J?genstedt From dkg at fifthhorseman.net Tue Sep 17 16:17:11 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Sep 2013 10:17:11 -0400 Subject: How to find and verify a trust path? In-Reply-To: References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> Message-ID: <52386467.5040908@fifthhorseman.net> On 09/17/2013 09:56 AM, Philip J?genstedt wrote: > Going with the GnuPG built-on model, it seems like I can get the "n > people would need to be deceived" effect by (in a temporary keyring) > assigning marginal trust to all keys in the world and > --marginals-needed n, without requiring the paths to be independent. > Does that sound right? No, it doesn't sound right because one key ? one person. It is possible for one person to hold many keys. If I hold n keys, and i certify with all of them, and you grant all my keys marginal ownertrust, then all it takes is 1 person to be deceived (me) and you will be misled. I won't even go into here the difference between "n people would need to be deceived" and "n people would need to be (convinced to be) malicious", but it's worth considering what your actual threat model is. Trust is not a mechanical or universal process. Different people have different perspectives, different information, different allies, and different adversaries. Any system which claims that there is a universal trust perspective would need some *very* convincing (and highly surprising) arguments to seem plausible. 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 mailinglisten at hauke-laging.de Tue Sep 17 16:29:08 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 17 Sep 2013 16:29:08 +0200 Subject: How to find and verify a trust path? In-Reply-To: <52386467.5040908@fifthhorseman.net> References: <52386467.5040908@fifthhorseman.net> Message-ID: <1914387.1huCfnxJaF@inno.berlin.laging.de> Am Di 17.09.2013, 10:17:11 schrieb Daniel Kahn Gillmor: > No, it doesn't sound right because one key ? one person. It is possible > for one person to hold many keys. > > If I hold n keys, and i certify with all of them, and you grant all my > keys marginal ownertrust, then all it takes is 1 person to be deceived > (me) and you will be misled. Thus quite some time ago somebody (not me) asked for a new feature (without success): Keys should be grouped by their owner so that each person's certifications are counted once only. 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 peter at digitalbrains.com Tue Sep 17 20:02:06 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 17 Sep 2013 20:02:06 +0200 Subject: Sign key and export for each UID In-Reply-To: <52385771.4050809@fifthhorseman.net> References: <52375480.7020606@dougbarton.us> <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> <52377FE6.1070903@spth.de> <52385771.4050809@fifthhorseman.net> Message-ID: <5238991E.9030702@digitalbrains.com> On 17/09/13 15:21, Daniel Kahn Gillmor wrote: > Again, please see Monkeysign [0] Thank you, bookmarking it now. That was the one I couldn't remember. 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 kwadronaut at aktivix.org Tue Sep 17 20:21:38 2013 From: kwadronaut at aktivix.org (kwadronaut) Date: Tue, 17 Sep 2013 20:21:38 +0200 Subject: Signature timestamp ordering and dissecting Message-ID: <52389DB2.9070005@aktivix.org> Hi, Up until now, I always see signatures on a key ordered in chronological fashion, with GnuPG, sks' web interface and enigmail. It's always in a format with day, month and year (sometimes year-month-day or another format of that data). Now I'm curious to see when a signature has *exactly* been made. Can I see the exact time stamp of individual signatures? And the next question would be: how? And: is there any specific rationale behind ordering the signatures in a chronological way? Can signatures be made at the exact same time? ciao, kwadronaut [Being curious] From rookcifer at gmail.com Tue Sep 17 20:23:56 2013 From: rookcifer at gmail.com (Roflcopter) Date: Tue, 17 Sep 2013 11:23:56 -0700 (PDT) Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <20130916124641.GA7285@IUPUI.Edu> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> Message-ID: <1379442236204-32563.post@n7.nabble.com> I second this motion. After the recent revelations about NSA shenanigans regarding NIST and with Bruce Schneier himself saying he is highly suspicious of NIST curves, I think it behooves the OpenPGP standards group to think about alternative curves. Of course, some users of OpenPGP will need NIST compliance, and that's fine. It can still be included as long as the rest of us (who don't like being played for fools) have alternatives available. I don't think there is a better place to start than with djb's curve25519. It is faster than the NIST curves, can be shown to have "nothing up the sleeve" and appears to be quite secure. Djb even gave a talk a number of years ago where he compared it to NIST curves and even raised his own suspicions about how those curves were generated. Moreover, djb has provided a lot of reference implementations for it (with full C code) on his site, thus implementation is more of a "will to do it" than a technical challenge. It's good to see that Werner has already made the suggestion to implement different curves. Let's hope that the OpenPGP working group agrees with his recommendation and that we can finally see (non-tampered with) ECC put into use in Gnupg. -- View this message in context: http://gnupg.10057.n7.nabble.com/Support-for-additional-ECC-Curves-in-GnuPG-gcrypt-tp32408p32563.html Sent from the GnuPG - User mailing list archive at Nabble.com. From dkg at fifthhorseman.net Tue Sep 17 21:17:55 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Sep 2013 15:17:55 -0400 Subject: Signature timestamp ordering and dissecting In-Reply-To: <52389DB2.9070005@aktivix.org> References: <52389DB2.9070005@aktivix.org> Message-ID: <5238AAE3.70001@fifthhorseman.net> On 09/17/2013 02:21 PM, kwadronaut wrote: > Up until now, I always see signatures on a key ordered in chronological > fashion, with GnuPG, sks' web interface and enigmail. It's always in a > format with day, month and year (sometimes year-month-day or another > format of that data). Now I'm curious to see when a signature has > *exactly* been made. Can I see the exact time stamp of individual > signatures? And the next question would be: how? And: is there any > specific rationale behind ordering the signatures in a chronological > way? Can signatures be made at the exact same time? You can see seconds since the unix epoch (which is the only timestamp granularity supported by RFC 4880) by using GnuPG's --with-colons argument (incidentally, this is also nice because it is machine-parseable, and does not vary across locales). When using --with-colons, you probably also want to be sure to include --fixed-list-mode. For more info, read DETAILS from the source (or /usr/share/doc/gnupg/DETAILS.gz on debian-derived systems). 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 philip at foolip.org Tue Sep 17 22:01:00 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Tue, 17 Sep 2013 22:01:00 +0200 Subject: How to find and verify a trust path? In-Reply-To: <52386467.5040908@fifthhorseman.net> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> Message-ID: On Tue, Sep 17, 2013 at 4:17 PM, Daniel Kahn Gillmor wrote: > On 09/17/2013 09:56 AM, Philip J?genstedt wrote: > >> Going with the GnuPG built-on model, it seems like I can get the "n >> people would need to be deceived" effect by (in a temporary keyring) >> assigning marginal trust to all keys in the world and >> --marginals-needed n, without requiring the paths to be independent. >> Does that sound right? > > No, it doesn't sound right because one key ? one person. It is possible > for one person to hold many keys. > > If I hold n keys, and i certify with all of them, and you grant all my > keys marginal ownertrust, then all it takes is 1 person to be deceived > (me) and you will be misled. That's a good point. So, if you have a tool to find signature paths, it could also show a sorted list of the keys which you are trusting to some non-zero degree. If similar/identical names show up, you investigate. > I won't even go into here the difference between "n people would need to > be deceived" and "n people would need to be (convinced to be) > malicious", but it's worth considering what your actual threat model is. > > Trust is not a mechanical or universal process. Different people have > different perspectives, different information, different allies, and > different adversaries. Any system which claims that there is a > universal trust perspective would need some *very* convincing (and > highly surprising) arguments to seem plausible. That's fine, I'm just trying to figure out what others do to convince themselves that (e.g.) the GnuPG dist sig key is trustworthy-ish and if there are any tools to help with the boring bits. -- Philip J?genstedt From wk at gnupg.org Wed Sep 18 09:06:37 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Sep 2013 09:06:37 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <1379442236204-32563.post@n7.nabble.com> (Roflcopter's message of "Tue, 17 Sep 2013 11:23:56 -0700 (PDT)") References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> <1379442236204-32563.post@n7.nabble.com> Message-ID: <87ioxywqv6.fsf@vigenere.g10code.de> On Tue, 17 Sep 2013 20:23, rookcifer at gmail.com said: > It's good to see that Werner has already made the suggestion to implement > different curves. Let's hope that the OpenPGP working group agrees with his The standard already allows for all kind of curses. They are specified by an OID and I offered DJB to assign OIDs from the GnuPG arc. The original reason why I wanted an OID based design is so that it will be possible to use Brainpool curves which are preferred by some European institutions. I rejected the idea to make them the default in GnuPG to support better interoperability but also told people that we change the default as soon as we see people are using other curves. Meanwhile I don't think that we need a pool to settle on a different default. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From josef at netpage.dk Wed Sep 18 10:33:21 2013 From: josef at netpage.dk (Josef Schneider) Date: Wed, 18 Sep 2013 10:33:21 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <87ioxywqv6.fsf@vigenere.g10code.de> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> <1379442236204-32563.post@n7.nabble.com> <87ioxywqv6.fsf@vigenere.g10code.de> Message-ID: On Wed, Sep 18, 2013 at 9:06 AM, Werner Koch wrote: > The standard already allows for all kind of curses. They are specified > by an OID and I offered DJB to assign OIDs from the GnuPG arc. The > original reason why I wanted an OID based design is so that it will be > possible to use Brainpool curves which are preferred by some European > institutions. I rejected the idea to make them the default in GnuPG to > support better interoperability but also told people that we change the > default as soon as we see people are using other curves. Meanwhile I > don't think that we need a pool to settle on a different default. Is there a way to say someone should under no circumstances send a message to me that is encrypted with a NIST curve? Even if that means, that he can't find a encryption for the message? From pkk at spth.de Wed Sep 18 10:46:24 2013 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 18 Sep 2013 10:46:24 +0200 Subject: Sign key and export for each UID In-Reply-To: <52379DCD.4000300@dougbarton.us> References: <52375480.7020606@dougbarton.us> <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> <52377FE6.1070903@spth.de> <52379DCD.4000300@dougbarton.us> Message-ID: <52396860.901@spth.de> Am 17.09.2013 02:09, schrieb Doug Barton: > On 09/16/2013 03:02 PM, Philipp Klaus Krause wrote: > | Unfortunately, tools for signing keys with multiple UIDs IMO are not > | user-friendly enough, tpically due to the following: > | > | 1) They require the user to be familiar with the command-line, > | 2) They require the user to run a unixoid OS, > | 3) They require the user to have configured mail for their OS. > > I would argue that this is true regardless of the number of uids on a > key. I do use PGP with Windows, but I also use the command line there. I > do not know of any software that has a competent GUI that does > everything I would want it to do, or even a reasonable subset of it. I > would find it interesting to be proven wrong however. :) Well, IMO enigmail does a somewaht resonable job for single-uid keys, since users can in the GUI right-click and select to sign a key (and the GUI lets them select the level of verification using radio boxes selecting from textual descriptions, instead of asking for a number, like pius does). And then they can right-click and select to send the public key. This is not optimal, as it requires two steps, and requires filling in the receivers email address manually. While I don't use Windows, AFAIK, this works the same on Windows as on other systems. It only requires mail to be configured in the mail client (which every user that runs a mail client has done), as opposed to the OS level. Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From nicholas.cole at gmail.com Wed Sep 18 10:54:59 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 18 Sep 2013 09:54:59 +0100 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> <1379442236204-32563.post@n7.nabble.com> <87ioxywqv6.fsf@vigenere.g10code.de> Message-ID: On Wed, Sep 18, 2013 at 9:33 AM, Josef Schneider wrote: > On Wed, Sep 18, 2013 at 9:06 AM, Werner Koch wrote: > >> The standard already allows for all kind of curses. They are specified >> by an OID and I offered DJB to assign OIDs from the GnuPG arc. The >> original reason why I wanted an OID based design is so that it will be >> possible to use Brainpool curves which are preferred by some European >> institutions. I rejected the idea to make them the default in GnuPG to >> support better interoperability but also told people that we change the >> default as soon as we see people are using other curves. Meanwhile I >> don't think that we need a pool to settle on a different default. > > Is there a way to say someone should under no circumstances send a > message to me that is encrypted with a NIST curve? > Even if that means, that he can't find a encryption for the message? If I understand correctly, the curve is used to create the Public/Private Keypair. So GPG probably needs to display clearly (in the --with-colons output and in the user-facing output) the curve used to create the key (if that is possible) so that people can make a judgement about that kind of thing when they certify keys -- assuming it matters to them. Or have I got that wrong? N. From John at enigmail.net Wed Sep 18 15:28:42 2013 From: John at enigmail.net (John Clizbe) Date: Wed, 18 Sep 2013 08:28:42 -0500 Subject: Signature timestamp ordering and dissecting In-Reply-To: <52389DB2.9070005@aktivix.org> References: <52389DB2.9070005@aktivix.org> Message-ID: <5239AA8A.4090507@enigmail.net> kwadronaut wrote: > Hi, > > Up until now, I always see signatures on a key ordered in chronological > fashion, with GnuPG, sks' web interface and enigmail. It's always in a > format with day, month and year (sometimes year-month-day or another > format of that data). Now I'm curious to see when a signature has > *exactly* been made. Can I see the exact time stamp of individual > signatures? gpg with --with-colons --fixed-list-mode or you may use pgpdump > And the next question would be: how? And: is there any > specific rationale behind ordering the signatures in a chronological > way? Times are stored as a number of seconds. Sorting numbers in order is a sensible thing > Can signatures be made at the exact same time? Certainly. If one signs all of the UserIDs of a key, they will have the same time. Caveat: the time recorded is the local system time (as UTC) when the signature is made. If the machine's clock is off, the time will also be off. Also, the clock time may be manipulated before the signature is made. -- 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 ndk.clanbo at gmail.com Wed Sep 18 22:00:35 2013 From: ndk.clanbo at gmail.com (NdK) Date: Wed, 18 Sep 2013 22:00:35 +0200 Subject: How to find and verify a trust path? In-Reply-To: References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> Message-ID: <523A0663.4010308@gmail.com> Il 17/09/2013 22:01, Philip J?genstedt ha scritto: > That's fine, I'm just trying to figure out what others do to convince > themselves that (e.g.) the GnuPG dist sig key is trustworthy-ish and > if there are any tools to help with the boring bits. I think "stability" is what most newbies (and probably experienced users too) use. If the same "identity" keeps using the same key while relating with different users, it's "trustworthy". So if I have CDs from some years ago and OpenPGP is signed with the same key used today, I can be "sure enough" it's not been tampered with and the new file is trustworthy. And often it's more important stability over "impossible" verifications of "real life identity". BYtE, Diego. From philip at foolip.org Wed Sep 18 22:14:40 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Wed, 18 Sep 2013 22:14:40 +0200 Subject: How to find and verify a trust path? In-Reply-To: <523A0663.4010308@gmail.com> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> Message-ID: On Wed, Sep 18, 2013 at 10:00 PM, NdK wrote: > Il 17/09/2013 22:01, Philip J?genstedt ha scritto: > >> That's fine, I'm just trying to figure out what others do to convince >> themselves that (e.g.) the GnuPG dist sig key is trustworthy-ish and >> if there are any tools to help with the boring bits. > I think "stability" is what most newbies (and probably experienced users > too) use. > > If the same "identity" keeps using the same key while relating with > different users, it's "trustworthy". So if I have CDs from some years > ago and OpenPGP is signed with the same key used today, I can be "sure > enough" it's not been tampered with and the new file is trustworthy. > > And often it's more important stability over "impossible" verifications > of "real life identity". Yeah, that sounds like a useful approach. If I assume that the Wayback Machine isn't part of a conspiracy against me, then I could use it to check what signing keys were listed on gnupg.org in the past: http://web.archive.org/web/20070610103602/http://www.gnupg.org/signature_key.en.html -- Philip J?genstedt From dkg at fifthhorseman.net Wed Sep 18 22:20:18 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 18 Sep 2013 16:20:18 -0400 Subject: How to find and verify a trust path? In-Reply-To: References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> Message-ID: <523A0B02.3040500@fifthhorseman.net> On 09/18/2013 04:14 PM, Philip J?genstedt wrote: > Yeah, that sounds like a useful approach. If I assume that the Wayback > Machine isn't part of a conspiracy against me, then I could use it to > check what signing keys were listed on gnupg.org in the past: > > http://web.archive.org/web/20070610103602/http://www.gnupg.org/signature_key.en.html Given that the above link is cleartext (http instead of https), you're also trusting every machine connected to the network path between you and web.archive.org to not imperceptibly MITM your connection. 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 peter at digitalbrains.com Wed Sep 18 22:23:10 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Sep 2013 22:23:10 +0200 Subject: How to find and verify a trust path? In-Reply-To: References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> Message-ID: <523A0BAE.4010709@digitalbrains.com> On 18/09/13 22:14, ? wrote: > If I assume that the Wayback Machine isn't part of a conspiracy against me I don't see how this is different than not verifying at all and "assuming gnupg.org isn't part of a conspiracy against me". What is your thread model? Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Sep 18 22:26:52 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 18 Sep 2013 22:26:52 +0200 Subject: How to find and verify a trust path? In-Reply-To: <523A0663.4010308@gmail.com> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> Message-ID: <523A0C8C.4010007@digitalbrains.com> On 18/09/13 22:00, NdK wrote: > I think "stability" is what most newbies (and probably experienced users > too) use. Alternatively, if you use a Linux distro: simply install it with the package manager. You already implicitly trust that anyway. If somebody got inside the package manager, they don't need to bother to attack GnuPG specifically. I suppose technically you're also trusting the maintainer for the package. No worse than trusting any other maintainer, I think. They all have access to the binaries you run. 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 philip at foolip.org Wed Sep 18 22:58:04 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Wed, 18 Sep 2013 22:58:04 +0200 Subject: How to find and verify a trust path? In-Reply-To: <523A0B02.3040500@fifthhorseman.net> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> <523A0B02.3040500@fifthhorseman.net> Message-ID: On Wed, Sep 18, 2013 at 10:20 PM, Daniel Kahn Gillmor wrote: > On 09/18/2013 04:14 PM, Philip J?genstedt wrote: >> Yeah, that sounds like a useful approach. If I assume that the Wayback >> Machine isn't part of a conspiracy against me, then I could use it to >> check what signing keys were listed on gnupg.org in the past: >> >> http://web.archive.org/web/20070610103602/http://www.gnupg.org/signature_key.en.html > > Given that the above link is cleartext (http instead of https), you're > also trusting every machine connected to the network path between you > and web.archive.org to not imperceptibly MITM your connection. Yes, of course I would need to check it from multiple networks, but even that is no guarantee, since the MITM could just be very close to web.archive.org. -- Philip J?genstedt From philip at foolip.org Wed Sep 18 23:37:01 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Wed, 18 Sep 2013 23:37:01 +0200 Subject: How to find and verify a trust path? In-Reply-To: <523A0BAE.4010709@digitalbrains.com> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> <523A0BAE.4010709@digitalbrains.com> Message-ID: On Wed, Sep 18, 2013 at 10:23 PM, Peter Lebbing wrote: > On 18/09/13 22:14, ? wrote: >> If I assume that the Wayback Machine isn't part of a conspiracy against me > > I don't see how this is different than not verifying at all and "assuming > gnupg.org isn't part of a conspiracy against me". It's one more server which would have to be under the attacker's control, in addition to gnupg.org, Google cache, mailing list mirrors and whatever else one might find. > What is your thread model? When checking the GnuPG dist sig key, the risk is some third party modifying the source, i.e. that the code I'm getting is not from the same origin as all the gpg binaries everyone else is using and trusting with their secrets. > Alternatively, if you use a Linux distro: simply install it with the package > manager. You already implicitly trust that anyway. If somebody got inside the > package manager, they don't need to bother to attack GnuPG specifically. > > I suppose technically you're also trusting the maintainer for the package. No > worse than trusting any other maintainer, I think. They all have access to the > binaries you run. I wanted to try 2.1.0beta3 which isn't in Debian testing, but using the package manager (which I trust) as yet another cross-check sounds reasonable, if some package happened to include the dist sig key, but I haven't found it. While imperfect, checks like these might have to suffice until I can use the web of trust to establish key validity instead. -- Philip J?genstedt From kloecker at kde.org Wed Sep 18 23:40:30 2013 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 18 Sep 2013 23:40:30 +0200 Subject: How to find and verify a trust path? In-Reply-To: <5238232F.6070400@digitalbrains.com> References: <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> Message-ID: <1613683.ZHbRUzjK5b@thufir.ingo-kloecker.de> On Tuesday 17 September 2013 11:38:55 Peter Lebbing wrote: > On 17/09/13 11:07, Peter Lebbing wrote: > > > The independent paths need to be completely disjoint (except for > > > start and end point) _and_ they all need to start with Philip's > > > key. > > > > AFAIK, there is no such requirement in the Web of Trust. I've never > > heard of it. > > Euh... apart from the part where you said they need to start with > Philip's key. I didn't trim the quote far enough :). I meant there is > no requirement that the paths are independent. True. There's no such requirement in the Web of Trust. But Philip's question > > > > > How would an attacker create n independent paths without > > > > > deceiving n people? (which you snipped away in your reply) specifically requires the path to be independent. And that the n independent paths have to connect Philip's key and the key Philip wants to verify is an implicit requirement. Of course, the attacker could create n keys all with his correct name. Then nobody would have to be deceived because there's nothing wrong about those keys. But IMHO that's not a convincing answer because I wouldn't trust n paths all involving keys from the same person more than 1 path involving a key of that person. Of course, if somebody blindly trusts gpg to do the right thing then he probably deserves to be deceived. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From expires2013 at ymail.com Thu Sep 19 01:14:03 2013 From: expires2013 at ymail.com (MFPA) Date: Thu, 19 Sep 2013 00:14:03 +0100 Subject: Sign key and export for each UID In-Reply-To: References: <52375480.7020606@dougbarton.us> <277626970.20130916204508@my_localhost> Message-ID: <1332131790.20130919001403@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 16 September 2013 at 9:20:45 PM, in , Pete Stephenson wrote: > I consider UIDs > corresponding to no-longer-functioning email addresses > to be invalid and won't sign them as I have no idea if > the keyholder is the actual owner of that address. Doesn't the CAFF method (emailing the key with your signature on just one uid in an encrypted message to the email address in that uid) take care of that for you? Unless the same person has access to both the secret key and the email address, they don't have access to your signature on that uid. - -- Best regards MFPA mailto:expires2013 at ymail.com Live your life as though every day it was your last. -----BEGIN PGP SIGNATURE----- iQCVAwUBUjozzqipC46tDG5pAQqvxQP+PHgNpjl9joLZQHH2iHXD7MnE3LC65LT1 DlfZd6/IkcwNZWYHJLjr2JXQga5TNSgvT+N1z7sXW/C2Trarg7f55YDVAqe2HwoU CANkwK0acARcYwEl7+bfh+f9ynDc0LoXc7zqTxtJB6h1GZhs6HixImX/lEluduUi B3ONX7K3gc8= =urRp -----END PGP SIGNATURE----- From expires2013 at ymail.com Thu Sep 19 01:15:44 2013 From: expires2013 at ymail.com (MFPA) Date: Thu, 19 Sep 2013 00:15:44 +0100 Subject: Sign key and export for each UID In-Reply-To: <52376A16.9080400@dougbarton.us> References: <52375480.7020606@dougbarton.us> <277626970.20130916204508@my_localhost> <52376A16.9080400@dougbarton.us> Message-ID: <1466088672.20130919001544@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 16 September 2013 at 9:29:10 PM, in , Doug Barton wrote: > I take uids with no e-mail address on a case by > case basis. Good to hear that. Some people claim to have a blanket policy of not signing them. - -- Best regards MFPA mailto:expires2013 at ymail.com The One with The Answer is seldom asked The Question -----BEGIN PGP SIGNATURE----- iQCVAwUBUjo0JaipC46tDG5pAQp76AP/RKT2ziOH9vwJWB6QOFz2G9XNTlEftCSI D2RLAkussGaLhviFi/umDIQIOUirTAEyoscTvxOlU+Vj+LyKwDXElWnw99rK0V0u Osk250PwSdoR+IbDse7ESgAFX68U2SGH2gKNvj0wkBPlR/sb+ylaDHS/HPA6cANq XHnpYbMcDeE= =rU4e -----END PGP SIGNATURE----- From expires2013 at ymail.com Thu Sep 19 01:41:11 2013 From: expires2013 at ymail.com (MFPA) Date: Thu, 19 Sep 2013 00:41:11 +0100 Subject: Sign key and export for each UID In-Reply-To: <52377947.4010705@dougbarton.us> References: <52375480.7020606@dougbarton.us> <2987231.cVKiPcDoaI@thufir.ingo-kloecker.de> <52377947.4010705@dougbarton.us> Message-ID: <1827439758.20130919004111@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 16 September 2013 at 10:33:59 PM, in , Doug Barton wrote: > Like I said, reasonable minds can differ. I personally > don't find it all that burdensome to select the uids > that I am willing to sign when I get the responses > back. It doesn't sound that onerous to me. But I have to wonder what is actually gained by selectively signing the uids? Doesn't GnuPG calculate key validity based on all the certifications on a key, rather than taking into account only the signatures on an individual uid? So keeping track of selectively-signed uids on other people's keys on an ongoing basis might be very burdensome indeed. - -- Best regards MFPA mailto:expires2013 at ymail.com War is a matter of vital importance to the State. -----BEGIN PGP SIGNATURE----- iQCVAwUBUjo6JKipC46tDG5pAQr5NgP8C1OyVHVA652PwF00KeD4qu3pmrDNlTd7 Yw3k6cQ3ho+OTnID5IMAitljbgOpvz7uvOpjqZgsUVQBW2rI639X8HZa5iwvcx1U Z0/lQthZmo6B+UWd3QQqM1OuXsSpK15dcKx33sNo5VIkCDZYQOC8h4hR7vZMuYkB DAkcJh9Vvgs= =v8WP -----END PGP SIGNATURE----- From dougb at dougbarton.us Thu Sep 19 04:35:02 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 18 Sep 2013 19:35:02 -0700 Subject: Sign key and export for each UID In-Reply-To: <1332131790.20130919001403@my_localhost> References: <52375480.7020606@dougbarton.us> <277626970.20130916204508@my_localhost> <1332131790.20130919001403@my_localhost> Message-ID: <523A62D6.6000409@dougbarton.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/18/2013 04:14 PM, MFPA wrote: | Hi | | | On Monday 16 September 2013 at 9:20:45 PM, in | , | Pete Stephenson wrote: | | |> I consider UIDs |> corresponding to no-longer-functioning email addresses |> to be invalid and won't sign them as I have no idea if |> the keyholder is the actual owner of that address. | | Doesn't the CAFF method (emailing the key with your signature on just | one uid in an encrypted message to the email address in that uid) take | care of that for you? Unless the same person has access to | both the secret key and the email address, they don't have access to | your signature on that uid. The issue for me is the "cleanliness" and accuracy of my local key ring (as I pointed out in a previous message in this thread). I don't like what either CAFF or Pius do; leave signatures that I consider "bogus" on my local copy of the key, or rely on the user to upload the signatures so that I can get them back after a refresh. Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSOmLVAAoJEFzGhvEaGryEvv4H/06tE11VoU+XXxEvtODF56cA feL5L9IP1ZTGHiWaIKHuO1ioWKVxjYZpwvNlpEcHA0jWmE6JsWgMND1M74M79tR+ JSZKB//qufrw+Sm6o83siOdBNvX+Np1GhE5hjkh3z7U6iPd9Ld45u0Zf4uIDv7ou jJEzIJ1uKlTzKIwO0cRAc3JP1tZNx2aNxQFqf3oiwC9ZpjNtXWhWWmRdlbA9Bini wzo9AMwFhAGuEIC3a+qjJardVb6MvMl6MzClZYgMY5rpzp/uGJdKe5ptrIjlTo/I N3x3vfj7+oEtUZPzBG/MQVKoGDHDwbiovW+hghTr3R3n/gTbKYqOjtuDjY+G4SM= =vB6t -----END PGP SIGNATURE----- From dougb at dougbarton.us Thu Sep 19 04:55:45 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 18 Sep 2013 19:55:45 -0700 Subject: How to find and verify a trust path? In-Reply-To: References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> <523A0BAE.4010709@digitalbrains.com> Message-ID: <523A67B1.6050405@dougbarton.us> I don't recall if anyone has mentioned http://pgp.cs.uu.nl/ yet. Tragically not available over https, but nowadays that isn't as much of an assurance as once thought, depending on your threat model of course. :) More below ... On 09/18/2013 02:37 PM, Philip J?genstedt wrote: > On Wed, Sep 18, 2013 at 10:23 PM, Peter Lebbing wrote: >> On 18/09/13 22:14, ? wrote: >>> If I assume that the Wayback Machine isn't part of a conspiracy against me >> >> I don't see how this is different than not verifying at all and "assuming >> gnupg.org isn't part of a conspiracy against me". > > It's one more server which would have to be under the attacker's > control, in addition to gnupg.org, Google cache, mailing list mirrors > and whatever else one might find. You can spend an enormous amount of time going further and further down the rabbit hole if you choose to. :) At the end of the day the question becomes, "How much extra benefit does this extra work provide me, vs. the cost of any potential attack that not doing the work might permit?" If you're running a GnuPG binary on a Windows system, then spending more than 2 minutes is probably 1:30 too long. As has been mentioned here before, unless you are qualified to audit all of the existing build tool chain binaries and related libs on your Unix-like OS even building the GnuPG package yourself after thoroughly verifying the signature/key for the source tarball is putting a whole lot of faith in the system. Admittedly in the case of something like a mainstream Linux or BSD system your trust is probably better placed by an order of magnitude, but it's still a lot of trust. >> What is your threat model? > > When checking the GnuPG dist sig key, the risk is some third party > modifying the source, i.e. that the code I'm getting is not from the > same origin as all the gpg binaries everyone else is using and > trusting with their secrets. Sorry, all you've done there is restate the problem. What bad things are you concerned will happen to you if you use this non-standard source? You may think that's a totally obvious question, but it's not. And see above for why it's probably the wrong question anyway. >> Alternatively, if you use a Linux distro: simply install it with the package >> manager. You already implicitly trust that anyway. If somebody got inside the >> package manager, they don't need to bother to attack GnuPG specifically. >> >> I suppose technically you're also trusting the maintainer for the package. No >> worse than trusting any other maintainer, I think. They all have access to the >> binaries you run. > > I wanted to try 2.1.0beta3 which isn't in Debian testing, but using > the package manager (which I trust) as yet another cross-check sounds > reasonable, if some package happened to include the dist sig key, but > I haven't found it. When I was a FreeBSD developer I tried to get the PTB interested in adding standard (albeit opt-in) support for PGP signatures in our ports/packages system. For the source side (ports) I wanted to include the PGP signatures from the distributor of the tarball. On the pre-compiled packages side I wanted our package creation system to create a signature for the package. I even included a POC for the former in the ports I maintained. While the security conscious users liked it, the general consensus was that the SHA-256 checksums we were already using to verify the authenticity of the source tarballs was enough. My counter-argument was that this is insufficient, since it relies on the (volunteer) maintainer of the port to provide thorough review of new source packages, which is something we had consistency problems with even amongst those with the best of intentions. The Linux package systems I'm familiar with (and admittedly that's not many) seem to share the same "reliability" (pardon the pun) issue. If the maintainer is the one who wants to pwn me, that would theoretically be possible, at least for a time. FWIW, Doug From mailinglisten at hauke-laging.de Thu Sep 19 05:36:54 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 19 Sep 2013 05:36:54 +0200 Subject: Where does this signature come from? Some magic around --export-secret-keys? Message-ID: <2502783.6A2d9D9l8f@inno.berlin.laging.de> Hello, I have tried to export the secret keys only (i.e. without the user IDs) in order to avoid importing old user ID signatures when importing the secret key file. I had the idea to delete the selfsig on the UID before exporting. Thus it could not be exported or imported. But due to some magic gpg exports even an "officially non-existent" signature: LC_ALL= LC_MESSAGES=C gpg --edit-key foo at bar check 2>/dev/null Secret key is available. pub 3072R/0x5D266D4E created: 2013-09-19 expires: never usage: SCEA trust: ultimate validity: ultimate sub 2048R/0x9B681F49 created: 2013-09-19 expires: 2014-09-19 usage: S sub 2048R/0xB42B66D3 created: 2013-09-19 expires: 2014-09-19 usage: E [ultimate] (1). Hauke Laging uid Hauke Laging 1 user ID without valid self-signature detected gpg> gpg --armor --export-secret-keys foo at bar > secret.asc # you cannot import secret keys if there is one already gpg --delete-secret-key foo at bar gpg --import secret.asc LC_ALL= LC_MESSAGES=C gpg --edit-key foo at bar check 2>/dev/null Secret key is available. pub 3072R/0x5D266D4E created: 2013-09-19 expires: 2014-09-19 usage: SCE trust: ultimate validity: ultimate sub 2048R/0x9B681F49 created: 2013-09-19 expires: 2014-09-19 usage: S sub 2048R/0xB42B66D3 created: 2013-09-19 expires: 2014-09-19 usage: E [ultimate] (1). Hauke Laging uid Hauke Laging sig!3 PN 0x5D266D4E 2013-09-19 never [self-signature] WTF? gpg-agent is not running for this user so the signature cannot be created on the fly. Is there a secret selfsig storage which is used for exporting only? This does not happen when exporting the public key! gpg --list-packets shows the difference, too. I played around with gpgsplit and noticed that a secret key file is not imported if the UID is missing completely. But it is happily imported if there is a UID without selfsig... :-) gpg --version gpg (GnuPG) 2.0.19 libgcrypt 1.5.3 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 philip at foolip.org Thu Sep 19 09:26:20 2013 From: philip at foolip.org (=?ISO-8859-1?Q?Philip_J=E4genstedt?=) Date: Thu, 19 Sep 2013 09:26:20 +0200 Subject: How to find and verify a trust path? In-Reply-To: <523A67B1.6050405@dougbarton.us> References: <52377166.9010408@digitalbrains.com> <2493384.5tWvIerWZN@thufir.ingo-kloecker.de> <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> <523A0BAE.4010709@digitalbrains.com> <523A67B1.6050405@dougbarton.us> Message-ID: On Thu, Sep 19, 2013 at 4:55 AM, Doug Barton wrote: > I don't recall if anyone has mentioned http://pgp.cs.uu.nl/ yet. Tragically > not available over https, but nowadays that isn't as much of an assurance as > once thought, depending on your threat model of course. :) I did mention it once: On Mon, Sep 16, 2013 at 5:45 PM, Philip J?genstedt wrote: > http://pgp.cs.uu.nl/ can help for keys in the strong set, but requires > a lot of manual work. Since the signature paths it finds can be verified separately, I don't think it matters that it's not served over HTTPS. > You can spend an enormous amount of time going further and further down the > rabbit hole if you choose to. :) At the end of the day the question > becomes, "How much extra benefit does this extra work provide me, vs. the > cost of any potential attack that not doing the work might permit?" Right, so I was looking for an approach that requires little work for me, while requiring a lot of work for someone else to subvert. (Of course I've already spent a lot more time discussing the approach than I would investigating any single key, because the topic in itself is fun and interesting.) >>> What is your threat model? >> >> >> When checking the GnuPG dist sig key, the risk is some third party >> modifying the source, i.e. that the code I'm getting is not from the >> same origin as all the gpg binaries everyone else is using and >> trusting with their secrets. > > > Sorry, all you've done there is restate the problem. What bad things are you > concerned will happen to you if you use this non-standard source? You may > think that's a totally obvious question, but it's not. And see above for why > it's probably the wrong question anyway. I get the feeling that if I say that I don't want a third party to insert backdoors into gnupg, git, nginx, node, or whatever other packages I might be compiling from source, you'll tell me that the maintainer can do that as well and I should audit the code. At the end of the day I'm assuming that Debian, GnuPG, Git and a lot of other packages that I and people I know have used for years have maintainers who care about their reputation, and that the reason these packages are popular is because they've done a good job historically. I've certainly trusted them with my secrets, so if the trust is misplaced I've already lost. When compiling from source, it would be nice to verify that what I'm getting is from these same maintainers. I realize that there's no guarantee that the maintainers of the packages I've been trusting using are the same people I'll find when following (multiple, independent) signature paths, but it looks much better than no check at all, and my servers and secrets just aren't important enough to warrant going much further. -- Philip J?genstedt From sergi at calcurco.cat Thu Sep 19 13:29:39 2013 From: sergi at calcurco.cat (=?ISO-8859-1?Q?Sergi_Blanch_i_Torn=E9?=) Date: Thu, 19 Sep 2013 13:29:39 +0200 Subject: Support for additional ECC Curves in GnuPG (gcrypt) In-Reply-To: References: Message-ID: In my humble opinion, this has been an enormous limitation on this standard. But there are other curves with OIDs (check for the "Brainpool standard Curves". The rfc4492, similar to what you mention but for TLS, allows any arbitrary curve (prime & char2) but rfc 6637 doesn't allow us to go that far. About your question of the alternative curves, yes, I'm working in an auditable algorithm (to get us to trust on it) to allow us to not share the curve we use as the X9.62 mention as a issue when too many people shares the same curve. The issue I'm having for this algorithm is to build them, even for the "big" fields in a non-user desperation time (I mean not bigger but smaller than equivalent rsa generation). /Sergi. On Wed, Sep 11, 2013 at 1:46 PM, Alexandre Dulaunoy wrote: > Hi Everyone, > > Do you know if someone is currently working to implement additional > curves in ECC > and especially to have an alternative to the NIST ones in gcrypt/GnuPG? > > and I was wondering if we are bound to the ones defined in: > > http://tools.ietf.org/html/rfc6637#section-11 > > Thank you, > > Cheers. > > -- > -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ > -- http://www.foo.be/cgi-bin/wiki.pl/Diary > -- "Knowledge can create problems, it is not through ignorance > -- that we can solve them" Isaac Asimov > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Thu Sep 19 18:36:24 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Sep 2013 12:36:24 -0400 Subject: Sign key and export for each UID In-Reply-To: <523A62D6.6000409@dougbarton.us> References: <52375480.7020606@dougbarton.us> <277626970.20130916204508@my_localhost> <1332131790.20130919001403@my_localhost> <523A62D6.6000409@dougbarton.us> Message-ID: <523B2808.7010300@fifthhorseman.net> On 09/18/2013 10:35 PM, Doug Barton wrote: > The issue for me is the "cleanliness" and accuracy of my local key ring > (as I pointed out in a previous message in this thread). I don't like > what either CAFF or Pius do; leave signatures that I consider "bogus" on > my local copy of the key, or rely on the user to upload the signatures > so that I can get them back after a refresh. It seems like either one or the other is likely to be the Right Thing to do with any particular User ID. Do you have any desired behavior to recommend as a middle ground? Should caff or pius or monkeysign or similar tools ask the user during signing about which of the e-mail-containing User IDs they are already confident about somehow, and use that feedback from the user to either (if confident) to store the new certifications in the user's main keyring, or (if not confident) to require the round trip through the keyservers? If this is what you want, how would you ask the user that question in a comprehensible way for each User ID? or is there some other approach you'd like to see happen? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Sep 19 19:44:39 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Sep 2013 19:44:39 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: (Nicholas Cole's message of "Wed, 18 Sep 2013 09:54:59 +0100") References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> <1379442236204-32563.post@n7.nabble.com> <87ioxywqv6.fsf@vigenere.g10code.de> Message-ID: <87hadgu2ns.fsf@vigenere.g10code.de> On Wed, 18 Sep 2013 10:54, nicholas.cole at gmail.com said: > If I understand correctly, the curve is used to create the > Public/Private Keypair. So GPG probably needs to display clearly (in The curve is part of the key. We have a similar thing in Elgamal and DSA algorithms, over there we call it domain parameters. You may use the same domain parameters for all keypairs or use new ones for every key (that is what GnuPG does). Selecting random elliptic curves is a more time consuming process and thus almost everyone is using one curve for everything. > to create the key (if that is possible) so that people can make a > judgement about that kind of thing when they certify keys -- assuming If Bobs decides to use NIST curve, why don't you want to send a mail to him. It his his decision whether he want to keep stuff confidential. OTOH, for key signing, the use of certain curves may well be a data point on how far you trust someone else to sign a key. Thus, I concur that gpg should print a notice which curve has been used. We may be able to reuse the key size field for this (a curve specifies the key size). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Sep 19 19:55:21 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Sep 2013 19:55:21 +0200 Subject: Signature timestamp ordering and dissecting In-Reply-To: <5239AA8A.4090507@enigmail.net> (John Clizbe's message of "Wed, 18 Sep 2013 08:28:42 -0500") References: <52389DB2.9070005@aktivix.org> <5239AA8A.4090507@enigmail.net> Message-ID: <87d2o4u25y.fsf@vigenere.g10code.de> On Wed, 18 Sep 2013 15:28, John at enigmail.net said: > Times are stored as a number of seconds. Sorting numbers in order is a > sensible thing Let me add a this from doc/DETAILS: Note that the date is usally printed in seconds since epoch, however, we are migrating to an ISO 8601 format (e.g. "19660205T091500"). This is currently only relevant for X.509. A simple way to detect the new format is to scan for the 'T'. Note that old versions of gpg without using the =--fixed-list-mode= option used a "yyyy-mm-tt" format. Thus if you want to parse a GnuPG time string, you should better check whether a 'T' is in that string. And you should also take care of the year 2038 problem; which is the very reason that we use fixed size strings in GPGSM to work with timestamps. Those ISO time strings are also easy to sort. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Sep 19 20:24:15 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Sep 2013 20:24:15 +0200 Subject: Support for additional ECC Curves in GnuPG (gcrypt) In-Reply-To: ("Sergi Blanch i =?utf-8?Q?Torn=C3=A9=22's?= message of "Thu, 19 Sep 2013 13:29:39 +0200") References: Message-ID: <8738p0u0ts.fsf@vigenere.g10code.de> On Thu, 19 Sep 2013 13:29, sergi at calcurco.cat said: > allows any arbitrary curve (prime & char2) but rfc 6637 doesn't allow us to > go that far. Sorry, I can't see that. The only problem I see with 6637 is that the standard uncompressed encoding is required and that we have no way to change that. Compact encodings as for example specified for Ed255519 can't be used. However, I see no problem to put an uncompressed EdDSA point into an RFC-6637 packet and alias EdDSA to ECDSA. The secret key will be prefixed with a 0x00 to fit into OpenPGP's unsigned MPIs. In case you are talking about random curves: You are mostly out of luck because the size of an OID is limited to 254 bytes. Thus if you really want to have random curves you would need to write a new spec which takes advantage of the two reserved values in the OID size fields. OR request a new algorithm ID - which might be the cleaner solution. For everyone else I believe that just a few curves (which might be just a single one) fits all our needs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From josef at netpage.dk Thu Sep 19 20:59:50 2013 From: josef at netpage.dk (Josef Schneider) Date: Thu, 19 Sep 2013 20:59:50 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <87hadgu2ns.fsf@vigenere.g10code.de> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> <1379442236204-32563.post@n7.nabble.com> <87ioxywqv6.fsf@vigenere.g10code.de> <87hadgu2ns.fsf@vigenere.g10code.de> Message-ID: On Thu, Sep 19, 2013 at 7:44 PM, Werner Koch wrote: > If Bobs decides to use NIST curve, why don't you want to send a mail to > him. It his his decision whether he want to keep stuff confidential. Yes, but it isn't only HIS stuff! I want to know if the information I send out is secure enough or not. If, for example, my doctor asks me to send him all my medical information on a postcard, I won't do it! So why shouldn't I decide myself what I consider secure enough to send him that information on the Internet? Best regards, Josef From nicholas.cole at gmail.com Thu Sep 19 19:58:58 2013 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 19 Sep 2013 18:58:58 +0100 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <87hadgu2ns.fsf@vigenere.g10code.de> References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> <1379442236204-32563.post@n7.nabble.com> <87ioxywqv6.fsf@vigenere.g10code.de> <87hadgu2ns.fsf@vigenere.g10code.de> Message-ID: On Thu, Sep 19, 2013 at 6:44 PM, Werner Koch wrote: >> to create the key (if that is possible) so that people can make a >> judgement about that kind of thing when they certify keys -- assuming > > If Bobs decides to use NIST curve, why don't you want to send a mail to > him. It his his decision whether he want to keep stuff confidential. > > OTOH, for key signing, the use of certain curves may well be a data > point on how far you trust someone else to sign a key. Thus, I concur > that gpg should print a notice which curve has been used. We may be > able to reuse the key size field for this (a curve specifies the key > size). That sounds ideal. And I am sure you are right that for private use it makes little to no difference. But on the other hand, if gpg is being used where people are trying to comply with different national standards, it might be important that they know the curve being used. From jharris at widomaker.com Fri Sep 20 04:26:54 2013 From: jharris at widomaker.com (Jason Harris) Date: Thu, 19 Sep 2013 22:26:54 -0400 Subject: How to find and verify a trust path? In-Reply-To: <523A67B1.6050405@dougbarton.us> References: <52381BB8.5090802@digitalbrains.com> <5238232F.6070400@digitalbrains.com> <52386467.5040908@fifthhorseman.net> <523A0663.4010308@gmail.com> <523A0BAE.4010709@digitalbrains.com> <523A67B1.6050405@dougbarton.us> Message-ID: <20130920022654.GA94718@wave> On Wed, Sep 18, 2013 at 07:55:45PM -0700, Doug Barton wrote: > When I was a FreeBSD developer I tried to get the PTB interested in > adding standard (albeit opt-in) support for PGP signatures in our > ports/packages system. For the source side (ports) I wanted to include > the PGP signatures from the distributor of the tarball. On the BTW, I've kept the USE_GPG code alive in bsd.port.mk, even working around projects like Apache that only distribute .asc files from their master site. For example, before building GPG 1.x, I will get the following - or else the build stops with a "failed" checksum: %make checksum ===> Found saved configuration for gnupg-1.4.14 ===> Fetching all distfiles required by gnupg-1.4.14 for building => MD5 Checksum OK for gnupg-1.4.14.tar.bz2. => SHA1 Checksum OK for gnupg-1.4.14.tar.bz2. => RMD160 Checksum OK for gnupg-1.4.14.tar.bz2. => SHA256 Checksum OK for gnupg-1.4.14.tar.bz2. => No SHA512 checksum recorded for gnupg-1.4.14.tar.bz2. => MD5 Checksum OK for gnupg-1.4.14.tar.bz2.sig. => SHA1 Checksum OK for gnupg-1.4.14.tar.bz2.sig. => RMD160 Checksum OK for gnupg-1.4.14.tar.bz2.sig. => SHA256 Checksum OK for gnupg-1.4.14.tar.bz2.sig. => No SHA512 checksum recorded for gnupg-1.4.14.tar.bz2.sig. ===> Verifying PGP signature gnupg-1.4.14.tar.bz2.sig gpg: assuming signed data in `/usr/ports/distfiles//gnupg-1.4.14.tar.bz2' gpg: Signature made Thu Jul 25 04:56:52 2013 AST using RSA key ID 4F25E3B6 gpg: please do a --check-trustdb gpg: Good signature from "Werner Koch (dist sig)" Primary key fingerprint: D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 gpg: binary signature, digest algorithm SHA256 ===> Valid sig. from expected ID #1 D8692123C4065DEA5E0F3AB5249B39D24F25E3B6. > pre-compiled packages side I wanted our package creation system to > create a signature for the package. I even included a POC for the former > in the ports I maintained. While the security conscious users liked it, I'm in this group. > the general consensus was that the SHA-256 checksums we were already > using to verify the authenticity of the source tarballs was enough. And I have total dissensus with that consensus. > My counter-argument was that this is insufficient, since it relies on > the (volunteer) maintainer of the port to provide thorough review of new > source packages, which is something we had consistency problems with > even amongst those with the best of intentions. The Linux package Definitely, and I really dislike that the autotools create so many gratuitious diffs. > systems I'm familiar with (and admittedly that's not many) seem to share > the same "reliability" (pardon the pun) issue. If the maintainer is the > one who wants to pwn me, that would theoretically be possible, at least > for a time. With signed tarballs, I really don't worry as long as the FreeBSD- distributed patches (files/*) are small/easy enough to thoroughly check. Contributed patches from PATCH_SITES are more likely to be a threat because they're almost always not signed. I also [re]compute the SHA256 and other hashes ("make makesum"), "svn diff distinfo" to make sure the "official" FreeBSD SHA256 hashes haven't changed, and might even check the other BSD and Linux distributions' MD5/SHA-1/etc. hashes for the same tarball. Even before a port/package is updated in FreeBSD, I can download the new tarball and signature and easily make sure it was signed by the same (or a previous) GPG key with a known fingerprint. -- 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 wk at gnupg.org Fri Sep 20 13:44:32 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Sep 2013 13:44:32 +0200 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: (Josef Schneider's message of "Thu, 19 Sep 2013 20:59:50 +0200") References: <52313871.90109@hammet.net> <523152A5.3050704@fifthhorseman.net> <87fvt92oxs.fsf@vigenere.g10code.de> <5232F632.7010401@vulcan.xs4all.nl> <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> <1379442236204-32563.post@n7.nabble.com> <87ioxywqv6.fsf@vigenere.g10code.de> <87hadgu2ns.fsf@vigenere.g10code.de> Message-ID: <878uyrra3j.fsf@vigenere.g10code.de> On Thu, 19 Sep 2013 20:59, josef at netpage.dk said: > Yes, but it isn't only HIS stuff! You have to trust the recipient anyway that he keep the information confidential. It does not help to use string encryption if the message is later re-tweeted by the recipient. Unfortunately this is too often the case: For example, you snail confidential information and the recipient in turn scans them and passed them on using plain email. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cwr at cwrichardson.com Fri Sep 20 14:14:01 2013 From: cwr at cwrichardson.com (Christopher W. Richardson) Date: Fri, 20 Sep 2013 19:14:01 +0700 Subject: Can't adduid (can't read pubring.gpg?) Message-ID: <442567D8-F146-4DC7-8AD7-A3622236F5BC@cwrichardson.com> Hi folks, First off, I'm new to the list, so if I violate any etiquette, feel free to educate me. Second, a couple of quick questions before I get to the heart of the matter: 1) is there any general place to go look for help with debugging issues other than Chapter 10 of the manual? 2) is there a way to search the mail archives? (http://www.gnupg.org/documentation/mailing-lists.en.html say to go tohttp://marc.theaimsgroup.com/, but the latter is down, at least ATM ? not sure if that's temporary or permanent (and if the latter, we should probably update the former link)). Now, to the heart of the matter: I've been using GPG for A Long Time Now (my keys were generated in mid-2000). And I use it daily, but almost exclusively to encrypt and decrypt files. Recently, I've had call to use it for email again, and realized my userIDs all refer to email addresses which haven't been used in 5 or 6 years. So ? I went to add a userID. gpg responds thusly: gpg> save gpg: /Users/cwr/.gnupg/pubring.gpg: copy to `/Users/cwr/.gnupg/pubring.gpg.tmp' failed: file read error gpg: update failed: file read error (hopefully all of the) relevant details: cwr$gpg --version gpg (GnuPG) 1.4.14 ... Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 cwr$ls -al pubring.gpg -rwx------ 1 cwr staff 34564 Apr 22 14:38 pubring.gpg cwr$uname -a Darwin Christophers-MacBook-Pro.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 Any suggestions on how to fix this, or how to further debug it would be much appreciated. TIA, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwood at IUPUI.Edu Fri Sep 20 15:17:50 2013 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Fri, 20 Sep 2013 09:17:50 -0400 Subject: Where is ECC in gpg2 (specifically gnupg-2.0.21 In-Reply-To: <878uyrra3j.fsf@vigenere.g10code.de> References: <87wqmk1i0a.fsf@vigenere.g10code.de> <5233AB07.7040608@sixdemonbag.org> <20130916124641.GA7285@IUPUI.Edu> <1379442236204-32563.post@n7.nabble.com> <87ioxywqv6.fsf@vigenere.g10code.de> <87hadgu2ns.fsf@vigenere.g10code.de> <878uyrra3j.fsf@vigenere.g10code.de> Message-ID: <20130920131750.GC7399@IUPUI.Edu> On Fri, Sep 20, 2013 at 01:44:32PM +0200, Werner Koch wrote: > On Thu, 19 Sep 2013 20:59, josef at netpage.dk said: > > Yes, but it isn't only HIS stuff! > You have to trust the recipient anyway that he keep the information > confidential. It does not help to use string encryption if the message > is later re-tweeted by the recipient. Unfortunately this is too often > the case: For example, you snail confidential information and the > recipient in turn scans them and passed them on using plain email. If Alice does not trust the NIST curves, and Bob insists on using them, this is a reason for Alice not to trust Bob because (in her eyes) his security practice is lax. Bob does not (in Alice's view) take sufficient care to keep Alice's words confidential. It is reasonable for her then not to exchange confidences with Bob in this channel. A: Can you keep a secret? B: No. A: Then I won't tell you any. -- 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 cr at rheloud.net Fri Sep 20 16:50:17 2013 From: cr at rheloud.net (C. Rossberg) Date: Fri, 20 Sep 2013 16:50:17 +0200 Subject: Can't adduid (can't read pubring.gpg?) In-Reply-To: <442567D8-F146-4DC7-8AD7-A3622236F5BC@cwrichardson.com> References: <442567D8-F146-4DC7-8AD7-A3622236F5BC@cwrichardson.com> Message-ID: <20130920145016.GA2287@teletypeIII> On Fri, 20 Sep 2013, Christopher W. Richardson wrote: > 2) is there a way to search the mail archives? (http://www.gnupg.org/documentation/mailing-lists.en.html say to go tohttp://marc.theaimsgroup.com/, but the latter is down, at least ATM ? not sure if that's temporary or permanent (and if the latter, we should probably update the former link)). try gmane http://dir.gmane.org/gmane.comp.encryption.gpg.user or mail-archive http://www.mail-archive.com/gnupg-users at gnupg.org/ yours //c -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From cwr at cwrichardson.com Sat Sep 21 05:58:42 2013 From: cwr at cwrichardson.com (Christopher W. Richardson) Date: Sat, 21 Sep 2013 10:58:42 +0700 Subject: Can't adduid (can't read pubring.gpg?) In-Reply-To: <20130920145016.GA2287@teletypeIII> References: <442567D8-F146-4DC7-8AD7-A3622236F5BC@cwrichardson.com> <20130920145016.GA2287@teletypeIII> Message-ID: On 20 Sep 2013, at 21:50, "C. Rossberg" wrote: > On Fri, 20 Sep 2013, Christopher W. Richardson wrote: > >> 2) is there a way to search the mail archives? (http://www.gnupg.org/documentation/mailing-lists.en.html say to go tohttp://marc.theaimsgroup.com/, but the latter is down, at least ATM ? not sure if that's temporary or permanent (and if the latter, we should probably update the former link)). > > try gmane Thanks, C! With a search front-end to the archives, I was able to find someone who fixed a similar problem by moving his sec and pub rings to *.old files, and then reimporting. It turns out that worked, sort of. If I export my public key, then import just my pub and private keys creating new keyrings, the problem is solved. However, if I try to import the entire old pubring.gpg, the problem persists and the following happens: cwr at Hermes$gpg --import pubring.gpg.old gpg: keyring `/Users/cwr/.gnupg/secring.gpg' created gpg: keyring `/Users/cwr/.gnupg/pubring.gpg' created ... gpg(5521) malloc: *** error for object 0x70000: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug ... gpg: Total number processed: 19 gpg: imported: 19 (RSA: 6) gpg(5521) malloc: *** error for object 0x70000: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug I guess there are some corrupted public key(s)? Like I said, my problem is effectively solved; however, if the above looks like a bug and someone wants to work on it, I'm happy to change the subject line and provide whatever information would be useful. Cheers! Chris From cwr at cwrichardson.com Sat Sep 21 06:04:55 2013 From: cwr at cwrichardson.com (Christopher W. Richardson) Date: Sat, 21 Sep 2013 11:04:55 +0700 Subject: Can't adduid (can't read pubring.gpg?) In-Reply-To: References: <442567D8-F146-4DC7-8AD7-A3622236F5BC@cwrichardson.com> <20130920145016.GA2287@teletypeIII> Message-ID: <0E8F3547-4C96-4237-9EB3-83FAD4642A15@cwrichardson.com> On 21 Sep 2013, at 10:58, Christopher W. Richardson wrote: > > gpg(5521) malloc: *** error for object 0x70000: pointer being freed was not allocated > *** set a breakpoint in malloc_error_break to debug > > I guess there are some corrupted public key(s)? Like I said, my problem is effectively solved; however, if the above looks like a bug and someone wants to work on it, I'm happy to change the subject line and provide whatever information would be useful. Ignore that. The above was on a different machine, running 1.4.10. Using 1.4.14, the problem is just plain fixed; no malloc errors and the entire pubring reimports. Still not sure what cause it to _need_ to be reimported, but all better now. Cheers! Chris From joergd at bitquell.de Sat Sep 21 19:28:14 2013 From: joergd at bitquell.de (=?ISO-8859-1?Q?J=F6rg?= Deckert) Date: Sat, 21 Sep 2013 19:28:14 +0200 Subject: OpenPGP card, gpgsm, decrypt Message-ID: <2242538.IbLcNkSWhX@asus> Hi, S/MIME decryption with OpenPGP card doesn't work for me: $ gpgsm --armor --encrypt --recipient addr at mail Test.txt >Test.txt.asc gpgsm: encrypted data created $ LC_ALL=C gpgsm --decrypt Test.txt.asc gpgsm: DBG: recp 0 - issuer: xxxxxxxxx gpgsm: DBG: recp 0 - serial: 0096A601DB1CC451E4 gpgsm: error decrypting session key: Invalid ID gpgsm: decrypting session key failed: Invalid ID gpgsm: message decryption failed: No secret key (De)crypting with gpg and signing with gpg and gpgsm is fully working. What's wrong? The OpenPGP card: $ LC_ALL=C gpg --card-status Application ID ...: D2760001240102000005000010B10000 Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: 000010B1 Name of cardholder: Joerg Deckert Language prefs ...: de Sex ..............: male URL of public key : Login data .......: Signature PIN ....: forced Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 1 Signature key ....: D827 D045 09AC 6FA6 5BA2 03D4 D54B 22F8 BBDB 852D created ....: 2013-09-21 14:30:58 Encryption key....: 8F35 5D73 11D8 9931 C152 81E2 4C02 68BA 178F E724 created ....: 2013-09-21 14:29:51 Authentication key: 310F A63E C901 6251 8CEF 2897 224C 4841 4A9E C43B created ....: 2013-09-21 14:32:30 General key info..: pub 2048R/BBDB852D 2013-09-21 J D sec# 2048R/DE9405E1 created: 2013-09-21 expires: never ssb> 2048R/178FE724 created: 2013-09-21 expires: 2015-09-21 card-no: 0005 000010B1 ssb> 2048R/BBDB852D created: 2013-09-21 expires: 2015-09-21 card-no: 0005 000010B1 ssb> 2048R/4A9EC43B created: 2013-09-21 expires: 2015-09-21 card-no: 0005 000010B1 $ LC_ALL=C gpg --list-secret-keys /home/joergd/.gnupg/secring.gpg ------------------------------- sec# 2048R/DE9405E1 2013-09-21 uid J D () ssb> 2048R/178FE724 2013-09-21 ssb> 2048R/BBDB852D 2013-09-21 ssb> 2048R/4A9EC43B 2013-09-21 $ LC_ALL=C gpgsm --list-secret-keys /home/joergd/.gnupg/pubring.kbx ------------------------------- ID: 0xFFFFFFFF9B49DE76 S/N: 0096A601DB1CC451E4 Issuer: xxxxxxxxxxxxxxxxxxxxxxxxxx Subject: yyyyyyyyyyyyyyyyyyyyyyyyyy aka: joergd at bitquell.de validity: 2013-09-21 16:20:00 through 2015-09-21 16:20:00 key type: 2048 bit RSA key usage: digitalSignature keyEncipherment dataEncipherment fingerprint: CE:B1:78:2F:86:8F:DA:E4:03:F5:68:5B:46:B5:1C:33:9B:49:DE:76 card s/n: D2760001240102000005000010B10000 -- J?rg Deckert From al-gnupg_users at none.at Sat Sep 21 23:06:22 2013 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Sat, 21 Sep 2013 23:06:22 +0200 Subject: Question about a perfect private Key store for today's environment Message-ID: Hi all. Due to the fact that more and more users, including me, want to use pgp and smime for end-to-end-encryption I asked myself the following. What could be a perfect or at least a very good storage of the private Key. What could be a secret use of the pgp and smime technology implemented for today's user environment. My definition of "today's user environment": 1.) Private mobile device, tablet, notebook with private E-Mail program 2.) Business mobile device, tablet, notebook with company E-Mail program with company key and private key 3.) Private mobile device, tablet, notebook with Web mail only access 4.) Business mobile device, tablet, notebook with Web mail only access 5.) more to defined There are for different clients different tools available but the problem from my point of view is that you must always add your private key into the different clients. This is a lot of work and sometimes not possible as in point 3+4 defined. Point 1+2 are also not very secure due to the fact that nobody knows what really happen on such devices. There are some HW-Solutions like http://g10code.com/p-card.html http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=133&osCsid=503b6045b0863ea8f4bc84757e89ee81 but how could this or other HW-Solutions be usable along with Point 1+2 definitions? In case you have your own server with your own web mail solution like roundcube, Horde or any other and you have secured your private Key on this server then you have a solution for point 3+4 but not for 1+2. What solution is available for public Web mail providers like gmail, gmx, hotmail, .... .? In this case there must be a way to sign the message with the private key on disc or USB-Stick. From my point of view I don't see a secure and usable solution for the most users out there. Maybe I have the wrong point of view. I'm sure that I don't know not all possible solutions. What are your opinions about the thought above? What are your solution which you use? Thanks for reading and looking forward to your answers. Aleksandar Lazic From pete at heypete.com Sun Sep 22 10:28:58 2013 From: pete at heypete.com (Pete Stephenson) Date: Sun, 22 Sep 2013 10:28:58 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: References: Message-ID: On Sat, Sep 21, 2013 at 11:06 PM, Aleksandar Lazic wrote: > What could be a perfect or at least a very good storage of the > private Key. Probably a smartcard -- this keeps your key entirely on the card and it is not accessible to the computer (that is, a bad guy with control of your computer cannot extract the key from the card). It's almost certainly possible that a well-equipped adversary with chip-disassembly equipment (read: a major government) could physically take apart the chip and read the data off the internal parts directly, but that's a different story altogether. Personally, I use a smartcard to prevent my private keys from being revealed if my computer is compromised by malware or some other sneaky stuff. If someone is willing to go through with seizing my smartcard and taking it apart, I have bigger problems. :) > My definition of "today's user environment": > > 1.) Private mobile device, tablet, notebook with private E-Mail program > 2.) Business mobile device, tablet, notebook with company E-Mail program > with company key and private key > 3.) Private mobile device, tablet, notebook with Web mail only access > 4.) Business mobile device, tablet, notebook with Web mail only access > 5.) more to defined > > There are for different clients different tools available but the problem > from my point of view is that you must always add your private key into the > different clients. > > This is a lot of work and sometimes not possible as in point 3+4 defined. > > Point 1+2 are also not very secure due to the fact that nobody knows what > really happen on such devices. Well, #1 is probably the most secure: it's your own device and your own mail client (e.g. Thunderbird). #2 is probably the least secure, as the company has access to your private key. > There are some HW-Solutions like > > http://g10code.com/p-card.html > http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=133&osCsid=503b6045b0863ea8f4bc84757e89ee81 > > but how could this or other HW-Solutions be usable along with Point 1+2 > definitions? Easy: many mail clients have OpenPGP support built-in, or available through an add-on like Enigmail for Thunderbird. Many can read the smartcard and handle the encryption/decryption/signing operations through the normal interface. Even without a smartcard, they can access one's keyring and perform the various operations. > In case you have your own server with your own web mail solution like > roundcube, Horde or any other and you have secured your private Key on this > server then you have a solution for point 3+4 but not for 1+2. I'm not sure how much I'd trust a web service, even one operated by myself or a company, with my private keys. I'd much rather keep them on a smartcard, accessible only to myself. > What solution is available for public Web mail providers like gmail, gmx, > hotmail, .... .? Gmail permits access with mail clients (e.g. Thunderbird), so one could use such a client in conjunction their OpenPGP software to send and receive encrypted mails. For webmail-only providers, you'd need to compose your message offline (say in a text editor like Notepad or something similar), then perform the encrypt/sign operations, then copy-paste the encrypted/signed output into the webmail compose window. > What are your opinions about the thought above? > What are your solution which you use? Usability is a big concern, and it's difficult with webmail-only services that people use these days. It becomes much more straightforward if one uses a mail client program. Cheers! -Pete -- Pete Stephenson From markoran at eunet.rs Sun Sep 22 10:29:47 2013 From: markoran at eunet.rs (Marko Randjelovic) Date: Sun, 22 Sep 2013 10:29:47 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: References: Message-ID: <20130922102947.14aa4bf1@eunet.rs> Of course it is not safe. If you realy need a smartphone, use some of those that are supported by Replicant OS. http://replicant.us/ From ndk.clanbo at gmail.com Sun Sep 22 10:37:17 2013 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 22 Sep 2013 10:37:17 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: References: Message-ID: <523EAC3D.2090300@gmail.com> Il 21/09/2013 23:06, Aleksandar Lazic ha scritto: > What solution is available for public Web mail providers like gmail, > gmx, hotmail, .... .? Firefox+GreaseMonkey+script to interface to card? BYtE, Diego From htd at fritha.org Sun Sep 22 10:45:17 2013 From: htd at fritha.org (Heinz Diehl) Date: Sun, 22 Sep 2013 10:45:17 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: References: Message-ID: <20130922084516.GB1571@fritha.org> On 22.09.2013, Aleksandar Lazic wrote: > What could be a perfect or at least a very good storage of the > private Key. Spend a little bit money and buy you a smartcard and a reader. Then, boot a machine without internet connection from an USB-stick or CD/DVD with some live version (e.g. http://www.sysresccd.org ), generate a fresh key pair and install it on your smartcard. From len.cooley at gmail.com Sun Sep 22 16:57:10 2013 From: len.cooley at gmail.com (Len Cooley) Date: Sun, 22 Sep 2013 10:57:10 -0400 Subject: gpg: Go ahead and type your message Message-ID: I'm sure this has been a topic of inquiry many times, but I can't seem to find useful information about it. I haven't used gpg command line for a long time (I actually haven't used gpg much at all in the past few years, as I've had a Windows machine, and I just don't trust the OS), but I have gpg on my android phone. It utilizes the terminal. When I type in gpg (return) I get the message that I placed in the subject line. I'm not really sure what I do at that point. If I use Ctrl C, the program terminates. If I hit CtrlZ, I think it suspends the program (but I'm not sure). Would/could I use this area to type a text message that I would then, subsequently, encrypt/sign/save? If so, where could I find a set of basic commands to use with this (what appears to be) text editor? If this isn't what it's intended for, what's it for? Thanks for bearing with me. -- http://www.auditmypc.com/freescan/antispam.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Sep 22 19:41:23 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 22 Sep 2013 13:41:23 -0400 Subject: gpg: Go ahead and type your message In-Reply-To: References: Message-ID: <523F2BC3.5020602@sixdemonbag.org> On 9/22/2013 10:57 AM, Len Cooley wrote: > I'm sure this has been a topic of inquiry many times, but I can't seem > to find useful information about it. The normal way to use GnuPG is to first compose your document (using whatever application you wish -- a word processor, a text editor, whatever) and save it as you normally would. Then, at the command line, you would type something like: gpg --local-user [keyID] --recipient [keyID] --sign --encrypt [filename] This would tell GnuPG to encrypt the file for a specified person (given by the --recipient flag), and to sign the file using a specified certificate (given by the --local-user flag). From oliver at wps-verlinden.de Sun Sep 22 19:10:56 2013 From: oliver at wps-verlinden.de (Oliver Verlinden) Date: Sun, 22 Sep 2013 19:10:56 +0200 Subject: CryptoList - Looking for beta testers Message-ID: <201309221911.12744.oliver@wps-verlinden.de> Hey guys, some days ago I had the idea of a pgp compatible mailing list. I know there is a mailman extension which supports pgp encrypted messages out there, but I wanted ta have a small, fast and easy to configure solution. I imagined something like that: - A list member writes an pgp signed and encrypted message to the list server - Encryption is enforced: Non encrypted messages are rejected - The senders pgp signature is checked, to ensure the message integrity - The message is multiplied and resigned/reencrypted by the list server - The signed and encrypted messages are delivered to the list members Well it's weekend, so I started to code. ;) Meanwhile the key functionalities are implemented and the project is ready for some beta tests. It's very annoying to write emails to myself all the time to check functionality. So if you want to try this, just give me a short notification with your public key id. I will add your public key into the lists keyring and add you to the recipients list. After some testings, the whole project will be available on SourceForge. 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 kwadronaut at aktivix.org Sun Sep 22 20:33:45 2013 From: kwadronaut at aktivix.org (kwadronaut) Date: Sun, 22 Sep 2013 20:33:45 +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: <523F3809.9020100@aktivix.org> On 22/09/13 19:10, Oliver Verlinden wrote: > some days ago I had the idea of a pgp compatible mailing list. > I know there is a mailman extension which supports pgp encrypted messages out > there, but I wanted ta have a small, fast and easy to configure solution. ?re you also aware of Schleuder? [1] I don't want to surpress your enthusiasm, but if possible, maybe, you can ameliorate that other thing even more? With Schleuder: > - A list member writes an pgp signed and encrypted message to the list server Or an outsider, depends on the configuration. There are some good use cases, for example if a list address is used as a contact address. > - Encryption is enforced: Non encrypted messages are rejected Depends on configuration, see above. > - The senders pgp signature is checked, to ensure the message integrity I guess that's a default minimal basic thing everyone expects to be done > - The message is multiplied and resigned/reencrypted by the list server Same as Schleuder > - The signed and encrypted messages are delivered to the list members If this part was missing I wouldn't call it mailing list software ;-) > Well it's weekend, so I started to code. ;) Sound like you created a mitm! ;-) > Meanwhile the key functionalities are implemented and the project is ready for > some beta tests. It's very annoying to write emails to myself all the time to > check functionality. So if you want to try this, just give me a short > notification with your public key id. I will add your public key into the lists > keyring and add you to the recipients list. So, I'm sorry that I'm not here to beta-test, but would rather see Schleuder getting better as someone reinventing the wheel. Maybe your wheel is more round or has better brakes, I don't know. [2] It has happened to me before that I enthusiastically spend a lot of time on something that someone else already did. And sometimes that other project served as a good example or inspiration. > After some testings, the whole project will be available on SourceForge. I might be asking (too) much, but I'd suggest to reconsider SourceForge, they now try to push some drive-by installer in everyones mouth. I guess a discussion on that subject is too much off-topic for this list, so I'll stick with a link to a simple rant. [3] All in all, I hope I found the right tone in my mail, don't get it wrong, I applaud your energy and enthusiasm! And if someone figures a way to do group public key encryption, I'd be interested in hearing how that would work. ciao, kwadronaut [1] http://schleuder2.nadir.org/ [2] I wonder, were the first wheels in humankind equipped with brakes? [3] http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fallen/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From al-gnupg_users at none.at Sun Sep 22 20:39:03 2013 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Sun, 22 Sep 2013 20:39:03 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: <20130922102947.14aa4bf1@eunet.rs> References: <20130922102947.14aa4bf1@eunet.rs> Message-ID: <15906d1b7c4507c7ab3047a4946673dc@none.at> Hi Marko, Am 22-09-2013 10:29, schrieb Marko Randjelovic: > Of course it is not safe. If you realy need a smartphone, use some of > those that are supported by Replicant OS. http://replicant.us/ Thank you for your feedback. I'm not sure how much 'normal' or mass user are able to use this OS. Maybe there is a possibility to get pre-installed Replicant OS for the main stream, like the current devices with the pre-installed Vendor OS. Currently i don't know this possibility. Do you see any other solution for the users to use safely the private key? Best regards Aleks From al-gnupg_users at none.at Sun Sep 22 20:43:27 2013 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Sun, 22 Sep 2013 20:43:27 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: <523EAC3D.2090300@gmail.com> References: <523EAC3D.2090300@gmail.com> Message-ID: Dear Diego, Am 22-09-2013 10:37, schrieb NdK: > Il 21/09/2013 23:06, Aleksandar Lazic ha scritto: > >> What solution is available for public Web mail providers like gmail, >> gmx, hotmail, .... .? > Firefox+GreaseMonkey+script to interface to card? Your solution implies that you need to install all this components on all devices. I'm not sure that this is always possible. Do you see any other solution for the users to use safely the private key? Best regards Aleks From al-gnupg_users at none.at Sun Sep 22 20:47:57 2013 From: al-gnupg_users at none.at (Aleksandar Lazic) Date: Sun, 22 Sep 2013 20:47:57 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: <20130922084516.GB1571@fritha.org> References: <20130922084516.GB1571@fritha.org> Message-ID: <8b4315065ab1ba88c3794e8dca9744c3@none.at> Dear Heinz, Am 22-09-2013 10:45, schrieb Heinz Diehl: > On 22.09.2013, Aleksandar Lazic wrote: > >> What could be a perfect or at least a very good storage of the >> private Key. > > Spend a little bit money and buy you a smartcard and a reader. Then, > boot a machine without internet connection from an USB-stick or > CD/DVD with some live version (e.g. http://www.sysresccd.org ), > generate a fresh key pair and install it on your smartcard. Ok, that sound possible for people which have linux or unix experience, not the 'normal' mainstream user. The other question was how can a user could use such a key to sign or encrypt his or her mail on e.g. Smartphones? Best regards Aleks From oliver at wps-verlinden.de Sun Sep 22 21:34:07 2013 From: oliver at wps-verlinden.de (Oliver Verlinden) Date: Sun, 22 Sep 2013 21:34:07 +0200 Subject: CryptoList - Looking for beta testers In-Reply-To: <523F3809.9020100@aktivix.org> References: <201309221911.12744.oliver@wps-verlinden.de> <523F3809.9020100@aktivix.org> Message-ID: <201309222134.15587.oliver@wps-verlinden.de> On Sunday, 22. September 2013, 20:33:45 kwadronaut wrote: Hi kwadronaut, > On 22/09/13 19:10, Oliver Verlinden wrote: > > some days ago I had the idea of a pgp compatible mailing list. > > I know there is a mailman extension which supports pgp encrypted messages > > out there, but I wanted ta have a small, fast and easy to configure > > solution. No, I did not know Schleuder yet. Thank you for the link, I will take a look at this. > > ?re you also aware of Schleuder? [1] I don't want to surpress your > enthusiasm, but if possible, maybe, you can ameliorate that other thing > even more? > > With Schleuder: > > - A list member writes an pgp signed and encrypted message to the list > > server > > Or an outsider, depends on the configuration. There are some good use > cases, for example if a list address is used as a contact address. > > > - Encryption is enforced: Non encrypted messages are rejected > > Depends on configuration, see above. > > > - The senders pgp signature is checked, to ensure the message integrity > > I guess that's a default minimal basic thing everyone expects to be done > > > - The message is multiplied and resigned/reencrypted by the list server > > Same as Schleuder > > > - The signed and encrypted messages are delivered to the list members > > If this part was missing I wouldn't call it mailing list software ;-) That's right. This functionality is the basic functionality of a mailing list software (combined with secure cryptography). Depending on the peoples feedback I will imlement additional (useful) features. I will see..... > > > Well it's weekend, so I started to code. ;) > > Sound like you created a mitm! ;-) > > > Meanwhile the key functionalities are implemented and the project is > > ready for some beta tests. It's very annoying to write emails to myself > > all the time to check functionality. So if you want to try this, just > > give me a short notification with your public key id. I will add your > > public key into the lists keyring and add you to the recipients list. > > So, I'm sorry that I'm not here to beta-test, but would rather see > Schleuder getting better as someone reinventing the wheel. Maybe your > wheel is more round or has better brakes, I don't know. [2] It has > happened to me before that I enthusiastically spend a lot of time on > something that someone else already did. And sometimes that other > project served as a good example or inspiration. > As I mentioned above. I will take a deeper look at Schleuder. By the way. Is it open source too? > > After some testings, the whole project will be available on SourceForge. > > I might be asking (too) much, but I'd suggest to reconsider SourceForge, > they now try to push some drive-by installer in everyones mouth. I guess > a discussion on that subject is too much off-topic for this list, so > I'll stick with a link to a simple rant. [3] Oh really? I did not heard about that. The projects I downloaded from SourceForge were "clean". > > All in all, I hope I found the right tone in my mail, don't get it > wrong, I applaud your energy and enthusiasm! And if someone figures a > way to do group public key encryption, I'd be interested in hearing how > that would work. No, your tone is absolutely fine. I just spend some great programming hours on this project and got some experiences with encrypt things programmatically. You're right, if I have a great idea and too much free time, I just try to implement this and follow this target very enthisiastic. That's me. ;) > > ciao, > kwadronaut Best regards Oliver Verlinden > > [1] http://schleuder2.nadir.org/ > [2] I wonder, were the first wheels in humankind equipped with brakes? > [3] > http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fall > en/ -------------- 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 ralf at ramses-pyramidenbau.de Sat Sep 21 17:56:51 2013 From: ralf at ramses-pyramidenbau.de (Ralf Ramsauer) Date: Sat, 21 Sep 2013 17:56:51 +0200 Subject: Generation of key ID's Message-ID: <523DC1C3.6070104@ramses-pyramidenbau.de> Hi, just a short question: When a new GPG key gets generated, then in fact and by default two key pairs get generated. Let's assume we deployed RSA-RSA. Both, signature and encryption key get their own ID's. How are these ID's generated? Randomly? Or are they some kind of checksum of the modulus of the key? And why is it done that way? I had a look into the source, but I wasn't able to find it out straight away. Sure someone of you knows this by heart :-) Thanks in advance! -- Ralf Ramsauer PGP: 0x8F10049B From ndk.clanbo at gmail.com Sun Sep 22 22:16:59 2013 From: ndk.clanbo at gmail.com (NdK) Date: Sun, 22 Sep 2013 22:16:59 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: References: <523EAC3D.2090300@gmail.com> Message-ID: <523F503B.4020602@gmail.com> Il 22/09/2013 20:43, Aleksandar Lazic ha scritto: >> Firefox+GreaseMonkey+script to interface to card? > Your solution implies that you need to install all this components on > all devices. Sure. Unless you want to trust someone else to handle your keys. But then don't be surprised if who have something sensitive to tell, *not* to tell it to you... > I'm not sure that this is always possible. Then that user won't be able to use encryption. At least not on that device. > Do you see any other solution for the users to use safely the private key? "I want to surf the web but I can't install a browser. How can I do it?" BYtE, Diego. From rdohm321 at gmail.com Sun Sep 22 22:24:33 2013 From: rdohm321 at gmail.com (Randolph D.) Date: Sun, 22 Sep 2013 22:24:33 +0200 Subject: CryptoList - Looking for beta testers In-Reply-To: <201309222134.15587.oliver@wps-verlinden.de> References: <201309221911.12744.oliver@wps-verlinden.de> <523F3809.9020100@aktivix.org> <201309222134.15587.oliver@wps-verlinden.de> Message-ID: you can look at the buzz channel function of http://spot-on.sf.net too, that is a kind of encrypted irc as message list. regards 2013/9/22 Oliver Verlinden > > No, I did not know Schleuder yet. Thank you for the link, I will take a > look > at this. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sun Sep 22 22:30:52 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 22 Sep 2013 16:30:52 -0400 Subject: Generation of key ID's In-Reply-To: <523DC1C3.6070104@ramses-pyramidenbau.de> References: <523DC1C3.6070104@ramses-pyramidenbau.de> Message-ID: <523F537C.2090707@fifthhorseman.net> On 09/21/2013 11:56 AM, Ralf Ramsauer wrote: > Both, signature and encryption key get their own ID's. How are these > ID's generated? Randomly? the key IDs are the low-order bits of the fingerprints. the fingerprints are an SHA-1 digest of the creation date of the key plus the public elements of the key plus some boilerplate/formatting. You can read up on the specifics in the standard: https://tools.ietf.org/html/rfc4880#section-12.2 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 dkg at fifthhorseman.net Sun Sep 22 22:45:19 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 22 Sep 2013 16:45:19 -0400 Subject: CryptoList - Looking for beta testers In-Reply-To: <201309221911.12744.oliver@wps-verlinden.de> References: <201309221911.12744.oliver@wps-verlinden.de> Message-ID: <523F56DF.50201@fifthhorseman.net> On 09/22/2013 01:10 PM, Oliver Verlinden wrote: > some days ago I had the idea of a pgp compatible mailing list. > I know there is a mailman extension which supports pgp encrypted messages out > there, but I wanted ta have a small, fast and easy to configure solution. Very cool to see that you've done this work and that you want to see something like this happen. It raises a lot of questions for me, though: how does your system know whose keys are whose? what if a key expires? how does it handle new subscribers? who gets access to the lists? are they archived? what about messages that can't be delivered right away? How do i as a user know what keys to encrypt to? how do i as an admin make sure my user's confidential data doesn't leak to outside parties? I'm not saying that mailman is perfect, but there are some legitimate reasons that mailman is complex. Dealing with store-and-forward message delivery in a dynamic network is challenging in its own right, let alone getting the key management right for lists that deal with crypto. Taking on all those tasks and getting them right is a tall order! Abhilash Raj has done a bunch of work on Mailman over the last few months, working toward integrating Mailman and OpenPGP. I'm quite sure he would be happy to collaborate with you if you're interested in working as part of a team on a project that other people will help maintain :) 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 kententen at me.com Mon Sep 23 01:08:01 2013 From: kententen at me.com (Kenneth Jones) Date: Mon, 23 Sep 2013 07:08:01 +0800 Subject: CryptoList - Looking for beta testers In-Reply-To: <523F56DF.50201@fifthhorseman.net> References: <201309221911.12744.oliver@wps-verlinden.de> <523F56DF.50201@fifthhorseman.net> Message-ID: <523F7851.40201@Me.com> On 09/23/2013 04:45 AM, Daniel Kahn Gillmor wrote: > On 09/22/2013 01:10 PM, Oliver Verlinden wrote: >> some days ago I had the idea of a pgp compatible mailing list. >> I know there is a mailman extension which supports pgp encrypted messages out >> there, but I wanted ta have a small, fast and easy to configure solution. > Very cool to see that you've done this work and that you want to see > something like this happen. It raises a lot of questions for me, > though: how does your system know whose keys are whose? what if a key > expires? how does it handle new subscribers? who gets access to the > lists? are they archived? what about messages that can't be delivered > right away? How do i as a user know what keys to encrypt to? how do i > as an admin make sure my user's confidential data doesn't leak to > outside parties? > > I'm not saying that mailman is perfect, but there are some legitimate > reasons that mailman is complex. Dealing with store-and-forward message > delivery in a dynamic network is challenging in its own right, let alone > getting the key management right for lists that deal with crypto. > Taking on all those tasks and getting them right is a tall order! > > Abhilash Raj has done a bunch of work on > Mailman over the last few months, working toward integrating Mailman and > OpenPGP. I'm quite sure he would be happy to collaborate with you if > you're interested in working as part of a team on a project that other > people will help maintain :) > > Regards, > > --dkg > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users Hmmm... Last two messages from Daniel prompt my Thunderbird/Enigmail setup that an OpenPGP secret key is needed to decrypt the message (which nonetheless shows up in cleartext). What's happening? Is it signed with a public key? Can you do that? Why would one wnt to? Puzzled, Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xE2557AA7.asc Type: application/pgp-keys Size: 3600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: KenTenTen.vcf Type: text/x-vcard Size: 456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From mirimir at riseup.net Mon Sep 23 01:42:54 2013 From: mirimir at riseup.net (mirimir) Date: Sun, 22 Sep 2013 23:42:54 +0000 Subject: CryptoList - Looking for beta testers In-Reply-To: <523F7851.40201@Me.com> References: <201309221911.12744.oliver@wps-verlinden.de> <523F56DF.50201@fifthhorseman.net> <523F7851.40201@Me.com> Message-ID: <523F807E.8070207@riseup.net> On 09/22/2013 11:08 PM, Kenneth Jones wrote: > On 09/23/2013 04:45 AM, Daniel Kahn Gillmor wrote: SNIP > Hmmm... Last two messages from Daniel prompt my Thunderbird/Enigmail > setup that an OpenPGP secret key is needed to decrypt the message (which > nonetheless shows up in cleartext). What's happening? Is it signed with > a public key? Can you do that? Why would one wnt to? > Puzzled, > > Ken They're signed by Daniel Kahn Gillmor's key 0xD21739E9, just as your message is signed by your GuidedSuccessLLC key 0xE2557AA7. Neither are encrypted. From John at enigmail.net Mon Sep 23 02:31:50 2013 From: John at enigmail.net (John Clizbe) Date: Sun, 22 Sep 2013 19:31:50 -0500 Subject: CryptoList - Looking for beta testers In-Reply-To: <523F7851.40201@Me.com> References: <201309221911.12744.oliver@wps-verlinden.de> <523F56DF.50201@fifthhorseman.net> <523F7851.40201@Me.com> Message-ID: <523F8BF6.4060702@enigmail.net> Kenneth Jones wrote: > Hmmm... Last two messages from Daniel prompt my Thunderbird/Enigmail setup > that an OpenPGP secret key is needed to decrypt the message (which nonetheless > shows up in cleartext). What's happening? Is it signed with a public key? Can > you do that? Why would one wnt to? > Puzzled, > > Ken Both of Dan's show as OpenPGP Security Info Good signature from Daniel Kahn Gillmor Key ID: 0xD21739E9 / Signed on: 09/22/2013 03:30 PM Key fingerprint: 0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9 -- 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 kententen at me.com Mon Sep 23 04:57:18 2013 From: kententen at me.com (Kenneth Jones) Date: Mon, 23 Sep 2013 10:57:18 +0800 Subject: CryptoList - Looking for beta testers In-Reply-To: <523F8BF6.4060702@enigmail.net> References: <201309221911.12744.oliver@wps-verlinden.de> <523F56DF.50201@fifthhorseman.net> <523F7851.40201@Me.com> <523F8BF6.4060702@enigmail.net> Message-ID: <523FAE0E.8090004@Me.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/23/2013 08:31 AM, John Clizbe wrote: > Kenneth Jones wrote: > >> > ...and when I go back to review them after having read several intervening messages, they (and all others, it seems) behave just as I expected them to behave originally. Fascinating. I'm going back to bed. Thanks, Ken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSP64BAAoJEN0Mg/7iVXqnmWwH/1n4VBUau+Hebbb3DtiK7P5v Gd9If8VZD6eSjBHCNocqFJhGZBl62qGkO8Jo99ZziEKs1mDWCFdch2p8s5F6V2di 1W0XTeNwzouSeV3MuMDIBAuetB+iPxNwg+rjZMxD1llcBTQttztq87hYVH+Ssd/u ww2DPk718rNPh7wSBSKPVm8d2rppQfpds4iuqKN95a8HnbUDsB259MOY1+Nscw3w XFIq2XOY7EEiXYPLj/HXhjocfblkTfbkK7Y+DW/NG+puXCju5wrAGMcJFONtp6au U6EBwpa9nUggIfWEgYwCxNPEhzO7YUGM1D+HbvNQuV2fh17KHvETLYD7+SMbbOU= =g2Yk -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: KenTenTen.vcf Type: text/x-vcard Size: 456 bytes Desc: not available URL: From htd at fritha.org Mon Sep 23 07:28:05 2013 From: htd at fritha.org (Heinz Diehl) Date: Mon, 23 Sep 2013 07:28:05 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: <8b4315065ab1ba88c3794e8dca9744c3@none.at> References: <20130922084516.GB1571@fritha.org> <8b4315065ab1ba88c3794e8dca9744c3@none.at> Message-ID: <20130923052805.GA1553@fritha.org> On 22.09.2013, Aleksandar Lazic wrote: [Key on smartcard] > Ok, that sound possible for people which have linux or unix experience, not > the 'normal' mainstream user. On the other hand, it would be a great learning experience for those who dare to try ;-) It's well documented and not too hard. > The other question was how can a user could use such a key to sign or > encrypt his or her mail on e.g. Smartphones? I have no experience with email on smartphones. In fact, I don't have internet switched on on my phone either, because I don't need it (and it's somewhat expensive in my country). Generally, I think you can't have it all. Can't imagine how long it will take to encrypt/decrypt a mail on a smartphone using the 4k key which I have on my smartcard.. From oliver at wps-verlinden.de Mon Sep 23 08:03:54 2013 From: oliver at wps-verlinden.de (Oliver Verlinden) Date: Mon, 23 Sep 2013 08:03:54 +0200 Subject: CryptoList - Looking for beta testers In-Reply-To: <523F56DF.50201@fifthhorseman.net> References: <201309221911.12744.oliver@wps-verlinden.de> <523F56DF.50201@fifthhorseman.net> Message-ID: <201309230804.02871.oliver@wps-verlinden.de> > Very cool to see that you've done this work and that you want to see > something like this happen. It raises a lot of questions for me, > though: Ok, let me answer them. ;) > how does your system know whose keys are whose? The key is picked by one or more given email addresses. The recipient email address drives the key selection. > what if a key expires? Expired keys are not better then non available keys. Encryption will fail and the list admin is notified. > how does it handle new subscribers? ... need to be added to the list manually. I don't want to add encryption keys automatically. The list admin should check the level of trust, so this is used to be a manual task. I asume that the list of subscribers is mainly fixed and changes are a rare event. > who gets access to the lists? See above. In productive environments the list admin is hosting my software and of course may decide who to give access to the list. In this list I am searching for beta testers so everyone who is interested will get access. > are they archived? No archive functionality at the moment. > what about messages that can't be delivered > right away? At the moment delivery failures are not handled. So if the outbound mail server does not accept the message, it will be skipped. In the future some errors should have a retry count and be processed again after some time. > How do i as a user know what keys to encrypt to? You only encrypt with the list's public key. > how do i as an admin make sure my user's confidential data doesn't leak to > outside parties? As the list subscribers are added manually by you (as the admin), you should only give trustful people access to the list. The list itself does not leak any confidental information. Of course if you have a untrusted member in the list he will receive the confidental shared information (in a encrypted way, but he is able to unencrypt and read them) > Dealing with store-and-forward message delivery in a dynamic network is challenging in its own right What do you mean with store-and-forward handling. Can you explain? > > Regards, > > --dkg 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 wk at gnupg.org Mon Sep 23 08:13:53 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Sep 2013 08:13:53 +0200 Subject: OpenPGP card, gpgsm, decrypt In-Reply-To: <2242538.IbLcNkSWhX@asus> (=?utf-8?Q?=22J=C3=B6rg?= Deckert"'s message of "Sat, 21 Sep 2013 19:28:14 +0200") References: <2242538.IbLcNkSWhX@asus> Message-ID: <87li2om5em.fsf@vigenere.g10code.de> On Sat, 21 Sep 2013 19:28, joergd at bitquell.de said: > S/MIME decryption with OpenPGP card doesn't work for me: How did you create the key for S/MIME? > $ LC_ALL=C gpg --list-secret-keys Please run LC_ALL=C gpg --with-keygrip --list-secret-keys (I assume gpg2 is installed as gpg.) > $ LC_ALL=C gpgsm --list-secret-keys Please run LC_ALL=C gpgsm --with-keygrip --list-secret-keys this allows to see which key is actually use. The keygrip is a protocol agnostic fingerprint. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From josef at netpage.dk Mon Sep 23 08:35:16 2013 From: josef at netpage.dk (Josef Schneider) Date: Mon, 23 Sep 2013 08:35:16 +0200 Subject: Question about a perfect private Key store for today's environment In-Reply-To: <20130923052805.GA1553@fritha.org> References: <20130922084516.GB1571@fritha.org> <8b4315065ab1ba88c3794e8dca9744c3@none.at> <20130923052805.GA1553@fritha.org> Message-ID: On Mon, Sep 23, 2013 at 7:28 AM, Heinz Diehl wrote: > Generally, I think you can't have it all. Can't imagine how long it > will take to encrypt/decrypt a mail on a smartphone using the 4k key > which I have on my smartcard.. The cheapest phones you can get here have at least 800Mhz ARMv6 CPUs! My current one has a Quad-Core 4x1,5Ghz ARMv7. I don't think that will be any problem! On slow phones maybe you have to wait a few seconds, but you probably won't send that many mails on your phone that it matters. Best regards, Josef From joergd at bitquell.de Mon Sep 23 11:01:26 2013 From: joergd at bitquell.de (=?ISO-8859-1?Q?J=F6rg?= Deckert) Date: Mon, 23 Sep 2013 11:01:26 +0200 Subject: OpenPGP card, gpgsm, decrypt In-Reply-To: <87li2om5em.fsf@vigenere.g10code.de> References: <2242538.IbLcNkSWhX@asus> <87li2om5em.fsf@vigenere.g10code.de> Message-ID: <3149773.immk6VYuVn@nb-jdeckert> > How did you create the key for S/MIME? $ gpgsm --learn-card $ LC_ALL=C gpgsm --gen-key > ~/joergd-csr.pem gpgsm (GnuPG) 2.0.21; 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. Please select what kind of key you want: (1) RSA (2) Existing key (3) Existing key from card Your selection? 3 Serial number of the card: D2760001240102000005000010B10000 Available keys: (1) C080E663512A54C29D1D1108308AF44D28A0EBAE OPENPGP.1 (2) F106A6B05C3E509BC3BC5C25D02E7D1DE94060F2 OPENPGP.2 (3) 719D81D0405AF65B1BEC322725CB23DCECE389C4 OPENPGP.3 Your selection? 3 Possible actions for a RSA key: (1) sign, encrypt (2) sign (3) encrypt Your selection? 1 Enter the X.509 subject name: C=DE, ST=Thueringen, L=Gera, O=Test, OU=Test, CN=J D, EMAIL=joergd at bitquell.de Enter email addresses (end with an empty line): > joergd at bitquell.de > Enter DNS names (optional; end with an empty line): > Enter URIs (optional; end with an empty line): > Parameters to be used for the certificate request: Key-Type: card:OPENPGP.3 Key-Length: 1024 Key-Usage: sign, encrypt Name-DN: C=DE, ST=Thueringen, L=Gera, O=Test, OU=Test, CN=J D, EMAIL=joergd at bitquell.de Name-Email: joergd at bitquell.de Then I have created a certificate from the request. $ gpgsm --import CA-priv.crt $ gpgsm --import joergd.crt > Please run > LC_ALL=C gpg --with-keygrip --list-secret-keys > (I assume gpg2 is installed as gpg.) $ LC_ALL=C gpg --with-keygrip --list-secret-keys gpg: invalid option "--with-keygrip" $ LC_ALL=C gpg --version gpg (GnuPG) 2.0.21 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 > Please run > LC_ALL=C gpgsm --with-keygrip --list-secret-keys $ LC_ALL=C gpgsm --with-keygrip --list-secret-keys gpgsm: invalid option "--with-keygrip" Btw. the keygrips are in place (I think): $ ls -1 ~/.gnupg/private-keys-v1.d/ 719D81D0405AF65B1BEC322725CB23DCECE389C4.key C080E663512A54C29D1D1108308AF44D28A0EBAE.key F106A6B05C3E509BC3BC5C25D02E7D1DE94060F2.key -- J?rg Deckert From ryan at b19.org Mon Sep 23 15:31:33 2013 From: ryan at b19.org (Ryan Sawhill) Date: Mon, 23 Sep 2013 09:31:33 -0400 Subject: gpg: Go ahead and type your message In-Reply-To: References: Message-ID: Robert is correct that the usual way people run gpg is by passing it input via a pipe or from a file; however, what you're aiming for is totally doable. The missing piece you need is the keyboard shortcut: Ctrl-d, e.g.: [rsaw:~]$ gpg -ac Enter passphrase: Repeat passphrase: Here is where I started typing my message... Woooo! -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.14 (GNU/Linux) jA0ECQMImb+Sa0FjCzRg0lABQKbzLKTEWfsbpSQHdaxF78Rxsbas3efTDRHcVIKq 87YFppU4nkhsmB0DUD6cv3ILLF20KTx3/azi0+mJhWfnPdt8t41MFI2NjVTSwThM wQ== =BsPC -----END PGP MESSAGE----- [rsaw:~]$ On Sun, Sep 22, 2013 at 10:57 AM, Len Cooley wrote: > I'm sure this has been a topic of inquiry many times, but I can't seem to > find useful information about it. I haven't used gpg command line for a long > time (I actually haven't used gpg much at all in the past few years, as I've > had a Windows machine, and I just don't trust the OS), but I have gpg on my > android phone. It utilizes the terminal. When I type in gpg (return) I get > the message that I placed in the subject line. I'm not really sure what I do > at that point. If I use Ctrl C, the program terminates. If I hit CtrlZ, I > think it suspends the program (but I'm not sure). > Would/could I use this area to type a text message that I would then, > subsequently, encrypt/sign/save? If so, where could I find a set of basic > commands to use with this (what appears to be) text editor? > If this isn't what it's intended for, what's it for? Thanks for bearing with > me. > > -- > > > http://www.auditmypc.com/freescan/antispam.html > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From ryan at b19.org Mon Sep 23 15:34:48 2013 From: ryan at b19.org (Ryan Sawhill) Date: Mon, 23 Sep 2013 09:34:48 -0400 Subject: gpg: Go ahead and type your message In-Reply-To: References: Message-ID: Also Len: if you're looking for a Linux gpg gui to do these kinds of things, I would recommend Pyrite (https://github.com/ryran/pyrite). I'm partial of course, since I wrote it. On Mon, Sep 23, 2013 at 9:31 AM, Ryan Sawhill wrote: > Robert is correct that the usual way people run gpg is by passing it > input via a pipe or from a file; however, what you're aiming for is > totally doable. The missing piece you need is the keyboard shortcut: > Ctrl-d, e.g.: > > [rsaw:~]$ gpg -ac > Enter passphrase: > Repeat passphrase: > Here is where I started typing my message... > Woooo! > > -----BEGIN PGP MESSAGE----- > Version: GnuPG v1.4.14 (GNU/Linux) > > jA0ECQMImb+Sa0FjCzRg0lABQKbzLKTEWfsbpSQHdaxF78Rxsbas3efTDRHcVIKq > 87YFppU4nkhsmB0DUD6cv3ILLF20KTx3/azi0+mJhWfnPdt8t41MFI2NjVTSwThM > wQ== > =BsPC > -----END PGP MESSAGE----- > [rsaw:~]$ > > On Sun, Sep 22, 2013 at 10:57 AM, Len Cooley wrote: >> I'm sure this has been a topic of inquiry many times, but I can't seem to >> find useful information about it. I haven't used gpg command line for a long >> time (I actually haven't used gpg much at all in the past few years, as I've >> had a Windows machine, and I just don't trust the OS), but I have gpg on my >> android phone. It utilizes the terminal. When I type in gpg (return) I get >> the message that I placed in the subject line. I'm not really sure what I do >> at that point. If I use Ctrl C, the program terminates. If I hit CtrlZ, I >> think it suspends the program (but I'm not sure). >> Would/could I use this area to type a text message that I would then, >> subsequently, encrypt/sign/save? If so, where could I find a set of basic >> commands to use with this (what appears to be) text editor? >> If this isn't what it's intended for, what's it for? Thanks for bearing with >> me. >> >> -- >> >> >> http://www.auditmypc.com/freescan/antispam.html >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> From andrew.long at mac.com Mon Sep 23 18:56:58 2013 From: andrew.long at mac.com (Andrew Long) Date: Mon, 23 Sep 2013 17:56:58 +0100 Subject: PGP/GPG confusing PGPDisk? Message-ID: <34AE5ACC-416E-45C4-8662-64A1A29288D2@Mac.com> This is a bit of-topic for this list but I thought I'd float it here before trying to get an answer out of Symantec. Back in about JUne I created a (small) PGP disk using PGP Desktop for Mac. I never actually used it but it would mount itself on re-boots and was (apparently) there and available. Since I installed the security update to Lion last week though, this disk refuses to mount and complains about having been encrypted with an incompatible cipher. I believe that it was created with AES256. OK so it's no great loss - there wasn't anything in it - I'll create a new one. Only every time I try this now I get the same error, no matter what algorithm I choose from the dropdown box (one of CAST5, AES256 and EME2-AES256). I was wondering if it is possible/likely that, because I have both PGP & GnuPG installed on the same machine and keep copies of my public key on both the PGO keyservers & sks-keyserers that I might have introduced some confusion into the choices of algorithms available between the two different installations? Anyone have any thoughts on how to diagnose/resolve the situation, please? MAC )SX 10.7.5 on a 2.8GHz Intel Core i7 with 16Gb of RAM. saganami-island:~ andy$ gpg --version gpg (GnuPG) 1.4.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Regards, Andy -- Andrew Long andrew dot long at mac dot com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From peter at digitalbrains.com Mon Sep 23 20:23:03 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 23 Sep 2013 20:23:03 +0200 Subject: OpenPGP card, gpgsm, decrypt In-Reply-To: <3149773.immk6VYuVn@nb-jdeckert> References: <2242538.IbLcNkSWhX@asus> <87li2om5em.fsf@vigenere.g10code.de> <3149773.immk6VYuVn@nb-jdeckert> Message-ID: <52408707.7060607@digitalbrains.com> On 23/09/13 11:01, J?rg Deckert wrote: > (1) C080E663512A54C29D1D1108308AF44D28A0EBAE OPENPGP.1 > (2) F106A6B05C3E509BC3BC5C25D02E7D1DE94060F2 OPENPGP.2 > (3) 719D81D0405AF65B1BEC322725CB23DCECE389C4 OPENPGP.3 > Your selection? 3 > Possible actions for a RSA key: > (1) sign, encrypt > (2) sign > (3) encrypt > Your selection? 1 > [...] > Key-Type: card:OPENPGP.3 > Key-Length: 1024 > Key-Usage: sign, encrypt I think I see what's going wrong here. On my card, OPENPGP.3 refers to the authentication key. If you are trying to use this to decrypt stuff, the card will outright refuse. Only the encryption key of the card will decrypt stuff, and that one should refuse to sign. The other two will only sign stuff. 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 lunar at debian.org Mon Sep 23 19:40:59 2013 From: lunar at debian.org (=?iso-8859-1?B?Suly6W15?= Bobbio) Date: Mon, 23 Sep 2013 19:40:59 +0200 Subject: gpgme: is there a way to identify a signature as clear text or detached? Message-ID: <20130923174059.GG31401@loar> Hi! While having a look at a missing feature in seahorse-nautilus?[1], I did not find a way to use GPGME to figure out if a signature was a clear text signature or a detached signature. The idea for seahorse-nautilus is to allow users to right click on a `.asc` file and select ?Verify signature??. Ideally, if the file contains a clear text signature, it would proceed to verify the signature immediately. When having a detached signature, it would eventually prompt the user about the location of the signed material. Is there an easy way to give GPGME the file and know if it is a clear text signature or a detached signature? Another related question: in my tests, using the following always failed: err = gpgme_op_verify(ctx, sig, NULL, NULL); It seems that the `plain` 4th argument is mandatory when verifying cleartext signature. I don't understand the rationale for that. In seahorse-nautilus use case, we are only interested in the validity of the signature. Thanks for your help! [1]?https://bugzilla.gnome.org/show_bug.cgi?id=551042 -- 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 Andrew.Long at Yahoo.com Mon Sep 23 18:34:04 2013 From: Andrew.Long at Yahoo.com (Andrew Long) Date: Mon, 23 Sep 2013 17:34:04 +0100 Subject: PGP/GPG confusing PGPDisk? Message-ID: This is a bit of-topic for this list but I thought I'd float it here before trying to get an answer out of Symantec. Back in about JUne I created a (small) PGP disk using PGP Desktop for Mac. I never actually used it but it would mount itself on re-boots and was (apparently) there and available. Since I installed the security update to Lion last week though, this disk refuses to mount and complains about having been encrypted with an incompatible cipher. I believe that it was created with AES256. OK so it's no great loss - there wasn't anything in it - I'll create a new one. Only every time I try this now I get the same error, no matter what algorithm I choose from the dropdown box (one of CAST5, AES256 and EME2-AES256). I was wondering if it is possible/likely that, because I have both PGP & GnuPG installed on the same machine and keep copies of my public key on both the PGO keyservers & sks-keyserers that I might have introduced some confusion into the choices of algorithms available between the two different installations? Anyone have any thoughts on how to diagnose/resolve the situation, please? MAC )SX 10.7.5 on a 2.8GHz Intel Core i7 with 16Gb of RAM. saganami-island:~ andy$ gpg --version gpg (GnuPG) 1.4.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Regards, Andy -- Andrew Long andrew dot long at yahoo dot com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From wk at gnupg.org Mon Sep 23 22:34:36 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Sep 2013 22:34:36 +0200 Subject: OpenPGP card, gpgsm, decrypt In-Reply-To: <52408707.7060607@digitalbrains.com> (Peter Lebbing's message of "Mon, 23 Sep 2013 20:23:03 +0200") References: <2242538.IbLcNkSWhX@asus> <87li2om5em.fsf@vigenere.g10code.de> <3149773.immk6VYuVn@nb-jdeckert> <52408707.7060607@digitalbrains.com> Message-ID: <874n9bl1k3.fsf@vigenere.g10code.de> On Mon, 23 Sep 2013 20:23, peter at digitalbrains.com said: > I think I see what's going wrong here. On my card, OPENPGP.3 refers to the > authentication key. If you are trying to use this to decrypt stuff, the card > will outright refuse. Only the encryption key of the card will decrypt stuff, Right. We should add more checks here. This missing check is good for noticing that the "Existing key from card" feature is actually used ;-). I added the feature to create an X.509 key from the OpenPGP card. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cp at axs.org Tue Sep 24 02:21:09 2013 From: cp at axs.org (Chuck Peters) Date: Tue, 24 Sep 2013 00:21:09 +0000 Subject: Best Practice, subkeys and subkey cross-certification. Message-ID: <20130924002109.GA5328@xen.axs.org> I attended a small key signing party Saturday after generating a new key with multiple subkeys with the notion of having a email signing keys on less secure systems like my VPS (using mutt) and a separate subkey for each computer or device. https://wiki.debian.org/subkeys says "The really useful part of subkeys is that they can be revoked independently of the master keys, and also stored separately from them." ?So I can keep my primary key off the network and use it only for signing other peoples keys. ? Another sensible precaution is to have different passphrases for each of these subkeys. ?However when working with the full key set when I attempted to change the passphrase for a subkey, it also changed the passphrase for the main key. ?I'm assuming at this point when I separate the keys, I can change the passphrase as planned... ?Is this a bug? ?Should I file a bug report? ?? Then I decided I should do some more reading and get a better understanding of subkeys and of the more recent documentation and blogs I found the following:? http://www.gnupg.org/faq/subkey-cross-certify.en.html https://alexcabal.com/creating-the-perfect-gpg-keypair/ http://blog.dest-unreach.be/wp-content/uploads/2009/04/pgp-subkeys.html https://grepular.com/Android_Privacy_Guard_and_Subkeys OK, the FAQ is the first I heard about?subkey cross-certification. ?Is that info current and correct? ?What is recommended? Does anyone have some pointers on personal or organizational Policy and Best Practices documents under a copyright or license terms that allow modification? Thanks, Chuck From mailinglisten at hauke-laging.de Tue Sep 24 03:41:22 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Tue, 24 Sep 2013 03:41:22 +0200 Subject: Best Practice, subkeys and subkey cross-certification. In-Reply-To: <20130924002109.GA5328@xen.axs.org> References: <20130924002109.GA5328@xen.axs.org> Message-ID: <1523257.vbmaAPirSu@inno.berlin.laging.de> Am Di 24.09.2013, 00:21:09 schrieb Chuck Peters: > I attended a small key signing party Saturday after generating a new key > with multiple subkeys with the notion of having a email signing keys on > less secure systems like my VPS (using mutt) and a separate subkey for > each computer or device. Would you explain that in more detail? I am not sure whether that makes sense. > So I can keep my primary key off the > network and use it only for signing other peoples keys. You should consider not only storing the key offline but using it in a safe environment only. Besides managing your own and other keys it makes sense to use it for signing very important data (like your key policy). > Another sensible precaution is to have different passphrases for each of > these subkeys. However when working with the full key set when I > attempted to change the passphrase for a subkey, it also changed the > passphrase for the main key. I'm assuming at this point when I separate > the keys, I can change the passphrase as planned... Is this a bug? GnuPG can use keys with subkeys which have different passphrases but it cannot create such keys (at least not with "normal operation"). This is not a bug, just a missing feature. > OK, the FAQ is the first I heard about subkey cross-certification. Is > that info current and correct? What is recommended? Don't care about that, it's handled automatically. 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 Tue Sep 24 03:49:04 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 23 Sep 2013 21:49:04 -0400 Subject: PGP/GPG confusing PGPDisk? In-Reply-To: References: Message-ID: <5240EF90.3090504@sixdemonbag.org> On 9/23/2013 12:34 PM, Andrew Long wrote: > Since I installed the security update to Lion last week though, this > disk refuses to mount and complains about having been encrypted with > an incompatible cipher. I believe that it was created with AES256. You have the most probable cause of the problem right there. The problem happened after a security update to Lion. Look there. > I was wondering if it is possible/likely that, because I have both > PGP & GnuPG installed on the same machine and keep copies of my > public key on both the PGO keyservers & sks-keyserers that I might > have introduced some confusion into the choices of algorithms > available between the two different installations? Nope. PGP is smart enough to use its own keyrings, not GnuPG's. Whether your certificate is on the keyserver network also has nothing to do with it. I'm sorry about your problem, but really, it sounds as if it's either Apple's fault or Symantec's -- depending on whether Apple informed developers about the change which ultimately broke PGPDisk. If they did then it's Symantec's problem, if they didn't then it's Apple's problem. From joergd at bitquell.de Tue Sep 24 08:03:42 2013 From: joergd at bitquell.de (=?ISO-8859-1?Q?J=F6rg?= Deckert) Date: Tue, 24 Sep 2013 08:03:42 +0200 Subject: OpenPGP card, gpgsm, decrypt In-Reply-To: <52408707.7060607@digitalbrains.com> References: <2242538.IbLcNkSWhX@asus> <3149773.immk6VYuVn@nb-jdeckert> <52408707.7060607@digitalbrains.com> Message-ID: <7346590.OKxEmCa9Sr@nb-jdeckert> > I think I see what's going wrong here. On my card, OPENPGP.3 refers to the > authentication key. If you are trying to use this to decrypt stuff, the card > will outright refuse. Only the encryption key of the card will decrypt > stuff, and that one should refuse to sign. The other two will only sign > stuff. Right. But if I use OPENPGP.2 to create the CSR, I get: Really create request? (y/N) y Now creating certificate request. This may take a while ... gpgsm: about to sign CSR for key: &F106A6B05C3E509BC3BC5C25D02E7D1DE94060F2 gpgsm: signing failed: Invalid ID gpgsm: error creating certificate request: Invalid ID This is because the encryption key cannot sign the CSR. -- J?rg Deckert From wk at gnupg.org Tue Sep 24 09:02:12 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Sep 2013 09:02:12 +0200 Subject: OpenPGP card, gpgsm, decrypt In-Reply-To: <7346590.OKxEmCa9Sr@nb-jdeckert> (=?utf-8?Q?=22J=C3=B6rg?= Deckert"'s message of "Tue, 24 Sep 2013 08:03:42 +0200") References: <2242538.IbLcNkSWhX@asus> <3149773.immk6VYuVn@nb-jdeckert> <52408707.7060607@digitalbrains.com> <7346590.OKxEmCa9Sr@nb-jdeckert> Message-ID: <87zjr2k8i3.fsf@vigenere.g10code.de> On Tue, 24 Sep 2013 08:03, joergd at bitquell.de said: > This is because the encryption key cannot sign the CSR. You are right. Sorry, there is no standard solution for this. It depends on how a CA handles encryption keys. Set up your own CA and you do not need a CSR. With the card there is no way to sign using the encryption key - padding is handled inside the card and thus it can't be used to create a signature. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 24 09:18:05 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Sep 2013 09:18:05 +0200 Subject: gpgme: is there a way to identify a signature as clear text or detached? In-Reply-To: <20130923174059.GG31401@loar> (=?utf-8?B?IkrDqXLDqW15?= Bobbio"'s message of "Mon, 23 Sep 2013 19:40:59 +0200") References: <20130923174059.GG31401@loar> Message-ID: <87vc1qk7rm.fsf@vigenere.g10code.de> On Mon, 23 Sep 2013 19:40, lunar at debian.org said: > Is there an easy way to give GPGME the file and know if it is a > clear text signature or a detached signature? No. You may simply try to verify and only in the case of an error assume a detached signature and ask for the data file. The new gpgme_data_identify does not distinguish between a detached and a cleartext signature either. > Another related question: in my tests, using the following always > failed: > > err = gpgme_op_verify(ctx, sig, NULL, NULL); > > It seems that the `plain` 4th argument is mandatory when verifying > cleartext signature. I don't understand the rationale for that. In You usually need this to present the signed text. Without passing it through gpg you would need to do the un-escaping yourself. Feel free to add a feature request in the bug tracker. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From joergd at bitquell.de Tue Sep 24 09:36:44 2013 From: joergd at bitquell.de (=?ISO-8859-1?Q?J=F6rg?= Deckert) Date: Tue, 24 Sep 2013 09:36:44 +0200 Subject: OpenPGP card, gpgsm, decrypt In-Reply-To: <87zjr2k8i3.fsf@vigenere.g10code.de> References: <2242538.IbLcNkSWhX@asus> <7346590.OKxEmCa9Sr@nb-jdeckert> <87zjr2k8i3.fsf@vigenere.g10code.de> Message-ID: <1511067.8CA2S7YOxJ@nb-jdeckert> > You are right. Sorry, there is no standard solution for this. It > depends on how a CA handles encryption keys. Set up your own CA and you > do not need a CSR. I have my own CA (XCA / openssl). I think I have 2 options: - transfer the key from gnupg to openssl before I move it to card - transfer the key from openssl to gnupg and move it to the card But I don't know how can I do this. Any hints? -- J?rg Deckert From peter at digitalbrains.com Tue Sep 24 11:41:40 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 24 Sep 2013 11:41:40 +0200 Subject: Best Practice, subkeys and subkey cross-certification. In-Reply-To: <20130924002109.GA5328@xen.axs.org> References: <20130924002109.GA5328@xen.axs.org> Message-ID: <52415E54.8090806@digitalbrains.com> On 24/09/13 02:21, Chuck Peters wrote: > https://alexcabal.com/creating-the-perfect-gpg-keypair/ Let me quote what Hauke wrote one and a half month ago, because I fully agree :). Oh, and it's relevant. On 03/08/13 14:51, Hauke Laging wrote: > To me this seems to be a really strange article. My advise is to ignore that. I haven't looked at the latter two links you gave, but I recognised this link from your list. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From lunar at debian.org Tue Sep 24 17:40:40 2013 From: lunar at debian.org (=?iso-8859-1?B?Suly6W15?= Bobbio) Date: Tue, 24 Sep 2013 17:40:40 +0200 Subject: Is there a MIME type for clear text signatures? Message-ID: <20130924154040.GB26766@loar> Hi! shared-mime-info currently recognize files beginning with `-----BEGIN PGP SIGNED MESSAGE-----` as having the MIME type `application/pgp-signature`?[1]. According to RFC3156?[2] which defined `application/pgp-signature`, I believe this to be wrong. Can any one confirm this? In that case, is there a MIME type that has been defined for clear text signatures? [1]?http://cgit.freedesktop.org/xdg/shared-mime-info/tree/freedesktop.org.xml.in#n269 [2] https://www.ietf.org/rfc/rfc3156.txt Thanks! -- 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 wk at gnupg.org Tue Sep 24 19:51:05 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 24 Sep 2013 19:51:05 +0200 Subject: Is there a MIME type for clear text signatures? In-Reply-To: <20130924154040.GB26766@loar> (=?utf-8?B?IkrDqXLDqW15?= Bobbio"'s message of "Tue, 24 Sep 2013 17:40:40 +0200") References: <20130924154040.GB26766@loar> Message-ID: <87a9j2jegm.fsf@vigenere.g10code.de> On Tue, 24 Sep 2013 17:40, lunar at debian.org said: > According to RFC3156?[2] which defined `application/pgp-signature`, > I believe this to be wrong. Can any one confirm this? No. RFC-3156 (PGP/MIME) does not really care about this mime type because: OpenPGP signed messages are denoted by the "multipart/signed" content type, described in [2], with a "protocol" parameter which MUST have a value of "application/pgp-signature" (MUST be quoted). ... the mulitpart/signed container has two parts: An arbittrary MIME part and a MIME part with a content-type as described by the "protocol" paramter (e.g. application/pgp-signature). Any other use is not defined by PGP/MIME. > In that case, is there a MIME type that has been defined for clear text > signatures? application/pgp-signature is often used. However, if you already change to MIME type to an application/foo type, the verifying MUA needs to be abale to cope with that. It would thus be easier to use PGP/MIME directly. Clearsigned is a hack from the dark ages of the mid-90ies where most MUAs were not MIME aware. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From stanshear at gmail.com Tue Sep 24 20:05:31 2013 From: stanshear at gmail.com (Stan Shear) Date: Tue, 24 Sep 2013 20:05:31 +0200 Subject: Strange Encryption Problem Message-ID: When I attempt to encrypt an asc message and enter the recipients certificate (Adele included) I get the message: "None of the recipients you are encrypting to seems to be your own. This means that you will not be able to decrypt the data anymore, once encrypted." Can anybody help? Thanks Stan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johanw at vulcan.xs4all.nl Tue Sep 24 21:21:04 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 24 Sep 2013 21:21:04 +0200 Subject: Strange Encryption Problem In-Reply-To: References: Message-ID: <5241E620.7000007@vulcan.xs4all.nl> On 24-09-2013 20:05, Stan Shear wrote: > "None of the recipients you are encrypting to seems to be your own. > > This means that you will not be able to decrypt the data anymore, once > encrypted." > > Can anybody help? It means that encrypt to self is switched off (usually a message is encrypted to both the receiver(s) and yourself soyou can look it back in sent messages), so only the receiver can decrypt the message, you yourself will not be able to do so. If this is what you intended to do, then there is no problem. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From oliver at wps-verlinden.de Tue Sep 24 21:31:07 2013 From: oliver at wps-verlinden.de (Oliver Verlinden) Date: Tue, 24 Sep 2013 21:31:07 +0200 Subject: Strange Encryption Problem In-Reply-To: References: Message-ID: <201309242131.07590.oliver@wps-verlinden.de> > "None of the recipients you are encrypting to seems to be your own. > > This means that you will not be able to decrypt the data anymore, once > encrypted." That's the way asymmetric encryption works. You encrypt the plain message with someones public key, but onle the owner of the connected private key (hopefully only the receiver) can decrypt the message. So if you encrypt a outgoing message with the public key of the recipient but not with your orn public key, you will not be able read the messages you sent. To solve this issue most email programs additionally encrypt outgoing messages with you own public key before the message is saved in the "Sent" folder. If you have done this, you can easily decrypt the message with your own private key and you can read these messages afterwards 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 bruce at secryption.com Wed Sep 25 01:13:42 2013 From: bruce at secryption.com (Bruce Markey) Date: Tue, 24 Sep 2013 19:13:42 -0400 Subject: Encrypting already signed messages. Message-ID: <66f9f4e2f6061828e593274dd29e00a9@secryption.com> I'm hoping this isn't a dumb question. Is it possible to encrypt a message that is already signed without breaking the signing? I use gnupg as implented by gpg-mailgate to encrypt all incoming and outgoing messages. Currently it tests for pre encrypted messages and ones that have been signed. Thank you. Bruce -- Encrypt everything. Public key: https://www.secryption.com/BruceMarkey.asc I believe that any violation of privacy is nothing good. Lech Walesa From lunar at debian.org Wed Sep 25 10:06:23 2013 From: lunar at debian.org (=?iso-8859-1?B?Suly6W15?= Bobbio) Date: Wed, 25 Sep 2013 10:06:23 +0200 Subject: Is there a MIME type for clear text signatures? In-Reply-To: <87a9j2jegm.fsf@vigenere.g10code.de> References: <20130924154040.GB26766@loar> <87a9j2jegm.fsf@vigenere.g10code.de> Message-ID: <20130925080623.GA7112@loar> Werner Koch: > On Tue, 24 Sep 2013 17:40, lunar at debian.org said: > > > According to RFC3156?[2] which defined `application/pgp-signature`, > > I believe this to be wrong. Can any one confirm this? > > No. RFC-3156 (PGP/MIME) does not really care about this mime type > because: > > OpenPGP signed messages are denoted by the "multipart/signed" content > type, described in [2], with a "protocol" parameter which MUST have a > value of "application/pgp-signature" (MUST be quoted). > > ... the mulitpart/signed container has two parts: An arbittrary MIME > part and a MIME part with a content-type as described by the "protocol" > paramter (e.g. application/pgp-signature). Any other use is not defined > by PGP/MIME. Thanks for your prompt reply. I just filled . -- 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 Wed Sep 25 15:18:23 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 25 Sep 2013 09:18:23 -0400 Subject: Magic numbers for keyring files? Message-ID: <5242E29F.4090306@sixdemonbag.org> I'm working on adding support for GnuPG keyrings to a file carver (a forensic tool that recovers data from damaged filesystems, or recovers things that have been deleted but not overwritten). Detecting an ASCII-armored keyblock is pretty easy: look for the "BEGIN PGP PUBLIC" header. Binary, though, is still an unsolved question. Before I start diving into code to find out if the keyring has a specific binary header I can detect, I figured I'd ask on-list. :) Does anyone know of any magic numbers for GnuPG keyring files? From dougb at dougbarton.us Wed Sep 25 17:31:43 2013 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 25 Sep 2013 08:31:43 -0700 Subject: Magic numbers for keyring files? In-Reply-To: <5242E29F.4090306@sixdemonbag.org> References: <5242E29F.4090306@sixdemonbag.org> Message-ID: <524301DF.1030403@dougbarton.us> On 09/25/2013 06:18 AM, Robert J. Hansen wrote: > I'm working on adding support for GnuPG keyrings to a file carver (a > forensic tool that recovers data from damaged filesystems, or recovers > things that have been deleted but not overwritten). Detecting an > ASCII-armored keyblock is pretty easy: look for the "BEGIN PGP PUBLIC" > header. Binary, though, is still an unsolved question. > > Before I start diving into code to find out if the keyring has a > specific binary header I can detect, I figured I'd ask on-list. :) > > Does anyone know of any magic numbers for GnuPG keyring files? It would seem that they do exist: file secring.gpg secring.gpg: PGP key security ring The folks that maintain the file(1) program used by most free Unices are really good about maintaining that information, and sharing it. I don't have all the details to hand atm, but it shouldn't take too much searching to find it. If you can't find any other handy repos to dig through http://svnweb.freebsd.org/base/head/contrib/file/ should get you on your way. hth, Doug From dshaw at jabberwocky.com Wed Sep 25 17:46:03 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 25 Sep 2013 11:46:03 -0400 Subject: Magic numbers for keyring files? In-Reply-To: <5242E29F.4090306@sixdemonbag.org> References: <5242E29F.4090306@sixdemonbag.org> Message-ID: <84670803-3D19-4D4D-9E06-51F8C8B97675@jabberwocky.com> On Sep 25, 2013, at 9:18 AM, "Robert J. Hansen" wrote: > I'm working on adding support for GnuPG keyrings to a file carver (a > forensic tool that recovers data from damaged filesystems, or recovers > things that have been deleted but not overwritten). Detecting an > ASCII-armored keyblock is pretty easy: look for the "BEGIN PGP PUBLIC" > header. Binary, though, is still an unsolved question. > > Before I start diving into code to find out if the keyring has a > specific binary header I can detect, I figured I'd ask on-list. :) > > Does anyone know of any magic numbers for GnuPG keyring files? Do you mean OpenPGP keyrings (i.e. "transferable public/secret keys", a la RFC-4880)? If so, it's statistical magic only. There are binary headers you can look for that don't quite ensure it's a OpenPGP keyring, but can leave you fairly confident. Take a look at the "file" magic database as a start. It's not 100%, but should get you going. http://www.darwinsys.com/file/ David From dkg at fifthhorseman.net Wed Sep 25 18:25:33 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 25 Sep 2013 12:25:33 -0400 Subject: OpenPGP card, gpgsm, decrypt In-Reply-To: <1511067.8CA2S7YOxJ@nb-jdeckert> References: <2242538.IbLcNkSWhX@asus> <7346590.OKxEmCa9Sr@nb-jdeckert> <87zjr2k8i3.fsf@vigenere.g10code.de> <1511067.8CA2S7YOxJ@nb-jdeckert> Message-ID: <52430E7D.9020307@fifthhorseman.net> On 09/24/2013 03:36 AM, J?rg Deckert wrote: >> You are right. Sorry, there is no standard solution for this. It >> depends on how a CA handles encryption keys. Set up your own CA and you >> do not need a CSR. > > I have my own CA (XCA / openssl). I think I have 2 options: > - transfer the key from gnupg to openssl before I move it to card > - transfer the key from openssl to gnupg and move it to the card > But I don't know how can I do this. Any hints? i don't know how to do this with OpenSSL (afaict, the "openssl ca" command does need an CSR to produce a cert). But if you have access to the secret key for the CA, and you have the raw public key of the would-be end-entity, you can produce a cert using certtool (from the gnutls-bin package): certtool --load-ca-privkey=ca-secret.key \ --load-ca-certificate=ca-cert.pem \ --load-pubkey="ee-pubkey.pem" \ --generate-certificate 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 JDiaz at azdes.gov Wed Sep 25 18:36:13 2013 From: JDiaz at azdes.gov (Diaz, John, A) Date: Wed, 25 Sep 2013 16:36:13 +0000 Subject: Decrypt Issue References: <63dd71b54fc34a529932e29c6f6e3740@MBX03.azdes.gov> <522B98F4.6080108@gmail.com> <30e043faf8154cfcab7f4a63ba84b8dc@MBX03.azdes.gov> <3feb006e-b5c3-4b70-88c0-224136a3ced5@email.android.com> Message-ID: <7313d4e9fac54e708424d495bbc7a0c0@MBX01.azdes.gov> Good morning Paul. Some progress, but there is still an issue that I can?t identify: C:\Program Files\GNU\GnuPG\pub>gpg.exe --batch --passphrase ?the passphrase? -o D:\divisions\DTS\FMCS\Test\Upload\VJCFC20E\VJCFC20E_ETETime.txt -v ?decrypt D:\Divisions\DTS\FMCS\Test\Download\HRIS_SIE_Files\DE-ETE-.pgp 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-.' gpg: handle plaintext failed: General error BTW, I can manually decrypt the file From: Diaz, John, A Sent: Tuesday, September 10, 2013 6:42 AM To: 'Paul R. Ramer' Cc: gnupg-users at gnupg.org Subject: RE: Decrypt Issue 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? From: Paul R. Ramer [mailto:free10pro at gmail.com] Sent: Tuesday, September 10, 2013 12:46 AM To: Diaz, John, A Cc: gnupg-users at gnupg.org Subject: RE: Decrypt Issue "Diaz, John, A" > wrote: Paul, got it figured out. Programmer too stupid. The path to gpg.exe had changed, and I didn't catch it. -----Original Message----- From: Paul R. Ramer [mailto:free10pro at gmail.com] Sent: Saturday, September 07, 2013 2:22 PM To: Diaz, John, A Cc: gnupg-users at gnupg.org Subject: Re: Decrypt Issue On 09/04/2013 01:54 PM, Diaz, John, A wrote: 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 list the keys on the server that this is running I see the key listed. Here's the goofy part: If I login to the server with the credentials that the mainframe uses to call the first .bat file, and manually run the .bat file that starts the whole process, it runs correctly. Hello John, When you say that you log in to the server, are you logging into a user account on the server? And do you get a command prompt (i.e. you are ssh-ing into your server)? 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. Well, I am glad you figured it out. :-) Cheers, --Paul -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roam at ringlet.net Wed Sep 25 16:14:52 2013 From: roam at ringlet.net (Peter Pentchev) Date: Wed, 25 Sep 2013 17:14:52 +0300 Subject: Magic numbers for keyring files? In-Reply-To: <5242E29F.4090306@sixdemonbag.org> References: <5242E29F.4090306@sixdemonbag.org> Message-ID: <20130925141452.GC6592@straylight.m.ringlet.net> On Wed, Sep 25, 2013 at 09:18:23AM -0400, Robert J. Hansen wrote: > I'm working on adding support for GnuPG keyrings to a file carver (a > forensic tool that recovers data from damaged filesystems, or recovers > things that have been deleted but not overwritten). Detecting an > ASCII-armored keyblock is pretty easy: look for the "BEGIN PGP PUBLIC" > header. Binary, though, is still an unsolved question. > > Before I start diving into code to find out if the keyring has a > specific binary header I can detect, I figured I'd ask on-list. :) > > Does anyone know of any magic numbers for GnuPG keyring files? AFAIK, a GnuPG keyring (as well as a PGP Inc. keyring) is just a concatenation of the (binary representation of the) public/private keys stored there. Thus, the file format you're looking for is the file format of an OpenPGP key as defined by, yeah, you guessed it, RFC 4880 :) Of course, I could be wrong, but I really don't think that GnuPG stores anything more than that - and an easy way to test that is to point Bernhard Link's gpg2txt - https://alioth.debian.org/projects/gpg2txt/ or https://code.launchpad.net/gpg2txt - or Kazu Yamamoto's pgpdump - http://www.mew.org/~kazu/proj/pgpdump/en/ - at your secring.gpg or pubring.gpg file; they will display a sequence of packets comprising one or more OpenPGP keys. So what you need to look for is sequences of bytes matching the OpenPGP format; this usually means packets of type 5 for private keys or 6 for public ones. Unfortunately the first bytes will vary with 1. the format version and 2. the packet (key) length, so there is no exact marker. Still, file(1) does it somehow; you might want to look at file's source, at its magic database, to see the heuristics it uses. In general I would guess it could be something like (all in hex): - 94 xx: xx bytes of private key data, tag 5, old format packet length - 95 xx yy: xx*256+yy bytes of private key data, tag 5, old length - 96 xx yy zz: xx*65536 + yy*256 + zz bytes of the same - C5 xx: xx (less than 192) bytes of private key data, tag 5, new length - C5 xx yy: (xx-192) * 256 + yy bytes of private key data, tag 5, new - C5 FF xx yy zz tt: up to 4 GB of private key data, tag 5, new - 98 xx: xx bytes of public key data, tag 6, old format packet length - 99 xx yy: xx*256+yy bytes of public key data, tag 6, old length - 9A xx yy zz: xx*65536 + yy*256 + zz bytes of the same - C6 xx: xx (less than 192) bytes of public key data, tag 6, new length - C6 xx yy: (xx-192) * 256 + yy bytes of public key data, tag 6, new - C6 FF xx yy zz tt: up to 4 GB of public key data, tag 6, new Then you should match the first bytes of the packet itself; it would probably start with a 04 (version) xx yy zz tt (timestamp), algorithm, etc. Hope that 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 Hey, out there - is it *you* reading me, or is it someone else? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From expires2013 at ymail.com Wed Sep 25 21:29:58 2013 From: expires2013 at ymail.com (MFPA) Date: Wed, 25 Sep 2013 20:29:58 +0100 Subject: Generation of key ID's In-Reply-To: <523F537C.2090707@fifthhorseman.net> References: <523DC1C3.6070104@ramses-pyramidenbau.de> <523F537C.2090707@fifthhorseman.net> Message-ID: <441826251.20130925202958@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 22 September 2013 at 9:30:52 PM, in , Daniel Kahn Gillmor wrote: > You can read up on the specifics in the standard: > https://tools.ietf.org/html/rfc4880#section-12.2 Does anybody know the answer to the OP's other question:- "And why is it done that way?" - -- Best regards MFPA mailto:expires2013 at ymail.com We're all shipwrecked on this idea that everything has to be explained. -----BEGIN PGP SIGNATURE----- iQCVAwUBUkM5u6ipC46tDG5pAQqmbwP/Z6ihOHb0RVsyuTL8dLFGBuTfTl5q+h1j X+0olqXIui85qZy7NEAQdqNBfWs+a48sCwKpEGdISl3MVu29KaI244EFVv8KfIxh TkrTH1qka8Tn3WJaUoTQ5y0NXMaa2PGOFoU95WqO74+CDxSfQab64EzkeSqDnLv3 cYB30qs0hSw= =8L7g -----END PGP SIGNATURE----- From roam at ringlet.net Wed Sep 25 23:02:28 2013 From: roam at ringlet.net (Peter Pentchev) Date: Thu, 26 Sep 2013 00:02:28 +0300 Subject: Generation of key ID's In-Reply-To: <441826251.20130925202958@my_localhost> References: <523DC1C3.6070104@ramses-pyramidenbau.de> <523F537C.2090707@fifthhorseman.net> <441826251.20130925202958@my_localhost> Message-ID: <20130925210228.GA6991@straylight.m.ringlet.net> On Wed, Sep 25, 2013 at 08:29:58PM +0100, MFPA wrote: > > Hi > > On Sunday 22 September 2013 at 9:30:52 PM, in > , Daniel Kahn Gillmor wrote: > > > You can read up on the specifics in the standard: > > https://tools.ietf.org/html/rfc4880#section-12.2 > > Does anybody know the answer to the OP's other question:- > "And why is it done that way?" Of course, I cannot speak for the designers of the PGP and later OpenPGP key format, but... Um. When assigning identifiers to pieces of data created randomly by independent parties all around the world with no means of communication or synchronization, it makes perfect sense that the identifier would be some kind of hash over both information supplied by the person generating the piece of data and information generated randomly, that is, part of the data. So it makes perfect sense that the identifier should be some kind of a hash over parts of the PGP key material. Furthermore, the identifier should not change when the key owner makes modifications to the key itself, so it may not include user IDs or signatures made either by the owner or other people after the key has been generated. What does not change in a PGP key? Well, obviously, the key parameters themselves: the algorithm, the numbers comprising the key (be they primes or curve specifiers or whatever). In addition, a key may only be created once, so the creation time is not supposed to change. So there you have it - a long, long time ago, in a galaxy far, far away, the V3 key fingerprint was formed by hashing only the key parameters; they obviously characterize this key and they obviously will not change with time as this key is being used. Then, in V4 of the format, more information was included, but once again, all of it is not supposed to change with time. As an additional benefit, hashing the public key material also provides a quick and quite reliable way to make sure that the public key itself has not been damaged in transit. Note: in this text I repeatedly referred to "PGP keys" and not "OpenPGP keys" because, unless I am gravely mistaken, both the V3 and V4 key formats were designed before (okay, V4 was almost at the same time as) the OpenPGP Alliance was formed. 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 "yields falsehood, when appended to its quotation." yields falsehood, when appended to its quotation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From ptaukat at gmail.com Thu Sep 26 18:54:29 2013 From: ptaukat at gmail.com (Paul Taukatch) Date: Thu, 26 Sep 2013 12:54:29 -0400 Subject: GPG Private Key Export Question Message-ID: I had a question regarding exporting a private key using GPG. I generated a Key pair using GPG 1.4.13 and then used the export command to export the private key into another file. Based on the RFC 4880 documentation: A Secret-Key packet contains all the information that is found in a Public-Key packet, including the public-key material, but also includes the secret-key material after all the public-key fields. But when I --list-packets on the file it does not seem to contain any information about the public key. So my question is, do GPG private key packets contain the public key information as specified by the RFC 4880 documentation? Also, is there anyway to export a key pair using a single GPG command into a single file? The following is the out of my private key export using --list-packets: :secret key packet: version 4, algo 1, created 1376423121, expires 0 skey[0]: [2048 bits] skey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 5e4fccb70f72afef protect count: 65536 (96) protect IV: d1 7c 18 34 ab c7 be 14 f6 3d ec 49 86 1e ae 62 encrypted stuff follows :user ID packet: "Testee McTestin (Test All Day) " :signature packet: algo 1, keyid 611F977E042D92BD version 4, created 1376423121, md5len 0, sigclass 0x13 digest algo 2, begin of digest 48 b8 hashed subpkt 2 len 4 (sig created 2013-08-13) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) subpkt 16 len 8 (issuer key ID 611F977E042D92BD) data: [2048 bits] :secret sub key packet: version 4, algo 1, created 1376423121, expires 0 skey[0]: [2048 bits] skey[1]: [17 bits] iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 5e4fccb70f72afef protect count: 65536 (96) protect IV: 0a 16 bb e5 4a 91 84 0c 34 da 62 c4 2f 66 03 ef encrypted stuff follows :signature packet: algo 1, keyid 611F977E042D92BD version 4, created 1376423121, md5len 0, sigclass 0x18 digest algo 2, begin of digest 79 b1 hashed subpkt 2 len 4 (sig created 2013-08-13) hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID 611F977E042D92BD) data: [2048 bits] Also, I had a question regarding the Key Fingerprint/Key ID and its relation to the public/private key pair. While viewing my keys using GPG it seems that the private key has the same Key ID as the public key. Output of editing my key pair using GPG: pub 2048R/042D92BD created: 2013-08-13 expires: never usage: SC trust: ultimate validity: ultimate sub 2048R/87E42A5D created: 2013-08-13 expires: never usage: E [ultimate] (1). Testee McTestin (Test All Day) gpg> toggle sec 2048R/042D92BD created: 2013-08-13 expires: never ssb 2048R/87E42A5D created: 2013-08-13 expires: never (1) Testee McTestin (Test All Day) Based on the RFC4880 specifications I know that a fingerprint is generated by : A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. for the secre My question then is, when I attempt to import my exported secret key, how is the key fingerprint calculated for the secret key, is it based only on the "public key packet" portion or is it also based on the secret key information? Sorry for the very long question and I really appreciate any help on the matter! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Thu Sep 26 22:53:27 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 26 Sep 2013 16:53:27 -0400 Subject: GPG Private Key Export Question In-Reply-To: References: Message-ID: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> On Sep 26, 2013, at 12:54 PM, Paul Taukatch wrote: > I had a question regarding exporting a private key using GPG. > > I generated a Key pair using GPG 1.4.13 and then used the export command to export the private key into another file. > > Based on the RFC 4880 documentation: > A Secret-Key packet contains all the information that is found in a > Public-Key packet, including the public-key material, but also > includes the secret-key material after all the public-key fields. > > But when I --list-packets on the file it does not seem to contain any information about the public key. So my question is, do GPG private key packets contain the public key information as specified by the RFC 4880 documentation? Yes. This isn't an actual public key packet - just the contents of the public key packet at the end of the secret data, so it doesn't show up as a ":public key packet:" in --list-packets. > Also, is there anyway to export a key pair using a single GPG command into a single file? Not exactly, but (at least using GPG) you get the same effect. If you import a secret key and you don't have the public key, GPG will use the embedded public key data to recreate the public key, so effectively an exported secret key is like exporting a key pair. > Also, I had a question regarding the Key Fingerprint/Key ID and its relation to the public/private key pair. While viewing my keys using GPG it seems that the private key has the same Key ID as the public key. Correct. > Based on the RFC4880 specifications I know that a fingerprint is generated by : > > A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, > followed by the two-octet packet length, followed by the entire > Public-Key packet starting with the version field. for the secre > > My question then is, when I attempt to import my exported secret key, how is the key fingerprint calculated for the secret key, is it based only on the "public key packet" portion or is it also based on the secret key information? It's based only on the public key information. David From free10pro at gmail.com Fri Sep 27 04:52:20 2013 From: free10pro at gmail.com (Paul R. Ramer) Date: Thu, 26 Sep 2013 19:52:20 -0700 Subject: Decrypt Issue In-Reply-To: <7313d4e9fac54e708424d495bbc7a0c0@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> Message-ID: <5244F2E4.8080309@gmail.com> 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 From Jondebonis at gmail.com Thu Sep 26 23:30:04 2013 From: Jondebonis at gmail.com (Jon Debonis) Date: Thu, 26 Sep 2013 14:30:04 -0700 Subject: What's the encryption flow? Message-ID: Is there a document or diagram that explains how encryption happens? This is what I assume from http://www.gnupg.org/gph/en/manual/c173.html rand_key = GenerateRandomKey(bits) rand_key_e = E_pk(rand_key) cypher_text = E_rand_key(plain_text) unsigned_message = headers + rand_key_e + cypher_text ... sign message... Where E_pk === encrypt with public key (asymmetric); E_rand_key === encrypt with random_key (symmetric); Using user-specified ciphers. Jon -- jondebonis at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hankivy at hankivy.com Thu Sep 26 23:17:37 2013 From: hankivy at hankivy.com (Hank Ivy) Date: Thu, 26 Sep 2013 16:17:37 -0500 Subject: Use of two private/public key pairs, Sign only and Encrypt only In-Reply-To: References: Message-ID: <201309261617.37517.hankivy@hankivy.com> What articles exist on having two private/public key pairs, and using one to only sign a document, and the other only for encryption? The google searchs had articles on one person having a single private/public key pair for both signature, and encryption. "Advanced" articles did not seem to cover this topic. Have there been any courts that subpoenaed the private key and its pass phrase of a user? Would they make a distinction if a user had two pairs, and used them uniquely for signature or encryption? -- Hank Ivy From rjh at sixdemonbag.org Fri Sep 27 15:27:31 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Sep 2013 09:27:31 -0400 Subject: Use of two private/public key pairs, Sign only and Encrypt only In-Reply-To: <201309261617.37517.hankivy@hankivy.com> References: <201309261617.37517.hankivy@hankivy.com> Message-ID: <524587C3.4020502@sixdemonbag.org> On 9/26/2013 5:17 PM, Hank Ivy wrote: > What articles exist on having two private/public key pairs, and > using one to only sign a document, and the other only for > encryption? That depends on which context you're looking for. In terms of cryptographic articles about using separate keys, that one goes back to the early '80s; I think Dorothy Denning had one in _Communications of the ACM_. (Five minutes with Google Scholar revealed "Digital Signatures with RSA and other public-key cryptosystems," April 1984.) In terms of legal articles about the consequences of using separate keys, that one is currently badly unaddressed. > Have there been any courts that subpoenaed the private key and its > pass phrase of a user? Would they make a distinction if a user had > two pairs, and used them uniquely for signature or encryption? This has happened in the United Kingdom. To my knowledge it has not happened in the United States. However, as this is a legal question, you will be best served by asking a lawyer. :( From mailinglisten at hauke-laging.de Fri Sep 27 15:39:00 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 27 Sep 2013 15:39 +0200 Subject: Use of two private/public key pairs, Sign only and Encrypt only In-Reply-To: <201309261617.37517.hankivy@hankivy.com> References: <201309261617.37517.hankivy@hankivy.com> Message-ID: <4399273.TERJz7gO7x@inno.berlin.laging.de> Am Do 26.09.2013, 16:17:37 schrieb Hank Ivy: > What articles exist on having two private/public key pairs, and using one to > only sign a document, and the other only for encryption? > Have there been any courts that subpoenaed the private key and its pass > phrase of a user? You can have a single mainkey with separate subkeys for signing and encryption (and with different passphrases though that requires some tricks) so that it would be enough to give away the decryption key. I doubt that anywhere in the civilized world you can legally be forced to enable the police to forge your signature. You could even export just that key in advance. On the other hand most of us have learnt a lot about the real state of the world quite recently... 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 Sep 27 15:56:03 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Sep 2013 09:56:03 -0400 Subject: Use of two private/public key pairs, Sign only and Encrypt only In-Reply-To: <4399273.TERJz7gO7x@inno.berlin.laging.de> References: <201309261617.37517.hankivy@hankivy.com> <4399273.TERJz7gO7x@inno.berlin.laging.de> Message-ID: <52458E73.5020505@sixdemonbag.org> On 9/27/2013 9:39 AM, Hauke Laging wrote: > I doubt that anywhere in the civilized world you can legally be > forced to enable the police to forge your signature. Arguably, the United Kingdom. The Regulation of Investigatory Powers Act of 2000 (RIPA) can be used to compel you to turn over the encryption key used for a message. Normally the police are satisfied with getting the symmetric key used to encrypt the message, but there's nothing in RIPA that requires them to limit themselves to that. They could instead require the RSA key involved, and odds are fairly good a judge would uphold this demand. If you have an RSA sign-and-encrypt key, then by doing so you've just enabled the police to forge your signature. What's worse is that revoking your key could be seen as tipping off your correspondents to the police's activities, and that's a serious offense under RIPA. From ptaukat at gmail.com Fri Sep 27 15:58:35 2013 From: ptaukat at gmail.com (Paul Taukatch) Date: Fri, 27 Sep 2013 09:58:35 -0400 Subject: GPG Private Key Export Question In-Reply-To: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> Message-ID: Really appreciate the help and the quick response! I just wanted to clarify, where exactly is the public key information stored within the exported secret key data? Is it part of the Secret key packet as part of the "Encrypted stuff follows section" or is following that? I'm currently trying to develop some software and would like to extract the public key value along with the fingerprint/ID information from the exported secret key packet. I'm assuming that when GPG imports such a secret key packet it is able to extract the public key info and able to link it to the corresponding public key (if one exists within the keyring already) or is able to reconstruct and place the public key if it does not already exist. Thanks again, -Paul On Thu, Sep 26, 2013 at 4:53 PM, David Shaw wrote: > On Sep 26, 2013, at 12:54 PM, Paul Taukatch wrote: > > > I had a question regarding exporting a private key using GPG. > > > > I generated a Key pair using GPG 1.4.13 and then used the export command > to export the private key into another file. > > > > Based on the RFC 4880 documentation: > > A Secret-Key packet contains all the information that is found in a > > Public-Key packet, including the public-key material, but also > > includes the secret-key material after all the public-key fields. > > > > But when I --list-packets on the file it does not seem to contain any > information about the public key. So my question is, do GPG private key > packets contain the public key information as specified by the RFC 4880 > documentation? > > Yes. This isn't an actual public key packet - just the contents of the > public key packet at the end of the secret data, so it doesn't show up as a > ":public key packet:" in --list-packets. > > > Also, is there anyway to export a key pair using a single GPG command > into a single file? > > Not exactly, but (at least using GPG) you get the same effect. If you > import a secret key and you don't have the public key, GPG will use the > embedded public key data to recreate the public key, so effectively an > exported secret key is like exporting a key pair. > > > Also, I had a question regarding the Key Fingerprint/Key ID and its > relation to the public/private key pair. While viewing my keys using GPG it > seems that the private key has the same Key ID as the public key. > > Correct. > > > Based on the RFC4880 specifications I know that a fingerprint is > generated by : > > > > A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, > > followed by the two-octet packet length, followed by the entire > > Public-Key packet starting with the version field. for the secre > > > > My question then is, when I attempt to import my exported secret key, > how is the key fingerprint calculated for the secret key, is it based only > on the "public key packet" portion or is it also based on the secret key > information? > > It's based only on the public key information. > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes at zarl.at Fri Sep 27 13:36:44 2013 From: johannes at zarl.at (Johannes Zarl) Date: Fri, 27 Sep 2013 13:36:44 +0200 Subject: Problems with keypad on Cherry ST-2000U card reader Message-ID: <4317661.qAaK70T4lr@mani> 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 From mailinglisten at hauke-laging.de Fri Sep 27 16:20:01 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 27 Sep 2013 16:20:01 +0200 Subject: Use of two private/public key pairs, Sign only and Encrypt only In-Reply-To: <52458E73.5020505@sixdemonbag.org> References: <4399273.TERJz7gO7x@inno.berlin.laging.de> <52458E73.5020505@sixdemonbag.org> Message-ID: <1853704.NzafhxURl0@inno.berlin.laging.de> Am Fr 27.09.2013, 09:56:03 schrieb Robert J. Hansen: > What's worse is that > revoking your key could be seen as tipping off your correspondents to > the police's activities, and that's a serious offense under RIPA. Is that your interpretation or in any way official? My respective search engige efforts were not successful. This point of view would have quite strange consequences: For how long shall you be forced to keep a key? Even longer than before (if you change subkeys regularly)? Why should you have to accept that police can read future data of yours, data which they do not have a warrant for? Unfortunately for quite a while we have seen that there is a lot more between UK and the rest of (continental) Europe than just water. Maybe we will finally see the EU shrink for the first time. 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 roam at ringlet.net Fri Sep 27 16:33:59 2013 From: roam at ringlet.net (Peter Pentchev) Date: Fri, 27 Sep 2013 17:33:59 +0300 Subject: GPG Private Key Export Question In-Reply-To: References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> Message-ID: <20130927143359.GA22361@straylight.m.ringlet.net> On Fri, Sep 27, 2013 at 09:58:35AM -0400, Paul Taukatch wrote: > Really appreciate the help and the quick response! > > I just wanted to clarify, where exactly is the public key information > stored within the exported secret key data? Is it part of the Secret key > packet as part of the "Encrypted stuff follows section" or is following > that? It's part of the secret key packet. If you run gpg --list-packets with --debug=2 (or with --debug-all), so that it shows you the actual numeric data in the key representations, you'll see that skey[0] and skey[1] in the secret key packet are exactly the same as pkey[0] and pkey[1] shown when you --export | --list-packets (so GnuPG shows you the public key). 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 What would this sentence be like if pi were 3? -------------- 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 Fri Sep 27 16:40:10 2013 From: roam at ringlet.net (Peter Pentchev) Date: Fri, 27 Sep 2013 17:40:10 +0300 Subject: GPG Private Key Export Question In-Reply-To: <20130927143359.GA22361@straylight.m.ringlet.net> References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> <20130927143359.GA22361@straylight.m.ringlet.net> Message-ID: <20130927144010.GB22361@straylight.m.ringlet.net> On Fri, Sep 27, 2013 at 05:33:59PM +0300, Peter Pentchev wrote: > On Fri, Sep 27, 2013 at 09:58:35AM -0400, Paul Taukatch wrote: > > Really appreciate the help and the quick response! > > > > I just wanted to clarify, where exactly is the public key information > > stored within the exported secret key data? Is it part of the Secret key > > packet as part of the "Encrypted stuff follows section" or is following > > that? > > It's part of the secret key packet. If you run gpg --list-packets with > --debug=2 (or with --debug-all), so that it shows you the actual numeric > data in the key representations, you'll see that skey[0] and skey[1] in > the secret key packet are exactly the same as pkey[0] and pkey[1] shown > when you --export | --list-packets (so GnuPG shows you the public key). Also, if you're really writing software for parsing and extracting data from OpenPGP keys or messages, then you absolutely *must* start by reading RFC 4880, then reading it again, then bookmarking it and keeping it always open in a browser window or a text pager, so you can refer to it as often as you *will* need to :) 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 the thought you are now thinking. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From dshaw at jabberwocky.com Fri Sep 27 16:40:07 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 27 Sep 2013 10:40:07 -0400 Subject: GPG Private Key Export Question In-Reply-To: References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> Message-ID: On Sep 27, 2013, at 9:58 AM, Paul Taukatch wrote: > Really appreciate the help and the quick response! > > I just wanted to clarify, where exactly is the public key information stored within the exported secret key data? Is it part of the Secret key packet as part of the "Encrypted stuff follows section" or is following that? I'm currently trying to develop some software and would like to extract the public key value along with the fingerprint/ID information from the exported secret key packet. I'm assuming that when GPG imports such a secret key packet it is able to extract the public key info and able to link it to the corresponding public key (if one exists within the keyring already) or is able to reconstruct and place the public key if it does not already exist. It's part of the secret key packet, immediately before the encrypted stuff. So a secret key is effectively a public key, with a few more fields of secret stuff tacked on the end. Your assumption is correct, for both. When GPG imports a secret key, it creates a public key and imports it alongside the secret key. David From cryptostick at privacyfoundation.de Fri Sep 27 17:30:21 2013 From: cryptostick at privacyfoundation.de (Crypto Stick) Date: Fri, 27 Sep 2013 17:30:21 +0200 Subject: key generation fails with Crypto Stick and MacOS X In-Reply-To: <5EC69275-FD41-4919-B49A-DEEEA1351B63@dotplex.de> References: <5EC69275-FD41-4919-B49A-DEEEA1351B63@dotplex.de> Message-ID: <5245A48D.9050008@privacyfoundation.de> Hi! 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? Regars, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg.log Type: application/octet-stream Size: 29941 bytes Desc: not available URL: From johanw at vulcan.xs4all.nl Fri Sep 27 17:59:35 2013 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 27 Sep 2013 17:59:35 +0200 Subject: Use of two private/public key pairs, Sign only and Encrypt only In-Reply-To: <1853704.NzafhxURl0@inno.berlin.laging.de> References: <4399273.TERJz7gO7x@inno.berlin.laging.de> <52458E73.5020505@sixdemonbag.org> <1853704.NzafhxURl0@inno.berlin.laging.de> Message-ID: <5245AB67.6080908@vulcan.xs4all.nl> On 27-09-2013 16:20, Hauke Laging wrote: > Unfortunately for quite a while we have seen that there is a lot more between > UK and the rest of (continental) Europe than just water. Maybe we will finally > see the EU shrink for the first time. Unfortunately the UK is not the ponly EU country where such ideas live. The current Dutch minister of justice has proposed a decryption duty as well, although he said nothing about forbidding people to talk about it. Although the last part is probably just because of his incompetence than a lack of ill will. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From wk at gnupg.org Fri Sep 27 17:51:17 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Sep 2013 17:51:17 +0200 Subject: key generation fails with Crypto Stick and MacOS X In-Reply-To: <5245A48D.9050008@privacyfoundation.de> (Crypto Stick's message of "Fri, 27 Sep 2013 17:30:21 +0200") References: <5EC69275-FD41-4919-B49A-DEEEA1351B63@dotplex.de> <5245A48D.9050008@privacyfoundation.de> Message-ID: <87txh6e00a.fsf@vigenere.g10code.de> On Fri, 27 Sep 2013 17:30, cryptostick at privacyfoundation.de said: > 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. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Sep 27 17:56:19 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Sep 2013 17:56:19 +0200 Subject: What's the encryption flow? In-Reply-To: (Jon Debonis's message of "Thu, 26 Sep 2013 14:30:04 -0700") References: Message-ID: <87pprudzrw.fsf@vigenere.g10code.de> On Thu, 26 Sep 2013 23:30, Jondebonis at gmail.com said: > Is there a document or diagram that explains how encryption happens? Yes, RFC-4880 has all the details. > rand_key = GenerateRandomKey(bits) > rand_key_e = E_pk(rand_key) > cypher_text = E_rand_key(plain_text) Bascially correct. > ... sign message... > > Where E_pk === encrypt with public key (asymmetric); I don't understand this. For signing, you use a sign algorithms. It is just a coincidence that the core of the RSA algorithm is used in a kind of reversed mode for signature. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Fri Sep 27 20:39:59 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Sep 2013 14:39:59 -0400 Subject: Use of two private/public key pairs, Sign only and Encrypt only In-Reply-To: <1853704.NzafhxURl0@inno.berlin.laging.de> References: <4399273.TERJz7gO7x@inno.berlin.laging.de> <52458E73.5020505@sixdemonbag.org> <1853704.NzafhxURl0@inno.berlin.laging.de> Message-ID: <5245D0FF.4040607@sixdemonbag.org> On 9/27/2013 10:20 AM, Hauke Laging wrote: > Is that your interpretation or in any way official? My respective > search engige efforts were not successful. Nothing is official until the jury comes back. RIPA prohibits someone who is under a key-divulging order from telling other people about the order. That much is official. It's within the realm of possibility that a prosecutor would tell the Court, "Milord, Mr. Laging revoked his certificate immediately after divulging to us the passphrase. This had the effect of tipping off his correspondents that the certificate was compromised. We ask that you deem this to be a violation of RIPA's provisions prohibiting affected persons from telling others about the forced disclosure of their key." A lot of armchair lawyers (on this list and others) will say that this argument would never fly. I'm not so certain. I'm not saying it would certainly work; I'm also not saying it certainly wouldn't. It would depend a lot on the judge hearing the case. Notice how I said "revoking your key *could* be seen as". :) > This point of view would have quite strange consequences: For how > long shall you be forced to keep a key? Even longer than before (if > you change subkeys regularly)? Why should you have to accept that > police can read future data of yours, data which they do not have a > warrant for? These are legal questions. Ask a lawyer. (Or, given that it's a matter of United Kingdom law, ask a solicitor.) From rjh at sixdemonbag.org Fri Sep 27 20:44:17 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Sep 2013 14:44:17 -0400 Subject: GPG Private Key Export Question In-Reply-To: <20130927144010.GB22361@straylight.m.ringlet.net> References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> <20130927143359.GA22361@straylight.m.ringlet.net> <20130927144010.GB22361@straylight.m.ringlet.net> Message-ID: <5245D201.2010305@sixdemonbag.org> On 9/27/2013 10:40 AM, Peter Pentchev wrote: > Also, if you're really writing software for parsing and extracting data > from OpenPGP keys or messages, then you absolutely *must* start by > reading RFC 4880, then reading it again, then bookmarking it and keeping > it always open in a browser window or a text pager, so you can refer to > it as often as you *will* need to :) For the last week I've been writing a parser suitable for filesystem forensics. All I can say is, "preach it, brother." I printed out hardcopy of the whole of RFC4880 and have pages from it pinned up to my cubicle walls. There is also a sheet of paper pinned up there that has a red circle about six inches across and a caption beneath of, "BEAT HEAD HERE." I find myself referring to that almost as much as I do to RFC4880. (Speaking of that project: thank you, Peter and David, for pointing me towards the file(1) magic numbers library. It works well enough for my purposes.) From ptaukat at gmail.com Fri Sep 27 21:28:18 2013 From: ptaukat at gmail.com (Paul Taukatch) Date: Fri, 27 Sep 2013 15:28:18 -0400 Subject: GPG Private Key Export Question In-Reply-To: <5245D201.2010305@sixdemonbag.org> References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> <20130927143359.GA22361@straylight.m.ringlet.net> <20130927144010.GB22361@straylight.m.ringlet.net> <5245D201.2010305@sixdemonbag.org> Message-ID: Hey everyone thanks for all the contributions, really helped clear some things up. Was just hoping you could help clarify one more thing. Why exactly are the numerical values for skey[0] and skey[1] equal to pkey[0] and pkey[1]? Is it because the numerical value listed is actually the key value of the entire public/private key pair? If so, is a specific portion of that key value used as the "secret key" and another portion used as the "public key"? Also, is there any command I can use to view the entire contents of the exported secret key packet? Thanks again! On Fri, Sep 27, 2013 at 2:44 PM, Robert J. Hansen wrote: > On 9/27/2013 10:40 AM, Peter Pentchev wrote: > > Also, if you're really writing software for parsing and extracting data > > from OpenPGP keys or messages, then you absolutely *must* start by > > reading RFC 4880, then reading it again, then bookmarking it and keeping > > it always open in a browser window or a text pager, so you can refer to > > it as often as you *will* need to :) > > For the last week I've been writing a parser suitable for filesystem > forensics. All I can say is, "preach it, brother." I printed out > hardcopy of the whole of RFC4880 and have pages from it pinned up to my > cubicle walls. > > There is also a sheet of paper pinned up there that has a red circle > about six inches across and a caption beneath of, "BEAT HEAD HERE." I > find myself referring to that almost as much as I do to RFC4880. > > (Speaking of that project: thank you, Peter and David, for pointing me > towards the file(1) magic numbers library. It works well enough for my > purposes.) > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Sep 27 21:32:37 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Sep 2013 15:32:37 -0400 Subject: GPG Private Key Export Question In-Reply-To: <5245D201.2010305@sixdemonbag.org> References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> <20130927143359.GA22361@straylight.m.ringlet.net> <20130927144010.GB22361@straylight.m.ringlet.net> <5245D201.2010305@sixdemonbag.org> Message-ID: <5245DD55.8030402@sixdemonbag.org> On 9/27/2013 2:44 PM, Robert J. Hansen wrote: > (Speaking of that project: thank you, Peter and David, for pointing me > towards the file(1) magic numbers library. It works well enough for my > purposes.) And Doug. Sorry for the omission! From dougb at dougbarton.us Fri Sep 27 22:55:49 2013 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 27 Sep 2013 13:55:49 -0700 Subject: GPG Private Key Export Question In-Reply-To: <5245DD55.8030402@sixdemonbag.org> References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> <20130927143359.GA22361@straylight.m.ringlet.net> <20130927144010.GB22361@straylight.m.ringlet.net> <5245D201.2010305@sixdemonbag.org> <5245DD55.8030402@sixdemonbag.org> Message-ID: <5245F0D5.2000405@dougbarton.us> On 09/27/2013 12:32 PM, Robert J. Hansen wrote: > On 9/27/2013 2:44 PM, Robert J. Hansen wrote: >> (Speaking of that project: thank you, Peter and David, for pointing me >> towards the file(1) magic numbers library. It works well enough for my >> purposes.) > > And Doug. Sorry for the omission! Heh, no worries. GMTA, and all that. :) From cryptostick at privacyfoundation.de Fri Sep 27 15:35:20 2013 From: cryptostick at privacyfoundation.de (Crypto Stick) Date: Fri, 27 Sep 2013 15:35:20 +0200 Subject: key generation fails with Crypto Stick and MacOS X In-Reply-To: <5EC69275-FD41-4919-B49A-DEEEA1351B63@dotplex.de> References: <5EC69275-FD41-4919-B49A-DEEEA1351B63@dotplex.de> Message-ID: <52458998.8040001@privacyfoundation.de> Hi! 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? Regars, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg.log Type: application/octet-stream Size: 29941 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gpg.log.1 Type: application/octet-stream Size: 37301 bytes Desc: not available URL: From ashish.mitujn07 at gmail.com Fri Sep 27 16:26:18 2013 From: ashish.mitujn07 at gmail.com (ashish.....) Date: Fri, 27 Sep 2013 19:56:18 +0530 Subject: GnuPG encryption using command line Message-ID: Hi, We are trying to use GnuPg in an automated system in java application and below is our requirement . 1- We want to encrypt text file using command line and there should be a pass phrase passed to that encrypted file via command. 2. whole encryption process should be automatic there should be any prompt for pass phrase. Can you please help us how to pass pass phrase via command , so there should not be any prompt or manual work involve. -- Regards, Ashish From rjh at sixdemonbag.org Sat Sep 28 01:32:03 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 27 Sep 2013 19:32:03 -0400 Subject: GnuPG encryption using command line In-Reply-To: References: Message-ID: <52461573.2050004@sixdemonbag.org> On 9/27/2013 10:26 AM, ashish..... wrote: > We are trying to use GnuPg in an automated system in java application > and below is our requirement . Best solution: write JNI bindings for gpgme. There are already some bindings in varying stages of completion: you may want to use one of these as a bootstrap. Good luck! From peter at digitalbrains.com Sat Sep 28 11:27:07 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 28 Sep 2013 11:27:07 +0200 Subject: GPG Private Key Export Question In-Reply-To: References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> <20130927143359.GA22361@straylight.m.ringlet.net> <20130927144010.GB22361@straylight.m.ringlet.net> <5245D201.2010305@sixdemonbag.org> Message-ID: <5246A0EB.4070504@digitalbrains.com> On 27/09/13 21:28, Paul Taukatch wrote: > Was just hoping you could help clarify one more thing. Why exactly are the > numerical values for skey[0] and skey[1] equal to pkey[0] and pkey[1]? RFC 4880 really is the place to look for this stuff. All your questions can be answered by carefully reading the relevant sections of that RFC. Key packets are described in section 5.5. You showed a --list-packets for an RSA key, so section 5.5.2 tells us a public key packet, or equivalently the start of a secret key packet, contains, in order: a version number, a creation time, the algorithm, and a series of multiprecision integers describing the key material. For RSA, these are the modulus n and the exponent e. It is easily seen that these probably correspond to skey[0] and skey[1] respectively (or pkey), because the first one is 2048 bits, which is a reasonable size for the modulus, and the second one is 17 bits, and I believe that GnuPG always uses the public exponent 65537. Section 5.5.3 goes on to explain what follows in a secret key packet. If you would remove the password from the exported key, you could see that contents as well; right now it's in the encrypted part. Let's take a look at a 2048-bit RSA key secret packet without encryption: :secret key packet: version 4, algo 1, created 1374835387, expires 0 skey[0]: [2048 bits] skey[1]: [17 bits] skey[2]: [2043 bits] skey[3]: [1024 bits] skey[4]: [1024 bits] skey[5]: [1023 bits] checksum: 4527 keyid: A1DAD4EC3E7F0306 Section 5.5.3 starts off talking about the encryption with an S2K (string-to-key, the method to create cryptokeys from a passphrase). Then follows algorithm-specific stuff, then a checksum. Since we didn't do encryption, the output above just indicates the algo-specific stuff and the checksum. Algo-specific stuff for RSA is described as: multiprecision integer (MPI) of the secret exponent d, prime p, prime q and u, the multiplicative inverse of p, mod q. The secret exponent's size is on the order of the modulus, so that would be skey[2]. The others are indeed on the order of half the size of the modulus, so those sizes make sense as well. It would seem justified to think that, like it did so far, GnuPG is reporting them in the order they appear in the packet, making p skey[3], q skey[4] and u skey[5]. If you look at the Wikipedia article on RSA, they define q_inv = q^(-1) mod p. p and q are exchangeable in the definition, so q_inv is equivalent to u. u is expensive to compute, so it is included in the secret key material. The two derived private exponents modulo p or q are cheap to compute. At least, that's how I always interpreted the presence of u and absence of the other two. > Is it because the numerical value listed is actually the key value of the > entire public/private key pair? I don't know what you mean by "key value". It might be because... > If so, is a specific portion of that key value used as the "secret key" and > another portion used as the "public key"? I get the sense you don't know how the basics of RSA work. If you're going to look at RSA key material, you should know what makes an RSA key and how it basically functions. There's no need to know the mathematical proof of the correctness of its functioning, but you do need to understand a bit of the math. I think the Wikipedia article on RSA is pretty readable, but I think they don't state clearly enough for the uninitiated that by choosing d and e as they are defined, you get (thanks to Euler's theorem) the property that: m^e^d (mod n) = m^(e*d) (mod n) = m (mod n) (equivalently:) m^d^e (mod n) = m (mod n) Since you can do the (mod n) at any time you darn well like: c = m^e (mod n) -- creates ciphertext m = c^d (mod n) = m^e^d (mod n) = m (mod n) -- message recoverable s = h^d (mod n) -- signature is based on hash h = s^e (mod n) = s^e^d (mod n) = h (mod n) -- compare hashes By comparing hashes, you've proven that the person making the signature knows d, because only d would reverse the effects of raising it to the power of e. Interestingly, the Euler's theorem Wikipedia article does mention the property: " Euler's theorem also forms the basis of the RSA encryption system: encryption and decryption in this system together amount to exponentiating the original text by k*phi(n) + 1 for some positive integer k, so Euler's theorem shows that the decrypted result is the same as the original. " This can be seen from point 5 of "Key generation" of the RSA article: Solve d for d*e = 1 (mod phi(n)) = k*phi(n) + 1 > Also, is there any command I can use to view the entire contents of the > exported secret key packet? As indicated above: remove the passphrase from the key. HTH, Peter. PS: I took the liberty to write = where it should be a congruence relation modulo n. Keeps it ASCII. -- 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 robertc at broadcom.com Sun Sep 29 22:28:20 2013 From: robertc at broadcom.com (Bob (Robert) Cavanaugh) Date: Sun, 29 Sep 2013 20:28:20 +0000 Subject: GPG Private Key Export Question In-Reply-To: <5246A0EB.4070504@digitalbrains.com> References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> <20130927143359.GA22361@straylight.m.ringlet.net> <20130927144010.GB22361@straylight.m.ringlet.net> <5245D201.2010305@sixdemonbag.org> <5246A0EB.4070504@digitalbrains.com> Message-ID: <8F0B09FC6339FA439524099BFCABC11F042DBC36@IRVEXCHMB11.corp.ad.broadcom.com> Peter, I usually lurk on this group, but I have to give kudos for this. This is the best introductory explanation I have seen in a long time. Well done. 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 Peter Lebbing Sent: Saturday, September 28, 2013 2:27 AM To: Paul Taukatch Cc: gnupg-users at gnupg.org Subject: Re: GPG Private Key Export Question On 27/09/13 21:28, Paul Taukatch wrote: > Was just hoping you could help clarify one more thing. Why exactly are the > numerical values for skey[0] and skey[1] equal to pkey[0] and pkey[1]? RFC 4880 really is the place to look for this stuff. All your questions can be answered by carefully reading the relevant sections of that RFC. Key packets are described in section 5.5. You showed a --list-packets for an RSA key, so section 5.5.2 tells us a public key packet, or equivalently the start of a secret key packet, contains, in order: a version number, a creation time, the algorithm, and a series of multiprecision integers describing the key material. For RSA, these are the modulus n and the exponent e. It is easily seen that these probably correspond to skey[0] and skey[1] respectively (or pkey), because the first one is 2048 bits, which is a reasonable size for the modulus, and the second one is 17 bits, and I believe that GnuPG always uses the public exponent 65537. Section 5.5.3 goes on to explain what follows in a secret key packet. If you would remove the password from the exported key, you could see that contents as well; right now it's in the encrypted part. Let's take a look at a 2048-bit RSA key secret packet without encryption: :secret key packet: version 4, algo 1, created 1374835387, expires 0 skey[0]: [2048 bits] skey[1]: [17 bits] skey[2]: [2043 bits] skey[3]: [1024 bits] skey[4]: [1024 bits] skey[5]: [1023 bits] checksum: 4527 keyid: A1DAD4EC3E7F0306 Section 5.5.3 starts off talking about the encryption with an S2K (string-to-key, the method to create cryptokeys from a passphrase). Then follows algorithm-specific stuff, then a checksum. Since we didn't do encryption, the output above just indicates the algo-specific stuff and the checksum. Algo-specific stuff for RSA is described as: multiprecision integer (MPI) of the secret exponent d, prime p, prime q and u, the multiplicative inverse of p, mod q. The secret exponent's size is on the order of the modulus, so that would be skey[2]. The others are indeed on the order of half the size of the modulus, so those sizes make sense as well. It would seem justified to think that, like it did so far, GnuPG is reporting them in the order they appear in the packet, making p skey[3], q skey[4] and u skey[5]. If you look at the Wikipedia article on RSA, they define q_inv = q^(-1) mod p. p and q are exchangeable in the definition, so q_inv is equivalent to u. u is expensive to compute, so it is included in the secret key material. The two derived private exponents modulo p or q are cheap to compute. At least, that's how I always interpreted the presence of u and absence of the other two. > Is it because the numerical value listed is actually the key value of the > entire public/private key pair? I don't know what you mean by "key value". It might be because... > If so, is a specific portion of that key value used as the "secret key" and > another portion used as the "public key"? I get the sense you don't know how the basics of RSA work. If you're going to look at RSA key material, you should know what makes an RSA key and how it basically functions. There's no need to know the mathematical proof of the correctness of its functioning, but you do need to understand a bit of the math. I think the Wikipedia article on RSA is pretty readable, but I think they don't state clearly enough for the uninitiated that by choosing d and e as they are defined, you get (thanks to Euler's theorem) the property that: m^e^d (mod n) = m^(e*d) (mod n) = m (mod n) (equivalently:) m^d^e (mod n) = m (mod n) Since you can do the (mod n) at any time you darn well like: c = m^e (mod n) -- creates ciphertext m = c^d (mod n) = m^e^d (mod n) = m (mod n) -- message recoverable s = h^d (mod n) -- signature is based on hash h = s^e (mod n) = s^e^d (mod n) = h (mod n) -- compare hashes By comparing hashes, you've proven that the person making the signature knows d, because only d would reverse the effects of raising it to the power of e. Interestingly, the Euler's theorem Wikipedia article does mention the property: " Euler's theorem also forms the basis of the RSA encryption system: encryption and decryption in this system together amount to exponentiating the original text by k*phi(n) + 1 for some positive integer k, so Euler's theorem shows that the decrypted result is the same as the original. " This can be seen from point 5 of "Key generation" of the RSA article: Solve d for d*e = 1 (mod phi(n)) = k*phi(n) + 1 > Also, is there any command I can use to view the entire contents of the > exported secret key packet? As indicated above: remove the passphrase from the key. HTH, Peter. PS: I took the liberty to write = where it should be a congruence relation modulo n. Keeps it ASCII. -- 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 _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From peter at digitalbrains.com Mon Sep 30 10:21:20 2013 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 30 Sep 2013 10:21:20 +0200 Subject: GPG Private Key Export Question In-Reply-To: <8F0B09FC6339FA439524099BFCABC11F042DBC36@IRVEXCHMB11.corp.ad.broadcom.com> References: <5E592188-EA34-4D08-B781-ABB9489A444D@jabberwocky.com> <20130927143359.GA22361@straylight.m.ringlet.net> <20130927144010.GB22361@straylight.m.ringlet.net> <5245D201.2010305@sixdemonbag.org> <5246A0EB.4070504@digitalbrains.com> <8F0B09FC6339FA439524099BFCABC11F042DBC36@IRVEXCHMB11.corp.ad.broadcom.com> Message-ID: <52493480.7030801@digitalbrains.com> On 29/09/13 22:28, Bob (Robert) Cavanaugh wrote: > Peter, I usually lurk on this group, but I have to give kudos for this. This > is the best introductory explanation I have seen in a long time. Well done. Thanks! :) I appreciate the compliment! (I was doubting whether to send this to the list, but I suppose civility isn't off-topic!) 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 Mon Sep 30 23:10:23 2013 From: pete at heypete.com (Pete Stephenson) Date: Mon, 30 Sep 2013 23:10:23 +0200 Subject: OpenPGP Smartcard + signing email = two signatures? Message-ID: <5249E8BF.3090802@heypete.com> 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? 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: