Go navi con una suite completa di pacchetti di crittografia nella biblioteca standard per aiutare gli sviluppatori a costruire applicazioni sicure. completare un audit del core set di pacchetti che sono anche convalidati come parte del L'audit ha prodotto un singolo risultato di bassa gravità, ereditato e non supportato. , e una manciata di risultati informativi. Il testo completo del rapporto di audit può essere trovato . Trail di Bits Nuovo modulo FIPS 140-3 Integrazione Go+BoringCrypto qui La portata dell'audit comprendeva le nostre implementazioni di scambio chiave (ECDH e ML-KEM post-quantum), firma digitale (ECDSA, RSA e Ed25519), crittografia (AES-GCM, AES-CBC e AES-CTR), hashing (SHA-1, SHA-2, e SHA-3), derivazione chiave (HKDF e PBKDF2) e autenticazione (HMAC), nonché il generatore di numeri casuali crittografici. Siamo orgogliosi del record di sicurezza dei pacchetti di crittografia Go, e del risultato di questo audit, che è solo uno dei molti modi in cui otteniamo la certezza della correttezza dei pacchetti. che, per esempio, priorizzano la sicurezza rispetto alle prestazioni. Facciamo un punto di sfruttare le API sicure anche per i pacchetti interni, e naturalmente possiamo fare affidamento sulle proprietà del linguaggio Go per evitare problemi di gestione della memoria. Principi di criptografia Testare attentamente le Una scoperta di bassa gravità L'unico problema potenzialmente sfruttabile, TOB-GOCL-3, ha , il che significa che ha avuto un impatto minore ed è stato difficile da attivare. Questo problema è stato risolto in Go 1.24. bassa gravità In particolare, il TOB-GOCL-3 ( La gestione della memoria nella , che non è abilitato per impostazione predefinita e non è supportato per l'uso al di fuori di Google. discusso più in basso Legacy Go+BoringCrypto GOEXPERIMENT 5 Risultati informativi I risultati rimanenti sono , il che significa che non rappresentano un rischio immediato ma sono rilevanti per le migliori pratiche di sicurezza. li abbiamo affrontati nell'attuale albero di sviluppo Go 1.25 Informativa I risultati TOB-GOCL-1, TOB-GOCL-2, e TOB-GOCL-6 riguardano i possibili canali laterali di temporizzazione in varie operazioni crittografiche. Di questi tre risultati, solo TOB-GOCL-2 influisce sulle operazioni che si aspettava fossero costanti a causa del funzionamento su valori segreti, ma colpisce solo gli obiettivi di Power ISA (GOARCH ppc64 e ppc64le). TOB-GOCL-4 evidenzia il rischio di abuso in un'API interna, se dovrebbe essere riproposto al di là del suo caso di utilizzo attuale. TOB-GOCL-5 evidenzia un controllo mancante per un limite che è impraticabile da raggiungere. I canali laterali I risultati TOB-GOCL-1, TOB-GOCL-2, e TOB-GOCL-6 riguardano canali laterali di temporizzazione minori. TOB-GOCL-1 e TOB-GOCL-6 sono correlati a funzioni che non usiamo per valori sensibili, ma potrebbero essere utilizzati per tali valori in futuro, e TOB-GOCL-2 è correlato alla realizzazione di assemblaggio di P-256 ECDSA su Power ISA. : la conversione da byte a elementi di campo non è costante nel tempo (TOB-GOCL-1) crypto/ecdh,crypto/ecdsa L'implementazione interna delle curve ellittiche NIST ha fornito un metodo per convertire gli elementi di campo tra una rappresentazione interna ed esterna che operava in tempo variabile. Tutti gli usi di questo metodo hanno funzionato su input pubblici che non sono considerati segreti (valori pubblici ECDH e chiavi pubbliche ECDSA), quindi abbiamo determinato che questo non era un problema di sicurezza. , al fine di prevenire l'uso accidentale di questo metodo in futuro con valori segreti, e in modo che non dobbiamo pensare se si tratta di un problema o meno. rendere il metodo costante nel tempo comunque La negazione condizionale P-256 non è un tempo costante nell'assemblaggio Power ISA (TOB-GOCL-2, CVE-2025-22866) crypto/ecdsa Oltre il , Go supporta anche una serie di piattaforme aggiuntive, tra cui alcune architetturi meno comuni. Durante la revisione delle nostre implementazioni di assemblaggio di vari primiti crittografici sottostanti, il team di Trail of Bits ha trovato un problema che ha influenzato l'implementazione di ECDSA sulle architetture ppc64 e ppc64le. Prima classe per le piattaforme A causa dell'uso di un'istruzione di ramificazione condizionale nell'implementazione della negazione condizionale di P-256 punti, la funzione ha funzionato in tempo variabile, piuttosto che tempo costante, come previsto. con un modello che utilizziamo già altrove per selezionare condizionalmente il risultato corretto in tempo costante. Sostituzione delle istruzioni di ramificazione condizionale Per dare priorità al codice che raggiunge la maggior parte dei nostri utenti, e a causa delle conoscenze specialistiche necessarie per mirare a specifici ISA, in genere ci affidiamo ai contributi della comunità per mantenere l'assemblaggio per le piattaforme non di prima classe. Scalar.SetCanonicalBytes non è tempo costante (TOB-GOCL-6) crypto/ed25519 Il pacchetto interno edwards25519 fornisce un metodo per la conversione tra una rappresentazione interna ed esterna di scalari che operano in tempo variabile. Questo metodo è stato utilizzato solo su input di firma per ed25519.Verify, che non sono considerati segreti, quindi abbiamo determinato che questo non era un problema di sicurezza. , al fine di prevenire l'uso accidentale di questo metodo in futuro con valori segreti, e perché siamo consapevoli che le persone forcano questo codice al di fuori della libreria standard, e può essere utilizzato con valori segreti. rendere il metodo costante nel tempo comunque Gestione della memoria Cgo Trovare TOB-GOCL-3 riguarda un problema di gestione della memoria nell'integrazione Go+BoringCrypto. : il finalizzatore personalizzato può liberare la memoria all'inizio di una chiamata della funzione C utilizzando questa memoria (TOB-GOCL-3) crypto/ecdh Durante la revisione, ci sono state una serie di domande sulla nostra integrazione Go+BoringCrypto basata su cgo, che fornisce una modalità di crittografia conforme a FIPS 140-2 per uso interno a Google. Il team di Trail of Bits ha trovato una vulnerabilità e una Poiché il team di Go non supporta l'uso di questo codice al di fuori di Google, abbiamo scelto di non emettere una voce di database di vulnerabilità CVE o Go per questo problema, ma abbiamo . Bug non rilevanti per la sicurezza In questo modo si ottiene in 1.24 Questo tipo di trappola è una delle molte ragioni per cui abbiamo deciso di allontanarci dall'integrazione Go+BoringCrypto. che utilizza i regolari pacchetti di crittografia Go pura, permettendoci di evitare la complessa semantica cgo a favore del tradizionale modello di memoria Go. Modalità FIPS 140-3 Completezza implementazione I risultati TOB-GOCL-4 e TOB-GOCL-5 riguardano implementazioni limitate di due specifiche, e . NIST SP 800-90A Il RFC 8018 L'API CTR_DRBG presenta più rischi di uso improprio (TOB-GOCL-4) crypto/internal/fips140/drbg Come parte della che stiamo introducendo, abbiamo bisogno di un'implementazione del NIST CTR_DRBG (un generatore di bit randomistici deterministici basato su AES-CTR) per fornire randomizzazione conforme. Modalità FIPS 140-3 Poiché abbiamo bisogno solo di un piccolo sottoinsieme delle funzionalità del NIST SP 800-90A Rev. 1 CTR_DRBG per i nostri scopi, non abbiamo implementato la specifica completa, in particolare omettendo la funzione di derivazione e le stringhe di personalizzazione. Poiché la nostra implementazione è strettamente mirata al caso di utilizzo specifico di cui abbiamo bisogno, e poiché l'implementazione non viene esportata pubblicamente, abbiamo determinato che questo era accettabile e valeva la diminuzione della complessità dell'implementazione. Dettagli su queste limitazioni. Aggiungere un avvertimento alla documentazione PBKDF2 non impone limiti di lunghezza di uscita (TOB-GOCL-5) crypto/pbkdf2 In Go 1.24, abbiamo iniziato il processo di spostamento dei pacchetti da In un pattern confuso, i pacchetti di crittografia Go di prima parte, di alta qualità e stabili sono stati mantenuti al di fuori della biblioteca standard senza un motivo particolare. di golang.org/x/crypto Come parte di questo processo, abbiamo messo in Il pacchetto viene inserito nella libreria standard, come crypto/pbkdf2. Durante la revisione di questo pacchetto, il team di Trail of Bits ha notato che non abbiamo applicato il limite sulla dimensione delle chiavi derivate definite in . Scrivi una recensione su golang.org/x/crypto/pbkdf2 Il RFC 8018 Il limite è Quando si utilizza SHA-256, superare il limite richiederebbe una chiave di più di 137GB. Non ci aspettiamo che nessuno abbia mai usato PBKDF2 per generare una chiave così grande, soprattutto perché PBKDF2 esegue le iterazioni a ogni blocco, ma per amore della correttezza, noi . (2^32 - 1) * <hash length> attuare il limite definito dalla norma Che cosa è il prossimo I risultati di questo audit validano gli sforzi che il team di Go ha messo nello sviluppo di librerie di crittografia di alta qualità e facili da usare e dovrebbero fornire fiducia ai nostri utenti che si affidano a loro per costruire software sicuro e sicuro. Non stiamo riposando sui nostri lauri: i contribuenti di Go continuano a sviluppare e migliorare le librerie di crittografia che forniamo agli utenti. Go 1.24 include ora una modalità FIPS 140-3 scritta in puro Go, che è attualmente in fase di test CMVP. Questo fornirà una modalità compatibile con FIPS 140-3 supportata per tutti gli utenti di Go, sostituendo la attualmente non supportata integrazione Go+BoringCrypto. Stiamo anche lavorando per implementare la moderna crittografia post-quantum, introducendo una implementazione ML-KEM-768 e ML-KEM-1024 in Go 1.24 nel , e aggiungendo il supporto al pacchetto crypto/tls per lo scambio chiave ibrido X25519MLKEM768 . Pacchetto criptovaluta/mlkem Infine, stiamo pianificando di introdurre nuove API di crittografia di alto livello più facili da usare, progettate per ridurre la barriera per la selezione e l'uso di algoritmi di alta qualità per casi di utilizzo di base. pianifichiamo di iniziare con l'offerta di un semplice API di hashing delle password che elimina la necessità per gli utenti di decidere su quale della miriade di possibili algoritmi dovrebbero fare affidamento, con meccanismi per migrare automaticamente agli algoritmi più recenti come le modifiche all'avanguardia. Roland Shoemaker e Filippo Valsorda Questo articolo è disponibile su The Go Blog sotto una licenza CC BY 4.0 DEED. Il blog di Go Il blog di Go Foto di Batyrkhan Shalgimbekov su Unsplash di Batyrkhan Shalgimbekov Unsplash

Try and Download Go 

Read My Stories

Questo audio è prodotto nella lingua originale della storia!

I pacchetti di crittografia di Go sono stati controllati: i risultati

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

Raggiungi più lettori! POTENZIA la tua storia su HackerNoon

How to Mint Your Name.HackerNoon Web3 Identity Namespace

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

Meet BrowserStack: HackerNoon Company of the Week

Raggiungi più lettori! POTENZIA la tua storia su HackerNoon

How to Mint Your Name.HackerNoon Web3 Identity Namespace

I Tried Perplexity For a Week, And I Don't Think AI Search Engines Can Replace Google.. Yet

Meet BrowserStack: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps