3 ms·

> We've previously made the decision not to distribute any crypto with Rust at all, but this is probably not tenable since crypto is used everywhere. This is p

> We've previously made the decision not to distribute any crypto with Rust at all, but this is probably not tenable since crypto is used everywhere. This is pretty much why I haven't used Rust for any serious application development. Any HTTP or TCP connection I'd want to make would be over TLS and there are better options than importing c crypto libraries in Rust. I get what they're trying to do, and the conservative nature is admirable but I just want to "get things done" and while Rust is nice not having crypto is as is mentioned not tenable for application developers. Crypto is very critical. Many people do not want their application to send their critical data in the clear.

tinco 12y ago
Did you read to the end of the paragraph where they say that they're going to implement crypto? They're not insecure about being able to make a workable crypto api. They are aware that it's not a good idea to implement crypto in a high level language that's not been engineered for security yet. Their solution is to wrap a proven C crypto library, which is probably what good Go and JVM languages do also (I wouldn't trust one that doesn't) and it's probably going to be ready within a month or two. edit: just an aside, why would you terminate your SSL in Go/Java, it's good practice to have a proxy like nginx or haproxy do that for you.
- leorocky 12y ago
  > Did you read to the end of the paragraph where they say that they're going to implement crypto? I did, they said it would take a very long time. > Their solution is to wrap a proven C crypto library This is good. I don't have a problem with that, because that's what you'd have to do yourself right now if you wanted to do any kind of basic crypto with rust, include a C library and wrap it with boiler plate just to get it working. > which is probably what good Go and JVM languages do Nope, Go implemented their own crypto: http://golang.org/src/pkg/crypto/elliptic/p224.go http://golang.org/src/pkg/crypto/elliptic/p224.go http://golang.org/src/pkg/crypto/ http://golang.org/src/pkg/crypto/
  - tptacek 12y ago
    Golang had subject matter experts to do that work.
    - deleted 12y ago
      [deleted]
- numbsafari 12y ago
  Here's the go crypto, written in go (and some hand-crafted assembly): https://code.google.com/p/go/source/browse/#hg%2Fsrc%2Fpkg%2Fcrypto https://code.google.com/p/go/source/browse/#hg%2Fsrc%2Fpkg%2... and, in case you are curious: https://groups.google.com/forum/#!topic/golang-nuts/0za-R3wVaeQ https://groups.google.com/forum/#!topic/golang-nuts/0za-R3wV...
ape4 12y ago
There must be external libraries you can use. Or curl.
Hemospectrum 12y ago
There may be further reasons they don't want to ship crypto libraries as part of the Rust language distribution when it's not yet even properly out the door. That doesn't stop third parties from writing crypto libraries in Rust and then distributing them separately from the core platform. I can think of a couple obvious reasons why they would take this approach: (1) Crypto is hard, and they want to get the core platform out the door in a usable form on a relatively tight schedule. (2) Designating an official Rust crypto solution would be a social statement about what crypto code you're supposed to use in Rust, even if the quality of the code itself is inferior due to being newly written and unvetted. This is riskier than just using existing C libraries, because at least now they can't be blamed for any horrible security bugs in libraries they didn't write. If you'd only read past the specific sentence you quoted, you'd see that they do have plans to build crypto solutions in Rust, but that they're taking an extremely conservative approach to making it happen, and developing it "out of tree," ie. not as part of the Rust language codebase. Moving conservatively with respect to crypto development is not inappropriate. I'm sure you understand the sensitive nature of crypto libraries and why they need to be treated with as much care as possible.
- leorocky 12y ago
  I totally agree with everything you've said and I did read the entire paragraph, but speaking as an application developer as long as crypto is an issue in Rust, because there aren't libraries and they haven't yet implemented crypto, Rust is not a good option. I'm not trying to write a middlebrow dismissal, I'm simply explaining honestly why I don't use Rust and why I will not use Rust for the foreseeable future. The implication being that it's not just about me, but any application developer would pass on Rust as long as the only crypto options are to import c libraries. I could be mistaken in this.
  - iopq 12y ago
    If you can link against crypto libraries written in C, why is that an issue? If Rust 1.0 comes out with the SMALLEST amount of features possible that's not a problem, since you can always add more features in a backwards-compatible manner. You can't take away a badly-designed stdlib. Now people already use your poorly-designed APIs. You have to support them for 50 years.

