Yes Paul.
I tried following steps:
export INSTALLDIR=/tmp/openssl_arm
export OPENSSLDIR=/tmp/openssl_arm
export PATH=$INSTALLDIR/bin:$PATH
export CROSS=aarch64-linux-gnu
export CC=${CROSS}-gcc
export LD=${CROSS}-ld
export AS=${CROSS}-as
export AR=${CROSS}-ar
export AR=${CROSS}-ar
./C
Link against the generated .a files rather than the .so ones?
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 23 May 2019, at 4:26 pm, Raveendra Padasalagi via openssl-users
> wrote:
>
> Hi,
>
> Any help/pointers on compi
Hi,
Any help/pointers on compiling openssl library to generate static version
of openssl executable for ARM64 bit linux platform will help.
Thanks,
Raveendra
On 22/05/2019 19:32, Dennis Clarke wrote:
Good options inspired by other cryptographic libraries include:
- Number of bits of entropy passed in call (For example, a
perfectly balanced coin flipper could provide the 4 byte
values "head" or "tail" with an entropy of 1 bit).
Let's drop the
Good options inspired by other cryptographic libraries include:
- Number of bits of entropy passed in call (For example, a
perfectly balanced coin flipper could provide the 4 byte
values "head" or "tail" with an entropy of 1 bit).
Let's drop the coin flipper. It was an off hand remark an
I can understand why you may not want to break existing API. Why not add
another similar interface done the right way?
On 5/22/19, 1:11 PM, "openssl-users on behalf of Dr. Matthias St. Pierre"
wrote:
I think nobody of us needs to be convinced anymore that making it a
'double' was a bad
I think nobody of us needs to be convinced anymore that making it a 'double'
was a bad idea.
But the RAND api is very ancient and changing the argument type would be a
breaking change.
That's why we didn't dare to touch it when we overhauled the RNG implementation
for 1.1.1,
because we tried ve
> From: Chethan Kumar [mailto:chethan.ku...@toshiba-tsip.com]
> Sent: Wednesday, May 22, 2019 02:41
>
> What we are trying to achieve is, if there is failure in connection between
> host and destination, then at the host side, log messages saying to which
> destination it got failed.
So if the con
On 21/05/2019 16:44, Salz, Rich via openssl-users wrote:
When I overhauled the RAND mechanism, I tried to deprecate this use of floating
point, in favor of just a number from 0 to 100 but was voted down.
It *is* stupid. Luckily, on a modern system with system-provided randomness to
seed the R
On 5/21/2019 9:48 PM, Paul Dale wrote:
Double makes sense. Entropy is often estimated as a real value.
Having a human readable calculation using floating point doesn't (to me)
mean that an API argument has to be a double.
From what I see in the code, the parameter 'double entropy' is used
On 5/21/2019 10:07 PM, Salz, Rich via openssl-users wrote:
>Then just set it to 1.0 and be done with it.
That hardly helps on systems that don't have floating point at all.
No it doesn't. Such systems aren't supported by OpenSSL. There are many
places were floating point is u
SLES 10 is 13 years old and stopped receiving (security) updates three
years ago.
The best course of action here is to upgrade the operating system.
-Marian
Am 22.05.19 um 11:16 schrieb pcraghavendra.pra...@dell.com:
> Hi Team,
>
>
>
> Need help on the openssl library.
>
> We want to upgrad
Hi Team,
Need help on the openssl library.
We want to upgrade the openssl to the latest version available 1.1.1b.
We are using SLES 10 SP2 build box where we need to upgrade, but when we try to
upgrade it is throwing not supported error.
openssl-1.1.1b # ./config --prefix=/usr/local/openssl
Thanks for the input.
>> If applications set this using SSL_set_tlsext_host_name(), is it
>> correct to print hostname/IP in tlsext_hostname.
>"correct" in what sense? "print" where?
> Maybe. You haven't explained what you're trying to do.
What we are trying to achieve is, if there is failure in
14 matches
Mail list logo
