La sicurezza dell'oscurità è orribile. La sicurezza e l'oscurità sono buone?

Non eseguire il crypto!

Da un punto di vista crittografico puramente , qualsiasi funzione biettiva di preservazione della lunghezza non può ridurre la sicurezza. Infatti, anche la funzione di identità , definita come f (x) = x , non ridurre la sicurezza, assumendo che le chiavi utilizzate per il codice standard e il codice homebrew siano reciprocamente indipendenti. L'unico modo possibile per ridurre la sicurezza è se la funzione homebrew non utilizza una chiave diversa e indipendente e perde la chiave nel testo cifrato, ad esempio con f _k (x) = x ⊕ k fatto su ogni singolo blocco di input x , una classica crittografia XOR vulnerabile agli attacchi di testo normale.

Da un punto di vista pratico, ci sono dei trucchi che possono avere importanza. Ho menzionato la preservazione 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 pessimi . Questo è in parte il motivo per cui il tuo secondo esempio, con l'algoritmo personalizzato applicato prima della crittografia standard, è effettivamente peggiore. Può perdere informazioni sul testo in chiaro attraverso la lunghezza. Ci possono anche essere bug nella tua implementazione che si traducono in altre vulnerabilità della sicurezza. Da un punto di vista puramente teorico, sono fuori ambito.

Mi è stato fatto notare in un commento che forse non sto enfatizzando sufficientemente quanto sia pessima questa idea. Mentre in teoria può andare bene, il mondo reale funziona diversamente. In realtà usare la tua crittografia homebrew è una idea molto brutta , indipendentemente da come la usi. L'unica volta in cui dovresti farlo effettivamente è se sei un crittografo professionista. Bernstein può farlo. Rivest può farlo. Rijmen può farlo. Non puoi. Non spararti ai piedi e usa invece algoritmi appropriati.

C'è un rischio quando si applica prima l'algoritmo di crittografia personalizzato.
Questo si basa sul fatto che una crittografia come AES perde informazioni sulla lunghezza del testo in chiaro.

Supponiamo l'esempio estremamente ipotetico (e non 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 lo 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'hacker può "decrittografarlo" nel testo in chiaro originale senza la chiave di crittografia AES.

In breve: un algoritmo molto pessimo può davvero danneggiare la sicurezza di una successiva crittografia AES.

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

Se per prima cosa utilizzi la tua crittografia, anche se il secondo livello è una crittografia di livello militare, rischi di ridurre la sicurezza rispetto all'uso della crittografia standard.

Ad esempio, supponi di crittografare il testo. Per prima cosa usi una semplice cifra sostitutiva e poi usa la tua scelta dell'algoritmo pesante. Sfortunatamente, i codici di sostituzione sono intrinsecamente dipendenti dalla ricerca di array da informazioni private (ad esempio il testo in chiaro e la chiave). Ciò li rende vulnerabili agli attacchi temporali: a causa del modo in cui le cache della CPU funzionano se due lettere nel testo in chiaro sono vicine, probabilmente crittografano più velocemente di due lettere che sono ulteriormente disponibili. Questo non sembra una gran quantità di informazioni, ma se un utente malintenzionato può vedere un numero sufficiente di crittografie, può potenzialmente capire che il testo in chiaro è senza che deve craccare AES o qualsiasi altra cosa tu stia utilizzando.

Se il 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, quindi potrebbe essere sicuro. Almeno, non sarà possibile bypassare la crittografia standard. Ci sono ancora dei rischi, però, perché ogni ulteriore porzione di software comporta rischi aggiuntivi. Forse un bug nel tuo livello personalizzato consente ad un avversario remoto di eseguire comandi arbitrari sulla tua macchina; allora potrebbero semplicemente inviare loro stessi il testo in chiaro!

Il messaggio da portare a casa, quindi, è che avere un grumo di codice di sicurezza eccellente che è ben controllato e privo di bug come una funzione di crittografia standard può ancora essere compromessa se si inserisce un programma autocostruito (di qualsiasi tipo, crittografia o altrimenti) sullo stesso sistema.

Semplice. Non farlo.

Innanzitutto, gli algoritmi di crittografia sono progettati in modo tale che tu, io e tutti quelli che ci circondano possiamo guardarlo e cercare di romperlo. Puoi letteralmente guardare ai calcoli per AES . Un sacco di persone intelligenti hanno investito tempo nella convalida di AES. Questo è un principio di buona crittografia e perché possiamo fidarci di esso.

Secondo, l'Obscurity non è mai un'opzione di "Sicurezza". Non fornisce alcun vantaggio. Se ci credi davvero, allora ti rimando a "Legge di Schneier" .

Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something. - Bruce Schneier, 2016

Tutto ciò che hai fatto è:

• Introduci rischi inutili nell'applicazione
• Tempo di debug aumentato per problemi
• Aggiunto tempo CPU per una funzione senza valore

Il principio fondamentale in Sicurezza. Keep It Simple Stupid (KISS).

La sicurezza per oscurità è buona, a volte anche grande , purché non sia l'unico livello di sicurezza su cui ti basi. Ma nel tuo caso temo che non ne valga la pena.

Ad esempio, prendi GPG. Se si utilizza 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 utilizzi quindi la crittografia personalizzata per crittografare il file GPG, otterrai un file che potrebbe essere irriconoscibile. Un utente malintenzionato potrebbe erroneamente supporre di utilizzare qualsiasi tipo di crittografia (e perdere molto tempo per niente), o potrebbe supporre di utilizzare la crittografia personalizzata e quindi decidere di utilizzare le tecniche di crittanalisi per analizzare il file (e riuscire a decrittografarlo se è abbastanza bravo o il tuo algoritmo fa schifo abbastanza). D'altra parte, se lo fai al contrario (prima criptare con algoritmo personalizzato e poi con AES), lo scenario non cambia in modo significativo dopo tutto.

Detto questo, temo che non ne valga la pena perché la crittografia personalizzata ha un enorme con comunque: 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 persi o rubati, ecc.), sei fregato e non sarai in grado di recuperare nessuno dei tuoi dati.

Una soluzione migliore potrebbe essere l'utilizzo di diversi livelli di crittografia utilizzando algoritmi già noti e disponibili. Ad esempio, GPG sembra supportare twofish, camelia, ecc. Non ho esperienza per sapere quali algoritmi dovrebbero essere considerati i più sicuri sebbene, a parte AES. Ad ogni modo, proprio come un esempio, AES - > TWOFISH - > CAMELLIA è probabilmente una soluzione molto migliore che il tuo AES - > CUSTOM_ALGO. Ovviamente a condizione di utilizzare password forti diverse per ogni livello di crittografia!

OPSEC? ...

Mettere ulteriori barriere tra le informazioni critiche e un avversario è una buona idea in generale, purché sia fatto efficacemente .

L'oscurità come misura di sicurezza significativa è affrontata dal principio di OPSEC (sicurezza operativa). In breve, ciò comporta la privazione di un avversario di qualsiasi informazione che potrebbe aiutarli 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 busto

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

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

In pratica, il wrapping della buona crittografia è inutile. Una volta che un utente malintenzionato incontra una buona crittografia, generalmente pivot e attacca gli endpoint in cui vengono esposti i dati non crittografati.

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

Sul saldo

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

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

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

1. L'oscurità può interferire con la sicurezza. Se arrotoli la tua cripto, è molto probabile che sia difettosa. Anche i migliori sistemi hanno difetti, nonostante i maggiori esperti abbiano lavorato su di loro per decenni. Le possibilità che tu possa fare meglio della comunità di sicurezza sono basse.

2. Poche cose sono davvero oscure. Non ci sono molte nuove idee in crittografia e qualsiasi cosa tu faccia è probabilmente una variazione su qualcosa che è stato fatto prima, quindi in realtà non è così oscuro. Le modifiche minori sono qualcosa che gli aggressori sono abituati a gestire.

