dashohoxha at gmail.com
Wed Mar 23 00:12:07 CET 2016
On Tue, Mar 22, 2016 at 11:25 PM, Peter Lebbing <peter at digitalbrains.com>
> > What is wrong with that? As long as there is a subkey for encryption,
> > gpg will use the subkey for encryption, even if the primary key is
> > capable of encryption.
> That is not up to you! It's up to your peers, or your attackers. They
> pick which key they encrypt to, and your GnuPG will just use whatever
> key was encrypted to, to decrypt it. You don't have a say in it. Your
> only recourse is to delete your primary key, meaning you can't certify
> anymore either.
> If there are hidden recipients, GnuPG will simply try both your primary
> and your subkey to decrypt the hidden PKESK packet.
> Why did you change this to the setting it had in the way before, the
> long-long ago: one key for everything? I've only ever seen it advocated
> in the sense that "you should encrypt to the primary key for TOP SECRET
> material, since I only have that key on an air-gapped offline computer".
> Not precisely a beginner's scenario, and a flawed argument anyway if you
> ask me.
You are right on this, I got it wrong. I had no particular reason for doing
I will make the primary key ony with certification capability, if this is
what the experts recommend.
> > And I beleive that this can be done with a bunch of simple
> > shell scripts.
> Go ahead. You've heard multiple opinions from several people. But please
> be aware of the criticism with regard to the details like the key
> capabilities and so forth. You're choosing this for your users, not just
> for yourself. Be prudent. Don't hurt your users, and realise that the
> defaults are that for good reason. I would strongly urge you to keep
> GnuPG at its defaults: they are good. Just change the interface, not the
I do expect some help on these matters, because I am neither a security
expert nor a gpg expert.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnupg-users