[Cryptech Tech] SHA-2 security and RNG verification

[Philipp Gühring]

Hi!

> I agree that it is not a property we want. I'm trying to understand if
> and how the length extension attack would work in this case.

I don´t think that length extension attack is relevant at all in your
case. It applies to the same fundamental property, but to different use-cases.

I am far more worried about a potential problem in the CSPRNG. If anyone
discovered such a problem, your whole system is likely toasted. I think
that you can work against that.

Another idea I had was that you could add a Von-Neumann filter between
SHA-2 and the CSPRNG. Quality-wise it shouldn´t make a difference, it
should be easy to implement, and any problem in the CSPRNG will not cause
problems with SHA-2, since you can´t calculate back through the
Von-Neumann filter. It should reduce the amount of bits you get from SHA-2
by half, and I think it should be a perfect protection against any
calculating-back attacks.

> In terms of state guessability, as far as I understand it, you need to
> break the CSPRNG. That is, by observing generated values, be able to
> calculate the initial state of the CSPRNG and thus the state of the
> mixer at the time of seeding. we use the stream cipher ChaCha as our
> CSPRNG with 24 rounds by default (that is 4 more rounds that what is
> recommended by DJB for 256-bit security).

Yes, what if someone finds a problem in ChaCha (or perhaps call it an
unintentional backdoor) that can be used to calculate back?

It seems unlikely and implausible now, but that´s what we also thought
about those elliptic curve RNGs.

> So, based on this I don't see length extension attacks are applicable
> in
> this case.

Yes, there is no problem with length extension attacks.

>  And that guessability would require breaking ChaCha.

breaking or discovering a backdoor in it.

> But
> lets
> discuss further. 

Yes, that´s the potential problem I see.

> This is interesting and we want to ensure that we
> aren't vulnerable or that we have issues that we could fix to make our
> TRNG better.
 
Yes, and I think it should be easy now to protect it here.
 
> > The suggestion I have normally is to use SHA2-384 or SHA-3 instead,
> > but I am not sure, whether that´s the optimal choice for this
> > project. SHA2-384 reveals only a part of the internal state (even
> > that might be too much, I am not sure there)
> 
> Yes, only extracting part of the mixer state as seed is probably good.
> An easy change would be to use SHA-384. We are extracting two 512 bit
> words from the mixer to seed the CSPRNG, but we actually ditch parts of
> the latter word. In total we use 896 for a complete initial state of
> the
> csprng. So two words would be to little, but three works. A minor
> change.
> 
> Moving to SHA-3 is also possible and might be what we do if we decide
> on
> changing the mixer.




> > PS: I haven´t noticed a submission of your generated random numbers
> > on my RNG testsite yet, so I would like to invite you to use it: 
> > http://www.cacert.at/random/
> 
> Thanks. I'm not through with testing yet and want to ensure that we are
> comfortable that we know that it produces the values we expect (when
> given test patterns). But then sure.

Sure.

> (We are using custom tools, ent and dieharder today to verify the
> entropy sources and the TRNG output.)

Great! Yes, ent and dieharder is what I would use too, good choice at the
moment. Can you tell me more about your custom tools? Is there anything
that might be useable for my service?
I think we could really need some completely new and fresh ideas for
testing random numbers and detecting flaws in them.

Best regards,
Philipp Gühring