<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/Cargo.toml, branch arti-v1.1.7</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.7</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.7'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2023-07-27T14:20:14Z</updated>
<entry>
<title>Include debug symbols in "bench" profile</title>
<updated>2023-07-27T14:20:14Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-07-05T21:03:29Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=3e8b8d035a110a8f55100029638246a179586597'/>
<id>urn:sha1:3e8b8d035a110a8f55100029638246a179586597</id>
<content type='text'>
Including full debug symbols makes the benchmark builds useful for
profiling too.
</content>
</entry>
<entry>
<title>Start implementing Proposal 327</title>
<updated>2023-07-27T14:20:14Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-06-28T22:15:17Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=e7aa1d6b6251102f9b2b0e382ad2a1f7b5b47ee5'/>
<id>urn:sha1:e7aa1d6b6251102f9b2b0e382ad2a1f7b5b47ee5</id>
<content type='text'>
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 &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>Reimplement Equi-X in Rust</title>
<updated>2023-07-27T14:20:14Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-06-28T22:08:29Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=16c9bdf1785516fc57589786a1a7f250c486e131'/>
<id>urn:sha1:16c9bdf1785516fc57589786a1a7f250c486e131</id>
<content type='text'>
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 &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>Reimplement HashX in Rust</title>
<updated>2023-07-27T14:20:06Z</updated>
<author>
<name>Micah Elizabeth Scott</name>
<email>beth@torproject.org</email>
</author>
<published>2023-06-28T21:59:46Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a8756f2bce9f0dba8e445baae82aab90aa9ad096'/>
<id>urn:sha1:a8756f2bce9f0dba8e445baae82aab90aa9ad096</id>
<content type='text'>
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 &lt;beth@torproject.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'add-tor-geoip' into 'main'</title>
<updated>2023-06-20T17:59:15Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-06-20T17:59:15Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=8d4ca94e192dc3d3e397f5f61f6b2c93fb46feac'/>
<id>urn:sha1:8d4ca94e192dc3d3e397f5f61f6b2c93fb46feac</id>
<content type='text'>
tor-geoip: Add new crate with GeoIP database functionality

See merge request tpo/core/arti!1239</content>
</entry>
<entry>
<title>tor-geoip: Add new crate with GeoIP database functionality</title>
<updated>2023-06-20T15:57:58Z</updated>
<author>
<name>eta</name>
<email>tor@eta.st</email>
</author>
<published>2023-06-13T14:27:14Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=d5632eacb2b0c03e6f250f6fbe435d921dea4f8e'/>
<id>urn:sha1:d5632eacb2b0c03e6f250f6fbe435d921dea4f8e</id>
<content type='text'>
- This adds a new crate, `tor-geoip`, which can parse and perform
  lookups in the GeoIP database C-tor already uses (generated by a
  maintenance utility in the C-tor codebase).
- We embed a copy of C-tor's databases with the crate and use
  `include_str!` to ship them with the binary, bloating its size
  somewhat.
  - This does, however, solve the problem of figuring out how to
    distribute these.
  - The plan is to gate this functionality behind a feature flag anyway,
    so the cost should be nil unless explicitly opted into.

Part of tpo/core/onionmasq#47.
</content>
</entry>
<entry>
<title>keymgr: Move the HS client and service key specifiers out of tor-keymgr.</title>
<updated>2023-06-15T17:16:33Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2023-06-13T10:29:27Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=eda974cd34753ca8dc17d699a86d978ff59c9f0e'/>
<id>urn:sha1:eda974cd34753ca8dc17d699a86d978ff59c9f0e</id>
<content type='text'>
The HS `HsClientSpecifier` and `HsClientSecretKeySpecifier` are moved to
`tor-hsclient`. The HS service secret key specifier stubs are moved to
`tor-hsservice`.
</content>
</entry>
<entry>
<title>keymgr: Add ArtiNativeKeyStore implementation skeleton.</title>
<updated>2023-06-15T17:15:30Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2023-05-30T15:08:18Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a2d0ee63ccf44eefdd71bdbc6a95bbb5a4ec2f38'/>
<id>urn:sha1:a2d0ee63ccf44eefdd71bdbc6a95bbb5a4ec2f38</id>
<content type='text'>
This adds implementation stubs for `ArtiNativeKeyStore`, and introduces
the traits needed to make the `KeyStore` APIs work.
</content>
</entry>
<entry>
<title>Rename tor-rpccmd to tor-rpcbase.</title>
<updated>2023-04-12T11:34:57Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-04-11T19:13:19Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=9a5f319a840bbbd906d64803a4992ea1e21b7d1f'/>
<id>urn:sha1:9a5f319a840bbbd906d64803a4992ea1e21b7d1f</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Start on a lower-level tor-rpccmd crate.</title>
<updated>2023-04-12T11:34:57Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-03-31T15:57:05Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a4660a4e0988cd3b1eb453c6757e1755665b6d72'/>
<id>urn:sha1:a4660a4e0988cd3b1eb453c6757e1755665b6d72</id>
<content type='text'>
This crate will hold the backend pieces of RPC interaction that
different parts of Arti get to implement.
</content>
</entry>
</feed>
