Hi, Steve, Steven M. Bellovin wrote: > On Wed, 14 Nov 2007 15:39:50 -0500 > Stephen Kent <kent@xxxxxxx> wrote: > >> Joe, >> >> I disagree with your suggestion "The software performance of security >> protocols has been the more substantial issue, and is likely to >> continue to be for the forseeable future." >> >> I suspect that most desktop users do not need hardware crypto for >> performance. Irarely if ever drive my GiGE interface at its line >> rate. With fast processors, especially multi-core processors, we have >> enough cycles to do symmetric crypto at data rates consistent with >> most application demands for individual users. Public key operations >> for key management are usually low duty cycle, so they too can be >> accommodated. >> > Thanks -- I was going to say something similar. I regularly back up my > laptop's disk over a software-encrypted GigE link. The dump file > occupies about 35G of disk space; it takes about 70 minutes. Exclusive > of protocol overhead, that comes to ~71M bps; given IP, TCP, and ssh, > I'd guess it's more like 75-80M bps. I also know that I can run ttcp > between that pair of machines at about 500M bps. Am I really suffering > from a 7:1 performance hit from the crypto? Nope. By essentially shutting your machine down for over an hour. > I can't do controlled experiments right now, since the laptop and > server in question are currently about 350 km apart at the moment. > > Dumping the disk to /dev/null took about 30 minutes. The maximum hit > I'm taking from the crypto, then, is about 2.3:1. The numbers I get are 3:1 for some protocols, worse for others, but the CPU hit is also substantial, vs. just taking time but not CPU to do the transfer. > Using the > performance numbers from 'openssl speed' for 1024-byte blocks for > AES-128 and SHA-1, the crypto is 23 minutes of CPU time. (This is a > 1.8Ghz, single-core laptop.) The other 17 minutes probably go to data > copies -- I'm doing 'dump | ssh cat >file' -- so a kernel implementation > (say, IPsec) would be better -- and overhead, plus (of course) > calculation error). The point, though, is that the crypto isn't the > limiting factor. It's not stopping me from doing anything. It's not > even the biggest bottleneck in my application. And *that's* what's > important -- not *network* speed, but *application* speed. Your application shut your machine down for over an hour - just dumping alone wouldn't). That's substantial - sure, not for you, but you run crypto. For those who don't, this is a large part of why (the other part is key management, but that doesn't come into play for things like backups since it's a single key and two known parties). --- The point is that you have a GigE interface you don't use. Why? It's cheap, and when you do use it - to dump at work - it's a lot faster than 100Mbps. Crypto puts a huge dent into that capability the way it's done right now, and nobody is selling me 1Gbps crypto chips for a price that makes it cost-effective to put it into a laptop. And I don't exactly want to burn 100% of my CPU capacity to saturate my 802.11 link, let alone such a small fraction of my GigE. Joe
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf