Estava querendo comentar sobre como estava vendo Nekopara e achei estranho o primeiro capítulo do vídeo se chamar “Capítulo 7” e seguir numerado, mas na instância onde eu estava parecia não ser um lugar bom para comentar sobre isso, então resolvi ir para uma instância mais focada em anime. É uma instância focada em inglês, mas para mim isso não tem problema.

Quanto aos capítulos estou até pensando em arrumar uma forma de detectar quando os nomes dos capítulos estão com problema e renomeá-los com nomes mais apropriados como “Introdução / Abertura / Parte A / Parte B / Encerramento / Prévia”. O único problema é detectar que parte é qual: abertura e encerramentos geralmente são 90 segundos e dá para fazer análise de áudio para detectar as músicas, porém diferenciar uma prévia de uma cena pós-créditos não é tão simples, mesmo que usasse as legendas para isso ainda assim não é tão fácil.

Quanto ao Mastodon, estou postando isso mais para forçar uma atualização do blog e retomar o status do link do meu blog como verificado. Como a instância é focada em inglês fico pensando se vale a pena escrever postagens em inglês, só não sei como fazer isso usando o WordPress. Deve ter um plugin para blogs de várias línguas – melhor, deve ter uma dúzia de plugins – o problema é achar um que presta.

Bem, é isso por hoje, até.

O post Mastodon apareceu primeiro em o canto do qgustavor.

Por quê?

A menos que você esteja lutando contra o sistema, como alguns tradutores da Crunchyroll estão fazendo, é importante entender as limitações da forma que você trabalha. Se você distribui vídeos usando arquivos MKV, por exemplo, é recomendado que você evite usar fontes pesadas (está no fim desta página): não faz sentido você aumentar o tamanho do vídeo em 10MB só porque precisa de mostrar um kanji em uma nota de tradução, certo? Por outro lado, limitações como essa limitam a capacidade dos tradutores, o que não é bom.

Como?

Haveriam soluções melhores? Proponho uma: reduzir o tamanho das fontes eliminando os caracteres que não foram usados na legenda. Não é algo difícil de ser executado pois há várias ferramentas criadas para esse propósito, basta procurar por “font subsetting”. Para aplicar esse conceito com legendas, fiz um script que recebe uma legenda e uma pasta com fontes e otimiza elas removendo os caracteres não usados. Só usar o ass-parser e o fontkit, simples.

Mas não me contentei em apenas reduzir as fontes, resolvi unir todas as fontes em um arquivo só, assim a quantidade de metadados e outras informações redundantes entre as fontes é reduzida. Isso também tem o benefício de evitar que alguém extraia as fontes do MKV (usando o mkv-extract talvez) e instale no sistema.

Pontos positivos e negativos

Há dois grandes pontos positivos para esse conceito:

1. Ele permite que tradutores possam usar quantas fontes acharem que for necessário sem se preocupar com o tamanho das fontes. Querem colocar um kanji em uma nota de tradução? Não tem problema. Querem usar dezenas de fontes para fazer algum efeito? Ótimo!
2. Ele permite reduzir o tamanho dos vídeos sem reduzir a qualidade do vídeo e de forma mais eficaz e inteligente do que outras técnicas que certos grupos usam, como compactar o vídeo usando rar ou 7z e dividir aberturas e encerramentos em arquivos separados (o que reduz a compatibilidade, o que não é inteligente).

Há um ponto que pode ser positivo ou negativo, dependendo das suas prioridades: a legenda fica ilegível se unir as fontes em uma só e elas não forem carregadas, isso é bom pois garante que ninguém vai ver uma legenda com fontes padrões erradas, mas isso pode ser ruim para os que preferem uma legenda ruim do que nenhuma.

Ainda há três pontos negativos: complexidade adicional, dificuldade para editar a legenda distribuída e problemas de licenciamento já que as licenças de certas fontes não permitem que elas sejam editadas dessa maneira. Esse último problema não afeta fansubs pois quase todas¹ usam fontes sem ter permissão de redistribuição. Fansubbers que me falaram “a gente só usa fontes gratuitas”, por favor, leiam isso e aprendam que Arial não é uma fonte gratuita.

Na prática

