That guide is great --- really helped me out when I started! Then I realized why no one uses GPG in practice: this stuff is way too hard even for security experts. That's why I believe in making things as easy and usable as possible w/o sacrificing security.
But you already succeeded at sacrificing security, because there is no note about performing key generation not in an internet-connected machine, ideally a live cd / usb image boot.
From the drduh guide:
> It is recommended to generate cryptographic keys and configure YubiKey from a secure operating system and using an ephemeral environment
To the best of my knowledge, if you trust the YubiKey firmware, and assuming that it behaves correctly, the private keys are generated on the YubiKey itself, and cannot be exported.
Also I'd strongly encourage generating encryption subkey in software (offline, air-gapped machine) and then copying it to Yubikeys. If you lose your Yubikey (or mistype 3 times the PIN) you wouldn't be able to decrypt your secret data.
We're aware of hardware vulns like ROCA (we used to check the exact version of the YK, now we support only the major version 5).
We're taking the risk anyway because the benefits of having the private keys generated and stored entirely on the YK is entirely worth it.
We're also not primarily using the YK to encrypt messages. If continuing to decrypt shared messages in the future is critical, I'd personally look into HSMs which offers key-wrapped backup.
"Trust" isn't really that binary. I trust smart cards and key fobs much more with not leaking key material than generating said keys in a safe fashion.
That specific best practice might not be the most important for most people to follow, compared to other things on the list, but it is definitively a good idea and has saved me before. Random number generators on embedded devices aren't always the best.
Oh that's great, alleviates my concerns, which was like, how do you know you're even asking the yubikey to do key generation rather than a malicious actor generating a private key and placing it on the yubikey. Thanks!
I didn't say I distrusted the hardware, I said the very opposite. I said I didn't see how, before this attestation feature, you could guarantee your computer software even asked the hardware to generate the key.
> 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.
How would that help though? If you have a compromised USB interface, and you're entering your pin on that machine, you could just capture the keyboard input anyway.
Nope, you were right. It's for USB MITM. I guess the assumption is that the keyboard is wired in a different way (a laptop?) or in wireless scenarios (NFC Yubikey).
New firmware is quite interesting if one is using OpenPGP: it supports newer algorithms (25519) and key attestation (proofs that the key was generated in hardware, useful for enterprises). Still, PIV applet has some more advantages (like dozens of possible encryption subkeys) but this is mainly a limitation of OponPGP Card spec.
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
No, but try unplugging the YubiKey and trying again. Also, the script officially supports only YubiKey 5, but I've heard that 4 works if you remove the code that checks the version.
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.
> 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.
I think "sign every commit useful?" is less about whether signing is useful, and more about the trade-off of signing every commit vs just signing a tag on a commit.
Signing every commit is going to make it a mindless task. It's easier to be vigilant when signing if you sign less frequently.
this turns commit signing on for every commit, you don't have to explicitly sign commits as a separate step.
the criticism I've always heard of this practice is, what do you do with those signatures? github displays a little widget showing that the commits are signed, but beyond that I don't think it cares which public key they were signed with, so it's not really helping anything.
Entering a key passphrase each time is going to be annoying without providing benefit over just signing some git tag.
Leaving the key unlocked in an agent is going to be somewhat less secure than requiring the key to be unlocked on every use.
> github displays a little widget showing that the commits are signed, but beyond that I don't think it cares which public key they were signed with, so it's not really helping anything.
As I understand it, "verified" means it's either a commit made on GitHub's website with that user signed in, or the commit was signed with one of the keys associated with that user's profile.
I guess for the case of "I only trust commits signed by a certain key", you'd need to use a different GitHub profile.
Gentoo org was hacked on GitHub, and had their source code modified. Luckily, their private build infrastructure used only their own personal git repo, which required signing all commits (and presumably checking them).
It is simply an audit trail to trace back to the origin, since anyone can set any email address as the author of a commit. GitHub will show the signature fingerprint I think when you hover over that widget, so you can at least distinguish between your key and an impostor’s.
I use this but it causes weird usability issues for me when using multiple iTerm tabs or git GUIs when the GPG daemon’s unlock timeout expires and I need to input my passphrase in again. I wish it could just be tied to the mac’s keychain, so when I unlock my computer it is ready to go. Or at least tie it into TouchID or Watch like unlocking the mac does.
Yes, it's so easy with this YK setup that there's no reason not to do it. The only exception is during rebase, but there's an option in GPG to disable signing then.
I sign all my commits so that everyone knows it was most likely me. You can even turn on branch protection in GitHub these days that rejects unsigned commits.
With all due respect, Mr. Torvalds isn't exactly famous for having designed the most secure kernel.
Slightly related: Anyone know why Google Chrome (not upstream Chromium, nor any derivative) is the only browser on Android that implements WebAuthn as intended? Do they implement it as a proprietary component?
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.