Delivery-Date: Fri, 26 Feb 2016 17:47:46 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 021071E0512;
	Fri, 26 Feb 2016 17:47:45 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 5E3A539A89;
	Fri, 26 Feb 2016 22:47:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 4996739A7D
 for <tor-talk@lists.torproject.org>; Fri, 26 Feb 2016 22:47:35 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id yKUZu4bzKBpn for <tor-talk@lists.torproject.org>;
 Fri, 26 Feb 2016 22:47:35 +0000 (UTC)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com
 [IPv6:2607:f8b0:400d:c04::22b])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 1E675395DE
 for <tor-talk@lists.torproject.org>; Fri, 26 Feb 2016 22:47:35 +0000 (UTC)
Received: by mail-qg0-x22b.google.com with SMTP id y9so77913483qgd.3
 for <tor-talk@lists.torproject.org>; Fri, 26 Feb 2016 14:47:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:date:message-id:subject
 :from:to; bh=Nqs4whPcu/EbcrGjJRtzV3CDtFgRItV5vfdalUfKA5w=;
 b=FbztXLn1jNeX2ImzK+u+pRTRLT69rrdRkaQ2x5KYfNZLIcyahER9hucLsIXoMM0+Zr
 aBwUGV5jAkjVJ4t+Wh2D/9RBHyJECSKDF67jl+paHCupMbPMB2HwqNKuapv4In1NNjQA
 hXiWBUVdg5x0gP0Z00OBubJXQ6CkETbpybC8Dy/S5PEYw0hVEfwMV0QU4YwbYjTfwXxS
 7GxheECxXKRDMfPIHPBVAZef7RYzoiSfUuFB93iCRSEtMG1DnOLja2SigObugFEaAtMd
 DUui3bPkiAop/Z6tMkfh+PDQtiYUDH8n0gXREc56+xjZ+DatJpquadZzCHkjhhj8UB9o
 l5/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
 :message-id:subject:from:to;
 bh=Nqs4whPcu/EbcrGjJRtzV3CDtFgRItV5vfdalUfKA5w=;
 b=HE3LWlHbdWKV3X7VoY3JhWHjFfjesxf2mPf+9fu17yNFv/rJEOi23OfT/Qk9gchomO
 dP9tZgk49pDWt0Ig0U2DpeHfW1vpnd16HrekQlNvlA0X8O0K0wVYwKyFDgPs5vuv1xNO
 xAXIXsqDj8iz8zYOpucHZpleX7SWtD7pWeuxBgXXt25wB3ujKgblz1xfDXK6EQwvU/IV
 xcW9euMmG+jS4flWXyay/ZSi7GvGHE1FjXR576G2J7dPDvPtp5zsVSAR5RQBqpH1W/TX
 P1G1tlvtXdtSWYlesnKFeDUCH8B53HUe+HvL9snXyc1hLr7P8GJIDBRaFPA0bm9bX9WX
 dCPQ==
X-Gm-Message-State: AD7BkJLZV6RyXVC118SJj9o6UnaDsedWF+fBSxd6+CfiUcDLeBrS3E32/HUQmiAK/TEeuIN7XTHnk/cN586KSQ==
MIME-Version: 1.0
X-Received: by 10.140.83.212 with SMTP id j78mr5304225qgd.83.1456526852371;
 Fri, 26 Feb 2016 14:47:32 -0800 (PST)
Received: by 10.55.64.68 with HTTP; Fri, 26 Feb 2016 14:47:31 -0800 (PST)
In-Reply-To: <56D0B632.40305@witmond.nl>
References: <56CC3191.1000402@beroal.in.ua> <56CCA590.5020506@witmond.nl>
 <56CCAA26.8070609@beroal.in.ua> <56CCC954.6080102@witmond.nl>
 <CAB7TAMmRBgO2FPvV8rpW7ZaWZ14hbvQ_3NZyhENi4bN1aKDBuw@mail.gmail.com>
 <56CCE201.7070706@witmond.nl>
 <CAB7TAM=kJZG=8eEka2sNBjyh-T7omJ7B1oBga--eDej6F_1-=A@mail.gmail.com>
 <56CE28F7.4040800@witmond.nl>
 <56ce2e4d.8518370a.50ae9.ffffb299@mx.google.com>
 <56CE3C0A.1060702@witmond.nl>
 <20160225005853.GP57127@vpn212046.nrl.navy.mil>
 <56D0B632.40305@witmond.nl>
Date: Fri, 26 Feb 2016 22:47:31 +0000
X-Google-Sender-Auth: 6x-h1qkxb5wvqxedF-dEeI8L1eA
Message-ID: <CAOsGNSSATd0AOwfVEV+Ejp32+7BE7SfvTXnVi1M2DPTVLVBGqQ@mail.gmail.com>
From: Zenaan Harkness <zen@freedbms.net>
To: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Tor for everyone;
	introducing Eccentric Authentication
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 2/26/16, Guido Witmond <guido@witmond.nl> 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?

>> The description below sounds a fair amount like Keybase
>> (https://keybase.io)
>> Perhaps it would be helpful to contrast your goals with theirs?
> Both Keybase.io and Eccentric Authentication share the same goal: Crypto
> for everyone!
>
> But there are differences:
>
> 1. Technology
>
> - Keybase uses PGP, Eccentric uses X509;
> - 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?

Why do you say you considered, but discarded, the blockchain as trust anchor?


> 2. Model
>
> - Keybase has a person centric key model:

Surely that's just an end-user app consideration.

This seems to be your primary gripe about keybase (from what I can
tell) - have you discussed this "limitation" with the keybase
developers/ designers to see if your concept might fit nicely into
keybase?

If you have discussed, please refer us with link(s) to such
discussions - this will be important information for anyone
considering your "solution".

If you have not, perhaps you need to have a good hard think about
whether you are a NIH dope.


> Even though people can have multiple private keys, these are connected.
> Each user has 1 identity. That means, every message sent is attributed
> to the person.
>
> In this model, each of the actions strengthens the faith in the relation
> between the key and the identity.

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!


> - Eccentric uses a key model where each user has many keys:

This should of course also be raised with the keybase folks.

> Each of those keys is an identity, tied to the site that signed it. Keys
> cannot be shared between sites. This prevents linking of identities
> unless the person reveals it. Or if cookies betray him.

and this

> In Eccentric, people are advised to use a throwaway identity whenever a
> site requires an identity. In Keybase, it's much harder to remain
> anonymous as I expect sites to encourage linking your account to your
> identity.

and again

> 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"?

> Eccentric uses a single CA per site. There is no central repository. The
> risks of compromise are spread out. With some proper use of subkeys, the
> scary part of key management can be outsourced to a service provider.

"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.

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?

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.

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?

But then I'm biased - neither do I understand the value proposition of keybase.


> 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".


> 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?


> With Eccentric it's harder to
> assure a certain key belongs to an author of a publication.

So what value does it provide (sorry, I'm a slow learner).
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

