Domanda:
Perché è sbagliato * implementare * io stesso un algoritmo crittografico noto, pubblicato, ampiamente ritenuto sicuro?
gaazkam
2019-05-07 15:49:52 UTC
view on stackexchange narkive permalink

Conosco il consiglio generale che non dovremmo mai progettare¹ un algoritmo crittografico. Se ne è parlato molto ampiamente su questo sito e sui siti web di professionisti del calibro di Bruce Schneier.

Tuttavia, il consiglio generale va oltre: dice che non dovremmo nemmeno implementare algoritmi progettati da più saggi di noi, ma piuttosto attenerci a implementazioni ben note e ben testate realizzato da professionisti.

E questa è la parte che non sono riuscita a trovare discussa a lungo. Ho anche effettuato una breve ricerca nel sito Web di Schneier e non sono riuscito a trovare questa affermazione nemmeno lì.

Pertanto, perché siamo categoricamente sconsigliati di implementare anche algoritmi crittografici? Apprezzerei molto una risposta con un riferimento a un acclamato esperto di sicurezza che ne parla.

¹ Più precisamente, progetta in base al contenuto dei nostri cuori; potrebbe essere una buona esperienza di apprendimento; ma per favore per favore per favore per favore , non utilizzare mai ciò che abbiamo progettato.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/93406/discussion-on-question-by-gaazkam-why-is-it-wrong-to-implement-myself-a-conosciuto).
Dodici risposte:
#1
+233
MechMK1
2019-05-07 16:24:15 UTC
view on stackexchange narkive permalink

Il motivo per cui vuoi evitare di implementare algoritmi crittografici da solo è a causa di attacchi side-channel.

Che cos'è un side-channel?

Quando comunichi con un server, il contenuto dei messaggi è il canale di comunicazione "principale". Tuttavia, ci sono molti altri modi per ottenere informazioni dal tuo partner di comunicazione che non implica direttamente che ti dica qualcosa.

Questi includono, ma non sono limitati a:

  • Il tempo necessario per risponderti
  • L'energia consumata dal server per elaborare la tua richiesta
  • La frequenza con cui il server accede alla cache per rispondere.

Cos'è un attacco a canale laterale?

