Domanda:
Come si potrebbe rompere un protocollo di crittografia debole ma sconosciuto?
Ram Rachum
2013-03-18 20:03:57 UTC
view on stackexchange narkive permalink

Stavo leggendo questa domanda interessante:

La sicurezza della password fatta in casa dal mio sviluppatore è giusta o sbagliata, e perché?

Mostra un debole algoritmo home-brew sviluppato da "Dave" e le risposte spiegano perché questa è una cattiva idea. (In realtà l'algoritmo di hashing piuttosto che la crittografia, ma la mia domanda si applica a entrambi.)

Per me ha senso che un algoritmo fatto in casa sia una pessima idea, ma c'è una cosa che non capisco.

Supponiamo che io sia un attaccante e che mi trovi di fronte a un algoritmo di crittografia debole ma sconosciuto sviluppato da "Dave". Come potrei risolverlo? Non saprei nemmeno da dove cominciare. Sarebbe una stringa di caratteri apparentemente priva di significato.

Ad esempio, supponiamo che l'algoritmo home-brew sia così:

  • Utilizza un algoritmo di crittografia noto e debole su i dati originali, quindi:
  • Esegui un bit per bit negativo su qualsiasi byte il cui numero di serie nel file ha una somma di cifre ripetute che è primo. (O qualsiasi altra manipolazione matematica simile, questo è solo un esempio.)

Come si potrebbe hackerare un file prodotto da un tale algoritmo senza saperlo in anticipo?

Modifica: tutti, per favore non cercate di convincermi di quanto sia difficile mantenere segreto un algoritmo. Rispondi a questa domanda partendo dal presupposto che l'algoritmo sia tenuto completamente segreto, nonostante quanto sia difficile da ottenere nella vita reale.

Inoltre, supponi che io non abbia alcun accesso all'algoritmo, ma solo a i dati risultanti.

Se stai cercando risposte relative alla crittoanalisi, potresti voler specificare un paio di informazioni aggiuntive. In primo luogo, a quanti testi cifrati avrebbe accesso l'attaccante, in secondo luogo a quanti testi cifrati avrebbe accesso l'attaccante e in terzo luogo il tipo di dati crittografati dal testo cifrato (ad esempio, dati binari o testo).
Sentiti libero di rispondere alla domanda nel caso di più testi cifrati o solo di uno. Per quanto riguarda il tipo di dati: dì binario.
Inoltre: vedere qui: http://old.honeynet.org/scans/scan16/som/som34.html
Nessun algoritmo di crittografia "sconosciuto" può essere considerato "debole" finché non viene compreso e violato. Sconosciuto non implica debolezza, è il tentativo di scoperta che rivela la natura della bestia e d'ora in poi la sua forza di ossessione.
Bene, sembra che tu abbia fatto il tuo punto. Ecco fatto, vinci. Un gruppo di ragazzi su un sito di sicurezza non è stato in grado di violare la tua "crittografia".
Ciao RamRachum, [Sfida a decodificare qualcosa di stile-domande] (http://meta.crypto.stackexchange.com/questions/100/do-we-want-challenge-analyse-this-questions-and-if-so-what -constraints-if-any) sono considerati fuori tema qui.
Ciao Ram, penso che tu abbia alcune supposizioni fuori luogo. Prima di tutto, a quanto ho capito, stai * solo * chiedendo dei puri aspetti matematici della crittoanalisi. Se questo è il caso, la domanda dovrebbe probabilmente essere spostata in [crypto.se], invece di rimanere su [security.se] - Qui * guardiamo * l'intera immagine, e sicuramente * restiamo * nel regno della realtà e non un pollo perfettamente sferico (come ha detto uno dei commentatori).
Negli scenari del mondo reale, se la riservatezza dei tuoi dati dipende dalla segretezza del tuo algoritmo di crittografia, probabilmente sarebbe più facile rubare i dettagli di quell'algoritmo (supponendo che l'algoritmo non sia banale). Collegamento più debole e tutto il resto. Inoltre, in scenari di utilizzo del mondo reale non banali, è quasi impossibile mantenere l'algoritmo a qualsiasi livello di segretezza, anche * senza * il coinvolgimento dell'aggressore, che si tratti di altri consumatori dell'algoritmo, sviluppatori con accesso al codice sorgente repository o altri aggressori interni.
Dal momento che abbiamo a che fare con il mondo reale, è spesso molto più semplice lanciare alcuni strumenti automatizzati al compito della crittoanalisi di base, senza dover approfondire i dettagli di mathy. Va bene, sono proprio questi i dettagli che vuoi sapere, ma ancora una volta sarebbe fuori tema qui. (Proprio come i dettagli di un algoritmo di crittografia sarebbero fuori tema).
Infine, dubito che qualcuno qui sarebbe incline a spendere più di una banale quantità di tempo per violare la crittografia, ciò ovviamente non significa che non possa essere fatto con tempo e risorse appropriati. Il che mi porta al punto finale: quanto sia facile violare la crittografia, è rilevante per il profilo di rischio e il modello di minaccia. È un'applicazione bancaria o il blog dei gatti di tua sorella minore? Le ricompense proporzionate definiranno quanto sforzo, in base al numero di aggressori, proverà probabilmente a violare la crittografia. In realtà è * più facile *, figuriamoci più sicuro, utilizzare solo una crittografia avanzata.
La tua domanda manca davvero dei dettagli citati da @RoryMcCune, con una forte influenza sulla risposta "corretta": se tutto ciò che hai sono messaggi crittografati e nessuna conoscenza di base, il presupposto peggiore è che qualcuno abbia usato qualcosa di equivalente a un [blocco unico ] (http://en.wikipedia.org/wiki/One-time_pad) - se è stata utilizzata una chiave veramente casuale e irriproducibile _ non puoi_ ottenere il messaggio senza ulteriori interazioni con il mittente o il destinatario (diretto o indiretto). Ma potrebbe essere anche uno schema banale, che un crittoanalista esperto possa interrompere per colazione. Puoi solo provare e vedere.
@Thomas wow! A quanto pare anche io adesso sono un l33th4x0r. Mi ci sono voluti <5 minuti usando python (sto imparando python) e non ho esperienza di crittoanalisi degna di nota ... :)
Posso consigliarti "The Code Book" di Simon Singh. Vuoi sapere come è stato crackato Enigma durante la seconda guerra mondiale? Questo libro lo spiega con parole semplici. Elenca anche molti dei famosi cifrari della storia e come sono stati decifrati. È una bella lettura per tutti coloro che sono interessati alla crittografia.
"Come potrei risolverlo? Non saprei nemmeno da dove cominciare." Stai assumendo che la persona che sta tentando di decifrarlo sia scarsamente esperto nel cracking di criptovalute come te o me.
A proposito: nella vita reale ottieni i dati crittografati da una certa fonte (che conosci) e in un certo momento, probabilmente sapendo già qualcosa sulla fonte. Ciò consente di fare un sacco di ipotesi sul contenuto del testo, che può aiutare molto nella decrittazione. Lo stesso è stato fatto durante la seconda guerra mondiale da Turing et al. quando si trattava di Enigma: sapevano che alle 06:00 c'era un messaggio riguardante il tempo e presumevano che alcune parti del messaggio criptato si riferissero a termini meteorologici, consentendo loro di rompere la cifra in molto meno tempo (sebbene sapessero * più o meno * il algoritmo).
Ora ho posto una domanda simile su crypto.stackexchange: http://crypto.stackexchange.com/questions/6752/how-would-one-crack-a-weak-but-unknown-encryption-protocol
Per favore, non fare la stessa domanda su due siti diversi. Questo è scoraggiato / non consentito. Invece, puoi fare clic sul pulsante "flag" per chiedere che la domanda venga spostata in Crypto.stackexchange.
Otto risposte:
user2213
2013-03-18 20:31:09 UTC
view on stackexchange narkive permalink

Supponiamo che io sia un attaccante e che mi trovi di fronte a un algoritmo di crittografia debole ma sconosciuto sviluppato da "Dave". Come potrei risolverlo? Non saprei nemmeno da dove cominciare. Sarebbe una stringa di caratteri apparentemente priva di significato.

È corretto, non lo faresti. Ecco alcuni dati crittografati (4587556841584465455874588). Hai idea di cosa significhi? Assolutamente no.

Tuttavia, ti manca la chiave del pilastro centrale fondamentale, più integralmente importante dell'universo che tiene insieme la crittografia. L'idea è semplice:

  la chiave è tutto  

Questo è tutto. Questo è il pezzo che devi proteggere. Il bit che devi proteggere con la tua vita e sperare che nessuno ti colga con un martello finché non gli dici di cosa si tratta.

Su questa base, devi presumere che il tuo algoritmo possa essere letto dall'aggressore . Loro sanno come funziona. Possono documentarne il processo. Se ci sono punti deboli, li troveranno. E li sfrutteranno. Come quel papà arrabbiato della CIA di Taken.

Questo, a quanto pare, è meno un'ipotesi e più un caso pratico in uso. Dave, il crittografo casalingo, vuole includere un algoritmo di crittografia nel suo programma. Decidendo di evitare tutto il lavoro di test e progettazione che i crittografi hanno svolto gratuitamente nel corso degli anni, scrive qualcosa che coinvolge lo strano xor, compila il suo programma e lo dà utilmente agli amici.

Quell'algoritmo è ora disponibile le loro mani. Game over.

Ora potresti chiedere "non posso semplicemente mantenere segreto l'algoritmo? Funzionerà, giusto?" Oh Dave, per favore smettila. Nonono. Il problema con gli algoritmi segreti è che è molto più probabile che vengano rubati. Dopo tutto, la chiave è diversa per ogni utente (in realtà, questo non è un requisito, ma supponiamo che sia per semplicità) ma l'algoritmo rimane invariato. Quindi hai solo bisogno di una delle tue implementazioni per essere esposta a un attaccante e il gioco è di nuovo.


Modifica : ok, in risposta alla domanda aggiornata dell'OP. Supponiamo per un momento che l'algoritmo sia totalmente sconosciuto. Ciascuno dei due partecipanti a una conversazione crittografata ha una sicurezza perfetta dell'implementazione del proprio algoritmo.

In questo caso, hai dati da analizzare. Puoi eseguire una delle seguenti operazioni:

  • Analizza lettere conosciute di frequente. Ecco come spezzeresti una tipica cifratura a spostamento di cesare.
  • Prova a indovinare la lunghezza della chiave. Con queste informazioni, puoi passare alla ricerca di blocchi di testo cifrato ripetuti che possono corrispondere allo stesso testo in chiaro.
  • Tenta l'indice di coincidenza e altre misure simili utilizzate per rompere il cifrario vigenere, poiché molti cifrari polialfabetici sono (possibilmente ) solo varianti di questo.
  • Guarda i modelli. Qualsiasi pattern potrebbe darti la chiave.
  • Cerca altri indizi. Le lunghezze corrispondono a una certa misura, sono per esempio multipli di un certo valore come un limite di byte e quindi sono (possibilmente) riempite?
  • Prova ad analizzare con uno dei cifrari simmetrici tecniche di crittoanalisi. Questi si basano sulla conoscenza dell'algoritmo in molti casi, quindi potrebbero non essere applicabili qui.
  • Se ritieni che i dati in questione rappresentino uno scambio di chiavi, puoi provare una delle tante tecniche per rendere pubblico algoritmi chiave.

Il fatto è che un breve frammento di dati da un algoritmo sconosciuto potrebbe essere indecifrabile. Tuttavia, questo non significa che dovresti fare affidamento su questo caso. Più dati può recuperare un crittoanalista, più è probabile che interrompano il tuo algoritmo. Probabilmente non sai senza una seria crittoanalisi quale sia questo confine: ad esempio, è ragionevole presumere che si possa forzare brutemente un algoritmo di cifratura caeser per parole di tre lettere, poiché ce ne sono pochi che hanno un senso.

Hai anche problemi di riutilizzo. Nella seconda guerra mondiale, l'Engima ha superato questo problema disponendo di impostazioni programmabili per il loro algoritmo segreto, ma anche questo è stato rotto.

C'è anche l'elemento umano della crittografia da considerare. Mi rendo conto che l'etichetta sulla lattina dice "usa una volta, non digerire" ecc., Ma gli esseri umani sono umani e probabilmente useranno due, tre volte ecc. Qualsiasi comportamento del genere gioca nelle mani del crittoanalista.

Hai sostenuto che mantenere la segretezza dell'algoritmo è molto difficile. Sono completamente d'accordo. Tuttavia, non è questo l'argomento della domanda, quindi questa risposta non è utile.
@RamRachum: Potresti voler aggiornare la tua risposta per specificare che le nostre ipotesi di partenza sono un pollo perfettamente sferico su un piano senza attrito.
Scott: di solito, il pollo occupa una massa puntiforme, perché la resistenza dell'aria è davvero complicata con tutte quelle piume e uh, sì. @Ram ok, ho aggiornato la risposta per fornire alcune indicazioni generali su dove inizieresti con alcuni dati casuali e cosa costituisce un rischio per i dati "casuali". Dichiarazione di non responsabilità: se ti affidi a tali informazioni, lo fai a tuo rischio.
@AntonyVennard Grazie per aver aggiunto informazioni utili!
Ora, uno degli approcci che hai menzionato avrebbe funzionato nella crittografia di esempio che ho fornito nella mia domanda sopra?
Probabilmente @Ram. Modificare un file per posizione di byte potrebbe confondere parte del testo, ma se ne hai abbastanza scoprirai presto che è questo il modello, in particolare se compaiono parti di parole. Fondamentalmente lo spezzeresti in due fasi: 1) l'algoritmo debole, quindi 2) ok, ho parti di parole, ora, qual è lo schema con le rimanenti?
Se non conosci l'algoritmo e, a seconda di quanto sia buono il suo design, non è banale, ma è stato dimostrato che hai solo bisogno di un numero sufficiente di messaggi cifrati o di alcuni messaggi chiari e delle loro versioni cifrate per rimuovere il rumore e dedurre la trasformazione mediante l'applicazione di un algoritmo di correlazione tra i messaggi cifrati e la loro più probabile decrittazione (utilizzando i messaggi noti come sequenza di addestramento, se disponibile). Se sei interessato alla matematica coinvolta, leggere la teoria dell'informazione, l'elaborazione dei segnali e l'apprendimento automatico può aiutarti.
Non so chi sei, ma +1 per il riferimento Taken.
Questa risposta sarebbe stata utile quando ho avuto la faccia tosta di provare a risolvere Kryptos alcuni anni fa: http://en.wikipedia.org/wiki/Kryptos
Tom Leek
2013-03-18 22:30:27 UTC
view on stackexchange narkive permalink

Un algoritmo di "crittografia" sconosciuto è stato storicamente raggiunto almeno una volta. Sto parlando della scrittura minoica in lineare B, un metodo di scrittura utilizzato a Creta intorno al 1300 a.C. Il metodo andò perduto pochi secoli dopo, con la morte di tutti i praticanti e il collasso generale della civiltà durante il cosiddetto Medioevo greco. Quando gli archeologi iniziarono a setacciare la terra intorno a Cnosso e in altri luoghi, alla fine del XIX secolo, tutto ciò che ottennero fu un mucchio di tavolette con segni sconosciuti, senza la minima idea del sistema di scrittura utilizzato per produrli.

La storia interessante qui è che la lineare B è stata svelata negli anni '50, utilizzando gli stessi strumenti di analisi che erano impiegati contro i sistemi di crittografia di quel tempo. In effetti, la scrittura è stata considerata come un "algoritmo di crittografia sconosciuto". Ha ceduto ad analisi statistiche, inferenze concatenate e alcune ipotesi sul testo in chiaro (fondamentalmente, l'ipotesi che la lingua di base per una variante del greco). Questa è un'illustrazione classica e magistrale di come funziona la crittoanalisi contro i "crittosistemi manuali".


Ovviamente, supporre che un algoritmo crittografico possa essere in uso e rimanere segreto, non è plausibile. Per lo stesso presupposto, non c'è pirateria di videogiochi o contenuti multimediali. Il mondo reale ci ricorda implacabilmente che questo non è vero. L'unico modo noto con cui un algoritmo può rimanere segreto è uccidere i suoi inventori e professionisti, distruggere il loro apparato e aspettare alcuni secoli. Questo ha alcuni effetti collaterali scomodi.

