RE: Secure storage of private (RSA) keys

[Salz, Rich]

In our haste to help, the secure memory allocation patch we posted last week 
had two issues. First, it wasn’t easy to use. We knew that, and tried to set 
expectations accordingly. Second, it wasn’t really secure enough. We didn’t 
know that, and we thank everyone who brought it to our attention. For example, 
it only protected keys that came in via ASN.1 (which addressed our use-case but 
wasn’t made explicit) and, much worse, it failed to protect all the necessary 
key parameters and values used in intermediate calculations.
 
We are working on new code that will  address both issues, and hope to post the 
next revision in a couple of days.  The heap is more like OpenSSL coding style, 
and protects all BIGNUM's.  If you are interested and able to help out before 
we post it, please contact me directly.
 
/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

Re: Heart bleed with 0.9.8 and 1.0.1

[ag@gmail]

Yes, your client is vulnerable. Which ip to connect to is governed by your 
application, and IP addresses can be falsified, so it is very much possible 
your client connects to a malicious server.

-ag

--
sent via 100% recycled electrons from my mobile command center.

> On Apr 11, 2014, at 8:32 AM, cvishnuid  wrote:
> 
> Hi I am having 0.9.8 open ssl libraries in my server and 1.0.1 in my client. 
> Am I venerable to heart bleed attach? Regards, Vishnu. 
> View this message in context: Heart bleed with 0.9.8 and 1.0.1
> Sent from the OpenSSL - User mailing list archive at Nabble.com.

Re: Heart bleed with 0.9.8 and 1.0.1

[Dave Thompson]

Possibly too Postelian, OpenSSL answers a received heartbeat request 

(and thus before the fix answers a malicious request with leaked data) 

even if the heartbeat extension was negotiated off.

Only the build option to exclude the code stops it.

OpenSSL will *send* hb request only if/after negotiating on.

 

The first >OpenSSL< version with heartbeat is 1.0.1 (base).

The extension RFC is written against current 5246 TLSv1.2, but like 

most extensions the logic can apply to any version that supports extensions 

which is since TLSv1(.0) and that’s what OpenSSL implements.

The only exception I see is sigalgs which only makes sense for D/TLS1.2.

 

 

From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of cvishnuid
Sent: Sunday, April 13, 2014 12:24
To: openssl-users@openssl.org
Subject: *** Spam *** Re: Heart bleed with 0.9.8 and 1.0.1

 

Will client respond for heart beat request even if server doesn't support
heart beat . ?

 

Which version of ssl this heart beat in introduced ? 

 

I am assuming as the client know that the session establish with sever
doesn't support heart beat it will not respond am I correct ?

 

 


On Sunday, April 13, 2014, Jin Jiang [via OpenSSL] <[hidden email]> wrote:

Hi,

I think your client is vulnerable, if the attacker can touch your client.

 

Regards,

Jin 

 

On Fri, Apr 11, 2014 at 5:32 PM, cvishnuid <[hidden email]
 > wrote:

Hi I am having 0.9.8 open ssl libraries in my server and 1.0.1 in my client.
Am I venerable to heart bleed attach? Regards, Vishnu. 

  _  

View this message in context: Heart bleed with 0.9.8 and 1.0.1
 
Sent from the OpenSSL - User mailing list archive
  at Nabble.com.

 

 

  _  

If you reply to this email, your message will be added to the discussion
below:

 

http://openssl.6102.n7.nabble.com/Heart-bleed-with-0-9-8-and-1-0-1-tp49300p4
9373.html 

To unsubscribe from Heart bleed with 0.9.8 and 1.0.1, click here.
 
 NAML 

 

  _  

View this message in context: Re: Heart bleed with 0.9.8 and 1.0.1
 
Sent from the OpenSSL - User mailing list archive
  at Nabble.com.

RE: Help me for ECDHE algorithm

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of chetan
> Sent: Monday, April 14, 2014 00:42

> xxx.c is my program file.
> So, i'm compile simply like "cc xxx.c ".
> I am Gettting [undefined reference]

This is basic C programming. Whenever you link (not just compile) a C
program 
that uses a library (or several) other than the standard C lib(s) you must 
specify it(them) to the linker, or to the compiler when it runs the linker
as here.

The exact syntax depends on what compiler and/or linker you are using, 
which you don't say, but AFAIK the component 'collect2' indicates
GCC/binutils.
The syntax for that (and some others) is -lxxx where l is lowercase ell and
xxx 
is the 'short' name of the library; the actual filename is usually libxxx.so
or libxxx.a .
For OpenSSL EVP* routines (and more generally everything but actual SSL/TLS)

the library you need is -lcrypto .

If the library(s) you want isn't placed in the compiler's (or platform's)
default 
location for libs, you also need to specify -L (uppercase ell) with the
directory.
If you are using a OS-vendor-provided or packaged version, as on Linux, it
will 
almost certainly be in the default location, whatever that is for a given
distro.



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

Re: Re: Converting a root certificate from md5 to sha1

[Kyle Hamilton]

Stephan,

It depends on how pedantic your clients are.  If you aren't rekeying,
it shouldn't matter, though.

X.509 has a "Subject" and an "Issuer".  The Issuer of a certificate is
the Subject of the certificate which private key was used to sign it.
If the Issuer doesn't change, then the matching algorithm doesn't
change at all.

However, the answer is always going to be "test the clients in your
environment".  There are a *lot* of options, a *lot* of things that
can potentially get screwed up, and there's no way to make a blanket
statement without caveat.

The problem with that command, though, is that it doesn't change the
serial number, or the signing algorithm claimed in the main
certificate.  Anything which pedantically enforces the rule that "the
signing algorithm claimed in the TbsCertificate MUST match the signing
algorithm in the Certificate" is going to fail.  (I think I saw a root
certificate from Boeing which failed that particular test.)

As always, your mileage may vary.  The proper way to do this is to
create a new certificate request with the appropriate information, and
then sign it, but OpenSSL makes that difficult.

-Kyle H


