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

crypto/des: Docs do not mention that DES has serious known practical weaknesses #7148

Closed
gopherbot opened this issue Jan 18, 2014 · 5 comments

Comments

@gopherbot
Copy link
Contributor

by alex.gaynor:

The documentation should inform users that DES, because of it's small keysize, is
vulnerable to brute force attacks and should not be used for any new applications, and
existing applications should strongly consider switching.

Without such a warning, users reading this documentation alone may not be able to make a
good decision about encryption algorithms.
@ianlancetaylor
Copy link
Contributor

Comment 1:

I don't know if we can take responsibility for helping people choose a good encryption
algorithm.  Still, leaving for agl to decided.

Owner changed to @agl.

@gopherbot
Copy link
Contributor Author

Comment 2 by alex.gaynor:

Not sure if this is the right place to make this argument, but I'll put it here anyways
:-):
99.9% of everyone isn't educated on cryptography (here everyone means "software
engineers"). The result is that when developers go to make cryptographic decisions they
don't have the information to make good decisions. In basically any other domain of
software engineering, you can stumble around and just use any APIs you find, and when
one spits out the right answer, you roll with it.
This doesn't work in cryptography, because the thing at issue isn't the result, you
can't check the result and see if these bytes are secure, the thing at issue is the
process that produced them, and you either need to do some cryptanalysis, or you need
someone to let you know.
Developers don't know this, so they'll romp around looking for something named encrypt()
that takes a key and a plaintext and spits out what looks like nonsense bytes. Which
would be ok, except the API they'll find won't be secure, they need someone to point
them the right direction. Developers, as often as not, choose encryption algorithms
because the name sounded familiar, between that and the docs mentioning some nice USG
standards DES is in, what could be wrong with it!
Anyways, that's why I think cryptographic library authors have a responsibility to try
to inform their users about risks.

@ianlancetaylor
Copy link
Contributor

Comment 3:

Sounds nice in theory, but these things change and we can't possibly keep such
documentation up to date.
If we say anything perhaps we should add a disclaimer to all crypto packages saying
"please get expert help in choice of algorithms."

@dominikh
Copy link
Member

Comment 4:

The implication of "99.9% of everyone isn't educated on cryptography" shouldn't be
"throw them another bone so they can stumble along a bit longer", it should be "they
shouldn't be using cryptography primitives". 
There are bookshelves full of books on cryptography. A comment saying "don't use DES" in
API documentation isn't going to cut it. Now they'll use AES in ECB mode. Or they'll
implement a OTP with reused keys. Or they'll make one of the other possible mistakes, of
which there are probably hundreds.

@agl
Copy link
Contributor

agl commented Jan 21, 2014

Comment 5:

I think that I agree that "don't use DES" in the documentation isn't going to save
anyone who didn't already know that and isn't going to help anyone who wouldn't
otherwise screw things up.
It's on my TODO for 1.3 to add a simple seal/open API into the core libraries, although
I'm not sure what form that'll take yet.

Status changed to WontFix.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants