Sto eseguendo il mio protocollo TCP / IP protetto crittografando ogni pacchetto con AES128 / CBC, raggruppando un HMAC SHA256 su quel pacchetto.
Questo causa un sovraccarico di spazio per piccoli pacchetti, quindi all'inizio pensavo di eseguire AES in modalità CTR e utilizzare ancora l'HMAC, ma sarebbe molto meglio eseguire una sorta di codifica stream con autenticazione integrata .
Quali sono le mie migliori opzioni per mantenere un overhead piccolo?
Utilizza qualsiasi modalità di crittografia autenticata.
Potrebbe trattarsi di un codice di flusso con supporto integrato per l'autenticazione (non quello che consiglierei, tutti i candidati sono ancora all'avanguardia), qualsiasi modalità di crittografia autenticata standard (ad es. GCM, EAX, ecc.); oppure utilizzare encrypt-then-MAC con AES-CTR e un MAC appropriato (ad esempio, AES-CMAC o SHA256-HMAC). Ognuno di quelli andrà bene. Non ci hai dato alcun requisito che possa escludere qualcuno di loro. Tutti consentono di selezionare la dimensione del tag MAC, in modo da poter controllare il sovraccarico rispetto al compromesso di sicurezza.
Ma in realtà, probabilmente staresti meglio usando TLS o DTLS - almeno, probabilmente la maggior parte della gente lo sarebbe. (So che hai detto che non vuoi, ma non ho sentito alcun convincente motivo tecnico a non usarli.)
Supponendo che il tuo protocollo sia stateful (ad esempio, devi solo inviare i parametri - come il nonce / IV - una volta), quindi il sovraccarico dell'utilizzo di una modalità AE dovrebbe essere molto piccolo. Ad esempio, CCM ha un overhead fisso di appena 4 bytes (dipende dalla dimensione MAC desiderata) . Poiché la dimensione minima di un pacchetto TCP / IP è 40 bytes , si tratta di un aumento massimo in 10% delle dimensioni (per il messaggio vuoto). Al contrario, l'HMAC SHA256 da solo ha bisogno di 32 extra bytes .
Disclaimer : non ho abbastanza esperienza per dire se questo è sufficiente per ottenere le proprietà di sicurezza di cui hai bisogno. In una risposta a una delle mie prime (e più stupide) domande, Tom Leek ha detto:
An open SSL connection implies a very slight overhead compared with raw unprotected data: in practice, about 30 extra bytes per record (it depends on the cipher suite), each record able to hold up to 16384 bytes of data, so we are talking about less than 0.2% of size increase, and you would get that with any other protocol which ensures confidentiality and integrity anyway.
Dato che una modalità AE dovrebbe fornire "riservatezza, integrità e autenticità", allora qui deve esserci qualcosa di sbagliato (ho dimenticato qualcosa che deve essere inviato oltre al testo cifrato su ogni messaggio? o è dovuto al requisito "stateful"? )
Leggi altre domande sui tag cryptography cipher-selection integrity