> ... ARM, Amazon Web Services, Google, and Microsoft [...] should support the Rust community by letting their experts help the Rust community create FIPS-validated cryptography libraries written entirely in safe Rust that expose safe and idiomatic Rust APIs.
Rust's large corporate sponsors need to step up to make these crates more broadly suitable for production.
Alone how much Azure Sphere gets sold as high security device, and the SDK is C only. There is a new preview support for Rust, yet nothing announced for the stable product, only C on that one.
It's not always possible to make the same security guarantees for these implementations. Software implementations of AES are frequently vulnerable to cache timing attacks, for example (e.g. [1]); even simple operations integer multiplication may not be constant-time on some architectures.
On the other hand, most of the security problems found in OpenSSL are not in the core cryptographic functions. They're in the networking and certificate management machinery. All that should definitely be in Rust.
You mean like AESENC which you should always be using if available?
The rust fanclub obsession with calling things like that unsafe simply because it has the same keyword in front of it is fairly ridiculous.
> inline assembly
Sometimes it's the only way to get some sort of constant time guarantees.
You can write constant time code in Rust by carefully making sure your code only compiles to constant time instructions without branches, but you'd really want some kind of annotation on the code to enforce that.
That's mostly a guess though.
I know constant time operation is important for these algorithms, but couldn't I do this with a timer? Call the algorithm, store the result, return the result exactly one second (an eternity in CPU time) after it was called. Basically put a timer wrapper around the actual cryptography algorithm. It would harm latency, but not throughput.
This is a honest question I'm hoping to have answered.
Not wonder it is becoming the de-facto language for building applications in the blockchain space.
Does anyone else use Rust outside the blockchain/cryptography space? What are you working on?
Now that I've been using rust for ~5 years, I reach for rust for when I have to do almost anything else. I write small backend services in rust[1], and small utilities that would previously have been python scripts[2]. The only thing I still use any other language for is python for writing test scripts + interactive data exploration, and typescript for front end stuff. We still use a lot of C for firmware because the Rust target support isn't as good as C yet.
[1] you might argue that Go might be better suited for this, but I disagree. The lack of null safety and less strict typing would come back to bite me a lot. A typical backend service we write is 10x simpler than our simulation engine so 1) compile times are approx the same as the project is small and 2) we usually don't care that much about performance for these services so we can just clone or RC away any problems we might have with the borrow checker. Swift might be a nice, but the ecosystem isn't there for backend apps last time I looked.
[2] Total LoC for small scripts ends up being about the same for python/rust in my experience. Development time is approx the same, but I much prefer maintaining small rust apps when I come back to it after 6 months. You _can_ set up safe and maintainable python projects with external libraries for validation, but its too much effort when rust has it all out of the box. Also, python deployment/venv management is still immensely frustrating
I work at Materialize which is building database software in Rust. One of my coworkers blogged about our experience with the language here: https://materialize.com/blog/our-experience-with-rust/
For the business im building the frontend is written in js but everything on the backend is rust. i needed one highly multithreaded realtime server and rust was the right choice for that. For everything else (api, file server) I decided to just use rust too, maintaining a node backend and a rust backend and having to deal with typescript build systems when i could just use rust for everything made my life easier.
What ive found is that open source authors interested in releasing libraries in python and nodejs choose to write it once in rust then release python and js libraries using rust ffi.
See polars, yrs, rapierjs, lancedb, candle, etc.
It's pretty popular for AWS Lambda functions.
Pretty popular for terminal / shell applications.
Definitely a great way to write wasm for compute or graphics intensive browser/web apps.
There are a few places where I wouldn't recommend it - for beginners, when compile time is really important (e.g. as a scripting engine in games), or where you need a repl (science).
But otherwise it's a better choice than most languages for most tasks.
We chose Rust for its unique position in the performance/productivity tradeoff space, and didn't regret it even for a second. There's no way we could have pulled this off with C++ in the same time, especially the bug-free parallelization.
I'm building an OS in rust, and write most firmware with rust too.
Really?
Solana [0] a top 10 market cap cryptocurrency is written in Rust and so is its smart contracts.
NEAR Protocol is another [1] one as well as Sui [2] and Polkadot [3] written and using Rust.
[0] https://github.com/solana-labs/solana
[1] https://github.com/near/nearcore
Been a great choice even with trade offs like needing to train some hires and compilation speeds.
It's nicer writing in Rust than JS, no GC makes Rust a good WASM candidate, theoretically the performance can be better if you're careful, people take 2D game engines more seriously in lower level languages, and it keeps the door open for shipping on Steam later.
I've found it much slower to develop in, though. Compilation times are an issue and after working in JS for decades I realize how big the JS ecosystem is compared to something like Rust.
I doubt the decision was a good choice overall in terms of trying to ship an MVP, but it might still pay dividends for a finished product, if the game gets there, due to having a higher cap on performance
Playing devil's advocate, when is security not extremely important, except maybe in throwaway bash script-type applications?
* Small things for one's personal use or local network use only
* Quickly prototyped experiments, as long as they're not used in production
Like, you need to be able to sandbox mods if they're a thing, and Rust's memory safety only handles a tiny part of that.
Work is all about Java, .NET, Web and mobile OSes, Rust hardly brings anything to the table there, other than less capable tooling, higher attrition with existing ecosystem and complexity in designing borrow checker friendly algorithms versus automatic memory management.
But that's basically anything that touches the internet.
Not having buffer overflow vulnerabilities in your communications code is huge.
Cross-platform desktop app development, systems programming and authorization which is still cryptography related, I guess.
I misread that at first as saying it already did and was rushing to the comments to say "like hell it does!"-- but this is a difficult situation given that it doesn't really even exist in C where it would be easier to provide.
Technically, since Intel and AMD won't make guarantees that operations like multiplies won't have data dependent timing no language on these popular systems provide what is needed, at least in theory. (In practice things are somewhat better).
Ignoring the processor interface issues, it would be totally rad if there were types in rust for secrets that were guaranteed to get suitable handling. But doing so would probably require architectural changes to LLVM...
Like the Everest project.
I don't see the benefit, that's what I was wondering about.
Plus the syntax is not that different, you can hand transpose python -> rust.
You tend to the large bleeds before the small theoretical ones.
(But this is also irrelevant: assembly can be completely wrong and exploitable while also being perfectly well defined.)
Heartbleed also wasn't caused by ambiguity or undefined behavior, if you believe compiler writers.
