[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24659 [Core Tor/Tor]: Wrap our sha2 interface in Rust which implements the appropriate traits
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs