| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Just running maint/add_warning after the rebase
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was hoping most of the program generator would get inlined, so we can
resolve a lot of the edge cases at compile-time. This patch gets us
close to that, adding many inline attrs and rewriting RegisterSet with
explicit unrolling and storage types that are easier for the optimizer
to reason about.
From the disassembly of the program generator, it's now mostly one big
function with a jump table. From callgrind instruction profiles, there
are no longer obvious hotspots in register set scanning loops. It also
looks like we're often keeping per-register schedule information all
loaded into machine registers now.
Keeping the Rng entry points non-inlined for now seems to be slightly
better, by a percent or two.
There's some work left to do in compiled programs, and maybe room for
improvement in the Program representation too. That will be in a future
patch.
Benchmark shows about 20% improvement on my machine,
generate-interp time: [75.440 µs 75.551 µs 75.684 µs]
change: [-24.083% -23.775% -23.483%] (p = 0.00 < 0.05)
Performance has improved.
Found 11 outliers among 100 measurements (11.00%)
5 (5.00%) high mild
6 (6.00%) high severe
generate-x86_64 time: [96.068 µs 96.273 µs 96.540 µs]
change: [-18.699% -18.381% -18.013%] (p = 0.00 < 0.05)
Performance has improved.
Found 10 outliers among 100 measurements (10.00%)
4 (4.00%) high mild
6 (6.00%) high severe
Signed-off-by: Micah Elizabeth Scott <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new tor-hspow crate with the first layers of support in
place for onion service client puzzles as described in Proposal 327.
The API here is experimental, and it's currently only implementing
the self-contained parts of the client puzzle. So, it can verify and
solve puzzles, but it has no event loop integration or nonce replay
tracking or prioritization code yet. These things seem like they would
eventually live in the same crate.
Signed-off-by: Micah Elizabeth Scott <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a new pure Rust implementation of the Equi-X algorithm
designed by tevador for Tor's onion service proof of work puzzle v1.
Equi-X is an asymmetric puzzle algorithm based on Equihash, with
N=60, K=3, the XOR replaced with modular addition, a 16-bit index
space, and HashX as the inner hash function.
Signed-off-by: Micah Elizabeth Scott <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new pure Rust implementation of the HashX algorithm
designed by tevador for Tor's onion service proof of work puzzle v1.
HashX is a lightweight family of randomly generated hash functions.
A seed, via blake2 and siphash, drives a program generation model
which randomly selects opcodes and registers while following some
constraints that avoid timing stalls or insufficient hash mixing.
The execution of these hash funcions can be done using a pure Rust
interpreter, or about 20x faster using a very simple just in time
compiler based on the dynasm assembler crate. This has been
implemented for x86_64 and aarch64.
Signed-off-by: Micah Elizabeth Scott <[email protected]>
|
| |\
| |
| |
| |
| | |
tor-proto: Extract Create message handling from Reactor::run_once()
See merge request tpo/core/arti!1441
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This helps reduce code duplication, as `CtrlMsg::Shutdown` and
`CtrlMsg::AddFakeHop` are now handled in multiple places.
|
| | |
| |
| |
| |
| |
| | |
I think it's safe to handle `ChanMsg::Create` separately, because
there's nothing for the reactor to do until the first hop of the circuit
is created (so blocking on this _should_ be alright).
|
| | |
| |
| |
| |
| |
| | |
This logic from `create_firsthop()` was extracted (copied) from
`Reactor::run_once()`. A future commit will update `Reactor::run_once()`
to use `create_firsthop()`.
|
| |\ \
| |/
|/|
| |
| | |
keymgr: Add KeyMgr::generate() for generating new keys.
See merge request tpo/core/arti!1433
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This will enable us to test the parts of `ArtiNativeKeystore::insert`
that _are_ implemented (such as the part where it creates the missing
directories).
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
fixes deadlock in TorClient::reconfigure
See merge request tpo/core/arti!1432
|
| | | | |
|
| | | | |
|
| | |/ |
|
| |/
|
|
|
|
|
|
|
|
|
| |
rustfmt has grown opinions about how let ... else ... ought to be
formatted. They don't always agree with our previous manual
decisions.
I think our policy is to always insist on rustfmt. When that version
of rustfmt hits stable, our CI will start to fail for everyone.
(Right now this discrepancy just causes trouble for contributors who
are using nightly by default.)
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
keymgr: API updates and other improvements
Closes #903
See merge request tpo/core/arti!1421
|
| | |\
| | |
| | |
| | |
| | | |
Keymgr api updates minor fixes
See merge request gabi-250/arti!1
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Trying to use a keystore that doesn't exist is `bad_api_usage!`.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This also removes the corresponding
`KeyMgrError::UnsupportedKeystoreSelector` error, because it's not
needed anymore.
|
| | | |
| | |
| | |
| | | |
keys from." (fmt)
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
keys from."
This reverts commit 38a6c74c7894dc96b16c9039cacc2a4023977b05.
This also updates some tests to make them compile with the reverted
version of the code.
|
| | |
| |
| |
| |
| | |
As with `KeyMgr::insert`, only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported.
|
| | | |
|
| | |
| |
| |
| | |
We'll need this to implement `Keystore::insert`.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This refactoring will make more sense later, when we give
`KeyMgr::get` an extra parameter that specifies which keystore to
retrieve the key from.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The concept of a "key bundle" would introduce a lot of complexity while
providing little to no gain.
Some context:
```
Originally, "key bundles" were meant to be the answer to the question
"which keystore should insert place keys in?":
https://gitlab.torproject.org/tpo/core/arti/-/blob/36606a66ddca9abd1595d13c9397bc812bf24cb5/crates/tor-keymgr/src/mgr.rs#L60-69
However, I'm not so sure anymore that "key bundles" are the answer. I
don't think there is any way we can "guess" where a key should go. When
inserting/generating a new key, we should either:
always write to the same, primary key store, OR require the user to be
explicit about which key store the new key should go in (by assigning an
ID to each key store and expecting the user to provide it when
inserting/generating new keys)
I prefer the latter option, because it provides more flexibility, which
we're going to need when implementing the key management CLI (which I
think should allow users to generate keys anywhere they want, e.g. arti
keymgr generate <key type> --keystore hsm ...)
```
For more details, see the discussion on #903.
Closes #903
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The caller uses `KeystoreSelector` to specify which keystore to insert
the new key into (only `KeystoreSelector::Id` and
`KeystoreSelector::Default` are supported for `insert`).
The ability to insert keys in a particular keystore will come in handy
when we implement the key management CLI (the CLI will have an option
for specifying the keystore to access/modify).
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This error will be returned by `KeyMgr` if the caller tries to access a
keystore that does not exist, or if the requested `KeystoreSelector`
cannot be applied.
|
