[Gnuk-users] gnuk-users Digest, Vol 107, Issue 7

Thu Jan 11 21:35:20 UTC 2018

While doing keytocard you are supposed to be doing it on a secure offline
dedicated or throw away box.

Say tails or a pi or with a neug or good random numbers configured.

So it is OK to first do keytocard then set passwords. Dont worry about the
key on the card with default pin. As at that point you are on a secure box
and wont go to piss or blink or breath while doing it. :)

If the guy is stepping out when there are collegues moving in that room he
should be also ok/linient to be OK for short period of time the key is on
card with default pins.

It may be OK with encrypting zeroes as long as user also changes his
password after first keytocard. (Avoid known plaintext attack)

Anyway it is good to not store password for the private key and the
encrypted private key together both on the card.

Say we have unknown backdoor to hardware.

On Jan 11, 2018 2:26 PM, <gnuk-users-request at lists.alioth.debian.org> wrote:

> Send gnuk-users mailing list submissions to
>         gnuk-users at lists.alioth.debian.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.alioth.debian.org/mailman/listinfo/gnuk-users
> or, via email, send a message with subject or body 'help' to
>         gnuk-users-request at lists.alioth.debian.org
>
> You can reach the person managing the list at
>         gnuk-users-owner at lists.alioth.debian.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gnuk-users digest..."
>
>
> Today's Topics:
>
>    1. Re: gnuk-users Digest, Vol 107, Issue 3 (Mike Tsao)
>    2. Re: gnuk-users Digest, Vol 107, Issue 3 (Peter Lebbing)
>    3. Re: gnuk-users Digest, Vol 107, Issue 3 (Mike Tsao)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Jan 2018 18:38:04 +0000
> From: Mike Tsao <mike at sowbug.com>
> To: Peter Lebbing <peter at digitalbrains.com>
> Cc: Gnuk and NeuG <gnuk-users at lists.alioth.debian.org>
> Subject: Re: [Gnuk-users] gnuk-users Digest, Vol 107, Issue 3
> Message-ID:
>         <CACi+kjpb7JtU7=tp0CJ6cZsz_qBXrfEmYKMST==onDsAg0s_5w@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Peter, that's a nice idea, but I have some larger concerns about the
> general problem being solved.
>
> First, if the plaintext is known, then a dictionary or at least brute-force
> attack is feasible. In this case, though, the threat model involves first
> obtaining the unique physical device, so I'm not sure an attacker would
> bother to construct the dictionary. It's unlikely someone would suddenly
> find 10,000 gnuk devices with PINs but no keys.
>
> The brute-force attack unfortunately applies to both the static string and
> the private key plaintext cases. I haven't looked at the gnuk
> implementation that verifies the PIN indeed decodes the private key
> correctly, but it's likely equivalent to the static case -- checking a few
> magic header bytes.
>
> Which brings us back to the original problem. What exactly are we
> protecting against?
>
> Normally private keys in a GnuPG keychain must be stored in a way that's
> immune to offline brute-force attacks (PBKDF with strong passphrase).
> That's a well-understood and secure system, but it's hard to use because
> users need to worry about managing strong passphrases, including worrying
> about whether malware steals the passphrase. Thus GnuPG is hard to use.
>
> Smart cards solve that problem. They are inexpensive and they replace a
> strong stretched passphrase with a short unstretched PIN that's easy to
> memorize and enter. But they can do this only if the hardware is
> tamper-resistant, and if the firmware locks out anything resembling a
> brute-force attack on the PIN. That lockout mechanism must be very
> conservative (only 3 tries) because the PIN space is so small.
>
> If we suspend the tamper-resistance requirement, then we're left with this:
>
>
>    - Valuable asset...
>    - That is encrypted by a brute-forceable PIN...
>    - That is not stretched (or else the device would be slow or
>    expensive)...
>    - That is housed on a device where we must explicitly assume the
>    attacker obtains a copy of the device's ciphertext (uh-oh).
>
> This is an unsolvable problem. If the PIN is long enough to resist brute
> forcing, then the smart card's purpose (usability) is defeated. If the PIN
> is stretched, an attractive element of the hardware (cheap and fast) is
> lost. And if the device is compromised and the attacker contains a
> ciphertext weakly encrypted with a small key, the smart card is worse than
> no solution at all, because it caused a well-protected but unusable key to
> be exposed in the open with virtually no real protection.
>
> That's why it makes more sense to assume the device actually is
> tamper-resistant (the hacker will never obtain the ciphertext), and build
> on that assumption. Otherwise we end up with partial solutions that don't
> actually address the threat model sufficiently to stop any attacker.
>
> On Thu, Jan 11, 2018, 1:04 AM Peter Lebbing <peter at digitalbrains.com>
> wrote:
>
> > On 11/01/18 07:48, Mike Tsao wrote:
> > > If I'm understanding the current gnuk code, the key-before-PIN policy
> is
> > also
> > > the mechanism of the implementation ("Gnuk 1.2 does validation of user
> > PIN by
> > > successful decryption of private key"), so it doesn't appear that
> > someone with a
> > > perspective like mine can easily or elegantly reconfigure gnuk
> > accordingly.
> >
> > Well, this could be solved by representing the "no key" state with dummy
> > data
> > that is encrypted to the PIN.
> >
> > When there is a key, the PIN encrypts the key, and succesful decryption
> > indicates success.
> >
> > When there is no key, the PIN encrypts the literal string "Nothing to see
> > here,
> > move along"[1] and succesful decryption indicates success. The PIN that
> > was then
> > verified in this way can be kept in RAM and used to subsequently encrypt
> > the
> > uploaded key. I suppose this is roughly what happens when keys are
> > uploaded to a
> > GnuK that already has some keys?
> >
> > HTH,
> >
> > Peter.
> >
> > [1] Well, that would give me a chuckle if I were reading the code. A
> > string of
> > zeroes would work just as well and occupy no flash memory in the
> > controller, but
> > it wouldn't be funny, damn it!
> >
> > --
> > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> > You can send me encrypted mail if you want some privacy.
> > My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/
> attachments/20180111/20862906/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 11 Jan 2018 19:59:36 +0100
> From: Peter Lebbing <peter at digitalbrains.com>
> To: Mike Tsao <mike at sowbug.com>
> Cc: Gnuk and NeuG <gnuk-users at lists.alioth.debian.org>
> Subject: Re: [Gnuk-users] gnuk-users Digest, Vol 107, Issue 3
> Message-ID: <f0971a16-4b86-fb11-52fe-b296a77bf545 at digitalbrains.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 11/01/18 19:38, Mike Tsao wrote:
> > They are inexpensive and they replace a
> > strong stretched passphrase with a short unstretched PIN that's easy to
> > memorize and enter.
>
> Well, if you're not worried about brute-force attacks on extracted
> encrypted keys, sure, you can use a short unstretched PIN. I was however
> assuming you are using a proper good passphrase for your GnuK. I haven't
> looked at the key derivation function of GnuK, but I know that this area
> is under construction to be improved by letting the host PC do (part
> of?) the KDF. So even if right now the KDF isn't as good as you want,
> this is already being worked on.
>
> With a good KDF, there is no problem with brute-forcing, known plaintext
> or no.
>
> >   * Valuable asset...
> >   * That is encrypted by a brute-forceable PIN...
>
> As you say, this is unsolvable, might as well not encrypt it at all. It
> is not the assumed usage of GnuK, it is assumed you use a good
> passphrase rather than a PIN if you're worried about data extraction.
> Luckily, nobody is forcing you to use a PIN :-).
>
> With a 6-digit PIN, the time needed to crack is inherently only 500,000
> times slower than that of regular use, *irrespective* *of* *stretching*.
> Even if you were to accept a totally painful delay of 10 seconds on
> passphrase entry, that /same/ computer could necessarily crack it after
> on average just two months of computation. A dedicated cracking rig
> would be much quicker even, so these numbers are unrealistically benign.
>
> HTH,
>
> Peter.
>
> --
> I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> You can send me encrypted mail if you want some privacy.
> My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 488 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/
> attachments/20180111/263e9087/attachment-0001.sig>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 11 Jan 2018 20:26:24 +0000
> From: Mike Tsao <mike at sowbug.com>
> To: Peter Lebbing <peter at digitalbrains.com>
> Cc: Gnuk and NeuG <gnuk-users at lists.alioth.debian.org>
> Subject: Re: [Gnuk-users] gnuk-users Digest, Vol 107, Issue 3
> Message-ID:
>         <CACi+kjqO5qDWCtHw0ziZJbfsNWekxJq2xd=XWRsyV0M2Vdfxug at mail.gmail.
> com>
> Content-Type: text/plain; charset="utf-8"
>
> That's why tamper resistance is such a critical assumption -- otherwise you
> can't use a short PIN. If you know the hardware is tamper-resistant, then
> you can trust that the attacker will never obtain a copy of the ciphertext,
> so you don't have to worry about offline brute-force attacks *even for a
> 6-digit PIN*. Instead you can trust that the retry lockout asserted by the
> tamper-resistant hardware will prevent more than three incorrect tries,
> which is not impossible to do but a reasonable tradeoff given the
> significant usability of needing to remember only a short PIN. (I believe
> the math is (999999?1000000)?(999998?999999)?(999997?999998) = 99.9997%
> chance of getting locked out rather than correctly guessing 6 numeric
> digits, given a maximum of three attempts.)
>
> > I was however assuming you are using a proper
> > good passphrase for your GnuK.
>
> If you still need a good passphrase, then there is no usability benefit
> over pure desktop GnuPG -- in either case the experience is "start GPG
> operation, enter long passphrase into pinentry dialog on desktop, complete
> GPG operation."
>
> There is a small bit of additional security from the fact that the private
> key lives in a physical home that you can take with you or lock in a
> lockbox. But if the threat model includes exfiltration of the encrypted
> private key from that physical home, then that additional security is
> largely imaginary; moreover, you don't need GnuK to make it possible to
> lock a copy of your GPG key in a box.
>
> On Thu, Jan 11, 2018 at 10:59 AM Peter Lebbing <peter at digitalbrains.com>
> wrote:
>
> > On 11/01/18 19:38, Mike Tsao wrote:
> > > They are inexpensive and they replace a
> > > strong stretched passphrase with a short unstretched PIN that's easy to
> > > memorize and enter.
> >
> > Well, if you're not worried about brute-force attacks on extracted
> > encrypted keys, sure, you can use a short unstretched PIN. I was however
> > assuming you are using a proper good passphrase for your GnuK. I haven't
> > looked at the key derivation function of GnuK, but I know that this area
> > is under construction to be improved by letting the host PC do (part
> > of?) the KDF. So even if right now the KDF isn't as good as you want,
> > this is already being worked on.
> >
> > With a good KDF, there is no problem with brute-forcing, known plaintext
> > or no.
> >
> > >   * Valuable asset...
> > >   * That is encrypted by a brute-forceable PIN...
> >
> > As you say, this is unsolvable, might as well not encrypt it at all. It
> > is not the assumed usage of GnuK, it is assumed you use a good
> > passphrase rather than a PIN if you're worried about data extraction.
> > Luckily, nobody is forcing you to use a PIN :-).
> >
> > With a 6-digit PIN, the time needed to crack is inherently only 500,000
> > times slower than that of regular use, *irrespective* *of* *stretching*.
> > Even if you were to accept a totally painful delay of 10 seconds on
> > passphrase entry, that /same/ computer could necessarily crack it after
> > on average just two months of computation. A dedicated cracking rig
> > would be much quicker even, so these numbers are unrealistically benign.
> >
> > HTH,
> >
> > Peter.
> >
> > --
> > I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
> > You can send me encrypted mail if you want some privacy.
> > My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/
> attachments/20180111/63de4b0c/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> gnuk-users mailing list
> gnuk-users at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/gnuk-users
>
>
> ------------------------------
>
> End of gnuk-users Digest, Vol 107, Issue 7
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20180111/50e1139a/attachment-0001.html>