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
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,
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
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,
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
> 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
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
> - 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
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
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
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
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
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
14 matches
Mail list logo
