Riservatezza e integrità per la sessione web

Bene, voi state reinventando la ruota, ma almeno utilizzate una forma circolare per questo, che è migliore di quella che fanno la maggior parte degli inventori di ruote. E, francamente, c'è un po 'di carenza di ruote di alta qualità immediatamente utilizzabili.

Utilizzi CBC con una IV (che deve essere generata con un strong PRNG ), e va bene. Si applica HMAC sui dati crittografati e è buono . Non dimentichi di includere IV nell'input di HMAC, che sarebbe stato il classico errore di encrypt-then-MAC. E stai usando chiavi distinte per la crittografia e il MAC, che è bello. Quindi, davvero, non è affatto male.

Potresti prendere in considerazione i seguenti punti:

• Nel tuo formato, non vi è alcuna indicazione su quali algoritmi vengono utilizzati, quindi non c'è agilità algoritmo : se domani si desidera passare a un altro algoritmo di crittografia, non è possibile farlo senza rompere la compatibilità con i carichi utili esistenti (a meno che non giochi con la lunghezza totale). Per un'agilità pulita dell'algoritmo, potresti voler aggiungere un'intestazione: un singolo byte con un valore convenzionale, ad es. sempre 0x01 (le versioni successive del formato del carico utile utilizzerebbero altri valori). Nota importante: se lo fai, non dimenticare di aggiungere anche il byte di intestazione nell'input HMAC.

• Se avere due chiavi K1 e K2 è scomodo per te, potresti voler memorizzare una sola chiave K , e derivano chiavi K1 e K2 da K . Finché il processo di derivazione è unidirezionale e uniforme, questo andrà bene. Vogliamo che la chiave di crittografia e la chiave MAC siano distinte in modo da evitare brutte interazioni tra i due algoritmi; tali interazioni non sono note nel caso di AES-CBC e HMAC / SHA-256, ma "meglio prevenire che curare". Nel tuo caso, solo hash K con SHA-256, usa la prima metà (128 bit) per K1 , la seconda metà (128 bit) per K2 .

• Esistono nuove crittografia autenticata che combinano crittografia e controllo dell'integrità e fanno tutto il duro lavoro per tu. In particolare, GCM e EAX sono considerati sicuri e privi di brevetti. Offrono alcuni bonus: non c'è bisogno di un random IV (è sufficiente una IV non ripetitiva come un contatore), non c'è bisogno di padding (si basano sulla modalità CTR internamente), solo una chiave (qualsiasi "espansione" è gestita internamente).

• Se un utente può ottenere diversi payload, allora può cambiarli e riprodurre vecchi payload. A seconda del contesto, questo potrebbe o non potrebbe essere un problema per te.

• Se le chiavi non sono specifiche dell'utente, gli utenti collusi possono scambiare i payload. A seconda del contesto, questo potrebbe o non potrebbe essere un problema per te.

The padding will probably be done with spaces, since the format used for payload does not give significance to trailing spaces.

È probabile che starai meglio usando uno schema di riempimento standard e poi inventando il tuo. Ad esempio, riempire fino a n byte utilizzando n ripetendo byte di n o aggiungendo un blocco pad fittizio se è già di lunghezza adeguata.