On Tue, Sep 17, 2013, at 07:13 AM, Norbert Bollow wrote: > Mark Handley <[email protected]> wrote: > > > The key reason for an approach at this layer in the stack is that it > > gets you the most bang for the buck. By leveraging the TCP handshake, > > you can get sessions encypted very easily with minimal infrastructure > > deployment, and only a single change to the stack. > > I've tried to find (in the draft or in the paper) information on the > server's entropy consumption, and the practical consequences. > > Can entropy generation become performance-limiting on servers that > receive a lot of connection requests? > > What kind of source of randomness did you use in the experiments?
That is a good question. I don't know what Andrea's implementation currently does. A few thoughts (but it would be better to ask one of the security people on the draft rather than me): A busy server will be handling a lot of packets per second, and the precise arrival times (as measured by CPU cycle counter) of those packets is not predictable, so the more traffic a server receives, the more entropy it has from this source. This helps less if you've got an eavesdropper very close to the server, but precise arrival times will still have some unobservable entropy. We could require the client supplies another random (encrypted) nonce right after the key exchange. This would be sufficient to top up the entropy pool in the presence of a passive eavesdropper, assuming entropy generation is easier at the client. An active attacker could try to deplete this entropy source by making a lot of connections and sending known values of this nonce, but they'd have to drown out all the legitimate clients, which would be difficult on a busy server, and would likely reveal the presence of the attack. And they'd need to combine this with eavesdropping very close to the server, or all they'd do is add randomness to the pool from their packet arrival times. Regards, Mark _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
