You can re-use the keys, but then you get no forward secrecy, and sessions
generated with one connection are vulnerable to another.
Why are you using DH? Unless you have compelling reasons (interop with
legacy), you really should use ECDHE.
--
openssl-dev mailing list
To unsubscribe: https://
all the server connections. Is my
> understanding correct? Is there any risk in using same parameter for all the
> server connections.
>
> Another question is what is guidelines/document should be followed to derive
> DH parameter.
>
> Any input is appreciated.
>
> Thanks and
same DH parameter for all the server connections. Is
my understanding correct? Is there any risk in using same parameter for all
the server connections.
Another question is what is guidelines/document should be followed to
derive DH parameter.
Any input is appreciated.
Thanks and Regards
It seems that OCSP_basic_verify(bs, certs, st, flags) unfortunately is
not documented, but from its code it becomes clear that the "certs"
parameter is meant to be a set of untrusted certificates, which is first
used (together with bs->certs) to determine the signer cert of the OCSP
response "bs" a
On Mon, Jun 26, 2017, Brett R. Nicholas wrote:
> AFAIK (and please correct me if this is wrong) my init_key function is
> invoked by the EVP interface when I call the EVP_[En/De]cryptInit_ex
> function, and the do_cipher function is called upon EVP_[En/De]cryptUpdate.
> But how should I handle
Hi there,
I'm building a dynamic engine to support a custom AES hardware module that I've
implemented in FPGA logic**, but after reading all available documentation, and
pouring over the source code, I'm still very confused about the following two
things.
1. How and where I should defi
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
> OCSP responses do not seem to include the intermediate certificates so they
> have to be acquired in other ways. I have been doing this and adding them
> to the certificate stack handed to OCSP_basic_verify().
Perhaps adding them to X509_STORE or STORE_CTX directly?
> I am relatively new to
Hello!
I have been using openssl to get OCSP status for a certificate and I ran across
an interesting case.
OCSP responses do not seem to include the intermediate certificates so they
have to be acquired in other ways. I have been doing this and adding them to
the certificate stack handed
There are no plans, at this point, to change the names used in logging.
If you think it's worthwhile, please open a *github issue* for this.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3728
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To un
> In the function private_AES_set_decrypt_key, in aes_core.c, it inverts
> the order of the round keys before applying the MixColumn transform from
> low to high (excluding low and high, order doesn’t really matter as each
> transformation is dependent only on the item in que
Hi,
In the function private_AES_set_decrypt_key, in aes_core.c, it inverts the
order of the round keys before applying the MixColumn transform from low to
high (excluding low and high, order doesn't really matter as each
transformation is dependent only on the item in question).
> It's quite probably that in 1.1 they will become X509v3_addr_xxx etc.
Thanks for the heads-up. Having already crossed the "some API changes
will not be 100% backwards compatible" Rubicon, this is no big deal.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/
> Yes. See:
Great, thanks. It's quite probably that in 1.1 they will become
X509v3_addr_xxx etc.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
At Thu, 14 Apr 2016 16:57:56 +, Salz, Rich wrote:
>
> Do you use the v3_asid_xxx or v3_addr_xxx API's?
Yes. See:
https://subvert-rpki.hactrn.net/trunk/ext/POW.c
https://subvert-rpki.hactrn.net/trunk/rp/rcynic/rcynic.c
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mail
Do you use the v3_asid_xxx or v3_addr_xxx API's? Please let me know.
(They are not going away, we just need to know if they're internal-only or if
people are using them.)
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
--
openssl-dev mailing list
To unsubscri
> 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, a
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:
> >&g
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 archi
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&#x
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 se
ificates
> from the wire, and should be verified in the same manner. The
> changes I want to backport from 1.1.0 ensure identical treatment
> of untrusted intermediates regardless of provenance.
I have an important question for the list. At present the pending
patches to backport from 1.
l right. It answered a question that would have been asked
sooner or later, and I much prefer sooner.
Cheers,
Richard
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mail
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 sh
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 eng
The length is specified by the standards and is less than the digest length.
Closing this ticket.
Matt
-
http://rt.openssl.org/Ticket/Display.html?id=2256
Please log in as guest with password guest if prompted
_
We're only doing security fixes in 1.0.1 now; sorry we didn't get to this
sooner.
Fixed in current releases.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-
> 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
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 Engineer
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
Just compile openssl 1.0.2 daily 20150804 and got
making all in crypto/cmac...
if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make
libcrypto.so.1.0.0); fi
[ -z "" ] || gcc -dPIC -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
-DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_
x27;. /
>
> We haven't change all calls to CRYPTO_set_id_callback(),
> CRYPTO_get_id_callback(), and CRYPTO_thread_id() in our code to
> CRYPTO_THREADID routines.
>
> The question I would like to ask is if we upgrade OpenSSL from 9.0.8b to
> OpenSSL 1.0.1e without m
>> 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
Hello,
I want to add OpenSSL to my Cortex M3 bare metal platform. I am using a Keil
IDE and I am having trouble configuring a library to support this
environment. Any suggestions would be most appreciated.
Thanks for your time!
Best regards
Will
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
On 17/05/15 20:13, Kurt Cancemi wrote:
> Hello,
>
> If anyone from the openssl dev team can answer this question about the
> openssl code:
>
> In ssl_lib.c in SSL_shutdown(), s->handshake_func is compared against
> 0 (inferring that s != NULL) and then there is a NULL
Hello,
If anyone from the openssl dev team can answer this question about the
openssl code:
In ssl_lib.c in SSL_shutdown(), s->handshake_func is compared against
0 (inferring that s != NULL) and then there is a NULL check that (s
!= NULL) which the compiler optimizes out because (s) is infer
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
gt; On 05/13/2015 10:46 AM, John Foley wrote:
>> 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
>>
ing 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
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, ther
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
On Sat, Mar 07, 2015 at 09:56:36AM -0800, Daniel Kahn Gillmor wrote:
> > No. These are just the names of internal functions. Originally written when
> > it
> > was just a choice of ssl2 or ssl3 they were subsequently reused for TLS -
> > but
> > the names have remained the same.
>
> Is there a
On Thu 2015-03-05 08:58:10 -0800, Matt Caswell via RT wrote:
> On Thu Mar 05 17:42:49 2015, richard.c.pater...@sas.com wrote:
>> Apologies if this is the incorrect forum for this question.
>>
>> We’re
>> seeing error messages like SSL3_READ_BYTES and
>> SSL3_GET_S
On Thu 2015-03-05 08:58:10 -0800, Matt Caswell via RT wrote:
> On Thu Mar 05 17:42:49 2015, richard.c.pater...@sas.com wrote:
>> Apologies if this is the incorrect forum for this question.
>>
>> We’re
>> seeing error messages like SSL3_READ_BYTES and
>> SSL3_GET_S
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
On Thu Mar 05 17:42:49 2015, richard.c.pater...@sas.com wrote:
> Apologies if this is the incorrect forum for this question.
>
> We’re
> seeing error messages like SSL3_READ_BYTES and
> SSL3_GET_SERVER_CERTIFICATE for some reason;
>
> -
> SSL3_GET_SERVER_CERTIFICATE:c
Apologies if this is the incorrect forum for this question.
We’re seeing error messages like SSL3_READ_BYTES and
SSL3_GET_SERVER_CERTIFICATE for some reason;
- SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
- SSL£_GET_BYTES:sslv3 alert handshake failure
However, we
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
Local gcc config/install issue, not an openssl issue.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List opens
Duh - thank you Steef, Kurt and Rich - not sure how I could miss that
either... So please only take the key message - your team does a great
job with OpenSSL, thank you all!
Regards,
Henning
On 08/13/2014 01:35 PM, Steef wrote:
> Hi Henning,
>
>> So my question is - would it be r
Hi Henning,
> So my question is - would it be reasonable to send an early warning
> (without any details) to one of the OpenSSL lists a few days before
> publishing a version containing fixes for security vulnerabilities?
> Just saying something along the lines of "we plan
Hi Henning,
> So my question is - would it be reasonable to send an early warning
> (without any details) to one of the OpenSSL lists a few days before
> publishing a version containing fixes for security vulnerabilities?
> Just saying something along the lines of "we plan
is
> published fixing security issues, it is more or less a surprise to many.
> After the disclosure everyone tries to have their developers jump on
> integrating the fixes as soon as possible, but this may take some time
> to allocate and coordinate resources, increasing the time to a fix
Thanks for your kind words. We do post a notice that we're putting out a
security update. Not sure how you missed it...
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
__
everyone tries to have their developers jump on
integrating the fixes as soon as possible, but this may take some time
to allocate and coordinate resources, increasing the time to a fixed
version.
So my question is - would it be reasonable to send an early warning
(without any details) to one of the
Hello Openssl team
I have managed to make Jenkins CI up and running on various config
(Linux and Windows)
For the moment
-Linux Ubuntu 12.04 32 bits
-Linux Rasberrypi 3.12.22
-Windows 7 Family edition
Run openssl make + make depend + make test with
-for linux standard ./config
-for linux st
The request tracker should not be used for general user queries. Please direct
them to the openssl-users mailing list.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
Hi, my name is Yousik Kim from Republic of Korea.
I use OpenSSL for https function of my security camera web server.
Thank you.
I have a problem as below.
I use fd transfer function in lighttpd web server for video streaming.
(Fd transfer is the function that pass client socket to other process.)
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
Spam *** Question on ECC (openssl vs wcurve)
Hi All,
Have a basic ECC question, I have a predefined scalar K, and I used the
x9.62 256 prime curve. Invoking the scalar multiplication method
EC_POINT_mul with the generator of that curve, I get a different output,
when compared with wcurve of p
Hi All,
Have a basic ECC question, I have a predefined scalar K, and I used the
x9.62 256 prime curve. Invoking the scalar multiplication method
EC_POINT_mul with the generator of that curve, I get a different output,
when compared with wcurve of python.
The curve is fixed, K is fixed but the
Thanks for your reply.
> Are you, by chance, trying to derive secret from keypairs generated with
> *different* parameters? This cannot possibly work, of course. Both sides
> keypairs must be generated for same DH parameters.
OK, I guess the larger prime numbers of each group makes there paramete
Thanks for your reply.
> Can you provide the source for the problem that you're running into?
I cannot give the source code as it is now, but I will create a new test case
using only the OpenSSL calls I make in this situation. I will post it or report
back if I find an error.
Regards,
LJB
Leon Brits wrote:
> In a test I have three DH key pairs generated from the IKE groups 14,15
> and 16 paramters.
>
> When I want to derive a secret and I use the 2048 bit private key then
> the derivation fails if I use the 3072 or 4096 bit public key.
Are you, by chance, trying to derive secret f
On 02/11/2014 09:19 AM, Leon Brits wrote:
> In a test I have three DH key pairs generated from the IKE groups 14,15 and
> 16 paramters.
[...]
> It seems the private key must be the same or larger to succeed.
> Is this correct: Can the public key not be larger than the private key?
There shouldn
Hi all,
In a test I have three DH key pairs generated from the IKE groups 14,15 and 16
paramters.
When I want to derive a secret and I use the 2048 bit private key then the
derivation fails if I use the 3072 or 4096 bit public key.
But if I derive using the 3072 bit private key then I can derive
callback(), and CRYPTO_thread_id() in our code to
CRYPTO_THREADID routines.
The question I would like to ask is if we upgrade OpenSSL from 9.0.8b to
OpenSSL 1.0.1e without making the above suggested change what the
sebsequence is? Will this cause race conditions?
And do we take any rick if we decid
Hello!
I have a question about the check in the ssl_parse_serverhello_tlsext
function:
if (data >= (d+n-2))
goto ri_check;
Shouldn't it be
if (data > (d+n-2))
goto ri_check;
instead?
Thank you!
--
SY, Dmitry Belyavsky
1 - 100 of 609 matches
Mail list logo
