Re: [tor-dev] Moving key material out of the main tor process

[Linus Nordberg <linus@xxxxxxxxxxxxxx>]

Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote
Tue, 2 Jun 2020 11:51:07 -0400:

> One issue with the ssh-agent protocol as I see it is that it isn't
> originally designed for decryption or for high-volume usage.  If we
> want to support those in the future, we'll need to make sure that we
> have an extension path for them in whatever vault tool we're using.

Good point. The extension mechanism defined for the protocol (see
[draft-miller-ssh-agent-04] section 4.7) could be used for finding out
if and how other types of operations are supported by the "vault" or
"crypto daemon". This sounds like an invitation to complicate things
though, like defining an extension function returning a new endpoint for
a separate, more powerful, protocol. But maybe we should be able to
constrain ourselves.

An alternative to using the ssh-agent protocol extension would be to
have the internal key data type in tor include a protocol and an
endpoint and let the user set things up through torrc (default
"call_openssl://path/to/privkey"). This would allow for expressing that
your signing keys have moved from "ssh-agent://path/to/ssh-agent.socket"
to "new-and-shiny://path/to/powerful-crypto-daemon.socket".

And even if I don't like it much, there's always the option of defining
something new, encompassing all our needs from start. To be weighed
against the upside of being able to use already well established
software for our specific needs of signing. One could argue that the
minimal implementation of such a protocol, only for signing, could
forward requests to a running instance of ssh-agent but the number of
moving parts just went up. Simple is better here IMO.

[draft-miller-ssh-agent-04] https://www.ietf.org/id/draft-miller-ssh-agent-04.txt
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev