<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-llcrypto/src/pk, branch arti-v1.4.3</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.3</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.3'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2025-03-18T16:09:44Z</updated>
<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>
<entry>
<title>Rename "memquota" feature to "memquota-memcost" when it's just HasMemoryCost (fmt)</title>
<updated>2024-10-16T13:48:29Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2024-10-16T13:48:29Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a8b2d247f35c0c5b014b6011caee2832c5f39d31'/>
<id>urn:sha1:a8b2d247f35c0c5b014b6011caee2832c5f39d31</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Rename "memquota" feature to "memquota-memcost" when it's just HasMemoryCost</title>
<updated>2024-10-16T13:48:11Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2024-10-16T13:43:47Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=6ee75b3866e374250a760822b4aab49aef70e930'/>
<id>urn:sha1:6ee75b3866e374250a760822b4aab49aef70e930</id>
<content type='text'>
It's not documented anywhere ATM.  I will do that in a followup MR.
</content>
</entry>
<entry>
<title>Some HasMemoryCost impls in tor-llcrypto</title>
<updated>2024-10-02T18:11:26Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2024-09-26T20:19:34Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=b99b6104923dc97d514fab0a7b60e9e98a3ba647'/>
<id>urn:sha1:b99b6104923dc97d514fab0a7b60e9e98a3ba647</id>
<content type='text'>
</content>
</entry>
<entry>
<title>tor-llcrypto: replace simple_asn1 dependency with der_parser</title>
<updated>2024-09-28T02:45:13Z</updated>
<author>
<name>Morgan</name>
<email>morgan@torproject.org</email>
</author>
<published>2024-09-28T02:21:23Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=0956b386580d5d75983a8faff4e3043654936698'/>
<id>urn:sha1:0956b386580d5d75983a8faff4e3043654936698</id>
<content type='text'>
</content>
</entry>
<entry>
<title>tor_hsservice: add `impl From&lt;&amp;FooPublicKeySpecifier&gt; for FooKeypairSpecifier` instances</title>
<updated>2024-09-09T16:08:10Z</updated>
<author>
<name>Adam Joseph F0B74D717CDE8412A3E0D4D5F29AC8080DA8E1E0</name>
<email>3587-amjoseph@gitlab.torproject.org</email>
</author>
<published>2024-09-07T07:24:16Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=2c60baee2ca6aa6c76f19d150c77d119f0d6ece4'/>
<id>urn:sha1:2c60baee2ca6aa6c76f19d150c77d119f0d6ece4</id>
<content type='text'>
This adds the following trivial `From` instances:

- tor_hsservice: impl From&lt;&amp;HsIdPublicKeySpecifier&gt; for HsIdKeypairSpecifier
- tor_hsservice: impl From&lt;&amp;BlindIdPublicKeySpecifier&gt; for BlindIdKeypairSpecifier
- tor_hscrypto::pk: impl From&lt;HsBlindIdKeypair&gt; for HsBlindIdKey
- tor_llcrypto::pk::ed25519: impl From&lt;ExpandedKeypair&gt; for PublicKey
- tor_keymgr::mgr: impl From&lt;TestKey&gt; for TestPublicKey
- tor::hscrypto::pk: impl From&lt;HsIdKeypair&gt; for HsIdKey
</content>
</entry>
<entry>
<title>keymanip: Make blind_pubkey exist unconditionally</title>
<updated>2024-08-21T14:41:11Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2024-08-21T13:50:27Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=eabea0226da288aaa2cfbf7a64eeccbc3fd5c8a1'/>
<id>urn:sha1:eabea0226da288aaa2cfbf7a64eeccbc3fd5c8a1</id>
<content type='text'>
Now it exists unconditionally so that we can have our assertion for
public key consistency happen unconditionally.  (Blinding secret
keys is not remotely in the critical path, so I'm not concerned
about the critical path.)

From a suggestion from Gabi on !2341.
</content>
</entry>
<entry>
<title>keymanip: Use doc(cfg(...)) in place of "Availability" sections</title>
<updated>2024-08-21T14:41:11Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2024-08-21T12:45:32Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=309e8220332a9e5f81954a621d8a02f0daf7aa00'/>
<id>urn:sha1:309e8220332a9e5f81954a621d8a02f0daf7aa00</id>
<content type='text'>
</content>
</entry>
<entry>
<title>llcrypto: Make `blind_keypair` build without hsv3-client.</title>
<updated>2024-08-21T14:41:11Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2024-08-14T13:06:02Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=34cd96eca10c321a44cea39f596161545853c3b6'/>
<id>urn:sha1:34cd96eca10c321a44cea39f596161545853c3b6</id>
<content type='text'>
The `blind_keypair` function should only call `blind_pubkey` when it
is present.

Also, fix the documentation: blind_keypair is a hsv3-service function,
not a hsv3-client function.

Closes #1504.
</content>
</entry>
</feed>
