[jitsi-dev] Dropping ZrtpFortuna / ZRTP security


#1

Hi all,

Fortuna is a nice CSPRNG that need constant reseeding/entropy addition to
work.

ZrtpFortunaEntropyGatherer was our entropy gatherer but it was totally
broken and not safe, that's why i've replaced all calls to ZrtpFortuna
and ZrtpFortunaEntropyGatherer
with Securerandom in libjitsi (https://github.com/jitsi/libjitsi/pull/113)

As we know that ZrtpFortuna (FortunaGenerator singleton) is unsafe, I've
submitted https://github.com/jitsi/zrtp4j/pull/1 to remove last calls to
ZrtpFortuna.
This PR was rejected by Ingo because he prefer to have this integrated
upstream first (and I totally agree).

So I sent the same PR upstream (https://github.com/wernerd/ZRTP4J/pull/5)
but Werner Dittmann (@wernerd / author maintainer of zrtp4j) rejected it
saying that ZrtpFortuna is safer than SecureRandom and we just need to use
it the right way (add entropy constantly) (we already failed once with
ZrtpFortunaEntropyGatherer
...).

I asked Ingo to reconsider https://github.com/jitsi/zrtp4j/pull/1, but he
refuses again (https://github.com/jitsi/zrtp4j/pull/1#issuecomment-209601254
)
This only impact Jitsi/ZRTP, and as I'm not a Jitsi/ZRTP user, I will not
start and maintain a fork of zrtp4j (as suggested by Ingo).

So to sum up 3 peoples (Ingo, Werner and I) agree that ZrtpFortuna as
currently used is unsafe, but nobody want to merge a fix, and code stay
unsafe.

Regards
Etienne

P.S: This is not a rant and I just really want to unlock the situation


#2

Hi Etienne,

...

Fortuna is a nice CSPRNG that need constant reseeding/entropy addition
to work.

...

So I sent the same PR upstream
(https://github.com/wernerd/ZRTP4J/pull/5) but Werner Dittmann
(@wernerd / author maintainer of zrtp4j) rejected it saying that
ZrtpFortuna is safer than SecureRandom and we just need to use it the
right way (add entropy constantly) (we already failed once with
ZrtpFortunaEntropyGatherer ...).

Is there any objection to adding a SecureRandom as an additional entropy
source to ZrtpFortuna?

Best,

Jesse

···

On Wed, 2016-05-04 at 09:45 +0200, Etienne Champetier wrote:


#3

Hi,

Hi Etienne,

...

> Fortuna is a nice CSPRNG that need constant reseeding/entropy addition
> to work.

...
>
> So I sent the same PR upstream
> (https://github.com/wernerd/ZRTP4J/pull/5) but Werner Dittmann
> (@wernerd / author maintainer of zrtp4j) rejected it saying that
> ZrtpFortuna is safer than SecureRandom and we just need to use it the
> right way (add entropy constantly) (we already failed once with
> ZrtpFortunaEntropyGatherer ...).
>

Is there any objection to adding a SecureRandom as an additional entropy
source to ZrtpFortuna?

If you use SecureRandom as a source of entropy for ZrtpFortuna, then why
not use SecureRandom directly?
Adding code always make thing less safe ...

···

2016-05-04 14:21 GMT+02:00 Jesse <bickelj@gmail.com>:

On Wed, 2016-05-04 at 09:45 +0200, Etienne Champetier wrote:

Best,

Jesse

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hi,

···

On Wed, 2016-05-04 at 14:30 +0200, Etienne Champetier wrote:

Hi,

2016-05-04 14:21 GMT+02:00 Jesse <bickelj@gmail.com>:
        Hi Etienne,
        
        On Wed, 2016-05-04 at 09:45 +0200, Etienne Champetier wrote:
        ...
        
        > Fortuna is a nice CSPRNG that need constant
        reseeding/entropy addition
        > to work.
        
        ...
        >
        > So I sent the same PR upstream
        > (https://github.com/wernerd/ZRTP4J/pull/5) but Werner
        Dittmann
        > (@wernerd / author maintainer of zrtp4j) rejected it saying
        that
        > ZrtpFortuna is safer than SecureRandom and we just need to
        use it the
        > right way (add entropy constantly) (we already failed once
        with
        > ZrtpFortunaEntropyGatherer ...).
        >
        
        Is there any objection to adding a SecureRandom as an
        additional entropy
        source to ZrtpFortuna?

If you use SecureRandom as a source of entropy for ZrtpFortuna, then
why not use SecureRandom directly?

Adding code always make thing less safe ...

The reason for not using SecureRandom directly is Werner believes
ZrtpFortuna is safer than SecureRandom. If I understand it correctly, it
also aggregates multiple entropy sources. If it is at least using
SecureRandom as one of its entropy sources, at worst it cannot be worse
than SecureRandom, assuming correct implementation, right?

Jesse