Puoi lanciarne uno tuo, ma probabilmente commetterai un grave errore di sicurezza se non sei un esperto di sicurezza / crittografia o se il tuo schema è stato analizzato da più esperti. Sono più disposto a scommettere su uno schema di crittografia open source pubblicamente noto che è disponibile per tutti da vedere e analizzare. Più occhi significa che è più probabile che la versione corrente non abbia grosse vulnerabilità, al contrario di qualcosa sviluppato internamente da non esperti.

Da Phil Zimmermann (creatore di PGP) Introduzione alla crittografia ( Pagina 54):

Quando ero al college all'inizio degli anni '70, ho ideato quello che credevo fosse un brillante schema di crittografia. Un semplice flusso di numeri pseudocasuali è stato aggiunto al flusso di testo in chiaro per creare testo cifrato. Ciò apparentemente ostacolerebbe qualsiasi analisi di frequenza del testo cifrato e sarebbe indecifrabile anche per le agenzie di intelligence governative più intraprendenti. Mi sentivo così soddisfatto dei miei risultati.

Anni dopo, ho scoperto lo stesso schema in diversi testi introduttivi di crittografia e documenti tutorial. Che carino. Altri crittografi avevano pensato allo stesso schema. Sfortunatamente, lo schema è stato presentato come un semplice compito a casa su come usare le tecniche crittoanalitiche elementari per decifrarlo banalmente. Questo per quanto riguarda il mio brillante schema.

Da questa esperienza umiliante ho imparato quanto sia facile cadere in un falso senso di sicurezza quando si concepisce un algoritmo di crittografia. La maggior parte delle persone non si rende conto di quanto sia diabolicamente difficile ideare un algoritmo di crittografia in grado di resistere a un attacco prolungato e determinato da parte di un avversario pieno di risorse.

(Questa domanda ha più discussioni sulla citazione precedente.)

Se non sei convinto di "Don't Roll Your Own [Cryptography / Security]", allora probabilmente non sei un esperto e ci sono molti errori che probabilmente farà.

La tua applicazione è robusta contro:

• Temporizzazione degli attacchi. Ad esempio, in nanosecondi chiavi completamente danneggiate e chiavi parzialmente danneggiate impiegano la stessa quantità di tempo nell'aggregato per fallire? Altrimenti, queste informazioni temporali possono essere sfruttate per trovare la chiave / password corretta.

• Trivial Brute Force Attacks; ad esempio, ciò può essere fatto in pochi secondi o anni (quando ti preoccupi che si rompa entro pochi anni). Forse la tua idea di sicurezza potrebbe essere una possibilità su un miliardo (1 000 000 000) di irrompere (cosa succede se qualcuno con una rete bot ci prova qualche miliardo di volte?). La mia idea è di puntare a qualcosa come 1 su ~ 2 ¹²⁸ (34.000.000.000.000.000.000.000.000.000.000.000.000), che è circa dieci milioni di miliardi di miliardi di volte più sicuro e completamente al di fuori del regno di indovinare la tua strada.

• Attacchi agli account utente in parallelo; ad esempio, puoi eseguire l'hashing delle password con lo stesso (o peggio no) "salt" su tutti gli hash delle password nel database come quello che è successo con gli hash di LinkedIn trapelati.

• Attacca banalmente qualsiasi account specifico. Forse c'era un salt casuale univoco con ciascuna password con semplice hash (ad esempio, MD5 / SHA1 / SHA2), ma poiché puoi provare miliardi di possibili password su qualsiasi hash ogni secondo, quindi usando elenchi di password comuni, attacchi di dizionario, ecc. impiegano solo pochi secondi per violare la maggior parte degli account. Usa hash crittografici potenti come bcrypt o PBKDF2 per evitare o rafforzare con la chiave gli hash regolari con un fattore adatto (tipicamente 10 ^(3-8) ).

• Attacchi a numeri "casuali" indovinabili / deboli. Forse usi microtime / MT-rand o troppe poche informazioni per seminare il numero pseudo-casuale come Debian OpenSSL ha fatto qualche anno fa.

• Attacchi che aggirano le protezioni. Forse hai eseguito l'hashing / convalida dell'input lato client nell'applicazione web e questo è stato bypassato dall'utente modificando gli script. Oppure hai un'applicazione locale che il client tenta di eseguire in una macchina virtuale o disassembla per decodificarla / alterare la memoria / o in altro modo imbrogliare in qualche modo.

