On Sun, Apr 08, 2001 at 03:12:49AM +0100, toad wrote:
> On Sat, Apr 07, 2001 at 07:18:33PM -0400, Tavin Cole wrote:
> > On Fri, Apr 06, 2001 at 06:31:27PM +0100, toad wrote:
> > > 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...
> >
> > No it can't. It's true you get 2 different CHKs inserting the same data
> > stream
> > with Fred and libfreenet if there is a metadata section. But the fact that
> > Fred
> > currently uses a different _convention_ for deciding what encryption key to
> > use
> > opens up no attacks. The only reason there is a _convention_ is to make
> > identical files collide by encrypting them with the same key so that the
> > data
> > the CHK is made from is the same. So all this little bug does is reduce CHK
