Re: [openssl-dev] DRBG entropy

[Leon Brits]

Thanks for the helping me understand the whole entropy thing better. It is 
still get the feeling that this is a "best effort" thing and that nobody can 
actually proof what is correct. I am probably just bringing the math down to my 
level - sorry.

With that said for validation I still need to be sure that I give the required 
entropy back from the OpenSSL callback. Now since I am not allowed to use a 
hash with the DRBGs (FIPS lab and SP800-90B section 8.4), can you please 
confirm that, with a source of raw 2b/B entropy data, I need to return 4 times 
the data from the callback function?

Regards,

Leon Brits
System Engineer
Parsec

Work +27 12 678 9740 Cell +27 84 250 2855 Email le...@parsec.co.za
www.parsec.co.za/disclaimer 

> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of
> Paul Dale
> Sent: 28 July 2016 02:33 AM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] DRBG entropy
> 
> John's spot on the mark here.  Testing gives a maximum entropy not a
> minimum.  While a maximum is certainly useful, it isn't what you really
> need to guarantee your seeding.
> 
> A simple example which passes the NIST SP800-90B first draft tests with
> flying colours:
> 
> seed = π - 3
> for i = 1 to n do
> seed = frac(exp(1+2*seed))
> entropy[i] = 256 * frac(2^20 * seed)
> 
> where frac is the fractional part function, exp is the exponential
> function.
> 
> I.e. start with the fractional part of the transcendental π and iterate
> with a simple exponential function.  Take bits 21-28 of each iterate as a
> byte of "entropy".  Clearly there is really zero entropy present: the
> formula is simple and deterministic; the floating point arithmetic
> operations will all be correctly rounded; the exponential is evaluated in
> a well behaved area of its curve where there will be minimal rounding
> concerns; the bits being extracted are nowhere near where any rounding
> would occur and any rounding errors will likely be deterministic anyway.
> 
> Yet this passes the SP800-90B (first draft) tests as IID with 7.89 bits of
> entropy per byte!
> 
> IID is a statistical term meaning independent and identically distributed
> which in turn means that each sample doesn't depend on any of the other
> samples (which is clearly incorrect) and that all samples are collected
> from the same distribution.  The 7.89 bits of entropy per byte is pretty
> much as high as the NIST tests will ever say.  According to the test
> suite, we've got an "almost perfect" entropy source.
> 
> 
> There are other test suites if you've got sufficient data.  The Dieharder
> suite is okay, however the TestU01 suite is most discerning I'm currently
> aware of.  Still, neither will provide an entropy estimate for you.  For
> either of these you will need a lot of data -- since you've got a hardware
> RNG, this shouldn't be a major issue.  Avoid the "ent" program, it seems
> to overestimate the maximum entropy present.
> 
> 
> John's suggestion of collecting additional "entropy" and running it
> through a cryptographic has function is probably the best you'll be able
> to achieve without a deep investigation.  As for how much data to collect,
> be conservative.  If the estimate of the maximum entropy is 2.35 bits per
> byte, round this down to 2 bits per byte, 1 bit per byte or even ½ bit per
> byte.  The lower you go the more likely you are to be getting the entropy
> you want.  The trade-off is the time for the hardware to generate the data
> and for the processor to hash it together.
> 
> 
> Pauli
> --
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7
> 3031 7217 Oracle Australia
> 
> -Original Message-
> From: John Denker [mailto:s...@av8n.com]
> Sent: Wednesday, 27 July 2016 11:40 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] DRBG entropy
> 
> On 07/27/2016 05:13 AM, Leon Brits wrote:
> >
> > I have a chip (FDK RPG100) that generates randomness, but the
> > SP800-90B python test suite indicated that the chip only provides
> > 2.35 bits/byte of entropy. According to FIPS test lab the lowest value
> > from all the tests are used as the entropy and 2 is too low. I must
> > however make use of this chip.
> 
> That's a problem on several levels.
> 
> For starters, keep in mind the following maxim:
>  Testing can certainty show the absence of entropy.
>  Testing can never show the presence of entropy.
> 
> That is to say, you have ascertained that 2.35 bits/byte is an /upper
> bound/ on the entropy density coming from the chip.  If you care about
> security, you need a lower bound.  Despite what FIPS might lead you to
> believe, you cannot obtain this from testing.
> The only way to obtain it is by understanding how the chip works.
> This might require a trmendous amount of effort and expertise.
> 
> 
> 
> Secondly, entropy is probably not even the correct concept.  For 