È facile vedere che la prima variante (l'ultimo algoritmo personalizzato) non può compromettere la sicurezza di una crittografia ben nota, poiché se fosse possibile, sarebbe un metodo per decifrare la ben nota crittografia. Dopotutto, gli autori di attacchi potrebbero anche eseguire l'algoritmo personalizzato su un testo cifrato crittografato esclusivamente con la ben nota crittografia se fosse stato utile per craccarlo.

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

Ad esempio, prendi il seguente schema di "crittografia" personalizzato completamente imperfetto: ripeti il testo in chiaro due volte per produrre un "testo cifrato". Ciò porta a una quantità estrema di ridondanza aggiunta nell'input del secondo algoritmo, che potrebbe indebolire alcune crittografie reali. (Indipendentemente dal fatto che indebolisca AES o meno è una domanda diversa). Questo è effettivamente accaduto con Enigma , dove gli operatori hanno ripetuto tre -la sequenza di lettere nel suo testo in chiaro che ha reso il suo criptato vulnerabile a certi tipi di attacchi. Citando da Cryptanalysis della pagina Wikipedia di Enigma :

The second problem was the repetition of message key within the indicator, which was a serious security flaw. The message setting was encoded twice, resulting in a relation between first and fourth, second and fifth, and third and sixth character. This security problem enabled the Polish Cipher Bureau to break into the pre-war Enigma system as early as 1932. On 1 May 1940 the Germans changed the procedures to encipher the message key only once.

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

CustomEncryptionAlgorithm potrebbe consentire la deduzione della chiave segreta e quindi anche compromettere 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 funzione di crittografia personalizzata abbia un bug e in qualche modo riduca la sicurezza. L'unico modo per assicurarti che il tuo CustomEncryptionAlgorithm non riduca la tua sicurezza è di avere ricercatori più intelligenti di te, io e il resto del tuo team messi insieme per riversarlo e controllare il tuo lavoro. Ma poi non è assolutamente oscuro.

Per fare un esempio estremo:

public string CustomEncryptionAlgorithm(string plaintext) {
    var ciphertext = plaintext.shuffle();
    return "password";
    return ciphertext; // ya ya. I know. You'd never make a bug that obvious.
                       // tell it to the guy who did the 'goto bug' at apple
}

Ne conseguirebbe qualcosa del genere se usassi questo schema:

• AES - > CipherText - > CustomEncryptionAlgorithm- > testo cifrato :

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

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

• CustomEncryptionAlgorithm - > CipherText - > AES - > Testo cifrato

  'abcABC123!@#' -> '8ZnO44trPK48kqr3rDxkdQ=='
  'correct_horse_staple_battery' -> '8ZnO44trPK48kqr3rDxkdQ=='
  'password' -> '8ZnO44trPK48kqr3rDxkdQ=='
  

Leggermente migliore, forse. Ma ancora non c'è nulla di buono.

Come è stato detto: Chi è l'attaccante?

Questo è davvero ciò che devi scoprire e definire per primo!

È la tua nonna tecnofobica che ha problemi con il telecomando della TV? La tua piccola (e molto ficcanaso) sorella? Tuo padre, che in realtà programma e gestisce i computer --- e sa come rimuovere un disco rigido? Il bullo della scuola locale che ti lavora? Crimine organizzato? Una società che può spendere milioni per noleggiare un cloud computer per un attacco di cracking? 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 ti dispiacerà prendere in consegna sacchi per il corpo?

Secondo: quale extra, vera sicurezza sarebbe la tua 'crittografia' 1 ti darà contro i tuoi attaccanti? A meno che tu non sia in grado di fare un buon esempio perché la crittografia del testo cifrato di nuovo [2] sia 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 attaccanti non si rompono o si intrufolano nella tua casa e mettono sul computer un software spia o un keylogger? Sei sicuro che la tua crittografia sarà di qualche aiuto contro la cryptoanalysis del tubo di gomma [3], o se non c'è possibilità di farlo, chi è abbastanza potente da rompere AES ma non è in grado di raggiungere te o il tuo più caro e più vicino?

1. Diciamo la tua possibilità di ottenere la crittografia strong e sicuro è alto 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 esso ...

   Non conosco alcun sistema di crittografia costruito da qualcuno al di fuori del campo che non si incrina quando viene controllato da esperti e quanti sono forti i sistemi di crittografia inventati dai migliori esperti sono stati infranti?

2. Un esempio potrebbe essere la comunicazione della seconda guerra mondiale dalla Germania al sottomarini. Qualche comunicazione molto segreta era "solo ufficiale", che era crittografato, la metadata è stata anteposta e entrambe sono state quindi crittografate da la chiave normale e inviata. Alla ricezione della radio / l'operatore Enigma lo farebbe decifrare il messaggio e passare la meta informazione e ancora criptato blocco per l'ufficiale. ( vedi qui per esempio )

3. "in cui un tubo di gomma viene applicato con forza e frequentemente al suole dei piedi fino a quando la chiave per il cryptosystem è scoperto, un processo che può richiedere un tempo sorprendentemente breve ed è abbastanza computazionalmente economico. "

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. Esempio: 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 si passa alla porta 10000 + rand(1,55535) , è probabile che scompaiano completamente. Un altro esempio è il bussare alla porta. Fondamentalmente, l'oscurità è utile soprattutto nel processo di connessione, non nella crittografia o nelle password.

Ti riferisci al secondo algoritmo come oscurità, quindi sembra che tu pensi che non aggiunga alcuna sicurezza.

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

Se fatto correttamente: sicuro. La domanda è: come sai che è corretto? È certamente possibile scrivere qualcosa che trapelare informazioni attraverso vari livelli. La più ovvia è la lunghezza e le ripetizioni. Anche l'uso della stessa chiave potrebbe essere problematico.

È troppo difficile dire cosa è giusto e cosa no. Certo, potresti obiettare che usare il ROT13 prima che AES lo renda un po 'sicuro e il mio intuito direbbe ... beh, almeno non può far male, ma in realtà non lo so.

La mia intuizione direbbe che se si applica un algoritmo che produce un output indistinguibile dalla casualità senza cambiare la lunghezza e quindi si applica AES, ciò non dovrebbe ridurre la sicurezza di AES.

L'oscurità fa parte di una sicurezza (generale), ed è ortogonale a la sicurezza (crittografia AES nel tuo caso). L'oscurità difende da diverse minacce rispetto alla crittografia. Ad esempio, le password sono crittografate per impedire la fuoriuscita di dati dal server, TLS impedisce il traffico di rete intercettatore, mentre l'oscurità essendo una forma di password che riempie con [*******] impedisce di sbirciare il testo in chiaro dallo spettatore casuale. Quindi non puoi fare sicurezza di obscurity (solo), ma la sicurezza con oscurità è di solito la strada da percorrere. Nel mondo reale l'oscurità significa nascondere i metadati, ad es. spedire con BCC invece di CC / To o bloccare i cookie di terze parti.

È brutto, cattivo , cattivo .

C'è un aneddoto da qualche protocollo mobile dell'Estremo Oriente per l'inizializzazione della SIM o qualcosa di simile, che utilizzava una combinazione di RSA (buono, sicuro e strong) e qualcosa di homebrewed.

La debolezza decisiva non era solo la crittografia "aggiuntiva" homebrewed. Ma il problema era che in effetti c'era un caso speciale quando il metodo aggiuntivo era associativo con RSA, che causava un sanguinamento parziale delle chiavi. Non ricordo i dettagli, come mi è stato detto loro come un aneddoto delle lezioni molti anni fa.

Ma il punto è valido: con un'aggiunta homebrew impropria a un protocollo altrimenti sicuro potreste rendere il più debole del protocollo rispetto alla sua versione originale. Quindi, questo è un no importante.