In poche parole, un attacco a canale laterale è qualsiasi attacco a un sistema che coinvolge uno di questi canali laterali. Prendi il codice seguente come esempio:

  public bool IsCorrectPasswordForUser (string currentPassword, string inputPassword) {// Se entrambe le stringhe non hanno la stessa lunghezza, non sono uguali. if (currentPassword.length! = inputPassword.length) restituisce false; // Se il contenuto delle stringhe è diverso in qualsiasi punto, interrompi e restituisci che non sono uguali. for (int i = 0; i < currentPassword.length; i ++) {if (currentPassword [i]! = inputPassword [i]) return false; } // Se le stringhe erano della stessa lunghezza e non hanno mai avuto differenze, devono essere uguali. return true;}  

Questo codice sembra funzionalmente corretto, e se non ho fatto errori di battitura, probabilmente fa quello che dovrebbe fare. Riesci ancora a individuare il vettore di attacco del canale laterale? Ecco un esempio per dimostrarlo:

Supponi che la password corrente di un utente sia Bdd3hHzj (8 caratteri) e che un utente malintenzionato stia tentando di violarla. Se l'aggressore inserisce una password della stessa lunghezza, verranno eseguiti sia il controllo if che almeno un'iterazione del ciclo for ; ma se la password di input è più corta o più lunga di 8 caratteri, verrà eseguito solo if . Il primo caso sta facendo più lavoro e quindi richiederà più tempo per essere completato rispetto al secondo; è semplice confrontare i tempi necessari per controllare una password di 1 carattere, 2 caratteri, 3 caratteri ecc. e notare che 8 caratteri è l'unico che è notevolmente diverso, e quindi è probabile che sia la lunghezza corretta del password.

Con questa conoscenza, l'attaccante può perfezionare i propri input. Per prima cosa provano da aaaaaaaa tramite aaaaaaaZ , ognuno dei quali esegue solo un'iterazione del ciclo for . Ma quando arrivano a Baaaaaaa , si verificano due iterazioni del ciclo, che di nuovo richiede più tempo per essere eseguito rispetto a un input che inizia con qualsiasi altro carattere. Questo indica all'aggressore che il primo carattere della password dell'utente è la lettera B e può ora ripetere questo passaggio per determinare i caratteri rimanenti.

Come si collega questo al mio Codice crittografico?

Il codice crittografico ha un aspetto molto diverso dal codice "normale". Quando si guarda all'esempio precedente, sembra sbagliato in alcun modo significativo. Pertanto, quando si implementano le cose da soli, potrebbe non essere ovvio che il codice che fa quello che dovrebbe fare ha solo introdotto un grave difetto.

Un altro problema a cui posso pensare è che i programmatori non sono crittografi. Tendono a vedere il mondo in modo diverso e spesso fanno supposizioni che possono essere pericolose. Ad esempio, guarda il seguente test unitario:

  public void TestEncryptDecryptSuccess () {string message = "This is a test"; KeyPair keys = MyNeatCryptoClass.GenerateKeyPair ();
byte [] cipher = MyNeatCryptoClass.Encrypt (messaggio, keys.Public); stringa decryptedMessage = MyNeatCryptoClass.Decrypt (cifratura, chiavi.Private); Assert.Equals (message, decryptedMessage);}  

Riuscite a indovinare cosa c'è che non va? Devo ammettere che non era una domanda giusta. MyNeatCryptoClass implementa RSA ed è impostato internamente per utilizzare un esponente predefinito di 1 se non viene fornito esplicitamente alcun esponente.

E sì, RSA funzionerà perfettamente se si utilizza un esponente pubblico di 1. Semplicemente non "crittografa" nulla, poiché "x 1 " è ancora "x".

Potresti chiederti chi sano di mente lo farebbe , ma ci sono casi in cui ciò si verifica effettivamente.

Errori di implementazione

Un altro motivo per cui potresti sbagliare nell'implementare il tuo codice sono gli errori di implementazione. Come sottolinea l'utente Bakuridu in un commento, i bug nel codice Crypto sono fatali rispetto ad altri bug. Ecco alcuni esempi:

Heartbleed

Heartbleed è probabilmente uno dei bug di implementazione più noti quando si parla di crittografia. Pur non coinvolgendo direttamente l'implementazione del codice crittografico, tuttavia illustra come possono andare cose mostruosamente sbagliate con un bug relativamente "piccolo".

Mentre l'articolo di Wikipedia collegato va molto più in profondità sulla questione, io vorrei che Randall Munroe spiegasse la questione in modo molto più conciso di quanto avrei mai potuto:

https://xkcd.com/1354/ https://xkcd.com/1354/ - Immagine concessa in licenza con CC 2.5 BY-NC

Debian Debian PRNG Bug

Nel 2008, c'era un bug in Debian che ha influenzato la casualità di tutti gli altri materiali chiave utilizzati. Bruce Schneier spiega il cambiamento apportato dal team Debian e perché è stato problematico.

L'essenza di base è che gli strumenti che controllano possibili problemi nel codice C si lamentavano dell'uso di variabili non inizializzate. Sebbene di solito questo sia un problema, il seeding di un PRNG con dati essenzialmente casuali non è male. Tuttavia, poiché a nessuno piace fissare gli avvisi ed essere addestrato a ignorare gli avvisi può portare a propri problemi su tutta la linea, il codice "offensivo" è stato rimosso ad un certo punto, portando così a una minore entropia per OpenSSL con cui lavorare.

Summary

In sintesi, non implementare la tua Crypto a meno che non sia progettata per essere un'esperienza di apprendimento! Usa una libreria crittografica controllata progettata per rendere facile farlo nel modo giusto e difficile farlo nel modo sbagliato. Perché Crypto è molto facile sbagliare.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/93466/discussion-on-answer-by-mechmk1-why-is-it-wrong-to-implement-myself-a-noto-p).
Personalmente, farei "errori di implementazione" il primo elemento in quanto è molto più probabile, secondo me, che uno sviluppatore medio di joe commetta un errore che consente di rompere facilmente la crittografia, invece di essere colpito da un attacco di canale laterale.Consiglierei anche di sottolineare che i manutentori dei progetti OpenSSL erano programmatori crittografici esperti, e se * hanno * fatto un errore così semplice, è improbabile che lo sviluppatore medio di joe faccia molto meglio.
So di aver risposto "per", ma un ottimo argomento contro è l'implementazione ben intenzionata della "convalida dell'email" con migliaia di esempi che fanno schifo, nonostante le regole siano chiare, pubbliche e disponibili negli ultimi 30 anni.
@mckenzm Perché?RFC-822 definisce una regex per un indirizzo e-mail valido.
#2
+85
Cort Ammon
2019-05-07 19:18:46 UTC
view on stackexchange narkive permalink

Gli attacchi al canale laterale menzionati sono una cosa importante. Lo generalizzerei un po 'di più. La tua libreria crittografica è un codice ad alto rischio / alta difficoltà. Questa è spesso la libreria affidabile per proteggere il resto di un sistema altrimenti morbido. Gli errori qui possono facilmente essere milioni di dollari.

Peggio ancora, spesso devi combattere il tuo stesso compilatore. Le implementazioni affidabili di questi algoritmi sono pesantemente studiate, sotto molti compilatori diversi, e hanno piccole modifiche per garantire che i compilatori non facciano cose cattive. Quanto male? Bene, considera quegli attacchi di canale laterale che tutti menzionano. Scrivi attentamente il tuo codice per evitare tutti quegli attacchi, facendo tutto bene. Quindi esegui il compilatore su di esso. Il compilatore non ha la più pallida idea di cosa stavi facendo. Può facilmente vedere alcune di quelle cose che hai fatto per evitare attacchi al canale laterale, vedere un modo più veloce per farlo e ottimizzare il codice che hai aggiunto con cura! Questo è stato anche mostrato nel codice del kernel, dove un'assegnazione apparentemente fuori ordine finisce per dare al compilatore il permesso di ottimizzare un controllo degli errori!

Rilevare cose del genere può essere fatto solo con un disassemblatore e molta pazienza.

Oh, e non dimenticare mai i bug del compilatore. Il mese scorso ho passato la maggior parte della settimana a rintracciare un bug nel mio codice che in realtà era perfettamente a posto: era un bug noto nel mio compilatore che stava effettivamente causando il problema. Ora sono stato fortunato qui, in quanto il bug ha bloccato il mio programma in modo che tutti sapessero che era necessario fare qualcosa. Alcuni bug del compilatore sono più sottili.

L'assegnazione leggermente fuori ordine non era nel codice crittografico ed è qualcosa di cui tutti gli sviluppatori C e C ++ devono essere consapevoli.(Naturalmente, è potenzialmente più costoso nel codice crittografico).
@MartinBonner D'accordo, non codice crittografico, anche se anni fa ho sentito che ha colpito MySQL come una vulnerabilità.Hanno verificato "correttamente" la presenza di un buffer overflow circolare, ma lo hanno fatto utilizzando l'overflow del puntatore, che è UB, quindi il compilatore ha compilato il check out.Non criptovaluta, ma una di quelle piccole cose che non puoi permetterti di sbagliare in criptovaluta.
@CortAmmon e la differenza fondamentale è che quando è coinvolta la crittografia, le persone ** molto attivamente ** cercheranno tutti i tuoi difetti e avranno buone ragioni per non dirtelo mai.Lanceranno letteralmente tutti i trucchi attualmente esistenti, quindi passeranno a cose a cui non si è ancora pensato.
_Qualunque_ codice, non solo codice crittografico, che "si basa" su un comportamento indefinito non può essere considerato attendibile, punto.Il codice che richiama UB è essenzialmente privo di significato e non c'è modo di contenere l'indefinizione.I casi che hai citato in cui il compilatore "rovina" il codice applicando un'ottimizzazione sono un artefatto della malformatezza del sorgente che è stato fornito.Non è un errore da parte del compilatore, ma del programmatore.
Non si combatte il compilatore quando si tratta di un comportamento indefinito (ciò implicherebbe che si sta comportando male), si combatte invece il linguaggio C e il modo in cui rende UB difficile da individuare.Se non ti piace il C, allora non usarlo o proponi formalmente una revisione.
Sul tema dei compilatori, c'è anche la possibilità che si tratti di [malware] (https://www.wired.com/2009/08/induc/).
@AlexReinking Condividete un'opinione con gli sviluppatori di GCC =) È vero che UB è UB, a meno che non miriate specificamente a * a * compilatore e ai suoi comportamenti particolari (nel qual caso è UB per le specifiche, ma non UB per quel compilatore).Lo scopo di quella sezione era mostrare quanto possono essere tremendamente * sottili * questi bug.E può anche funzionare per diverse versioni del tuo compilatore, superando i tuoi test, solo per apparire quando aggiorni i compilatori in un secondo momento e il compilatore risponde all'UB in modo diverso.
@Nelson Ho cercato di capire se questa è davvero una differenza o no.Credo che le persone guardino molto attivamente a tutti i software sfruttabili, crittografici o meno.Penso che la crittografia sia semplicemente una libreria rivolta agli utenti che, se compromessa, probabilmente espone il software scarsamente protetto sottostante (che dipendeva dalla crittografia).Questa è pura congettura, ma mi aspetto che software come httpd di Apache o lo stack TCP / IP del kernel Linux vengano attaccati in modo altrettanto brutale come software crittografico come OpenSSL.Poi di nuovo, consiglierei anche "non tirare il tuo" anche per questo tipo di librerie!
@CortAmmon - Può essere ragionevole, anche se avverto che c'è una differenza tra UB e il comportamento definito dall'implementazione.Se prendi questa filosofia, devi anche riconoscere che non sei dipendente solo dal fornitore, ma dalla particolare versione e dal livello di patch.
@CortAmmon Sì, le persone cercano tutto il software sfruttabile, ma la crittografia è vista come un obiettivo di alto valore perché è usata per proteggere cose di valore.Se un utente malintenzionato può sfruttare un difetto in una libreria crittografica che fa parte di uno schema di autenticazione per ottenere l'accesso a un sistema, può causare molti danni.
Con un codice ad alto rischio / alta difficoltà, vuoi davvero scegliere una libreria crittografica ben controllata, possibilmente anche open source.Molte paia di occhi hanno maggiori possibilità di individuare errori, quindi poche.
Il pensiero paranoico sugli effetti collaterali dell'avere una cultura forte che scoraggia le persone a lanciarsi nella propria: garantisce che tutti finiscano per utilizzare un numero esiguo di librerie per tutto il lavoro crittografico ... rendendo molto più trattabile per qualsiasi gruppo capace di compromettere la maggior parte di tutticomunicazione mirando a circa una mezza dozzina di biblioteche.
@Murphy Questo è il pensiero della teoria del complotto ... il che significa che ti adatti perfettamente alla folla =) In tutta serietà, questa è l'idea alla base dell'open source.Più occhi sul codice significano più occhi cappello bianco sul codice e occhi cappello nero.Se quell'idea * effettivamente * funziona a nostro favore è qualcosa che impareremo (o non impareremo!) Nei prossimi decenni!Buona aggiunta alla discussione!(Se posso offrire un caso di studio per approfondire la tua argomentazione, [backdoor di accesso di Ken Thompson] (https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html) è un esempio di questorivelato nel lontano 1984)
@CortAmmon un po '.Il mio esempio è l '[Underhanded C Contest] (http://www.underhanded-c.org/) dove l'obiettivo è scrivere codice che possa superare la revisione del codice includendo qualcosa di subdolo.Mi piacerebbe che ci fosse un framework per rendere più sicuro per le persone il roll del proprio codice.Crittografa prima con la libreria standard ... quindi rilascialo in una sandbox dove un dilettante può sovrapporre il proprio metodo casuale con chiavi separate senza il rischio significativo di indebolire il livello interno.Sconfiggere le tattiche che prendono di mira le biblioteche standard.
@Murphy che sembra una ricetta per il fallimento.Crittografa qualcosa e lascia che qualcun altro giochi con il risultato.Hmm, fammi memorizzare nella cache i risultati di questa password crittografata e fare qualcosa di speciale se qualcuno lo vuole di nuovo.Hai appena proposto un modo per indebolire la crittografia.
@iheanyi quindi perché ho menzionato una sorta di framework per separare l'altra implementazione.Se non riutilizzi le chiavi o agisci in modo altrettanto stupido e lavori con il blocco di dati crittografato, non dovresti essere in grado di indebolirlo più di tutto il resto del codice casuale in esecuzione sul tuo server che esegue attività o del server che trasmette quel blocco crittografatosulla rete dovrebbe essere in grado di indebolire la crittografia.(sebbene sia importante che l'implementazione più solida vada per prima) La monocultura nel mercato delle biblioteche crittografiche rende l'intero settore vulnerabile.
@Murphy hahaha, il tuo "framework" apparentemente è "non scrivere codice difettoso o codice che fa qualcosa di sbagliato".
@Murphy Se ti sto leggendo correttamente, stai parlando di utilizzare la crittografia multipla?Prima crittografate con qualcosa di "fatto in casa" per la diversità, quindi crittografate con un metodo di crittografia standard prima di inviarlo?Si spera usando chiavi diverse, ovviamente.
@CortAmmon Cascade cipher ed è molto importante che il miglior algoritmo vada per primo. https://link.springer.com/article/10.1007/BF02620231 E sì, devi usare chiavi diverse. Se fossi una figura oscura in una delle grandi agenzie di intelligence governative, probabilmente lascerei solo 10 milioni per sovvertire ciascuna delle prime 10 biblioteche crittografiche più utilizzate, quindi altri pochi milioni su una campagna di pubbliche relazioni incentrata sulla discussione crittografica che dice a tutti di mai e poi maicreare le proprie implementazioni .... e chiamarlo un giorno.
#3
+19
Emilio M Bumachar
2019-05-07 22:52:37 UTC
view on stackexchange narkive permalink

