Se il testo cifrato, plain-text e nonce è noto, si può determinare la chiave segreta?

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

A seconda dell'algoritmo di crittografia utilizzato, la conoscenza del testo in chiaro e del testo cifrato non rivela la chiave. Altrimenti, un singolo blocco di testo in chiaro noto (un'intestazione comune o un valore controllato da un utente malintenzionato, ad esempio) interromperà il codice! Un tale attacco per il recupero della chiave è molto raro per qualsiasi cifrario moderno e ben progettato. La libreria che stai usando supporta diversi codici di sicurezza basati su Algoritmo Salsa20 di DJB . Tutti i codici utilizzati sono al sicuro dagli attacchi di recupero delle chiavi.

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

In genere è una pessima idea riutilizzare una chiave per altri scopi. Ogni distinto uso della crittografia dovrebbe utilizzare una nuova chiave. Ad esempio, la chiave di crittografia del token CSRF non deve essere uguale a una chiave di crittografia del collegamento. Se si dispone di un valore di una chiave, è possibile estenderlo in modo sicuro in più chiavi. Un modo sicuro per farlo è con la famosa funzione HKDF . Fornisci alla funzione una chiave principale e sputa qualsiasi numero di chiavi crittograficamente sicure idonee per l'uso.

forest sicuramente risponde alle cose, ma vorrei aggiungere anche una frase simile:

Perché riutilizzi il token di accesso dell'utente per il token CSRF?

Anche se riusare il login dell'utente per CSRF non aumenta al livello di "errore di sicurezza", anch'io non lo considererei una buona pratica e lo eviterei a meno che non ci sia una buona ragione. Riutilizzarlo come si fa non crea immediatamente buchi di sicurezza, ma in generale riutilizzare le chiavi / token è come inavvertitamente si introduce un problema di sicurezza lungo la strada. In genere questo accade perché qualcuno che apporta modifiche su una parte del sistema non si rende conto delle implicazioni che ha da un'altra parte.

Tuttavia, questo crea uno sfortunato livello di sicurezza, ovvero che non è possibile rigenerare il token CSRF dopo ogni richiesta. La rigenerazione dei token CSRF dopo ogni utilizzo è un passaggio di sicurezza consigliato (anche se non necessario) e può anche aiutare a proteggere da doppie segnalazioni accidentali. Di conseguenza, suggerirei semplicemente di implementare un token CSRF separato se così facendo non è una grande seccatura per il tuo sistema. Dopo tutto, perché preoccuparsi con la crittografia / nonce / etc per il token di accesso per creare un CSRF? Tutti i bisogni di un token CSRF devono essere unici e imprevedibili. È altrettanto facile generare una stringa casuale lunga (crittograficamente protetta) e memorizzarla nel cookie per il token CSRF. Non è richiesto il riutilizzo dei token di accesso.