Non utilizzare la tua crittografia!

Da un punto di vista puramente crittografico, qualsiasi funzione biiettiva che preserva la lunghezza non può ridurre la sicurezza. In effetti, anche la funzione di identità, definita come f (x) = x , non ridurrà la sicurezza, assumendo che le chiavi utilizzate per la cifratura standard e la tua cifratura homebrew siano reciprocamente indipendente. L'unico modo possibile per ridurre la sicurezza è se la tua funzione homebrew non usa una chiave diversa e indipendente e perde la chiave nel testo cifrato, ad esempio con f _{k sub > (x) = x ⊕ k} fatto su ogni singolo blocco di input x , un classico cifrario XOR vulnerabile agli attacchi di testo in chiaro noto.

Da un punto di vista pratico , ci sono trucchi che possono essere importanti. Ho menzionato la conservazione della lunghezza sopra per una buona ragione. Una funzione di compressione è ancora una funzione e talvolta la compressione e la crittografia possono portare a risultati molto negativi. Questo è in parte il motivo per cui il tuo secondo esempio, con il tuo algoritmo personalizzato applicato prima della crittografia standard, è davvero peggiore. Può far trapelare informazioni sul testo in chiaro per tutta la lunghezza. Possono anche esserci bug nella tua implementazione che provocano altre vulnerabilità di sicurezza. Da un punto di vista puramente teorico, sono fuori campo.

In un commento mi è stato fatto notare che potrei non enfatizzare a sufficienza quanto sia pessima questa idea è. Sebbene possa andare bene in teoria, il mondo reale funziona in modo diverso. In realtà usare la tua crittografia homebrew è una pessima idea , indipendentemente da come la usi. L'unica volta in cui dovresti farlo davvero è se sei un crittografo professionista. Bernstein può farlo. Rivest può farlo. Rijmen può farlo. Non puoi. Non spararti sui piedi e utilizza invece algoritmi adeguati.

Esiste un rischio quando applichi prima il tuo algoritmo di crittografia personalizzato.
Questo si basa sul fatto che una crittografia come AES fa trapelare informazioni sulla lunghezza del testo in chiaro.

Supponi l'esempio estremamente ipotetico (e poco pratico) in cui l'algoritmo personalizzato "crittografa" un testo in chiaro a byte singolo come 0x40 in 64 zeri e un testo in chiaro a due byte come 0x02 0x00 in 512 zeri.

Quando crittografate utilizzando AES, un utente malintenzionato conoscerà ancora la lunghezza del risultato crittografato personalizzato semplicemente osservando la lunghezza del testo crittografato AES.
Con queste informazioni, l'autore dell'attacco può "decrittografarlo" nel testo in chiaro originale senza avere l'AES chiave di crittografia.

In sintesi: un algoritmo personalizzato pessimo può effettivamente danneggiare la sicurezza di una crittografia AES successiva.

La prima domanda da porsi quando si valuta qualsiasi tipo di sistema di sicurezza è "Chi è l'attaccante e cosa può fare?" Nella fascia bassa, sei contro un utente malintenzionato che può semplicemente vedere l'output crittografato di uno dei tuoi messaggi. Nella fascia alta ti trovi di fronte a un utente malintenzionato che conosce le coppie di testo in chiaro e cifrato di centinaia di altri messaggi, che può costringere il tuo computer a crittografare altri messaggi con la stessa chiave, chi può monitorare le linee elettriche del tuo edificio e misurare le minime variazioni dell'assorbimento di corrente durante il processo di crittografia e tutti i tipi di attacchi simili. Gli algoritmi di crittografia standard sono controllati per assicurarsi che resistano anche a questi potenti avversari.

Se usi prima la tua crittografia, anche se il secondo livello è la crittografia di livello militare, rischi di diminuire la tua sicurezza rispetto al semplice utilizzo della crittografia standard.

Ad esempio, supponi di crittografare il testo. In primo luogo si utilizza un semplice cifrario di sostituzione e quindi si utilizza l'algoritmo di selezione pesante. Sfortunatamente, i cifrari di sostituzione dipendono intrinsecamente dall'esecuzione di ricerche di array da informazioni private (cioè il tuo testo in chiaro e la tua chiave). Questo li rende vulnerabili agli attacchi temporali: a causa del modo in cui funzionano le cache della CPU se due lettere nel testo in chiaro sono vicine tra loro, probabilmente verranno crittografate più velocemente di due lettere che sono più separate. Non sembrano molte informazioni, ma se un utente malintenzionato può guardare un numero sufficiente di crittografie, può potenzialmente capire quale sia il testo in chiaro senza dover decifrare AES o qualsiasi cosa tu stia utilizzando in cima.

