Strumenti per sviluppatori · SHA calcolatore hash
Perché Web Crypto offre SHA-1 a SHA-512 ma non MD5 o SHA-3
· Come funziona
crittografia API del browser sha-256 javascript
Il digest del browser API supporta esattamente quattro algoritmi. Questo post spiega perché MD5 è stato escluso, perché SHA-3 non è stato aggiunto e cosa significa per uno strumento che rifiuta di spedire ciò che la piattaforma non fornisce.
Dov'è MD5? - la prima domanda di chiunque esegua la migrazione di un flusso di lavoro con checksum legacy
Web Crypto del browser API fornisce esattamente quattro algoritmi digest: SHA-1, SHA-256, SHA-384 e SHA-512. Se raggiungi il calcolatore hash ToolAcre SHA aspettandoti MD5 o SHA-3, non li troverai. Questa specificità non è una limitazione dello strumento; riflette una scelta deliberata della piattaforma. Capire perché questi quattro sono stati inclusi e perché due alternative popolari sono state escluse ti dice molto su come sono progettate le API del browser.
Tutti i principali browser espongono crypto.subtle.digest su origini sicure. Quando JavaScript chiama quel metodo, passa all'implementazione crittografica della piattaforma: codice nativo eseguito con sandboxing di sicurezza e ottimizzazione delle prestazioni. Gli algoritmi digest offerti sono stati scelti dal W3C Web Crypto Working Group con priorità specifiche: compatibilità con gli standard di sicurezza esistenti, supporto disponibile tra le librerie crittografiche, maturità e esigenze pratiche di sicurezza della piattaforma web.
I quattro algoritmi SubtleCrypto.digest supportano: SHA-1, SHA-256, SHA-384 e SHA-512 e nient'altro
ToolAcre accetta gli stessi quattro identificatori imposti da digestBytes: SHA-1, SHA-256, SHA-384 e SHA-512. Un nome non riconosciuto viene rifiutato prima che venga chiamato Web Crypto e la suite di test supera specificatamente MD5 per confermare tale rifiuto. Il selettore descrive quindi un confine di prodotto testato piuttosto che un sondaggio di ogni digest mai standardizzato.
La presenza di SHA-1 nell'elenco non fornisce tutti e quattro i consigli equivalenti. Il suo oggetto risultato porta un flag interrotto e l'interfaccia ripete un avviso legacy; le altre tre sono le scelte SHA-2 disponibili. Disponibilità e idoneità devono rimanere separate ogni volta che uno strumento di compatibilità riproduce un vecchio valore senza incoraggiare una nuova dipendenza da esso.
MD5 è assente da questa implementazione e da Web Crypto; questo articolo non aggiunge una logica di standard non fornita
MD5 è una funzione hash crittografica che produce un digest di 128-bit, rendendolo più breve e computazionalmente più economico di SHA-256. Per decenni è stata la scelta standard per somme di controllo e firme digitali. Tuttavia, la resistenza alle collisioni di MD5 è fondamentalmente compromessa. In 2004, i crittografi hanno dimostrato collisioni pratiche (due input diversi con lo stesso digest) e l'algoritmo è stato completamente smantellato dal lavoro accademico. La vulnerabilità matematica è assoluta e permanente.
La specifica W3C Web Crypto ha fatto la scelta deliberata di non includere MD5. Il ragionamento è semplice: fornire un algoritmo non funzionante a milioni di utenti di browser ne normalizzerebbe l’utilizzo in nuove applicazioni, anche se dovrebbe apparire solo in scenari di compatibilità legacy. Se un'applicazione richiede veramente MD5 per l'interoperabilità con i vecchi sistemi, quel codice appartiene a un runtime lato server in cui il requisito viene compreso e controllato, non nel browser. Rendere convenientemente accessibile un algoritmo difettoso creerebbe aspettative di sicurezza nei nuovi sistemi.
Anche il calcolatore hash ToolAcre SHA non fornisce un'implementazione MD5. Come la piattaforma API che utilizza, si rifiuta di rendere comodamente accessibile un algoritmo difettoso. Se la tua applicazione richiede assolutamente MD5, raro al di fuori dei sistemi Git legacy, l'implementazione appartiene alla tua codebase con una nota chiara che si tratta di uno shim di compatibilità. L’accessibilità crea aspettative e gli algoritmi non funzionanti non meritano aspettative.
SHA-3 è esterno al browser API e allo strumento; la sua storia di adozione è al di fuori delle prove dell'archivio
SHA-3 è stato standardizzato da NIST in 2015 dopo una lunga competizione pubblica ed è crittograficamente solido. Utilizza una costruzione fondamentalmente diversa da SHA-2, chiamata spugna, che offre proprietà teoriche interessanti e compromessi in termini di prestazioni a seconda dell'hardware. Sui sistemi moderni, SHA-3 può essere più veloce di SHA-256. Eppure la piattaforma browser oggi non lo espone e questo ritardo riflette decisioni pratiche sulla maturità della piattaforma e sul ritmo di adozione.
Il ritardo nella spedizione di SHA-3 riflette la realtà: Web Crypto è stato progettato per coprire gli algoritmi più utilizzati sul Web e in HTTPS/TLS. Alla finalizzazione di API, SHA-2 (256, 384, 512) è stato il consenso schiacciante per i nuovi sistemi e il passaggio a SHA-3 sta avvenendo molto più lentamente rispetto al passaggio da MD5 o SHA-1. La maggior parte delle applicazioni non necessita ancora di SHA-3. Il costo per espandere API e testarlo su ogni browser e piattaforma non era giustificato dalla domanda al momento del lancio.
Questo non è un rifiuto permanente. La Web Crypto API può evolversi. Se l'adozione di SHA-3 accelera, il gruppo di lavoro potrebbe aggiungerlo. Il set attuale rappresenta gli algoritmi maturi e ampiamente standardizzati di cui Web Crypto ha bisogno per soddisfare le esigenze di sicurezza immediate della piattaforma. Le API del browser devono essere stabili e mantenute con cura; affrettarsi ad aggiungere funzionalità prima che ne sia diffusa la necessità crea oneri di manutenzione e rischi di compatibilità per gli anni a venire.
Perché SHA-1 è ancora disponibile: esigenze di verifica legacy e differenza tra offrire e consigliare
SHA-1 è incluso in Web Crypto nonostante sia crittograficamente danneggiato. Questa scelta controintuitiva spesso sorprende gli sviluppatori. L'algoritmo produce un digest da 160 bit e gli attacchi di collisione contro SHA-1 sono ora pratici: è possibile creare due documenti diversi per condividere lo stesso digest. Le collisioni con il prefisso scelto consentono agli aggressori di creare due documenti entrambi significativi durante la collisione, il che interrompe firme e certificati. Eppure rimane nella piattaforma.
SHA-1 rimane in Web Crypto per un motivo necessario: compatibilità legacy. Gli identificatori di oggetti Git sono basati su SHA-1 e, mentre il progetto Git sta passando a SHA-256, milioni di repository, riferimenti e sistemi di compilazione esistenti emettono ancora hash SHA-1. Le impronte digitali del certificato TLS dei sistemi più vecchi contengono digest SHA-1. Le API che hanno emesso firme HMAC-SHA1 anni fa necessitano ancora di convalida. Questi sistemi distribuiti devono essere verificati o migrati. La piattaforma include SHA-1 per rendere possibile il lavoro necessario.
La piattaforma API include SHA-1 con la chiara consapevolezza che è lì per compatibilità, non per raccomandazione. L'interfaccia utente del browser etichetta SHA-1 con un avviso. Il calcolatore hash ToolAcre SHA visualizza "Crittograficamente danneggiato" accanto al risultato SHA-1, garantendo che chiunque lo utilizzi comprenda che sta lavorando con materiale legacy. La trasparenza è essenziale; gli utenti non devono mai confondere la compatibilità SHA-1 con l'approvazione SHA-1.
Se la compatibilità richiede MD5, utilizza un'implementazione rivista al di fuori di questo strumento e non confondere mai la compatibilità con la sicurezza
I quattro algoritmi di Web Crypto si allineano con l'ecosistema della suite di crittografia TLS e con i più importanti standard di sicurezza. SHA-256 è l'impostazione predefinita attuale per l'hashing generico, utilizzato nei controlli di integrità delle risorse secondarie, nell'indirizzamento dei contenuti e nei nuovi sistemi di sicurezza. SHA-512 è più veloce su hardware 64 bit e offre un digest più ampio. SHA-384 è noto principalmente per il suo utilizzo nelle suite di crittografia TLS.
SHA-1 viene mantenuto per l'interoperabilità, non perché qualcuno dovrebbe avviare un nuovo sistema con esso. Se stai verificando un checksum SHA-1 esistente, facendo corrispondenza con l'impronta digitale di un vecchio certificato o riproducendo un ID commit Git, SHA-1 in ToolAcre ti consente di farlo. Se stai progettando un nuovo sistema, SHA-256 è la scelta più ovvia. L'algoritmo che scegli segnala la tua comprensione del modello di sicurezza.
Ciò che questo non copre: runtime lato server, che di solito espongono molti più algoritmi digest
Se la tua applicazione ha veramente bisogno di MD5, SHA-3 o qualsiasi altro algoritmo, la scelta è chiara: mantieni quel codice nel runtime lato server ed esponi solo il risultato finale al browser. Non fornire la propria implementazione JavaScript di un algoritmo crittografico per l'utilizzo nel browser. La crittografia Web nativa del browser è più veloce, più sicura e controllata in modi che una funzione JavaScript scritta a mano non può eguagliare. Delegare alla piattaforma è sempre la scelta corretta quando la piattaforma fornisce ciò di cui hai bisogno.
Questo vale anche per algoritmi "semplici". Un'implementazione MD5 autoscritta potrebbe sembrare innocua perché MD5 è comunque non funzionante, ma gli algoritmi non funzionanti non hanno gradazioni: sono semplicemente non funzionanti. La spedizione di uno normalizza la pratica di implementazione della crittografia nel codice dell'applicazione. Il browser fornisce ciò di cui ha bisogno la piattaforma; utilizzare ciò che fornisce. La crittografia manuale è la principale fonte di vulnerabilità della sicurezza nelle applicazioni Web perché gli sviluppatori ne sottovalutano la sottigliezza e i casi limite.
Conclusione: le limitazioni fanno parte del prodotto: il calcolatore di hash ToolAcre SHA offre i quattro algoritmi che il browser implementa in modo nativo e documenta tale confine
Il calcolatore di hash ToolAcre SHA fa emergere direttamente questo vincolo: vedi esattamente i quattro algoritmi forniti da Web Crypto, né più né meno. Se incolli un valore e pensi "Ho bisogno di MD5", l'assenza è intenzionale. Se ne hai bisogno, questo è un segnale che il tuo sistema ha un componente legacy che necessita di un'attenta gestione, esattamente il tipo di cosa a cui serve uno strumento specializzato di migrazione lato server, non un'utilità del browser. L'onestà dello strumento su ciò che fa e non offre è di per sé un'informazione preziosa.
Il design di Web Crypto riflette decenni di pratica crittografica: algoritmi standardizzati, controllati e collaudati in un'ampia implementazione. SHA-256 e SHA-512 sono le impostazioni predefinite sensate. SHA-384 porta con sé la sua stirpe TLS. SHA-1 è lì perché il Web contiene SHA-1 digest che dovranno essere verificati per anni. MD5 e SHA-3 non sono presenti perché MD5 è rotto e SHA-3 non è ancora fondamentale per la piattaforma.