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

[Zenaan Harkness]

On 6/12/15, Natanael <natanael.l at gmail.com> wrote:
> Den 12 jun 2015 10:19 skrev "Zenaan Harkness" <zen at freedbms.net>:
>>
>> On 6/12/15, grarpamp <grarpamp at gmail.com> wrote:
>> > On Thu, Jun 11, 2015 at 10:17 PM, Zenaan Harkness <zen at freedbms.net>
> wrote:
>> >> May be time to get serious about known-user to known-user
>> >> offline-key-established networks - F2F network, not necessarily
>> >> darknets either, but a new "public" network - to join the new internet
>> >> you must contact your local HUG (hospitable user group) for assistance
>> >> and establishment of shared keys.
>
> [...]
>
>> Some possible next steps to focus on:
>> - How to ensure that what we download, e.g. for an Ubuntu system
>> upgrade, is actually what is intended to be distributed by the
>> developers?
>> - How can we reduce the dependencies when "publicly browsing" - e.g.
>> slim down TBB (e.g. do not support SVG fonts, and much more)?
>> - How do we improve the security of the code we are depending on (in
>> the public website viewing pipeline)? E.g. industrialized fuzz-testing
>> (libraries, kernel-level code like the network stack, kernel data
>> structures, kernel drivers etc)?
>
> Harden and trim something like Tails. Run the better minimum.
>
>> Medium to longer term:
>> - Now that no OS is spared when accessing public web sites, even with
>> F2F encrypted network infrastructure, we need a specification/
>> foundations for a hardware-level F2F network node - e.g. libre open
>> code from the BIOS/ firmware up to "userspace" e.g. the VPN code etc.
>> - What type of F2F network makes sense?
>> - What type of crypto is reasonable with current think, for our F2F
> networks?
>> - Document protocols for key exchange/ OS installation/ F2F HUG meetings
> etc.
>> - Userspace network stack - Simplify (and audit) network packet
>> pathways - e.g. take a copy of the Linux network stack, remove
>> everything extraneous, perhaps make it a user-space thing with really
>> minimal "driver" code in the kernel only - this might be a good
>> foundation for multiple cross-project collaboration (eg TBB, I2P, Tor
>> node, Gnunet, mixmaster, openvpn, whonix/ qubes, etc).
>
> 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.


> Just stick with I2P or similar traffic anonymization networks and run your

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

> traffic on top of that. Oneswarm (now abandoned, IIRC), RetroShare, or

"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)!


> whatever else, run that over the anonymizing networks. Inviting somebody
> would be a matter of sharing the public key based address to the public
> services and noting his public key so you can accept an invite request, or
> directly send an invite to private mail of his like Bote mail or Pond.

There are many models.

I am confident that local off-net PHY connections can go a long way to
increasing anonymity provided by anonymizing P2P networks - it's an
avenue unfortunately untapped, and even more so, not yet studied
academically.

This is one small, yet important, piece of the longer term puzzle.


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


> haven't written it all down yet. You can find a bunch of my thoughts on
> these matters in my blog, https://roamingaroundatrandom.wordpress.com,
> there's multiple relevant posts there. I know approximately what I want and
> how to make it easy to secure. One crucial part is key management where I
> believe hardware tokens is the best solution, including for in-person key
> exchange (see the developments for Bitcoin hardware wallets).

Sounds like you've indeed done some thinking. Thank you very much for
sharing your thoughts.

We evidently have a long way to go, as a community.

Regards
Zenaan