Reunión de desarrolladores de I2P, 29 de julio de 2003

--- Registro abierto Tue Jul 29 16:54:31 2003 17:11 <@hezekiah> Tue Jul 29 21:11:18 UTC 2003 17:11 <@hezekiah> La 51.ª (creo) reunión iip-dev. 17:11 <@hezekiah> Agenda: 17:11 <@hezekiah> 1.) Bienvenida 17:11 <@hezekiah> 2.) Cosas de jrand0m 17:11 <@hezekiah> 3.) Cualquier cosa de los demás desarrolladores 17:11 <@hezekiah> 4.) Cualquier cosa que nop añada cuando/si llegue 17:12 <@hezekiah> 5.) Preguntas y comentarios de las siempre ansiosas masas no lavadas. ;-) 17:12 <@hezekiah> ¡OK! 17:12 <@hezekiah> Bienvenidos todos a la 51.ª (creo) reunión iip-dev 17:12 <@hezekiah> ¡Punto número 2! 17:12 <@hezekiah> Cosas de jrand0m 17:12 -!- thetower [none@anon.iip] se ha unido a #iip-dev 17:12 * hezekiah le pasa el micrófono a jrand0m 17:12 <@jrand0m> sub-agenda: 17:12 <@jrand0m> 2.1) Estado de la especificación I2CP & dev 17:12 < co> ¿Dónde están los logs de la reunión 50? 17:12 <@jrand0m> 2.2) Planes del SDK 17:12 <@jrand0m> 2.3) criptografía 17:12 <@jrand0m> 2.4) hoja de ruta / estado del protocolo de red 17:13 <@hezekiah> co: cohesion está trabajando para subirlos 17:13 <@jrand0m> (por cierto, es "mic", de microphone) 17:13 <@hezekiah> jrand0m: Perdón. :) 17:13 <@hezekiah> jrand0m: (¡Y este error de un técnico de sonido!) 17:13 -!- luckypunk [~yetalohe@anon.iip] se ha unido a #iip-dev 17:13 -!- odargur [odargur@anon.iip] se ha unido a #iip-dev 17:13 <@jrand0m> 2.1) I2CP: la especificación se ha subido a CVS con una ligera modificación a uno de los mensajes (MessageStatusMessage) 17:14 <@jrand0m> Comentarios sobre I2CP siempre son bienvenidos, cuanto antes mejor. 17:14 <@hezekiah> jrand0m: ¿Dónde está la especificación en CVS? ... ¿y está también en el CVS de SF? 17:14 <@jrand0m> La razón de cuanto antes mejor es que tendremos una implementación de cliente Java funcionando para el viernes. 17:14 -!- some_random_guy [~dan@anon.iip] se ha unido a #iip-dev 17:14 * thecrypto cruza los dedos con eso 17:14 <@jrand0m> Además de un router solo local para fin de semana, eso espero 17:15 <@jrand0m> no hez, solo en la cathedral 17:15 <@jrand0m> buen punto, thecrypto. 17:15 <@jrand0m> Advertencia: 17:15 <@hezekiah> Uf. Todavía no consigo que CVS funcione con cathedral. 17:15 <@jrand0m> algo de crypto no está al 100%, pero todo está "stubbed" para poder enchufar implementaciones más completas u otras más adelante 17:15 <@jrand0m> hezekiah> te ponemos en marcha después de la reunión. 17:15 <@hezekiah> jrand0m: Gracias. :) 17:16 <@jrand0m> la especificación está en i2p/doc/specs/data_structure_spec/datastructures.html 17:16 <@jrand0m> thecrypto> ¿tienes algo que añadir sobre la implementación en Java? 17:16 -!- ArdVark [simple1@anon.iip] se ha unido a #iip-dev 17:16 <@jeremiah> el router solo local que mencionaste era el de python, ¿verdad? ¿o hay uno en java también? 17:17 <@jrand0m> depende :) 17:17 <@jrand0m> jeremiah/hezekiah> ¿cómo va el cliente en python y el router solo local? 17:17 <@thecrypto> no mucho, salvo el tema de crypto que creo que trataremos en un rato 17:17 <@jrand0m> de acuerdo, thecrypto. 17:17 <@hezekiah> jrand0m: Va avanzando. Ayer por fin hice funcionar lo del transporte TCP. 17:17 <@jeremiah> parece bien, creo que gran parte dependerá de la velocidad de desarrollo de hezekiah más que de la mía 17:17 <@hezekiah> jrand0m: Jeremiah tiene cosas lindas con las estructuras de mensajes. 17:18 <@hezekiah> hezekiah: Espero que podamos cumplir el plazo. 17:18 <@jrand0m> genial. 17:18 <@jeremiah> además... el viernes es mi cumpleaños, así que planeo no estar frente al ordenador ese día 17:18 <@hezekiah> jeremiah: Comprensible. :) 17:18 <@hezekiah> jeremiah: Y feliz cumpleaños por adelantado. :) 17:18 <@jeremiah> gracias 17:18 <@jrand0m> saltando un poco a la agenda 2.4> ¿cuándo podríamos tener el router solo local en python? ¿realistamente? 17:19 <@jrand0m> oye, si programas el viernes te pateo el trasero 17:19 <@jrand0m> al menos virtualmente 17:19 <@hezekiah> jrand0m: Pensé que eso es lo que estoy programando. El router solo local en Python. 17:19 <@jrand0m> sí, eso mismo 17:19 <@hezekiah> Pues la fecha límite es el 1 de agosto. 17:19 <@jeremiah> ahora estamos trabajando en el paso de mensajes a/de formato binario 17:19 <@hezekiah> Eso no es tan difícil. 17:19 <@jeremiah> sí 17:19 <@hezekiah> Espero tener eso hecho en un día o dos. 17:20 <@jrand0m> eso es el viernes :) 17:20 <@jrand0m> genial 17:20 <@hezekiah> Espero que esté listo para el 1 de agosto. Realistamente podría retrasarse unos días, pero espero que no. 17:20 <@jrand0m> vale, entonces no toco nada del Java del solo local y me pongo con la especificación de red después de fijar el API del cliente Java. 17:20 <@hezekiah> Sí. Las especificaciones son buenas. 17:21 <@hezekiah> ¡Me hacen el trabajo MUCHO más fácil! :) 17:21 <@jrand0m> eso. 17:21 <@jrand0m> También escribiré un recorrido rápido de 2 párrafos del banco de pruebas I2CP de Java 17:21 <@jrand0m> Lo saco esta noche 17:22 <@hezekiah> jrand0m: Me encanta cómo escribes estas especificaciones tan rápido. 17:22 <@hezekiah> Esto es divertido. :) 17:22 <@jrand0m> Ok, hez/jeremiah/thecrypto> ¿algo más sobre I2CP? 17:22 <@jrand0m> lol 17:22 -!- dm [~hifi@anon.iip] se ha unido a #iip-dev 17:22 <@hezekiah> Eh ... 17:22 <@hezekiah> ¡Quiero la especificación de crypto! 17:22 < dm> bienvenido 17:22 * hezekiah hace pucheros como un bebé 17:22 <@hezekiah> ;-) 17:23 <@hezekiah> En serio, ... no se me ocurre nada. 17:23 <@jrand0m> ese es el punto 2.3 de la agenda 17:23 <@thecrypto> aún esperando a que salga el 2.3 17:23 <@hezekiah> Si se me ocurre, entraré y te atosigaré con preguntas, jrand0m. :) 17:23 <@jrand0m> eso. 17:23 <@jrand0m> ok. 2.2) Planes del SDK 17:23 <@hezekiah> ¿Qué punto de la agenda acabamos de terminar? 17:23 <@hezekiah> ¿2.4? 17:23 <@hezekiah> ¿Y ya terminamos 2.1? 17:23 <@jrand0m> 2.1 17:24 <@jrand0m> ahora 2.2> el SDK 17:24 <@hezekiah> OK. 17:24 < dm> ¿la agenda tiene punto decimal ahora? Ya veo progreso. 17:24 <@hezekiah> Ahora estoy encontrado (en lugar de perdido). 17:24 <@thecrypto> podríamos tener 2 puntos decimales :) 17:25 <@jeremiah> ¿qué compone el SDK aparte de las varias APIs? 17:25 <@jrand0m> el SDK es: el API del cliente (tantos como tengamos), el router solo local, una app de ejemplo trivial, y algo de documentación sobre cómo usar las APIs. 17:25 <@hezekiah> jrand0m: ¿Sería correcto asumir que tú estás escribiendo la documentación? :) 17:26 <@jrand0m> Me gustaría publicar el SDK cuanto antes, para que desarrolladores de terceros (o incluso de segunda o primera parte) puedan escribir y probar aplicaciones que se ejecutarán sobre I2P, y así, cuando la red esté operativa, salgamos rodando a toda velocidad. 17:26 <@jrand0m> hezekiah> En realidad preferiría que no. 17:26 <@jrand0m> hezekiah> y lo digo no porque no quiera documentar, sino porque estoy demasiado involucrado. 17:26 <@hezekiah> jrand0m: OK. 17:26 <@jrand0m> deberíamos tener a alguien que NO implemente el código escribiendo ese documento, para que sea comprensible para personas que no escribieron la especificación de I2CP 17:26 <@hezekiah> jrand0m: Cruzaremos ese puente cuando lleguemos. 17:26 <@jrand0m> pero si hace falta, me pongo. 17:26 <@jrand0m> eso. 17:27 < dm> ¿qué incentivo tiene la gente para escribir apps sin una red operativa, y cómo probarían siquiera su app. 17:27 <@hezekiah> jrand0m: O por qué no que lo escriba quien diseñó el protocolo, y luego alguien que nunca trabajó con él lo repase hasta que tenga sentido? 17:27 <@jrand0m> Ok, ha habido algo de discusión sobre una app simple tipo 'talk'. 17:27 <@jrand0m> dm> la gente podrá probar con el SDK. 17:27 <@thecrypto> en realidad, me preguntaba cuál sería el uso si es solo local 17:28 <@jeremiah> dm: la idea es implementar una red simple que no esté completamente funcional pero pueda pasar mensajes 17:28 <@thecrypto> solo podrías hablar contigo mismo 17:28 <@jeremiah> no es realmente solo local, sino que solo incluye cliente-router, no código router-router 17:28 <@jrand0m> thecrypto> puedes hablar con otros Destinations. I2P es independiente de la ubicación: local es igual que remoto. 17:29 <@thecrypto> ok 17:29 < dm> está bien y todo, solo que no veo a nadie (aparte de ustedes 3-4) escribiendo nada si solo se puede probar localmente. Pero bueno, da igual. 17:29 <@jrand0m> así que una app talk puede abrir dos instancias de la aplicación y hablar con uno mismo, etc. 17:30 <@thecrypto> pero cuando añadamos lo remoto, la app debería simplemente funcionar 17:30 <@jrand0m> dm> exacto, esto es solo un prerequisito para que otros escriban apps. 17:30 <@jrand0m> exacto. 17:30 <@jrand0m> la app funcionará sin absolutamente NINGÚN cambio 17:30 < co> dm: Esta es una aplicación de prueba. Una vez que el código router-router esté escrito, podrás hablar con otros. 17:30 <@jeremiah> tener solo local nos permite desarrollar en paralelo 17:30 < dm> sí, pero si la app asume 10 ms de latencia, y termina siendo 12 segundos, no funcionará muy bien :) 17:31 <@jrand0m> de acuerdo dm 17:31 < dm> ¿alguna estimación de latencia por cierto? :) 17:31 <@jrand0m> si tenemos 12 segundos de latencia, tenemos trabajo que hacer. 17:31 <@jrand0m> pero no tendremos eso. 17:31 <@jrand0m> estimaciones son 0,6-2,7 s 17:31 <@jrand0m> para una red de 5.000.000 routers. 17:31 <@hezekiah> Por cierto, eso me recuerda. Tenemos que hablar de ElGamal. 17:31 <@thecrypto> el mayor tiempo es el de configuración 17:31 <@jrand0m> (ver el archivo de iip-dev para los modelos rudimentarios) 17:32 < dm> ¿más baja o más alta para redes más pequeñas? 17:32 <@jrand0m> hezekiah> 2.3: crypto. 17:32 <@thecrypto> después de eso el tiempo cae dramáticamente 17:32 <@jrand0m> dm> más baja. 17:32 <@thecrypto> hezekiah: probablemente tienes la misma pregunta que yo 17:32 <@jrand0m> thecrypto> exacto, el tiempo de configuración es fuera de línea para la entrega de mensajes [es decir, configurar tunnels antes de enviar mensajes] 17:32 < dm> ok, solo te estaba comprobando ;) 17:32 <@jrand0m> je 17:33 <@jrand0m> ok. última parte del SDK - la app 17:33 <@jrand0m> co/thecrypto: ¿ideas sobre una implementación talk en Java? ¿viable? ¿tiempos? ¿planes? ¿interés? 17:34 <@thecrypto> una vez que el API esté listo, probablemente tengamos un talk hecho en una semana más o menos, 2 como mucho, ¿co de acuerdo? 17:34 <@jeremiah> chat podría integrarse como un router jabber, ¿no? 17:34 < co> Eso debería ser bastante fácil de hacer. 17:34 < co> thecrypto: De acuerdo. 17:34 <@jrand0m> jeremiah> no conozco jabber, pero si jabber puede funcionar sobre el API, genial 17:35 <@jrand0m> de acuerdo co & thecrypto 17:35 <@jrand0m> jeremiah> ten en cuenta que esto es solo una app trivial como prueba de concepto, no un Kickass Anonymous IM System :) 17:35 <@jeremiah> aún no ;) 17:35 <@thecrypto> podemos añadir esa funcionalidad después 17:35 <@jeremiah> ok 17:36 <@jrand0m> je 17:36 <@thecrypto> empecemos pequeño 17:36 * jrand0m añade al plan "agregar característica: ser kickass" 17:36 < some_random_guy> je 17:36 < some_random_guy> linda característica :) 17:36 -!- dm2 [~hifi@anon.iip] se ha unido a #iip-dev 17:37 <@jeremiah> jrand0m: Creo que me perdí esto en 2.1, ¿algún pensamiento sobre kademlia como DHT (tabla hash distribuida)? requiere menos mantenimiento que Chord 17:37 -!- nop [nop@anon.iip] se ha unido a #iip-dev 17:37 < nop> perdón 17:37 <@jrand0m> además un día de estos necesitamos que alguien ponga el rediseño de IIP a funcionar sobre esto. 17:37 -!- dm [~hifi@anon.iip] ha salido [Ping timeout] 17:37 < nop> ¿qué? 17:37 < nop> quién 17:37 < nop> dónde 17:37 < nop> cuándo 17:37 < nop> ? 17:37 -!- dm2 ahora se llama dm 17:37 <@jrand0m> hey, hablando del diablo 17:37 < WinBear> ¿por qué? 17:37 < WinBear> nm 17:37 < nop> en realidad soy un ángel 17:37 <@hezekiah> lol 17:38 <@thecrypto> que alguien le pase un log a nop 17:38 < WinBear> azrel 17:38 <@jrand0m> jeremiah> kademila es un buen DHT, y definitivamente revisaremos eso además del equipo chord/tapestry, junto con dhts "sloppy" en la especificación de red. 17:38 <@jeremiah> jrand0m: genial 17:38 <@hezekiah> thecrypto: Estoy en ello. :) 17:38 < nop> oí de uno que la rompe 17:38 < nop> llamado chord/middle 17:38 -!- hif [~hifi@anon.iip] se ha unido a #iip-dev 17:39 < nop> pero ya sabes con quién es bueno hablar, con brandon wiley 17:39 * jrand0m ¡thwaps nop! 17:39 < nop> Sabía que dolería 17:39 <@hezekiah> lol 17:39 <@hezekiah> ¿Quién es Brandon Wiley? 17:39 < nop> alguien con quien estoy seguro que jrand0m ha discutido numerosas veces 17:39 < nop> :) 17:39 < nop> que alguien me envíe un log por email 17:39 < dm> ¡Brandon es el nombre real de jrandom, pillado! 17:39 <@hezekiah> Estoy en ello. 17:40 <@hezekiah> Tranquilo, nop. :) 17:40 < nop> jaja 17:40 < dm> Brandon Wiley es el primer programador de Freenet, habiendo 17:40 < dm> cofundado el esfuerzo de desarrollo con el inventor del sistema, Ian Clarke 17:40 < nop> ¿está userx aquí o allí? 17:40 < WinBear> puedes hablar con mi brandon wiley 17:40 <@hezekiah> OK. Ya va ... si mi cliente de correo coopera y envía un adjunto de 15K. 17:41 <@thecrypto> hemos hablado mucho :) 17:41 <@hezekiah> nop: UserX no está ni aquí ni allí. 17:41 <@hezekiah> ¡OK! 17:41 <@hezekiah> ¡El log está enviado, nop! Ve a leer. :) 17:41 <@thecrypto> y ahora esperamos 17:41 <@jrand0m> ok, ¿alguien tiene pensamientos sobre el SDK mientras le damos a nop un minuto para ponerse al día? ;) 17:41 <@hezekiah> jrand0m: Ahora que ya hice lo del log ... ¿qué es kademlia? 17:42 <@jrand0m> Otro DHT Académico Más :) 17:42 <@hezekiah> ¿Y dónde puedo conseguir un enlace a la página de kademlia? 17:42 -!- Erazerhead [JohnDoe@anon.iip] se ha unido a #iip-dev 17:42 <@jeremiah> http://kademlia.scs.cs.nyu.edu/ 17:42 <@hezekiah> Gracias. :) 17:42 <@thecrypto> ¿YAADHT? 17:42 <@hezekiah> lol 17:42 <@hezekiah> Los nombres hoy en día ... ¡te digo! 17:43 <@jrand0m> y si alguna vez se menciona algo de CS que no entiendas, ve a citeseer.nj.nec.com/cs 17:43 < WinBear> ¿clamidia? 17:43 <@hezekiah> OK. 17:43 < nop> jrand0m: iba a decir citeseer 17:43 < dm> ¿cuál es el ETA del SDK? 17:44 * jrand0m evita inyectar la gonorrea en I2P 17:44 * jrand0m espera que el SDK salga la próxima semana. quizá el próximo viernes? 17:44 * thecrypto cruza otro par de dedos 17:45 <@jrand0m> ok. pasando a 2.3) Crypto. 17:45 * hezekiah se imagina a thecrypto con como 13 juegos de dedos cruzados ... y luego se da cuenta de que ya se le habrán acabado. 17:45 <@hezekiah> ¡Yay! 17:45 * jrand0m pincha a nop para asegurarse de que está aquí 17:45 <@hezekiah> ¡Crypto! 17:45 <@hezekiah> Tengo algo para empezar. :) 17:46 <@thecrypto> yo también tengo algo 17:46 <@thecrypto> ¡Primero! :) 17:46 * jrand0m no tiene, así que discútanlo ustedes dos 17:46 <@hezekiah> que hable primero thecrypto. :) 17:46 <@jrand0m> thecrypto> habla 17:46 <@jrand0m> :) 17:46 <@thecrypto> Ok, sobre Elgamal 17:47 <@thecrypto> Tenemos que decidir si tenemos p y alfa comunes o no 17:47 -!- some_random_guy [~dan@anon.iip] ha salido [BitchX: la interfaz original de apuntar y hacer clic.] 17:47 <@thecrypto> el problema con un p y alfa comunes es que tendríamos que encontrar alguna forma de cambiar las claves de todos al mismo tiempo 17:48 <@jrand0m> o sea: muy malo. 17:48 < co> thecrypto: Lo siento, ¿qué son p y alfa? 17:48 <@thecrypto> la ventaja es que podemos escoger unos especialmente optimizados y la cantidad de datos transmitidos para una clave pública es muy pequeña 17:48 * jrand0m no ve una buena razón para usar p y alfa comunes, más allá de ahorrar unos pocos bits 17:48 <@thecrypto> co: a efectos prácticos, números grandes especiales 17:49 <@jrand0m> thecrypto> aún podemos optimizar para el p y alfa del destino al que ciframos más comúnmente 17:49 <@thecrypto> ¿o entro en una explicación de cómo funciona el elgamal? 17:49 <@thecrypto> jrand0m: sí 17:49 < co> thecrypto: OK. 17:49 <@thecrypto> también podemos hacer que cada uno tenga un p y alfa distintos 17:50 <@jeremiah> para quien le interese: http://www.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem 17:50 <@thecrypto> esto significa que la cantidad de datos transmitidos es mucho mayor y tenemos que ver cómo empaquetarlo 17:50 <@jrand0m> de acuerdo, gracias jeremiah 17:50 <@jrand0m> ¿mucho mayor? 17:50 <@jrand0m> Pensé que con p y alfa variables podemos usar p y alfa más pequeños? 17:51 <@thecrypto> en lugar de números de 160 bits ahora hablamos de 2 de 1024 bits y 1 de 160 17:51 <@thecrypto> o en total 2308 17:51 <@hezekiah> 288 bytes 17:51 <@hezekiah> No es para tanto. 17:52 <@jrand0m> ok, no está tan mal. hemos planeado 256 bytes 17:52 <@hezekiah> Estas claves no se transfieren tan a menudo, ¿no? 17:52 <@jrand0m> otros 32 no duelen 17:52 <@jrand0m> hezekiah> se insertan en el DHT 17:52 <@hezekiah> ¡Ah! 17:52 <@hezekiah> Por eso las queríamos pequeñas. 17:53 <@thecrypto> también, otro problema sobre el elgamal que quizá debamos preocuparnos 17:53 <@jrand0m> bueno, no importa mucho si la estructura RouterInfo tiene unos 10K o así 17:53 -!- mrflibble [mrflibble@anon.iip] se ha unido a #iip-dev 17:53 <@jrand0m> vale, ¿qué pasa, thecrypto? 17:53 <@thecrypto> la expansión del mensaje es 2, el tamaño de un cifrado o una firma es el doble del tamaño del mensaje 17:54 <@jrand0m> El cifrado ElG es solo de la clave AES 17:54 <@jrand0m> La firma ElG es solo de los hashes SHA256 17:55 <@thecrypto> ok, solo es algo que mencionar también 17:55 <@hezekiah> jrand0m: Lo cual me deja realmente perplejo. 17:55 <@thecrypto> volviendo al tema original, ¿queremos tener un p y alfa compartidos o queremos que todos tengan p y alfa distintos? 17:55 <@jrand0m> hezekiah> ¿hmm? ¿leíste la especificación de estructura de datos para #Payload? 17:55 <@jrand0m> ¿alguna idea/pregunta sobre eso, hezekiah? 17:55 * dm ahora entiende cómo funcionan los DHT. 17:55 <@jrand0m> nop> ¿opiniones? 17:55 <@jrand0m> genial dm 17:55 <@hezekiah> Si una firma es el doble del tamaño de los datos firmados, ¿entonces por qué la especificación IC2P dice que una firma es de 128 bytes? 17:56 < nop> no 17:56 < nop> p compartido 17:56 <@hezekiah> ¿No debería ser 512? 17:56 <@thecrypto> el hash de los bytes 17:56 < nop> y alfas 17:56 < dm> parece que se requiere mucho trabajo al unirse a un DHT, pero supongo que funciona. 17:56 < nop> base compartida, p compartido 17:56 <@jrand0m> hezekiah> bits / bytes. 17:56 < nop> eso eliminará mucho riesgo 17:56 <@thecrypto> entonces, ¿de qué tamaño lo queremos? 17:56 <@hezekiah> Hmm 17:56 <@jrand0m> nop> ¿en 3 años querremos que todo el mundo cambie su p y alfa al mismo tiempo? 17:56 < nop> y mantener nuestro protocolo en estándares 17:57 <@thecrypto> ya que eso abre grandes ataques sobre p y alfa 17:57 < nop> jrand0m: hay algo llamado primos "cooked", en este momento, y este es el momento que estoy considerando 17:57 <@thecrypto> que si se completan derriban toda la red 17:57 < nop> creo que podemos adaptarnos con los tiempos 17:57 < nop> pero se aconseja un primo estático aprobado por oakley 17:57 < nop> ya que han sido revisados a fondo como seguros 17:58 < nop> y esa es una base mejor que cualquiera de nuestras suposiciones sobre primos generados (probables) 17:58 <@thecrypto> si no es primo, el cifrado o las firmas no funcionan, así que simplemente lo desechamos 17:59 <@jrand0m> de acuerdo, tienen mejores primos. así que cuando uno de esos primos sea factorizado, todo el que los use queda expuesto, ¿correcto? 17:59 < dm> hmmm, tengo que irme. ¿Esto se está registrando, verdad? 17:59 < nop> jrand0m: sí 17:59 <@thecrypto> sip 17:59 < nop> jrand0m: cuando pase lo sabremos todos 17:59 < nop> no quiero arriesgar la generación de primos 17:59 -!- dm [~hifi@anon.iip] ha salido [it better be] 17:59 <@thecrypto> ¿cómo lo sabremos? 17:59 < nop> además añade tiempo de cálculo 17:59 -!- hif [~hifi@anon.iip] ha salido [] 17:59 < nop> thecrypto: si usas un conjunto de primos de Oakley estándar definido, sabrás cuándo se haya roto 18:00 <@thecrypto> ¿cómo? 18:00 < nop> porque será una noticia muy pública 18:00 <@jrand0m> nop> lo sabremos a menos que la NSA lo rompa. 18:00 < co> nop: ¿Cuántos de esos primos hay? Si no son muchos, usarlos es un riesgo. 18:00 <@thecrypto> sí, el espionaje pasivo sigue siendo una amenaza 18:00 <@thecrypto> y puedo hacer un programa para generar p y alfas y probarlos en aproximadamente una hora 18:00 <@jrand0m> nop> sería muy público a menos que fuera una amenaza a la seguridad nacional. 18:00 < co> Espera... no, esa es una pregunta tonta. Olvida. 18:01 < nop> esto es cierto, pero creo por numerosos contactos en la comunidad de criptografía que si se resuelve, se resolverá antes de que la NSA lo haga 18:01 < nop> nuestra generación de primos no asegurará eso de ningún modo 18:01 < nop> si resuelven esos primos 18:01 < nop> más vale que encuentres un nuevo algoritmo que usar 18:01 <@jrand0m> vale. 18:02 < nop> por favor usa estático, aliviará problemas con el criptoanálisis, y reducirá riesgos de errores en nuestra crypto 18:02 <@jrand0m> Yo estaba en duda, y estoy bien con ir con primos compartidos "known good". 18:02 <@thecrypto> ok, entonces elijamos un primo 18:02 <@jrand0m> nop> aún te tenemos apuntado en el diagrama de Gantt para la especificación de crypto 18:02 <@thecrypto> ¿y tienen generadores para esos primos? 18:02 < nop> sí 18:02 < nop> sí, tengo 18:03 < nop> 2 18:03 < nop> es una raíz primitiva de los primos que tendré 18:03 < nop> ¿de qué tamaño de primos quieren? 18:03 <@thecrypto> estoy pensando en algún lugar entre 2048-4096 18:03 <@hezekiah> Estamos usando una clave de 2048, ¿no? 18:03 < nop> sí, así que usa un primo de 4096 o más 18:04 <@thecrypto> porque el hecho de compartir nos deja expuestos 18:04 <@thecrypto> y si esto despega, sería un primo muy valioso para romper 18:04 * cohesion se perdió la reunión 18:04 < co> Están usando ese primo dentro de ElGamal, ¿cierto? 18:04 <@hezekiah> ¿Entonces las claves serán de 4096 bits? 18:04 <@cohesion> ¿alguien registró? 18:04 < nop> co sí 18:04 < nop> no hezekiah 18:04 < nop> las claves serán de 2048 18:04 <@cohesion> ok 18:04 < nop> el primo será mayor de 4096 18:04 * cohesion vuelve a su trabajo 18:04 <@hezekiah> OK. Por favor perdonen mi horrible entendimiento aquí. :) 18:04 < nop> vuelvo enseguida 18:05 <@thecrypto> p y alfa pueden ser fijos, alfa será 2 y p será el primo que elijamos 18:05 < nop> ok, déjenme enviar por email los candidatos a primo 18:05 < nop> denme un par de horas, tengo algo de trabajo que hacer 18:05 * jeremiah se va a cenar, leerá los logs después 18:05 <@thecrypto> la clave secreta es a, un número entre 0 y p - 2 18:05 <@thecrypto> la clave pública es 2^a mod p 18:06 < nop> ¿podemos pasar al siguiente tema y volver para que yo esté presente para eso? Vuelvo enseguida, estoy en el trabajo y tengo que hacer una tarea rápido 18:06 <@hezekiah> OK, así que llamas a mi 'x' como 'a' 18:06 <@hezekiah> ... y a mi 'g' como 'alfa'. 18:06 < nop> por favor muevan las explicaciones del algoritmo a un mensaje privado 18:06 <@hezekiah> thecrypto: ¿Verdad? 18:06 <@thecrypto> sí 18:06 <@jrand0m> ok. así que thecrypto, nop y hezekiah resolverán los detalles del algoritmo más tarde. 18:06 < nop> ok 18:06 < nop> seguro 18:06 <@hezekiah> OK ... entonces thecrypto, ¿terminaste con tu pregunta? 18:06 <@thecrypto> sigamos 18:06 < nop> enviaré nuestros primos por email 18:06 <@thecrypto> s 18:06 <@hezekiah> ¡OK. Mi turno! :) 18:07 <@hezekiah> ¿Por qué demonios estamos usando ElGamal para firmar? 18:07 <@jrand0m> ok. 2.4) estado de la hoja de ruta / protocolo de red 18:07 <@jrand0m> aún no hez :) 18:07 <@jrand0m> oh hez 18:07 <@hezekiah> ¿Cuándo puedo preguntarlo? 18:07 -!- dm [~hifi@anon.iip] se ha unido a #iip-dev 18:07 <@jrand0m> ¿qué recomendarías, cuando tenemos claves públicas ElG? 18:07 <@thecrypto> cuando nop vuelva 18:07 <@jrand0m> no, tienes razón, me equivoco. ahora es el momento adecuado. 18:07 < co> Siguiente tema, por favor. 18:07 <@hezekiah> jrand0m: Bueno, el problema es este: 18:07 <@hezekiah> velocidad 18:08 <@hezekiah> Estuve jugando con las cosas de crypto hoy, y me llevé una desagradable sorpresa. 18:08 <@hezekiah> ElGamal era astronómicamente más lento al verificar una firma que DSA o RSA. 18:08 <@jrand0m> hezekiah> ¿es un problema de implementación de la biblioteca o del algoritmo? 18:08 <@hezekiah> No lo sé. 18:09 <@hezekiah> Pero miré Applied Crypto y vi que al menos parte del problema es ElGamal. 18:09 <@hezekiah> AC tiene tablas del tiempo que toma firmar y verificar para DSA, RSA y ElGamal. 18:09 <@jrand0m> ¿entonces sugieres que pasemos a RSA para cifrado, descifrado y firma? 18:09 <@hezekiah> Yo 18:09 <@hezekiah> No sugiero realmente nada definitivo. 18:09 <@jrand0m> ...aunque podríamos añadir una segunda clave pública de firma a la estructura RouterInfo 18:10 <@hezekiah> Solo digo que AC lista la verificación de ElGamal en 9,30 segundos. 18:10 <@hezekiah> RSA es 0,08 segundos 18:10 <@thecrypto> para 1024 bits 18:10 <@jrand0m> caray. 18:10 <@hezekiah> DSA es 1,27 segundos 18:10 <@hezekiah> Ahora ves mi problema. 18:10 <@hezekiah> ElGamal es lentísimo ... 18:10 <@jrand0m> necesitamos verificación <100 ms. 18:10 <@jrand0m> si no <10 ms 18:10 <@hezekiah> ... y mi CPU es 333MHz. 18:11 <@hezekiah> Por cierto, esos cálculos se hicieron en un SPARC II 18:11 <@hezekiah> Yo tengo un AMD K6-2 333MHz. 18:11 <@jrand0m> un sparc 2 es una máquina de 40Mhz. 18:11 <@hezekiah> Verificando una firma ElGamal con mi módulo de Python (que usa backend en C pero huele un poco raro). 18:11 < luckypunk> dios 18:11 < luckypunk> bueno 18:11 <@hezekiah> jrand0m: OK. No tengo idea sobre los SPARC. 18:11 <@hezekiah> De todos modos, tardó como 20 segundos. 18:12 <@hezekiah> Si no un poco más. 18:12 < luckypunk> cualquiera con un procesador de 1 ghz -2 ghz no necesita preocuparse. 18:12 < co> hezekiah: En ordenadores modernos, entonces, la verificación debería ser aceptablemente rápida. 18:12 <@hezekiah> DSA y RSA fueron casi instantáneos. 18:12 <@jrand0m> hezekiah> Sí. sparc 2 era rápido en el 92 18:12 <@hezekiah> En fin, por eso saco esto. 18:12 <@hezekiah> Podríamos añadir una clave DSA, pero eso significaría 2 claves 18:12 <@thecrypto> aún debemos pensar en gente que no tiene máquinas súper rápidas 18:12 <@hezekiah> O podríamos ir con RSA. 18:12 <@jrand0m> mi recuerdo de la razón para ElG en lugar de RSA era que la preferencia no era muy fuerte. 18:13 <@hezekiah> O podemos vivir con el largo tiempo de verificación y usar ElG. 18:13 <@jrand0m> thecrypto> absolutamente. 18:13 <@thecrypto> nop fue quien dijo, usemos elgamal 18:13 <@hezekiah> thecrypto: Precisamente. Mamá y papá eventualmente usarán I2P de forma transparente. 18:13 <@jrand0m> vamos a querer distros arrancables para 386, así como implementaciones en applet. 18:13 <@hezekiah> Mamá y papá no tendrán hardware de última generación. 18:13 < luckypunk> oh dios 18:14 < luckypunk> todo el que querría esto tiene al menos un p100 o así. 18:14 < co> No comprometamos la seguridad eligiendo un algoritmo más débil que sea más rápido. 18:14 <@hezekiah> co: No estoy sugiriendo eso. 18:14 <@thecrypto> elgamal y DSA son equivalentes 18:14 <@jrand0m> ok. así que vamos a revisitar la elección RSA/ElG. los cambios de código no deberían ser un problema. 18:14 < luckypunk> pueden sufrir. 18:14 <@hezekiah> co: RSA y DSA son tan reputados como ElGamal. 18:14 < luckypunk> jaja 18:14 < luckypunk> si te preocupa el anonimato 18:14 <@hezekiah> thecrypto: Y nada podría estar más lejos de la verdad. 18:14 < luckypunk> no te importará mucho la velocidad. 18:14 <@thecrypto> hezekiah: ambos son implementaciones del mismo algoritmo general 18:14 < dm> el paso obvio aquí es que alguien averigüe con certeza el uso de CPU de ambos :) 18:14 <@jrand0m> luckypunk> ¿escuchas muchas quejas sobre freenet? 18:15 <@hezekiah> thecrypto: DSA no puede cifrar. Es solo de firma, y es mucho más rápido que ElG. 18:15 <@thecrypto> hezekiah: simplemente las ecuaciones de firmado y verificación de DSA son más rápidas 18:15 <@jrand0m> dm> si Applied Crypto midió la verificación RSA en 1/100 de ElG, me basta. 18:15 <@thecrypto> podemos usar ElG para cifrado/descifrado y DSA para firmado/verificación 18:15 <@jrand0m> las opciones son pasar a RSA o añadir una clave DSA (~256 bytes más) a la estructura RouterInfo 18:15 <@hezekiah> Cierto. Pero ahora el DHT tiene 2 claves públicas. 18:16 <@jrand0m> ¿y? 18:16 < co> Tengamos una clave pública. Será menos confuso. 18:16 <@hezekiah> co: Solo sería 'confuso' para los desarrolladores ... y necesitamos saber lo que hacemos. :) 18:16 <@thecrypto> creo que es hora de esperar a nop también en esto 18:16 <@hezekiah> Cierto. 18:16 <@jrand0m> pero si es 100 veces más lento... 18:16 <@jrand0m> en fin, continuaremos el diseño de crypto fuera de línea. 18:17 <@hezekiah> jrand0m: ¿Enviarás un correo a la lista? 18:17 < luckypunk> jrand0m: dios, no me importa, si no puedes esperar 40 segundos a que cargue tu página, lárgate. 18:17 <@thecrypto> o después de la parte principal de la reunión 18:17 <@jrand0m> mierda, envío a la lista a diario :) 18:17 <@jrand0m> je lucky 18:17 -!- hif [~hifi@anon.iip] se ha unido a #iip-dev 18:17 <@jrand0m> bien. 18:17 <@jrand0m> ok> 2.4) hoja de ruta / estado del protocolo de red 18:17 -!- hif ahora se llama dm2 18:18 <@jrand0m> He hecho muy poco con respecto al protocolo de red más allá de responder a los mensajes de co, ya que he estado trabajando en Java y I2CP. 18:18 <@jrand0m> la hoja de ruta sigue en objetivo. 18:18 <@jrand0m> ¿algún cambio a la hoja de ruta? 18:19 <@jrand0m> ok. si los hay, cuando los haya, solo envíen a la lista. 18:19 <@hezekiah> Cierto. 18:19 -!- dm [~hifi@anon.iip] ha salido [Ping timeout] 18:19 <@jrand0m> el roadmap.xml ahora está en el módulo cvs de i2p i2p/doc/projectPlan 18:19 -!- dm2 ahora se llama dm 18:20 <@hezekiah> jrand0m: Déjame adivinar ... ¿eso también está en cathedral? 18:20 < nop> de vuelta 18:20 < nop> perdón por eso 18:20 <@jrand0m> ok, eso es todo por eso (aunque podemos volver a preguntas del protocolo de red en la sección de preguntas). 18:20 <@jrand0m> No tengo más subpuntos 18:20 <@jrand0m> hezekiah> no uso sf 18:20 <@thecrypto> bueno, ahora que nop volvió podemos volver al tema de la velocidad rápido 18:20 <@hezekiah> Cierto. 18:21 < nop> ¿qué tema de velocidad? 18:21 <@thecrypto> Elgamal es lento de verificar 18:21 < nop> eso es cierto 18:21 < nop> pero rsa también 18:21 <@jrand0m> nop> Applied Crypto midió la verificación RSA a 1/100 de ElG para firmas. 18:21 < nop> hmm 18:22 <@hezekiah> RSA y DSA son instantáneos para mí. 18:22 <@hezekiah> ElG tarda 20 segundos. 18:22 < nop> DSA es el gamal 18:22 <@jrand0m> Así que podemos saltar a RSA o añadir una clave DSA a la estructura RouterInfo 18:22 < nop> DSA 18:22 < nop> tengo algo contra todo lo que tenga R 18:22 < nop> ;) 18:22 * jrand0m no recuerda una razón realmente fuerte para ElG en lugar de RSA 18:22 * jrand0m se resiente de eso 18:22 <@hezekiah> nop: ¿Nos iluminas? ¿Por qué no usamos RSA? 18:22 <@hezekiah> Con todos los detalles escabrosos. :) 18:23 < nop> por estas razones, y es debatible, pero 18:23 < dm> que alguien me pase por msg la URL de iip-dev de nuevo cuando pueda. 18:23 < nop> factorizar primos es cómo se rompe RSA 18:23 < dm> la lista iip-dev, esa. 18:23 < luckypunk> Se ha roto RSA. 18:23 < luckypunk> prácticamente. 18:23 < nop> sí, se ha roto RSA de 512 bits 18:23 < luckypunk> ¿o era DES? 18:23 < luckypunk> bah. 18:23 <@hezekiah> Se ha roto DES. 18:23 < nop> creo que te refieres a DES 18:23 < co> luckypunk: Se han roto claves de cierto tamaño. 18:23 <@hezekiah> RSA no está ahí todavía. 18:24 < nop> en fin 18:24 < luckypunk> pero podría. 18:24 < nop> volviendo a mi punto 18:24 <@hezekiah> Pero la pregunta es: ¿una clave RSA de 2048 o 4096 es segura hoy? 18:24 <@thecrypto> un segundo 18:24 < nop> claves RSA de 512 bits se han roto con ordenadores de oficina 18:24 <@jrand0m> estamos mirando RSA o ElG de 2048 bits 18:24 < nop> hezekiah: lo sería, pero aquí viene lo divertido 18:24 < nop> si puedes factorizar primos 18:24 < nop> puedes romper RSA 18:24 < nop> si puedes computar logaritmos discretos puedes resolver RSA y EL gamal 18:24 < nop> estamos más cerca de factorizar 18:24 < nop> que de computar logs discretos 18:24 < nop> en este momento 18:24 < luckypunk> ¿no son los logs discretos un poco más difíciles? 18:25 <@hezekiah> Si puedes factorizar primos rápidamente, puedes romper RSA. 18:25 <@hezekiah> luckypunk: Eso es lo que dice nop. 18:25 < luckypunk> computadoras cuánticas. 18:25 < luckypunk> están casi funcionales. 18:25 <@hezekiah> lol 18:25 < nop> y la proporción de tamaños de bits para claves públicas de logaritmos discretos es más fuerte que las claves de RSA 18:25 < nop> por ejemplo no se aconseja clave de 768 bits por variantes Diffie-Hellman, pero no se ha roto demostrablemente 18:25 <@hezekiah> Entonces, el resultado es que añadimos una clave DSA. 18:25 <@thecrypto> nop, no hagas un bill gates, es factorizar n grande donde n = pq 18:25 < nop> como sí lo han hecho claves RSA de 512 bits 18:25 <@thecrypto> ya que factorizar números primos es fácil 18:25 < nop> gracias 18:25 < nop> perdón 18:25 <@jrand0m> hezekiah> eso parece. 18:26 < nop> trataba de que todos entendieran 18:26 < nop> perdón 18:26 <@thecrypto> solo una aclaración 18:26 <@jrand0m> bien nop, está bien, gracias 18:26 <@hezekiah> OK. 18:26 < nop> así que DSA 18:26 < nop> entonces 18:26 <@hezekiah> ¿Entonces añadimos una clave DSA? 18:26 < nop> que es también una variante diffie-hellman 18:26 <@jrand0m> ok, dado eso, continuaremos detalles de crypto fuera de línea. 18:26 < nop> prefiero logs sobre factores 18:27 < nop> ;) 18:27 <@hezekiah> Por cierto, ¿qué nos falta por continuar? 18:27 < co> dm: Esa URL es http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel 18:27 <@thecrypto> hezekiah: elegir el primo mágico 18:27 <@hezekiah> ¡Ah, cierto! 18:27 < dm> gracias co, encontré las especificaciones de jrand0m. Ahora solo me falta una impresora con mucho tóner. 18:27 < nop> enviaré eso 18:27 <@jrand0m> hezekiah> actualiza la especificación de estructura de datos, añade info respecto a DSA, especifica tamaño de clave para dsa, etc. 18:27 < nop> hagámoslo fuera de línea 18:27 <@jrand0m> je dm. 18:28 <@hezekiah> OK, ¿tienes algo más, jrand0m? 18:28 <@jrand0m> ok, terminé con mis cosas. hezekiah> ¿tenías la # 3? 18:28 <@hezekiah> Sí. 18:28 < dm> hmmm. las imágenes no aparecen. 18:28 <@hezekiah> 3.) Lo que nop quiera añadir a la agenda. 18:28 < dm> jrand0m: ¿hay algún lugar para conseguir el 'I2P Network Spec Draft 2003.07.23' con imágenes incluidas? 18:29 < co> dm: Sí, yo también he tenido ese problema. 18:29 <@jrand0m> dm/co> consigan la primera revisión de la especificación de red (dos semanas antes en el zip), que incluye el png. 18:30 <@jrand0m> (está en cvs también, pero eso no es anon/público aún) 18:30 < arj> ¿cuándo será? :) 18:30 <@hezekiah> ¡Guau! 18:30 <@hezekiah> ¡CVS ahora es rápido! 18:31 <@jrand0m> arj> estamos haciendo lo posible para evitar el hype, así que cuando esté listo pondremos las cosas públicas, pero lo mantendremos bastante silencioso hasta entonces. 18:31 < nop> hezekiah: ¿el de la cathedral? 18:31 <@jrand0m> arj> sin embargo, todo lo que estamos haciendo es GPL, al menos hasta ahora. 18:31 <@hezekiah> nop: Sí 18:31 <@hezekiah> ! 18:31 < dm> ¿dos semanas antes en qué zip? 18:31 <@jrand0m> oh bien, ¿lo tienes funcionando hezekiah? 18:31 < arj> jrand0m: solo quería leer las últimas especificaciones 18:31 <@jrand0m> dm> network_spec_*.zip si no recuerdo mal 18:31 <@hezekiah> jrand0m: ¡Sip! :) 18:31 < dm> yo igual, ¡con imágenes! 18:31 <@thecrypto> iip-dev tiene la mayor parte 18:32 <@jrand0m> arj> http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/292 tiene todo salvo un pequeño cambio. 18:32 <@jrand0m> (bueno, excepto la Capa de Acceso del Cliente, que ahora está en una especificación distinta) 18:33 < arj> ok gracias 18:33 <@jrand0m> la especificación de la Capa de Acceso del Cliente es http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/298 18:33 < dm> ok, ¿y el enlace al zip con las imágenes? 18:33 <@jrand0m> ok. nop ¿tienes algo, o pasamos a "5) abrir a preguntas/pensamientos de las masas"? 18:34 -!- mihi [none@anon.iip] ha salido [Ping timeout] 18:34 * jeremiah ha vuelto y ha leído el backlog 18:34 <@jrand0m> dm> un momento, lo busco 18:34 <@jrand0m> http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/269 18:35 < dm> gracias 18:35 <@jrand0m> ok, ¿alguna pregunta / pensamientos? 18:35 -!- arj [anders@anon.iip] ha salido [EOF From client] 18:35 < co> sí. 18:35 <@jrand0m> np 18:35 < co> ¿Estamos en el punto 5 ahora? 18:35 * jrand0m sabía que tendrías algunas co :) 18:35 < co> Actualmente, la comunicación entre cliente y router (saliente) no está cifrada. 18:35 <@jrand0m> sí, dado que nop es lento :) 18:35 <@jrand0m> (malditos los que tienen trabajo y esas cosas) 18:36 <@hezekiah> lol 18:36 < co> Supón que tengo un amigo de confianza y quiero usar su router para mensajes salientes. 18:36 <@hezekiah> jrand0m: Bueno, ya sabes. No todos pueden permitirse no tener vida. 18:36 <@jrand0m> co> en gran parte correcto. la carga útil de mensajes está cifrada, pero el resto de I2CP no 18:36 < co> ¿Eso no me pondría en riesgo de que capturen mis mensajes? 18:37 <@hezekiah> Sí. Se transferirían en claro por el cable. 18:37 <@hezekiah> A menos que hagas un túnel ssh a su router o algo así. 18:37 <@jrand0m> si tienes un amigo de confianza y te conectas a su router, puede saber que enviaste o recibiste un mensaje, pero no puede saber qué enviaste. 18:37 <@jeremiah> ¿los mensajes no irían bajo cifrado de clave pública? 18:37 <@hezekiah> Ups. 18:37 <@hezekiah> Mi culpa. 18:37 < dm> Voy a usar I2P como forma de aprender cosas nuevas para evitar que un trabajo 9 a 5 (admin de windows, herramientas VB) me convierta en zombi. 18:37 <@jrand0m> Estoy bien con añadir soporte de listener SSL, en lugar de solo listener TCP. 18:37 <@hezekiah> Olvidé que los clientes hacen cifrado de extremo a extremo. 18:37 < co> Tu suposición es que ejecuto un router local de confianza, pero como dije arriba, puede que no quiera hacer eso para que los mensajes no se conecten a mí. 18:37 <@jrand0m> sí jeremiah, pero eso es solo para la carga útil 18:37 <@jrand0m> je bien dm 18:37 -!- mihi [none@anon.iip] se ha unido a #iip-dev 18:38 <@jrand0m> hmm. 18:38 <@hezekiah> jrand0m: ¿Por qué no añadir más adelante soporte para cifrar la comunicación cliente-router? 18:38 <@jrand0m> realmente siempre deberías tener un router local de confianza. puedes hacer que se conecte a otro router no local de confianza también. 18:39 < co> Cierto, pero me gustaría secundar la sugerencia de hezekiah. 18:39 <@jrand0m> hezekiah> me parece bien añadirlo más adelante (donde más tarde: t=0...releaseDate ;) 18:40 <@jrand0m> No tengo ningún reparo en incluso añadir soporte para DH+AES para I2CP 18:40 < nop> bien 18:40 <@jrand0m> de hecho, esas funciones también se pueden añadir por router individualmente 18:41 < nop> jrand0m: también creo que la rotación polimórfica de claves será necesaria así como tráfico chaff (tráfico de relleno) 18:41 < nop> Seguro que veremos eso en una reunión posterior 18:41 < nop> solo mi comentario 18:41 < nop> usando conjuntos de claves 18:41 <@jrand0m> sí, cuando toquemos la comunicación router-router. 18:41 <@jrand0m> (en 1-2 semanas) 18:41 < co> nop: Actualmente, no veo tráfico chaff en la espec, pero sería bueno añadirlo. 18:42 <@jrand0m> hay chaff, en el sentido de que los routers y participantes de tunnel se prueban a sí mismos y a sus pares. 18:42 -!- arj [~anders@anon.iip] se ha unido a #iip-dev 18:42 <@jrand0m> además, las peticiones DHT son chaff respecto a los mensajes de carga útil 18:42 < nop> jrand0m: bueno, me meteré en investigación sobre evasión de análisis de tráfico y evitar dar cualquier texto claro conocido 18:42 <@jrand0m> y los transportes individuales tendrán su propio estilo de chaff (p. ej., el transporte http consultará periódicamente Google por "cute puppy dogs", o lo que sea) 18:43 < nop> bueno, ese chaff está bien, pero también me refiero a chaff cifrado 18:43 < nop> esto ayuda a rotar las claves de sesión 18:43 < nop> y mantener tu nodo ocupado incluso cuando esté inactivo 18:43 < dm> 18:43 <@jrand0m> eso. 18:43 < dm> ¡es broma! 18:43 <@hezekiah> dm: Bien. Si no tendría que ¡thwackearte!. 18:43 <@hezekiah> :) 18:44 <@jrand0m> DHT (enlace cifrado) y mensajes de prueba (free route mix, al estilo onion/garlic) no tendrán problemas de texto claro conocido 18:44 < nop> ya que los nodos más nuevos tendrán menos tráfico al comenzar 18:44 <@jrand0m> además tendremos soporte para transportes de tasa de bits constante 18:44 < nop> garlic rocks 18:44 < nop> :) 18:44 < nop> jrand0m: estilo DC-net :) 18:44 * jrand0m va a hacerse una pasta con mucho ajo cuando termine esta reunión 18:45 < nop> jrand0m: me refería a garlic routing (enrutamiento garlic de I2P) 18:45 <@hezekiah> ¡lol! 18:45 <@jrand0m> lo sé ;) 18:45 < nop> jrand0m: en fin, la tasa constante podría forzarse con el cifrado por bloques pues AES genera bloques de 128 bits 18:45 < nop> ;) 18:45 < nop> así que podríamos rellenar todos los datos a 16 bytes por mensaje 18:45 <@jrand0m> co> ¿tuvieron sentido mis respuestas a tu email? 18:47 <@jrand0m> *ping* 18:47 <@hezekiah> *pong* 18:47 <@thecrypto> *pong 18:47 <@thecrypto> * 18:47 <@jrand0m> ¿alguna otra pregunta de alguien, o mi iproxy se desconectó? 18:47 <@jrand0m> je bien 18:47 <@hezekiah> thecrypto: ¡Paquete fragmentado! 18:47 <@hezekiah> lol 18:48 <@thecrypto> perdí ese final 18:48 <@thecrypto> MTU más pequeño aquí :) 18:48 <@hezekiah> jrand0m: Bueno, yo no tengo preguntas. 18:48 < co> jrand0m: Sí, las respuestas tenían sentido. 18:48 < co> No tengo más preguntas. 18:48 < dm> Crearé preguntas cuando lea las especificaciones mañana. 18:49 <@jrand0m> bueno, espero que tengas más luego :) 18:49 <@jrand0m> genial dm 18:49 < dm> genial inicialmente quizá. 18:49 < dm> bueno, me voy. ¡Buena suerte gente! 18:49 -!- dm [~hifi@anon.iip] ha salido [] 18:50 <@jrand0m> aún tenemos el gran periodo de revisión por pares de 2 semanas en el calendario, pero se agradece la revisión antes (aunque todos los detalles aún no se hayan puesto) 18:51 <@jrand0m> ok. ¿alguna otra pregunta, o vamos a cerrar la #52 como una reunión de 102 minutos? 18:52 <@thecrypto> #51 18:52 <@hezekiah> Eh, leí 1:57 minutos. 18:52 <@hezekiah> Duh. 18:52 <@hezekiah> Soy tonto 18:52 <@hezekiah> No me hagan caso. 18:52 <@hezekiah> No tengo preguntas ... 18:52 <@hezekiah> ¡Preguntas! 18:52 * jrand0m nunca supo sumar... 18:52 <@hezekiah> ¡Hablen ahora o callen hasta el próximo martes! 18:52 <@hezekiah> ¡A la una! 18:53 <@hezekiah> ... ¡A las dos! 18:53 <@thecrypto> Vendido al tipo con camisa de botones 18:53 <@hezekiah> ¡Listo! 18:53 * jrand0m va a la cocina a hacerse una cena muy atrasada 18:53 <@jrand0m> gracias srs y srtas 18:53 <@hezekiah> ¡Adiós a todos! 18:53 <@jeremiah> Debería revisar el código fuente antes de irme 18:53 <@hezekiah> ¡Nos vemos el próximo martes! --- Registro cerrado Tue Jul 29 18:53:55 2003