[mnet-devel] open issue in record keeper, part 3: efficiency
Zooko
zooko at zooko.com
Sun Jul 27 18:31:54 BST 2003
How big do these things get? Less than 1 KB?
And how many of them are there? Do we get a number of different records that
grows something like linearly with the total number of nodes on the network?
Or even super-linearly?
One possibility that we could consider for the future -- i.e., if storage
space for records were to become an issue -- is to introduce an added layer of
indirection in front of the current design. Take the encrypted record, take
the SHA1 hash of it, and store it under that id in the net (i.e. -- treat it
exactly like a block), and then have the other keyword-based ids map to the
canonical blockId instead of mapping to the encrypted record itself.
See what I mean?
There are a few interesting things about this:
1. To add a new keyword to an extant record takes up only O(uniqueId) space,
i.e, around 20 bytes plus overhead.
2. By the same token (ha ha) it becomes harder to do a "flushing" attack
against a node who is holding keywordIds (which map to the record's blockId),
but not holding the actual encrypted record. Every new mapping you send him
for the keywordId "lisa" takes up another O(uniqueId) of his space, instead of
taking up another O(record) of his space.
Now the flushing attack against the record itself looks exactly like the
flushing attack against any block -- data block, inode block, or record block.
3. You could choose to publish the encrypted record block, and then give your
friends mnetURIs to the record block, without publishing *any* keyword based
mappings. This is one possible way to provide a specific privacy guarantee,
which is the same as the normal stored-file privacy guarantee, and cleanly
re-uses the current code.
The drawbacks are obvious: an added layer of indirection makes things slower,
more prone to failure at runtime, more complicated to implement and
understand, etc..
Also, technique #3 above is only good for private sharing of metadata. For
public metadata that you want anyone to find, #3 is useless.
--Z
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel
More information about the Mnet-devel
mailing list