E anche se, in una data istanza specifica, i dettagli su un algoritmo non sono trapelati ancora , non c'è modo di quantificare quanto segreto è l'algoritmo, cioè quanto tempo ci vorrà per il reverse engineering, le tangenti o il furto sano per ricostruire l'algoritmo. Questo è il motivo principale per cui i crittografi, circa 40 anni fa, decisero che chiave e algoritmo dovevano essere divisi, con la chiave segreta e l'algoritmo non segreto: puoi quantificare la segretezza di una chiave , non la segretezza di un algoritmo.

Questo ci dà un'idea della tua domanda specifica. Il tuo "algoritmo segreto" dipende dalla nozione di "manipolazione matematica". Quanti di questi sono? Puoi stimare o descrivere l'insieme delle "manipolazioni matematiche"? Scoprirai che un algoritmo di crittografia è esso stesso una "manipolazione matematica", quindi la tua domanda è piuttosto mal definita.

+1 questo ha alcuni effetti collaterali scomodi.
Ottima risposta, mostra chiaramente perché la domanda è "imperfetta" in sé.
Non capisco davvero tutto questo "Il mondo reale ci ricorda implacabilmente che questo non è vero." in tutte le risposte. Esempio di vita reale: si utilizza un algoritmo di crittografia reversibile per proteggere i dati sensibili degli utenti sul server. Ciò significa che non può essere un algoritmo unidirezionale come quello che possiamo usare per memorizzare le password, quindi deve avere una chiave. Quindi ora in che modo proteggere esattamente questa chiave è diverso dal proteggere l'algoritmo? Supponi solo che la persona che ha scritto questo algoritmo sia la stessa persona che genera / gestisce le chiavi di crittografia. Tangenti, furto, ecc. Si applicherebbero allo stesso modo a entrambi i metodi.
Non sto dicendo che sia la strada da percorrere e non userò mai qualcosa di simile nella produzione, ma tutte le risposte sono solo pigre, imho.
L'algoritmo esiste come codice compilato nei file e anche codice sorgente sulle macchine degli sviluppatori, software di controllo delle revisioni, backup ... e ci sono documenti di progettazione, come carta stampata, e-mail e nella testa di diverse persone. Sarebbe molto difficile rintracciarli tutti e garantire la segretezza. Questo contrasta con un _key_, che esiste solo nella RAM o, nel peggiore dei casi, in un singolo file, e non in tutti gli altri mezzi che ho appena elencato. Puoi rapire tutti gli sviluppatori, nessuno di loro ha la minima idea del _valore_ della chiave poiché non è mai entrata nel loro cervello in primo luogo.
@Tom Leek, Quando ho letto la domanda OP mi aspettavo di vedere risposte interessanti che spiegassero quanto sia difficile progettare un algoritmo che non possa essere rotto utilizzando i moderni metodi di crittoanalisi (ad esempio goo.gl/IEkfh), invece ho appena ricevuto il messaggio "non puoi mantenere segreto l'algoritmo". Scrivi "Sarebbe molto difficile rintracciarli tutti e garantire la segretezza" ma è del tutto possibile e il motivo per cui le persone non lo fanno non è perché è difficile, ma perché anche gli algoritmi fatti in casa più complessi lo faranno probabilmente hanno "buchi" che possono essere sfruttati dagli aggressori anche senza conoscere l'algoritmo
Per favore, non fraintendetelo, non ho sottovalutato la tua risposta ed è giusta in molti casi e avrei dovuto scrivere la mia risposta se volevo cambiare qualcosa nella tua. Solo ... non sono un crittografo e sebbene sia interessato a questo tema, non sono davvero qualificato per dare una risposta completa a questa domanda e mi aspettavo di più da uno dei migliori utenti :)
@XzKto: bene, progettare un algoritmo che resista alla crittoanalisi è un argomento completamente diverso. La domanda riguardava il cracking di un algoritmo _unknown_ (enfasi già nella domanda originale) rispetto a un algoritmo noto. I crittografi presumono che l'algoritmo sia noto per tutti i motivi che ho spiegato; Il modo in cui algoritmi conosciuti resistono ancora alla crittoanalisi è un argomento molto vasto da trattare meglio in [crypto.SE] (http://crypto.stackexchange.com/). Quando l'algoritmo è totalmente sconosciuto, beh ... non accade mai veramente. Quindi non c'è risposta possibile se non battute sull'archeologia.
@Tom Leek "La domanda riguardava il cracking di un algoritmo sconosciuto" - sì, ne stavo scrivendo anche io. "I crittografi presumono che l'algoritmo sia noto": credo che questo sia ciò su cui non siamo d'accordo. Non conosco molti casi popolari di reverse engineering di un algoritmo sconosciuto, ma so che succede e ci sono metodi per farlo. Non ho trovato niente di buono, ma questo può essere un esempio di ciò di cui sto parlando: http://goo.gl/sgvBY. Penso che questo dovrebbe essere il motivo per cui gli algoritmi fatti in casa sono cattivi, ma guardando di nuovo a tutte le risposte ammetto che forse mi sbagliavo.
Adi
2013-03-18 21:32:28 UTC
view on stackexchange narkive permalink