• Altri attacchi, inclusi non tentando di essere un elenco completo) CSRF, XSS, iniezione SQL, intercettazioni di rete, attacchi di replay, Attacchi Man in the Middle, buffer overflow, ecc. Le migliori protezioni riassunte molto rapidamente.

  • CSRF: richiede token CSRF generati casualmente nelle azioni POST; XSS: convalida / esci sempre dall'input dell'utente non attendibile prima di inserirlo nel database e visualizzarlo per l'utente / browser.
  • SQLi: utilizza sempre i parametri associati e limita il numero di risultati restituiti.
  • Intercettazioni: crittografa il traffico di rete sensibile.
  • Replay: inserisce nonce una tantum univoche in ogni transazione.
  • MitM: Web of Trust / Uguale all'ultima visita del sito / Certificato emesso da CA affidabile .
  • Buffer overflow: linguaggio di programmazione sicuro / librerie / protezione dello spazio eseguibile / ecc.).

Sei forte solo quanto il tuo anello sfruttabile più debole. Anche solo perché non stai implementando il tuo schema, non significa che il tuo schema sarà sicuro, è molto probabile che la persona che ha creato ciò che hai implementato non fosse un esperto o che abbia creato uno schema altrimenti debole.

C'è una casa nella mia zona con un bel terrazzo fuori dalla camera familiare al secondo piano. Sembra gonfio, finché non vai sotto e vedi come è stato costruito. Sembra che il proprietario della casa abbia deciso di non dover pagare un sacco di soldi a un costruttore o architetto per dirgli come costruire un mazzo. L'ha costruito lui stesso e sembra una ragnatela caotica di 2x4 sotto. PROBABILMENTE andrà bene. Personalmente, preferirei non rischiare la vita e l'incolumità fisica in un lavoro di costruzione amatoriale come quello.

Penso che se vuoi sviluppare un algoritmo per fare la crittografia, dovresti farlo e divertirti. . Non consiglierei di usarlo per nascondere i tuoi estratti conto bancari online, ma se vuoi crittografare le lettere d'amore della tua ragazza sul tuo computer di casa, dovrebbe andare bene, a condizione che tua moglie non sia una crittoanalista.

una storia in "The American Black Chamber" * sulla Marina che sviluppa i propri codici. La Marina avrebbe mostrato il loro nuovo criptosistema, soddisfatta di se stessa e Yardley, l'analista dell'esercito, avrebbe prontamente infranto il codice, spiegando cosa avevano fatto di sbagliato. Si sarebbero offerti di correggere il codice, ma Yardley ha sottolineato che mentre potevano correggere punti deboli specifici, senza una solida comprensione, avrebbero sempre avuto un problema. Il loro sistema era intrinsecamente difettoso. È un po 'come riparare un tetto che perde. Puoi rattoppare per sempre ma l'acqua sta ancora entrando. Se non vuoi bagnarti, il tetto deve essere costruito da qualcuno che sa più di un po 'di tetti.

Ti ho mai parlato della chirurgia cerebrale fai-da-te che ho eseguito sulla mia defunta suocera? Tutto è andato bene finché lei non è morta. Seriamente, pochi di noi affiderebbero la nostra salute a un medico dilettante; vuoi davvero affidare i tuoi segreti al software amatoriale? Odio ammetterlo, ma compro un biglietto della lotteria ogni pochi mesi. Mi aspetto di perdere, ma il potenziale pagamento è enorme. Posso giocare le probabilità e forse uscirò in vantaggio. Se non lo faccio, sono fuori un dollaro. Perché giocare le probabilità sulla crittografia? La vincita non c'è.

Saluti, / Bob Bryan

• Consigliato: Herbert O. Yardley, "The American Black Chamber" - Un libro interessante oggi come quando è stato scritto nel 1931. “L'American Black Chamber era pieno di buone storie ben raccontate, così come di descrizioni franche dei successi di Yardley nella crittoanalisi. Fu un best-seller nel 1932, sia all'estero che a livello nazionale ". Da NSA: Pearl Harbor Review - The Black Chamber

Bruce Schneier scrisse nel 1998:

Chiunque, dal dilettante più incapace al miglior crittografo, può creare un algoritmo che lui stesso non può rompere . Non è nemmeno difficile. Ciò che è difficile è creare un algoritmo che nessun altro possa rompere, anche dopo anni di analisi. E l'unico modo per dimostrarlo è sottoporre l'algoritmo ad anni di analisi da parte dei migliori crittografi in circolazione.

Cory Doctorow ha soprannominato questo concetto "Legge di Schneier" in un discorso del 2004:

Qualsiasi persona può inventare un sistema di sicurezza così intelligente da non riuscire a pensare a come romperlo.

Come un follow-up, questo, di nuovo da Schneier:

