[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