Hi Zenaan,
Thank you for all these questions, I'll answer them to the best of my
ability.
But first, please accept the premise that I don't want to cast Keybase
in a bad light. On the contrary, they are trying to solve the most
difficult problem on the internet:
*How to find the correct public key of a person.*
I respect Keybase for their work and I think that their model has a good
chance of getting adoption in their target area: linking identities
between several social sites to strengthen the link between names and
public keys.
I've tried to create an objective comparison between them and me, not a
value judgement. Apologies for my bias that have crept in.
On to your questions
On 02/26/16 23:47, Zenaan Harkness wrote:
> On 2/26/16, Guido Witmond <guido@xxxxxxxxxx> wrote:
>> On 02/25/16 01:58, Paul Syverson wrote:
>>> On Thu, Feb 25, 2016 at 12:26:02AM +0100, Guido Witmond wrote:
>>>> I don't want *people* to exchange keys. I envision people to exchange
>>>> names and let computers do the key lookup.
>
> That's fine but should be achievable with a DHT yes?
A hash table does a lookup from HASH(data) -> data.
When I retrieve the data, I can calculate the hash and determine if I
got the correct data.
What I want is a lookup of name -> public key.
I could set up a DHT that does HASH(name) -> public key but there in no
user name in the public key, so there is no way to calculate that I got
the correct data.
Would I create a DHT based on HASH(name) -> certificate, where
certificate is {name, public key, CA-signature}, I still have to
validate if I got a result from the correct CA. The question that
remains: who is the CA chosen by <name>.
>> - Keybase uses the Bitcoin blockchain as trust anchor, Eccentric uses
>> DNSSEC and a separate verification service like Certificate Transparency.
>
> - separate verification service
> - sub certificates
> - mitm
>
> This model is fundamentally broken and asking for MITMs.
>
> Why re-use such a model?
I'm not sure which fundamentally broken model you are referring to.
> Why do you say you considered, but discarded, the blockchain as trust anchor?
I've tried to give an objective comparison, not a value judgment. The
blockchain is suitable as a trust anchor. I haven't found a need for it
yet in Eccentric.
>> 2. Model
>>
>> - Keybase has a person centric key model:
>
> Surely that's just an end-user app consideration.
On the contrary, it's their fundamental design decision. Tying several
identities together strengthens the relationship between identity and
public key. It's how Keybase solves the most important question.
> This seems to be your primary gripe about keybase (from what I can
> tell)
Indeed, I find it scary to link all aspects of my life into a single key.
I'm a strong believer in keeping separate contexts of my life separate.
Humor is a good example. Thing I say to friends in jest are not funny to
people who weren't there at that time. That same words could mean
something entirly different in a different context.
Or take the example of a boss who doesn't hire a candidate based upon
drunk pictures on facebook. That candidate could have a good social
life, going out with friends, getting drunk once in a while but not
getting in trouble.
Or take the person who drinks at home. Why does he drink? Is it because
he's out of a job, then hiring him may find you with a very motivated
employee.
Keybase doesn't offer me that separation.
I try to solve the same key lookup question (which is the correct key
for a given name), but I want to keep contexts separate. And that's a
different goal.
If keybase gets big, I probably use them to link some of my identities
into one but I keep that network small.
- have you discussed this "limitation" with the keybase
> developers/ designers to see if your concept might fit nicely into
> keybase?
Keybase and I solve for different goals. We might learn from each other,
no doubt, but I don't see a need to integrate.
> If you have discussed, please refer us with link(s) to such
> discussions - this will be important information for anyone
> considering your "solution".
People should consider each proposal on their merits.
I'm not even sure yet that I've solved all the avenues where MitM could
sneak in. I'm not sure that there is a general solution, it's probably
impossible to be anonymous and have complete protection against MitMs.
> If you have not, perhaps you need to have a good hard think about
> whether you are a NIH dope.
In that regard, I'm a NIH dope, going down avenues that no one else took
to see where it gets me. Even if it doesn't get me anywhere, the journey
is fun.
But the things that I find, I publish on my site, for others to poke
holes in it.
And last Thursday, someone just did. [1]
> Again, please provide links to the discussions you've had with the
> keybase folks about exactly these points you raise, so we can read for
> ourselves, their responses!
I've got my information from reading their site: keybase.io.
>> - Eccentric uses a key model where each user has many keys:
>
> This should of course also be raised with the keybase folks.
Again, different design decisions.
>> 3. Central / Dispersed
>>
>> Keybase uses a central repository for all key/identity announcements.
>> This makes them a single high value target.
>
> Perhaps keybase needs to be forked due to some fundamental
> limitations? (it is libre source yes? - before this thread, I'd never
> heard of either of these projects...). Perhaps the keybase devs are
> aware of such fundamental "problems"?
They are aware of it and moved to the bitcoin blockchain for that reason.
> "every site has it's own CA"
>
> That's a burden upon site operators that will never be "widely"
> achieved - except perhaps the large blogging platform providers,
> facebook etc.
This is a valid concern. Keeping the private key secret is the ultimate
burden of every use of cryptography.
But we already have that burden. Every https-secured site needs to keep
the private key secret. Every DNSSEC signed domain name has two private
keys. Every bitcoin address is a public key that belongs to a private key.
Please see the nitrokey.com HSM as one offering to help keys secret.
I expect that in the eccentric model, most CA keys will be managed by
hosting providers. It will be one more service in their offering,
hosting, DNS, Eccentric CA. Just keep your root key on your HSM.
> When a site can use HTTPS, users can create identities on the site,
> and then users can use perfect forward secrecy with throwaway keys for
> "ephemeral" communications, really, what does some new CA per site
> actually provide?
The CA provides the one-to-one mapping between usernames and keys. It's
my answer to the question at the top.
The eccentric protocol demands that the CA signs each <username> @ part
only once. This is easy to do in software and easy to verify with an
verification service. If a site ever signs two different public keys for
the same <username>, the protocol requires all user agents to warn their
users about this broken promise and consider that site untrustworthy.
The benefit of this requirement is that I can write my <username>@site
on the back of a beer coaster and give it to someone. That person
verifies at the verification service that there is just one certificate
that bears my <username>. If so, that person has got my public key and
can encrypt messages to me.
> I'm just not getting the significant value proposition or even
> properly understanding your use case and why most people would bother
> with all your proposed infrastructure.
It's a method to tie keys to usernames so people can do the lookup of
name -> public key. See the question on top of this message.
> Without a significant "value proposition" for the sites, or for the
> users (and implicitly perhaps for the sites as a result of that),
> who's going to bother?
If answering the big question isn't enough value, the eccentric protocol
also offers phishing protection where anonymity isn't required, such as
electronic banking.
> But then I'm biased - neither do I understand the value proposition of keybase.
Their value (to users) is to make it easy to find the correct key for a
username so users can send encrypted messages without worries about a MitM.
>> 4. User Security
>>
>> Keybase provides confidentiality of the message contents but as it uses
>> existing email transport, neglects meta data protection, in fact it
>> gives up meta data protection to gain stronger ties between usernames,
>> keys and identity.
>
> In other words they've delegated part of meta data protection back to
> the user "you'll have to use a throwaway email account if you want any
> anonymity in your keybase communications".
Indeed, people could create a different keybase identity (in a Tails VM)
to separate their contexts.
>> Eccentric offers much stronger protection of meta data and equals
>> protection of message confidentiality.
>
> So you're building a messaging platform?
>
> Or building infrastructure which you expect others to build messaging
> platforms on top of?
I'm investigating how such an infrastructure can be build. Please see
the eccentric-authentication.org site and read through the archives.
>> With Eccentric it's harder to
>> assure a certain key belongs to an author of a publication.
This is current research on how to make it easier.
> So what value does it provide (sorry, I'm a slow learner).
I offer mechanisms to make it easy to use cryptography correctly. So
people can be safe against eavesdropping, MitM, remain anonymous when
they desire.
I hope you find it interesting.
With regards, Guido Witmond.
1: https://lists.torproject.org/pipermail/tor-talk/2016-February/040416.html
Attachment:
signature.asc
Description: OpenPGP digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk