Op do 18 jun. 2020 om 11:16 schreef Guido Vranken :
>
> I think this could be an issue with the system's /dev/urandom or entropy, as
> I've observed similar infinite loops in BN_prime when I changed OpenSSL code
> to always return the same sequence of bytes from its PRNG (for testing
>
I think this could be an issue with the system's /dev/urandom or entropy,
as I've observed similar infinite loops in BN_prime when I changed OpenSSL
code to always return the same sequence of bytes from its PRNG (for testing
purposes). It could also be a genuine bug in OpenSSL, or both. I'll let
Hi,
I'm trying to connect to www.google.com on 443 port with SSL but my code
shows an error at ssl_write.
This code is written in C++ Builder on Windows.
Everything is good before this point
err = SSL_write(ssl, buf, strlen(buf));
But after that err=-1 and code=1 (means SSL_ERROR_SSL )
What
On Thu, 18 Jun 2020 09:39:11 +0200,
Hal Murray wrote:
> I think that checking for NULL from EVP_get_ciphername() works in 1.1.1
> but that changed for 3.0.0
>
> Is there anything better/cleaner than actually calling EVP_CipherInit() or
> such?
For 3.0 and on, the better way is to find the
On Thu, 18 Jun 2020 09:25:43 +0200,
Hal Murray wrote:
>
> In the context of making things go fast/clean, do I need a reset? If so, why?
No. I sent another message where I pointed out that I made a mistake
when saying so.
--
Richard Levitte levi...@openssl.org
OpenSSL Project
On 18/06/2020 08:46, Ronny Meeus wrote:
> Hello
>
> we are in the process of upgrading our openssl to version 1.1.1g.
> On one of our architectures (Cavium MIPS, running kernel 4.9) we have
> an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
> core.
> On other architectures
On 18/06/2020 16:06, Ronny Meeus wrote:
> probable_prime BN_num_bits=1473 bits=1536
> BN_num data (size=24 top=24 neg=0 flags=13, sizeof(*d)=4):
>
On Thu, Jun 18, 2020 at 05:10:08PM +0200, Ronny Meeus wrote:
> > What is the "endianness" of this CPU? Is it big-endian or
> > little-endian? And does OpenSSL expect the correct one?
>
> This is a big endian CPU.
And, is OpenSSL configured for the correct endianness?
On Thu, Jun 18, 2020 at
Op do 18 jun. 2020 om 16:20 schreef Viktor Dukhovni
:
>
> On Thu, Jun 18, 2020 at 09:46:52AM +0200, Ronny Meeus wrote:
>
> > I added the print function and the result of the print is as follows:
> > probable_prime BN_num_bits 1473 1536
>
> The difference is exactly 63 bits! Suggesting that either
On Thu, Jun 18, 2020 at 09:46:52AM +0200, Ronny Meeus wrote:
> we are in the process of upgrading our openssl to version 1.1.1g.
> On one of our architectures (Cavium MIPS, running kernel 4.9) we have
> an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
> core.
Have you tried
I think that the default behavior should change for 3.0, and the API change
described in the Release Notes. I find that alternative less impacting that
this silent sudden performance deterioration.
On 6/18/20, 04:42, "openssl-users on behalf of Tomas Mraz"
wrote:
On Wed, 2020-06-17 at
On Thu, Jun 18, 2020 at 09:46:52AM +0200, Ronny Meeus wrote:
> I added the print function and the result of the print is as follows:
> probable_prime BN_num_bits 1473 1536
The difference is exactly 63 bits! Suggesting that either the high
64-bit bit word is 0x0001 or the bit
Op do 18 jun. 2020 om 15:33 schreef Matt Caswell :
>
>
>
> On 18/06/2020 08:46, Ronny Meeus wrote:
> > Hello
> >
> > we are in the process of upgrading our openssl to version 1.1.1g.
> > On one of our architectures (Cavium MIPS, running kernel 4.9) we have
> > an issue in the ssh-keygen tool. It
>BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
should also be 4. If BN_BYTES is being incorrectly set to 8 on your
platform then that would explain the discrepancy. Can you check?
This
On Thu, Jun 18, 2020 at 02:12:56PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I think that the default behavior should change for 3.0, and the API change
> described in the Release Notes. I find that alternative less impacting that
> this silent sudden performance deterioration.
Note that I
On Thu, Jun 18, 2020 at 12:00:33PM +0200, Attila Csosz wrote:
> err = connect(sd, (struct sockaddr*) , sizeof(sa));
>
> // Create SSL context
> meth = SSLv23_server_method();
Have you tried SSLv23_client_method()? Your application is a TLS
client, not a TLS server...
> if (!meth) throw
On Thu, Jun 18, 2020 at 07:24:39PM +0200, Kurt Roeckx wrote:
>
> Now that a large fraction of the cost has been found, I can look
> again to see where the biggest cost in 3.0 comes from now and if we
> can do something about it.
So a code path that I've noticed before when looking at the
profile
On 18/06/2020 17:27, Ronny Meeus wrote:
> Op do 18 jun. 2020 om 18:13 schreef Salz, Rich :
>>
>>>BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
>> BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
>> should also be 4. If BN_BYTES is being
Op do 18 jun. 2020 om 18:27 schreef Ronny Meeus :
>
> Op do 18 jun. 2020 om 18:13 schreef Salz, Rich :
> >
> > >BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
> > BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
> > should also be 4. If
Op do 18 jun. 2020 om 18:13 schreef Salz, Rich :
>
> >BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
> BN_BYTES. You have already told us that sizeof(*d) is 4. So BN_BYTES
> should also be 4. If BN_BYTES is being incorrectly set to 8 on your
> platform then
On 6/18/20, 12:46, "openssl-users on behalf of Kurt Roeckx"
wrote:
On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
>> > I question the default behaviour, I think most people don't need
>> > that support.
>>
>> Unfortunately that would be an API break that could
On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
> > I question the default behaviour, I think most people don't need
> > that support.
>
> Unfortunately that would be an API break that could be very hard to
> discover, so I do not think we can change this even in 3.0.
But I think the
Op do 18 jun. 2020 om 20:01 schreef Matt Caswell :
>
>
>
> On 18/06/2020 17:27, Ronny Meeus wrote:
> > Op do 18 jun. 2020 om 18:13 schreef Salz, Rich :
> >>
> >>>BN_bin2bn assumes that the size of a BN_ULONG (the type of a bn->d) is
> >> BN_BYTES. You have already told us that sizeof(*d)
Replying again since it looks like the final mail has not been
delivered to the newsgroup archive.
The issue has been found. It was a bug in buildroot passing the wrong target.
Op do 18 jun. 2020 om 20:33 schreef Ronny Meeus :
>
> Op do 18 jun. 2020 om 20:01 schreef Matt Caswell :
> >
> >
> >
> >
I think that checking for NULL from EVP_get_ciphername() works in 1.1.1
but that changed for 3.0.0
Is there anything better/cleaner than actually calling EVP_CipherInit() or
such?
I'm curious. What does it mean to have a non-NULL cipher that doesn't work?
I'm using default Engines and
Hello
we are in the process of upgrading our openssl to version 1.1.1g.
On one of our architectures (Cavium MIPS, running kernel 4.9) we have
an issue in the ssh-keygen tool. It keeps on consuming 100% CPU of 1
core.
On other architectures we do not see the issue at all.
I instrumented the
On 17/06/2020 12:39, Hal Murray wrote:
>
> There are 3 cases of "structure of NULL" where the "of" should be "or".
> The "NULL" is actually "B" in the pod file.
>
> doc/man3/EVP_PKEY_CTX_new.pod
> doc/man3/X509_NAME_add_entry_by_txt.pod
> doc/man3/X509V3_get_d2i.pod
>
> --
>
> There
On Thu, 18 Jun 2020 08:27:13 +0200,
Richard Levitte wrote:
>
> I think 16k was enough to demonstrate that the timing difference
> becomes more marginal the larger the amount of data to encrypt in the
> same session is.
>
> This makes me think that we might want to rethink the reset functions,
>
I honestly believe that the various contexts should be reusable.
Without this, the recent provider additions will impose a significant overhead.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 18 Jun 2020, at 4:27 pm,
I can successfully add a multi-value RDN to the Subject of a
certificate request using the + format in the config file:
distinguished_name = req_dn
[ req_dn ]
O=Acme
CN=Bloggs
+C=GB
However, if I add a SAN to the request:
subjectAltName = @alt_names
[ alt_names ]
In the context of making things go fast/clean, do I need a reset? If so, why?
My straw man is that setup has 3 stages:
1: get storage and whatever for the cipher
2: setup tables and such for a key
3: init internal data
In the same key case, the basic operation is
Init (does step 3)
I think 16k was enough to demonstrate that the timing difference
becomes more marginal the larger the amount of data to encrypt in the
same session is.
This makes me think that we might want to rethink the reset functions,
i.e. the likes of EVP_CIPHER_CTX_reset()... could we change that
function
On Wed, 2020-06-17 at 23:02 +0200, Kurt Roeckx wrote:
> On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> > levi...@openssl.org said:
> > > What does surprise me, though, is that direct EVP_MAC calls would
> > > be slower
> > > than going through the PKEY bridge. I would very much
33 matches
Mail list logo
