-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Add DES crypto #4157
Add DES crypto #4157
Conversation
What is the use case? |
Don't forget to expose it from std and make sure the tests get run. |
DES is completely broken, and even Triple DES has only 80 bits of security. Neither algorithm should be used in any modern application. Some applications might need to support DES for compatibility reasons, but I'd argue that that isn't sufficient justification for inclusion in the stdlib (which, at least to me, implies some degree of endorsement). |
@andrewrk some weird test failures on aarch64 and windows, will investigate. @lukechampine like it or not, 3DES is still used in many proprietary protocols and it is not going away any time soon. I disagree that including it in the stdlib constitutes any sort of endorsement, it is simply there in the toolkit if you need it. Let's leave the ultimate fate of this to #1629. |
Would it be valuable to flag uses of a 3DES function as a warning, similar to how Microsoft flags string function usage in their c lib if you use one of the overloads that doesn't take a length? The warnings MS did for the string functions are a bit controversial, but maybe using a warning for this case wouldn't be. |
I'm going to make the judgement call on this one, no DES in std. It appears to be cryptographically broken. The use cases for DES can take advantage of the planned package manager (#943) and a third party maintained package. Sorry @schmee for misleading you - I was unaware of the details and implications of DES until now. Consider this to be a little bit of #1629 happening now. |
No worries @andrewrk! |
that's not what std lib inclusion is for. particularly in the field of crpyto, the algorithms get added to the std lib so that end users can easily use an implementation that they can trust works. if someone is writing an app that needs X, then they're gonna find a way to use X. now, they could use the std lib or have to take the plunge to find and verify a third party dependency. it's not about endorsement, its about code trust and removing dependencies as well as improving interop in code that uses the same primitives. |
@nektro I agree with you in general; did you have an argument specifically on why DES should be in the std lib rather than as a third party package? Is there some common reason it still needs to be used? For example, for MD5, the zig self hosted compiler needs it for dwarf information, and so we may as well expose it in std and maintain it. Is there something like that for DES? |
other than the reason I listed above, not particularly. afaik I had not even heard of des before today. |
related: #5763 (comment) |
I realize my position here is kind of extreme, but I would even push for not exposing MD5. The only defensible reason to use MD5 in a new project is if you absolutely must be compatible with existing software that requires MD5. If you just need any old hash function, there are plenty of other options that are both safer and faster than MD5, just like there are many block ciphers that are safer and faster than DES. Whether it's in the stdlib or a third-party package, any DES or MD5 implementation should have a large warning that implores developers to only use them for compatibility reasons. Crypto packages don't need to be in stdlib to be trustworthy; on the contrary, most languages don't have crypto in their stdlib. AFAIK Go is the most prominent language to do so, and Go is now in the process of removing/deprecating various broken algorithms from its stdlib. If you really need DES or MD5, you can do what most programmers do: google "[lang] md5" and look for the GitHub repo with the most stars. |
A very non-scientific benchmark here: https://gist.github.com/schmee/7860d017ec791170c20db19c14229b5b.
@shawnl @tiehuis any feedback is much appreciated!