Hi there, On Friday 28 December 2001 12:49, Patrick Li wrote: > Hi, > > I have implemented the SSL client and server applications and I will be > using them to conduct SSL sessions. Since I have control on the client > and the server, I want to find a cipher which offers strong encryption > but does not require a lot of CPU cycles. I think using TLSv1 protocol > is the logical choice over SSL v3 or SSL v2 right? How about the > individual cipher? How > about > > EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 > DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 > > Any advice or pointer will be greatly appreciated.
Well I'm assuming you're not using any hardware acceleration - in which case you would want to be using EDH *only* in circumstances where "Perfect Forward Secrecy" is worth the cost of massive CPU overheads. If you conduct any benchmarks, you'll soon notice that the EDH cipher suites take a *much* bigger CPU hit during (re)negotiations than others. Try playing around with "ssltest" in the openssl self-test suite ... you should be able to get it to do handshakes with itself using whatever cipher suites you like - that'll give you some ideas about comparitive speeds. You didn't mention whether you'd be using server *and* client authentication or just server authentication. If you don't use client certs - the CPU overhead at the client end is going to be much lower than that at the server end anyhow, so your problem can be discussed simply in terms of the server. In which case, you could try using "swamp" (a shameful plug I might add, http://www.geoffthorpe.net/crypto/swamp/) to hit your server side and use the "-cipher" switch to see how its performance holds up given different cipher suites. A cipher suite involving RC4 will probably be lower overhead than one involving DES, though the scale of that difference depends on your traffic, the number of (re)negotiations per unit of traffic, your CPU, etc etc etc. You should also probably decide what size certificate/keys to use - if 512-bit RSA keys are sufficient, your (re)negotiation speed will be way faster than 1024-bit RSA keys - but less "secure". "secure" is quoted because we all know breaking your RSA key based on traffic snooping is likely to be the *last* actual target of any determined attack. Good luck, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