Il motivo contro il rollio della tua crittografia è che i bug possono nascondersi nel software crittografico senza sintomi, anche di fronte a test approfonditi.

Tutto sembrerà funzionare perfettamente. Ad esempio, in un'applicazione di firma / verifica, il verificatore andrà bene. firme valide e rifiuta quelle non valide. Le firme stesse appariranno incomprensibili alla vista, ma il bug sarà ancora lì, in attesa di un vero attacco.

Hai mai digitato un carattere nel tuo codice e non te ne sei accorto, causando un editor evidenziare o un errore di compilazione veloce o di runtime, quindi risolto prontamente? Se non avesse evidenziato, compilato ed eseguito senza sintomi visibili, potresti mai cogliere quell'errore di battitura? Questo è il livello di difficoltà nel lanciare la tua crittografia.

#4
+15
Mark
2019-05-08 01:39:00 UTC
view on stackexchange narkive permalink

Anche in situazioni in cui non sono possibili attacchi sul canale laterale, gli algoritmi crittografici spesso hanno dettagli di implementazione che sono critici per la sicurezza ma non ovvi. Due esempi:

  • L ' algoritmo di firma ECDSA richiede l'uso di un numero intero casuale durante la generazione di una firma. Questo numero intero deve essere diverso per ogni firma generata con una determinata chiave privata. Se viene riutilizzata, chiunque riceva due firme può recuperare la chiave privata utilizzando l'aritmetica modulare di base. (Sony ha commesso questo errore con la protezione dalla copia per PlayStation 3, utilizzando lo stesso numero per ogni firma.)

  • Generazione della coppia di chiavi per l'algoritmo RSA richiede la generazione di due numeri primi grandi casuali. In condizioni normali, il ripristino della chiave privata richiede la fattorizzazione di interi o la risoluzione del problema RSA, entrambe operazioni matematiche molto lente. Se, tuttavia, una coppia di chiavi condivide uno dei suoi numeri primi con un'altra coppia di chiavi, le chiavi private di entrambe le coppie possono essere facilmente recuperate semplicemente calcolando il massimo comune divisore delle due chiavi pubbliche. (Un certo numero di router genera certificati SSL al primo avvio, quando non è disponibile molta casualità. Di tanto in tanto, due router generano certificati con coppie di chiavi sovrapposte.)