Se il tuo livello di crittografia personalizzato non interagisce affatto con informazioni segrete: cioè funziona con dati che sono già stati crittografati in modo sufficientemente sicuro per la trasmissione e non toccano le chiavi della crittografia standard, allora potrebbe essere sicuro. Almeno, non sarà possibile aggirare la crittografia standard. Ci sono ancora dei rischi, tuttavia, perché ogni software aggiuntivo comporta rischi aggiuntivi. Forse un bug nel tuo livello personalizzato consente a un avversario remoto di eseguire comandi arbitrari sulla tua macchina; quindi potrebbero semplicemente inviare via email a se stessi il testo in chiaro!

Il messaggio da portare a casa, quindi, è che avere un pezzo di codice di sicurezza eccellente che è ben controllato e privo di bug come una funzione di crittografia standard può ancora essere compromesso se tu mettere un programma sviluppato in casa con bug (di qualsiasi tipo, crittografia o altro) sullo stesso sistema.

Semplice. Non farlo.

Prima di tutto, gli algoritmi di crittografia sono progettati in modo che tu, io e tutti coloro che ci circondano possiamo guardarli e provare a romperli. Puoi letteralmente guardare i conti per AES. Molte persone intelligenti hanno investito tempo nella convalida dell'AES. Questo è un principio di buona crittografia e perché possiamo fidarci di esso.

Secondo, l'oscurità non è mai un'opzione di "sicurezza". Non fornisce alcun vantaggio. Se ci credi davvero, allora ti rimando alla "Legge di Schneier".

Chiunque può inventare un sistema di sicurezza che lui stesso non può violare. L'ho detto così spesso che Cory Doctorow l'ha chiamato "Legge di Schneier": Quando qualcuno ti consegna un sistema di sicurezza e dice: "Credo che questo sia sicuro", la prima cosa che devi chiedere è: "Chi diavolo sono tu?" Fammi vedere cosa hai rotto per dimostrare che la tua affermazione sulla sicurezza del sistema significa qualcosa. - Bruce Schneier, 2016

Tutto quello che hai fatto è:

• Introdurre rischi non necessari nella tua applicazione
• Tempo di debug aumentato per problemi
• Tempo di CPU aggiunto per una funzione inutile

Il principale di base della sicurezza. Keep It Simple Stupid (KISS).

La sicurezza tramite oscurità è buona, a volte anche ottima , a patto che non sia l'unico livello di sicurezza su cui fai affidamento. Ma nel tuo caso temo che non ne valga la pena.

Prendi GPG per esempio. Se utilizzi GPG per crittografare un file con AES, avrà un'intestazione che consente a un utente malintenzionato di riconoscerlo come file GPG crittografato con AES. Se poi utilizzi la crittografia personalizzata per crittografare il file GPG, otterrai un file che potrebbe essere irriconoscibile. Un utente malintenzionato potrebbe erroneamente supporre che tu stia utilizzando qualsiasi tipo di crittografia (e perdere molto tempo per niente), o potrebbe supporre che tu stia utilizzando la tua crittografia personalizzata e quindi decidere di utilizzare tecniche di crittoanalisi per analizzare il tuo file (e riuscire a decrittografarlo se è abbastanza bravo o il tuo algoritmo fa schifo abbastanza). D'altra parte, se lo fai al contrario (prima crittografa con algoritmo personalizzato e poi con AES), lo scenario non cambia in modo significativo, dopotutto.

Detto questo, temo che non ne valga la pena perché la crittografia personalizzata ha comunque un enorme con : dovrai archiviare il tuo software di crittografia da qualche parte e il tuo software è totalmente personalizzato, il che significa che se per qualsiasi motivo lo perdi (backup smarriti o rubati, ecc.) sei fregato e non sarai in grado di recuperare nessuno dei tuoi dati.

Una soluzione migliore potrebbe essere quella di utilizzare diversi livelli di crittografia utilizzando algoritmi già noti e disponibili. Ad esempio GPG sembra supportare twofish, camellia, ecc. Non ho esperienza per sapere quali algoritmi dovrebbero essere considerati i più sicuri, a parte AES. Ad ogni modo, solo per fare un esempio, AES -> TWOFISH -> CAMELLIA è probabilmente una soluzione molto migliore del tuo AES -> CUSTOM_ALGO. Ovviamente a patto di utilizzare password complesse diverse per ogni livello di crittografia!

