Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Encryptr – Free, open-source password manager and e-wallet

encryptr.org

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Encryptr – Free, open-source password manager and e-wallet

#61

Post by sarciszewski »

daviddahl wrote: post #52
sarciszewski wrote: post #4

https://github.com/devgeeks/Encryptr/blob/64223f0cb4adba80c8... 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…

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)

Yes, but see the other comments about how the % operator can introduce bias into an RNG's output.

Re: Encryptr – Free, open-source password manager and e-wallet

#62

Post by sarciszewski »

daviddahl wrote: post #55
sarciszewski wrote: post #8

Earlier quoted context omitted.

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

Encryptr does not ue node.js crypto at all. Just Blink and Webkit's getRandomValues, which is secure

Yep, this is why I prefaced my statement with "outside the scope of Cordova apps".

Re: Encryptr – Free, open-source password manager and e-wallet

#63

Post by pbsd »

sarciszewski wrote: post #4

https://github.com/devgeeks/Encryptr/blob/64223f0cb4adba80c8... 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…

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.

Re: Encryptr – Free, open-source password manager and e-wallet

#64

Post by incompatible »

feld wrote: post #11
Nux wrote: post #7

"Cloud-based. Private." ... Right.

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

The other issue is whether your passwords would be lost if they shut down, or had some catastrophic server failure.

Re: Encryptr – Free, open-source password manager and e-wallet

#65

Post by daviddahl »

cmrx64 wrote: post #46
shuzchen wrote: post #26

Earlier quoted context omitted.

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. Crypton it…

The contents of the second audit in particular deeply troubled me. Lots of simple but grevious mistakes. It's nice that they got the audit though.

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!

Re: Encryptr – Free, open-source password manager and e-wallet

#66

Post by daviddahl »

incompatible wrote: post #64
feld wrote: post #11

Earlier quoted context omitted.

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

The other issue is whether your passwords would be lost if they shut down, or had some catastrophic server failure.

A planned feature is "export all data"

Re: Encryptr – Free, open-source password manager and e-wallet

#68

Post by gingerlime »

sarciszewski wrote: post #47
gingerlime wrote: post #42

Earlier quoted context omitted.

> I'm not a fan of Crypton Just curious - is this to do with using javascript crypto[0]? or something that goes beyond that? [0] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

JavaScript is only a real issue when you have an insecure code delivery mechanism. The article spells that out pretty well.

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.

[0] https://crypton.io/docs/

Re: Encryptr – Free, open-source password manager and e-wallet

#70

Post by devgeeks »

msh wrote: post #67

Strange that there are no iOS client.

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.

Post reply on HN