Re: wanted: educate us please on key dongles

[Christian Seiler]

On 08/30/2017 01:52 PM, Christian Seiler wrote:
> Am 2017-08-30 09:01, schrieb Marc Haber:
>> And I hope that it's really hard to fuck up here and to send private
>> keys to the keyserver.
> 
> I don't think that's possible with GnuPG command line, as far as
> I know GnuPG will only ever send public keys to the keyservers.

While GnuPG won't send your private key to the keyservers when 
using the automatic mechanism, if you export your key manually
in order to post it somewhere public, say a blog, you should
really take care to _only_ export the public key...

https://twitter.com/jupenur/status/911286403434246144

Regards,
Christian

Re: [summary] Re: wanted: educate us please on key dongles

[Charles Plessy]

Le Sat, Sep 09, 2017 at 08:09:00PM +, Sotirios Vrachas a écrit :
> >  - https://wiki.debian.org/GnuPG/StubKe
> This page does not exist.
> 

Sorry, it was .

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Re: [summary] Re: wanted: educate us please on key dongles

[Sotirios Vrachas]

>  - https://wiki.debian.org/GnuPG/StubKe
This page does not exist.



signature.asc
Description: OpenPGP digital signature

[summary] Re: wanted: educate us please on key dongles

[Charles Plessy]

Hello everybody,

that thread was very interesting, and I tried to input in
wiki.debian.org the information that seemed to not be covered
yet.  Most of the input went in two new pages:

 - https://wiki.debian.org/OfflineMasterKey
 - https://wiki.debian.org/GnuPG/StubKe

I did my best to preserve attribution by relating each edit
to one email in the thread, for instance:

 - https://wiki.debian.org/OfflineMasterKey?action=info

I hope you will find them useful.  Due to their cut-n-paste nature, they
are still is quite draftish, and I will not mind if somebody extensively
reworks or relocates them, etc.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Re: wanted: educate us please on key dongles

[Sean Whitton]

Hello,

On Wed, Aug 30 2017, Marc Haber wrote:

> People keep mentioning to store the private key on a LUKS-encrypted
> device. Why? Is the private key encryption that happens inside GnuPG
> itself when you protect your private key with a passphrase not
> sufficient?

You can pass the --iter-time option when creating a LUKS partition that
makes a brute force take much longer (at the cost of it taking slightly
longer to decrypt and mount the partition).

You can't do that with the encryption gpg does with your passphrase,
AFAIK.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: wanted: educate us please on key dongles

[Alexander Zangerl]

On Wed, 30 Aug 2017 10:09:38 +0100, Jonathan McDowell writes:
>I think NIIBE was selling them for about €30 at DebConf, so that's a
>reasonable mark up. He said Seeed are currently changing business model
>to move away from low volume devices, but despite what their website
>says they do still have some in stock.

i emailed seeed last week and they said 'not in stock, and no plans
for restocking'.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Everyone gives lip service to that 7 layer model but that fact is that the 
only thing that has ever been truly OSI 7 layer compliant is the  
Taco Bell 7 Layer Burrito. -- Kent "Dogman" Dahlgren


signature.asc
Description: Digital Signature

Re: wanted: educate us please on key dongles

[Ian Campbell]

On Wed, 2017-08-30 at 12:50 +0200, Marc Haber wrote:
> That's a point, but I cannot validate whether the free hardware
> design running the free software crypto app isn't backdoored anyway due
> to lack of knowledge and expertise.

Some large fraction of the world could/would make the same argument
about Open Source software too, since they have little to no
programming skills or knowledge.

