Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can you go into more detail about this? Because I hear "biased RNG" and the switch that flips in my head is "never use this thing".


Considering how tiny the bias is along with the added complexity of the solution (in a chaotic language like Javascript, no less), I'd say the SpiderOak people are not crazy for not having accepted it. There would be somewhat of an argument here if the original was reducing random bytes modulo 84. As it is, this is almost like dinging EdDSA for doing a similar thing: reducing a 512-bit number modulo a 252-bit integer instead of doing the 'proper' procedure.


> I'd say the SpiderOak people are not crazy for not having accepted it.

They didn't simply not accept it.

They tossed one bit of feedback my way, which I addressed in a follow-up commit, and then they neglected to do anything further. No discussion, no rejection, etc.

If they wanted to reject it because of complexity concerns, I would have been fine with that. At least it would have been some sort of closure, and I wouldn't feel like the person I replied to originally about this project being inactive. If it turns out that they're actually still planning to develop it further, I'm happy to be proven wrong about that.

Today, 'dchest wrote a superseding PR that solves the problem while maintaining a very small code diff, and I'd prefer his solution over my own. (I have no ego about my JavaScript coding skills. There are tens of millions of people who can do it better than me.)


Thank you for your interest and efforts to contribute to the project.

I think there were some questions about your patch that you did not answer, and reviewers moved to other projects. Honestly we felt overall the patch was low quality. Certainly the serious error in the first version of the patch which dramatically added bios didn't help. In general we had already completed auditing the selection approach taken by the existing password generation code and did not want to consider a different approach for little benefit.

We should have given you better feedback. Sorry.


No hard feelings. :)


Yeah, I literally didn't know what the bias was in this case. I should have worded that comment differently. Thanks!


The password generator gets 32 bit random values and then does modulus 84 to pick characters. There is a bias, but it has as much entropy as a perfect generator choosing out of 83.999999999999999 characters.

Edit: The question in my mind is whether it was oversight or intentional simplicity. The first is a bad sign, the second isn't a big deal.


Considering they had earlier tickets opened by their own team to fix it and hadn't, I'm calling "oversight".

https://github.com/SpiderOak/Encryptr/issues/49

That being said, I do agree with your analysis that the impact of this isn't a problem for users.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: