[tor-bugs] #24659 [Core Tor/Tor]: Wrap our sha2 interface in Rust which implements the appropriate traits

[Tor Bug Tracker & Wiki]

#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