You're both partially right in my view. First of all I agree with Thomas, that your response was a bit unwelcoming.
In terms of your reasoning. I agree that a bad prng could inversly damage the image of the project. Which would be a shame, considering the many hours put into it so far. Thats why I like the idea of a polyfill for window.crypto.getRangomValues using fortuna. A developer has the option of adding it himself if he wants to tradeoff security against broader browser support. The nice thing is, that we don't have to change openpgp.js for that. And the potentially dangerous PRNG is not there by default. What do you think? Am 23.06.2013 um 12:24 schrieb Niklas <[email protected]>: 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]> 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]> 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
_______________________________________________ http://openpgpjs.org
