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 ha
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
(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
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 th
@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 th
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 MAC
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
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 Win
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 dynami
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-op
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
> 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
__
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
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 mig
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?
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
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
> 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 p
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: sha1WithRSAEncryptio
> 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 me
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
> 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
__
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
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
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 st
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 t
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,
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 seem
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
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
> 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
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
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, Camb
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
> 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 Wo
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
> 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
> 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.i
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
> 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:
>
> 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 th
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,
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
> file
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
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.
--
Vikt
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... wh
> 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.
___
n 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
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.
O
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
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 ri
> 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 yo
> 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
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_m
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.co
> 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
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 k
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.o
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 buffe
-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_CI
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>
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 s
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 primiti
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 li
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 comin
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
66 matches
Mail list logo
