Re: Hibernation and secret keys
On Jun 23, 2009, at 7:28 AM, Werner Koch wrote: On Sun, 21 Jun 2009 00:10, t.e...@yahoo.com said: So, here is the question: Is is possible to secure gpg (or PGP or TrueCrypt for that matter) on a Windows system? If you have the ability to run a program if hibernation kicks in, you may want to run: gpgconf --reload gpg-agent That deletes the passphrase cache. I assume that you are using a recent version of gnupg2. If possible, I'd also add a pause for running gpg processes to exit to cover a small race condition. Even if the passphrase cache is wiped, if there is a running gpg process at suspend time, secret material could still be caught in the hibernation data. GPG does wipe its memory for things like session keys (to the limit that such things can be done in software), but the process has to complete for the wipe to happen. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Hibernation and secret keys
On Tue, 23 Jun 2009 16:55, ds...@jabberwocky.com said: If possible, I'd also add a pause for running gpg processes to exit to cover a small race condition. Even if the passphrase cache is wiped, if there is a running gpg process at suspend time, secret material could still be caught in the hibernation data. GPG does wipe its That is right. With 2.1 we will change that so that only the gpg-agent performs any private key operations and the gpg2 processes care only about session keys. The latter is not really problematic given that the plaintext is usually also in RAM and thus a lower hanging fruit. (gpgsm already works like this). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Required patches for the OpenPG card v2.0
Hi!
Unfortunately I realized too late that 2.0.12 still had bugs with the
new OpenPGP card[1]. Without actual hardware testing stuff is a bit
hard; I had 2 engineering samples during development and we swapped card
back and forth to squash the bugs in the card's firmware while also
hacking gnupg. Thus some things got not tested for 2.0.12.
Find attached 2 patches against GnuPG 2.0.12 to fix the card problem as
well as an unlrealted Windows-only problem. These patches are already
in the Gpg4win 2.0.0rc1 installer currently being copied to the servers.
GnuPG 1.4 does not yet support the v2 cards. I plan to backport the
code from 2.0 in the next week and then it should not take too long to
get 1.4.10 out. If you don't want to wait: gpg2 is the perfect version
for the desktop or laptop ;-)
A cautionary note: If you plan to buy a smartcard reader, please abstain
From Omnikey based readers (Cardman and some others). They do not work
with 2048 bit smartcards. They work on Windows, but not on a free OSes.
We need to do some protocol analysis to see how the Windows driver
achieves to send so-called extended lengths APDUs. The vendors are not
very helpful in this regard, thus I can only suggest to resort to SCM
based readers.
Salam-Shalom,
Werner
[1] Meanwhile we received the first batch of cards; they will be sold at
the LinuxTag and if cards are left over by next week through the
well known distributor.
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
#! /bin/sh
patch -p0 -f $* $0
exit $?
scd/
2009-06-18 Werner Koch w...@g10code.com
* app-openpgp.c (verify_chv2): Remove special case for v2 cards.
(get_public_key): Use extended mode.
Index: scd/app-openpgp.c
===
--- scd/app-openpgp.c (revision 5047)
+++ scd/app-openpgp.c (working copy)
@@ -1118,11 +1118,25 @@
if (app-card_version 0x0100)
{
+ int exmode, le_value;
+
/* We may simply read the public key out of these cards. */
+ if (app-app_local-cardcap.ext_lc_le)
+{
+ exmode = 1;/* Use extended length. */
+ le_value = app-app_local-extcap.max_rsp_data;
+}
+ else
+{
+ exmode = 0;
+ le_value = 256; /* Use legacy value. */
+}
+
err = iso7816_read_public_key
-(app-slot, 0, (const unsigned char*)(keyno == 0? \xB6 :
- keyno == 1? \xB8 : \xA4), 2,
- 0,
+(app-slot, exmode,
+ (const unsigned char*)(keyno == 0? \xB6 :
+keyno == 1? \xB8 : \xA4), 2,
+ le_value,
buffer, buflen);
if (err)
{
@@ -1579,43 +1593,31 @@
char *pinvalue;
if (app-did_chv2)
-return 0; /* We already verified CHV2 (PW1 for v2 cards). */
+return 0; /* We already verified CHV2. */
- if (app-app_local-extcap.is_v2)
+ rc = verify_a_chv (app, pincb, pincb_arg, 2, 0, pinvalue);
+ if (rc)
+return rc;
+ app-did_chv2 = 1;
+
+ if (!app-did_chv1 !app-force_chv1 pinvalue)
{
- /* Version two cards don't have a CHV2 anymore. We need to
- verify CHV1 (now called PW1) instead. */
- rc = verify_a_chv (app, pincb, pincb_arg, 1, 0, pinvalue);
+ /* For convenience we verify CHV1 here too. We do this only if
+ the card is not configured to require a verification before
+ each CHV1 controlled operation (force_chv1) and if we are not
+ using the keypad (PINVALUE == NULL). */
+ rc = iso7816_verify (app-slot, 0x81, pinvalue, strlen (pinvalue));
+ if (gpg_err_code (rc) == GPG_ERR_BAD_PIN)
+rc = gpg_error (GPG_ERR_PIN_NOT_SYNCED);
if (rc)
-return rc;
- app-did_chv2 = 1;
-}
- else
-{
- /* Version 1 cards only. */
- rc = verify_a_chv (app, pincb, pincb_arg, 2, 0, pinvalue);
- if (rc)
-return rc;
- app-did_chv2 = 1;
-
- if (!app-did_chv1 !app-force_chv1 pinvalue)
{
- /* For convenience we verify CHV1 here too. We do this only
- if the card is not configured to require a verification
- before each CHV1 controlled operation (force_chv1) and if
- we are not using the keypad (PINVALUE == NULL). */
- rc = iso7816_verify (app-slot, 0x81, pinvalue, strlen (pinvalue));
- if (gpg_err_code (rc) == GPG_ERR_BAD_PIN)
-rc = gpg_error (GPG_ERR_PIN_NOT_SYNCED);
- if (rc)
-{
- log_error (_(verify CHV%d failed: %s\n), 1, gpg_strerror (rc));
- flush_cache_after_error (app);
-}
- else
-app-did_chv1 = 1;
+ log_error (_(verify CHV%d failed: %s\n), 1, gpg_strerror (rc));
+ flush_cache_after_error (app);
}
+ else
+app-did_chv1 = 1;
}
+
xfree (pinvalue);
return rc;
#! /bin/sh
patch -p0 -f $* $0
Key propagation
I was wondering if it is possible to limit key propagation, that is the number of times a key can be exported and reimported. If I understand correctly, once a key is created, there is no way to limit the number of times this key is going to be propagated. If I give my public (or secret for that matter) key to someone else, that person in turn can export it and give it to someone else, ad infinitum. If I want only 1 or 2 other people to have my key, is it possible during the key creation to give it a parameter stating that this key can only be exported x number of times? Of course all this assumes that I still have control of the key file, for instance I go on the other person's computer, import the key and then delete the original key file that was used for the import. Thanks ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: corrupted file?
Joseph Oreste Bruni wrote the following on 6/23/09 1:22 PM: Hello, The file gnupg-2.0.12.tar.bz2 hosted on ftp.gnupg.org appears to be corrupt. [...] Downloaded from http://www.gnupg.org/download: $ gpg --verify path/gnupg-2.0.12.tar.bz2.sig path/gnupg-2.0.12.tar.bz2 gpg: Signature made Wed Jun 17 06:43:42 2009 EDT using RSA key ID 1CE0C630 gpg: Good signature from Werner Koch (dist sig) dd...@gnu.org I didn't try to verify the MD5 string. Charly MacOSX 10.5.7 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key propagation
On 06/23/2009 12:45 PM, franv wrote: I was wondering if it is possible to limit key propagation, that is the number of times a key can be exported and reimported. A key is a piece of digital information; as such, it can be transferred without loss an arbitrary number of times, and there's really no way to prevent that (witness all the problems record companies have trying to limit propagation of recordings they produce). However, if you want to advise people that they should not export signatures on your key, you can set the no export flag, making that signature local. If you were to set that flag on your self-signature, then no one who respects the intent of that flag would export the key itself, and reasonable keyservers should not accept or store it, but i've never tried. I'm not sure what you'd need to do to make sure that the non-exportable flag was set on your self-signature with gpg. If you sort it out, it would be great if you could publish how you did it. note that this doesn't let you limit it to an arbitrary number of hops. it simply requests that people do not propagate the certification (or the associated key, if it's a self-sig), and reasonable clients should respect that. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key propagation
Thanks for the answer Daniel. That's more or less what I thought, even though I could retain the control of the exported key file, of course once imported on the other computer, it is then written in the gpg conf files that could in turn be copied to another computer... Franv On Tuesday 23 June 2009 11:33:12 Daniel Kahn Gillmor wrote: On 06/23/2009 12:45 PM, franv wrote: I was wondering if it is possible to limit key propagation, that is the number of times a key can be exported and reimported. A key is a piece of digital information; as such, it can be transferred without loss an arbitrary number of times, and there's really no way to prevent that (witness all the problems record companies have trying to limit propagation of recordings they produce). However, if you want to advise people that they should not export signatures on your key, you can set the no export flag, making that signature local. If you were to set that flag on your self-signature, then no one who respects the intent of that flag would export the key itself, and reasonable keyservers should not accept or store it, but i've never tried. I'm not sure what you'd need to do to make sure that the non-exportable flag was set on your self-signature with gpg. If you sort it out, it would be great if you could publish how you did it. note that this doesn't let you limit it to an arbitrary number of hops. it simply requests that people do not propagate the certification (or the associated key, if it's a self-sig), and reasonable clients should respect that. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key propagation
On Jun 23, 2009, at 2:33 PM, Daniel Kahn Gillmor wrote: On 06/23/2009 12:45 PM, franv wrote: I was wondering if it is possible to limit key propagation, that is the number of times a key can be exported and reimported. A key is a piece of digital information; as such, it can be transferred without loss an arbitrary number of times, and there's really no way to prevent that (witness all the problems record companies have trying to limit propagation of recordings they produce). However, if you want to advise people that they should not export signatures on your key, you can set the no export flag, making that signature local. If you were to set that flag on your self-signature, then no one who respects the intent of that flag would export the key itself, and reasonable keyservers should not accept or store it, but i've never tried. Unfortunately, local signatures do not work that way. Each implementation strips local signatures both on export and on import (just in case someone leaked one on export). They just don't have anything to do with exporting keys. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key propagation
On Jun 23, 2009, at 12:45 PM, franv wrote: I was wondering if it is possible to limit key propagation, that is the number of times a key can be exported and reimported. No. If I want only 1 or 2 other people to have my key, is it possible during the key creation to give it a parameter stating that this key can only be exported x number of times? You can ask those people, nicely, to not give your key out to anyone, but that's about it. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: corrupted file?
On Jun 23, 2009, at 3:35 PM, Joseph Oreste Bruni wrote: Here's the weird part: If I download the file using Safari I receive the file correctly. If I download the file using the command-line ftp on either OS X (10.5.7) or FreeBSD (7.2) the file appears corrupted and is slightly smaller. BUT, if I issue the binary command to the command line ftp program, the file is retrieved correctly. This is really bizarre because both my local system and the remote system are both UNIX so binary is supposed to be the default. ftp(1): ascii Set the file transfer type to network ASCII. This is the default type. Binary is not the default in the command line ftp program. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: corrupted file?
On Jun 23, 2009, at 8:01 PM, David Shaw wrote: On Jun 23, 2009, at 3:35 PM, Joseph Oreste Bruni wrote: ftp(1): ascii Set the file transfer type to network ASCII. This is the default type. Binary is not the default in the command line ftp program. Oddly, it is when I connect to ftp.gnupg.ca. I'm guessing that site overrides the default? -Joe ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Key propagation
On 06/23/2009 10:53 PM, David Shaw wrote: Unfortunately, local signatures do not work that way. Each implementation strips local signatures both on export and on import (just in case someone leaked one on export). They just don't have anything to do with exporting keys. Right, but a key with no valid self-sigs won't be imported either, right? If all self-sigs were marked non-exportable, wouldn't that limit the import (if not export) of the key itself? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
