Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Cryptography Should Be Written in Rust

briansmith.org

Post reply on HN
Print view View original

101–110 of 110 posts

Re: Rust Cryptography Should Be Written in Rust

#101

Post by cesaref »

wffurr wrote: post #70
cesaref wrote: post #64

I can't seem to fathom the why in this. Why is Rust different from, say, Python?

Unlike Python, Rust is efficient enough and suitable for low level bit twiddling to write fast crypto libraries without using an unsafe language like C.

So it's a safety concern, is that what this is about? Safety as in, thread safety that sort of thing? I personally would be more worried about correctness, and so i'm not sure what the win is over wrapping an existing library, like every other language does (ok, there are bound to be exceptions).

Re: Rust Cryptography Should Be Written in Rust

#102

Post by cesaref »

conradludgate wrote: post #73
cesaref wrote: post #64

I can't seem to fathom the why in this. Why is Rust different from, say, Python?

Well, let's put it this way. The python cryptography package contains rust code. The rust cryptography libraries are certainly not going to contain python code.

I wasn't clear, I mean, why should Rust have it's own implementation, with the cost and worries about correctness, and maintenance burden vs using an existing library, as is typically what other languages (e.g. Python) would do in this situation.

I don't see the benefit, that's what I was wondering about.

Re: Rust Cryptography Should Be Written in Rust

#103

Post by conradludgate »

cesaref wrote: post #102
conradludgate wrote: post #73

Earlier quoted context omitted.

Well, let's put it this way. The python cryptography package contains rust code. The rust cryptography libraries are certainly not going to contain python code.

I wasn't clear, I mean, why should Rust have it's own implementation, with the cost and worries about correctness, and maintenance burden vs using an existing library, as is typically what other languages (e.g. Python) would do in this situation. I don't see the benefit, that's what I was wondering about.

What library? Who maintains the library?

For some background, ring/rustls is a Rust library that replaces openssl because it doesn't have a good track record for vulnerabilities - especially those caused by memory safety issues.

Re: Rust Cryptography Should Be Written in Rust

#104

Post by wffurr »

cesaref wrote: post #101
wffurr wrote: post #70

Earlier quoted context omitted.

Unlike Python, Rust is efficient enough and suitable for low level bit twiddling to write fast crypto libraries without using an unsafe language like C.

So it's a safety concern, is that what this is about? Safety as in, thread safety that sort of thing? I personally would be more worried about correctness, and so i'm not sure what the win is over wrapping an existing library, like every other language does (ok, there are bound to be exceptions).

Well yes? Heartbleed? The majority of significant security bugs are memory corruption and data races, both of which safe Rust prevents by design.

Re: Rust Cryptography Should Be Written in Rust

#105

Post by agsgs »

adwn wrote: post #23
max_ wrote: post #2

So far the only solid use case for Rust that I have seen in applications where security is extremely important. 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?

For our client, we've developed a desktop application in Rust – with a thin GUI frontend in C++/Qt – to filter, process, and visualize sensor data streams (3D point cloud data from a Lidar). Each data stream was about 400-500 Mbit/s in 55k UDP packets per second, with support for at least 4 simultaneous streams. The focus was on high performance and development speed, security didn't matter at all. We chose Rust for…

[dead]

Re: Rust Cryptography Should Be Written in Rust

#106

Post by [deleted] »

adwn wrote: post #23
max_ wrote: post #2

So far the only solid use case for Rust that I have seen in applications where security is extremely important. 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?

For our client, we've developed a desktop application in Rust – with a thin GUI frontend in C++/Qt – to filter, process, and visualize sensor data streams (3D point cloud data from a Lidar). Each data stream was about 400-500 Mbit/s in 55k UDP packets per second, with support for at least 4 simultaneous streams. The focus was on high performance and development speed, security didn't matter at all. We chose Rust for…

[deleted]

Re: Rust Cryptography Should Be Written in Rust

#108

Post by Grimburger »

conradludgate wrote: post #96
Grimburger wrote: post #85

Earlier quoted context omitted.

> unsafe intrinsics 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 mean like AESENC which you should always be using if available? Yes. And make it not unsafe > Sometimes it's the only way to get some sort of constant time guarantees I don't think you understood the article then. Brian wants the constant time guarantees as an intrinsic in the std library, guaranteed by the compiler, and exposed as safe rust. > The rust fanclub obsession with calling things like that unsafe sim…

> Yes. And make it not unsafe

That's simply not possible, all intrinsics are unsafe by definition, the rust compiler can't check them for the same guarantees.

Re: Rust Cryptography Should Be Written in Rust

#109

Post by brobinson »

IshKebab wrote: post #77
brobinson wrote: post #34

Earlier quoted context omitted.

What if there are branches but both paths result in the same number of cycles being required to execute the instructions? Is it correct to say: "all branchless code runs in constant time, but not all constant time code is branchless"?

> all branchless code runs in constant time No - e.g. division is not constant time. You have to have branchless code and only use certain instructions. E.g. here is the list for RISC-V. https://github.com/rvkrypto/riscv-zkt-list/blob/main/zkt-lis... Most things except div/rem, branches and floating point are ok. Oh and obviously store/load.

Thanks, this is really interesting.

Re: Rust Cryptography Should Be Written in Rust

#110

Post by brobinson »

AlotOfReading wrote: post #47
brobinson wrote: post #34

Earlier quoted context omitted.

What if there are branches but both paths result in the same number of cycles being required to execute the instructions? Is it correct to say: "all branchless code runs in constant time, but not all constant time code is branchless"?

The subtlety is that eliminating branching isn't sufficient to have constant time code. A simple example is using trigonometric and transcendental opcodes. They don't branch (at the assembly level), but on x86 take variable amounts of time depending on the input operand. Very few algorithms actually use these opcodes though, so a more relevant concern is memory access due to variable latency. Even if you have that na…

Really interesting information, thank you.
Post reply on HN