Using PCKS Padding in OpenSSL

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Using PCKS Padding in OpenSSL

greenelephant
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
Reply | Threaded
Open this post in threaded view
|

Re: Using PCKS Padding in OpenSSL

Michael S. Zick-4
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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Using PCKS Padding in OpenSSL

Dave Thompson-5
In reply to this post by greenelephant
> From: [hidden email] 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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using PCKS Padding in OpenSSL

greenelephant
In reply to this post by greenelephant
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?
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?
  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
Reply | Threaded
Open this post in threaded view
|

RE: Using PCKS Padding in OpenSSL

Dave Thompson-5
> From: [hidden email] 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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Using PCKS Padding in OpenSSL

Eric S. Eberhard-2
In reply to this post by greenelephant
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: [hidden email] 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 List                    [hidden email]
>Automated List Manager                           [hidden email]


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 Support!!!!    http://www.vicsmba.com

Pictures of Snake in Spring

http://www.facebook.com/album.php?aid=115547&id=1409661701&l=1c375e1f49

Pictures of Camp Verde

http://www.facebook.com/album.php?aid=12771&id=1409661701&l=fc0e0a2bcf

Pictures of Land Cruiser in Sedona

http://www.facebook.com/album.php?aid=50953&id=1409661701

Pictures of Flagstaff area near our cabin

http://www.facebook.com/album.php?aid=12750&id=1409661701

Pictures of Cheryl in a Horse Show

http://www.facebook.com/album.php?aid=32484&id=1409661701


Pictures of the AZ Desert

http://www.facebook.com/album.php?aid=58827&id=1409661701

(You can see why we love this state :-) )








______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Using PCKS Padding in OpenSSL

Jeffrey Walton-3
On Tue, Jun 7, 2011 at 3:21 PM, Eric S. Eberhard <[hidden email]> 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: [hidden email] 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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Using PCKS Padding in OpenSSL

Dave Thompson-5
In reply to this post by Eric S. Eberhard-2
> From: [hidden email] 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 List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Using PCKS Padding in OpenSSL

Eric S. Eberhard-2
In reply to this post by Eric S. Eberhard-2
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: [hidden email] 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 List                    [hidden email]
>Automated List Manager                           [hidden email]


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 Support!!!!    http://www.vicsmba.com

Pictures of Snake in Spring

http://www.facebook.com/album.php?aid=115547&id=1409661701&l=1c375e1f49

Pictures of Camp Verde

http://www.facebook.com/album.php?aid=12771&id=1409661701&l=fc0e0a2bcf

Pictures of Land Cruiser in Sedona

http://www.facebook.com/album.php?aid=50953&id=1409661701

Pictures of Flagstaff area near our cabin

http://www.facebook.com/album.php?aid=12750&id=1409661701

Pictures of Cheryl in a Horse Show

http://www.facebook.com/album.php?aid=32484&id=1409661701


Pictures of the AZ Desert

http://www.facebook.com/album.php?aid=58827&id=1409661701

(You can see why we love this state :-) )








______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Using PCKS Padding in OpenSSL

greenelephant
In reply to this post by Eric S. Eberhard-2
Thanks Dave, Eric and jeffrey. I would truly be lost without your help!

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-users@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 List                    openssl-users@openssl.org
>Automated List Manager                           majordomo@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 Support!!!!    http://www.vicsmba.com

Pictures of Snake in Spring

http://www.facebook.com/album.php?aid=115547&id=1409661701&l=1c375e1f49

Pictures of Camp Verde

http://www.facebook.com/album.php?aid=12771&id=1409661701&l=fc0e0a2bcf

Pictures of Land Cruiser in Sedona

http://www.facebook.com/album.php?aid=50953&id=1409661701

Pictures of Flagstaff area near our cabin

http://www.facebook.com/album.php?aid=12750&id=1409661701

Pictures of Cheryl in a Horse Show

http://www.facebook.com/album.php?aid=32484&id=1409661701


Pictures of the AZ Desert

http://www.facebook.com/album.php?aid=58827&id=1409661701

(You can see why we love this state :-) )








______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org
Reply | Threaded
Open this post in threaded view
|

RE: Using PCKS Padding in OpenSSL

Dave Thompson-5
> From: [hidden email] 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                    [hidden email]
Automated List Manager                           [hidden email]