Reunião de Desenvolvedores do I2P - 12 de setembro de 2006

16:06 <jrandom> 0) oi 16:06 <jrandom> 1) 0.6.1.25 e status da rede 16:06 <jrandom> 2) I2PSnark 16:06 <jrandom> 3) Syndie (o quê/por quê/quando) 16:06 <jrandom> 4) Perguntas de cripto do Syndie 16:06 <jrandom> 5) ??? 16:06 <jrandom> 0) oi 16:06 * jrandom acena 16:06 <jrandom> notas de status semanais publicadas em http://dev.i2p.net/pipermail/i2p/2006-September/001307.html 16:07 <jrandom> já que essas notas saíram horas e horas atrás, vocês todos já deveriam tê-las lido e ter observações prontas, certo? ;) 16:07 <jrandom> pulando para 1) 0.6.1.25 e status da rede 16:08 <vulpine> <Complication> Sobre a 0.6.1.25, parece que funcionou bem por aqui, só um erro que eu não tinha visto antes 16:08 <jrandom> legal, qual é o problema? 16:08 <vulpine> * Complication procura nos logs 16:09 <jrandom> o tamanho da rede parece maior do que antes, embora ainda na mesma ordem de grandeza 16:09 <vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840" 16:10 <vulpine> <Complication> Começou com "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)" 16:10 <jrandom> ah ok, tranquilo, esse já existe há muito tempo, pode ignorar 16:11 <vulpine> <Complication> Ocorreu uma vez só 16:11 <vulpine> <frosk> eu recebi vários desse último 16:11 <vulpine> * jrandom cutuca fox 16:12 <vulpine> <Complication> Ah, e mais um: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ" 16:12 <vulpine> <Complication> (parece não ser significativo também, talvez congestão simples) 16:12 <jrandom> sim, provável 16:13 <jrandom> o irc está, obviamente, um pouco instável no momento ainda 16:13 <jrandom> (mas, pela primeira vez, não é culpa do i2p :) 16:14 <jrandom> ok, alguém tem mais algo para 1) Status da rede e 0.6.1.25? 16:15 <kostya213> só quero acrescentar que a .25 resolveu todos os meus problemas dos últimos meses 16:15 <jrandom> irado! 16:16 <vulpine> <green> por favor, mude o cálculo de status quando estiver usando apenas NTCP 16:16 <jrandom> 'tá, mas não é recomendado desabilitar udp (acho que eu disse explicitamente que não vou dizer às pessoas como desabilitar udp também) 16:17 <jrandom> mas o status deve ser atualizado para levar em consideração que udp não é o único transporte 16:17 <jrandom> vou corrigir isso na próxima revisão, obrigado 16:17 <vulpine> <green> jrandom : claro que você não conta, mas eu sei ler código ;) 16:18 <jrandom> certo, embora quando eu não recomendo algo, e digo às pessoas para nem tentarem, não se surpreendam se aparecer uma mensagem de exibição confusa ;) 16:19 <vulpine> <green> claro, eu também poderia simplesmente exibir "OK" no console :) 16:19 <jrandom> verdade 16:21 <jrandom> ok, vamos pular para 2) I2PSnark 16:21 <jrandom> zzz não parece estar por aí no momento 16:22 <jrandom> há algumas mudanças que o zzz está fazendo para melhorar o agendamento no i2psnark 16:23 <jrandom> (está um pouco... simplista no momento, se não me engano, embora eu não tenha certeza das modificações que o zzz está hackeando) 16:23 <jrandom> ((mas estou ansioso pelo progresso!)) 16:25 <jrandom> ok, se não houver mais nada em 2) I2PSnark, vamos seguir para 3.*) coisas do Syndie 16:26 <jrandom> vamos começar com 3.1) o que é o Syndie primeiro, já que há tanto a cobrir 16:27 <jrandom> recebi algumas perguntas antes da reunião sobre a criptografia para os posts 16:27 <jrandom> basicamente, os posts são criptografados de forma simétrica — qualquer um com a chave simétrica pode ler o post, pois está autorizado 16:28 <jrandom> respostas do canal são criptografadas de forma assimétrica para a chave pública associada ao canal/fórum 16:28 <jrandom> alguns posts podem usar criptografia baseada em frase-secreta para gerar a chave simétrica de leitura 16:29 <jrandom> e alguns posts podem incluir a chave simétrica nos cabeçalhos legíveis do post (de modo que qualquer um possa ler) 16:29 <modulus> qual é o objetivo desse último? 16:29 <jrandom> e alguns fóruns podem incluir a chave simétrica nos metadados do fórum, de modo que qualquer um possa ler o post, mas só se tiver os metadados do canal 16:29 <jrandom> modulus: para que tudo esteja sempre criptografado, até o que é publicamente legível 16:29 <jrandom> (assim grampos triviais são inúteis) 16:30 <modulus> certo, entendi. 16:31 <jrandom> ok, acho que isso cobre as perguntas de criptografia que fizeram antes da reunião 16:31 <jrandom> alguém tem perguntas sobre 3.1) o que é o Syndie? 16:31 <jrandom> (Quero dizer, mais coisas ficarão claras à medida que for divulgado, claro) 16:32 <vulpine> <void> hmm 16:33 <jrandom> que tal, void? 16:33 <vulpine> <void> <void> imagino que o arquivo de mensagens (.zip) também possa incluir outras mensagens, possivelmente de outras pessoas, como as mensagens citadas? 16:34 <jrandom> bem, sim, você pode incluir arquivos .snd como anexos, mas existe um espaço de nomes explícito, então você pode fazer links no estilo References: para mensagens anteriores 16:34 <jrandom> (ou seja, você não precisa fazer “encadeamento” estilo frost) 16:35 <vulpine> <void> ok, certo 16:37 <vulpine> <Complication> Sobre o Syndie, eu me perguntei como as pessoas resolveriam o problema de conceder acesso a um fórum de múltiplos autores (como contas em um quadro de mensagens comum) sem conceder isso irrevogavelmente, e evitar a bagunça indesejada quando for necessário revogar o acesso (pelos motivos que forem) 16:38 <vulpine> <Complication> Uma solução, claro, seria o autor especificar uma recomendação de cujas respostas os clientes deveriam exibir 16:38 <jrandom> Complication: crie um novo par de chaves pub/privada, dê a chave privada às pessoas (temporariamente) autorizadas e inclua a chave pública como a lista de "chaves autorizadas a publicar" 16:38 <vulpine> <Complication> ..e para os clientes, a menos que queiram pesquisar o histórico, seguir essa recomendação (ou mais especificamente sua versão mais recente) 16:38 <jrandom> (e quando não estiverem mais autorizadas, remova essa chave da lista de "chaves autorizadas a publicar") 16:39 <kostya213> jrandom: talvez você queira usar uma extensão diferente de .snd, já que é amplamente usada por apps de áudio; o MIME vai confundir 16:39 <jrandom> ah, certo — todos os fóruns têm um "dono" (uma chave privada de assinatura) que pode gerenciar a lista de quem tem permissão para publicar, etc. 16:39 <vulpine> <Complication> "chaves autorizadas a publicar" seriam metadados anexados ao post mais recente do autor, ou alguma outra mensagem, certo? 16:39 <jrandom> bom ponto, kostya213, embora talvez fiquemos presos com .dat então ;) 16:40 <jrandom> Complication: ah, desculpe, não, é como o syndie atual/antigo — posts de metadados separados e assinados para o próprio fórum/canal 16:40 <vulpine> * Complication acredita que alguém até já reivindicou .dat para algo :) 16:40 <jrandom> sim, o aplicativo chamado "octet-stream" ;) 16:40 <vulpine> <void> não parece que .syn seja usado para nada relevante 16:41 <vulpine> <Complication> Aha, posts especiais de metadados... certo, isso pode resolver 16:41 <jrandom> ah bacana, chegamos ao syn! 16:41 <jrandom> (bom olho, void, obrigado, kostya213) 16:41 <vulpine> <void> hmm, " 16:41 <vulpine> <void> hmm, "Word Synonym File", Empresa: Microsoft 16:42 <jrandom> bem, tenho certeza de que vamos dar um jeito 16:42 <kostya213> sim, é usado pelo Word 16:42 <vulpine> <void> mas podemos simplesmente ignorar isso :) 16:42 <kostya213> não perca a esperança, acho que é possível achar algo que não cause problemas com tipos MIME amplamente usados 16:43 <jrandom> ok, mais algo em 3.1) O que é o Syndie? 16:43 <vulpine> <void> err, por outro lado, por que ficar presos a extensões de três letras? é um resquício da era do DOS 16:43 <kostya213> uma coisa que precisa ser perguntada: por que limitar a uma extensão de três letras? ninguém usa DOS mais 16:44 <jrandom> heh 16:44 <kostya213> jinx no void 16:44 <kostya213> .syndie me parece bom 16:44 <vulpine> <void> .synd não conflitaria com nenhuma 16:44 <kostya213> bom também 16:45 <vulpine> <void> droga de lag :( 16:48 <jrandom> ok, vamos pular para 3.2) Por que o Syndie importa? 16:48 <vulpine> <void> jrandom: espera 16:48 <cervantes> (porque você diz que sim) 16:48 * jrandom espera 16:48 <jrandom> !thwap cervantes ;) 16:48 <vulpine> <void> as notas de status mencionam que um avatar pode ser anexado a um post, caso contrário um padrão será usado 16:49 <vulpine> <void> mas e se a pessoa quiser ter vários avatares predefinidos em vez de um único "padrão"? 16:49 <jrandom> sim, o autor pode incluir um avatar padrão nos metadados do próprio canal 16:49 <vulpine> <void> anexar o outro toda vez não vai ser eficiente 16:49 <jrandom> boa pergunta, void — vamos pular para aquele trecho de script nas notas 16:50 <jrandom> listauthkeys --authorizedOnly true 16:50 <jrandom> authenticate 0 16:50 <vulpine> <void> (?) 16:50 <jrandom> listauthkeys exibirá todas as identidades com as quais você pode assinar a mensagem dizendo que você é, enquanto "authenticate 0" escolhe uma identidade com a qual assinar 16:51 <jrandom> então, essa identidade tem seu próprio canal, e esse canal tem seus próprios metadados, que podem incluir um avatar 16:51 <vulpine> <void> hmm, uma identidade separada significa um par de chaves separado? 16:51 <jrandom> sim 16:51 <vulpine> <void> e se a pessoa quiser ter vários avatares em uma única identidade? 16:52 <jrandom> ela tem um avatar padrão nos metadados do canal e pode sobrescrevê-lo por mensagem 16:52 <kostya213> valor duvidoso 16:52 <vulpine> <void> vários avatares "padrão" para escolher 16:52 <vulpine> <void> ou estou sendo preciosista aqui? :) 16:53 <jrandom> ah, entendi o que você está dizendo. não, não será suportado no início 16:53 <jrandom> talvez depois 16:53 <vulpine> <void> verdade, kostya213, deixa pra lá então 16:53 <vulpine> <void> :) 16:53 <jrandom> (mas os avatares serão bem limitados em tamanho, então não deve ser muito incômodo incluí-los) 16:53 <vulpine> * Complication acha que adicionar por mensagem poderia ser fácil de codar 16:53 <vulpine> <void> então, 3.1) O que é o Syndie? 16:53 <vulpine> <Complication> (eventualmente) 16:54 <vulpine> * cervantes cola os servidores de irc 16:54 <vulpine> <void> Complication: jrandom acabou de dizer que já vai fazer isso :) 16:54 <jrandom> (por mensagem estará no básico, Complication; é a ideia de ter muitos 'padrões' para escolher, selecionando dizendo "use o avatar 1" numa mensagem em vez de incluir o próprio avatar) 16:54 <vulpine> <Complication> latência, latência... 16:54 <jrandom> ok, mais algo para 3.1? 16:54 <jrandom> se não, vamos para 3.2 16:55 <vulpine> <void> acho que é isso 16:55 <jrandom> isso aí. 16:56 <jrandom> tirando a ironia do cervantes, alguém tem perguntas/comentários/preocupações sobre o "por quê"? 16:56 <jrandom> (er, "preocupações") 16:58 <vulpine> <Complication> cervantes: você limpou a superfície com álcool antes de passar cola no ircd? ;) 16:58 <kostya213> na minha opinião, o syndie não precisa de justificativa, seu valor deve ser autoevidente para quem já se interessa por redes de anonimização 16:58 <kostya213> e está ciente dos perigos da centralização da informação 16:59 <vulpine> <Complication> (repost, por favor ignore se chegou ao servidor) 16:59 <vulpine> * Complication acha que o Syndie importa porque o Zé Ninguém rodando phpBB seria hackeado rápido demais, e o Zé Ninguém rodando $random_blogging_tool também sofreria 16:59 <vulpine> <Complication> (ainda que a probabilidade possa variar) 16:59 <vulpine> <void> de fato 16:59 <jrandom> sim, além de qualquer um enfrentando adversários realmente hostis (nem necessariamente em nível estatal) 17:00 <jrandom> ok, legal, só queria validar com vocês 17:00 <jrandom> mais algo em 3.2, ou passamos para 3.3) quando podemos usar o Syndie? 17:01 <vulpine> <void> bem, essencialmente é uma ferramenta de fórum/blog/e-mail/comunicação baseada em primitivos criptográficos e independente da camada de transporte 17:01 <vulpine> <Complication> ...e no cenário distante em que o adversário do Zé Ninguém monte ataques de interseção, qualquer um executando uma eepsite de qualquer tipo acabaria sendo comprometido eventualmente (exceto em uma rede enorme) 17:01 <kostya213> pode ser mais difícil convencer quem não vê valor imediato em privacidade/anonimato 17:01 <jrandom> kostya213: sim, embora possamos usar alguns truques, como navegar com segurança offline 17:02 <vulpine> <Complication> Eles podem apreciar segurança de qualquer forma 17:02 <jrandom> (por exemplo, um leitor de RSS offline que também baixa o conjunto completo de páginas referenciadas, não só o resumo do rss) 17:02 <vulpine> <void> então é, não vejo por que precisa de justificativa :) 17:02 <vulpine> <void> kostya213: não precisam ser anônimos para usar o Syndie 17:02 <cervantes> quando podemos usar o Syndie ou quando o Syndie estará usável? 17:02 <jrandom> falou e disse, void :) 17:03 <cervantes> para a interface de texto imagino que seja necessário uma quantidade bem grande de documentação de uso 17:03 <jrandom> cervantes: agora mesmo, o syndie é funcional (você pode criar posts, gerenciar canais, ler posts, responder a posts, etc.) 17:03 <kostya213> jrandom: como o syndie lida com redundância? quão resiliente é contra desaparecimento de conteúdo? 17:03 <cervantes> (antes de estar usável) 17:03 <jrandom> cervantes: há menus inline com cada comando documentado (ao menos minimamente) 17:04 <cervantes> legal, algum plano de exemplos de casos de uso? 17:04 <jrandom> kostya213: o syndie atua na camada de conteúdo — a redundância é tratada por outra coisa. se você publica no usenet, é replicado pelo usenet (por exemplo) 17:04 <cervantes> acho que o desafio será aprender como todos eles se “scriptam” juntos 17:04 <vulpine> <void> kostya213: isso está fora do escopo do syndie, depende do mecanismo de transporte 17:04 <vulpine> <void> infelizmente 17:04 <jrandom> boa ideia, cervantes 17:05 <jrandom> a primeira versão do syndie incluirá um sistema de replicação http como o syndie antigo/existente 17:05 <jrandom> cervantes: talvez alguns usuários beta possam montar seus scripts favoritos para distribuirmos :) 17:05 <modulus> mmm, isso é um app de console? 17:05 <jrandom> modulus: sim, o primeiro app baseado em texto 17:06 <modulus> excelente! 17:06 <cervantes> jrandom: desde que os usuários beta consigam descobrir como usar ;-) 17:06 <jrandom> hehe 17:06 * jrandom considerou curses/etc, assim como apenas CLI, mas uma interface de texto interativa e “scriptável” provavelmente é a mais simples e útil 17:07 <jrandom> (sem GUI, quero dizer) 17:07 <cervantes> modulus: viu, o jrandom ouviu seu feedback incessante :) 17:07 <vulpine> <Complication> Se quiserem, as pessoas provavelmente podem construir interfaces textuais mais interativas em cima disso 17:07 <jrandom> sim, com certeza 17:08 <jrandom> (o código é feito para suportar integração fácil com um cliente de irc, como o pircbot) 17:08 <modulus> cervantes: hehe 17:09 <modulus> acho que você poderia colocar uma GUI em cima disso também, se funcionar mais ou menos como imagino 17:09 <modulus> embora dê muito mais trabalho. 17:09 * kostya213 aguarda o plugin para emacs 17:09 <modulus> hahaha 17:09 <jrandom> heh 17:09 <modulus> na verdade um modo do emacs não é uma ideia tão ruim, talvez atraia mais malucos para isso. 17:10 <cervantes> aperte ctrl-alt-shift-break-setacima-num7-b para escolher sua identidade 17:10 * jrandom vai deixar isso para os elipsers resolverem ;) 17:10 <kostya213> sem ofensa, mas não sei se esse projeto precisa atrair mais malucos 17:10 <vulpine> <Complication> esses tipos de malucos também codificariam? 17:11 <jrandom> tomara, Complication 17:11 <jrandom> ok, espero que 3.3) explique um pouco do que vem por aí 17:11 <jrandom> quanto ao *quando*, bem, vamos ver, mas eu espero que "em breve" ;) 17:12 <jrandom> ok, alguém tem mais algo para 3.3)? 17:12 <vulpine> * Complication daria boas-vindas a algumas hordas desses malucos então :D 17:12 <cervantes> bem, há programar e há escrever perl ofuscado interpretado em tcl 17:12 <kostya213> um plugin para FUSE também poderia ser útil 17:13 <jrandom> sim 17:13 <jrandom> ok, vamos pular para 4) cripto para o syndie 17:13 <jrandom> alguém tem comentários sobre essas questões? 17:14 <vulpine> <Complication> Eu gostaria de ter, mas não sou competente para estimar a força desses cifradores/hashes/tamanhos de chave 17:15 <vulpine> <void> qual o tamanho das assinaturas elgamal/rsa? 4kbit para uma chave de 2kbit? 17:15 <vulpine> * Complication deixa essa conversa inteiramente para outros 17:15 <jrandom> não sei de cabeça 17:15 <vulpine> <void> vs dsa? 17:16 <jrandom> (embora ecc (criptografia de curva elíptica) pareça bonita e pequenininha) 17:16 <modulus> Assinaturas ElGamal são difíceis e longas. como a equipe do gnupg descobriu. 17:16 <jrandom> sim, embora alguns desses truques estivessem relacionados a reuso de chave 17:16 <vulpine> <void> ah, ok 17:16 <vulpine> <void> é, parece mesmo 17:16 <tethra> modulus: se são difíceis e longas, tem site fetichista para isso 17:17 <jrandom> ok, esse ponto era realmente só um aviso e um convite a comentários quando vocês tiverem ideias 17:17 <cervantes> não seria possível implementar algum tipo de cifradores plugáveis — quando um método melhor de criação de chaves for padronizado, podemos adicioná-lo ao syndie e novos posts começariam a usá-lo, mas ainda podemos usar métodos obsoletos para posts antigos 17:17 <tethra> (foi mal) 17:17 <jrandom> cervantes: inclui um prefixo DSA:, então um prefixo Elg: funcionaria 17:17 <modulus> você está usando dsa limitado a 1024 ou não? 17:18 <modulus> também, qual hash? sha1 ou versões de ordem superior? 17:18 <cervantes> então realmente você está preocupado em dar ao syndie um bom começo 17:18 <jrandom> dsa é só 1024bit (há propostas dsa2 para maiores, mas ainda não são padronizadas) 17:18 <jrandom> e sim, dsa requer sha1 17:18 <modulus> hmm, meu entendimento é que eram bem fortes pré-padrões. 17:18 <kostya213> cervantes tem um bom ponto, ter conteúdo do syndie em cifradores fixos oferece pouca sigilo futuro; você nunca sabe quando um algoritmo vai pro saco 17:18 <modulus> mas não acompanho o processo de perto o suficiente, então você provavelmente está certo 17:19 <jrandom> kostya213: mas escolha é ruim para cripto, então devemos ter valores fixos quando pudermos 17:19 <jrandom> (ruim por causa do anonimato) 17:19 <vulpine> <void> você sabe por que mais pessoas/protocolos não usam ecc, afinal? têm receio da falta de pesquisa, ou só preocupados com compatibilidade? 17:19 <modulus> patentes. 17:20 <jrandom> patentes e FUD (medo, incerteza e dúvida), e ainda algumas preocupações de implementação 17:20 <vulpine> <void> ah, certo, modulus 17:20 <modulus> a propósito, há bom motivo para usar dsa vs rsa-sha512, por exemplo? 17:20 <tethra> patentes e FUD e o estado (oh meu) 17:20 <modulus> não estou tentando ser chato, só considerando que o gpg, por exemplo, foi por esse caminho, entre outros. 17:20 <jrandom> não reviso essa opção há anos, modulus 17:21 <modulus> obviamente dsa é um padrão, o que fala a favor, mas as chaves são pequenas e os hashes são fracos. não que eu ache provável que acabe sendo o elo mais fraco ;-) 17:23 <cervantes> Eu não proporia "escolha" — mas novas versões do syndie viriam com cifradores (obrigatórios) cada vez mais seguros 17:23 <vulpine> <Complication> Deixar alguma folga nas estruturas para mudanças futuras parece razoável, independentemente de qual cripto atual se prove melhor, eu diria 17:23 <jrandom> sim, embora isso implique recuar para versões mais fracas/antigas para interoperar 17:23 <jrandom> mas ok, vamos trabalhar nisso 17:24 <jrandom> ok, vamos pular para 5) ??? 17:24 <jrandom> alguém tem mais algo para trazer à reunião? 17:25 <cervantes> não poder ler os posts mais recentes da sua fonte favorita é um bom incentivo para garantir que todos se mantenham atualizados 17:25 <jrandom> até certo ponto 17:26 <cervantes> não=nem 17:26 <jrandom> (sim, é um incentivo, mas as pessoas são preguiçosas/não interessadas em "atualizar software", etc.) 17:27 <jrandom> s/people/some people/ 17:27 <cervantes> acho que esse é o problema delas, porém 17:27 <jrandom> verdade 17:27 <kostya213> pelo menos a implementação do i2p pode ter atualização indolor 17:28 <jrandom> com certeza 17:28 <cervantes> quanto ao ??? — desculpem pela conectividade do irc — o ISP deve restaurar um de seus principais backbones "o mais rápido possível" 17:29 <jrandom> w3wt 17:29 <vulpine> <Complication> No tópico ???, eu talvez possa acrescentar que a segunda parte (mais extensa) das modificações no NTP está perto de funcionar, e espero commitar para testes em breve 17:29 * cervantes joga sal por cima do ombro 17:29 <kostya213> quais os planos de curto prazo para desenvolvimento do router? o roadmap está preciso? 17:29 <jrandom> maneiro, Complication 17:29 <vulpine> <Complication> O objetivo é contestar os servidores NTP com base nos desvios de relógio dos pares 17:29 <jrandom> kostya213: estabilização até o syndie sair 17:30 <jrandom> (do meu ponto de vista) 17:30 <vulpine> <Complication> (e evitar tomar ação potencialmente danosa à conectividade) 17:31 <cervantes> ótimo 17:32 <jrandom> ok, mais algo para a reunião? 17:34 * jrandom se apronta 17:34 * jrandom *baf*s encerra a reunião