Testei esse conceito com um episódio de Kobayashi-san. Como disse semana passada eu tinha trabalhado nesse anime para ver a versão dublada, logo eu já tinha o karaokê que eu traduzi para português e o vídeo do BD, bastou adicionar a tradução das falas as quais peguei da fansub Aenianos. Como apenas traduzi o karaokê da DameDesuYo!, que é um que usa várias fontes, o arquivo final ficou com mais de 35 fontes, o que é perfeito para o teste.

Postei o arquivo final em uma hospedagem e perguntei para o pessoal da UO se eles conseguiam abrir o arquivo, se estava funcionando corretamente, qual era o player que usaram e o que acharam que eu tinha alterado no vídeo. Os resultados:

Como podem ver, a maioria conseguiu abrir sem problemas, mas 28% das vezes o player não carregou a fonte, deixando a legenda ilegível. Praticamente todos os players populares aparecem entre os que apresentaram problemas, como MPV, MPC-HC e VLC. Por outro lado esses players também apareceram entre os que o vídeo funcionou, então não é que o problema esteja nos players, mas na forma que eles foram configurados.

Esse dado é interessante para fansubs, pois provavelmente essas pessoas estão vendo animes com os players mal-configurados de forma que as fontes não são carregadas. Isso não é só ruim porque elas estão vendo uma tradução pior do que a que foi distribuída, mas também representa que várias pessoas nem notam o problema e acham que vários grupos usam Arial por escolha própria e não porque elas que configuraram o player delas de forma errada.

Uma ideia que ainda não coloquei em prática, mas que acho que seria boa, seria deixar no início da legenda um aviso grande de que as fontes não foram carregadas usando uma fonte que aparece nada no lugar dos caracteres (algo como essa fonte, mas com espaços no lugar de retângulos), assim se as fontes não forem carregadas o aviso aparece, se elas forem carregadas.

Essa ideia não aumenta muito o tamanho do arquivo já que a fonte adicional só precisa ter os caracteres necessários para ocultar o aviso e pode ser aplicada em qualquer legenda existente caso algum grupo queira avisar quem está vendo o vídeo de que o player dele não está configurado corretamente e, por isso, ele não estará vendo o vídeo da forma que ele foi criado.

Alternativas

Embora o teste tenha sido com as legendas reduzidas e unidas, as fontes podem ser apenas reduzidas. Dessa forma as legendas podem funcionar mesmo com as fontes erradas, caso alguém prefira isso. A redução final não vai ser tão eficiente, mas ainda é muito boa. O problema de pessoas extraindo fontes faltando caracteres e instalando no sistema pode ser mitigado renomeando as fontes.

Alguns lendo essa postagem serão rápidos para pensar que hardsub é uma solução, mas quem leu a postagem da semana passada sabe que editar um formato comprimido causa perda de qualidade, e todos os formatos usados para distribuir vídeos são comprimidos, logo usar hardsub não é uma opção para quem se preocupa com qualidade. Repito: quem usa hardsub não se preocupa com qualidade. Ponto final.

Talvez a alternativa mais inteligente e simples é usar streaming: como a distribuição de fontes via streaming ocorre separadamente do vídeo, o tamanho delas não acumula e o problema de um arquivo de 500MB virar um de 600MB simplesmente não existe. Além disso, a redução na performance é mínima pois elas podem ficar em cache.

Conclusão!

O resultado do experimento foi bem interessante. Se algum grupo não estiver preocupado se o pessoal estiver usando os players de forma errada poderia muito bem usar um script como esse para reduzir o tamanho dos vídeos.

Posso disponibilizar ele se alguém quiser. Não sei se os comentários do blog ainda estão funcionando, acho que a função que lida com ele estava marcada para parar de funcionar por causa de uma atualização no servidor e a única forma que resolver esse problema seria pagando, o que eu não vou fazer.

Se quiserem podem me enviar uma mensagem no Discord, no Twitter, os dois são igualmente bugados e não recebo notificações dos dois. Tenho conta no Signal e no Keybase, são criptografados, mas acho que ninguém usa nenhum dos dois, né? É complicado.

Eu tinha dito que daria um prêmio para quem adivinhasse qual era o objetivo do experimento e ninguém acertou, mas alguém tinha que ganhar um prêmio e esse foi o henmarcelino, que chutou que era a escolha de fontes. Não era bem a escolha das fontes, era uma forma de reduzir o tamanho delas. Os outros chutes disseram que a qualidade do vídeo era melhor, o que entendo pois a qualidade do vídeo da Aenianos é inferior pois usaram hardsub na tradução das músicas. Aparentemente o pessoal inconscientemente nota que a qualidade de quem usa hardsub é inferior.

Voltando ao assunto das fontes, acho estranho que o pessoal da Crunchyroll se recuse a usar as fontes que eles licenciaram. São 60 fontes (incluindo variações) mas parece que só querem ficar usando 15 dessas variações, desperdiçam 75% do que licenciaram! Há vários animes onde aparece texto monoespaçado e, ao invés de usarem Courier New, Andale Mono ou DejaVu LGC Sans Mono, eles usam Arial, que não é apropriada para essa situação. Embora seja um problema que eles só tenham licenciado uma única fonte cursiva, Comic Sans MS, por que desperdiçam tantas fontes por nada? É estranho, mas tenho boas notícias: não licenciaram Papyrus. Ainda bem!

Acho que há dois problemas lá, em primeiro lugar como muita gente que trabalha lá era de fansubs eles ainda têm a mentalidade de fansubbers e acham que adicionar muitas fontes é algo ruim, em segundo lugar há um grupo rebelde que não lê os memorandos e usa qualquer fonte que dá na telha. Aliás, para mim esse grupo rebelde não é um problema, é uma benção já que no último mês eu arrumei o meu player para carregar essas fontes.

Espero que o futuro seja melhor, tanto para fãs, quanto para profissionais e para quem está no meio dos dois grupos. Ainda que demore anos para o projeto sair e mais ainda para os players implementarem, acho que propostas como essa deveriam ser revistas e melhoradas por pessoas dos dois lados. Muito do que já foi proposto é ótimo, mas sempre há espaço para melhorias, como definir o estilo ao invés de definir o tipo do evento por linha e mover o tipo de evento para ser uma propriedade do estilo, o que seria mais conciso. Mas para que essas melhorias ocorram é necessário que haja participação de várias pessoas envolvidas com a produção de legendas.

Quinta vou publicar uma postagem sobre um anime muito bom que me recomendaram quando eu estava na faculdade e que é muito educativo. Até mais!

Atualizações

Descobri duas coisas após a publicação desta postagem:

1. A Crunchyroll está usando mais fontes, só não é muito comum. Em um episódio que vi faz algumas horas eles usaram oito fontes diferentes (excluindo variantes), inclusive Courier New. Espero que as equipes estejam sendo melhor informadas de quais fontes elas podem ou não usar.
2. Há algumas fansubs que usam fontes otimizadas, como a Commie, mas até agora não encontrei ninguém que tenha feito um script ou programa que automaticamente pega as fontes de uma legenda e otimiza as fontes conforme os caracteres usados. Além disso, mesmo no exemplo que encontrei da Commie, em Nagatoro-san, só otimizaram uma fonte de 4 MB para 46 KB, o que indica que devem ter feito isso manualmente. A automatização desse processo pode ser o que faltava para que isso se popularize.

¹ Se encontrar uma que só usa fontes com licenças open-source, deve ser minha.

O post Otimizando fontes apareceu primeiro em o canto do qgustavor.

Geralmente cantamos três hinos. Como já fazemos isso por vários anos devíamos cantar bem só que se fossemos nos classificar de acordo com a escala Charles Cornell nós estaríamos entre o nível 1, quando a gente tenta cantar junto, e o nível “0”, quando só uma pessoa da nossa família canta porque o resto desistiu de cantar.

Um dos motivos para não conseguirmos cantar juntos é que não cantamos sempre os mesmos hinos da harpa e, claro, não sabemos como cantar todos eles. Tentamos arrumar um ritmo mas quase nunca dá certo.

Essa é a parte do culto que mais me dá raiva do site. Várias vezes o tamanho da fonte fica errado no iOS: algumas vezes fica maior do que devia cortando parte da estrofe, em outras vezes fica pequeno demais para ler. Também os hinos tem vários erros de digitação e, ainda que o site tenha uma opção para editar os hinos e corrigir ninguém da família tem a menor vontade de usar ela!

Depois lemos um capítulo… ou versículo… da Bíblia, geralmente acompanhados por comentários genéricos e simples que nem sempre estão de acordo com o conteúdo. É complicado: se alguém tentar argumentar alguma coisa aí entramos em uma discussão e vou ter menos tempo para assistir meu anime depois do culto terminar.

