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.