Encryptr – Free, open-source password manager and e-wallet • Hacker News Board

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

#11

Post by feld » Thu, Jul 30, 2015, 5:31 PM UTC

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 credentials to access the encrypted cloud storage and they have the key... this is bad.

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

#12

Post by sarciszewski » Thu, Jul 30, 2015, 5:33 PM UTC

homakov wrote: post #10

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

% shouldn't decrease the entropy, modulo of random is still random.

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.

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

#13

Post by dchest » Thu, Jul 30, 2015, 5:35 PM UTC

homakov wrote: post #10

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

% shouldn't decrease the entropy, modulo of random is still random.

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.

Here's an example from Wikipedia (https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#M...)

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

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

#14

Post by homakov » Thu, Jul 30, 2015, 5:38 PM UTC

homakov wrote: post #10

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

% shouldn't decrease the entropy, modulo of random is still random.

^ hopefully i didn't sound too confident! Thanks for explanations.

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

#15

Post by dchest » Thu, Jul 30, 2015, 5:41 PM UTC

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…

It encrypts locally and sends encrypted data to "the cloud".

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

#16

Post by sarciszewski » Thu, Jul 30, 2015, 5:45 PM UTC

dchest wrote: post #15

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…

It encrypts locally and sends encrypted data to "the cloud".

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

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

#17

Post by homakov » Thu, Jul 30, 2015, 5:46 PM UTC

sarciszewski wrote: post #12

homakov wrote: post #10

Earlier quoted context omitted.

% shouldn't decrease the entropy, modulo of random is still random.

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.

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

#18

Post by sarciszewski » Thu, Jul 30, 2015, 5:49 PM UTC

homakov wrote: post #17

sarciszewski wrote: post #12

Earlier quoted context omitted.

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.

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

#19

Post by sarciszewski » Thu, Jul 30, 2015, 5:53 PM UTC

verandaguy wrote: post #3

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…

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

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

#20

Post by tptacek » Thu, Jul 30, 2015, 5:56 PM UTC

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…

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.