On 4/23/2010 12:12 PM, Nicolas Williams wrote:
>
> Irrelevant: if the random octets being sent don't add entropy (because
> they are sent in cleartext) then this extension is completely orthogonal
> to PRNG failures.
Even though they are sent in-the-clear, the random data do serve the
same useful purpose as the existing [cs]_random data.
(Mathemeticians and professional cryptographers should probably avert
their eyes from the fast-and-loose reasoning which follows.)
Because they are unpredictable they make offline precomputation harder.
I think of it as adding entropy into offline computation, without adding
any to the online computation.
I would think that the current 224-256 bits is enough to thwart offline
attacks. The attacker would need something proportional to 2**224
storage to store the results of his precomputation, no?
Assume attacker can knock off 2**42 using rainbow table techniques (he
has a 1024 unit cluster of CPUs which can each compute one result online
every clock at 4GHz). So he needs to store something like 2**182 results
from his precomputation. Assuming 1 bit per result, probably you'd need
more. Raw HDDs are the cheapest form of mass storage today at $75/TB
(10**12 bytes?). Such a system would cost
$ 5746858278247083218843801351813700000000000.00
today. Of course those costs are likely to decline over time.
Again, this is the cost you impose on the attacker today by simply
ensuring you use the current protocol as intended.
> I do believe it's mostly harmless; I am concerned that 2^16 max octets
> seems like a bit much, possibly a source of DoS attacks. I believe it's
> also useless. As such I'm not opposed to it as an Experimental or even
> Informational RFC.
There is a danger with this proposal. In no way do I mean to suggest
that Paul has any unstated motivations here.
One aspect of saying that a data area is random is saying that the RFCs
can impose no restrictions on it. Allowing arbitrary unstructured
"random" data in the protocol opens the door for private extensions to
be added by various parties.
For example, it appears that 4 of the 32 bytes originally specified for
random data got repurposed for GMT leaving "this is GMT but the clock is
not required to be right" in the spec.
Once a few more of these accumulate in the protocol without central
coordination we end up with incompatibilities that the IETF process can
no longer prevent.
- Marsh
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf