mirrors/arti.git/crates/tor-hscrypto/src/pow, branch arti-v1.4.6

tor-hsservice: Make PowManager persist state.

2025-05-27T18:05:01Z

tor-hscrypto: Implement Display and FromStr for Seed.

2025-05-27T18:05:01Z

This is convenient for formatting filenames for the PoW nonce replay log.

tor-hsservice: Initial parts of PowManager.

2025-05-27T17:51:27Z

This adds PowManager, as described in doc/dev/notes/service-side-pow.md, hooks it into IptManager and Publisher, and adds code to publish and rotate seeds, and to keep a updated list of Verifier instances for currently active seeds.

squash! Upgrade rand dependency to 0.9.

2025-03-18T16:09:44Z

- The Rng::gen() functions have been renamed to Rng::random().

tor-hscrypto: Add Verifier::seed() helper function.

2024-11-25T18:20:11Z

tor-hscrypto: Add Seed::new.

2024-11-25T18:20:11Z

This includes the ability to generate a seed that does not share a head with the previously used seed, which is generally what we want to do.

tor-netdoc: Support writing pow-params line.

2024-11-25T18:20:11Z

I'm not particularly happy with the code that does the actual writing out of the pow-params line, in particular the error handling there seems very verbose. However, I don't know of a better way to structure it given that APIs I'm working with.

hs-pow: Effort type improvements.

2024-10-09T16:05:21Z

The Effort type didn't have any const constructor and we had to disassemble it to do any arithmetic. This adds a const constructor and int/float saturating arithmetic methods. Co-authored-by: Micah Elizabeth Scott

tor-hscrypto: Fixup broken doc links.

2024-10-09T16:05:21Z

Co-authored-by: Micah Elizabeth Scott

hs-pow: Refactor to prefer stub types rather than cfg sprawl.

2024-10-09T16:05:15Z

In this design, the thin multiplexing layer between PoW types is always available when onion services are in use, but the specific pow schemes (and their dependency libraries) are gated by crate features everywhere. There are now no new cfg() gates. When the pow-v1 scheme is disabled, we can parse `pow-params v1` lines into an empty type (so clients know a PoW scheme exists that might be supported if they were configured differently). We currently don't save the contents of unknown hsdesc items. On the relaycell side, the hs ext module already sets a strong precedent for keeping unrecognized data as a byte vec, and it doesn't provide a good way to signal soft parse errors like unrecognized optional extensions. There, the `v1` type is completely optional, and services lacking a pow scheme suggested by a client would see one of these 'unrecognized' blobs. This isn't necessarily helpful but it fits the rest of the design. Co-authored-by: Micah Elizabeth Scott