SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(128) Mac=SHA1
SRP-AES-128-CBC-SHA SSLv3 Kx=SRP Au=None Enc=AES(128) Mac=SHA1
normg@conifer>./openssl version
OpenSSL 1.0.1-dev xx XXX
Can anyone point me the right direction so I can get a simple SRP exampl
Hi Jeff,
> Was OPENSSL_NO_SRP defined when you built?
I'm 99.9% sure it wasn't, otherwise the compiler would have barfed on my call
to SSL_CTX_SRP_CTX_init()
> Thomas Wu's patches can be found in RT. The latest appears to be
> http://rt.openssl.org/Ticket/Display.html?id=2523&user=guest&pass=gu
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
- Original Message -
> From: "Peter Sylvester"
> To: openssl-users@openssl.org
> Sent: Tuesday, October 25, 2011 3:18:39 AM
> Subject: Re: OpenSSL 1.0.1 example with SRP
>
> On 10/25/2011 05:15 AM
681979
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
- Original Message -
> From: "Norm Green"
> To: openssl-users@openssl.org
> Sent: Tuesday, October 25, 2011 6:58:12 AM
> Subject: Re: OpenSSL 1.0.1 example with SRP
>
> Hi Peter,
>
> Sa
quot;
> To: openssl-users@openssl.org
> Sent: Wednesday, October 26, 2011 11:46:32 PM
> Subject: Re: OpenSSL 1.0.1 example with SRP
>
> On Wed, Oct 26, 2011 at 10:28 PM, Norm Green
> wrote:
> > Is there no one that can help me get a simple SRP test case
> > worki
27, 2011 7:44:35 AM
> Subject: Re: OpenSSL 1.0.1 example with SRP
>
> On Thu, Oct 27, 2011, Norm Green wrote:
>
> > > The best I can tell, the snapshot is broken.
> > At this point, I wouldn't be surprised.
> >
> > Update:
> >
> > I made som
SSL_accept() fail, which seems like a poor assumption.
I'm still fairly new to SSL and SRP and am grateful for any and all help.
Norm Green
VMware, Inc.
Here is the error I get on the client:
SSL_connect() failed, rc=0. resultCode=1 (SSL_ERROR_SSL)
0xfd7fffdf83a0 0xfd7fffdf839c 0xf
SSL_accept() fail, which seems like a poor
assumption. Is there some better way to determine that SRP authenication has
failed?
I'm still fairly new to SSL and SRP and am grateful for any and all help.
Norm Green
VMware, Inc.
Here is the error I get on the client:
SSL_connect() failed, rc=
>I use the git release tags, not the tarballs.
I do too, and I suspect many others do as well.
The empty krb5 directory has not caused grief for me, but it would be
nice if the git release tag directory structure matched the tarball.
Norm Green
On 4/21/2020 10:19 AM, Quanah Gibson-Mo
to include
err.h before ssl.h. Is this intentional or a bug?
It's easy enough for me to fix this in my source code, but other
packages that rely upon openssl break with "ssl.h is unusable" errors
due of this change (OpenLDAP is one such example).
Norm Green
All tests on AIX fail like this. Is this a known issue? What debugging
information is needed? Should I open an issue on github?
Also note I had to set LD_LIBRARY_PATH to the SSL build directory to get
the tests to run at all.
normg@sky>gmake test
make depend && make _tests
jamin Kaduk wrote:
On Wed, May 06, 2020 at 05:22:17PM -0700, Norm Green wrote:
All tests on AIX fail like this. Is this a known issue? What debugging
information is needed? Should I open an issue on github?
Also note I had to set LD_LIBRARY_PATH to the SSL build directory to get the
tests to run a
In 3.0 I see this new function in evp.h :
int EVP_PKEY_can_sign(const EVP_PKEY *pkey);
Is there an equivalent way to check if a key can verify? I'm not seeing
an obvious way to do that. Previously I used
EVP_PKEY_meth_get_verifyctx() but that call is now deprecated in 3.0.
thanks,
implement EVP_PKEY_can_verify() with some assurance such a
PR would be accepted.
Norm Green
On 8/18/2020 6:01 PM, Norm Green wrote:
In 3.0 I see this new function in evp.h :
int EVP_PKEY_can_sign(const EVP_PKEY *pkey);
Is there an equivalent way to check if a key can verify? I'm not
seeing an obvious
I'm also interested in the answer to these questions regarding SRP in
OpenSSL v3.
Our project still uses OpenSSL v1.1.1 with plans to move to v3 next year.
However we use SRP extensively and will not be able to move to v3 if SRP
support is soon to be no longer available.
Norm Green
Ge
Hi
In OpenSSL 3.x, what RSA padding scheme does EVP_SealInit() use? PKCS1
or OAEP ?
In 1.1, I wrote my own version of this code that forced the padding to
be OAEP and am wondering if I still need that in 3.x.
Norm Green
o shared cipher" complaint after
line 31 on the server side is clearly bogus.
Any idea where to begin debugging this? Any and all help is appreciated.
Norm Green
Server Side:
[ 1] SSL call: SSL_load_error_strings with args: NONE (nothing returned)
[ 2] SSL call: ERR_load_crypto_str
Thanks for tracking it down so fast Steve. I will revert the mods in
that commit and try it again tomorrow.
Norm
On 8/7/2014 7:21 PM, Dr. Stephen Henson wrote:
On Thu, Aug 07, 2014, Norm Green wrote:
Any idea where to begin debugging this? Any and all help is appreciated.
The cause is
, Aug 07, 2014, Norm Green wrote:
Any idea where to begin debugging this? Any and all help is appreciated.
The cause is incorrect handling of new SRP authentication type which was added
to correct a bug where SRP authentication was incorrectly classified as NULL
authhentication.
A temporary
Then what would you suggest? SRP is completely broken for us with 1.0.1i
Norm
On 8/8/14, 11:51, Matt Caswell wrote:
On 08/08/14 19:33, Norm Green wrote:
Hello Steve,
Reverting the below commit is necessary but not sufficient. There are
also references to aSRP in s3_clnt.c and ssl_lib.c
Hi Steve,
That patch works! We will go with that one instead of rolling back the
commit mentioned in your previous message.
Thanks very much for your help!!!
Norm
On 8/8/14, 12:25, Dr. Stephen Henson wrote:
On Fri, Aug 08, 2014, Norm Green wrote:
Then what would you suggest? SRP is
accept (s=0x1082180) at s3_srvr.c:680
#9 0x7f666a560042 in SSL_accept (s=0x1082180) at ssl_lib.c:940
#10 0x7f669731b0fb in GsSslState::SSL_accept (this=0x7f669800fd20
,
ssl=0x1082180) at /export/ghana1/users/bretlb/trunk/src/sslsocket.c:528
Thanks in
cipher = 0x7f91b3809e0a
,
get_ssl_method = 0x7f91b383fabc , get_timeout
= 0x7f91b38428f4 , ssl3_enc = 0x7f91b3b1bf20
,
ssl_version = 0x7f91b38374f5 ,
ssl_callback_ctrl = 0x7f91b380ad79 ,
ssl_ctx_callback_ctrl = 0x7f91b380b57b }
(gdb)
On 9/8/14 14:21, Viktor Dukhovni wrote:
On Mon, Sep 08, 2
h" is not sensitive.
I will try to capture traffic in the next run.
Norm
On 9/8/14 15:03, Viktor Dukhovni wrote:
On Mon, Sep 08, 2014 at 02:36:20PM -0700, Norm Green wrote:
Thanks Victor. I don't have a handshake recording for these stacks. The
problem occurs intermittently.
Any c
17:30, Viktor Dukhovni wrote:
On Mon, Sep 08, 2014 at 03:10:47PM -0700, Norm Green wrote:
I will try to capture traffic in the next run.
Looking at the commit history after 1.0.1i, I think
you want:
commit 30fbe92c78981a417718bcbf25d295d16c5b7ed9
Author: Dr. Stephen Henson
Date: Fri Aug 8 11:
(SSL_aNULL|SSL_aSRP))
return 2;
cpk = ssl_get_server_send_pkey(s);
if (!cpk)
Norm
On 9/8/2014 7:10 PM, Viktor Dukhovni wrote:
On Mon, Sep 08, 2014 at 05:41:13PM -0700, Norm Green wrote:
Thanks Viktor. I did get some
nect with args: 0x16bafe0 result=0
[ 17] SSL call: SSL_get_error with args: 0x16bafe0 0 result=1
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1275:SSL alert number 40
Thanks,
Norm Green
__
O
tar -ztvf openssl-1.0.2d.tar.gz |grep cast.h
-rw-rw-r-- openssl/openssl 4659 2015-07-09 04:53
openssl-1.0.2d/crypto/cast/cast.h
lrwxrwxrwx openssl/openssl 0 2015-07-09 05:03
openssl-1.0.2d/include/openssl/cast.h -> ../../crypto/cast/cast.h
How can I resol
in the in
error? What will 1.0.2f look like in this regard?
I need to merge 1.0.2e into a vendor branch in svn and I can foresee
these symlink changes causing me a lot of grief.
Norm Green
On 12/3/2015 9:05 AM, Viktor Dukhovni wrote:
On Thu, Dec 03, 2015 at 04:59:56PM +, Viktor Dukho
.c
./test/rsa_test.c
./test/evp_test.c
./test/ecdhtest.c
./test/mdc2test.c
./test/rc5test.c
./test/rc2test.c
./test/ectest.c
./test/exptest.c
./test/constant_time_test.c
Will there be a 3rd 1.0.2e tarball released to fix this?
Norm Green
On 12/3/15 09:41, Viktor Dukhovni wrote:
On Thu, Dec 03
Are these sym links going to remain this way in subsequent releases? Or
will they revert back to the way they were in 1.0.2d? Merging changes
like this into svn is a pain because it causes conflicts.
Norm Green
On 12/3/15 13:31, Matt Caswell wrote:
On 03/12/15 21:27, Norm Green wrote
going to try modifying the make file to use shorter directory names
to try to get the link line back under the max length threshold.
Any other suggestions?
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
e the same encryption keys used every time with ADH?
3) Is it possible to use ephemeral DH without using certificates? I was
not able to get that to work.
4) What is the best practice for establishing an anonymous encrypted
channel using OpenSSL?
Norm Green
--
openssl-users mailing list
To unsubscr
t these?
I previously tried "kEECDH:kEDH" and that didn't work.
2) These ciphers all report as SSLv3. Do I have to use SSLv3
client/server methods to get access to these ciphers? I was using TLS
1.2 (TLSv1_2_server_method()) methods.
Norm Green
On 5/24/16 10:08, Salz, R
hared
cipher:s3_srvr.c:1417:
The following works but is not what I want:
SSL_CTX_set_cipher_list("ADH")
Any suggestions on how to proceed?
Norm Green
On 5/24/16 10:45, Salz, Rich wrote:
>./openssl ciphers -v 'ALL:aNULL' |grep ECDH |grep "Au=None"
AECDH-AES2
Yes! That was the problem. In order to use cipher "AECDH",
SSL_CTX_set_ecdh_auto(ctx, 1) must be called first.
Thanks Michael!!
Norm
On 5/24/16 15:52, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Norm Green
Sent: Tuesday, Ma
Yes, it's only required on the server.
Norm Green
On 5/25/16 14:10, Jeremy Farrell wrote:
Interesting; is this a server-side requirement? I ask because with
1.0.2g my client using "AECDH+AES:ADH+AES" makes a TLS 1.2 connection
with AECDH-AES256-SHA without calling this func
tions implemented without aes instructions in that case?
Norm Green
On 8/10/16 06:28, Jan Just Keijser wrote:
Hi,
On 10/08/16 14:25, Nagesh shamnur wrote:
Hi Group,
I am running an application which transfers huge chunks of data every
second (850Mbps) and the same is secured using op
The man page for EVP_SealInit says:
"The public key must be RSA because it is the only OpenSSL public key
algorithm that supports key transport."
1 ) Is this still true?
2) Will this restriction change now that RSA key transport is being
dropped from TLS 1.3 (or so I've r
Ok, thanks.
What I don't understand is what key transport has to do with
EV_SealInit() ? Why is key transport important here ?
Norm Green
On 8/15/2016 2:38 PM, Dr. Stephen Henson wrote:
On Mon, Aug 15, 2016, Norm Green wrote:
The man page for EVP_SealInit says:
"The public k
Sorry, I'm still not quite getting it.
It sounds like you're saying that only RSA supports encrypting with a
public key. But can't any asymmetric encryption algorithm encrypt using
the public key? Why is RSA special in this regard?
Norm Green
On 8/15/2016 5:31 PM, Dr. Steph
+1
I agree with Daniel's sentiment and respectfully suggest EPV_Seal* and
EVP_Open be updated and kept up to date.
We all know how easy it is to get crypto wrong. Having "one stop shop"
functions like these are invaluable for when it comes to getting crypto
right.
Norm Gre
see anywhere in the build log where the assembler is
being invoked directly.
My compiler is:
cc: Sun C 5.10 SunOS_i386 Patch 142363-05 2010/04/28
usage: cc [ options] files. Use 'cc -flags' for details
thanks,
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.ope
L
Details: error:141640B5:SSL routines:tls_construct_client_hello:no
ciphers available
ssl/statem/statem_clnt.c at 815
What do I need to do to make AECDH work in 1.1 ?
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
That was it. Thanks Matt!
On 12/13/16 15:48, Matt Caswell wrote:
On 13/12/16 21:09, Norm Green wrote:
I have a simple C program that works in 1.0.2 but fails with the same
code in 1.1.
Here's the psuedo code for the client and server:
Server:
const SSL_METHOD *meth = TLSv1_2_server_m
h6UxDyYdrQv
XmxFEr1AwKnmeD8dAg4F62ddmzX76fNaw1QqLbmEQTLdrEYM3KxUdA==
-END PUBLIC KEY-----
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
This is with openssl 1.10d. When I run:
./openssl ciphers -v
The OCB ciphers are not in the list. Is this an omission or
intentional? Other AEAD ciphers are there (GCM).
Thanks,
Norm Green
normg@bunk>./openssl ciphers -v |grep AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH
tanding of things correct? Seems like there should be a way
for the openssl command to verify a chain file which will be used with the
SSL_CTX_use_certificate_chain_file() function.
Norm Green
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
On 1/9/2018 6:03 AM, Benjamin Kaduk wrote:
Did you try something like (with a 1.1.0 installation):
openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem
with the leaf certificate as the first one in chain.pem?
Same result. The only way it seems to work is if the leaf cert appears
Well that is not *at all* obvious from the documentation, but ok.
What is the correct order of intermediate CA certs in the untrusted
chain file?
On 1/9/2018 3:36 PM, Viktor Dukhovni wrote:
The correct way to verify a chain is to put the root CA in a CAfile,
intermediate CAs in an "untruste
ion failed
On 1/9/2018 3:57 PM, Viktor Dukhovni wrote:
On Jan 9, 2018, at 6:43 PM, Norm Green wrote:
What is the correct order of intermediate CA certs in the untrusted chain file?
The untrusted CA list is a heap, the order is irrelevant.
--
openssl-users mailing list
To unsubscr
On 1/9/2018 4:55 PM, Viktor Dukhovni wrote:
On Jan 9, 2018, at 7:28 PM, Norm Green wrote:
It still doesn't verify correctly.
Or correctly fails to verify?
To simplify, I tried it with 1 intermediate CA. Here's the chain:
rootCa.pem - self-signed root cert. CN =
On 1/9/18 19:32, Viktor Dukhovni wrote:
This Key Usage is more appropriate. When the "Key Usage" is present in
a CA certificate, it*MUST* include "Certificate Sign".
That was indeed the problem. Thank you!! It seems strange to me that
OpenSSL will allow creation of a CA cert (CA:TRUE) that m
This is on Ubuntu 16.04with a build configured to be debug-linux-x86_64
normg@moop>gmake
make depend && make _all
make[1]: Entering directory
'/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1'
make[1]: Leaving directory
'/export/moop3/users/normg/gs64-3xm1/slow50/openssl_1.1'
make[1]: Ent
Turns out it only fails in my build environment and it builds clean as a
stand-alone SSL build. So it's something on my end.
Sorry for the noise.
Norm
On 2/13/2018 2:59 PM, Matt Caswell wrote:
On 13/02/18 21:06, Norm Green wrote:
This is on Ubuntu 16.04with a build configured to be
In 1.1.1 pre-relase 1, we have this new function:
int OSSL_STORE_ctrl(OSSL_STORE_CTX *ctx, int cmd, ... /* args */);
Would it be possible to add a version that takes va_args like this?
int OSSL_STORE_vctrl(OSSL_STORE_CTX *ctx, int cmd, va_list args);
OpenSSL already have this precedent in othe
Not sure if this is expected on this platform?
Test Summary Report
---
../test/recipes/04-test_asn1_encode.t (Wstat: 256 Tests: 1
Failed: 1)
Failed test: 1
Non-zero exit status: 1
../test/recipes/90-test_secmem.t (Wstat: 256 Tests: 1
Failed: 1)
'
Makefile:167: recipe for target 'tests' failed
gmake: *** [tests] Error 2
slow test failed
On 2/19/2018 12:50 PM, Benjamin Kaduk wrote:
On 02/19/2018 02:06 PM, Norm Green wrote:
Not sure if this is expected on this platform?
Test Summary Report
---
../test/reci
205 in "driver.c"
[9] main(argc = 1, argv = 0x7fffec08), line 51 in "main.c"
(dbx)
On 2/19/2018 1:30 PM, Viktor Dukhovni wrote:
On Feb 19, 2018, at 4:20 PM, Norm Green wrote:
/export/localnew/sparc.Solaris/bin/gmake depend &&
/export/localnew/sparc.Solari
olaris compiler which apparently
does not define these macros.
Nornm
On 2/19/2018 1:20 PM, Norm Green wrote:
The output is not too long.
/export/localnew/sparc.Solaris/bin/gmake depend &&
/export/localnew/sparc.Solaris/bin/gmake _tests
gmake[1]: Entering directory
'/hamb
ations_elem_size);
ret = ASN1_item_print(bio_err, o, 0, i, NULL);
On 2/19/2018 9:00 PM, Viktor Dukhovni wrote:
On Mon, Feb 19, 2018 at 01:45:26PM -0800, Norm Green wrote:
# ASN1_LONG_DATA:
# success: TRUE
t@1 (l@1) signal BUS (invalid address alignment) in asn1_item_print_ctx at
On 2/20/2018 5:43 AM, Michael Wojcik wrote:
Not by default. The comments in /usr/include/sys/feature_tests.h (on a Solaris
system) explain this in excruciating detail, but in short you need either
-DPOSIX_C_SOURCE=200112L or -D_XOPEN_SOURCE=600 (or the equivalent in the code)
to compile with X
Just download and build v1.1.1 pre alpha 1 on Solaris. It's on
ftp.openssl.org. That's all I did. Configure using
solaris64-sparcv9-cc . I'm using Solaris studio 12.3.
Norm
On 2/20/2018 10:01 AM, Dennis Clarke wrote:
On 20/02/18 12:47 PM, Norm Green wrote:
On 2/20/2018 5
Hi Dennis,
You're right, I did modify the config file, sorry. I did it so long ago
I had forgotten. I will email it to you shortly.
Norm
On 2/20/2018 10:14 AM, Dennis Clarke wrote:
On 20/02/18 01:11 PM, Norm Green wrote:
Just download and build v1.1.1 pre alpha 1 on Solaris. It
On 2/21/2018 8:42 AM, Dennis Clarke wrote:
Pretty sure I have done builds and tests. In fact I am certain of it.
If you added -xmemalign=8s to the SPARC compiler flags (as shown in one
of your emails from yesterday) then you would not see the problem.
-xmemalign=8s forces the compiler to use
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to the compile/link flags.
Norm
--
openssl-
On 2/21/2018 12:46 PM, Andy Polyakov wrote:
And "the default for all v9 architectures is -xmemalign=8s".
I'm getting confused. Since I did not specify -xmemalign at all, why
did the test fail with SIGBUS in the first place? Seems like there
should have been no alignment problem if the compile
Looks like no target .a file is passed to ar ?
Note: OpenSSL 1.1.0 succeeds on this platform.
/export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl -i -pe 's/^.*\|//; s/
\/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" unless
!defined($_) or /\R$/g;' apps/s_socket.d.tmp
ar -X 64
Adding "-cru" to arflags for AIX in Configuratinos/10-main.conf solves
the problem.
On 2/23/2018 2:36 PM, Dennis Clarke wrote:
On 23/02/18 05:31 PM, Norm Green wrote:
Looks like no target .a file is passed to ar ?
Note: OpenSSL 1.1.0 succeeds on this platform.
/export/localne
With CC=cc, I get this:
cc -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall
-Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_A
:39:47 -0800, Norm Green said:
norm.green> With CC=cc, I get this:
norm.green>
norm.green> cc -I. -Icrypto/include -Iinclude -g -O0 -arch x86_64 -Wall
norm.green> -Qunused-arguments -fPIC -DDSO_DLFCN -DHAVE_DLFCN_H
norm.green> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL
It looks like 32 bit builds set the -WX flag (treat warnings as errors)
while the 64 bit builds don't.
cl -W3 -wd4090 -Gs0 -GF -Gy -nologo /MDd /Od -WX /Zi
/Fdossl_static /I "." /I "crypto\include" /I "include" /I
"crypto\ec\curve448\arch_32" /I "crypto\ec\curve448" -DDSO_WIN32
-DOP
SSL version-specific? SSL 1.1.0 builds clean on the same machine
I'm wondering if the solution is code changes or
On 3/1/18 04:27, Andy Polyakov wrote:
I mean it might happen that it's not version-specific...
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/l
How does one specify the CRL to the SSL_CTX when setting up a
connection? I would expect there to be something similar to
SSL_CTX_use_certificate(), such as:
int SSL_CTX_use_crl(SSL_CTX *ctx, X509_CRL *crl)
but can nothing like that.
Norm Green
--
openssl-users mailing list
To unsubscribe
I'm seeing the following link failure on Solaris, both SPARC and x86_64
with 1.1.1a. 1.1.1 does not have this problem. Adding -lcrypto to the
link line makes the problem go away.
Any suggestions on how to proceed?
Norm Green
rm -f test/rsa_complex
${LDCMD:-/opt/studio12.5/bin/cc}
I'm debugging a failure in a debug build on Solaris SPARC in the below
code in rand_lib.c. On line 744, rand_meth_lock is NULL, which suggests
the RUN_ONCE code is not working. Wondering if anyone else has seen
this problem?
We did not see this issue in 1.1.1a. Perhaps changes in the RUN_ONCE
exit with pthread_exit() or
return to a known state such that no SSL calls are in progress in any
thread before the process can safely exit().
On 3/1/2019 11:54 AM, Viktor Dukhovni wrote:
On Fri, Mar 01, 2019 at 11:16:52AM -0800, Norm Green wrote:
[ Please avoid non-breaking spaces in your
/ first chunk
destSize -= 512;
EVP_CipherUpdate(ctx, &encrypted[512], &destSize, &payload[512], 512);
// second chunk
EVP_CipherFinal(); (produces no additional data)
I have a short C program that demonstrates the problem that I can post
if necessary.
Can anyone explain what&#x
Could be, but that's not how EVP_CipherUpdate is documented to work. If
this is an XTS mode limitation and not a bug, shouldn't the limitation
be documented on a man page somewhere? And shouldn't my second call to
EVP_CipherUpdate fail?
Norm Green
On 9/30/2019 8:04 PM, Thu
79 matches
Mail list logo
