Domanda:
Quali algoritmi crittografici non sono considerati sicuri?
Olivier Lalonde
2010-11-12 05:08:33 UTC
view on stackexchange narkive permalink

Quali algoritmi crittografici non sono considerati sicuri, ma sono ancora ampiamente utilizzati e disponibili nelle librerie standard? Se applicabile, menziona un'alternativa sicura.

Voto per chiudere questa domanda come fuori tema perché le risposte diventeranno obsolete molto rapidamente. Speriamo di modificare le Risposte per fornire una guida più generale sulla scoperta dei consigli più recenti sugli standard crittografici.
Nove risposte:
#1
+21
AviD
2010-11-12 05:12:20 UTC
view on stackexchange narkive permalink

Questi sono i più comuni:

  • MD5 - Usa SHA512
  • SHA1 - Usa SHA512 (nota che questo non è veramente insicuro, ma mostra la sua età e essere fragiler nei prossimi due anni ....)
  • DES / 3DES - Usa AES
Ancora più interessante sarebbe il contesto in cui questi sono considerati insicuri e dove fanno il loro lavoro bene.
@Jorn, direi che con l'eccezione di SHA1 (che è ancora abbastanza buono per sistemi non critici per un altro paio di anni buoni), non c'è motivo di usarli mai (MD5 / DES / 3DES) in un contesto crittografico. Soprattutto 3DES, poiché AES è più veloce! Anche se ho visto MD5 utilizzato in un contesto non di sicurezza, un po 'come un GUID dipendente dal contenuto ... o qualcosa del genere.
Se si dispone di un dispositivo incorporato molto debole, è possibile scegliere di utilizzare un algoritmo più debole per informazioni di basso valore e / o sensibili al tempo (i dati sono necessari rapidamente e i dati invecchiano molto velocemente). Il problema è che le informazioni apparentemente innocenti possono effettivamente essere utilizzate in modi nefasti. È più facile usare la crittografia (attualmente) indistruttibile.
@rox0r, anche su un dispositivo embedded debole, AES è migliore sulle risorse di 3DES. L'unico problema è nelle piattaforme legacy, che non supportano la crittografia moderna.
Un buon consiglio, anche se SHA256 è più veloce, più corto e per ora va bene anche. Vedere http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html e notare che la sicurezza delle funzioni hash è ancora poco conosciuta e ci sono anche preoccupazioni teoriche su SHA512. Esiste una grande competizione sull'hashish organizzata dal NIST per stimolare la ricerca e specificare, forse nel 2012, ciò che verrà chiamato SHA-3 http://en.wikipedia.org/wiki/NIST_hash_function_competition
-1
@avid Grazie. E hai ragione su SHA-3: il mio punto nel menzionarlo era sottolineare come anche gli esperti siano a disagio con la nostra conoscenza delle funzioni hash, rispetto ad es. crittografia e il passaggio a sha256 o sha512 probabilmente non sarà il nostro consiglio per così tanto tempo.
@nealmcb - hai ragione ovviamente, ma per i prossimi 3-5 anni SHA512 sarà ancora probabilmente l'hash di scelta. E anche dopo che SHA3 sarà ampiamente adottato, SHA512 sarà ancora "accettabile". (Anche SHA256, ma 512 in più).
@avid, l'RFC per gli UUID contiene già le indicazioni sulla creazione di GUID dipendenti dal contenuto ;-)
-1
Se sei su un server a 32 bit, la differenza di prestazioni rispetto a una buona implementazione di sha256 (224) e sha512 (384) è più evidente che su un server a 64 bit. C'è ancora una differenza perché sha256 ha 64 round, sha512 ha 80 round. (rispettivamente per ogni blocco di dati da 512 o 1024 bit). È interessante notare che sha224 e sha384 sono un * un po '* un po' ** più lenti ** delle loro controparti, perché fanno gli stessi calcoli e poi eliminano parte del risultato. ([eccolo in python] (http://code.google.com/p/slowsha/source/browse/slowsha.py))
#2
+15
nealmcb
2010-12-23 05:50:15 UTC
view on stackexchange narkive permalink

A partire dalla fine del 2010, il governo degli Stati Uniti ha deprecato questi algoritmi sulla base dei consigli di persone molto esperte del NIST:

  • SHA-1
  • 1024 bit RSA o DSA
  • ECDSA a 160 bit (curve ellittiche)
  • 2TDEA a 80/112 bit (DES tripla a due chiavi)

