Live data from Hacker News

SpiderOak Encryptr – Zero-Knowledge Password Syncing

github.com

21–30 of 63 posts

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#21
post #6

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?

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.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#22
post #6

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?

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-knowledg…

Have you looked at Master Password?

http://masterpasswordapp.com/algorithm.html

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#23
post #22

Earlier quoted context omitted.

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-knowledg…

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.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#24
post #7
post #6

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

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#25

Earlier quoted context omitted.

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

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 clockin…

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'?

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#26
post #7
post #6

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.

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.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#27

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.

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.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#28
post #25

Earlier quoted context omitted.

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 clockin…

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…

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

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#29
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-…

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.

Re: SpiderOak Encryptr – Zero-Knowledge Password Syncing

#30
post #14

Earlier quoted context omitted.

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

Post reply on HN