#5
+9
Augusto
2019-05-07 16:06:35 UTC
view on stackexchange narkive permalink

Penso che la piccola stampa dica:

Va ​​bene implementare un algoritmo crittografico fintanto che il codice è privo di bug ed evita ogni trappola su ogni piattaforma (sistema operativo e architettura) in cui il codice verrà eseguito.

Ad esempio, alcune implementazioni probabilmente hanno codice extra per prevenire attacchi di canale laterale. Non è intrinseco all'algoritmo, ma è necessario per rendere sicura l'implementazione. Questo è probabilmente uno dei tanti.

#6
+8
AJ Henderson
2019-05-08 03:14:31 UTC
view on stackexchange narkive permalink

È estremamente facile sbagliare la crittografia se la implementi tu stesso e non ne hai una comprensione estremamente solida. Delle implementazioni coltivate in casa che ho visto nella mia carriera, non riesco a pensare a una sola che non presentasse debolezze catastrofiche che sono state facilmente sfruttate portando a una rottura definitiva nella maggior parte dei casi o almeno a un grave indebolimento del protezione.

Oltre a ciò, anche se hai le capacità e la comprensione per eseguire la tua implementazione, la possibilità di altri punti deboli rispetto all'implementazione stessa è alta per cose come attacchi temporali o bug effettivi nell'implementazione che potrebbero informazioni sulle perdite direttamente anche se le cose funzionano correttamente in un caso ideale. In questi casi, non è che gli implementatori abbiano una migliore comprensione, necessariamente tanto quanto molte più persone hanno utilizzato e testato l'implementazione e ci sono molte più persone che cercano di assicurarsi che sia sicura.

