I2P dev meeting, July 29, 2003

--- Log aberto Ter Jul 29 16:54:31 2003 17:11 <@hezekiah> Tue Jul 29 21:11:18 UTC 2003 17:11 <@hezekiah> A 51ª (acho) reunião iip-dev. 17:11 <@hezekiah> Agenda: 17:11 <@hezekiah> 1.) Boas-vindas 17:11 <@hezekiah> 2.) coisas do jrand0m 17:11 <@hezekiah> 3.) Coisas de quaisquer outros desenvolvedores 17:11 <@hezekiah> 4.) Qualquer coisa que o nop adicionar quando/se ele chegar 17:12 <@hezekiah> 5.) Perguntas e comentários das eternamente ávidas massas mal lavadas. ;-) 17:12 <@hezekiah> OK! 17:12 <@hezekiah> Bem-vindos todos à 51ª (acho) reunião iip-dev 17:12 <@hezekiah> Item número 2! 17:12 <@hezekiah> coisas do jrand0m 17:12 -!- thetower [none@anon.iip] entrou em #iip-dev 17:12 * hezekiah entrega o microfone ao jrand0m 17:12 <@jrand0m> subagenda: 17:12 <@jrand0m> 2.1) I2CP spec & status de desenvolvimento 17:12 < co> Onde estão os logs da reunião 50? 17:12 <@jrand0m> 2.2) planos do SDK 17:12 <@jrand0m> 2.3) cripto 17:12 <@jrand0m> 2.4) roadmap / status do proto de rede 17:13 <@hezekiah> co: cohesion está trabalhando para colocá-los no ar 17:13 <@jrand0m> (a propósito, é "mic", de microphone) 17:13 <@hezekiah> jrand0m: Desculpe. :) 17:13 <@hezekiah> jrand0m: (E esse erro vindo de um cara de som!) 17:13 -!- luckypunk [~yetalohe@anon.iip] entrou em #iip-dev 17:13 -!- odargur [odargur@anon.iip] entrou em #iip-dev 17:13 <@jrand0m> 2.1) I2CP: a especificação foi commitada no CVS com uma leve modificação em uma das mensagens (MessageStatusMessage) 17:14 <@jrand0m> Comentários sobre I2CP são sempre bem-vindos, quanto antes melhor. 17:14 <@hezekiah> jrand0m: Onde está a spec no CVS? ... e está no CVS do SF também? 17:14 <@jrand0m> O motivo do "quanto antes melhor" é que teremos uma implementação de cliente Java funcional até sexta. 17:14 -!- some_random_guy [~dan@anon.iip] entrou em #iip-dev 17:14 * thecrypto cruza os dedos por essa 17:14 <@jrand0m> Além de um router apenas local até o fim de semana, espero 17:15 <@jrand0m> não, hez, só no cathedral 17:15 <@jrand0m> bem lembrado, thecrypto. 17:15 <@jrand0m> Caveat: 17:15 <@hezekiah> Argh. Ainda não consigo fazer o CVS funcionar com o cathedral. 17:15 <@jrand0m> alguma cripto não está 100%, mas está toda "stubada" para nos permitir encaixar implementações mais completas ou outras depois 17:15 <@jrand0m> hezekiah> te colocamos para funcionar depois da reunião. 17:15 <@hezekiah> jrand0m: Valeu. :) 17:16 <@jrand0m> a spec está em i2p/doc/specs/data_structure_spec/datastructures.html 17:16 <@jrand0m> thecrypto> você tem algo a acrescentar sobre a impl em java? 17:16 -!- ArdVark [simple1@anon.iip] entrou em #iip-dev 17:16 <@jeremiah> o router apenas local que você mencionou era o de Python, certo? ou há um em Java também? 17:17 <@jrand0m> isso depende :) 17:17 <@jrand0m> jeremiah/hezekiah> como vão o cliente Python e o router apenas local? 17:17 <@thecrypto> na verdade, não, exceto pela questão de cripto que acho que vamos discutir em breve 17:17 <@jrand0m> manda ver, thecrypto. 17:17 <@hezekiah> jrand0m: Está indo. Finalmente consegui fazer o transporte TCP funcionar ontem. 17:17 <@jeremiah> parece ok, acho que a maior parte vai depender mais da velocidade de dev do hezekiah do que da minha 17:17 <@hezekiah> jrand0m: O Jeremiah tem umas coisas legais rolando com as estruturas de mensagem. 17:18 <@hezekiah> hezekiah: Espero que consigamos cumprir o prazo. 17:18 <@jrand0m> legal. 17:18 <@jeremiah> também... sexta é meu aniversário, então pretendo não estar perto do computador 17:18 <@hezekiah> jeremiah: Compreensível. :) 17:18 <@hezekiah> jeremiah: E feliz aniversário adiantado. :) 17:18 <@jeremiah> obrigado 17:18 <@jrand0m> pulando um pouco para a agenda 2.4> quando esperaríamos conseguir ter o router Python apenas local? realisticamente? 17:19 <@jrand0m> certo, se você programar na sexta eu vou chutar seu traseiro 17:19 <@jrand0m> virtualmente, pelo menos 17:19 <@hezekiah> jrand0m: Achei que era isso que eu estou codando. O router Python apenas local. 17:19 <@jrand0m> si, é isso mesmo 17:19 <@hezekiah> Bem, o prazo é 1º de agosto. 17:19 <@jeremiah> agora estamos trabalhando em coisas de formato binário de mensagem de/para 17:19 <@hezekiah> Isso não é tão difícil. 17:19 <@jeremiah> certo 17:19 <@hezekiah> Espero ter isso pronto em um dia ou dois. 17:20 <@jrand0m> isso é sexta :) 17:20 <@jrand0m> ótimo 17:20 <@hezekiah> Espero que esteja pronto até 1º de agosto. Realisticamente pode atrasar alguns dias, mas espero que não. 17:20 <@jrand0m> 'k, então vou evitar mexer em qualquer coisa de router apenas local em Java e trabalhar na spec da rede depois que a API do cliente Java estiver pronta. 17:20 <@hezekiah> Sim. Especificações são boas. 17:21 <@hezekiah> Elas tornam meu trabalho MUITO mais fácil! :) 17:21 <@jrand0m> isso. 17:21 <@jrand0m> Vou escrever também um rápido resumo de 2 parágrafos do ambiente de testes de I2CP em Java 17:21 <@jrand0m> Solto isso hoje à noite 17:22 <@hezekiah> jrand0m: Adoro como você escreve essas specs tão rápido. 17:22 <@hezekiah> Isso é divertido. :) 17:22 <@jrand0m> Ok, hez/jeremiah/thecrypto> mais algo sobre I2CP? 17:22 <@jrand0m> lol 17:22 -!- dm [~hifi@anon.iip] entrou em #iip-dev 17:22 <@hezekiah> Hum ... 17:22 <@hezekiah> Eu quero a spec de cripto! 17:22 < dm> bem-vindo 17:22 * hezekiah faz bico como um bebê 17:22 <@hezekiah> ;-) 17:23 <@hezekiah> Falando sério, ... não consigo pensar em nada. 17:23 <@jrand0m> esse é o item 2.3 da agenda 17:23 <@thecrypto> ainda esperando o 2.3 entrar 17:23 <@hezekiah> Se eu lembrar, eu entro online e te encho de perguntas, jrand0m. :) 17:23 <@jrand0m> beleza. 17:23 <@jrand0m> ok. 2.2) planos do SDK 17:23 <@hezekiah> Em que ponto da agenda acabamos? 17:23 <@hezekiah> 2.4? 17:23 <@hezekiah> E já terminamos 2.1? 17:23 <@jrand0m> 2.1 17:24 <@jrand0m> agora 2.2> o SDK 17:24 <@hezekiah> OK. 17:24 < dm> a agenda tem ponto decimal agora? Já vejo progresso. 17:24 <@hezekiah> Agora estou situado (em vez de perdido). 17:24 <@thecrypto> podemos ter 2 pontos decimais :) 17:25 <@jeremiah> o que compõe o SDK além das várias APIs? 17:25 <@jrand0m> o SDK é: a API do cliente (quantas tivermos disponíveis), o router apenas local, um app de exemplo trivial e alguma documentação de como usar as APIs. 17:25 <@hezekiah> jrand0m: Eu estaria certo em supor que você está escrevendo a documentação? :) 17:26 <@jrand0m> Eu gostaria de lançar o SDK o quanto antes, para que desenvolvedores de terceiros (ou até de segunda ou primeira parte) possam escrever e testar aplicações que rodarão sobre o I2P, para que, quando a rede estiver operacional, já comecemos a todo vapor. 17:26 <@jrand0m> hezekiah> Na verdade, eu preferiria não. 17:26 <@jrand0m> hezekiah> e digo isso não porque não quero documentar, mas porque estou perto demais do assunto. 17:26 <@hezekiah> jrand0m: OK. 17:26 <@jrand0m> deveríamos ter alguém que NÃO implementa o código escrevendo esse documento, para que seja compreensível para pessoas que não escreveram a spec do I2CP 17:26 <@hezekiah> jrand0m: Resolvemos isso quando chegarmos lá. 17:26 <@jrand0m> mas, se necessário, eu assumo. 17:26 <@jrand0m> ok. 17:27 < dm> que incentivo as pessoas têm para escrever apps sem uma rede operacional, e como testariam seus apps. 17:27 <@hezekiah> jrand0m: Ou por que alguém que projetou o protocolo não escreve, e depois alguém que nunca trabalhou com ele revisa até fazer sentido? 17:27 <@jrand0m> Ok, houve alguma discussão sobre um app simples estilo 'talk'. 17:27 <@jrand0m> dm> as pessoas poderão testar com o SDK. 17:27 <@thecrypto> na verdade, eu estava me perguntando qual seria a utilidade disso se for apenas local 17:28 <@jeremiah> dm: a ideia é implementar uma rede simples que não é totalmente funcional mas consegue passar mensagens 17:28 <@thecrypto> você só conseguiria falar consigo mesmo 17:28 <@jeremiah> na verdade não é apenas local; ele inclui apenas cliente-router, não o código router-router 17:28 <@jrand0m> thecrypto> você pode falar com outras Destinations. I2P é independente de localização - local é o mesmo que remoto. 17:29 <@thecrypto> ok 17:29 < dm> legal e tal, só não vejo ninguém (além de vocês 3-4) escrevendo nada se só der para testar localmente. Mas enfim, tanto faz. 17:29 <@jrand0m> então um app de talk pode abrir duas instâncias do aplicativo e conversar consigo mesmo, etc 17:30 <@thecrypto> mas quando adicionarmos a parte remota, o app deve simplesmente funcionar 17:30 <@jrand0m> dm> certo, isso é só um pré-requisito para outras pessoas escreverem apps. 17:30 <@jrand0m> exatamente. 17:30 <@jrand0m> o app vai funcionar sem absolutamente NENHUMA mudança 17:30 < co> dm: Este é um aplicativo de teste. Assim que o código router-router for escrito, você poderá falar com outros. 17:30 <@jeremiah> ter o apenas local só nos permite desenvolver em paralelo 17:30 < dm> sim, mas se o app assume latência de 10 ms e acaba sendo 12 segundos, não vai funcionar muito bem :) 17:31 <@jrand0m> concordo, dm 17:31 < dm> alguma estimativa de latência, aliás? :) 17:31 <@jrand0m> se tivermos 12 segundos de latência, temos trabalho a fazer. 17:31 <@jrand0m> mas não teremos isso. 17:31 <@jrand0m> estimativas são de 0,6–2,7 s 17:31 <@jrand0m> para uma rede de 5.000.000 de routers. 17:31 <@hezekiah> A propósito, isso me lembra: precisamos falar sobre ElGamal. 17:31 <@thecrypto> o maior tempo é a configuração 17:31 <@jrand0m> (veja os arquivos do iip-dev para os modelos rudimentares) 17:32 < dm> menor ou maior para redes menores? 17:32 <@jrand0m> hezekiah> 2.3: cripto. 17:32 <@thecrypto> depois disso o tempo cai drasticamente 17:32 <@jrand0m> dm> menor. 17:32 <@thecrypto> hezekiah: você provavelmente tem a mesma pergunta que eu 17:32 <@jrand0m> thecrypto> exatamente, o tempo de configuração é offline para entrega de mensagens [vulgo configurar túneis antes de enviar mensagens] 17:32 < dm> ok, só te testando ;) 17:32 <@jrand0m> heh 17:33 <@jrand0m> ok. última parte do SDK - o app 17:33 <@jrand0m> co/thecrypto: ideias sobre uma impl de talk em java? dá para fazer? tempo? planos? interesse? 17:34 <@thecrypto> quando a API estiver pronta, provavelmente conseguimos um talk em cerca de uma semana, 2 no máximo, co concorda? 17:34 <@jeremiah> chat poderia ser construído como um router jabber, certo? 17:34 < co> Deve ser relativamente fácil de fazer. 17:34 < co> thecrypto: Concordo. 17:34 <@jrand0m> jeremiah> não conheço jabber, mas se jabber pode rodar sobre a API, beleza 17:35 <@jrand0m> fechado co & thecrypto 17:35 <@jrand0m> jeremiah> note que isso é apenas um app trivial para prova de conceito, não um Kickass Anonymous IM System :) 17:35 <@jeremiah> ainda não ;) 17:35 <@thecrypto> podemos adicionar essa funcionalidade depois 17:35 <@jeremiah> k 17:36 <@jrand0m> heh 17:36 <@thecrypto> vamos começar pequeno 17:36 * jrand0m coloca na agenda "adicionar recurso: ser kickass" 17:36 < some_random_guy> heh 17:36 < some_random_guy> bom recurso :) 17:36 -!- dm2 [~hifi@anon.iip] entrou em #iip-dev 17:37 <@jeremiah> jrand0m: Acho que perdi isso no 2.1, mas alguma opinião sobre kademlia como uma DHT? exige menos manutenção que Chord 17:37 -!- nop [nop@anon.iip] entrou em #iip-dev 17:37 < nop> desculpa 17:37 <@jrand0m> e um dia desses precisamos colocar alguém no redesign do IIP para rodar sobre isso. 17:37 -!- dm [~hifi@anon.iip] saiu [Ping timeout] 17:37 < nop> o quê? 17:37 < nop> quem 17:37 < nop> onde 17:37 < nop> quando 17:37 < nop> ? 17:37 -!- dm2 agora é conhecido como dm 17:37 <@jrand0m> olha ele, falando do diabo 17:37 < WinBear> por quê? 17:37 < WinBear> deixa pra lá 17:37 < nop> na verdade sou um anjo 17:37 <@hezekiah> lol 17:38 <@thecrypto> alguém passe um log para o nop 17:38 < WinBear> azrel 17:38 <@jrand0m> jeremiah> kademlia é uma boa DHT, e vamos definitivamente revisar essa além da turma de chord/tapestry, junto com DHTs "sloppy" na spec da rede. 17:38 <@jeremiah> jrand0m: legal 17:38 <@hezekiah> thecrypto: Estou cuidando disso. :) 17:38 < nop> eu estava ouvindo sobre uma que arrebenta 17:38 < nop> chamada chord/middle 17:38 -!- hif [~hifi@anon.iip] entrou em #iip-dev 17:39 < nop> mas sabe quem é bom para conversar? brandon wiley 17:39 * jrand0m !thwaps nop 17:39 < nop> Eu sabia que isso ia doer 17:39 <@hezekiah> lol 17:39 <@hezekiah> Quem é Brandon Wiley? 17:39 < nop> alguém com quem tenho certeza de que o jrand0m já teve inúmeras discussões 17:39 < nop> :) 17:39 < nop> alguém me envie um log por email 17:39 < dm> Brandon é o nome real do jrandom, pego! 17:39 <@hezekiah> Estou cuidando disso. 17:40 <@hezekiah> Segura os cavalos, nop. :) 17:40 < nop> haha 17:40 < dm> Brandon Wiley é o primeiro programador do Freenet, tendo 17:40 < dm> cofundado o esforço de desenvolvimento com o inventor do sistema, Ian Clarke 17:40 < nop> o userx está aqui ou lá 17:40 < WinBear> você pode falar com o meu brandon wiley 17:40 <@hezekiah> OK. Está a caminho ... se meu cliente de email cooperar e enviar um anexo de 15K. 17:41 <@thecrypto> conversamos bastante :) 17:41 <@hezekiah> nop: O UserX não está nem aqui nem ali. 17:41 <@hezekiah> OK! 17:41 <@hezekiah> O log foi enviado, nop! Vá ler. :) 17:41 <@thecrypto> e agora esperamos 17:41 <@jrand0m> ok, alguém tem algum pensamento sobre o SDK enquanto damos um minuto pro nop se atualizar? ;) 17:41 <@hezekiah> jrand0m: Agora que resolvi esse negócio do log ... o que é kademlia? 17:42 <@jrand0m> Mais Uma DHT Acadêmica :) 17:42 <@hezekiah> E onde posso conseguir um link para a página do kademlia? 17:42 -!- Erazerhead [JohnDoe@anon.iip] entrou em #iip-dev 17:42 <@jeremiah> http://kademlia.scs.cs.nyu.edu/ 17:42 <@hezekiah> Valeu. :) 17:42 <@thecrypto> YAADHT? 17:42 <@hezekiah> lol 17:42 <@hezekiah> Os nomes hoje em dia ... viu só! 17:43 <@jrand0m> e se algum dia surgir alguma coisa de CS que você não entenda, vá a citeseer.nj.nec.com/cs 17:43 < WinBear> klamidia? 17:43 <@hezekiah> OK. 17:43 < nop> jrand0m: eu estava prestes a dizer citeseer 17:43 < dm> qual é o ETA do SDK? 17:44 * jrand0m evita injetar a "clap" no I2P 17:44 * jrand0m espera que o SDK saia na semana que vem. talvez na próxima sexta? 17:44 * thecrypto cruza outro par de dedos 17:45 <@jrand0m> ok. passando para 2.3) Cripto. 17:45 * hezekiah imagina o thecrypto com umas 13 mãos de dedos cruzados ... e então percebe que ele já deve ter ficado sem. 17:45 <@hezekiah> Aê! 17:45 * jrand0m cutuca o nop para ver se ele está aqui 17:45 <@hezekiah> Cripto! 17:45 <@hezekiah> Tenho algo para começar. :) 17:46 <@thecrypto> eu também tenho algo 17:46 <@thecrypto> Eu primeiro! :) 17:46 * jrand0m não tem, então vocês dois que se entendam 17:46 <@hezekiah> o thecrypto pode ir primeiro. :) 17:46 <@jrand0m> thecrypto> fale 17:46 <@jrand0m> :) 17:46 <@thecrypto> Ok, sobre ElGamal 17:47 <@thecrypto> Precisamos decidir se teremos p e alpha comuns ou não 17:47 -!- some_random_guy [~dan@anon.iip] saiu [BitchX: a interface original de apontar-e-clicar.] 17:47 <@thecrypto> o problema de um p e alpha comuns é que teríamos que achar um jeito de trocar as chaves de todo mundo ao mesmo tempo 17:48 <@jrand0m> ou seja: muito ruim. 17:48 < co> thecrypto: Desculpe, o que são p e alpha? 17:48 <@thecrypto> a vantagem é que podemos escolher valores especialmente otimizados e a quantidade de dados transmitida para uma chave pública é bem pequena 17:48 * jrand0m não vê boa razão para usar p e alpha comuns, além de economizar alguns bits 17:48 <@thecrypto> co: para todos os efeitos práticos, números grandes especiais 17:49 <@jrand0m> thecrypto> ainda podemos otimizar para os p e alpha do destino mais comumente criptografado 17:49 <@thecrypto> ou devo explicar como o ElGamal funciona 17:49 <@thecrypto> jrand0m: sim 17:49 < co> thecrypto: OK. 17:49 <@thecrypto> também podemos fazer cada um ter p e alpha diferentes 17:50 <@jeremiah> para quem se interessar: http://www.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem 17:50 <@thecrypto> isso significa que a quantidade de dados transmitida é bem maior e temos que ver como empacotar isso 17:50 <@jrand0m> isso, valeu jeremiah 17:50 <@jrand0m> bem maior? 17:50 <@jrand0m> Achei que com p e alpha variáveis poderíamos usar p e alpha menores? 17:51 <@thecrypto> em vez de números de 160 bits, agora estamos falando de 2 de 1024 bits e 1 de 160 17:51 <@thecrypto> ou 2308 no total 17:51 <@hezekiah> 288 bytes 17:51 <@hezekiah> Grande coisa. 17:52 <@jrand0m> ok, não é tão ruim. planejamos 256 bytes 17:52 <@hezekiah> Essas chaves não são transferidas com tanta frequência, certo? 17:52 <@jrand0m> mais 32 não dói 17:52 <@jrand0m> hezekiah> elas são inseridas na DHT 17:52 <@hezekiah> Ah! 17:52 <@hezekiah> É por isso que queríamos pequeno. 17:53 <@thecrypto> também, outro problema do elgamal que talvez precisemos nos preocupar 17:53 <@jrand0m> bem, não dói muito se a estrutura RouterInfo tiver uns 10K 17:53 -!- mrflibble [mrflibble@anon.iip] entrou em #iip-dev 17:53 <@jrand0m> 'k, qual é a questão, thecrypto? 17:53 <@thecrypto> a expansão da mensagem é 2, o tamanho de uma criptografia ou assinatura é o dobro do tamanho da mensagem 17:54 <@jrand0m> A criptografia ElG é apenas da chave AES 17:54 <@jrand0m> A assinatura ElG é apenas dos hashes SHA256 17:55 <@thecrypto> ok, é só algo para levantar também 17:55 <@hezekiah> jrand0m: O que me deixa realmente intrigado. 17:55 <@thecrypto> voltando à questão original, queremos ter p e alpha compartilhados ou queremos que cada um tenha p e alphas diferentes? 17:55 <@jrand0m> hezekiah> hmm? você leu a spec de estrutura de dados para #Payload? 17:55 <@jrand0m> alguma ideia/pergunta sobre isso, hezekiah? 17:55 * dm agora entende como DHTs funcionam. 17:55 <@jrand0m> nop> opiniões? 17:55 <@jrand0m> ótimo dm 17:55 <@hezekiah> Se uma assinatura tem o dobro do tamanho dos dados assinados, então por que a spec do IC2P diz que uma assinatura tem 128 bytes? 17:56 < nop> não 17:56 < nop> p compartilhado 17:56 <@hezekiah> Não deveria ser 512? 17:56 <@thecrypto> o hash dos bytes 17:56 < nop> e alphas 17:56 < dm> parece que é necessário muito trabalho ao entrar em uma DHT, mas acho que funciona. 17:56 < nop> base compartilhada, p compartilhado 17:56 <@jrand0m> hezekiah> bits / bytes. 17:56 < nop> isso vai eliminar muito risco 17:56 <@thecrypto> então quão grande queremos? 17:56 <@hezekiah> Hmm 17:56 <@jrand0m> nop> em 3 anos, vamos querer que todo mundo mude seus p e alpha ao mesmo tempo? 17:56 < nop> e manter nosso protocolo alinhado com padrões 17:57 <@thecrypto> já que isso abre grandes ataques sobre p e alpha 17:57 < nop> jrand0m: existem os chamados primos "cozidos", neste momento, e é esse o momento que estou considerando 17:57 <@thecrypto> que, se concluídos, derrubam a rede inteira 17:57 < nop> acredito que podemos nos adaptar com o tempo 17:57 < nop> mas um primo Oakley estático aprovado é aconselhável 17:57 < nop> pois foram amplamente revisados como seguros 17:58 < nop> e isso é uma base melhor do que quaisquer de nossas suposições sobre geração de primos (prováveis, no caso) 17:58 <@thecrypto> se não for primo, criptografia ou assinaturas não funcionam, então simplesmente descartamos 17:59 <@jrand0m> concordo, eles têm primos melhores. então quando um desses primos for fatorado, todo mundo que os usa fica exposto, correto? 17:59 < dm> hmmm, tenho que ir. Isso está sendo logado, certo? 17:59 < nop> jrand0m: sim 17:59 <@thecrypto> sim 17:59 < nop> jrand0m: quando isso acontecer, todos saberemos 17:59 < nop> Não quero arriscar a geração de primos 17:59 -!- dm [~hifi@anon.iip] saiu [it better be] 17:59 <@thecrypto> como saberemos? 17:59 < nop> além de adicionar tempo de cálculo 17:59 -!- hif [~hifi@anon.iip] saiu [] 17:59 < nop> thecrypto: se você usar um conjunto de primos Oakley padrão, saberá quando tiver sido quebrado 18:00 <@thecrypto> como? 18:00 < nop> pois será notícia bem pública 18:00 <@jrand0m> nop> saberemos, a menos que a NSA quebre. 18:00 < co> nop: Quantos desses primos existem? Se não muitos, usá-los é um risco. 18:00 <@thecrypto> sim, escuta passiva ainda é uma ameaça 18:00 <@thecrypto> e posso escrever um programa para gerar p's e alphas e testá-los em cerca de uma hora 18:00 <@jrand0m> nop> seria notícia muito pública, a menos que fosse uma ameaça à segurança nacional. 18:00 < co> Espera... não, pergunta idiota. Deixa pra lá. 18:01 < nop> isso é verdade, mas acredito, por inúmeros contatos na comunidade de criptografia, que se for resolvido será resolvido antes da NSA 18:01 < nop> nossa geração de primos não vai garantir isso de qualquer forma 18:01 < nop> se eles resolverem esses primos 18:01 < nop> é melhor você pensar em um novo algoritmo para usar 18:01 <@jrand0m> 'k. 18:02 < nop> por favor use estático, isso aliviará problemas com criptoanálise e reduzirá o risco de erro na nossa cripto 18:02 <@jrand0m> Eu estava em cima do muro, e estou tranquilo em usar primos compartilhados conhecidos e bons. 18:02 <@thecrypto> ok, então vamos escolher um primo 18:02 <@jrand0m> nop> ainda temos você planejado no ganttchart para a spec de cripto 18:02 <@thecrypto> e eles têm geradores para esses primos? 18:02 < nop> sim 18:02 < nop> sim, tenho 18:03 < nop> 2 18:03 < nop> que é uma raiz primitiva dos primos que terei 18:03 < nop> que tamanho de primos vocês querem? 18:03 <@thecrypto> estou pensando em algo entre 2048-4096 18:03 <@hezekiah> Estamos usando uma chave de 2048, certo? 18:03 < nop> sim, então usem um primo de 4096 ou maior 18:04 <@thecrypto> porque o compartilhamento nos deixa expostos 18:04 <@thecrypto> e se isso decolar, seria um primo muito valioso para quebrar 18:04 * cohesion perdeu a reunião 18:04 < co> Vocês estão usando esse primo dentro do ElGamal, certo? 18:04 <@hezekiah> Então as chaves serão de 4096 bits? 18:04 <@cohesion> alguém logou? 18:04 < nop> co sim 18:04 < nop> não, hezekiah 18:04 < nop> as chaves serão 2048 18:04 <@cohesion> ok 18:04 < nop> o primo será maior que 4096 18:04 * cohesion volta ao trabalho 18:04 <@hezekiah> OK. Por favor perdoem meu entendimento horrível. :) 18:04 < nop> já volto 18:05 <@thecrypto> p e alpha podem ser fixos, alpha será 2 e p será o primo que escolhermos 18:05 < nop> ok, vou enviar por email os candidatos a primo 18:05 < nop> me deem algumas horas, tenho trabalho a fazer 18:05 * jeremiah vai jantar, lerá os logs depois 18:05 <@thecrypto> a chave secreta é a, um número entre 0 e p - 2 18:05 <@thecrypto> a chave pública é 2^a mod p 18:06 < nop> podemos ir ao próximo tópico e voltar para que eu possa estar aqui para isso, já volto, estou no trabalho e preciso fazer uma tarefa rapidinho 18:06 <@hezekiah> OK, então você chama meu 'x' de 'a' 18:06 <@hezekiah> ... e meu 'g' de 'alpha'. 18:06 < nop> por favor movam as explicações do algoritmo para mensagem privada 18:06 <@hezekiah> thecrypto: Certo? 18:06 <@thecrypto> sim 18:06 <@jrand0m> ok. então thecrypto, nop e hezekiah vão acertar os detalhes do algoritmo depois. 18:06 < nop> ok 18:06 < nop> com certeza 18:06 <@hezekiah> OK ... então thecrypto, você terminou sua pergunta? 18:06 <@thecrypto> então vamos continuar 18:06 < nop> Vou enviar nossos primos por email 18:06 <@thecrypto> si 18:06 <@thecrypto> m 18:06 <@hezekiah> OK. Minha vez! :) 18:07 <@hezekiah> Por que diabos estamos usando ElGamal para assinatura? 18:07 <@jrand0m> ok. 2.4) roadmap / status do proto de rede 18:07 <@jrand0m> ainda não, hez :) 18:07 <@jrand0m> ah, hez 18:07 <@hezekiah> Quando posso perguntar isso? 18:07 -!- dm [~hifi@anon.iip] entrou em #iip-dev 18:07 <@jrand0m> o que você recomendaria, dado que temos chaves públicas ElG? 18:07 <@thecrypto> quando o nop voltar 18:07 <@jrand0m> não, você está certo, eu estou errado. agora é a hora certa. 18:07 < co> Próximo tópico, por favor. 18:07 <@hezekiah> jrand0m: Bem, o problema é o seguinte: 18:07 <@hezekiah> velocidade 18:08 <@hezekiah> Eu estava brincando com as coisas de cripto hoje e levei um choque desagradável. 18:08 <@hezekiah> ElGamal foi astronomicamente mais lento ao verificar uma assinatura do que DSA ou RSA. 18:08 <@jrand0m> hezekiah> isso é problema da implementação da biblioteca ou do algoritmo? 18:08 <@hezekiah> Não sei. 18:09 <@hezekiah> Mas consultei o Applied Cryptography e vi que pelo menos parte do problema é com o ElGamal. 18:09 <@hezekiah> O AC tem tabelas com o tempo para assinatura e verificação para DSA, RSA e ElGamal. 18:09 <@jrand0m> então você está sugerindo irmos para RSA para criptografia, descriptografia e assinatura? 18:09 <@hezekiah> E 18:09 <@hezekiah> Não estou sugerindo muito de forma definitiva. 18:09 <@jrand0m> ...embora possamos adicionar uma segunda chave pública de assinatura na estrutura RouterInfo 18:10 <@hezekiah> Só estou dizendo que o AC lista a verificação de ElGamal em 9,30 segundos. 18:10 <@hezekiah> RSA é 0,08 segundos 18:10 <@thecrypto> para 1024 bits 18:10 <@jrand0m> caramba. 18:10 <@hezekiah> DSA é 1,27 segundos 18:10 <@hezekiah> Agora você vê meu problema. 18:10 <@hezekiah> ElGamal é muito lento ... 18:10 <@jrand0m> precisamos de verificação abaixo de <100 ms. 18:10 <@jrand0m> se não, abaixo de <10 ms 18:10 <@hezekiah> ... e meu CPU é 333 MHz. 18:11 <@hezekiah> A propósito, esses cálculos foram feitos em um SPARC II 18:11 <@hezekiah> Eu tenho um AMD K6-2 333MHz. 18:11 <@jrand0m> um sparc 2 é uma máquina de 40 MHz. 18:11 <@hezekiah> verificando uma assinatura ElGamal com meu módulo Python (que usa um backend em C, mas cheira meio estranho). 18:11 < luckypunk> deus 18:11 < luckypunk> bem 18:11 <@hezekiah> jrand0m: OK. Não manjo de SPARC. 18:11 <@hezekiah> De qualquer forma, levou uns 20 segundos. 18:12 <@hezekiah> Se não um pouco mais. 18:12 < luckypunk> qualquer um com um processador de 1 ghz -2 ghz não precisa se preocupar. 18:12 < co> hezekiah: Em computadores modernos, então, a verificação deve ser aceitavelmente rápida. 18:12 <@hezekiah> DSA e RSA foram quase instantâneos. 18:12 <@jrand0m> hezekiah> Eu lembro. sparc 2 era rápido em '92 18:12 <@hezekiah> Enfim, é por isso que trago isso à tona. 18:12 <@hezekiah> Poderíamos adicionar uma chave DSA, mas isso significaria 2 chaves 18:12 <@thecrypto> ainda devemos nos preocupar com pessoas que não têm máquinas ultra rápidas 18:12 <@hezekiah> Ou poderíamos ir de RSA. 18:12 <@jrand0m> minha lembrança da nossa justificativa para ElG em vez de RSA é que a preferência não era muito forte. 18:13 <@hezekiah> Ou podemos conviver com o longo tempo de verificação e usar ElG. 18:13 <@jrand0m> thecrypto> com certeza. 18:13 <@thecrypto> nop foi quem disse, vamos usar elgamal 18:13 <@hezekiah> thecrypto: Precisamente. Papai e mamãe vão acabar usando I2P de forma transparente. 18:13 <@jrand0m> vamos querer distros bootáveis para 386, bem como implementações em applet. 18:13 <@hezekiah> Papai e mamãe não terão hardware de última geração. 18:13 < luckypunk> oh deus 18:14 < luckypunk> todo mundo que quer isso tem pelo menos um p100 ou algo assim. 18:14 < co> Não vamos comprometer a segurança escolhendo um algoritmo mais fraco que seja mais rápido. 18:14 <@hezekiah> co: Não estou sugerindo isso. 18:14 <@thecrypto> elgamal e DSA são equivalentes 18:14 <@jrand0m> ok. então vamos revisitar a escolha RSA/ElG. as mudanças de código não devem ser problema. 18:14 < luckypunk> eles podem sofrer. 18:14 <@hezekiah> co: RSA e DSA são tão respeitáveis quanto ElGamal. 18:14 < luckypunk> lol 18:14 < luckypunk> se você se preocupa com anonimato 18:14 <@hezekiah> thecrypto: E nada poderia estar mais longe da verdade. 18:14 < luckypunk> você não vai ligar tanto para velocidade. 18:14 <@thecrypto> hezekiah: são ambas implementações do mesmo algoritmo geral 18:14 < dm> o passo óbvio aqui é alguém determinar com certeza qual o uso de CPU para as duas :) 18:14 <@jrand0m> luckypunk> você ouve muito as reclamações a respeito do freenet? 18:15 <@hezekiah> thecrypto: DSA não cifra. É só um algoritmo de assinatura, e é muito mais rápido que ElG. 18:15 <@thecrypto> hezekiah: acontece que as equações de assinatura e verificação do DSA são mais rápidas 18:15 <@jrand0m> dm> se o Applied Crypto mediu a verificação de RSA em 1/100 da de ElG, isso me basta. 18:15 <@thecrypto> podemos usar ElG para criptografia/descriptografia e DSA para assinatura/verificação 18:15 <@jrand0m> as opções são ir para RSA ou adicionar uma chave DSA (~256 bytes a mais) à estrutura RouterInfo 18:15 <@hezekiah> Certo. Mas agora a DHT tem 2 chaves públicas. 18:16 <@jrand0m> e daí? 18:16 < co> Vamos ter uma chave pública. Vai ser menos confuso. 18:16 <@hezekiah> co: Só seria 'confuso' para desenvolvedores ... e precisamos saber o que estamos fazendo. :) 18:16 <@thecrypto> acho que é hora de esperar o nop nisso também 18:16 <@hezekiah> Certo. 18:16 <@jrand0m> mas se for 100 vezes mais lento... 18:16 <@jrand0m> enfim, vamos continuar a discussão de design de cripto offline. 18:17 <@hezekiah> jrand0m: Manda um email para a lista, vai? 18:17 < luckypunk> jrand0m: cara, não me importo, se você não consegue esperar 40 segundos para sua página carregar, dane-se. 18:17 <@thecrypto> ou depois da parte principal da reunião 18:17 <@jrand0m> porra, eu mando e-mail para a lista todo dia :) 18:17 <@jrand0m> heh lucky 18:17 -!- hif [~hifi@anon.iip] entrou em #iip-dev 18:17 <@jrand0m> certo. 18:17 <@jrand0m> ok> 2.4) roadmap / status do proto de rede 18:17 -!- hif agora é conhecido como dm2 18:18 <@jrand0m> Fiz muito pouco em relação ao proto de rede além de responder às mensagens do co, pois tenho trabalhado no Java e no I2CP. 18:18 <@jrand0m> o roadmap ainda parece no alvo. 18:18 <@jrand0m> alguma mudança no roadmap? 18:19 <@jrand0m> ok. se houver, quando houver, apenas enviem para a lista. 18:19 <@hezekiah> Certo. 18:19 -!- dm [~hifi@anon.iip] saiu [Ping timeout] 18:19 <@jrand0m> o roadmap.xml agora está no módulo i2p do CVS i2p/doc/projectPlan 18:19 -!- dm2 agora é conhecido como dm 18:20 <@hezekiah> jrand0m: Deixa eu adivinhar ... isso também está no cathedral? 18:20 < nop> voltei 18:20 < nop> foi mal 18:20 <@jrand0m> ok, é isso por enquanto (embora possamos voltar a perguntas sobre protocolo de rede na seção de perguntas). 18:20 <@jrand0m> Não tenho mais subitens 18:20 <@jrand0m> hezekiah> Eu não uso sf 18:20 <@thecrypto> bem, agora que o nop voltou podemos voltar rapidamente à questão da velocidade 18:20 <@hezekiah> Certo. 18:21 < nop> que questão de velocidade 18:21 <@thecrypto> Elgamal é lento para verificar 18:21 < nop> isso é verdade 18:21 < nop> mas rsa também é 18:21 <@jrand0m> nop> o Applied Crypto mediu a verificação de RSA em 1/100 da de ElG para assinatura. 18:21 < nop> hmm 18:22 <@hezekiah> RSA e DSA são instantâneos para mim. 18:22 <@hezekiah> ElG leva 20 segundos. 18:22 < nop> DSA é el gamal 18:22 <@jrand0m> Então podemos ou migrar para RSA ou adicionar uma chave DSA à estrutura RouterInfo 18:22 < nop> DSA 18:22 < nop> I have anything with R's in it 18:22 < nop> ;) 18:22 * jrand0m não lembra de um motivo muito forte para ElG em vez de RSA 18:22 * jrand0m fica ressentido com isso 18:22 <@hezekiah> nop: Pode nos esclarecer? Por que não usamos RSA? 18:22 <@hezekiah> Em todos os detalhes sórdidos. :) 18:23 < nop> pelos seguintes motivos, e é debatível, mas 18:23 < dm> alguém me mande por msg a URL do iip-dev quando puder. 18:23 < nop> fatorar primos é como se resolve RSA 18:23 < dm> a lista iip-dev, no caso. 18:23 < luckypunk> RSA foi quebrado. 18:23 < luckypunk> praticamente. 18:23 < nop> sim, RSA de 512 bits foi quebrado 18:23 < luckypunk> ou foi o DES? 18:23 < luckypunk> bah. 18:23 <@hezekiah> DES foi quebrado. 18:23 < nop> acho que você está falando do DES 18:23 < co> luckypunk: Chaves de certo tamanho foram quebradas. 18:23 <@hezekiah> RSA ainda não chegou lá. 18:24 < nop> enfim 18:24 < luckypunk> mas pode ser. 18:24 < nop> voltando ao meu ponto 18:24 <@hezekiah> Mas a questão é: uma chave RSA de 2048 ou 4096 é segura hoje? 18:24 <@thecrypto> um segundo 18:24 < nop> chaves RSA de 512 bits foram quebradas com computadores de escritório 18:24 <@jrand0m> estamos olhando para RSA 2048 bits ou ElG 18:24 < nop> hezekiah: seria, mas aqui vai a parte divertida 18:24 < nop> se você consegue fatorar primos 18:24 < nop> você pode quebrar RSA 18:24 < nop> se você consegue computar logaritmos discretos você consegue resolver RSA e EL gamal 18:24 < nop> estamos mais perto de fatorar 18:24 < nop> do que de computar logs discretos 18:24 < nop> neste momento 18:24 < luckypunk> logaritmos discretos não são um pouco mais difíceis? 18:25 <@hezekiah> Se você consegue fatorar primos rapidamente, você pode quebrar RSA. 18:25 <@hezekiah> luckypunk: É isso que o nop está dizendo. 18:25 < luckypunk> computadores quânticos 18:25 < luckypunk> estão quase funcionais. 18:25 <@hezekiah> lol 18:25 < nop> e a relação de tamanhos em bits para chaves públicas de log discreto é mais forte que a das chaves RSA 18:25 < nop> por exemplo, uma chave de 768 bits não é aconselhada pelas variantes de diffie-hellman, mas não foi provadamente quebrada 18:25 <@hezekiah> Então, no fim das contas, adicionamos uma chave DSA. 18:25 <@thecrypto> nop, não paga de Bill Gates, é fatorar um n grande onde n = pq 18:25 < nop> como as chaves RSA de 512 bits foram 18:25 <@thecrypto> já que fatorar números primos é fácil 18:25 < nop> valew 18:25 < nop> desculpa 18:25 <@jrand0m> hezekiah> é o que parece. 18:26 < nop> eu estava tentando fazer todos entenderem 18:26 < nop> desculpa 18:26 <@thecrypto> só uma pequena clarificação 18:26 <@jrand0m> beleza nop, tranquilo, gracias 18:26 <@hezekiah> OK. 18:26 < nop> então DSA 18:26 < nop> então 18:26 <@hezekiah> Então vamos adicionar uma chave DSA? 18:26 < nop> que também é uma variante de diffie-hellman 18:26 <@jrand0m> ok, dado isso, continuaremos os detalhes de cripto offline. 18:26 < nop> prefiro logs do que fatores 18:27 < nop> ;) 18:27 <@hezekiah> A propósito, o que ainda precisamos continuar? 18:27 < co> dm: Essa URL é http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel 18:27 <@thecrypto> hezekiah: escolher o primo mágico 18:27 <@hezekiah> Ah, certo! 18:27 < dm> valeu co, achei as specs do jrand0m. Agora só preciso de uma impressora com bastante toner. 18:27 < nop> vou enviar isso 18:27 <@jrand0m> hezekiah> atualize a spec de estrutura de dados, adicione info sobre o DSA, especifique o tamanho de chave para DSA, etc. 18:27 < nop> vamos fazer isso offline 18:27 <@jrand0m> lol dm. 18:28 <@hezekiah> OK, então você tem mais algo, jrand0m? 18:28 <@jrand0m> ok, terminei minhas coisas. hezekiah> você tinha o # 3? 18:28 <@hezekiah> Sim. 18:28 < dm> hmmm. as imagens não estão aparecendo. 18:28 <@hezekiah> 3.) O que quer que o nop queira adicionar à agenda. 18:28 < dm> jrand0m: há um lugar para pegar o 'I2P Network Spec Draft 2003.07.23' com as imagens incluídas? 18:29 < co> dm: Sim, eu tive esse problema também. 18:29 <@jrand0m> dm/co> peguem a primeira revisão da spec de rede (duas semanas antes no zip), que inclui o png. 18:30 <@jrand0m> (está no cvs também, mas ainda não é anon/público) 18:30 < arj> quando vai ser? :) 18:30 <@hezekiah> Uau! 18:30 <@hezekiah> O CVS está rápido agora! 18:31 <@jrand0m> arj> estamos fazendo o possível para evitar hype, então quando estiver pronto vamos tornar as coisas públicas, mas manter relativamente discreto até lá. 18:31 < nop> hezekiah: o do cathedral? 18:31 <@jrand0m> arj> porém, tudo que estamos fazendo é GPL, pelo menos até agora. 18:31 <@hezekiah> nop: Sim 18:31 <@hezekiah> ! 18:31 < dm> duas semanas antes em qual zip? 18:31 <@jrand0m> oh beleza, você conseguiu fazer funcionar, hezekiah? 18:31 < arj> jrand0m: só queria ler as specs mais recentes 18:31 <@jrand0m> dm> network_spec_*.zip se não me engano 18:31 <@hezekiah> jrand0m: Sim! :) 18:31 < dm> eu também, com imagens! 18:31 <@thecrypto> iip-dev tem a maior parte 18:32 <@jrand0m> arj> http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/292 tem tudo menos uma pequena mudança. 18:32 <@jrand0m> (bem, exceto pela Client Access Layer, que está em outra spec agora) 18:33 < arj> ok valeu 18:33 <@jrand0m> a spec da Client Access Layer é http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/298 18:33 < dm> ok, e o link para o zip com as imagens? 18:33 <@jrand0m> ok. nop você tem algo, ou vamos para "5) abrindo para perguntas/pensamentos das massas"? 18:34 -!- mihi [none@anon.iip] saiu [Ping timeout] 18:34 * jeremiah está de volta e leu o backlog 18:34 <@jrand0m> dm> um instante, puxando aqui 18:34 <@jrand0m> http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/269 18:35 < dm> vlw 18:35 <@jrand0m> ok, alguma pergunta / pensamento? 18:35 -!- arj [anders@anon.iip] saiu [EOF do cliente] 18:35 < co> sim. 18:35 <@jrand0m> np 18:35 < co> Estamos no item 5 agora? 18:35 * jrand0m sabia que você teria algo, co :) 18:35 < co> Atualmente, a comunicação entre cliente e router (saída) não é criptografada. 18:35 <@jrand0m> sim, já que o nop está lento :) 18:35 <@jrand0m> (malditas pessoas com empregos e tal) 18:36 <@hezekiah> lol 18:36 < co> Suponha que eu tenha um amigo de confiança e queira usar o router dele para mensagens de saída. 18:36 <@hezekiah> jrand0m: Bem, você sabe. Nem todo mundo pode se dar ao luxo de não ter vida. 18:36 <@jrand0m> co> em grande parte correto. os payloads das mensagens são criptografados, mas o resto do I2CP não é 18:36 < co> Isso não me colocaria em risco de ter minhas mensagens capturadas. 18:37 <@hezekiah> Sim. Elas seriam transferidas em claro pelo fio. 18:37 <@hezekiah> A menos que você faça um túnel ssh até o router dele ou algo assim. 18:37 <@jrand0m> se você tem um amigo de confiança e se conecta ao router dele, ele pode saber que você enviou ou recebeu uma mensagem, mas não o que você enviou. 18:37 <@jeremiah> as mensagens ainda não passariam por criptografia de chave pública? 18:37 <@hezekiah> Opa. 18:37 <@hezekiah> Erro meu. 18:37 < dm> Vou usar I2P como forma de aprender coisas novas para evitar que o trabalho 9–5 (admin windows, ferramentas VB) me transforme em zumbi. 18:37 <@jrand0m> Eu topo adicionar suporte a listener SSL, em vez de apenas listener TCP. 18:37 <@hezekiah> Esqueci que clientes fazem criptografia fim a fim. 18:37 < co> Sua suposição é que eu rode um router local confiável, mas como dito acima, eu talvez não queira fazer isso para que as mensagens não sejam conectadas a mim. 18:37 <@jrand0m> sim, jeremiah, mas isso é só para o payload 18:37 <@jrand0m> heh vlw dm 18:37 -!- mihi [none@anon.iip] entrou em #iip-dev 18:38 <@jrand0m> hmm. 18:38 <@hezekiah> jrand0m: Por que não adicionar suporte depois para que a comunicação cliente-router seja criptografada? 18:38 <@jrand0m> você realmente sempre deveria ter um router local confiável. você pode fazê-lo conectar-se a outro router conhecido não-local confiável também. 18:39 < co> Verdade, mas eu gostaria de endossar a sugestão do hezekiah. 18:39 <@jrand0m> hezekiah> Eu topo adicionar isso depois (onde depois: t=0...dataDeLançamento ;) 18:40 <@jrand0m> Não tenho absolutamente nenhum problema em até adicionar suporte a DH+AES para I2CP 18:40 < nop> bom 18:40 <@jrand0m> na verdade, esses recursos podem ser adicionados também por router, individualmente 18:41 < nop> jrand0m: também acredito que a rotação de chaves polimórfica será necessária, assim como tráfego chaffe 18:41 < nop> tenho certeza de que vamos ver isso em uma reunião posterior 18:41 < nop> só um comentário à parte 18:41 < nop> usando conjuntos de chaves 18:41 <@jrand0m> sim, quando tratarmos da comunicação router-router. 18:41 <@jrand0m> (1–2 semanas) 18:41 < co> nop: Atualmente, não vejo tráfego chaffe na spec, mas seria bom adicionar. 18:42 <@jrand0m> existe chaffe no sentido de que routers e participantes de túnel testam a si mesmos e seus pares. 18:42 -!- arj [~anders@anon.iip] entrou em #iip-dev 18:42 <@jrand0m> além de requisições DHT serem chaffe em relação a mensagens de payload 18:42 < nop> jrand0m: bem, vou mergulhar em pesquisa sobre evadir alguma análise de tráfego e expor qualquer plaintext conhecido 18:42 <@jrand0m> e os transportes individuais terão seus próprios estilos de chaffe (por exemplo, o transporte http vai consultar o google por "cute puppy dogs" periodicamente, ou o que for) 18:43 < nop> bem, esse chaffe é legal, mas também falo de chaffe criptografado 18:43 < nop> isso ajuda a rotacionar as chaves de sessão 18:43 < nop> e manter seu nó ocupado mesmo quando inativo 18:43 < dm> talvez mude isso para pornografia infantil pesada para um chaffe mais realista 18:43 <@jrand0m> entendido. 18:43 < dm> brincadeira! 18:43 <@hezekiah> dm: Ainda bem. Caso contrário eu teria que te !thwack. 18:43 <@hezekiah> :) 18:44 <@jrand0m> DHT (com link criptografado) e mensagens de teste (free route mix, ao estilo onion/garlic) não terão problemas de plaintext conhecido 18:44 < nop> já que nós mais novos nós terão menos tráfego ao começar 18:44 <@jrand0m> além de termos suporte a transportes de taxa de bits constante 18:44 < nop> garlic é demais 18:44 < nop> :) 18:44 < nop> jrand0m: estilo DC net :) 18:44 * jrand0m vai fazer uma massa com muito alho depois que a reunião acabar 18:45 < nop> jrand0m: Eu quis dizer garlic routing 18:45 <@hezekiah> lol! 18:45 <@jrand0m> eu sei ;) 18:45 < nop> jrand0m: de qualquer forma, taxa de bits constante poderia ser forçada com o block encryption já que AES gera blocos de 128 bits 18:45 < nop> ;) 18:45 < nop> então poderíamos apenas preencher todos os dados para 16 bytes por mensagem 18:45 <@jrand0m> co> minhas respostas ao seu email fizeram sentido? 18:47 <@jrand0m> *ping* 18:47 <@hezekiah> *pong* 18:47 <@thecrypto> *pong 18:47 <@thecrypto> * 18:47 <@jrand0m> mais alguma pergunta de alguém, ou meu iproxy desconectou? 18:47 <@jrand0m> heh beleza 18:47 <@hezekiah> thecrypto: Pacote fragmentado! 18:47 <@hezekiah> lol 18:48 <@thecrypto> perdi aquele finalzinho 18:48 <@thecrypto> MTU menor aqui :) 18:48 <@hezekiah> jrand0m: Bem, não tenho perguntas. 18:48 < co> jrand0m: Sim, as respostas fizeram sentido. 18:48 < co> Não tenho mais perguntas. 18:48 < dm> Vou criar perguntas quando ler as specs amanhã. 18:49 <@jrand0m> bem, espero que você tenha mais depois :) 18:49 <@jrand0m> ótimo dm 18:49 < dm> ótimo inicialmente talvez. 18:49 < dm> bom, vou nessa. boa sorte, pessoal! 18:49 -!- dm [~hifi@anon.iip] saiu [] 18:50 <@jrand0m> nós ainda temos o grande período de revisão por pares de 2 semanas no cronograma, mas revisão antes disso é apreciada (mesmo que todos os detalhes ainda não tenham sido inseridos) 18:51 <@jrand0m> ok. mais alguma pergunta, ou vamos encerrar a #52 como uma reunião de 102 minutos? 18:52 <@thecrypto> #51 18:52 <@hezekiah> Uh, eu li 1:57 minutos. 18:52 <@hezekiah> Duh. 18:52 <@hezekiah> Sou burro 18:52 <@hezekiah> Não liguem para mim. 18:52 <@hezekiah> Não tenho perguntas ... 18:52 <@hezekiah> Perguntas! 18:52 * jrand0m nunca conseguiu somar... 18:52 <@hezekiah> Falem agora ou calem-se até terça que vem! 18:52 <@hezekiah> Uma vez! 18:53 <@hezekiah> ... Duas vezes! 18:53 <@thecrypto> Vendido para o cara de camisa social 18:53 <@hezekiah> Foi! 18:53 * jrand0m vai à cozinha fazer um jantar muito atrasado 18:53 <@jrand0m> gracias srs y srtas 18:53 <@hezekiah> Tchau, pessoal! 18:53 <@jeremiah> Eu devia fazer checkout do código-fonte antes de ir embora 18:53 <@hezekiah> Até terça que vem! --- Log fechado Ter Jul 29 18:53:55 2003