Instead of only bashing tor, why not discuss the alternatives?
Zenaan Harkness
zen at freedbms.net
Tue Jul 19 02:30:57 PDT 2016
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 :/
More information about the Testlist
mailing list