1
$\begingroup$

I'm currently using aes to encrypt/decrypt messages to and from a web service.

When the user establishes a session he sends a random generated secret via rsa public key.

This secret is used to establish a secure channel using AES (CBC).

I'm using Rfc2898 to derive a key with a static salt (the salt is hardcoded and never changes). The IV is randomly generated for each message and prepended in cleartext.

Is it ok to use a static salt (Since I'm using a random generated secret for each session)?

Improve this question
$\endgroup$
6
  • $\begingroup$ Your question is a bit confusing. If the "secret" that is sent is uniformly random, and long enough, then there is no need to use a key derivation function. That would be for if you had a password with less entropy than was nominally required for your encryption. What are you hoping to accomplish using Rfc2898? $\endgroup$
    – Travis Mayberry
    Commented Oct 6, 2014 at 21:57
  • $\begingroup$ Also, it's unclear what you mean by generating random secrets via an RSA public key. $\endgroup$
    – Stephen Touset
    Commented Oct 6, 2014 at 22:14
  • $\begingroup$ The secret is sent when establishing a session. Yes you are right, when I use a static salt there is kinda no use for a key Derivation function. Currently the secret was not long enough for the aes key, so I used a Derivation function. @Stephen I use a random function on the client to choose a secret which I then exchange with the server via rsa. $\endgroup$
    – coalmee
    Commented Oct 6, 2014 at 22:20
  • $\begingroup$ Why not just use Diffie Hellman? $\endgroup$
    – Stephen Touset
    Commented Oct 6, 2014 at 22:33
  • $\begingroup$ I don't see that it makes any difference to my problem using diffiehellman instead of rsa. $\endgroup$
    – coalmee
    Commented Oct 6, 2014 at 22:46

1 Answer 1

Reset to default
3
$\begingroup$

Currently you seem to be using a Password Based KDF (PBKDF); you are using PBKDF2, as defined in Rfc2898. You don't need to do this as randomly generated data is already fine for creating an AES key. So - as you don't need a PBKDF - you don't actually need a salt.

If you need more keys or key data then what is actually required is a Key Based KDF (KBKDF), as your shared secret already contains enough entropy. Passwords usually don't, that's why they require the key strengthening delivered by PBKDF (by using a salt and iteration count). HKDF doesn't require a salt either, but its security properties are significantly enhanced if you do provide a salt.

Note that CBC should not be used by itself to create a secure transport protocol. CBC does not provide integrity nor authenticity. And if error (padding) oracles apply - which is likely - then it doesn't even provide confidentiality, leaving you with nothing. You need to at least add a MAC - HMAC is preferred - and a MAC key. To generate two keys...see the second paragraph and provide two different labels (or "OtherInfo"), one for each key.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.