Proviamo ...
Per prima cosa, creo un file di 500 MByte pieno di byte casuali:
dd if=/dev/urandom of=/tmp/foo bs=1000000 count=500
quindi lo crittografo utilizzando GnuPG, misurando il tempo impiegato da quel processo (" keyID
" è l'UID della chiave pubblica che sto usando):
time gpg -r "keyID" --cipher-algo AES256 --compress-algo none -o /tmp/bar --encrypt /tmp/foo
Tempo totale sul mio computer (Intel i7 a 2.7 GHz, modalità a 64 bit, GnuPG 2.0.22):
3.77s user 0.55s system 99% cpu 4.328 total
quindi una larghezza di banda di crittografia di 115 MByte al secondo: non è così male! Ora proviamo ancora, ma questa volta senza disattivare la compressione (ad esempio, rimuoviamo le opzioni " --compress-algo none
"):
20.99s user 0.79s system 98% cpu 22.038 total
che è 5 volte più lento. Ecco qua: non è la crittografia che è "lenta", è la compressione (anche se più di 20 MB / s possono ancora essere decentemente veloci per molti usi).
115 MB / s è coerente con un'implementazione "portatile" di AES. Il codice che utilizza gli codici opzionali AES specializzati (che sono disponibili sul mio i7) sarebbe più veloce, fino a, ad esempio, da 300 a 400 MB / s (sebbene gli opcode AES-NI abbiano un throughput molto elevato, hanno anche una latenza non trascurabile, il che significa che le migliori prestazioni richiedono l'elaborazione parallela, ovvero Modalità CTR , ma lo standard OpenPGP richiede CFB , che è sequenziale).
In ogni caso, dal momento che un buon hard disk meccanico supera a circa 120 MB / s, mentre un ottimo accesso a Internet (fibra ottica) sarà inferiore a 10 MB / s, si può dire che 115 MB / s di velocità di crittografia grezza sia sufficiente.