Re: best practices for creating keys

[James]

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 been tremendously insightful. My thanks to all who
responded and shared their perspectives.

James

On Mon, Nov 23, 2015 at 12:05 PM, Robert J. Hansen  wrote:
>> 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 meandering, but if you'll bear with me for two
> paragraphs it'll make sense:
>
> I live in the United States, in a state which allows private citizens,
> under incredibly close regulation, to own military firearms.  When I
> visit the rifle range, sometimes I'll spend some time with a suppressed
> German-made MP5SD3 submachinegun.  (It's not mine: a friend owns one and
> we sometimes hit the range together.)  It's a nice piece of kit; I like
> it.  And quite often, other people who are at the range want to talk
> shop about it.  We get into discussions about roller-locked firearms
> like the Cz52 and MG42 versus roller-delayed firearms like the MP5, how
> annoying it is when people get the terminology wrong, whether it's a
> good thing or a bad thing the MP5 uses a fluted chamber, how anyone who
> thinks it's okay to fire subsonic 9mm from the MP5 needs their head
> examined, and so on and so on.  And it's fun, as far as it goes, and
> it's often educational for the people who've never seen an MP5 before
> and are fascinated to learn more about its inner workings.
>
> It's great -- up until they think they know enough to use an MP5 on the
> range, despite the fact they've never fired a weapon before.  At that
> point we have to explain to them that look, yes, they know a lot more
> about the MP5 than most people do, but really, they need to start off
> with something small, like a nice .22 Ruger Mk II, develop the basic
> skills, learn trigger discipline and proper usage of safeties, learn how
> the range operates and what the various calls by the Range Safety
> Officers mean, etcetera.  There's a huge amount to learn: they don't
> need to make things worse by leaping straight over this stuff straight
> to firing fully-automatic military hardware.  That's just imprudent, and
> we'd be awful human beings if we permitted them to do that.
>
> That's what we're talking about here.  The knobs and dials on GnuPG are
> great fun to learn about: you're in good company!  But there's a big
> reason why we're urging you to not do what you want to do, and that's
> because you're not yet competent to do what you want to do.  We'd rather
> see you start off with small steps, and from there move on to the big
> ones, than have you start off big.
>
> Admittedly, it's highly unlikely that screwing up with GnuPG will lead
> to a magazine of 9mm being sprayed around the room.  But it's the
> principle of the thing.  :)
>
> So: for now, please stick with the defaults.
>
>> It seems to me that, perhaps, making these sorts of decisions up front
>> is of some value.
>
> Not really.  It's probably not worth worrying about.
>
>> 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.
>
> No.
>
> One of the important skills to learn early on is about how to migrate a
> certificate.  You're going to make mistakes.  You'll forget passphrases,
> you'll compromise your keys, you'll realize you made a hash of it and
> need to start over again.  How do you recover from this?  How do you
> communicate a change-of-certificate with your correspondents?  Etc.
>
> The only reason to think "it's a bit too late" is if
>
> a) you're not allowed to change your certificate -- you
>*must* keep the same one for the next X years
> b) you don't know how to migrate to a new certificate
>
> There are almost certainly people and groups for whom (a) applies.  If
> you're one of them, please let me know.  But if (b) applies, then I
> suggest learning the skill, because it's important.  :)
>
>> It's also worth noting that the suggestion to remove the primary key
>> from your laptop isn't thrown up on a few random blogs; instead it is
>> something that other projects[1] encourage.
>
> That wiki page is guidance *for Debian*.  Debian has some very specific
> operating restrictions which are unlikely to apply to you.  The
> guidelines Debian put together apply to them, in their environment,
> facing their threat model, which they defend with their particular set
> of resources.
>
> It is not guidance for you, unless you're part of Debian.
>
> By all means, 

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

[Peter Lebbing]

On 23/11/15 08:54, Jan Suhr wrote:
> 2nd factors are usually not access protected at all e.g. may have a
> display (which allows funny hacks[1]). 

Ah, that makes sense! I forgot about that because I myself would
actually like an OTP protected by PIN as complete two-factor solution
(have the device, know the PIN). But that is an uncommon scenario.

