Delivery-Date: Fri, 31 Jul 2015 04:47:48 -0400
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 A1B761E0349;
	Fri, 31 Jul 2015 04:47:46 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 302A435664;
	Fri, 31 Jul 2015 08:47:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id E0019353BB
 for <tor-talk@lists.torproject.org>; Fri, 31 Jul 2015 08:47:37 +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 Jb5MIy9ZtJvo for <tor-talk@lists.torproject.org>;
 Fri, 31 Jul 2015 08:47:37 +0000 (UTC)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com
 [IPv6:2607:f8b0:4001:c06::234])
 (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 B3C8320927
 for <tor-talk@lists.torproject.org>; Fri, 31 Jul 2015 08:47:37 +0000 (UTC)
Received: by ioeg141 with SMTP id g141so79141812ioe.3
 for <tor-talk@lists.torproject.org>; Fri, 31 Jul 2015 01:47:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=2xB7Q52Qi9e0sk/j7rKBvvrApRfu+mbs6K7K0rclx6A=;
 b=yoIg/yEQo2b//Sj8YU9GNl/RPD8zlglHW/IMWNeM+PKhNsTa4EQ3TjnEjgoDn/fVqZ
 ThTtgBjrp8BRP9Rpaib2Pz/wCrTkorZ0Nz5XehSg6jiyA+vBS2TOmADosOri7Oe/B5xO
 Enr07msRMf11uuoVMxcHUCdYE6uy8FSlmIBd/6Gi2+tZ7xSEi1hb4MeL6iuijZgn0gzI
 Bf/TUObiKHHwd0qeHaw5s8YpSpoO6GFyBWqD96pN0BgClBkN2FreJuwmXjSrrZyLA9H8
 8ssJw6Htj94sXT4uUiGsZBSbvPhud6js9UpcIYH/NCVAAhIZoxX1ubtSB/UNUNCbHUmP
 8Fag==
MIME-Version: 1.0
X-Received: by 10.107.128.214 with SMTP id k83mr3029717ioi.7.1438332455468;
 Fri, 31 Jul 2015 01:47:35 -0700 (PDT)
Received: by 10.36.44.69 with HTTP; Fri, 31 Jul 2015 01:47:35 -0700 (PDT)
In-Reply-To: <20150530064018.GA2622@lo.psyced.org>
References: <CAD2Ti29GdabbDUMK9fXBR00RJ4Fbg-VHNN9eFwOOUDgecGBeHQ@mail.gmail.com>
 <3997552.s7nlVdOtgF@kerdohl> <20150530064018.GA2622@lo.psyced.org>
Date: Fri, 31 Jul 2015 04:47:35 -0400
Message-ID: <CAD2Ti2_D3mh5xi9XNfb+xLFSGidnhV6pB8t1RcCXwGPWy1NnLA@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: tor-talk@lists.torproject.org
Cc: onioncat@lists.blackmesa.at
Subject: Re: [tor-talk] [onioncat] Paper for OnionCat and Tor New Crypto
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 Sat, May 30, 2015 at 2:40 AM, carlo von lynX
<lynX@time.to.get.psyced.org> wrote:
> On Mon, Feb 16, 2015 at 09:19:51AM +0100, Bernhard R. Fischer wrote:
>> On Sunday 15 February 2015 12:59:08 grarpamp wrote:
>> > Hello.
>> > Is there an English version of a paper (or presentation) for this?
>> >
>> > Bernhard Fischer - OnionCat und Tors neues Kryptosystem
>> > https://www.youtube.com/watch?v=Zj4hSx6cW80
>>
>> Unfortunately not yet.
>> I'll write a proposal in English on my blog.
>
> Sorry, I only watched this presentation now.. months later.
>
> It didn't click with me why you would do such a hack to
> allocate a "next" onion if all you need is a way to upgrade
> an 80 bit hash to a full public key. Well, I presume Tor
> will maintain backwards compatibility with 80bit onions
> anyway, so you can always just look up the 80 bit hash and
> find out which key owns it. Should Tor one day indeed upgrade
> its crypto it could generate 301 redirect messages from the
> old .onion names to whatever comes next. Or it could pin them
> in the router. I don't see the need for the procedure that
> you proposed.
>
> Also, providing a global cryptographic IPv6 address scheme
> in the spirit of cjdns looks like a false problem to me.
> Cryptographically authenticated IP numbers do not solve the
> problem that DNS can be spoofed to return the wrong address.
>
> Therefore if people want an address they can refer to and that
> will always be valid, they can use a simulated TLD which uses
> the entire public key, much like the .zkey proposal. There is
> no advantage in mapping it into the IPv6 address space, losing
> bits in the process.
>
> If instead people want an address they can memorize, then they
> need a new naming system that doesn't mess up security and/or
> look-up privacy. What about GNS for that.
>
> I think the cjdns/onioncat style is the wrong approach, even
> if it gives everybody an excuse to check if thep rograms
> are indeed IPv6 compatible, and kind of has an air of a neat hack.
>
>
> --
>   E-mail is public! Talk to me in private using Tor.
>   torify telnet loupsycedyglgamf.onion          DON'T SEND ME
>           irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
>          http://loupsycedyglgamf.onion/LynX/    OR FACEBOOGLE


> 301 redirects

This implies all a network expects and allows its users to do is
browse, and in some strange transport way at that. Nothing wrong
with that, however that's an artificial limitation of what the
network behind it might be capable of.

> DNS

People need to be clear what they mean by "DNS", "naming", etc. As
a lookup of, or into, something else? As a "human" representation
of something? As something used by the network itself, or by apps
on top of it? Etc.
And note that you don't really need "names" or "DNS" if your apps
or personal notebook perform an equivalent to storing "bookmarks"
of whatever address scheme is in place. TorChat / onion addresses
and bittorrent hashes are managed locally that way.

> I don't see the need for the procedure that you proposed.

It has to do with support for apps over some nets that don't offer
IPv6 natively. Not necessarily part of a networks crypto itself.

The notion of IPv6 is that you can immediately plug whatever
preexisting applications you want into those networks. That avoids
needing to write apps from scratch and/or pleading with app upstream
to support your particular crypto addressing scheme, transport
protocol, or usage model. On some networks IPv6 capable apps either
won't work at all, or are partly constrained, which may bring
slower adoption of a network than desired due to users needing
to switch apps into you.

It was a neat (even coincidental) design hack to have one-to-one
mapping between IPv6 and the internal crypto addressing.

If your crypto addressing is wider than IPv6, it's not a loss of
bits to register a map in some auxiliary lookup thing such as a DHT,
it may be possible that it's only there for app support.

If you're a general purpose overlay transport network that doesn't
care about existing apps and wants to force people to expend writing
new apps and wait long time for new app ecosystem to flourish over
it... then any cryptographic "name" (addressing) scheme that doesn't
present an IPv6 address will work.

Some features to compare (my nomenclature sucks)
- native one to one addressing vs a map between sparsely used address spaces
- bidirectional communication using src and dst addresses
- direct existing app pluggability (meaning IPv6 via tun)
- raw IPv6 (not just TCP)

A rudimentary ranking of support for existing IPv6 capable apps
between internal endpoints (roughly better on the left)

Cjdns and Phantom / Tor (Onioncat) / Gnunet (VPN/PT ?) / I2P (Onioncat)
[ No support: native modes of Tor, I2P, Gnunet, and Freenet ]


I may be mistaken as to forum but I think there were also some
threads around IPv6 on forum.i2p or zzz.i2p.
-- 
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

