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
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
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
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
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
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
In message CALiegfmvaG-nc=putyxey20otoiow6op+lajohnoqxf86aw...@mail.gmail.com
on Mon, 8 Sep 2014 18:19:09 +0200, Iñaki Baz Castillo i...@aliax.net 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
-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
And of course, I noticed this email after sending my own... sorry.
In message CALiegf=BytJ-1ZDzcCw3=e2=6moritr87pjunro4cxorysy...@mail.gmail.com
on Mon, 8 Sep 2014 18:41:40 +0200, Iñaki Baz Castillo i...@aliax.net said:
ibc 2014-09-08 18:35 GMT+02:00 Kyle Hamilton aerow...@gmail.com:
ibc The
2014-09-09 10:46 GMT+02:00 Richard Levitte rich...@levitte.org:
And of course, I noticed this email after sending my own... sorry.
:)
Thanks a lot.
--
Iñaki Baz Castillo
i...@aliax.net
__
OpenSSL Project
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
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
On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall f...@sbcglobal.net 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:
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
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
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
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
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
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.
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
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.
2014-09-09 13:14 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com:
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
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
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
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
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:
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
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:
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
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
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
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 rs...@akamai.com:
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,
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
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
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 rs...@akamai.com:
We disagree. I've got two IETF WG's coming to the same conclusion so
making post-1.0.2 follow IETF
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,
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
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
2014-09-09 17:58 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com:
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
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 openssl-us...@dukhovni.org:
On Tue, Sep
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
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
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:
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:
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
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
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
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
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
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 :)
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
Thanks Jacob for your response. Very informative indeed!
Thanks
-Prasad
Sent from my iPhone
On 09-Sep-2014, at 10:05 pm, Jakob Bohm jb-open...@wisemo.com wrote:
On 09/09/2014 09:01, Prasad Dabak wrote:
Thanks Jacob for an elaborate answer. Somehow I never received your response
to my
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:
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 bug...@seanet.com escribió:
In the FWIW column
Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL
from Python (and
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
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
On Tue, Sep 9, 2014 at 2:42 PM, Iñaki Baz Castillo i...@aliax.net 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
@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
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
(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
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,
62 matches
Mail list logo
