Reunião de Desenvolvedores do I2P - 7 de fevereiro de 2006

15:36 <jrandom> 0) oi 15:36 <jrandom> 1) Status da rede 15:36 <jrandom> 2) progresso da rede _PRE 15:36 <jrandom> 3) I2Phex 0.1.1.37 15:36 <jrandom> 4) ??? 15:36 <jrandom> 0) oi 15:37 * jrandom acena 15:37 <jrandom> notas semanais de status publicadas em @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html 15:37 <bar> olá 15:38 <jrandom> enquanto todos vocês vasculham aquele material tão empolgante, vamos pular para 1) Status da rede 15:38 <jrandom> não houve muitas mudanças na rede ao vivo na última semana, do ponto de vista do I2P, então não tenho muito a acrescentar aqui 15:39 <jrandom> alguém tem algo que queira mencionar sobre o status atual da rede? 15:39 <KBlup> Tenho visto picos terríveis de clientes falhando ao executar i2p por muito tempo... não sei se isso se encaixa no 1) 15:39 <jrandom> KBlup: isso se correlaciona com alta carga de CPU ou consumo de largura de banda? 15:40 <KBlup> resulta em msg-delay> 10000ms :-/ 15:40 <jrandom> ah, muito provavelmente uma das causas de a rede _PRE estar sendo desenvolvida :) 15:40 <KBlup> Acho que então tenta estabelecer novos tunnels e falha constantemente, o que resulta em 300+ jobs às vezes... 15:41 <KBlup> minha máquina é bem potente, mas fica sobrecarregada com isso... 15:41 <jrandom> sim, tudo isso foi retrabalhado no caminho para 0.6.1.10, aguente firme até que esteja pronto 15:43 <jrandom> ok, mais algo sobre 1), ou vamos seguir adiante para 2) progresso da rede _PRE 15:43 <+Complication> 0.6.1.10 parece conter mudanças substanciais, de fato 15:45 <jrandom> sim, há muita substância aqui. O estado atual é que o novo código de criação está no lugar e parece estar funcionando corretamente, mas agora estou aproveitando para depurar mais alguns problemas subjacentes 15:46 <+Complication> Você mencionou ter que desembolsar bastante tempo de CPU antecipadamente 15:47 <+Complication> Esse custo agora estaria associado à construção de qualquer tipo de tunnel? 15:48 <+Complication> (ou seja, antes da construção, por um curto período, você teria que executar um lote de cripto pesada) 15:48 <jrandom> sim, todas as solicitações de construção de tunnel precisarão fazer k operações de cripto pesada (onde k = número de saltos no tunnel que está sendo construído) 15:49 <+Complication> O que eu queria perguntar... o intervalo está apenas mais apertado do que antes, ou a quantidade também é maior? 15:50 <jrandom> a quantidade é ao mesmo tempo maior, menor e mais apertada. Mais apertada porque tudo é feito antecipadamente. Maior porque não podemos fazer um curto-circuito e deixar de fazer a criptografia para um salto se um salto anterior o rejeitar, e menor porque saltos anteriores falham muito menos 15:51 <jrandom> além disso, porém, ao contrário das versões anteriores, não estamos mais usando ElGamal/AES+SessionTag para as solicitações de tunnel — usamos (basicamente) ElGamal puro 15:52 <+Complication> ...e isso não poderia ser pré-calculado, a menos que se soubesse o conjunto final que vai ser bem-sucedido? 15:52 <jrandom> isso significa que, embora antes pudéssemos trapacear sem uma operação assimétrica, não tentamos mais trapacear (pois a própria trapaça expunha uma classe de ataques) 15:53 <+Complication> (conjunto de pares) 15:53 <jrandom> hmm, certamente poderia ser pré-calculado, assumindo que você saiba quais são os pares no tunnel que vão ser solicitados 15:54 <jrandom> o novo processo de criação de tunnel é feito em uma thread separada, para não sobrecarregar a fila principal de jobs sob carga e para poder se auto-regular melhor 15:54 <+Complication> Também se poderia supor que, na ausência de novas informações, sabe-se alguns a quem se vai pedir, caso as tentativas falhem? 15:54 <jrandom> hmm, não tenho certeza se entendi 15:55 <+Complication> Ou saber isso já é inútil, já que a estrutura precisa ser refeita do zero? 15:56 <+Complication> (ou seja: os ElGamal refeitos do zero, pelo menos) 15:56 <jrandom> ah, a estrutura é http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.requestRecord 15:56 <jrandom> então, sim, se o próximo salto mudar, o ElGamal deve ser refeito 15:56 <jrandom> (se você pré-calcular) 15:56 <+Complication> Certo, eu não tinha certeza disso na hora 15:57 <+Complication> Mas agora percebo 15:57 <jrandom> por outro lado, estamos realmente tentando aumentar nossa taxa de sucesso de construção, e o novo processo de construção deve conseguir se adaptar para minimizar criações desnecessárias 15:58 <+Complication> Como parece estar na prática? 15:58 <jrandom> (ah, essa estrutura foi levemente modificada no ramo _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> Notei o detalhe sobre as criptografias ElGamal dando um salto em direção à rapidez... 15:59 <jrandom> bem, a taxa de sucesso de construção é muito, muito maior do que na rede ao vivo, mas isso pode ser apenas devido ao pequeno tamanho da rede _PRE 16:00 <jrandom> sim, criar uma estrutura de 2 saltos, por exemplo, leva em média 44ms ao longo de 1120 execuções, em comparação com o tempo de criptografia ElGamal da rede ao vivo de 542ms (ao longo de 1344 execuções) 16:02 <jrandom> (na mesma máquina) 16:02 <+Complication> Esses 542 incluiriam novas tentativas em caso de falha também, ou apenas a construção pura? 16:02 <+Complication> Se for construção pura, preciso procurar minha mandíbula inferior... ela está no chão em algum lugar. :P 16:02 <KBlup> sobre aquela mudança do expoente: em que medida isso afeta o anonimato? 16:02 <jrandom> não, essa é a estatística de ElGamal pura, já que a rede ao vivo não constrói a nova estrutura da rede _PRE 16:04 <jrandom> KBlup: anonimato? nenhum. segurança? pelo que li, 228 bits é mais do que suficiente para equiparar ElGamal de 2048 bits 16:04 * Complication não sabe muito sobre o x e o y do ElGamal 16:04 <+Complication> Não o suficiente para comentar de forma significativa 16:06 <+Complication> Se pesquisadores sérios consideram o x mais curto suficientemente duro, e aqueles nerds de cripto não saíram correndo gritando... 16:06 <@cervantes> bem, não só isso, mas as implicações de cair para 1024/160 16:07 <KBlup> acho que tenho que ler o artigo depois ;) 16:07 <+Complication> cervantes: sim, é melhor do que isso, com certeza 16:08 <+Complication> Além disso, qual é o principal ataque que esta cifra deve repelir, e por quanto tempo o ataque é viável? 16:09 <+Complication> Pode ser algo que te beneficia apenas se você quebrá-la rapidamente, ou também beneficia se você quebrá-la eventualmente? 16:11 <+Complication> Se entendi corretamente, o segredo imediato que ela protege é o próximo participante do tunnel, certo? 16:11 <+Complication> (ou, mais precisamente, o próximo do próximo) 16:11 <@modulus> reunião em andamento? 16:11 <+Complication> (que apenas o próximo pode saber) 16:11 <@cervantes> modulus: ayre 16:11 <@cervantes> -r 16:11 <jrandom> para um adversário prático (ainda que insanamente poderoso), seria necessário quebrá-la durante a vida útil do tunnel. Quebrá-la após essa vida útil só ajudaria se você registrasse todo o tráfego de rede e quebrasse todos os tunnels (isto é, depois de quebrar a cripto efêmera da camada de transporte e trabalhar na cripto da camada de tunnel) 16:11 <jrandom> então, estamos falando na ordem de minutos aqui, não décadas 16:12 <jrandom> (então 1024 bits provavelmente é até exagero) 16:12 <@cervantes> há uma forma de medir o risco de maneira significativa? 16:13 <+Complication> Além disso, para um tunnel com mais saltos, o adversário teria que quebrar vários, certo? 16:13 <+Complication> (embora o construtor também tenha que construir vários) 16:13 <@cervantes> se não precisamos de mais do que 1024 bits, então é realmente necessário usar mais? 16:14 <@cervantes> sempre podemos usar um algoritmo mais forte em 3 anos, quando tivermos computadores quânticos muito mais poderosos 16:14 <@modulus> jrandom: se o adversário soubesse que às hh:mm algo importante vai passar por um tunnel é provável que ele pudesse quebrar isso de alguma forma registrando? 16:14 <jrandom> Complication: certo, eles teriam que quebrar vários (e as chaves DH que protegem a camada de transporte) 16:14 <@modulus> até onde sei 1024 bits é break()able com muito poder 16:15 <jrandom> muito poder e uma década 16:15 <jrandom> (ou três) 16:15 <@cervantes> jrandom: é difícil experimentar a cifra mais fraca? 16:15 <@modulus> eu tinha a impressão de que compostos de 1024 bits eram fatoráveis hoje em alguns meses. 16:15 <@cervantes> poderíamos disponibilizar na rede _PRE 16:15 <@cervantes> e ver se realmente oferece muito benefício 16:16 <@cervantes> modulus: sim, mas eles teriam que quebrar vários 16:16 <@modulus> se isso é baseado em log discreto e todo esse negócio então eu não sei nada 16:16 <@modulus> cervantes: aha 16:16 <jrandom> cervantes: isso requer mudanças em muitas estruturas, já que atualmente usamos slots de 512 bytes. embora, talvez, pudéssemos apenas preencher os primeiros 256 bytes com 0x00 para testes 16:17 <jrandom> modulus: ElGamal é baseado em log discreto 16:17 <@cervantes> jrandom: vale a pena testar? 16:17 <@modulus> certo, certo, eu estava imaginando RSA 16:17 <@cervantes> ou é melhor focar em outras coisas e voltar a isso se necessário 16:18 <jrandom> definitivamente vale a pena testar, embora no momento eu esteja hackeando algumas avaliações da camada de transporte 16:18 <+Complication> Acho que depende de como seus cálculos podem ser tratados na vida real. 16:18 <jrandom> (e o tempo de criptografia de 44 ms é bom o suficiente por enquanto, embora um tempo de 4 ms seria ainda melhor :) 16:19 <+Complication> Se isso se sustenta com os computadores atuais, vai melhorar com máquinas mais novas. 16:19 <@modulus> especialmente se vier hardware de cripto, como está começando a aparecer em alguns 16:19 <jrandom> mas, claro, mudar esse parâmetro não será feito de ânimo leve ou imediatamente. porém, se alguém tiver um bom motivo para evitá-lo, por favor, entre em contato 16:21 <jrandom> modulus: Eu ouvi falar de chips dedicados para AES e RSA, mas nada para DH/ElGamal. por outro lado, quando se olha para a NSA/etc como adversário, onde eles podem construir os seus, é possível 16:22 <@cervantes> eles têm máquinas de cripto construídas com tecnologia de donuts com granulados em anel 16:23 * Complication está disposto a atualizar o Celeron 300 para Athlon 600, se isso contiver a maré de donuts com granulados em anel :D 16:23 <tethra> heheh 16:24 <jrandom> mmMMmm donuts 16:25 <jrandom> ok, alguém tem mais alguma coisa sobre 2) progresso da rede _PRE? 16:25 <jrandom> se não, vamos pular para 3) I2Phex 0.1.1.37 16:26 <jrandom> Complication: quer dar o panorama? 16:26 <+Complication> Bem, parece funcionar. :) 16:26 <+Complication> Há esperança de conseguir mais webcaches para redundância extra em breve. 16:27 <jrandom> certo 16:27 <jrandom> hmm, você acha que precisamos de mais webcaches? não precisamos só de uma ativa? não que mais faça mal, claro 16:27 <+Complication> (se o legion conseguir resolver os mistérios que assombraram sua tentativa inicial) 16:27 <+Complication> Também há um bug misterioso lá, mas ele não dá um 'byte' forte, e estou tentando encontrá-lo. 16:28 <+Complication> Uma ativa é suficiente 16:28 <+Complication> Mais apenas aumenta as chances de que uma esteja ativa 16:28 <jrandom> legal 16:28 <+Complication> Porque no estágio atual, ele nunca vai descartar webcaches como ruins. São poucas ao todo. 16:29 <+Complication> (essa rotina será ativada se existirem mais de 10) 16:29 <+Complication> (se me lembro corretamente) 16:29 <+Complication> Quanto ao bug: após muito tempo operando, o subsistema de webcache às vezes trava 16:30 <+Complication> Provavelmente porque uma requisição GET do httpclient não consegue ser abortada com sucesso 16:31 <@modulus> então ele precisa morrer de tempos em tempos? 16:31 <+Complication> É seguro e nunca parece morder máquinas recém-chegadas 16:31 <jrandom> hmm, o que isso significa, funcionalmente? depois de um tempo, ele vai parar de se registrar no webcache, então novas pessoas não receberão referências a eles? 16:31 <+Complication> Se isso atingir uma máquina já bem integrada, essa máquina pode obter pares suficientes a partir dos pares aos quais já está conectada 16:31 <+Complication> Então, atualmente, o impacto parece perto de 0 16:31 <@modulus> legal 16:32 <+Complication> É curioso, só isso 16:32 <@modulus> sem regra sobre quando vai falhar ou algo assim? 16:32 <+Complication> modulus: geralmente não antes de 20 horas 16:33 <+Complication> E como não tenho como forçar isso a ocorrer, a depuração fica um pouco lenta 16:33 <@modulus> :_) 16:34 <+Complication> De qualquer forma, se eu encontrar, vou corrigir; e se não encontrar, vou achar outras coisas para mexer :) 16:34 <jrandom> :) 16:34 <jrandom> parece que é só um sintoma de alguns bugs que vimos na streaming lib / eepproxy, então corrigir aqueles deve corrigir isto 16:35 <+Complication> Pode ser 16:38 <jrandom> ok, ótimo, bom trabalho, Complication 16:38 <jrandom> alguém tem mais alguma coisa sobre 3) I2Phex 0.1.1.37, ou vamos pular para o geralzão, 4) ??? 16:41 <jrandom> (considere que pulamos) 16:41 <jrandom> ok, alguém tem mais alguma coisa para a reunião? 16:42 <tmp> Ou para sempre segurar a respiração? 16:43 <jrandom> e sempre, e sempre 16:43 * jrandom se apronta 16:43 * jrandom *baf* fecha a reunião