On Sep 22, 2013, at 8:09 PM, Phillip Hallam-Baker <[email protected]> wrote:
> I was thinking about this and it occurred to me that it is fairly easy to get
> a public SSL server to provide a client with a session key - just ask to
> start a session.
>
> Which suggests that maybe the backdoor [for an NSA-spiked random number
> generator] is of the form that ... you get a lot of nonces [maybe just one]
> from the random number generator ... and that allows the [next one to be
> predicted more easily or even the] seed to be unearthed. One simple way [to
> stop this] would be to encrypt the nonces from the RNG under a secret key
> generated in some other fashion.
>
> nonce = E (R, k)
>
> Or hashing the RNG output and XORing with it
>
> nonce = R XOR H(R)
You shifted from "random value" to "nonce". Given the severe effects on
security that using a "nonce" - a value that is simply never repeated in a
given cryptographic context; it may be predictable, even fixed - to a "random
value", one needs to be careful about the language. (There's another layer as
well, partly captured by "unpredictable value" but not really: Is it a value
that we must plan on the adversary learning at some point, even though he
couldn't predict it up front, or must it remain secret? The random values in
PFS are only effective in providing forward security if they remain secret
forever.)
Anyway, everything you are talking about here is *supposed* to be a random
value. Using E(R,k) is a slightly complicated way of using a standard PRNG:
The output of a block cipher in counter mode. Given (a) the security of the
encryption under standard assumptions; (b) the secrecy and randomness of k; the
result is a good PRNG. (In fact, this is pretty much exactly one of the
Indistinguishability assumptions. There are subtly different forms of those
around, but typically the randomness of input is irrelevant - these are
semantic security assumptions so knowing something about the input can't help
you.) Putting R in there can't hurt, and if the way you got R really is random
then even if k leaks or E turns out to be weak, you're still safe. However ...
where does k come from? To be able to use any of the properties of E, k itself
must be chosen at random. If you use the same generator as way use to find R,
it's not clear that this is much stronger than R itself. If
you have some assured way of getting a random k - why not use it for R itself?
(This might be worth it if you can generate a k you believe in but only at a
much lower rate than you can generate an R directly. Then you can "stretch" k
over a number of R values. But I'd really think long and hard about what
you're assuming about the various components.)
BTW, one thing you *must not* do is have k and the session key relate to each
other in any simple way.
For hash and XOR ... no standard property of any hash function tells you
anything about the properties of R XOR H(R). Granted, for the hash functions
we generally use, it probably has about the same properties; but it won't have
any more than that. (If you look at the structure of classic iterated hashes,
the last thing H did was compute S = S + R(S), where S was the internal state
and R was the round function. Since R is usually invertible, this is the only
step that actually makes the whole thing non-invertible. Your more-or-less
repetition of the same operation probably neither helps more hinders.)
At least if we assume the standard properties, it's hard to get R from H(R) -
but an attacker in a position to try a large but (to him) tractable number of
guesses for R can readily check them all. Using R XOR H(R) makes it no harder
for him to try that brute force search. I much prefer the encryption approach.
-- Jerry
_______________________________________________
The cryptography mailing list
[email protected]
http://www.metzdowd.com/mailman/listinfo/cryptography
