Perché usiamo un linguaggio ridondante (inglese) per le comunicazioni di rete? [chiuso]

Question

Perché usiamo un linguaggio ridondante (inglese) per le comunicazioni di rete? [chiuso]

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

0

Ho sentito in tutta la rete che l'inglese è incredibilmente ridondante. Quindi, perché trasformiamo i messaggi in inglese in un codice che è quindi, dalla mia comprensione più vulnerabile all'analisi della frequenza delle lettere (LFA). Penso che sarebbe più vulnerabile a LFA perché qualcuno che cerca di decifrare il messaggio avrebbe solo bisogno di ottenere una certa percentuale delle lettere corrette. Perché non usare qualcosa in cui l'hacker richiederebbe una percentuale molto più alta di corrispondenze alle lettere? O sto parlando da tempi antichi e la LFA non è un problema con le cifre più recenti?

modifica: avrebbe più senso usare un linguaggio meno ridondante, forse un linguaggio personalizzato specifico per le comunicazioni di rete in cui i nodi di origine e destinazione hanno un software di traduzione?

Grazie:)

encryption

posta someSortOfProgrammer 17.08.2014 - 13:41

fonte

3 risposte

Leggi altre domande sui tag encryption

Quanto è sicuro la scatola virtuale senza internet [duplicato] C'è qualcosa di simile ai generatori pseudocasuali, ma nella direzione opposta?

score 2 · Answer 1

Non usiamo l'inglese per "comunicazione di rete", utilizziamo i protocolli di rete. Le cose che le persone dicono nel linguaggio naturale sono di solito molto meno interessanti di quelle che i computer si dicono l'un l'altro.

LFA dipende dalla definizione di una "lettera". In inglese e ASCII (o più probabilmente UTF-8) codifica, questo corrisponde a un byte. Per fare questo tipo di analisi, quindi, è necessario un cifrario a byte singolo come XOR o un codice Caesar. Puoi fare cose simili con un codice Vigenère, con un po 'più di lavoro. Tuttavia, questi non sono di uso comune: solitamente usiamo cifrari a blocchi o cifrari a flusso.

I codici a blocchi in modalità ECB (Electronic Code Book) sono soggetti all'analisi della frequenza dei blocchi, che non è infallibile, ma è comunque un attacco valido. A scale più grandi, questo è ciò che sta dietro la demo di "vedere il pinguino".

Se qualcosa di questo è interessante per te, altamente ti consiglio di provare le Crypto Challange di Matasano , che prenderà attraverso l'implementazione pratica di veri attacchi crittografici, dall'analisi di frequenza su cifrari XOR a oracle padding e attacchi ripetuti nonce.

score 1 · Answer 2

Molto spesso non usiamo l'inglese diretto. Eseguiamo algoritmi di compressione sui dati. Se osservi la documentazione di OpenPGP suggerisce di comprimere i messaggi prima di crittografarli.

Gli algoritmi di compressione rimuovono la ridondanza.

score 1 · Answer 3

Ritengo che la domanda che chiedi nel titolo non sia completa. Nel tuo post ti chiedi perché usiamo l'inglese se possiamo usare le frequenze lettera per decodificare i codici (testo crittografato).

Il motivo è perché noi umani possiamo capirlo più facilmente e perché non è un grosso problema. I protocolli progettati per la velocità sono binari per evitare overhead (ad esempio SPDY), ma quando è stato progettato HTTP era molto più conveniente avere un protocollo basato su testo.

Certo, possiamo creare strumenti per leggere il traffico per noi e, il più delle volte, lo facciamo. Ma a volte il compromesso tra le dimensioni extra e l'aumento della leggibilità rende sensato (fatto?). Il fatto che tu possa craccarlo quando lo cifri usando un cifrario non sicuro non è un problema con il protocollo, è un problema nel codice di crittografia.

Inoltre, impedisce davvero di crackare il codice se l'algoritmo di crittografia è così rotto? Io non la penso così La maggior parte delle pagine web contiene parole o elementi comuni, non è necessario un protocollo di rete basato su testo per questo.

Modifica: leggi la tua domanda un po 'più attentamente e vedi questo:

is LFA not so much of a problem with the more recent ciphers?

No, non lo è. LFA è solo un problema con i codici di crittografia che sono insicuri per progettazione. I cifrari come AES, RSA, DES, Twofish, Camellia e praticamente tutto ciò che usiamo al giorno d'oggi, sono sicuri. Basta non provare a inventare la tua crittografia, andare con gli standard e andrà bene.