Skip to main content
Cryptography

Return to Question

Tweeted twitter.com/#!/StackCrypto/status/547355173308616704
corrected grammar
Source Link
user991
user991

I'm developing a messenger application with encrypted chats.

In the first version of the app I've used PBKDF2 (10000 iterations, SHA1, random salt) to extend a short user password and generate keys to encrypt (AES256) and sign message (HMAC).

In the current version of the app I generate a random 130-bit key and use it instead of a user password. I think that using PBKDF2 with such a key has some overhead.

I see 2 possible ways to improve the current approach:

  1. Keep using PBKDF2 and decrease iterations to 1 or 10.
  2. Don't use PBKDF2 and use HKDF instead.

What are the advantages and disadvantages of each approach? Are there any other options?

I'm developing a messenger application with encrypted chats.

In the first version of the app I've used PBKDF2 (10000 iterations, SHA1, random salt) to extend a short user password and generate keys to encrypt (AES256) and sign message (HMAC).

In the current version of the app I generate a random 130-bit key and use it instead of a user password. I think that using PBKDF2 with such key has some overhead.

I see 2 possible ways to improve the current approach:

  1. Keep using PBKDF2 and decrease iterations to 1 or 10.
  2. Don't use PBKDF2 and use HKDF instead.

What are the advantages and disadvantages of each approach? Are there any other options?

I'm developing a messenger application with encrypted chats.

In the first version of the app I've used PBKDF2 (10000 iterations, SHA1, random salt) to extend a short user password and generate keys to encrypt (AES256) and sign message (HMAC).

In the current version of the app I generate a random 130-bit key and use it instead of a user password. I think that using PBKDF2 with such a key has some overhead.

I see 2 possible ways to improve the current approach:

  1. Keep using PBKDF2 and decrease iterations to 1 or 10.
  2. Don't use PBKDF2 and use HKDF instead.

What are the advantages and disadvantages of each approach? Are there any other options?

corrected grammar
Source Link
edit approved Dec 23, 2014 at 9:32
Guut Boy
edit approved Dec 23, 2014 at 9:32
Guut Boy
  • 2.9k
  • 18
  • 25

I'm developing a messenger application with encrypted chats.

In the first version of the app I've used PBKDF2 (10000 iterations, SHA1, random salt) to extend a short user password and generate keys to encrypt (AES256) and sign message (HMAC).

In the current version of the app I generate a random 130-bit key and use it instead of a user password. I think that using PBKDF2 with such key has some overhead.

I see 2 possible ways to improve the current approach:

  1. Keep using PBKDF2 and decrease iterations to 1 or 10.

    Keep using PBKDF2 and decrease iterations to 1 or 10.

  2. Don't use PBKDF2 and use HKDF instead.

    Don't use PBKDF2 and use HKDF instead.

What are the advantages and disadvantages of each approach? Are there any other options?

I'm developing messenger application with encrypted chats.

In the first version of app I've used PBKDF2 (10000 iterations, SHA1, random salt) to extend short user password and generate keys to encrypt (AES256) and sign message (HMAC).

In the current version of app I generate random 130-bit key and use it instead of user password. I think that using PBKDF2 with such key has overhead.

I see 2 possible ways to improve current approach:

  1. Keep using PBKDF2 and decrease iterations to 1 or 10.

  2. Don't use PBKDF2 and use HKDF instead.

What are the advantages and disadvantages of each approach? Are there any other options?

I'm developing a messenger application with encrypted chats.

In the first version of the app I've used PBKDF2 (10000 iterations, SHA1, random salt) to extend a short user password and generate keys to encrypt (AES256) and sign message (HMAC).

In the current version of the app I generate a random 130-bit key and use it instead of a user password. I think that using PBKDF2 with such key has some overhead.

I see 2 possible ways to improve the current approach:

  1. Keep using PBKDF2 and decrease iterations to 1 or 10.
  2. Don't use PBKDF2 and use HKDF instead.

What are the advantages and disadvantages of each approach? Are there any other options?

Source Link
alexeylang
alexeylang
  • 113
  • 1
  • 5

PBKDF vs HKDF for pretty long key

I'm developing messenger application with encrypted chats.

In the first version of app I've used PBKDF2 (10000 iterations, SHA1, random salt) to extend short user password and generate keys to encrypt (AES256) and sign message (HMAC).

In the current version of app I generate random 130-bit key and use it instead of user password. I think that using PBKDF2 with such key has overhead.

I see 2 possible ways to improve current approach:

  1. Keep using PBKDF2 and decrease iterations to 1 or 10.

  2. Don't use PBKDF2 and use HKDF instead.

What are the advantages and disadvantages of each approach? Are there any other options?