On 10/24/2015 05:55 PM, Marcus Meissner wrote:
> On Fri, Oct 23, 2015 at 07:19:11PM +0200, Alessandro Ghedini wrote:
>> On Fri, Oct 23, 2015 at 04:34:11PM +0200, Dr. Matthias St. Pierre wrote:
>> ...
>> In general the NIST DRBGs seem fairly complicated (or completely
>> untrustworthy
>> like Dual
> Yeah, I guess both pthread and Windows implementations can both be called
> "native".
Yes, that's the intent.
> FWIW I did a quick research and NW, OS/2 and VMS all seem to support
> pthreads (but I don't know anything about those platforms, so I may be
> wrong).
That would be good.
> Incide
On Fri, Oct 23, 2015 at 07:19:11PM +0200, Alessandro Ghedini wrote:
> 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-SP80
On Sat, Oct 24, 2015 at 04:22:38PM +0200, Alessandro Ghedini wrote:
>
> So at some point I'd like to
> try and make OPENSSL_malloc & co. aliases for malloc(), realloc() and free()
> and remove (or deprecate) the custom memory functions... but that's probably a
> whole different discussion.
Please
On Fri, Oct 23, 2015 at 05:13:02pm +, Salz, Rich wrote:
> > 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
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
- 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
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
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
19 matches
Mail list logo