> We introduced PIN-protection of
> OTPs as an optional feature because we don't have a physical button.

Can I suggest you document this well so people know the limitations of
the functionality? As a part of that, I'm sure you are aware a physical
button is out-of-band (a remote attacker can't press it), but a remote
attacker can send a PIN to the smartcard.

>> Hardware:
>> NK-02-006 Micro SD and Smartcard Slots lack ejection switch (High)
> 
> An ejection switch doesn't make any sense to me. Note that ejection
> switch could only be triggered if a card is ejected while the device is
> powered.
> Furthermore any pupil would be able to use a soldering iron to
> circumvent an ejection switch.

I read this part of the pentest document as a bundle complete with a
supercap to keep the power applied when unplugged and the part where
there is tamper detection. All three together make sense, the tamper
detection beating the pupil[1].

But the odd thing there is that the ejection switch is rated high
importance, but the others medium.

Thanks for your explanation!

Peter.

[1] With his own soldering iron, if need be ;P.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

[NdK]

Il 23/11/2015 08:56, Jan Suhr ha scritto:

>> I didn't look at the code (so this could be completely wrong and I'd be
>> happy!), but if the OTP key is decrypted using a key in the chip after
>> verifying that the card accepts the PIN, then it's even worse, since
>> that master key is in cleartext somewhere outside the smartcard. So,
>> with some efforts and a good lab the OTP keys can be extracted.
> The key is stored in the card.
Then, replacing the card replaces the OTP key. No?

BYtE,
 Diego

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Crowdfunding USB Security Key for Email- and Data-Encryption - Nitrokey Storage

[Jan Suhr]

Hi Diego,

Am 23.11.2015 um 09:42 schrieb NdK:
> Il 23/11/2015 08:56, Jan Suhr ha scritto:
> 
>>> I didn't look at the code (so this could be completely wrong and I'd be
>>> happy!), but if the OTP key is decrypted using a key in the chip after
>>> verifying that the card accepts the PIN, then it's even worse, since
>>> that master key is in cleartext somewhere outside the smartcard. So,
>>> with some efforts and a good lab the OTP keys can be extracted.
>> The key is stored in the card.
> Then, replacing the card replaces the OTP key. No?

If the optional PIN protection for OTPs is enabled, replacing the smart
card would render the OTPs inaccessible.

Regards,
Jan

> BYtE,
>  Diego
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
Jan Suhr

Nitrokey UG (haftungsbeschränkt)
Web: https://www.nitrokey.com

Email: j...@nitrokey.com
Phone: +49 163 7010 408

Berliner Str. 166, 10715 Berlin, Germany
CEO / Geschäftsführer: Jan Suhr
Register Record: AG Charlottenburg, HRB 164549 B
VAT ID / USt-IdNr.: DE300136599

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[James]

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, tinkered
with GPG for many hours and poured over the documentation (again). I
still have a few questions:

- 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?
- I'm also curious why the default-preference-list isn't set to
something more secure, as suggested here[1]:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
CAST5 ZLIB BZIP2 ZIP Uncompressed

To be perfectly clear, I am sure the folks who made the decision to
choose SHA256 is _far_ more intelligent than I am and there is sound
reason behind these default choices. I simply would like to better
understand these design decisions.

I'm also looking for some clarification around the primary key. Out of
the box it appears that GPG will create a private key for signing and
certification. Some documentation around the web indicates that the
primary key can be stripped of all capabilities, leaving _only_
certify. What are the pros and cons of allowing the private key only
to certify, then creating a subkey to sign (and another to encrypt)?

To go a bit further down that rabbit hole, let's say I want to create
a primary key (with certify-only capabilities), several subkeys and
then remove the private key (as has been discussed ad nauseam in this
thread); it appears that stripping the capabilities of the primary key
to the bare minimum (i.e., no signing, no encrypting, no
authenticating) would be "safer," no?

