Probemos ...
Primero, creo un archivo de 500 MBytes lleno de bytes aleatorios:
dd if=/dev/urandom of=/tmp/foo bs=1000000 count=500
luego lo cifro usando GnuPG, midiendo el tiempo que lleva ese proceso (" keyID
" es el UID de la clave pública que estoy usando):
time gpg -r "keyID" --cipher-algo AES256 --compress-algo none -o /tmp/bar --encrypt /tmp/foo
Tiempo total en mi máquina (Intel i7 a 2.7 GHz, modo de 64 bits, GnuPG 2.0.22):
3.77s user 0.55s system 99% cpu 4.328 total
así que un ancho de banda de encriptación de 115 MB por segundo: ¡eso no es tan malo! Ahora intentemos de nuevo, pero esta vez sin desactivar la compresión (es decir, eliminemos las opciones " --compress-algo none
"):
20.99s user 0.79s system 98% cpu 22.038 total
que es 5 veces más lento. Así que ahí lo tienen: no es el cifrado lo que es "lento", es la compresión (aunque más de 20 MB / s todavía pueden ser bastante rápidos para muchos usos).
115 MB / s es consistente con una implementación "portátil" de AES. El código que utiliza los opcodes AES especializados (que están disponibles en mi i7) sería más rápido, digamos, 300 a 400 MB / s (aunque los códigos de operación AES-NI tienen un rendimiento muy alto, también tienen una latencia no despreciable, lo que significa que el mejor rendimiento requiere un procesamiento paralelo, es decir, CTR mode ; pero el OpenPGP standard exige CFB , que es secuencial).
De todos modos, dado que un buen disco duro mecánico alcanza aproximadamente los 120 MB / s, mientras que un muy buen acceso a Internet (fibra óptica) estará por debajo de 10 MB / s, se puede decir que 115 MB / s de velocidad de cifrado sin formato es suficiente.