Geralmente quando termina eu fico pensando como eu poderia melhorar o site para resolver os problemas que temos com ele. Por exemplo lemos um versículo aleatório pois esquecemos onde paramos na leitura da Bíblia. Era para estar registrado no histórico, mas como ele é armazenado no dispositivo um dia perdemos essa informação.

Eu poderia sincronizar isso com o Firebase, IPFS, GUN ou outro sistema desse tipo… ou melhor, não o GUN: qualquer projeto que tenha “machine-learning” e “blockchain” nas tags não parece ser algo confiável, parece algo tirado de um gerador de buzzwords. E, claro, já olhei o código: se a demonstração dele usa jQuery de forma insegura imagina como é a parte de criptografia dele? Deve ser terrível.

De qualquer forma eu nunca arrumo o adorai: a versão anterior do site usava jQuery, a atual usa React/Inferno (o que é irônico já que é um site que leitura da Bíblia) e já tentei usar Mithril e Vue mas nunca deu certo. Já estou cansado de tantas tentativas, então é melhor aguentar a versão que ainda funciona. No dia que ela quebrar eu resolvo esse problema.

O post Culto doméstico apareceu primeiro em o canto do qgustavor.

É, infelizmente, uma das piores versões de demonstração que já joguei pois não é possível concluir nenhuma meta nela. Eu queria que fosse que nem as versões de demonstração dos jogos da Ubisoft onde o jogo deixa claro que é uma demonstração, é possível terminar pelo menos uma fase do jogo e no final aparece um trailer para o jogo completo.

Eu conheci esse jogo quando criança em um daqueles CDs de pacotes de jogos. Acho que quem é novo acharia isso estranho, mas em uma época onde internet era extremamente cara esses CDs eram a principal fonte de jogos para mim. Sendo assim, como no CD não aparecia nada sobre esse jogo ser uma demonstração, eu fiquei muito tempo tentando ganhar ele e nunca conseguia, o que era muito ruim.

Na época que escrevi a postagem anterior eu tinha pensado "depois de tanto tempo, agora que já sei tanta coisa, eu devo conseguir achar uma forma de resolver esse problema" só para descobrir que não havia nenhuma solução.

Mas consegui pelo menos resolver um problema: descobri porque eu não estava conseguindo abrir as imagens do jogo.

Em primeiro lugar a forma que as imagens estavam armazenadas não era um formato tão simples como eu imaginei, aparentemente quem desenvolveu usou um XOR para evitar que alguém simplesmente convertesse os formatos e abrisse a imagem. Em segundo lugar não era RGB24 mas BGR24.

Essas são as duas imagens que são impossíveis de ser acessadas no jogo:

Imagino que elas existem porque era para o alçapão que fica na sala onde está o terminal do jogo ser aberto, porém não há nenhuma imagem dessa sala sem a grade que dá acesso para essa escada. Como pode ser visto no site do jogo esse projeto morreu, então só restaram essas duas imagens.

Esse jogo, de certa forma, foi uma inspiração para um jogo que eu desenvolvi, então eu sei que criar um jogo desses não é fácil. No meu caso o meu jogo não ficou tão bom, teve algumas salas que ficaram sem ser usadas no jogo final e coloquei poucas ilustrações pois se eu fosse ilustrar tudo o jogo nunca iria ficar pronto. É complicado fazer jogos.

O post Angra 2 apareceu primeiro em o canto do qgustavor.

O último experimento que eu fiz foi pegar o TweetNaCl.js e fazer uma versão dele que pode ser simplificada automaticamente dependendo das funções usadas: https://github.com/qgustavor/tweetnacl-js

Tive essa ideia pois eu estava desenvolvendo um projeto usando o Vite e notei que no código havia algumas funções do TweetNaCl que eu não estava usando, então resolvi reescrever parte do código que lida como as funções são exportadas e o resultado foi o código acima.

O interessante é que isso não só permite que as funções não usadas (pelo menos a maior parte delas) sejam eliminadas mas também permite que as funções sejam renomeadas, o que eu acho interessante já que.

Em termos de segurança não sei se isso é mais seguro ou não. Deve ser, mas não posso confirmar nada. É um experimento interessante, de qualquer forma.

O post Um experimento com criptografia apareceu primeiro em o canto do qgustavor.

