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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#9471

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

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

#9472

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.

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

#9478

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

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

#9473

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

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

#9474

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

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

#9480

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.

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

#9484

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

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

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

#9462

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

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

#9463

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

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

#9467

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

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

#9475

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

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

#9477

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

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

#9479

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

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

#9512

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

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

#9476

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

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   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

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

#9485

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

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

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

#9439 — Re: wanted: ... key dongles GNUK is available

Hi,

I just got a GNUK from Niibe-san at Debconf17.

Niibe-san is a DD and the original circuit and software developer of GNUK.

On Wed, Aug 02, 2017 at 10:16:29PM +0200, Adam Borowski wrote:
> There's GNUK ("out of stock")

According to Niibe-san, the web page says out-of-stock after their site
update, but if you ask, they have it!  Typical for this kind of site
according to Niibe-san.  It's 100% FREE.

The latest version of source is available:
 http://git.gniibe.org/gitweb/?p=gnuk/gnuk.git;a=summary

The code runs on:
 FST-01 (Flying Stone Tiny ZERO-ONE) -- Niibe-san (also via SEEEDSTUDIO)
 Olimex STM32-H103
 STM32 part of STM8S Discovery Kit
 STBee

I don't know where is the binary since Niibe-san installed binary for me.

http://www.fsij.org/doc-gnuk/

There is a lot of info there.

Osamu
 

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

#9460 — Re: wanted: ... key dongles GNUK is available

On Wed, Aug 16, 2017 at 11:55:02PM +0900, Osamu Aoki wrote:
> According to Niibe-san, the web page says out-of-stock after their site
> update, but if you ask, they have it!  Typical for this kind of site
> according to Niibe-san.  It's 100% FREE.

"They" would be the seeedstudio.com store? Or the japanese store on
http://www.gniibe.org/category/shop.html?

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]

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

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

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

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

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

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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web