Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

[Dean Anderson <[e-mail]>]

On Mon, 26 Apr 2010, Marsh Ray wrote:

> 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.

Except they aren't actaully random, they are pseudo-random.

> (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 if attacker could do what you describe below, he
could mount an attack on your pseudo-random number generator using the
(now) exposed output.  But I'm not really sure.

I am pretty confident that every crypto act that isn't founded in theory
and absolutely necessary, actually makes things worse.

The purpose of these bits are to ensure non-collision in practice. The
easiest, simplest, and least-information-leaking means of achieving that
is to use a counter.  More complication and pseudo-random bits doesn't
help achieve that purpose any more effectively, and leaks information
that might be used by the attacker, somehow, someday.  A counter cannot
be used by the attacker.  And if you think it could be, then pick the
initial counter value pseudo-randomly and count up from there (exposing
at most 1 set of bits per reboot)

> 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
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494