On Tue, Apr 15, 2014 at 6:54 AM,   wrote:
>>You need to generate a new certificate with the same data (except a
>>different serial number and a reference to sha1WithRSAEncryption),
>>containing the same public key, and signed with the same private key.
>>
>>I'd recommend sha256WithRSAEncryption, but that's possibly not an
>>option for you.
>>
>>Make sure that you do not reuse the same serial number, it *will*
>>cause problems (particularly for such software as Firefox, but also
>>for anything that's written in an X.509-pedantic mode).
>>
>>-Kyle H
>
> Okay, thanks. Would this mean that I need to replace the old root cert with 
> the new one on all clients ? I have certificates that are already in use and 
> the new root cert would have a start date of today, wouldn't it confuse the 
> client when the start date of the cert is older than that of the root cert ?
>
> Also I managed to convert the existing root cert from md5 to sha1 with
>
> openssl x509 -sha1 -inform pem -outform pem -in cacert.pem -out 
> cacertsha1.pem -signkey cakey.pem
>
> this recreates the cert with sha1 but it also resets the startdate to . 
> I tried using -startdate and -enddate but openssl moans that it doesn't 
> recognize the date as option. I tried 'Jan 01 10:37:30 2014 GMT' as well as 
> the YYMMDDHHMMSSZ, both don't work.
>
> Thanks,
> Stephan
>
>>On Tue, Apr 15, 2014 at 1:41 AM,  wrote:
>>> Hello world,
>>>
>>> I am running my own little CA and the root certificate was created using 
>>> md5:
>>>
>>> Signature Algorithm: md5WithRSAEncryption
>>>
>>> I need to change this do sha1 because I have clients that do not accept md5 
>>> anymore. Is there any way to convert the existing cert from md5 to sha1 ? I 
>>> tried converting it to another format and then reimporting it using -sha1 
>>> but this doesn't work.
>>>
>>> Thanks,
>>> Stephan
>
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-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: RSA Private key extract using Heartbleed

[Luis Rocha]

Ok, sorry about the spam   the keys have a different header and
googling it arround found that:

"BEGIN RSA PRIVATE KEY is PKCS#1 and is just an RSA key. It is essentially
just the key object from PKCS#8, but without the version or algorithm
identifier in front. BEGIN PRIVATE KEY is PKCS#8 and indicates that the key
type is included in the key data itself."


# xxd apache.key | head
000: 2d2d 2d2d 2d42 4547 494e 2050 5249 5641  -BEGIN PRIVA
010: 5445 204b 4559 2d2d 2d2d 2d0a 4d49 4943  TE KEY-.MIIC
020: 6477 4942 4144 414e 4267 6b71 686b 6947  dwIBADANBgkqhkiG
030: 3977 3042 4151 4546 4141 5343 416d 4577  9w0BAQEFAASCAmEw
040: 6767 4a64 4167 4541 416f 4742 414e 6f59  ggJdAgEAAoGBANoY
050: 4434 4a42 4255 7352 7773 4b46 0a73 6d35  D4JBBUsRwsKF.sm5


# xxd apache-recovered.key | head
000: 2d2d 2d2d 2d42 4547 494e 2052 5341 2050  -BEGIN RSA P
010: 5249 5641 5445 204b 4559 2d2d 2d2d 2d0a  RIVATE KEY-.
020: 4d49 4943 5851 4942 4141 4b42 6751 4461  MIICXQIBAAKBgQDa
030: 4741 2b43 5151 564c 4563 4c43 6862 4a75  GA+CQQVLEcLChbJu
040: 6562 5a72 432f 7a49 4554 6535 4530 385a  ebZrC/zIETe5E08Z
050: 4c61 4f44 3030 6458 3152 4661 6f57 5567  LaOD00dX1RFaoWUg

And with the command "openssl rsa -inform PEM -text -noout" both keys have
the same key material 

Thanks!


On Tue, Apr 15, 2014 at 7:49 PM, Luis Rocha  wrote:

> Hello All,
>
> Please bare with me but could someone explain the following exercise
> result?
> How can a different private key generate the same public key?
>
>
> Basically I started a new VM and installed Ubuntu 13. Configured SSL and
> run the heartbleed script that is available in the wild.
>
> After a few packets got the RSA Modulus and one PrimeP.
> Converted the hex into decimal
> Divided the Modulus / PrimeP and got PrimeQ
> Used rsatool to generate RSA key and saved output in PEM format
> Compared (md5) the original key with the reconstructed key and got
> different values
> Extracted the pubkey from the original key and the reconstructed and got
> equal values.
> Signed a file with the original key and verified it successfully with the
> public reconstructed key.
>
> Here is the evidence:
>
> root@kali:~/Heartbleed# md5sum apache.key apache-recovered.key
>
> 8f3b1bc3c4fb4875b61ba39b6cf8f766  apache.key
>
> b3198c6328b097568018061b51834ddd  apache-recovered.key
>
>
>
> root# openssl rsa -in apache-recovered.key -pubout >
> apache-recovered.pub.key
>
> writing RSA key
>
> root# openssl rsa -in apache.key -pubout > apache.pub.key
>
> writing RSA key
>
>
> root@kali:~/Heartbleed# md5sum apache.pub.key apache-recovered.pub.key
>
> 9c4420445578366d0369a744a12cf313  apache.pub.key
>
> 9c4420445578366d0369a744a12cf313  apache-recovered.pub.key
>
>
>
>
> root# openssl dgst -md5 -sign apache.key -out filename.sign filename
>
> root# openssl dgst -md5 -verify apache-recovered.pub.key -signature
> filename.sign filename
> Verified OK
>
>
> Thank you,
> Luis
>
>
>
>
>

RSA Private key extract using Heartbleed

[Luis Rocha]

Hello All,

Please bare with me but could someone explain the following exercise result?
How can a different private key generate the same public key?


Basically I started a new VM and installed Ubuntu 13. Configured SSL and
run the heartbleed script that is available in the wild.

After a few packets got the RSA Modulus and one PrimeP.
Converted the hex into decimal
Divided the Modulus / PrimeP and got PrimeQ
Used rsatool to generate RSA key and saved output in PEM format
Compared (md5) the original key with the reconstructed key and got
different values
Extracted the pubkey from the original key and the reconstructed and got
equal values.
Signed a file with the original key and verified it successfully with the
public reconstructed key.

Here is the evidence:

root@kali:~/Heartbleed# md5sum apache.key apache-recovered.key

8f3b1bc3c4fb4875b61ba39b6cf8f766  apache.key

b3198c6328b097568018061b51834ddd  apache-recovered.key



root# openssl rsa -in apache-recovered.key -pubout >
apache-recovered.pub.key

writing RSA key

root# openssl rsa -in apache.key -pubout > apache.pub.key

writing RSA key


root@kali:~/Heartbleed# md5sum apache.pub.key apache-recovered.pub.key

9c4420445578366d0369a744a12cf313  apache.pub.key

9c4420445578366d0369a744a12cf313  apache-recovered.pub.key




root# openssl dgst -md5 -sign apache.key -out filename.sign filename

root# openssl dgst -md5 -verify apache-recovered.pub.key -signature
filename.sign filename
Verified OK


Thank you,
Luis

RE: New and bleeding - Install Win64 problems

[Aaron Bahmer]

Call me wimpy, but after six hours of fighting the compiling process, I went 
with the slproweb binary. New certificates are also in place. Thanks for the 
help--I'm no longer bleeding!

==
Aaron Bahmer
Director, Instructional Technology
Eastern Wyoming College
http://ewc.wy.edu | (307) 532-8284
1-866-327-8996 (1-866-EAST WYO) x8284

> > -Original Message-
> > From: Aaron Bahmer
> > Sent: Monday, April 14, 2014 6:22 PM
> > To: openssl-users@openssl.org
> > Subject: New and bleeding - Install Win64 problems
> >
> > Sorry for the newbie question, but the archives didn't provide me any
> > help. I'm dealing with the heartbleed bug, so updating openssl from
> > 1.0.1e to 1.0.1g on a Windows box where I run Apache/Tomcat.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

CVE-2010-5298 and 0.9.8

[no_spam_98]

It appears that the NIST NVD entry for CVE-2010-5298 may be incorrect.  This 
issue seems to affect 1.0.0+.  Nothing earlier - specifically 0.9.8, correct?

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

RE: SSL_ERROR_SYSCALL errno=0

[Carl Young]

This thread have any relevance to you?

http://stackoverflow.com/questions/12885680/pem-read-rsaprivatekey-returns-illegal-seek-when-decrypting-using-openssl-libs



From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on 
behalf of hhachem [hamze.hac...@deos-ag.com]
Sent: 15 April 2014 10:07
To: openssl-users@openssl.org
Subject: Re: SSL_ERROR_SYSCALL errno=0

Strace shows the following before the error:


ioctl(10, TCGETS, 0x7fffe068)   = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x300
26000
_llseek(0xa, 0, 0, 0x7fffe2f8, 0x1) = -1 ESPIPE (Illegal seek)




--
View this message in context: 
http://openssl.6102.n7.nabble.com/SSL-ERROR-SYSCALL-errno-0-tp49462p49464.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: help upgrading to 1.0.1g

[Ricardo Villegas]

First of all, what system are you using?

 

  _  

From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of
laxminarayana.ganes...@maersk.com
Sent: Tuesday, April 15, 2014 1:40 AM
To: openssl-users@openssl.org
Subject: help upgrading to 1.0.1g

 

Hi Team,

 

Please provide me steps to download and upgrade to 1.0.1g.

Thanks in advance

 

Regards,

LaxmiNarayana

System Specialist, MDS - Operations

Maersk Drilling IT

Maersk Drilling, Maersk FPSOs, Maersk Supply Service

A.P. Moller - Maersk A/S

286/1, Prince Infocity, 7th Floor, Old Mahabalipuram road, Kandanchavadi,
Chennai - 600096, India.

(O)+91-44-66934000 | Extn: 5230 | (M) +91-9600091332

 

 

 

  _  


The information contained in this message is privileged and intended only
for the recipients named. If the reader is not a representative of the
intended recipient, any review, dissemination or copying of this message or
the information it contains is prohibited. If you have received this message
in error, please immediately notify the sender, and delete the original
message and attachments.

Please consider the environment before printing this email.

Re: SSL_ERROR_SYSCALL errno=0

[hhachem]

Strace shows the following before the error:


ioctl(10, TCGETS, 0x7fffe068)   = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x300
26000
_llseek(0xa, 0, 0, 0x7fffe2f8, 0x1) = -1 ESPIPE (Illegal seek)




--
View this message in context: 
http://openssl.6102.n7.nabble.com/SSL-ERROR-SYSCALL-errno-0-tp49462p49464.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

SSL_ERROR_SYSCALL errno=0

[hhachem]

Hello,

I have an issue, that I've been trying to resolve for weeks now. I have 2
devices. The major different between them is the linux Kernel version. On
Linux 2.6.24.6, ssl_connect() works flawlessly. On 2.4.21 it returns -1. The
SSL_get_error() returns SSL_ERROR_SYSCALL but errno is 0 (perror() prints
"Success"). Does anyone have a solution for this?



--
View this message in context: 
http://openssl.6102.n7.nabble.com/SSL-ERROR-SYSCALL-errno-0-tp49462.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

help upgrading to 1.0.1g

[Laxminarayana.Ganeshan]

Hi Team,

Please provide me steps to download and upgrade to 1.0.1g.
Thanks in advance

Regards,
LaxmiNarayana
System Specialist, MDS - Operations
Maersk Drilling IT
Maersk Drilling, Maersk FPSOs, Maersk Supply Service
A.P. Moller - Maersk A/S
286/1, Prince Infocity, 7th Floor, Old Mahabalipuram road, Kandanchavadi, 
Chennai - 600096, India.
(O)+91-44-66934000 | Extn: 5230 | (M) +91-9600091332





The information contained in this message is privileged and intended only for 
the recipients named. If the reader is not a representative of the intended 
recipient, any review, dissemination or copying of this message or the 
information it contains is prohibited. If you have received this message in 
error, please immediately notify the sender, and delete the original message 
and attachments.

Please consider the environment before printing this email.

Aw: Re: Converting a root certificate from md5 to sha1

[steffo76]

>You need to generate a new certificate with the same data (except a
>different serial number and a reference to sha1WithRSAEncryption),
>containing the same public key, and signed with the same private key.
>
>I'd recommend sha256WithRSAEncryption, but that's possibly not an
>option for you.
>
>Make sure that you do not reuse the same serial number, it *will*
>cause problems (particularly for such software as Firefox, but also
>for anything that's written in an X.509-pedantic mode).
>
>-Kyle H

Okay, thanks. Would this mean that I need to replace the old root cert with the 
new one on all clients ? I have certificates that are already in use and the 
new root cert would have a start date of today, wouldn't it confuse the client 
when the start date of the cert is older than that of the root cert ?

Also I managed to convert the existing root cert from md5 to sha1 with 

openssl x509 -sha1 -inform pem -outform pem -in cacert.pem -out cacertsha1.pem 
-signkey cakey.pem

this recreates the cert with sha1 but it also resets the startdate to . I 
tried using -startdate and -enddate but openssl moans that it doesn't recognize 
the date as option. I tried 'Jan 01 10:37:30 2014 GMT' as well as the 
YYMMDDHHMMSSZ, both don't work. 

Thanks,
Stephan

>On Tue, Apr 15, 2014 at 1:41 AM,  wrote:
>> Hello world,
>>
>> I am running my own little CA and the root certificate was created using md5:
>>
>> Signature Algorithm: md5WithRSAEncryption
>>
>> I need to change this do sha1 because I have clients that do not accept md5 
>> anymore. Is there any way to convert the existing cert from md5 to sha1 ? I 
>> tried converting it to another format and then reimporting it using -sha1 
>> but this doesn't work.
>>
>> Thanks,
>> Stephan


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

Re: Could openssl foundation give itself rules not to accept money from intelligence agencies?

[Steve Marquess]

On 04/14/2014 03:01 PM, Benjamin Schulz wrote:
> 
> Hello, 
> The openssl foundation writes here: 
> 
> https://www.openssl.org/support/acknowledgments.html 
> 
> ...
> 
> So I think the openssl foundation should take some measures that perhaps may 
> help to scare intelligence agencies away from openssl in the future. 
> 
> 
> Could the openssl foundation add official rules that ...

This has already been ably addressed by another commenter, but I'll make
three comments:

1) OSF has as its singular purpose the objective of *relieving* those
who do the heavy lifting on OpenSSL from financial worries and
temptations. Any of the OpenSSL team could earn a lot more money
elsewhere for the hours they spend on OpenSSL. Frankly I find it
ludicrous to think that any of them could be bribed to deliberately
corrupt OpenSSL.

2) As the paper-shuffler for OSF I will consider revenue from any
source. It was my hope from the beginning that the bulk of that revenue
would come from software support contracts, which carry no obligation to
code anything at all. Those are becoming a larger portion of our
revenues, but in the meantime most revenues come from "work-for-hire"
commercial contracting. That will continue until such time as there is a
better alternative.

