>From: [email protected] On Behalf Of Stefan Schindler >Sent: Sunday, 03 February, 2013 17:00
>I'm setting up 3 servers for mobile clients. Because the data is >allways very small, i think the curve sect571r1 fit's best. If you mean SSL/TLS (connections to) server(s), the size of the data is irrelevant. The ECC cert/key and algorithms are used only in the handshake. Data encryption uses a symmetric algorithm. For other usage, see below. >I didn't find much helpful documentation on the net, so it would be >very cool if you could provide some. If you mean EC crypto in general, I don't know anything very good. It's arcane and nearly magic -- but it works. If you mean EC usage in SSL/TLS, RFC 4492 (several places, canonically rfc-editor.org). If you mean EC support in OpenSSL: man pages for the current version are under www.openssl.org/docs and the ones for any version you have installed on Unix should be available there. I have usually found what I need for commands/options, and EVP. man page coverage of EC low-level primitives is even spottier than the rest of OpenSSL, but the (newish) ec*.h headers do have much better comments than old ones. Aside from the specific routines and utilities or options (including pkeygen etc. in 1.0.0+) to handle EC parameters and keys, it's mostly the same as non-EC. ECDSA primitives, and suites, work much like DSA. ECDH primitives, and ECDH ECDHE AECDH suites, work much like DH ones. Certs containing EC keys work much like DSA (or DH, but certifying DH is even rarer than DSA). Two sometimes-gotchas: in libssl before 1.0.0 the EC suites are implemented but disabled by default; you must specify a cipherstring including "ECCdraft" to use them. And in all versions libssl server will (silently) suppress an EC cert and/or ECDH temp key that uses a curve excluded from a client's supported_curves extension. (TLS1.2 can also exclude based on sigalg for both EC and non-EC, but EC sigalgs might be a little more likely to be unsupported.) >I created my first keys with these commands: >openssl ecparam -out defaultServer-key.pem -name sect571r1 -genkey >openssl req -newkey ec:defaultServer-key.pem -x509 -nodes -days 365 >-keyout defaultServer-pkey.pem -out defaultServer-cert.pem That creates two different keypairs, with a selfsigned cert for (the public half of) one of them. Is that what you want? >I will try to setup a CA, so the clients can verify the 3 servers. >Documentation would be appreciated too. If you use the selfsigned cert (from req -x509) you don't need a CA. You do need to make the clients trust the selfsigned cert, which sometimes means *calling* it a CA cert. But it's not really a CA unless you use it to issue child certs, or at least plan to. If you do want a private CA, don't bother creating selfsigned EE cert(s). You do need to make the clients trust your CA cert, but if you have multiple servers (with different keys/certs) trusting one CA may be easier than trusting N servers or server versions. If you're doing something other than SSL/TLS, you may or may not need a cert, or a cert with particular features, depending. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
