It's a dangerous addition which could lead users of browsers without
crypto.getRandomValues support believe that they are equally secure as
browsers that support it. Generating random data differently depending
on which browser the user is using is dangerous and needs to be met with
skepticism. Don't get me wrong, of course innovation should be welcomed
and encouraged. However I find it quite misleading to fail over to a
nontested PRNG instead of notifying the user that if they switch to any
modern browser that supports the replaced function all is well.
Let's be honest towards each other: it's no coincidence that Mozilla
spent five years finalizing exactly crypto.getRandomValues[1]. Those
five years weren't wasted, random entropy generation for cryptography is
extremely sensitive, those five years were spent to ensure validity.
David Dahl's and other pilgrims' work should not be ignored merely
because it is easy to call an alternative method when something is missing.
Let's start from the relevant beginning: where's the proof that shows
that the Fortuna PRNG has been properly ported to JavaScript? Why did
Fortuna never make it past the old -mm branch of the Linux kernel as a
random.c replacement[2]? In this thread I see an implemented suggested
alternative but no proof validating the fail over to Fortuna to begin with.
Welcoming attitudes by all means, cryptography is extremely fragile.
It's not about resources, it's about science. Anyone implementing
Fortuna before considering its actual strength and use is clearly not
prioritizing security but the functionality across browsers. So, do we
want secure cryptography or broken implementations that work across
browsers?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=440046
[2] http://jlcooke.ca/random/
/N
On 2013-06-23 16:50, Thomas Oberndörfer wrote:
On Sun, Jun 23, 2013 at 8:53 AM, Niklas <[email protected]
<mailto:[email protected]>> wrote:
Then perhaps you should leave it alone. People don't replace important
I would appreciate a more welcoming attitude towards contributions.
This functionality is not a replacement but an addition. If there are
currently
no resources in this project to evaluate its correctness - fair enough.
Thomas
On Sun, Jun 23, 2013 at 8:53 AM, Niklas <[email protected]
<mailto:[email protected]>> wrote:
On 2013-06-23 13:24, Dr. M. Weihrauch wrote:
> I don't exactly know
Then perhaps you should leave it alone. People don't replace important
functionality because it's mad easy to do wrong and can have
catastrophical impact on those that rely on it for security, not
because
it's a programmatic challenge calling an alternative method when the
original one is missing.
/N
_______________________________________________
http://openpgpjs.org
_______________________________________________
http://openpgpjs.org
_______________________________________________
http://openpgpjs.org
