Re: [freenet-dev] SSK/KSK Collision

Top Page
Author: Matthew Toseland
Date:  
To: Discussion of development issues
Subject: Re: [freenet-dev] SSK/KSK Collision
Delete this message
Reply to this message
gpg: Signature made Fri Apr 21 17:31:44 2006 UTC using DSA key ID 6554A22D
gpg: Good signature from "Matthew John Toseland (Toad) <toad@amphibian.dyndns.org>"
On Thu, Apr 20, 2006 at 02:49:11AM +0100, Dave Baker wrote:
> Hi,
>
> So I've just spent a while tracking down why KSKs and SSKs don't collide, even
> if you insert different data. The answer is that in
> MultiPutCompletionCallback, onFailure gets called, but doesn't complete the
> request because it's still waiting on some blocks. onSuccess then gets called
> and so it returns success and tells the client that everything went fine.
> This could be fixed by changing the:
>
> complete(null);
>
> (line 40), to:
>
> complete(this.e);


Suggest you fix it.
>
> Which would consider any exception which it may have been given earlier. I'm
> happy to change this, but I'm not really sure whether this is a mistake or by
> design, since there is a certain degree of sense in reporting success when
> the onSuccess method is called, even if a failure occurred in the past. Note
> that, as far as I can tell, this only applies to collisions and cancellations
> - other errors (RNFs and the like - I assume all the nonfatal ones) are
> handled differently.
>
> The second problem, however, is that nodes always report a collision, even if
> the data is the same. After some probing, it turns out this is because the
> last 64 bytes of the SSK headers are different between the block from the
> data store and the block being inserted (see 'equals' in SSKBlock.java). I
> gather from the comments in SSKBlock.java that these are signatures on the
> rest of the hash, so I'm confused as to how they can be different when the
> other 72 bytes are identical. This part I could use some advice on. Are they
> meant to be the same, or is there some reason why they'll differ?


Ah. DOH. Yeah, this needs to be handled specially... the signatures are
different because they incorporate a random element. We need to compare
everything except for the signatures (while still checking the sigs).

Please file a bug for this. :)
>
> Sorry for the slightly lengthy email!
>
>
> Dave (dbkr)

-- 
Matthew J Toseland - toad@???
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.