tinco 12y ago

Did you read to the end of the paragraph where they say that they're going to implement crypto? They're not insecure about being able to make a workable crypto api. They are aware that it's not a good idea to implement crypto in a high level language that's not been engineered for security yet. Their solution is to wrap a proven C crypto library, which is probably what good Go and JVM languages do also (I wouldn't trust one that doesn't) and it's probably going to be ready within a month or two. edit: just an aside, why would you terminate your SSL in Go/Java, it's good practice to have a proxy like nginx or haproxy do that for you.

leorocky 12y ago
> Did you read to the end of the paragraph where they say that they're going to implement crypto? I did, they said it would take a very long time. > Their solution is to wrap a proven C crypto library This is good. I don't have a problem with that, because that's what you'd have to do yourself right now if you wanted to do any kind of basic crypto with rust, include a C library and wrap it with boiler plate just to get it working. > which is probably what good Go and JVM languages do Nope, Go implemented their own crypto: http://golang.org/src/pkg/crypto/elliptic/p224.go http://golang.org/src/pkg/crypto/elliptic/p224.go http://golang.org/src/pkg/crypto/ http://golang.org/src/pkg/crypto/
- tptacek 12y ago
  Golang had subject matter experts to do that work.
  - deleted 12y ago
    [deleted]
numbsafari 12y ago
Here's the go crypto, written in go (and some hand-crafted assembly): https://code.google.com/p/go/source/browse/#hg%2Fsrc%2Fpkg%2Fcrypto https://code.google.com/p/go/source/browse/#hg%2Fsrc%2Fpkg%2... and, in case you are curious: https://groups.google.com/forum/#!topic/golang-nuts/0za-R3wVaeQ https://groups.google.com/forum/#!topic/golang-nuts/0za-R3wV...

ape4 12y ago

There must be external libraries you can use. Or curl.

Hemospectrum 12y ago

There may be further reasons they don't want to ship crypto libraries as part of the Rust language distribution when it's not yet even properly out the door. That doesn't stop third parties from writing crypto libraries in Rust and then distributing them separately from the core platform. I can think of a couple obvious reasons why they would take this approach: (1) Crypto is hard, and they want to get the core platform out the door in a usable form on a relatively tight schedule. (2) Designating an official Rust crypto solution would be a social statement about what crypto code you're supposed to use in Rust, even if the quality of the code itself is inferior due to being newly written and unvetted. This is riskier than just using existing C libraries, because at least now they can't be blamed for any horrible security bugs in libraries they didn't write. If you'd only read past the specific sentence you quoted, you'd see that they do have plans to build crypto solutions in Rust, but that they're taking an extremely conservative approach to making it happen, and developing it "out of tree," ie. not as part of the Rust language codebase. Moving conservatively with respect to crypto development is not inappropriate. I'm sure you understand the sensitive nature of crypto libraries and why they need to be treated with as much care as possible.

leorocky 12y ago
I totally agree with everything you've said and I did read the entire paragraph, but speaking as an application developer as long as crypto is an issue in Rust, because there aren't libraries and they haven't yet implemented crypto, Rust is not a good option. I'm not trying to write a middlebrow dismissal, I'm simply explaining honestly why I don't use Rust and why I will not use Rust for the foreseeable future. The implication being that it's not just about me, but any application developer would pass on Rust as long as the only crypto options are to import c libraries. I could be mistaken in this.
- iopq 12y ago
  If you can link against crypto libraries written in C, why is that an issue? If Rust 1.0 comes out with the SMALLEST amount of features possible that's not a problem, since you can always add more features in a backwards-compatible manner. You can't take away a badly-designed stdlib. Now people already use your poorly-designed APIs. You have to support them for 50 years.