Cipher suites

[Chris Clark]

According to the documentation, "medium" encryption cipher suites are

those that use 128 bit encryption, and "high" suites are those that use

higher then 128 bits...

 

Why is it that when I select a "medium" set of cipher suites, it will never

include any AES ciphers such as:

AES128-SHA

DHE-RSA-AES128-SHA

DHE-DSS-AES128-SHA

 

But when I select a "high" set of cipher suites it does include the above,

in addition to the 256 bit ciphers.

 

It seems that this is only a problem with the AES ciphers.

 

-Chris Clark

[Richard Salz]

The high medium and low are arbitrary terms, and date back to then the US
had stricter export controls on cryptography.

Ignore them.

        /r$

--
SOA Appliance Group
IBM Application Integration Middleware

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Chris Clark]

Hi Richard,

> The high medium and low are arbitrary terms, and date back to then the US
> had stricter export controls on cryptography.
>
> Ignore them.

But I want my client/server application to allow users to select the
level of encryption they wish to use. It is my understanding that 128
bit AES is faster then 256 bit AES, and will use less CPU overhead on
slower machines. Is this not true?

Is there an easy way I can limit openssl to only use 128 bit ciphers
for example?

-Chris Clark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Richard Salz]

The openssl "ciphers" command shows the text format of the cipher suites
supported....  Allow you users to choose from (a subset of) that list, and
set the env var or config param appropriately.  Like PATH, it's a
colon-separated list in order of priority.
        /r$

--
SOA Appliance Group
IBM Application Integration Middleware

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Chris Clark]

Hi Richard,

> The openssl "ciphers" command shows the text format of the cipher suites
> supported....  Allow you users to choose from (a subset of) that list, and
> set the env var or config param appropriately.  Like PATH, it's a
> colon-separated list in order of priority.

Yes, but that would be rather messy.

I was hoping for a simpler solution, so rather then letting users
choose the exact cipher suite names they could simply choose between
AES, 3DES, DES, RC4,  and they could also choose if they want MEDIUM
(128 bit) encryption, or HIGH (greater then 128 bit) encryption.

This method works great for everything except AES, which incorrectly
groups all the 128 bit ciphers as being HIGH instead of MEDIUM.

Is it  a known bug, or are the docs outdated?

-Chris Clark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Dr. Stephen Henson]

On Sat, Jan 28, 2006, Chris Clark wrote:

>
> I was hoping for a simpler solution, so rather then letting users
> choose the exact cipher suite names they could simply choose between
> AES, 3DES, DES, RC4,  and they could also choose if they want MEDIUM
> (128 bit) encryption, or HIGH (greater then 128 bit) encryption.
>
> This method works great for everything except AES, which incorrectly
> groups all the 128 bit ciphers as being HIGH instead of MEDIUM.
>
> Is it  a known bug, or are the docs outdated?
>

The docs are a bit outdated and the designation is always going to be a bit
subjective.

For example triple DES although it uses 168 bits due to the meet in the middle
attack is only effectively 112 bits.

Also there are grounds for classifying AES in general as "stronger" (for some
value of stronger) due its 128 bit block length compared to the other block
ciphers which have a 64 bit block length.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Chris Clark]

Hi Steve,

> Also there are grounds for classifying AES in general as "stronger" (for some
> value of stronger) due its 128 bit block length compared to the other block
> ciphers which have a 64 bit block length.

So I won't be able to use the MEDIUM and HIGH settings to let the
users choose between 128 bit and 256 bit key lengths when they are
using AES...

Looks like I will have to implement these user options the hard way then  :(

-Chris Clark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Richard Salz]

The docs are outdated.  AES is strong.
--
SOA Appliance Group
IBM Application Integration Middleware

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Kyle Hamilton]

If nothing else, you can implement your own interpretation of "HIGH"
and "MEDIUM", and then for MEDIUM as specified by the user change the
string passed to the cipher setup function to include "MEDIUM+" and
the AES128 algorithm names.

-Kyle H

On 1/28/06, Chris Clark <[hidden email]> wrote:

> Hi Steve,
>
> > Also there are grounds for classifying AES in general as "stronger" (for some
> > value of stronger) due its 128 bit block length compared to the other block
> > ciphers which have a 64 bit block length.
>
> So I won't be able to use the MEDIUM and HIGH settings to let the
> users choose between 128 bit and 256 bit key lengths when they are
> using AES...
>
> Looks like I will have to implement these user options the hard way then  :(
>
> -Chris Clark
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Chris Clark]

Hi Richard,

> The docs are outdated.  AES is strong.

That makes sense. In that case I could let users choose either MEDIUM
or "Strong" along with which Cipher group (RC4, 3DES, DES, AES).

Of course if they choose Medium and only AES, they would not have any
cipher in the result list, so I could hide AES as a selection when
Medium is selected. :)

A question: Would users see much performance difference between AES
128 bit and AES 256 bit ciphers on slower PC's, such as on PII and P3
class CPU's? What about CPU usage differences? I'm wondering if its
worth giving users detailed options on which ciphers to use, or to
stick with the simplistic nature of the MEDIUM and HIGH settings along
with the 4 groups.

 -Chris Clark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Chris Clark]

> If nothing else, you can implement your own interpretation of "HIGH"
> and "MEDIUM", and then for MEDIUM as specified by the user change the
> string passed to the cipher setup function to include "MEDIUM+" and
> the AES128 algorithm names.

Thanks Kyle. After giving this some thought I can see it would be best to do
it this way so the users have a choice of 128 or 256 bit AES, and at the same
time adhering to the documented definition of what MEDIUM means.

-Chris Clark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Samy Thiyagarajan]

hi
when i try to sign my request  i get an error saying the country name field need to be same in CA cert and in the req. !!
Any idea..?

here is the snip..

OpenSSL> ca -in expired_req.csr -cert ...  -keyfile ...  -key ....  -startdate 051201101010 -enddate 051230101010 -out expiredCert.pem
Using configuration from /usr/local/ssl/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
Check that the request matches the signature
Signature ok
The countryName field needed to be the same in the
CA certificate (DU) and the request (te)
7768:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:329:group=CA_default name=email_in_dn
error in ca

thanks
samy

[Dr. Stephen Henson]

On Wed, Feb 01, 2006, Samy Thiyagarajan wrote:

> hi
> when i try to sign my request  i get an error saying the country name
> field need to be same in CA cert and in the req. !!
>

That's because the policy section of the configuration file says they must
match.

If you don't want that use an alternative policy or edit the existing one.

Check out the policy section description on the "ca" manual page.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

[Samy Thiyagarajan]

Thanks Steve.
I got it

-Samy

"Dr. Stephen Henson" <[hidden email]>

Sent by:
[hidden email]

01.02.2006 13:59

Please respond to
[hidden email]

To	[hidden email]
cc
Subject	Re: Error in signing
Classification

On Wed, Feb 01, 2006, Samy Thiyagarajan wrote:

> hi
> when i try to sign my request  i get an error saying the country name
> field need to be same in CA cert and in the req. !!
>

That's because the policy section of the configuration file says they must
match.

If you don't want that use an alternative policy or edit the existing one.

Check out the policy section description on the "ca" manual page.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]