OpenSSL che crittografa l'overhead della larghezza di banda dei pacchetti di piccole dimensioni

1

Ho un programma c / c ++ usato per crittografare i dati per comunicare tra due estremità. La crittografia viene eseguita utilizzando OpenSSL (0.9.8d-fips, settembre 2006). Pensa che sarà interessante menzionare che non ho molta familiarità con l'uso di OpenSSL.

Il programma funziona bene per pacchetti più grandi. Ma l'overhead delle dimensioni è molto alto quando si crittografa pacchetti di dimensioni più piccole. Ho fatto un test per dimostrare il problema.

+-------------+-----------------+-------------------+
| Input Chars | Encrypted Chars | Input/Encrypted % |
+-------------+-----------------+-------------------+
|           1 |              74 | 1.351351351       |
|           2 |              74 | 2.702702703       |
|           3 |              74 | 4.054054054       |
|           4 |              74 | 5.405405405       |
|           5 |              74 | 6.756756757       |
|           6 |              74 | 8.108108108       |
|           7 |              74 | 9.459459459       |
|           8 |              74 | 10.81081081       |
|           9 |              74 | 12.16216216       |
|          10 |              74 | 13.51351351       |
|          11 |              74 | 14.86486486       |
|          12 |              90 | 13.33333333       |
|          13 |              90 | 14.44444444       |
|          14 |              90 | 15.55555556       |
|          15 |              90 | 16.66666667       |
+-------------+-----------------+-------------------+

Il test è stato eseguito durante l'incremento del numero di caratteri di input da 1 a 10000. I seguenti grafici illustrano i risultati in modo più chiaro.

Grafico 1: dimensioni crittografate e dimensioni di input

Grafico2:rapportorispettoalladimensionedell'input

Dal secondo grafico, è chiaramente visibile che il sovraccarico della crittografia è molto alto per gli input più piccoli (dimensioni inferiori a 300 byte).

Questo è normale / accettabile? Se è così ci sono alternative (con meno spese generali). Poiché l'applicazione utilizza pesantemente pacchetti più piccoli (raggrupparli insieme non è un'opzione).

Come menzionato sopra, viene utilizzato OpenSSL 0.9.8d, che è una versione un po 'più datata (1.0.1g, aprile 2014, è ora disponibile). Il problema verrà risolto se lo aggiorno?

    
posta Anubis 29.05.2014 - 13:05
fonte

3 risposte

3

- Ciao, questa è la linea diretta di TastyChef, come posso aiutarti?

- Ciao. Sto cucinando. Devo sapere per quanto tempo dovrei mettere il mio cibo nel forno.

- Dipende da cosa stai cucinando, signore.

- Oh, è un forno Miele-Samsung 1200+. Il numero di serie è X67NQ-56D3034.

- Non il forno, Signore.

- Pensi che la sostituzione del forno con un 1500+ cambierebbe il tempo di cottura?

- ...

Ciò che conta è il protocollo che stai usando, che si riduce agli algoritmi coinvolti e ai formati di codifica. Devi capire cosa stai cercando di fare. In questo momento, sembra che tu usi "OpenSSL" come una specie di condimento crittografico, nella speranza selvaggia che spargere la crittografia farà in qualche modo avvenire la sicurezza. Non succede in questo modo.

Dicono che l'ingegneria del software inizia con l'architettura, poi con l'analisi, poi con le specifiche, quindi con l'implementazione (e solo successivamente). Se salti i primi tre passaggi, il quarto condurrà a doom.

    
risposta data 29.05.2014 - 13:31
fonte
1

I dati SSL vengono inseriti nei record e ogni record ha un sovraccarico di circa 25..40 byte (vedi link ). Più piccoli sono i tuoi frammenti di dati, più evidente è questo overhead. Oltre a SSL, c'è anche un sovraccarico per pacchetto dagli altri livelli, ad es. TCP, IP, ethernet ....

Il sovraccarico non è specifico di OpenSSL, ma è comune a tutte le implementazioni SSL.

    
risposta data 29.05.2014 - 15:15
fonte
1

Anche questo overhead potrebbe rivelarsi utile (non andrei fino a dire che è di design, quindi): ad esempio, se avessi una mappatura 1-a-1, un avversario sarebbe in grado di determinare cosa tipo di traffico che stai inviando osservando la lunghezza del pacchetto senza doverlo decodificare.

Questo, a sua volta, potrebbe perdere alcune informazioni e in base alle circostanze. Vedi ad esempio questo articolo:

Packet headers identify the destination and source addresses and the size of the payload data, along with other information. The address and packet size information is usually sufficient to identify which page a target user downloads

    
risposta data 29.05.2014 - 18:29
fonte

Leggi altre domande sui tag