Na criptografia e na comunidade de segurança há um termo emprestado da cultura popular norte-americana: "Snake Oil", o óleo de cobra. Ele é empregue para se referir a produtos mequetrefes, suspeitos, fradulentos ou que são pura falcatrua. Na wikipedia, há uma lista de exemplos de técnicas de falcatruas.
É que, frente às revelações feitas por Snowden, todo dia uma solução nova aparece para combater a vigilância em massa. Na pressa do mercado querer solucionar os problemas difíceis da comunicação segura, há péssimos programas sendo disseminados.
Nessa onda entra na lista das técnicas "snake oil": dizer que o código foi auditado (por quem? o que foi encontrado? o relatório final contém análise dos bugs privados?) e que ele é open source (tudo? ou só do lado do cliente? que protocolo está envolvido? o protocolo está sendo aplicado corretamente? é um protocolo conhecido ou é 'caseiro'? e o que está rodando no servidor? quantos colaboradores ativos? escrito em qual linguagem?).
É também a vez de dizer que o projeto é hospedado na Suíça. Problemas jurídicos resolvidos. Afinal a Suíça é o paraíso cypherpunk. E, claro, a vigilância em massa passou a respeitar fronteiras nacionais.
No geral, nota-se programas que se limitam a reinventar a roda, quer dizer, têm as mesmas ou mais vulnerabilidades e deficiências que as ferramentas já desenvolvidas e usadas há muitos anos, como email criptografado à la PGP. Porém, são implementados em javascript para serem usadas diretamente no navegador.
A discussão sobre a segurança dos navegadores merece um post à parte, uma vez que há posições nesse debate como "um computador com navegador web instalado está comprometido". Mas, de modo geral, o que importa dizer é que as ferramentas de criptografia que usam os navegadores web têm como base algo extremamente vulnerável. Gerar chaves criptográficas e gerenciá-las no navegador significa, então, um risco muito alto.
Segurança é gerenciamento de riscos, que, como sabemos, nunca são iguais a zero, mas sempre em níveis que definimos como aceitáveis. Sendo assim, vale a pena perguntar: no meu modelo de ameaça, há quantos passos (ou camadas) estaria um atacante de obter minha chave privada?