EAY is Eric A. Young, the original author of SSLeay, which became OpenSSL.
https://en.wikipedia.org/wiki/SSLeay
-Ben
On 10/23/2015 09:44 PM, Fan Zhang wrote:
> Thanks that seems to be the right place to look into.
>
> btw, what does eay stand for?
>
>> On Oct 23, 2015, at 5:50 PM, Benjamin Kad
Thanks that seems to be the right place to look into.
btw, what does eay stand for?
> On Oct 23, 2015, at 5:50 PM, Benjamin Kaduk wrote:
>
> On 10/23/2015 04:27 PM, Fan Zhang wrote:
>> Hi, all,
>>
>> Happy to meet your guys by this email. I’m trying to dig into the code base
>> and find an im
If you are going to make all that effort you may as well go for FIPS compliance as the default.SP800-90 A/B/C do cover the areas of concern, the algorithms are simple and clear as is the overall flow of processing to start from 'noise' to produce safe and reliable TRNG/PRNG's. More importantly, yo
On 10/23/2015 08:22 AM, Alessandro Ghedini wrote:
> Hello everyone,
>
> (sorry for the wall of text...)
>
> one of the things that both BoringSSL and LibreSSL have in common is the
> replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner
> alternative. Given RAND_SSLeay() compl
On 23/10/15 15:33, Albe Laurenz wrote:
> Matt Caswell wrote:
>> On 16/10/15 16:05, Hubert Kario via RT wrote:
>>> we may actually be able to patch this up partially in 1.0.x
>>>
>>> the original problem description mentions server being unable to process
>>> application data before Certificate/Cl
On 10/23/2015 04:27 PM, Fan Zhang wrote:
> Hi, all,
>
> Happy to meet your guys by this email. I’m trying to dig into the code base
> and find an implementation of RSA signature. Naturally, I looked into the
> function `int RSA_sign` in file `crypto/rsa/rsa_sign.c`, which further calls
> the `RS
Hi, all,
Happy to meet your guys by this email. I’m trying to dig into the code base and
find an implementation of RSA signature. Naturally, I looked into the function
`int RSA_sign` in file `crypto/rsa/rsa_sign.c`, which further calls the
`RSA_private_encrypt` and `RSA_private_encrypt` calls t
On 10/23/2015 01:38 PM, Vijay Singh wrote:
>
> It seems that the library uses 13 bytes of AAD data. Is this per-spec?
> The reason I am asking is that the new Intel AESNI APIs that provide
> HW support seem to require AAD as a multiple of 4 bytes, and 0 padding
> the AAD changes the computed auth v
- the non-CryptGenRandom() code on Windows is just crazy. Do we even support
Windows versions before XP?
Some of that code really needs to go away, specifically the heap walk
code. It is extremely unsafe, and crashes ~66% of the time when running
under the Visual Studio debugger. There's
On Fri, Oct 23, 2015 at 03:22:39PM +0200, Alessandro Ghedini wrote:
> Hello everyone,
>
> (sorry for the wall of text...)
>
> one of the things that both BoringSSL and LibreSSL have in common is the
> replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner
> alternative. Given
It seems that the library uses 13 bytes of AAD data. Is this per-spec? The
reason I am asking is that the new Intel AESNI APIs that provide HW support
seem to require AAD as a multiple of 4 bytes, and 0 padding the AAD changes
the computed auth value.
Any insights are much appreciated.
-vijay
___
On Fri, Oct 23, 2015 at 04:34:11PM +0200, Dr. Matthias St. Pierre wrote:
>
> Hi,
>
> I have a related question concerning alternative RNGs, hope it is not too
> off-topic:
>
> Currently we are using the NIST-SP800-90a compliant DRBG (fips_drbg_method()),
> because it seemed to us to be more soph
> Yes, that's what BoringSSL does. They have three implementations: pthread,
> windows and none (which is just nops). I don't know what the availability of
> pthreads is on the above platforms (NW, OS/2 and VMS), but it should cover
> quite a bit of platforms.
I'd instead have two: native or none
On Fri, Oct 23, 2015 at 05:40:29PM +0300, Dmitry Belyavsky wrote:
> Hello Alexander,
>
> On Fri, Oct 23, 2015 at 4:22 PM, Alessandro Ghedini
> wrote:
>
>
> > So, any thought? If there's interest in this, I can look into investigating
> > these things more in detail and propose possible patches.
On Fri, Oct 23, 2015 at 02:30:14pm +, Salz, Rich wrote:
> I am very interested in cleaning this area up. We still do care about
> Netware, OS/2, and VMS; I don't think we care about pre-XP Windows.
Ok.
> We have broader portability issues than boringSSL does, so my thoughts on
> threading ar
Hello Alexander,
On Fri, Oct 23, 2015 at 4:22 PM, Alessandro Ghedini
wrote:
> So, any thought? If there's interest in this, I can look into investigating
> these things more in detail and propose possible patches.
>
>
In Russia we have to certify the RNG hardware and software for using in
organ
On Fri, Oct 23, 2015 at 5:22 PM, Alessandro Ghedini
wrote:
> Hello everyone,
>
> ...
>
> For comparison, OpenBSD's getentropy() implementation [0] is much cleaner
> and
> supports many of the platforms supported by OpenSSL.
>
> So, any thought? If there's interest in this, I can look into investi
Hi,
I have a related question concerning alternative RNGs, hope it is not too
off-topic:
Currently we are using the NIST-SP800-90a compliant DRBG (FIPS_drbg_method()),
because it seemed to us to be more
sophisticated and mature than the default RAND_SSLeay(). At least it's better
documented a
Matt Caswell wrote:
> On 16/10/15 16:05, Hubert Kario via RT wrote:
>> we may actually be able to patch this up partially in 1.0.x
>>
>> the original problem description mentions server being unable to process
>> application data before Certificate/Client Key Exchange, not in any
>> place what so e
Matt Caswell wrote:
> On 16/10/15 16:05, Hubert Kario via RT wrote:
>> we may actually be able to patch this up partially in 1.0.x
>>
>> the original problem description mentions server being unable to process
>> application data before Certificate/Client Key Exchange, not in any
>> place what so e
I am very interested in cleaning this area up. We still do care about Netware,
OS/2, and VMS; I don't think we care about pre-XP Windows.
We have broader portability issues than boringSSL does, so my thoughts on
threading are different: two builds, either "not threaded" or "use native
system
On Fri, Oct 23, 2015 at 03:38:51pm +0200, Tomas Mraz wrote:
> On Pá, 2015-10-23 at 15:22 +0200, Alessandro Ghedini wrote:
> ...
> > BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to
> > RAND_bytes(). Additionally, if the RDRAND instruction is available, the
> > output
>
On Pá, 2015-10-23 at 15:22 +0200, Alessandro Ghedini wrote:
...
> BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to
> RAND_bytes(). Additionally, if the RDRAND instruction is available, the output
> of RDRAND is mixed with the output of the system RNG using ChaCha20. This
Hello everyone,
(sorry for the wall of text...)
one of the things that both BoringSSL and LibreSSL have in common is the
replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner
alternative. Given RAND_SSLeay() complexity I think it'd be worth to at least
consider possible alte
Patch fixes
LIBEAY32.def : error LNK2001: unresolved external symbol
TS_CONF_set_crypto_device
LIBEAY32.def : error LNK2001: unresolved external symbol
TS_CONF_set_default_engine
caused by always adding those functions to .def file
Ensure they are added only if engine is not disabled
Regards
-
25 matches
Mail list logo
