Re: Kaminsky finds DNS exploit
Udhay Shankar N <[EMAIL PROTECTED]> writes: > Kaminsky Breaks DNS [...] > Unlike other researchers who give up the gory details, Kaminsky took a > wiser path by smiling and nodding. He’ll give up the goods at Black > Hat in August. That should give folks enough time to patch their > systems. The details of the exploit (or at least an exploit just as bad) have now leaked. I'm not surprised -- any secret known by more than one person doesn't remain secret for long, and what one person can figure out can be figured out by others. Still, it was good that we had a couple extra weeks to patch. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
how to check if your ISP's DNS servers are safe
Niels Provos has a web page up with some javascript that automatically checks if your DNS caching server has been properly patched or not. http://www.provos.org/index.php?/pages/dnstest.html It is worth telling people to try. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Looking through a modulo operation
On Mon, Jul 21, 2008 at 8:33 AM, Matt Ball <[EMAIL PROTECTED]> wrote:
>
>"If someone uses the __random32 function as defined in the 2.6.26
> Linux kernel, and leaks to you the result of taking successive outputs
> modulo 28233 (= 9 * 3137), can you determine the probable 96-bit
> internal state with fewer than 1000 outputs and with modest processing
> power (e.g., a laptop computer running less than a day)?"
>
Another attacking avenue is the 32-bit initial seed. If the
implementation re-seeds frequently, or leaks to you the first outputs
after initialization, then you only have to brute-force the 32-bit
seed space, times the number of samples since reseeding.
Here is the function that performs the initial seeding, based on a 32-bit seed:
static void __set_random32(struct rnd_state *state, unsigned long s)
{
if (s == 0)
s = 1; /* default seed is 1 */
#define LCG(n) (69069 * n)
state->s1 = LCG(s);
state->s2 = LCG(state->s1);
state->s3 = LCG(state->s2);
/* "warm it up" */
__random32(state);
__random32(state);
__random32(state);
__random32(state);
__random32(state);
__random32(state);
}
For those who want to get cleaver, I suspect there is an optimization
for running __random32 six times.
--
Thanks!
Matt Ball, IEEE P1619.x SISWG Chair
M.V. Ball Technical Consulting, Inc.
Phone: 303-469-2469, Cell: 303-717-2717
http://www.mvballtech.com
http://www.linkedin.com/in/matthewvball
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Looking through a modulo operation
Matt Ball writes:
>Another attacking avenue is the 32-bit initial seed. If the
>implementation re-seeds frequently, or leaks to you the first outputs
>after initialization, then you only have to brute-force the 32-bit
>seed space, times the number of samples since reseeding.
Well, that's good and broken then, isn't it? No ifs about it.
It doesn't matter whether the implementation re-seeds frequently or
rarely. It doesn't matter whether it leaks to you the first outputs
after initialization or only later ones. If it's using a 32-bit seed,
this sucker is just plain broken, period.
The attack is trivial -- it's just exhaustive keysearch.
Attack: Given ~ 3 known outputs from the RNG, try all possible 32-bit
seeds. You'll be able to recognize when your guess at the seed is correct
because the output from your guessed seed will match the observed output.
This assumes you know the offsets of your outputs (how many times the
RNG has been cranked before producing your known outputs), but even
if you only have partial information about that you can still make a
variant of this attack work. The exhaustive search attack has to try
only 2^32 possibilities, so I'm guessing this attack should only take
minutes (at worst, hours) on a fast computer.
My earlier email about fancy attacks on this scheme is irrelevant.
There's no need to bother with fancy attacks, when the PRNG only uses
a 32-bit seed -- that's just blatantly insecure. This is a textbook
error, one of the oldest mistakes in the book. (For example, look
here: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html)
Using this PRNG for security-critical purposes would not be wise.
I'll include your code snippet for seeding the PRNG below. Note: I'm
assuming, per your comments, that "unsigned long" is a 32-bit type.
>Here is the function that performs the initial seeding, based on a 32-bit seed:
>
>static void __set_random32(struct rnd_state *state, unsigned long s)
>{
>if (s == 0)
>s = 1; /* default seed is 1 */
>#define LCG(n) (69069 * n)
>state->s1 = LCG(s);
>state->s2 = LCG(state->s1);
>state->s3 = LCG(state->s2);
>/* "warm it up" */
>__random32(state);
>__random32(state);
>__random32(state);
>__random32(state);
>__random32(state);
>__random32(state);
>}
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