Apart from the good (better than I'm about to make IMHO) points Ian J
made it is also the case that if you have the hw design (or source
code) then you have the _opportunity_ to acquire the
knowledge/expertise the interpret/check/extend/fix/break them if you
want, either by unlocking those achievements yourself or (if you have
the means to trade money in lieu of your time learning something you
may not be inherently interested in) by employing someone who already
has them (or multiple independent someones if you are both a bit
paranoid and rather flush with cash...). You don't get that opportunity
with closed hardware (or software).

Ian.

Re: wanted: educate us please on key dongles

[Christian Seiler]

Am 2017-08-30 14:45, schrieb Marc Haber:

On Wed, Aug 30, 2017 at 01:52:54PM +0200, Christian Seiler wrote:

Well, you could create a completely separate key pair (with a separate
master key) for Debian purposes only.


That would double the effort of obtaining signatures and also double 
the

burden on my signers. Doesnt scale.


Meh. It's not uncommon for people to have multiple keys that they
ask signatures for during keysigning parties. But yeah, that this
is more work is the obvious downside of this approach.


> People keep mentioning to store the private key on a LUKS-encrypted
> device. Why? Is the private key encryption that happens inside GnuPG
> itself when you protect your private key with a passphrase not
> sufficient?

Defense in depth. First of all, it's not immediately clear that the
media I keep my private key on is actually the one that contains my
private key (_all_ external media I have at home is LUKS encrypted,
except for a couple of USB sticks I use to share data with other
people),


That sounds like security-by-obscurity.


To be fair: I encrypt all of my external media out of principle
anyway, I didn't just do this for my GPG key.

Furthermore, security by obscurity is rightfully frowned upon
because many people use it as their _only_ security strategy. But
here it's just use as an additional barrier to something that
actually has actual security properties.


However, you _could_ achieve that if you export the private key
manually and accidentally upload that via the web interface that
some keyservers provide. ;-) They'll probably reject the upload
(because it's not a public key), but who knows where that'll be
logged...


yes, but that's truely advanced stupidity. I hope that I am not capable
of that.


I didn't mean to imply that you were. ;-)

I was just saying that's kind of the only kind of scenario I could
come up with where someone could indeed upload a private key to a
keyserver by accident.

Regards,
Christian

Re: wanted: educate us please on key dongles

[Marc Haber]

Ian,

thanks for your level-headed response and your solid reasoning.

On Wed, Aug 30, 2017 at 12:10:34PM +0100, Ian Jackson wrote:
> How far down the paranoia road you want to go is up to you, but buying
> an open hardware / libre firmware security device, rather than a
> proprietary one, has relatively few downsides (esp. compared to other
> things you might do to reduce your risks).
> 
> Also of course buying a libre device has other wider benefits.

Otoh, the GnuK is rather bulky when it's compared with one of the
commercial devices, and it's unlikely to survive being on my keychain
for a reasonable time due to its fragility.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: wanted: educate us please on key dongles

[Marc Haber]

On Wed, Aug 30, 2017 at 01:52:54PM +0200, Christian Seiler wrote:
> Am 2017-08-30 09:01, schrieb Marc Haber:
> > On Tue, Aug 29, 2017 at 04:07:45PM -0300, Henrique de Moraes Holschuh
> > wrote:
> > > The **public** portion of *every* key (master and all subkeys) go into
> > > the public keyrings and also in the Debian keyring.  gnupg will handle
> > > this automatically if you use "--export" (do *NOT* confuse with a
> > > different export option that is for private keys).
> > 
> > So it is probably a bad idea / impossible (?) to have a dedicated
> > signing-only key used for Debian that guared more closely than the
> > "regular every-day" key?
> 
> Well, you could create a completely separate key pair (with a separate
> master key) for Debian purposes only.

That would double the effort of obtaining signatures and also double the
burden on my signers. Doesnt scale.

> > People keep mentioning to store the private key on a LUKS-encrypted
> > device. Why? Is the private key encryption that happens inside GnuPG
> > itself when you protect your private key with a passphrase not
> > sufficient?
> 
> Defense in depth. First of all, it's not immediately clear that the
> media I keep my private key on is actually the one that contains my
> private key (_all_ external media I have at home is LUKS encrypted,
> except for a couple of USB sticks I use to share data with other
> people),

That sounds like security-by-obscurity.

>and secondly I use a different passphrase for LUKS as
> compared to the private key.

That, of course, goes without saying.

> Basically, it's an added level of paranoia.

Usually I am the one who is paranoid, that's why I asked.

> However, you _could_ achieve that if you export the private key
> manually and accidentally upload that via the web interface that
> some keyservers provide. ;-) They'll probably reject the upload
> (because it's not a public key), but who knows where that'll be
> logged...

yes, but that's truely advanced stupidity. I hope that I am not capable
of that.

> To be fair: SSH's naming convention for files is not the easiest
> to understand for new users. Using ${filename} for the private key
> and ${filename}.pub for the public key does not make it obvious
> that they need to keep ${filename} private. Had they used
> ${filename}.secret for the private key this might have reduced
> such occurrences.

agreed.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: wanted: educate us please on key dongles

[Teemu Likonen]

Marc Haber [2017-08-30 09:01:09+02] wrote:

> People keep mentioning to store the private key on a LUKS-encrypted
> device. Why? Is the private key encryption that happens inside GnuPG
> itself when you protect your private key with a passphrase not
> sufficient?

A strong passphrase for the key itself is sufficient. Obviously an
encrypted partition adds one more layer and have other benefits like
hiding the content.

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Re: wanted: educate us please on key dongles

[Christian Seiler]

Am 2017-08-30 09:01, schrieb Marc Haber:
On Tue, Aug 29, 2017 at 04:07:45PM -0300, Henrique de Moraes Holschuh 
wrote:

The **public** portion of *every* key (master and all subkeys) go into
the public keyrings and also in the Debian keyring.  gnupg will handle
this automatically if you use "--export" (do *NOT* confuse with a
different export option that is for private keys).


So it is probably a bad idea / impossible (?) to have a dedicated
signing-only key used for Debian that guared more closely than the
"regular every-day" key?


Well, you could create a completely separate key pair (with a separate
master key) for Debian purposes only.


People keep mentioning to store the private key on a LUKS-encrypted
device. Why? Is the private key encryption that happens inside GnuPG
itself when you protect your private key with a passphrase not
sufficient?


Defense in depth. First of all, it's not immediately clear that the
media I keep my private key on is actually the one that contains my
private key (_all_ external media I have at home is LUKS encrypted,
except for a couple of USB sticks I use to share data with other
people), and secondly I use a different passphrase for LUKS as
compared to the private key. (The tricky thing here is making sure
you don't forget the second passphrase, otherwise you're screwed.)

Basically, it's an added level of paranoia.


Only the public keys (all of them: master and subkeys).  gnupg will
handle this automatically if you use --send-key.


And I hope that it's really hard to fuck up here and to send private
keys to the keyserver.


I don't think that's possible with GnuPG command line, as far as
I know GnuPG will only ever send public keys to the keyservers.

However, you _could_ achieve that if you export the private key
manually and accidentally upload that via the web interface that
some keyservers provide. ;-) They'll probably reject the upload
(because it's not a public key), but who knows where that'll be
logged...


I have had people send me the private parts of their ssh keys...


To be fair: SSH's naming convention for files is not the easiest
to understand for new users. Using ${filename} for the private key
and ${filename}.pub for the public key does not make it obvious
that they need to keep ${filename} private. Had they used
${filename}.secret for the private key this might have reduced
such occurrences.

Regards,
Christian

Re: wanted: educate us please on key dongles

[Marc Haber]

I seem to have offended people by trying to make up my mind and
introducing arguments into the discussion that might not be wanted. I
can only lose by continuing this thread. No offense was ever intended,
and neither was an attack.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: wanted: educate us please on key dongles

[Jonathan McDowell]

On Wed, Aug 30, 2017 at 12:50:53PM +0200, Marc Haber wrote:
> On Wed, Aug 30, 2017 at 12:42:13PM +0200, Adam Borowski wrote:
> > * with Yubikey 4 (suspected): they send the secret handshake, get a
> > copy of the key, and you don't even know anything happened
> 
> That's a point, but I cannot validate whether the free hardware design
> running the free software crypto app isn't backdoored anyway due to
> lack of knowledge and expertise.

If you're not interested in anything where you're not able to do all of
the validation yourself, why are you asking us for advice only to then
say you don't see the point of the recommendations given?

At the risk of trying to teach my grandmother to suck eggs, the
advantage of an open hardware + software design is that even if you
yourself are unable to fully validate the security of the device there
is the opportunity for others to do so and share their findings.

(I do not claim to have done any security investigation of the GnuK
 code, but I have successfully built and installed it using only tools
 available in Debian.)

J.

-- 
/-\ | No thanks, I'm already having one.
|@/  Debian GNU/Linux Developer |
\-  |

Re: wanted: educate us please on key dongles

[Ian Jackson]

Marc Haber writes ("Re: wanted: educate us please on key dongles"):
> That's a point, but I cannot validate whether the free hardware
> design running the free software crypto app isn't backdoored anyway due
> to lack of knowledge and expertise.

You don't need to be able to validate it personally.  The thing spooks
most hate is discovery.  Backdooring supposedly-free hardware is
harder (more costly) because it comes with greater risk of discovery.

To put it concretely: if they backdoor all of them, someone (not
necessarily you) might notice.  (Backdooring only yours involves
messing with the shipping arrangements and so on, and supposes that
you specifically are of interest.)

That's not to say it's perfect (nothing is, in security).  But
supposedly-free hardware is easier for anyone else to validate and/or
audit, and by that measure is less likely to be compromised.

How far down the paranoia road you want to go is up to you, but buying
an open hardware / libre firmware security device, rather than a
proprietary one, has relatively few downsides (esp. compared to other
things you might do to reduce your risks).

Also of course buying a libre device has other wider benefits.

Ian.

Re: wanted: educate us please on key dongles

[Marc Haber]

On Wed, Aug 30, 2017 at 12:42:13PM +0200, Adam Borowski wrote:
> On Wed, Aug 30, 2017 at 12:17:33PM +0200, Marc Haber wrote:
> > On Wed, Aug 30, 2017 at 10:09:38AM +0100, Jonathan McDowell wrote:
> > > The Start is based on the GnuK and I think should be upgradable to do 4K
> > > keys. The Pro uses a non-free smartcard internally for the RSA
> > > operations. I believe the Start should also be capable of ECC, as per
> > > the GnuK. It's possible Nitrokey haven't updated their firmware to
> > > support this yet.
> > 
> > I might be missing something, but I am wondering what a free hardware
> > design will help here. I am not in a position to validate it anyway, and
> > an USB token is unlikely to take any private data and phone it home.
> > What do I gain from using the GnuK over a yubi- or nitrokey other than
> > being able to say "yay, it's free"?
> 
> Assume you're passing a border, or otherwise have the token temporarily in
> hands of someone nasty.
> * with a non-backdoored token: there's no way to copy the key off the token,
>   the attacker may try their luck decapping, or try https://xkcd.com/538/
>   while keeping you in custody the whole time

In this usecase, the idea is the same for a free and a non-free token,
with the added fun of perps being too stupid to believe that the device
is indeed secure and continuing the torture of the human to make her
reveal the secret key.

> * with Yubikey 4 (suspected): they send the secret handshake, get a copy of
>   the key, and you don't even know anything happened

That's a point, but I cannot validate whether the free hardware
design running the free software crypto app isn't backdoored anyway due
to lack of knowledge and expertise.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: wanted: educate us please on key dongles

[Adam Borowski]

On Wed, Aug 30, 2017 at 12:17:33PM +0200, Marc Haber wrote:
> On Wed, Aug 30, 2017 at 10:09:38AM +0100, Jonathan McDowell wrote:
> > The Start is based on the GnuK and I think should be upgradable to do 4K
> > keys. The Pro uses a non-free smartcard internally for the RSA
> > operations. I believe the Start should also be capable of ECC, as per
> > the GnuK. It's possible Nitrokey haven't updated their firmware to
> > support this yet.
> 
> I might be missing something, but I am wondering what a free hardware
> design will help here. I am not in a position to validate it anyway, and
> an USB token is unlikely to take any private data and phone it home.
> What do I gain from using the GnuK over a yubi- or nitrokey other than
> being able to say "yay, it's free"?

Assume you're passing a border, or otherwise have the token temporarily in
hands of someone nasty.
* with a non-backdoored token: there's no way to copy the key off the token,
  the attacker may try their luck decapping, or try https://xkcd.com/538/
  while keeping you in custody the whole time
* with Yubikey 4 (suspected): they send the secret handshake, get a copy of
  the key, and you don't even know anything happened


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Re: wanted: educate us please on key dongles

[Marc Haber]

On Wed, Aug 30, 2017 at 10:09:38AM +0100, Jonathan McDowell wrote:
> On Tue, Aug 29, 2017 at 07:34:35PM +0200, Marc Haber wrote:
> > Their web page says that it will only suppor 2048 bit RSA keys, which is
> > the limitation of most USB crypto tokens on the market today. The
> > Nitrokey Pro will also do 3072 and 4096 bit, but it's considerably less
> > free?
> 
> The Start is based on the GnuK and I think should be upgradable to do 4K
> keys. The Pro uses a non-free smartcard internally for the RSA
> operations. I believe the Start should also be capable of ECC, as per
> the GnuK. It's possible Nitrokey haven't updated their firmware to
> support this yet.

I might be missing something, but I am wondering what a free hardware
design will help here. I am not in a position to validate it anyway, and
an USB token is unlikely to take any private data and phone it home.
What do I gain from using the GnuK over a yubi- or nitrokey other than
being able to say "yay, it's free"?

> > I have been postponing the offline master stuff for years because of
> > the hassle connected. Would it be a stupid idea to have one hardware
> > token for the Master key (generated on the device, never having left
> > it) and a second token for the everyday signing and encryption keys?
> > Can I have a master certification key on one device and subkeys on
> > another one? Can I also have this when the private parts of master and
> > sub keys have been generated on different devices?
> 
> Yes. I have a GnuK which holds my 0x21E278A66C28DBC0 master key, and
> then a separate device which has the 3 active subkeys (signing,
> encryption + authentication) for this key.

How do you back up the key? Was the 0x21E278A66C28DBC0 master key
created on the GnuK, or was it imported into the GnuK with a backup
somewhere?

What do I gain from having my certification master key on a GnuK or
other hardware token stored away in the safe over having the
certificatio master key with a nasty passphrase on a memory card in the
safe? The only issue that I see is that someone who gets access to my
safe can (a) copy the encrypted key without me noticing and (b) brute
force the passphrase of that copy with unlimited tries. Otoh, with a
hardware device, an attacker will have to steal the actual device since
he cannot make a copy, and the PIN will self-destruct after three tries,
making brute force impossible.

The price I pay for this added security is that I have to decide now
how many backups of the key I want to have since once the file version
of the key was deleted there is no more making copies of it, regardless
of how many devices I have it on, and that it would be impossible to
move to a different kind of device (smaller, more robust, faster)
without creating a new key. Those price is rather severe. What is an
acceptable trade-off between:

(1) only one copy of the key on one hardware device, with the key never
having left that device
(2) arbitrary copies of the key on hardware device with no readable copy
of the key left
(3) key on hardware device with a readable backup stored away in
$SAFE_PLACE


Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: wanted: educate us please on key dongles

[Jonathan McDowell]

On Tue, Aug 29, 2017 at 07:34:35PM +0200, Marc Haber wrote:
> On Fri, Aug 11, 2017 at 01:41:39PM +0100, Jonathan McDowell wrote:
> > * GnuK: My favourite choice. It's slow with RSA4096, but does
> >   support it. The hardware is open. The software is open (you can
> >   compile and flash it using tools available in main). Upstream is
> >   responsive (and a DD). However it's physically not quite as
> >   polished and there are availability issues.
> 
> Would that be this device:
> 
> https://www.amazon.de/Fst-Without-Enclosure-32-Bit-Computer/dp/B01IOYSIBG ?
> Is that a reasonable price?

I think NIIBE was selling them for about €30 at DebConf, so that's a
reasonable mark up. He said Seeed are currently changing business model
to move away from low volume devices, but despite what their website
says they do still have some in stock.

> > * Nitrokey Start: This is based on the GnuK (note their other
> >   devices are not) and seems like it might be a good alternative
> >   that is more physically robust will still being reasonably Free.
> >   I've not actually had my hands on one however so this is guesswork
> >   - but they do pop up on the GnuK dev list occasionally.
> 
> Their web page says that it will only suppor 2048 bit RSA keys, which is
> the limitation of most USB crypto tokens on the market today. The
> Nitrokey Pro will also do 3072 and 4096 bit, but it's considerably less
> free?

The Start is based on the GnuK and I think should be upgradable to do 4K
keys. The Pro uses a non-free smartcard internally for the RSA
operations. I believe the Start should also be capable of ECC, as per
the GnuK. It's possible Nitrokey haven't updated their firmware to
support this yet.

> > I appreciate this is not the "key dongles for dummies" asked for,
> > but hopefully it's more helpful than continued silence. I personally
> > would like us to get to the point where the "offline master" is our
> > base line for how contributors to Debian manage their key - it
> > provides a useful measure of extra security without the extra
> > expense that a USB token involves. That said a USB token is
> > definitely a better option.
> 
> I have been postponing the offline master stuff for years because of
> the hassle connected. Would it be a stupid idea to have one hardware
> token for the Master key (generated on the device, never having left
> it) and a second token for the everyday signing and encryption keys?
> Can I have a master certification key on one device and subkeys on
> another one? Can I also have this when the private parts of master and
> sub keys have been generated on different devices?

Yes. I have a GnuK which holds my 0x21E278A66C28DBC0 master key, and
then a separate device which has the 3 active subkeys (signing,
encryption + authentication) for this key.

J.

-- 
   101 things you can't have too   |  .''`.  Debian GNU/Linux Developer
   much of : 25 - email.   | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Re: wanted: educate us please on key dongles

[Marc Haber]

On Tue, Aug 29, 2017 at 04:07:45PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 29 Aug 2017, Marc Haber wrote:
> > - Which key goes on the paper slab that everybody uses to collect
> >   signatures? The certification only master key?
> 
> The main key fingerprint.  Which happens to be the certification master
> key in gnupg, yes.

Understood.

> > - For which (set of) keys should I have revocation certificates on file?
> 
> You need to have a revocation certificate for the master key.  When you
> revoke it, you revoke every subkey as well.  Also, as long as you keep
> control of the master key, you can revoke any subkey.

Understood. I didn't find that information in all clearness anywhere.

> It goes without saying that losing control of your revocation
> certificate can open you to a DoS attack, so please keep it protected
> somehow, but NOT in a way you might find yourself unable to use it.

Of course.

> > - What key goes into the Debian keyring? A signing (only?) subkey of the
> >   certification master key? Is it recommended to have this key
> >   "available", for example in a Gnuk on my keychain next to the key to
> >   my home?
> 
> The **public** portion of *every* key (master and all subkeys) go into
> the public keyrings and also in the Debian keyring.  gnupg will handle
> this automatically if you use "--export" (do *NOT* confuse with a
> different export option that is for private keys).

So it is probably a bad idea / impossible (?) to have a dedicated
signing-only key used for Debian that guared more closely than the
"regular every-day" key?

> In the "normal use" smartcard, you store the *private* portion of the
> *subkeys* you need.
> 
> In a offline digital vault of some sort (encrypted removable storage, or
> secure smartcard, etc), you need to keep everything including the
> private portion of the master (main) key.

After pondering about that for a while, it might be not wise to have the
master certification key generated on a "the key never leaves the card"
smart card since that doesn't allow you to have backups. So one needs to
have the certificatio master key somewhere on a medium from where you
can read it, to be able to write it to a new smart card.

People keep mentioning to store the private key on a LUKS-encrypted
device. Why? Is the private key encryption that happens inside GnuPG
itself when you protect your private key with a passphrase not
sufficient?

> In .gnupg you might have to store a "crippled" version of the main key,
> which has its private data zeroed, for it to work.  This is where people
> screw up and lose the key, or fail to protect it, so it should be a
> topic of its own.

That is the "stub" in GnuPG-Ling, right?

> > - Which (set of) keys goes to the key servers?
> 
> Only the public keys (all of them: master and subkeys).  gnupg will
> handle this automatically if you use --send-key.

And I hope that it's really hard to fuck up here and to send private
keys to the keyserver. I have had people send me the private parts of
their ssh keys...

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: wanted: educate us please on key dongles

[Henrique de Moraes Holschuh]

On Tue, 29 Aug 2017, Marc Haber wrote:
> - Which key goes on the paper slab that everybody uses to collect
>   signatures? The certification only master key?

The main key fingerprint.  Which happens to be the certification master
key in gnupg, yes.

> - For which (set of) keys should I have revocation certificates on file?

You need to have a revocation certificate for the master key.  When you
revoke it, you revoke every subkey as well.  Also, as long as you keep
control of the master key, you can revoke any subkey.

It goes without saying that losing control of your revocation
certificate can open you to a DoS attack, so please keep it protected
somehow, but NOT in a way you might find yourself unable to use it.

> - What key goes into the Debian keyring? A signing (only?) subkey of the
>   certification master key? Is it recommended to have this key
>   "available", for example in a Gnuk on my keychain next to the key to
>   my home?

The **public** portion of *every* key (master and all subkeys) go into
the public keyrings and also in the Debian keyring.  gnupg will handle
this automatically if you use "--export" (do *NOT* confuse with a
different export option that is for private keys).

In the "normal use" smartcard, you store the *private* portion of the
*subkeys* you need.

In a offline digital vault of some sort (encrypted removable storage, or
secure smartcard, etc), you need to keep everything including the
private portion of the master (main) key.

In .gnupg you might have to store a "crippled" version of the main key,
which has its private data zeroed, for it to work.  This is where people
screw up and lose the key, or fail to protect it, so it should be a
topic of its own.

> - Which (set of) keys goes to the key servers?

Only the public keys (all of them: master and subkeys).  gnupg will
handle this automatically if you use --send-key.

-- 
  Henrique Holschuh

Re: wanted: educate us please on key dongles

[Marc Haber]

On Fri, Aug 11, 2017 at 01:41:39PM +0100, Jonathan McDowell wrote:
>  * If you don't want to buy hardware, use an offline master key. Create
>a certification only master key using something like PGP Clean Room
>on a non-networked host, and store that on a USB key you only ever put
>into your machine when running your clean, non-networked,
>environment. Create at least 2 subkeys - signing + encryption - and
>use those in your day to day work. You then only need the master key
>when dealing with signing other keys, or updating your subkeys. In
>the event of your subkeys being compromised or lost or whatever you
>can just regenerate; because your master key is offline it should
>remain secure meaning you don't have to go through the pain of
>getting cross signatures again.

- Which key goes on the paper slab that everybody uses to collect
  signatures? The certification only master key?
- For which (set of) keys should I have revocation certificates on file?
- What key goes into the Debian keyring? A signing (only?) subkey of the
  certification master key? Is it recommended to have this key
  "available", for example in a Gnuk on my keychain next to the key to
  my home?
- Which (set of) keys goes to the key servers?

Greetings
Marc
-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: wanted: educate us please on key dongles

[Christian Seiler]

On 08/29/2017 07:34 PM, Marc Haber wrote:
> On Fri, Aug 11, 2017 at 01:41:39PM +0100, Jonathan McDowell wrote:
>> * Yubikey. I'm not sure about this; it's entirely closed these days
>>   I believe. However they're easily available and I understand
>>   they're pretty robust in terms of living on a keyring all the
>>   time.
> 
> I am using these devices for ssh login via the PIV suite. It's also
> limited to 2048 bit RSA, but can also do Elliptic Curve stuff. I neither
> have tried the Elliptic Curve cryptography in my Yubikeys and have never
> tried GnuPG (afraid of overwriting my ssh key).

Just FYI:

I don't know about SSH, but with GnuPG you can do 4096bit RSA with a
YubiKey 4, the non-free successor to the Neo, which indeed only
supports 2048bit RSA.

Regards,
Christian

Re: wanted: educate us please on key dongles

[Marc Haber]

On Fri, Aug 11, 2017 at 01:41:39PM +0100, Jonathan McDowell wrote:
> * GnuK: My favourite choice. It's slow with RSA4096, but does
>   support it. The hardware is open. The software is open (you can
>   compile and flash it using tools available in main). Upstream is
>   responsive (and a DD). However it's physically not quite as
>   polished and there are availability issues.

Would that be this device:

https://www.amazon.de/Fst-Without-Enclosure-32-Bit-Computer/dp/B01IOYSIBG ?
Is that a reasonable price?

> * Nitrokey Start: This is based on the GnuK (note their other
>   devices are not) and seems like it might be a good alternative
>   that is more physically robust will still being reasonably Free.
>   I've not actually had my hands on one however so this is guesswork
>   - but they do pop up on the GnuK dev list occasionally.

Their web page says that it will only suppor 2048 bit RSA keys, which is
the limitation of most USB crypto tokens on the market today. The
Nitrokey Pro will also do 3072 and 4096 bit, but it's considerably less
free?

> * Yubikey. I'm not sure about this; it's entirely closed these days
>   I believe. However they're easily available and I understand
>   they're pretty robust in terms of living on a keyring all the
>   time.

I am using these devices for ssh login via the PIV suite. It's also
limited to 2048 bit RSA, but can also do Elliptic Curve stuff. I neither
have tried the Elliptic Curve cryptography in my Yubikeys and have never
tried GnuPG (afraid of overwriting my ssh key).

> I appreciate this is not the "key dongles for dummies" asked for, but
> hopefully it's more helpful than continued silence. I personally would
> like us to get to the point where the "offline master" is our base line
> for how contributors to Debian manage their key - it provides a useful
> measure of extra security without the extra expense that a USB token
> involves. That said a USB token is definitely a better option.

I have been postponing the offline master stuff for years because of the
hassle connected. Would it be a stupid idea to have one hardware token
for the Master key (generated on the device, never having left it) and a
second token for the everyday signing and encryption keys? Can I have a
master certification key on one device and subkeys on another one? Can I
also have this when the private parts of master and sub keys have been
generated on different devices?

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: wanted: educate us please on key dongles

[Jonathan McDowell]

On Fri, Aug 11, 2017 at 04:52:36PM -0300, Henrique de Moraes Holschuh
wrote:
> On Fri, 11 Aug 2017, Jonathan McDowell wrote:
> > I see no reason why the master key should ever be used for
> > signatures in such a scenario, so it seems sensible to indicate that
> > it is purely for certification.
> 
> Well, it can be useful.  A SC master key (Sign and Certify) can be
> used to sign messages explaining to someone else the need for a new
> subkey when you had to revoke every subkey, when just adding the
> subkey itself is not enough, or when adding subkeys is subject to a
> delay.
> 
> Suppose you forget to renew/upload a new subkey in your Debian key
> set, and the current subkeys expire: it takes time for a new subkey
> upload to clear keyring maint.  During that time, an SC master key can
> be used in an emergency to sign a vote or an upload.

I see this as a failure to manage the signing subkey correctly, and a
certification only master key as helping to prevent the temptation to
just make use of the master for signing (and potentially avoid jumping
through all of the hoops required to use it securely).

(That said, I'm very conscious that a lot of crypto comes down to a set
of tradeoffs and I'm all in favour of people who have strong informed
opinions about how to do things differently doing those things if they
want. But if you ask me for a base line set of advice to J. Random DD
I'd still go with the certification only master.)

J.

-- 
... And you can't help my life. But you can hide the knives.

Re: wanted: educate us please on key dongles

[Henrique de Moraes Holschuh]

On Fri, 11 Aug 2017, Jonathan McDowell wrote:
> On Fri, Aug 11, 2017 at 10:08:16AM -0700, Sean Whitton wrote:
> > On Fri, Aug 11 2017, Jonathan McDowell wrote:
> > >  * If you don't want to buy hardware, use an offline master
> > >  key. Create
> > >a certification only master key using something like PGP Clean Room
> > >on a non-networked host [...]
> > 
> > By default, GnuPG creates a signing+certification master key.  Could you
> > explain why it's a good idea to override that?  I'm not sure what it
> > achieves.
> 
> I see no reason why the master key should ever be used for signatures in
> such a scenario, so it seems sensible to indicate that it is purely for
> certification.

Well, it can be useful.  A SC master key (Sign and Certify) can be used
to sign messages explaining to someone else the need for a new subkey
when you had to revoke every subkey, when just adding the subkey itself
is not enough, or when adding subkeys is subject to a delay.

Suppose you forget to renew/upload a new subkey in your Debian key set,
and the current subkeys expire: it takes time for a new subkey upload to
clear keyring maint.  During that time, an SC master key can be used in
an emergency to sign a vote or an upload.

-- 
  Henrique Holschuh

Re: wanted: educate us please on key dongles

[Christian Seiler]

Hi there,

On 08/11/2017 07:29 PM, Sean Whitton wrote:
> On Fri, Aug 11 2017, Christian Seiler wrote:
> 
>>   - on the computers I use daily the filesystem doesn't contain any
>> private keys, but only stubs for the subkeys so that GnuPG
>> automatically tells me to insert the key
> 
> I think I know what you mean by "stub", but what gpg command generates
> these?

The following options exist to create a stub exist:

 - initially when you move a key to the card gpg will delete the
   private keys on your computer after the key has been
   transferred to the smartcard

   (gpg --edit-key $keyid, then select the subkey to transfer,
   then keytocard, please read the docs before doing this!)

 - when you have a dongle plugged in you can also fetch the
   public key associated with it from the keyserver
   (gpg --card-edit, then fetch)

Both will automatically create the stubs in the
.gnupg/private-keys-v1.d/ directory associated with them.

>  Are they data that needs to be protected?

No, they can be recreated if you have access to the public
key (for example via keyserver) and the smartcard/dongle.

The stubs are smaller than normal private keys and are just
references for GnuPG telling it "it's on the smartcard/dongle
with serial number XYZ".

If you do --list-private-keys the output is a little different
depending on what you have. For example, for my personal key
this shows:

sec#  rsa4096/0x55DB1ABC3818B08C 2013-04-24 [SCEA] [expires: 2023-04-22]
  Key fingerprint = D328 4E4E 61A9 278A 511A  BC96 55DB 1ABC 3818 B08C
uid   [ultimate] Christian Seiler 
ssb>  rsa4096/0xA91531EA50BD3D08 2013-04-24 [SEA] [expires: 2023-04-22]
ssb>  rsa4096/0x63233459CDCFA018 2016-02-09 [S] [expires: 2018-03-11]

If the private key is available there would be no # and > signs after
'sec' and 'ssb'.

The # indicates that the private key for that key is not available
at all - in this case that's my master key which is not on my
live system.

The > indicates that the private key is only a stub, meaning that
it's not actually stored on the computer but that you need the
right smartcard/dongle to access it. As the stub encodes the
serial number gnupg will ask you to insert the smartcard / dongle
with that serial number if you attempt to perform any operation
that requires the private key for which only a stub exists and the
corresponding dongle is not plugged in at that time.

Regards,
Christian

Re: wanted: educate us please on key dongles

[Sean Whitton]

On Fri, Aug 11 2017, Christian Seiler wrote:

>   - on the computers I use daily the filesystem doesn't contain any
> private keys, but only stubs for the subkeys so that GnuPG
> automatically tells me to insert the key

I think I know what you mean by "stub", but what gpg command generates
these?  Are they data that needs to be protected?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: wanted: educate us please on key dongles

[Jonathan McDowell]

On Fri, Aug 11, 2017 at 10:08:16AM -0700, Sean Whitton wrote:
> Thank you for the explanation.
> 
> On Fri, Aug 11 2017, Jonathan McDowell wrote:
> 
> >  * If you don't want to buy hardware, use an offline master
> >  key. Create
> >a certification only master key using something like PGP Clean Room
> >on a non-networked host [...]
> 
> By default, GnuPG creates a signing+certification master key.  Could you
> explain why it's a good idea to override that?  I'm not sure what it
> achieves.

I see no reason why the master key should ever be used for signatures in
such a scenario, so it seems sensible to indicate that it is purely for
certification.

J.

-- 
/-\ |"Could I have an 'E', please,
|@/  Debian GNU/Linux Developer |Bob?"  (Blockbusters)
\-  |


signature.asc
Description: Digital signature

Re: wanted: educate us please on key dongles

[Sean Whitton]

Hello,

Thank you for the explanation.

On Fri, Aug 11 2017, Jonathan McDowell wrote:

>  * If you don't want to buy hardware, use an offline master
>  key. Create
>a certification only master key using something like PGP Clean Room
>on a non-networked host [...]

By default, GnuPG creates a signing+certification master key.  Could you
explain why it's a good idea to override that?  I'm not sure what it
achieves.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: wanted: educate us please on key dongles

[Christian Seiler]

Hi,

Am 2017-08-11 14:41, schrieb Jonathan McDowell:

* Yubikey. I'm not sure about this; it's entirely closed these days
  I believe. However they're easily available and I understand
  they're pretty robust in terms of living on a keyring all the
  time.


I bought a YubiKey 4 a couple of years ago, because the YubiKey Neo
had great reviews and was open, and I assumed the 4 would be the
same, plus I wanted something that supported 4096bit RSA, which the
Neo doesn't. Unfortunately I only found out afterwards that the
YubiKey 4 is not open anymore. As I'd already transferred my keys
there, I decided to keep it until it breaks down.

From the pure hardware standpoint I must say that that thing is
_really_ good. I've had it on my "analog" keyring for the last two
years, I've dropped thamy keyring by accident countless times, the
thing has chaffed against the metal keys in there for all that
time - and while it doesn't look quite new anymore, I've never had
any problems with it, it just works. If you want something that is
really sturdy and lasts from a hardware perspective, I can really
recommend it.

The software perspective isn't quite as rosy: the closedness of
the integrated firmware (which also means that there's a lack of
design review) is a definite problem. As you mentioned you can
only store 3 PGP keys on it, one for each type of function
(Encryption, Authentication and Signing), though that is not
something that's unique to this dongle. It does have some other
features that I've never used, so I can't comment on those.

Speed is reasonable, it takes a couple of seconds (< 5, I didn't
benchmark) to perform a RSA4096 signature, which is perfectly
fine. It tames me longer to enter my (long) passphrase.

When it comes to price I paid around 50€ 2 years ago for it. I
consider that to be very reasonable for a dongle.

If the software were open, I could wholeheartedly recommend it
to everyone - functionality-wise the only criticism I have is
the 3 key (or rather 1 key per function) limit.

Setting up the key was relatively simple, I just looked at a
couple of tutorials online to understand the basics and then the
rest was quite trivial. (I did not follow those tutorials
blindly though, I always tried to understand what they told me
to do first.) The main issue was that I needed to add some udev
rules to older versions of Debian because the dongle wasn't
known to them yet. But that was documented somewhere - and with
Stretch I didn't have to do that anymore.







My setup currently looks like this:

 - master private key is _not_ on the dongle, but I have two SD
   cards that are LUKS-encrypted (with a different password from
   the password of the key) that contain the master private key

   (plus I have a backup of it somewhere as well, again encrypted)

   Whenever I need to perform an action I do this on a live system
   without any configured network connection and with no persistent
   state anywhere (except for the SD card with the key, plus a
   separate USB stick for data exchange)

   I rarely do that though, the only instances where I actually
   need this is:

 - when I need to sign the key of another person

 - when I want to change the expiry date of my keys

 - separate subkeys for signing and encryption, those private keys
   are on the dongle

   Very important: I can revoke these subkeys without compromising
   the master key. So should I believe that my subkeys could have
   been compromised I can easily just revoke these without loosing
   the web of trust.

 - dongle configured in such a way that I have to reenter the
   password for every signature I make (but I do let it remember
   the password for the encryption key for a short while out of
   practicality)

 - on the computers I use daily the filesystem doesn't contain any
   private keys, but only stubs for the subkeys so that GnuPG
   automatically tells me to insert the key

Not saying this is the best possible setup, but I found it to be
a reasonable compromise between security and usability. (Of course,
if someone has any additional suggestions, I'll gladly listen.)

The main caveat I have at the moment is the lack of automation for
the master key management. Especially if  Iwant to update the master
key itself (and not just the subkeys or sign a third-party key) I
currently need to manually copy the modified key back to my second
SD card (which I have in case the first one breaks down) somehow,
which is quite tedious.

Regards,
Christian

Re: wanted: educate us please on key dongles

[Jonathan McDowell]

On Wed, Aug 02, 2017 at 10:16:29PM +0200, Adam Borowski wrote:
> It would be nice if someone knowledgeable could educate the rest of us
> about physical key dongles -- a number of DDs/DMs/contributors still
> keep their secret keys on a regular disk, and could use a primer.  Me
> included.  I do have a backup key with plenty of sigs that's stored
> securely, but my regular key is on the same physical machine I test
> random software on.
...
> There's GNUK ("out of stock"), Nitrokey and others -- but how do they
> differ?  Actually, at this point it would be easier to skip the
> details and say "if you don't know any better, buy X".
> 
> Thus: can I has "key dongles for dummies", plz?

The need for such a document has been brought up several times, but
it's never actually been created (and indeed a general "what's my best
approach to managing keys"). It's on the todo list, but I think there
are a bunch of software pieces that need to also happen in order to make
it a smooth process that people can actually easily engage in.

Here, at a very high level without instructions of how to do any of it,
is what I think might be a suitable base:

 * If you don't want to buy hardware, use an offline master key. Create
   a certification only master key using something like PGP Clean Room
   on a non-networked host, and store that on a USB key you only ever put
   into your machine when running your clean, non-networked,
   environment. Create at least 2 subkeys - signing + encryption - and
   use those in your day to day work. You then only need the master key
   when dealing with signing other keys, or updating your subkeys. In
   the event of your subkeys being compromised or lost or whatever you
   can just regenerate; because your master key is offline it should
   remain secure meaning you don't have to go through the pain of
   getting cross signatures again.

   (All of this needs a nice easy work flow, including a set of scripts
or something to shuffle keys to sign off your network connected
machine onto a USB stick and then into the clean room to be signed
and then back to the USB stick to be shuffled onto the networked
host to be emailed out and this is why I haven't written the doc
because without tooling it's going to be 100 pages of the most
boring screenshots you've ever read.)

  * If you want to buy hardware then one of the self contained USB
tokens that look like a smartcard + reader to the OS is probably
easiest. Part of the problem is that everything I've seen only
supports 3 keys on the device and those are one each of signing,
encryption + authentication. Which means you can't have a master
certification key and a signing subkey on the same device.

If you can manage it, have 2 devices; one with the master and the
other with your day-to-day keys. Otherwise I guess having a master
key that is signing enabled might be the best option? (Opinions,
anyone else?)

  * For hardware I'm aware of the following:
* GnuK: My favourite choice. It's slow with RSA4096, but does
  support it. The hardware is open. The software is open (you can
  compile and flash it using tools available in main). Upstream is
  responsive (and a DD). However it's physically not quite as
  polished and there are availability issues.
* Nitrokey Start: This is based on the GnuK (note their other
  devices are not) and seems like it might be a good alternative
  that is more physically robust will still being reasonably Free.
  I've not actually had my hands on one however so this is guesswork
  - but they do pop up on the GnuK dev list occasionally.
* Yubikey. I'm not sure about this; it's entirely closed these days
  I believe. However they're easily available and I understand
  they're pretty robust in terms of living on a keyring all the
  time.

I appreciate this is not the "key dongles for dummies" asked for, but
hopefully it's more helpful than continued silence. I personally would
like us to get to the point where the "offline master" is our base line
for how contributors to Debian manage their key - it provides a useful
measure of extra security without the extra expense that a USB token
involves. That said a USB token is definitely a better option.

J.

-- 
 Life is a bitch, but some of the  |  .''`.  Debian GNU/Linux Developer
 puppies are cute. | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.


signature.asc
Description: Digital signature

Re: wanted: educate us please on key dongles

[Daniel Pocock]

On 02/08/17 21:16, Adam Borowski wrote:
> Hi!
> Continuing from IRC:
> It would be nice if someone knowledgeable could educate the rest of us about
> physical key dongles -- a number of DDs/DMs/contributors still keep their
> secret keys on a regular disk, and could use a primer.  Me included.  I do
> have a backup key with plenty of sigs that's stored securely, but my regular
> key is on the same physical machine I test random software on.
>
> There are docs available on the interwebs, but:
> 21:22 < lamby> The concept of following random docs/commands on the web in
>order to get a "super secure" key makes me smie :)
>
> There's GNUK ("out of stock"), Nitrokey and others -- but how do they
> differ?  Actually, at this point it would be easier to skip the details and
> say "if you don't know any better, buy X".
>
>
> Thus: can I has "key dongles for dummies", plz?

We do have documents but they are spread over the wiki, some of them
contain duplicate information and they link back and forth between each
other.  Examples below.

How could we refine that into a step-by-step "howto" guide that takes
any user from whatever situation they are in today (whether it is bare
metal or already using some other OS or an existing Debian user) and
helps them reach a place where they are using PGP securely?


https://keyring.debian.org/creating-key.html
https://wiki.debian.org/Keysigning

https://wiki.debian.org/Smartcards
https://wiki.debian.org/Smartcards/OpenPGP
https://wiki.debian.org/Smartcards/OpenPGP/Buying
https://wiki.debian.org/Smartcards/YubiKey4
https://wiki.debian.org/GnuPG/SmartcardSubkeys

Re: wanted: educate us please on key dongles

[Wouter Verhelst]

On Thu, Aug 03, 2017 at 11:19:25AM +0200, Wouter Verhelst wrote:
> Having said all that, I'll repeat what I said on the gnupg-users
> mailinglist a while back[1]:
[...]
> [1]

That should have said
https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058035.html

Having said all that, I'd be happy to demo the use of my OpenPGP
smartcard to anyone who's interested. I also have a number of smartcard
readers (due to $DAYJOB requiring me to and me being too lazy to throw
them out before stepping on a plane), so you can toy with things on your
own laptop if you want to.

Just don't expect my to wipe the card, I still need to do some uploads
to Debian ;-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: wanted: educate us please on key dongles

[Wouter Verhelst]

On Wed, Aug 02, 2017 at 10:16:29PM +0200, Adam Borowski wrote:
> Hi!
> Continuing from IRC:
> It would be nice if someone knowledgeable could educate the rest of us about
> physical key dongles -- a number of DDs/DMs/contributors still keep their
> secret keys on a regular disk, and could use a primer.  Me included.  I do
> have a backup key with plenty of sigs that's stored securely, but my regular
> key is on the same physical machine I test random software on.
> 
> There are docs available on the interwebs, but:
> 21:22 < lamby> The concept of following random docs/commands on the web in
>order to get a "super secure" key makes me smie :)
> 
> There's GNUK ("out of stock"), Nitrokey and others -- but how do they
> differ?  Actually, at this point it would be easier to skip the details and
> say "if you don't know any better, buy X".
> 
> 
> Thus: can I has "key dongles for dummies", plz?

They're not "key dongles", they're OpenPGP Smart Cards. The
specification is open and defines how they should work on the smartcard
level; most "dongles" also implement a CCID interface and so can be used
as smartcards, even though you can never remove the smartcard from the
"reader". 

The specification assigns a manufacturer ID to the serial number;
therefore you can see what kind of device you're using by looking at the
serial number. My kernelconcepts card uses manufacturer ID 0005 (i.e.,
ZeitControl); yubikey uses 0007, for example. There are others.

Having said all that, I'll repeat what I said on the gnupg-users
mailinglist a while back[1]:

Smartcards are useful. They ensure that the private half of your key is
never on any hard disk or other general storage device, and therefore
that it cannot possibly be stolen (because there's only one possible
copy of it).

Smartcards are a pain in the ass. They ensure that the private half of
your key is never on any hard disk or other general storage device but
instead sits in your wallet, so whenever you need to access it, you need
to grab your wallet to be able to do so, which takes more effort than
just firing up GnuPG. If your laptop doesn't have a builtin cardreader,
you also need to fish the reader from your backpack or wherever, etc.

Additionally, unfortunately accessing smartcards from software isn't
always an entirely painless operation, and that may result in things
like https://twitter.com/wouter_verhelst/status/844686341711581185

[1]

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: wanted: educate us please on key dongles

[Jonas Smedegaard]

Quoting Adam Borowski (2017-08-02 16:16:29)
> There are docs available on the interwebs, but:
> 21:22 < lamby> The concept of following random docs/commands on the web in
>order to get a "super secure" key makes me smie :)

Ah - enlightening: I always wondered what a smiey looked like.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: wanted: educate us please on key dongles

[Zlatan Todoric]

On 08/02/2017 10:16 PM, Adam Borowski wrote:

Hi!
Continuing from IRC:
It would be nice if someone knowledgeable could educate the rest of us about
physical key dongles -- a number of DDs/DMs/contributors still keep their
secret keys on a regular disk, and could use a primer.  Me included.  I do
have a backup key with plenty of sigs that's stored securely, but my regular
key is on the same physical machine I test random software on.

There are docs available on the interwebs, but:
21:22 < lamby> The concept of following random docs/commands on the web in
order to get a "super secure" key makes me smie :)

There's GNUK ("out of stock"), Nitrokey and others -- but how do they
differ?  Actually, at this point it would be easier to skip the details and
say "if you don't know any better, buy X".


Thus: can I has "key dongles for dummies", plz?


+1 on the need for such education/tutorial