> From: owner-openssl-us...@openssl.org On Behalf Of greenelephant > Sent: Sunday, 29 May, 2011 14:31
> I have a computer with Ubuntu OS and an Apache HTTP server. > I am trying to > create a SSL certificate using RSA public and private keys. > > However it has come to my attention that at this present > moment there are > sophisticated methods such as man in middle attack, Side > channel attack, and > Branch prediction analysis attacks. > > http://en.wikipedia.org/wiki/Man-in-the-middle_attack > http://en.wikipedia.org/wiki/Side_channel_attack > http://en.wikipedia.org/wiki/Branch_prediction > These are different. MITM is a class of protocol attack essentially independent of what crypto, and crypto implementation, you use. Branch prediction, or rather timing and possibly power deltas due to branch prediction, is one kind of side-channel attack. > This is of a concern to me especially the side channel attack > as it can > analyse one's CPU variants to predict one's secret key. I am > aware of the > ongoing battle between hackers/attackers and the institutions > which provide > and create integrity modules/programs such as RSA/SSL etc. I > also know that > using high numbered bits (1024 bit encryption) and above > lessens the chance 1024 is no longer "high" for RSA, it is roughly the minimum. Up to about 800 bits is now breakable by factoring, and e.g. NIST SP800-57 prohibits (<=)1024 for US government (civilian) general use after 2010 (although part3 makes an exception for DNSSEC due to problems in getting large-enough UDP widespread). 1536 or 2048 is recommended today, and more isn't crazy. OpenSSL supports "blinding" of RSA privatekey operations, which should defeat any timing or power side-channel attack. Assuming Apache uses OpenSSL (and not an absurdly old version) it will get this features unless it actively disables it, which seems unlikely but I can't absolutely rule out. http://en.wikipedia.org/wiki/Blinding_%28cryptography%29 Different numbers apply to other algorithms but you only asked about RSA. > of an attacker breaching your system using this method. This > may be obsolete > now with the introduction of attacks listed above such as Side-Channel > Attack but RSA keys can be renewed and regenerated > > However what also has come to my attention is methods created > and introduced > by RSA to combat these threats such as 'padding' used by sub programs > created by RSA such as OAEP and PKCS. > OAEP was created by Bellare and Rogaway, though the exact scheme is *standardized* in PKCS#1v2 (originally) from RSA (actually RSA Labs) along with the PKCS#1v1.5 scheme(s) created by RSA (which was not designed to 'combat' implementation attacks). Note that there are several other PKCS's (documents) on different topics, not related to RSA padding at all. In particular, PKCS#5 defines (among other things) a padding scheme commonly used for block-mode symmetric encryption. > So here is my question. I have an APACHE web server which I > would like to > host a HTTPS/SSL page. I would like to be able through > OPENSSL to create a > certificate and key(s) which use either PKCS or OAEP methods > to 'pad' the > encrypted connections between my computer and my clients. How > would I be > able to go about this? > If you want to use SSL (or TLS, the difference doesn't matter here) (including HTTPS), you can use only the ciphersuites and options/formats/etc. defined by SSL/TLS. SSL/TLS encrypts session data with a symmetric cipher (and authenticates it with an HMAC) using PKCS#5 padding. The session keys and IVs (if applicable) for the data cipher and HMAC are derived from a key exchange in the initial (or subsequent) handshake. If the server has only an RSA key and cert (and the server and client don't both support and agree on an anonymous ciphersuite, which is possible but rarely done) then the key exchange will be kRSA as defined by SSL/TLS, which transfers the premaster secret encrypted by RSA using PKCS#1v1.5 padding. If you are satisfied with SSL/TLS (and most of the world is) you can use OpenSSL to generate an RSA keypair, and to either: 1. generate a self-signed cert (for that key), which most clients (e.g. web browsers) won't trust by default; 2. create your own CA (Certificate Authority) and issue a cert (for the server key) under that CA, which again most clients won't trust by default; or 3. create a certificate request (aka CSR) which you can use to get a cert (for the key) from a public CA for example Verisign, which most clients WILL trust by default. Depending on what options you use, the generate-RSA step can usually be combined with the selfsign or request step. OpenSSL key/cert files are usable by Apache last I looked. man genrsa man req man x509 man ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
