On Fri, Dec 16, 2016 at 03:17:39PM -0500, George Spelvin wrote: > > That's a nice analysis. Might one conclude from that that hsiphash is > > not useful for our purposes? Or does it still remain useful for > > network facing code? > > I think for attacks where the threat is a DoS, it's usable. The point > is you only have to raise the cost to equal that of a packet flood. > (Just like in electronic warfare, the best you can possibly do is force > the enemy to use broadband jamming.) > > Hash collision attacks just aren't that powerful. The original PoC > was against an application that implemented a hard limit on hash chain > length as a DoS defense, which the attack then exploited to turn it into > a hard DoS. What should we do with get_random_int() and get_random_long()? In some cases it's being used in performance sensitive areas, and where anti-DoS protection might be enough. In others, maybe not so much. If we rekeyed the secret used by get_random_int() and get_random_long() frequently (say, every minute or every 5 minutes), would that be sufficient for current and future users of these interfaces? - Ted P.S. I'll note that my performance figures when testing changes to get_random_int() were done on a 32-bit x86; Jason, I'm guessing your figures were using a 64-bit x86 system?. I haven't tried 32-bit ARM or smaller CPU's (e.g., mips, et. al.) that might be more likely to be used on IoT devices, but I'm worried about those too, of course. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