Per attaccare un protocollo crittografico, hai i seguenti metodi di attacco

  • Testo in chiaro noto: cercando di trovare correlazioni tra il testo in chiaro che hai e il corrispondente testo cifrato.

  • Testo in chiaro scelto: crittografia di un testo in chiaro specifico e studio delle modifiche al testo cifrato man mano che il testo in chiaro cambia.

  • Testo cifrato scelto: decifrare un testo cifrato specifico e studiare le modifiche al testo in chiaro e le modifiche al testo cifrato.

  • Codifica nota testo: dove tutto ciò che hai è il testo cifrato, di seguito è riportato un semplice esempio.

Molto tempo fa ho seguito un corso di crittografia, in una delle lezioni che abbiamo è stata insegnata la crittografia dei cifrari di sostituzione. Non è così che vanno le cose adesso, ma è qui che è iniziata la scienza della crittografia, ed è così che è iniziata la crittografia.

Diciamo che puoi farlo attraverso questo testo cifrato.

Mx qeoiw wirwi xs qi xlex e lsqi-fvia epksvmxlq mw e zivc feh mhie, fyx xlivi'w sri xlmrk M'q rsx yrhivwxerhmrk.

Non conosci il algoritmo, non conosci la chiave. Come dovresti iniziare?

  • Analizza la frequenza delle lettere: la lunghezza totale è di 87 lettere. Vediamo che i è stato utilizzato 12 volte -> ~ 13%. Secondo l ' articolo di Wikipedia sulla frequenza delle lettere, è probabile che questa lettera sia e . Il nostro testo cifrato ora è:

Mx qeoew werwe xs qe xlex e lsqe-fvea epksvmxlq mw e zevc feh mhee, fyx xleve'w sre xlmrk M'q rsx yrhivwxerhmrk.

  • Ora la seconda lettera più frequente è x è stata usata 11 volte -> ~ 11%, quindi è probabile che sia t . Il nostro testo cifrato ora è:

Mt qeoew werwe ts qe tlet e lsqe-fvea epksvmtlq mw e zevc feh mhee, fyt tleve'w sre tlmrk M'q rst yrhivwterhmrk.

  • Ora stiamo iniziando a vedere gli schemi. La sostituzione di i->e e x->t suggerisce che la chiave potrebbe essere 4 . Proviamolo:

Per me ha senso che un algoritmo fatto in casa sia una pessima idea, ma c'è una cosa che non capisco.

Ahaa! Abbiamo capito! Ora hai eseguito la tua prima crittografia. Questo è un modo in cui il testo cifrato potrebbe essere analizzato.

Nakedible
2013-03-19 01:16:39 UTC
view on stackexchange narkive permalink

Penso che nessuno l'abbia detto ad alta voce qui, quindi lo farò.

Se a un crittografo viene fornito un solo testo cifrato senza mezzi per ottenerne di più, il testo cifrato è breve e non viene fornita alcuna conoscenza del testo in chiaro , è quasi impossibile decrittografare il testo. L'unico modo in cui ciò è ancora possibile è se il codice è intorno al livello di difficoltà di un cifrario a sostituzione.

