Re: Revocation certificates [was: time delay unlock private key.]
On 24.01.2014, Leo Gaspard wrote: Actually, this is something I never understood. Why should people create a revocation certificate and store it in a safe place, instead of backing up the main key? Because a backup only makes sense when it's stored in a diffrent place than the key itself: With every backup you create, you have one place more you'll have to keep secure, and doubled the chance that your key can be accessed. ___ 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 04:38:19PM -0800, Robert J. Hansen wrote: Well... I don't know how you type With a nine-volt battery, a paperclip, and a USB cable that has only one end -- the other is bare wires. You wouldn't believe how difficult it is to do the initial handshake, but once you've got it down you can easily tap out oh, three or four words a minute. For speed, nothing else comes close. My father gets on my case for using the nine-volt battery. In his day, they had a potato and a couple of wire leads plunged into it. But really, technology marches on and we should all embrace battery technology. Great laugh! (of course, I meant how fast) passphrase would really have to try hard to guess what passphrase I am using. And even more to remember a seven-word sentence seen once. You are not the typical use case. No one person is a typical use case. Well... You are right, of course. Yet this does not answer my second point: if the spouse is spying on you to get your passphrase and remember it, then love is already gone, and you are being subject to the usual hooker attack. Yet I do see your point for revocation certificates here, I think. Oh, just found another one in favor of revocation certificates: they can be easily sent to keyservers from cybercafes without any special software installed. Thanks and cheers, Leo ___ 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 [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 [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
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
