Skip to content

Reconsider distribution of cryptographic hash functions #9300

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

Closed
brson opened this issue Sep 18, 2013 · 7 comments · Fixed by #9744
Closed

Reconsider distribution of cryptographic hash functions #9300

brson opened this issue Sep 18, 2013 · 7 comments · Fixed by #9744

Comments

@brson
Copy link
Contributor

brson commented Sep 18, 2013

Per my own comment in #8989 we are shying away from rolling our own crypto. We already have SHA1, SHA2 and MD5 in libextra, but maybe we should not. If we want to completely eliminate these then SHA1 would need to move into librustc.

@bluss
Copy link
Member

bluss commented Sep 18, 2013

For completeness, the two pieces in libstd's public API:

  • SipHash which is a cryptographic hash (albeit with different properties than for example SHA-2).
  • IsaacRng which is documented as suitable for cryptographic purposes.

These two are clearly useful.

@DaGenix
Copy link

DaGenix commented Sep 22, 2013

So, I clearly disagree with the path that's been decided upon. If the goal of Rust is to create a safer language, I don't see why we'd want to avoid implementing security algorithms in that language and instead delegate them to more unsafe languages. However, since that is the decision, I don't think it makes any sense to implement a tiny subset of algorithms and ignore all the rest. I'll submit a patch to remove everything crypto related, but it might take me a few weeks to get together.

@thestinger
Copy link
Contributor

@brson: I think we should move this stuff out to a rust-crypto incubator repository and explicitly mark it as experimental + not necessarily secure in the README. At some point we're going to want this kind of thing in pure Rust, even if that's far down the road from now.

@Seldaek
Copy link
Contributor

Seldaek commented Oct 29, 2013

I for one think this is bad news. I hope this hypothetical rust-crypto at least makes it back into a rust-core-blessed repo somewhere. I wouldn't want such an important piece of code to be controlled by some random guy. This may save some rust-core maintenance hassle (although these algos are pretty much written in stone so I'm not sure what the burden really is once the language stabilizes) but it makes everyone less secure.

@zooko
Copy link
Contributor

zooko commented Oct 31, 2013

I, too, would like to see crypto algorithms implemented in pure Rust. I suppose it is up to someone to create a repo and put some source code there and ask for review. ☺

@alexcrichton
Copy link
Member

@DaGenix has done a lot of excellent work in this area and you can find it all at https://github.com/DaGenix/rust-crypto. The fate of libextra is still to be decided, but when we dissolve it into smaller packages, there may be a place for code like this, so hope isn't completely lost just yet!

@e-oz
Copy link

e-oz commented Nov 15, 2015

Sorry for bumping old thread, but I absolutely agree with @DaGenix. I realize rust-crypto is his work, but in security questions 100% trust can exist only to "builtin" functions.

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

Successfully merging a pull request may close this issue.

8 participants