Dato lo stesso algoritmo, se c'è un modo per ottenere più testi cifrati su richiesta, se il testo cifrato è sufficientemente lungo o se ci sono alcune parti note del testo in chiaro che possono aiutare, è probabile che l'algoritmo possa essere violato con uno sforzo sufficiente.

Ma anche ancora, la crittoanalisi richiede molto sforzo rispetto allo sforzo di creare un semplice algoritmo crittografico da zero, quindi è improbabile che qualcuno spenda lo sforzo a meno che non ci sia una buona ragione per farlo.

Hmm, quindi l'accordo di sicurezza definitivo sarebbe quello di accoppiare un noto algoritmo di crittografia con uno fatto in casa, no? Perché allora godi dei vantaggi di entrambi: godi della sicurezza del noto algoritmo, ma se viene scoperta una vulnerabilità in esso, sei comunque protetto da quello fatto in casa. No?
Non è una posizione irragionevole, se sei abbastanza esperto da combinare gli algoritmi in modo sicuro senza introdurre nuove vulnerabilità. Un'altra scelta, se sei abbastanza esperto, è apportare una modifica banale a un algoritmo ben noto e mantenere segreta la modifica. Tuttavia, nel mondo reale, hai quasi la garanzia al 100% di peggiorare le cose aggiungendovi qualcosa: la crittografia è difficile, anche se a volte potrebbe sembrare che non lo sia.
Se, nella crittografia simmetrica, applichi il tuo algoritmo di home brew prima o dopo un noto algoritmo, non peggiorerai in nessun caso le cose. Penso che applicare il tuo algoritmo home-brew dopo un noto algoritmo di crittografia (e quindi prima del noto algoritmo di decrittazione) sarebbe meglio che applicarlo prima del noto algoritmo. Quello che stai affermando nel tuo commento è probabilmente vero, Ram.
Per fornire un altro esempio dell'approccio combinato "sicurezza attraverso l'oscurità" e "algoritmi noti": quando si esegue un hash crittografico, si applica una funzione iniettiva (come il salting o lo xor-ing con una costante) sui dati prima o dopo l'hashing non può diminuire la sicurezza, se la funzione hash non ha punti deboli.
mgjk
2013-03-18 21:40:51 UTC
view on stackexchange narkive permalink

