Re: TLS Overhead

2011-11-13 Thread Curt Sampson
On 2011-11-14 03:51 +0100 (Mon), jb-open...@wisemo.com wrote: > Running outside TLS context will also allow you to manage > key selection independently of socket level connection setup [etc. etc.] Yes, I've actually considered rolling my own cryptosystem for this stuff. For example, in some situa

Re: TLS Overhead

2011-11-13 Thread jb-openssl
For authenticated encryption speed on a typical general purpose processor (such as Atom), I would suggest AES-128 in GCM (Galois Counter Mode), this does one 12-round AES per 16 bytes, plus one extra per message, with no additional hashing algorithm use. I don't know if that mode is in TLS, or yo

Re: TLS Overhead

2011-11-13 Thread Curt Sampson
I'm dealing with some of the exact same issues; I am trying to satisfy a requirement that a rather lightweight host (an embedded system with an Atom processor) handle conversations with about 5,000 other hosts with strict latency requirements. I'm currently attempting this as peer-to-peer TLS commu

TLS Overhead

2011-11-13 Thread Mr.Rout
Dear All, Actually in large TLS client deployment network what are the Silence points we need to take into consideration to have a healthy handshakes with data traffic without any issues? i.e. to avoid TLS server overload If my TLS client does not support Session Resumption(means every time it