search

nucypher / zerodb

*This project is no longer actively maintained. If you'd like to become the maintainer, please let us know.* ZeroDB is an end-to-end encrypted database. Data can be stored and queried on untrusted database servers without ever exposing the encryption key. Clients can execute remote queries against the encrypted data without downloading all of it or suffering an excessive performance hit.
GNU Affero General Public License v3.0
1.56k stars 102 forks source link

Check out PBKDF2 instead of sha256(passphrase) #3

Closed thatguystone closed 8 years ago

thatguystone commented 8 years ago

Link to code

PBKDF2 was designed specifically to deal with insecure user passwords by making them harder to bruteforce with added entropy and compute time. sha256, on the other hand, was meant to be fast, which is definitely not what you want here.

michwill commented 8 years ago

Yep, true. A friend of mine pointed that out earlier today. Do you think it's better to use pbkdf2 (which is NIST standard?) or something like (b/s)crypt?

thatguystone commented 8 years ago

Personally, I would stick with the PBKDF2 (it's used in TrueCrypt, cryptsetup, lastpass, and ...the list goes on). scrypt uses PBKDF2 (along with salsa20, and some mixing), so in the very least, it shouldn't be less secure than plain PBKDF2. Most implementations I've seen of bcrypt don't allow you to specify an output key length, so that could be troublesome.

michwill commented 8 years ago

All right. Since we see many financial services interested, that is another point in favor of more standard PBKDF2. Will take your recommendation :-)

taoeffect commented 8 years ago

Do you think it's better to use pbkdf2 (which is NIST standard?) or something like (b/s)crypt?

It is definitely better to pick scrypt or at least bcrypt.

PBKDF2 is orders of magnitude weaker.

As sec-tech routinely becomes outdated and deprecated, always pick the best security options available to you.

deathtrip commented 8 years ago

how about argon2 https://github.com/P-H-C/phc-winner-argon2

michwill commented 8 years ago

I see advantages and disadvantages of one over the other.

If we want some corporate customers to use zerodb, pbkdf2 is good. But I personally think that scrypt is more secure (or maybe better scrypt-N since scrypt ASICs are way too effective).

Maybe we can have it pluggable and store salt and parameters server-side.

A problem I see here (and maybe some of you know how to solve it?) is this. If we store the salt server-side, we have to give it back to the client to make a key out of a passphrase (the key is derived client-side, not server-side!). Is it ok to do that, could there be any security issues due to that?

taoeffect commented 8 years ago

how about argon2

If it's too new there could be issues with finding relevant/useful implementations. I'm not familiar with Argon2 myself though. Scrypt is still considered "state of the art" for today's purposes and has fairly good library/implementation support.

Maybe we can have it pluggable and store salt and parameters server-side.

A problem I see here (and maybe some of you know how to solve it?) is this. If we store the salt server-side, we have to give it back to the client to make a key out of a passphrase (the key is derived client-side, not server-side!). Is it ok to do that, could there be any security issues due to that?

I'm not super familiar with how zero-db works (and lack time to familiarize myself, sorry!), so some further explanation of how it's being used would help.

However, generally speaking, I'm about 98% sure what you're saying is safe to do (storing salt and params server-side), since those bits of information are stored in the clear anyway in how scrypt is used normally to encrypt data. If you want additional 2% certainty, feel free to ask on the scrypt mailing list.

taoeffect commented 8 years ago

There are 4 bits that are stored in the clear (and which you can store server-side): salt, N, p, r.

taoeffect commented 8 years ago

Oh, also make sure you pick the right parameters. If you pick the wrong ones scrypt won't be secure.

The default code actually picks them for you based on constants called MAXMEM, MAXMEMFRAC and MAXTIME.

I have some custom code to extract what parameters scrypt decided to choose upon encrypting a piece of information (it stores them in a header), as these can change depending on the values of those 3 aforementioned variables and the specs of the individual machine that scrypt was run.

Alternatively, you try to dictate them yourself as per the end of this article:

http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html

michwill commented 8 years ago

Switched to using a combination of scrypt client-side and sha256 server-side in ZEO5 branch, so fixed