5 ms·

Latest commit 5fdc936 on Dec 18, 2015 Is this still an active project? 4 months is a long time to pass without a commit published.

CiPHPerCoder 11y ago
I lean towards "No". For example, this was never merged: https://github.com/SpiderOak/Encryptr/pull/180 https://github.com/SpiderOak/Encryptr/pull/180 I eventually closed it because I keep an eye on https://github.com/pulls https://github.com/pulls and it was unnecessary clutter.
- ekrizzle 11y ago
  One reason that was never merged was because it was a flawed patch to a non-problem. - Erin @ SpiderOak
  - CiPHPerCoder 11y ago
    The "non-problem" of a biased PRNG is that you get reduced entropy in your generated passwords, thus reducing security. The "flaw" in the pull request was fixed in a later commit (by switching to Uint8Array instead of Uint32Array), and then it was ignored by the SpiderOak team.
    - Dylan16807 11y ago
      Selecting one of 84 characters purely randomly gives you 6.3923174227787602763 bits of entropy. Selecting one of 84 characters by using modulus on a 32 bit random number gives you 6.3923174227787602889 bits of entropy. It is a bug, but it is absolutely a non-problem. The difference you would get from using 83 or 85 characters is many orders of magnitude larger; this is not something that needs such an enormous level of precision.
  - dchest 11y ago
    Wow. While the bias was tiny, I expect more from crypto software. Calling it a "non-problem" is very strange. Edit: submitted another patch https://github.com/SpiderOak/Encryptr/pull/263 https://github.com/SpiderOak/Encryptr/pull/263
    - rarrrrrr 11y ago
      Thank you! We'll take a look. By the way: I recognized your nick from various repos you've authored/contributed to. Always really solid stuff!
      - dchest 11y ago
        Thanks!
  - tptacek 11y ago
    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".
    - Dylan16807 11y ago
      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.
      - CiPHPerCoder 11y ago
        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 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.
    - pbsd 11y ago
      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.
      - CiPHPerCoder 11y ago
        > 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.)
  - marshray 11y ago
    While I agree that 2^32%85 produces a minuscule bias, there's this thing called base 64 that interoperates pretty well with arbitrary byte strings.
nitrogen 11y ago
Sometimes software is just "done", you know, or only needs updates every few years.
- dsp1234 11y ago
  That there are 93 issues including what appear to be UI issues implies that this project is probably not in that category though.
- JshWright 11y ago
  Yes, but those projects don't generally include references to things that are "coming soon" in the readme.
- zymhan 11y ago
  Sure, if it's a command line tool that does something simple maybe. Not a project that depends on a bunch of modern frameworks and has a mobile app. Plus, it's security software.

CiPHPerCoder 11y ago

I lean towards "No". For example, this was never merged: https://github.com/SpiderOak/Encryptr/pull/180 https://github.com/SpiderOak/Encryptr/pull/180 I eventually closed it because I keep an eye on https://github.com/pulls https://github.com/pulls and it was unnecessary clutter.

ekrizzle 11y ago
One reason that was never merged was because it was a flawed patch to a non-problem. - Erin @ SpiderOak
- CiPHPerCoder 11y ago
  The "non-problem" of a biased PRNG is that you get reduced entropy in your generated passwords, thus reducing security. The "flaw" in the pull request was fixed in a later commit (by switching to Uint8Array instead of Uint32Array), and then it was ignored by the SpiderOak team.
  - Dylan16807 11y ago
    Selecting one of 84 characters purely randomly gives you 6.3923174227787602763 bits of entropy. Selecting one of 84 characters by using modulus on a 32 bit random number gives you 6.3923174227787602889 bits of entropy. It is a bug, but it is absolutely a non-problem. The difference you would get from using 83 or 85 characters is many orders of magnitude larger; this is not something that needs such an enormous level of precision.
- dchest 11y ago
  Wow. While the bias was tiny, I expect more from crypto software. Calling it a "non-problem" is very strange. Edit: submitted another patch https://github.com/SpiderOak/Encryptr/pull/263 https://github.com/SpiderOak/Encryptr/pull/263
  - rarrrrrr 11y ago
    Thank you! We'll take a look. By the way: I recognized your nick from various repos you've authored/contributed to. Always really solid stuff!
    - dchest 11y ago
      Thanks!
- tptacek 11y ago
  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".
  - Dylan16807 11y ago
    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.
    - CiPHPerCoder 11y ago
      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 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.
  - pbsd 11y ago
    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.
    - CiPHPerCoder 11y ago
      > 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.)
- marshray 11y ago
  While I agree that 2^32%85 produces a minuscule bias, there's this thing called base 64 that interoperates pretty well with arbitrary byte strings.

nitrogen 11y ago

Sometimes software is just "done", you know, or only needs updates every few years.

dsp1234 11y ago
That there are 93 issues including what appear to be UI issues implies that this project is probably not in that category though.
JshWright 11y ago
Yes, but those projects don't generally include references to things that are "coming soon" in the readme.
zymhan 11y ago
Sure, if it's a command line tool that does something simple maybe. Not a project that depends on a bunch of modern frameworks and has a mobile app. Plus, it's security software.