> Well, I think it is quite a simple trade-off. Increasing Sec increases > computational effort on both sides by equal amount. Increasing the length of > the hash increases computational effort only on the attacker side. As a > result, the hash bits are relatively valuable.
Jari, the effect of sec is different on both sides. The effort is not increased "by equal amount" but rather "in the same proportion." Suppose that an attacker could crack the 59 bit hash in a day with sec=0. Adding sec = 1 means that the attacker will have to try 65536 times as many keys. The time to crack becomes 65536 hours, i.e. about 7 years. The defender will have to try 65536 instead of one to get the right sec, taking only a fraction of a second. > 1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits of hash > length after accommodating for u and g bits as well. The good with this is > that it leaves maximum size for hash. The bad is that it is less flexible for > adding many new hash algorithms. I kind of like the status quo. > 2) The proposed new approach: Eat a total of six bits, for Sec and the hash > algorithm identifier. 56 bits remain. The good is that this gives more > flexibility to allocate hash algorithms, including the ability to > independently choose Sec and the algorithm. The bad is that the hash size is > decreased. Decreased a lot. On the other hand, if we do gain the flexibility to define new algorithms, then we can define a mandatory-to-implement algorithm that incorporates the equivalent of the "sec" strengthening. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
