> On 27 Dec 2019, at 20:52, Werner Koch wrote:
>
> On Thu, 26 Dec 2019 23:04, Dirk-Willem van Gulik said:
>
>> But this does not seem to happen when doing a --quick-add-key
>> subkey. Is this intentional ? Or is there a flag one can set ?
>
> Right. If you want to revoke a subkey we can ass
On Thu, 26 Dec 2019 23:04, Dirk-Willem van Gulik said:
> But this does not seem to happen when doing a --quick-add-key
> subkey. Is this intentional ? Or is there a flag one can set ?
Right. If you want to revoke a subkey we can assume that you still have
access to the primary key and thus it is
When you generate the main key (even with a programmatic
--quick-key-generate) - it nicely puts revocation certificats in the
revocs.d directory of GNUPGHOME.
But this does not seem to happen when doing a --quick-add-key subkey. Is
this intentional ? Or is there a flag one can set ?
Dw
___
fwiw, i agree with Damien that the existing text in the FAQ about
generating a revocation certificate should be removed.
I think that there should be some text like "where can i find my key's
revocation certificate?" which could be added to the FAQ.
However, situations like these:
On Sat 2018-11
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 8 November 2018 at 3:21:58 PM, in
,
Damien Goutte-Gattat via Gnupg-users wrote:-
> And with
> modern GnuPG there
> is no need to recommend to generate a revocation
> certificate.
Not immediately after generating a new GnuPG certif
On Fri, 09 Nov 2018 09:22:13 +0100, Werner Koch wrote:
> On Thu, 8 Nov 2018 18:34, stefan.cl...@posteo.de said:
>
> > apartment and accidentally threw away the box
> > in which the revocation cert was stored... :-(
>
> :-(
>
> > How would you procede now?
>
> Fetch your backup which for yo
On Thu, 8 Nov 2018 18:34, stefan.cl...@posteo.de said:
> apartment and accidentally threw away the box
> in which the revocation cert was stored... :-(
:-(
> How would you procede now?
Fetch your backup which for you will have stored at a different
venue .-)
Call the locksmith to open the loc
On Thu, 8 Nov 2018 15:21:58 +, Damien Goutte-Gattat via Gnupg-users
wrote:
> Hi GnuPG folks,
>
> The current version of the FAQ recommends creating a revocation
> certificate at several places.
>
>
> § 7.17
>
> "We recommend you create a revocation certificate immediately
>after gener
Hi GnuPG folks,
The current version of the FAQ recommends creating a revocation
certificate at several places.
§ 7.17
"We recommend you create a revocation certificate immediately
after generating a new GnuPG certificate."
§ 8.5
"What should I do after making my certificate?
Genera
On Fri, Jan 24, 2014 at 07:47:15AM +0100, Werner Koch wrote:
> [...]
>
> > 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
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.
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:
at 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 i
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 min
;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 thi
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
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 dat
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 expirati
opy 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, w
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 secr
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 i
On Thu, Jan 23, 2014 at 9:25 PM, Leo Gaspard 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,
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
On 01/28/2010 10:44 PM, Richard Geddes wrote:
> Generating a revocation certificate as soon as you generate your key
> pair is a wise thing to do, in case you lose control of your passphrase
> ... I did that.
Good! :)
> My question is, if I edit my key pair... let's say I add a new uid to my
> k
Generating a revocation certificate as soon as you generate your key
pair is a wise thing to do, in case you lose control of your passphrase
... I did that.
My question is, if I edit my key pair... let's say I add a new uid to my
key pair... do I need to generate a new revocation certificate o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
John Clizbe escribió:
> And depending on the printer font, you get the joy of '0' vs 'O'; '1' vs 'l';
> and '8' vs 'B'.
But I suppose you can copy/paste it into a text editor, and chose a
font clearer to read... or I am wrong?
> I'll take 0-9A-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
John Clizbe escribió:
> Faramir wrote:
>> John Clizbe escribió:
>>
>>> And depending on the printer font, you get the joy of '0' vs 'O'; '1' vs
>>> 'l';
>>> and '8' vs 'B'.
>> But I suppose you can copy/paste it into a text editor, and chose a
>>
Faramir wrote:
> John Clizbe escribió:
>
>> And depending on the printer font, you get the joy of '0' vs 'O'; '1' vs 'l';
>> and '8' vs 'B'.
>
> But I suppose you can copy/paste it into a text editor, and chose a
> font clearer to read... or I am wrong?
Could you explain how you are going to c
David Shaw wrote:
> But you seem to be missing the point. Uuencode (or GPG armor) creates
> lines that are very difficult to type in. There are no spaces, and
> the character set includes uppercase, lowercase, numbers, and
> symbols. There is no CRC to help you type it back in again, so if
ckily revocation
certificates are pretty short to begin with. The only real
advantage
that paperkey could bring to revocation certificates is the per-
line
CRC, which makes retyping easier.
Yes, that's the point.
NAME
uuencode, uudecode - encode a binary file, or decode its
David Shaw wrote:
> On Mon, Oct 06, 2008 at 08:03:12AM +0200, Sven Radde wrote:
>> Am Sonntag, den 05.10.2008, 19:49 -0400 schrieb David Shaw:
>>> A revocation certificate, on the other hand, doesn't
>>> have all that much that can be removed. Luckily revocati
On Mon, Oct 06, 2008 at 08:03:12AM +0200, Sven Radde wrote:
> Am Sonntag, den 05.10.2008, 19:49 -0400 schrieb David Shaw:
> > A revocation certificate, on the other hand, doesn't
> > have all that much that can be removed. Luckily revocation
> > certificates are
Hi!
Am Sonntag, den 05.10.2008, 20:11 -0400 schrieb Faramir:
> Also, if the key is reconstructed (and provided the passphrase can be
> found somewhere), it should be easy to revoke it...
Actively revoking a key requires the passphrase and it requires a
trustworthy PC. When I'm currently trying
Am Sonntag, den 05.10.2008, 19:49 -0400 schrieb David Shaw:
> A revocation certificate, on the other hand, doesn't
> have all that much that can be removed. Luckily revocation
> certificates are pretty short to begin with. The only real advantage
> that paperkey could br
On Oct 5, 2008, at 8:11 PM, Faramir wrote:
* The file format is now included as part of the base16 output, as
there is no guarantee that this program will be on-hand when a
reconstruction is necessary. The format can also be displayed
via the --file-format command. Suggested
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David Shaw escribió:
...
> that much that can be removed. Luckily revocation certificates are
> pretty short to begin with. The only real advantage that paperkey could
> bring to revocation certificates is the per-line CRC, which makes
&
On Oct 5, 2008, at 3:40 PM, Sven Radde wrote:
Although David's awesome little tool [1] reduces the chance of
losing a
secret key, I am still a fan for pre-generated revocation certificates
in case a key is irrecoverably lost.
David, is there a chance that you will extend paperkey so th
On Sun, 2008-10-05 at 21:40 +0200, Sven Radde wrote:
> David, is there a chance that you will extend paperkey so that it
> encodes and decodes revocation certificates?
I'm not David (obviously), but I don't see the win here.
The problem with paper copies of private keys is
Hi!
Although David's awesome little tool [1] reduces the chance of losing a
secret key, I am still a fan for pre-generated revocation certificates
in case a key is irrecoverably lost.
David, is there a chance that you will extend paperkey so that it
encodes and decodes revocation certifi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Jorgen Christiansen Lysdal wrote:
> Robert J. Hansen wrote:
>> This deputy sheriff reported to his superior, and I wound up
>> with a thirty-day delay in the paperwork while the county sheriff made
>> sure that I didn't have murder afoot. Were they
Robert J. Hansen wrote:
> This deputy sheriff reported to his superior, and I wound up
> with a thirty-day delay in the paperwork while the county sheriff made
> sure that I didn't have murder afoot. Were they overreacting? Sure,a
> bit. But they were also doing their job.
They could have been
Faramir wrote:
> With due respect to USA, each time I read things like this, I am happy
> for not living there... my main concern here is if economy will be
> affected or not for things happening outside my country. But at least I
> know I can rely on justice to don't cause me problems for things
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Lawrence Chin escribió:
> I'm sorry to have failed to observed Netiquette, but I was just too
> afraid. I have been reported before to law enforcement as saying things
You was reported? By somebody? The *proper* use of encryption should
prevent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Robert J. Hansen wrote:
> If you are that concerned about the intelligence and/or law-enforcement
> communities seeing what you write, you should be very careful about your
> involvement on this, or any of several other, mailing lists.
More precise
Lawrence Chin wrote:
> So I'm very paranoid about, not just what I said to others, but
> precisely what others said to me.
If this is of so much concern to you, you should probably consider
leaving the various crypto mailing lists altogether. Members of various
national intelligence communities a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
markus reichelt wrote:
> * Faramir <[EMAIL PROTECTED]> wrote:
>
>> Begin of "spoiler blank lines"
>> [...]
>> End of "spoiler blank lines"
>
> niiice, I bet he didn't catch that one!
>
>
>
>
* Faramir <[EMAIL PROTECTED]> wrote:
> Begin of "spoiler blank lines"
> [...]
> End of "spoiler blank lines"
niiice, I bet he didn't catch that one!
--
left blank, right bald
pgptXuX9KPvBR.pgp
Description: PGP signature
___
Gnupg-users mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Lawrence, if your nerves are so shaken, maybe you should stop reading
this message right now, and delete this message, or maybe keep it to
read it once you are better. I will put some blank lines as "spoiler",
just in case. And please note, this mess
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Lawrence Chin wrote:
> This is another message of Kara's that's causing me nightmare last night
> when I read through it. We shouldn't have words like "...Deputy
> director" or "NS adviser" etc in an encrypted email!
Why? Even if Reference to enti
or
>> maybe in the GnuPG folder, since you was working at that folder
>> when you generated the rev certificate.
>
> Here I'd politely tend to disagree with Faramir -- you are able to
> save the revocation statements wherever you wish -- it's your decision
> and n
50 matches
Mail list logo