Re: [openssl-dev] [TLS1 PRF]: unknown algorithm

[Catalin Vasile]

The scenario is kind of like this:
1. I copy the newest openssl library to the platform I am testing.
2. I build evp_test along with the newest openssl version (the one from point 
no 1) and then I copy it on the platform I am testing.
3. With an older openssl in the build path, I build a custom application, and 
then copy it on the platform.

Cata V

>From: openssl-dev  on behalf of Dr. Stephen 
>Henson 
>Sent: Wednesday, July 27, 2016 7:51 PM
>To: openssl-dev@openssl.org
>Subject: Re: [openssl-dev] [TLS1 PRF]: unknown algorithm
>    
>On Wed, Jul 27, 2016, Catalin Vasile wrote:
>
>> Hi,
>> 
>> I'm trying to use the EVP_PKEY_TLS1_PRF interface.
>> 
>> The first thing I do inside my code is:
>> pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_TLS1_PRF, NULL);
>> But pctx is NULL after that call.
>> 
>> I've watched test/evp_test.c and it does not seem it does anything special, 
>> but it successful in running the TLS1-PRF tests.
>> 
>> Is there something I'm missing?
>> 
>
>Is it linking against an older version of OpenSSL?
>
>Steve.
>--
>Dr Stephen N. Henson. OpenSSL project core developer.
>Commercial tech support now available see: http://www.openssl.org
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DRBG entropy

[Hubert Kario]

On Wednesday, 27 July 2016 15:23:21 CEST Leon Brits wrote:
> John,
> 
> Thanks for your reply.
> 
> The SP800-90B test has different types of test but the test with the lowest
> output is used as the maximum entropy capability of the chip. That is how I
> understand it from the FIPS lab.
> 
> For the FIPS validation, using a NDRNG, that source must feed the DRBG
> directly (FIPS lab) and not from something like the PRNG. I use seed the
> /dev/random from the NDRNG and then source from the PRNG, but that is not
> allowed for DRBGs. Again I hope I understand them correct.

but PRNG and DRBG is the same thing, both generate pseudo-random numbers from 
a seed using (hopefully) a cryptographically secure algorithm

FIPS definitely allows you to use output of one DRBG to seed other DRBG

in the end, you should gather as much entropy as possible in the system, and 
mix it all together and then use output of a DRBG that uses all that entropy 
to seed other DRBGs

what that means in practical terms, is feed output from your NDRNG to kernel's 
entropy pool and seed everything from /dev/urandom output (or getrandom())

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DRBG entropy

[Short, Todd]

See:

https://tools.ietf.org/html/rfc4086

Section 4 suggests ways to de-skew.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On Jul 28, 2016, at 6:51 AM, Hubert Kario  wrote:
> 
> On Wednesday, 27 July 2016 15:23:21 CEST Leon Brits wrote:
>> John,
>> 
>> Thanks for your reply.
>> 
>> The SP800-90B test has different types of test but the test with the lowest
>> output is used as the maximum entropy capability of the chip. That is how I
>> understand it from the FIPS lab.
>> 
>> For the FIPS validation, using a NDRNG, that source must feed the DRBG
>> directly (FIPS lab) and not from something like the PRNG. I use seed the
>> /dev/random from the NDRNG and then source from the PRNG, but that is not
>> allowed for DRBGs. Again I hope I understand them correct.
> 
> but PRNG and DRBG is the same thing, both generate pseudo-random numbers from
> a seed using (hopefully) a cryptographically secure algorithm
> 
> FIPS definitely allows you to use output of one DRBG to seed other DRBG
> 
> in the end, you should gather as much entropy as possible in the system, and
> mix it all together and then use output of a DRBG that uses all that entropy
> to seed other DRBGs
> 
> what that means in practical terms, is feed output from your NDRNG to kernel's
> entropy pool and seed everything from /dev/urandom output (or getrandom())
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic--
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DRBG entropy

[John Denker]

Let's play a guessing game.  I provide a hardware-based random number
generator of my choosing.  It produces a stream of bytes.  It has
an entropy density greater than 2.35 bits per byte.  This claim is
consistent with all the usual tests, but it is also more than that;
it is not just "apparent" entropy or an upper bound based on testing,
but real honest-to-goodness Boltzmann entropy.  The bytes are IID
(independent and identically distributed).  The design and 
implementation are open to inspection.