Se implementi te stesso, hai un numero molto piccolo di cappelli bianchi che lo guardano e un numero potenzialmente elevato di cappelli neri, quindi sei fuori numerato dagli aggressori. Utilizzando un'implementazione ampia e molto utilizzata, bilancia il numero di hacker white e black hat che lo attaccano per ottenere un mix più uniforme.

#7
+3
jl6
2019-05-09 21:00:36 UTC
view on stackexchange narkive permalink

Vorrei offrire una prospettiva leggermente diversa ...

Non è che nessuno dovrebbe mai implementare la crittografia. Dopotutto, qualcuno deve farlo. È solo un compito estremamente arduo e dovresti chiederti se hai l'esperienza e le risorse necessarie a tua disposizione.

Se hai una forte esperienza in campi pertinenti della matematica e dell'informatica, un forte team di revisori tra pari, test metodici e accurati in tutti gli ambienti, tieniti aggiornato con la letteratura pertinente, comprendi le insidie ​​di progettazione e implementazione che sono specifico per crypto ... allora certo, vai avanti e implementa crypto.

..e se pensi che non ci sia già niente di adatto al tuo uso e che sarà buono come quello che farai tu.
#8
+2
drjpizzle
2019-05-09 05:29:55 UTC
view on stackexchange narkive permalink

Bene, questo si è intensificato rapidamente. Mi rendo conto che non sarà popolare ma, se pensi di sapere cosa stai facendo e hai una buona comprensione della lingua che usi e del modo in cui viene utilizzata, allora potresti benissimo essere perfettamente al sicuro scrivendo la propria implementazione di alcune primitive crittografiche.

Per esempio, se si controlla che gli hash corrispondano al valore atteso prima di avviare un firmware, è probabile che l'implementazione dell'algoritmo di hashing vada bene. C'è pochissimo feedback per l'attaccante, se diciamo che un valore errato non riceve alcuna risposta.

Tuttavia questo accade raramente in natura poiché esiste già un'implementazione SHA256 in ogni lingua a cui puoi pensare: perché lo copieresti con alcuni nomi di variabili diversi. Quello che succede è che qualcuno decide di essere intelligente o vuole un comportamento diverso, o non capisce le sfumature (come i canali secondari ecc.).

Il pensiero nella comunità sembra essere: meno cowboy è meglio, quindi spaventa tutti. Potrebbe anche essere giusto, ma penso che il consiglio sia più facile da seguire senza fare osservazioni (come non implementare mai le tue) che sembrano troppo zelanti.

Detto questo, è facile dimenticare che mentre sai esattamente quando non capisci la maggior parte delle cose di programmazione perché non funzionano come ti aspetti. Crypto funziona sempre come ti aspetti nel senso 'ha dato la risposta giusta'. Tuttavia, sapere ciò che non sai che altri potrebbero fare sulla crittografia è un compito non banale. Questa è una mentalità con cui le persone hanno difficoltà. Quindi le persone chiedono "perché non posso", non "cosa c'è di sbagliato nella mia prova che posso".

Nel complesso, mi dispiace mantenere la posizione "se devi chiedere: non" è probabilmente per il meglio. Ma questo non significa che il tuo processo di pensiero sia sbagliato. Solo che coloro che danno il consiglio non possono essere veramente sicuri che non lo sia.

Per fortuna SHA-256 è naturalmente resistente al canale laterale.
L'idea che "se nessuno è autorizzato a fare * X * allora, * chi * può fare * X *?"è piuttosto comune in tutte le domande che finiscono come "Non tirare le tue".L'idea della mia risposta non è che non dovresti mai implementare codice crittografico.L'idea è "Se si implementa il codice crittografico, è necessario essere consapevoli di molte più cose rispetto al codice medio" e il comune sviluppatore probabilmente non riuscirà a fornire un buon codice crittografico.
@forest È sarcasmo?Altrimenti, cosa rende SHA-256 naturalmente resistente al canale laterale?
@MechMK1 Non è sarcasmo.SHA-256 è naturalmente resistente al canale laterale perché utilizza aggiunte, rotazioni a distanza fissa e XOR (ovvero, è una funzione _ARX_), che sono tutte operazioni a tempo costante sulla maggior parte dei processori moderni.A differenza, ad esempio, di AES, non utilizza tabelle di ricerca dipendenti dal segreto.Ciò significa che anche un'implementazione ingenua resisterà ai canali secondari, mentre l'implementazione di AES in tempo costante richiede una comprensione dell'architettura della CPU di basso livello.
Lo stesso vale anche per MD4, MD5, SHA-1, il resto della famiglia SHA-2 e RIPEMD160, che sono tutti hash ARX strettamente correlati (i loro progetti derivano tutti da MD4 e lo migliorano in vari modi).Ci sono anche alcuni _ciphers_ che sono naturalmente resistenti ai canali laterali, come ChaCha20.Praticamente qualsiasi funzione ARX pura sarà facile da implementare senza preoccuparsi del comportamento temporale costante.
#9
  0
