SpiderOak Encryptr – Zero-Knowledge Password Syncing | Hacker News Reader

SpiderOak Encryptr – Zero-Knowledge Password Syncing

github.com

71 pointsnjaremko60 comments

    Requirements:
        Node and npm - http://nodejs.org/
            Node package manager for the Cordova CLI and Grunt
        Cordova CLI - https://github.com/apache/cordova-cli/
            Cordova / PhoneGap command line interface
            npm install -g cordova
        Grunt - http://gruntjs.com/
            Build tool for minimising, running and tests
            npm install -g grunt-cli
        PhantomJS - http://phantomjs.org/
            Headless webkit for running tests
        Cordova-icon and Cordova-splash - https://github.com/AlexDisler/cordova-icon/ and https://github.com/AlexDisler/cordova-splash/
            npm install -g cordova-icon and npm install cordova-splash

Nope. Nope nope nope.

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.

I assume it's against a bunch of dodgy software from a source which is perceived as being less eyeballed than a distribution's repository.

Not that guy, but that's a ridiculously bloated set of requirements.

The language it's written in, the testing framework, and the support library that lets it target more platforms? That doesn't seem too bloated to me.

> That doesn't seem too bloated to me.

For a security software? It may not be too bloated for a web app, but for a piece of security software it is absolutely bloated.

Note: I'm not talking from a utility point-of-view, that "C'mon, writing a security-related app doesn't have to use so much stuff".

I'm talking from a safety point-of-view, that "Security stuff should absolutely not have such a large code footprint".

Almost all of those requirements are only for developing / testing the repository. That's not uncommon for most languages / projects.

But... it really isn't. This is kind of the norm for node projects + cordova stuff.

This is a piece of software that we are supposed to trust with our passwords. It depends on a long list of crappy bloated software, including something from an apparently-non-standard source, and including a package manager that is probably going to pull in yet more untold reams of crappy, unaudited, JavaScript code from the four corners of the internet at build time. It would not surprise me if this ended up clocking in at millions of lines of code by the time it built.

Just say no.

It depends on a long list of crappy bloated software

If you don't actually want to test the software, and just want to create a production mobile/desktop application, then it depends on codova, cordova-icon, cordova-splash, semver and it's own source code. That's not a long list. If you want to test it, then it's probably not a shock that it pulls in testing frameworks for testing javascript UIs.

including something from an apparently-non-standard source

Here are the listed requirements from above:

http://nodejs.org/

npm install -g cordova

npm install -g grunt-cli

http://phantomjs.org/

npm install -g cordova-icon and npm install cordova-splash

Can you point out which of these is 'apparently-non-standard'?

> 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 that touch it, the more risky it is of being vulnerable. Not to mention the sheer astronomical difficulty of auditing it. From what I know of the industry, I wouldn't be surprised if a security auditor plain refused to touch this because of the sheer magnitude.

And that's without even mentioning it uses npm.

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 really matter, because all synced files are encrypted by GnuPG before any syncing tools gets access to it.

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.

Care for elaborate on the "nopes"? Grunt, PhantomJS and node are essentially for dev support and the rest are for running it. It's not that heavy.

I was slightly puzzled what they meant by "zero-knowledge encryption", but after looking around a bit it looks to be more of a buzzword than really related to zero-knowledge proofs (besides them using SRP for password validation). As far as I know, all password managers like Lastpass, 1Password, etc. use client-side encryption of data. Does this do anything new?

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-end encrypted" even in this context, but that doesn't really make sense for data at rest, which is almost all of what SpiderOak's products deal with.

Edit: SpiderOak has had a super-hard time marketing their privacy features to people who aren't already familiar with the fairly stark distinctions in play in different access models. I'm sure they would appreciate if someone came up with a straightforward way to explain "products where the service provider doesn't have access to your data, and can't get access without your help in any circumstances because of technical constraints".

Steve Gibson calls this type of design "Trust No One" (TNO), which I quite like.

But I think "end-to-end encrypted" is fine and has caught on with the public to some extent.

Of course, you can't really get to "Trust No One" level unless you build your own computer by hand and write its entire software stack from scratch. It's kind of an arbitrary distinction, otherwise.

I think client-side encryption covers it pretty well.

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

Because it differentiates them from the likes of Dropbox, who can easily look into your files. What other term would you use? "Client-side encryption" is too diluted a term.

That confused me as well. And I find it worrying that the author is apparently confused about this term (or deliberately using it in a non-standard sense).

I was excited about a password manager that finally manages like, domain names and then scrypts your master-password locally with standardized domain-names (ie: scrypt(masterpassword+gmail.com)) that then transforms the hash into a format that gmail.com accepts. (keeping track of which websites have weird requirements, like !$#% required, or special characters NOT allowed).

And then I realized that the "zero-knowledge" thing is just a buzzword and has nothing to do with the implementation. Ah well.

Have you looked at Master Password?

http://masterpasswordapp.com/algorithm.html

I want that, but the counter and webpage info to be cloud-based storage.

If the cloud-storage gets hacked, the hackers know I'm on my 5th password at gmail.com. Good luck with that info, lol. Otherwise, all my devices are sync'd with regards to password-count.

I've been thinking about this recently, since attending a recent lecture on ZKP by Shafi Goldwasser. Do you use or know of any services currently using zero knowledge proofs? I am curious as to why this isn't in wider use.

SpiderOak started using the term Zero Knowledge commercially back in 2007, in an attempt to explain the benefits of End-to-End Encryption to customers in a market where most participants were making wildly misleading claims. At the time, Mozy and Carbonite were referring to their systems as fully encrypted, even though all they did was transport encryption, or encryption of content and not filenames and folder names. These days, the term seems to make sense to at least the portion of customers who aren't crypto academics. - Erin @ SpiderOak

I'm a little confused by this. The project page makes it sound like someone's weekend project, complete with a donation link, but in fact it seems to be the client for one of SpiderOak's products.

In any case, I'm having fun reading about some of the projects used to build this, including Crypton. Will this work with any Crypton server, or is it somehow tied to SpiderOak?

Edit: "I am happy to announce that SpiderOak has acquired Encryptr" (blogs.devgeeks.org).

Yes, Encryptr and Crypton (the framework and server) are both fully open, in that you can run with your own server. SpiderOak also provides a public free server. https://github.com/SpiderOak/crypton - Erin @ SpiderOak

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.

I haven't figured that one out yet! :(

For Android: Password Store! https://github.com/zeapo/Android-Password-Store It's on F-Droid (not sure about Google Play) and it works really well. You need another app to manage your keys, but there is OpenKeyChain for that (also on F-Droid).

    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.

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.

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.

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

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!

Thanks!

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

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.

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!

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.

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

That there are 93 issues including what appear to be UI issues implies that this project is probably not in that category though.

Yes, but those projects don't generally include references to things that are "coming soon" in the readme.

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.

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.

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.

Previously: https://news.ycombinator.com/item?id=9976158

Reply on news.ycombinator.com