Hi Sergio,
We are using OpenSSL APIs in our product code. We are not making any changes in
OpenSSL. Our product code is a C++ code and it makes use of openSSL APIs for
some functionality.
This compilation error we are getting in Linux and windows platforms. But in
Linux, we have a
Agree that XTS specific deviation should have been documented similar to
some of the AEAD ciphers with EVP interface.
Thanks,
Thulasi.
On Tue, 1 Oct 2019 at 08:46, Norm Green
wrote:
> Could be, but that's not how EVP_CipherUpdate is documented to work. If
> this is an XTS mode limitation and
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, Thulasi Goriparthi
As 512 byte blocks are independently encrypted, they should be decrypted
similarly. This is how XTS mode is defined.
i.e Try to decrypt 512 byte blocks separately with two CipherUpdates.
Thanks,
Thulasi.
On Tue, 1 Oct 2019 at 06:43, Norm Green
wrote:
> Hi all,
>
> I'm using OpenSSL 1.1.1d on
Hi all,
I'm using OpenSSL 1.1.1d on Linux with the cipher EVP_aes_256_xts() in
order to write database/disk encryption software.
When encrypting, I have problems if I call EVP_CipherUpdate() and
encrypt the data in chunks. Encrypting only works when I encrypt the
entire payload with one and
Hi All,
I am facinmg issue while upgrading my OpenSSL version from 1.0.2p to 1.1.1c.
I am facing the issue where "ENGINE_by_id("capi")" is not returning proper
pointer. I want to access windows certificate store with certificate and keys.
Snippet of my working code in 1.0.2p:(This is working
On 30/09/2019 17:02, Matt Caswell wrote:
> openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem \
> -url http://ocsp.myhost.com/ -resp_text -respout resp.der
Ah, I hadn't realised that -cert could be given multiple times.
--
Thanks,
Jeremy
On 30/09/2019 14:49, Jeremy Harris wrote:
> Looking at implementing the above, under TLSv1.3 and (at least
> initially) server-side. I'm currently using
>
> SSL_CTX_set_tlsext_status_cb()
> SSL_set_tlsext_status_ocsp_resp( a DER blob )
>
> and the problem is: will this accept a
>
Ciao.
I haven't had a chance to compile the exact OpenSSL version using g++ compiler
as stated by the user/poster.
If this user is using a modified or altered version of OpenSSL provided source
code, is there support available? Don't get me wrong, I don't mind helping out
but .
I'll try
> OpenSSL code is compiling without any issues. When it is used from our
> product code and while compiling using C++ compiler, the issue is seen.
As I wrote previously, the error you posted was caused by the fact that you
are compiling Ansi C (a.k.a ISO/IEC 9899:1990, a.k.a C90) source code
Looking at implementing the above, under TLSv1.3 and (at least
initially) server-side. I'm currently using
SSL_CTX_set_tlsext_status_cb()
SSL_set_tlsext_status_ocsp_resp( a DER blob )
and the problem is: will this accept a
(DER-wrapped, basicresp-wrapped) stack of singleresp
where the
I’m not aware of any such work having been undertaken.
OpenSSL 3.0 will definitely be sufficiently modular to support this. 1.1.1 a
little less so but it might be possible.
If anyone is willing to take this up, I’d suggest targeting OpenSSL 3.0.
At the moment we are busy with FIPS and the 3.0
>Greetings. I was checking for the support for Trusted
> Execution Environment (TEE) in OpenSSL.
I’m curious – what do you think would be required?
Hi Michael,
OpenSSL code is compiling without any issues. When it is used from our product
code and while compiling using C++ compiler, the issue is seen.
We also don’t use the ‘warning as errors’ and warning level 3 we are using
currently.
Thanks and regards,
Nagalakshmi
From: Michael
On 30/09/2019 11:56, Nagalakshmi V J wrote:
> In our code, We included “ssl_locl.h” which in turn includes packet_locl.h.
> Any
> way to avoid this kind of error?
Don't include "ssl_locl.h"!!! This is an internal header file and relying on it
is likely to cause problems for you. There are no
Hi Matthias,
Yes that's right. The error message is
..\..\OpenSSL\openssl-1.1.1c\crypto\../ssl/packet_locl.h(429) : error C2440:
'=' : cannot convert from 'void *' to 'unsigned char *' Conversion from 'void*'
to pointer to non-'void' requires an explicit cast
Sorry, it was missed by
We compile using Visual Studio. We don't use 'warnings as errors' and
selected a warning level that minimized warnings. The 'make test' runs
cleanly.
On Mon, Sep 30, 2019, 3:16 AM Nagalakshmi V J
wrote:
> Hi,
>
> I am using openssl 1.1.c from our product code. While compiling the code,
> I am
Dear OpenSSL Group,
Greetings. I was checking for the support for Trusted Execution
Environment (TEE) in OpenSSL. I could see that the current design is modular
enough to support it. But sadly, I was unable to find the relevant code changes
adapting any TEE implementation such
> Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '=' :
> cannot convert from 'void *' to 'unsigned char 'Conversion from 'void' to
> pointer to non-'void' requires an explicit cast
Is it possible that your error message was copied incorrectly? Line 429 is an
assignment
Hi,
I am using openssl 1.1.c from our product code. While compiling the code, I am
getting the errors which can be suppressed as warnings using -fpermissive flag
in Linux (gcc/g++). In windows, I am getting the same compilation errors in
visual studio (2005). Would like to know the alternative
20 matches
Mail list logo
