Possible bug in "fingerprint" lookup for private keys in MultipartEncrypted.SignAndEncrypt

[polterguy]

When I type in my fingerprint for my key, then it cannot find my key. If I however type in the ID of my key (which is a much shorter 32 bit value), then it will find my ID.

I was of the impression that if you used a SecureMailboxAddress to sign a message, then the "fingerprint" would be what for instance my GPG Keychain app shows as the fingerprint (which is a REALLY long hex string, 152 bit or something), while it is actually necessary for me to type in the ID, since it won't find my private key if I type what is actually the fingerprint ...?

Is this expected behaviour or is this a bug ...?

[jstedfast]

I guess I was assuming that the 'fingerprint' was the ID for PGP. Maybe I can make it check both... but I'm not sure how to get the fingerprint from BouncyCastle.

I may have to explain this in the docs instead.

[jstedfast]

This now matches either the key id or the fingerprint.

[polterguy]

Are there any security issues related to using the ID instead of fingerprint ...?
The ID is 32 bits, while the fingerprint is 152 bits, so I assume there theoretically can be two keys with the same ID ...?

The reason why I am asking, is because I am creating a WebMail client with crypto support. Hence theoretically there might be a "gazillion" users, and if some of the IDs are the same, theoretically one can retrieve the wrong key. Which the password should guard against I presume, still retrieving the wrong key, with the right password, would probably trigger an exception, meaning it would be impossible to sign a message for a user who has a private key with the same ID as some other key in the system ...

In addition, I am also considering creating support for automatically downloading certificates from the Key Ring servers from my system, which would increase the likelihood of having to certificates with the same ID, etc ...

32 bits are relatively unlikely there will ever be any that are the same, statistically, but still ...

Saw your enhancement label just now, hope that kills my worries ...

Thx :)

[polterguy]

Brilliant!! I owe you a LOT of candy 💃

[polterguy]

BTW, while we're at it, what is the logical functionality occurring when you do not supply en email address (string.Empty address), but supplies the fingerprint (now the ID)

I mean, I obviously know what is happening, which is that it exclusively use the ID (next release this can be fingerprint too, I assume) to lookup the key. But what if I supply BOTH an email, AND an ID (fingerprint in future release), will it check both the address and the fingerprint ...?

And what happens when the email address is wrong, but the fingerprint is correct. Will it still fetch the key ...?

[jstedfast]

Well, you can't specify an empty email address...

If you use a SecureMailboxAddress, it will only use the fingerprint (or key id currently) to look up the key.

[polterguy]

OK, so I will have to create a "dummy address", such as "[email protected]" if I don't know the email address, but I do know the fingerprint/ID ...?

[jstedfast]

Well, surely you must have an email address or you wouldn't be able to send the message... right?

[polterguy]

Of course, but that email address might not necessarily be neither an existing valid email address, nor might the message be created for transporting over an SMTP server ... ;)

[jstedfast]

MimeKit 1.2.18 just released to nuget fixes this.