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

[Natanael]

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.

Just stick with I2P or similar traffic anonymization networks and run your
traffic on top of that. Oneswarm (now abandoned, IIRC), RetroShare, or
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.

I've done a lot of thinking on P2P social networks, I'll share later,
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 3791 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20150612/db385034/attachment-0002.txt>