> From: owner-openssl-us...@openssl.org On Behalf Of greenelephant > Sent: Sunday, 12 June, 2011 11:02
> Im not sure how I would be able to encode/decode files before > transmission > Dave. Would it be possible to encode them using OAEP before > transmission? > OAEP is not an encryption; it is a padding method that can be used with some encryptions, particularly RSA. To encrypt before sending and decrypt after receipt has the (possible) advantages that storage (in addition to transfer) is protected, and the crypto cost can be separated from transfer -- but nowadays crypto cost is an issue only on *extremely* limited devices. The disadvantage is that you need separate software, on both ends, that is either the same or is compatible. Using transfer security, like SSL/TLS or SSH/SFTP etc., means you need transfer software that is compatible (and if it isn't you can't even connect) but nothing further. In practice you don't encrypt "files" with publickey cryptography like RSA. In principle it can be done, but you won't find software on the recipient(s) (for you, clients?) that is compatible with that unless you write it yourself, which as a "novice" would be hard. Because the PKC primitives are relatively costly, what people actually do is called "hybrid" cryptography. For the traditional and simple case of RSA: * the originator encrypts "bulk" data using a symmetric cipher (like AES, triple-DES or DES, RC4, CAST, IDEA, Blowfish, etc.) and a randomly chosen key, and encrypts that random key (which is typically 16-32 bytes) using RSA and the recipient's public key, and sends (or stores for sending) a structure containing both of these plus usually some additional info and overhead * the recipient uses RSA and its *private* key to decrypt the random per-file key, and uses that with the symmetric cipher to decrypt the data. Probably the most widespread standard for doing this started as PKCS#7 and evolved into CMS (Cryptographic Message Syntax) and its close derivative S/MIME; openssl supports these directly in the commandline utility. There are and have been lots of other, functionally similar, schemes, for which you need other software; PGP, and the GNU variant GNUPG, is the most widespread in this category. > I am an novice and Im not 2 sure how I can utilise your > advice you have > given me correctly. So below is my step by step process I > would personally > use to create a key and certificate file for use in apache2. > How could these > steps be modified to include encryption using more secure > padding (OAEP if For SSL/TLS you can use only the crypto methods SSL/TLS defines, and its RSA key exchange is PKCS1v1.5 not RSA-OAEP (PKCS1v2). However, I'm pretty sure OpenSSL server implements kRSA using all the other defenses against Bleichenbacher (no shortcut operations, no different response information) so there should be no practical weakness here. > possible)? I want to if possible encrypt the connection > without the hassle > of encrypting files then transmitting them. PS I am using > Linux/Ubuntu as my > operating system > Transfer (communication) security using SSL/TLS is certainly a good solution to your stated goals, and as far as I know the only one directly supported by Apache. <snip> > // Build Self CA key > 1. > sudo openssl genrsa -des3 -out ca.key 1024 > > // Build Self CA certificate . Note [x] is the duration of > days you wish > your CA certificate to last. > 2. > sudo openssl req -new -x509 -days [x] -key ca.key -out ca.crt > > // One Key file = ca.key | One certificate file = ca.crt > > * Enter Country Code > * Enter Region > * Enter City > * Enter Organisation Name > * Enter Section > * Enter Common Name + "CA" > * Enter Email Address > * Enter Passphrase > Correct. Although you can combine keygen into req -new if you want. And you might consider a greater keysize; RSA 1024 isn't broken yet and isn't very close, but many authorities feel it no longer has enough margin to be comfortable for long-term use. > // Build SSL Server key > 3. > sudo openssl genrsa -des3 -out server.key 1024 > > // Build SSL Server certificate. Note - IT IS IMPORTANT YOU > REMEMBER YOUR > PASSPHRASE CREATED IN STEPS 2 AND 4. Actually passphrases are created in 1 3 and used in 2 4 5. (And in Apache, if you give it the encrypted key.) > 4. > sudo openssl req -new -key server.key -out server.csr > > // One Key file = server.key | One certificate file = server.crt > > * Enter Country Code > * Enter Region > * Enter City > * Enter Organisation Name > * Enter Section > * Enter Common Name + "CA" > * Enter Email Address > * Enter Passphrase > > * Enter Organisation Name > I assume the duplicated "Organisation Name" is a typo. Probably wrong. The Distinguished Name of the server *must* be different from that of the CA. And using "CA" in the name of the server is confusing at best. Plus for *most* HTTPS clients (like web browsers) the Common Name field in the server (req and) cert must be the domain name of the server, otherwise they will throw ever more alarming warnings. So name the server with the server's name, and name the CA something involving "CA". > // > 5. > sudo openssl x509 -req -days [x] -in server.csr -CA ca.crt > -CAkey ca.key > -set_serial 01 -out server.crt > Lifetime for the server cert can be different (less) than for the CA cert. But in your environment there's probably no point. > // Enable SSL Module > 6. > sudo a2enmod ssl > I'm not sure what the configuration for Apache is (by default, or what you've already done). It *may* need some changes. You also need to distribute the CA cert (ca.crt) to each client and make it a 'trusted root'. The method for doing so varies depending on the client e.g. browser. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