3) It is the consensus and (unwritten) policy of the OpenSSL team that
U.S. citizens do not have commit access to the OpenSSL code repository.
Even though I am a U.S. citizen I agree with that policy, for three
reasons: 1) given recent events the issue of perceptions does matter, we
don't need that distraction, 2) U.S. export controls make it challenging
for U.S. citizens to work on cryptography (BTDT myself), 3) it gives me
a handy excuse to avoid admitting that I'm not smart enough to work on
the code.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Could openssl foundation give itself rules not to accept money from intelligence agencies?

[Michael Wojcik]

> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Benjamin Schulz
> Sent: Monday, 14 April, 2014 15:01
> 
> Could the openssl foundation add official rules that

This list is probably not the place to discuss this at any length, but I for 
one find these proposed "rules" foolish, naive, counterproductive, impractical, 
and unlikely to achieve anything useful.

> a) it is not accepting money from intelligence agencies or companies that
> work for intelligence agencies and that, if it turned out, a given money
> comes from intelligence agencies or a contractor of them, the openssl
> foundation will return the money, and that this applies even to all earlier
> donations.

I propose an amendment: "Benjamin Schulz, and others who believe this is a good 
idea, particularly the bit about 'earlier donations', will donate funds to 
openssl.org in the amount rejected or returned".