Por outro lado uma coisa que nunca tinha parado para pensar é no uso automático de aspas, como na imagem acima onde as aspas fazem parte do modelo do site. O normal, nesse caso, seria que as aspas no texto citado fossem invertidas de duplas para simples e de simples para duplas, se estas existissem.

Nunca vi alguém comentar sobre esse assunto, talvez porque essa seja uma situação rara: talvez ficasse mais bonito se o nome do episódio ficasse escrito só em negrito, sem aspas. Por outro lado, considerando que alguém quer usar aspas no modelo de um site ou de um aplicativo, o que poderia ser feito? Fiz esse gist com uma possível implementação.

Espero que esse código sirva para alguém no futuro.

O post Aspas apareceu primeiro em o canto do qgustavor.

A maioria das respostas irá sugerir para usar o ffmpeg. Na maioria dos casos ele é realmente a melhor opção por ser simples de usar: "ffmpeg -ss tempo -i fonte.mp4 -vframes 1 destino.png", repetir isso a quantidade de vezes que for necessária e o problema está resolvido. Por outro lado esse método tem certos problemas:

• Você precisa de iniciar uma instância do ffmpeg para cada imagem, o que torna o processo muito lento, mesmo se você usar várias instâncias em paralelo;
• As legendas não aparecem nas capturas por padrão; você pode usar um filtro para isso, mas nem sempre é fácil já que é complicado configurar as fontes para funcionar com esse filtro;
• O ffmpeg não suporta certos MKVs (que são raros… exceto se você estiver trabalhando com animes);
• As capturas ficarão erradas para vídeos em que o aspect ratio mostrado (DAR) é diferente do codificado (SAR);
• Alguns vídeos podem ter problemas de compatibilidade (use “-x264_build 150” para esses casos).

Um método alternativo que eu achei bem mais interessante é usar o MPV para isso. Ele é mais complexo e consiste dos seguintes passos:

1. Abra o vídeo no MPV usando “–vo=null” para não abrir uma janela, “–audio=no” para não processar o áudio, “–pause” para pausar o vídeo (bem na lata, né?), e o argumento mais importante, “–input-ipc-server=/tmp/node-mpv.sock”;
2. Conecte ao MPV usando o IPC acima e aguarde pelo evento “playback-restart”;
3. Para cada imagem que você precisar tirar use o comando “seek [tempo] absolute+exact”, espere pelo evento “playback-restart” e então use o comando “screenshot-to-file [arquivo]”;
4. Por padrão as legendas aparecem nas capturas (o que é ótimo!). Se quiser desativar isso só adicionar “video” depois do nome do arquivo nesse último comando.

Assim como com o ffmpeg é possível usar várias instâncias em paralelo (geralmente uso uma para cada vídeo) e, apesar de toda a dificuldade envolvendo a comunicação via IPC, os resultados são surpreendentes: todos os problemas que listei acima são resolvidos e claro, é BEM mais rápido.

Só não me perguntem por que tenho tantas capturas no meu computador…

O post Capturas em massa apareceu primeiro em o canto do qgustavor.

Como no momento o Deno ainda está muito novo estou evitando ele para esse projeto e usando o Node, mas como boa parte desse clima de sair experimentando com esses módulos sem depender de Webpack, Parcel ou Rollup começou no Deno eu acabei levando uns sustos quando fui testar no Node.

Para começar eu não sabia que o import.meta.main era algo exclusivo do Deno. Achei que fosse algo "padrão", já que o Deno se valoriza tanto por isso. Acabei fazendo isso um desafio: escrever uma função que retorna se um módulo é o principal ou não:

export default function isMain (meta) {
  if (meta.main) return true
  if (typeof Deno !== 'undefined') return false
  if (typeof document !== 'undefined') {
    return Array.from(document.scripts).some(e => e.src === meta.url)
  }

  if (typeof process !== 'undefined') {
    const calledScript = process.argv[1]
    const normalize = e => e.split(/[/\]/).pop().toLowerCase().replace(/..*$/, '')
    return normalize(calledScript) === normalize(meta.url)
  }

  if (typeof WorkerGlobalScope !== 'undefined') {
    return self.location.href === meta.url
  }

  throw Error('could not find if module is main')
}

No Deno e em navegadores funciona bem mas no Node é uma gambiarra. Há um módulo no NPM que faz isso e, claro, deve fazer melhor. Espero que no futuro isso seja padronizado.

