Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

32bit key ids are not secure to use #10

Open
osminogin opened this issue Mar 24, 2016 · 5 comments
Open

32bit key ids are not secure to use #10

osminogin opened this issue Mar 24, 2016 · 5 comments

Comments

@osminogin
Copy link

I found examples of the use of 32 bit gpg key ids in the documentation and code. This is a bad behavior, because now it is very easy to generate a colliding 32bit key id with special software.

More information on trouble: https://evil32.com/

In my opinion, a good idea to specify in the documentation that short key ids are no longer safe.

Possible in gpget code is to completely eliminate processing of short ids. This is the current reality.

@brianredbeard
Copy link
Owner

Whoops. This issue slipped through the cracks. I'll put in some serious "WARN" messages on that. As you mentioned with the evil32.com link, this is just as much an issue of education.

As of right now the default behavior in gpg is still to display the 32bit id. This means for the average user they won't know the difference between their short id, long id, or full fingerprint. Speaking of that last point, I'm going to make sure that gpget will also support the full long fingerprint.

@brianredbeard
Copy link
Owner

It should also be noted that this is only relevant if the key id is specified with the -k flag. In my use, I'm always pre-loading the entire public key into the key ring and not specifying the key id on the CLI.

Nonetheless, still good to call out.

brianredbeard added a commit that referenced this issue Jul 20, 2016
The use of GPG short ids is insecure is insecure.  It is trivial to
create a colliding short id with the use of inexpensive hardware.  As
GPG still uses short ids as their default behavior, it is important to
meet users where they're at and while not causing things to break, we
should inform and discourage users from this practice.

Affects #10
@osminogin
Copy link
Author

Man, thank you for attention.

I fully agree that the most users don't understand difference between the short ids, long ids and fingerprint. I also understand that GnuPG use short ids in CLI in most cases, but I believe that all the new GPG oriented software should take into insecurity 32bit ids.

Yes, this issue - a special case. But it is possible to treat ALL security issues as theoretically and only for learning.

@brianredbeard
Copy link
Owner

After another month of thinking through this my opinions have evolved a bit. I'll summarize them as follows:

  1. Providing a warning on short ids really just adds a false sense of security. While it could be useful from an education perspective to let folks know about the perils of 32 bit identifiers, it won't change any behavior.
  2. the ante on this has been upped recently - it's now no longer even a hypothetical confusion
  3. As mentioned in that article, even long ids can now have collisions

In light of this in the coming weeks I will be:

  • remove support for short ids
  • change the warnings aroud "short ids" to fire on long ids
  • recommend the use of full fingerprints

Any other commentary is welcome, and thanks @osminogin for bringing this up!

@osminogin
Copy link
Author

osminogin commented Aug 24, 2016

Is really now very simple make collading short gpg ids (especially with videocard acceleration), is very simple make similar bitcoin address for donations and etc. Importantly it's now available even for script kiddies.

It may look like an of paranoia attack, but my opinion of the whole modern GPG oriented software should proceed from current reality. Thank you again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants