On Fri, Apr 06, 2001 at 06:31:27PM +0100, toad wrote:
> To: Steven Hazel <sah at thalassocracy.org>
> Subject: Re: libfreenet patch for htl=0 => don't insert, just generate CHK
>
> On Fri, Apr 06, 2001 at 05:03:51PM +0100, toad wrote:
> > On Fri, Apr 06, 2001 at 04:28:16PM +0100, toad wrote:
> > > Hi. I have patched libfreenet-0.3.0 so that HTL=0 causes it to generate
> > > the CHK
> > > but not insert the file. Attached patch.
> > >
> > Also, -m doesn't work.
> > $ testclient -i -f 1 freenet:CHK at CxnLMc~RfDCIooExc25ke7nfRyUOAwE -h 0 -d
> > -m 26
> > reached EOF
> > key:
> > freenet:CHK at p0rl410lZ0QcAfxg~~AHKWXH4lAOAwE,~lowoPtaSZxH7C~vG-QApw
> >
> > $ testclient -i -f 1 -m 26 freenet:CHK at CxnLMc~RfDCIooExc25ke7nfRyUOAwE
> > -h 0 -d
> > reached EOF
> > key:
> > freenet:CHK at p0rl410lZ0QcAfxg~~AHKWXH4lAOAwE,~lowoPtaSZxH7C~vG-QApw
> >
> > $ testclient -i -f 1 -m26 freenet:CHK at CxnLMc~RfDCIooExc25ke7nfRyUOAwE -h
> > 0 -d
> > reached EOF
> > key:
> > freenet:CHK at p0rl410lZ0QcAfxg~~AHKWXH4lAOAwE,~lowoPtaSZxH7C~vG-QApw
> >
> > $ testclient -i -f 1 -m25 freenet:CHK at CxnLMc~RfDCIooExc25ke7nfRyUOAwE -h
> > 0 -d
> > reached EOF
> > key:
> > freenet:CHK at p0rl410lZ0QcAfxg~~AHKWXH4lAOAwE,~lowoPtaSZxH7C~vG-QApw
> >
> I see what the apparent problem is now. Fred 0.3.8.1 uses the file content,
> not including the metadata, to get the encryption key. This is a bug as has
> been pointed out on the list recently (is there going to be a 0.3.8.2 soon?).
> libfreenet does what Fred should, and will/soon will, do, i.e. it hashes the
> whole file including metadata to get the encryption key. This is incompatible
> with 0.3.8.1, so means I can't use libfreenet to get the CHK of files I then
> insert with Fred (specifically, GJ's PutFiles wrapper). I may be able to patch
> libfreenet to have an option for the broken fred behaviour, but it becomes
> irrelevant when fred 0.3.8.2 comes out. More seriously, it means that we have
> an instant way to produce CHK collisions - put something in with the same
> data+
> metadata, but change the boundary byte from one to the other, and you get a
> different CHK. Can be used for some interesting spoofing attacks...
Umm, I mean the same CHK. libfreenet produces the exact same CHK for the same
datastream regardless of where the divide between metadata and data is. Is this
the correct behaviour? Isn't it a risk with malicious collisions?
--
Always hardwire the explosives
-- Fiona Dexter quoting Monkey, J. Gregory Keyes, Dark Genesis
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
