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

Add DES crypto #4157

Closed
wants to merge 1 commit into from
Closed

Add DES crypto #4157

wants to merge 1 commit into from

Conversation

schmee
Copy link
Contributor

@schmee schmee commented Jan 12, 2020

A very non-scientific benchmark here: https://gist.github.com/schmee/7860d017ec791170c20db19c14229b5b.

@shawnl @tiehuis any feedback is much appreciated!

@daurnimator daurnimator added the standard library This issue involves writing Zig code for the standard library. label Jan 12, 2020
@shawnl
Copy link
Contributor

shawnl commented Jan 12, 2020

What is the use case?

andrewrk
andrewrk previously approved these changes Jan 12, 2020
@andrewrk
Copy link
Member

andrewrk commented Jan 12, 2020

Don't forget to expose it from std and make sure the tests get run.

@lukechampine
Copy link
Contributor

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).

@schmee
Copy link
Contributor Author

schmee commented Jan 14, 2020

@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.

@kavika13
Copy link
Contributor

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.

@andrewrk
Copy link
Member

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.

@andrewrk andrewrk closed this Jan 15, 2020
@schmee schmee deleted the des branch January 15, 2020 19:45
@schmee
Copy link
Contributor Author

schmee commented Jan 15, 2020

No worries @andrewrk!

@nektro
Copy link
Contributor

nektro commented Sep 17, 2020

inclusion in the stdlib (which, at least to me, implies some degree of endorsement)

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.

@andrewrk
Copy link
Member

@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?

@nektro
Copy link
Contributor

nektro commented Sep 17, 2020

did you have an argument specifically on why DES should be in the std lib

other than the reason I listed above, not particularly. afaik I had not even heard of des before today.

@andrewrk
Copy link
Member

related: #5763 (comment)

@lukechampine
Copy link
Contributor

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants