It’s not endianness, it’s random data in the encrypted stream. Try encrypting
the same file (and password) twice on the same host. Try decrypting it.
Everything will work right.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
When I attempt to encrypt the same text file with the command " openssl bf
tfile.bin" I get different results on big endian machines vs
little endian machines.
Is this the expected result? If so how do you share encrypted data between
big endian and little endian machines
Thanks
--
*Samuel A
Hi Jakob & Michael & openssler,
The openssl can work well now.
I just used the date command to reset my system time.
And then it can return OK value now.
Although I didn't try it in the latest openssl1.1.0c.
In my embedded linux device, I didn't initialize the time. And there is no
RTC.
This
Hi Jakob & Michael & opensslers,
I'm sorry to ask a stupid question.
That I found when I used the openssl1.0.1f, it said the error log:
--log--
/tmp # ./openssl s_client -connect curl.haxx.se:443 -CAfile ./cacert.pem
CONNECTED(0003)
depth=2 O =
Hi Michael & opensslers,
> So: either there's more than one certificate in cacert-2016-11-02.pem, or
OpenSSL on the PC is searching its default CA certificate directory in
addition to cacert-2016-11-02.pem. Since we don't know what's > actually in
cacert-2016-11-02.pem, we can't provide much