New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hash_pbkdf2 is too slow #359

Closed
ardabeyazoglu opened this Issue Aug 16, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@ardabeyazoglu

ardabeyazoglu commented Aug 16, 2017

Hi,

php hash_pbkdf2 is slower when the number of iterations are bigger, which in some cases not neccessary. const PBKDF2_ITERATIONS = 100000; makes it around 180ms in my case and it is too slow, at least for my case. 10000 makes it around 20-30ms.

It would be better, if we could change the iteration count programmatically for performance reasons in different scenarios.

@defuse

This comment has been minimized.

Show comment
Hide comment
@defuse

defuse Aug 16, 2017

Owner

Giving users full control over the iteration count is a little too risky -- this library is designed around the philosophy of "no options, just always do the secure thing." Something safer would be to have "weak" (fast) and "strong" (slow) options, but I want to avoid introducing an option if possible.

What's your use case where 180ms is unacceptable? If you're decrypting a lot of ciphertexts with the same password, it could make more sense to use a KeyProtectedByPassword, so that you only need to run PBKDF2 once to decrypt the key, and then do fast encryption/decryption with that key.

Owner

defuse commented Aug 16, 2017

Giving users full control over the iteration count is a little too risky -- this library is designed around the philosophy of "no options, just always do the secure thing." Something safer would be to have "weak" (fast) and "strong" (slow) options, but I want to avoid introducing an option if possible.

What's your use case where 180ms is unacceptable? If you're decrypting a lot of ciphertexts with the same password, it could make more sense to use a KeyProtectedByPassword, so that you only need to run PBKDF2 once to decrypt the key, and then do fast encryption/decryption with that key.

@ardabeyazoglu

This comment has been minimized.

Show comment
Hide comment
@ardabeyazoglu

ardabeyazoglu Aug 16, 2017

I was using it to create self contained token until I migrated it to JWT, which makes more sense for api tokens. But in any case, if i would need to encrypt/decrypt something in each request 180ms would be pretty unacceptable. (I didn't know KeyProtectedByPassword usage, though.)

ardabeyazoglu commented Aug 16, 2017

I was using it to create self contained token until I migrated it to JWT, which makes more sense for api tokens. But in any case, if i would need to encrypt/decrypt something in each request 180ms would be pretty unacceptable. (I didn't know KeyProtectedByPassword usage, though.)

@defuse

This comment has been minimized.

Show comment
Hide comment
@defuse

defuse Aug 16, 2017

Owner

That's a good use case. Yeah, I don't think there's a need to use passwords at all there, you could just save a Key and use that for fast encryption/decryption without involving PBKDF2 at all.

Owner

defuse commented Aug 16, 2017

That's a good use case. Yeah, I don't think there's a need to use passwords at all there, you could just save a Key and use that for fast encryption/decryption without involving PBKDF2 at all.

@defuse defuse closed this Aug 16, 2017

@ardabeyazoglu

This comment has been minimized.

Show comment
Hide comment
@ardabeyazoglu

ardabeyazoglu Aug 16, 2017

Thanks for explanations. I ll keep it in mind for other areas i use

ardabeyazoglu commented Aug 16, 2017

Thanks for explanations. I ll keep it in mind for other areas i use

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment