I would say that Rust would be a better choice rarher than patching memory safety on top of C. But I think the reason for this is that most, if not all, cryptographic reference implementations are in C. So they want to use existing reference implementations without having to port them to Rust.

IMO cryptographers should start using Rust for their reference implementations, but I also get that they'd rather spend their time working on their next paper rather than learning a new language.

▲ _flux 4 days ago | parent | next [-]

I'm not a practioner of cryptography, but I would be wary about timing attacks that might become possible if such a dynamic runtime is introduced. At least relevant pieces of code would need to be re-evaluated in the Fil-C environment.

But maybe you could use C as the "glue language" and then the build better performing libraries in Rust for C to use. Like in Python!

▲

mbrock 4 days ago | parent [-]

Good call! Fil-C does in fact have a way to let you build and run OpenSSL with its constant time crypto. I don't know how this works exactly but I guess it's relatively easy to guarantee it's safe.

	▲	kragen 4 days ago \| parent [-]
		How easy is it to link Rust code with C compiled with Fil-C's ABI?

▲ pjdesno 4 days ago | parent | prev | next [-]

The original poster got pretty much all of Debian running in Fil-C, in a fairly brief amount of time.

Re-writing even a single significant library or package in Rust would take exponentially longer, so in this case Rust would not be "a better choice", but rather a non-starter.

▲ bangaladore 4 days ago | parent | prev | next [-]

Memory safety is a very small concern for most cryptographic implementations (e.g Side Channel attacks). Rust solves essentially none of the other concerns.

	▲	GTP 3 days ago \| parent [-]
		IIRC SHA3's reference implementation had an integer overflow in a counter that made finding collisions trivial, as it meant that some blocks of the input weren't considered.

▲ johnisgood 4 days ago | parent | prev [-]

> IMO cryptographers should start using Rust for their reference implementations

IMO they should not, because if I look at a typical Rust code, I have no clue what is going on even with a basic understanding of Rust. C, however, is as simple as it gets and much closer to pseudocode.

▲ Ar-Curunir 4 days ago | parent [-]

Good cryptographic code should match its algorithmic description. Rust enables abstractions that allow this. C does not. That you have some familiarity with C and not Rust should not be a contributing factor.

I say this as someone who has written cryptographic code that’s been downloaded millions of times.

▲ johnisgood 3 days ago | parent [-]

The problem in terms of reference implementations is exactly the abstractions. Reference implementations should be free of abstractions and should be understandable. Abstractions make code much less understandable.

I say this as someone who has been involved in cryptography and has read through dozens of reference implementations. Stick to C, not Python or Rust, it is much easier to understand because the abstractions are just there to hide code. Less abstractions in reference implementations = better. If you do not think so, I will provide you a code snippet of a language of my own choosing that is full of abstractions, and let us see that you understand exactly what it does. You will not. That is the point.

▲ Ar-Curunir 3 days ago | parent [-]

Abstractions are the only way to make sense of cryptography. Pretending otherwise leads to cross layer bugs and vulnerabilities. Of course bad abstractions are bad, but that doesn’t mean no abstraction is good.

Feel free to post your challenge snippet.

▲ johnisgood 3 days ago | parent [-]

  pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {
    fn inner(path: &Path) -> io::Result<Vec<u8>> {
      let mut file = File::open(path)?;
      let mut bytes = Vec::new();
      file.read_to_end(&mut bytes)?;
      Ok(bytes)
    }
    inner(path.as_ref())
  }

"aBsTraCtiOnS aRe gOod"... Right.

Reference implementations must NOT have abstractions like this. Rust encourages it. Lots of Rust codebase is filled with them. Your feelings for Rust is irrelevant. C is simple and easy to understand, therefore reference implementations must be in C. Period.

...or Common Lisp, or OCaml... why not?!

▲

Ar-Curunir 3 days ago | parent [-]

(a) that is a fairly easy to understand piece of code. Are you complaining about the definition of the inner function?

(b) the equivalent C code would look pretty similar.

▲

johnisgood 3 days ago | parent [-]

(a) I'm complaining about the messed up syntax and symbol soup.

https://github.com/ioccc-src/winner/blob/master/2024/burton/...

This code is fairly easy to understand, too, then.

(b) No, it would definitely not look "pretty similar".

(c) So what? You talked about abstractions in cryptographic code. Abstractions are layers to hide things. That is bad in crypto code.

	▲	Ar-Curunir 2 days ago \| parent [-]
		Hiding things is totally great in crypto code! When I’m implementing signature verification, I shouldn’t have to worry how the underlying, eg, field or elliptic curve algebra is implemented! In fact there have been many crypto bugs which insufficiently abstract this kind of stuff away.