Doppia crittografia con algoritmo di preparazione a casa

Principio di Kerckhoffs afferma:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Quindi se AES è rotto, probabilmente il tuo algoritmo homebrew sarà molto più semplice e sarebbe già stato rotto.

Mi rendo conto che una parte della tua domanda originale ha dichiarato:

provided they do not have the algorithm

Tuttavia, poiché questo viola il principio di Kerckhoffs, il tuo approccio alla produzione casalinga è di per sé imperfetto e insicuro.

Il motivo principale per cui questo è un problema è che non è quantificabile la sicurezza che aggiunge al tuo sistema. Ti rimando alla risposta di Thomas Pornin a una domanda simile qui :

An additional twist is that algorithm obscurity can harm security. What I explain above is that obscurity cannot be trusted for security: it might increase security, but not by much (and you cannot really know "how much"). It turns out that it can also decrease security. The problem is the following: it is very hard to make a secure cryptographic algorithm. The only known method is to publish the algorithm and wait for the collective wisdom of cryptographers around the world to gnaw at it and reach a conclusion which can be expressed as either "can be broken that way" or "apparently robust". An algorithm is declared "good" only if it resisted the onslaught of dozens or hundreds of competent cryptographers for at least three or four years.

Quindi, dovresti usare un altro algoritmo se sei preoccupato che AES possa presto essere rotto (o che non usi affatto AES). Suppongo che il resto del tuo sistema non sia sicuro al 100%, quindi invece di sprecare tempo, sforzi, energie e risorse nella creazione di un algoritmo di produzione casalinga, questo sforzo dovrebbe essere speso altrove, dove può essere quantificabile che sta effettivamente aumentando sicurezza. Tutto il codice ha un costo, e non è solo lo stipendio dello sviluppatore junior che lo sta creando. Deve essere mantenuto e compreso da tutti - e ogni persona in più che impara come funziona è una via in più per far filtrare l'algoritmo. Non perdere tempo.

Potrebbe funzionare, e sarebbe la sicurezza in profondità invece della sicurezza per oscurità, ma ci sono alcuni modi per rovinare tutto questo in modo catastrofico:

• Uso di un algoritmo HomeBrew che è vulnerabile agli attacchi dei canali laterali. Ora l'utente malintenzionato può eseguire una semplice analisi della cache o del timing, ad esempio, e ignorare la parte AES interamente. Sei così sicuro nella tua implementazione?

• Riutilizzo del materiale tra gli algoritmi. Se riutilizzi le chiavi e i nonces, ad esempio AES(HomeBrew(openText, "secret"), "secret") , potrebbe essere vulnerabile alla crittanalisi. Questa è una minaccia lontana, ma necessaria se si desidera mantenere lo stesso standard di sicurezza di appena AES(openText) .

• Utilizzo di un'implementazione fragile HomeBrew . se potrebbe interrompersi quando il testo contiene valori nulli o superiori a una determinata dimensione o inferiori a una certa dimensione o assomiglia a questo , o contiene un Unicode valido, o contiene codifiche non valide, ecc. Questo è un problema di programmazione, ma apre il tuo software a qualsiasi cosa, da smentite di servizio a autenticazione impropria o peggio.

Tutto sommato, trovo che questa sia un'idea divertente , ma non pratica . Forse usare qualcosa che non è homebrew funzionerebbe meglio; ci sono modi più sicuri per aggiungere profondità alla tua sicurezza.

Di per sé, l'algoritmo di home-brew è una forma di sicurezza attraverso l'oscurità . Tuttavia, se applicato in combinazione con una buona crittografia nota, l'algoritmo di home-brew può essere considerato una strategia di difesa in profondità. Citando direttamente da Wikipedia,

A system may use security through obscurity as a defense in depth measure; while all known security vulnerabilities would be mitigated through other measures, public disclosure of products and versions in use makes them early targets for newly discovered vulnerabilities in those products and versions. An attacker's first step is usually information gathering; this step may be delayed by security through obscurity.

Se una vulnerabilità in AES è divulgata pubblicamente oggi, ci vorrà ancora del tempo perché un hacker possa capire come decifrare l'algoritmo di brew casalingo, dandoti il tempo di passare a un altro algoritmo. Come dice il proverbio, "non mettere tutte le uova in un cesto".

Per i veri paranoici, puoi adottare due livelli di crittografia standard diversa come AES + DES. Tuttavia, avere più livelli di crittografia diversa non costa nulla. Il compromesso è che il tuo testo cifrato diventa più complesso.

Dieter Vandenbroeck ha scritto un articolo su quando la sicurezza attraverso l'oscurità ha senso:

