Re: črypto is finished... and it's about time × (also: 'Balrog' malnet, firsthand view)

Natanael natanael.l at gmail.com
Tue Jun 16 09:44:40 PDT 2015


On Fri, Jun 12, 2015 at 12:02 PM, Zenaan Harkness <zen at freedbms.net> wrote:

> On 6/12/15, Natanael <natanael.l at gmail.com> wrote:
> > Den 12 jun 2015 10:19 skrev "Zenaan Harkness" <zen at freedbms.net>:
> > Don't do F2F at the lowest network layer. Don't give away sociograms,
> don't
> > allow timing attacks, and avoid the whole NAT issue.
>
> Sorry, I'm thinking about it differently - like a physical layer.
>
> Let's name it differently: H2H - HUG node to HUG node, which might be
> overlayed over existing ISP/ centralized net, or might be your own PHY
> layer (e.g. local street-level wireless).
>
> So, treat this is a PHY layer, where everyone is expected to connect,
> relatively speaking, to their neighbours.
>
> A F2F (by terminology/meaning) would overlay on top of that.
>

So like what CJDNS does? https://en.wikipedia.org/wiki/Cjdns

It can be compared to a kind of VPN, it creates an IPv6 addressed network
in the private fc:: range where the addresses are based on hashes of public
keys. The connections can go over the internet, or over meshnets, or over
your local LAN, or over a RONJA link (http://ronja.twibright.com/about.php).

Then on top of that you could run anonymization like I2P and any other
services you might want.


> The key that I2P (and Tor for that matter) are missing is fill packets
> - i.e., the nodes you talk to, promise to backfill their link to you
> (likewise you to them) any empty packet slots, so that the link
> maintains a continuous throughput (to hide all real traffic within) -
> the only thing a state-level adversary (or ISP-level for that matter)
> can do to analyse things is kill the link entirely (shock testing),
> which can correlate your traffic with "exit node" traffic, but is much
> harder to see anything when you are only operating within the dark
> net.
>
> This is now a very important feature which our anonymizing network
> software needs in order to provide any meaningful protection.
>
> Local PHY is now also very very useful to increasing network access
> anonymity. This urgently needs some research study/papers to analyse/
> determine the best ways (within eg onion routing context) to maximise
> advantage of off-net (private PHY layers).
>

IIRC support for that already exists in I2P, although not yet implemented.
The protocol already have support for a number of things like fake filler
traffic.

Anonymizing routing in local networks can be hard to achieve against timing
attacks and other correlation attacks, in particular when assisted by DoS.
The problem is that there's typically a limited number of local routes
going outwards, poor interconnction and not many long-range links, and
node-to-node links reflect human sociograms very well. Having I2P being
able to support connections over both types of networks simultaneously
would be an advantage.


> "Just use..." is very problematic! Please do not be so cavalier with
> your languaging as those without understanding might mistake your
> absolutist languaging for relevant fact (as opposed to intuitive sense
> or reasonable avenue for consideration depending on various factors
> .... etc etc)!
>

I'm using "just" as a synonym for "doesn't need novel research, can be
implemented by a any experienced programmer". As compared to requiring
experts in the field to create new algorithms to make it possible,
practical and secure. The difference between "needs time" and "needs
brainpower".

> I've done a lot of thinking on P2P social networks, I'll share later,
>
> Great. Looking forward to your thoughts. Please don't portend that
> there are easy conclusive "solutions". There are not!


I'm aware there's a very significant amount of work required, see my
comment above. I'm trying to gather the various things I've written about
it now. There's a lot to write down. There's a lot of questions about how
to make it work without massive overhead. I'm trying to figure out how it
should work on each level of abstraction, from data encoding to routing to
key management, etc... I want to see a mainly P2P oriented system that
allows for server assistance (for distribution of signed data, storage,
receiving messages on your behald when you're offline, synchronization /
coordination, etc...). And I keep finding edge cases that would be messy
with most of the potential solutions I'm considering, which is another
reason for why I don't have a complete sketch written down yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 5933 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20150616/041d3506/attachment-0002.txt>


More information about the cypherpunks mailing list