Reunión de desarrolladores de I2P - 12 de septiembre de 2006

16:06 <jrandom> 0) hola 16:06 <jrandom> 1) 0.6.1.25 y estado de la red 16:06 <jrandom> 2) I2PSnark 16:06 <jrandom> 3) Syndie (qué/por qué/cuándo) 16:06 <jrandom> 4) preguntas de criptografía de Syndie 16:06 <jrandom> 5) ??? 16:06 <jrandom> 0) hola 16:06 * jrandom saluda 16:06 <jrandom> notas semanales de estado publicadas en http://dev.i2p.net/pipermail/i2p/2006-September/001307.html 16:07 <jrandom> puesto que esas notas salieron hace horas y horas, ya deberían haberlas leído y tener notas listas, ¿no? ;) 16:07 <jrandom> saltando a 1) 0.6.1.25 y estado de la red 16:08 <vulpine> <Complication> Con respecto a 0.6.1.25, parece haber funcionado bien por aquí, solo un error no visto antes 16:08 <jrandom> genial, ¿cuál es el problema? 16:08 <vulpine> * Complication busca en los registros 16:09 <jrandom> el tamaño de la red parece mayor que antes, aunque sigue siendo del mismo orden de magnitud 16:09 <vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840" 16:10 <vulpine> <Complication> Empezó con "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)" 16:10 <jrandom> ah ok, genial, ese ha estado desde hace mucho tiempo, se puede ignorar con seguridad 16:11 <vulpine> <Complication> Ocurrencia única 16:11 <vulpine> <frosk> he recibido varios de ese último 16:11 <vulpine> * jrandom le da un toque a fox 16:12 <vulpine> <Complication> Oh, y uno más: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ" 16:12 <vulpine> <Complication> (parece no significativo también, quizá simple congestión) 16:12 <jrandom> sí, probablemente 16:13 <jrandom> irc está, obviamente, un poco inestable en este momento todavía 16:13 <jrandom> (pero, por una vez, no es culpa de i2p :) 16:14 <jrandom> ok, ¿alguien tiene algo más para 1) Estado de la red y 0.6.1.25? 16:15 <kostya213> solo quiero añadir que la .25 arregló todos los problemas que he tenido los últimos meses 16:15 <jrandom> ¡brutal! 16:16 <vulpine> <green> por favor, cambien el cálculo de estado cuando solo se use NTCP 16:16 <jrandom> 'k, pero no se recomienda deshabilitar udp (creo que he dicho explícitamente que tampoco les voy a decir cómo deshabilitar udp) 16:17 <jrandom> pero el estado debería actualizarse para tener en cuenta que udp no es el único transporte 16:17 <jrandom> lo corregiré en la próxima revisión, gracias 16:17 <vulpine> <green> jrandom : claro que no lo dices, pero soy capaz de leer código ;) 16:18 <jrandom> cierto, aunque cuando no recomiendo algo y le digo a la gente que ni lo intente, no se sorprendan si aparece un mensaje en pantalla confuso ;) 16:19 <vulpine> <green> claro, también podría simplemente mostrar "OK" en la consola :) 16:19 <jrandom> cierto 16:21 <jrandom> ok, pasemos a 2) I2PSnark 16:21 <jrandom> zzz no parece estar por ahí ahora mismo 16:22 <jrandom> hay algunos cambios en los que zzz está trabajando para mejorar la planificación en i2psnark 16:23 <jrandom> (es un poco... simplista ahora mismo, si no recuerdo mal, aunque no estoy completamente seguro de los mods en los que zzz está hackeando) 16:23 <jrandom> ((¡pero espero con ganas el progreso!)) 16:25 <jrandom> ok, si no hay nada más sobre 2) I2PSnark, sigamos a 3.*) cosas de Syndie 16:26 <jrandom> entremos primero en 3.1) ¿qué es syndie?, ya que hay mucho que cubrir 16:27 <jrandom> recibí algunas preguntas antes de la reunión sobre el cifrado de las publicaciones 16:27 <jrandom> básicamente, las publicaciones están cifradas de forma simétrica: cualquiera con la clave simétrica puede leer la publicación, pues están autorizados 16:28 <jrandom> las respuestas del canal se cifran asimétricamente para la clave pública asociada con el canal/foro 16:28 <jrandom> algunas publicaciones pueden usar cifrado basado en frase de paso para generar la clave simétrica para leer 16:29 <jrandom> y algunas publicaciones pueden incluir la clave simétrica en las cabeceras legibles de la publicación (para que cualquiera pueda leerla) 16:29 <modulus> ¿cuál es el sentido de esa última? 16:29 <jrandom> y algunos foros en sí pueden incluir la clave simétrica en los metadatos del foro, para que cualquiera pueda leer la publicación pero solo si tienen los metadatos del canal 16:29 <jrandom> modulus: para que todo esté siempre cifrado, incluso el material de lectura pública 16:29 <jrandom> (para que las escuchas triviales sean inútiles) 16:30 <modulus> bien, ya veo. 16:31 <jrandom> ok, creo que eso cubre las preguntas de cifrado que se hicieron antes de la reunión 16:31 <jrandom> ¿alguien tiene preguntas sobre 3.1) ¿qué es syndie? 16:31 <jrandom> (quiero decir, se aclarará más a medida que se publique, por supuesto) 16:32 <vulpine> <void> hmm 16:33 <jrandom> que tal void? 16:33 <vulpine> <void> <void> supongo que el archivo de mensajes (.zip) también puede incluir otros mensajes, posiblemente de otras personas, como los mensajes citados? 16:34 <jrandom> bueno, sí, puedes incluir archivos .snd como adjuntos, pero hay un espacio de nombres explícito, así que puedes hacer enlaces estilo References: a mensajes anteriores 16:34 <jrandom> (o sea, no tienes que hacer 'threading' al estilo frost) 16:35 <vulpine> <void> ok, correcto 16:37 <vulpine> <Complication> Sobre Syndie, me preguntaba cómo resolverían las personas el problema de dar acceso a un foro con múltiples autores (como cuentas en un tablón de mensajes normal) pero sin otorgarlo irrevocablemente, y evitando el desorden indeseado cuando surge la necesidad de revocar el acceso (por cualquier motivo) 16:38 <vulpine> <Complication> Una solución, por supuesto, parecía que el autor especificara una recomendación sobre de quién deberían mostrar los clientes las respuestas 16:38 <jrandom> Complication: crea un nuevo par de claves pública/privada, da la clave privada a las personas autorizadas (temporalmente) e incluye la clave pública como la lista de "claves permitidas para publicar" 16:38 <vulpine> <Complication> ..y que los clientes, salvo que quieran investigar el historial, sigan esta recomendación (o más específicamente su última versión) 16:38 <jrandom> (y cuando ya no estén autorizados, quita esa clave de la lista de "claves permitidas para publicar") 16:39 <kostya213> jrandom: podrías querer usar una extensión diferente a .snd ya que es una extensión ampliamente usada para aplicaciones de audio; MIME la confundirá 16:39 <jrandom> ah, correcto: todos los foros tienen un "propietario" (una clave privada de firma) que puede gestionar la lista de quién puede publicar, etc. 16:39 <vulpine> <Complication> ¿"claves permitidas para publicar" serían metadatos adjuntos a la última publicación del autor, o a algún otro mensaje, cierto? 16:39 <jrandom> buen punto, kostya213, aunque entonces quizá nos quedemos con .dat ;) 16:40 <jrandom> Complication: ah perdón, no, es como el syndie actual/antiguo: publicaciones de metadatos firmados por separado para el propio foro/canal 16:40 <vulpine> * Complication cree que alguien incluso ha reclamado .dat para algo :) 16:40 <jrandom> sí, la aplicación llamada "octet-stream" ;) 16:40 <vulpine> <void> no parece que .syn se use para nada digno de mención 16:41 <vulpine> <Complication> Ajá, publicaciones especiales de metadatos... bien, eso podría servir 16:41 <jrandom> oh, qué bien, ¡llegamos a syn! 16:41 <jrandom> (buen ojo, void, gracias, kostya213) 16:41 <vulpine> <void> hmm, 16:41 <vulpine> <void> hmm, "Word Synonym File", Empresa: Microsoft 16:42 <jrandom> bueno, seguro que lo solucionaremos 16:42 <kostya213> sí, lo usa Word 16:42 <vulpine> <void> pero podríamos ignorar eso :) 16:42 <kostya213> no pierdas la esperanza, creo que es posible encontrar algo que no cause problemas con tipos MIME ampliamente usados 16:43 <jrandom> ok, ¿algo más sobre 3.1) ¿Qué es syndie? 16:43 <vulpine> <void> eh, pensándolo bien, ¿por qué nos limitaríamos a extensiones de tres letras? es una reliquia de la era DOS 16:43 <kostya213> una cosa que hay que preguntar: ¿por qué limitarlo a una extensión de tres letras? nadie usa DOS ya 16:44 <jrandom> jeje 16:44 <kostya213> jinx con void 16:44 <kostya213> .syndie me parece bien 16:44 <vulpine> <void> .synd no entraría en conflicto con ninguna 16:44 <kostya213> también bueno 16:45 <vulpine> <void> maldito lag :( 16:48 <jrandom> ok, pasemos a 3.2) ¿Por qué importa Syndie? 16:48 <vulpine> <void> jrandom: espera 16:48 <cervantes> (porque dices que sí) 16:48 * jrandom espera 16:48 <jrandom> !thwap cervantes ;) 16:48 <vulpine> <void> la publicación de notas de estado menciona que se puede adjuntar un avatar a una publicación; de lo contrario se usará uno predeterminado 16:49 <vulpine> <void> pero ¿qué si una persona quiere tener varios avatares predefinidos en lugar de uno único "predeterminado"? 16:49 <jrandom> sí, el autor puede incluir un avatar predeterminado en los metadatos de su propio canal 16:49 <vulpine> <void> adjuntar el otro cada vez no va a ser eficiente 16:49 <jrandom> buena pregunta, void: vamos a ese código de script en las notas 16:50 <jrandom> listauthkeys --authorizedOnly true 16:50 <jrandom> authenticate 0 16:50 <vulpine> <void> (?) 16:50 <jrandom> listauthkeys mostrará todas las identidades con las que puedes firmar el mensaje diciendo que eres tú, mientras que "authenticate 0" elige una identidad con la que firmar 16:51 <jrandom> entonces, esa identidad tiene su propio canal, y ese canal tiene sus propios metadatos, que pueden incluir un avatar 16:51 <vulpine> <void> hmm, ¿una identidad separada significa un par de claves separado? 16:51 <jrandom> sí 16:51 <vulpine> <void> ¿y si una persona quiere tener varios avatares en una sola identidad? 16:52 <jrandom> tienen un avatar predeterminado en los metadatos de su canal, y pueden sobrescribirlo por mensaje 16:52 <kostya213> valor dudoso 16:52 <vulpine> <void> varios avatares "predeterminados" entre los que puede elegir 16:52 <vulpine> <void> ¿o estoy hilando demasiado fino? :) 16:53 <jrandom> ah, entiendo lo que dices. no, no estará soportado al principio 16:53 <jrandom> quizá después 16:53 <vulpine> <void> cierto, kostya213, entonces olvida eso 16:53 <vulpine> <void> :) 16:53 <jrandom> (pero los avatares estarán muy limitados en tamaño, así que no debería ser mucho problema incluirlos) 16:53 <vulpine> * Complication piensa que añadirlos por mensaje podría codificarse para que sea suficientemente fácil 16:53 <vulpine> <void> entonces, 3.1) ¿Qué es syndie? 16:53 <vulpine> <Complication> (eventualmente) 16:54 <vulpine> * cervantes pega juntos los servidores irc 16:54 <vulpine> <void> Complication: jrandom justo dijo que ya va a hacer eso :) 16:54 <jrandom> (los por-mensaje estarán en la base, complication; la idea de tener muchos 'predeterminados' para elegir, seleccionándolo al decir "usar avatar 1" en un mensaje en vez de incluir el propio avatar) 16:54 <vulpine> <Complication> latencia, latencia... 16:54 <jrandom> ok, ¿algo más para 3.1? 16:54 <jrandom> si no, pasemos a 3.2 16:55 <vulpine> <void> creo que eso es todo 16:55 <jrandom> wr0d. 16:56 <jrandom> aparte de la pulla de cervantes, ¿alguien tiene preguntas/comentarios/preocupaciones sobre el "por qué"? 16:56 <jrandom> (ejem, "preocupaciones") 16:58 <vulpine> <Complication> cervantes: ¿limpiaste la superficie con alcohol antes de aplicar el pegamento en el ircd? ;) 16:58 <kostya213> en mi opinión, Syndie no necesita justificación, su valor debería ser evidente para cualquiera que ya esté interesado en redes de anonimización 16:58 <kostya213> y consciente de los peligros de la centralización de la información 16:59 <vulpine> <Complication> (republicación, por favor ignora si llegó al servidor) 16:59 <vulpine> * Complication piensa que Syndie importa porque un usuario promedio (Joe Sixpack) con phpBB sería hackeado muy rápido, y Joe Sixpack ejecutando $random_blogging_tool también lo sería 16:59 <vulpine> <Complication> (aunque la probabilidad pueda variar) 16:59 <vulpine> <void> en efecto 16:59 <jrandom> sí, además de cualquiera que enfrente adversarios realmente hostiles (ni siquiera necesariamente a nivel estatal) 17:00 <jrandom> ok, bien, solo quería pasarles estas cosas 17:00 <jrandom> ¿algo más sobre 3.2, o pasamos a 3.3) ¿cuándo podemos usar Syndie? 17:01 <vulpine> <void> bueno, esencialmente es una herramienta de foro/blog/correo/comunicación basada en primitivas criptográficas e independiente de una capa de transporte 17:01 <vulpine> <Complication> ...y en el escenario remoto en que el adversario de Joe Sixpack montase ataques de intersección, cualquiera que ejecute un eepsite de cualquier tipo acabaría siendo hackeado (salvo en una red enorme) 17:01 <kostya213> podría ser más difícil de vender para quienes no ven un valor inmediato en la privacidad/el anonimato 17:01 <jrandom> kostya213: sí, aunque quizá podamos aplicar algunos trucos, como poder navegar sin conexión de forma segura 17:02 <vulpine> <Complication> Podrían apreciar la seguridad de todos modos 17:02 <jrandom> (p. ej., un lector de RSS sin conexión que también traiga el conjunto completo de páginas referenciadas, no solo el resumen RSS) 17:02 <vulpine> <void> así que sí, no veo por qué necesita justificación :) 17:02 <vulpine> <void> kostya213: no necesitan ser anónimos para usar Syndie 17:02 <cervantes> ¿cuándo podemos usar Syndie o cuándo será usable? 17:02 <jrandom> cierto, void :) 17:03 <cervantes> para la interfaz de texto imagino que se necesita una cantidad bastante grande de documentación de uso 17:03 <jrandom> cervantes: ahora mismo, Syndie es funcional (puedes crear publicaciones, gestionar canales, leer publicaciones, responder a publicaciones, etc.) 17:03 <kostya213> jrandom: ¿cómo maneja Syndie la redundancia? ¿Qué tan resistente es contra la desaparición de contenido? 17:03 <cervantes> (antes de que sea usable) 17:03 <jrandom> cervantes: hay menús en línea con cada comando documentado (al menos mínimamente) 17:04 <cervantes> genial, ¿planes para algunos ejemplos de casos de uso? 17:04 <jrandom> kostya213: Syndie trabaja en la capa de contenido: la redundancia la maneja otra cosa. si publicas en usenet, se replica en usenet (por ejemplo) 17:04 <cervantes> creo que el truco será aprender cómo se encadenan todos los scripts 17:04 <vulpine> <void> kostya213: eso está fuera del alcance de Syndie, depende del mecanismo de transporte 17:04 <vulpine> <void> por desgracia 17:04 <jrandom> buena idea, cervantes 17:05 <jrandom> la primera versión de Syndie incluirá un sistema de replicación http como el Syndie antiguo/actual 17:05 <jrandom> cervantes: quizá algunos de los usuarios beta puedan armar sus scripts favoritos para que los distribuyamos :) 17:05 <modulus> mmm, ¿esto es una aplicación de consola? 17:05 <jrandom> modulus: sí, la primera aplicación basada en texto 17:06 <modulus> ¡excelente! 17:06 <cervantes> jrandom: siempre que los usuarios beta puedan averiguar cómo usarla ;-) 17:06 <jrandom> jeje 17:06 * jrandom consideró curses/etc, así como solo CLI, pero una interfaz de texto interactiva y scriptable probablemente sea lo más simple y útil 17:07 <jrandom> (sin GUI, claro) 17:07 <cervantes> modulus: ves, jrandom escuchó tus comentarios implacables :) 17:07 <vulpine> <Complication> Si la gente quiere, probablemente puedan construir interfaces textuales más interactivas encima 17:07 <jrandom> sí, ciertamente 17:08 <jrandom> (el código está hecho para soportar integración fácil con un cliente irc, como pircbot) 17:08 <modulus> cervantes: jeje 17:09 <modulus> supongo que también podrías ponerle una GUI encima, si funciona más o menos como imagino 17:09 <modulus> aunque eso sería mucho más trabajo. 17:09 * kostya213 espera el plugin de Emacs 17:09 <modulus> jajaja 17:09 <jrandom> jeje 17:09 <modulus> en realidad, un modo de Emacs no es tan mala idea, quizá atraería a más chiflados. 17:10 <cervantes> presiona ctrl-alt-shift-break-flecha arriba-num7-b para elegir tu identidad 17:10 * jrandom dejará que los elispers lo hackeen ;) 17:10 <kostya213> sin ánimo de ofender, pero no estoy seguro de que este proyecto necesite atraer a más chiflados 17:10 <vulpine> <Complication> ¿ese tipo de chiflados también programarían? 17:11 <jrandom> con suerte, complication 17:11 <jrandom> ok, con suerte 3.3) explica un poco lo que viene 17:11 <jrandom> en cuanto a *cuándo*, bueno, ya veremos, pero espero que "pronto" ;) 17:12 <jrandom> ok, ¿alguien tiene algo más para 3.3)? 17:12 <vulpine> * Complication daría la bienvenida a unas cuantas hordas de esos chiflados entonces :D 17:12 <cervantes> bueno, está programar y luego está escribir perl ofuscado interpretado en tcl 17:12 <kostya213> un plugin para FUSE también podría ser útil 17:13 <jrandom> sí 17:13 <jrandom> ok, pasemos a 4) cripto para Syndie 17:13 <jrandom> ¿alguien tiene comentarios sobre esos temas? 17:14 <vulpine> <Complication> Ojalá, pero no soy competente para estimar la fortaleza de esos cifrados/hashes/longitudes de clave 17:15 <vulpine> <void> ¿qué tan largas son las firmas ElGamal/RSA? ¿4 kbit para una clave de 2 kbit? 17:15 <vulpine> * Complication deja esa charla enteramente para otros 17:15 <jrandom> no lo sé de memoria 17:15 <vulpine> <void> ¿frente a DSA? 17:16 <jrandom> (aunque ECC se ve bonita y pequeñita) 17:16 <modulus> Las firmas ElGamal son complicadas y largas. como descubrió el equipo de GnuPG. 17:16 <jrandom> sí, aunque algunos de esos trucos estaban relacionados con la reutilización de claves 17:16 <vulpine> <void> ah, ok 17:16 <vulpine> <void> sí, así es 17:16 <tethra> modulus: si son duras y largas, hay un sitio fetish para eso 17:17 <jrandom> ok, ese punto era realmente solo un aviso y una llamada a comentarios cuando tengan ideas 17:17 <cervantes> ¿no sería posible implementar algún tipo de cifrados enchufables? cuando se estandarice un método mejor de creación de claves podremos añadirlo a Syndie y las nuevas publicaciones comenzarán a usarlo, pero aún se podrán usar métodos obsoletos para publicaciones antiguas 17:17 <tethra> (perdón) 17:17 <jrandom> cervantes: incluye un prefijo DSA:, así que un prefijo Elg: funcionaría 17:17 <modulus> ¿estás usando DSA limitado a 1024 o no? 17:18 <modulus> también, ¿qué hash? ¿sha1 o revisiones de orden superior? 17:18 <cervantes> así que realmente te preocupa arrancar Syndie con buen pie 17:18 <jrandom> DSA es solo de 1024 bits (hay propuestas DSA2 para más largos, pero aún no están estandarizadas) 17:18 <jrandom> y sí, DSA requiere sha1 17:18 <modulus> hmm, mi entendimiento es que eran bastante fuertes antes de los estándares. 17:18 <kostya213> cervantes tiene un buen punto; tener contenido de Syndie en cifrados fijos ofrece poca confidencialidad futura, nunca se sabe cuándo un algoritmo se irá al carajo 17:18 <modulus> pero no sigo el proceso lo bastante de cerca, así que probablemente tengas razón 17:19 <jrandom> kostya213: pero la elección es mala para la cripto, así que deberíamos tener valores fijos cuando podamos 17:19 <jrandom> (malo por el anonimato) 17:19 <vulpine> <void> ¿saben por qué no hay más gente/protocolos usando ECC, en todo caso? ¿temen la falta de investigación, o solo les preocupa la compatibilidad? 17:19 <modulus> patentes. 17:20 <jrandom> patentes y FUD, y también algunas preocupaciones en la implementación 17:20 <vulpine> <void> ah, cierto, modulus 17:20 <modulus> por cierto, ¿hay una buena razón para usar DSA en vez de RSA-SHA512, por ejemplo? 17:20 <tethra> patentes y FUD y el Estado (oh cielos) 17:20 <modulus> no intento ser molesto, solo considerando que GPG, por ejemplo, ha ido por ese camino, entre otros. 17:20 <jrandom> no he revisado esa opción en años, modulus 17:21 <modulus> obviamente DSA es un estándar, lo cual habla a su favor, pero las claves son pequeñas y los hashes son débiles. no es que crea que vaya a acabar siendo el eslabón más débil ;-) 17:23 <cervantes> no propondría "opción", pero las nuevas versiones de Syndie empaquetarían cifrados (obligatorios) cada vez más seguros 17:23 <vulpine> <Complication> Dejar cierto margen en las estructuras para cambios futuros parece razonable, independientemente de cuál cripto actual resulte mejor, creo 17:23 <jrandom> sí, aunque eso implica recurrir a versiones más débiles/antiguas para interoperar 17:23 <jrandom> pero, ok, lo resolveremos 17:24 <jrandom> ok, pasemos a 5) ??? 17:24 <jrandom> ¿alguien tiene algo más que plantear para la reunión? 17:25 <cervantes> no poder leer las últimas publicaciones de tu fuente favorita es un buen incentivo para asegurarse de que todos se mantengan actualizados 17:25 <jrandom> hasta cierto punto 17:26 <cervantes> no=not 17:26 <jrandom> (sí, es un incentivo, pero la gente es perezosa/no está interesada en "actualizar software", etc.) 17:27 <jrandom> s/people/some people/ 17:27 <cervantes> supongo que ese es su problema, de todos modos 17:27 <jrandom> cierto eso 17:27 <kostya213> al menos la implementación de i2p puede tener actualizaciones indoloras 17:28 <jrandom> ciertamente 17:28 <cervantes> en cuanto a ???: disculpas por la conectividad irc; el ISP debería estar restaurando uno de sus principales carriers de red "lo antes posible" 17:29 <jrandom> w3wt 17:29 <vulpine> <Complication> Sobre el tema ???, quizá pueda añadir que la segunda (más extensa) parte de las modificaciones de NTP está cerca de funcionar, y espero tenerla comprometida para pruebas pronto 17:29 * cervantes toma una pizca de sal 17:29 <kostya213> ¿cuáles son los planes a corto plazo para el desarrollo del router? ¿es precisa la hoja de ruta? 17:29 <jrandom> ¡genial, complication! 17:29 <vulpine> <Complication> Su objetivo es contrastar a los servidores NTP basándose en las desviaciones de reloj de los pares 17:29 <jrandom> kostya213: estabilización hasta que salga Syndie 17:30 <jrandom> (desde mi perspectiva) 17:30 <vulpine> <Complication> (y evitar tomar acciones potencialmente dañinas para la conectividad) 17:31 <cervantes> genial 17:32 <jrandom> ok, ¿algo más para la reunión? 17:34 * jrandom concluye 17:34 * jrandom *baf* cierra la reunión