On 2012/12/20 (Dec), at 6:31 PM, Matthew Toseland wrote: > Do an "insert" ... into [many nodes] pre-insert cache, including X_n. > When all the keys have been pre-inserted, ... send a Reveal request for each > block.
This is really fun to think about, but... > Protecting the reveal stage I think that's where the crux of the matter lies. I haven't thought it through too much (but for the sake of bouncing ideas and what not), what if you turned the problem around to make the initiative of revelation come from the target instead of the inserter? e.g. secret_key=generate(); key_hash=calculate_chk(secret_key); address=pre_insert([key_hash,encrypted(data)]); [...insert the other blocks?...] insert(secret_key); //for which the target is polling... I suppose it might be more expensive, but it would be easy to implement, and might even increase the likelihood of insert success (because it would then follow the fetch/demand trail towards another location). It would also be easy to make cascading reveal chains, which (I think) could be used to avoid naredowells sniffing for the secret/revealation key [since it's location is known] with even one level of indirection [because the reveal key is coming from a location that is not the inserter], but could be deepened as needed if there is reason to believe that the network is mostly hostile. -- Robert Hailey
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