On each move in this game, I try to predict the exact value of the
next byte.  Every time I succeed, you pay me a dollar; every time
I fail, I pay you a dollar.  We play at least 100 moves, to minimize
stray fluctuations.

The point is, if you think entropy is a good measure of resistance
to guessing, then you should be eager to play this game, expecting
a huge profit.

Would anybody like to play?


On 07/28/2016 12:40 AM, Leon Brits wrote:
> Thanks for the helping me understand the whole entropy thing better.
>  It is still get the feeling that this is a "best effort" thing and 
> that nobody can actually proof what is correct. I am probably just 
> bringing the math down to my level - sorry.
> 
> With that said for validation I still need to be sure that I give the
> required entropy back from the OpenSSL callback. Now since I am not
> allowed to use a hash with the DRBGs (FIPS lab and SP800-90B section
> 8.4), can you please confirm that, with a source of raw 2b/B entropy
> data, I need to return 4 times the data from the callback function?

That depends on what the objective is.  The objective is not
obvious, as discussed below.

> According to FIPS test lab the lowest value from all the tests are 
> used as the entropy and 2 is too low.

  1a) I assume the idea that "2 is too low" comes from the FIPS lab.

  1b) I assume the designer's boss doesn't directly care about this,
   so long as the FIPS lab is happy.

  1c) This requirement has little if any connection to actual security.

> I must however make use of this chip.

  2a) I assume the FIPS lab doesn't care exactly which chip is used.

  2b) I assume this requirement comes from the boss.

  2c) This requirement has little if any connection to actual security.

> I am not allowed to use a hash with the DRBGs (FIPS lab and
> SP800-90B section 8.4),

Where's That From?  Section 8.4 says nothing about hashes.  It's about
health testing.  The hash doesn't interfere with health testing, unless
the implementation is badly screwed up.

Furthermore, in sections 8.2 and 8.3, and elsewhere, there is explicit
consideration of "conditioning", which is what we're talking about.

  3a) Does this requirement really come from the FIPS lab?  It 
   certainly doesn't come from SP800-90B as claimed.

  3c) This requirement has nothing to do with actual security.

> It is still get the feeling that this is a "best effort" thing and 
> that nobody can actually proof what is correct.

Where's That From?

Proofs are available, based on fundamental physics and math, delineating
what's possible and what's not.

> can you please confirm that, with a source of raw 2b/B entropy data, 
> I need to return 4 times the data from the callback function?

Two answers:
 -- My friend Dilbert says you should do that, in order to make the
  pointy-haired boss happy.
 -- You should not, however, imagine that it provides actual security.

> I have a chip (FDK RPG100) that generates randomness, but the
> SP800-90B python test suite indicated that the chip only provides
> 2.35 bits/byte of entropy

That means the chip design is broken in ways that the manufacturer
does not understand.  The mfgr data indicates it "should" be much
better than that:
  http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf

The mfgr has not analyzed the thing properly, and nobody else will
be able to analyze it at all.  The block diagram in the datasheet
is a joke:
  http://www.fdk.com/cyber-e/pdf/HM-RAE106.pdf#Page=9

> I must however make use of this chip.

My friend suggests you XOR the chip output with a decent, well-
understood HRNG.  That way you can tell the pointy-haired boss
that you "make use of this chip".





Bottom line: consider the contrast:
-- I'm seeing a bunch of feelings and made-up requirements.
-- I have not yet seen any sign of concern for actual security.

Under such conditions it is not possible to give meaningful advice
on how to proceed.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DRBG entropy

[Kurt Roeckx]

On Wed, Jul 27, 2016 at 05:32:49PM -0700, Paul Dale wrote:
> John's spot on the mark here.  Testing gives a maximum entropy not a minimum. 
>  While a maximum is certainly useful, it isn't what you really need to 
> guarantee your seeding.

Fom what I've read, some of the non-IID tests actually underestimate
the actual entropy.  Which is of course better the overestimating
it, but it's also annoying.

It will also never give a value higher than 6, since one of the
tests only uses 6 bits of the input.

> IID is a statistical term meaning independent and identically distributed 
> which in turn means that each sample doesn't depend on any of the other 
> samples (which is clearly incorrect)

You shouldn't run the IID tests when you clearly know it's not an
IID.  If fact, if you're not sure it's an IID you should use the
non-IID tests.


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Building current master fails when option no-nextprotoneg is used

[Michel]

Hi,

 

Just to let you know that today's master fails to build when option
no-nextprotoneg is used.

