Si se conoce el texto cifrado, el texto sin formato y el nonce, ¿se puede determinar la clave secreta?

  

Si un usuario tiene texto cifrado, no cifrado y descifrado, ¿puede determinar la clave que se utilizó para cifrar la información?

Según el algoritmo de cifrado utilizado, el conocimiento del texto simple y del texto cifrado no revela la clave. De lo contrario, un solo bloque de texto simple conocido (por ejemplo, un encabezado común o un valor controlado por un atacante) rompería el cifrado. Tal ataque de recuperación de clave es muy raro para cualquier cifrado moderno y bien diseñado. La biblioteca que está utilizando admite varios cifrados seguros basados en algoritmo Salsa20 de DJB . Todos los cifrados utilizados están protegidos contra ataques de recuperación de claves.

  

Por simplicidad, sería útil usar la misma clave para otras funciones de cifrado en el software

En general, es una muy mala idea reutilizar una clave para cualquier otro propósito. Cada uso distinto del cifrado debe utilizar una nueva clave. Por ejemplo, su clave de cifrado de token CSRF no debe ser la misma que una clave de cifrado de enlace. Si realmente tiene un valor de tamaño de clave, puede expandirlo de manera segura en múltiples claves. Una forma segura de hacerlo es con la popular función HKDF . Le da a la función una clave maestra, y escupe cualquier cantidad de claves seguras criptográficamente aptas para su uso.

el bosque definitivamente responde a las cosas, pero también me gustaría agregar un comentario similar:

¿Por qué está reutilizando el token de inicio de sesión del usuario para el token CSRF?

Si bien la reutilización del inicio de sesión del usuario para CSRF no alcanza el nivel de "error de seguridad", tampoco lo consideraría la mejor práctica y lo evitaría a menos que haya una buena razón. Reutilizarlo como lo está haciendo no crea brechas de seguridad de inmediato, pero en general, reusar claves / tokens es la forma en que introduce inadvertidamente un problema de seguridad en el futuro. Normalmente esto sucede porque alguien que realiza un cambio en una parte del sistema no se da cuenta de las implicaciones que tiene en otra parte.

Sin embargo, esto crea una seguridad de corto plazo, que es que no puede volver a generar su token CSRF después de cada solicitud. La regeneración de tokens CSRF después de cada uso es un paso de seguridad recomendado (aunque no es necesario), y también puede ayudar a proteger contra envíos dobles accidentales. Como resultado, sugeriría simplemente implementar un token CSRF separado si hacerlo no es una gran molestia para su sistema. Después de todo, ¿por qué molestarse con el cifrado / nonce / etc para que el token de inicio de sesión realice un CSRF? Todo lo que necesita un token CSRF es ser único e impredecible. Es igual de fácil generar una cadena aleatoria larga (criptográficamente segura) y almacenarla en la cookie para su token CSRF. No es necesario reutilizar el token de inicio de sesión.