For several reasons I think we need to discuss the dubious security assumption of "it's hard to probe your peers' datastores", and the performance tradeoffs that go with it ...
Why is this important now?
- Darknet bloom filters. Okay, it's darknet; there's more trust; so
that's okay then? Maybe.
- Opennet bloom filters (for long-lived peers). We'll need to identify
long-lived peers anyway for tunnels and security (MAST countermeasures).
So it'd be good to do bloom filter sharing with them.
- Opportunistic data exchange (possibly with CBR) (on both darknet and
opennet).
- Broadcast probes at low HTL. Same effect as bloom filter sharing but
work with low uptime nodes. Can be made cheap; we don't have to wait for
them before forwarding, and we because latency isn't a big deal we can
aggregate them and make them cheap. (We might want to wait for them,
with timeouts, before finishing with DNF) Would probably have to be
non-forwardable, to cut costs ... so it's a true probe. But then the
security model is the same for bloom filter sharing - except for the
bandwidth cost, which makes probing bloom filters a bit more costly...
What is the model?
- Censorship: We want it to be hard for bad guys to identify nodes
containing a specific key and eliminate them. Classically, fetching a
key tells you where it's stored (the data source, used for path
folding), but in fetching it you have propagated it. The problem with
this theory is you've only propagated it to *caches*, not stores.
-- Does this mean we need to give more protection to the store than the
cache? E.g. only do bloom filter sharing for stores, only read store for
broadcast probes?
-- Possibly we could avoid path folding if we served it from the store?
However this might make path folding less effective...
- Plausible deniability: The bad guys request a key from you. You return
it. It might be in your store or it might not be; you might have
forwarded the request, and the attacker can't tell. This is IMHO
legalistic bull****. It's easy to tell with a timing attack (and
whatever randomisation we add won't make it much harder, as long as you
are fetching multiple keys). Also, RejectedOverload{local=false} implies
it came from downstream, though probing would use minimal HTL so might
not see that... (But at least *that* is fixable; it is planned to
generate RejectedOverload{local=false} locally when we are over some
fraction of our capacity, as part of load management reforms).
The security issues are doubtful IMHO. So it really comes down to
censorship attacks... The problem with censorship attacks is inserts
store the key on ~ 3 nodes; it's cached on lots of nodes, but the CHK
cache turnover is very high; if you take out those 3 nodes, the data
goes away very quickly. So the classic attack of "fetch it and kill the
data source" may actually work - if you care about blocking single keys,
or can kill lots of nodes (e.g. all elements of a splitfile middle layer
etc).
Do we need even more "put it back where it should be" mechanisms? E.g.
if a sink node finds the data from a store probe it should store it?
Would this help with censorship attacks?
The average store turnover is unknown but guesswork suggests it's around
2 weeks ...
Possibly we need to know the average turnover times of the store, cache,
for SSKs and CHKs. Do we have a probe for that?
(Might be a good reason for people to insert as SSK!)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
