Sha1sum è ancora sicuro per la firma dei pacchetti software scaricabili?

Suppongo che tu "usi sha1sum " nel seguente contesto: distribuisci alcuni pacchetti software e vuoi che gli utenti siano in grado di controllare che il loro download sia il pacchetto corretto, fino all'ultimo bit. Ciò presuppone che tu abbia un modo per trasmettere il valore hash (calcolato con SHA-1) in un modo "inalterabile" (ad esempio come parte di una pagina Web che viene pubblicata su HTTPS).

Suppongo anche che stiamo parlando di attacchi qui, cioè di un individuo malintenzionato che può in qualche modo alterare il pacchetto mentre viene scaricato, e vorrebbe inserire alcune modifiche che non verranno rilevate.

La proprietà di sicurezza che la funzione di hash utilizzata dovrebbe offrire qui è la resistenza alle seconde preimmagini . Ancora più importante, questo è non uguale alla resistenza alle collisioni. Una collisione avviene quando l'utente malintenzionato può creare due messaggi distinti m e m ' che ha hash sullo stesso valore; un secondo preimage è quando l'attaccante riceve un m fisso e sfidato a trovare un distinto m ' che hash allo stesso valore.

Le seconde pre-immagini sono molto più difficili da ottenere rispetto alle collisioni. Per una funzione di hash "perfetta" con bit di n di output, lo sforzo computazionale per trovare una collisione è di circa 2 invocazioni ^{n / 2} del funzione di hash; per un secondo preimage, questo è 2 ⁿ . Inoltre, le debolezze strutturali che consentono un attacco di collisione più veloce non si applicano necessariamente a un attacco di seconda preimage. Questo è vero, in particolare, per le note debolezze di SHA-1: al momento (settembre 2015), ci sono alcune note debolezze teoriche di SHA-1 che dovrebbero consentire il calcolo di una collisione in meno del 2 ideale ⁸⁰ sforzo (questo è ancora uno sforzo enorme, circa 2 ⁶¹ , quindi non è stato ancora dimostrato); ma queste debolezze sono percorsi differenziali che intrinsecamente richiedono che l'attaccante realizzi sia m sia m ', quindi non ripercorrono le seconde preimmaginazioni.

Per il momento, non c'è nessun attacco di secondo-preimage noto su SHA-1 che sia teoricamente o accademicamente più veloce dell'attacco generico, con un costo di 2 ¹⁶⁰ che va ben oltre la tecnologia fattibilità, da un tiro lungo .

Bottom-line: nel contesto di ciò che stai cercando di fare, SHA-1 è sicuro, e probabilmente rimarrà al sicuro per qualche tempo (anche MD5 sarebbe ancora appropriato).

Un altro motivo per utilizzare sha1sum è la disponibilità di strumenti lato client: in particolare, lo strumento di hashing della riga di comando fornito da Microsoft per Windows (chiamato FCIV ) conosce MD5 e SHA-1, ma non SHA-256 (almeno così dice la documentazione) (*).

^{Windows 7 e versioni successive contengono anche uno strumento da riga di comando chiamato "certutil" in grado di calcolare gli hash SHA-256 con il sottocomando "-hashfile". Questo non è molto noto, ma a volte può essere conveniente.}

Detto questo, un potente motivo contro usando SHA-1 è quello di image : attualmente è molto di moda fare il tifo e prendere in giro qualsiasi utilizzo di SHA-1; le folle chiedono la rimozione, l'anatema, l'arresto e l'esecuzione pubblica. Usando SHA-1 stai dicendo al mondo che sei, sicuramente, non un hipster. Dal punto di vista del business, raramente fa bene a non cedere alla moda du jour , quindi dovresti usare una delle funzioni SHA-2, ad es. SHA-256 o SHA-512.

Non c'è una strong ragione per preferire SHA-256 su SHA-512 o viceversa; alcune piccole architetture solo a 32 bit sono più comode con SHA-256, ma questo raramente conta nella pratica (anche un'implementazione a 32 bit di SHA-512 sarà ancora in grado di eseguire hash diverse dozzine di megabyte di dati al secondo su un anemico laptop, e anche in modalità a 32 bit, una CPU x86 non troppo vecchia ha alcune capacità di calcolo a 64 bit con SSE2, che danno una buona spinta per SHA-512). Qualsiasi esperto di marketing ti direbbe di usare SHA-512 sulla base del fatto che 512 è maggiore di 256, quindi "deve essere migliore" in qualche (magico) modo.

Dovresti usare SHA-256 o SHA-512.

Se stai solo firmando pacchetti che hai creato da solo, allora tecnicamente SHA-1 è ancora sicuro a tale scopo. La proprietà che ora è indebolita è la "resistenza alla collisione" alla quale non si sta strettamente affidando. Tuttavia, la sicurezza di SHA-1 sta per peggiorare con il tempo, quindi ha senso andare avanti adesso.

Tom Leak ha una bella risposta (che è il motivo per cui è accettata). Si occupa dei fatti matematicamente dimostrabili dietro l'uso di SHA-1. Esiste un secondo approccio meno basato sui fatti, ma che può fornire preziose informazioni euristiche. Ho imparato questo approccio leggendo le opinioni di Bruce Schneier, ma non riesco a trovare i link a portata di mano, quindi Bruce dovrà occuparsi del mio namedropping.

