Will OpenSSL fallback to software mode if ENGINE using hardware fails?

[Maciej Grzymkowski]

Hi everyone,

Firstly, I'm a beginner in the OpenSSL world. I apologize in advance for
any basic, barbaric errors. Also not quite sure if it's OK to ask here, if
not - please disregard it. I've asked this question on stackoverflow as
well.

Consider a flow:
- Initialize OpenSSL with engine using hardware (let's call it EngineHW).
- Call an OpenSSL function, e.g. X509_sign.

1. How to check if the function called was performed on the hardware?
(seems engine specific)
2. How to verify the EngineHW function was called?
3. What if the function is not defined by EngineHW - will OpenSSL fallback
to any default engine it has? (related to two)

The question is related to asserting quality - since I've got the hardware
to do crypto for me, I consider using software implementation an error (at
least for the important/heavy functions).

It seems easy to check for operations requiring keys - those do not leave
the HSM. But cert checking, RAND, hashing, and so on?


Best regards,

Maciej G.

RE: cannot read PEM key file - no start line

[Dave Thompson]

I was half wrong before. 

 

The base64 read in EVP_Decode* allows 76. But the PEM parser in PEM_read_bio 

enforces exactly 64 >>only for input files that have PEM-encrypt headers<< 

which in practice is only encrypted legacy-format privatekey files.

(Nonprivate things like cert, CSR, publickey, params, etc. aren’t encrypted at 
all.

PKCS8 privatekey or PKCS12 key-plus-cert is encrypted within the ASN1, not as 
PEM.)

 

I have and know of no software to create encrypted legacy-format privatekeys

other than OpenSSL itself which always writes 64, so I never encountered this 
before.

(Other sw does do PKCS8-e or PKCS12 but see above.)

 

(As seen elsethread, OP apparently had PEM certs where PEM key was expected.)

 

From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Jeffrey Walton
Sent: Tuesday, September 09, 2014 08:09
To: OpenSSL Users List
Subject: Re: cannot read PEM key file - no start line

 

 

 

On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall  wrote:

All,

 

I am getting the following with my client cert when trying to connect to an 
SSL-enabled MongoDB:

 

2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: 
/users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem 
error:0906D06C:PEM routines:PEM_read_bio:no start line

I just tried to duplicate with a key (not a certificate) that uses line breaks 
at 76 characters. I don't have a certificate because my routines don't support 
certificates. But it should reveal a little about the OpenSSL parser.

Reading the public and private keys were OK when the line size was 76 (see 
below). So the OpenSSL parser is lenient during a read. This seems very 
reasonable to me.

Reading an encrypted private key resulted in an error "PEM_read_bio:bad end 
line:pem_lib.c:802" when the line size was 76 (see below). This kind of 
surprised me.

Since you are receiving the "no start line" error (and not another error), I 
would suspect you are reading an ASN.1/DER encoded certificate; and not a PEM 
encoded certificate. The error occured before anything related to line lengths.

RE: Certificate pass phrase brute force...

[Dave Thompson]

(Sorry not inline, my Outlook can’t do that for HTML.)

 

That’s actually a subvariant I forgot to describe: PKCS#8 *version 2*.

It has “BEGIN ENCRYPTED PRIVATE KEY” (not specifying RSA etc.) like version 1,

but instead of a single PBE algorithm-id PBE-with-$kdf-and-$cipher it has a 
structure

PBES2 with {$kdf-alg using $params} and {$cipher-alg using $params}.

So yes you read right, the cipher part is TDEA aka [3]DES[3]-EDE[3] in CBC mode.

 

Yes, req –newkey can only encrypt with TDEA. You can do that and then 

re-encrpyt as you did; or you generate the key separately with genpkey 

encrypting with any algo and then use req –new on that key.

Either way is two steps.

 

However, your conversion apparently produced a legacy-format file 

“BEGIN RSA PRIVATE KEY” with DEK-Info. You/the script probably used 

rsa -$cipher , which does this. This is MUCH LESS SECURE.

As I believe was mentioned, no one will bruteforce the data cipher, 

neither TDEA nor AES-anything. Even 112 would take basically all the 

computers on Earth for many many years, and 128 millions or more.

Even NSA can’t do that. What can be attacked is the password-based 

derivation, especially if the password is something a human can remember.

And for backward compatibility the legacy-format files use a poor PBKDF – 

based on PBKDF1 (slightly poor) WITH ITERATIONS=1 (AWFUL!!!).

 

If you want decent security at all, much less anything even approaching the 

strength AES-256 appears to promise, use pkcs8 –topk8 –v2 $cipher

(which unobviously works for input that is already pkcs8) or pkey -$cipher .

 

Cheers.

 

 

From:   owner-openssl-us...@openssl.org 
[  
mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop
Sent: Tuesday, September 09, 2014 01:19
To:   openssl-users@openssl.org
Subject: Re: Certificate pass phrase brute force...

 

I used the asn1parse command [thanks Dave!] and while the key looks "old style" 
it parses as follows:

50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc

Which appears to equate to: des-ede3-cbc   Three key triple DES EDE in CBC 
mode

The full asn parse is:
---
 0:d=0  hl=4 l=2446 cons: SEQUENCE
   4:d=1  hl=2 l=  64 cons: SEQUENCE
   6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
  17:d=2  hl=2 l=  51 cons: SEQUENCE
  19:d=3  hl=2 l=  27 cons: SEQUENCE
  21:d=4  hl=2 l=   9 prim: OBJECT:PBKDF2
  32:d=4  hl=2 l=  14 cons: SEQUENCE
  34:d=5  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA 
(REDACTED)
  44:d=5  hl=2 l=   2 prim: INTEGER   :0800
  48:d=3  hl=2 l=  20 cons: SEQUENCE
  50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc
  60:d=4  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA 
(REDACTED)
---
[I don't know if I needed to redact those fields at all, but I don't think it 
matters.)

So, if I've read that properly, the encryption method is 3DES.

---
While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA 
script from OpenVPN - I thought I'd share a solution that appears to work and 
do what I want.

It doesn't appear easy to modify the EasyRSA script to use aes-256 [or any non 
3DES cypher] in the script. From my look at the syntax of a "openssl req -new 
-newkey ..." command, you don't get to specify the cypher it will use in 
encrypting the private key. This appears to be a result of generating both the 
key and the signing request in a single step - in this case you don't appear to 
get to choose what crypto is used to encrypt the private key. [I'd be glad to 
be shown a way you can specify it - it doesn't appear possible from the 
command-line options at least.] 

However, as I pointed out there is code in the EasyRSA tool to re-encrypt the 
private key with a new password, or remove the password.
You can edit the script to use aes256 as follows: [or any of the other cyphers 
here:   
https://www.openssl.org/docs/apps/rsa.html#]
In the easyrsa bash script:
Look for the line: [ local crypto="-des3" ] (It's line 861 in the current 
EasyRSA version)
Change it to: [ local crypto="-aes256" ]

Now when you issue the command easyrsa set-rsa-pass, and issue the "old" 
encryption key, along with a new one [you can certainly use the same key for 
the old and "new"] it will re-encrypt it with aes-256.

Looking at the key file it does appear to indeed work and re-encrypts it with 
AES-256.

#cat somekey.key
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC ...

---
Thus, this is the best work-around for the tool I can find. Unfortunately it 
requires a "redundant" step unless someone can show me a way to put the 
encryption type for private keys in a config file or specify it as part of a 
"openssl -req ..." command

But at least it works the way I want it to, and makes the task of setting up 
keys and 

Re: Certificate pass phrase brute force...

[Kyle Hamilton]

Having a sterile VM to do all of the cert generation is a good idea. But can 
you guarantee, in these days of logging and versioned filesystems, that the 
unencrypted key file data block will in fact be overwritten by the encryption? 
Or will it remain intact, with a new data block allocated for the new content?

(Also, I'm trying to generalize good security principles to the design of a 
non-specific script. I now see that you have a particular scenario with a 
particular threat model in mind, and disclaim the creation of a solution for 
general utility.)

-Kyle H

On September 9, 2014 3:27:27 PM PST, Gregory Sloop  wrote:
>@Kyle: I'm the admin for the OpenVPN system setup and config, and
>generate all the server/client certs, CA etc., and if my machine is
>infested with malware, then well, the CA's compromised, along with
>everything else. IOW, game over.
>
>It's not that I disagree with you particularly, but I doubt that the
>short time a private key is "exposed" before it gets re-encrypted, will
>matter much, especially in the very controlled situation I'm
>contemplating. [Which is actually inside a sterile VM.]
>
>---
>@Michael: Yeah, I can use the EasyRSA tool to initially create the
>Key+CSR without a password [encryption-less] and then add the aes-256
>re-key in the second process. [Like so: # easyrsa build-client-full
>somefilename nopass ] As I was writing up the post last night, I
>thought about describing that process, but thought it would confuse
>things further since I hadn't opened the thread that way...
>
>But yet, that will make it easier as I only have to input the password
>once into the terminal, instead of on both passes.
>
>And you're right in regards to modifying the EasyRSA script; it's more
>work than I'm able to do at the moment, and while I'm not terrible at
>bash, I'd be hesitant in making fairly major mods to [security
>critical] code in fear of introducing ill effects that won't get caught
>in a cursory peer-review.
>
>The current code can be made to work without too much hassle and has
>been around for a while and has been real-world tested. Unless the
>current maintainer is willing to do it, it's probably better to leave
>it the way it is now with the minor change I suggest.
>
>Again thanks all for the excellent help, ideas and suggestions. It's
>been a pleasure. 
>[And that's an uncommon compliment - far more than can be said of many
>listservs.]
>
>-Greg
>
>
>Sure, if that's a better fit to your threat model. (I certainly
>wouldn't recommend changing "openssl req" to make -nodes the default.)
>I was just suggesting possibilities for Gregory.
> 
>Personally, I'd probably go with generating an encrypted private key
>with "openssl genpkey" first, but that might be more changes to the
>EasyRSA script than he's inclined to make. He has a working solution
>now which seems fine for his purposes.
> 
>A cipher option for "openssl req -newkey" wouldn't be a bad idea, but
>it's not a high priority, so I wouldn't expect it to happen anytime
>soon unless someone wants to submit a patch.
> 
>Michael Wojcik 
>Technology Specialist, Micro Focus
> 
> 
>From: Kyle Hamilton [mailto:aerow...@gmail.com] 
>Sent: Tuesday, 09 September, 2014 13:43
>To: openssl-users@openssl.org; Michael Wojcik
>Subject: RE: Certificate pass phrase brute force...
> 
>At least 3DES is *some* encryption. The issue is that peoples'
>computers are usually infested with malware; it's better to assume (for
>a software distribution) that the disk is compromised, and always
>encrypt it before writing.
>
>Perhaps there should be a cipher option for the req -newkey option?
>
>-Kyle H
>On September 9, 2014 8:58:08 AM PST, Michael Wojcik
> wrote:
>As far as I know, openssl req doesn't let you specify the encryption
>cipher for the private key.
> 
>You can generate the key file first, with openssl genpkey, which does
>let you specify the encryption cipher; and then use -key to tell
>openssl to use your existing key rather than creating a new one.
> 
>You can also do what you describe below, but not encrypt the private
>key the first time, by using the -nodes option with openssl req; that
>saves decrypting it before encrypting it with your preferred cipher.
> 
> 
>Michael Wojcik 
>Technology Specialist, Micro Focus
> 
> 
>From: owner-openssl-us...@openssl.org
>[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop
>Sent: Tuesday, 09 September, 2014 01:19
>To: openssl-users@openssl.org
>Subject: Re: Certificate pass phrase brute force...
> 
>I used the asn1parse command [thanks Dave!] and while the key looks
>"old style" it parses as follows:
>
>50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc
>
>Which appears to equate to: des-ede3-cbc   Three key triple DES EDE
>in CBC mode
>
>The full asn parse is:
>---
> 0:d=0  hl=4 l=2446 cons: SEQUENCE
>   4:d=1  hl=2 l=  64 cons: SEQUENCE
>   6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
>  17:d=2  hl=2 l=  51 cons: SEQUENCE
>  19:d=3  hl=2 l=  27 cons: SEQUE

Re: Certificate pass phrase brute force...

[Gregory Sloop]

@Kyle: I'm the admin for the OpenVPN system setup and config, and generate all 
the server/client certs, CA etc., and if my machine is infested with malware, 
then well, the CA's compromised, along with everything else. IOW, game over.

It's not that I disagree with you particularly, but I doubt that the short time 
a private key is "exposed" before it gets re-encrypted, will matter much, 
especially in the very controlled situation I'm contemplating. [Which is 
actually inside a sterile VM.]

---
@Michael: Yeah, I can use the EasyRSA tool to initially create the Key+CSR 
without a password [encryption-less] and then add the aes-256 re-key in the 
second process. [Like so: # easyrsa build-client-full somefilename nopass ] As 
I was writing up the post last night, I thought about describing that process, 
but thought it would confuse things further since I hadn't opened the thread 
that way...

But yet, that will make it easier as I only have to input the password once 
into the terminal, instead of on both passes.

And you're right in regards to modifying the EasyRSA script; it's more work 
than I'm able to do at the moment, and while I'm not terrible at bash, I'd be 
hesitant in making fairly major mods to [security critical] code in fear of 
introducing ill effects that won't get caught in a cursory peer-review.

The current code can be made to work without too much hassle and has been 
around for a while and has been real-world tested. Unless the current 
maintainer is willing to do it, it's probably better to leave it the way it is 
now with the minor change I suggest.

Again thanks all for the excellent help, ideas and suggestions. It's been a 
pleasure. 
[And that's an uncommon compliment - far more than can be said of many 
listservs.]

-Greg


Sure, if that's a better fit to your threat model. (I certainly wouldn't 
recommend changing "openssl req" to make -nodes the default.) I was just 
suggesting possibilities for Gregory.
 
Personally, I'd probably go with generating an encrypted private key with 
"openssl genpkey" first, but that might be more changes to the EasyRSA script 
than he's inclined to make. He has a working solution now which seems fine for 
his purposes.
 
A cipher option for "openssl req -newkey" wouldn't be a bad idea, but it's not 
a high priority, so I wouldn't expect it to happen anytime soon unless someone 
wants to submit a patch.
 
Michael Wojcik 
Technology Specialist, Micro Focus
 
 
From: Kyle Hamilton [mailto:aerow...@gmail.com] 
Sent: Tuesday, 09 September, 2014 13:43
To: openssl-users@openssl.org; Michael Wojcik
Subject: RE: Certificate pass phrase brute force...
 
At least 3DES is *some* encryption. The issue is that peoples' computers are 
usually infested with malware; it's better to assume (for a software 
distribution) that the disk is compromised, and always encrypt it before 
writing.

Perhaps there should be a cipher option for the req -newkey option?

-Kyle H
On September 9, 2014 8:58:08 AM PST, Michael Wojcik 
 wrote:
As far as I know, openssl req doesn't let you specify the encryption cipher for 
the private key.
 
You can generate the key file first, with openssl genpkey, which does let you 
specify the encryption cipher; and then use -key to tell openssl to use your 
existing key rather than creating a new one.
 
You can also do what you describe below, but not encrypt the private key the 
first time, by using the -nodes option with openssl req; that saves decrypting 
it before encrypting it with your preferred cipher.
 
 
Michael Wojcik 
Technology Specialist, Micro Focus
 
 
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Gregory Sloop
Sent: Tuesday, 09 September, 2014 01:19
To: openssl-users@openssl.org
Subject: Re: Certificate pass phrase brute force...
 
I used the asn1parse command [thanks Dave!] and while the key looks "old style" 
it parses as follows:

50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc

Which appears to equate to: des-ede3-cbc   Three key triple DES EDE in CBC 
mode

The full asn parse is:
---
 0:d=0  hl=4 l=2446 cons: SEQUENCE
   4:d=1  hl=2 l=  64 cons: SEQUENCE
   6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
  17:d=2  hl=2 l=  51 cons: SEQUENCE
  19:d=3  hl=2 l=  27 cons: SEQUENCE
  21:d=4  hl=2 l=   9 prim: OBJECT:PBKDF2
  32:d=4  hl=2 l=  14 cons: SEQUENCE
  34:d=5  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA 
(REDACTED)
  44:d=5  hl=2 l=   2 prim: INTEGER   :0800
  48:d=3  hl=2 l=  20 cons: SEQUENCE
  50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc
  60:d=4  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA 
(REDACTED)
---
[I don't know if I needed to redact those fields at all, but I don't think it 
matters.)

So, if I've read that properly, the encryption method is 3DES.

---
While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA 
script from OpenVPN - I thought I'd share a so

Re: Why does OpenSSL own all the prefixes in the world?

[Ted Byers]

On Tue, Sep 9, 2014 at 2:42 PM, Iñaki Baz Castillo  wrote:
> The (bad) idea of using C++ namespaces was just targeted for those
> integrating OpenSSL into their own C++ projects.
>
Now, I would have said that using C++ namespaces was a good idea and
perhaps it might be motivation to replace the MACROs by something more
useful,

> El 09/09/2014 20:39, "Larry Bugbee"  escribió:
>>
>> In the FWIW column
>>
>> Please don't mangle names by forcing C++ namespaces.  Some us call OpenSSL
>> from Python (and other dynamic languages) and depend on the C naming
>> convention.  Adding a "OSSL_" prefix is fine; mangling creates huge
>> problems.
>>
I use a number of such languages and it isn't all that hard to mix
them with C++ (in sme cases, I'd extend them using C++ code, for the
sake of performance).  In the case of Python, for example, there is a
boost library designed specifically for that purpose.  From my
perspective, that is not a big problem.  Rather, it is just one of
countless things I routinely have to deal with: just the cost of
getting things done.

Cheers

Ted

-- 
R.E.(Ted) Byers, Ph.D.,Ed.D.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: On 2K keys and SHA-256

[Benny Baumann]

Hi Rich,

Am 09.09.2014 14:18, schrieb Salz, Rich:
>> May I suggest 4096 bit with SHA-256.
> 
> I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see 
> much deployment because of the computational cost.  At least, that's how we 
> see things at my employer.
> 
>> And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you
>> to create Low (512), Medium (1024) or High (2048) grade encryption keys
>> (patch available for ages BTW) ...
> 
> If you can point me to patches, email, or whatever I can try to make sure 
> those links get seen by folks in charge.
Sure, there are 6 related bugs when searching for "keygen" on Mozilla's
Bugzilla that effect the problem:

Key size spec for  tag:
https://bugzilla.mozilla.org/show_bug.cgi?id=495876
(potentially doing a comma list of asymm+size - e.g. rsa2048,dsa2048,...
- might be an option working for every cipher with ecc-* to wildcard all
EC curves or !dsa to prohibit any DSA keys might be an option).

1024 bit option should be removed:
https://bugzilla.mozilla.org/show_bug.cgi?id=649910
(or the default options modified to more sane values like 2048, 3072 and
4096)

Automated tests for  tag
https://bugzilla.mozilla.org/show_bug.cgi?id=698315
(IIRC this one was the blocker for some of the other issues)

Some more automated tests for  tag
https://bugzilla.mozilla.org/show_bug.cgi?id=960888
(IMHO low prio, but probably related)

SPKAC signed with MD5withRSAencryption
https://bugzilla.mozilla.org/show_bug.cgi?id=549460
(would be nice if this was done with SHA-2 - or I'd prefer using a
setting to select between MD5 up to SHA-3, but optional on that setting)

Increase options offered by  tag
https://bugzilla.mozilla.org/show_bug.cgi?id=495836
(IMHO one of the oldest issues in the list)

For Chrome I can fire up a search on the bugtracker too if you like, but
the issues should be similar. Also, when we are at client certificates:
please remove the limit of sent client certificates: If I happen to have
a certificate with such a long key (and Firefox happily imports them)
you shouldn't get into trouble while using them. Will file a bug for the
exact behaviour when I get around to it (related to the #747453 issue in
Debian).

Regards,
BenBE.
> 
>   /r$
> --  
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: rs...@jabber.me Twitter: RichSalz
> 
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
> 




signature.asc
Description: OpenPGP digital signature

Re: Verifying authenticode signature using openssl API

[Kyle Hamilton]

http://msdn.microsoft.com/en-us/windows/hardware/gg463180.aspx is the spec for 
the Authenticode PE signature format.

http://msdn.microsoft.com/en-us/gg463119 is the Microsoft PE and COFF 
Specification.

Better download them now before they disappear, they appear to be deprecated in 
favor of Windows 8 format packages (of which I have no information).

On September 9, 2014 10:18:18 AM PST, Prasad Dabak  wrote:
>Thanks Jacob for your response. Very informative indeed!
>
>Thanks
>-Prasad
>
>Sent from my iPhone
>
>> On 09-Sep-2014, at 10:05 pm, Jakob Bohm 
>wrote:
>> 
>>> On 09/09/2014 09:01, Prasad Dabak wrote:
>>> Thanks Jacob for an elaborate answer. Somehow I never received your
>response to my registered email address, hence delay in responding.
>> This time I have CC-ed you in addition to the mail list.
>>> I have a few follow-up questions on your response.
>>> 
>>> 1. So, "encryptedDigest"  has no relation to the stored
>"messageDigest"? I thought it's a encrypted version of the
>messageDigest?
>> As far as I recall, there is a chain of 4 digests.  The first digest
>> is calculated over the file and is stored in the spcIndirectData. The
>> second digest is calculated over the spcIndirectData (the contentInfo
>> of the the PKCS#7 structure) and is stored as "messageDigest" in the
>> AuthenticatedAttributes of each PKCS#7 signerInfo.  The third hash
>> is calculated over the AuthenticatedAttributes and is signed to
>> produce the "encryptedDigest" in that same signerInfo.  All 3 need to
>> be checked to confirm that the file hash is actually (indirectly)
>> signed by the encryptedDigest using the public key in the certificate
>> whose name is listed in the signerInfo.
>>> 2. I agree that it's better to do cheaper checks first e.g. I am
>also matching PE checksum stored in the optional header.
>> Indeed, though that is a very weak checksum (file size plus 16 bit
>TCP/IP
>> checksum of file).  Also it is allowed to be 0 to indicate no
>checksum
>> (even if you set the checksum, it might be cleared if an
>Administrator
>> adds his own countersignature to all authorized programs on his
>> computers, aka AppLocker).
>>> 3. spcPEImageData is probably relevant only for signing that uses
>page hashes?
>> I never quite figured out where they store the page hashes. However I
>> believe the constant semi-empty spcPEImageData with the
>"<<>>"
>> string is the traditional marker to indicate that the signature is
>for
>> a PE file, and not e.g. a document file with the same hashed
>bytestream.
>> 
>>> 4. PKCS7_verify is already matching the encryptedDigest, do we still
>need to validate it ourselves?
>> If it is, I am myself guessing a bit as to what that function does
>and
>> does not check.  But note that it probably doesn't check the full
>chain
>> of 3 message digests, since at least the digest over the file itself
>is
>> inside a blob that the PKCS#7 standard has no opinion about.
>>> 5. So, basically are are suggesting to look into the subject string
>and see if we can find patterns like /CN=COMPANY-NAME... issuer:
>/C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone
>else have same COMPANY-NAME and PATTERN-NAME in their certificate?
>> Actually, the subject is a data structure (a hierarchical list of
>sets
>> of tagged strings) and the relevant comparison would be to compare
>those
>> elements that don't change when getting a new certificate from the
>CA.
>> It is the CAs responsibility to make sure the don't issue
>certificates
>> to the wrong people, and if they make a mistake they are expected to
>> quickly add the bad certificate to their published CRL, which is why
>> you need to check the CRL before trusting the certificate.  An
>> additional check is to make sure the CA that issued the intermediary
>> certificate that issued the "COMAPNY-NAME" certificate is actually
>one
>> of the (few) CAs that "COMPANY-NAME" is going to buy certificates
>from.
>>  This protects against fake certificates issued by smaller CAs that
>> you aren't going to use anyway.
>>> 
>>> In my case, I am the one who is signing the executable using my
>certificate and a "cross certificate" issued by Microsoft and I want to
>programmatically ensure following things.
>>> 
>>> 1. Code is not tampered since it was signed (matching messageDigest
>with computed hash)
>> Actually matching digest in spcIndirectData with computed hash. Plus
>> consistency checks to make sure the signature is actually for a PE
>file
>> and was not otherwise doctored.  For instance there should be no
>bytes
>> in the file after the end of the signature blob.
>>> 2. Verifying the digital signature (PKCS7_Verify)
>>> 3. Confirming that the executable is signed by my company
>certificate.
>>> 
>>> I am stuck on part (3) and don't see a clean way apart from matching
>strings in subject field?  If I hard-code the public key in my
>verification code, I will need to update it when I switch to a newer
>public key?
>> Yep, that is why careful matching

RE: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

The (bad) idea of using C++ namespaces was just targered for those
integrating OpenSSL into their own C++ projects.
El 09/09/2014 20:39, "Larry Bugbee"  escribió:

> In the FWIW column
>
> Please don't mangle names by forcing C++ namespaces.  Some us call OpenSSL
> from Python (and other dynamic languages) and depend on the C naming
> convention.  Adding a "OSSL_" prefix is fine; mangling creates huge
> problems.
>
>
> -- Sent fm iTouch via Boxer
>

RE: Why does OpenSSL own all the prefixes in the world?

[Larry Bugbee]

In the FWIW column Please don't mangle names by forcing C++ namespaces.  
Some us call OpenSSL from Python (and other dynamic languages) and depend on 
the C naming convention.  Adding a "OSSL_" prefix is fine; mangling creates 
huge problems. 

-- Sent fm iTouch via Boxer

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-

> us...@openssl.org] On Behalf Of Iñaki Baz Castillo

> Sent: Tuesday, 09 September, 2014 12:44

> To: openssl-users@openssl.org

> Subject: Re: Why does OpenSSL own all the prefixes in the world?

>  
> May be I was not clear, but what I mean is:

>  
>  
> - Let's suppose openssl/foo.h has a #include .

>  
> - In myproject.h I add:

>  
>   namespace myproject {

>   #include 

>   }

>  
> - And then in myproject.cpp I write:

>  
>   p = (char*)malloc(sizeof(char) * 100);

>  
>  
> Would this produce the "malloc not found, may be you mean

> 'myproject::malloc'?" error?

>  
> PS: Note that I do NOT include  in myproject.*.



Yes, in this case I'd expect that error. You need to include stdlib.h outside 
of any namespace before you include openssl/foo.h.