My concern is that if my primary key is for certification only, how
would it sign other people's certificates to expand the web of trust?
I suspect that if the capabilities are set to _only_ certify, I would
need to sign other people's keys using my subkey. How would this
affect the notion of "even if you lose your subkeys, your identity and
web of trust are not impacted as long as your primary key is not
compromised?"

Seems to me that the primary key /should/ have both certify and sign
capabilities to really be useful, no?

Any thoughts and ideas regarding these questions is greatly appreciated.

James

1 https://help.riseup.net/en/security/message-security/openpgp/best-practices

On Wed, Nov 18, 2015 at 7:35 PM, da...@gbenet.com  wrote:
> On 18/11/15 12:08, Peter Lebbing wrote:
>> 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.
>>
>> HTH,
>>
>> Peter.
>>
>> [1] https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html
>>
>
> Peter,
>
> When you think about it - if a person stole your laptop with your private and 
> public key on
> it - they still could not use your private key to do anything. Security is in 
> the passphrase
> one sets to use your key. Without it your buggered and so is anyone who has 
> acquired your
> private and public key. They could spend a great deal of time and money - but 
> essentially a
> good passphrase is secure. Brute force - beating the shit out of you - may 
> work - the human
> link is the weakest in the chain.
>
> There is no perfect key - they are all "perfect" their security depends on 
> your passphrase.
>
> Be Happy
>
> David
> --
> “See the sanity of the man! No gods, no angels, no demons, no body. Nothing 
> of the
> kind.Stern, sane,every brain-cell perfect and complete even at the moment of 
> death. No
> delusion.” https://linuxcounter.net/user/512854.html - http://gbenet.com
>

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: scdaemon lockup with Yubikey NEO

[the2nd]

Hi,

i've done some more testing and found out that the problem starts to 
exist with openssh version 6.8p1. With 6.7p1 everything works perfect. I 
downloaded the openssh tarballs one by one, compiled with 
./configure;make and just copied the "ssh" binary.


I was able to reproduce the problem with the following steps:

1. Start gpg-agent: eval $(gpg-agent --daemon --enable-ssh-support 
--log-file ~/.gnupg/gpg-agent.log)
2. Login to any host with your SSH key and keep the session open: ssh -l 
root localhost

3. Plug your yubikey out/in
4. Try to login with your SSH key to any other host

With openssh 6.8p1 this fails reproducable. With version 6.7p1 or 
earlier it works.


As a workaround i replaced my ssh client binary with the old version.

It would be great to get a real fix for this. But i am unsure where the 
realm problem lies, gpg or openssh.


Maybe we should ask this on the openssh list?

regards
the2nd


On 2015-11-22 03:06, Lance R. Vick wrote:

This happens to me constantly as well. I my case I frequently need to
kill and restart gpg-agent to get things working again on both Arch
Linux and Gentoo.

On Sat, Nov 21, 2015 at 4:41 AM, the2nd  wrote:


Hi Ben,

We have a similar Problem since we've upgraded from Ubuntu 15.04 to
15.10.  When starting gpg-agent with --log-file the log show the
following:

2015-05-30 13:49:36 gpg-agent[3600] error accessing card:
Conflicting use
2015-05-30 13:49:36 gpg-agent[3600] smartcard signing failed: 
Conflicting use 
2015-05-30 13:49:38 gpg-agent[3600] error getting
default authentication keyID of card: Conflicting use

I've asked the list serval times about this issue but got now answer
yet. So i dont have a solution but it may be interesting if your
problem is the same...

Regards
The2nd 

 Ursprüngliche Nachricht 
Von: Ben Warren
Datum:11.20.2015 16:26 (GMT+01:00)
An: gnupg-users@gnupg.org
Betreff: scdaemon lockup with Yubikey NEO

Hi,

I’ve noticed several other problem reports that seem similar,
hopefully they’re all related and there’s a simple fix.

The problem:

After an indeterminate amount of time (sometimes minutes, sometimes
hours), any GPG operation that uses my Yubikey NEO device hangs. 
The two most common operations are SSH authentication and git
signing.  The following sequence gets things going again:

$ killall -SIGKILL scdaemon

$ gpg2 —card-status

System particulars:

