Come usare RC4 in modo sicuro

Question

Come usare RC4 in modo sicuro

#1 da (3 voti)
#2 da (1 voti)

3

Voglio crittografare le mie comunicazioni di rete con RC4 . La ragione per cui si sceglie RC4 è la semplice implementazione e velocità.

Ho bisogno di una pura implementazione Python, perché non posso compilare il mio sistema di destinazione. La mia implementazione è leggermente modificata da TLS Lite .

Se capisco i problemi di sicurezza correttamente, il problema principale è che l'algoritmo non è progettato per essere utilizzato con un nonce . Come proposto su Wikipedia, il mio approccio è quello di generare un hash MD5 della chiave e un nonce e usarlo come chiave di crittografia.

È sufficiente o devo implementare anche la variante dropN ? Qualunque altro punto debole devo guardare?

Sarebbe anche apprezzata un'alternativa rapida e semplice a RC4.

Aggiornamento Dopo aver letto Archivio ePrint di Cryptology: Report 2002/067 , penso che dovrei sicuramente usare l'approccio dropN (con almeno 512 byte).

Aggiornamento 2 La revisione della mia implementazione sarebbe anche carina.

encryption network

posta schlamar 19.06.2012 - 14:20

fonte

2 risposte

Leggi altre domande sui tag encryption network

Perché alcune applicazioni ospitano l'API in un dominio diverso? Un worm polimorfico / metamorfico può usare un mutex?

score 3 · Answer 1

Primo: NON usare MD5. Mai. Mai. Soprattutto non in qualsiasi forma di contesto di sicurezza. Utilizza almeno SHA-1 o SHA-2 (256 o 512/256 se la velocità è un problema su macchine a 64 bit). A parte alcuni motivi ereditari, MD5 dovrebbe essere bannato e più velocemente smetti di usarlo, meglio è fuori servizio.

Se hai bisogno di un'implementazione Python semplice e pura, ne ho una a link .

È fondamentalmente la stessa implementazione che abbiamo usato come una delle fonti per i vettori di test in RFC 6229 .

Sì, dovresti usare nByte. Guarda l'arcfour128, arcfour256 definito in RFC 4345 o alcuni degli altri per i quali abbiamo calcolato i vettori di test.

Mi rendo conto che dovrei spostare RC4.py in GitHub . E cambia l'impronta digitale per usare qualcosa di diverso da MD5. Facepalm. ; -)

score 1 · Answer 2

RC4 presenta alcune lacune:

Non ha Vettore di inizializzazione distinto dalla chiave. Se si usa la stessa chiave due volte, si ottiene il doppio della stessa sequenza di byte pseudo-casuali, e l'uso di questo è un peccato mortale. Pertanto, ogni chiave dovrebbe essere utilizzata una sola volta (per un flusso di byte possibilmente lungo). Derivando la chiave di crittografia da una "chiave principale" e un valore casuale per messaggio, utilizzando una funzione di derivazione della chiave (ad esempio una funzione di hash), puoi correggere che se fatto correttamente .
Ha bias piuttosto grandi nei primi byte. Eliminare i primi N byte di output (per un valore di N che dovrebbe essere di alcune centinaia) può risolverlo.
Ha piccoli pregiudizi in seguito. Questi possono essere mostrati statisticamente su alcuni gigabyte di dati. Non esiste una cura conosciuta. Questi pregiudizi sono raramente fatali.
RC4 è solo crittografia . Non fa nulla per l'integrità. In qualsiasi modello di attacco grave, la crittografia deve essere accoppiata con un MAC . Combinare un cifrario simmetrico e un MAC sicuro non è facile .

Per tutti questi motivi, il modo migliore di usare RC4 è spesso non usarlo affatto. Invece, utilizza una modalità di crittografia autenticata che fa tutto il duro lavoro; il mio preferito è EAX .

Come per performance , considera che la CPU x86 moderna offra un'implementazione hardware di AES contro quale RC4 sarà una lumaca artritica. Se tuttavia si dispone di un problema di prestazioni effettivo su un'architettura che non offre un AES ottimizzato per l'hardware, RC4 non è il migliore della classe; ci sono altri codici di flusso che sono entrambi più veloci e più sicuri (tutti i codici di flusso da l'attuale portafoglio di eSTREAM ha ricevuto un discreto controllo e ne è uscito indenne).