Remove ZrtpFortuna, use SecureRandom instead

[champtar]

We are not reseeding Fortuna RNG,
so we are not sure it's still safe to use

See FortunaGenerator doc (Adding Random Data)

Signed-off-by: Etienne CHAMPETIER champetier.etienne@gmail.com

[wernerd]

It's OK to modify the ZRTP4J sources for your project, however not every system may have a sufficient secure random generator thus the generic ZRTP4J project should still use it.

[champtar]

Hi @wernerd,
I've started to ask on reddit, and Fortuna as used here is not safe as we are not reseeding
https://www.reddit.com/r/crypto/comments/4daxax/is_fortuna_rng_without_reseeding_safe/

What you are telling me is that you take an insecure seed (if SecureRandom is insecure), put it into FortunaGenerator and it become magically secure?
Please give me a system where SecureRandom is insecure, because right now ZrtpFortuna seems to be insecure on every system.

[wernerd]

If you don't seed or re-seed a random number generator then it's not save to use
it at all, that's true for any random number generator. If you don't re-seed
the Fortuna generator than obviously it's 'cryptograhically strong'. It was an
agreement that the project (Jitsi) uses data to regularly seed (add entropy) to
the generator.

Actually, there is no such thing as a "secure seed", the data used to seed the
or added as seed (entropy) over the lifetime of the generator shall not be used
outside or known to or controlled by a potential attacker. The PRNG then uses
this entropy to generate random data. The entropy is never 'secure' in that sense.

See the Wikipedia about the Fortuna generator regarding its properties. Just two
quotes:

"Fortuna is a cryptographically secure pseudorandom number generator (PRNG) ... "

"Unless an attacker is able to control all the sources of alleged entropy flowing
into the system (in which case no algorithm can save it from compromise), there
will be some k for which the kth pool collects enough entropy between reseedings
that a reseeding with that pool ensures security. "

Am 04.04.2016 um 16:42 schrieb champtar:

Hi @wernerd https://github.com/wernerd,
I've started to ask on reddit, and Fortuna as used here is not safe as we are not reseeding
https://www.reddit.com/r/crypto/comments/4daxax/is_fortuna_rng_without_reseeding_safe/

What you are telling me is that you take an insecure seed (if SecureRandom is insecure), put it into FortunaGenerator and it become magically secure?
Please give me a system where SecureRandom is insecure, because right now ZrtpFortuna seems to be insecure on every system.

Fortuna is 'secure' if the application feeds some entropy from a/several source(s)
not controlled by a potential attacker. IIRC in Jitsi uses several seconds of audio
data (noise) as entropy to seed the Fortuna generator. This entropy is not known to
or controlled by an attacker. The whole idea of a PRNG is to generate random data
using this entropy - thus, yes, Fortuna generates 'secure', better 'cryptographically
strong', random data from 'unsecure' entropy - as long as this entropy is not known
to the attacker :-)

The link to the Wikipedia: https://en.wikipedia.org/wiki/Fortuna_(PRNG)

BTW, the current Fortuna implementation does not store a seed file, it requires seeding
right after start to get a first set of entropy, in Jitsi this is audio noise IIRC.

Werner

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #5 (comment)

Werner Dittmann
email: Werner.Dittmann@t-online.de
cell: +49 173 44 37 659
PGP key: 82EF5E8B

[champtar]

I've a pending PR to remove all ZrtpFortuna from jitsi jitsi/libjitsi#113 (my project is jitsi)

I know that Fortuna is a CSPRNG, the problem is that you have to implement and use it the right way. As most of the times in crypto the problem is not the algo, it's the implementation.

In this specific case, the entropy gathering depends on audio noise gathering.
This was fine for jitsi, as you expect jitsi to have working audio, but here comes jvb, on a virtual machine, with no audio device, and now entropy gathering is broken, without even a warning :)

The problem with ZrtpFortuna/FortunaGenerator is that there is no failsafe, if you don't gather entropy/reseed it, it still outputs 'pseudo-random' data, without warning or exception.
Also there are no random sources other than SecureRandom in a VM, so what should we use?

Etienne

[wernerd]

Am 04.04.2016 um 20:13 schrieb champtar:

I've a pending PR to remove all ZrtpFortuna from jitsi jitsi/libjitsi#113 jitsi/libjitsi#113 (my project is jitsi)

I know that Fortuna is a CSPRNG, the problem is that you have to implement and use it the right way. As most of the times in crypto the problem is not the algo, it's the implementation.

In this specific case, the entropy gathering depends on audio noise gathering.
This was fine for jitsi, as you expect jitsi to have working audio, but here comes jvb, on a virtual machine, with no audio device, and now entropy gathering is broken, without even a warning :)

