On Wed, May 11, 2011 at 03:42:30PM -0400, Nick Mathewson wrote: > RIght. If we can get away with something faster than HMAC_SHA256 > here, I'd love to move to it. SHA3 is right around the corner, and > most of the candidates seem to allow better constructions for > "tweakability" than HMAC. > > Would this make a difference, actually? Let's see. Looking at the > numbers from my desktop and doing some back-of-the-envelope > calculations. > > I would expect the old handshake to take, total, about 3500 > microseconds. (This is counting both client and server crypto.) > > If we tried to do that with 2048-bit keys, it would take, total, about > 14700 microseconds. > > And I would expect the new handshake to take, total, something like > 830 microseconds. That's more than 4x faster than the old one, and > more than 17x faster than the old one using keys with equivalent > security. (Nice!) > > Of that 830 microseconds, I'd spend something like 3-5% doing SHA256 > hashes. So it might not be worthwhile spending too much time > optimizing the number of hashes here.
You're totally right. No sense stressing about how many hash blocks we're processing. Remember also that if you have non-black-box access to the exponentiation routine, the server can compute X^y and X^b simultaneously. That will make a bigger difference in time, but is not really relevant from a spec-level standpoint. - Ian _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
