Delivery-Date: Sat, 27 Feb 2016 06:35:00 -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_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,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 8138C1E0359;
	Sat, 27 Feb 2016 06:34:58 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id C33D539CE2;
	Sat, 27 Feb 2016 11:34:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 03E1139A9C
 for <tor-talk@lists.torproject.org>; Sat, 27 Feb 2016 11:34:49 +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 5tFteoD6rI2C for <tor-talk@lists.torproject.org>;
 Sat, 27 Feb 2016 11:34:48 +0000 (UTC)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com
 [IPv6:2a00:1450:400c:c09::22f])
 (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 916A6396A8
 for <tor-talk@lists.torproject.org>; Sat, 27 Feb 2016 11:34:48 +0000 (UTC)
Received: by mail-wm0-x22f.google.com with SMTP id l68so4184305wml.1
 for <tor-talk@lists.torproject.org>; Sat, 27 Feb 2016 03:34:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=subject:to:references:from:message-id:date:user-agent:mime-version
 :in-reply-to:content-transfer-encoding;
 bh=ccAbeY8IQUaluHMcxkt2k1FnGB888T/E6Y7mJ3eiRS4=;
 b=v5GAidZgJWyA8nMdG+/fWFDF0ioXCxwz4hxLqh/vfFkysQuEYXl8W45xEi2iLiBAKP
 TmsxrhpaUyJ1jLJwusfmNHMVLego3kOZOXYlpok9JDEVrO9TYDdJA54PN98Kb3BcbjM5
 KvX8R/o9n3T91KLpBgWXoEZK4J+GUzsdlF121r/qA/YO/DhsBEYN93pD4WuGPOn6NlM3
 PbNxmTyrztdSEcrpxifHMUaDXTGFttmNVVmW1O72csIdUgNIZ3PQbrWTSP1agTHPJi04
 Ijgn31P3UrmIWnQVXLetL6phwWdOYkZd8vGgXjbbVSaN7u++HANdKSVNu9k5heID/3I0
 xX/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:subject:to:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding;
 bh=ccAbeY8IQUaluHMcxkt2k1FnGB888T/E6Y7mJ3eiRS4=;
 b=NxdhpR9Ea58Qp+t6J1rQVflf5AHkJg0l7nIffxi/xbd+NU3tsx+qkMD0shwSlhuDbm
 4lJ0lgO2TwOlsoPmn0IQmIEFlLV4shGSDuU9NoD7xp0cLaNDNKZbCwVy9JAl/oXrQ0UY
 zvonaNMYN3U15tirzWo7SWP+BjrOyD07MMWcKpIY1b5wzJlytxiGT0210ajVwJIJlOuL
 soj9j/1S8ESqIhnSHKD2StkMIiluERYLEp8vgsTvCnIYkyTQkmotn3mGoXISvW0NXZwi
 YNDatC8/hJjXHdOZyePr3QfkZbSWE1rlDGZQkYGUuiVbBQEWxXx7G8Q4586CbkG2bFYA
 a+jw==
X-Gm-Message-State: AD7BkJIYr+gdhmjbJyBNFqJfjh7RO1vOl0iF6piIwz4gCHSxiYT+BBa6cyRwIXv1U1u5cQ==
X-Received: by 10.194.90.172 with SMTP id bx12mr6010424wjb.128.1456572885538; 
 Sat, 27 Feb 2016 03:34:45 -0800 (PST)
Received: from [192.168.1.10] (ANice-654-1-121-198.w86-203.abo.wanadoo.fr.
 [86.203.176.198])
 by smtp.googlemail.com with ESMTPSA id j18sm6848327wmd.2.2016.02.27.03.34.44
 for <tor-talk@lists.torproject.org>
 (version=TLSv1/SSLv3 cipher=OTHER);
 Sat, 27 Feb 2016 03:34:44 -0800 (PST)
To: tor-talk@lists.torproject.org
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>
 <CAOsGNSSATd0AOwfVEV+Ejp32+7BE7SfvTXnVi1M2DPTVLVBGqQ@mail.gmail.com>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <56D189DA.6000806@gmail.com>
Date: Sat, 27 Feb 2016 12:34:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAOsGNSSATd0AOwfVEV+Ejp32+7BE7SfvTXnVi1M2DPTVLVBGqQ@mail.gmail.com>
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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

100% OK with Zenaan

Maybe slow too but this model would need another validation step (like
sites' CA verification via an external system, blockchain for example)

Which seems useless, the concept of CA is obsolete, in addition the
future for ID management can't be centralized.

I have evoked the problem already, the web is imposing strange
limitations due to the CA system (for example you can't "downgrade" a
https connection using ws) for entities that can't have valid
certificates, for example a WebRTC peer or a Tor router.

So I believe the right model would be to have a peerID system
management, a peerID can be a peer, a server, a website, so can be
called entityID too, in a decentralized system like a blockchain.

Then instead of CA validation, this system can be used to validate IDs,
for the web and/or between peers, then people can build services on top
of this, like a P2P network inside browsers using the Tor protocol to
exchange data, access sites, etc, and other services on top of this like
messaging, chat, etc

Le 26/02/2016 23:47, Zenaan Harkness a =E9crit :
> 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 anc=
hor?
> =

> =

>> 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 ke=
ybase.
> =

> =

>> 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).
> =


-- =

Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-- =

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

