Re: [dev] [quark] patch

On Sat, 5 Feb 2011 13:45:07 +0100
Szabolcs Nagy <nsz_AT_port70.net> wrote:

> * Robert Ransom <rransom.8774_AT_gmail.com> [2011-02-04 18:56:48 -0800]:
> > > -> GET /key#hash-of-data HTTP/1.0\r\n\r\n
> > > <- [waiting..]
> >
> > The server will never see the fragment identifier (the "#" and text
> > following it).
>
> there is no such restriction in http nor in urls
> (it's not a reserved character)

Yes it is. See RFC 2616 (section 5.1.2) and RFC 3986 (section 4).

> your browser strips fragments away, which is good: we don't want
> to use this protocol from a browser, but if you insist on using one
> it's better not to keep the connection open but reply immediately
> (this is one of the reasoning behind using #)
>
> altough i might choose another character (in case proxies etc
> do not handle it properly), the separator does not really matter
> much

The "#" character is an easy fingerprint for DPI firewalls to detect
and block. Your protocol and software will be more useful if you use a
character commonly used in URLs (e.g. "?").

> > > communication here the communicated data does not know its destination)
> >
> > But the server does.
>
> the data you put somewhere is (x,data) the
> server sees (hash(x), encrypt(data,x), yourip)
> neithr yourip nor hash(x) is stored
> only hash(hash(x)) and encrypt(data,x) is stored
>
> of course if a server keeps track which client requested which
> keys then it can associate the communicating parties
>
> but that will be solved with replication: if data does not know
> its destination and is only identified by a key then it can be
> replicated without issues. there will be no single server which
> knows the source and destination as well
>
> eg clients sitting behind a router requesting the same data
> do not necessarily connect to a server: the router can cache
> the data (integrity and authenticity of the data can be easily
> verified, the freshness is more difficult (eg add timestamp
> and expiration?))
>
> full replication is of course not simple to implement efficiently
> especially with notifications in mind, but this part is not
> designed yet
> (at this point you can use simple mirroring techniques for replication
> and polling for notification like in rss feeds)

If you can keep all servers online and connected to each other most of
the time, that should be fairly simple.

If you expect groups of servers to be disconnected for extended periods
of time, there are fancy algorithms that may help; look for 'set
reconciliation' in <http://cs.nyu.edu/~dodis/ps/fuzzy.pdf>.

> (btw tor is not very useful here: it adds encryption layers
> during routing we don't need, and in the end sends the original
> data to the original target, so it needs to know the data and
> target, we only know the (already encrypted) data, there is no
> target.

I said 'have all clients connect to the server using Tor'.

> we don't want strong anonymity guarantees at this point, only privacy.
> tor only gives anonymity iff the entry and exit nodes are not
> compromised)

Even if you add replication among many servers, your system will still
only give anonymity iff the entry and exit nodes are not colluding.

If you ever do care about anonymity, a well-designed mix-net system can
provide stronger anonymity than Tor *and* be much more efficient than
replication for non-multicast messages.

Robert Ransom