MD5 mai era un algoritmo accettabile per l'uso da parte del governo, insieme a molti altri algoritmi meno recenti.

Per la sicurezza fino all'anno 2030, raccomandano almeno SHA-224, 2048 bit per RSA o DSA, EDCSA a 224 bit e È possibile utilizzare AES-128 o triple-DES a 3 tasti.

Questo è in lavorazione da diversi anni. Vedi questo post e i documenti del NIST a cui fa riferimento: http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation

Aggiornamento: Un'altra serie di consigli concisi e utili è Cryptographic Right Answers di Colin Percival.

#3
+12
Thomas Pornin
2011-04-29 01:30:58 UTC
view on stackexchange narkive permalink

Gli algoritmi crittografici non sicuri ma ampiamente utilizzati includono:

  • funzioni hash: MD4, MD5, (SHA-1) (MD2 è anche insicuro ma non ampiamente utilizzato; SHA-1 è solo "indebolito"; MD4 e MD5 sono anche ampiamente utilizzati in situazioni in cui non è richiesta resistenza crittografica, quindi non è un problema)

  • crittografia simmetrica: DES (chiave a 56 bit ), RC4 (non casualità, ma la maggior parte dei problemi di sicurezza con RC4 sono nel modo in cui viene utilizzato, non a causa dell'algoritmo stesso), il cifrario del flusso nel formato di archivio Zip (le utilità Zip più recenti utilizzano AES)

  • crittografia asimmetrica: RSA con una chiave troppo corta (ovvero 768 bit o meno), RSA con riempimento errato (ad esempio ISO 9796-1), Diffie-Hellman modulo un numero primo troppo piccolo (768 bit o meno) (Diffie-Hellman non è realmente un algoritmo di crittografia asimmetrica, ma un algoritmo di accordo chiave, ma la maggior parte degli usi della crittografia asimmetrica sono accordi chiave in realtà camuffati)

  • firme digitali : RSA con una chiave troppo corta (ovvero 768 bit o meno)

  • molti (troppi) algoritmi fatti a mano da persone che si sono esagerate; un ottimo esempio è CSS, la crittografia per DVD

Alternative sicure: SHA-256 per l'hashing (SHA-512 se hai lo stesso feticcio in termini di dimensioni dell'esercito americano, e / o se si desidera ridurre le prestazioni su sistemi a 32 bit), AES per la crittografia simmetrica. Per un accordo chiave, considera ECDH (Diffie-Hellman su una curva ellittica) con una delle curve NIST standard (ad esempio P-224, K-233 o B-233 - ma P-256 è più ampiamente supportato). Per la crittografia asimmetrica, utilizza RSA con una chiave abbastanza grande (1024 bit per la sicurezza a breve termine, preferibilmente 1536 o 2048 bit) e il riempimento PKCS # 1 (v1.5 "vecchio stile" va bene, ma OAEP è più fine). Per le firme, considera ECDSA (stesse curve che per ECDH) o RSA con una chiave abbastanza grande e riempimento PKCS # 1 (v1.5 o PSS). Mai progettare il tuo algoritmo (o, se lo fai, mai credere che sia sicuro).

La maggior parte dei problemi di sicurezza, tuttavia, non sono nella scelta dell'algoritmo, ma nel modo in cui vengono utilizzati. WEP utilizza RC4, ma RC4 non è uno dei numerosi punti deboli di WEP. Sony ha protetto la PlayStation 3 con ECDSA, che è sicuro, ma ha compromesso il proprio generatore di casualità, provocando un guasto catastrofico (esposizione della chiave privata ...).

#4
+6
yfeldblum
2011-05-04 04:00:51 UTC
view on stackexchange narkive permalink

Il contesto è importante. Sicuro per cosa ? Come viene utilizzato qualcosa?

Ad esempio:

  • AES-256 è "sicuro". Fino a quando non decidi di crittografare un flusso di dati strutturati a blocchi con AES-256 in modalità ECB.
  • AES-256 è "sicuro". Fino a quando non cripti più messaggi in modalità CBC ma con la stessa chiave e lo stesso IV.
  • AES-256 è "sicuro". Fino a quando non utilizzi un'implementazione la cui tempistica varia con i bit della chiave o dei dati.
