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