If jvb does no use audio: why do you need ZRTP then? ZRTP in Jitsi requires
a RTP sessions for example. Without audio and I expect without video, what's
the use case for ZRTP?

The problem with ZrtpFortuna/FortunaGenerator is that there is no failsafe, if you don't gather entropy/reseed it, it still outputs 'pseudo-random' data, without warning or exception.
Also there are no random sources other than SecureRandom in a VM, so what should we use?

It's clearly stated in the Fortuna documentation that the application has to
provide entropy, this could be even a simple /dev/random or some other data
that the app gathers, for example when setting up a audio connection then use
the first few packets as entropy and not sending out this data.

For a developer of secure communication clients it's of paramount importance to
check these things and put this into the app ;-) .

Thus you are free to use Fortuna in a VM as long as the application can provide
some entropy. Actually a built-in CSPRNG, in Linux for example, is also just
a PRNG that uses some system events/data as entropy. If you have a system that
does not have a built-in CSPRNG then you need some other way to get random data.
That was the use case to use case Fortuna in Jitsi - at that time no real, proven
CSPRNG was available and also w don't know on which systems Jitsi will run and
thus cannot check if that system provides a built-in CSPRNG. Jitsi was (is?)
designed to run on a number of different system platforms.

Werner

Etienne

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #5 (comment)

Werner Dittmann
email: Werner.Dittmann@t-online.de
cell: +49 173 44 37 659
PGP key: 82EF5E8B

[champtar]

And it's clearly NOT stated in ZrtpFortuna doc (just read it twice) that you MUST provide entropy.
ZrtpFortuna (not Fortuna) is unsafe by default, where SecureRandom is safe by default.

I agree we can find ways to provide entropy, but it's really too easy to use it in unsafe ways.
How much bytes should we provide? how often? ZrtpFortuna is not a fail waiting to happen, it happened already :)

I know Linux is using a CSPRNG, the difference is that the entropy gathering is always taken care of.

All Java implementation on all platform have SecureRandom for quite some time, why not use it now?
Please name a system without CSPRNG (Linux, OSX, Windows?).

Also jitsi/libjitsi#113 is now merged so there is no ZrtpFortunaEntropyGatherer anymore, so please merge this.

[ibauersachs]

@wernerd There's no use of ZRTP in the Videobridge. However we used ZrtpFortuna as the default random source for ZRTP, then SDES and then DTLS. Reseeding of Fortuna never happened in Jitsi. And the supposedly random initialization with audio noise also wasn't happening (at least on some systems) because the capture device simply provided zeros, likely because of noise cancellation. This was a major #fail because we seeded Fortuna with zero (until jitsi/libjitsi@8648e19).
Later on the only halfway safeguard for libjitsi usages on devices without audio/capture devices was jitsi@1bd0743.

I'm not sure if this PR is the right way to go, but I agree with @champtar that ZrtpFortuna is dangerous and detrimental to the intended goal of making things more secure.

[champtar]

thanks @ibauersachs
@wernerd i'm not sure my PR is the best way to go, but i'm sure that for now ZrtpFortuna is unsafe, and that my PR make things safe, so if you don't have a better solution in mind please consider the safety of the users and merge this

[wernerd]

ZrtpFortuna is just a wrapper to Fortuna, not the real generator. It's the "Fortuna" documentation
I was refering to.

Fell free to do whatever you wan't in your project :-) - that'S the beauty of open
source, isn't it.

Werner

Am 05.04.2016 um 09:06 schrieb champtar:

And it's clearly NOT stated in ZrtpFortuna doc (just read it twice) that you MUST provide entropy.
ZrtpFortuna (not Fortuna) is unsafe by default, where SecureRandom is safe by default.

I agree we can find ways to provide entropy, but it's really too easy to use it in unsafe ways.
How much bytes should we provide? how often? ZrtpFortuna is not a fail waiting to happen, it happened already :)

I know Linux is using a CSPRNG, the difference is that the entropy gathering is always taken care of.

All Java implementation on all platform have SecureRandom for quite some time, why not use it now?
Please name a system without CSPRNG (Linux, OSX, Windows?).

Also jitsi/libjitsi#113 jitsi/libjitsi#113 is now merged so there is no ZrtpFortunaEntropyGatherer anymore, so please merge this.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #5 (comment)

Werner Dittmann
email: Werner.Dittmann@t-online.de
cell: +49 173 44 37 659
PGP key: 82EF5E8B

[champtar]

@wernerd i know FortunaGenerator doc is explicit, but ZrtpFortuna is not!
If you still think insecure by default is the way to go, please close this PR