Description Thomas Wolf 2019-05-22 02:21:22 EDT

BouncyCastleGpgKeyLocator currently finds the private key corresponding to a public key obtained from the pubring.kbx keybox by iterating over all files in the gnupg/private-keys-v1.d directory. It tries to parse all of them as SExpr private keys until it finds one that matches the given public key.

This also attempts to parse files that are not private keys at all, and depending on the number of key files in that directory, it may be needlessly inefficient.

The directory is gpg-agent's private key repository, and how exactly and under what names it stores private keys there is in theory an implementation detail of GPG. However, the computation of the hash used in the file names is in libgcrypt and will, according to the main author of GPG, remain stable.[1] GPG calls this hash the "keygrip".

Private key files in gnupg/private-keys-v1.d have filenames of the pattern

  [0-9A-F]{40}.key

where the 40 hex digits are the keygrip, which is a hash of the public key parameters. In GPG, it's computed in libgcypt, function gcry_pk_get_keygrip, and there's also an alternate C implementation at [2].

I have not found anything corresponding in Bouncy Castle nor any other Java implementation, though. But basically it _is_ possible to re-implement this algorithm in Java and determine the right filename up front, so that one doesn't have to scan all files in that directory.

At least we might perhaps limit the file scan to paths matching the pattern given above to not even attempt to parse files that have different names.

[1] http://gnupg.10057.n7.nabble.com/GnuPG-2-1-x-and-2-2-x-keyring-formats-td54146.html
[2] https://github.com/riboseinc/rnp/blob/e6c7fef/src/librekey/rnp_key_store.cpp#L952