OPSEC?...

Mettere ulteriori barriere tra le informazioni critiche e un avversario è una buona idea in generale, a condizione che sia fatto in modo efficace .

L'oscurità come misura di sicurezza significativa è affrontata dal principio OPSEC (sicurezza operativa). In breve, ciò comporta privare un avversario di qualsiasi informazione che potrebbe aiutarlo a compromettere la tua organizzazione tramite metodi sociali o tecnici.

Con una buona crittografia, tuttavia, mantenere le chiavi segrete è sufficiente per proteggere i tuoi dati. Eventuali livelli tecnici aggiuntivi devono essere giustificati in base ai propri meriti tecnici.

... O fallire

La crittografia è una disciplina matematica molto complicata e piccoli errori può avere enormi conseguenze. Quando si ha a che fare con la crittografia, si supponga che il valore di un algoritmo sia virtualmente zero a meno che un esperto affidabile non indichi diversamente.

Negli Stati Uniti, la NSA e il NIST sono i valutatori ufficiali degli algoritmi crittografici e implementazioni, rispettivamente. Se non sai dove cercare opinioni o desideri una base ragionevole per le politiche interne, inizia da lì.

In pratica, avvolgere una buona crittografia è inutile. Una volta che un utente malintenzionato incontra buona crittografia, generalmente ruotano e attaccano gli endpoint in cui sono esposti i dati non crittografati.

Questo potrebbe essere il server Web in cui gli utenti forniscono le informazioni, il sistema SCADA che alimenta il database o le workstation in cui i dipendenti analizzano o monitorare le informazioni. Se si dispone di un data pump che estrae le informazioni da un database e le converte in un altro formato per la consegna a un fornitore / cliente, questo è un altro grande obiettivo. In alternativa, potrebbero cercare le tue chiavi.

A conti fatti

L'aggiunta di funzionalità a un'applicazione ha una possibilità diversa da zero di introdurre bug e complicare la risoluzione dei problemi. Ciò può comportare tempi di inattività prolungati quando qualcosa va storto o risposte più lente alle vulnerabilità della sicurezza nell'applicazione. A causa di questi fattori, una funzione di sicurezza di valore minimo o nullo è un danno piuttosto che un miglioramento.

Se desideri proteggerti da un potenziale attacco ad AES, allora dovresti semplicemente usare un altro standard crittografico basato su un algoritmo controllato piuttosto che svilupparne uno tuo. Otterrai una maggiore sicurezza con meno sforzo.

Ci sono due problemi principali con la modalità sicurezza e oscurità.

1. L'oscurità può interferire con la sicurezza. Se lanci la tua crittografia, è molto probabile che sia difettosa. Anche i migliori sistemi hanno dei difetti, nonostante i massimi esperti ci abbiano lavorato per decenni. Le possibilità che tu sia in grado di fare meglio della comunità della sicurezza sono basse.

2. Poche cose sono davvero oscure. Non ci sono molte nuove idee in criptovaluta e qualunque cosa tu faccia è probabile che sia una variazione di qualcosa che è stato fatto prima, quindi in realtà non è così oscuro. Le modifiche minori sono qualcosa a cui gli aggressori sono abituati.

È facile vedere che la prima variante (algoritmo personalizzato per ultimo) non può compromettere la sicurezza di una crittografia ben nota, poiché se potesse, sarebbe un metodo per violare la crittografia ben nota. Dopo tutto, gli aggressori potrebbero anche eseguire l'algoritmo personalizzato su un testo cifrato crittografato esclusivamente con la ben nota crittografia se li aiutasse a decifrarlo.

L'altra direzione (prima l'algoritmo personalizzato) potrebbe effettivamente compromettere la sicurezza del ben noto algoritmo introducendo ridondanza nell'input di testo in chiaro della nota crittografia, che potrebbe potenzialmente indebolire quell'algoritmo.

Ad esempio, prendi il seguente schema di "crittografia" personalizzato completamente difettoso: ripeti il ​​testo in chiaro di input due volte per produrre un "cyphertext". Ciò porta ad una quantità estrema di ridondanza aggiuntiva nell'input del secondo algoritmo, che potrebbe indebolire alcune crittografie reali. (Se indebolisce o meno AES è una questione diversa.) Ciò è effettivamente accaduto con Enigma, in cui gli operatori ripetevano una sequenza di tre lettere nel suo testo in chiaro che rendeva il suo testo cifrato vulnerabile a certi tipi di attacchi. Citando dalla Cryptanalysis of the Enigma Wikipedia page:

