On Fri, May 04, 2001 at 12:29:20AM -0400, Tavin Cole wrote: > On Thu, May 03, 2001 at 11:03:55PM -0500, Scott G. Miller wrote: > > On Thu, May 03, 2001 at 10:41:30PM -0400, Tavin Cole wrote: > > > 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. > > > > > It should. The whole point here wsa to have a mechanism in place to force > > encryption of files. > > Yea, the code's commented out - ?? It shouldn't be.
> > > the crypto key at the beginning of the document makes things > > > unnecessarily difficult. > > Why? > > Well, part of it is that having to strip off those few bytes tends to > require a whole extra filtering stream wrapped in, in the client code > I am working on (as I have to set up a passive layering of output > streams instead of an active layering of input streams). Also, I > need to know the metadata length in order to set up these streams, > but I need them set up to read the metadata length :) Thats a decent point. > Then consider FCP where you want to return the MetadataLength in the > DataFound response, but you don't know it until the first DataChunk. Also good. > Of course I can deal with all this, but it will complicate our reference > code in odd ways, and I expect would be difficult to handle in any > language. > > > And why expose any more information to the node than it needs? > > I agree. I was expecting that it would be sufficient to encrypt the > items in the storables. There's little difference between that and > having it at the beginning of the trailing field. Is there a subtle > cryptographic vulnerability, even if you go as far as lumping it > under Storable.Client-data? > I don't think so, except for perhaps making a known-plaintext attack easier, but not really, since that length would have gone in the document itself. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20010504/8c00a318/attachment.pgp>
