Currently the full structure of an unencrypted Freenet document looks like this:
2 bytes: crypto key length X bytes: crypto key, where X == crypto key length remainder: actual file data This allows the requesting client to check that it in fact has the correct decryption key, although the java clients don't actually do this. The key specs are changing in 0.4, mainly in order to make the storables untamperable. While we are doing this, I believe we should also take the opportunity to move Metadata-length out of the storables. One way to do this would be to encode it into the document structure (#1): 2 bytes: crypto key length X bytes: crypto key 8 bytes: metadata length remainder: actual file data However, at least as far as the java implementation goes, this is rather difficult to deal with in practice. Actually even having the crypto key at the beginning of the document makes things unnecessarily difficult. So what if we don't put _any_ extra stuff at the beginning of the document, and instead put it in the storables, but encrypted with the same crypto key as the file data itself? One possibility (#2): Storable.Symmetric-key=<hex,encrypted> Storable.Metadata-length=<hex,encrypted -- exactly 16 characters> Another way would be to make it totally opaque to the node (#3): Storable.Client-data=<arbitrary encrypted data in hex or base64> In which case, this structure could decrypt to a full FieldSet, which would be the most extensible, or it could decrypt to something more rigid like: <2 bytes crypto key length><X bytes crypto key><8 bytes metadata length> Opinions? I am favoring #2 or #3. -- # tavin cole # # "The process of scientific discovery is, in effect, # a continual flight from wonder." # - Albert Einstein _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