Usually, the principle of security through obscurity is just utterly wrong. The idea behind this principle is to have obscurity in your solution as the principal means of security. Of course, this is not a valid substitute for real security: once your obscurity schema is broken, your security would be broken. It might form a defense against automated scripts, but an attacker with sufficient determination will always be able to fight through this defense.

Nel tuo caso non avrai uno script automatico e nel momento in cui AES può essere decifrato in modo automatico, homebrew sarà probabilmente ancora più difettoso e facile da decifrare. Quindi no, non credo che l'homebrew ti darebbe un ulteriore vantaggio in termini di sicurezza rispetto alla semplice AES.

• Ha senso , anche se utilizzi ROT13, poiché aggiungi un livello di sicurezza. AES (HomeBrew (openText)) sarà sempre più sicuro di AES (openText) ...

• ... a meno che questo tuo algoritmo non aggiunga qualche debolezza ad AES che renderà la criptanalisi più facile. Di cui dubito.

• Ma personalmente mi attenevo agli algoritmi conosciuti e uso qualcosa come AES (Threefish (Plaintext)) .

• Tuttavia, dov'è il divertimento in questo?

• E come intendi mantenere sicuro il tuo algoritmo, se intendi usarlo?

Generalmente non mi preoccuperei.

Sono d'accordo con abligh.

L'esecuzione di "Homebrew_Crypto (AES (testo in chiaro)") probabilmente non aggiungerà molto alla sicurezza del sistema, ma ciò che farà - anche contro un attaccante a livello di stato - è semplicemente rallentarli. (Rallenterà molto gli attaccanti non sofisticati, poiché per tali agenzie non li obbligherà a utilizzare qualche altro ciclo di tempo per il supercomputer, il che potrebbe farti ottenere dei punti brownie nella lista dei "Nemici del nostro stato di sicurezza nazionale".

Una variante molto divertente di questo sarebbe:

"Homebrew_Crypto (Twofish_Or_Some_Other_Good_Crypto_Algorithm (AES (plaintext)))" - a rischio di rallentare significativamente l'I / O, ovviamente. Un po 'come quelle bambole russe che nidificano l'una dentro l'altra.

Si noti che quest'ultima opzione era disponibile in Truecrypt e credo nei suoi successori come Veracrypt.

C'è un altro motivo per cui questa potrebbe aiutare. Invece di fare AES (Homebrew (testo normale) , supponiamo di fare Homebrew (AES (testo normale) .

Supponiamo anche il caso peggiore, e anche se pensi di essere criptico, il tuo algoritmo Homebrew non è più utile di ROT-13.

In questo caso, oggi hai uno schema combinato che non è peggio di AES da solo (salvo che potrebbe essere un po 'più lento), ma non meglio. Se il tuo Homebrew è migliore di ROT-13, chi sa che lo schema combinato potrebbe essere leggermente migliore di AES da solo.

Tuttavia, supponiamo ora che in futuro, AES si rompa. Un exploit zero day diventa disponibile e un exploit è ampiamente pubblicizzato. Script kiddies a bizzeffe tentativo di trovare materiale crittografato AES e decrittografarlo. Supponendo che non ti stiano bersagliando in modo specifico, è improbabile che siano in grado di decrittografare i tuoi dati usando l'hack, dato che non penseranno di applicare prima altre decrittografie, e ci sono frutti a bassa quota altrove. Questo ti dà almeno un po 'di tempo per cambiare la crittografia sottostante con qualcosa che non è rotto.

Se vale la pena, la penalità per la manutenzione e la manutenzione è un'altra questione completamente.

1. Crittografia standard che si è dimostrata valida
2. Algoritmo sconosciuto "nel caso in cui" anche in caso di perdite non fornirà molto all'attaccante a meno che non sappiano come interrompere AES

Tranne che ora hai DUE standard da mantenere, e un punto debole in ognuno di essi indebolirà il secondo, perché due cifre in tandem producono effettivamente un terzo codice soggetto alle debolezze di ciascuno. L'homebrew probabilmente lo rovinerà per tutti, alla fine della giornata. :)

Se hai una cifra che è PIÙ CONOSCIUTA rispetto all'altra, allora lo sforzo sarebbe meglio speso per assicurarti che sia distribuito correttamente.

Anche i protocolli stabiliti con sicurezza dimostrabile dovrebbero essere combinati solo in determinati casi; algoritmi inadeguati a cascata possono portare a modelli sottostanti che emergono quando i singoli codici "annullano" reciprocamente il lavoro degli altri, semplicemente perché le loro metodologie sono controproducenti.

È molto più probabile che un codice homebrew indebolirà il risultato anziché rafforzarlo. Secondo me, è meglio non tessere la tua crittografia.