Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #9351 > unrolled thread

wanted: educate us please on key dongles

Back to article view | Back to linux.debian.project

Contents

  wanted: educate us please on key dongles Adam Borowski <kilobyte@angband.pl> - 2017-08-02 22:20 +0200
    Re: wanted: educate us please on key dongles Zlatan Todoric <zlatan@riseup.net> - 2017-08-02 22:40 +0200
    Re: wanted: educate us please on key dongles Jonas Smedegaard <dr@jones.dk> - 2017-08-02 22:50 +0200
    Re: wanted: educate us please on key dongles Wouter Verhelst <w@uter.be> - 2017-08-03 11:30 +0200
    Re: wanted: educate us please on key dongles Wouter Verhelst <wouter@debian.org> - 2017-08-03 11:30 +0200
    Re: wanted: educate us please on key dongles Daniel Pocock <daniel@pocock.pro> - 2017-08-03 13:40 +0200
    Re: wanted: educate us please on key dongles Víctor Cuadrado Juan <me@viccuad.me> - 2017-08-03 19:10 +0200
    Re: wanted: educate us please on key dongles Jonathan McDowell <noodles@earth.li> - 2017-08-11 15:20 +0200
      Re: wanted: educate us please on key dongles Christian Seiler <christian@iwakd.de> - 2017-08-11 17:30 +0200
        Re: wanted: educate us please on key dongles Sean Whitton <spwhitton@spwhitton.name> - 2017-08-11 19:30 +0200
          Re: wanted: educate us please on key dongles Christian Seiler <christian@iwakd.de> - 2017-08-11 19:50 +0200
      Re: wanted: educate us please on key dongles Sean Whitton <spwhitton@spwhitton.name> - 2017-08-11 19:10 +0200
        Re: wanted: educate us please on key dongles Jonathan McDowell <noodles@earth.li> - 2017-08-11 19:30 +0200
          Re: wanted: educate us please on key dongles Henrique de Moraes Holschuh <hmh@debian.org> - 2017-08-11 22:00 +0200
            Re: wanted: educate us please on key dongles Jonathan McDowell <noodles@earth.li> - 2017-08-12 00:00 +0200
      Re: wanted: educate us please on key dongles Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-29 19:40 +0200
        Re: wanted: educate us please on key dongles Christian Seiler <christian@iwakd.de> - 2017-08-29 20:00 +0200
        Re: wanted: educate us please on key dongles Jonathan McDowell <noodles@earth.li> - 2017-08-30 11:10 +0200
          Re: wanted: educate us please on key dongles Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-30 12:20 +0200
            Re: wanted: educate us please on key dongles Adam Borowski <kilobyte@angband.pl> - 2017-08-30 12:50 +0200
              Re: wanted: educate us please on key dongles Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-30 13:00 +0200
                Re: wanted: educate us please on key dongles Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-08-30 13:20 +0200
                  Re: wanted: educate us please on key dongles Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-30 15:00 +0200
                Re: wanted: educate us please on key dongles Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-30 13:20 +0200
                Re: wanted: educate us please on key dongles Jonathan McDowell <noodles@earth.li> - 2017-08-30 13:20 +0200
                Re: wanted: educate us please on key dongles Ian Campbell <ijc@debian.org> - 2017-08-30 17:20 +0200
          Re: wanted: educate us please on key dongles Alexander Zangerl <az+debmnt@snafu.priv.at> - 2017-08-31 00:40 +0200
      Re: wanted: educate us please on key dongles Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-29 20:10 +0200
        Re: wanted: educate us please on key dongles Henrique de Moraes Holschuh <hmh@debian.org> - 2017-08-29 21:10 +0200
          Re: wanted: educate us please on key dongles Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-30 09:10 +0200
            Re: wanted: educate us please on key dongles Christian Seiler <christian@iwakd.de> - 2017-08-30 14:00 +0200
              Re: wanted: educate us please on key dongles Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-30 14:50 +0200
                Re: wanted: educate us please on key dongles Christian Seiler <christian@iwakd.de> - 2017-08-30 17:20 +0200
              Re: wanted: educate us please on key dongles Christian Seiler <christian@iwakd.de> - 2017-09-22 22:10 +0200
            Re: wanted: educate us please on key dongles Teemu Likonen <tlikonen@iki.fi> - 2017-08-30 14:10 +0200
            Re: wanted: educate us please on key dongles Sean Whitton <spwhitton@spwhitton.name> - 2017-08-31 07:10 +0200
    Re: wanted: ... key dongles GNUK is available Osamu Aoki <osamu@debian.org> - 2017-08-16 17:00 +0200
      Re: wanted: ... key dongles GNUK is available Marc Haber <mh+debian-project@zugschlus.de> - 2017-08-29 19:50 +0200
    [summary] Re: wanted: educate us please on key dongles Charles Plessy <plessy@debian.org> - 2017-09-08 15:20 +0200
      Re: [summary] Re: wanted: educate us please on key dongles Sotirios Vrachas <sotirios@vrachas.com> - 2017-09-09 22:20 +0200
        Re: [summary] Re: wanted: educate us please on key dongles Charles Plessy <plessy@debian.org> - 2017-09-10 06:00 +0200

Page 1 of 3  [1] 2 3  Next page →

#9351 — wanted: educate us please on key dongles

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?


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair)
⠈⠳⣄⠀⠀⠀⠀ • use glitches to walk on water

[toc] | [next] | [standalone]

#9353

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

[toc] | [prev] | [next] | [standalone]

#9356

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#9360

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

[toc] | [prev] | [next] | [standalone]

#9361

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

[toc] | [prev] | [next] | [standalone]

#9362

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

[toc] | [prev] | [next] | [standalone]

#9363

On 02/08/17 22: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 :)
>...
> Thus: can I has "key dongles for dummies", plz?

In the direction of random commands on the web, I have done a blogpost detailing
a master key + subkeys on a Yubikey Neo some time ago, still relevant:

http://viccuad.me/blog/Revisited-secure-yourself-part-1-airgapped-computer-and-gpg-smartcards



-- 
Víctor Cuadrado Juan           me@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.

[toc] | [prev] | [next] | [standalone]

#9394

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#9396

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

[toc] | [prev] | [next] | [standalone]

#9399

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#9400

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 <christian@iwakd.de>
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

[toc] | [prev] | [next] | [standalone]

#9397

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#9398

[Multipart message — attachments visible in raw view] — view raw

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)
\-                              |

[toc] | [prev] | [next] | [standalone]

#9401

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

[toc] | [prev] | [next] | [standalone]

#9404

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.

[toc] | [prev] | [next] | [standalone]

#9459

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

[toc] | [prev] | [next] | [standalone]

#9461

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

[toc] | [prev] | [next] | [standalone]

#9468

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.

[toc] | [prev] | [next] | [standalone]

#9469

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

[toc] | [prev] | [next] | [standalone]

#9470

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
⠈⠳⣄⠀⠀⠀⠀ 

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.project

csiph-web