Not quite true - "All signing and encryption operations happen on the card, rather than in OS memory."

[skaht]

More precise to say:

All message signing and asymmetric cryptography decryption can happen on a YubiKey OpenPGP smart card, rather than in OS memory. The following operations are not offloaded to YubiKeys and still occur in OS memory: 1. symmetric message encryption ephemeral key generation, 2. bulk message symmetric key encryption, and 3. asymmetric encryption of the ephemeral key.

[drduh]

Can we cite a resource that backs this up and sheds more detail, @skaht ?

[skaht]

Been investigating the this tech for over two years now. For #3, I'm certain that Yubikeys are applied to perform asymmetric decryption operations, not asymmetric encryption. The encryption is performed by parties having the public key of the the intended recipient. Albeit, OpenPGP asymmetric encryption is used to hide the symmetric keys used for bulk encryption.

Home grown code (no gpg dependencies for creating OpenPGP keyblocks) is explicitly synthesizing and also configuring Yubikeys that are OpenPGP interoperable, specifically with gpg. I'm very reluctant to think Yubikeys are psychic, and I have not explicitly located details about how Yubikeys can perform bulk symmetric encryption/decryption that directly relates to gpg, which currently makes me think gpg natively only supports software-based encryption with the public keys contained within one's keychain. gpg-agent-coonect RPCs also to be consistent with this point.

RFC 6979 gets into deterministic ephemeral key generation for creating digital signatures. I've applied the secp256k1 library (from bitcoin-core) that uses RFC 6979 to create a master, sign, decrypt, and auth keys/(Open PGP public and private certs) interoperable with OpenPGP that can be loaded into a a Yubikey for use. Have not found details yet if nor how Yubikeys can generate ephemeral keys to perform symmetric encryption.

With the ability to independently create OpenPGP keyblockc/certs, I can attest to signature malleability is an issue with OpenPGP with the secp256k1 curve with its cofactor or 2. Signature malleability is even more of an issue with the ed25519 curve with a cofactor of 8. Signature malleability has the potential to overload OpenPGP keyservers with non-value added certs.

[drduh]

I think I get it. Let's find a simple, one or two sentence way to explain this. Like, when do those three conditions occur and what can a user really do about it? Can you draft a PR since you seem best qualified to answer these questions?

[drduh]

@skaht Can we still interest you in that PR?

[skaht]

Here are a few pearls to drawl from for https://github.com/drduh/YubiKey-Guide#using-multiple-keys Section:

One can can re-import their public keys/certs (master and subkeys) and perform a "gpg card-status" to transform/stub the certificate representation in one's keyring to point to proper hardware token keys if they are rotated or different hardware tokens are used.

Have not experimented with re-stubbing over a stub with a card-status. The ~/.gnupg/private-keys-v1.d/#keygrip#.key files when stubbed really act as pointers to specific serial numbered hardware tokens. Cleaning up ~/.gnupg/private-keys-v1.d/#keygrip#.key lint can sometimes be problematic.

Using the gpg command line, one should not be required to have access to private keys to calculate keygrips.

cat public_cert-395a2384.asc | gpg --with-colons --show-keys => does not yield keygrip info cat private_cert-395a2384.asc | gpg --with-colons --show-keys => does yield keygrip info

It is definitely possible to calculate a keygrip directly without gpg source code from knowing an elliptic curve type and the associated public key. GPG obfuscated the hell of how to interface directly with gpg to calculate keygrips with the application of s-expressions (sexp) , see https://crypto.stackexchange.com/questions/77108/computing-pgp-ed25519-and-curve25519-keygrips and https://blog.djoproject.net/2020/05/03/main-differences-between-a-gnupg-fingerprint-a-ssh-fingerprint-and-a-keygrip/#5-keygrip.

Within gpg, keygrips are used as a means to index private keys hosted on a protected gpg-agent that performs crypto operations without the need to use fingerprints that have creation dates that influences the computed fingerprint of a certificate. For example to exercise auth key signing functionality directly (such as with ssh), GPG ASSUAN RPC commands can only use a keygrip to specify which key is to applied. There appears to be no key support for specifying a key to use from a fingerprint. GPG's smartcard daemon is invoked when the private keys reside inside external hardware tokens, the ~/.gnupg/private-keys-v1.d/#keygrip#.key files provides pointer information for the gpg-agent to direct the SCdaemon

If you want to talk, reach me at [email protected]. We likely have overlapping interests based upon this repository. A lot of effort went into developing this repository.

[drduh]

I've removed the statement and tried to better qualify what makes Yubikey secure. Please send a PR with any additional technical suggestions and improvements you may have. Thank you!