Re: IQ Handling vulnerabilities

Am 11.02.2014 13:29, schrieb Dave Cridland:
> On Tue, Feb 11, 2014 at 12:23 PM, Alexander Holler <[email protected]>wrote:
> 
>> Hmm, in all these mails it was never be mentioned that IDs still have to
>> be unique over some time for one session. I'm not sure if such is given
>> with the above constructs. It might be very unlikely that the same ID will
>> appear twice, but someone has to take a deeper look at it when using such
>> constructs like above. Of course, in reality the window in time IDs must be
>> unique is rather small, but ...
>>
> 
> You'd need random collisions amongst cryptographically secure hashes.
> You're pretty safe.

I don't aggree. You are safe if you use the hash as intendend, but not
if you just use some part of the hash(-number) or hashes of hashes. I'm
not sure about how safe it is (in regard to collisions) if you look at
consequent hashes of hashes. I would assume that is not what
cryptographers do look for (primarily).

At least I can't remember to have seen some discussion if the series of
hash(hash(hash(...))) is collision free (that is imho quiet different
than hash(random); hash(random)). Of course, I'm not looking that often
at cryptographic papers, I usually prefer if cryptographers do such. ;)

> In practise, ids do not have to be unique anyway, even over a small window.
> Most MUC implementations preserve ids on broadcast, for instance, to no
> ill-effect.

How do you track responses if you don't have unique IDs? Unique IDs
might not be necessary for everything, but usually you are unable to
match a response to a request without having unique IDs in consequent
requests (of the same session).

Regards,

Alexander Holler