Transmisión cifrada de datos: coste computacional
Sección [Seguridad] Fecha [2003-10-29] Hora [03:10] Ya hemos visto que cifrando realmente no comprimimos los datos, sino que esto lo hace gpg por su cuenta (gracias Draco). El aumento de tamaño de los datos tampoco es especialmente espectacular así que aún podemos considerar la transmisión de datos cifrados siempre como algo posible.
Vamos a empezar con una clave de 1024bits y un tar de X bytes. Pero antes de hacer las pruebas vamos a dejar los datos de la máquina (los importantes):
Procesador: Pentium III 750MHz
Memoria: 384MB (128+256) SODIMM PC133
Disco duro: Toshiba de 4200RPM y 10GB. 3 particiones (1 swap, 1 ReiserFS para /usr y una ext3 para el resto del sistema).
Sistema: Knoppix 3.3 instalada en el disco duro, medio actualizada a sid.
Resultados del hdparm en el HD:
root@wardriver:/home/pj/pruebas# hdparm -Tt /dev/hda /dev/hda: Timing buffer-cache reads: 428 MB in 2.01 seconds = 212.94 MB/sec Timing buffered disk reads: 48 MB in 3.02 seconds = 15.89 MB/sec
Versiones de los programas a usar:
pj@wardriver:~$ tar --version tar (GNU tar) 1.13.25 pj@wardriver:~$ gpg --version gpg (GnuPG) 1.2.3 pj@wardriver:~$ gzip --version gzip 1.3.5 (2002-09-30) pj@wardriver:~$ bzip2 --version bzip2, a block-sorting file compressor. Version 1.0.2, 30-Dec-2001.
Creación del tar: tar cvf /usr/X11R6/bin/
Resultado:
pj@wardriver:~/pruebas$ ll total 35252 -rw-r--r-- 1 pj pj 36055040 Oct 28 19:41 binarios.tar
Pruebas:
1) Cifrado usando gpg sin compresión
pj@wardriver:~/pruebas$ time gpg -e -z0 binarios.tar You did not specify a user ID. (you may use "-r") Enter the user ID. End with an empty line: prova Added 1024g/E4714C9E 2003-10-27 "prova (prova)" real 0m7.023s user 0m4.540s sys 0m0.750s pj@wardriver:~/pruebas$ ll total 70504 -rw-r--r-- 1 pj pj 36055040 Oct 28 19:41 binarios.tar -rw-r--r-- 1 pj pj 36055383 Oct 28 19:45 binarios.tar.gpg
Marca 4 segundos de user time pero realmente he estado apenas medio segundo escribiendo el identificador (prova) y dando al enter dos veces.
2) Cifrado usando gpg con compresión
pj@wardriver:~/pruebas$ time gpg -e binarios.tar You did not specify a user ID. (you may use "-r") Enter the user ID. End with an empty line: prova Added 1024g/E4714C9E 2003-10-27 "prova (prova)" Enter the user ID. End with an empty line: real 0m19.640s user 0m16.030s sys 0m0.540s
Creo que no hacen falta más pruebas para ver porqué no se transmite hoy en día con claves de 1024bits y que cuando sí se transmite cifrado es con claves mucho más pequeñas como los 128bits o incluso 256bits del WEP y los típicos 128bits de las "páginas seguras".
¿Porqué esto es así? En las redes, incluida Internet, suele ser muy importante la latencia en las comunicaciones pues los sistemas cortan la conexión cuando el otro comunicante no responde en X tiempo (=tiene una latencia muy alta). Si hacemos una petición a un sitio web para bajarnos un fichero de datos confidenciales y la máquina tiene que cifrarlo bajo petición nos tendremos que esperar 7 segundos a recibir una respuesta y 19 segundos si lo queremos comprimido.
Para envios puntuales no dudo que pueda servir, pero en esos casos el cifrado se hace manualmente antes del envio de forma que no avisamos del envio ni recibimos la petición del archivo hasta que este esté cifrado. Este caso sería el de los correos electrónicos que, además, suelen tener un tamaño reducido.
Conclusión:
El coste computacional sigue siendo muy elevado. Imaginen una conexión ethernet de 100Mbps recibiendo datos a tope que otra máquina está cifrando y enviando. La máquina cifradora no va a poder servir a tiempo los datos, tengan en cuenta que si para 35MB hemos necesitado 7s de tiempo imaginen cuanto necesitaremos por segundo para servir más o menos 10MB/s.
Comenta (1) comentario/s
Referencias (TrackBacks)
URL de trackback de esta historia http://simbiosis.blogalia.com//trackbacks/12464
Comentarios
| 1 |
|
||
|
FANTASIA EROTICA
|
|||