* Host OS is OS-X Yosemite, although it is also present on
Mavericks (haven’t tried El Capitan yet)

* GPG 2.1.5

* Using the Yubikey’s authentication subkey to login to remote
Linux hosts

* Using the Yubikey’s signing subkey for git signing operations,
both local and remote

* Using gpg-agent for forwarding both GPG and SSH (great features,
BTW!)

GPG configuration file:

$ cat ~/.gnupg/gpg-agent.conf

default-cache-ttl 1

ignore-cache-for-signing

no-allow-external-cache

max-cache-ttl 1

extra-socket ${HOME}/.gnupg/S.gpg-extra-agent

debug-all

log-file ${HOME}/.gnupg/mygpglogfile.log

enable-ssh-support

I’ll be happy to help debug this, but need some guidance.

thanks,

Ben
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users [1]


--

Lance R. Vick
__
Cell      -  407.283.7596
Gtalk     -  la...@lrvick.net
Website   -  http://lrvick.net [2]
PGP Key   -  http://lrvick.net/0x36C8AAA9.asc [3]
keyserver -  subkeys.pgp.net [4]
__

Links:
--
[1] http://lists.gnupg.org/mailman/listinfo/gnupg-users
[2] http://lrvick.net
[3] http://lrvick.net/0x36C8AAA9.asc
[4] http://subkeys.pgp.net


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[James]

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 curiosity to understand the various knobs and
gears that can be tweaked. Said deep understanding also puts me in a
position whereby I can more easily deal with various issues or
complexities down the line.

The same can be said for almost any complex system, software or not.

It seems to me that, perhaps, making these sorts of decisions up front
is of some value. 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).

It's also worth noting that the suggestion to remove the primary key
from your laptop isn't thrown up on a few random blogs; instead it is
something that other projects[1] encourage.

If one's primary key is his or her identity, I'd like to be certain
that I correctly create the key(s). Thus being meticulous and careful
in creating primary key seems like a reasonable step, IMHO.

Finally, I do appreciate the list of things that I should focus on --
there are several I had not contemplated and will now do so.

James

https://wiki.debian.org/Subkeys

On Mon, Nov 23, 2015 at 10:52 AM, Robert J. Hansen  wrote:
>> - 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 the same as better.  At
> some point there's such a thing as enough.
>
> SHA-256 is (a) safe enough for essentially all purposes, (b) more
> interoperable with other OpenPGP implementations, and (c) better for
> human readability.
>
>> I'm also looking for some clarification around the primary key. Out of
>> the box it appears that GPG will create a private key for signing and
>> certification. Some documentation around the web indicates that the
>> primary key can be stripped of all capabilities, leaving _only_
>> certify. What are the pros and cons of allowing the private key only
>> to certify, then creating a subkey to sign (and another to encrypt)?
>
> I'm going to repeat my earlier advice: learn to walk before you run.
> The defaults are safe.  Use them.  We can have this conversation at
> great length, but I don't want to encourage you to start doing this.
> Quite the opposite.  Please don't.
>
>> thread); it appears that stripping the capabilities of the primary key
>> to the bare minimum (i.e., no signing, no encrypting, no
>> authenticating) would be "safer," no?
>
> The last word in your sentence is the answer.
>
> It's not safer.  You're talking about making a bank vault door "safer"
> by adding a single millimeter of armor plate.  Your attention is better
> spent elsewhere, especially right now when you're just starting out.
> Focusing on the technical components of the system is ... I hate to say
> "you're doing it wrong," but IMO, you are.  The stuff you're paying
> attention to right now is pretty much irrelevant and unimportant.  The
> stuff you're ignoring is relevant and important.  Start focusing on
> that.  I'd start with:
>
> * Do you have a revocation certificate generated?
> * Is it stored safely?
> * Who has access to your revocation certificate and/or private key?
> * How would you know if someone else had access?
> * How strong is your passphrase?
> * How do you know how strong it is?
> * What will you do if you forget your passphrase -- what's your
>   fallback?
> * If you revoke your certificate, how will you rebuild your personal
>   web of trust?
> * Is GnuPG integrated into your email workflow?  If not, how can it
>   be integrated?
> * Have you considered storing your certificate on a smartcard?
>
> These are the places where GnuPG fails in the real world.  In 20+ years
> of using PGP 2.6+ and GnuPG 1.0+, I've never -- not once, not ever --
> encountered anyone who has said, "man, I really wish I'd stripped my
> certificate, that would've saved me no end of grief," and a lot of
> people who have said, "man, I really wish I'd safely stored a revocation
> certificate, that would've saved me no end of grief."
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Robert J. Hansen]

