Re: [tor-talk] [onioncat] Paper for OnionCat and Tor New Crypto

[grarpamp <grarpamp@xxxxxxxxx>]

On Sat, May 30, 2015 at 2:40 AM, carlo von lynX
<lynX@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk