Instead of only bashing tor, why not discuss the alternatives?

[Zenaan Harkness]

On Tue, Jul 19, 2016 at 11:44:16AM +0300, Georgi Guninski wrote:
> Instead of only bashing tor, why not discuss the alternatives and move
> to something allegedly better?

Great question Georgi.


> Certainly some advanced attack and/or backdoor will screw them all.
> 
> For a start, I would like to know:
> 
> 1. What are alternatives to tor (possibly with less functionality)?

I2P has been touted, but despite a stated intention, it still lacks the
most relevant fundamental enhancement over tor:
- chaff traffic (i.e. maintain e.g. a 15kibps connection to each of my
  direct peers, throtting and chaff-filling as needed to achieve that)


> 2. Is the alternative known to be in bed with shady stuff like TLAs?
> 3. Did they have braindamaged bugs (like debian's openssl memset())?
> 4. What is their security/anonymity bug history?
> 5. To what attacks they are known to be vulnerable?
> 6. To what attacks they are conjectured to be immune?
> 
> As an aside, I heard critique of Riffle: MIT are allegedly in bed with
> USA. Don't know it this makes sense or not.

Fundamentals of any stack for any system are:

 - physical concept - N2N/ neighbour to neighbour vs software overlay
   on existing ISP based centralised "Internet" as people know it today


 - hardware
   - open cores are available
   - but audit trails and distribution networks and more still need to
     be solved conceptually, before any sort of kickstarter/ community
     group funding


 - ability/ tools/ software for small community groups to randomly audit
   a random chip, circuit board, ethernet jack, etc, to verify that it
   conforms to a FLOSS design


 - bios and firmware - EVERY piece of the stack MUST be FLOSS!
   - needs to be audited


 - drivers - more FLOSS required
   - need a minimal set, to go with chosen hardware
   - needs to be audited


 - network stack - floss of course
   - needs to be audited



Pick any level of the stack, have a think, and contribute.


My current pet thought lorenz well is the network stack - twould be good
to have an analysis of available stack, comparing them re various
attributes, including:
 - simplicity
 - dependencies - libraries, data structures
 - suitability to user space operation
 - what application-level APIs/ libraries would we want to target,
   e.g. just UDP (not TCP :), sockets, SCTP, ethernet, more?
 - "flexibility"
 - to what level is it field tested?


Sadly, there is much work to do before we can even begin to satisfy the
Juan's of the world :/