In teoria un algoritmo non è rotto fino a quando non viene rotto. Fino a quando qualcuno non ha trovato un modo per fare X, dove X è qualcosa che dovrebbe essere computazionalmente non fattibile, non è considerato "rotto". ¹ Tuttavia, ciò dimostra di avere un valore limitato nella sua applicazione pratica in crittografia. I crittografi dovrebbero veramente piuttosto ricevere un piccolo preavviso prima che i loro prodotti cadano a pezzi, non dopo.

Ciò che è stato trovato, storicamente, è che gli algoritmi vengono raramente interrotti in un unico grande passo. Sì, può succedere, e un crittografo deve pianificarlo, ma ciò che è stato trovato empiricamente è che sono tipicamente ridotti nel tempo, carta dopo carta. È stato scoperto che osservare la difficoltà di generare una collisione è una metrica ragionevolmente buona per stimare quando l'algoritmo sarà effettivamente rotto. Quindi, quando Tom sottolinea che la collisione dovrebbe richiedere 2 ⁸⁰ operazioni e ora richiede 2 ⁶¹ , è molto importante indicare, come ha fatto, che il 2 ⁶¹ operazioni è teorica, perché è ancora troppo grande per giustificare un tentativo. Tuttavia, è anche valido considerarlo come "l'algoritmo ha subito una riduzione della forza di 19 bit di potenza", e lo usa come regola empirica per proiettare avanti e stimare quando ciò diventerà un problema.

Questo tipo di pensiero è il motivo per cui ora c'è un SHA-3, anche se teoricamente SHA-1 non è ancora completamente rotto. I crittografi coinvolti nello sviluppo e nei test di SHA-3 sanno che ci vorrà un po 'di tempo per sviluppare la fiducia in SHA-3, e vogliono assicurarsi che ci sia fiducia prima che l'SHA-1 si rompa, non dopo.

^1. Sono consapevole che la definizione tecnicamente più rigida di un hash "rotto" è semplicemente quella in cui un attaccante può fare meglio della forza bruta, invece che quando diventa effettivamente computazionale. Tuttavia, quest'ultima definizione è più tipicamente utilizzata quando si discute del lato pratico dell'hashing.

Anche se non stai lavorando per il governo federale, il link al documento qui sotto è un buon riferimento a quanto tempo le persone dovrebbero usare le lunghezze delle chiavi hash fino alle date future per attività specifiche come l'autenticazione di una firma. Per l'autenticazione del pacchetto, includerei anche una dimensione che rende molto più difficile creare una collisione (pacchetto modificato che corrisponde allo stesso hash). Perché non dovresti utilizzare sia SHA1 che SHA512 (se il tempo di elaborazione non è così oneroso)? Prendere in considerazione anche la lunghezza della chiave asimmetrica utilizzata per firmare l'hash indicato. Mentre è bello che tu stia pensando a questo, ci sono probabilmente altri problemi di integrità che sono più pressanti come il modo per garantire che una persona non riceva un hash falsificato per il confronto e l'origine di tutte le tue librerie incluse che sarebbero più di un rischio.

P.S. Se stai pensando ai certificati per un browser, sia Chrome che IE stanno per o hanno impostato l'interfaccia utente per l'uso di SHA1. Se stai memorizzando le password, cerca gli hash salati (e possibilmente pepati) con PBKDF2.

link link link

Per lo scopo previsto, la risposta pratica è "Sì, certo", anche se per ragioni di prestigio dovresti pubblicare anche un hash più recente (come SHA-3).
Se non avesse così tanto "puzza", in linea di principio potreste ancora usare MD5 (a parte le persone che urlano contro di voi, anche MD5 funzionerà bene per questa applicazione).

L'utilizzo di SHA-1 per verificare i download non è mai stato "sicuro" e in primo luogo non è destinato a esserlo. Lo scopo principale di fornire un hash (di qualsiasi tipo) è di rilevare errori di bit, download parziali o scaricare accidentalmente l'eseguibile sbagliato (facendo clic sulla riga sopra o sotto nell'elenco e senza accorgersene).

Le modifiche dannose sono un problema che non è risolto molto bene con un hash, dal momento che un utente malintenzionato che ha accesso sufficiente al server in modo che possa sostituire il file binario di solito può anche sostituire l'hash.
Probabilmente, do ottieni un po 'di sicurezza se usi una CDN, dato che qualcuno che accede a un nodo nella CDN non può sostituire con successo il binario su quel nodo senza l'utente (chi scarica l'hash dal server che solo tu controllo) noti.

Se, tuttavia, hai bisogno di qualcosa che deve essere "sicuro" e resiliente alle modifiche dannose, devi firmare in modo definitivo digitale i tuoi eseguibili e includere ad esempio una firma GPG. Un hash non lo farà.

Puoi ancora usarlo? .. Sì, ma sha-1 è vulnerabile agli attacchi di collisione ed è stato deprecato da un certo numero di browser.

Se la domanda fosse se dovessi ancora usarla, allora direi di no, non dovresti, dovresti passare al programma di tipo sha-2 e sha256sum.

Ci sono scelte migliori di SHA2. Blake2, ad esempio, è finalista della competizione SHA3 e blake2-256 è veloce quanto SHA1 e molto più veloce di SHA2. Può essere utilizzato come algoritmo di checksum in Winrar 5. Come MD5 e SHA1, SHA2 è basato sulla struttura Merkle-Damgard e presenta probabilmente vulnerabilità simili. SHA3 non è vulnerabile, ma SHA3-224 è ca. 8 volte più lento di SHA1.