Um outro experimento que resolvi fazer foi pegar o MKV Extract e migrar ele de JavaScript para TypeScript, de CommonJS para ESM, e de Browserify para Parcel. Além disso agora ele usa GitHub Actions o que significa que não preciso ficar compilando no meu computador o site se alguém enviar um pull request corrigindo alguma coisa, é bem mais prático.

Quero terminar de arrumar esses scripts logo: as partes que dependem do MAL já estão dando problemas (mesmo com a API não oficial) e, como eu disse antes, em setembro a API que eu estava usando para gerar as estatísticas vai parar de funcionar. Na prática estou só organizando as coisas: ao invés de ter um monte de informação espalhada em uma planilha e um monte de arquivos JSON e TXT o meu plano é juntar tudo em um único ponto.

Assim que eu terminar vai ficar mais fácil gerar as estatísticas e ainda quero fazer um aplicativo para celular para poder votar nos animes sem precisar de internet. Claro, estamos na época onde todo mundo tem internet a qualquer momento, mas pelo menos nisso eu não sou todo mundo: minha internet é tão ruim que a conexão cai até dentro de casa!

Eu quero fazer um gráfico da nota de cada anime por episódio. É uma pena que só vou implementar isso depois de mais de cinco anos que comecei a coletar esses dados, mas antes tarde do que nunca. Enfim, isso é tudo por hoje, até semana que vem.

O post Experimentando com módulos apareceu primeiro em o canto do qgustavor.

No momento que escrevo a situação ainda está relativamente calma, mas acho que quando essa postagem for publicada vai ser a mesma complicação de sempre: é propaganda pra todo lado e todo mundo compartilhando e falando besteira por onde quer que vá, qualquer rede social, nem o shoutbox se salva!

Mas já que o motivo iniciador dessa postagem foram as bagunças com criptografia devo de falar algo importante, a minha opinião sobre eleições eletrônicas. Ela é simples, o Randall ilustrou ela muito bem:

Parece que o problema dos brasileiros que determinaram o uso de eleições eletrônicas é que ao invés de pensarem que nem a Megan eles pensam que nem a Ponytail: acreditam na propaganda que os problemas reportados podem ser corrigidos (e foram corrigidos) com soluções tais como blockchains.

Ou talvez as eleições são motivadas porque alguém está ganhando algo por trás dos panos. Há como saber? Não! Afinal, é eletrônico, dá para saber como funciona?

Volta e meia aparece alguém que é contra, depois aparecem outros dez que acreditam que blockchain são a solução (sem saber nada de blockchains) ou algo parecido e falam que tudo está certo, e nada muda.

Além da desinformação, tal como mostrada acima, outro problema comum é ignorar os avisos, por razões diversas. Claro que nos dois vídeos do Tom Scott sobre o assunto ele focou muito nos problemas dos EUA e alguns desses problemas não se aplicam aqui, mas isso não invalida os pontos dele.

Por exemplo: argumentos contra eleições via internet (o que ocorre no exterior) não valem aqui porque isso não ocorre aqui. Argumentos sobre votos deixando de ser considerados ou sendo adicionados, por outro lado, podem ocorrer, pois ainda que exista vários dispositivos criados para evitar essas situações, mas o que garante que esses dispositivos estejam funcionando adequadamente?

Nada impede que a urna dê uma de Volkswagen e funcione perfeitamente durante os testes realizados com ela, ou há um mecanismo mágico que permita isso? O que garante que o código testado ou o código entregue às equipes que testam é o mesmo que será usado no dia da eleição? Uma hash? Uma assinatura? E o que o que vai verificar isso? Outro mecanismo que funciona nos moldes da Volks?

Nada impede que ela mostre algo na tela e registre outra coisa internamente: mesmo se o total de votos contabilizados for o mesmo total de eleitores poderá ocorrer uma troca de votos. Talvez, se colocarem para imprimir algo, seja possível fazer alguma verificação, porém nada impede que o valor registrado seja o mesmo impresso e, nessa situação, o eleitor não pode fazer nada pois se for revelar o problema acabará revelando o próprio voto ajudando a comprometer mais a integridade da eleição.

Claro, neste ano as eleições vão ser eletrônicas, mas vamos ver se daqui dois anos deixaremos essa mania de usar modinhas como "blockchains" e urnas eletrônicas no passado. Vai que o resultados mudem. Se acontecer, provavelmente mudarão.