Se hai intenzione di distribuire un algoritmo segreto, perché non distribuire invece solo blocchi unici? È più sicuro.

Se non ti piace l'idea dei blocchi unici perché troppi dati si spostano in rete, perché pensi che l'attaccante abbia solo un testo cifrato?

Supponendo che qualcuno abbia solo un testo cifrato e non abbia l'algoritmo, (due presupposti sbagliati), allora il tuo sistema di crittografia sottostante debole ma ben noto probabilmente non ha alcuna vulnerabilità per cominciare.

user10211
2013-03-18 20:07:16 UTC
view on stackexchange narkive permalink

Esistono diversi modi.

Il primo e più ovvio è che gli aggressori hanno compromesso il tuo server nella misura in cui sono riusciti a ottenere il tuo codice sorgente. In quel caso particolare, il tuo schema creato internamente non vale niente.

Il secondo modo è che l'aggressore potrebbe essere in grado di inviare i propri valori al tuo algoritmo e vedere il risultato prima / dopo. Questo è noto come attacco con testo in chiaro scelto. Un buon schema di crittografia non dovrebbe esserne vulnerabile. Uno schema interno probabilmente lo è.

Anche senza un attacco con testo in chiaro scelto, uno schema interno è di solito ridicolmente debole. Un laico come te e io potremmo non essere in grado di dare un senso all'output di uno schema nostrano. Tuttavia, c'è una classe di persone molto intelligenti che dedicano il loro tempo e i loro sforzi a rompere tali schemi crittografici di solito in cambio di un buon stipendio. Potresti averne sentito parlare, li chiamiamo Cryptographers.

