Hi all,
I've noticed in my unit tests that, for the same code path, when I encrypt an
decrypt the data read from a file which is 959120 bytes in size, then the FIPS
mode of AES-XTS works every time, while the non-FIPS mode fails some times. It
fails frequently but seemingly random. I've seen
On Mon, Aug 26, 2013, Leon Brits wrote:
Hi all,
I've noticed in my unit tests that, for the same code path, when I encrypt an
decrypt the data read from a file which is 959120 bytes in size, then the
FIPS mode of AES-XTS works every time, while the non-FIPS mode fails some
times. It
I am using a FIPS compiled OpenSSL and I switch between FIPS and non-FIPS mode
with the FIPS_mode_set() API call. The selection is made by the application
linked to my library based on its configuration.
Thanks
LJB
-Original Message-
From: owner-openssl-...@openssl.org
On Sat Aug 24 21:16:05 2013, beld...@gmail.com wrote:
Greetings!
We have found an inconsistent behaviour of the openssl engine command. The
problem appeared in version 1.0.1d in case openssl is built with
--enable-shared.
1. When the config file does not mention the gost engine, the command
On Mon, Aug 26, 2013, Leon Brits wrote:
I am using a FIPS compiled OpenSSL and I switch between FIPS and non-FIPS
mode with the FIPS_mode_set() API call. The selection is made by the
application linked to my library based on its configuration.
That's weird. It should be using exactly the
Greetings!
Thank you for your explanation! But I'm sorry, I did not understand why the
behaviour depends on the config option's order. In case 3 and 4 the
behaviour differs but it is expected by me to be the same.
And how difficult will it be to write a patch for avoiding the unlisted
engines?
Greetings!
Thank you for your explanation! But I'm sorry, I did not understand why the
behaviour depends on the config option's order. In case 3 and 4 the
behaviour differs but it is expected by me to be the same.
And how difficult will it be to write a patch for avoiding the unlisted
engines?
On 08/25/2013 12:23 PM, PMHager wrote:
If your intention is performance optimization you could even replace
if((*p 0x80) == 0)
with
if((signed char)(*p) = 0)
as you cannot assume that all compilers will do it correctly themselves.
Actually, this proposed change relies on a GCC
I don't think that it is true that (signed char)(*p) = 0 is always true,
otherwise all of the else if branches would never be taken. I think the
optimization that PMHager was thinking about (based on what I see in the
x86_64 assembly from gcc) is that the compiler could (but apparently not
every
