Aside: this message was pretty garbled, and in richtext which my Outlook won't fix sensibly. I've tried to manually reformat what I can, but it would be easier if you posted plaintext.
> From: owner-openssl-us...@openssl.org On Behalf Of laurent.boll...@laposte.net > Sent: Tuesday, October 08, 2013 04:51 > [I wrote] > >RSA key size only affects handshake, and should be costly client side only > >if > >using client-auth; are you? > No; as client and server code is under my responsability, I chosed to also > asked for client-auth. > Still, I don't see how this could be the reason for my slowdown given the > overall data transmission length; > I will anyways give a try with a smaller key but I'm pretty sure that it will > have no influence. Do you mean "no" or "yes"? If you do use client-auth and RSA, then the handshake is slower (costlier). But my ">only< affects handshake" was agreeing that your problem probably *isn't* handshake. > >Data handling speed will normally be affected by encryption *and* MAC > >(usually >HMAC). > True, in my case, SHA is negociated; don't really know why HMAC is not > selected BTW, any idea ? All the ciphersuite names that use a hash (MD5, SHA, SHA256, SHA384) actually mean HMAC using the identified hash -- except 'SHA' really means SHA1; at the time those suites were defined and named, SHA-0 had been withdrawn and SHA-1 was the only SHA in use. The only TLS ciphersuites that don't use HMAC with some hash for integrity are the new TLSv1.2 ones that use GCM (see below). In case you aren't clear, HMAC is not one algorithm; it is a construction that uses a hash algorithm to construct a MAC algorithm. See Wikipedia and the RFC. SSL/TLS uses HMAC using different hashes, but until TLSv1.2 always the same HMAC construction, so it's only the hash that was named. (Somewhat similarly, the SSL 3 and TLS 1 and 1.1 protocols used one KDF for all key exchanges. Only in 1.2 do we explicitly identify the KDF to allow for a choice, and unless I've missed something recently no one has actually made another choice yet.) > >You could certainly try different data (symmetric) cipher, such as 3DES or > >RC4. > They are less secure than AES256 (that I'm using), but I guess I will have to > make a compromise so yes I believe that's the most obvious hint. Not really at least for 3DES. Nobody is going to bruteforce any >=112 bit cipher in my lifetime or yours. Not even NSA, everybody's bete du jour (if not de l'annee, or whatever the correct spelling is). RC4 is the most endangered technically; it does have distinguishers (which don't matter for SSL/TLS which usually exposes the algorithm choice already, and in any case has relatively few choices available) and there has been progress against it when used for massively repeated data which your described application of file transfer wouldn't have. If the adversary can break the key-exchange, or actively the authentication, or the RNG, those are just as effective against AES256 as against old single DES. > >I don’t know for Atom and ARM [but AES is generally fast] > Ok; what about engines, is there anyone for SPEAr320 (the ARM-based SoC I > will use along with Atom) ? > It has its own cryptographic accelerator that supports AES but I hardly > understand how I can use it; I > only get that engines should be the way, but then I probably need a Linux > kernel driver also right ? I don't know anything about that specific hardware, maybe someone else does. In general, if it's just an accelerator and architecture specific, like AES-NI on Intel, it may be enough to do assembler that is conditionally invoked when available and maybe enabled. Otherwise yes the 'engine' architecture in OpenSSL is the way to use hardware or encapsulated crypto primitives. > >If you have 1.0.1 at both ends, or otherwise have TLSv1.2 at both ends, you > >could try the GCM ciphersuites, >which combine encryption with MAC into one > >operation. > By 'MAC' you mean hashing operation right ? I will see if I can do this also. MAC is any kind of integrity check. Sometimes it can be just a protected hash, but not in SSL/TLS. HMAC is one kind of MAC, and the only one used in SSL/TLS until recently. GCM is a relatively new cipher mode that provides both encryption and MAC in one operation, generically called AEAD Authenticated Encryption with Additional Data. (Some other AEAD modes have been created, but not adopted for TLS.) Real performance may vary quite a bit by platform, but generally since GCM needs to do more work than just encryption alone, but somewhat less than encryption plus separate HMAC, it might be faster. OTOH if you have special hardware, GCM is new enough it may well not be in the hardware. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
