[tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[meejah]

George Kadianakis <desnacked at riseup.net> writes:

> Also, it means that clients need to _securely_ send credentials to the
> HS operator and then they need to _wait_ till the HS operator adds
> those creds to Tor, before they are able to visit the HS.

One thing that might help here is Brian Warner's "magic wormhole"
(http://magic-wormhole.io) -- which supports Tor. This would answer the
"how to securely communicate the key" part, at the expense of both
parties needing to be online at the same time. Basically, instead of
exchanging the HS credentials directly, you'd share a "wormhole code"
which is a SPAKE2 one-time password.

If, for example, a controller library like txtorcon added support for
this, the HS operator (Bob) would run some command on their side
("invite alice") which would add credentials for Alice to Tor (via
ADD_ONION_CLIENT or something) and give Bob a "wormhole code". Bob gives
the code to Alice (ideally securely, but not nearly as critical here as
with "actual" keys), who would run something app-specific on their side
(e.g. "accept invitation") and type in the code they were given. The
command running on Bob's side would pass the actual HS credentials (via
the now-established wormhole) to Alice's running application (which then
also would use some controller command to add the client credentials to
their Tor instance).

So, neither Alice nor Bob ever actually see any keys at all.

> We should probably speak with people that use client auth to tell us
> if this UX will break their model.

+1
It would be great to know how people actually exchange these things
currently :)

-- 
meejah