If you don't know or care what FIPS 140-2 is, trash this message quickly
before it harshes your mellow.
The "RE" validation, an "Alternative Scenario 1A" clone of the #1747
validation, was approved today
(http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473).
It was submitted
Sorted; needed to call SSL_CTX_set_tmp_ecdh with my private EC_KEY. Can
someone express an opinion if using my private key is acceptable there, or
if I should generate a new one from a named curve each time I create a
context?
Cheers,
--B
On Fri, Nov 13, 2015 at 11:21 AM, Benn Bollay wrote:
>
> Rfc5246 basically says that the server will choose the highest version but I
> wanted to confirm that that's what openssl does (just to be certain).
That is what openssl does.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mai
Hi folks -
Tested against OpenSSL 1.0.1f and 1.0.1p (but with modifications).
I've got some code that creates an SSL_CTX (http://pastebin.com/XveDvvch)
that works fine for negotiating ECDHE-* ciphers as a client when talking to
an s_server, but fails as a server both when accepting connections fr
Hi everybody,
I'm new with OpenSSL and I have some questions.
The thing is that several RSA key pairs (each one for a
different user) will be stored in a shared secured location (Safenet HSM).
As the key pairs will be stored in the same place, we are looking
> ALL BINARY ELLIPTIC CURVES
This one may be premature.
I understand the TLS WG is moving against it. However, I am aware of
implementations of Shoup's ECIES, and they, in turn, depend on
OpenSSL. I don't know if the ECIES implementations rely solely on
prime fields or not, however.
> BLOWFISH -
On Wed, Nov 11, 2015, jonetsu wrote:
> Hello,
>
>
> There is a thread in 2013 (30 May 03:15) in which Steve writes that OpenSSL
> 1.0.1 has a bug regarding the use of PKCS12 in FIPS mode since it tries to
> handle a certificate using a non-FIPS component. I think I found the commit
> that fi
On Fri, Nov 13, 2015, Benjamin Kaduk wrote:
>
> As another thread calls to mind, PKCS#12 could potentially just use
> triple-DES. (BTW, the CMS tests fail when openssl is configured with
> no-rc2, due to this; I have a WIP patch sitting around.)
>
The issue is that some cuurent software (inclu
On 13/11/2015 18:00, Benjamin Kaduk wrote:
On 11/13/2015 09:31 AM, Jakob Bohm wrote:
On 13/11/2015 14:40, Emilia Käsper wrote:
Hi all,
We are considering removing from OpenSSL 1.1 known broken or
outdated cryptographic primitives. As you may know the forks have
already done this but I'd like
On 11/13/2015 09:31 AM, Jakob Bohm wrote:
> On 13/11/2015 14:40, Emilia Käsper wrote:
>> Hi all,
>>
>> We are considering removing from OpenSSL 1.1 known broken or outdated
>> cryptographic primitives. As you may know the forks have already done
>> this but I'd like to seek careful feedback for Ope
On 11/13/2015 10:14 AM, jonetsu wrote:
> Hello,
>
>
> I would like to see the bug fix for RT3515 'Use 3DES in pkcs12 if built with
> no-rc2' although the opnssl tree I got recently does not show it:
The bug fix is just the patch contained in the initial submission.
>
> % git status
> On branch
> Is there a up to date list of elliptic curves approved or recommended for
> government use in OpenSSL?
You'll have to look outside OpenSSL for advice like that.
I would suggest looking at the CFRG, part of the IETF basically. Do web search
for curve recommendations.
Good luck. It's a conte
Hello,
I would like to see the bug fix for RT3515 'Use 3DES in pkcs12 if built with
no-rc2' although the opnssl tree I got recently does not show it:
% git status
On branch master
Your branch is up-to-date with 'origin/master'.
% git show 92830dc1ca0bb2d12bf05a12ebb798709595fa5a
fatal: bad
On 13/11/2015 14:40, Emilia Käsper wrote:
Hi all,
We are considering removing from OpenSSL 1.1 known broken or outdated
cryptographic primitives. As you may know the forks have already done
this but I'd like to seek careful feedback for OpenSSL first to ensure
we won't be breaking any major a
Hi Wim,
I'll give this a shot, thank you for the suggestion!
-Peter
On Wed, Nov 11, 2015 at 5:05 PM, Wim Lewis wrote:
>
> On Nov 9, 2015, at 3:46 PM, Peter P. wrote:
> > I'm writing an application using Openssl 1.0.2d where I am trying to
> take a DER encoded unsigned CSR and read it into an
Hi all,
We are considering removing from OpenSSL 1.1 known broken or outdated
cryptographic primitives. As you may know the forks have already done this
but I'd like to seek careful feedback for OpenSSL first to ensure we won't
be breaking any major applications.
These algorithms are currently ca
Thank you kindly Matt, for the pointers - these connections always end with
that renegotiation and subsequent failure - I suspect there is a ciphersuite
problem and am following up to see what the client *will* support.Paul H.
--
View this message in context:
http://openssl.6102.n7.nabble.com/B
On 13/11/2015 10:34, Matt Caswell wrote:
On 13/11/15 02:56, pratyush parimal wrote:
Hi,
I'm writing a client-server program that uses TLS for communication.
I'm wondering if there's any way to programmatically find out which TLS
protocol versions are supported by the OpenSSL library installed o
Hey,
this is on fedora 23, though I built openssl 1.0.1k (since it is the
version supported on rhel 6)
These are the specific test cases that are failing with openssl for us:
https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n1948
https://git.gnome.org/browse/g
On 13/11/15 08:37, Ignacio Casal wrote:
> Hey guys,
>
> I am having a specific problem that I do not seem to find a solution for.
>
> - I have a server and a client that handshake properly
> - the server will read from the client and the client from the server a
> few bytes
> - the client will
On 13/11/15 02:56, pratyush parimal wrote:
> Hi,
>
> I'm writing a client-server program that uses TLS for communication.
> I'm wondering if there's any way to programmatically find out which TLS
> protocol versions are supported by the OpenSSL library installed on my
> system.
>
> I'm currentl
Hey guys,
I am having a specific problem that I do not seem to find a solution for.
- I have a server and a client that handshake properly
- the server will read from the client and the client from the server a few
bytes
- the client will try to read again
- the server will try to handshake again
22 matches
Mail list logo
