[guardian-dev] WOT and Authentication Research
patch at cs.ucsb.edu
Tue Feb 12 19:10:51 EST 2013
On Thu, Jan 24, 2013 at 12:42 AM, Abel Luck <abel at guardianproject.info> wrote:
> Finally jumping into this thread. Honestly, I'm not sure I agree with
> where this is going at a high level.
> (from above, emphasis added)
>> Publishing signatures will help with that and
>> should be encouraged for *those who aren't at risk by having published
> Threats change with time and circumstance and risk changes, but a public
> WOT is permanently public.
> IMO, everyone is at risk when their social networks is publicly available.
> Welcome to Hotel WOT. You can checkin, but you can't checkout.
A couple points here. I think the danger of exposing your social graph
definitely needs to be looked at more, but I don't think its a central
part of what I'm arguing for.
This infrastructure would provide benefits whether you use a public
WOT or not. It would also describe a model for varying degrees of
authentication (keyserver lookup < independent WOT < manual signing
or protocol based verification (key-signing, socialist
millionaire,ect.)) for users while making it easier to both use and
bootstrap into the system. A public WOT is optional. I think it makes
sense to include the ability to upload signatures for now, but that's
a tradeoff that could be decided on the application level (don't allow
user's to participate if its dangerous to the threat model).
The idea is that independent authentication is promoted and
represented as the highest level of authentication. For the ultra
basic user that can't be bothered to do anything but login, then a
cert-pinned connection to this key-server that enforces a stricter
policy of propagating mappings (public key-> name) will provide at
least some improvement over what people do now. This requires trusting
the keyserver. However, this would just provide your first bootstrap
into a TOFU/POP client until the user can be asked to independently
verify a key. Ultimately they may learn a WOT path or perform a social
millionaire transaction to be more secure against a MITM attack.
This system brings up the baseline in bootstrapping into a
communication infrastructure with encryption and authentication.
Clients/users will also have a better way to manage long-term identity
mappings and keys. Ultimately, the key-server would have both a web
and RESTful interface (for users vs clients).
I think the centralized design is actually an important aspect of this
too. Just having a key-server with strict mappings actually adds value
to a distributed WOT. If any keys in your independent path exist on
the key-server then you can check that the records match. As far as I
know, a distributed WOT can't have any guarantees on whether your
email is being shared with another public key and so a public data
structure adds value to persistent pseudonyms.
My current plan as a research project is prototyping this approach
with the following systems components:
2) Modified crypocat client that functions as a general XMPP client
promoting long-term identities with the key-server as the backend.
3) Key-storage would be provided by a zero-knowledge storage system
separate from the key-server.
> William Binney has shown us that metadata analysis is just as good a ft
> providing intelligence as cleartext. By mapping associations over time
> with other available data, statistically significant conclusions can be
> Traffic and metadata analysis research is lightyears ahead of the
> corresponding anonymity research. We're still fumbling with encrypted
> email, failing to explain asymmetric crypto to users, while massive
> appliances and datacenters have been built to suck up and analyze three
> simple fields: To, From, Date.
Also, given our knowledge from William Biney, it is the conservative
and correct stance to take that exposure of social graphs present a
huge threat in themselves and may be as paramount as having private
That said, I think there is a spectrum of security tradeoffs here, and
you must consider that this is a different situation then that
presented by Biney. First, exposure of key-signatures as a social
graph is much different then the graph that exposes each edge as a
time-stamped two-way connection that may include location data (GPS or
A signature exposes that psuedonym A has had some connection with
psuedonym B once or more times. We don't have frequency, physical
realities, or a timeline besides the initial publishing. If you couple
this with a pseudonymous name that is accessed through Tor this would
be a partial solution.
So what you expose in every email header is far more damning then that
which you expose from those who have signed your key at some point in
time. Until this is solved it may be a worthwhile trade-off to have a
public WOT for certain people.
Additionally, having a public WOT would benefit those who don't
participate, because they can still leverage paths in the public WOT
and can find a path into it in their own distributed fashion.
TLDR; a public WOT is opt-in and would provide some value in the
> This is definitely possible. Look at Spider Oak, Tarsnap, and TahoLAFS
> (don't look at Mega).
> Key backup is definitely important, something not specifically addressed
> in PSST, but something we should look at.
I think having a standard for this would be really valuable. I'm
hoping to prototype this as part of the project :). Hopefully it'd be
a very simple storage API. A web app like cryptocat could now let the
user manage their own private key or you could upload your .gnupg
folder as well.
More information about the Guardian-dev