How many bits are GPG keys & does 32-bit collision problem affect GPGTools?
GPGServices 1.1.3 (601)
Recently, a site and some knowledgeable people raised concerns about 32-bit keys not correctly verifying duplicates when uploading keys to key servers. This results in key collisions (basically, it seems that longer bit keys are needed. This site describes it more fully. https://evil32.com. 1) Is this related to key length? 2) How many bits does GPGTools use for its keys and if this is a problem then is it non-trivial to move to, say, 128-bit keys? 3) Besides checking fingerprints, is there anything to be done? 4) If you guys can, please consider responding to this on your blog, including an explanation and its impact for GPGTools, and work-arounds or fixes? Thanks so much!
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Luke Le on 09 Jan, 2015 01:34 PM
Hi,
as far as I know the problem is not that the use of 32-bit keys, but rather that most people only use the 32-bit representation of the key fingerprint to identify their keys to others. This representation is rather easy to fake, so you should always check the entire fingerprint.
In addition there was in fact a bug in gnupg which didn't properly check that the key returned from the key server matches the fingerprint or key id of the key that was requested. So a malicious keyserver could return any key for that request.
This issue has been patched in recent versions of gnupg2 and such a recent version is included in GPG Suite Beta 4 which you can download from https://gpgtools.org
Steve closed this discussion on 08 Feb, 2015 08:49 PM.