Computational efficiency is one of the criteria for selecting Rijndael as AES. Below is the output of openssl speed from my desktop:
The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des cbc 53346.83k 55115.71k 55865.17k 56023.04k 56027.82k des ede3 20305.48k 20581.74k 20687.45k 20645.55k 20679.34k aes-256 cbc 56244.68k 80301.78k 90277.29k 93125.63k 94674.94k aes-128-cbc 83307.89k 114343.85k 126573.48k 130061.99k 130512.21k If you are referring to the network transfer speed, then CPU time is probably not the bottleneck:) On Fri, Jun 26, 2009 at 10:08 PM, George <[email protected]> wrote: > > Hi Freepine, > > That did the trick, thanks! I was surprised I didn't see much of a > speed increase in the (non-cached) connection being established when I > dropped down from a 256-bit AES to a 40-bit export DES key. I guess > most of the time is gobbled up by the handshake itself. > > On Jun 20, 3:01 am, Freepine <[email protected]> wrote: > > Hi, SHA1PRNG indicates the preudo-random number generator is based on > > SHA-1(a message digest algorithm), it's not the encryption algorithm > used > > for communication. > > You can try SSLSocket.getSupportedCipherSuites() to retrieve the > information > > of supported cipher suites, and setEnabledCipherSuites to specify the > cipher > > suites enabled for use on this connection. > > > > On Fri, Jun 19, 2009 at 11:22 PM, george <[email protected]> wrote: > > > > > As far as I can see, the only encryption algorithm available for SSL > > > connections is the default SHA-1. (Which can be passed as > > > SecureRandom.getInstance("SHA1PRNG") into the SSLSocketFactory > > > constructor. Is there support for other algorithms such as DES, or > > > RC4? >
