Well being able to issue keys is an important mechanism to prevent
starvation attacks. The idea is that you issue keys and provide the
Obelisk servers as a service. If someone abuses their access, you revoke
their keys and they can't keep creating more.

The other case is where you use Obelisk as a backend for your website.
Maybe it runs on a different box. You whitelist the IP address you
access it from and setup a keypair between client and server which
doesn't allow access from other hosts or IP addresses.

But if you just want a public Obelisk server where clients create a new
keypair each time they access the server, then just configure Obelisk to
accept any public key and you're good to go.

Comment this line and all client pubkeys will be accepted:

https://github.com/spesmilo/obelisk/blob/master/src/worker/worker.cfg#L31

About discovering server keys and servers in general, we need to develop
something. I think it's better to wait and think something through. My
proposal is a special daemon (maybe part of Obelisk) which servers can
register themselves with, register which methods they implement and the
documentation for those methods (allowing remote introspection by client
developers). This would allow discovery and all kinds of nice stuff.

On 12/03/14 20:13, Eric Voskuil wrote:
> Thanks for getting this integrated Amir, privacy on the wire is a
> necessary piece in the anonymity puzzle!
>
> There needs to be a mechanism for publication of server public keys.
> Adding this field to the published list of Obelisk servers
> <https://wiki.unsystem.net/index.php/Obelisk/Servers> would be a good
> start.
>
> When it comes to client implementation I would expect that a client
> would maintain its whitelist of servers (i.e. those for which it has
> public keys) and not typically utilize a persistent keypair (i.e.
> would remain anonymous to the server) - as in scenario 3 from the
> CurveZMQ docs:
>
> "Where the server does not check client keys at all. In this case the
> clients can be certain they are talking securely to the correct
> server, but the server will accept connections from any client. This
> fits the conventional Internet model where a browser talks securely to
> a website to place and order and send credit card information."
>
> This would also mean that the server whitelist of clients would not be
> typically utilized by a public server.
>
> e
>
> On 03/12/2014 10:14 AM, Amir Taaki wrote:
>> Hey, The new Obelisk has support for server-client encryption and
>> signing using ed25519 crypto. The client can specify a key, and
>> the server can specify which client pubkeys it will accept (or all)
>> and a whitelist of IP addresses.
>
>> See this config file for reference:
>
>> https://github.com/spesmilo/obelisk/blob/master/src/worker/worker.cfg#L24
>