> 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 meandering, but if you'll bear with me for two
paragraphs it'll make sense:

I live in the United States, in a state which allows private citizens,
under incredibly close regulation, to own military firearms.  When I
visit the rifle range, sometimes I'll spend some time with a suppressed
German-made MP5SD3 submachinegun.  (It's not mine: a friend owns one and
we sometimes hit the range together.)  It's a nice piece of kit; I like
it.  And quite often, other people who are at the range want to talk
shop about it.  We get into discussions about roller-locked firearms
like the Cz52 and MG42 versus roller-delayed firearms like the MP5, how
annoying it is when people get the terminology wrong, whether it's a
good thing or a bad thing the MP5 uses a fluted chamber, how anyone who
thinks it's okay to fire subsonic 9mm from the MP5 needs their head
examined, and so on and so on.  And it's fun, as far as it goes, and
it's often educational for the people who've never seen an MP5 before
and are fascinated to learn more about its inner workings.

It's great -- up until they think they know enough to use an MP5 on the
range, despite the fact they've never fired a weapon before.  At that
point we have to explain to them that look, yes, they know a lot more
about the MP5 than most people do, but really, they need to start off
with something small, like a nice .22 Ruger Mk II, develop the basic
skills, learn trigger discipline and proper usage of safeties, learn how
the range operates and what the various calls by the Range Safety
Officers mean, etcetera.  There's a huge amount to learn: they don't
need to make things worse by leaping straight over this stuff straight
to firing fully-automatic military hardware.  That's just imprudent, and
we'd be awful human beings if we permitted them to do that.

That's what we're talking about here.  The knobs and dials on GnuPG are
great fun to learn about: you're in good company!  But there's a big
reason why we're urging you to not do what you want to do, and that's
because you're not yet competent to do what you want to do.  We'd rather
see you start off with small steps, and from there move on to the big
ones, than have you start off big.

Admittedly, it's highly unlikely that screwing up with GnuPG will lead
to a magazine of 9mm being sprayed around the room.  But it's the
principle of the thing.  :)

So: for now, please stick with the defaults.

> It seems to me that, perhaps, making these sorts of decisions up front
> is of some value.

Not really.  It's probably not worth worrying about.

> 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.

No.

One of the important skills to learn early on is about how to migrate a
certificate.  You're going to make mistakes.  You'll forget passphrases,
you'll compromise your keys, you'll realize you made a hash of it and
need to start over again.  How do you recover from this?  How do you
communicate a change-of-certificate with your correspondents?  Etc.

The only reason to think "it's a bit too late" is if

a) you're not allowed to change your certificate -- you
   *must* keep the same one for the next X years
b) you don't know how to migrate to a new certificate

There are almost certainly people and groups for whom (a) applies.  If
you're one of them, please let me know.  But if (b) applies, then I
suggest learning the skill, because it's important.  :)

> It's also worth noting that the suggestion to remove the primary key
> from your laptop isn't thrown up on a few random blogs; instead it is
> something that other projects[1] encourage.

That wiki page is guidance *for Debian*.  Debian has some very specific
operating restrictions which are unlikely to apply to you.  The
guidelines Debian put together apply to them, in their environment,
facing their threat model, which they defend with their particular set
of resources.

It is not guidance for you, unless you're part of Debian.

By all means, study it!  It's a well-written policy.  Learn what goes
into their policy and why they make the decisions they do.  But don't
think that what they recommend will automatically apply to you.  Some of
it will be applicable; a lot of it won't be.