Build stop when linking ssl_test.exe :

 

cl  /I "." /I "include" /I "include" -DOPENSSL_USE_APPLINK
-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE
-DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM  -DWHIRLPOOL_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
-DOPENSSL_API_COMPAT=0x1010L
"-DENGINESDIR=\"C:\\OpenSSL_DLL\\lib\\engines-1_1\""
"-DOPENSSLDIR=\"c:\\OpenSSL_DLL\\ssl\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo
-DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN
-D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2 /Zi /Fdapp -c
/Fotest\ssl_test_ctx.obj "test\ssl_test_ctx.c" ssl_test_ctx.c

IF EXIST test\ssl_test.exe.manifest DEL /F /Q
test\ssl_test.exe.manifest

 

link /nologo /debug /subsystem:console /opt:ref
/out:test\ssl_test.exe @C:\Users\...\AppData\Local\Temp\nm4C03.tmp

handshake_helper.obj : error LNK2019: unresolved external symbol
_SSL_CTX_set_next_protos_advertised_cb referenced in function
_configure_handshake_ctx

handshake_helper.obj : error LNK2019: unresolved external symbol
_SSL_CTX_set_next_proto_select_cb referenced in function
_configure_handshake_ctx

handshake_helper.obj : error LNK2019: unresolved external symbol
_SSL_get0_next_proto_negotiated referenced in function
_do_handshake_internal

test\ssl_test.exe : fatal error LNK1120: 3 unresolved externals

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
12.0

\VC\BIN\link.EXE"' : return code '0x460'

Stop.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] 1.0.2h Compile fails if OPENSSL_NO_SHA512 is defined

[Rod Falck]

I am defining OPENSSL_NO_SHA512 and get a compilation error in ssl/t1_lib.c:

[08:47:30][Step 3/5]   c->pkeys[SSL_PKEY_ECC].digest = 
EVP_sha384();
[08:47:30][Step 3/5] ^
[08:47:30][Step 3/5] 
"D:\BuildAgent\sandbox_OpenSSL_NSK_TNSR_Debug\ssl/t1_lib.c", line 902: 
error(611):
[08:47:30][Step 3/5]   a value of type "int" cannot be assigned to an 
entity of type
[08:47:30][Step 3/5]   "const EVP_MD *"

The above code does not depend on OPENSSL_NO_SHA512 but EVP_sha384 is does not 
get declared in evp.h:

# ifndef OPENSSL_NO_SHA512
const EVP_MD *EVP_sha384(void);
const EVP_MD *EVP_sha512(void);
# endif

and therefore defaults to returning int, resulting in the compile error. The 
function containing error code, tls1_check_cert_param, did not exist in 1.0.1.

For now I have just included the #ifndef, but is that sufficient?

Rod.
--
Rod Falck. Software Architect. comForte Pty Ltd.

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] DRBG entropy

[Paul Dale]

I probably should have mentioned this in my earlier message, but the 
exponential example is valid for the NSIT SP800-90B non-IID tests too: 5.74889 
bits per byte of assessed entropy.  Again about as good a result as the tests 
will ever produce given the ceiling of six on the output.  There is still zero 
actual entropy in the data.  The tests have massively over estimated.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia


-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be] 
Sent: Friday, 29 July 2016 8:31 AM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] DRBG entropy

On Wed, Jul 27, 2016 at 05:32:49PM -0700, Paul Dale wrote:
> John's spot on the mark here.  Testing gives a maximum entropy not a minimum. 
>  While a maximum is certainly useful, it isn't what you really need to 
> guarantee your seeding.

Fom what I've read, some of the non-IID tests actually underestimate the actual 
entropy.  Which is of course better the overestimating it, but it's also 
annoying.

It will also never give a value higher than 6, since one of the tests only uses 
6 bits of the input.

> IID is a statistical term meaning independent and identically 
> distributed which in turn means that each sample doesn't depend on any 
> of the other samples (which is clearly incorrect)

You shouldn't run the IID tests when you clearly know it's not an IID.  If 
fact, if you're not sure it's an IID you should use the non-IID tests.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] CA chain.

[asmarner]

Hi,
I am new to SSL stuff.
I was wondering whether the CA chain of a certificate can be changed.
Let say the initial chain is 

Server->Intermediate CA1->Intermediate CA2->Root CA
and during renewal we have Server->Root CA


Sent from Yahoo Mail. Get the app-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev