Den 12 jun 2015 10:19 skrev "Zenaan Harkness" <zen@freedbms.net>:
On 6/12/15, grarpamp <grarpamp@gmail.com> wrote:
On Thu, Jun 11, 2015 at 10:17 PM, Zenaan Harkness <zen@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).