> If one's primary key is his or her identity, I'd like to be certain
> that I correctly create the key(s).

Yes.  And, as several people here have told you, you correctly create it
by running "gpg --gen-key" and accepting the defaults.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Peter Lebbing]

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 detail:

Separating encryption from signing is a general advice (and done by
default) because there is a range of subtleties that are avoided by this
simple action. This affects how your keys are actually *used*, not *usable*.

However, one who has access to the private part of the primary key can
easily change the capabilities of the primary key to add signing as a
capability, even if you had it removed. There is not enough reason to
separate certifications from data signatures to make it the default.
Whether there is reason at all from a cryptographic standpoint, I do not
know. But it is certainly nothing to be worried about, or it would have
been dealt with in the defaults.

Also, let me quote and answer a part from an earlier mail you wrote:

> My concern is that if my primary key is for certification only, how
> would it sign other people's certificates to expand the web of trust?
> I suspect that if the capabilities are set to _only_ certify, I would
> need to sign other people's keys using my subkey.

No, signing other people's keys is known as certification, and is
something that can *only* be done by the primary key. If you have an
offline primary key, you would use an offline system that has the secret
part available to sign other people's keys, and then transfer the
signature from that offline system.

Or if you only delete the primary key from your laptop but still have it
on your desktop, you'd use the latter. For that setup, you could create
a signing subkey for your laptop to use without removing signing
capability from your primary key.

> It's also worth noting that the suggestion to remove the primary key
> from your laptop isn't thrown up on a few random blogs; instead it is
> something that other projects[1] encourage.

Yes, well, most importantly, maybe their threat model is different. In
this specific case, note that a signature by a Debian developer means
that, by and large, any Debian machine on the planet will trust the
software update that that signature validates and install it on the next
system upgrade. That's quite an important signature.

Normally, a Debian dev can only upload source code, not binaries, but
it's still a significant amount of power.

> If one's primary key is his or her identity, I'd like to be certain
> that I correctly create the key(s). Thus being meticulous and careful
> in creating primary key seems like a reasonable step, IMHO.

Yes, but the defaults are sane, so there's no need to fiddle with things
that are different from the defaults. It's all the other stuff you
should be meticulous about.

Furthermore, all is not lost if you wish to swap your primary key. Many
people will accept a transition statement and issue a signature on your
new key. Also; the Web of Trust is overrated, and you can probably
persuade your friends more easily to recertify.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Robert J. Hansen]

> - 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 the same as better.  At
some point there's such a thing as enough.

SHA-256 is (a) safe enough for essentially all purposes, (b) more
interoperable with other OpenPGP implementations, and (c) better for
human readability.

> I'm also looking for some clarification around the primary key. Out of
> the box it appears that GPG will create a private key for signing and
> certification. Some documentation around the web indicates that the
> primary key can be stripped of all capabilities, leaving _only_
> certify. What are the pros and cons of allowing the private key only
> to certify, then creating a subkey to sign (and another to encrypt)?

I'm going to repeat my earlier advice: learn to walk before you run.
The defaults are safe.  Use them.  We can have this conversation at
great length, but I don't want to encourage you to start doing this.
Quite the opposite.  Please don't.

> thread); it appears that stripping the capabilities of the primary key
> to the bare minimum (i.e., no signing, no encrypting, no
> authenticating) would be "safer," no?

The last word in your sentence is the answer.

It's not safer.  You're talking about making a bank vault door "safer"
by adding a single millimeter of armor plate.  Your attention is better
spent elsewhere, especially right now when you're just starting out.
Focusing on the technical components of the system is ... I hate to say
"you're doing it wrong," but IMO, you are.  The stuff you're paying
attention to right now is pretty much irrelevant and unimportant.  The
stuff you're ignoring is relevant and important.  Start focusing on
that.  I'd start with:

* Do you have a revocation certificate generated?
* Is it stored safely?
* Who has access to your revocation certificate and/or private key?
* How would you know if someone else had access?
* How strong is your passphrase?
* How do you know how strong it is?
* What will you do if you forget your passphrase -- what's your
  fallback?