Forse sono un po 'pedante qui, ma non è "buono come niente" piuttosto che essere "peggio di niente"?
@AndySmith Fine bene. : P modificato.
@RamRachum, per favore dicci, perché pensi che sia inutile? Forse con più informazioni Terry o qualcun altro potrebbero aiutarti. Per quanto posso vedere, questa è una risposta abbastanza buona.
@RamRachum Mi dispiace, ma perché è inutile? Non puoi aspettarti che ti dica come rompere ogni singolo schema locale là fuori, vero? Il nocciolo della questione è che gli schemi fatti in casa sono deboli e ci sono persone molto intelligenti là fuori che li infrangono.
@RamRachum Quindi vuoi che dia una risposta specifica per il tuo algoritmo con limitazioni francamente molto irrealistiche? Spiacente, non posso farlo. Sarebbe "Troppo localizzato". La mia risposta è valida finché vivi nel mondo reale.
@Ram - che ne dici di rimanere educato, ok?
Peggio di niente perché genera un falso senso di sicurezza. Almeno se non hai un controllo in atto, continui a razionalizzare le future decisioni sulla sicurezza su quel presupposto, piuttosto che fare affidamento sul presupposto che tu abbia un controllo in atto che è migliore di quanto non sia in realtà.
matugm
2013-03-18 21:25:19 UTC
view on stackexchange narkive permalink

Rispondi a questa domanda partendo dal presupposto che l'algoritmo sia tenuto completamente segreto, nonostante quanto sia difficile da ottenere nella vita reale.

Il problema con questo è che stai ignorando il principio di Kerckhoffs, che dice che la sicurezza di uno schema di crittografia non dovrebbe dipendere dalla segretezza dell'algoritmo.

Comunque se sei veramente interessato alla crittografia dovresti prendere un corso come questo.

È un principio. Ha lo scopo di guidare il processo decisionale. Non è una legge, regola o teoria che sia effettivamente un fatto.
** è ** una regola.
@Rushyo Dato quanto bene il principio di Kerckhoff ha funzionato per gli algoritmi moderni, direi che è un dato di fatto.
@SmitJohnth Perché sia ​​una regola ci vorrebbe un obbligo. È possibile applicare una regola a un principio (ovvero tutti devono seguire il principio di Kerckhoff per lavorare su questa libreria) ma ciò non rende il principio stesso una regola.
@TerryChia Un principio può essere applicato con successo il 100% delle volte e ancora non diventa un dato di fatto. Un fatto non è perseguibile, come lo è un principio. Puoi mettere in atto un principio seguendolo, non puoi mettere in atto un fatto. Non dici "Dobbiamo applicare le leggi di gravità per questo". Dici "Dobbiamo applicare il principio di Kerckhoff per questo". Qualcuno può scegliere di ignorare il principio di Kerckhoff (a proprio rischio e pericolo). Non possono scegliere di ignorare le leggi di gravità.
Chloe
2013-03-20 12:09:04 UTC
view on stackexchange narkive permalink

Dato che non è stato menzionato e questa domanda è in giro da un po '...

Uno scienziato informatico ha aiutato a decifrare il testo crittografato di una società segreta del XVIII secolo. Il testo era molto decorato, con simboli e glifi. Per secoli ha lasciato perplessi esperti letterari. Il trucco era indovinare alcune delle lettere e cosa potrebbero significare, e anche indovinare la lingua originale, poiché il tedesco ha frequenze di lettere diverse dall'inglese o dall'italiano.

Ecco la descrizione del testo cifrato e come è stato svelato.

http://phys.org/news/2011-10-scientist-mysterious-copiale-cipher.html

http://stp.lingfil.uu.se/~bea/copiale/

http://www.wired.com/dangerroom/2012/11/ ff-the-manuscript / all / (Molto lungo, molto interessante.)

Con Copiale Cipher, il team di codebreaking ha iniziato a non conoscere nemmeno la lingua del documento crittografato. Ma avevano un'idea dei caratteri romani e greci distribuiti in tutto il manoscritto, quindi li isolarono dai simboli astratti e lo attaccarono come il vero codice.

"Ci è voluto molto tempo e il risultato è stato completo fallimento ", dice Knight. Dopo aver provato 80 lingue, il team di crittografia si è reso conto che i caratteri romani erano "nulli", destinati a fuorviare il lettore. Erano i simboli astratti a contenere il messaggio.

Il team ha quindi testato l'ipotesi che simboli astratti con forme simili rappresentassero la stessa lettera o gruppi di lettere. Alla fine, sono emerse le prime parole significative in tedesco: "Cerimonie di iniziazione", seguite da "Sezione segreta".



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