DrM
2019-05-09 22:36:58 UTC
view on stackexchange narkive permalink

Molto semplicemente, il software di crittografia più vecchio e più diffuso è stato sottoposto a più test (amichevole e ostile) e più analisi.

Inoltre, la storia della crittografia è disseminata di software non funzionante, alcuni dei quali è stato scritto da eminenti crittografi esperti.

Quindi, i codici in cui puoi avere più fiducia, sono molto spesso i codici che esistono da un po 'di tempo.

#10
-1
mckenzm
2019-05-08 04:48:34 UTC
view on stackexchange narkive permalink

Non lo è, e questo sembra essere rivolto ai laici come avvertimento di lasciarlo ai loro migliori.

Se l'implementazione non esiste per la tua lingua, qualcuno dovrà farlo. Non è come se non ci fossero abbastanza casi di test e se sei un professionista ci saranno revisioni tra pari e ulteriori test.

Sì, deve essere corretto, ma se è pubblicato (e precedentemente implementato in altre lingue) dovrebbe essere quasi standard.

Quindi forse non dovresti farlo, ma ovviamente qualcuno deve farlo. Se non viene fatto dovrai chiamare qualcos'altro per coprire il tuo vuoto, il che non è mai desiderabile.

Ovviamente dovrebbe essere scritto in modo che un professionista della sicurezza possa riconoscerlo tramite "impronta digitale" visiva.

Non sono d'accordo con l'idea che le implementazioni crittografiche siano "quasi standard".
Inoltre, beh, in quale linguaggio insolito stai lavorando dove non ci sono librerie crittografiche esistenti?Voglio dire, a meno che tu non stia programmando in Malbolge e abbia bisogno di utilizzare specificamente l'algoritmo di cifratura Camellia, probabilmente non sei su questa barca per cominciare.
Saresti sorpreso.Ho visto alcuni negozi implementare le proprie implementazioni assembler z / OS.Dipende dall'interesse o dalla spesa dallo scaffale.
@Kevin mentre Delphi ha una singola libreria crittografica, è estremamente bacato e il team di sviluppo dietro di esso ha dichiarato che non lo risolverà, pur continuando a venderlo E negare la modifica di esso.
..e nel caso dell'Open Source, in genere c'è il nome di qualcuno, non si è materializzato dal nulla.
#11
-1
Wayne Werner
2019-05-10 02:44:33 UTC
view on stackexchange narkive permalink

Un altro motivo che va di pari passo con molte altre risposte, dal fatto che fare bene la crittografia è difficile”:

Ottenere la crittografia giusta ​​em > è costoso.

Ottenere la crittografia sbagliata è costoso.

Perché implementare correttamente la crittografia è una cosa così difficile da fare che richiede una gran quantità di lavoro, da un prospettiva aziendale è improbabile che abbia senso implementare la propria crittografia.

E quindi si corre il rischio di sbagliare, il che potrebbe includere tutti i tipi di conseguenze negative, comprese multe, cattiva pubblicità e peggio a seconda su ciò che dovresti crittografare.

#12
-12
Jennifer
2019-05-08 16:59:19 UTC
view on stackexchange narkive permalink

Il problema con l'utilizzo di noti algoritmi implementati professionalmente è che tutto ciò che hai per proteggere il messaggio è la chiave. Se Evelyn riesce a trovare (o indovinare) la chiave, il messaggio può essere decodificato.