Enfim, pelo contexto das duas últimas postagens vocês já sabem que eu não confio muito nessas soluções supostamente mágicas e seguras, nem mesmo se forem (supostamente) open-source .

Até semana que vem!

O post Votação apareceu primeiro em o canto do qgustavor.

O Speck é uma cifra de bloco, ou seja, é uma função que toma uma chave e uma entrada e ela retorna uma versão criptografada desta entrada. Esse processo também pode ser invertido. O resultado é tal que, mantendo a chave, uma pequena diferença na entrada resulta em uma grande diferença no bloco, em oposição uma cifra de stream onde isso não ocorre.

Em geral os dois tipos de cifras usam vetores de inicialização para evitar problemas relativos a descobrir a entrada com base em comparações das saídas, porém em situações onde as entradas são menores que o tamanho dos blocos e a entradas nunca se repetem, as cifras de bloco permitem dispensar o uso desses vetores, o que permite uma redução na quantidade de dados transmitida.

Ele não é só uma cifra, mas uma família. Se for implementada corretamente ela suporta blocos de 32, 48, 64, 96 e 128 bit, com chaves variando entre 64 bits e 256 bits. Além disso é simples de implementar: a minha implementação dele tem apenas 81 linhas (incluindo linhas em branco, comentários e funções auxiliares) e suporta todas as variações dessa família de cifras. Uma implementação mais simplificada, implementando apenas uma cifra da família, pode ser implementada em 24 linhas de JavaScript.

Agora, qual é o problema do Speck? Por que eu não uso ele em situações que precisam de segurança? São vários problemas! O primeiro problema é desde que ela foi criada pela NSA e publicada em 2013, ainda que ninguém tenha publicado um ataque completo à cifra, a reputação da cifra é péssima! Ela não conseguiu ser padronizada pela ISO, foi removida do kernel do Linux e foi alvo de várias críticas.

O outro problema é fácil de ser notado: o tamanho dos blocos é pequeno demais. Isso facilita vários tipos de ataques. Um bloco de 32 bits, por exemplo, só permite 4.2 bilhões de entradas diferentes, o que parece muito, mas não é. Um bloco de 128 bit, que é tão comum que estou usando ele exatamente agora para acessar o meu editor, é 10^28 vezes mais seguro.

Mesmo assim eu gosto do Speck! A forma que ele trabalha permite que os blocos sejam de qualquer tamanho múltiplo de 2 bits, então posso usar um bloco de 12 bits se eu quiser. Além disso o tamanho da chave é limitado apenas pelo número de ciclos da operação, então posso usar chaves de 512 bits se eu quiser. Duvido que seja seguro, mas é uma melhoria enorme.

Se não estão entendendo, eis um exemplo prático:

• A lista de erros da Crunchyroll tem milhares de imagens cadastradas, cada uma é representada internamente por um número;
• Alguns erros não são publicados seja porque não era realmente um erro ou porque cadastrei antes do episódio estar disponível para não-assinantes[^1];
• Se eu publicasse o número interno das imagens seria possível descobrir facilmente quantos erros eu já cadastrei no total, incluindo os que não foram publicados;
• Usando o Speck posso manter estes erros ocultos transformando o número da imagem – algo como "123" – em um código como “RD5JM2”;
• Esse código é o número representado como um bloco de 30 bits, processado pelo Speck e codificado em Base32. Como cada caractere nesse formato representa 5 bits o código usa 6 caracteres. Como o tamanho máximo do bloco é 30 bits, posso cadastrar até um pouco mais de um bilhão de erros.

Imagino que não seja muito difícil inverter a operação e descobrir os números originais das imagens: tentar as 10^18 chaves possíveis, considerando que o Speck é absurdamente rápido, não deve demorar muito. Se fizermos um benchmark simples a minha implementação processa 7 milhões de chaves por segundo, uma mais otimizada deve processar cem vezes isso, alguém atacando a chave provavelmente usaria umas cinquenta máquinas em paralelo, assim a chave poderá ser quebrada em menos de um ano.

É isso o que tenho para hoje, até semana que vem!

[^1]: É um exercício adicional para o leitor entender o motivo real deste problema.

O post Speck apareceu primeiro em o canto do qgustavor.