> b) that developers of openssl are not allowed to do contracting work for
> intelligence agencies and companies working for intelligence agencies, and
> that if it turned out a developer had such contracts, he may no longer work
> for openssl, and that this applies also for earlier contracts of the openssl
> developers.

So if, say, the NSA decides to use Akamai as an edge server for their site, 
then OpenSSL has to remove the memory-protection code supplied by Rich Salz? 
Brilliant.

> c) that the names of all companies who hire openssl developers must be
> published in the open on the openssl homepage, and that this applies also for
> the companies who hired openssl developers earlier

Because there's no way for the evil masterminds of shadowy security agencies to 
disguise their affiliations...

> d) that the companies who make donations to openssl will be published in the
> open on the openssl homepage and that this applies also for the companies who
> donated to openssl earlier.

...or to hide a money trail.

And as for "companies who donated to openssl earlier": Violating a prior 
agreement and the trust of people who donated to your organization to satisfy 
the paranoia of random users is a fair trade?

> e) and that donnations above a certain value, or a person donating very often
> is named publicly on the openssl website.

What part of your threat model could this possibly address? (Let's leave aside 
for the moment the question of whether that threat model is at all realistic or 
sensible.) What's the vulnerability here? That some intelligence agency will 
donate so much money to OpenSSL.org or the OSF that the OpenSSL developers will 
deliberately introduce backdoors for them? Aren't there dozens of easier, less 
detectable ways to suborn developers - from direct bribes (why go through the 
organization?) to threats to blackmail to ideological persuasion? Either 
OpenSSL developers are corruptible or they aren't - donating money to the 
organization is surely one of the clumsier ways to attempt to corrupt them.