Il secondo problema era la ripetizione della chiave del messaggio all'interno dell'indicatore, che era un grave difetto di sicurezza. L'impostazione del messaggio è stata codificata due volte, risultando in una relazione tra il primo e il quarto, il secondo e il quinto e il terzo e il sesto carattere. Questo problema di sicurezza permise al Polish Cipher Bureau di entrare nel sistema Enigma prebellico già nel 1932. Il 1 ° maggio 1940 i tedeschi cambiarono le procedure per cifrare la chiave del messaggio una sola volta.

La soluzione 1 potrebbe potenzialmente ridurre la sicurezza se utilizzi la stessa chiave segreta per crittografare AES e CustomEncryptionAlgorithm.

CustomEncryptionAlgorithm potrebbe consentire la deduzione della chiave segreta e quindi compromettere anche AES.

Se crei una chiave univoca per CustomEncryptionAlgorithm dovresti stare di nuovo bene.

Qualcosa come KEY = SHA-2 (AES-CipherText)

Il problema è che è possibile che la tua funzione di crittografia personalizzata abbia un bug e in qualche modo riduca la sicurezza. L'unico modo per assicurarti che il tuo CustomEncryptionAlgorithm non stia riducendo la tua sicurezza è avere ricercatori più intelligenti di te, me e il resto del tuo team uniti per versarci sopra e controllare il tuo lavoro. Ma poi non è affatto oscuro.

