Quale crittografia a chiave privata devo usare per la comunicazione da server a server?

2

Sono tentato di scrivere il mio che copre:

  • Checksum per garantire che i dati non vengano manomessi.
  • Tasti lunghi e rotanti multipli in modo che sia (praticamente) impossibile decodificare.
  • Utilizzerà /dev/random per il seed iniziale

Altri elementi più elusivi che probabilmente non verranno affrontati:

  • In base ai frammenti di dimensioni dei dati e al modello di connessione, un intercettore può indovinare le cose sui dati senza visualizzare i dati; quale protocollo, come viene utilizzato.
  • Gli IP di origine e di destinazione danno un indizio di identità.
  • Le intestazioni TCP e IP possono contenere informazioni sul sistema operativo.

Anche se sono molto fiducioso, c'è il rischio che ci sia qualcosa che mi manca che non realizzerò mai: Lezioni apprese e idee sbagliate riguardanti crittografia e crittologia

Quindi cosa dovrei usare se dovessi evitare di scrivere il mio? I fattori importanti sono

  • Velocità
  • Somma di controllo
  • Mi piacerebbe sapere quanti dati ci vogliono prima che la chiave finisca e verrà riutilizzata.

Oppure scrivere la mia crittografia è una buona idea in questo caso?

    
posta George Bailey 11.07.2011 - 18:01
fonte

2 risposte

4

is writing my own encryption is a good idea in this case?

No. Approfitta della conoscenza, dell'esperienza e del lavoro dei professionisti che hanno trascorso decenni a progettare algoritmi di crittografia.

impossible to decrypt.

Qualsiasi crittografia può essere decodificata semplicemente provando ogni possibile chiave con un algoritmo e controllando se l'output ha senso. Pertanto, in genere ci riferiamo a quanto lavoro ci si aspetta che un utente malintenzionato esegua prima di decifrare un messaggio.

Un algoritmo è considerato sicuro contro una certa classe di aggressori quando si stima che l'autore dell'attacco non possa decifrare il messaggio entro un periodo di tempo pertinente .

Se proteggi contro una singola persona con una piccola quantità di attrezzatura per la vendita al dettaglio, il fattore di lavoro previsto è basso. Se proteggi contro le risorse informatiche di un paese industrializzato, il fattore di lavoro previsto è enorme.

Speed

La velocità dipende dalla dimensione della chiave. Diversi algoritmi moderni supportano dimensioni di chiavi multiple. Basato su Valutazione delle prestazioni degli algoritmi di crittografia simmetrica sembra che Blowfish sia veloce, ma Blowfish non è stato accuratamente controllato come AES.

ensure data is not tampered with.

Checksum

I checksum, gli hash e i codici di autenticazione dei messaggi (MAC) non si riferiscono necessariamente all'algoritmo di crittografia scelto. Tuttavia alcuni algoritmi hanno modalità che eseguono la crittografia e l'autenticazione. Galois / Counter Mode è una modalità che viene utilizzata in un numero o standard. AES-GCM è un esempio di un algoritmo che fornisce crittografia e autenticazione.

how much data it takes before the key runs out and is going to be re-used.

Come @ Thomas-Pornin ha detto che questo non è applicabile ai moderni algoritmi di crittografia. È prassi comune utilizzare dati casuali per generare chiavi e i dati casuali non si esauriscono. Si potrebbe fare riferimento al problema di non ripetere un vettore di inizializzazione (IV, noto anche come Nonce), ma non sono sicuro.

Based on the size chunks of data and connection pattern, an interceptor can guess things about the data without seeing the data; what protocol, how is it being used.

Sì, questi sono generalmente noti come attacchi a canali laterali. Ci sono misure che puoi prendere per attenuare alcuni attacchi di canale laterale e che riguardano principalmente la protezione della trasmissione.

Source and destination IPs give an identity clue.

Sì, ma il tentativo di nascondere la tua presenza è probabilmente uno sforzo maggiore di quello che vale.

TCP and IP headers are liable to contain OS information.

I pacchetti di rete possono aiutare un utente malintenzionato a prendere le impronte digitali nel sistema, ma penso che sia più importante concentrarsi su una buona sicurezza operativa, specialmente sulle politiche e sulle procedure che influiscono sulla sicurezza.

So what would I use if I was to avoid writing my own?

Per rispondere, dovremmo modellare il fattore di lavoro della classe di aggressori prevista, la latenza e il throughput desiderati e le risorse di calcolo disponibili. Tuttavia, la mia ipotesi è che alcune modalità di AES siano adatte a te.

    
risposta data 11.07.2011 - 22:58
fonte
7

Scrivere la propria crittografia è mai una buona idea. Anche i crittografi addestrati (intendo persone che hanno studiato l'argomento per anni, hanno un grande diploma brillante [un dottorato] per dirlo e, cosa più importante, hanno fatto e pubblicato ricerche reali) non pensare a usando un algoritmo o protocollo che hanno progettato prima di averlo sottoposto per l'ispezione da parte dei loro colleghi per diversi anni.

Più aneddotico:

  • "Checksum" è un termine ampio; i crittografi preferiscono Codice di autenticazione dei messaggi , che è molto più preciso.
  • "Tasti lunghi e rotanti multipli": sembra un romanzo di Dan Brown e, per quanto riguarda la sicurezza, è non una buona cosa.
  • Non utilizzare /dev/random , usa /dev/urandom .
  • "Quanti dati ci vogliono prima che il tasto si esaurisca e verrà riutilizzato": questa frase ha senso solo se si considera il tipo di sistemi di crittografia utilizzati durante la prima guerra mondiale, vale a dire prima del invenzione del computer.

Non conosco alcun modo per affermarlo: ti senti sicuro, ma non dovresti davvero.

Utilizza TLS (il nuovo nome standard per SSL).

    
risposta data 11.07.2011 - 18:19
fonte

Leggi altre domande sui tag