My advice would be to stick a bunch of include statements for all the standard 
headers used by any openssl/*.h into a single .h file, and then include that at 
the top of myproject.h and any other C++ header file that includes an OpenSSL 
header.



So:



- Create openssl_c_hdrs.h which has:



#include 

#include 

#include 

...



- Change myproject.h to have:



#include "openssl_c_hdrs.h"

namespace myproject {

#include 

}



Again, I can't say for sure that will work, because I haven't tested it. But it 
ought to work around this particular issue. The standard headers included by 
openssl_c_hdrs.h will preempt their inclusion within the namespace by the 
OpenSSL headers.



Of course, for C++ code you normally wouldn't include the C standard headers; 
you'd use their C++ versions (, etc). But this sort of thing is a 
special case.



--  
Michael Wojcik

Technology Specialist, Micro Focus







This message has been scanned for malware by Websense. www.websense.com
???H???7??m
)z{,???RǫJ?i??Lj)b????)z{,????)z{,????h??^t???Ƨj??&??^??%??

Re: Verifying authenticode signature using openssl API

[Prasad Dabak]

Thanks Jacob for your response. Very informative indeed!

Thanks
-Prasad

Sent from my iPhone

> On 09-Sep-2014, at 10:05 pm, Jakob Bohm  wrote:
> 
>> On 09/09/2014 09:01, Prasad Dabak wrote:
>> Thanks Jacob for an elaborate answer. Somehow I never received your response 
>> to my registered email address, hence delay in responding.
> This time I have CC-ed you in addition to the mail list.
>> I have a few follow-up questions on your response.
>> 
>> 1. So, "encryptedDigest"  has no relation to the stored "messageDigest"? I 
>> thought it's a encrypted version of the messageDigest?
> As far as I recall, there is a chain of 4 digests.  The first digest
> is calculated over the file and is stored in the spcIndirectData. The
> second digest is calculated over the spcIndirectData (the contentInfo
> of the the PKCS#7 structure) and is stored as "messageDigest" in the
> AuthenticatedAttributes of each PKCS#7 signerInfo.  The third hash
> is calculated over the AuthenticatedAttributes and is signed to
> produce the "encryptedDigest" in that same signerInfo.  All 3 need to
> be checked to confirm that the file hash is actually (indirectly)
> signed by the encryptedDigest using the public key in the certificate
> whose name is listed in the signerInfo.
>> 2. I agree that it's better to do cheaper checks first e.g. I am also 
>> matching PE checksum stored in the optional header.
> Indeed, though that is a very weak checksum (file size plus 16 bit TCP/IP
> checksum of file).  Also it is allowed to be 0 to indicate no checksum
> (even if you set the checksum, it might be cleared if an Administrator
> adds his own countersignature to all authorized programs on his
> computers, aka AppLocker).
>> 3. spcPEImageData is probably relevant only for signing that uses page 
>> hashes?
> I never quite figured out where they store the page hashes. However I
> believe the constant semi-empty spcPEImageData with the "<<>>"
> string is the traditional marker to indicate that the signature is for
> a PE file, and not e.g. a document file with the same hashed bytestream.
> 
>> 4. PKCS7_verify is already matching the encryptedDigest, do we still need to 
>> validate it ourselves?
> If it is, I am myself guessing a bit as to what that function does and
> does not check.  But note that it probably doesn't check the full chain
> of 3 message digests, since at least the digest over the file itself is
> inside a blob that the PKCS#7 standard has no opinion about.
>> 5. So, basically are are suggesting to look into the subject string and see 
>> if we can find patterns like /CN=COMPANY-NAME... issuer: 
>> /C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone else 
>> have same COMPANY-NAME and PATTERN-NAME in their certificate?
> Actually, the subject is a data structure (a hierarchical list of sets
> of tagged strings) and the relevant comparison would be to compare those
> elements that don't change when getting a new certificate from the CA.
> It is the CAs responsibility to make sure the don't issue certificates
> to the wrong people, and if they make a mistake they are expected to
> quickly add the bad certificate to their published CRL, which is why
> you need to check the CRL before trusting the certificate.  An
> additional check is to make sure the CA that issued the intermediary
> certificate that issued the "COMAPNY-NAME" certificate is actually one
> of the (few) CAs that "COMPANY-NAME" is going to buy certificates from.
>  This protects against fake certificates issued by smaller CAs that
> you aren't going to use anyway.
>> 
>> In my case, I am the one who is signing the executable using my certificate 
>> and a "cross certificate" issued by Microsoft and I want to programmatically 
>> ensure following things.
>> 
>> 1. Code is not tampered since it was signed (matching messageDigest with 
>> computed hash)
> Actually matching digest in spcIndirectData with computed hash. Plus
> consistency checks to make sure the signature is actually for a PE file
> and was not otherwise doctored.  For instance there should be no bytes
> in the file after the end of the signature blob.
>> 2. Verifying the digital signature (PKCS7_Verify)
>> 3. Confirming that the executable is signed by my company certificate.
>> 
>> I am stuck on part (3) and don't see a clean way apart from matching strings 
>> in subject field?  If I hard-code the public key in my verification code, I 
>> will need to update it when I switch to a newer public key?
> Yep, that is why careful matching against various Distinguished Name
> fields is needed.
> 
>> 
>>> On Sep 06, 2014, at 09:44 PM, Prasad Dabak  wrote:
>>> 
>>> Hello,
>>> 
>>> Given a signed Windows portable executable, I want to programmatically 
>>> verify two things using openssl APIs
>>> 
>>> 1. Verify the digital signature.
>>> 2. Confirm that the executable is signed by a specific company using that 
>>> company's public key.
>>> 
>>> It seems that part (1) can be done by parsing the sign

RE: Value of DEFAULT cipher suite

[Salz, Rich]

> You really should look at the extensive research done by SSL Labsbefore
> blindly deprecating stuff.

Sorry you think I'm doing that.  I'm raising an issue six months before it will 
affect people.

--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Value of DEFAULT cipher suite

[Jakob Bohm]

On 09/09/2014 19:20, Salz, Rich wrote:

In addition to removing the very-weak (less than 70 bits security) ciphers
from the default list,this would be a good opportunity to reorder the default

I'd prefer to wait until TLS 1.3 is implemented, which has some definite (and 
rather strong :) feelings on the subject.  Doing things like putting PFS first 
would greatly increase the computation load on servers and doesn't seem like 
the right thing to do as a quiet change.  (But yes, moving RC4 down to LOW does 
seem to me like the right thing to do. :)

You conveniently snipped the part of my post which explained why RC4 is
currently the*strongest* available cipher when talking to some clients,
being (in those situations)effectively stronger than AES-256 CBC, despite
its known weaknesses.

To protect from the known RC4 repeated-plaintext vulnerability, one might
consider adding rate limiting to some SSL/TLS protocol steps whenever RC4 is
actually used.

The TLS WG looked at adding arbitrary padding as a record type.  I hope it 
comes back.  Maybe the fact that the next TLS WG interim meeting will be at 
INRIA, home of the triple-handshake attack and the padding proposal, will have 
some effect :)

That arbitrary padding (or any other future TLS feature) will do nothing
to mitigate the problem that interoperating with some widely deployed real
world clients leaves the choice between CBC with no mitigation and RC4 with
limitedkey lifespan (e.g. max 2**?? bytes encrypted with any given key).

You really should look at the extensive research done by SSL Labsbefore
blindly deprecating stuff.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Certificate pass phrase brute force...

[Michael Wojcik]

Sure, if that's a better fit to your threat model. (I certainly wouldn't 
recommend changing "openssl req" to make -nodes the default.) I was just 
suggesting possibilities for Gregory.

Personally, I'd probably go with generating an encrypted private key with 
"openssl genpkey" first, but that might be more changes to the EasyRSA script 
than he's inclined to make. He has a working solution now which seems fine for 
his purposes.

A cipher option for "openssl req -newkey" wouldn't be a bad idea, but it's not 
a high priority, so I wouldn't expect it to happen anytime soon unless someone 
wants to submit a patch.

Michael Wojcik
Technology Specialist, Micro Focus


From: Kyle Hamilton [mailto:aerow...@gmail.com]
Sent: Tuesday, 09 September, 2014 13:43
To: openssl-users@openssl.org; Michael Wojcik
Subject: RE: Certificate pass phrase brute force...

At least 3DES is *some* encryption. The issue is that peoples' computers are 
usually infested with malware; it's better to assume (for a software 
distribution) that the disk is compromised, and always encrypt it before 
writing.

Perhaps there should be a cipher option for the req -newkey option?

-Kyle H
On September 9, 2014 8:58:08 AM PST, Michael Wojcik 
 wrote:
As far as I know, openssl req doesn't let you specify the encryption cipher for 
the private key.


You can generate the key file first, with openssl genpkey, which does let you 
specify the encryption cipher; and then use -key to tell openssl to use your 
existing key rather than creating a new one.


You can also do what you describe below, but not encrypt the private key the 
first time, by using the -nodes option with openssl req; that saves decrypting 
it before encrypting it with your preferred cipher.




Michael Wojcik
Technology Specialist, Micro Focus




From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Gregory Sloop
Sent: Tuesday, 09 September, 2014 01:19
To: openssl-users@openssl.org
Subject: Re: Certificate pass phrase brute force...


I used the asn1parse command [thanks Dave!] and while the key looks "old style" 
it parses as follows:

50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc

Which appears to equate to: des-ede3-cbc   Three key triple DES EDE in CBC 
mode

The full asn parse is:
---
 0:d=0  hl=4 l=2446 cons: SEQUENCE
   4:d=1  hl=2 l=  64 cons: SEQUENCE
   6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
  17:d=2  hl=2 l=  51 cons: SEQUENCE
  19:d=3  hl=2 l=  27 cons: SEQUENCE
  21:d=4  hl=2 l=   9 prim: OBJECT:PBKDF2
  32:d=4  hl=2 l=  14 cons: SEQUENCE
  34:d=5  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA 
(REDACTED)
  44:d=5  hl=2 l=   2 prim: INTEGER   :0800
  48:d=3  hl=2 l=  20 cons: SEQUENCE
  50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc
  60:d=4  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA 
(REDACTED)
---
[I don't know if I needed to redact those fields at all, but I don't think it 
matters.)

So, if I've read that properly, the encryption method is 3DES.

---
While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA 
script from OpenVPN - I thought I'd share a solution that appears to work and 
do what I want.

It doesn't appear easy to modify the EasyRSA script to use aes-256 [or any non 
3DES cypher] in the script. From my look at the syntax of a "openssl req -new 
-newkey ..." command, you don't get to specify the cypher it will use in 
encrypting the private key. This appears to be a result of generating both the 
key and the signing request in a single step - in this case you don't appear to 
get to choose what crypto is used to encrypt the private key. [I'd be glad to 
be shown a way you can specify it - it doesn't appear possible from the 
command-line options at least.]

However, as I pointed out there is code in the EasyRSA tool to re-encrypt the 
private key with a new password, or remove the password.
You can edit the script to use aes256 as follows: [or any of the other cyphers 
here: 
https://www.openssl.org/docs/apps/rsa.html#]
In the easyrsa bash script:
Look for the line: [ local crypto="-des3" ] (It's line 861 in the current 
EasyRSA version)
Change it to: [ local crypto="-aes256" ]

Now when you issue the command easyrsa set-rsa-pass, and issue the "old" 
encryption key, along with a new one [you can certainly use the same key for 
the old and "new"] it will re-encrypt it with aes-256.

Looking at the key file it does appear to indeed work and re-encrypts it with 
AES-256.

#cat somekey.key
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC ...

---
Thus, this is the best work-around for the tool I can find. Unfortunately it 
requires a "redundant" step unless someone can show me a way to put the 
encryption type for private keys in a config file or specify it as part of a 
"openssl -req ..." command

But at least it works the way I

RE: Certificate pass phrase brute force...

[Kyle Hamilton]

At least 3DES is *some* encryption. The issue is that peoples' computers are 
usually infested with malware; it's better to assume (for a software 
distribution) that the disk is compromised, and always encrypt it before 
writing.

Perhaps there should be a cipher option for the req -newkey option?

-Kyle H

On September 9, 2014 8:58:08 AM PST, Michael Wojcik 
 wrote:
>As far as I know, openssl req doesn't let you specify the encryption
>cipher for the private key.
>
>You can generate the key file first, with openssl genpkey, which does
>let you specify the encryption cipher; and then use -key to tell
>openssl to use your existing key rather than creating a new one.
>
>You can also do what you describe below, but not encrypt the private
>key the first time, by using the -nodes option with openssl req; that
>saves decrypting it before encrypting it with your preferred cipher.
>
>
>Michael Wojcik
>Technology Specialist, Micro Focus
>
>
>From: owner-openssl-us...@openssl.org
>[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop
>Sent: Tuesday, 09 September, 2014 01:19
>To: openssl-users@openssl.org
>Subject: Re: Certificate pass phrase brute force...
>
>I used the asn1parse command [thanks Dave!] and while the key looks
>"old style" it parses as follows:
>
>50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc
>
>Which appears to equate to: des-ede3-cbc   Three key triple DES EDE
>in CBC mode
>
>The full asn parse is:
>---
> 0:d=0  hl=4 l=2446 cons: SEQUENCE
>   4:d=1  hl=2 l=  64 cons: SEQUENCE
>   6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
>  17:d=2  hl=2 l=  51 cons: SEQUENCE
>  19:d=3  hl=2 l=  27 cons: SEQUENCE
>  21:d=4  hl=2 l=   9 prim: OBJECT:PBKDF2
>  32:d=4  hl=2 l=  14 cons: SEQUENCE
>34:d=5  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA
>(REDACTED)
>  44:d=5  hl=2 l=   2 prim: INTEGER   :0800
>  48:d=3  hl=2 l=  20 cons: SEQUENCE
>  50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc
>60:d=4  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA
>(REDACTED)
>---
>[I don't know if I needed to redact those fields at all, but I don't
>think it matters.)
>
>So, if I've read that properly, the encryption method is 3DES.
>
>---
>While this isn't really relevant to OpenSSL, and more relevant to the
>EasyRSA script from OpenVPN - I thought I'd share a solution that
>appears to work and do what I want.
>
>It doesn't appear easy to modify the EasyRSA script to use aes-256 [or
>any non 3DES cypher] in the script. From my look at the syntax of a
>"openssl req -new -newkey ..." command, you don't get to specify the
>cypher it will use in encrypting the private key. This appears to be a
>result of generating both the key and the signing request in a single
>step - in this case you don't appear to get to choose what crypto is
>used to encrypt the private key. [I'd be glad to be shown a way you can
>specify it - it doesn't appear possible from the command-line options
>at least.]
>
>However, as I pointed out there is code in the EasyRSA tool to
>re-encrypt the private key with a new password, or remove the password.
>You can edit the script to use aes256 as follows: [or any of the other
>cyphers here:
>https://www.openssl.org/docs/apps/rsa.html#]
>In the easyrsa bash script:
>Look for the line: [ local crypto="-des3" ] (It's line 861 in the
>current EasyRSA version)
>Change it to: [ local crypto="-aes256" ]
>
>Now when you issue the command easyrsa set-rsa-pass, and issue the
>"old" encryption key, along with a new one [you can certainly use the
>same key for the old and "new"] it will re-encrypt it with aes-256.
>
>Looking at the key file it does appear to indeed work and re-encrypts
>it with AES-256.
>
>#cat somekey.key
>-BEGIN RSA PRIVATE KEY-
>Proc-Type: 4,ENCRYPTED
>DEK-Info: AES-256-CBC ...
>
>---
>Thus, this is the best work-around for the tool I can find.
>Unfortunately it requires a "redundant" step unless someone can show me
>a way to put the encryption type for private keys in a config file or
>specify it as part of a "openssl -req ..." command
>
>But at least it works the way I want it to, and makes the task of
>setting up keys and certs a bit easier than raw openssl commands.
>
>Hope that helps someone else too. And thanks again for all the pointers
>and tips!
>
>[Ya'll are probably going to chuckle and say "If you'd just dumped that
>lousy 'playskool' EasyRSA tool and run openssl like a real man, you'd
>have avoided all this hoopla in the first place!" And yeah, you're
>probably right - but I trust a good script to do it right more often
>than I trust myself - but perhaps that trust is misplaced in this
>case.]
>
>Again, glad for any follow-up advice - it's been an interesting thread
>- at least for me.
>
>-Greg
>
>
>For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY)
>just look on the DEK-Info: header line.
>
>For PKCS#8 format (dashes-BEGIN EN

Re: Value of DEFAULT cipher suite

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 07:04:36PM +0200, Jakob Bohm wrote:

> In addition to removing the very-weak (less than 70 bits security)
> ciphers from the default list,this would be a good opportunity to
> reorder the default list (either via the define, or bettervia whatever
> internal priorities guide the interpretation of a similar user-provided
> list), tomaximize security, similar to what is checked e.g. by the
> online "ssllabs" checker.
> 
> Basically: Prefer PFS suites to non-PFS suites (i.e. prefer EDH/ECDH to
> bare RSA) at each nominalsecurity level (256 bits, 192 bits, 128 bits,
> ...)

This is already the case starting 1.0.0.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: On 2K keys and SHA-256

[Jakob Bohm]

On 09/09/2014 14:18, Salz, Rich wrote:

May I suggest 4096 bit with SHA-256.

I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see 
much deployment because of the computational cost.  At least, that's how we see 
things at my employer.

There was (some years ago) a heated debate between Certicom/NSA and
the rest of the crypto community regarding the RSA sizes needed to
match a given symmetric key security level.  I don't know if it was
ever resolved, but I guess some are going to use the old Certicom
list to choose their RSA key sizes.

Another, related problem is the large amount of patent FUD (and
maybe real issues too) regarding the ECC patent situation, causing
many applications to only use traditional RSA, DSA and DH, rather
than their ECC counterparts.  Until this problem is truly resolved
for everybody (not just the OpenSSL project and the US Government),
supporting even painfully slow RSA, DSA and DH key lengths is a
practical necessity.  Note that the only public guidance I have
found on this was written by the NSA, which affects it credibility
in the current international political climate.

One problem which I recently encountered when using stunnel for a
dedicated long running session is that OpenSSL 1.0.1 apparently
rejects large client keys with "SSL_accept: 1408E098: error:
1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size",
which forced me to downgrade from 6K RSA to 4K RSA for the client
auth.  But this was for a dedicated link where the CPU overhead
was acceptable.


And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you
to create Low (512), Medium (1024) or High (2048) grade encryption keys
(patch available for ages BTW) ...

If you can point me to patches, email, or whatever I can try to make sure those 
links get seen by folks in charge.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

RE: Value of DEFAULT cipher suite

[Salz, Rich]

> In addition to removing the very-weak (less than 70 bits security) ciphers
> from the default list,this would be a good opportunity to reorder the default

I'd prefer to wait until TLS 1.3 is implemented, which has some definite (and 
rather strong :) feelings on the subject.  Doing things like putting PFS first 
would greatly increase the computation load on servers and doesn't seem like 
the right thing to do as a quiet change.  (But yes, moving RC4 down to LOW does 
seem to me like the right thing to do. :)

> To protect from the known RC4 repeated-plaintext vulnerability, one might
> consider adding rate limiting to some SSL/TLS protocol steps whenever RC4 is
> actually used.

The TLS WG looked at adding arbitrary padding as a record type.  I hope it 
comes back.  Maybe the fact that the next TLS WG interim meeting will be at 
INRIA, home of the triple-handshake attack and the padding proposal, will have 
some effect :)

--  
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: cannot read PEM key file - no start line

[Liz Fall]

Hi Jeff,



Please find  the certificates attached.



openssl x509 -in DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pembackup 
-inform PEM -text -noout

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1085434364 (0x40b269fc)

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=US, O=Wells Fargo, OU=Wells Fargo Certification Authority, 
CN=Wells Fargo Root Certificate Authority

Validity

Not Before: May 28 18:17:26 2009 GMT

Not After : May 28 18:17:26 2019 GMT

Subject: C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities, 
CN=Wells Fargo Enterprise CA 02

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:9b:59:84:56:05:e5:1c:76:dd:e0:3a:ca:14:84:

4e:4d:fe:90:e4:9c:33:24:4b:63:16:25:8d:e2:54:

2c:12:f2:9e:54:dd:69:ef:fb:9a:d7:a7:34:80:58:

62:cd:0b:ee:0f:4d:36:a6:db:54:1b:b4:e7:ea:e5:

28:9d:46:31:25:a8:c3:d9:39:f2:90:04:2e:d6:6e:

4a:b3:58:22:b0:d8:18:08:6c:c7:f2:d9:6e:29:e5:

98:00:da:69:49:1b:79:17:52:2c:dd:8b:6c:34:e1:

a2:62:d5:45:9d:97:f7:15:e8:ce:cd:55:a4:86:74:

f9:ad:85:e3:4d:ff:4e:b2:ee:4a:2b:52:61:ec:dc:

b0:6c:55:39:3f:6c:ad:0b:88:7f:33:dc:67:94:7b:

82:8f:2e:d1:06:63:7d:e7:a8:86:ec:46:fe:04:1a:

ef:a3:b6:5f:4d:fc:d6:b8:5c:e6:bd:f8:9c:2a:8b:

e8:0d:b6:4e:96:82:c7:1e:c4:73:8f:68:90:d9:eb:

98:fb:15:bf:83:e6:67:d6:51:cf:40:26:5f:4d:d2:

e0:3d:47:27:57:ba:a9:3f:ed:5f:45:5c:b9:84:d2:

d0:4f:0d:e7:06:b3:5a:e5:12:c8:64:af:11:06:96:

3a:92:28:38:c1:68:72:34:a3:fe:f5:2b:1c:da:6d:

f8:95

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints: critical

CA:TRUE

X509v3 Certificate Policies:

Policy: 2.16.840.1.114171.500.0.0

  CPS: http://www.wellsfargo.com/cps/

Policy: 2.16.840.1.114171.500.0.1

  CPS: http://www.wellsfargo.com/cps/



Authority Information Access:

OCSP - URI:http://ocsp-root.pki.wellsfargo.com/

CA Issuers - URI:http://crl.pki.wellsfargo.com/wf_root.crt



X509v3 Key Usage: critical

Digital Signature, Non Repudiation, Key Encipherment, Data 
Encipherment, Certificate Sign, CRL Sign

X509v3 Authority Key Identifier:


keyid:14:AF:18:F7:BD:E6:E7:6B:E3:5A:FA:EA:51:EF:FE:D4:5A:71:39:C0

DirName:/C=US/O=Wells Fargo/OU=Wells Fargo Certification 
Authority/CN=Wells Fargo Root Certificate Authority

serial:39:E4:97:9E



X509v3 CRL Distribution Points:



Full Name:

  URI:http://crl.pki.wellsfargo.com/root.crl



X509v3 Subject Key Identifier:

C4:AB:45:B6:3A:0B:01:1C:62:5C:CA:3F:C7:E3:CD:2F:30:C4:57:D7

Signature Algorithm: sha1WithRSAEncryption

 2d:42:30:eb:21:4d:8f:b9:ab:4d:22:2e:aa:d4:fa:ae:c0:17:

 80:a0:29:ca:52:37:1e:d7:a9:6d:66:ba:ab:11:26:98:30:e3:

 08:06:8e:c5:76:4a:4a:14:f1:05:06:ba:a9:2a:58:16:0d:0a:

 17:1a:8a:b0:d8:a8:b7:c0:80:10:cc:57:71:aa:6b:e4:e2:f0:

 ca:d4:c5:be:70:d2:45:af:47:fa:69:4b:4f:a8:e9:66:2f:02:

 dd:f6:ea:12:f6:d5:7a:1e:cd:8d:3e:28:8f:c7:cd:6e:c7:f5:

 dd:48:0d:d3:1c:65:82:27:b3:e3:b9:68:71:65:40:0d:d6:0f:

 fd:1b:9c:1b:7d:68:fb:c3:aa:25:a6:7f:f8:05:ac:73:e0:7a:

 2e:84:3d:8d:a6:25:61:a8:97:5c:44:50:a2:92:d2:f1:dc:53:

 78:6a:7c:a6:f9:9d:60:ae:20:84:71:bf:03:02:d6:d1:f1:1c:

 6a:a4:0e:aa:b0:5c:7f:c0:3e:df:f4:50:60:47:49:eb:6b:d9:

 f1:0f:53:e8:7c:1b:74:fa:f4:cd:3a:2a:79:53:39:8b:e0:e0:

 2e:3c:b6:7e:ad:5e:12:9e:9a:e4:89:f4:37:bf:2d:92:01:2b:

 f0:d3:e5:a4:f8:1b:f7:70:ba:4f:c9:0d:62:2a:10:63:6d:1d:

 36:49:6a:2d



This is the C++ MongoDB API I am using to connect to the database:



#include "mongo/util/net/ssl_options.h"

#include "mongo/client/init.h"



int main() {

sslGlobalParams.sslMode.store(SSLGlobalParams::SSLMode_requireSSL);



// only really need a PEM on the server side

mongo::sslGlobalParams.sslPEMKeyFile = "";



mongo::Status status = mongo::client::initialize();



if (!status.isOK())

::abort();



DBClientConnection c;

c.connect("hostname.whatever.com"); // outgoing connections are SSL

}



My question to MongoDB support was:  From the code above, the comment states 
that there is only a need of a PEM on the server side. What identifies the "key 
store" on the C++ client server? Is as key sto

RE: Why does OpenSSL own all the prefixes in the world?

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Iñaki Baz Castillo
> Sent: Tuesday, 09 September, 2014 12:44
> To: openssl-users@openssl.org
> Subject: Re: Why does OpenSSL own all the prefixes in the world?
> 
> May be I was not clear, but what I mean is:
> 
> 
> - Let's suppose openssl/foo.h has a #include .
> 
> - In myproject.h I add:
> 
>   namespace myproject {
>   #include 
>   }
> 
> - And then in myproject.cpp I write:
> 
>   p = (char*)malloc(sizeof(char) * 100);
> 
> 
> Would this produce the "malloc not found, may be you mean
> 'myproject::malloc'?" error?
> 
> PS: Note that I do NOT include  in myproject.*.

Yes, in this case I'd expect that error. You need to include stdlib.h outside 
of any namespace before you include openssl/foo.h.

My advice would be to stick a bunch of include statements for all the standard 
headers used by any openssl/*.h into a single .h file, and then include that at 
the top of myproject.h and any other C++ header file that includes an OpenSSL 
header.

So:

- Create openssl_c_hdrs.h which has:

#include 
#include 
#include 
...

- Change myproject.h to have:

#include "openssl_c_hdrs.h"
namespace myproject {
#include 
}

Again, I can't say for sure that will work, because I haven't tested it. But it 
ought to work around this particular issue. The standard headers included by 
openssl_c_hdrs.h will preempt their inclusion within the namespace by the 
OpenSSL headers.

Of course, for C++ code you normally wouldn't include the C standard headers; 
you'd use their C++ versions (, etc). But this sort of thing is a 
special case.

-- 
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com

Re: Value of DEFAULT cipher suite

[Jakob Bohm]

On 09/09/2014 00:42, Salz, Rich wrote:

We are considering removing weak cryptography from the value of DEFAULT.  That is, append 
":!LOW:!EXPORT"

It is currently defined as this in include/openssl/ssl.h:
#define SSL_DEFAULT_CIPHER_LIST   "ALL:!aNULL:!eNULL:!SSLv2"

Please let us know if you have strong objections to this.


In addition to removing the very-weak (less than 70 bits security)
ciphers from the default list,this would be a good opportunity to
reorder the default list (either via the define, or bettervia whatever
internal priorities guide the interpretation of a similar user-provided
list), tomaximize security, similar to what is checked e.g. by the
online "ssllabs" checker.

Basically: Prefer PFS suites to non-PFS suites (i.e. prefer EDH/ECDH to
bare RSA) at each nominalsecurity level (256 bits, 192 bits, 128 bits,
...), also enable 0/n splitting (and/or prefer a stream cipher)for CBC
encryption with older TLS protocol versions whenever the send timing
makes them otherwise subject to BEAST.

The latter is, by the way, the reason many systems have *recently* been
configured to explicitly prefer RC4 as the only unbroken cipher
compatible with servers or clients that don't protect against BEAST in
other ways.

To protect from the known RC4 repeated-plaintext vulnerability, one
might consider adding rate limiting to some SSL/TLS protocol steps
whenever RC4 is actually used.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Salz, Rich]

> Folks who want strong BCP crypto, can disable MEDIUM.

Folks who want weak non-BCP crypto can enable LOW.

I'm putting this on hold to see where we are 6-9 months from now.

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: On 2K keys and SHA-256

[Jeroen de Neef]

No, I do not have numbers to back it up, that is why my guess is that
3K-RSA is the next step after 2K-RSA.
It also depends on what data you are planning to transport, and in what
kind of organisation you are.

2014-09-09 18:21 GMT+02:00 Viktor Dukhovni :

> On Tue, Sep 09, 2014 at 05:54:15PM +0200, Jeroen de Neef wrote:
>
> > I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the
> > computational costs of a 4K-RSA certificate is much of an obstruction
> with
> > current hardware and I think that it isn't a problem at all a couple
> years
> > in the future.
>
> Have any numbers to back that up?  The performance ratios are likely
> similar for recent and not so recent CPUs:
>
>   signverifysign/s verify/s
> rsa 1024 bits 0.000385s 0.25s   2599.2  40210.7
> rsa 2048 bits 0.002494s 0.78s401.0  12762.7
> rsa 4096 bits 0.017500s 0.000284s 57.1   3527.3
>
> On my CPU the sign/s ratios for the two steps are 6.5 and 7.0,
> which are quite significant.  The performance gulf between 1024
> and 4096 is rather wide, while the security gain from 2048 to 4096
> is far from clear.
>
> --
> Viktor.
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: Value of DEFAULT cipher suite

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 06:29:51PM +0200, Jeroen de Neef wrote:

> I can see RC4 going in the list of low security ciphers within a couple of
> years anyways, so we can better discourage the usage right now.

Note that RC4 is essentially the only widely used MEDIUM cipher,
and is by default last on that list.  There is little reason at
present to demote it to LOW.  Folks who want strong BCP crypto,
can disable MEDIUM.

$ openssl ciphers -v 'MEDIUM:!aNULL:@STRENGTH'
DHE-RSA-SEED-SHASSLv3 Kx=DH   Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHASSLv3 Kx=DH   Au=DSS  Enc=SEED(128) Mac=SHA1
SEED-SHASSLv3 Kx=RSA  Au=RSA  Enc=SEED(128) Mac=SHA1
IDEA-CBC-SHASSLv3 Kx=RSA  Au=RSA  Enc=IDEA(128) Mac=SHA1
IDEA-CBC-MD5SSLv2 Kx=RSA  Au=RSA  Enc=IDEA(128) Mac=MD5
RC2-CBC-MD5 SSLv2 Kx=RSA  Au=RSA  Enc=RC2(128)  Mac=MD5
ECDHE-RSA-RC4-SHA   SSLv3 Kx=ECDH Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA  SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5 SSLv3 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=MD5
RC4-MD5 SSLv2 Kx=RSA  Au=RSA  Enc=RC4(128)  Mac=MD5
PSK-RC4-SHA SSLv3 Kx=PSK  Au=PSK  Enc=RC4(128)  Mac=SHA1

Once RC4 use is negligible (my guess is in ~5 years), then OpenSSL
can demote it in the library, rather than leave the choice to
applications.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

2014-09-09 17:58 GMT+02:00 Michael Wojcik :
>> I did that, but if a openssl header file includes standard C headers
>> that I don't include, then the namespace declaration would affect them
>> too, am I wrong?
>
> It shouldn't. The C standard says that the second and subsequent inclusion of 
> a standard header has no effect, and I believe the current C++ standard 
> inherits that rule.
>
> All the implementations I know of (with maybe some special exceptions like 
> Splint) implement that with "inclusion guards" - conditional-compilation 
> directives around all the contents of the file.
>
> So if a standard header is included once outside any namespace, then if it's 
> included again inside a namespace, it shouldn't declare anything in that 
> namespace, because all its contents should be skipped. I believe namespaces 
> don't affect macro identifiers, so the guards should work.
>
> I could be wrong about that, though. I haven't tried it myself, and I don't 
> know the C++ standard nearly as well as the C one.


May be I was not clear, but what I mean is:


- Let's suppose openssl/foo.h has a #include .

- In myproject.h I add:

  namespace myproject {
  #include 
  }

- And then in myproject.cpp I write:

  p = (char*)malloc(sizeof(char) * 100);


Would this produce the "malloc not found, may be you mean
'myproject::malloc'?" error?

PS: Note that I do NOT include  in myproject.*.



-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Value of DEFAULT cipher suite

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 12:14:36PM -0400, Salz, Rich wrote:

> We disagree.  I've got two IETF WG's coming to the same conclusion
> so making post-1.0.2 follow IETF practices seems pretty inarguable.
> 
> > The IETF is sadly also prone to knee-jerk reactions.
> 
> True.  Some would put perpass in that category.

Which is why I cautioned against overly hasty counter-measures.

I don't disagree that applications and operators should generally
disable RC4.  Howerver, OpenSSL is not the right place to do so.
In opportunistic TLS, disabling RC4 is often worse than leaving it
enabled.

The library should provide a sensible default preference order,
and a sensible choice of DEFAULT cipher suites, these can be updated
from time to time.  Dropping cipher suites nobody is using is fine.
Dropping cipher suites that are in wide use, and making the choice
in code below the application layer is I think unwise.

We could introduce a new cipher suite class name "BCP", to complement
"DEFAULT".  The latter is broadly interoperable with sensible
ordering but inclusive cipher choices, the former would be more
restrictive, offering only the BCP cipher suites, sensibly ordered.

Applications that want "BCP", could have it.  Applications that
emphasize interoperability would use "DEFAULT".  Then you would
be free to tweak "BCP" more aggressively than "DEFAULT".

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Verifying authenticode signature using openssl API

[Jakob Bohm]

On 09/09/2014 09:01, Prasad Dabak wrote:
Thanks Jacob for an elaborate answer. Somehow I never received your 
response to my registered email address, hence delay in responding.



This time I have CC-ed you in addition to the mail list.

I have a few follow-up questions on your response.

1. So, "encryptedDigest"  has no relation to the stored 
"messageDigest"? I thought it's a encrypted version of the messageDigest?

As far as I recall, there is a chain of 4 digests.  The first digest
is calculated over the file and is stored in the spcIndirectData. The
second digest is calculated over the spcIndirectData (the contentInfo
of the the PKCS#7 structure) and is stored as "messageDigest" in the
AuthenticatedAttributes of each PKCS#7 signerInfo.  The third hash
is calculated over the AuthenticatedAttributes and is signed to
produce the "encryptedDigest" in that same signerInfo.  All 3 need to
be checked to confirm that the file hash is actually (indirectly)
signed by the encryptedDigest using the public key in the certificate
whose name is listed in the signerInfo.
2. I agree that it's better to do cheaper checks first e.g. I am also 
matching PE checksum stored in the optional header.

Indeed, though that is a very weak checksum (file size plus 16 bit TCP/IP
checksum of file).  Also it is allowed to be 0 to indicate no checksum
(even if you set the checksum, it might be cleared if an Administrator
adds his own countersignature to all authorized programs on his
computers, aka AppLocker).
3. spcPEImageData is probably relevant only for signing that uses page 
hashes?

I never quite figured out where they store the page hashes. However I
believe the constant semi-empty spcPEImageData with the "<<>>"
string is the traditional marker to indicate that the signature is for
a PE file, and not e.g. a document file with the same hashed bytestream.

4. PKCS7_verify is already matching the encryptedDigest, do we still 
need to validate it ourselves?

If it is, I am myself guessing a bit as to what that function does and
does not check.  But note that it probably doesn't check the full chain
of 3 message digests, since at least the digest over the file itself is
inside a blob that the PKCS#7 standard has no opinion about.
5. So, basically are are suggesting to look into the subject string 
and see if we can find patterns like /CN=COMPANY-NAME... issuer: 
/C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone 
else have same COMPANY-NAME and PATTERN-NAME in their certificate?

Actually, the subject is a data structure (a hierarchical list of sets
of tagged strings) and the relevant comparison would be to compare those
elements that don't change when getting a new certificate from the CA.
It is the CAs responsibility to make sure the don't issue certificates
to the wrong people, and if they make a mistake they are expected to
quickly add the bad certificate to their published CRL, which is why
you need to check the CRL before trusting the certificate.  An
additional check is to make sure the CA that issued the intermediary
certificate that issued the "COMAPNY-NAME" certificate is actually one
of the (few) CAs that "COMPANY-NAME" is going to buy certificates from.
  This protects against fake certificates issued by smaller CAs that
you aren't going to use anyway.


In my case, I am the one who is signing the executable using my 
certificate and a "cross certificate" issued by Microsoft and I want 
to programmatically ensure following things.


1. Code is not tampered since it was signed (matching messageDigest 
with computed hash)

Actually matching digest in spcIndirectData with computed hash. Plus
consistency checks to make sure the signature is actually for a PE file
and was not otherwise doctored.  For instance there should be no bytes
in the file after the end of the signature blob.

2. Verifying the digital signature (PKCS7_Verify)
3. Confirming that the executable is signed by my company certificate.

I am stuck on part (3) and don't see a clean way apart from matching 
strings in subject field?  If I hard-code the public key in my 
verification code, I will need to update it when I switch to a newer 
public key?



Yep, that is why careful matching against various Distinguished Name
fields is needed.



On Sep 06, 2014, at 09:44 PM, Prasad Dabak  wrote:


Hello,

Given a signed Windows portable executable, I want to 
programmatically verify two things using openssl APIs


1. Verify the digital signature.
2. Confirm that the executable is signed by a specific company using 
that company's public key.


It seems that part (1) can be done by parsing the signedData 
attribute in the portable executable, extracting the hashing 
algorithm and digest stored there, re-computing the digest of the 
executable using the same hashing algorithm and match them.


I have following questions.

1. The signData contains messageDigest (unencrypted) and 
encryptedDigest (encrypted). Is it enough to match messgaeDigest wit

Re: Value of DEFAULT cipher suite

[Jeroen de Neef]

I can see RC4 going in the list of low security ciphers within a couple of
years anyways, so we can better discourage the usage right now.

2014-09-09 18:14 GMT+02:00 Salz, Rich :

> We disagree.  I've got two IETF WG's coming to the same conclusion so
> making post-1.0.2 follow IETF practices seems pretty inarguable.
>
> > The IETF is sadly also prone to knee-jerk reactions.
>
> True.  Some would put perpass in that category.
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: rs...@jabber.me Twitter: RichSalz
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: On 2K keys and SHA-256

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 05:54:15PM +0200, Jeroen de Neef wrote:

> I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the
> computational costs of a 4K-RSA certificate is much of an obstruction with
> current hardware and I think that it isn't a problem at all a couple years
> in the future.

Have any numbers to back that up?  The performance ratios are likely
similar for recent and not so recent CPUs:

  signverifysign/s verify/s
rsa 1024 bits 0.000385s 0.25s   2599.2  40210.7
rsa 2048 bits 0.002494s 0.78s401.0  12762.7
rsa 4096 bits 0.017500s 0.000284s 57.1   3527.3

On my CPU the sign/s ratios for the two steps are 6.5 and 7.0,
which are quite significant.  The performance gulf between 1024
and 4096 is rather wide, while the security gain from 2048 to 4096
is far from clear.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Salz, Rich]

Yes, I'm jumping the gun claiming that the I-D are standards.  They're not.  
They're just drafts.
I'm willing to wait and see what happens for a few months.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Salz, Rich
> Sent: Tuesday, 09 September, 2014 11:35
> To: openssl-users@openssl.org
> Subject: RE: Value of DEFAULT cipher suite
> 
> > Far more productive than disabling RC4 would be ensuring that it is not the
> > preferred cipher suite when better options are enabled.
> 
> I am not disabling RC4.  I am saying that applications that want to use it
> will, after the post-1.0.2 release is adopted, need to take pro-active
> action.

Which is tantamount to disabling it, for any applications that:

- Link OpenSSL dynamically and don't set a non-default cipher suite list
- Are rebuilt with the new OpenSSL but aren't changed to set a non-default 
cipher suite list

You're talking about violating the Principle of Least Surprise, which is rarely 
a good idea.

> This follows the current thinking of the IETF.

Glossing "what's currently in an I-D" as "the current thinking of the IETF" is 
quite a stretch.

And UTA applies to *applications*, not to libraries.

And personally I think UTA is somewhat misguided, particularly in its excessive 
use of RFC 2119 conditional-compliance ("MUST") requirements in sections that 
the text refers to as "recommendations"; and I'm not convinced the authors have 
done a good job of considering the ramifications.

As for the PRC4 I-D: It too applies to applications; and unless OpenSSL is 
going to enforce the final requirement of part 2 ("the TLS server MUST 
terminate the handshake"), I can't see how you can claim your proposed change 
is "following" the I-D. Without that final requirement, the other two are 
potentially more dangerous than allowing RC4.

> It's just being standards-compliant.

Which standard are we talking about? In your other message you cited to I-Ds, 
which are NOT standards.

-- 
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Value of DEFAULT cipher suite

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 11:34:43AM -0400, Salz, Rich wrote:

> > Far more productive than disabling RC4 would be ensuring that it is not the
> > preferred cipher suite when better options are enabled.
> 
> I am not disabling RC4.  I am saying that applications that want
> to use it will, after the post-1.0.2 release is adopted, need to
> take pro-active action.

Declaring "RC4" LOW is not the right answer:

$ openssl ciphers -v 'LOW:@STRENGTH'
EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH   Au=RSA  Enc=DES(56)   Mac=SHA1
EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH   Au=DSS  Enc=DES(56)   Mac=SHA1
ADH-DES-CBC-SHA SSLv3 Kx=DH   Au=None Enc=DES(56)   Mac=SHA1
DES-CBC-SHA SSLv3 Kx=RSA  Au=RSA  Enc=DES(56)   Mac=SHA1
DES-CBC-MD5 SSLv2 Kx=RSA  Au=RSA  Enc=DES(56)   Mac=MD5

I've not seen a TLS connection established with one of these in
the last decade, and single DES is easily brute-forced with
off-the-shelf hardware.

Thus I'm not objecting to disabling by default "EXPORT" and "LOW"
because they at this point no longer used, and obviously much too
weak.

Though RC4 is considerably tarnished, the story is rather different,
since it is still widely used, and the attacks rather specialized.

I agree that applications and system administrators should take
measures to replace RC4 with safer choices whenever possible, but
I don't think that marking RC4 as LOW (many applications that use
RC4 disable LOW ciphers) is a positive development.

In OpenSSL there is no way to enable a cipher suite disabled with
"!blah".  To enable RC4 while not allowing the remaining "LOW"
cipher suites, one would have to replace "!LOW" with the much less
obvious "!DES".

A lot of needless editing of cipherspecs which are error-prone in
the hands of non-experts.  Far better to offer carrots not sticks
in the form of stronger alternatives, that are preferred by default,
and perform as well or better.

> This follows the current thinking of the IETF.

The IETF is sadly also prone to knee-jerk reactions.  For example,
recent discussion of disabling session tickets, where for once
reason prevailed, but some folks are on a crusade to stamp out
crypto too weak for them and damn the unintended consequences.

> It's just being standards-compliant. If you say "security
> levels are a better way to handle this" then why don't security
> levels require RC4?

We can discuss alternative approaches in a separate thread.  Security
levels still need a bit of work.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Salz, Rich]

We disagree.  I've got two IETF WG's coming to the same conclusion so making 
post-1.0.2 follow IETF practices seems pretty inarguable.

> The IETF is sadly also prone to knee-jerk reactions.

True.  Some would put perpass in that category.
--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: On 2K keys and SHA-256

[Jeroen de Neef]

I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the
computational costs of a 4K-RSA certificate is much of an obstruction with
current hardware and I think that it isn't a problem at all a couple years
in the future.

2014-09-09 14:18 GMT+02:00 Salz, Rich :

> > May I suggest 4096 bit with SHA-256.
>
> I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to
> see much deployment because of the computational cost.  At least, that's
> how we see things at my employer.
>
> > And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering
> you
> > to create Low (512), Medium (1024) or High (2048) grade encryption keys
> > (patch available for ages BTW) ...
>
> If you can point me to patches, email, or whatever I can try to make sure
> those links get seen by folks in charge.
>
> /r$
> --
> Principal Security Engineer
> Akamai Technologies, Cambridge MA
> IM: rs...@jabber.me Twitter: RichSalz
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
>

RE: Why does OpenSSL own all the prefixes in the world?

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Iñaki Baz Castillo
> Sent: Tuesday, 09 September, 2014 09:10
> To: openssl-users@openssl.org
> Subject: Re: Why does OpenSSL own all the prefixes in the world?
> 
> 2014-09-09 13:14 GMT+02:00 Michael Wojcik :
> > You'd have to include the standard C headers before including the OpenSSL
> ones, outside the namespace, so that their inclusion by the OpenSSL headers
> has no effect.
> 
> I did that, but if a openssl header file includes standard C headers
> that I don't include, then the namespace declaration would affect them
> too, am I wrong?

It shouldn't. The C standard says that the second and subsequent inclusion of a 
standard header has no effect, and I believe the current C++ standard inherits 
that rule.

All the implementations I know of (with maybe some special exceptions like 
Splint) implement that with "inclusion guards" - conditional-compilation 
directives around all the contents of the file.

So if a standard header is included once outside any namespace, then if it's 
included again inside a namespace, it shouldn't declare anything in that 
namespace, because all its contents should be skipped. I believe namespaces 
don't affect macro identifiers, so the guards should work.

I could be wrong about that, though. I haven't tried it myself, and I don't 
know the C++ standard nearly as well as the C one.

-- 
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com

RE: Certificate pass phrase brute force...

[Michael Wojcik]

As far as I know, openssl req doesn't let you specify the encryption cipher for 
the private key.

You can generate the key file first, with openssl genpkey, which does let you 
specify the encryption cipher; and then use -key to tell openssl to use your 
existing key rather than creating a new one.

You can also do what you describe below, but not encrypt the private key the 
first time, by using the -nodes option with openssl req; that saves decrypting 
it before encrypting it with your preferred cipher.


Michael Wojcik
Technology Specialist, Micro Focus


From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Gregory Sloop
Sent: Tuesday, 09 September, 2014 01:19
To: openssl-users@openssl.org
Subject: Re: Certificate pass phrase brute force...

I used the asn1parse command [thanks Dave!] and while the key looks "old style" 
it parses as follows:

50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc

Which appears to equate to: des-ede3-cbc   Three key triple DES EDE in CBC 
mode

The full asn parse is:
---
 0:d=0  hl=4 l=2446 cons: SEQUENCE
   4:d=1  hl=2 l=  64 cons: SEQUENCE
   6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
  17:d=2  hl=2 l=  51 cons: SEQUENCE
  19:d=3  hl=2 l=  27 cons: SEQUENCE
  21:d=4  hl=2 l=   9 prim: OBJECT:PBKDF2
  32:d=4  hl=2 l=  14 cons: SEQUENCE
  34:d=5  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA 
(REDACTED)
  44:d=5  hl=2 l=   2 prim: INTEGER   :0800
  48:d=3  hl=2 l=  20 cons: SEQUENCE
  50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc
  60:d=4  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA 
(REDACTED)
---
[I don't know if I needed to redact those fields at all, but I don't think it 
matters.)

So, if I've read that properly, the encryption method is 3DES.

---
While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA 
script from OpenVPN - I thought I'd share a solution that appears to work and 
do what I want.

It doesn't appear easy to modify the EasyRSA script to use aes-256 [or any non 
3DES cypher] in the script. From my look at the syntax of a "openssl req -new 
-newkey ..." command, you don't get to specify the cypher it will use in 
encrypting the private key. This appears to be a result of generating both the 
key and the signing request in a single step - in this case you don't appear to 
get to choose what crypto is used to encrypt the private key. [I'd be glad to 
be shown a way you can specify it - it doesn't appear possible from the 
command-line options at least.]

However, as I pointed out there is code in the EasyRSA tool to re-encrypt the 
private key with a new password, or remove the password.
You can edit the script to use aes256 as follows: [or any of the other cyphers 
here: 
https://www.openssl.org/docs/apps/rsa.html#]
In the easyrsa bash script:
Look for the line: [ local crypto="-des3" ] (It's line 861 in the current 
EasyRSA version)
Change it to: [ local crypto="-aes256" ]

Now when you issue the command easyrsa set-rsa-pass, and issue the "old" 
encryption key, along with a new one [you can certainly use the same key for 
the old and "new"] it will re-encrypt it with aes-256.

Looking at the key file it does appear to indeed work and re-encrypts it with 
AES-256.

#cat somekey.key
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC ...

---
Thus, this is the best work-around for the tool I can find. Unfortunately it 
requires a "redundant" step unless someone can show me a way to put the 
encryption type for private keys in a config file or specify it as part of a 
"openssl -req ..." command

But at least it works the way I want it to, and makes the task of setting up 
keys and certs a bit easier than raw openssl commands.

Hope that helps someone else too. And thanks again for all the pointers and 
tips!

[Ya'll are probably going to chuckle and say "If you'd just dumped that lousy 
'playskool' EasyRSA tool and run openssl like a real man, you'd have avoided 
all this hoopla in the first place!" And yeah, you're probably right - but I 
trust a good script to do it right more often than I trust myself - but perhaps 
that trust is misplaced in this case.]

Again, glad for any follow-up advice - it's been an interesting thread - at 
least for me.

-Greg


For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY)
just look on the DEK-Info: header line.

For PKCS#8 format (dashes-BEGIN ENCRYPTED PRIVATE KEY) do
 openssl asn1parse and.


From: owner-openssl-us...@openssl.org 
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop
Sent: Monday, September 08, 2014 20:58

--On that note: Is there a way to determine from an encrypted key-file what 
encryption was used to encrypt it? [I have the password, so it doesn't need to 
be a blind test.]



--
Gregory Sloop, Principal: Sloo

RE: Value of DEFAULT cipher suite

[Salz, Rich]

> Far more productive than disabling RC4 would be ensuring that it is not the
> preferred cipher suite when better options are enabled.

I am not disabling RC4.  I am saying that applications that want to use it 
will, after the post-1.0.2 release is adopted, need to take pro-active action.  
 This follows the current thinking of the IETF. It's just being 
standards-compliant. If you say "security levels are a better way to handle 
this" then why don't security levels require RC4?

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Salz, Rich]

> For what it's worth, I'm with Victor on this. RC4 as cipher of last resort in 
> the
> default set is better than not having it there at all.

Take it up with the IETF which has two working groups advocating against it.  
UTA (use of TLS in applications) and the TLS group itself:

https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02
Implementations MUST NOT negotiate RC4 cipher suites
https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-00 
As a result, RC4 can no longer be seen as providing a sufficient level 
of security for TLS sessions.

"To improve security, raise the ceiling."  An equal number of experienced 
people are equally firm that the only way to raise the standard of practice is 
to remove bad ciphers.

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Value of DEFAULT cipher suite

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 10:40:26AM -0400, Salz, Rich wrote:

> That should probably also be done.  But things like HIGH LOW,
> etc are point-in-time statements and raising the bar so that existing
> applications just get more secure without having to change anything
> is also worth doing.

This is often a misconception.  There are two "bars" that can be
raised.  The "floor" and the "ceiling".

Raising the ceiling (strength of most preferred algorithms) improves
security.  For example implement ChaCha with Poly1305, and prefer
it to RC4.

Raising the floor often breaks interoperability, and leads to people
disabling security or automatically failing over to cleartext, ...

https://www.ietf.org/mail-archive/web/perpass/current/msg00654.html

While there are minor inaccuracies in that post, the core points
stand.

Far more productive than disabling RC4 would be ensuring that it
is not the preferred cipher suite when better options are enabled.

To improve security, raise the ceiling.  ChaCha, new EC curves,
extensions to negotiate DH parameters, ...  Raising the floor can
do more harm than good.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Viktor Dukhovni
> Sent: Tuesday, 09 September, 2014 09:01
> To: openssl-users@openssl.org
> Subject: Re: Value of DEFAULT cipher suite
> 
> On Tue, Sep 09, 2014 at 08:42:36AM -0400, Salz, Rich wrote:
> 
> > > Moving RC4 to "LOW" is also premature.  It is already at the bottom of
> the
> > > medium cipherlist, that should be enough.
> >
> > I am planning on doing it for master, not 1.0.2  That means it
> > won't be in an official release until... what, at least six months.
> 
> Master has "security levels", which still need some work, but are
> a less crude mechanism for such tweaks.  Disabling RC4 at security
> level 2 or some such, is better than incompatibly reclassifying it
> as "LOW".  We can discuss the details later.

For what it's worth, I'm with Victor on this. RC4 as cipher of last resort in 
the default set is better than not having it there at all.

The work factor and conditions for the best attacks on RC4 (around 2**24 
largely-similar plaintexts, unless I've missed more-recent improvements, which 
is certainly possible) are potentially dangerous for some applications - 
particularly HTTPS against server clusters that will handle the load, where a 
client (generally a browser) can be tricked into making the requests (generally 
via malicious scripting). But for other applications it could be much more 
difficult, in practice, to mount the attack.

I think it's fair to say that RC4 is strictly weaker than the other medium 
ciphers (SEED and RC2), since the best published attacks against RC4 are 
definitely considerably more feasible than those against the other two. But as 
Victor said, it's better than plaintext; and it's still very widely used (often 
preferentially), so there's a decent chance that an OpenSSL-based application 
using the default suite list will encounter a peer that only supports RC4.

-- 
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Salz, Rich]

> Master has "security levels", which still need some work, but are a less crude
> mechanism for such tweaks.  Disabling RC4 at security level 2 or some such, is
> better than incompatibly reclassifying it as "LOW".  We can discuss the 
> details
> later.

That should probably also be done.  But things like HIGH LOW, etc are 
point-in-time statements and raising the bar so that existing applications just 
get more secure without having to change anything is also worth doing.


--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Can we have a PyOpenSSL 0.15?

[Kyle Hamilton]

I don't think this is the right place to ask on. This list is for OpenSSL 
itself, not the python binding to it.

The PyOpenSSL folks may be watching this list, but this list is probably not 
the official list to discuss it.

-Kyle H

On September 8, 2014 8:56:35 AM PST, Eric Chazan  
wrote:
>All,
>
>My team is considering a port to Python 3 from Python 2.7.  One issue
>we
>see is that we cant run a flask server with ssl.  I am seeing that the
>fix
>is in this pull request:
>
>https://github.com/pyca/pyopenssl/pull/78/commits
>
>
>Which has already been merged.  Is a new version of PyOpenSSL coming
>that
>contains this pull request?
>
>Thanks,
>Eric Chazan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: cannot read PEM key file - no start line

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 04:42:53AM -0700, Liz Fall wrote:

> Thanks for the info.  I will try what you suggested today.  However, I am a
> bit confused by what you are saying - You may need to separately specify a
> CAfile, or CApath for validating the server certificate.  I have the two pem
> files below.

Most applications that use TLS do not employ client certificates.

In such applications the server typically has a certificate chain
file (containing its certificate and those of issuing CAs ordered
from leaf to optional root) and a private key file (which may be
the same as the chain file, since PEM can store multiple objects
of various types in a single file).

The client typically has no certificate chain file or private key,
rather it needs to be able to verify the server certificate.  Thus
it needs to specify the location (or employ the system default) of
the file or directory holding trusted issuer certificates.

> I thought the
> DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem file resided on the
> MongoDB database server and I was supposed to connect from my C++ app with
> the DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem file.

Or perhaps you're supposed to simply append the intermediate CA
certs in the second to the leaf server certificate in the first,
and employ the result (with a suitable private key) on the server
side.

Only the client side, you'll need just the root CA cert in the
default system location (see docs for c_rehash) or explicitly
loaded by the client as a "CAfile".

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Why does OpenSSL own all the prefixes in the world?

[Iñaki Baz Castillo]

2014-09-09 13:14 GMT+02:00 Michael Wojcik :
> You'd have to include the standard C headers before including the OpenSSL 
> ones, outside the namespace, so that their inclusion by the OpenSSL headers 
> has no effect.

I did that, but if a openssl header file includes standard C headers
that I don't include, then the namespace declaration would affect them
too, am I wrong?


> Mind you, I don't think it's worth the effort, for the reasons I outlined 
> earlier.

Sure, it was just a vague attempt. And indeed, lot of functions in
OpenSSL are given as macros, so namespaces are of little help.

Thanks a lot.


-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OPenssl 20140909 issues

[Viktor Dukhovni]

On Mon, Sep 08, 2014 at 11:41:42PM -0600, The Doctor wrote:

> ls: error initializing month strings

The literal string "month" does not appear in OpenSSL 1.0.2 source
code.  You're probably compiling in a locale not supported by your
system.  "ls -l" is unable to format the date.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Value of DEFAULT cipher suite

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 08:42:36AM -0400, Salz, Rich wrote:

> > Moving RC4 to "LOW" is also premature.  It is already at the bottom of the
> > medium cipherlist, that should be enough.
> 
> I am planning on doing it for master, not 1.0.2  That means it
> won't be in an official release until... what, at least six months.

Master has "security levels", which still need some work, but are
a less crude mechanism for such tweaks.  Disabling RC4 at security
level 2 or some such, is better than incompatibly reclassifying it
as "LOW".  We can discuss the details later.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Salz, Rich]

> Moving RC4 to "LOW" is also premature.  It is already at the bottom of the
> medium cipherlist, that should be enough.

I am planning on doing it for master, not 1.0.2  That means it won't be in an 
official release until... what, at least six months.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OPenssl 20140909 issues

[Mike Bland]

Is the top-level "rehash" target not getting executed? It should be a
dependency of "test" (via the "tests" target).

Mike

On Tue, Sep 9, 2014 at 1:41 AM, The Doctor  wrote:
> Just found this in the latest openssl 1.0.2 snapshot
>
>
> Script started on Mon Sep  8 23:19:16 2014
> doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20140909$ make test
> testing...
> (cd ..; make DIRS=crypto all)
> making all in crypto...
> ar  r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o 
> cpt_err.o ebcdic.o  uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o 
> fips_ers.o mem_clr.o
> test -z "" || ar  r ../libcrypto.a fipscanister.o
> /usr/bin/ranlib ../libcrypto.a || echo Never mind.
> making all in crypto/objects...
> making all in crypto/md2...
> making all in crypto/md4...
> making all in crypto/md5...
> making all in crypto/sha...
> making all in crypto/mdc2...
> making all in crypto/hmac...
> making all in crypto/ripemd...
> making all in crypto/whrlpool...
> making all in crypto/des...
> making all in crypto/aes...
> making all in crypto/rc2...
> making all in crypto/rc4...
> making all in crypto/rc5...
> making all in crypto/idea...
> making all in crypto/bf...
> making all in crypto/cast...
> making all in crypto/camellia...
> making all in crypto/seed...
> making all in crypto/modes...
> making all in crypto/bn...
> making all in crypto/ec...
> making all in crypto/rsa...
> making all in crypto/dsa...
> making all in crypto/ecdsa...
> making all in crypto/dh...
> making all in crypto/ecdh...
> making all in crypto/dso...
> making all in crypto/engine...
> making all in crypto/buffer...
> making all in crypto/bio...
> making all in crypto/stack...
> making all in crypto/lhash...
> making all in crypto/rand...
> making all in crypto/err...
> making all in crypto/evp...
> making all in crypto/asn1...
> making all in crypto/pem...
> making all in crypto/x509...
> making all in crypto/x509v3...
> making all in crypto/conf...
> making all in crypto/txt_db...
> making all in crypto/pkcs7...
> making all in crypto/pkcs12...
> making all in crypto/comp...
> making all in crypto/ocsp...
> making all in crypto/ui...
> making all in crypto/krb5...
> making all in crypto/cms...
> making all in crypto/pqueue...
> making all in crypto/ts...
> making all in crypto/jpake...
> making all in crypto/srp...
> making all in crypto/store...
> making all in crypto/cmac...
> if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make 
> libcrypto.so.1.0.0);  fi
> [ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
> -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 
> -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g 
> -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
> -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  
> -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c 
> fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
> (cd ..; make DIRS=ssl all)
> making all in ssl...
> if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make 
> libssl.so.1.0.0);  fi
> [ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
> -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 
> -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g 
> -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
> -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  
> -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c 
> fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
> ( :;LIBDEPS="${LIBDEPS:-../libssl.a ../libcrypto.a  -lgmp -ldl -lm -lc}"; 
>  LDCMD="${LDCMD:-gcc3}"; LDFLAGS="${LDFLAGS:--fPIC -DOPENSSL_PIC 
> -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT 
> -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer 
> -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
> -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM}";  LIBPATH=`for x 
> in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;  
> LIBPATH=`echo $LIBPATH | sed -e &

Re: Value of DEFAULT cipher suite

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 08:13:40AM -0400, Salz, Rich wrote:

> > Please consider also adding !SSLv3 and !RC4 to this list.
> 
> My plan is to move RC4 and MD5 to LOW; see RT3518.

Moving RC4 to "LOW" is also premature.  It is already at the bottom
of the medium cipherlist, that should be enough.

Opportunistic security is degraded when TLS handshakes fail, and
applications resort to cleartext.  Instead of additional security
such changes often lead to reduced security.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Value of DEFAULT cipher suite

[Viktor Dukhovni]

On Tue, Sep 09, 2014 at 11:02:45AM +0200, Benny Baumann wrote:

> Please consider also adding !SSLv3 and !RC4 to this list.

No.  That would be unwise at this time.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Problem building openssl 1.0.1h on SUSE Linux 9.3 Power PC 64

[Vighnesh Nayak]

Hi,

I am trying to build openssl 1.0.1h (static) library on SUSE Linux 9.3 on 
PowerPC 64 bit arch using GCC version 3.3.3.

I am getting following errors in "app" directory.. Can somebody tell me what is 
going on wrong and how can I fix this? This is my first post, so 
excuse/direct-me to the right forum if I am knocking at the wrong door. I have 
seen the earlier archives but did not come across this.

Configured as  ./Configure no-shared linux-ppc64
==START
ADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall 
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o 
pkeyutl.o pkeyutl.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o spkac.o spkac.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o smime.o smime.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o cms.o cms.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o rand.o rand.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o engine.o engine.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o ocsp.o ocsp.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o prime.o prime.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o ts.o ts.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o srp.o srp.c
gcc -DMONOLITH -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM   -c -o openssl.o openssl.c
rm -f openssl
shlib_target=; if [ -n "" ]; then \
shlib_target="linux-shared"; \
elif [ -n "" ]; then \
  FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC FIPSLD_CC; \
fi; \
LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o dgst.o 
dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o 
rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o 
genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o 
app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o 
pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o 
srp.o" \
LIBDEPS=" $LIBRARIES -ldl" \
link_app.${shlib_target}
make[2]: Entering directory 
`/unixhome/vnayak/workspace/openssl/lnx-ppc64/openssl-1.0.1h/apps'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl  -L.. -lcrypto -ldl}"; 
LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall 
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM}"; 
LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | 
uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; 
LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o 
${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o 
enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o 
dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o 
s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o 
sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o 
spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
dgst.o(.text+0x7d8): In function `.dgst_main':
: undefined reference to `.OPENSSL_cleanse'
enc.o(.text+0x7fc): In function `.enc_main':
: undefined reference to `.OPENSSL_cleanse'
ca.o(.text+0x3d9c): In function `.ca_main':
: undefined reference to `.OPENSSL_cleanse'
s_server.o(.te

RE: On 2K keys and SHA-256

[Salz, Rich]

> May I suggest 4096 bit with SHA-256.

I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see 
much deployment because of the computational cost.  At least, that's how we see 
things at my employer.

> And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you
> to create Low (512), Medium (1024) or High (2048) grade encryption keys
> (patch available for ages BTW) ...

If you can point me to patches, email, or whatever I can try to make sure those 
links get seen by folks in charge.

/r$
--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Value of DEFAULT cipher suite

[Salz, Rich]

> Please consider also adding !SSLv3 and !RC4 to this list.

My plan is to move RC4 and MD5 to LOW; see RT3518.  As for SSLv3, the issue is 
that you really mean the protocol, not the ciphers (there's overlap with SSL 
and TLS), which is configured separately, and only via code.  So I think I have 
to leave that as-is, unfortunately.

Thanks for the feedback.
--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: cannot read PEM key file - no start line

[Jeffrey Walton]

On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall  wrote:

> All,
>
>
>
> I am getting the following with my client cert when trying to connect to
> an SSL-enabled MongoDB:
>
>
>
> 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file:
> /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
> error:0906D06C:PEM routines:PEM_read_bio:no start line
>
I just tried to duplicate with a key (not a certificate) that uses line
breaks at 76 characters. I don't have a certificate because my routines
don't support certificates. But it should reveal a little about the OpenSSL
parser.

Reading the public and private keys were OK when the line size was 76 (see
below). So the OpenSSL parser is lenient during a read. This seems very
reasonable to me.

Reading an encrypted private key resulted in an error "PEM_read_bio:bad end
line:pem_lib.c:802" when the line size was 76 (see below). This kind of
surprised me.

Since you are receiving the "no start line" error (and not another error),
I would suspect you are reading an ASN.1/DER encoded certificate; and not a
PEM encoded certificate. The error occured before anything related to line
lengths.

Can you post the X509 certificate for inspection?

Jeff

**

# Line breaks at 76
$ cat rsa-pub-xxx.pem
-BEGIN PUBLIC KEY-
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDse17vxd2lkVIxwt1gkipo0EZo3NdDhIvPRowZ
6hfRM1n3+8NlS4Qw76PvM1EMR9FXCFTBtv9zzZ7OkNH84LgG6mbNS28PuWeUFmMZumdLbT4KNu2U
pttFup08OUEIlrmkeP1GqMCfaVcbCfl0tScpCMeEhXUpiIvtzUin2kqGHQIDAQAB
-END PUBLIC KEY-

# Line breaks at 76
$ cat rsa-priv-xxx.pem
-BEGIN RSA PRIVATE KEY-
MIICXgIBAAKBgQDse17vxd2lkVIxwt1gkipo0EZo3NdDhIvPRowZ6hfRM1n3+8NlS4Qw76PvM1EM
R9FXCFTBtv9zzZ7OkNH84LgG6mbNS28PuWeUFmMZumdLbT4KNu2UpttFup08OUEIlrmkeP1GqMCf
aVcbCfl0tScpCMeEhXUpiIvtzUin2kqGHQIDAQABAoGBAJqxzZW98tMW8BS7K0O7+eActqJsLKjv
MOIDfSyKlM/17pmo6NX/g1bbvHqCMDd/V3K+cWtTAWJIlOT9mU/51Ib3h29xEQQ6Ql/ubMPAmm/t
f7itQMxn5FVY+ZA2/pL/mDzAdMuLeS/1TcHCqjbpAL8VaZjHTqztHBcVcNzbIQ6BAkEA/e7hE6WV
caAoFEVfoZW0AIjwWpziQdI1bhNAi70fxWEU1kSq2ZZZhqxU4G37IKmVfBnx3CSzCgp5daPqUpEO
oQJBAO5oIOgVf3GqL03fA6N3s2gx9L4VzAaZZynDF6yjhCCAXs8uUSEYKL32a17dFq+0SrQUSS2J
Tylsz2cv+Uk6cf0CQQCV5RLb5BypbB78iE8BNTuCLVOkSYON0yZTCe5KDqPYgYwpR3OK6aODSer4
aDObfj+NeEs65jcBsFkuRkol3xbBAkEAiN+rlNNS2fU1N2YEdsNwcy/LLZ7iBh/ohKeHXgx6/RX2
WMhkt7VhHr7tIgeY0MOX6A+Fe+lLU6Mu6DU4z/wIGQJAQfEGaJbtaq8bLu6m2VYPpGig1NyBx9i8
kF/E+JC9ZSYh//5nhp6+lBbxceDcijPqnKGZlMYS51nPLSHQBRqbog==
-END RSA PRIVATE KEY-

# Line breaks at 76, password is "test"
$ cat rsa-enc-priv-xxx.pem
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,8878824B00BA92932DC5AA1E4A9F12E0

klcOjPvZmj/19sUcf031oUckm2YUw7nEp6UtSbs41OKd2TyRfveNl4vv3J8AzOh18AqPPSKR3chM
8lSvKIdcksieh8raqr2s5wMd8ds/mDkguoVWGVnN8f+FKoVTny7OMhXAbQhk2ZXwZMEU5Q8M/Jnj
3ZfrbgcLYH50UoPlkgD6Y0krcNB+TDJEMvErn7G6RedrDPOjQ2gFCmRSE6Yuqtcgl5JaVS+1UT8Z
4l+EMuUjQcBiwuSQNxgfwyGQ3g/2maluLJsEKHDQhAKufe2c7lXlK/0MdHY+q4RbNLmGBigHb97U
A5jTZl5+dBrQgtgPx7V13F/7EHT6m2KrYSDvfoPadcT65sT1ukoZF5rvbdRcN1QtVetVrymwM5XU
8CrlSz6tihleipPx27JUA7WQjIQc/Kk7R0e1dNB0oEkgd0i5+20bg+4/Keh0t5fwkXlyrCwjEItT
zoC0Hm2dvXG6BTm1OUyRL94DxStVmqRpwDbthbEUqxYWrxTgWKu+noGYu3xJFI6plKEHTY+YMxjm
azeyV8CE0HGwRXTBHpj47bekt5dpxMxZasgeIJqHrUI3am+CijdJTHQyHU3Zxk7rdiLha1inpN6M
Z+ImQxqzm22e4/KMnTxcZ7L6hNzCKXgAGZ9gdg2uV+fwwyFRwzLDWMbQFeYH10yHB6Ua6Wg2LZdr
+NTuJlrMykVULD382XszNMLFtJGl46lpJ9XKWTTIX4e5Fg5N1WSHS2gD8YLxtRzd9vM9ewsZOMtw
gqw5uK7GSJUo8FHKtYuLGKY0jnVHFm2VnYo+76RXQxmJyo+ANmALJCJENCZDMm0I0pRGgRVV
-END RSA PRIVATE KEY-

$ openssl rsa -in rsa-pub-xxx.pem -pubin -text -noout
Public-Key: (1024 bit)
Modulus:
00:ec:7b:5e:ef:c5:dd:a5:91:52:31:c2:dd:60:92:
2a:68:d0:46:68:dc:d7:43:84:8b:cf:46:8c:19:ea:
17:d1:33:59:f7:fb:c3:65:4b:84:30:ef:a3:ef:33:
51:0c:47:d1:57:08:54:c1:b6:ff:73:cd:9e:ce:90:
d1:fc:e0:b8:06:ea:66:cd:4b:6f:0f:b9:67:94:16:
63:19:ba:67:4b:6d:3e:0a:36:ed:94:a6:db:45:ba:
9d:3c:39:41:08:96:b9:a4:78:fd:46:a8:c0:9f:69:
57:1b:09:f9:74:b5:27:29:08:c7:84:85:75:29:88:
8b:ed:cd:48:a7:da:4a:86:1d
Exponent: 65537 (0x10001)

$ openssl rsa -in rsa-priv-xxx.pem -text -noout
Private-Key: (1024 bit)
modulus:
00:ec:7b:5e:ef:c5:dd:a5:91:52:31:c2:dd:60:92:
2a:68:d0:46:68:dc:d7:43:84:8b:cf:46:8c:19:ea:
17:d1:33:59:f7:fb:c3:65:4b:84:30:ef:a3:ef:33:
51:0c:47:d1:57:08:54:c1:b6:ff:73:cd:9e:ce:90:
d1:fc:e0:b8:06:ea:66:cd:4b:6f:0f:b9:67:94:16:
63:19:ba:67:4b:6d:3e:0a:36:ed:94:a6:db:45:ba:
9d:3c:39:41:08:96:b9:a4:78:fd:46:a8:c0:9f:69:
57:1b:09:f9:74:b5:27:29:08:c7:84:85:75:29:88:
8b:ed:cd:48:a7:da:4a:86:1d
publicExponent: 65537 (0x10001)
privateExponent:
00:9a:b1:cd:95:bd:f2:d3:16:f0:14:bb:2b:43:bb:
f9:e0:1c:b6:a2:6c:2c:a8:ef:30:e2:03:7d:2c:8a:
94:cf:f5:ee:99:a8:e8:d5:ff:83:56:db:bc:7a:82:
30:37:7f:57:72:be:71:6b:53:01:62:48:94:e4:fd:
99:4f:f9:d4:86:f7:87:6f:71:11:04:3a:42:5f:ee:
6c:c3:c0:9a:6f:ed:7f:b8:ad:40:cc:67:e4:55:58:
f9:90:36:fe:92:ff:98:3c:c0:74:cb:8b:79:2f:f5:
4d:c1

RE: cannot read PEM key file - no start line

[Liz Fall]

Hi Viktor,

Thanks for the info.  I will try what you suggested today.  However, I am a
bit confused by what you are saying - You may need to separately specify a
CAfile, or CApath for validating the server certificate.  I have the two pem
files below.  I thought the
DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem file resided on the
MongoDB database server and I was supposed to connect from my C++ app with
the DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem file.  I am new to
this, so I am sorry for not understanding completely. 

.   DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem
.   private key of DTCD9C3B2F42757.ent.wfb.bank.corp machine
.   certificate for DTCD9C3B2F42757.ent.wfb.bank.corp, signed by WF
Enterprise CA 02
 
.   DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem
.   WF Enterprise CA 02 certificate, signed by WF Root
.   WF Root certificate

Thanks,
Liz

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni
Sent: Monday, September 08, 2014 8:28 PM
To: openssl-users@openssl.org
Subject: Re: cannot read PEM key file - no start line

On Mon, Sep 08, 2014 at 08:14:32PM -0700, Liz Fall wrote:

> I am trying to connect to a MongoDB SSL-enable database.  This is the API:

> // only really need a PEM on the server side
> mongo::sslGlobalParams.sslPEMKeyFile = "";

The comment is highly misleading.  PEM is a "meta" format.  It encapsulates
base64 encoded blobs between BEGIN/END headers/trailers, allowing multiple
objects to be concatenated unambiguously and transported undamaged via ASCII
email.

This this is a client, what goes here is likely a client certificate chain
and a client private key, or just NULL, if client certificates are not
employed (you're likely authenticating the client with a username and
password instead).

-- BEGIN RSA PRIVATE KEY -
private key for client cert base64 encoded
-- END RSA PRIVATE KEY -
client cert base64 encoded
-- END CERTIFICATE -
-- BEGIN CERTIFICATE -
intermediate issuer base64 encoded
-- END CERTIFICATE -
...
-- BEGIN CERTIFICATE -
root issuer base64 encoded
-- END CERTIFICATE -

I would try NULL first.  You may need to separately specify a CAfile, or
CApath for validating the server certificate.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org


---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Why does OpenSSL own all the prefixes in the world?

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Iñaki Baz Castillo
> Sent: Monday, 08 September, 2014 18:14
> To: openssl-users@openssl.org
> Subject: Re: Why does OpenSSL own all the prefixes in the world?
> 
> 2014-09-08 16:29 GMT+02:00 Salz, Rich :
> > The extern "C" makes it difficult to put things into a namespace.  You'd
> either have to write class declarations that used NO public openssl header
> files in their public declaration, or we'd have to change the extern "C"
> wrappers to be something like
> > #if defined(__cplusplus) && !defined(OPENSSL_NAMESPACED_API)
> 
> 
> I've tried the "namespace openssl {  #include  }
> approach and it has been terrible. I've ended with compiler error
> messages like:
> 
>   openssl::malloc not found
> 
> It makes sense given that the namespace is also affecting to any other
> include within the openssl header file.

You'd have to include the standard C headers before including the OpenSSL ones, 
outside the namespace, so that their inclusion by the OpenSSL headers has no 
effect.

Mind you, I don't think it's worth the effort, for the reasons I outlined 
earlier.

-- 
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com

certificate

[Amir Reda]

dear all
i have just made a code to make a certificate request from a node and my
certificate authority reply with the certificate
the node has attributes as below
   X509_REQ   *x;
   EVP_PKEY   *prk;
   EVP_PKEY   *puk;
   X509m_myCert;
   //RSA structure contain both private and public key
   RSA*rsa_keyPair;
   X509_NAME  *name;
the function which made the certificate request is
  X509_REQ*
  AeroRoutingProtocol :: MakeSignedCertReq (int bits, int serial, int days)
  {
X509_REQ_set_pubkey(x,puk);
name=X509_REQ_get_subject_name(x);
// it gives errors i don't knoe why
//X509_NAME_add_entry_by_txt(name,"C",MBSTRING_ASC, "UK", -1, -1, 0);
//X509_NAME_add_entry_by_txt(name,"CN",MBSTRING_ASC, "OpenSSL Group",
-1, -1, 0);
X509_REQ_sign(x,puk,EVP_md5());
return x;
  }
the certificate authority receive this request and reply by the certificate
the function that make certificate as below

 X509*
 CertificateAuthority :: CreateCertificate (X509 *issuer, X509_REQ *req,
RSA *key )
 {
X509 *cert = NULL;
int rv;
X509_NAME *xn_req = NULL, *subject = NULL;
EVP_PKEY *pkey = NULL;

//create the certificate
X509 * x509;
x509 = X509_new();
X509_NAME *issuerSubject = X509_get_subject_name(issuer);
X509_set_issuer_name(cert, issuerSubject);
xn_req = X509_REQ_get_subject_name(req);
X509_set_subject_name(cert, subject);
pkey = X509_REQ_get_pubkey(req);
rv = X509_set_pubkey(cert, pkey);
X509_gmtime_adj(X509_get_notBefore(cert), 0);
X509_gmtime_adj(X509_get_notAfter(cert), 36400);
signCertificateWithKey(cert, key);
return cert;
 }

when i compile i got this error
../src/aerorp/model/certificate-authority.cc: In member function ‘X509*
ns3::AeroRP::CertificateAuthority::CreateCertificate(X509*, X509_REQ*,
RSA*)’:
../src/aerorp/model/certificate-authority.cc:58:37: error:
‘signCertificateWithKey’ was not declared in this scope

thanks allot for help

-- 
Warmest regards and best wishes for a good health,*urs sincerely *
*mero*

Re: How to empty a BIO buffer?

[Iñaki Baz Castillo]

2014-09-09 10:46 GMT+02:00 Richard Levitte :
> And of course, I noticed this email after sending my own...  sorry.


:)

Thanks a lot.

-- 
Iñaki Baz Castillo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to empty a BIO buffer?

[Richard Levitte]

And of course, I noticed this email after sending my own...  sorry.

In message  
on Mon, 8 Sep 2014 18:41:40 +0200, Iñaki Baz Castillo  said:

ibc> 2014-09-08 18:35 GMT+02:00 Kyle Hamilton :
ibc> > The allocated buffer needs to be sizeof(char *). What's happening is the
ibc> > address of the buffer (&buffer[0]) gets written to the
ibc> > pointer-to-pointer-to-char, data. If data == NULL, you're asking to write
ibc> > the address of the buffer to unallocated memory.
ibc> >
ibc> > It's done this way because the return value of the function is the 
number of
ibc> > valid bytes you can read from that location, and the address must go
ibc> > somewhere for you to get the data from it.
ibc> >
ibc> > I'm sorry this is probably difficult to understand, I don't know if I can
ibc> > explain it more easily.
ibc> 
ibc> It's clear. And my error was terrible, I was creating a char** data
ibc> instead of char* data. The following updated code does work:
ibc> 
ibc> 
ibc> -
ibc> long read;
ibc> char* data = NULL;
ibc> 
ibc> read = BIO_get_mem_data(bio, &data);
ibc> 
ibc> // Use data and read values.
ibc> -
ibc> 
ibc> 
ibc> Thanks a lot.
ibc> 
ibc> 
ibc> -- 
ibc> Iñaki Baz Castillo
ibc> 
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Value of DEFAULT cipher suite

[Benny Baumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Rich,

Am 09.09.2014 00:42, schrieb Salz, Rich:
> We are considering removing weak cryptography from the value of 
> DEFAULT.  That is, append ":!LOW:!EXPORT"
> 
> It is currently defined as this in include/openssl/ssl.h: #define 
> SSL_DEFAULT_CIPHER_LIST   "ALL:!aNULL:!eNULL:!SSLv2"
> 
> Please let us know if you have strong objections to this.
Please consider also adding !SSLv3 and !RC4 to this list.

Regards,
BenBE.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJUDsI0AAoJEPHTXLno4S6t9FIP/0U0GxY3LyyULMPFGc+AVGmV
BfgR5WZOd1+VsWudCfhpOS9OGAMBdmjxzI2TQvm1osUnSyRI8k8642eCF8v1Gqtf
QIGtUp/A0UghKygoo9XzNCLfu2WL6DOa9HYWpURDEVanM+ZGImwNh02zv8b9jXcM
REFi7rkr8gIje7O7z9SVb3RkKqp/QBwR9s7w1i2bzdEyKi4pbsGhX0s2zclALTgU
6Gn5SMh0o3LeIoNjvfhxe4KyDY/u97omkgOmThERkgZEILrzcj2lgZZ+sI6W2qpa
E/QUNKrStQJXereOp2iAO7uEXPe3Md+VhqsSjP8pxpiTb1U6o74FITeyEggBSWS9
u8i/2sCpXZPRqUGe1OTbxzu3BjFXHOEQ6kc7pZahPAX3M9spY5WMglnFJODCn5F3
QIps8pZ1CJuXm1UhVJ3LvTKsbIsQ3C7egbPrK6zAZwCWRDUmYOya6YUUTA+gu3xs
6Tv6FHoI+r/yyiff4BfhdU7ECHlqw7+pqIgwyIWJQeNRxzOzUquuaQDy2bLnWMX5
+NGQEmgfzIPQhD5rzNI3TUrzutJB+4cyVnaIGjcjzc79gcQYRaLgkGXOg2D5nFgj
KGeUbls7kft+48Junrap/2q1ozblQt+D1j9czQPdeFWCnnt+uG6yCtnnPYqtp/GJ
3EOir+BPawK99iMGjUYy
=TFs7
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: How to empty a BIO buffer?

[Richard Levitte]

In message  
on Mon, 8 Sep 2014 18:19:09 +0200, Iñaki Baz Castillo  said:

ibc> Why do I need to provide BIO_get_mem_data() with an already allocated
ibc> buffer? I've checked the function and I do not understand what it
ibc> does). The only I want is to get the pointer to the BIO's buffer in
ibc> which SSL_write() wrote. Why should I provide an allocated buffer? The
ibc> BIO already has a buffer and the data is already in there after
ibc> calling SSL_write(). Why do I need to pass an allocated buffer?

Actually, you don't, you only need to pass it the address to a char*
(that's what a char** is).  This code snippet (which is your code
snippet that crashes with a small change) is sufficient:

--
long read;
char* data = NULL;

read = BIO_get_mem_data(bio, &data);

// Use data and read values.

BIO_reset(bio);
--

Cheers,
Richard

-- 
Richard Levitte rich...@levitte.org
http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Performance related queries for SSL based client server model

[Alok Sharma]

Hi,
   Thanks all for your update. But functionality wise it is working
fine. I can remove the inner loop but that will require packet size to
be of 1K. I tried with that also but did not find any improvement in
performance. In my setup there are 8 routers between source &
destination. Can anyone share me sample SSL based client server
programme which I could use to measure performance.
Regards,
Alok

On Tue, Sep 9, 2014 at 3:54 AM, Iñaki Baz Castillo  wrote:
>
> 2014-09-08 19:46 GMT+02:00 Alok Sharma :
> > One thing I observerd by looking into scp
> > code that it does not use SSL provided APIs (i.e.SSL_Read or SSL_Write) but
> > they use it differenly i.e. might be directly calling encryption APIs and
> > writing data to sockets. But I don't have much understanding what SSL_Write
> > or SSL_read does internally.
>
> It has been already replied above. SSH is not SSL so don't look for
> SSL_ methods on openssh. Said that, AFAIK openssh uses the crypto
> library from openssl, but that is not SSL/TLS at all.
>
>
> > So wanted to understand if there is any way to
> > improve performance of SSL_Read or SSL_write to achive high performance.
> > Following are my client server programmes. Here  client writes file on
> > server machine in hardcoded location and name.
>
> You have lot of errors in your program. I suggest that you first
> properly learn openssl, then measure your code if you need.
>
>
>
> --
> Iñaki Baz Castillo
> 
> __
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@openssl.org
> Automated List Manager                           majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: On 2K keys and SHA-256

[Benny Baumann]

Hi Rich,

Am 08.09.2014 23:59, schrieb Salz, Rich:
> We are considering changing the default keysize (RSA, DSA, DH) from 1K
> to 2K, and changing the default signing digest from SHA-1 to SHA-256.
May I suggest 4096 bit with SHA-256.

That way you have a security level of >= 128 bit for both primitives and
as the weakest link counts ... Also: attacks only get better over time.
> 
> We’ve already committed this to HEAD/master.  We would like to make this
> change in the upcoming 1.0.2 release as well. Several downstream
> distributions, such as Debian, have already done this. Microsoft has
> already announced deprecation of SHA-1  certificates, and Google just
> recently posted a fairly aggressive plan for Chrome.
And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering
you to create Low (512), Medium (1024) or High (2048) grade encryption
keys (patch available for ages BTW) ...
> 
> Does anyone have strong objections?
The only objection I have regarding this change is that originally
intended one reflects only the bare minimum of the chosen primitives
that you can widely use without being deprecated. Why aren't people
thinking ahead for a moment and try to set defaults more to the middle
of the practical range*.

*for digests this unfortunately is SHA-256 through SHA-256 as GnuTLS 2.x
(available on most Debian Stable boxes) barfs on anything else like
SHA-384 or SHA-512.

Kind regards,
BenBE.

>  
> 
> -- 
> 
> Principal Security Engineer
> 
> Akamai Technologies, Cambridge MA
> 
> IM: rs...@jabber.me  Twitter: RichSalz
> 
>  
> 




signature.asc
Description: OpenPGP digital signature

Re: Why does OpenSSL own all the prefixes in the world?

[Benny Baumann]

What about introducing a openssl_deprecated.h which sole purpose is to
throw in a bunch of defines that map ERR_old_style_name
OPENSSL_ERR_new_style_name.

To make an old-style codebase compatiblae the only thing to add would be
either including openssl_deprecated.h or set a macro on the command line
that does so from within the new-style headers (maybe on by default via
the configure).

And BTW: C++ won't hurt legibility of the source: using some scoped
pointers you can cleanup most error paths to become just "return
OPENSSL_ERR_new_style_error_name.

Regards,
BenBE.

Am 08.09.2014 03:52, schrieb Jakob Bohm:
> And how would you do that without breaking compatibility with every
> program (in C, C++ or any other language) that already uses openssl and
> depends on the current API names?
> 
> Providing the API, semantics and portability of the original SSLeay
> library is thesecond-most important feature of OpenSSL (right after
> actually being a secure SSL/TLSimplementation when used correctly).
> 
> On 08/09/2014 01:15, Pierre DELAAGE wrote:
>> Hmm...
>> Switch strongly and definitely to C++
>> Not for fancy object programming, but for more practical syntaxES for
>> things like this.
>>
>> And I am an old C fan programmer...
>> Pierre Delaage
>>
>>
>>
>> Le 08/09/2014 00:04, Kyle Hamilton a écrit :
>>> The reason is "legacy". Eric Young was not conscious of namespace
>>> pollution when he implemented SSLeay; since then, even after the
>>> migration to the OpenSSL name and team, the focus has been more on
>>> maintaining source compatibility than in creating new
>>> interoperability opportunities.
>>>
>>> To meet the goal of interoperability while enabling an alternate
>>> symbolic namespace, what would you suggest?
>>>
>>> -Kyle H
>>>
>>> On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo"
>>>  wrote:
>>>
>>> Hi,
>>>
>>> RAND_xxx
>>> CRYPTO_xxx
>>> ERR_xxx
>>> ENGINE_xxx
>>> EVP_xxx
>>> sk_xxx
>>> X509_xxx
>>> BIGNUM_xxx
>>> RSA_xxx
>>> BN_xxx
>>> ASN1_xxx
>>> EC_xxx
>>>
>>> etc etc etc.
>>>
>>> May I understand why it was decided that OpenSSL can own all the
>>> prefixes or "namespaces" in the world? How is it possible that
>>> OpenSSL
>>> owns the ERR_ prefix (for example ERR_free_strings() and others)?
>>>
>>> OpenSSL is a library. I should be able to integrate OpenSSL into my
>>> own code and define my own prefixes without worrying about creating
>>> conflicts with the near 200 prefixes that OpenSSL owns.
>>>
>>>
>>> An example of a well designed C library is libuv [*], in which:
>>>
>>> * Public API functions and structs begin with uv_.
>>> * Private API functions begin with uv__.
>>> * Public macros begin UV_.
>>>
>>> That's a good design!
>>>
>>>
>>> PS: In my project I use both openssl and libsrtp. In which of them
>>> do
>>> you expect the following macro is defined?:
>>>
>>>SRTP_PROTECTION_PROFILE
>>>
>>>
>>>
>>>
>>> [*]https://github.com/joyent/libuv/
>>>
> 
> Enjoy
> 
> Jakob




signature.asc
Description: OpenPGP digital signature

Can we have a PyOpenSSL 0.15?

[Eric Chazan]

All,

My team is considering a port to Python 3 from Python 2.7.  One issue we
see is that we cant run a flask server with ssl.  I am seeing that the fix
is in this pull request:

https://github.com/pyca/pyopenssl/pull/78/commits


Which has already been merged.  Is a new version of PyOpenSSL coming that
contains this pull request?

Thanks,
Eric Chazan

Re: Verifying authenticode signature using openssl API

[Prasad Dabak]

Thanks Jacob for an elaborate answer. Somehow I never received your response to 
my registered email address, hence delay in responding.

I have a few follow-up questions on your response.

1. So, "encryptedDigest"  has no relation to the stored "messageDigest"? I 
thought it's a encrypted version of the messageDigest?
2. I agree that it's better to do cheaper checks first e.g. I am also matching 
PE checksum stored in the optional header.
3. spcPEImageData is probably relevant only for signing that uses page hashes?
4. PKCS7_verify is already matching the encryptedDigest, do we still need to 
validate it ourselves?
5. So, basically are are suggesting to look into the subject string and see if 
we can find patterns like /CN=COMPANY-NAME... issuer: /C=US/O=SIGNER_NAME? 
How authoritative it is? I mean can someone else have same COMPANY-NAME and 
PATTERN-NAME in their certificate?

In my case, I am the one who is signing the executable using my certificate and a 
"cross certificate" issued by Microsoft and I want to programmatically ensure 
following things.

1. Code is not tampered since it was signed (matching messageDigest with 
computed hash)
2. Verifying the digital signature (PKCS7_Verify)
3. Confirming that the executable is signed by my company certificate.

I am stuck on part (3) and don't see a clean way apart from matching strings in 
subject field?  If I hard-code the public key in my verification code, I will 
need to update it when I switch to a newer public key?

Thanks.
-Prasad

On Sep 06, 2014, at 09:44 PM, Prasad Dabak  wrote:


Hello,

Given a signed Windows portable executable, I want to programmatically verify 
two things using openssl APIs

1. Verify the digital signature.
2. Confirm that the executable is signed by a specific company using that 
company's public key.

It seems that part (1) can be done by parsing the signedData attribute in the 
portable executable, extracting the hashing algorithm and digest stored there, 
re-computing the digest of the executable using the same hashing algorithm and 
match them.

I have following questions.

1. The signData contains messageDigest (unencrypted) and encryptedDigest 
(encrypted). Is it enough to match messgaeDigest with the computed digest? OR 
we also need to decrypt the encryptedDigest using the company public key and 
match that as well?
2. What does PKCS7_Verify exactly do? I looked at 
https://www.openssl.org/docs/crypto/PKCS7_verify.html  and I understand  that 
it verifies certificate chain.  However, it's not clear to me as to what 
exactly it does with respect to signature verification?
3. I am assuming that I require to do both (1) and (2) in order to verify the 
authenticode signature?
4. What is the best way to verify if the executable is signed by specific 
company using that company's public key?

Any inputs will be greatly appreciated!

Thanks.
-Prasad