Prima della seconda guerra mondiale, c'erano due tipi di macchine crittografiche Enigma: una per gli affari e una per i militari. La versione militare, più complicata e robusta dell'altra, era ovviamente introvabile, ma chiunque poteva presentarsi e acquistare la versione business. I crittografi ne hanno preso uno, lo hanno smontato e analizzato e alla fine hanno capito come costruire la propria versione militare. (Questa è stata una delle principali ragioni per cui la Germania ha perso.)

Per una migliore protezione, l'algoritmo DEVE essere tenuto segreto. E non ci sono algoritmi segreti ben noti là fuori.

In teoria, potresti costruire macchine che sono tutte algoritmi e nessuna chiave. Eseguilo semplicemente attraverso la macchina senza bisogno di chiavi e assicurati che Evelyn non riceva mai una copia dell'algoritmo. (Probabilmente non vorrei farlo da solo.)

Per la massima sicurezza, eseguirei il testo in chiaro tramite il mio algoritmo non pubblicato e quindi attraverso uno implementato professionalmente. Questo ovviamente è possibile solo tra un piccolo numero di utenti "solo su invito"; non puoi metterlo su GitHub.

Dovresti evitare che il secondo processo (implementato professionalmente) faccia qualcosa di insicuro se il suo input è già codificato. D'altra parte, molti tentativi di codebreaking funzionano provando ogni tasto possibile e fermandosi quando viene fuori qualcosa che assomiglia a un testo in chiaro. Poiché l'output di questo processo richiede un ulteriore passaggio prima che diventi umanamente leggibile, il processo di codebreaking non saprebbe quando fermarsi.

IANAC, ma non ho mai permesso a qualcosa del genere di fermarmi prima.

"D'altra parte, molti tentativi di codebreaking funzionano provando ogni possibile tasto e fermandosi quando esce qualcosa che assomiglia a un testo non crittografato." Una chiave per rompere Enigma nella seconda guerra mondiale era che così tanti messaggi iniziavano con "Heil Hitler".Non appena ricevi una lettera che non corrisponde, interrompi, incrementa la rotella di codifica e riprova.E una volta ottenuta la chiave completa, puoi decrittografare tutto il resto quel giorno ...
Questo è un consiglio sbagliato e cattivo.Chiunque può inventare un approccio crittografico che loro stessi non possono rompere.Il trucco è inventarne uno che * nessuno * può rompere - e non puoi determinarlo se stai cercando di mantenere segreto il tuo algoritmo.Se non sei un team di criptoanalisti, avresti difficoltà a determinare se il tuo algoritmo homebrew sta aumentando / diminuendo / compromettendo la sicurezza del vero algoritmo a cui stai attaccando.
Inoltre, "Il problema con l'utilizzo di algoritmi ben noti implementati professionalmente è che tutto ciò che hai per proteggere il messaggio è la chiave."- questo non è un * problema *.È una comprensione chiave della sicurezza.Onestamente, se vuoi davvero fermare questo tipo di vettore di attacco (applicazione cieca di uno specifico algoritmo di crittografia), aggiungi semplicemente un Pepper.Previene lo stesso potenziale vettore di attacco, non introduce potenziali vulnerabilità di sicurezza e non richiede l'implementazione di un algoritmo di sicurezza casalingo.
È un po 'difficile mantenerlo segreto se è pubblicato come RFC o in Wikipedia.L'argomento qui è metodi "conosciuti".
-1 ** Stai suggerendo la sicurezza attraverso l'oscurità ** e stai palesemente violando il principio di Kerckhoffs.Non otterrai molto supporto su questo sito con quella posizione ...
Quasi infinitamente pessima idea.Nel tuo scenario, solo una persona che usa il tuo algoritmo deve essere pessimo nel preservarlo e un attaccato ha qualcosa da decodificare banalmente.Quindi l'intera implementazione è discutibile.Ecco perché esiste un principio secondo il quale ogni metodo sicuro di protezione dei dati non può fare affidamento su dettagli di implementazione non conosciuti pubblicamente.
"Per una migliore protezione, l'algoritmo DEVE essere tenuto segreto": scusate, ma questo è completamente sbagliato.Se lo mantieni segreto, non saprai mai se è * veramente * sicuro, o piuttosto ti sembra sicuro, ma può essere infranto da altri.Lo scopo dell'utilizzo di AES, RSA e così via è che hanno resistito agli attacchi dell'intera comunità, rendendo così estremamente improbabile che ci siano alcune vulnerabilità che solo pochi (NSA?) Hanno trovato.Questi algoritmi sono così sicuri che anche far sapere al nemico che li stai usando non dà loro alcun vantaggio.


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