| Arador | bien, me gustaria dar la bienvenida a todos en la presentacion final del dia, james morris de intercode |
|---|
| Arador | <jamesm> hola, gracias por venir! |
|---|
| Arador | ;) |
|---|
| Arador | su presentacion sera del nuevo sistema critografico que ayudo a introducir en el kernel 2.5 |
|---|
| Arador | jems tambien ha estado en el proyecto LSM |
|---|
| Arador | las preguntas a #qc |
|---|
| Arador | <james> una nueva api de criptografica se añadio recientemente en le kernel 2.5 |
|---|
| Arador | que sera parte de la proxima rama estable del kernel 2.6 |
|---|
| Arador | esta api fue desarrollada inicialmente para soportar la impplementcaion de pisec de David Miller y Alexey Kuznetsov |
|---|
| Arador | (que tambien esta en el kernel 2.5) |
|---|
| Ricardo | s/pisec/ipsec/ |
|---|
| Arador | Tambien intenta ser una api generica para usar con otros componentes del kernel |
|---|
| Arador | que requieren criptografica, como CIFS, crypthologyloop y el driver /dev/random |
|---|
| Arador | actualmente, es un api muy simple, con una interfaz de plguins para modulos con algoritmos |
|---|
| Arador | algoritmos implementados hasta el momento |
|---|
| Arador | Digests: SHA1, SHA256, MD4, MD5 |
|---|
| Arador | estos ¡s se usan para verificar la integridad de los datos y para crear firmas digitales y codigos de autenticacion para la red |
|---|
| Arador | Ciphers: Blowfish, DES, 3DES, Twofish, Serpent. (AES esta en desarrollo) |
|---|
| Arador | (ciphers=cifrado) |
|---|
| Ricardo | cifradores, incluso :-) |
|---|
| Arador | estos son algoritmos de encriptacion simetricos, donde tu (normalmente) usas la misma llave para codificar y descodificar, y la llave debe guardarse |
|---|
| Arador | la mayoria de las aplicaciones de encriptacion usan una combinacion de la intgridad de datos y encriptacion |
|---|
| Arador | <sarnold> jamesm: Hariais mi vida mas facil si incluyerais algoritmos asimetricos tambien ;) |
|---|
| Arador | el soporte asimetrico esta siendo considerado, seria util para forma de codigo y ipsec multicast |
|---|
| Arador | y ciertamente nos gustaria permitir al espacio de usuario tomar ventajas del hardware de encriptacion asimetrica disponible |
|---|
| Arador | porque esto es muy lento en software |
|---|
| Arador | <shonX>jamesq: puede esta API de criptografia ser usada para SSH/SSL? o todavia necesitamos depender del software en la criptografia a nivel de software? |
|---|
| Arador | todavia no, y tendria sentido cuando el api provee accesso a aceleracion de hardware |
|---|
| Arador | la api provee el algoritmo HMAC para resumenes (usado por ipsec) y CBC |
|---|
| Arador | y modo CBC para cifrados (estao encadena los resultados de la ultima encriptacion al proximo, para incrementar la seguridad, y es muy usado) |
|---|
| Arador | actualmente, la api ha sido probada con ipsec. Alguun trabajo podria ser requerido para que funcionara bien con cryptoloop |
|---|
| Arador | una caracteristica especifica de la aip es que opera en arrays de vectores de paginas (scatterlists) en vez de con buffers de memoria plana (las paginas son las unidades basicas de memoria que le kernel puede manejar) |
|---|
| Arador | esto permite una integracion mas profuna con otros componentes del kernel como la pila de red, y provee una interzas dispersion/reunion |
|---|
| Arador | (en espacio de usuario, una interfaz de dispersion/reunion es readv()/writev(), la api crypto usa un concepto similar en las paginas en vez de buffers planos) |
|---|
| Arador | <sarnold> creo que cryptoloop podria necesitar usar el modo ECB para accesoo aleatorio a los bloques...es correcto? |
|---|
| Arador | por lo que yo se, cryptoloop usa el modo ECB, y configura el IV hacia algo derivado del bloque del disco |
|---|
| Arador | asique la idea principal de operar en paginas y dispersion/reunion es la eficiencia |
|---|
| Arador | las paginas son fundamentales para el kernel, y dispersion/reunion permite a los datos ser transformados sin copiarlos al a un buffer |
|---|
| Arador | esto puede ser descontinuado a nivel del hardware, y usar generacion de DMA de dispersion/reunion |
|---|
| Arador | asi como David Miller ha diseñado parte de esto, se espera un gran rendimiento |
|---|
| Arador | seria bueno comparar nuestro rendimiento contra openbsd, quien ya tiene inegrado crypto |
|---|
| Arador | en el caso de ipsec, el diseño de la api crypto permite a las transformacions de crypto ser aplicadas directamente a paginas de memoria discontiguas ser asociadas con paquetes de red (por ejemplo, listas de fragmentos IP, paginas de copia cero ser transmitidas por sendfile()) |
|---|
| Arador | parece que funciona bien por ahora, pero no hemos hecho optimizaciones de rendimiento todavia, o intentado aceleracion de hardware |
|---|
| Arador | <addict> sabes porque linux no lo integro antes? |
|---|
| Arador | ha habido un parche de crypto disponible por algun tiempo (de la gente de kerneli.org) pero creo que asuntos legales no permitieron a crypto de ser plenamente integrado en el kernel hasta ahora |
|---|
| Arador | openbsd tiene cripto integrado porque esta desarrollado fuera de los EEUU |
|---|
| Arador | la apl actualmente funciona en el lugar de los datos, aunque podria ser modificado pronto |
|---|
| Arador | para permitir diferentes listas de dispersion de entrada/salida para cryptoloop |
|---|
| Arador | trabajo futuro: |
|---|
| Arador | Optimizar en ensamblador los algoritmos es algo que no ha sido implmentado todavia |
|---|
| Arador | todo son versiones en C |
|---|
| Arador | Se ha hecho trabajo para soportar dispositivos de hardware criptograefico, que podria ser util para incrementar el rendimiento y la escalabilidad |
|---|
| Arador | (notad que algunas personas, como Linus, tienen dudas de lo util que podrian ser las tarjetas de hardware, porque envolveria copiar los datos a traves del bus pci, cuando las cpus de hoy en dia son muy rapidas, es un gran area a ser analizada) |
|---|
| Arador | <sh0nx> con la nueva criptografia, esta toda la memoria protegida mientras se usa? |
|---|
| Arador | <sarnlod><shonx> la memoria del kernel no se pùede paginar al disco |
|---|
| Arador | cuando se desarrollo al api del espacio de usuaio, esto podria ser un asunto |
|---|
| Arador | <addict>estas buscando hardware criptografico como powercrypt? |
|---|
| Ricardo | [cuando se desarrolle el api en espacio de usuario, esto podría ser un problema] |
|---|
| Arador | si, tengo una vieja tarjeta powercruypt (hifn7751) y algunas tarjetas soekris (que son muy baratas) |
|---|
| Arador | de particular interes son las tarjetas de red que tiene chips criptograficos en ellas |
|---|
| Arador | esas tarjetas permite que se copien los paquetes una vez a traves del bus pci a la tarjeta |
|---|
| Arador | dondo los paquetes puede encriptarse y transmitirse a la red sin retraso |
|---|
| Arador | copiando a traves del bus |
|---|
| Arador | desafortunadamente, no tenemos todavia ninguna documentacion de esas taejetas |
|---|
| Arador | una api en el espacio de usuario esta siendo diseñada para permitir a aplicaciones (como SSL, IKE) que tomen ventaja del hardware disponible |
|---|
| Arador | la api del espacio de usuario sera como un pseudo sistyema de archivos (cryptoapifs quizas) y los dispositivos caracter seran usados para acceder a las caracteristicas de criptografica del kernel y del hardware) |
|---|
| Arador | asi como la api trabaja en paginas, deberiamos poder hacer cosas mas interesantes mmap()eando los dispositivos caracter |
|---|
| Arador | la api del espacio de usuario tambien permitira una bateria de pruebas mucho mas limpia y extensa |
|---|
| Arador | el codigo actual de puruebas es un modulo del kernel muy muy feo |
|---|
| Arador | <sarnlod>jamesq: ha sido discutido usar el /dev/crypto de openbsd? |
|---|
| Arador | si, estaria bien proveer una capa de compatibilidad, aunque no ha sido muy analizado todavia |
|---|
| Arador | los primeros pasos para el soporte de hardware son obtener tarjetas, documentacion y escribir drivers GPL (mucho trabajo) |
|---|
| Arador | estamos intentando conseguir tantas tarjetas differentes como podasmo para sentender los requerimientos genericos |
|---|
| Arador | es donde el soporte para la criptografia asimertica sera sonsiderada, asi como muchas tarjetas lo ofrecen ya, y es mucho mas rapido en hardware |
|---|
| Arador | recursos: |
|---|
| Arador | http://samba.org/~jamesm/crypto/ (updates, status, patches etc.) |
|---|
| Arador | http://www.kerneli.org/pipermail/cryptoapi-devel/ (discusiones de desarrollo) |
|---|
| Arador | las fuentes del kernel estan bajo el directorio crypto en los kernels 2.5 recientes |
|---|
| Arador | la documentacion en el directorio Documentation/crypto (que incluye creditos detallados) |
|---|
| Ricardo | El número de marzo de 2003 de Linuex Journal saldrá con un artículo sobre la API |
|---|
| Ricardo | esto es todo lo que he preparado, de manera que si alguien tiene preguntas o quiere comentarlo... |
|---|
| Ricardo | <addict> jamesm: estaría bien que pegaras también esta URL: http://www.openbsd.org/crypto.html |
|---|
| Ricardo | (recuerden, las preguntas se hacen en #qc, si alguien quiere que las traduzcamos, me la puede hacer en privado, o en el canal, directamente) |
|---|
| Ricardo | <sarnold> jamesq: cómo le sugerirías a alguien intentar implementar, por ejemplo RSA, para la API de plugins? |
|---|
| Ricardo | aún no lo sé, pero Jean-Luc Cooke ha estado trabajando en eso |
|---|
| Ricardo | vean http://jlcooke.ca/cryptoapi/pk/ y los comentarios en cryptoapi-devel |
|---|
| Ricardo | no es un aspecto que haya tenido tiempo de mirar con detalle aún |
|---|
| Ricardo | <riel> jamesq: ¿leíste mi idea al respecto de "random ipsec" (ipsec aleatorio) sin autenticación? ¿te parece útil o necesita realmente ipsec autenticación para ser útil? |
|---|
| Ricardo | ups. Creo que me he adelantado :))) |
|---|
| Ricardo | bueno, es igual :-) Al final han pillado esa pregunta ;) |
|---|
| Ricardo | creo recordar haber leído algo al respecto de esto ayer, o algo así, pero no recuerdo los detalles |
|---|
| Ricardo | pero creo que ipsec necesita autenticación en general para ser seguro |
|---|
| Ricardo | <riel> básicamente, la idea es tener una cosa como "ipsec por defecto" que negocio cifrado con máquinas desconocidas |
|---|
| Ricardo | <riel> de manera que gran parte del tráfico de internet vaya cifrado |
|---|
| Ricardo | <riel> y el esnifado pasivo de tráfico masivo se vuelva prohibitivamente costoso |
|---|
| Ricardo | no tengo idea de todas las implicaciones criptográficas, y habría que analizarlo más |
|---|
| Ricardo | en realidad abre la puerta a nuevos ataques |
|---|
| Ricardo | (si decides confiar en datos sin autenticar, por ejemplo) |
|---|
| Ricardo | <riel> jamesq: ahh, pero la cosa no va sobre confianza en sí, sino en hacer prohibitivo hacer esnifado pasivo sobre tráfico masivo |
|---|
| Ricardo | una idea interesante |
|---|
| Ricardo | ¿más preguntas sobre la api? |
|---|
| Ricardo | bueno, vale, hemos llegado al final de mi presentación, y creo que hay algo de interés en discutir temas de criptografía más general |
|---|
| Ricardo | Bueno. |
|---|
| Ricardo | Hemos abierto #linux |
|---|
| Ricardo | Y #redes |
|---|
| Ricardo | Intentaré traducir algo de lo que se hable, pero supongo que irán demasiado rápido :-) |
|---|
| Ricardo | <sarnold> jamesq: ¿algo al respecto de la idea de theo sobre reservar un procesador para tareas de criptografía en máquinas SMP? |
|---|
| Ricardo | <riel> sarnold: probablemente no sea lo más inteligente |
|---|
| Ricardo | <jamesm> sarnold: en realidad, no |
|---|
| Ricardo | <riel> sarnold: en ese caso el tráfico de red tendría que pasar de la caché de una CPU a RAM para pasar a la de la otra CPU |
|---|
| Ricardo | <jamesm> además, |
|---|
| Ricardo | <jamesm> <garoeda> ¿cómo puede beneficiarse un usuario normal de esto? |
|---|
| Ricardo | <riel> probablemente sería más rápido que cada paquete de red sólo toque una CPU |
|---|
| Ricardo | <addict> sarnold: sería mucho más lento |
|---|
| Ricardo | <jamesm> lo principal para los usuarios es que la criptografía estará integrada en el núcleo, de manera que cosas como ipsec, y el cifrado de discos se convierta en parte del núcleo principal |
|---|
| Ricardo | * riel le compra a jamesm una cerveza virtual |
|---|
| Ricardo | Bueno. Ahora vienen toda suerte de aplausos y agradecimientos :) |
|---|
| viZard | :-) |
|---|
| Ricardo | <sarnold> jamesm: ¿piensas que el dispositivo de bloques de cifrado necesita que se implementen las dos listas de dispersión/juntado? |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| viZard | plas plas plas plas plas plas plas plas plas |
|---|
| sarnold | cervezas para todos.. |
|---|
| Ricardo | thanks sarnold :) |
|---|
| Arador | sarnold: ¡gracias! ;) |
|---|
| Ricardo | <jamesm> sarnold: necesita bien listas de dispersión (scatterlists) de entrada/salida (difícil), o quizá podamos proporcionar acceso directo a los algoritmos subyacentes de criptografía mediante envoltorios de la api |
|---|
| Ricardo | <Arador> no se mucho de ipsec y criptografía, pero podría explicar un poco más riel su idea para tontos (ya que todo el mundo parece estar interesado ;)? |
|---|
| Ricardo | <sarnold> Arador: el ipsec común necesita que ambos puntos se "autentifiquen" entre sí |
|---|
| Ricardo | <riel> Arador: jamesm es el experto en cifrado, yo no se mucho al respecto |
|---|
| Ricardo | <sarnold> Arador: lo cual precisa relaciones de confianza preestablecidas |
|---|
| Ricardo | <sarnold> Arador: La idea de riel es que ambos puntos puedan hablar ipsec entre ellos sin necesidad de que haya habido autentificación |
|---|
| Ricardo | <sarnold> Arador: (err, pero hablándose entre ellos mediante conexiones cifradas/"autenticadas"...) |
|---|
| Ricardo | <sarnold> Arador: esto, como mínimo, haría mucho más difícil esnifar una conexión de red (necesitaría un ataque "man in the middle" activo) |
|---|
| Ricardo | <sarnold> Arador: e interceptar una sesión activa se volvería mucho más difícil que sin ipsec, aunque no tan difícil como con una conexión ipsec completamente autentificada |
|---|
| Ricardo | <sarnold> Arador: si no estoy equivocado, aquí es donde IKE y pluto y ... ? otros protocolos de negociación de clave son útiles; podrían negociar claves sobre la marcha con quien sea |
|---|
| Ricardo | <Arador> osea, cifrar todo para asegurar el tráfico en general? |
|---|
| Ricardo | <sarnold> Arador: con otros destinos capaces de trabajar con ipsec, sí |
|---|
| Ricardo | bueno :-) Luego vienen más agradecimientos, y esas cosas ;) |
|---|
| Arador | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| Arador | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| Arador | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| Arador | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| Arador | plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas |
|---|
| Arador | :-) |
|---|
| Ricardo | gracias, gracias |
|---|
| Ricardo | pero sólo merezco reconocimiento por la última parte |
|---|
| * Ricardo señala a Arador |
| Arador | que no es poco XD |
|---|
| Ricardo | mh... |
|---|
| Ricardo | Casi había olvidado que jfs iba a dar una charla :-) |
|---|
| Ricardo | Todos los años da una :-) |
|---|
| Arador | quien es jfs? |
|---|
| Ricardo | Javier Fernández-Sanguino Peña |
|---|