> If you incorporate these rules ito the openssl foundation, it may help to
> scare intelligence agencies away from openssl, since these agencies hate
> nothing more than publicity.

What a peculiar fantasy.

Certainly intelligence agencies (ones with SIGINT remits, anyway) have an 
interest in defeating OpenSSL, just as they do with any secure-communications 
implementation. And yes, as both an operational imperative and a matter of 
habit, they like to limit their public exposure. But none of your proposed 
rules impose any significant barrier to anything those agencies might do today.

As everyone knows, OpenSSL included Dual_EC_DRBG at the request of a paying 
customer. It happened to be a broken implementation, and no one noticed, 
because there wasn't any reason to use it; but there's no reason to believe 
that paying customer was a front for some intelligence agency. Customers ask 
for all sorts of things.

How is OpenSSL.org or the OSF supposed to determine whether a customer "work[s] 
for an intelligence agency"? What constitutes "working for" an agency? If an 
agency purchases software from my employer, does that mean I work for such an 
agency? What kind of resources is OSF meant to devote to performing background 
checks on its customers?

And what's to stop an agency from operating through a proxy that has no public 
connection to the intelligence industry? Nothing, that's what.

> Is it possible for the openssl foundation to do this?

Oh, sure. They're swimming in cash. What can't you do with $2000 a year?

