#24659: Wrap our sha2 interface in Rust which implements the appropriate traits -----------------------------------------------+--------------------------- Reporter: isis | Owner: isis Type: enhancement | Status: | needs_review Priority: Medium | Milestone: Tor: | 0.3.4.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: rust, tor-crypto, review-group-34 | Actual Points: Parent ID: | Points: 1 Reviewer: catalyst | Sponsor: | Sponsor3-can -----------------------------------------------+---------------------------
Comment (by isis): Replying to [comment:13 isis]: > I've thought about this a bit more, and—since our C code that I'm wrapping is currently tested for correctness in C—I think that an easy workaround for this, would be temporarily (assuming we're eventually only going to require implementations in C ''or'' Rust, not both) doing what Chelsea Komlo's Rust tor logging code is doing: the wrapping implementation in release mode, and a dummy implementation in testing mode. For this, that would probably amount to a dev-dependency (Rust distinguishes between hard dependencies, optional dependencies, and "dev" or testing dependencies in Cargo.toml files) on [https://crates.io/crates/sha2 the sha2 crate]. This way, Rust code that is higher level (eventually) will actually be able to test correctness of results of functions which rely on the output of a hash function. (Probably we'll want to do the same for the [https://crates.io/crates/rand rand crate] when we wrap that. Except for the `rand` crate, it's a bit messed up, because we'll extremely want the `rand::Rng` trait in release/production in order to use generic code throughout the Rust ecosystem. Possibly we should nicely ask its maintainers to split the trait off into a separate crate, or otherwise rely on the fact that the crate is scheduled to be absorbed into libstd/libcore in Rust and just use it entirely, including calling it from C.) Err, sorry, I'm worried I wasn't explicit/clear enough. Let me try again, please. :) So, what I'm worried about isn't that somehow our hash functions in C are somehow incorrect. That would be absurd. Hash functions either pass test vectors or they don't, and it would be inconceivable for them to pass some vectors and fail others, that would undermine all cryptography based on the random oracle model. What I worry about is that, with the current code, there's no way to test higher-level, pure-Rust functionality. So for example, if I were to implement ed25519 signing in Rust for tor, with my `ed25519-dalek` [https://crates.io/crates/ed25519-dalek crate], which takes the hash function as a generic, i.e.: {{{#!rust /// Sign a message with this `ExpandedSecretKey`. pub fn sign<D>(&self, message: &[u8], public_key: &PublicKey) -> Signature where D: Digest<OutputSize = U64> + Default { }}} Hence, if we ever needed to test e.g. a Rust parser for descriptors, which contain ed25519 `ntor-onion-key-crosscert` signatures, we'd be unable to, since the test code can't call the signatures code because the signature code won't be able to call the digest code which wraps the C. This seems kind of bad moving forward, since so much of our code relies on hash functions. One long-term solution is to say that some things are only Rust ''or'' C, not both. Another solution is to do something like #25386, but I had a stab at that in this ticket, and it seems like we're not really moving forward in a sustainable way with testing linker issues. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24659#comment:14> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs