[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Aside of Tor Research Project: SlowTor
Gerardus Hendricks writes:
> As an aside, I'm really interesed in how we could modify or build an
> adapter to the web so it is more tolerant of high-latency interaction.
> Seeing recent events it seems prudent to start thinking of ways in which
> common applications could (for a small part) function in a high-latency
> environment. We need to have a SlowTor.
>
> It could for example work really well for many read-only uses of
> applications, like reading web pages or other structured data (tweets,
> video, maps, comments). A high-latency proxy to the open internet would
> require nodes to cache content. The main problem is denial of service: how
> to prevent nodes from forging the data itself? We assume that for the most
> part, publishers won't be bothered to cryptographically vouch for the
> authenticity of the data (like Freenet requires). A best-effort service
> combined with BadNode flags would already be a lot.
Maybe content-based networking
https://en.wikipedia.org/wiki/Named_data_networking
can address this model.
I also heard about HTML element attributes to let you refer to objects
by their hashes, although I don't remember which standard this is being
proposed for. I guess the idea is that instead of (or in addition to)
<img src />, you can specify <img hash /> and you indicate which static
resource to load by its hash value. In that case, both attributes
could be provided at the same time, and the src attribute can be viewed
as an initial bootstrapping hint but not the only means of resolving
the reference.
> An aside of an aside: if a node would provide a complete (non PFS) TLS
> conversation between him and a webserver, could a 'verifyer' that agrees
> on the certificate belonging to that Common Name, verify that the data
> contained in the conversation was indeed sent by the server in possession
> of the private key belonging to that certificate?
Do you mean that the verifier is allowed to know the client's or
server's keys, or only to see the encrypted session as a passive
network adversary would see it?
--
Seth Schoen <schoen@xxxxxxx>
Senior Staff Technologist https://www.eff.org/
Electronic Frontier Foundation https://www.eff.org/join
815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk