Perché i risultati del benchmarking di Truecrypt e cryptsetup (LUKS) sono così diversi?


10

Voglio crittografare una parte del mio HDD. Ma prima volevo confrontare i diversi algoritmi disponibili chiedendomi se avrei dovuto scegliere aes-xts-256o aes-xts-512.

Nota: non ho aesaccelerazione hardware. I parametri di riferimento sono stati ripetuti più volte senza grandi cambiamenti. Vorrei affermare chiaramente che questi benchmark sono validi solo sul mio computer (Debian, core 2 duo). Questo non vuole essere un confronto LUKS-TrueCrypt completo.

TL; DR: vai alla parte 4


1- Cryptsetup

Quindi ho scaricato cryptsetup v1.6.0per utilizzare il nuovo cryptsetup benchmarkcomando.

Comando

$cryptsetup benchmark

risultati

 #  Algorithm | Key | Encryption |  Decryption
     aes-cbc   128b   128,2 MiB/s   157,2 MiB/s
 serpent-cbc   128b    49,6 MiB/s    57,7 MiB/s
 twofish-cbc   128b   138,0 MiB/s   183,8 MiB/s
     aes-cbc   256b    97,5 MiB/s   121,9 MiB/s
 serpent-cbc   256b    51,8 MiB/s    57,7 MiB/s
 twofish-cbc   256b   139,0 MiB/s   183,8 MiB/s
     aes-xts   256b   156,4 MiB/s   157,8 MiB/s
 serpent-xts   256b    55,7 MiB/s    58,7 MiB/s
 twofish-xts   256b   161,5 MiB/s   165,9 MiB/s
     aes-xts   512b   120,5 MiB/s   120,9 MiB/s
 serpent-xts   512b    55,7 MiB/s    58,5 MiB/s
 twofish-xts   512b   161,5 MiB/s   165,3 MiB/s

Pensieri

  • In cbcmodalità, serpentè sorprendentemente veloce nel decifrare!
  • In xtsmodalità, serpentè chiaramente il più veloce.
  • Le dimensioni della chiave sembrano non avere quasi alcun effetto evidente su .serpent twofish
  • aes non si comporta bene quando si aumenta la dimensione della chiave.

Aggiornamenti dalla VM


2- TrueCrypt

Sono rimasto davvero sorpreso perché aesè noto per essere il più veloce (anche senza accelerazione hardware). Quindi ho scaricato TrueCryptper ricontrollare questi risultati. TrueCryptusa la xtsmodalità di default quindi presumo che la usi anche nei suoi benchmark.

Metodo

  1. Strumenti> Benchmark
  2. Scegli qualsiasi dimensione del buffer (qui, 5 MB)
  3. Fai clic su "Benchmark"

risultati

 #  Algorithm | Encryption |  Decryption
         AES     106 MB/s      107 MB/s
     Twofish      78 MB/s       76 MB/s
     Serpent      41 MB/s       42 MB/s

Pensieri

Questi risultati corrispondono molto di più a ciò che ci si aspetta, ma non corrispondono bene ai cryptsetuprisultati.


3- Pensieri generali

  • cryptsetupha fornito prestazioni generali migliori rispetto TrueCrypta questo caso. Questo potrebbe essere spiegato nel modo seguente:
    • cryptsetupè stato compilato sul mio sistema con routine di ottimizzazione del compilatore mentre TrueCryptera già compilato in modo generico;
    • AFAIK cryptsetuputilizza moduli di crittografia kernelspace mentre TrueCryptutilizza routine di crittografia spazio utente.
  • Tuttavia, non riesco a spiegare perché serpent-xts-512sembra essere la strada da percorrere cryptsetupmentre aes-xtsl'unico codice vale la pena usare.

4- Domanda

cryptsetupe TrueCryptfornire risultati qualitativi (velocità di cifratura relativa) e quantitativi (velocità effettiva di ogni cifra) completamente diversi nei benchmark in-RAM.

  • È qualcosa che hai già notato?
  • Devo fidarmi cryptsetupe usare la serpent-xts-512crittografia per la velocità?

Risposte:


5

Non hai accelerazione hardware AES e stavi eseguendo i test in una macchina virtuale. È improbabile che i risultati dei test riflettano i risultati del mondo reale, poiché le velocità di crittografia / decrittazione dipendono fortemente dagli attuali carichi di CPU e disco. La soluzione migliore è creare due partizioni Truecrypt indipendenti ed eseguire benchmark manuali copiando alcuni file di grandi dimensioni da / verso ciascuna partizione.

Anche LUKS e Truecrypt hanno implementazioni leggermente diverse e, come hai detto, "questi benchmark sono validi solo sul mio computer". È necessario testare effettivamente entrambi sul sistema con trasferimenti di file effettivi per determinare le prestazioni effettive.


Per quanto riguarda le differenze, Truecrypt utilizza FUSE per implementare un filesystem nello spazio utente, mentre LUKS viene di solito eseguito nel kernel reale. Per questo motivo, è probabile che si ottenga un throughput migliore in un sistema Linux utilizzando LUKS / dm-crypt / cryptsetup rispetto a Truecrypt, anche se quale opzione si sceglie dipende dai requisiti della crittografia (ad es. Le partizioni Truecrypt possono essere trasferite tra le operazioni sistemi se necessario).


Strano: ho provato direttamente nel mio sistema e praticamente tutto è salvo, serpentche è diventato molto più lento. Quindi il problema con il serpente è risolto. Twofishè ancora più veloce che aesin cryptsetup e più lento in TrueCrypt. E non ho alcuna aesaccelerazione hardware ... questa non è una cosa da VM ...

Ho aggiornato i risultati.

@Gael cryptsetupsarà più veloce rispetto TrueCryptagli stessi algoritmi di crittografia poiché TrueCryptviene eseguito in FUSE(file system spazio utente), mentre cryptsetuputilizza LUKS, che è un modulo del kernel. Ho citato la macchina virtuale come se steste eseguendo altri programmi nel sistema operativo host (anche attività in background), influenzerebbe i risultati dei benchmark.
Breakthrough

1

Il kernel Linux ha moduli Serpent ottimizzati SSE2 e AVX per accelerare i carichi di lavoro parallelizzabili (come la decrittografia CBC e XTS enc & dec).

Le prestazioni di Serpent nella decrittografia CBC e XTS con quei moduli caricati dovrebbero essere quasi allo stesso livello del software AES e Twofish (leggermente più veloce o più lento a seconda del modello esatto di CPU).


0

Si noti inoltre che il codice SSE2 eseguito dal kernel guest in alcune macchine virtuali è molto più lento rispetto al kernel host. L'ho sperimentato con Oracle VirtualBox. Pertanto, i risultati per Serpent su VM potrebbero non essere necessariamente correlati alle prestazioni previste sull'host reale.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.