Valery Smyslov writes:
> You missed the point. The attacker finds a collision so that
> C1 (sent to initiator) contains COOKIE notification (with
> SAi', KEi', NONCEi' included), while in C2 (sent to responder)
> the notification type is changed from COOKIE to smth unknown
> (and of course the length changed too, as in original attack).
The attack finds common-prefix-collision, i.e. where everything before
the C1 and C2 is same. If the C1 and C2 requires some kind of
structure (i.e. other needs to start with 0x2100009600004006..., and
the other starts with 0x210000960000A006) then the attack is no longer
common prefix collision.
If I remember right, I think that common-prefix-collions worked on
blocks, so it would require full hash-blocks for prefix, but that is
of course easy to take, as we can pad C1 and C2 with zeros or
something until next block size.
I.e. it is not as easy to find C1 and C2 so that hash(P1 || C1) ==
hash(P2 || C2) where P1 and P2 are different.
> >> So the responder will see two unknown status notifications (Nx and Ny)
> >> and will just ignore them. Nothing suspicious.
> >
> > If the attacker changes the m1' to contain some other notification in
> > the beginning that cookie notification he needs to find different type
> > of collison where the prefix is no longer constant, i.e., he needs to
> > modify that.
>
> He need to do that anyway. Note, that the ck and ck' cookie
> length in the original attack must be correct and different
> (ck = C1 | SAi' | g^xi' |NONCEi, while ck' = C2).
Hmm... yes, I think that also makes the attack impossible, as the
length needs to be modified, thus it is no longer common prefix
attack.
> The other option for the attacker is to make the length of ck and
> ck' equal, but in this case the length of m and m' will be different
> and he must find a collision so that the length field in HDR and
> HDR' be correct (m' will be longer than m). The authors write about
> this on p.13:
>
> We also observe that the two prefixes are very similar:
> we only need the length of the cookie to be different.
>
> Following the format of IKE message, the length field
>
> is on bytes 22 and 23 of the hashed transcript, and
>
> all previous bytes must have a fixed value. Hence, we
>
> can _almost_ use a common-prefix collision attack, if the
>
> collision algorithm introduces a difference in bytes 22-
>
> 23, and no difference in preceding bytes.
>
You should have read the rest of that paragraph:
For MD5, the most efficient collision attacks do not have a
compatible message difference, but it seems possible to build
a dedicated attack with complexity below 2^39. However, for
SHA-1, all known collision attacks use differences in every
message words, and are thus unsuitable.
I.e. they say that this attack is impossible with SHA-1 too for now,
as they cannot use the 2^77 attack for SHA-1, as it only works with
chosen-prefix collisions where this requires almost-common-prefix
collision attack, and that does not work for SHA. To be able to attack
SHA-1 they need to find new ways to make almost chosen-prefix attacks
against SHA1.
[1] https://www.mitls.org/downloads/transcript-collisions.pdf
> So it is not a pure collision attack. In the modified attack the
> additional requirement is that not only length of the notification
> be different, but also the type of notification in C2 changes from
> COOKIE in C1 to any unused status notification. It makes finding a
> collision harder, but I think not too much.
For MD5 they say that it might be possible, for SHA-1 they say all
known collision attacks are unsuitable...
I would consider that makeing it much harder in general..
> >> So the only real defense against this attack is an unpredictability
> >> of SPIi.
> >
> > And checking the small subgroups in Diffie-Hellman, i.e., not using
> > groups 22-24.
>
> Sure.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