Quando qualcuno ti consegna un sistema di sicurezza e dice "Credo che sia sicuro", la prima cosa che hai chiedere è: "Chi diavolo sei?" Mostrami cosa hai infranto per dimostrare che la tua affermazione sulla sicurezza del sistema significa qualcosa.

Phil Zimmerman ha scritto anche nei suoi documenti PGP originali:

Quando ero al college nei primi anni settanta, ho ideato quello che credevo fosse un brillante schema di crittografia. Un semplice flusso di numeri pseudocasuali è stato aggiunto al flusso di testo in chiaro per creare testo cifrato. Ciò apparentemente ostacolerebbe qualsiasi analisi di frequenza del testo cifrato e sarebbe indecifrabile anche per le agenzie di intelligence governative più intraprendenti. Mi sentivo così compiaciuto del mio risultato. Così sicuro.

Anni dopo, ho scoperto lo stesso schema in diversi testi introduttivi di crittografia e documenti tutorial. Che carino. Altri crittografi avevano pensato allo stesso schema. Sfortunatamente, lo schema è stato presentato come un semplice compito a casa su come usare le tecniche crittoanalitiche elementari per decifrarlo banalmente. Questo per quanto riguarda il mio brillante schema.

Il post originale chiedeva un esempio:

Il Babington Plot è una bella storia di un cattivo sistema crittografico che causa problemi. Mary Queen of Scots fu imprigionata da sua cugina, la regina Elisabetta I, e comunicava con persone all'esterno tramite lettere crittografate. L'alfabeto è stato sostituito con un criptoalfabeto di scarabocchi, cerchi incrociati e triangoli con lettere extra assegnate per lettere comuni, come e, t, i e o, quindi il significato delle lettere non può essere trovato rapidamente dall'analisi della frequenza. Hanno anche aggiunto alcuni caratteri nulli che sono stati ignorati nella decrittazione per respingere gli analisti. Il problema era che The Queen aveva un crittoanalista molto competente nel suo staff nella persona di Thomas Phelippes che era in grado di decrittare i messaggi mentre venivano intercettati.

Mentre le cose andavano avanti, Mary seguì un piano per falla fuggire e prendi il trono. Quando gli agenti della Regina intercettarono l'ultima lettera di Mary prima di trasmetterla, aggiunsero una frase crittografata che chiedeva i nomi di coloro che erano coinvolti nella trama "in modo che possano essere adeguatamente ricompensati". Il corrispondente di Mary rispose diligentemente e gli agenti della Regina fecero giustiziare tutte le persone coinvolte.

Quando i miei figli erano piccoli, inviavo loro crittogrammi con il loro pranzo (con una chiave (usando un cifrario Vernam)). In genere erano barzellette ma non avevano mai importanza. In un caso del genere, rotolare il tuo va bene. Se stai complottando per rovesciare la Regina d'Inghilterra (o lo Scià d'Iran o il Thug-ocracy che si sta lentamente riformando in Myanmar), ti suggerirei di assicurarti che ciò che stai usando non possa essere facilmente decifrato. Come ha detto Bruce Schneier, chiunque può inventare un sistema crittografico che non è in grado di decifrare, ma inventarne uno che nessun altro possa decifrare è più difficile.

