If the cypher-text, plain-text and nonce is known, can the secret key be determined?

Question

I'm using the sodium_crypto_secretbox and sodium_crypto_secretbox_open functions in PHP (currently PHP 5.6, using paragonie/sodium_compat).

If a user has cypher text, nonce and decrypted plain text, can they determine the key that was used to encrypt the information?

The context: I'm encrypting the user's login token (a cookie, stored on the machine) and using this as a CSRF token. The CSRF token necessarily includes the nonce for decryption when submitted. The CSRF token is decrypted and verified on submission of form POSTs to protect against CSRF attacks.

My concern is not so much for CSRF attackers who won't have access to the cookies, but for the key itself. For simplicity, it would be useful to use the same key for other encryption functions in the software, but I can't if it can easily be exposed via this information. A legitimate user can see CSRF token and cookie: could they discover the key?

Answer 1

If a user has cypher text, nonce and decrypted plain text, can they determine the key that was used to encrypt the information?

Depending on the encryption algorithm used, knowledge of the plaintext and ciphertext does not reveal the key. Otherwise, a single block of known plaintext (a common header or an attacker-controlled value, for example) would break the cipher! Such a key-recovery attack is very rare for any modern, well-designed cipher. The library you are using supports several secure ciphers based on DJB's Salsa20 algorithm. All the ciphers used are secure from key-recovery attacks.

For simplicity, it would be useful to use the same key for other encryption functions in the software

It is generally a very bad idea to re-use a key for any other purposes. Each distinct use of encryption should use a new key. For example, your CSRF token encryption key should not be the same as a link encryption key. If you really do have one key-sized value, you can expand it safely into multiple keys. A safe way to do this is with the popular HKDF function. You give the function one master key, and it spits out any number of cryptographically secure keys fit for use.

Answer 2

forest definitely answers things, but I would also like to add a similar aside:

Why are you reusing the user's login token for the CSRF token?

While reusing the user's login for CSRF doesn't rise to the level of "security blunder", I also wouldn't consider it best practice and would avoid it unless there is a good reason. Reusing it like you are doing doesn't immediately create security holes, but in general reusing keys/tokens is how you inadvertently introduce a security problem down the road. Typically this ends up happening because someone making a change on one part of the system doesn't realize the implications it has somewhere else.

However, this does create one security short-coming, which is that you can't regenerate your CSRF token after each request. Regenerating CSRF tokens after each use is a recommended (although not necessary) security step, and it can also help protect against accidental double submits. As a result I'd suggest just implementing a separate CSRF token if doing so isn't a big hassle for you system. After all, why bother with the encryption/nonce/etc for the login token to make a CSRF? All a CSRF token needs is to be unique and unpredictable. It is just as easy to generate a long (cryptographically secure) random string and store that in the cookie for your CSRF token. No login token reuse required.