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

[meejah]

Regarding the API / interface for communicating client-keys for hidden-
services .. I thought we were encouraging ADD_ONION based services?

Personally, I think using the filesystem as "an API" isn't very
good. From a controller standpoint, it's *way* simpler to use ADD_ONION
properly than on-disc services (i.e. via SETCONF) because directory
permissions, file permissions etc have to line up and it's not
immediately clear if the files will always for-sure be on-disc when the
SETCONF command says OK. (Also, you have to deal with the one-shot
nature of SETCONF and order-matters configuration options)

On the disadvantage side, this means any applications using these
services are then responsible for their own key-management.

In any case, something like growing an "ADD_ONION_CLIENT" command or
similar might be way easier to understand and implement.

A flow might look something like this:

 - client creates a key(/pair) in tor-browser or whatever
 - client sends it to service operator ("exercise to the
   app-developer"?)
 - operator uses their controller to run "ADD_ONION_CLIENT"
 - ???
 - profit!
 
Definitely out-of-scope for "ng hidden-services", but it would also
probably be nice to have more separation in the control-protocol. Right
now, you get the authority to do anything at all -- but maybe you'd like
to give an application *just* the authority to "add hidden services
and/or clients". You can use a control-port-filtering thing
(e.g. roflcopter) to get something like this, but ... not ideal (and not
really the same as being able to grant limited authority to an
application).

I'm thinking here of scenarios where you have an application that wants
to "use Tor" to do service-stuff -- so "just edit the config" isn't a
satisfying answer at all. Also, having every app launch its own Tor
instance (which is about the only answer currently) seems bad.

-- 
meejah