> And by the way:
> Is there a book or something where one can learn the programming of openssl?

I'd suggest starting with Rescorla's /SSL and TLS/ and Schneier's /Applied 
Cryptography/. For the code that handles ASN.1 DER parsing and generation (for 
X.509 certificate handling and some of the PKCS standards), there are a number 
of good online resources, such as:

http://www.zytrax.com/books/ldap/apb/asn1.pdf

> I know a bit C++ and C and would

Re: Help me for ECDHE algorithm

[Matt Caswell]

On 15 April 2014 05:40, chetan  wrote:
> Thanks to you...it's working.
> Now i have one last query for you.
> I'm generating public and private key files using command line openssl. I
> generated 2 .PEM files each for public and private key.
> Now i want to generate shared secret from that files using APIs like
> EVP_PKEY_derive and others. So,Can i do like this or not?
> If yes than how?
> thanks once again for help.
>

There are functions to read and write PEM files. See:
https://www.openssl.org/docs/crypto/pem.html

In particular see the functions:
PEM_read_PUBKEY
and
PEM_read_PrivateKey

There is a discussion on EC Key files on the wiki here:
http://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations

However, note that if both sides of your communication are reading
from key files (and reusing those key files), then you are not doing
ECDHE (as is in the subject of this thread) - you're just doing ECDH.

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

Re: Converting a root certificate from md5 to sha1

[Kyle Hamilton]

You need to generate a new certificate with the same data (except a
different serial number and a reference to sha1WithRSAEncryption),
containing the same public key, and signed with the same private key.

I'd recommend sha256WithRSAEncryption, but that's possibly not an
option for you.

Make sure that you do not reuse the same serial number, it *will*
cause problems (particularly for such software as Firefox, but also
for anything that's written in an X.509-pedantic mode).

-Kyle H

On Tue, Apr 15, 2014 at 1:41 AM,   wrote:
> Hello world,
>
> I am running my own little CA and the root certificate was created using md5:
>
> Signature Algorithm: md5WithRSAEncryption
>
> I need to change this do sha1 because I have clients that do not accept md5 
> anymore. Is there any way to convert the existing cert from md5 to sha1 ? I 
> tried converting it to another format and then reimporting it using -sha1 but 
> this doesn't work.
>
> Thanks,
> Stephan
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-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: Converting a root certificate from md5 to sha1

[Hanno Böck]

I don't know the answer to your main question, but:

On Tue, 15 Apr 2014 10:41:20 +0200
steff...@gmx.de wrote:

> I need to change this do sha1 because I have clients that do not
> accept md5 anymore.

If you use SHA256 you won't have to do this again in a few years.
(Microsoft announced to deprecated sha1 signed certs at some point)

> Is there any way to convert the existing cert
> from md5 to sha1 ? I tried converting it to another format and then
> reimporting it using -sha1 but this doesn't work.

I think it should be somehow possible to create a cert with all the
same parameters and just a new signature, but I'm not sure. Others may
know more.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


signature.asc
Description: PGP signature

Converting a root certificate from md5 to sha1

[steffo76]

Hello world,

I am running my own little CA and the root certificate was created using md5: 

Signature Algorithm: md5WithRSAEncryption

I need to change this do sha1 because I have clients that do not accept md5 
anymore. Is there any way to convert the existing cert from md5 to sha1 ? I 
tried converting it to another format and then reimporting it using -sha1 but 
this doesn't work.

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