RE: Using PCKS Padding in OpenSSL
Thanks Dave, Eric and jeffrey. I would truly be lost without your help! :confused: 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? 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 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 If this is not a feasible solution then I shall stand corrected. If so I would need help to know how to encrypt selected files. Again thanks in advance for any feedback I receive from you. ** // 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 // 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. 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 // 5. sudo openssl x509 -req -days [x] -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt // Enable SSL Module 6. sudo a2enmod ssl ** Eric S. Eberhard-2 wrote: I would point out in that last approach -- encrypting and sending un secure (which is a good idea in many cases) does have a few considerations. If the data is sensitive (like magnetic strip data from a credit card) this is completely NOT ALLOWED. PCI and PA-DSS won't allow it to hit the disk. If you do hit the disk and you care about security on either end, you also need a secure delete program. Simply deleting a file does not remove the data from the disk. It takes about 5 lines of C to make a secure delete which if anyone likes I can give them. Eric At 08:44 PM 6/6/2011, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of greenelephant Sent: Sunday, 05 June, 2011 05:20 Thanks for the reply Dave. I am grateful for your advice. I am a novice as you have probably gathered. If I am not wrong in my judgement you seem to have some expertise on cryptology. Some, not a whole lot. I have stated SSL in my first post that I would like help with as you know. But with your expertise is there a better solution to use except SSL in terms of security using openssl? SSL/TLS (preferably the newest version supported, today usually TLS 1.1 or maybe 1.2) is a good general solution for security of Internet endpoint communication (particularly, but not only, web traffic using HTTPS). OpenSSL is a good implementation of SSL/TLS, plus some related (crypto) functionality, but not the only one; any other conforming and well-tested implementation available to you should be fine. For examples, Java includes its own SSL/TLS implementation (for Java), and I understand dot-NET does (for C#, VB, etc.) There are other protocols that may be better in specific situations (e.g. SSH as below) or necessary (e.g. IPsec and DNSsec are done at a level below where SSL can work). Also is SSL an ideal security solution for secured FTP transmissions using the openssl module to enable me to subvert any efforts to sabotage or breach security perpetrated by intruders or hackers using the methods of attacks (side channeling for instance) previously mentioned? FTP over SSL (FTPS) is a secure means of file transfer, if supported by both your server(s) and your client(s), which in my experience is not very common. When it is supported, the server and client code determines what module is used; it might be OpenSSL or something else. Another good and in my experience more common method of securing file transfer is SFTP, part of the SSH
RE: Using PCKS Padding in OpenSSL
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
RE: Using PCKS Padding in OpenSSL
Actually the 2.0 specs don't allow disk storage at all for magstripe -- you can keep cardholder data until auth. Since 1.2 specs are not required until 1/1/12 and 2.0 another year ... I was pointing more to the future (and had our software certified for 2.0 as 1.2 is only good until 2013 and 2.0 is good till 2016 and I wanted to avoid another audit so soon). Not knowing the nature of the data and network setup makes it hard to answer definitively but if it is going to be lying around, encrypting it first is, as I said, a good idea in many cases. E At 08:36 PM 6/7/2011, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of Eric S. Eberhard Sent: Tuesday, 07 June, 2011 15:21 I would point out in that last approach -- encrypting and sending un secure (which is a good idea in many cases) does have a few considerations. If the data is sensitive (like magnetic strip data from a credit card) this is completely NOT ALLOWED. PCI and PA-DSS won't allow it to hit the disk. If you do hit the disk and you care about security on either end, you also need a secure delete snip To be exact, PCI DSS (and therefore PA-DSS) prohibits storing magstripe, CVV2 and PIN after authorization (even if encrypted). Authorization should always be real-time and thus there should be no good reason to store on disk during auth, but it isn't specifically prohibited. If you do store it, yes you will then need to wipe it. But this is not specific to my last approach. The OP's question seemed to be about files, and storing this data in a clear file securely transferred with FTPS, SFTP, or such would be even worse. At 08:44 PM 6/6/2011, Dave Thompson wrote: Another approach is to secure the files themselves, rather than just the transfer. That is, encrypt and perhaps sign the files when (or before) they are placed on the sending system(s), transfer them using plain FTP or HTTP or other, and decrypt and perhaps verify them on the receiving system(s). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Eric S. Eberhard (928) 567-3727 Voice (928) 567-6122 Fax (928) 301-7537 Cell Vertical Integrated Computer Systems, LLC Metropolis Support, LLC For Metropolis support and VICS MBA Supporthttp://www.vicsmba.com Pictures of Snake in Spring http://www.facebook.com/album.php?aid=115547id=1409661701l=1c375e1f49 Pictures of Camp Verde http://www.facebook.com/album.php?aid=12771id=1409661701l=fc0e0a2bcf Pictures of Land Cruiser in Sedona http://www.facebook.com/album.php?aid=50953id=1409661701 Pictures of Flagstaff area near our cabin http://www.facebook.com/album.php?aid=12750id=1409661701 Pictures of Cheryl in a Horse Show http://www.facebook.com/album.php?aid=32484id=1409661701 Pictures of the AZ Desert http://www.facebook.com/album.php?aid=58827id=1409661701 (You can see why we love this state :-) ) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Using PCKS Padding in OpenSSL
I would point out in that last approach -- encrypting and sending un secure (which is a good idea in many cases) does have a few considerations. If the data is sensitive (like magnetic strip data from a credit card) this is completely NOT ALLOWED. PCI and PA-DSS won't allow it to hit the disk. If you do hit the disk and you care about security on either end, you also need a secure delete program. Simply deleting a file does not remove the data from the disk. It takes about 5 lines of C to make a secure delete which if anyone likes I can give them. Eric At 08:44 PM 6/6/2011, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of greenelephant Sent: Sunday, 05 June, 2011 05:20 Thanks for the reply Dave. I am grateful for your advice. I am a novice as you have probably gathered. If I am not wrong in my judgement you seem to have some expertise on cryptology. Some, not a whole lot. I have stated SSL in my first post that I would like help with as you know. But with your expertise is there a better solution to use except SSL in terms of security using openssl? SSL/TLS (preferably the newest version supported, today usually TLS 1.1 or maybe 1.2) is a good general solution for security of Internet endpoint communication (particularly, but not only, web traffic using HTTPS). OpenSSL is a good implementation of SSL/TLS, plus some related (crypto) functionality, but not the only one; any other conforming and well-tested implementation available to you should be fine. For examples, Java includes its own SSL/TLS implementation (for Java), and I understand dot-NET does (for C#, VB, etc.) There are other protocols that may be better in specific situations (e.g. SSH as below) or necessary (e.g. IPsec and DNSsec are done at a level below where SSL can work). Also is SSL an ideal security solution for secured FTP transmissions using the openssl module to enable me to subvert any efforts to sabotage or breach security perpetrated by intruders or hackers using the methods of attacks (side channeling for instance) previously mentioned? FTP over SSL (FTPS) is a secure means of file transfer, if supported by both your server(s) and your client(s), which in my experience is not very common. When it is supported, the server and client code determines what module is used; it might be OpenSSL or something else. Another good and in my experience more common method of securing file transfer is SFTP, part of the SSH protocol suite. The crypto used in SSH is generally similar (though not identical) to SSL/TLS, and in fact the most widespread implementation OpenSSH uses libcrypto from OpenSSL, but the trust model is different (simpler). Instead of creating and verifying certificates, SSH requires you to manually verify a key fingerprint on the first connection between a given client and server (or else manually pre-transfer the encoded publickey). This isn't very good for communications with strangers (like sites you found on Google), but works okay for people that already have some contact (like your friends, customers of your company, etc). Another approach is to secure the files themselves, rather than just the transfer. That is, encrypt and perhaps sign the files when (or before) they are placed on the sending system(s), transfer them using plain FTP or HTTP or other, and decrypt and perhaps verify them on the receiving system(s). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Eric S. Eberhard (928) 567-3727 Voice (928) 567-6122 Fax (928) 301-7537 Cell Vertical Integrated Computer Systems, LLC Metropolis Support, LLC For Metropolis support and VICS MBA Supporthttp://www.vicsmba.com Pictures of Snake in Spring http://www.facebook.com/album.php?aid=115547id=1409661701l=1c375e1f49 Pictures of Camp Verde http://www.facebook.com/album.php?aid=12771id=1409661701l=fc0e0a2bcf Pictures of Land Cruiser in Sedona http://www.facebook.com/album.php?aid=50953id=1409661701 Pictures of Flagstaff area near our cabin http://www.facebook.com/album.php?aid=12750id=1409661701 Pictures of Cheryl in a Horse Show http://www.facebook.com/album.php?aid=32484id=1409661701 Pictures of the AZ Desert http://www.facebook.com/album.php?aid=58827id=1409661701 (You can see why we love this state :-) ) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Using PCKS Padding in OpenSSL
On Tue, Jun 7, 2011 at 3:21 PM, Eric S. Eberhard fl...@vicsmba.com wrote: I would point out in that last approach -- encrypting and sending un secure (which is a good idea in many cases) does have a few considerations. If the data is sensitive (like magnetic strip data from a credit card) this is completely NOT ALLOWED. PCI and PA-DSS won't allow it to hit the disk. If you do hit the disk and you care about security on either end, you also need a secure delete program. Simply deleting a file does not remove the data from the disk. It takes about 5 lines of C to make a secure delete which if anyone likes I can give them. Are you sure that its 5 lines? iPhone/iPad/iTouch puts my stomach in a knot due to lack of true background processing. Reliably Erasing Data From Flash-Based Solid State Drives, www.usenix.org/events/fast11/tech/full_papers/Wei.pdf. Jeff At 08:44 PM 6/6/2011, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of greenelephant Sent: Sunday, 05 June, 2011 05:20 Thanks for the reply Dave. I am grateful for your advice. I am a novice as you have probably gathered. If I am not wrong in my judgement you seem to have some expertise on cryptology. Some, not a whole lot. I have stated SSL in my first post that I would like help with as you know. But with your expertise is there a better solution to use except SSL in terms of security using openssl? SSL/TLS (preferably the newest version supported, today usually TLS 1.1 or maybe 1.2) is a good general solution for security of Internet endpoint communication (particularly, but not only, web traffic using HTTPS). OpenSSL is a good implementation of SSL/TLS, plus some related (crypto) functionality, but not the only one; any other conforming and well-tested implementation available to you should be fine. For examples, Java includes its own SSL/TLS implementation (for Java), and I understand dot-NET does (for C#, VB, etc.) There are other protocols that may be better in specific situations (e.g. SSH as below) or necessary (e.g. IPsec and DNSsec are done at a level below where SSL can work). Also is SSL an ideal security solution for secured FTP transmissions using the openssl module to enable me to subvert any efforts to sabotage or breach security perpetrated by intruders or hackers using the methods of attacks (side channeling for instance) previously mentioned? FTP over SSL (FTPS) is a secure means of file transfer, if supported by both your server(s) and your client(s), which in my experience is not very common. When it is supported, the server and client code determines what module is used; it might be OpenSSL or something else. Another good and in my experience more common method of securing file transfer is SFTP, part of the SSH protocol suite. The crypto used in SSH is generally similar (though not identical) to SSL/TLS, and in fact the most widespread implementation OpenSSH uses libcrypto from OpenSSL, but the trust model is different (simpler). Instead of creating and verifying certificates, SSH requires you to manually verify a key fingerprint on the first connection between a given client and server (or else manually pre-transfer the encoded publickey). This isn't very good for communications with strangers (like sites you found on Google), but works okay for people that already have some contact (like your friends, customers of your company, etc). Another approach is to secure the files themselves, rather than just the transfer. That is, encrypt and perhaps sign the files when (or before) they are placed on the sending system(s), transfer them using plain FTP or HTTP or other, and decrypt and perhaps verify them on the receiving system(s). [SNIP] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Using PCKS Padding in OpenSSL
From: owner-openssl-us...@openssl.org On Behalf Of Eric S. Eberhard Sent: Tuesday, 07 June, 2011 15:21 I would point out in that last approach -- encrypting and sending un secure (which is a good idea in many cases) does have a few considerations. If the data is sensitive (like magnetic strip data from a credit card) this is completely NOT ALLOWED. PCI and PA-DSS won't allow it to hit the disk. If you do hit the disk and you care about security on either end, you also need a secure delete snip To be exact, PCI DSS (and therefore PA-DSS) prohibits storing magstripe, CVV2 and PIN after authorization (even if encrypted). Authorization should always be real-time and thus there should be no good reason to store on disk during auth, but it isn't specifically prohibited. If you do store it, yes you will then need to wipe it. But this is not specific to my last approach. The OP's question seemed to be about files, and storing this data in a clear file securely transferred with FTPS, SFTP, or such would be even worse. At 08:44 PM 6/6/2011, Dave Thompson wrote: Another approach is to secure the files themselves, rather than just the transfer. That is, encrypt and perhaps sign the files when (or before) they are placed on the sending system(s), transfer them using plain FTP or HTTP or other, and decrypt and perhaps verify them on the receiving system(s). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Using PCKS Padding in OpenSSL
From: owner-openssl-us...@openssl.org On Behalf Of greenelephant Sent: Sunday, 05 June, 2011 05:20 Thanks for the reply Dave. I am grateful for your advice. I am a novice as you have probably gathered. If I am not wrong in my judgement you seem to have some expertise on cryptology. Some, not a whole lot. I have stated SSL in my first post that I would like help with as you know. But with your expertise is there a better solution to use except SSL in terms of security using openssl? SSL/TLS (preferably the newest version supported, today usually TLS 1.1 or maybe 1.2) is a good general solution for security of Internet endpoint communication (particularly, but not only, web traffic using HTTPS). OpenSSL is a good implementation of SSL/TLS, plus some related (crypto) functionality, but not the only one; any other conforming and well-tested implementation available to you should be fine. For examples, Java includes its own SSL/TLS implementation (for Java), and I understand dot-NET does (for C#, VB, etc.) There are other protocols that may be better in specific situations (e.g. SSH as below) or necessary (e.g. IPsec and DNSsec are done at a level below where SSL can work). Also is SSL an ideal security solution for secured FTP transmissions using the openssl module to enable me to subvert any efforts to sabotage or breach security perpetrated by intruders or hackers using the methods of attacks (side channeling for instance) previously mentioned? FTP over SSL (FTPS) is a secure means of file transfer, if supported by both your server(s) and your client(s), which in my experience is not very common. When it is supported, the server and client code determines what module is used; it might be OpenSSL or something else. Another good and in my experience more common method of securing file transfer is SFTP, part of the SSH protocol suite. The crypto used in SSH is generally similar (though not identical) to SSL/TLS, and in fact the most widespread implementation OpenSSH uses libcrypto from OpenSSL, but the trust model is different (simpler). Instead of creating and verifying certificates, SSH requires you to manually verify a key fingerprint on the first connection between a given client and server (or else manually pre-transfer the encoded publickey). This isn't very good for communications with strangers (like sites you found on Google), but works okay for people that already have some contact (like your friends, customers of your company, etc). Another approach is to secure the files themselves, rather than just the transfer. That is, encrypt and perhaps sign the files when (or before) they are placed on the sending system(s), transfer them using plain FTP or HTTP or other, and decrypt and perhaps verify them on the receiving system(s). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Using PCKS Padding in OpenSSL
Thanks for the reply Dave. I am grateful for your advice. I am a novice as you have probably gathered If I am not wrong in my judgement you seem to have some expertise on cryptology. I have stated SSL in my first post that I would like help with as you know. But with your expertise is there a better solution to use except SSL in terms of security using openssl? I will be thankful for any feedback received. :) :) greenelephant wrote: Hello 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 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 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. 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? Thank you in advance for any feedback -- View this message in context: http://old.nabble.com/Using-PCKS-Padding-in-OpenSSL-tp31728673p31776238.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Using PCKS Padding in OpenSSL
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 Listopenssl-users@openssl.org Automated
Re: Using PCKS Padding in OpenSSL
On Sun May 29 2011, greenelephant wrote: Hello 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 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. In the link you posted on the subject of side channel attacks, there is a link to the paper referenced. In that paper, section 5.1, Experiment Setup, the test setup is described. Which raises a question in my mind: Do you intend on using OpenSSL v0.9.7, compiled with gcc-2.96 on a single-core powered server? That setup reads as very 20th century to me. ;-) Mike 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 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. 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? Thank you in advance for any feedback __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
