<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-llcrypto/src, branch arti-v1.4.5</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.5</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.5'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2025-07-07T15:50:04Z</updated>
<entry>
<title>Temporarily suppress mismatched_lifetime_syntaxes.</title>
<updated>2025-07-07T15:50:04Z</updated>
<author>
<name>Gabriela Moldovan</name>
<email>gabi@torproject.org</email>
</author>
<published>2025-07-07T15:50:04Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a11b611466a5a73f5e06a0aabd17284a57d12fe3'/>
<id>urn:sha1:a11b611466a5a73f5e06a0aabd17284a57d12fe3</id>
<content type='text'>
See #2060.
</content>
</entry>
<entry>
<title>tor-llcrypto: Removed dependency on `once_cell`</title>
<updated>2025-06-15T02:11:18Z</updated>
<author>
<name>hashcatHitman</name>
<email>3924-hashcatHitman@gitlab.torproject.org</email>
</author>
<published>2025-06-15T01:39:58Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=5d9d8ba058e01ee698cb829299fd0ab663c151c1'/>
<id>urn:sha1:5d9d8ba058e01ee698cb829299fd0ab663c151c1</id>
<content type='text'>
- Replaced `once_cell::sync::Lazy` with `std::sync::LazyLock`.

Signed-off-by: hashcatHitman &lt;3924-hashcatHitman@gitlab.torproject.org&gt;
</content>
</entry>
<entry>
<title>tor-llcrypto: fix feature name typo</title>
<updated>2025-06-09T16:01:35Z</updated>
<author>
<name>Steven Engler</name>
<email>opara@torproject.org</email>
</author>
<published>2025-06-09T16:01:35Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=456f6759c98229a2dd8a7bfaba032cf4d35208fc'/>
<id>urn:sha1:456f6759c98229a2dd8a7bfaba032cf4d35208fc</id>
<content type='text'>
</content>
</entry>
<entry>
<title>llcrypto: Document some design choices from CautiousRng.</title>
<updated>2025-03-24T19:11:48Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-24T16:39:41Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=d3ba62b6e9bfa9d138042a062838c65d7fa3ab0f'/>
<id>urn:sha1:d3ba62b6e9bfa9d138042a062838c65d7fa3ab0f</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Use an EntropicRng trait to enforce key generation rules.</title>
<updated>2025-03-24T19:11:48Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-20T15:09:08Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=8a33afe155e9bd29d9302b4b44dd5843d00866db'/>
<id>urn:sha1:8a33afe155e9bd29d9302b4b44dd5843d00866db</id>
<content type='text'>
We want to require that whenever we generate a key that's persistent
(stored in KeyMgr), it's going to be made from a stronger-than-usual
Rng.  This trait helps us enforce that.

We also add a FakeEntropicRng struct to use for testing.

Note that this turned up a case that we'd missed, which required
an internal change in tor-hsservice.
</content>
</entry>
<entry>
<title>Use CautiousRng for keys going into the KeyMgr.</title>
<updated>2025-03-24T19:10:21Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-20T14:51:44Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=71ec7a3c6e563c4107ff62ea003794c6a31e45a6'/>
<id>urn:sha1:71ec7a3c6e563c4107ff62ea003794c6a31e45a6</id>
<content type='text'>
</content>
</entry>
<entry>
<title>llcrypto: new CautiousRng for constructing long-lived keys</title>
<updated>2025-03-24T19:10:21Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-20T14:26:56Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ee7c15868e916bc7dbbd26e707077c452dd5d452'/>
<id>urn:sha1:ee7c15868e916bc7dbbd26e707077c452dd5d452</id>
<content type='text'>
This Rng combines inputs from several sources,
including OsRng, to minimize the likelihood
of falling to a vulnerability in any particular one.
</content>
</entry>
<entry>
<title>squash! Upgrade rand dependency to 0.9.</title>
<updated>2025-03-18T16:09:44Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-18T14:47:35Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=895bc807f106e359d35522a3ad5f288ba6cf6a9c'/>
<id>urn:sha1:895bc807f106e359d35522a3ad5f288ba6cf6a9c</id>
<content type='text'>
- The Rng::gen() functions have been renamed to Rng::random().
</content>
</entry>
<entry>
<title>llcrypto: add an rng compatibility shim for dalek-crypto</title>
<updated>2025-03-18T16:09:44Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-18T13:24:41Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=9e4de6cbfe5cef6076b89f7a94a5232d47b980dd'/>
<id>urn:sha1:9e4de6cbfe5cef6076b89f7a94a5232d47b980dd</id>
<content type='text'>
dalek-cryptography is still on rand 0.8, so we need a compatibility
shim for the Rng.

Fortunately, since we merged interface-abstraction-of-the-daleks
(!2868), we no longer need to propagate this compatibility layer
throughout our codebase.
</content>
</entry>
<entry>
<title>Wrap ed25519-dalek types.</title>
<updated>2025-03-18T12:45:28Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2025-03-17T18:31:42Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=d50e945a5286d89d75892878ff3aa9ed7ebed1f7'/>
<id>urn:sha1:d50e945a5286d89d75892878ff3aa9ed7ebed1f7</id>
<content type='text'>
With this change, we'll no longer need to expose the types from
dalek-cryptography as part of our API, and we'll have more freedom
to switch ed25519 implementations, or to upgrade to a newer
`rand` ahead of their schedule.

Unlike with x25519-dalek, I had to tweak the API a bit: There's no
way to get a &amp;PublicKey out of a Keypair now, and implementing the
old ed25519-dalek traits seemed unnecessary.
</content>
</entry>
</feed>