I commenti di Justice sono davvero importanti (anche se un po 'concisi - @Justice, avresti potuto spiegare un po' meglio i tuoi punti, o almeno includere un collegamento ad alcune discussioni su questi problemi)
Bloccato un paio di link di Wikipedia lì.
#5
+5
Henri
2010-11-12 18:26:12 UTC
view on stackexchange narkive permalink

Sebbene questa domanda abbia già una risposta, mi mancano molte risposte.

  • RC2, RC4
  • MD4 (è ancora disponibile in alcune librerie)

Inoltre, dipende dall'uso e dallo scopo dell'algoritmo. Rompere il DES non è difficile, ma è piuttosto costoso. Considera chi sono i tuoi aggressori e quanti soldi e quanti sforzi possono spendere per violare la sicurezza?

#6
+4
Tate Hansen
2010-11-12 06:06:10 UTC
view on stackexchange narkive permalink

I collegamenti seguenti possono aiutarti a scegliere rapidamente il metodo e la lunghezza della chiave corretti per i tuoi requisiti di sicurezza (evitando così metodi non sicuri):

" Questo sito web implementa formule matematiche e riassume i rapporti di organizzazioni ben note che ti consentono di valutare rapidamente i requisiti minimi di sicurezza per il tuo sistema. Puoi anche confrontare facilmente tutte queste tecniche e trova la lunghezza della chiave appropriata per il livello di protezione desiderato. "

#7
+2
tylerl
2011-04-29 13:23:50 UTC
view on stackexchange narkive permalink

Ovviamente ci sono tanti algoritmi non funzionanti quanti sono i programmatori che scrivono sistemi di crittografia fatti in casa, ma in generale questi sono limitati a un dato pacchetto software. Vengono in mente diversi schemi di "protezione con password" per documenti e archivi come esempi.

Ma l'unico algoritmo di crittografia di uso generale (non algoritmo di hashing come altri sono elencati) che è considerato "non funzionante" per l'uso normale perché di difetti nell'algoritmo (piuttosto che nella lunghezza della chiave), e che è ancora ampiamente distribuito e accettato, è RC4.

Si noti che il motivo principale per cui RC4 rimane in giro nonostante i suoi noti difetti è che la vulnerabilità può essere mitigata eliminando i primi K output. Inoltre, è l'unico cifrario a flusso ampiamente distribuito e molti programmatori non si rendono conto che è possibile trasformare un codice a blocchi in un codice a flusso utilizzando una modalità di concatenamento di blocchi appropriata.

Non sono sicuro di quanto sia ampiamente distribuito, ma un interlocutore qui stava progettando di implementare TEA fino a quando non ne ha sentito parlare dei problemi. http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
@nealmcb: TEA è stato (male) utilizzato su Xbox (non su Xbox 360), quindi è stato ampiamente distribuito. Microsoft ha utilizzato TEA come funzione hash e TEA è molto peggiore come funzione hash di quanto non sia già come cifrario a blocchi.
Non ho elencato TEA perché non è generalmente disponibile nelle API crittografiche. L'attrazione principale è che è facile da implementare nell'hardware.
#8
+1
stiabhan
2014-12-29 06:16:03 UTC
view on stackexchange narkive permalink

È probabilmente meglio evitare RC4. Il suo uso improprio è stata la causa dei problemi in WEP, il che suggerisce che è difficile da ottenere anche per gli esperti. Per usarlo correttamente significa scegliere una chiave abbastanza grande (almeno 128 bit), mescolare chiave e IV in modo sicuro (es. Hashing invece di concatenazione) e scartare la parte iniziale del keystream per mitigare gli attacchi con chiave debole (256 ottetti al minimo).

#9
  0
Bradley Kreider
2011-05-03 01:28:22 UTC
view on stackexchange narkive permalink

Utilizzo di un codice a blocchi come Blowfish o AES, se utilizzato in modalità ECB (Electronic Code Book).

Non credo che l'abbia affermato. Lo analizzo come Blowfish / ECB e AES / ECB sono per lo più inutili.
Grazie, @Bruno. Hai ragione e io ho sbagliato. Ho cancellato il mio commento, dove ho frainteso @rox0r, e modificato la risposta per cercare di essere più chiaro nel caso in cui qualcun altro lo legga allo stesso modo.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...