Author Archives: Ralf

About Ralf

Currently Postdoctoral researcher in the LACS group at the University of Luxembourg.

Meaningful results against Trivium with reduced key setup

Michael Vielhaber presents an interesting result against a reduced version of the eSTREAM submitted cipher Trivium in a paper on the IACR ePrint archive. By reducing the key setup from 4 full rounds (1152 clock cycles) to two cycles (576 cycles) he is able to mount a chosen IV algebraic attack using a total of 2^6 chosen IV resyncs. This reduced version is called ONE.FIVIUM by him. The impact of the attack against ONE.FIVIUM that 47 of the 80 key bits are claimed to be determined with probability 1 by this attack. The write up needs polishing but most of the results indeed mostly check out. Unfortunately the method by which he arrived at these results is (in my opinion, at least) only superficially described. I strongly suspect this paper is intended to mark a claim. Further results against a clock setup with more cycles are to be expected. Trivium is living dangerously.If you want to check out Michael Vielhaber’s results yourself, I have written Python code for just that. My colleague Andrey Pyshkin initially confirmed the 6 out of the first 7 approximations listed in the table, aidatest.py checks all of them. Below is the output of 256 runs.

approx. for key bits [1] was correct 256 out of 256 times
approx. for key bits [2, 65] was correct 256 out of 256 times
approx. for key bits [3, 66] was correct 0 out of 256 times
approx. for key bits [4] was correct 256 out of 256 times
approx. for key bits [5] was correct 256 out of 256 times
approx. for key bits [6] was correct 256 out of 256 times
approx. for key bits [8] was correct 256 out of 256 times
approx. for key bits [9] was correct 256 out of 256 times
approx. for key bits [11] was correct 256 out of 256 times
approx. for key bits [14] was correct 256 out of 256 times
approx. for key bits [16] was correct 256 out of 256 times
approx. for key bits [17] was correct 256 out of 256 times
approx. for key bits [19] was correct 256 out of 256 times
approx. for key bits [25] was correct 256 out of 256 times
approx. for key bits [26] was correct 256 out of 256 times
approx. for key bits [27] was correct 256 out of 256 times
approx. for key bits [36] was correct 256 out of 256 times
approx. for key bits [38] was correct 256 out of 256 times
approx. for key bits [39] was correct 256 out of 256 times
approx. for key bits [55] was correct 256 out of 256 times
approx. for key bits [56] was correct 256 out of 256 times
approx. for key bits [57, 63] was correct 256 out of 256 times
approx. for key bits [59, 65] was correct 256 out of 256 times
approx. for key bits [60, 66] was correct 256 out of 256 times
approx. for key bits [61] was correct 256 out of 256 times
approx. for key bits [62] was correct 256 out of 256 times
approx. for key bits [63] was correct 256 out of 256 times
approx. for key bits [64] was correct 256 out of 256 times
approx. for key bits [65] was correct 256 out of 256 times
approx. for key bits [66] was correct 256 out of 256 times
approx. for key bits [67] was correct 0 out of 256 times
approx. for key bits [68] was correct 0 out of 256 times
approx. for key bits [15] was correct 256 out of 256 times
approx. for key bits [18] was correct 256 out of 256 times
approx. for key bits [20] was correct 256 out of 256 times
approx. for key bits [23] was correct 256 out of 256 times
approx. for key bits [30] was correct 256 out of 256 times
approx. for key bits [32] was correct 256 out of 256 times
approx. for key bits [33] was correct 256 out of 256 times
approx. for key bits [35] was correct 256 out of 256 times
approx. for key bits [58] was correct 166 out of 256 times
approx. for key bits [21] was correct 256 out of 256 times
approx. for key bits [22] was correct 256 out of 256 times
approx. for key bits [10] was correct 115 out of 256 times
approx. for key bits [12] was correct 141 out of 256 times
approx. for key bits [58] was correct 256 out of 256 times
approx. for key bits [69] was correct 256 out of 256 times

Shortcomings of the Windows PRNG

Leo Dorrendorf, Zvi Gutterman and Benny Pinkas presented interesting research at the ACM CCS 2007 conference lately. An updated version of their paper on attacks against the Windows 2000 PRNG has now appeared on the IACR ePrint archive. Since they only had access to the PRNG DLL binaries, they had to reverse-engineer these first to get started. Their devastating result: The Windows PRNG offers neither forward and backward security, allowing an attacker learning the internal state of the generator to predict 128kBytes of past and future output. The PRNG runs in user-space and each process uses its own instance. If I read the paper correctly, the same PRNG was used for all versions of Windows between Windows 95 up to Windows XP [caveat: they analysed a Windows 2000 build and haven’t practically checked their results against other OS versions yet]. Practically speaking, this means that a successful remote exploit against your browser on these platforms is also in the position to reveal 600-1200 of your past SSL session keys by sending out the internal PRNG state. It remains to be seen whether this carries over to Vista – my rather uneducated guess here is that it does not, but that remains to be seen.

Zvi Gutterman has co-authored a number of interesting papers on PRNGs, namely analyses of the Linux PRNG [ePrint version] and of the Java session ID generation.

[Disclaimer: I met Zvi at the first ECRYPT summer school in Samos back in 2005. Way to go, man, way to go!]

Update [2007-11-22]: Apparently Microsoft has admitted that the same flaw still is present in Windows XP. And of course: No, this is no security vulnerability, according to Microsoft, since the attacker must have had access in the first place. Still they claim that Windows Vista does not exhibit the same mistake. This however has not yet been independently verified.