Darò un esempio di qualcosa che è successo qui dove lavoro. Un mio collega era responsabile della progettazione di un sistema di archiviazione delle password (lunga storia, non chiedere) per gli account FTP aziendali. Mi è stato chiesto di subentrare e la prima cosa che ho visto è stata:

  public string Encrypt (string rawText) {// homebrew code here} public string Decrypt (string encrypted) {// homebrew code here}  

Li ho immediatamente estratti, sostituendoli con chiamate di libreria crittografica standard - e quando sono stato interrogato, ho risposto:

"Tu mai avvia la tua routine di crittografia. "

Il mio collega mi ha combattuto per ore. Ci aveva dedicato molto di tempo, rendendolo perfetto , in modo che un aggressore non potesse possibilmente avere alcun modo per infrangerlo . A un certo punto, hanno persino detto: "Questo è più sicuro di AES256, perché nessuno sa come funziona".

A quel punto, sapevo due cose:

• Il mio collega era un perfetto esempio dell'effetto Dunning Kruger (la mancanza di conoscenza su un argomento rendeva più probabile una sovrastima delle sue capacità)
• Il mio collega doveva essere corretto. Non solo perché erano "sbagliati", ma perché erano responsabili dell'architettura di altri sistemi e non volevo che mantenessero la crittografia casalinga.

Quindi ho messo da parte il codice. E invece, ho provato a rompere il codice della routine semplicemente chiamando la funzione Encrypt () ed esaminando l'output. Sono un principiante - non sono un crittoanalista - ma mi ci sono volute solo 4 ore. Ho dimostrato loro il crack, li ho guidati attraverso i miei passi e ho ripetuto: non utilizzare mai la tua crittografia. Si spera che lo prenderanno a cuore e non lo faranno mai più.

Quindi si riduce a:

1. Quanto sei sicuro della sicurezza della tua crittografia non influisce su quanto sia effettivamente sicuro.
2. Non utilizzare mai la tua crittografia (non può essere ripetuta abbastanza spesso ...)

In crittografia non hai un solo avversario che ti attacca nel modo in cui ti aspetti che faccia. Questo è ciò su cui è difficile ragionare, perché devi pensare assolutamente a TUTTO.

Ma davvero, nessuno può battere in astuzia ogni possibile avversario. Il meglio che possiamo fare è utilizzare il più possibile la nostra conoscenza comune e la ricerca esistente e fare piccoli passi per costruire da lì, attaccare vettore per vettore di attacco.

Questo è il motivo per cui molti problemi sull'orlo le abilità umane vengono avvicinate, sia che si tratti di ricerche in fisica o di giocare a scacchi al massimo livello.

In queste aree puoi anche ignorare ciò su cui stanno lavorando gli altri e escogitare le tue strategie e teorie, e se incontri il tuo primo abile avversario, sarai cancellato dallo stato dell'arte in più modi che puoi contare.

TL; DR
Gli esseri umani sono troppo stupidi per fare da soli la crittografia.

In realtà, lancia la tua crittografia, poi buttala via.

Come dice Crypto Fails, è un po 'duro dire che non puoi scrivere nessuna crittografia codice a tutti. Il problema principale è non prendere quel codice e usarlo ovunque (nel software rilasciato).

Dovresti assolutamente provarlo e usarlo come esperienza di apprendimento. Ancora meglio se sei amico di un crittoanalista e puoi ottenere il loro feedback su ciò che hai scritto. Se valgono il loro sale, anche loro ti diranno di non usare il codice nella vita reale, ma dovrebbero essere in grado di darti alcune informazioni che ti aiuteranno a imparare e crescere.

In genere è impossibile garantire che qualcuno che progetta un sistema crittografico non lasci l'azienda per la quale è stato creato e utilizzi la propria conoscenza di quel progetto a scapito del proprio ex datore di lavoro, se non progettando il sistema crittografico in modo in cui qualsiasi conoscenza del genere che un avversario può acquisire potrebbe essere resa inutile.

Se si ha un criptosistema che è sicuro anche contro attaccanti che sanno tutto tranne una chiave, e si cambia la chiave in una nuova generata casualmente valore, quindi il sistema sarà protetto da eventuali aggressori che non dispongono della nuova chiave. Anche se gli aggressori avessero informazioni sufficienti per compromettere il sistema prima che la chiave venisse modificata, non sarebbero in grado di rompere il sistema in seguito.

A meno che un sistema non abbia bisogno di proteggere dati insolitamente preziosi, probabilmente non è troppo difficile progettare un sistema crittografico in modo che sia abbastanza buono che, senza una conoscenza interna, il costo del cracking supererebbe qualsiasi valore che potrebbe essere ottenuto in questo modo. Non perché progettare una buona crittografia sia facile, ma perché la maggior parte dei sistemi non è utilizzata per proteggere qualcosa che potrebbe essere di grande valore per un utente malintenzionato (anche se un esperto crittografo potrebbe facilmente rompere un sistema in 58 minuti, non sarebbe molto un rischio a meno che il valore di tali informazioni per un utente malintenzionato non superi il costo del tempo del crittografo).

Progettare un sistema in modo che possa essere reso robusto contro qualcuno con dati interni, tuttavia, è molto più difficile , e ci sono pochissime persone con sufficiente esperienza per progettare un sistema che potrebbe - cambiando una chiave - essere reso robusto da qualcuno che avesse sia una conoscenza interna completa del design che l'esperienza in crittografia. Un esperto di crittografia senza una conoscenza interna potrebbe dover verificare centinaia o migliaia di potenziali errori che un designer potrebbe aver commesso, ma la conoscenza interna potrebbe consentire a quella persona di identificare e sfruttare immediatamente un errore.

Penso che la tua domanda ignori concetti importanti.

L'utilizzo del proprio sistema e la dipendenza dalla sicurezza del proprio sistema sono due concetti completamente diversi.

Usare il tuo codice personalizzato come ulteriore livello di difesa mentre usi il codice standard del settore per avere anche la sicurezza standard del settore va bene. Usare il proprio codice non testato e non provato come unica linea di difesa non ha senso.

Se il tuo codice è rilevante solo se l'attaccante ha già violato tutte le tue misure di sicurezza standard del settore e lo hai come "ultima linea di difesa", non puoi perdere nulla con quello.

Se il tuo codice è esposto e può avere falle di sicurezza sfruttabili? Se è la tua unica linea di difesa? Questa è una decisione stupida.

Mi piace l'idea di crearne uno tuo. La cosa sulle scoperte matematiche / crittografiche oggi è che è difficile, probabilmente impossibile, ottenere una revisione tra pari. Perché probabilmente è tanto o più lavoro controllare qualunque cosa si presenti quanto elaborarla. Questo NON dovrebbe scoraggiare il divertimento dell'esplorazione e della scoperta. Gli schemi asimmetrici sono più difficili, più impantanati in matematica e, per me, sono stati più imbarazzanti facili da rompere. Metodi simmetrici, meno. Penso che un buon metodo simmetrico dovrebbe operare su flussi di bit (non byte o blocchi) (ogni bit di dati che influisce sul domino ogni altro bit) e crittografare diciamo 10000 0 per sembrare completamente diverso da un blocco crittografato di 9999 0 e uno incorporato 1 ( nessuno dei metodi potenti di cui sono a conoscenza, ad esempio rijndael, DES, ecc., può farlo). E se un singolo bit della chiave, per quanto lungo, è sbagliato, la decrittazione dovrebbe fallire completamente, poiché in output non è riconoscibile un testo normale. Niente di sbagliato negli algoritmi proprietari. Solo un altro ostacolo per l'NSA da superare.

Il codice di esempio citato da Phil Zimmermann:

Un semplice flusso di numeri pseudocasuali è stato aggiunto al flusso di testo in chiaro per creare testo cifrato.

è facilmente contrastato. Alcuni hanno chiesto perché. Ecco perché:

1. Passaggio 1, inserisci il testo cifrato in chiaro di tutti gli 0. Poiché 0 aggiunto a qualsiasi numero è uguale al numero non modificato, espone completamente il flusso di numeri pseudocasuali nell'output.

2. Passaggio 2, dato quello che hai scoperto nel passaggio 1 e, dato il testo criptato di un messaggio segreto, puoi facilmente calcolare il testo originale mediante la semplice sottrazione del flusso di numeri pseudo casuali che ora conosci.

Detto questo , Non sono d'accordo con l'idea generale che inventare il proprio codice sia quasi brutto. Qualsiasi algoritmo di cifratura, alla prima creazione, ha uno stato di forza di sicurezza SCONOSCIUTO, anche quelli creati da esperti. Gli esperti hanno il vantaggio di essere in grado di applicare immediatamente i tipici attacchi noti e vedere come sta il nuovo codice, ed essere in grado di escludere rapidamente alcune invenzioni come deboli, e gli amatori non hanno questa capacità. Ma non significa necessariamente che il codice sia debole. Significa che la forza è sconosciuta e potrebbe essere un codice molto forte. Semplicemente non lo sai.

Ad esempio, non sono un esperto. Ecco una cifra banale che ho trovato in 5 secondi senza pensarci troppo:

1. Scegli un numero casuale di 128 bit come chiave.
2. circolare Ruota la chiave di X numero di bit, Chiama il valore del risultato A.
3. Circolare ruota la chiave di Y numero di bit, dividila in due parti a 64 bit e moltiplicale per produrre un valore B.
4. I valori XOR A e B per produrre una nuova chiave, utilizzare solo il bit 0 sul bit N-1 di questa chiave per crittografare N bit di testo normale mediante XOR.
5. Torna indietro e ripeti i passaggi 2,3,4 .

Questo sembra essere abbastanza semplice e non ho fatto alcuna analisi per vedere quanto sia forte. Ma tutto quello che posso dire è che questo ha una forza di sicurezza sconosciuta. Potrebbe essere molto forte. Se salti immediatamente alla conclusione per dire che è debole o inaffidabile, ti sfido a trovare un metodo per risolverlo. Puoi?

Penso che quando si tratta della forza della sicurezza, ce ne siano solo due:

1. Forza della sicurezza sconosciuta
2. Forza della sicurezza debole nota

Non esiste una cosa nota come una forte forza di sicurezza. Se lo schema è stato esaminato molto senza trovare un crack, significa solo che non è stato ancora trovato alcun crack e lo stato rimane sconosciuto, e non significa necessariamente forte, perché un crack potrebbe essere scoperto domani.