Re: IQ Handling vulnerabilities

Am 11.02.2014 18:28, schrieb Alexander Holler:
> Am 11.02.2014 18:06, schrieb Dave Cridland:
>> On Tue, Feb 11, 2014 at 4:31 PM, Alexander Holler
>> <[email protected]>wrote:
>>
>>> which I interpret such, that, besides using a hash from hash (so no new
>>> source), the ID consists of just the first 10 characters of the 40 of a
>>> sha1. And then you argument with the collision rate of sha1?
>>>
>>>
>> Oh, I see what you mean now.
>>
>> Yes, on that model the collision would probably happen much sooner.
>>
>> It's a collision space of 2^40, though, so a birthday attack would hit
>> after about 1.3 million stanzas by my calculations. The chance of this
>> causing a problem seems pretty low.
>
> Based on the assumption that a hash of a hash has the same collision
> space as the hash itself.
>
> Since I'm long out of university and academics and I'm unfortunately
> quiet out of practice in dealing with maths (even if I liked to do so,
> but math isn't needed that often in real world computing than
> universities tend to teach), I'm not going into a discussion about how
> (un)likely it is that two consequent outputs of such a homegrewn
> algorithm (sorry for that term) are different.
>
> I just wanted to raise awareness that whatever is used should still
> produce unique numbers (for a short period of time) and not just numbers
> which are unpredictable. It's easy to predict that a serial counter is
> unique for some time, but I don't see that when someone uses a series
> like whateverhash(whateverhash(...) and I wouldn't trust such without
> having a deeper look at it.

To play with that hash of hash, is it possible that the hash of a hash 
is the hash itself? If that ever happens your system will have a 
problem, so how likely is that? And in the proposed solution it's a bit 
more difficult, because only the higher 5 bytes of the 20 bytes long 
hash are used. At least for me, the answer to that isn't obvious.

Regards,

Alexander Holler