16 bit Key Id during key creation using Bouncy castle apis

[Susmit07]

Hello Team,

When we create a key, keys get associated with long 16-bit ones. But we have customer who are using 8-bit IDs.

And if they use the 8 bit ones the bc apis fails, is there any other way that we can allow the customer to use 8 bit keyIds rather than the 16 bit ones

Thanks,
Susmit

[peterdettman]

Please explain which actual part of our API you are using, perhaps including the specific code that "creates a key".

[Susmit07]

PGPSecretKeyRingCollection ringCollection = new PGPSecretKeyRingCollection(PGPUtil.getDecoderStream(keyInputStream), new BcKeyFingerprintCalculator()); Iterator<PGPSecretKey> innerSecretKeyIter = secretKeyRing.getSecretKeys(); String keyId = ""; while (innerSecretKeyIter.hasNext()) { PGPSecretKey secretKey = innerSecretKeyIter.next(); keyId = "0x" + Long.toHexString(secretKey.getKeyID()).toUpperCase(); }

Is the API secretKey.getKeyID() always return 16 bit, as I am getting 16 bit always when I invoke the API, or is specific to the PGP client-server which is creating the key ?

[dghgit]

I'd have to see the key, but if you look at what actually happens under the hood it's highly unlikely that a key id would come out as 2 bytes. If you look at PGPPublicKey, which is where the keyID is calculated, I think the only way this could happen is if it's a version 3 RSA key and the modulus has a string of zeros in the bottom 64 bits - the code above will drop leading zeros. I'd also regard that as highly unlikely though.

[Susmit07]

Didnt understood

Just a question: What is the best way to get key id?

1. Shall we get the fingerprintid first and take the last 8 bits of the finger print id
2. Call the publickey. getkeyid like above convert to a hex string in that case it will be last 16 bits of the finger print id

[dghgit]

Okay, so the actual KeyID is what is returned by getKeyID() - it's meant to be a 64 bit number. These days usually the last 64 bits of the fingerprint. GPG and many other apps display this as a 32 bit number by truncating the first 32 bits (so the shorter version is the last 32 bits of the fingerprint and the last 32 bits of what getKeyID() returns). I've never seen someone use a 16 bit one, but I would guess if they are following the convention the shorter KeyID will be the last 16 bits of the finger print (so the last 16 bits of what is returned by getKeyID()). I'd probably use Pack.longToBigEndian() to convert to bytes and then Hex.toHexString() for the ones you want.

[Susmit07]

Thanks for such prompt replies, but i hope using a small version of keyid all BC APIs will work fine correct?

[dghgit]

The APIs will expect the full one (64 bits) for their searching functionality, I'd suggest creating an intermediate table if you need to match from short IDs to actual keys.

[Susmit07]

Yes that is the way I designed, just wanted to cross verify with you guys, I added an extra column in my Cassandra table, and lept the mapping of short and longkeyIds