Maybe you should edit the title of this submission and add "Show HN" (https://news.ycombinator.com/showhn.html).
For those starting from scratch with a YubiKey I always recommend this guide:
https://github.com/drduh/YubiKey-Guide
Then they know how this stuff works and how to fix it when it breaks.
From the drduh guide:
> It is recommended to generate cryptographic keys and configure YubiKey from a secure operating system and using an ephemeral environment
One thing that I still haven't found a good answer for that's not mentioned in the guide: what's KDF for?
The new yubikey firmware has release notes here: https://support.yubico.com/support/solutions/articles/150000...
This is the bit that has me lost:
> To remove the transmission and on-card storage of OpenPGP PINs in plain text, the YubiKey supports the Key Derived Function (KDF) functionality. With the KDF function enabled, the PIN is stored as a hash on the YubiKey. When entering the PIN to the OpenPGP Smart Card, the OpenPGP client will only pass the hashed value, never passing the PIN directly. KDF functionality is set on the card itself, and communicated to the client; it is transparent to the user. Should the KDF functionality not be enabled, the PIN function will work as previously. The KDF function is listed in section 4.3.2 of the OpenPGP Smart Card 3.4 spec.
Can someone explain to me how KDF matters at all here?
It seems like the keys are encrypted on the yubikey via pin, or at least protected in hardware via pin, and that the pin is stored on the device. KDF seems to take that plain text pin and replace it with a hashed pin. If you steal my yubikey, it looks like KDF would prevent you from... dumping the PIN? But if you could dump the pin, wouldn't you just dump the key instead? I can't seem to figure out the threat model for this feature.
Still looking forward to SSH supporting U2F (some day).
[0]: https://marc.info/?l=openssh-unix-dev&m=157259802529972
> Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. So signing each commit is simply missing the point.
[0]: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
Signing every commit is going to make it a mindless task. It's easier to be vigilant when signing if you sign less frequently.
What trade-offs should be considered?
``` programs.gnupg.agent = { enable = true; enableSSHSupport = true; };
services.udev.packages = [ pkgs.yubikey-personalization pkgs.libu2f-host ]; services.pcscd.enable = true;
environment.shellInit = '' export GPG_TTY="$(tty)" gpg-connect-agent /bye export SSH_AUTH_SOCK="/run/user/$UID/gnupg/S.gpg-agent.ssh" ''; ```
The only surprise I had was that I forgot to tell gpg to trust the imported key after I imported it.
Combine this with GoPass... its the start of something good :)
What was the problem with gnome? I vaguely recall a problem with polkit or something.
For organizations publishing employee keys via Web Key Directory can also be an additional signal that the key is trustworthy.
It's also quite simple: for example exporting the key 5C090ED7318B6C1E (binary, not armored) and putting it on this exact URL: https://datadoghq.com/.well-known/openpgpkey/hu/964aj6q73iat... is enough to discover the key using e-mail address.
This post goes into more detail: https://spacekookie.de/blog/usable-gpg-with-wkd/
WKD is used by Linux distros (ArchLinux, Gentoo, Debian...) and kernel.org itself: https://www.kernel.org/category/signatures.html#using-the-we... as well as some OpenPGP sites (e.g. ProtonMail).
https://github.com/DataDog/yubikey/blob/master/gpg.sh#147
This statement has no effect when using Yubikey - the PIN is cached by the key itself and it will remain unlocked indefinitely until it's physically unplugged. See https://dev.gnupg.org/T3362
The best method I know is to store it on paper with the help of paperkey:
http://www.jabberwocky.com/software/paperkey/
The tool also supports a raw output mode which can be piped to a QR encoder. 4096 bit RSA secret keys fit in binary QR codes and they are much easier to use compared to manual data entry.
Current versions of zbar can't decode binary data in QR codes properly. I've sent some patches that fix the problem but they haven't been reviewed yet. Hopefully it will be possible to automate this process with zbarcam soon.
