[tor-dev] Alternative Implementations of Tor
there have been, general information about how Tor works, and the testing of Talla. At the same time of the presentation I want to make all of the code for Talla available for the audience and public to see even though it at this point is not ready for "production usage" on the public Tor network. I hope this email will also allow us to discuss the wider concept of a network where there exists multiple implementations and the consequences of that. It might be there are other people hacking on a Tor implementation in their favourite language :-) I'm also on IRC as 'ahf' if anybody wants to talk about things regarding Talla that is outside of the scope of this email. Thanks you! Cheers, Alex. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXtHtlAAoJEPm8L+IrCM6PNl4P/08HCGnEpLADudaul9KX4bzL OqcygCP6AXpFUZdUqsD+hgPRgi97NYaNZas/hWimQyye3OfLw4EH29lukGiBrIZu Fp+bT2CAsan8Nn+Vb3rH0em1PPOyXYJ/qhYrXex/CPk5kY7CIatbwau9AgwylAKs 8G3wz364EQaAwq5v4BVTieenFxtNXfnjwtlPkNhtJUgRDwrj16v2IqwN1C6nIq2p E86Vok4ToWKwfzIshf2wESSGWHZ+K9bpZs+e1GnSkY4VgwpKE1Swp/8IhIlxa843 KO4EknByZIWqZrEORCd43nok88hW8tpbnuoMCE5HGMJzw/KTwQrSiS794cAnyhYt 6yokEUO3JdwRuJxLPzmLZc8tBniBaKuGfRbqC7XAurJkgq+UgLukgYWnlyvHlap+ RZaNpMqFQf8grMHWGd6ffxYzAcIc+935XN4D54Ua17seIpDHnKGKS04ZmKwBeCxy myafcqSxJsNrqYEN40QrtYdgU0zv74S75uU/DHAHcOcaPyAy5yHGAqAdOeGvtpV5 6/VAQDwbOPncfIntoU8FUjKcpKJBn5csltuknwDiWKFYLfAVqVawMYO2Ef12hDul 7SuqOksSL2Yx59m/0Bu8i0QARxZBw8x8TzuQ7RJkNmDeTR17ugDOIaBKV1Se9fgS JaHsOgLd/G0T7S4PT5vQ =IeQJ -END PGP SIGNATURE- -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal: Directory Compression Scheme Negotiation
Hello, Here's my draft proposal for extending the directory protocol to support compression scheme negotiation using the semantics of the HTTP protocol. This is part of the work that Nick and I are looking into for our Sponsor4 design. All feedback is highly appreciated :-) Cheers, Alex. Filename: xxx-directory-compression-scheme-negotiation.txt Title: Directory Compression Scheme Negotiation Author: Alexander Færøy Created: 2017-03-06 Status: Draft Target: N/A 0. Overview This document describes a method to provide and use different compression schemes in Tor's directory specification[0] and let it be up the client and server to negotiate a mutually supported scheme using the semantics of the HTTP protocol. Furthermore this proposal also extends Tor's directory protocol with support for the LZMA2 and Zstandard compression schemes. 1. Motivation Currently Tor serves each directory client with its different document flavours in either an uncompressed format or, if the client adds a ".z"-suffix to the URL file path, a zlib-compressed document. This have historically been non-problematic, but it disallows us from easily extending the set of supported compression schemes. Some of the problems this proposal is trying to aid: - We currently only support zlib-based compression schemes and there is no way for directory servers or clients to announce which compression schemes they support. Zlib might not be the ideal compression scheme for all purposes. - It is not easily possible to add support for additional compression schemes without adding additional file extensions or flavours of the directory documents. - In low-bandwidth and/or low-memory client scenarios it is useful to be able to limit the amount of supported compression schemes to have a client only support the most efficient compression scheme for the given use-case and have the directory servers support the most commonly available compression schemes used throughout the network. - We add support for the LZMA2 compression scheme, which yields better compressed size and decompression time at the expensive of higher compression time and higher memory usage. - We add support for the Zstandard compression scheme, which yields better compression ratio than GZip, but slightly worse than LZMA2, but with a smaller CPU and memory footprint than LZMA2. 2. Analysis We investigated the compression ratio, memory usage, memory allocation strategies, and execution time for compression and decompression of the GZip, BZip2, LZMA2, and Zstandard compression schemes at compression levels 1 through 9. The data used in this analysis can be found in [1] and the `bench` tool for generating the data can be found in [2]. During the preparation for this proposal Nick have analysed compressing consensus diffs using both GZip, LZMA2, and Zstandard. The result of Nick's analysis can be found in [3]. We must continue to support both "gzip", "deflate", and "identity" which are the currently available compression schemes in the Tor network. Further to enhance the compression ratio Nick have also worked on proposal #274 (Rotate onion keys less frequently), #275 (Stop including meaningful "published" time in microdescriptor consensus), #276 (Report bandwidth with lower granularity in consensus documents), and #277 (Detect multiple relay instances running with same ID) which all aid in making our consensus documents less dynamic. 3. Proposal We extend the directory client requests to include the "Accept-Encoding" header as part of its request. The "Accept-Encoding" header should contain a comma-separated list of names of the compression schemes of which the client supports. For example: GET / HTTP/1.0 Accept-Encoding: zstd, xz, gzip, deflate When a directory server receives a request with the "Accept-Encoding" header included it must decide on a mutually supported compression scheme and add the "Content-Encoding" header to its response and thus notifying the client of its decision. The "Content-Encoding" header can at most contain one supported compression scheme. If no mutual compression scheme can be negotiated the server must respond with an HTTP error status code of 415 "Unsupported Media Type". For example: HTTP/1.0 200 OK Content-Length: 1337 Connection: close Content-Encoding: zstd Currently supported compression scheme names includes "identity", "gzip", and "deflate". This proposal adds two additional compression scheme named "xz" (LZMA2) and "zstd" (Zstandard). All compression scheme names are case-insensitive. The "deflate", "gzip", and
[tor-dev] Cross compiling Tor for Windows
Hello. I have recently been trying to wrap my head around some of the Windows/Unix I/O code of Tor to do an API experiment with the PT subsystem. While working on this I remembered that Nick did a cool trick during the development of the consensus diff feature where he managed to reproduce a Windows only test case failure with Wine on Linux using a cross compiled version of Tor that he build on Linux as well. I wanted to try out if I was able to make use of this "trick" as well and decided to write a short guide for setting up the cross compilation environment for Tor on Debian. The guide is published at https://github.com/ahf/tor-win32 The tor-win32 repository also contains a Makefile that will fetch and cross compile a minimal set of dependencies of Tor (OpenSSL, Libevent, and zlib) and Tor itself to the point where you should be able to run both tor.exe and the test suites in Wine. I hope this might be useful to someone else if they find themselves having a need to quickly try something out on "Windows" without actually having to install it -- remember though that this is not the same as running Tor and the test suites on an actual Windows machine, which is what many of our users are using! :-) Cheers, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Dormant Mode and pluggable transports
Hi, On Thu, Dec 13, 2018 at 04:15:56PM -0700, David Fifield wrote: > If transports need to become dormant too, then there needs to be some > way for tor to tell them to be. Now that https://bugs.torproject.org/28179 > (Handle output from PT processes with the event loop) is almost > finished, perhaps the stdin/stdout channel would work for it. A request > to become dormant really does apply to the entire PT process (not just a > single transport or connection), so it's a good match for a > process-global channel like stdin. The PT process could respond with a > "SIGNAL DORMANT" message on its stdout, which would inform tor that the > PT has understood the request and will try to become dormant. I've just opened bug #28849 for us to try to figure out how this should work both for the new process module itself, but especially for the only consumer of the process module right now: the pluggable transports. One part of this that especially affects PT's running on Windows is that we would like to disable the Process I/O timer on Windows (which currently ticks once a second) when we are in the dormant mode. This would probably mean that once the stdout or stderr pipe's buffer, in the PT process, is full writing to stdout/stderr will block which would effectively be the same result as described in ticket #26360 (which #28179 as a side-effect also happens to fix). The easy way out here would of course be to "just" terminate the PT's when we enter the dormant mode and re-spawn them when we leave the dormant mode. If we decide to extend the PT protocol to handle `SIGNAL DORMANT` would we also need to have a method to inform the PT that it can start interacting with the rest of the world again? Would it be bad if `SIGNAL DORMANT` also means that the PT should not write to stdout/stderr until it's been informed that we are no longer dormant? :-) Cheers, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
Hey Jeremy, On 2020/05/15 15:53, Jeremy Rand wrote: > FYI I already wrote a Prop279 provider that looks up the names via DNS > (it's aptly named "dns-prop279"); it does pretty much exactly what you > describe. It doesn't handle DNSSEC validation itself (it assumes that > you've specified a DNS server that you trust -- most likely one running > on localhost). Stream isolation can be handled via an EDNS0 field (and > I'm guessing it would not be difficult to patch an existing DNS server > to respect that EDNS0 field). I wouldn't be surprised if it's easy to > make dns-prop279 do DNSSEC validation itself (and not use a > localhost-based DNS server) if that's desired -- the library it uses > (miekg/dns) does claim to support DNSSEC validation, though I've never > tried testing that feature. Very interesting. I think proposal #279 only tries to solve the subset of name look ups, which is about looking up onions from a human name. The work in this thread is to replace all name lookups *except* for Onions. It could very well be that it would be easier to extend proposal #279 by having it handle all lookups and not just for .onion's, but I think my intuition says that it should be two different systems as onion lookups is still a much more open question whereas Tor will need to support ordinary DNS for many years into the future. If `OnionNamePlugin` allowed you to specify `.*` for "everything" as the TLD specifier, then it might be possible to implement such system using proposal #279 :-) All the best, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
Hello Christian, On 2020/04/26 19:37, Christian Hofer wrote: > I have a proposal regarding DNS name resolution. > > Ticket: https://trac.torproject.org/projects/tor/ticket/34004 > Proposal: > https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-dns-name-resolution.txt > Implementation: https://github.com/torproject/tor/pull/1869 > > All functioniality is behind the DNSResolver feature flag, so don't > forget to activate it before you start testing. > > Please let me know what you think. Thanks for doing this work. I think our DNS subsystem has been lacking behind for a while. This work is exciting. Generally, after having done one pass over your code, I think the source code is good quality, especially if this is your first contribution to Tor! However, I think this is going to be a bit problematic for us to import. It will be hard, if not impossible, for Tor's Network Team to adopt 27k LOC's in one pull-request. We will have to have multiple people going over each line repeatedly and try to build up some confidence in this code. If we are to go down this path, with having a complete DNS subsystem in Tor, we need to add some capacity from our side to take this in and maintain it. I think that with the recent layoffs in Tor, it will be hard to achieve in a time-frame that is fair towards you. One of the goals with our specification process is to have a set of documents, which allows other people to understand how Tor is working to the point where they should be able to implement Tor from scratch if they found that useful. This isn't always possible today, but this is a goal we should have in mind. Your proposal is mostly a specification of the *implementation* of the DNS resolver patches and doesn't contain any information on any changes to the network layer of Tor. Instead, those seem to be referenced as the various DNS related RFCs from the IETF. Configuration options of the Tor binary is largely an implementation detail. I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups. Such tool should be allowed to use Tor itself for transport of the actual queries. One of the best parts of Tor (in my opinion) is the Pluggable Transport subsystem. This subsystem allows external developers, researchers, and hackers to build new technology that benefits users in censored areas *without* having to alter a single line of C code in tor.git. Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to configure their Tor process to *never* use the built-in DNS subsystem in Tor, but instead outsource it to an external process that Tor spawns on startup. This process could use .onion's to reach a DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up via DNS. A "Pluggable DNS" subsystem would be much less code, I believe, and it wouldn't require us to have a DNS+DNSSEC implementation in the heart of Tor to maintain in the future. Such a system would be similar to the proposed design for Name => Onion lookups defined in proposal #279 by asn, yawning, and dgoulet. Lastly, I assume it's just for testing purpose, but I don't think we could ship with CloudFlare's DNS-over-Onion services as the default servers for a feature like this without having a discussion in the community about it first :-) All the best, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
Hey, On 2020/05/15 16:36, Jeremy Rand wrote: > The Prop279 spec text is ambiguous about whether the target is required > to be a .onion domain, but the implementations (TorNS and StemNS) do not > have that restriction. TorNS and StemNS allow a Prop279 plugin to > advertise acceptance of any domain suffix (haven't explicitly tried the > root zone as an suffix, but if that doesn't work, it's a bug that should > be easy to fix) and can resolve them to any result (e.g. an IP address, > a .onion domain, or another DNS name a la CNAME). In proposal #279 the subprocess passes the `RESOLVED` message to Tor once it is has completed a name look up. The `RESOLVED` message is defined as follows: ``When the name plugin completes the name resolution, it prints the following line in its stdout: RESOLVED where QUERY_ID is the corresponding query ID and STATUS_CODE is an integer status code. RESULT is the resolution result (an onion address) or an error message if the resolution was not succesful.'' Here the `` must be an onion address. We would have to change that, such that an IP address can be returned as well :-) All the best, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Safe Alternative Uses of Onion Service Keys
On 2020/07/29 05:15, Matthew Finkel wrote: > > [ ... snip ... ] > > A signature must include "v0" and the values used in "-MM-DD" and > INT_8(validity_period), such that the client can derive the correct > blinded public key for verification when starting from the long-term > identity key. The signature should be over a certification of an > independently generated ed25519 key pair. This new key pair (along with > the certification) can be used for providing message integrity within > the application's protocol. If, instead, the derived key is used > directly for signing, and the application needs the keys online for > signing messages, then this risks the security of the long-term key, as > well. The blinding scheme allows for (partially) recovering the > long-term secret key from the derived secret key. This is super useful, Matt! Thanks for writing all of this down. > Another example use case comes from Jeremy Rand where the onion service > key is used in a root CA certificate, and a leaf certificate (signed by > the CA cert) is used by the application. This idea stemmed from a conversation between David, George, and me a little while after the Stockholm meeting last summer. The implementation of the tool for generating the various x509 files (the x509 CA and the signed x509 certificates) is available from https://gitlab.torproject.org/ahf/onion-x509 For people who are unaware of what this tool is doing, I can flesh it out here: Tor uses an ed25519 secret key format that is incompatible with the ed25519 secret key encoding found in x509, and we cannot just convert the .onion identity ed25519 key to a PEM file and make, for example, a web server use it directly. This also seems to be what Matt is recommending against. As seen in Matt's [0], the signatures and public keys are all using the same encoding, however. In ordinary TLS, where the server sends the certificate chain, we don't keep ANY of our CA's secret keys online (since we hopefully don't have access to them under normal circumstances). Thus, we only need the secret and public key of our leaf certificate to be available for our TLS service to do signatures as part of the TLS protocol. We can therefore generate an "Onion CA" from Tor's .onion identity secret key, but never have to move any secret key with it into our TLS service deployments. Once we have generated this "Onion CA", which is identified by the onion identity public key, we use the onion-x509 tool to issue leaf certificates that are signed by the "Onion CA." By configuring our TLS service to use the Onion CA and our ed25519 leaf key pair, and its x509 certificate (signed by the Onion CA), the client will be able to verify if the certificate is "valid" just based on the Onion address itself. I think the stateless nature of this system is pretty cool. I don't believe that moving to blinded keys blocks anything for it to work, which means I think Jeremy and I should probably coordinate to do that instead of the direct use of the onion identity key pair as the tool does today. Of course, the modifications to the browser are the terrifying part of all of this as such changes touch some scary code paths in how TLS certificates are validated. Still, if this can work, it would make x509 certificates very easily accessible for Onion service operators. If Jeremy gets the demo to work in Tor Browser and it all looks promising, we should also spend a bit of time rewriting the Go tool to C and bundle it with the Tor codebase. > Following from the previous example, (most likely) the CA certificate > should not be signed directly using the onion service's long-term secret > key. However, a derived key could be used in the CA certificate and the > leaf cert could contain an ephemeral key (in exactly the same way that > tor certifies ephemeral keys using the derived blinded signing key). > This idea appears to be a concrete design of how the above (abstract) > key certification could be implemented, and it could be a format that > tor natively supports. >From what I can tell, it should be possible for us to update the onion-x509 tool to use the blinded key instead. Exciting stuff! All the best, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Gitlab CI runners available for experimentation on gitlab.torproject.org
Hello folks! Hans from The Guardian Project added his CI runners to our Gitlab instance. It looks like some pretty fast machines that allows each team to experiment with Gitlab CI on our Gitlab instance. Hans says that the runners have no uptime promises or anything like that, so if they are down they are down :-) Here's some documentation for getting started: https://docs.gitlab.com/ee/ci/ Thanks to Hans for this! All the best, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Gitolite to Gitlab Sync Change
Hello folks! In an attempt to solve Gitlab#41[1] the hooks that is executed when you push to git.torproject.org to synchronize to Gitlab was modified to avoid pruning references in Gitlab that was missing in the Gitolite repository. This /should/ have the following implications: - We no longer delete the "refs/merge-requests/*" namespace each time someone pushes to your repository on git.torproject.org. This should allow people to use the `git mr` alias that can be found online which should make local code-reviews easier and also allow you to handle manual CLI merging more easily. - We no longer delete branches automatically on Gitlab: if a branch is deleted on git.torproject.org. This have to be deleted manually now on Gitlab. Please report any issues you that you might discover on the ticket. Thanks to Hiro for getting this running! All the best, Alex. [1]: https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/41 -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Has Core Tor Development Slowed? Or Are We Moving To Rust/arti?
Hello Neel,
On 2021/01/08 16:34, Neel Chauhan wrote:
> I hope you all had a great holiday season.
Likewise!
> Sorry if I have been less active in the Tor community as opposed to the
> past. I've been more focused on FreeBSD Ports as of now, but I still want to
> post at least the occasional Tor patch here and there.
Absolutely no need to apologize, Neel, you're one of our more persistent
contributors over the years :-) Hope you enjoy hacking on the FreeBSD
ports tree as well.
> Core Tor/Tor hasn't seen an update since December 21, even when we are
> already a week into 2021.
TPI ("The Company behind Tor") gave everybody some additional amount of
vacation days for this holiday because last year was quite intense for
us all. Some people returned on the 7th and the rest will return on
Monday the 11th. That might explain why nothing have happened yet here
in 2021 :-) Expect operations to normalize next week, hopefully with
recharged batteries ready for 2021 :-)
> Is this related to the layoffs which happened last year? Or is Tor moving to
> Rust (via arti) and all the development is happening there? I'm guessing
> both.
The amount of work done is definitely related to the layoffs that
happened in April, but also related to our deliverables for 2020 for the
teams and thus the people left after the layoffs.
When the layoffs happened, most of April and quite a bit of May was used
for re-structuring the organisation and figuring out what to do next. We
decided to move some people around to do tasks for different teams than
their usual ones, and we created some new tasks we wanted to resolve
here and now that didn't have to do with any specific codebases or
teams, such as looking at our infrastructure for doing software
development.
If we look back at the second half of 2020, for Tor's Network Team, then
a lot of the tasks we have had has been longer term deliverables. We
started up the new project on network performance work where a lot of
cross-team interaction have happened together with the network team, the
metrics team, and our new network health team where the teams works
together on analysis/experiments or in codebases that are not
necessarily tor.git. Efforts such as looking into the next generation
bandwidth scanners (both sbws and flashflow) have taken some time as
well.
When Nick had shown the prototype of Arti at some point in 2020, we
tried to figure out a way where Nick could focus a bit more intensely on
this project, because it was looking *very* promising. This of course
have an impact too, but we think it's worth it because Arti will be
solving some of the architectural issues that will take a very long time
to resolve in the current codebase.
Additionally, some time have been spend helping our friends from the
guardian project on some profiling and Tor integration work for their
mobile applications.
It should be said though, that we don't hope that you have been impacted
by this as a volunteer over the year. We have tried to ensure that all
the normal tasks we have over the weeks regarding Tor maintenance have
remained the same (tasks such as doing code reviews, rolling releases,
backporting, etc.)
> If it's the latter, I guess I have to start learning Rust sooner rather than
> later. Well, who am I kidding, I had to learn C# and PowerShell for my job
> (Disclaimer: I work at Microsoft, not on security or Windows/Azure however).
I think exploring Rust now might be a good idea. The Arti project that
Nick started does seem to solve some very specific issues that we have
been trying to deal with for years, and everybody in the Network Team in
Tor have been very impressed with how quickly things are able to move
forward in the Arti project.
If you take a look at the TODO file[1] in the root of the Arti
repository, and take a look at its history, you can get a feeling on how
quickly Nick have been able to move this project forward. It's very
exciting, and people are starting to submit patches to it as well :-)
A lot of us inside of Tor's network team still need to become better
Rust programmers, but hopefully we can speed that up by working
together.
All the best,
Alex.
[1]: https://gitlab.torproject.org/tpo/core/arti/-/blob/main/TODO
--
Alexander Færøy
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Renaming the primary branch of tor.git
Hello! As of today, the primary development branch of tor.git (the Git repository containing the source code of Tor) is now named 'main'. If you use tor.git in your tools, where you refer to the branch names, you probably want to change that to 'main' right away, otherwise your tools may break. All existing Gitlab MR's should have been updated to target the new primary branch name, but contributors should make sure their local checkouts are tracking main now for updates. Tor.git maintainers should re-run the usual scripts and make sure their work tree setup uses 'main'. All the best, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onbasca - the next-generation bandwidth scanner
On 2022/02/09 17:48, Georg Koppen wrote: > welcome onbasca. Onbasca takes the best out of sbws and makes the code > easier to test and more robust for future improvements by deploying a > database management system where we previously dealt with JSON files > only.[1] Wow. I had not seen this coming already! Very exciting. Juga and Georg, it has been wonderful to follow you two working together on getting sbws ready for production use over the last few years. Seeing it running on the directory authorities is an outstanding achievement \o/ Looking forward to follow the development of Onbasca! All the best, Alex. -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 347: Domain separation for certificate signing keys
On 2023/10/19 12:49, Nick Mathewson wrote: > To see this rendered, go to > https://spec.torproject.org/proposals/347-domain-separation.html > > ``` > Filename: 347-domain-separation.md > Title: Domain separation for certificate signing keys > Author: Nick Mathewson > Created: 19 Oct 2023 > Status: Open > ``` > > ## Our goal > > We'd like to be able to use the "family key" from proposal 321 as a > general purpose signing key, to authenticate other things than the > membership of a family. For example, we might want to have a > challenge/response mechanism where the challenger says, "If you want > to log in as the owner of the account corresponding to this family, > sign the following challenge with your key. Or we might want to > have a message authentication scheme where an operator can > sign a message in a way that proves key ownership. > > We _might_ also like to use relay identity keys or onion service > identitiy keys for the same purpose. Very nice work here. This is exactly what we need for some of the experiments we want to do under Sponsor 112. Cheers, Alex -- Alexander Færøy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
