time delay unlock private key.
Hello A Long time ago, IBM's proprietary OS, called CMS had a particular feature for the login: It gave you three attempts to login in. If you failed there was a time delay of 20 min, if you failed again, the time delay was prolonged to one hour, and then I think to one day. My private pgp and smime keys are secured by a password, but there is no time delay, which makes a brute force attack possible. Could a time delay be implemented similar to the one I just mentioned? regards Uwe Brauer ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: time delay unlock private key.
On Thursday 23 January 2014 15:34:17 Uwe Brauer wrote: A Long time ago, IBM's proprietary OS, called CMS had a particular feature for the login: It gave you three attempts to login in. If you failed there was a time delay of 20 min, if you failed again, the time delay was prolonged to one hour, and then I think to one day. The same feature is implemented in some form in many/most contemporary login systems as well, and it makes great sense for a login system. The main reason this makes sense is that as a regular user you can't just bypass the login screen and get direct access to the hashed password value. My private pgp and smime keys are secured by a password, but there is no time delay, which makes a brute force attack possible. Could a time delay be implemented similar to the one I just mentioned? In contrast to the login screen example, a delay implemented by gnupg won't help you in this case. Once an attacker has access to your private key, he or she can try a brute-force attack against the passphrase using a patched version of gnupg that does not implement the delay. So in short: - a delay won't help you - protect your private key so this won't happen - always use a strong passphrase Cheers, Johannes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: time delay unlock private key.
On 01/23/2014 09:34 AM, Uwe Brauer wrote: Hello A Long time ago, IBM's proprietary OS, called CMS had a particular feature for the login: It gave you three attempts to login in. If you failed there was a time delay of 20 min, if you failed again, the time delay was prolonged to one hour, and then I think to one day. My private pgp and smime keys are secured by a password, but there is no time delay, which makes a brute force attack possible. Could a time delay be implemented similar to the one I just mentioned? Nope; the IBM system was an active system; the GnuPG private keyring is an on-disk data format. If the gnupg executable (which is an active system) were to implement its own timeout/falloff, anyone who wanted to crack the file in question would just recompile their own gnupg without that timeout/falloff, so it wouldn't be an effective countermeasure against an attacker. However, you can make each single attempt significantly more expensive by playing with the s2k-count argument (assuming a reasonable choice for s2k-mode and s2k-digest-algo and s2k-cipher-algo). See the manual page notes about those options for more details, and the specification's string-to-key section for a description of what those arguments do to the underlying data: https://tools.ietf.org/html/rfc4880#section-3.7 Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: time delay unlock private key.
On Thu, 23 Jan 2014 15:34, o...@mat.ucm.es said: It gave you three attempts to login in. If you failed there was a time delay of 20 min, if you failed again, the time delay was prolonged to one hour, and then I think to one day. IIRC, each CMS users gets his own VM and minidisk. Thus what you mean is the regular login protection most OSes provide. For Unix you configure this in /etc/login.defs. However, GnuPG is a user process and the agent as well as the keys are under the full control of the user. Thus the OS is not able to handle this like the login. After all, why should it. If you are logged in you may do anything with your data - why restrict it. My private pgp and smime keys are secured by a password, but there is no time delay, which makes a brute force attack possible. What is your threat model? Users who are able to access gpg/gpg-agent but are not able to read secring.gpg or private-keys-v1.d? Well, it is possible to do this with SELinux and then such a feature might make sense. However, there is a plethora of other things you need to secure first. In any case if an attacker has access to your machine or at least to your account, you already reached game over state. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
BoF at FOSDEM ?
Hi! is anyone interested in a BoF at FOSDEM on February 1 or 2? Anything special to put on the agenda? How long should we plan 30, 45 or 60 minutes? I plan to arrive on Saturday by noon which might be a bit too late to sign up for a slot. Thus if there is interest in holding a BoF, I would ask someone else to walk over to info desk at the H-Building and sign up for a slot on Saturday afternoon or Sunday. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: BoF at FOSDEM ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/23/2014 05:27 PM, Werner Koch wrote: Hi! Hi Werner, is anyone interested in a BoF at FOSDEM on February 1 or 2? Anything special to put on the agenda? How long should we plan 30, 45 or 60 minutes? I'd be interested in a BoF at the event. I don't have anything special to put on the agenda, but I can probably contribute most about the further development of the keyserver pools and SKS myself. I plan to arrive on Saturday by noon which might be a bit too late to sign up for a slot. Thus if there is interest in holding a BoF, I would ask someone else to walk over to info desk at the H-Building and sign up for a slot on Saturday afternoon or Sunday. I'll be arriving on friday evening, so I could do this on saturday morning. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Primum ego, tum ego, deinde ego First I, then I, thereafter I. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJS4VOUAAoJEPw7F94F4TagDJ0P/iAKnDsX/5zi2kJnxza8fXb8 eGdwDPPEfDjk6Zl74X7rBhYFQrK10d4VYYjnSmoWxvEX1AsEVav6lgs2pq5y+Qzf cR5v4azA0LN013ZKqyn1FX1F07NSJE54rXHvgcVFX8LmU2Z+SHCRcbq5BdouVrz1 Rb80D8AJt5yt5uvpxNYtSa8kko1Y2Qes7HTXIDNxvPpZbC+vK50itGD3yiudmLta dcaYunmTIiN7n9tQIK/NXtL2FP+ctf9O77s5JthNSHqU05s6m34Eh4xVPpIa/TL8 eHzQuqYa3SfguuhXPy6eDnvEN3F5IHO2kyZutevJfCN7qdiE+rhGNBYt7mRJL2C+ rEk5HjF6kXnkZyWhLl0XMbXwwmFNOEY4ehHXTjXb7Cteb/ORJKXtfr6oIwLTrCOJ GfA6/iWFs4K4YhdVmWUBgkHK1yNrtOr0KHj4DqiwAHekhU2Nddd36zLejZam+ad6 EDECwXNSXHCJK2wF2glr/k9q2UFcuH75j9dHb5CUSucNb6/MQp3ATEnqtY6A9uP2 2Ps9g4Wre1FMFXNQ08ZxxNq+L7+xsYIWVzq0IPEd96fuMPqLZU+3oJPFQvTSvOtW 8t8IWnfYqBijc3gsgzv/a21PAgy4oQ9GxqtZvaQoSYmUtyRN5zMkEZXXSZvEqlmn xvjwZQSDnm4Zx64kC4GU =e/eo -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: time delay unlock private key.
My private pgp and smime keys are secured by a password, but there is no time delay, which makes a brute force attack possible. GnuPG doesn't make a brute force attack possible. You make a brute-force attack possible by choosing a weak passphrase. Choose a strong one. It's really that simple. Could a time delay be implemented similar to the one I just mentioned? Not really, although DKG gave you a good heads-up about the number of iterations in s2k. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: time delay unlock private key.
On Thu, 23 Jan 2014 19:20, r...@sixdemonbag.org said: Not really, although DKG gave you a good heads-up about the number of iterations in s2k. FWIW: With GnuPG 2.x the default iteration count is calibrated to an iteration time of 100ms. That is of course machine dependent. To view that count you may run gpg-connect-agent as in this example: $ gpg-connect-agent 'getinfo s2k_count' /bye D 16777216 OK Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Revocation certificates [was: time delay unlock private key.]
On Thu, Jan 23, 2014 at 05:53:57PM +, nb.linux wrote: Hi Uwe, Johannes Zarl: So in short: - a delay won't help you - protect your private key so this won't happen - always use a strong passphrase and in addition: if you fear (or know) that your secret key was copied from your system, revoke it! To me, this is a very important feature of OpenPGP: _you_ can actually do something to reduce (not more, but also not less!) harm for yourself and others. And, you can be prepared for such an event (i.e. having created the revocation certificates in advance, stored them in a save but accessible place, printed out on paper,...). Actually, this is something I never understood. Why should people create a revocation certificate and store it in a safe place, instead of backing up the main key? So long as the primary key is encrypted and the passphrase is strong, this should not lead to any security danger. (Anyway, it's stored in a safe place. And a revocation certificate misused is dangerous too, as it ruins a web of trust.) And the advantages of doing so are that in case or accidental erasing of the private key (who never accidentally deleted an important file?), it also allows the main key to be retrieved. The primary key allows one to create a revocation certificate, not the other way around. So, why store a safe revocation certificate? Leo PS: Please, do not tell me one might have forgotten his passphrase. In this case there is no harm in shredding the secret key and waiting for the expiration date, answering persons emailing you encrypted files that you lost your passphrase. Anyway, in this case, you're screwed, and a revocation certificate would be no better -- unless it was stored unencrypted, at the risk of having it used when you do not want it to be. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates [was: time delay unlock private key.]
On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard ekl...@gmail.com wrote: On Thu, Jan 23, 2014 at 05:53:57PM +, nb.linux wrote: And, you can be prepared for such an event (i.e. having created the revocation certificates in advance, stored them in a save but accessible place, printed out on paper,...). Actually, this is something I never understood. Why should people create a revocation certificate and store it in a safe place, instead of backing up the main key? It's a sensible thing to do both, of course. So long as the primary key is encrypted and the passphrase is strong, this should not lead to any security danger. (Anyway, it's stored in a safe place. And a revocation certificate misused is dangerous too, as it ruins a web of trust.) And the advantages of doing so are that in case or accidental erasing of the private key (who never accidentally deleted an important file?), it also allows the main key to be retrieved. The primary key allows one to create a revocation certificate, not the other way around. So, why store a safe revocation certificate? The most damage that a misused revocation certificate can do is revoking one's certificate. This is a bit of a pain, in that one would need to create a new keypair, get it signed, etc., but it wouldn't result in the compromise of sensitive information, messages, etc. Misuse of a revocation certificate is a minor denial-of-service, but not a complete break of security. For example, one could easily give a trusted friend or family member a copy of a revocation certificate (perhaps printed on paper) to keep in a physically distant location. They would need to be trustworthy enough to not abuse the revocation certificate by revoking your certificate, but otherwise would not need to be given absolute trust that comes with having a copy of the private key. Same thing with keeping revocation certificates in a bank safe deposit box or some other location protected by a third-party -- if the box were compromised (say by the authorities with a court order), your private key would not be compromised. Leo PS: Please, do not tell me one might have forgotten his passphrase. In this case there is no harm in shredding the secret key and waiting for the expiration date, answering persons emailing you encrypted files that you lost your passphrase. Anyway, in this case, you're screwed, and a revocation certificate would be no better -- unless it was stored unencrypted, at the risk of having it used when you do not want it to be. Actually, that's a fairly reasonable scenario. Someone may have forgotten their passphrase for whatever reason (ranging from forgetfulness to head trauma) and would like to inform others that their key is no longer usable. Replying to people saying that their key is lost is essentially indistinguishable from a man-in-the-middle attack -- some people might simply resend the encrypted message in plaintext, defeating the purpose of encryption in the first place. A revocation certificate allows one to revoke the certificate even without access to the private key, so one could reply with their now-revoked public key (or direct someone to the revoked key on the keyserver) and say Sorry, I lost the private key and had to revoke it. -- while this doesn't resolve the issue of people resending things in plaintext, it does permit someone to actually show that their key is, in fact, revoked. Also, not all keys have expiration dates. I, for one, tend not to set expiration dates on my primary keys, but instead rotate encryption and signing subkeys (which do have expiration dates) for day-to-day use. While I could put an expiration date on the primary and extend the date as needed, it's easier for me to just make revocation certificates and keep them stored off-site. Your mileage may vary, of course. Cheers! -Pete -- Pete Stephenson ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates [was: time delay unlock private key.]
Actually, this is something I never understood. Why should people create a revocation certificate and store it in a safe place, instead of backing up the main key? A safe place for a revocation certificate may be vastly different from a safe place for a backup of your certificate. For instance, if you're married you may be completely comfortable storing a revocation certificate in a locked desk drawer to which your spouse also has a key, but you may not wish to leave a backup of your certificate there. In the event of divorce proceedings the worst your now-aggrieved spouse can do is revoke your certificate; your spouse won't have access to your private key as well. And yes, a strong passphrase is still the strongest bar against these backups being misused -- but unless you've got an eye-poppingly strong passphrase, your best bet is to rely on denying attackers access to the data as well as the passphrase. (I've often told people I'd be happy to post my private key to this mailing list in order to prove my claim that with a strong passphrase you have nothing to fear -- I never said I wouldn't grab 32 bytes from /dev/random, base64 encode them, and use that as a passphrase. That counts as eye-poppingly strong, I think...) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates
On Thu, 23 Jan 2014 21:25, ekl...@gmail.com said: PS: Please, do not tell me one might have forgotten his passphrase. In this case there is no harm in shredding the secret key and waiting for the expiration Experience has shown that this is the most common reason why there are so many secret keys on the servers which are useless. Further, an expiration data is not set by default and waiting a year until the key expired is not a good option. Further, it is also common that a secret key is lost (disk crash - no backup, backup not readable or too old) or simply stolen. This has the same effect as a forgotten passphrase. In particular in the stolen key case, you want to immediately revoke it and not wait until you can restore the key from a backup stored at some safe place. There are other rare scenarios, for example a high security key in a far away place, you are traveling and you want to immediately revoke the key for whatever reason. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates [was: time delay unlock private key.]
On Thu, Jan 23, 2014 at 09:59:30PM +0100, Pete Stephenson wrote: [...] They would need to be trustworthy enough to not abuse the revocation certificate by revoking your certificate, but otherwise would not need to be given absolute trust that comes with having a copy of the private key. Same thing with keeping revocation certificates in a bank safe deposit box or some other location protected by a third-party -- if the box were compromised (say by the authorities with a court order), your private key would not be compromised. Well, why not give them a copy of the encrypted key? So long as your passphrase is strong enough (e.g. diceware for 128-bit passphrase), it should not require to have absolute trust in the backup holder. And if you want to account for risks of mental injury serious enough to make you forget your passphrase, well... our threat models are not the same: in mine, my key will expire soon enough in this case, and noone will ever be able to compromise my secret key as noone on earth remembers the cryptographically strong passphrase. PS: Please, do not tell me one might have forgotten his passphrase. In this case there is no harm in shredding the secret key and waiting for the expiration date, answering persons emailing you encrypted files that you lost your passphrase. Anyway, in this case, you're screwed, and a revocation certificate would be no better -- unless it was stored unencrypted, at the risk of having it used when you do not want it to be. Actually, that's a fairly reasonable scenario. Someone may have forgotten their passphrase for whatever reason (ranging from forgetfulness to head trauma) and would like to inform others that their key is no longer usable. Replying to people saying that their key is lost is essentially indistinguishable from a man-in-the-middle attack -- some people might simply resend the encrypted message in plaintext, defeating the purpose of encryption in the first place. As you put it, this is essentially indistinguishable from a man-in-the-middle attack, so anyone who resend the encrypted message unencrypted is not respecting the protocol (or believe it is not important enough to be encrypted -- let's remember a lot of people just send christmas cards without envelopes). If anything important has to be transmitted (and the sender refuses to send it in cleartext), the sender will most likely send the message to someone else with physical contact with the recipient. One might argue this protocol is non-perfect, yet it is the best one the sender could achieve, revocation certificate or not. A revocation certificate allows one to revoke the certificate even without access to the private key, so one could reply with their now-revoked public key (or direct someone to the revoked key on the keyserver) and say Sorry, I lost the private key and had to revoke it. -- while this doesn't resolve the issue of people resending things in plaintext, it does permit someone to actually show that their key is, in fact, revoked. Indeed. Yet absence of answer should be clear enough to let the sender understand his message did not come to the recipient. Sure, a MitM could block the outgoing message, but anyway the sender has no better option than to find another way of sending his message: the recipient clearly does not receive the message. In case the fact of knowing a key has been revoked is critical in time, well... Knowledge of head traumas tend to expand quickly enough into the circles of acquaintances. (Sure, forgetfulness is a risk. Yet, forgetting a passphrase you type so often must be quite hard past the first few weeks.) And, what's more, such a time-critical scenarios happen only with special needs, which are AFAICT not usual. Also, not all keys have expiration dates. I, for one, tend not to set expiration dates on my primary keys, but instead rotate encryption and signing subkeys (which do have expiration dates) for day-to-day use. While I could put an expiration date on the primary and extend the date as needed, it's easier for me to just make revocation certificates and keep them stored off-site. Well, you lose the dead-man-switch. BTW, once your key is revoked, will it some day be cleared out of the keyservers, or will it stay there forever? AFAIC guess, keys with an expiration date must be purged a little while after they expired, as there is no point in keeping them, while revoked keys must be kept, as anyone might need to update them to retrieve the revocation certificate. Of course, I'm only discussing the case of normal people. There must be plenty of cases for which a revocation certificate is really useful, yet the number of tutorials in which I read Store a backup of your private key and a revocation certificate just looks like nonsense to me: if one stores both, it should at least be precised it should be in two different locations, as storing the two together is completely pointless, one
Re: Revocation certificates
On Thu, Jan 23, 2014 at 10:26:33PM +0100, Werner Koch wrote: On Thu, 23 Jan 2014 21:25, ekl...@gmail.com said: PS: Please, do not tell me one might have forgotten his passphrase. In this case there is no harm in shredding the secret key and waiting for the expiration Experience has shown that this is the most common reason why there are so many secret keys on the servers which are useless. Further, an expiration data is not set by default and waiting a year until the key expired is not a good option. Oh? I thought the most common reason was test keys, and tutorials which explain step-by-step how to make a keypair and push it on a keyserver, without telling to put an expiration date. I, unfortunately, have myself put a few test keys on the keyservers (whose passphrase I no longer have) without expiration date before knowing they would never (?) be deleted, and am still remorseful about it. And keys with an expiration date are someday deleted, while keys, even revoked, without are never, are they? BTW, revocation certificates are not produced by default either. So, why not advise people to put an expiration date, instead of counselling them to generate a revocation certificate? Further, it is also common that a secret key is lost (disk crash - no backup, backup not readable or too old) or simply stolen. This has the same effect as a forgotten passphrase. In particular in the stolen key case, you want to immediately revoke it and not wait until you can restore the key from a backup stored at some safe place. Well, my question is then: Why not restore the key immediately (having stored it at the place you would have stored the revocation certificate), and revoke it then? There are other rare scenarios, for example a high security key in a far away place, you are traveling and you want to immediately revoke the key for whatever reason. These corner-case scenarios are ones I did not mean to discuss, sorry for not having made them clear. I'm also feeling I may have failed to make myself understood: I am not denying the usefulness of revocation certificate, just the advice always popping out to generate a revocation certificate in any case, without thinking of whether it would be useful. Cheers ! Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates [was: time delay unlock private key.]
On Thu, Jan 23, 2014 at 01:27:58PM -0800, Robert J. Hansen wrote: [...] And yes, a strong passphrase is still the strongest bar against these backups being misused -- but unless you've got an eye-poppingly strong passphrase, your best bet is to rely on denying attackers access to the data as well as the passphrase. [...] Well... Diceware generates 128-bit passphrases of ten words, which is not *that* much. Yet is can be regarded as far too much. Well... seven-word passphrase provides 90-bit of security, and should not be so hard to remember. And bruteforcing it should be quite long... Sure, you would need to use really good random number generator, yet you could use /dev/random just as well as you would have for your randomly-generated passphrase. Yet, I agree I would not send my encrypted private key. But having your divorced spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an unreasonable threat to me. And AFAICT even well-funded-organizations are not yet powerful enough to bruteforce a 90-bit passphrase with enough s2k iterations. Cheers, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Non email addresses in UID
I've been thinking about UIDs in keys, rfc4880 section 5.1 says that by convention a UID is an rfc2822 email address but this is not a requirement[1]. Gnupg does enforce that restriction unless you explicitly disable it. It would seem to make sense to include other strings that can identify a user, many people have various URLs which could be said to relate to their identity, Facebook accounts, blogs etc... It could potentially be useful to be able to associate a key with these other identities, i.e. if you get an email purporting to be from someone you only know on a webforum it would be useful to be able to verify this. I'm curious what other people on this list think of this. [1] http://tools.ietf.org/html/rfc4880#section-5.11 -- Steve Jones st...@secretvolcanobase.org Key fingerprint: 3550 BFC8 D7BA 4286 0FBC 4272 2AC8 A680 7167 C896 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates [was: time delay unlock private key.]
Yet, I agree I would not send my encrypted private key. But having your divorced spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an unreasonable threat to me. It is. That's why that's not the threat being defended against. The threat is against your spouse seeing you enter your passphrase. It's very easy for roommates to discover each other's passwords and passphrases; sometimes it happens by accident. Everyone knows not to enter a passphrase with a shoulder surfer around, but if you and your spouse are sitting on the couch with your laptops open and you receive an encrypted email, are you really going to tell her, Sorry, honey, I have to take this into the other room so I can enter my passphrase without worrying about you spotting it? So long as there's marital bliss, you're perfectly safe. You just can't rely on that lasting forever. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates [was: time delay unlock private key.]
On Thu, Jan 23, 2014 at 03:08:40PM -0800, Robert J. Hansen wrote: Yet, I agree I would not send my encrypted private key. But having your divorced spouse bruteforce 90 bit of passphrase just to annoy you... seems quite an unreasonable threat to me. It is. That's why that's not the threat being defended against. The threat is against your spouse seeing you enter your passphrase. It's very easy for roommates to discover each other's passwords and passphrases; sometimes it happens by accident. Everyone knows not to enter a passphrase with a shoulder surfer around, but if you and your spouse are sitting on the couch with your laptops open and you receive an encrypted email, are you really going to tell her, Sorry, honey, I have to take this into the other room so I can enter my passphrase without worrying about you spotting it? So long as there's marital bliss, you're perfectly safe. You just can't rely on that lasting forever. Well... I don't know how you type, but someone looking at me who sees me type my passphrase would really have to try hard to guess what passphrase I am using. And even more to remember a seven-word sentence seen once. BTW, I once had a fun experiment: just type an eight random chars password with no protection at all, and asking people behind me to remember it. The password was displayed as I typed it, and left approx. two seconds more. No one managed to see it and remember it. A few days later, I conducted the same experiment with the same people and the same password, and no password was successfully guessed. Sure, the information gathered would be enough to bootstrap a successful bruteforce, but the experiment was a lot more easy to complete than peeping at and remembering a seven-word password. So, if the spouse is doing it, then marital bliss has already come to an end, and one should have noticed it. Yet, being unmarried, I cannot say anything about such things. So, within that threat model, revocation certificates are useful for sure. Assuming one's spouse would first grab the secret key and remember the passphrase before divorce. Thanks for making that point! Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates [was: time delay unlock private key.]
Well... I don't know how you type With a nine-volt battery, a paperclip, and a USB cable that has only one end -- the other is bare wires. You wouldn't believe how difficult it is to do the initial handshake, but once you've got it down you can easily tap out oh, three or four words a minute. For speed, nothing else comes close. My father gets on my case for using the nine-volt battery. In his day, they had a potato and a couple of wire leads plunged into it. But really, technology marches on and we should all embrace battery technology. passphrase would really have to try hard to guess what passphrase I am using. And even more to remember a seven-word sentence seen once. You are not the typical use case. No one person is a typical use case. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revocation certificates
On Thu, 23 Jan 2014 23:15, ekl...@gmail.com said: Oh? I thought the most common reason was test keys, and tutorials which explain step-by-step how to make a keypair and push it on a keyserver, without telling Obviously, I don't have no hard evidence for the claim that forgotten passpharses are a reason for many unusable keys. However, I have heard too many times statements like “Please don't encrypt to that key; I - uhmm - can't remember my passphrase”. And keys with an expiration date are someday deleted, while keys, even revoked, without are never, are they? No they are not deleted. They are still useful for signature verification. Think about gnupg 1.0.0 which has been signed by a long expired key of mine - verifying it still gives some evidence that the tarball is genuine. The key merely expired. If I had reasons to assume that the key is compromised I would issue a revocation. Verification tools show that. BTW, revocation certificates are not produced by default either. So, why not advise people to put an expiration date, instead of counselling them The reason why they are not generated by default is that I am sure that many people would accidentally publish the revocation. That is not optimal and thus my current plan is to create a revocation be default but modify the armored file so that it can only be imported after editing the file. Well, my question is then: Why not restore the key immediately (having stored it at the place you would have stored the revocation certificate), and revoke it then? The key is of course stored at a bank safe. The sheet/cdrom with the revocation is in the drawer of my desk. the usefulness of revocation certificate, just the advice always popping out to generate a revocation certificate in any case, without thinking of whether it would be useful. Okay, that is a different thing. I plan to change that with a notice saying which file has the edited revocation certificate. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