* If you revoke your certificate, how will you rebuild your personal
  web of trust?
* Is GnuPG integrated into your email workflow?  If not, how can it
  be integrated?
* Have you considered storing your certificate on a smartcard?

These are the places where GnuPG fails in the real world.  In 20+ years
of using PGP 2.6+ and GnuPG 1.0+, I've never -- not once, not ever --
encountered anyone who has said, "man, I really wish I'd stripped my
certificate, that would've saved me no end of grief," and a lot of
people who have said, "man, I really wish I'd safely stored a revocation
certificate, that would've saved me no end of grief."


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: best practices for creating keys

[Benjamin Black]

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 time.

If someone is really motivated to invade your privacy, they are not going
to attack crypto, they are going to do an end-run around it by attacking
the rest of the system.  The choice of key size has never been the weak
point: it doesn't matter what size key you use if there is a key logger
installed on your system.

Watch this excellent presentation by Peter Gutmann about this subject at
Linux.conf.au 2015:
https://www.youtube.com/watch?v=_ahcUuNO4so


On Mon, Nov 23, 2015 at 9:25 AM James  wrote:

> 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, tinkered
> with GPG for many hours and poured over the documentation (again). I
> still have a few questions:
>
> - 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?
> - I'm also curious why the default-preference-list isn't set to
> something more secure, as suggested here[1]:
>
> default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
> CAST5 ZLIB BZIP2 ZIP Uncompressed
>
> To be perfectly clear, I am sure the folks who made the decision to
> choose SHA256 is _far_ more intelligent than I am and there is sound
> reason behind these default choices. I simply would like to better
> understand these design decisions.
>
> I'm also looking for some clarification around the primary key. Out of
> the box it appears that GPG will create a private key for signing and
> certification. Some documentation around the web indicates that the
> primary key can be stripped of all capabilities, leaving _only_
> certify. What are the pros and cons of allowing the private key only
> to certify, then creating a subkey to sign (and another to encrypt)?
>
> To go a bit further down that rabbit hole, let's say I want to create
> a primary key (with certify-only capabilities), several subkeys and
> then remove the private key (as has been discussed ad nauseam in this
> thread); it appears that stripping the capabilities of the primary key
> to the bare minimum (i.e., no signing, no encrypting, no
> authenticating) would be "safer," no?
>
> My concern is that if my primary key is for certification only, how
> would it sign other people's certificates to expand the web of trust?
> I suspect that if the capabilities are set to _only_ certify, I would
> need to sign other people's keys using my subkey. How would this
> affect the notion of "even if you lose your subkeys, your identity and
> web of trust are not impacted as long as your primary key is not
> compromised?"
>
> Seems to me that the primary key /should/ have both certify and sign
> capabilities to really be useful, no?
>
> Any thoughts and ideas regarding these questions is greatly appreciated.
>
> James
>
> 1
> https://help.riseup.net/en/security/message-security/openpgp/best-practices
>
> On Wed, Nov 18, 2015 at 7:35 PM, da...@gbenet.com 
> wrote:
> > On 18/11/15 12:08, Peter Lebbing wrote:
> >> 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.
> >>
> >> HTH,
> >>
> >> Peter.
> >>
> >> [1]
> https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html
> >>
> >
> > Peter,
> >
> > When you think about it - if a person stole your laptop with your
> private and public key on
> > it - they still could not use your private key to do anything. Security
> is in the passphrase
> > one sets to use your key. Without it your buggered and so is anyone who
> has acquired your
> > private and public key. They could spend a great deal of time and money
> - but essentially a
> > good passphrase is secure. Brute force - beating the shit out of you -
> may work - the human
> > link is the weakest in the chain.
> >
> > There is no perfect key - they are all "perfect" their security depends
> on your passphrase.
> >
> > Be Happy
> >
> > David
> > --
> > “See the sanity of the man! No gods, no angels, no demons, no body.
> Nothing of the
> > kind.Stern, sane,every brain-cell perfect and complete even at the
> moment of death. No
> > delusion.” https://linuxcounter.net/user/512854.html - http://gbenet.com
> >
>
>