I'm a bit concerned that their random number generator might produce biased output. This is usually a red flag that there are other issues in the code that haven't been examined by a crypto person.
Just a word of caution from a casual glance. For all I know the rest of the code is fine. For all I know, the rest of the code is clunky swiss cheese.
There doesn't appear to be much crypto in this project; it's a small application built on SpiderOak's Crypton.io. I'm not a fan of Crypton, but it's not clownshoes crypto.
Just to be clear to everyone on the thread: it's very unlikely that there's anything practical an attacker can do with the modulus bias in a situation like this.
> Just to be clear to everyone on the thread: it's very unlikely that there's anything practical an attacker can do with the modulus bias in a situation like this.
Correct. This was just the first thing I saw in a cursory glance through their app.js file.
I haven't reviewed Crypton.io and can't say whether I like it or not. What don't you like about it in particular?
Yes, I understand. I was wondering why tptacek wasn't a fan though, and the only reason I could think of was that it might encourage this usage?? even though it looks like they explicitly discourage this[0]. It's the first time I hear of crypton.io - so just trying to learn more.
Encryptr's security bits are likely all implemented in the crypton framework. If you search the repo for that function (randomString), you'll see that it's only used in one place: to propose a new password (https://github.com/devgeeks/Encryptr/search?utf8=%E2%9C%93&q...). While it'd be best to not have any bias at all, this low bias only assists people trying to brute force passwords created by encryptr.
FWIW, the audit happened directly in the middle of a dev cycle, without any of the normal internal review of that code first. The audit report describes those circumstances in the first few pages. Scheduling audits is hard work!
Biases caused by modulo reduction are dangerous when the source integer is relatively close to the target distribution. This bias is unlikely to be useful for attackers. The probability difference between the most likely output, 0, and the less likely outputs is 2^-32. For comparison, Cryptocat's bug had a much larger distance of 1/251 ~ 2^-8, which greatly reduces the amount of samples needed for distinguishing the output from random. EdDSA itself uses modulo reduction for the nonce, using a large enough source (~2^512 modulo ~2^252) value that renders the bias irrelevant.
This is using getRandomValues which is cryptographically secure. The account/login/privacy crypto is using SJCL and the entire app is a signed desktop or mobile application - (no remote code)
Nothing in principle; it's the % operator that can biased the output.
Also, outside the scope of Cordova apps, Node.js uses OpenSSL rather than /dev/urandom for their crypto.getRandomBytes() implementation, so I don't really trust it in that context. ;)
Entropy is maximized when the distribution probability is uniform. A biased random sequence has less entropy than the one of the same length which has uniform distribution.
"For example, assume that your random number source gives numbers from 0 to 99 (as was the case for Fisher and Yates' original tables), and that you wish to obtain an unbiased random number from 0 to 15. If you simply divide the numbers by 16 and take the remainder, you'll find that the numbers 0–3 occur about 17% more often than others. This is because 16 does not evenly divide 100: the largest multiple of 16 less than or equal to 100 is 6×16 = 96, and it is the numbers in the incomplete range 96–99 that cause the bias. The simplest way to fix the problem is to discard those numbers before taking the remainder and to keep trying again until a number in the suitable range comes up. While in principle this could, in the worst case, take forever, the expected number of retries will always be less than one."
If you generate 1000 random integers, but we know there's a 28% chance it will be 0 and a 14% chance it will be 1,2,3,4, or 5, a clever attacker can more accurately predict/brute force outputs.
When you're working with cryptography, you want a uniform distribution of possible values as well as unpredictable randomness.
For 0..max random integer it depends on max and length. If max is 2^32 and 2^32 modulo charset.length = 0 it should be fine. Am I right?
In our case length is 85 and it is indeed biased. Needs a pull request.
Correct, that's the edge case where it actually falls together neatly.
If you're starting with a random byte and charset.length is an even power of 2, you end up with no bias.
It's better to design functions like this to discard values outside of an acceptable range and try again until they generate a safe value (also, apply a & bit mask to reduce the number of retries). This allows you to accept any arbitrary charset size without being concerned about security.
In theory, haha. In practice it gives me some numbers twice more. [2001954,
1000322,
998546,
1001551,
999105,
2000886,
998760,
998705,
1000001,
998424,
1000978,
2000907,
1002097,
998786,
1000101,
998818,
1000381,
1999818,
999662,
1001260,
999531,
1000076,
I thought instead of cutting off out of range results we could num*85/4294967296 and round it. But now realized buckets for rounding won't be of equal size and it's wrong.
3. Dedicated forms for credit cards, passwords, and notes.
UX shortcomings -
1. No way to tweak the password generator algorithm. This matters because different contexts need different things. EG mobile passwords should avoid special chars and be longer to tradeoff.
2. No way to search. In any reasonably long lived password file you will be unable to scroll through quickly enough.
3. No importer(s) for legacy password manager files.
Does it support self-hosting of the server part? If I could deploy it to one of my Digital Ocean servers easily, I could see it become my default (and last) password manager. I'm too small a fish for a hacker to actually hunt my own server, and even if they do... it's zero knowledge, so I think I'd be comfortable with that.
Side question: does it support sharing of secured notes and credentials? even to non-encryptr users?
In theory, sure. Crypton.io itself is available on github and you could build your own server.
On the Encryptr app side, src/app.js uses window.crypton.host and _.port to specify the crypton endopint to connect to. I think the app store build of encryptr uses a crypton endopint at devgeeks.org.
You could just use (apache) cordova to roll your own build of the android app with app.js set to point to your preferred self-hosted endpoint.
YMMV.
Note: this is definitely a product at the MVP stage. The platform is capable of implementing data sharing, but that is not currently used by the Encryptr application.
Indeed, you can do this and we encourage it. We are also building a private "feed" application called "Kloak", which resembles Twitter but is private and "un-dataminable".
This was my first question too. I checked the android app, and there was no obvious configuration option for a different server.
It's open source, so at least in theory it's possible to modify it to your needs.
Also side note: Was a little disappointed to not see this on f-droid's marketplace since it is open source and hosted on github. Need to get that changed. :-)
I'm cautiously optimistic about this, but won't be using it to manage passwords for anything important -- yet.
On one hand they claim to be in league with SpiderOak (how, I'm not sure), which surfaced after the Snowden leaks as a zero-knowledge encrypted alternative to Dropbox/Google Drive.
On the other hand, it's a cloud-based solution which to me is still a cause for caution, and I'd feel more reassured if someone (who knows JavaScript and security better than I do) conducted an audit of this.
Hoping for the best for Encryptr, but I'll have to keep it on the sidelines until it's more battle-tested.
I used to (as recent as a couple months back) work at SpiderOak. Encryptr is connected to SpiderOak in a couple ways. First, it's build on top of crypton (https://crypton.io/) which is a SpiderOak research project. Second, the dev (https://github.com/devgeeks) works for SpiderOak (see his github teams or https://spideroak.com/about/team-&-leadership). Encryptr was a side project of his that he started in his spare time (to mess around with crypton), though obviously SpiderOak is now interested in its success (since it's one of the first/only crypton projects live in the wild).
Some other notes: SpiderOak didn't surface after the Snowden leaks. It was around at the same time that dropbox started. However, the Snowden leaks did prompt a lot more interest in zero-knowledge cloud services, so if you mean "surface" as in "became more popular with the public" you're right on those lines.
> On the other hand, it's a cloud-based solution which to me is still a cause for caution, and I'd feel more reassured if someone (who knows JavaScript and security better than I do) conducted an audit of this.
I can extend an offer to them on behalf of Paragon Initiative Enterprises and, if it's accepted, post our findings on HN at a later date.
It's all UNIX based and takes advantage of GPG and Git for encryption and versioning, respectively. Super lightweight, and there are various front-ends for it, including an Android app.
It's not a cloud-based solution by default, but it wouldn't be hard to set it up to git push to a central location on each update and to pull from that location down to all your end-points.
Two suggestions for the web page. First, please include the system requirements for each platform under the platform names. That would make it easier to decide whether to download the application or not.
Second, a nitpick - the OS on Mac computers is called "OS X" since the time of OS X 10.7 Lion and not "Mac OS X". Please fix that. The name "Mac OS X" was used only for older releases up to Mac OS X 10.6 Snow Leopard. :)
This is cool, will install it right now. Shameless plug: I work in the same field but instead of storing passwords trying to replace passwords and 2fa altogether with one scheme working as a web app: truefactor.io/app
Nothing new, private keys are generated per account, the entire app will be in appcache, and sync is done via simple API and encrypted with your passphrase messages (same as crypton - zero knowledge). From the start you get 2 private keys both stored in your browser on truefactor.io/app. Later if you you decide to "2factorize" some website it can done with 1 click. To log in you need two signatures so you have to click "approve" on both devices with a private key.
The integration flow for consumer websites is also very simple: 1 tiny JS lib and 10-20 lines of code on the server side to verify 2 signatures against public keys of the user.
Out of box fixes passwords reuse, phishing, bruteforce, 2factorization, enforceable, open and free etc
It is a rogue CA that does not revoke compromised certificates even when presented with a proof of such compromise, unless the customer pays a revocation fee. If the customer does not pay the fee, StartCom provides trust (which is what CAs do; they say “we guarantee to the best of our knowledge that this server is the server it claims to be”) for websites which are known (by StartCom) to be compromised, defeating the purpose of having CAs in the first place.
After Heartbleed many certificates had to be revoked, and one person who did not want to pay the revocation fee had the idea of publishing his private key so that the certificate was compromised without doubt. StartCom refused to revoke it, and the page that explained the story has since disappeared mysteriously. The HN thread about it is here: https://news.ycombinator.com/item?id=7577290
Warning: long answer ahead. Short version: there will be very soon. I use it daily on my own iPhone.
The issue is that because Crypton does crypto with JavaScript in the web view of a Cordova app, it needs to not be stupendously slow. The default iOS web view available for Cordova apps, up until iOS 8, was the UIWebView which is well known for not having access to a JIT (like Nitro in mobile Safari). This means that JavaScript crypto (particularly done the way SJCL does it) is VERY slow. We're talking almost two minutes just to log in. :/
However, even though iOS 8 now provides a web view with a JIT (WKWebView), it has been slightly crippled by Apple. The WKWebView disallows loading local files except from the app's tmp folder. This has meant some work for the Cordova iOS team to get the WKWebView working. It is finally at a stage where it can be used, but some of the changes Cordova had to make to get it working, plus some differences in WKWebView's API, mean some changes had to be made to both Crypton and Encryptr to get it all to work.
It's working now. However, since I will still have to dance through a few more hoops of fire (Apple submission and other pain), I am planning on pushing out a new version for the existing platforms first. Then I should be able to do what needs to be done to get the iOS version out.
It's hard to trust a cloud-based password manager.
Now, if they're doing the crypto all local and syncing between devices with a miniature version of SpiderOak that would be OK. This is basically what 1Password does -- local crypto and stored on Dropbox or iCloud. That's not worrying at all as long as the crypto -- completely managed locally -- is strong.
But if they're using, say, SSL and an API with your credentials to access the encrypted cloud storage and they have the key... this is bad.
That's a good model to adopt. It's also the "ubiquitous encryption" that has James Comey crying like a baby.
I encourage more apps and services to adopt this model. Just, be careful when you do. Definitely open source your code, and definitely get it audited by a qualified team (e.g. NCC Group's crypto services).
I'm a bit concerned that their random number generator might produce biased output. This is usually a red flag that there are other issues in the code that haven't been examined by a crypto person.
Just a word of caution from a casual glance. For all I know the rest of the code is fine. For all I know, the rest of the code is clunky swiss cheese.
Further reading on biased RNGs, with a visual: https://stackoverflow.com/a/31374501/2224584