Per fare un esempio estremo:

  public string CustomEncryptionAlgorithm (string plaintext) {var ciphertext = plaintext.shuffle ( ); restituire "password"; testo cifrato di ritorno; // ya ya. Lo so. Non renderesti mai un bug così ovvio. // dillo al tizio che ha eseguito il "goto bug" su apple}  

Otterresti qualcosa del genere come risultato se usassi questo schema:

• AES -> CipherText -> CustomEncryptionAlgorithm-> CipherText:

    'abcABC123! @ #' -> 'password''correct_horse_staple_battery' -> 'password''password' -> 'password'  

D'altra parte, se hai usato l'altro schema:

• CustomEncryptionAlgorithm -> CipherText -> AES -> CipherText

    'abcABC123! @ #' -> '8ZnO44trPK48kqr3rDxkdQ ==' 'correct_horse_staple_battery' -> '8ZnO44trPK48kqr3rDxkdQ ==' 'correct_horse_staple_battery' -> '8ZnOqriliPassword' 8ZnOqr3rDxkdQ = ' 

Leggermente meglio, forse. Ma ancora non per niente buono.

Come è stato detto: Chi è l'attaccante?

Questo è davvero ciò che devi prima scoprire e definire!

È tua nonna tecnofobica che ha problemi con il telecomando della TV? La tua sorellina (e molto ficcanaso)? Tuo padre, che in realtà programma e amministra i computer e sa come rimuovere un disco rigido? Il bullo della scuola locale che ti ha fregato? Crimine organizzato? Un'azienda che può spendere milioni per noleggiare computer cloud per un attacco violento? Un dittatore del terzo mondo? FBI, NSA o agenzie equivalenti nel tuo paese? Qualche potenza mondiale che ha un eccellente servizio di spionaggio e non si preoccuperà dei sacchi per il corpo per prenderti?

Secondo: quale sicurezza extra reale ti darebbe la tua "crittografia" 1 contro la tua aggressori? A meno che tu non riesca a spiegare bene perché la crittografia di nuovo il testo cifrato è necessaria o molto utile, non dovresti farlo. Più complessità non significa più sicurezza, significa più bug e più possibilità che le cose non funzionino correttamente?

E perché gli aggressori non si introducono o si intrufolano in casa tua e posizionano un software spia o un key logger il tuo computer? Sei sicuro che la tua crittografia sarà di aiuto contro la crittoanalisi dei tubi di gomma [3] o, se non ce n'è alcuna possibilità, chi è abbastanza potente da rompere AES ma non è in grado di raggiungere te o il tuo caro e più vicino?

1. Diciamo solo che la tua possibilità di ottenere la crittografia forte e sicura è più o meno alta quanto la mia possibilità di camminare sulla luna; con crittografia, non solo tutto deve funzionare con la chiave giusta, ma niente può funzionare senza di essa ...

   Non conosco nessun sistema crittografico costruito da qualcuno al di fuori del campo che non si sia rotto quando è stato controllato da esperti, e quanti potenti sistemi di crittografia inventati dai migliori esperti sono stati violati?

2. Un esempio potrebbe essere la comunicazione nella seconda guerra mondiale dalla Germania ai sottomarini. Alcune comunicazioni molto segrete erano "solo ufficiali", il che era crittografate, le meta-informazioni sono state anteposte ed entrambe sono state quindi crittografate dalla chiave normale e inviate. Alla ricezione della radio / l'operatore Enigma decrittografava il messaggio e passava le meta informazioni e il blocco ancora criptato all'ufficiale. ( vedi qui per esempio)

3. "in cui un tubo di gomma viene applicato con forza e frequentemente alle suole dei piedi finché non viene scoperta la chiave del criptosistema , un processo che può richiedere un tempo sorprendentemente breve ed è piuttosto economico dal punto di vista computazionale. "

Risposta breve: può essere, ma non nel tuo esempio.

Risposta lunga: altre risposte hanno adeguatamente coperto il motivo per cui il tuo esempio non è così utile e può far male. Detto questo, l'oscurità può essere molto utile. Caso in questione: non mettere SSH sulla porta 22. Se cambi da 22 a 2222, avrai una piccola frazione dei tentativi di forza bruta che faresti altrimenti. Se passi alla porta 10000+ rand (1,55535) probabilmente scompariranno completamente. Un altro esempio è il port knocking. Fondamentalmente, l'oscurità è per lo più utile nel processo di connessione, non nella crittografia o nelle password.

È pessimo, pessimo , pessimo”.

C'è un aneddoto tratto da un protocollo mobile dell'Estremo Oriente per l'inizializzazione della SIM o qualcosa di simile, quello utilizzato una combinazione di RSA (buono, sicuro e forte) e qualcosa di fatto in casa.

Il punto debole decisivo non era solo la crittografia "aggiuntiva" casalinga. Ma il problema era che in realtà c'era un caso speciale in cui il metodo aggiuntivo era associativo con RSA, che causava il sanguinamento parziale delle chiavi. Non ricordo i dettagli, come mi è stato detto loro come aneddoto di una lezione molti anni fa.

Ma il punto è: con un'aggiunta homebrew impropria a un protocollo altrimenti sicuro potresti creare il protocollo più debole della sua versione originale. Quindi, questo è un grosso problema.

Ti riferisci al secondo algoritmo come oscurità, quindi sembri presumere che non aggiunga alcuna sicurezza.

Se effettivamente non aggiunge sicurezza, perché usarlo? Usa la seconda password oltre alla prima per la crittografia aes. Una password lunga il doppio è molto più sicura di due password (esempio: 2 ^ 2 + 2 ^ 2 = 4 vs. 2 ^ 4 = 16 ), specialmente quando il il secondo algoritmo è comunque insicuro.

Se fatto correttamente: certo. La domanda è: come fai a sapere che è corretto? Certamente puoi scrivere qualcosa che trapeli informazioni attraverso vari livelli. Quello più ovvio è la lunghezza e le ripetizioni. Anche l'utilizzo della stessa chiave potrebbe essere problematico.

È semplicemente troppo difficile dire cosa è corretto e cosa no. Certo, potresti sostenere che usare ROT13 prima di AES lo rende un po 'sicuro e la mia intuizione direbbe ... beh, almeno non può far male, ma in realtà non lo so.

La mia intuizione direbbe che se applichi un algoritmo che produce un output indistinguibile dalla casualità senza cambiare la lunghezza e poi applichi AES, almeno non dovrebbe ridurre la sicurezza di AES.

L'oscurità fa parte di una sicurezza (generale) ed è ortogonale alla sicurezza (crittografia AES nel tuo caso). L'oscurità difende da minacce diverse dalle criptovalute. Prendiamo ad esempio le password: gli hash crittografici sono necessari per impedire la fuoriuscita di testo in chiaro dal server, TLS impedisce di intercettare il traffico di rete, mentre l'oscurità essendo un modulo di password riempito con [*******] impedisce di sbirciare il testo in chiaro da uno spettatore casuale. Quindi non puoi creare sicurezza per (solo) oscurità, ma la sicurezza con oscurità è solitamente la strada da percorrere. Nel mondo reale l'oscurità significa nascondere i metadati, ad es. invio di messaggi di posta elettronica con BCC anziché CC / A o blocco dei cookie di terze parti.