Reunión de desarrolladores de I2P - 7 de febrero de 2006

15:36 <jrandom> 0) hola 15:36 <jrandom> 1) Estado de la red 15:36 <jrandom> 2) progreso de la red _PRE 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) hola 15:37 * jrandom saluda 15:37 <jrandom> notas de estado semanales publicadas en @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> hola 15:38 <jrandom> mientras revisan ese material tan emocionante, pasemos a 1) Estado de la red 15:38 <jrandom> no ha habido muchos cambios en la red en vivo en la última semana, desde la perspectiva de i2p, así que no tengo mucho que agregar aquí 15:39 <jrandom> ¿Alguien tiene algo que quiera comentar respecto al estado actual de la red? 15:39 <KBlup> He visto picos terribles de clientes fallando cuando ejecuto i2p por mucho tiempo... no sé si eso encaja en 1) 15:39 <jrandom> KBlup: ¿eso se correlaciona con alta carga de CPU o consumo de ancho de banda? 15:40 <KBlup> da como resultado msg-delay> 10000ms :-/ 15:40 <jrandom> ah, muy probablemente una de las razones por las que se está desarrollando la red _PRE :) 15:40 <KBlup> Creo que entonces intenta establecer nuevos tunnels y falla constantemente, lo que da como resultado 300+ jobs a veces... 15:41 <KBlup> mi máquina es bastante potente pero se sobrecarga con eso... 15:41 <jrandom> sí, todo eso se ha reestructurado de cara a 0.6.1.10, aguanten hasta que esté listo 15:43 <jrandom> ok, ¿algo más sobre 1), o nos movemos a 2) progreso de la red _PRE 15:43 <+Complication> 0.6.1.10 parece contener cambios sustanciales, en efecto 15:45 <jrandom> sí, hay mucha sustancia aquí. El estado actual es que el nuevo código de creación está en su lugar y parece funcionar correctamente, pero ahora estoy aprovechando para depurar más a fondo algunos de los problemas subyacentes 15:46 <+Complication> Mencionaste que hay que invertir bastante tiempo de CPU por adelantado 15:47 <+Complication> ¿Este costo estaría ahora asociado con construir cualquier tipo de tunnel? 15:48 <+Complication> (es decir, antes de la construcción, durante un breve lapso, habría que realizar un lote de cripto pesada) 15:48 <jrandom> sí, todas las solicitudes de construcción de tunnel tendrán que hacer k operaciones de cripto pesada (donde k = número de saltos en el tunnel que se está construyendo) 15:49 <+Complication> Lo que quería preguntar... ¿el intervalo es simplemente más ajustado que antes, o la cantidad también es mayor? 15:50 <jrandom> La cantidad es a la vez mayor, menor y más ajustada. Más ajustada, en que todo se hace por adelantado. Mayor, en que no podemos atajar y omitir el cifrado para un salto si un salto anterior lo rechaza, y menor en que los saltos anteriores fallan mucho menos 15:51 <jrandom> además, a diferencia de versiones anteriores, ya no usamos ElGamal/AES+SessionTag para las solicitudes de tunnel: usamos (bastante) ElGamal directo 15:52 <+Complication> …¿y no podría pre-calcularse, a menos que se conociera el conjunto final que va a tener éxito? 15:52 <jrandom> eso significa que, aunque antes podíamos hacer trampa sin una operación asimétrica, ya no intentamos hacer trampa (ya que esa trampa en sí exponía una clase de ataques) 15:53 <+Complication> (conjunto de pares) 15:53 <jrandom> hmm, ciertamente se podría pre-calcular, suponiendo que sabes quiénes son los pares en el tunnel a los que se va a pedir 15:54 <jrandom> el nuevo proceso de creación de tunnel se realiza en un hilo separado, para que no atasque la cola principal de jobs bajo carga y para que pueda autorregularse mejor 15:54 <+Complication> ¿También se podría suponer que, salvo cambios en la información disponible, se sabe a algunos a quienes se va a pedir si los intentos fallan? 15:54 <jrandom> hmm, no estoy seguro de entenderte del todo 15:55 <+Complication> ¿O conocerlos de antemano es inútil, ya que la estructura debe rehacerse desde cero? 15:56 <+Complication> (es decir: rehacer los ElGamal desde cero, al menos) 15:56 <jrandom> ah, la estructura está en http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> así que sí, si cambia el siguiente salto, hay que rehacer el ElGamal 15:56 <jrandom> (si precalculas) 15:56 <+Complication> Bien, no estaba lo bastante seguro de eso de inmediato 15:57 <+Complication> Ahora ya me doy cuenta 15:57 <jrandom> por otro lado, realmente estamos intentando aumentar nuestra tasa de éxito de construcción, y el nuevo proceso de construcción debería poder adaptarse para minimizar creaciones innecesarias 15:58 <+Complication> ¿Cómo parece ir en la práctica? 15:58 <jrandom> (oh, esa estructura se ha modificado ligeramente en la rama _PRE: http://dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/router/doc/tunnel-alt-creation.html?rev=1.1.2.1;content-type=text%2Fhtml#tunnelCreate.requestRecord ) 15:59 <+Complication> Noté el detalle de que los cifrados ElGamal dieron un salto hacia la rapidez... 15:59 <jrandom> bueno, la tasa de éxito de construcción es mucho, mucho mayor que en la red en vivo, pero eso puede deberse simplemente al tamaño pequeño de la red _PRE 16:00 <jrandom> sí, crear una estructura de 2 saltos, por ejemplo, toma un promedio de 44ms en 1120 ejecuciones, en comparación con el tiempo de cifrado ElGamal de 542ms en la red en vivo (en 1344 ejecuciones) 16:02 <jrandom> (en la misma máquina) 16:02 <+Complication> ¿Estos 542 incluirían reintentos tras fallos también, o solo la construcción pura? 16:02 <+Complication> Si es construcción pura, necesito buscar mi mandíbula... está por el suelo en algún lado. :P 16:02 <KBlup> sobre ese cambio del exponente: ¿a qué escala afecta al anonimato? 16:02 <jrandom> no, esa es la estadística de ElGamal pura, ya que la red en vivo no construye la nueva estructura de la red _PRE 16:04 <jrandom> KBlup: ¿anonimato? ninguno. ¿seguridad? según lo que he leído, 228 bits es más que suficiente para igualar ElGamal de 2048 bits 16:04 * Complication no sabe mucho sobre la x e y de ElGamal 16:04 <+Complication> No lo suficiente como para comentar con fundamento 16:06 <+Complication> Si investigadores serios consideran que la x más corta sigue siendo suficientemente difícil, y esos gurús cripto no salieron corriendo gritando... 16:06 <@cervantes> bueno, no solo eso, sino las implicaciones de bajar a 1024/160 16:07 <KBlup> supongo que tengo que leer el artículo después ;) 16:07 <+Complication> cervantes: sí, es mejor que eso, seguro 16:08 <+Complication> Además, ¿cuál es el principal ataque que este cifrado debe repeler y cuánto tiempo es viable el ataque? 16:09 <+Complication> ¿Podría ser algo que solo te beneficia si lo rompes rápido, o también beneficia si lo rompes eventualmente? 16:11 <+Complication> Si entiendo bien, el secreto inmediato que protege es el siguiente participante del tunnel, ¿no? 16:11 <+Complication> (o más precisamente, el siguiente del siguiente) 16:11 <@modulus> ¿sigue la reunión? 16:11 <+Complication> (que solo el siguiente puede conocer) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> para un adversario práctico (aunque increíblemente poderoso), sería necesario romperlo durante la vida útil del tunnel. Romperlo después de esa vida del tunnel solo ayudaría si registraste todo el tráfico de red y rompiste todos los tunnels (es decir, después de romper la cripto efímera de la capa de transporte y trabajar en la cripto de la capa de tunnel) 16:11 <jrandom> así que estamos hablando de minutos aquí, no de décadas 16:12 <jrandom> (así que 1024 bits probablemente es incluso excesivo) 16:12 <@cervantes> ¿hay alguna forma de medir el riesgo de manera significativa? 16:13 <+Complication> Además, para un tunnel con más saltos, el adversario tendría que romper varios, ¿no? 16:13 <+Complication> (aunque el constructor también tendría que construir varios) 16:13 <@cervantes> si no necesitamos más de 1024 bits, ¿entonces es realmente necesario usar más? 16:14 <@cervantes> siempre podemos usar un algoritmo más fuerte en 3 años cuando tengamos computadoras cuánticas muchísimo más potentes 16:14 <@modulus> jrandom: si el adversario supiera que a la hora hh:mm se va a enviar por un tunnel algo importante, ¿es probable que pudiera romperlo de alguna manera mediante registro? 16:14 <jrandom> Complication: correcto, tendrían que romper varios (y las claves DH que protegen la capa de transporte) 16:14 <@modulus> hasta donde sé, 1024 bits es break()able con mucha potencia 16:15 <jrandom> mucha potencia y una década 16:15 <jrandom> (o tres) 16:15 <@cervantes> jrandom: ¿es difícil probar el cifrado más débil? 16:15 <@modulus> tenía la impresión de que los compuestos de 1024 bits eran factorizables hoy en día en unos pocos meses. 16:15 <@cervantes> ¿podríamos desplegarlo en la red pre 16:15 <@cervantes> y ver si en realidad ofrece mucho beneficio 16:16 <@cervantes> modulus: sí, pero tendrían que romper varios 16:16 <@modulus> si esto está basado en logaritmo discreto y todo eso entonces no sé nada 16:16 <@modulus> cervantes: ajá 16:16 <jrandom> cervantes: requiere cambios en muchas estructuras, ya que actualmente usamos ranuras de 512 bytes. aunque, quizá podríamos simplemente rellenar los primeros 256 bytes con 0x00 para probar 16:17 <jrandom> modulus: ElGamal se basa en logaritmo discreto 16:17 <@cervantes> jrandom: ¿vale la pena probarlo? 16:17 <@modulus> sí, sí, me estaba imaginando RSA 16:17 <@cervantes> ¿o mejor enfocarnos en otras cosas y volver a esto si es necesario? 16:18 <jrandom> definitivamente vale la pena probarlo, aunque por el momento estoy trasteando con algunas evaluaciones de la capa de transporte 16:18 <+Complication> Supongo que depende de cómo se pueda manejar su cálculo en la vida real. 16:18 <jrandom> (y los 44ms de tiempo de cifrado son suficientes por ahora, aunque 4ms serían incluso mejores :) 16:19 <+Complication> Si se sostiene con las computadoras actuales, mejorará con máquinas más nuevas. 16:19 <@modulus> especialmente si llega hardware cripto, como está empezando a llegar en algunos 16:19 <jrandom> pero, por supuesto, cambiar este parámetro no se hará a la ligera ni de inmediato. pero si alguien tiene una buena razón para evitarlo, por favor que se ponga en contacto 16:21 <jrandom> modulus: he oído de chips dedicados a AES y RSA, pero nada sobre DH/ElGamal. por otro lado, cuando uno mira a la NSA/etc como adversario, donde pueden construir los suyos, es posible 16:22 <@cervantes> tienen máquinas cripto construidas con tecnología de donas con chispas en anillo 16:23 * Complication está dispuesto a actualizar el Celeron 300 a Athlon 600, si contiene la marea de donas con chispas en anillo :D 16:23 <tethra> jejeh 16:24 <jrandom> mmMMmm donas 16:25 <jrandom> ok, ¿alguien tiene algo más sobre 2) progreso de la red _PRE? 16:25 <jrandom> si no, pasemos a 3) I2Phex 0.1.1.37 16:26 <jrandom> Complication: ¿quieres darnos la primicia? 16:26 <+Complication> Bueno, parece que funciona. :) 16:26 <+Complication> Hay esperanza de conseguir más webcaches para redundancia adicional pronto. 16:27 <jrandom> vale 16:27 <jrandom> hmm, ¿crees que necesitamos más webcaches? ¿no basta con que haya una activa? no es que más hagan daño, claro 16:27 <+Complication> (si legion logra resolver los misterios que atormentaron su intento inicial) 16:27 <+Complication> También hay un bug misterioso ahí, pero no muerde fuerte, y estoy intentando encontrarlo. 16:28 <+Complication> Con una activa basta 16:28 <+Complication> Más solo aumenta las probabilidades de que haya una activa 16:28 <jrandom> genial 16:28 <+Complication> Porque en la etapa actual, nunca descartará webcaches por malas. Demasiado pocas en total. 16:29 <+Complication> (esa rutina se activará si existen más de 10) 16:29 <+Complication> (si recuerdo bien) 16:29 <+Complication> En cuanto al bug: después de mucho tiempo en funcionamiento, el subsistema de webcache a veces se atasca 16:30 <+Complication> Probablemente porque no se puede abortar correctamente una petición GET de un httpclient 16:31 <@modulus> ¿así que necesita morir de vez en cuando? 16:31 <+Complication> Es seguro, y nunca parece morder a máquinas recién incorporadas 16:31 <jrandom> hmm, ¿qué significa eso, funcionalmente? después de un tiempo, dejará de registrarse con la webcache, así que a la gente nueva no se le darán referencias hacia ellos? 16:31 <+Complication> Si muerde a una máquina ya bien integrada, esa máquina puede conseguir suficientes pares de los pares a los que ya está conectada 16:31 <+Complication> Así que actualmente el impacto parece cercano a 0 16:31 <@modulus> cool 16:32 <+Complication> Es curioso, simplemente 16:32 <@modulus> ¿ninguna regla sobre cuándo fallará ni nada? 16:32 <+Complication> modulus: generalmente no antes de 20 horas 16:33 <+Complication> Y como no tengo manera de forzarlo a ocurrir, depurar es un poco lento 16:33 <@modulus> :_) 16:34 <+Complication> De cualquier modo, si lo encuentro, lo arreglaré, y si no lo encuentro, encontraré otras cosas con las que trastear :) 16:34 <jrandom> :) 16:34 <jrandom> suena a que es solo un síntoma de algunos bugs que hemos visto en la biblioteca de streaming / eepproxy, así que arreglar esos debería arreglar esto 16:35 <+Complication> Podría ser 16:38 <jrandom> ok, genial, buen trabajo Complication 16:38 <jrandom> ¿alguien tiene algo más sobre 3) I2Phex 0.1.1.37, o pasamos al cajón de sastre, 4) ??? 16:41 <jrandom> (considéranos pasados) 16:41 <jrandom> ok, ¿alguien tiene algo más para la reunión? 16:42 <tmp> ¿O callan para siempre? 16:43 <jrandom> y siempre y siempre 16:43 * jrandom se prepara 16:43 * jrandom cierra la reunión de un *baf*