On 27/11/15 12:41, Andrew Gallagher wrote:
> There's a post about how to do this in the list archives:
>
> https://lists.gnupg.org/pipermail/gnupg-users/2009-May/036505.html
Thanks for the pointer!
> ... but it's really not worth your while. So long as your primary key
> doesn't have E usage set
On 27/11/15 10:32, Peter Lebbing wrote:
> On 23/11/15 21:31, James wrote:
>> It appears that information I had read previously was erroneous. I was
>> under the impression the capabilities (at least for the primary key)
>> were set in stone, hence my apprehension at avoiding those insatiable
>> kno
On 23/11/15 21:31, James wrote:
> It appears that information I had read previously was erroneous. I was
> under the impression the capabilities (at least for the primary key)
> were set in stone, hence my apprehension at avoiding those insatiable
> knobs and gears I like to tinker with. ;)
Well,
Among the privacy-concerned, there is a strong impulse to use the hardest
possible cryptography. The truth is that 2048-bit keys and a 256-bit hash
algorithm are completely secure against brute force attacks, and barring
any surprising developments in cryptanalysis, will remain so for a good
long t
Thank you Robert and Peter.
It appears that information I had read previously was erroneous. I was
under the impression the capabilities (at least for the primary key)
were set in stone, hence my apprehension at avoiding those insatiable
knobs and gears I like to tinker with. ;)
This thread has b
> The same can be said for almost any complex system, software or not.
Absolutely. Please don't misinterpret what I said as trying to dissuade
you from curiosity. I'm just urging you to not let your curiosity lead
you into making poor decisions from the get-go.
The following anecdote is meander
On 23/11/15 17:20, James wrote:
> If you create a primary key, upload it to a public
> keyserver and later decide: "hrm, my public key should really only
> certify, not sign," it's a bit too late. (although not impossible,
> difficult to change ex post facto).
Okay, so let me answer this one detai
Robert,
I appreciate the input and hear you loud and clear.
I respect that GPG makes sane, technically secure and well-thought-out
decisions. As I mentioned in my previous response, the folks that
designed and coded GPG are likely far more intelligent than I. This
does not assuage my deep curiosi
> - I believe that GPG has sane settings out-of-the-box, but prefer to
> verify that trust. ;) Why doesn't GPG set the digest algorithm to
> SHA512 instead of 256 out of the box?
For the same reason it doesn't default to RSA-4096: because the authors
are unconvinced there's a need. Longer is not
All,
I'm pleasantly surprised by the warm and helpful reception of this
community to my many questions. Thank you all in advance for your
detailed and thorough responses. The conversation thus far has been
quite thought-provoking.
I thoroughly read and re-read the responses in this thread, tinker
On 17/11/15 15:33, Andrew Gallagher wrote:
>> https://alexcabal.com/creating-the-perfect-gpg-keypair/
>
> This is a fairly good article - I've used it myself for reference in the
> past. Also have a look at:
I disagree, I'd recommend people not to read that article, let alone
follow its advice.
> Is this accurate?
Not really, no.
One of the weirdest things about OpenPGP (and, by extension, GnuPG) is
that it provides a great deal of mechanism and very little in the way of
policy. As a result, it's incredibly difficult to speak about best
practices in specific terms. What's good practic
On 11/17/2015 1:32 PM, James wrote:
> All,
>
> I'm just dipping my toes into GPG and am making a significant effort
> to "do things right" out of the gate.
Welcome!
> Based on my research, it is my understanding that "best practices"
> dictate we should have one master key with subkeys for speci
On 17/11/15 12:32, James wrote:
>
> Based on my research, it is my understanding that "best practices"
> dictate we should have one master key with subkeys for specific
> purposes (personal work, "work" work, etc.). The master key is kept on
> an "offline" computer and then used only to revoke par
All,
I'm just dipping my toes into GPG and am making a significant effort
to "do things right" out of the gate.
Based on my research, it is my understanding that "best practices"
dictate we should have one master key with subkeys for specific
purposes (personal work, "work" work, etc.). The maste
15 matches
Mail list logo
