Live data from Hacker News

SpiderOak Encryptr – Zero-Knowledge Password Syncing

github.com

41–50 of 63 posts

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#41
WebPass ( https://webpass.rkeene.org/ ) is similar -- its syncing is done by encrypting the list of sites (note that passwords are never stored or encrypted) and sending that from one client to another (no server ever stores the encrypteed list of sites).

It's also an iOS/Chrome webapp so it will act like a native app in some ways.

It's also a single JavaScript file which isn't too heavy. The sync'ing is done by a simple process that reads what another client writes implemented as a CGI talking over a FIFO.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#42

Earlier quoted context omitted.

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

One reason that was never merged was because it was a flawed patch to a non-problem. - Erin @ SpiderOak

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.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#43

Earlier quoted context omitted.

> That's not a long list It's not the list of top-level pieces of software, it's the amount of code that could have contact with the plaintext or the encryption keys. > If you don't actually want to test And build! Don't forget the building itself. It's not so much harder to exploit an app even if all you have access to is its build stage. ---- This is security software we are talking about. The more lines of code th…

You can build without grunt. Grunt just makes the flow a lot easier to manage.

Grunt is not the problem. It's using the npm ecosystem, the thousands of different codebases that I have little guarantee of constance over, that is the problem. Even using node.js alone (and no npm, no other libraries) would be extremely hard to audit, simply because of the huge code footprint of v8 alone. But at least I can download all the sources one time, audit it, and be certain every future build with the exact same versions would be safe.

npm doesn't provide even that much guarantee.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#44
post #24
post #7

Earlier quoted context omitted.

Yeah, it's puzzling why SpiderOak persists in using the term "zero knowledge" to mean something entirely different from ZKPs. As far as I can tell they're the only ones doing this too. Especially with zkSNARKs and practical applications like Zcash, all I can think this will accomplish is confusing people.

They tried to coin a new (unrelated) sense of this term about two years ago in order to try to explain services where the service provider doesn't have access to your data. I agree that it's confusing because of the much more clearly established technical term with a different meaning, and I don't think SpiderOak's sense has caught on outside of the company. Can anyone suggest a better term? Some people like "end-to-…

I think client-side encryption covers it pretty well.

https://en.wikipedia.org/wiki/Client-side_encryption

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#45

Earlier quoted context omitted.

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

One reason that was never merged was because it was a flawed patch to a non-problem. - Erin @ SpiderOak

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

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#46

Earlier quoted context omitted.

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

One reason that was never merged was because it was a flawed patch to a non-problem. - Erin @ SpiderOak

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".

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#47
post #8

I prefer pass, which uses GPG and regular bash scripts to store passwords. You can sync the directory of encrypted passwords via git too. No fancy stuff. https://www.passwordstore.org/

What is the easiest way to access such a store from a phone?

Assume I have synchronized the encrypted files myself.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#48

Earlier quoted context omitted.

> That's not a long list It's not the list of top-level pieces of software, it's the amount of code that could have contact with the plaintext or the encryption keys. > If you don't actually want to test And build! Don't forget the building itself. It's not so much harder to exploit an app even if all you have access to is its build stage. ---- This is security software we are talking about. The more lines of code th…

A valid concern for a password manager. This is why I like PasswordStore a lot better for managing passwords and other sensitive information. It is a Bash script that only depends on a very select list of binaries (gpg, git, and tree, if I recall correctly). It is also a script simple enough I can even audit it myself: https://www.passwordstore.org/ For syncing, either use git, or something like syncthing. It doesn't…

Thanks for the link to passwordstore.org. Fantastic piece of software!

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#49
post #12

Earlier quoted context omitted.

I'm not clear on what exactly your problem is here.

I'm also curious about what the problem is. If the goal is a simple API client that has iOS/Android/Desktop compatibility, then Cordova seems a reasonable choice. Would the above commenter have preferred 4+ separate projects instead?

You seem to imply 4 projects is 4x the time. In my experience I spent more than 2x the time just getting a Cordova project up an running compared to just building the whole dam thing from scratch on iOS. Why? Cordova kept changing all the time. Documentation sucked. It was buggy. The tools were substandard and it had inconsistent behavior across platforms. Terrible experience. I have colleagues who had the same terrible experience but they still cling to the idea that it will somehow work out in the end. The idea of one code to rule all the platforms is just too enticing.

I don't doubt that some people will be more effective at using Cordova. The problem is people treat this decision as if it is independent of the people who will build the solution. Somebody with years of training doing JavaScript and practically no experience with writing native code will likely be much faster with Cordova. That is why these projects exist in the first place. There are so many JavaScript developers out there. For them even a crappy setup like Cordova will still be faster than native development.

But in reverse if you actually got good experience with native platforms and know the tools, Cordova is not going to deliver. You wont have access to the kind of debugging tools, editors, type checking, GUI builders, documentation etc you get on a native platform, which makes a native developer work efficiently.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#50
I am an academic who works on zero-knowledge proofs; as far as I can tell, this system has nothing to do with the Turing-award winning concept of "zero-knowledge." Based on the information on the website, my opinion is that the author is gratuitously appropriating the term "zero-knowledge" here.
Post reply on HN