On Wed, Apr 12, 2017 at 1:26 PM, Salz, Rich via openssl-dev
wrote:
>> Did the no-fips option get removed by-design? Are the no-* corollaries going
>> to be dropped going forwards?
>
> Yes. All FIPS support was removed. It could be brought back, and made a
> no-op, if that's a real issue.
It is
Hi Bill,
William A Rowe Jr in gmane.comp.encryption.openssl.devel (Wed, 12 Apr
2017 13:09:05 -0500):
>Did the no-fips option get removed by-design? Are the no-*
>corollaries going to be dropped going forwards?
>
>../src/openssl-1.1.0git/config shared no-fips --libdir=lib
>--prefix=/opt/openssl110
> Yes. All FIPS support was removed. It could be brought back, and made a
> no-op, if that's a real issue.
By it, I meant the "no-fips" option
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> Did the no-fips option get removed by-design? Are the no-* corollaries going
> to be dropped going forwards?
Yes. All FIPS support was removed. It could be brought back, and made a
no-op, if that's a real issue.
There are no plans to remove any other no-* at this time.
--
openssl-dev mailin
Did the no-fips option get removed by-design? Are the no-*
corollaries going to be dropped going forwards?
../src/openssl-1.1.0git/config shared no-fips --libdir=lib
--prefix=/opt/openssl110
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring OpenSSL version 1.1.0f-d
On 12/04/17 00:20, Michael Reilly wrote:
> Unfortunately the check breaks code which doesn't know nor need to know the
> keysize. The engine takes care of allocating buffers required.
So how does EVP_SignFinal() work with your engine? The "sig" parameter
is supposed to be allocated by the calle
It seems like a more elegant option would be if there was some attribute
of the engine that could be queried and override the check against zero.
-Ben
On 04/11/2017 06:20 PM, Michael Reilly wrote:
> Unfortunately the check breaks code which doesn't know nor need to know the
> keysize. The engine
Unfortunately the check breaks code which doesn't know nor need to know the
keysize. The engine takes care of allocating buffers required.
Leaving it set to 0 has not broken anything yet. I supposed we could try to
somehow set it to an arbitrary non-zero value to please the == 0 check.
michael
On Tue, Apr 11, 2017, Michael Reilly wrote:
> Hi,
>
> commit 222333cf01e2fec4a20c107ac9e820694611a4db added a check that the size
> returned by EVP_PKEY_size(ctx->pkey) in M_check_autoarg() in
> crypto/evp/pmeth_fn.c is != 0.
>
> We are in the process of upgrading from 1.0.2j to 1.0.2k and disco
Hi,
commit 222333cf01e2fec4a20c107ac9e820694611a4db added a check that the size
returned by EVP_PKEY_size(ctx->pkey) in M_check_autoarg() in
crypto/evp/pmeth_fn.c is != 0.
We are in the process of upgrading from 1.0.2j to 1.0.2k and discovered that the
if (pksize == 0) check added in 1.0.2k break
Got it, thanks :)
On Mon, Mar 21, 2016 at 8:09 PM, Dmitry Belyavsky wrote:
> Dear John,
>
> On Mon, Mar 21, 2016 at 2:52 PM, John Hunter wrote:
>>
>> Hi Dmitry,
>> Thank you for you quick reply.
>>
>> On Mon, Mar 21, 2016 at 7:38 PM, Dmitry Belyavsky
>> wrote:
>> > Hello John,
>> >
>> > On Mon,
Dear John,
On Mon, Mar 21, 2016 at 2:52 PM, John Hunter wrote:
> Hi Dmitry,
> Thank you for you quick reply.
>
> On Mon, Mar 21, 2016 at 7:38 PM, Dmitry Belyavsky
> wrote:
> > Hello John,
> >
> > On Mon, Mar 21, 2016 at 1:53 PM, John Hunter wrote:
> >>
> >> I know that this question had been a
Hi Dmitry,
Thank you for you quick reply.
On Mon, Mar 21, 2016 at 7:38 PM, Dmitry Belyavsky wrote:
> Hello John,
>
> On Mon, Mar 21, 2016 at 1:53 PM, John Hunter wrote:
>>
>> I know that this question had been asked millions of times, I searched the
>> maillist archives and I know it, and this i
Hello John,
On Mon, Mar 21, 2016 at 1:53 PM, John Hunter wrote:
> I know that this question had been asked millions of times, I searched the
> maillist archives and I know it, and this is not a homework for an academic
> project, trust me :)
>
> In [1], Victor said that we don't need to rebuild
I know that this question had been asked millions of times, I searched the
maillist archives and I know it, and this is not a homework for an academic
project, trust me :)
In [1], Victor said that we don't need to rebuild OpenSSL just for adding a
crypto algrorithm, and he recoment to see the ccgo
In message <56c27dc0.3030...@oracle.com> on Tue, 16 Feb 2016 01:39:12 +,
Jeremy Farrell said:
jeremy.farrell> Thanks Richard - it was just a thought, and clearly not a very
helpful
jeremy.farrell> one. The rest of the proposal looks like a good improvement to
me.
Quite all right. It answ
On 15/02/2016 23:16, Richard Levitte wrote:
In message <20160215.185953.117619649162395329.levi...@openssl.org> on Mon, 15 Feb
2016 18:59:53 +0100 (CET), Richard Levitte said:
levitte> In message <56c210e7.5080...@oracle.com> on Mon, 15 Feb 2016 17:54:47 +,
Jeremy Farrell said:
levitte>
In message <20160215.185953.117619649162395329.levi...@openssl.org> on Mon, 15
Feb 2016 18:59:53 +0100 (CET), Richard Levitte said:
levitte> In message <56c210e7.5080...@oracle.com> on Mon, 15 Feb 2016 17:54:47
+, Jeremy Farrell said:
levitte>
levitte> jeremy.farrell> It sounds good, exce
In message <56c210e7.5080...@oracle.com> on Mon, 15 Feb 2016 17:54:47 +,
Jeremy Farrell said:
jeremy.farrell>
jeremy.farrell>
jeremy.farrell> On 15/02/2016 12:29, Richard Levitte wrote:
jeremy.farrell> > In message <20160215122509.ga15...@calimero.vinschen.de> on
Mon, 15
jeremy.farrell> >
On 15/02/2016 12:29, Richard Levitte wrote:
In message <20160215122509.ga15...@calimero.vinschen.de> on Mon, 15 Feb 2016 13:25:09
+0100, Corinna Vinschen said:
vinschen> On Feb 15 13:03, Richard Levitte wrote:
vinschen> > So here is what I'm thinking...
vinschen> >
vinschen> > - engines in 1
In message <20160215122509.ga15...@calimero.vinschen.de> on Mon, 15 Feb 2016
13:25:09 +0100, Corinna Vinschen said:
vinschen> On Feb 15 13:03, Richard Levitte wrote:
vinschen> > So here is what I'm thinking...
vinschen> >
vinschen> > - engines in 1.1 should be named FOO.{suffix} (for an engine
On Feb 15 13:03, Richard Levitte wrote:
> So here is what I'm thinking...
>
> - engines in 1.1 should be named FOO.{suffix} (for an engine FOO and
> whatever suffix is conventional on the platform at hand, be it .so,
> .dll, .sl, .dylib...)
> - the OpenSSL DSO module should be changed to have
In message <20160215113936.ga9...@calimero.vinschen.de> on Mon, 15 Feb 2016
12:39:36 +0100, Corinna Vinschen said:
vinschen> On Feb 15 12:11, Richard Levitte wrote:
vinschen> > Hi Corinna,
vinschen> >
vinschen> > In message <20160215105045.ga7...@calimero.vinschen.de> on Mon, 15
Feb 2016 11:50
On Feb 15 12:11, Richard Levitte wrote:
> Hi Corinna,
>
> In message <20160215105045.ga7...@calimero.vinschen.de> on Mon, 15 Feb 2016
> 11:50:45 +0100, Corinna Vinschen said:
>
> vinschen> > Cygwin: cygcapi.dll
> vinschen>
> vinschen> I can't speak for Mingw, but on Cygwin the modules are ca
Hi Corinna,
In message <20160215105045.ga7...@calimero.vinschen.de> on Mon, 15 Feb 2016
11:50:45 +0100, Corinna Vinschen said:
vinschen> > Cygwin: cygcapi.dll
vinschen>
vinschen> I can't speak for Mingw, but on Cygwin the modules are called
libFOO.so,
vinschen> e.g.
vinschen>
vinschen> /
Hi Richard,
On Feb 15 01:11, Richard Levitte wrote:
> Hi,
>
> I've got a question to the Cygwin / Mingw community, regarding the
> naming of dynamic engines.
>
> >From looking at Makefile.shared et al, the engines get the same kind
> of prefixes as a standard shared library (but without the acco
best and second best are pretty equal here.Pete-"openssl-dev" <openssl-dev-boun...@openssl.org> wrote: -To: openssl-dev@openssl.orgFrom: Richard Levitte Sent by: "openssl-dev" Date: 02/15/2016 10:13AMSubject: [openssl-dev] Question about dynamically loadable engines
Hi,
I've got a question to the Cygwin / Mingw community, regarding the
naming of dynamic engines.
>From looking at Makefile.shared et al, the engines get the same kind
of prefixes as a standard shared library (but without the accompanying
import library, of course). So the capi engine gets named
> I have a simple question:
>
> - Is the “*BN_MUL*” algorithm based on *Karatsuba*?
>
> - If YES please confirm, otherwise could you please explain me what
> algorithm is using?
And 'grep Karatsuba crypto/bn/*.c' in not an option? But answer to
question might be irrelevant. Because on most popul
Hi,
I have a simple question:
- Is the "BN_MUL" algorithm based on Karatsuba?
- If YES please confirm, otherwise could you please explain me what algorithm
is using?
Thank you
aa
[cid:image003.png@01D12DB8.62D5DBB0]
Antonio Ascrizzi, PhD
MM CTO
System and SW Engineering Center - Se
We can't help you with legal matters:
https://www.openssl.org/docs/faq.html#LEGAL1
Please note that this tracker is for bug reports.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 01/14/2014 07:12 AM, Aaron wrote:
> Hi All,
>
> We have upgraded our OpenSSL from 9.0.8b to OpenSSL 1.0.1e. We have
> encountered some thread issues. From releated OpenSSL document
> (http://www.openssl.org/docs/crypto/threads.html), we see the following
> description.
>
> /CRYPTO_THREADID and
>> Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind
>> error. But this isn't a valid fix since bn_get_bits5 no longer returns
>> the correct data. My assembly skills are near nil. Maybe someone else
>> can propose a valid fix.
>>
>> Having said this, this does show the prob
Andy Polyakov writes:
>> Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind
>> error. But this isn't a valid fix since bn_get_bits5 no longer returns
>> the correct data. My assembly skills are near nil. Maybe someone else
>> can propose a valid fix.
>>
>> Having said this
> Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind
> error. But this isn't a valid fix since bn_get_bits5 no longer returns
> the correct data. My assembly skills are near nil. Maybe someone else
> can propose a valid fix.
>
> Having said this, this does show the problem a
I'm looking into it and have a quick note.
> Could this be the issue your seeing? It was fixed in boringssl I think.
> https://boringssl.googlesource.com/boringssl/+/bf681a40d6142edfa44a27dc0d6e07e0c37865a4
> https://boringssl-review.googlesource.com/#/c/1393/
The reason for why that solution is
Kurt Cancemi writes:
> Could this be the issue your seeing? It was fixed in boringssl I think.
> https://boringssl.googlesource.com/boringssl/+/bf681a40d6142edfa44a27dc0d6e07e0c37865a4
> https://boringssl-review.googlesource.com/#/c/1393/
I haven't looked at the code (not much of an x86 assemble
Could this be the issue your seeing? It was fixed in boringssl I think.
https://boringssl.googlesource.com/boringssl/+/bf681a40d6142edfa44a27dc0d6e07e0c37865a4
https://boringssl-review.googlesource.com/#/c/1393/
---
Kurt Cancemi
https://www.x64architecture.com
On Wed, May 13, 2015 at 1:19 PM, Joh
Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind
error. But this isn't a valid fix since bn_get_bits5 no longer returns
the correct data. My assembly skills are near nil. Maybe someone else
can propose a valid fix.
Having said this, this does show the problem appears to be
Sorry for misinterpreting your question, my mistake. I was able to
replicate the error. It looks like the invalid read is in code that's
compiled in when OPENSSL_BN_ASM_MONT5 is set, which is only for the
X86_64 target. Looking at the diff of x86_64-mont5.pl between 1.0.1 and
1.0.2, there are qui
Upon further investigation, it looks like the problem is in your sample
code. You need to invoke CRYPTO_cleanup_all_ex_data() before
terminating your program.
On 05/13/2015 07:25 AM, Henrik Grindal Bakken wrote:
> Hi. I have an application that generates Diffie-Hellman key pairs based
> on some
John Foley writes:
> If you add the --show-reachable option to valgrind, you can see where
> the leaks originate. They appear to be in the ex_data code (see
> below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f
> as well as 1.0.2a.
Ah, I forgot to mention. I'm not concerned
If you add the --show-reachable option to valgrind, you can see where
the leaks originate. They appear to be in the ex_data code (see
below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f
as well as 1.0.2a.
==18173== HEAP SUMMARY:
==18173== in use at exit: 416 bytes in 6 blo
Hi. I have an application that generates Diffie-Hellman key pairs based
on some precomputed primes.
In 1.0.1 (and earlier) this works just fine, while in 1.0.2 it gives
valgrind errors (while still working).
The error only occurs on x86_64, and it does not occur on 1024 bit DH.
I've attached t
Closing ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
lease
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Sat, Mar 07, 2015, Allauddin Ahmad via RT wrote:
> Dear Concerned:
>
> Can you please confirm that OpenSSL branch 0.9.7 branch is not affected by:
>
As Viktor mentioned 0.9.7 is no longer being maintained.
However the following two issues will be present in 0.9.7:
>
> *RSA silent
On Sat, Mar 07, 2015, Allauddin Ahmad via RT wrote:
> Dear Concerned:
>
> Can you please confirm that OpenSSL branch 0.9.7 branch is not affected by:
>
As Viktor mentioned 0.9.7 is no longer being maintained.
However the following two issues will be present in 0.9.7:
>
> *RSA silent
On Sat, Mar 07, 2015 at 06:14:17PM +0100, Allauddin Ahmad via RT wrote:
OpenSSL 0.9.7 has been unsupported for quite some time. Therefore,
as far as I know the OpenSSL team is not checking 0.9.7 to verify
whether it is or is not affected by any recent vulnerability
disclosures. It is almost cert
Dear Concerned:
Can you please confirm that OpenSSL branch 0.9.7 branch is not affected by:
*DTLS segmentation fault in dtls1_get_record (CVE-2014-3571
(CVE-2015-0206
*DTLS memory leak in dtls1_buffer_record (CVE-2015-0206)
*no-ssl3 configuration sets method to NULL (C
Hi!
I am developing a software.
I want to use the OpenSSL ECDSA library to my software.
So, I would like to know if there is a legal problem using ECDSA in Openssl.
For example, patent issues, license etc.
Can I use ECDSA library without legal problem?
Please answ
Thanks Steve and Matt. That makes sense.
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Dr. Stephen Henson
Sent: Friday, June 06, 2014 6:11 PM
To: openssl-dev@openssl.org
Subject: Re: Question about SSL/TLS MITM vulnerability
On Fri, Jun 06, 2014, Matt Caswell wrote:
> On 6 June 2014 08:27, Zhong Chen wrote:
> >
> > We are using openssl 1.0.0 as a server. Looking at the diff between 1.0.0m
> > and 1.0.0k, same patch is applied to s3_srvr.c and s3_pkt.c. I want to
> > confirm this is just for precaution, or openssl 1.0
On 6 June 2014 08:27, Zhong Chen wrote:
> Hello,
>
>
>
> In the “OpenSSL Security Advisory [05 Jun 2014]”, regarding “SSL/TLS MITM
> vulnerability (CVE-2014-0224)”, it says:
>
>
>
> Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1.
> Usersof OpenSSL servers earlier than 1.0
Hello,
In the "OpenSSL Security Advisory [05 Jun 2014]", regarding "SSL/TLS MITM
vulnerability (CVE-2014-0224)", it says:
Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1.
Usersof OpenSSL servers earlier than 1.0.1 are advised to upgrade as a
precaution.
We are us
e to change all calls to
CRYPTO_set_id_callback(), CRYPTO_get_id_callback(), and CRYPTO_thread_id()
in our code to CRYPTO_THREADID routines?
Thanks so much,
Aaron
--
View this message in context:
http://openssl.6102.n7.nabble.com/A-Question-about-CRYPTO-THREADID-when-upgrading-to-OpenSSL-1-0-1e-tp
On Tue, Oct 29, 2013, Salz, Rich wrote:
> > You don't and shouldn't free it: it will be free when the SSL_CTX it is
> > added to is freed.
>
> In other words, if you want a local copy, bump the refcount for yourself.
> Right?
>
Yes. Unfortunately there isn't a function that does that at pres
On Tue, Oct 29, 2013, Daniel Kahn Gillmor wrote:
> On 10/29/2013 02:03 PM, Dr. Stephen Henson wrote:
> >On Tue, Oct 29, 2013, ?? ??? wrote:
> >
> >> I've noticed that SSL_CTX_add_extra_chain_cert (actually
> >>ss3_ctx_ctrl (..., SSL_CTRL_EXTRA_CHAIN_CERT, ..., ...)) just pushes
> >>X509
On 10/29/2013 02:03 PM, Dr. Stephen Henson wrote:
On Tue, Oct 29, 2013, ?? ??? wrote:
I've noticed that SSL_CTX_add_extra_chain_cert (actually
ss3_ctx_ctrl (..., SSL_CTRL_EXTRA_CHAIN_CERT, ..., ...)) just pushes
X509 cert to context's cert stack. This means that I'm unable to free
or
> You don't and shouldn't free it: it will be free when the SSL_CTX it is added
> to is freed.
In other words, if you want a local copy, bump the refcount for yourself.
Right?
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
On Tue, Oct 29, 2013, ?? ??? wrote:
> Hi all!
> I've noticed that SSL_CTX_add_extra_chain_cert (actually
> ss3_ctx_ctrl (..., SSL_CTRL_EXTRA_CHAIN_CERT, ..., ...)) just pushes
> X509 cert to context's cert stack. This means that I'm unable to free
> original certificate because double me
Hi all!
I've noticed that SSL_CTX_add_extra_chain_cert (actually ss3_ctx_ctrl
(..., SSL_CTRL_EXTRA_CHAIN_CERT, ..., ...)) just pushes X509 cert to
context's cert stack. This means that I'm unable to free original
certificate because double memory freeing occurs when context is free'd
later.
I'm
Hi all!
I've noticed that SSL_CTX_add_extra_chain_cert (actually
ss3_ctx_ctrl (..., SSL_CTRL_EXTRA_CHAIN_CERT, ..., ...)) just pushes
X509 cert to context's cert stack. This means that I'm unable to free
original certificate because double memory freeing occurs when context
is free'd later.
I'm
Hi,
It appears that the code in engines/e_aep.c has an "#ifdef
SIXTY_FOUR_BIT_LONG" to decide on things like BigNumSize (right shift by
3 or by 2, etc.).
However, there is also the macro SIXTY_FOUR_BIT, which is another way to
change BN_BYTES to 8 instead of 4. Should the #ifdefs in
engine
Hello,
I am trying to cross compile FIPS compliant openssl module
(openssl-fips-ecp-2.0.2.tar.gz) for linux armv4 pratform :
I have used following script to setup the environment:
===
export MACHINE=armv4t
export RELEASE=2.6.23
export SYSTEM=Linux
expor
On 10/24/2012 11:03 PM, Munagala Ramanath wrote:
Just downloaded built openssl 1.0.1c on Ubuntu 10.04 x86_64 with the
standard commands:
./config
make
make test
All is well but I noticed that these files from 'engines' are compiled
but the resulting objects are
not put into any library:
e_4
Just downloaded built openssl 1.0.1c on Ubuntu 10.04 x86_64 with the standard
commands:
./config
make
make test
All is well but I noticed that these files from 'engines' are compiled but the
resulting objects are
not put into any library:
e_4758cca, e_aep, e_atalla, e_cswift, e_gmp, e_chil,
e_
Hi Steve,
Dr. Stephen Henson wrote:
On Wed, May 09, 2012, Jan Just Keijser wrote:
thank you for the quick reply. The code we currently use is very similar:
254 nid = OBJ_sn2nid(curve_name);
255
256 if (nid == 0)
257 msg(M_SSLERR, "unknown curve name (%s)", curve_name);
258
On Wed, May 09, 2012, Jan Just Keijser wrote:
> thank you for the quick reply. The code we currently use is very similar:
> 254 nid = OBJ_sn2nid(curve_name);
> 255
> 256 if (nid == 0)
> 257 msg(M_SSLERR, "unknown curve name (%s)", curve_name);
> 258 else
> 259 {
> 260 e
Hi ,
Dr. Stephen Henson wrote:
On Tue, May 08, 2012, Jan Just Keijser wrote:
hello list,
we're trying to add ECDH/ECDSA support to OpenVPN and we have run
into a question we cannot easily answer ourselves:
we're using SSL_CTX_set_tmp_ecdh to add an ECDH curve to your
server-side SSL CTX o
On Tue, May 08, 2012, Jan Just Keijser wrote:
> hello list,
>
> we're trying to add ECDH/ECDSA support to OpenVPN and we have run
> into a question we cannot easily answer ourselves:
>
> we're using SSL_CTX_set_tmp_ecdh to add an ECDH curve to your
> server-side SSL CTX object; this is very simi
hello list,
we're trying to add ECDH/ECDSA support to OpenVPN and we have run into a
question we cannot easily answer ourselves:
we're using SSL_CTX_set_tmp_ecdh to add an ECDH curve to your
server-side SSL CTX object; this is very similar to the DH parameters
which are added using SSL_CTX_s
On 12/08/2011 03:34 PM, Dr. Stephen Henson wrote:
On Thu, Dec 08, 2011, Peter Sylvester wrote:
Hello,
I am actually makeing corrections to the SRP/TLS code. One of them
removes an unnecessary callback. There is a pointer in a SRP_CTX that
is no longer necessary.
I wonder what is the current p
On Thu, Dec 08, 2011, Peter Sylvester wrote:
> Hello,
>
> I am actually makeing corrections to the SRP/TLS code. One of them
> removes an unnecessary callback. There is a pointer in a SRP_CTX that
> is no longer necessary.
>
> I wonder what is the current policy concerning a stable branch and
>
Hello,
I am actually makeing corrections to the SRP/TLS code. One of them
removes an unnecessary callback. There is a pointer in a SRP_CTX that
is no longer necessary.
I wonder what is the current policy concerning a stable branch and
the head? It seems that one simply would leave the useless po
On Mon, 2011-10-17 at 21:18 +, Keith Welter wrote:
> The OpenSSL FIPS 140-2 User Guide says:
> "The FIPS Object Module provides an API for invocation of FIPS approved
> cryptographic functions from calling applications, and is designed for use in
> conjunction with standard OpenSSL 0.9.8 dis
The OpenSSL FIPS 140-2 User Guide says:
"The FIPS Object Module provides an API for invocation of FIPS approved
cryptographic functions from calling applications, and is designed for use in
conjunction with standard OpenSSL 0.9.8 distributions beginning with 0.9.8j.
Note: OpenSSL 1.0.0 is not sup
On Thu, Apr 15, 2010 at 3:25 PM, Phillip Hellewell wrote:
> Why does PKCS7_decrypt() require the recipient's X509 cert? Doesn't the
> recipient's cert already exist inside the PKCS7 structure? And if there is
> more than one recipient info, can't PKCS7_decrypt() just try the private key
> again
On Thu, Apr 15, 2010 at 3:25 PM, Phillip Hellewell wrote:
> My last question is, what is the difference between PKCS7_decrypt() and
> PKCS7_dataDecode()? I couldn't find any documentation on the latter.
>
Ok, I see now that PKCS7_decrypt() is implemented in terms of
PKCS7_dataDecode(). So I'm
If these questions are better directed at openssl-users, let me know.
Phillip
On Thu, Apr 15, 2010 at 3:25 PM, Phillip Hellewell wrote:
> Why does PKCS7_decrypt() require the recipient's X509 cert? Doesn't the
> recipient's cert already exist inside the PKCS7 structure? And if there is
> more
Why does PKCS7_decrypt() require the recipient's X509 cert? Doesn't the
recipient's cert already exist inside the PKCS7 structure? And if there is
more than one recipient info, can't PKCS7_decrypt() just try the private key
against each one?
My last question is, what is the difference between PK
Hi Folks,
Would appreciate some responses for the questions below.
Most importantly-
I see the following note in
http://www.openssl.org/docs/apps/pkcs8.html
"The format of PKCS#8 DSA (and other) private keys is not well documented:
it is hidden away in PKCS#11 v2.01, section 11.9. OpenSSL's defau
Sorry there was a small typo
s/DSA_generate_keys/DSA_generate_key
Could I possibly use EVP_PKEY2PKCS8() api for the encoding?
Regards
-AG
On Fri, Mar 5, 2010 at 11:35 AM, Anand Giriraj wrote:
> Hi Folks.
> If I generate DSA private key using the following commands:
>
> DSA_generate_params()
> D
Hi Folks.
If I generate DSA private key using the following commands:
DSA_generate_params()
DSA_generate_keys()
The resulting private keys are not encoded using any of the PKCS formats,
right?. If wrong, which format are they encoded in?.
Would it be appropriate to encode them in PKCS8?. And if
I'm trying to verify a certificate using OCSP protocol that is issued by
Wisekey. I used OCSP_resp_find_status function to find certificate end user's
status:
OCSP_resp_find_status(basic, id, &status, &reason, &producedAt,&thisUpdate,
&nextUpdate) ;
This above function return 0 (V_OCSP_CERTSTATU
Dr. Stephen Henson wrote:
On Fri, Sep 11, 2009, Lin Hwang wrote:
Hi,
I am an Openssl newby. Recently I am trying to build FIPS module and FIPS
capable lib on a Linux system.
I notice that all the fips_xxxtest programs at link time all go through
fipsld and linked with a digest. I expect
On Fri, Sep 11, 2009, Lin Hwang wrote:
> Hi,
>
> I am an Openssl newby. Recently I am trying to build FIPS module and FIPS
> capable lib on a Linux system.
> I notice that all the fips_xxxtest programs at link time all go through
> fipsld and linked with a digest. I expect
> the same thing wit
Because the 'fipsld' script isn't actually necessary to pass FIPS
validation. The steps that that script does are necessary to maintain
validation, but they can be done by anything (once the FIPS canister
is created, anyway). Try setting "OPENSSL_FIPS=1" in your
environment, and make sure that th
Hi,
I am an Openssl newby. Recently I am trying to build FIPS module and
FIPS capable lib on a Linux system.
I notice that all the fips_xxxtest programs at link time all go through
fipsld and linked with a digest. I expect
the same thing with application "openssl", but I don't see it happens
ca
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@ope
On September 12, 2008 12:35:10 am JeanYiYi wrote:
> Dear openssl guru:
>
> I am new in openssl. I have some questions regarding to 'CRL Distribution
> Points extension'. I did read the RFC. but I am still confused about some
> details. :-(.
>
> a) a certificate has a 'CRL Distribution Points extens
e which only have a DirName in its 'CRL
distribution points extension'. If I reserve the setting and replace slash
with comma, I can get an DN for ldap query, right?
Thanks and looking forward to any reply.
Best Regards
Jean
--
View this message in context:
http://www.nabble.com/
Hi there,
I want to decrypt the private key generated by openssl.
I can decrypt the data in format below:
DEK-Info: DES-EDE3-CBC,xxx
But for another one:
DEK-Info: AES-256-CBC,468B07F9866989E4D6C07305761F5F07
I don't know what key and IV I should use to decrypt the key.
Any hints?
Thanks
Hi,
The KDF implementation in ecdhtest.c is based on the IEEE P1363 standard
as the rest of the implementation of ECDH in OpenSSL. It can be regarded
as a generalization of the X9.63 standard. However, the file ecdhtest.c
is not part of the OpenSSL core and thus you can provide your own
implementa
Hello,
If I understand correctly, regarding X9.63 standard (5.6.3) derive key (in
case KDF_SHA1) must be computed as
SHA1(Z || counter || [SharedInfo])
Z - secret value.
But function KDF in the file ecdhtest .c does not use counter and compute key
as:
On Tue, Feb 12, 2008, Guenter Knauf wrote:
> Hi Steve,
> just curious why enable-tlsext isnt enabled by default in 0.9.8 branch as it
> is with 0.9.9...
> is it some policy about introducing new features in stable branch?
>
Yes the extension code hasn't been widely tested "in the field" and it
Hi Steve,
just curious why enable-tlsext isnt enabled by default in 0.9.8 branch as it is
with 0.9.9...
is it some policy about introducing new features in stable branch?
Thanks, Guenter.
__
OpenSSL Project
Hi Steve,
> None of text info (including fingerprint) is used during the lookup
> process.
> Omitting it makes the file shorter and makes it slightly quicker to read
> initially but has no effect after that.
thanks for your quick reply!
Guenter.
__
On Mon, Feb 11, 2008, Guenter Knauf wrote:
> Hi,
> there are some recommened methods for creating a ca-bundle.crt
> most use the openssl commandline with something like:
> openssl x509 -fingerprint -text -in infile -inform PEM >> outfile
> which produces a bunch of text info beside the PEM cer
Hi,
there are some recommened methods for creating a ca-bundle.crt
most use the openssl commandline with something like:
openssl x509 -fingerprint -text -in infile -inform PEM >> outfile
which produces a bunch of text info beside the PEM certs itself.
Now I would like to know:
- is anything of
me (originating from a Linux box).
Sounds right.
Regards
Michael
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Saladin
Sent: Donnerstag, 26. Juli 2007 16:14
To: openssl-dev@openssl.org
Subject: Question about EBCDIC
Hi all,
I compiled op
1 - 100 of 164 matches
Mail list logo
