Cabaladadá

Repetidoras ativáveis ou sintonizáveis em Campinas

Rafael Beraldo — Thu, 16 Mar 2023

O excelente canal Caçador de Repetidoras do Ricardo PY2QB traz uma longa lista de repetidoras em 2m e 70cm com as quais o radioamador conseguiu estabelecer contato, inclusive algumas bastante longe de São Paulo, SP, onde está localizada a sua estação.

Baseado naquele trabalho, apresento uma pequena lista de repetidoras ativáveis ou que consegui captar a partir da minha estação em Barão Geraldo, Campinas, SP. Atualmente, estou usando um Retevis RT3S rodando OpenGD77 e uma antena flowerpot montada no telhado de casa. Consigo estabelecer contatos a cerca de 120km com esse equipamento.

Clique aqui para baixar o arquivo .ods com a relação das repetidoras que consigo ouvir pela região. Outros formatos disponíveis:

O radioamadorismo é sustentável no Brasil?

Rafael Beraldo — Sun, 15 Jan 2023

Numa trilha pelo Espinhaço no carnaval de 2022, me dei conta de que um rádio teria feito toda a diferença. Estávamos em um grupo com cerca de quinze pessoas e houve momentos de algum estresse por não podemos nos comunicar facilmente. Foi assim que resolvi tirar a licença de radioamador no ano passado, comprei meu primeiro rádio (um Baofeng UV-5R) e tenho estudado e aprendido cada vez mais sobre a prática. Aliás, o meu indicativo é PU2URT (de Urutu Branco – leitores do Guimarães Rosa entenderão); me encontrem no QRZ.com!

Como atualmente moro em Campinas, tenho acompanhado as conversas nas repetidoras locais, como as Chapéu de Couro (146.910 MHz) e de Palha (439.900 MHz), em Amparo, as repetidoras do Clube de Radioamadores de Americana (CRAM; 146.770 MHz) e as raras conversas que escuto na repetidora do Capricórnio (146.810 MHz), localizada na Serra das Cabras, próximo do Observatório Municipal Jean Nicolini. Aliás, fiz um compilado das frequências que costumo ouvir para uso no CHIRP para quem estiver interessado em configurar seu rádio para ouvir e transmitir nas repetidoras da região. Baixe aqui.

Uma das coisas que mais tem me chamado a atenção no radioamadorismo é a (aparente, pelo menos) falta de pessoas jovens ou novatos. Quer dizer, a prática me parece dominada por pessoas mais experientes, que aprenderam o rádio há algumas décadas e novos radioamadores não parecem estar entrando no hobby. Minhas elucubrações me levaram a crer que a facilidade de comunicação via Internet, juntamente com a presença universal dos celulares, foram um tipo de tiro de misericórdia no radioamadorismo. Isso explicaria a falta de tráfego nas repetidoras e no simplex, ou seja, comunicação ponto-a-ponto entre dois rádios.

Mas, será mesmo que esse é o caso? Que métricas podemos consultar para obter uma imagem do radioamadorismo no Brasil? Neste post, vou tentar obter alguns dados no site da Anatel para caracterizar quem e quantos são, onde vivem e qual a idade dos radioamadores.

Uma hipótese e algumas perguntas

A minha hipótese sobre o estado do radioamadorismo no Brasil foi exposta acima: minha breve experiência parece indicar que há poucos novos radioamadores, de modo que essa poderia ser uma prática que está fadada a deixar de existir no Brasil. Rádios são equipamentos caros e as repetidoras usadas no VHF (faixa dos 2m) e no UHF (faixa dos 70cm), que me parecem ser as mais acessíveis para os novatos, exigem constante manutenção e alguém ou uma associação que pague a conta. Com menos radioamadores na cena, como essa infraestrutura iria se manter?

Assim, queria responder pelo menos as seguintes perguntas:

Qual a idade dos radioamadores no Brasil?
Quantos radioamadores há no país?
Onde eles estão localizados?
Qual a tendência para a taxa de novos licenciamentos?

Nem todas elas puderam ser respondidas satisfatoriamente. Além disso, de acordo com os dados limitados que consegui levantar, parece que eu estava errado em supor que há poucos novos radioamadores. Vamos aos números.

Dados oficiais da Anatel

O primeiro lugar onde podemos obter e visualizar dados é no próprio site da Anatel, em Painéis de Dados → Outorga e Licenciamento → Estações Licenciadas. Lá é possível filtrar a exibição apenas para as estações licenciadas de radioamador, o que nos dá um número total de 42.516 licenças. Para fins de comparação, há cerca de dez mil estações de rádio no Brasil segundo o Ministério das Comunicações.

Façamos algumas contas de padaria colocar esse número em perspectiva. A proporção da população que tem licença para operar estações de radioamador é de aproximadamente 0,02% (segundo o IBGE, estávamos estimados em 213,3 milhões em 2021). Isso significa que uma a cada 5.000 pessoas está outorgada. Nos Estados Unidos, um país com dimensões e população relativamente comparáveis, a quantidade de radioamadores é dez vezes maior: há quase 800.000 licenciados, ou cerca de 0,233% da população.

Mas como os radioamadores nos distribuímos pelo território nacional? O mapa abaixo, extraído do site da Anatel, indica que há uma concentração de radioamadores no Sudeste, no Sul e em estados do Nordeste (cores escuras indicam maior densidade):

Em valores numéricos:

Estado	Estações
São Paulo	10.800
Rio de Janeiro	4.685
Minas Gerais	3.506
Paraná	3.299
Rio Grande do Sul	3.239
Santa Catarina	2.748
Ceará	2.107
Paraíba	1.875
Rio Grande do Norte	1.553
Pernambuco	1.244
Distrito Federal	1.189
Bahia	1.168
Goiânia	699
Piauí	622
Mato Grosso do Sul	607
Espírito Santo	587
Pará	462
Sergipe	370
Alagoas	366
Maranhão	296
Mato Grosso	275
Amazonas	237
Rondônia	229
Amapá	126
Roraima	105
Tocantins	66
Acre	58

Até o momento, conseguimos obter os dados para duas perguntas: a quantidade e localização dos radioamadores. Entretanto, o site da Anatel não traz dados pessoais, em especial a idade dos operadores. Para isso, teremos que usar um proxy, ou seja, algum outro dado que possa estar correlacionado com a idade dos radioamadores.

Qual a idade dos radioamadores?

Essa pergunta se provou impossível de responder – a não ser que pesquisássemos os 42.000 radioamadores, um a um. Apesar disso, talvez seja possível estimar a idade dos radioamadores a partir da obtenção do primeiro registro de estação para cada indicativo. A hipótese é que, em havendo uma concentração de registros em anos passados e menos em anos recentes, há de se esperar que a idade dos radioamadores siga essa tendência.

A página de consulta de indicativos da Anatel nos permite inserir um indicativo e obter dados como a localização das estações a ele associadas, a data de validade da licença de cada estação, o nome do autorizado, a sua classe de radioamador e, crucialmente, a data de primeiro registro das estações. Por exemplo, a minha data de inclusão é 15/07/2022 e a data de validade é 23/06/2042. Estou presumindo, aqui, que ao renovar o indicativo, a data original de inclusão da primeira estação será mantida.

O problema é que essa informação deve ser obtida de maneira manual, ou seja, nós teríamos que digitar os indicativos um a um. Felizmente, foi possível confeccionar uma série de comandos no terminal do Linux para automatizar a tarefa. De maneira bastante resumida, primeiro a lista de indicativos foi obtida no site da Anatel. Então, um robô baixou a página correspondente a cada indicativo. Finalmente, foi possível extrair o ano mais antigo de cada página, produzindo-se assim os dados que discutiremos a seguir. A metodologia completa está anexada após a conclusão deste pequeno artigo.

Primeiros registros de cada indicativo

O gráfico abaixo (clique aqui para uma versão maior) apresenta o número de primeiros registros de estação por ano, desde 1987. Podemos ver que o maior número de registros, ao contrário do que minha hipótese supunha, não se concentra nos anos iniciais; na realidade, observamos exatamente o contrário! Parece que há uma distribuição relativamente uniforme dos registros, então não é possível dizer que há uma tendência de desaparecimento nos registros de novos radioamadores.

Gostaria de especular sobre algumas tendências curiosas:

O primeiro registro é de 1987, ano em que há apenas uma estação registrada. Presumivelmente, havia radioamadores desde muito antes disso; é possível que o sistema informatizado tenha sido implementado no fim dos anos 80.
Suponho que o registro informatizado foi um processo gradual e que os radioamadores paulatinamente atualizaram seu cadastro para o meio digital. A data final para essa atualização de dados me parece ter sido 1998, quando o número de registros explode, tendência que não se verifica nos anos consecutivos.
Uma outra possibilidade é que a promulgação da Constituição Cidadã de 1988 e o fim da ditadura militar no Brasil estejam relacionados ao início dos registros identificados aqui (obrigado, Igor Costa, por esse apontamento histórico!).
No começo dos anos 2010 e até 2019, a média de novos registros por ano fica em quase 2.000 novos registros por ano. Essa tendência acaba justamente em 2020, o ano da pandemia. É possível que o interesse pelo radioamadorismo tenha crescido em meados de 2010, seja por mudanças na legislação ou por mais fácil acesso ao equipamento ou informação.
Não podemos concluir, entretanto, que há uma falta de interesse após 2019; é possível que a pandemia tenha impactado negativamente o processo para a obtenção de novas licenças. De fato, o sistema de provas online para obtenção do Certificado de Operador de Estação de Radioamador (COER), que ainda perdura, foi implementado apenas como resposta à pandemia.

O radioamadorismo tem futuro no Brasil?

Ainda me é um pouco estranho que pareça haver pessoas mais experientes do que novatos no ar. Apesar disso, se a minha metodologia e os dados levantados estiverem corretos, então somos obrigados a concluir que, embora não haja um número muito grande de radioamadores no Brasil proporcionalmente à população, o interesse pela licença parece ter se mantido constante.

Embora o Sudeste, Sul e alguns estados do Nordeste concentrem o maior número de radioamadores, me parece que há poucos justamente em estados menos densamente populados, onde o serviço fornecido pelo radioamador em situações de emergência, ou como ponte de contato com o mundo, poderia ser ainda mais valioso. Presumivelmente, deve haver também menos estrutura, como torres repetidoras, nesses locais. É claro que isso pode ser mitigado pelo uso de frequências, como os 11m ou 20m, cujas propriedades naturais podem propagá-las até mesmo para outros locais do mundo. Entretanto, essas bandas são menos amigáveis para o iniciante tanto do ponto de vista do custo, quanto da facilidade de operação: é muito comum que se comece, como eu mesmo estou começando, por exemplo com o uso de HTs (hand talks, ou rádios móveis).

O estudo estatístico do professor Ricardo da Silva Benedito PY2QB (UFABC) aborda essa questão com uma métrica interessante: o número de estações de radioamador por 100 mil habitantes é relativamente maior em uma série de estados menos populosos. O estudo especula que isso pode indicar que há uma cultura de radioamadorismo mais bem difundida nessas regiões, o que pode estar relacionado ao fato levantado acima de que esses estados são menos densamente populados. Vale a pena ler o material, que vai muito além desta pequena análise que realizei, incidindo inclusive sobre a importante questão da proporção desigual de homens (93%) e mulheres (apenas 7%) no hobby.

Uma pergunta que me faço desde que iniciei o processo para tirar minha licença e que me fiz mais agudamente durante essa breve pesquisa foi sobre como poderíamos popularizar mais a atividade do radioamadorismo. Quais são as barreiras de entrada? Me parece que

a falta de acesso à informação
o processo burocrático envolvido no licenciamento
o custo dos equipamentos e
a universalidade do celular e da Internet nas cidades

são fatores que poderiam explicar a baixa adesão ao hobby de radioamador. Por exemplo, conheci pessoas em grupos de trilha que têm rádios móveis como meu Baofeng, mas restringem seu uso à trilha e à comunicação simplex. Não conhecem as associações de radioamadores, ou diferentes bandas e suas características de uso, nem mesmo como programar o rádio para ativação de uma repetidora, que poderia ser útil em certos locais bastante frequentados pelos trilheiros. Esse seria um dos públicos ideais para se atrair ao radioamadorismo: pessoas motivadas a aprender e que teriam uma aplicação prática dos conhecimentos e normas desse serviço.

Hoje mesmo estava escutando a uma transmissão no YouTube do radioamador Alexandre PU2YPO, em QSO – ou seja, uma conversa – com um senhor de Três Corações, MG. Esse senhor, Zé Mauro Braz PY4JMB, é deficiente visual e uma de suas formas de comunicação com o mundo é justamente o rádio, que o permite conhecer pessoas de longe e prestar informações quando chamado. Essa anedota representa bem a comunidade dos radioamadores: pessoas abertas, comunicativas e com vontade de se conectar umas com as outras para compartilhar interesses em comum. Se uma classe tão pequena quanto a dos radioamadores consegue manter uma infraestrutura não só física, mas também comunitária, não seriam eles capazes de expandir ainda mais essa atividade para novas pessoas que, apesar de não a conhecerem, ficariam fascinadas com sua riqueza e possibilidades?

Obrigado pela leitura! Ficou curioso para se tornar um radioamador? Fique de olho nesse blog, porque estou preparando um material para introduzir o radioamadorismo aos trilheiros.

Anexo: obtendo os dados de todos os indicativos

Para estimar a idade dos radioamadores no Brasil, decidi encontrar os anos de primeiro registro das estações no site de consulta de indicativos da Anatel. Seria impossível pesquisar os mais de quarenta mil indicativos manualmente, portanto encontrei uma maneira programática de compilar essa informação.

Primeiramente, obtive a lista de todos os indicativos existentes baixando o arquivo ZIP disponibilizado no site de informações e dados abertos da Anatel, clicando no botão de dados abertos. Uma cópia desse arquivo está disponível aqui. Abri o CSV no meu editor de planilhas e filtrei tudo aquilo que não fosse estação de radioamador; depois disso, deletei as colunas espúrias, mantendo apenas a coluna com os indicativos. Finalmente, removi os indicativos que por algum motivo estavam repetidos, obtendo o número exato de 42.516 indicativos. Bingo!

De posse dessa informação, com algum custo e usando do método do erro e acerto, confeccionei um script em Bash para baixar os dados de cada um dos indicativos nessa longa lista:

 #!/bin/bash
 #
 # Baixa, de maneira paralelizada, informações referentes a indicativos
 # no site da Anatel.

 # Criar 50 instâncias paralelas do curl.
 N=50
 (
     for ind in $(cat indicativos-uniq-2023-01-15.txt) ; do
         ((i=i%N)); ((i++==0)) && wait
         echo "Baixando indicativo $ind"
         # Baixar a página do indicativo $ind
         curl -X POST \
              -H "Content-Type=x-www-form-urlencoded" \
              # Preencher o campo do formulário de busca com o indicativo.
              -d "pIndicativo=$ind" \
                  https://sistemas.anatel.gov.br/easp/Novo/ConsultaIndicativo/Tela.asp?acao=e \
                  -o $ind.html 2> /dev/null &
     done
 )

O processo demorou várias horas, porque houve situações em que o processo do curl falhou em baixar a página, provavelmente algum erro no servidor da Anatel; tive que reiniciar o processo algumas vezes, excluindo manualmente os indicativos já baixados.

Em seguida, notei que alguns indicativos eram especiais, ou seja, concedidos pela Anatel para uso em eventos específicos. Esse é o caso, por exemplo, de ZZ5FLORIPA. Encontrei-os com o seguinte código

 grep "9 - Especial" *.html -o | cut -d : -f 1

e excluí todas as páginas referentes a esses indicativos especiais. Ao cabo, sobraram 42.202 indicativos regulares. Agora, só restava obter o ano do primeiro registro de cada um:

 #!/bin/bash

 # Criar o arquivo CSV
 echo "ano" > anos.csv

 for indicativo in $(ls *.html) ; do
   # Encontrar as datas no arquivo
   grep -E [0-9]{2}/[0-9]{2}/[0-9]{4} -o "$indicativo" |
   # Pular a primeira data (comentário no HTML)
   tail +2 |
   # Cortar apenas os anos e ordená-los
   cut -d / -f 3 | sort |
   # Retornar primeira linha (ano mais antigo)
   sed -n 1p >> anos.csv ;
 done

Como havia uma data usada em documentação em um comentário no HTML da página, foi necessário pular essa primeira data; só depois é que o script isola os anos, os ordena, de modo que o mais antigo esteja na primeira linha e retorna exatamente essa linha. Assim, se o meu código estiver todo correto, obtivemos então os anos de primeiro registro de estação para cada indicativo na base de dados da Anatel.

O arquivo com os anos foi então alimentado no seguinte script em R

 require(ggplot2)

 dados <- read.csv("anos.csv")
 contagem <- as.data.frame(table(dados$ano))

 ggplot(contagem, aes(x=Var1, y=Freq)) +
     geom_bar(stat="identity") +
     geom_text(aes(label=Freq), vjust=-1) +
     labs(title="Número de primeiros registros de estação por indicativo",
          x="Ano",
          y="Primeiros registros") +
     theme_minimal() +
     theme(panel.background = element_blank(),
           panel.grid.major.x = element_blank())

que gerou o gráfico apresentado mais acima.

Tá na Ponta da Língua: como a Psicolinguística explica seu esquecimento

Rafael Beraldo — Sun, 10 Dec 2017

Este texto foi escrito como trabalho de divulgação científica para a matéria de Psicolinguística da pós-graduação em Linguística no Instituto de Estudos da Linguagem (IEL), Unicamp, para o professor Thiago Oliveira da Motta Sampaio.

Deve ter sido há algumas terças-feiras, voltando do supermercado à pé, passei por algo que fez minha espinha gelar. Ouvi alguém chamar, “Rafael!”, e quando vi quem era, tratava-se do corretor de imóveis que havia me mostrado alguns apartamentos três ou quatro meses atrás. Imediatamente me lembrei de quem era, bem como podia lembrar dos locais que havíamos visitado e alguns comentários que havia feito sobre sua vida, como por exemplo que sua filha havia acabado de fazer aniversário. A ansiedade veio, como muitos podem entender, porque com frequência me esqueço do nome de pessoas que não vejo há algum tempo. Felizmente não tive de pensar muito, pois somos xarás! Evitado o desastre de uma situação desconfortável, segui meu caminho um pouco mais leve.

O fenômeno de conhecer um conceito, porém não se lembrar da palavra, não é incomum, muito menos exclusivo dos nomes próprios. Evidência disso é a existência do verbo coisar, companheiro magnificamente útil nas situações de esquecimento. A ocorrência é definitivamente menos desagradável do que esquecer o nome de um colega que encontramos inesperadamente, porém não menos frustrante quando se intromete numa conversa. A palavra resiste e esquiva qualquer tentativa de ser recuperada, muito embora esteja “na ponta da língua”. Recorremos ao amigo com quem conversamos, nos esforçamos para explicar o seu significado, dizemos qual era a primeira letra e até mesmo recorremos à Internet, muitas vezes interrompendo a conversa. Quando finalmente nos lembramos, o alívio é geral. Mas por que isso acontece?

Conhecido por psicólogos e linguistas por “tip of the tongue” (TOT), ou “ponta da língua” (PDL) em português, esse fenômeno tem sido sistematicamente estudado pelo menos desde 1966, quando Brown e McNeill realizaram um experimento para angariar dados iniciais sobre a PDL. Desde então, um grande número de pesquisadores tem se debruçado sobre o problema. Para entender algumas das descobertas e explicações que tem sido propostas, convém entender como a Linguística e a Psicologia dialogam.

Se por um lado a Linguística estuda a estrutura das línguas, o que as torna possíveis e como se dá seu uso, a Psicologia trata das capacidades cognitivas humanas. Na interseção entre as duas ciências está a Psicolinguística, que busca entender como processamos e produzimos palavras e sentenças, de maneira a construir modelos que agreguem conhecimentos de ambas as áreas.

Uma das maneiras mais poderosas de averiguar como um sistema funciona é observar os casos nos quais ele quebra. Essa abordagem tem sido lugar comum na Psicologia. Veja, por exemplo, a história de Phineas Gage, trabalhador ferroviário estadunidense do século XIX que sobreviveu a um acidente que lhe custou seu lóbulo frontal esquerdo, bem como produziu notáveis mudanças em sua personalidade. As consequências de seu dano cerebral permitiram avançar a discussão sobre a hipótese da localização de funções no cérebro. O mesmo princípio se aplica na Psicolinguística: com frequência, pesquisadores projetam experimentos usando fenômenos conhecidos sobre o funcionamento do cérebro e da língua para induzir participantes ao erro, confundi-los com sentidos ambíguos, ou pedir que resolvam tarefas deliberadamente difíceis, tudo em nome de entender melhor a relação entre língua e cérebro.

Essas práticas experimentais têm aberto espaço para que modelos psicolinguísticos possam ser propostos, refutados ou refinados. Para entendermos, por exemplo, como se dá o acesso lexical, devemos ter uma boa ideia sobre como o léxico mental — o “dicionário mental” que codifica palavras, suas representações fonológicas e sentidos — se organiza. Essa investigação pode se dar de várias maneiras. Uma delas explora um fenômeno cognitivo conhecido como priming.

Ao ler ou ouvir, os seres humanos levam um determinado tempo para recuperar a palavra em questão, uma vez que o estímulo deve ser transformado em fonemas — as unidades fundamentais de som que compõe uma determinada palavra — e esse encadeamento de fonemas deve ser comparado com o léxico que conhecemos, o que então nos levará ao seu significado. Em experimentos conhecidos como decisão lexical, nos quais os participantes leem ou ouvem uma palavra e devem decidir se ela pertence ou não à sua língua, pesquisadores verificaram que palavras mais frequentes, como casa, são processadas mais rapidamente. Essa facilidade indica a existência de algum tipo de mecanismo de reforço dos caminhos mentais percorridos mais frequentemente. Como é de se esperar, palavras menos frequentes, como sexteto, são recuperadas mais lentamente. Por outro lado, quando um falante de português vê ou ouve uma palavra em checo, o tempo de processamento é o menor de todos, indicando que em um instante o cérebro comparou os sons recebidos com o léxico mental e descartou a possibilidade de ser alguma palavra conhecida, nem se dando ao trabalho de tentar recuperar seu sentido.

É possível, no entanto, diminuir esse tempo de processamento ao apresentar uma palavra relacionada, conhecida como prime, antes da palavra-alvo. Assim, é constado que, ao ouvir guitarra, o participante apresentará um tempo de ativação consideravelmente menor para piano. Isso indica que, no léxico mental, palavras semanticamente relacionadas estão conectadas. Esse fenômeno não se limita, entretanto, ao sentido: o mesmo efeito se verifica para formas (c4s4 e casa) e sons (chá e pá).

Se a compreensão é realizada em estágios, o mesmo acontece na tarefa da produção de palavras. O processo começa com uma representação mental do conceito do que se quer dizer. Um lema, a representação mental da palavra que contém as informações gramaticais e de sentido, é então selecionado. Após isso, o conjunto ordenado de sons associado ao lema é recuperado e os sinais correspondentes são enviados ao aparelho da fala. É notável que a conexão entre uma palavra e o seu sentido raramente é enfraquecida; no entanto, com alguma frequência, falhamos em recuperar sua fonologia, causando o estado da PDL. De acordo com o modelo do déficit de transmissão, uma vez que a força entre uma palavra e sua representação fonológica pode variar, três fatores explicam a ocorrência da PDL: 1) a frequência da palavra — palavras de baixa frequência são mais afetadas, 2) o uso não recente e 3) a idade do falante. Por outro lado, apresentar a primeira sílaba da palavra que se busca tem o mesmo efeito de priming discutido acima, ajudando em sua recuperação. Tente se lembrar disso da próxima vez que você for pego com a sensação de que uma palavra está “na ponta da língua”.

Life update: the last six months

Rafael Beraldo — Tue, 28 Jun 2016

Uneventful, ordinary days should be either feared or celebrated. Every major change in my life seems to have happened on such days. And this year it was no different. It must have been a very lazy Sunday afternoon when I got a message from Débora Garcia a friend I hadn’t spoken to in a long time. We met because we were both doing research on computational linguistics back in 2011, under the supervision of Bento Silva.

I was caught off guard by what she had said: something to the effect that LaTeX was indeed a great way of producing documents and I’d been right all along. She had just started writing her PhD thesis, if memory serves me right. Having just graduated from Unesp, I hadn’t used LaTeX in a few months, and I had totally forgotten about the time I was advocating its use.

A few weeks later we were having coffee and catching up on each other’s news. It was a very stimulating day that rekindled our mutual interested in life and its possibilities. Through her, I learned that my hometown of São Carlos was teeming with smart computer science people working on amazing projects.

When I got home in Araraquara that night, I went straight to my computer and searched for like-minded people in São Carlos. It didn’t take me more than a couple of minutes to find OpenSanca, a local free software and entrepreneurship meetup group. They offer free workshops and talks about everything technology. I immediately went nuts with excitement. This was the group I’d been dying to find for years, right there, only 40 minutes away by car.

I joined their Slack channel right away and introduced myself. I said I was a linguist with a passion for Linux, technology and programming and mentioned being a LaTeX user. Right off the bat I was invited to do a workshop on the subject. I’ll talk more about that experience in a later post.

Very soon, I went back to São Carlos for a OpenSanca-promoted AngularJS workshop with Carlos Gomes, who would later become a friend. The event was great, jam-packed with information about clean code, Angular and mocking concepts. I learned a lot that day and I can’t thank Carlos or the OpenSanca staff enough for putting together such incredible events.

Since then, I’ve been able to go to a number of talks and workshops. Among so many other things, I learned what a JavaScript framework really is, how to program Arduinos and how 3D printing is going to change everything. I’m more excited than never and the many inspiring people I met over the last three months made me come to a few realizations and thoughts:

OpenSanca is a group that promotes technical education free of charge. It is exactly what I had been dreaming of since my first education class at college. It is living proof that we all have something to teach and something to learn, and that empowering our community is not only feasible, but incredibly important. I must write a post on this point later this year. Also, I’d like to sincerely thank all of OpenSanca’s staff, specially Cristofer Sousa, who I’ve had the chance to work with more closely.
Fuck the Silicon Valley. I’m not trying to be offensive here, but we have to face the truth. For a while I dreamed of working and doing great things abroad. I still think that would be great, however Laure Stelmastchuk, one of the greatest people I met through OpenSanca, made me realize I was failing to look around and see the opportunity that is all around us. We’re not living in the US or Europe. It would be impossible to emulate their market and infrastructure, so we’ll have to make do with what we have at hand instead. In other words, innovating has a different meaning in Brazil: it means achieving higher grounds in ways that make sense for us. I’ll try to develop this further in another post, as it’s only the germ of an idea.
Finally, this last idea connects with my most important realization. We are seeing the onset of a community that I hope grows to the point of no return, forever changing the city of São Carlos. May this sense of community that free software nurtures spread to other cities all over the country and to other areas of our lives too.

When I started this post, my initial intention was to report how my two LaTeX workshops went and where I failed. It grew to become a rather different beast. However, it’s given me a few ideas to chew on. I’ll try to develop the next three topics in future posts:

My two LaTeX workshops: where I failed and where I didn’t
The importance of informal education groups
How doing our own thing may be better than trying to copy Silicon Valley

Stay tuned for more!

Security Now #510 Digest

Rafael Beraldo — Thu, 04 Jun 2015

Hello again and welcome to my little Security Now digest. I’m going to try and assemble a short, actionable digest to help you get the most out of Steve and Leo’s tips.

Security Now #510 can be found at twit.tv. The show notes are over at grc.com. Here are the most important security news for this week:

iOS’s iMessage has a “UTF-8 encryption/encoding/viewing error” (as worded by user johnkphotos on Reddit). The bug can be triggered by sending a specially crafted message and will turn of the victim’s device. iPhone users up to iPhone 4 are the only not affected since the bug was introduced after iOS v7.1.2. Apple will probably fix this soon, so keep your phones up to date!
Since we started talking Apple, let’s continue on topic. A bug has been found in the Mac UEFI that allows the firmware to be rewritten. Usually, the UEFI is protected against this kind of attack, but there was a bug in the firmware that allows an attacker to overwrite the bios after a suspend-resume cycle. Newer Macs are not affected, but older Macs still don’t have a fix. For now, you can avoid performing suspends or buy a new computer =/

And that’s it! In other noteworthy news, your Windows 7 or 8 installation might be bugging you with a suspicious looking traybar notification about Windows 10. That’s not a virus, only Microsoft trying to push the newest, yet-to-be-released Windows version. If that annoys you, read this article on iDigitalTimes on how to remove the icon.

Now on to fun stuff:

Project Vault is a Google ATAP project to deliver a Hardware Security Module that can encrypt and decrypt streams of data.
Project Soli is a Google ATAP radar that Steve and Leo agree has to potential to completely change the way we interact with our devices. As Project Vault, Soli was introduced during the latest Google I/O, held on May 28 and 29.

A thus ends our digest. What did you think about it? Please send your comments, questions and suggestions to rberaldo at cabaladada dot org. I’ll be happy to hear from you.

See you next week!

Security Now #509 Digest

Rafael Beraldo — Thu, 28 May 2015

Introduction to the Security Now Digests

I’m a big fan of TWIT’s Security Now. Since the demise of my favorite show, Linux Outlaws, Security Now has had the highest priority on my playlist. Computer security has always been one of my favorite areas of interest, and Leo and Steve do a great job of summing up the big stories of the week, as well as breaking down complex concepts so they’re much easier to understand.

As with all podcasts I subscribe to, I usually listen to Security Now while doing the dishes, driving or doing something else that doesn’t require any intellectual effort. Furthermore, it often takes me a couple of days to get through each episode, since I don’t have a long commute every day. As a result, I can never act on the security breaches immediately. Committing them to memory doesn’t work either, and for the most part all the plans that I make while listening to the shows are never put into practice.

Since Snowden blew the metaphorical whistle there’s been a great spike in interest in security from the general public. So I thought I’d put together a short weekly digest with actionable information that I’m hoping may be useful for me and for other people who are interested in souping up their security.

Why wait any longer? Let’s hit the news!

Security Now #509 Digest

SN #509 can be found at twit.tv. The show notes are over at grc.com. Here are the most important security news for this week:

This week’s big story was Logjam, the latest in cleverly named security breaches. Without getting into too much detail, Logjam is a man-in-the-middle attack against TLS that allows the attacker to lower the strength of the ciphersuite used on a given web session. That allows the attacker to easily break the encryption and have access to the communication going between the client and the server. If you are a systems administrator, you should update your TLS implementation and configure services such as Apache or OpenSSH not to use the weak chipersuites. Regular users, on the other hand, should upgrade their browsers. See more info on weakdh.org.
A new security flaw that affects routers has been discovered. There is a NetUSB bug that affects most routers with a USB port. Such routers allow the users to remotely access any devices connected to the USB port. Unfortunately, the NetUSB driver is subject to a buffer overflow. In some cases, the flaw can be exploited remotely, since the router exposes the service to the WAN port. Solution: buy a new router, or use a custom firmware such as OpenWRT or Tomato. To check if your router is vulnerable, use Steve’s SHIELDS UP!: grc.com/x/portprobe=20005.
PKES (Passive Keyless Entry & Start, or The Stuff That Lets You Into Your Car Just By Having It On You) is Hopelessly Broken. Keep yours at a Faraday Cage! (I’m so happy my car is older, simpler and safer.)

Moving on to the fun stuff:

ScriptBlock is a (new?) Chromium/Chrome plugin that, well, blocks scripts! It works similarly to Firefox’s NoScript, allowing the user to control which scripts can run and which can’t.
Steve read the Let’s Encrypt subscriber agreement and it’s looking good! I’m looking forward to using TLS on Cabaladadá, and Let’s Encrypt is sure to be my CA of choice.

That’s all for this first digest, guys! Happy hacking!

Criptografia no Linux: Importância

Rafael Beraldo — Sun, 08 Dec 2013

Este é o décimo post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

Enquanto esta série estava sendo escrita, a partir de junho de 2013 Edward Snowden começou a vazar documentos ultrassecretos da Agência Nacional de Segurança [National Security Agency — NSA] dos Estados Unidos, demonstrando que a agência era capaz de vigilar a Internet em uma escala massiva com o sistema de vigilância PRISM e usando a interface XKeyscore nos dados que acumulara. A notícia de que a vigilância governamental secreta era possível e estava acontecendo não foi particularmente surpreendente para engenheiros de rede e teóricos da conspiração, mas as revelações finalmente deram ao público geral e não técnico uma ideia do quão seriamente os sistemas proprietários sobre os quais eles haviam construído grande parte de suas vidas digitais pode ser usado para prejudicá-los e comprometer sua privacidade.

Nos Estados Unidos, pessoas preocupadas são bastante conscientes de como o abuso secreto do poder de exercer essa vigilância e as fracassadas moções do Congresso dos Estados Unidos para cerceá-lo abalaram a confiança em seu próprio governo. No entanto, as implicações dos vazamentos são também internacionais. No meu próprio país, a Nova Zelândia, a agência de inteligência internacional, o Escritório Governamental de Segurança nas Comunicações (GCSB), foi no início do ano acusado de espionar ilegalmente cidadãos neozelandeses, e as mensagens diplomáticas da WikiLeaks mostram que a GCSB potencialmente já está colaborando com a NSA. Mesmo assim, novas leis estão definidas para extender os poderes da GCSB, apesar de análises independentes condenarem o projeto de lei tanto de uma perspectiva legal quanto do ponto de vista dos direitos humanos, mesmo após as ementas. O escândalo e a ira sobre o abuso da vigilância se estende ao Reino Unido, Alemanha, Suécia e muitos outros países.

Realmente continuo com esperanças em esforços como a ação coletiva da Electronic Frontier Foundation para reduzir a vigilância ou, no mínimo, registrar a ira pública sobre essa invasão injustificada de nossas vidas privadas. No entanto, estou preocupado não apenas pela possibilidade do surgimento de um estado de vigilância global, mas pelas implicações que isso tem no direito de proteger nossas comunicações utilizando a criptografia para autenticação e encriptação.

Não é nenhum segredo que a criptografia e a encriptação representam um problema para os sistemas de vigilância da NSA e que eles despendem muito esforço na tentativa de driblá-las, incluindo a exigência das chaves privadas de empresas para aplicações como o HTTPS. Minha preocupação é: caso se torne publicamente aceitável que governos espionem, sem mandados, redes internacionais e que isso é justificável ou necessário, podemos atingir um ponto no qual a própria legalidade do uso da criptografia pelo público geral seja questionada.

Profissionais da área de computação da minha geração provavelmente não começaram suas carreiras antes que o controle de exportação de criptografia dos Estados Unidos fosse relaxado em 1999, talvez levando-nos a tomar como certo a disponibilidade de algorítimos como o RSA e o AES com chaves grandes para propósitos criptográficos. Um mundo no qual uma agência governamental tentaria ativamente cercear o uso de tais tecnologias pode parecer inverossímil demais para nós — talvez menos para quem se lembra que a Pretty Good Privacy foi uma ideia radical que causou ao seu criador e ativista, Phil Zimmermann, problemas legais concretos.

Acredito que entusiastas da computação e usuários de sistemas operacionais livres, não apenas experts em criptografia, estão numa posição especial para ajudar seus amigos e familiares preocupados com a defesa de sua privacidade online e a segurança de suas comunicações e que, se valorizamos tanto a liberdade quanto a segurança da informação, como bons hackers fazem, temos, na verdade, a responsabilidade de fazê-lo. Acredito que as pessoas precisam estar conscientes não apenas das implicações da vigilância em massa numa escala global, mas também de como exercitar seus direitos para lutar contra ela. Se a legalidade da criptografia for algum dia questionada novamente, como um resultado de seu impedimento da vigilância sem mandados judiciais, sua difusão e a insistência do público em sua disponibilidade livre também deve tornar sua restrição não apenas impraticável, mas impensável.

É por isso que apoio a Electronic Frontier Foundation, a Free Software Foundation e qualquer um que apoie a liberdade e direito de todos para usar a tecnologia segura e privadamente. Espero que qualquer pessoa que leia este artigo considere fazer o mesmo.

Essa entrada é a parte 10 de 10 na série Criptografia no Linux.

Criptografia no Linux: Discos

Rafael Beraldo — Sat, 30 Nov 2013

Este é o nono post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

O GnuPG oferece uma maneira de criptografar seguramente arquivos individuais num sistema de arquivos, mas para informações ou sistemas de alta segurança, pode ser apropriado criptografar um disco inteiro para mitigar problemas como o cache de arquivos sensíveis em texto plano. Possivelmente, o modo mais popular de fazê-lo é usar a ferramenta TrueCrypt, mas o kernel do Linux inclui a sua própria solução de criptografia de disco, o dm-crypt. Você pode tirar proveito dela utilizando uma ferramenta de baixo nível chamada cryptsetup, ou mais facilmente com a LUKS, a Linux Unified Key Setup, implementando criptografia com senhas ou arquivos de chave.

Neste exemplo, demonstraremos como criptografar um disco USB, um bom método para armazenar seguramente dados realmente sensíveis, como chaves mestras PGP que só são necessárias ocasionalmente, ao invés de deixá-las constantemente montadas num dispositivo conectado à rede. Tenha cuidado, pois essa operação apagará qualquer arquivo existente no disco.

Instalação

As ferramentas criptográficas utilizadas pelo dm-crypt e pela LUKS são embutidas no Linux a partir da versão 2.6, mas você talvez tenha de instalar um pacote para acessar a interface cryptsetup. Em sistemas baseados no Debian, ela está disponível no pacote cryptsetup:

# apt-get install cryptsetup

Em sistemas baseados em pacotes RPM, como o Fedora ou CentOS, o pacote tem o mesmo nome, cryptsetup

# yum install cryptsetup

Criando o volume

Após identificarmos em qual dispositivo de blocos queremos o sistema de arquivos criptografado, por exemplo /dev/sdc1, podemos deletar qualquer conteúdo existente usando o wipefs:

# wipefs -a /dev/sdc1

Alternativamente, podemos zerar o disco inteiro, se quisermos sobrescrever completamente qualquer traço de dados prévios no disco. Essa operação pode levar um longo tempo para volumes grandes:

# cat /dev/zero >/dev/sdc1

Se você não tiver um dispositivo USB em mãos, mas ainda assim quiser testar essas instruções, é possível utilizar um dispositivo de loop num arquivo. Por exemplo, para criar um dispositivo de loop de 100MB:

# dd if=/dev/zero of=/loopdev bs=1k count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB) copied, 0.331452 s, 316 MB/s
# losetup -f
/dev/loop0
# losetup /dev/loop0 /loopdev

Você pode seguir o resto deste guia usando /dev/loop0 como o dispositivo de blocos em lugar de /dev/sdc1. Na saída acima, o comando losetup -f retorna o primeiro dispositivo de loop disponível para uso.

A configuração de um container LUKS num dispositivo de blocos é realizada como a seguir, sendo necessário fornecer uma senha forte; como sempre, quanto mais longa, melhor. Idealmente, você não deve utilizar a mesma senha que suas chaves do GnuPG ou SSH.

# cryptsetup luksFormat /dev/sdc1

WARNING!
========
This will overwrite data on /dev/sdc1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:

Esse comando cria um container de criptografia abstrato no disco, que pode ser aberto fornecendo a senha correta. Um dispositivo virtual mapeado é fornecido para criptografar todos os dados escritos a ele transparentemente, com os dados criptografados escritos no disco.

Usando o dispositivo mapeado

Podemos abrir o dispositivo mapeado utilizando cryptsetup luksOpen, que também irá perguntar a senha:

# cryptsetup luksOpen /dev/sdc1 secreto

Isso feito, o dispositivo de blocos em /dev/mapper/secreto pode ser utilizado da mesma maneira que qualquer outro dispositivo; todas as operações de disco são abstraídas pelas operações de criptografia. Provavelmente, você irá desejar criar um sistema de arquivos nele. No meu caso, criarei um sistema ext4:

# mkfs.ext4 /dev/mapper/secreto
mke2fs 1.42.8 (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
25168 inodes, 100352 blocks
5017 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1936 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

Agora, podemos montar o dispositivo normalmente, e os dados colocados no recém-criado sistema de arquivo serão criptografados transparentemente:

# mkdir -p /mnt/secreto
# mount /dev/mapper/secreto /mnt/secreto

Podemos, por exemplo, armazenar nossa chave privada do GnuPG:

# cp -prv /home/tim/.gnupg/secring.gpg /mnt/secreto

Informações sobre o dispositivo

Podemos obter informações sobre o container LUKS e as especificidades de sua criptografia usando o argumento luksDump no sistema de blocos subjacente. Ele nos mostra o método de criptografia utilizado, nesse caso, aes-xts-plain64.

# cryptsetup luksDump /dev/sdc1
LUKS header information for /dev/sdc1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      87 6d 08 59 b2 f0 c6 6e ca ec 5f 72 2c e0 35 33 c2 9e cb 8e
MK salt:        7f a5 38 4c 14 85 61 cb 6c 22 65 48 87 21 60 8f
                fa 40 2a ab ae 7d cc df c9 9b a4 e3 3c 64 b6 bb
MK iterations:  49375
UUID:           f4e5f28c-3b34-4003-9bcd-dbb2352042ba

Key Slot 0: ENABLED
        Iterations:             197530
        Salt:                   2d 57 f6 2b 44 a6 61 ee d6 ee e4 7d 64 f0 71 d6
                                55 16 09 83 b4 f0 94 ca 19 17 11 a9 34 84 02 96
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Desmontando o dispositivo

Quando terminamos de trabalhar com o dispositivo, devemos desmontar quaisquer sistemas de arquivos presentes e, também, fechar o dispositivo mapeado, para que a senha seja necessária para reabri-lo:

# umount /mnt/secreto
# cryptsetup luksClose /dev/mapper/secreto

Se ele também é um dispositivo removível, você também deve considerar a remoção física da mídia e colocá-la em algum local seguro.

Esse post apenas arranha a superfície da funcionalidade da LUKS; muitas outras coisas são possíveis com o sistema, incluindo a montagem automática de sistemas de arquivos criptografados e o uso de arquivos de chave armazenados ao invés de senhas digitadas. O FAQ do cryptsetup contém uma grande quantidade de informações, incluindo considerações sobre a recuperação de dados, e a Arch Wiki contém uma página muito completa com muitas outras maneiras de usar a LUKS seguramente.

Essa entrada é a parte 9 de 10 na série Criptografia no Linux.

Criptografia no Linux: Backups

Rafael Beraldo — Sat, 23 Nov 2013

Este é o oitavo post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

Embora possuir backups locais para a recuperação rápida de dados seja importante, tal como em um disco USB ou num disco rígido vago, é igualmente importante ter um backup externo, a partir do qual você possa restaurar seus documentos importantes se, por exemplo, o seu escritório foi roubado ou pegar fogo e você perder tanto seu computador quanto o seu meio de backup.

Para a maior parte das pessoas, a maneira mais fácil de fazê-lo é com um provedor de armazenamento que ofereça acesso a armazenamento em massa de tamanho apropriado para você, mantido nos sistemas de outras companhia, por um preço relativamente modesto ou mesmo de graça, como o Ubuntu One ou o Skydrive, da Microsoft. Os melhores provedores também criptografam os dados em seus servidores, não importando se eles têm acesso aos dados ou não.

Mas confiar todos os seus dados e a criptografia dos mesmos a uma companhia é arriscado, particularmente após as recentes revelações de um conluio corporativo com a NSA, e usuários preocupados com sua privacidade devem preferir a segurança de criptografar seus backups antes de serem enviados aos servidores. O provedor pode implementar seus próprios mecanismos de criptografia simétrica e/ou fechada, que podem ou não ser confiáveis. Como estalecemos anteriormente, para uma criptografia pessoal bastante robusta, podemos usar nossa instalação do GnuPG para criptografar arquivos antes de enviá-los:

$ tar -cf backup_docs-"$(date +%Y-%m-%d)".tar $HOME/Documentos
$ gpg --encrypt backup_docs-2013-07-27.tar
$ scp backup_docs-2013-07-27.tar.gpg usuario@backup.exemplo.com.br:backup_docs

O problema de criptografar arquivos inteiros antes de copiá-los ao servidor de armazenamento é que mesmo para dados de tamanho modesto, sempre realizar backups completos e sempre enviar todos os arquivos juntos pode custar muita banda. Da mesma forma, gostaríamos de ser capazes de restaurar nossos arquivos tal como eram num dia específico, para o caso de backups que não funcionem ou arquivos deletados acidentalmente, porém sem armazenar todos os arquivos em todos os dias de backup, o que pode acabar requerendo espaço demais.

Backups incrementais

Normalmente, a solução é usar um sistema de backup incremental, o que significa que, após o upload inicial de seus arquivos em sua totalidade ao sistema de backup, os backups sucessivos fazem o upload apenas das mudanças, arquivando-as num formato recuperável e com um aproveitamento de espaço eficiente. Sistemas como o Dirvish, uma interface escrita em Perl para o rsync(1), permitem isso.

Infelizmente, o Dirvish não criptografa os arquivos nem o conjunto de alterações que ele armazena. Precisamos de uma solução de backup incremental que calcule e armazene eficientemente as mudanças nos arquivos num servidor remoto e que também os criptografe. O Duplicity, uma ferramenta escrita em Python e construída sobre a biblioteca librsync se destaca nessa tarefa. Ele pode usar nossa configuração de chave assimétrica do GnuPG para a criptografia dos arquivos e está disponível em sistemas derivados do Debian no pacote duplicity.

Uso

Podemos ter uma ideia de como o duplicity(1) funciona pedindo que ele inicie um backup em nossa máquina local. O programa utiliza quase os mesmo argumentos de fonte e destino que ferramentas como o rsync ou o scp:

$ cd
$ duplicity --encrypt-key taspargos@exemplo.com.br Documentos file://backup_docs

É importante especificar a opção --encrypt-key, pois de outro modo o duplicity(1) utilizará a criptografia simétrica com senha, que é consideravelmente menos segura, ao invés da chave pública. Indique o endereço de email que corresponde ao par de chaves que você deseja utilizar para a criptografia.

O comando acima realiza o backup completo e criptografado do diretório, retornando a seguinte saída:

Os metadados remotos e locais estão sincronizados; nenhuma sincronização é necessária.
Data da última cópia de segurança completa: nenhuma
Não encontrou assinaturas, a mudança para backup completo.
--------------[ Estatísticas de backup ]--------------
StartTime 1374903081.74 (Sat Jul 27 17:31:21 2013)
EndTime 1374903081.75 (Sat Jul 27 17:31:21 2013)
ElapsedTime 0.01 (0.01 seconds)
SourceFiles 4
SourceFileSize 142251 (139 KB)
NewFiles 4
NewFileSize 142251 (139 KB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 4
RawDeltaSize 138155 (135 KB)
TotalDestinationSizeChange 138461 (135 KB)
Errors 0
-------------------------------------------------------

Você poderá notar que sua senha não é requerida. Lembre-se que para criptografar arquivos, a chave pública não requer uma senha; a ideia geral é que qualquer um possa criptografar utilizando nossa chave, sem precisar de sua permissão.

Verificando o diretório criado, backup_docs, encontramos três novos arquivos dentro, todos criptografados:

$ ls -1 backup_docs
duplicity-full.20130727T053121Z.manifest.gpg
duplicity-full.20130727T053121Z.vol1.difftar.gpg
duplicity-full-signatures.20130727T053121Z.sigtar.gpg

O arquivo vol1.difftar.gpg contém os dados armazenados; os outros dois arquivos contém metadados sobre os conteúdos do arquivo, para que as diferenças sejam calculadas na próxima vez que o backup for executado.

Se fizermos uma pequena mudança num arquivo do diretório que estamos copiando e rodarmos o mesmo comando novamente, notaremos que o backup será realizado incrementalmente, e apenas as mudanças (o novo arquivo) será salvo:

$ duplicity --encrypt-key taspargos@exemplo.com.br Documentos file://backup_docs
Os metadados remotos e locais estão sincronizados; nenhuma sincronização é necessária.
Data da última cópia de segurança completa: Sab Jul 27 17:34:33 2013
--------------[ Estatísticas de backup ]--------------
StartTime 1374903396.52 (Sat Jul 27 17:36:36 2013)
EndTime 1374903396.52 (Sat Jul 27 17:36:36 2013)
ElapsedTime 0.01 (0.01 seconds)
SourceFiles 5
SourceFileSize 142255 (139 KB)
NewFiles 2
NewFileSize 4100 (4.00 KB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 2
RawDeltaSize 4 (4 bytes)
TotalDestinationSizeChange 753 (753 bytes)
Errors 0
-------------------------------------------------------

Também encontraremos três novos arquivos no diretório backup_docs, contendo os novos dados:

$ ls -1 backup_docs
duplicity-full.20130727T053433Z.manifest.gpg
duplicity-full.20130727T053433Z.vol1.difftar.gpg
duplicity-full-signatures.20130727T053433Z.sigtar.gpg
duplicity-inc.20130727T053433Z.to.20130727T053636Z.manifest.gpg
duplicity-inc.20130727T053433Z.to.20130727T053636Z.vol1.difftar.gpg
duplicity-new-signatures.20130727T053433Z.to.20130727T053636Z.sigtar.gpg

Note que os novos arquivos têm o prefixo duplicity-inc- ou duplicity-new-, denotando que são backups incrementais e não completos.

Note, também, que para poder rastrear os arquivos que já foram copiados, o duplicity(1) armazena os metadados em ~/.cache/duplicity, bem como junto com os backups. Assim, podemos executar nossos processos de backup de forma autônoma, ao invés de ter de inserir nossa senha para ler os metadados no servidor remoto antes de realizar o backup incremental. Naturalmente, se perdermos nossos arquivos em cache, não há problemas; podemos ler os arquivos que estão no backup fornecendo nossa senha quando pedida.

Backups remotos

Se você tem acesso SSH ou mesmo apenas SCP/SFTP aos servidores do seu provedor de armazenamento, não é preciso mudar muito para que o duplicity(1) armazene os arquivos nesses servidores:

$ duplicity --encrypt-key taspargos@exemplo.com.br Documentos sftp://usuario@backup.exemplo.com.br:backup_docs

Seus backups serão, então, enviados por SSH ao diretório backup_docs no sistema backup.exemplo.com.br, com o nome de usuário usuario. Dessa maneira, os dados são não apenas protegidos durante a transmissão, mas também armazenados criptografados no servidor remoto, que nunca vê seus dados em texto plano. Qualquer um que tenha acesso aos seus backups pode ver apenas o tamanho aproximado dos dados, a data em que foram criados e (se você publicar sua chave pública) a ID de usuário da chave do GnuPG usada para criptografá-los.

Se você estiver usando o programa ssh-agent(1) para armazenar suas chaves privadas descriptografadas, você nem mesmo terá de digitar sua senha para isso.

A interface do duplicity(1) suporta outros métodos de envio para diferentes servidores, também, incluindo o backend boto, para o S3 Amazon Web Services, o backend gdocs, para o Google Docs, e httplib2 ou oauthlib para o Ubuntu One.

Se você desejar, também é possível assinar seus backups, para garantir que não foram modificados, mudando --encrypt-key para --encrypt-sign-key. Note que essa operação exigirá sua senha.

Restaurando o backup

Restaurar a partir de um volume de backup do duplicity é bastante parecido com realizar um backup, mas os argumentos são invertidos:

$ duplicity sftp://usuario@backup.exemplo.com.br:backup_docs restaura_docs
Sincronizando metadados remotos ao cache local...
Senha GnuPG:
Copiando duplicity-full-signatures.20130727T053433Z.sigtar.gpg ao cache local.
Copiando duplicity-full.20130727T053433Z.manifest.gpg ao cache local.
Copiando duplicity-inc.20130727T053433Z.to.20130727T053636Z.manifest.gpg ao cache local.
Copiando duplicity-new-signatures.20130727T053433Z.to.20130727T053636Z.sigtar.gpg ao cache local.
Data do último backup: Sat Jul 27 17:34:33 2013

Note que, dessa vez, sua senha será requerida, pois a restauração do backup requer a descriptografia dos dados e possivelmente as assinaturas em seu volume de backup. Após inseri-la, o conjunto completo de documentos mais recentemente copiados estará disponível em restaura_docs.

Usando esse sistema incremental, também podemos restaurar os dados tal como eram antes de uma data específica. Por exemplo, para recuperar meu diretório ~/Documentos tal como era há três dias, posso rodar:

$ duplicity --time 3D \
    sftp://usuario@backup.exemplo.com.br:backup_docs \
    restaura_docs

Para volumes maiores, você pode extender esse comando para restaurar apenas arquivos em particular, se precisar:

$ duplicity --time 3D \
    --file-to-restore privado/eff.txt \
    sftp://usuario@backup.exemplo.com.br:backup_docs \
    restaura_docs

Automatizando o backup

Você deve rodar seu primeiro backup interativamente para garantir que ele faz o que você precisa mas, quando você estiver confiante que tudo está funcionando corretamente, você pode escrever um Bash script simples para rodar backups incrementais automaticamente. Aqui está um exemplo, salvo em $HOME/.local/bin/backup-remote:

#!/usr/bin/env bash

# Rode o keychain para encontrar quaisquer agentes armazenando chaves
# descriptografadas que possamos precisar (opcional, dependendo da sua
# configuração de chave do SSH) 
eval "$(keychain --eval --quiet)"

# Especifique um diretório para realizar o backup, uma ID de chave GnuPG, e
# um usuário remoto e hostname
keyid=taspargos@exemplo.com.br
local=/home/tim/Documentos
remote=sftp://usuario@backup.exemplo.com.br/backup_docs

# Execute o backup com o duplicity
/usr/bin/duplicity --encrypt-key "$keyid" -- "$local" "$remote"

A linha com keychain é opcional, mas será necessária se você estiver usando uma chave SSH com senha; também será necessário ter se autenticado ao ssh-agent ao menos uma vez. Veja o artigo anterior sobre agentes SSH/GPG para mais detalhes.

Não esqueça de tornar o script executável:

$ chmod +x ~/.local/bin/backup-remote

Você também pode pedir ao cron(8) que execute-o uma vez por semana, rodando como seu usuário, editando o arquivo crontab(5) de usuário:

$ crontab -e

A linha a seguir roda o script toda manhã, começando às 6:

0 6 * * *   ~/.local/bin/backup-remote

Dicas

Algumas melhores práticas gerais se aplicam ao nosso caso, consistentes com o Tao do Backup:

Garanta que seus backups são concluídos; peça ao cron que envie sua saída para seu email ou para um arquivo que você cheque pelo menos ocasionalmente, para ter certeza que seus backups estão funcionando. Altamente recomendo usar o email e incluir erros:
```
  MAILTO=voce@exemplo.com.br
  0 6 * * *   ~/.local/bin/backup-remote 2>&1
```
Armazene seus backups em servidores locais, também. Você pode prevenir que seu provedor de backup leia seus arquivos, mas não pode evitar que sejam deletados acidentalmente.

Não se esqueça de testar/restaurar seus backups ocasionalmente para garantir que estão funcionando corretamente. Também é aconselhável rodar duplicity verify contra os arquivos ocasionalmente, especialmente se você não faz backups todos os dias:

  $ duplicity verify sftp://usuario@remoto.exemplo.com.br/backup_docs Documentos
  Os metadados remotos e locais estão sincronizados; nenhuma sincronização é necessária.
  Data da última cópia de segurança completa: Sat Jul 27 17:34:33 2013
  Senha GnuPG:
  Verificação completa: 2195 files compared, 0 differences found.

Esse sistema incremental significa que você, provavelmente, terá de fazer backups completos apenas uma vez, portanto é melhor copiar dados demais do que dados de menos; se você pode gastar a banda e o espaço, copiar seu computador inteiro não é tão extremo quanto soa.
Tente não depender demais dos seus backups remotos; veja-os como último recurso e trabalhe seguramente e com backups locais tanto quanto puder. Certamente, nunca confie em backups como controle de versão; use o Git para isso.

Essa entrada é a parte 8 de 10 na série Criptografia no Linux.

Criptografia no Linux: Email

Rafael Beraldo — Mon, 04 Nov 2013

Este é o sétimo post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

Um sistema de armazenamento de senhas criptografado é um bom começo, mas agora que temos uma instalação do GnuPG em funcionamento, devemos considerar o uso do PGP para aquilo que foi originalmente criado: emails. Para isso, usaremos o Mutt.

O Mutt é um cliente de email para o console, ou MUA (do inglês mail user agent), projetado sobretudo para gerenciar e ler emails. Ao contrário de outros clientes como o Thunderbird, ele não foi projetado para ser um cliente POP3/IMAP, ou um agente SMTP, embora versões mais recentes incluam essa funcionalidade; essas são operações realizadas por programas como o Getmail e o MSMTP.

Se, como muitas outras pessoas, você estiver usando o Gmail, o Mutt funciona muito bem com POP3/IMAP e SMTP, permitindo que você componha mensagens em texto plano, com seu editor de escolha, numa janela de terminal, num ambiente altamente configurável e utilizando sua própria criptografia para email, para qualquer comunicação confidencial, de maneira que nem mesmo o seu provedor de email possa lê-la.

O uso geral do Mutt e a configuração para usuários do Gmail não será coberta em detalhes aqui. Por enquanto, existem muitos artigos excelentes sobre a configuração básica do Mutt. Se você está interessado na configuração de outros clientes de email para o Linux, como o Claws ou o Thunderbird, o Cory Sadowski tem um ótimo passo-a-passo, além de comentar sobre outras configurações de privacidade relevantes tanto no GNU/Linux quanto no Windows.

As instruções abaixo presumem que você já tem um par de chaves GnuPG pronto, com o gpg-agent(1) rodando no background para gerenciar suas chaves.

Background

A maioria dos guias de configuração do PGP para o Mutt online são bastante antigos e geralmente sugerem muitas linhas para o arquivo de configuração, .muttrc, que lidam diretamente com o comando gpg, com uma miríade de opções e algumas substituições de variáveis obscuras:

set pgp_clearsign_command="gpg --no-verbose --batch --output - ...
set pgp_decode_command="gpg %?p?--passphrase-fd 0? --no-verbose ...
set pgp_decrypt_command="gpg --passphrase-fd 0 --no-verbose --batch ...
set pgp_encrypt_only_command="pgpewrap gpg --batch --quiet ...
set pgp_encrypt_sign_command="pgpewrap gpg --passphrase-fd 0 ...
set pgp_export_command="gpg --no-verbose --export --armor %r"
set pgp_import_command="gpg --no-verbose --import -v %f"
set pgp_list_pubring_command="gpg --no-verbose --batch --with-colons ...
set pgp_list_secring_command="gpg --no-verbose --batch --with-colons ...
set pgp_sign_command="gpg --no-verbose --batch --output - ...
set pgp_verify_command="gpg --no-verbose --batch --output - --verify %s %f"
set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint ...

Sou completamente a favor da filosofia do Unix de usar os programas em conjunto, mas isso é demais. Essa configuração é volúvel e muito difícil de trabalhar, além de requerer conhecimento demais do gpg(1) para ser usada e editada sensatamente. Afinal de contas, queremos uma configuração que possamos entender razoavelmente bem.

Então esqueça tudo aquilo; ao invés disso, iremos usar o GPGME. A configuração acima é exatamente o problema que essa biblioteca foi projetada para resolver: os aplicativos podem se ligar a ela para simplificar o uso das funções do GnuPG, incluindo a interface com agentes. Podemos substituir todas as linhas acima com o seguinte:

set crypt_use_gpgme = yes

Instalação

Se você tem o Mutt instalado, há chances que ele já possua uma interface para o GPGME. Você pode checar se sua versão atual do Mutt é capaz de utilizá-lo com a saída de mutt -v version. Essa é a saída do meu, usando o Mutt empacotado para o Debian GNU/Linux, que suporta o GPGME:

$ mutt -v | grep -i gpgme
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME
upstream/548577-gpgme-1.2.patch

Se você não tem uma versão do Mutt com GPGME, você pode fazer o download do código fonte e compilá-lo com a opção --enable-gpgme:

$ ./configure --enable-gpgme
$ make
# make install

Você pode ter de instalar a biblioteca GPGME e suas headers antes disso:

# apt-get install libgpgme11 libgpgme11-dev

Configuração

Adicione as seguintes linhas ao arquivo .muttrc; remova qualquer texto que comece por crypt_* ou pgp_*:

# Use o GPGME
set crypt_use_gpgme = yes

# Assine as respostas para emails já assinados
set crypt_replysign = yes

# Criptografe as respostas para emails já criptografados
set crypt_replyencrypt = yes

# Criptografe e assine as respostas para emails já criptografados e assinados
set crypt_replysignencrypted = yes

# Tente verificar assinaturas automaticamente
set crypt_verify_sig = yes

Reinicie o Mutt e pronto.

Uso

Primeiramente, verifique se você tem a chave pública do seu destinatário disponível em seu chaveiro do GnuPG:

$ gpg --list-keys joao@exemplo.com.br

Se ela estiver disponível para download, você pode baixá-la usando o curl(1) e importá-la diretamente com o gpg(1):

curl http://www.exemplo.com.br/joao-ninguem.asc | gpg --import
gpg: key 1234ABCD: public key "João Ninguém" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: no ultimately trusted keys found

Lembre-se: é sua responsabilidade decidir o grau de confiança que tem nessa chave; normalmente, a melhor prática é que vocês se encontrem em pessoa para trocar as fingerprints das chaves, de modo que se tenha certeza absoluta de que a chave corresponde àquele usuário.

Se você conhece mais ninguém que use o PGP para se comunicar, você pode me enviar uma mensagem criptografada com minha chave pública, 0x77BB8872, para tom@sanctum.geek.nz (em inglês). Caso você me envie sua chave pública, ou insira um link em sua mensagem, irei respondê-la com outra mensagem criptografada com a sua chave pública, para que você pode verificar se tudo está funcionando.

$ curl http://static.sanctum.geek.nz/thomas-ryder.asc | gpg --import

Você também pode enviar uma mensagem criptografada com a chave pública do tradutor desse artigo, 0x2D4BF1D0, para rberaldo@cabaladada.org (em português ou inglês).

$ curl http://www.cabaladada.org/public/rberaldo.asc | gpg --import

Voltando ao Mutt, comece a compor sua mensagem com a tecla m. Preencha os campos de destinatário e assunto normalmente e escreva sua mensagem. Quando terminar, salve e saia do $EDITOR e sua mensagem estará em sua tela de Composição, esperando para ser enviada. Aperte p para acessar o menu do PGP, que aparecerá na parte de baixo da tela:

PGP (e)ncrypt, (s)ign, sign (a)s, (b)oth, s/(m)ime or (c)lear?

Pressione b para assinar e criptografar a mensagem.

Caso você queira ser capaz de ler a mensagem após enviá-la, será necessário criptografá-la tanto com a sua chave quanto com a do destinatário. Em minha experiência, a maneira mais simples de fazer isso é adicionar o seu próprio endereço ao campo Bcc: pressionando b. Você também pode deixar esse comportamento como padrão com a seguinte linha em ~/.gnupg/gpg.conf, onde 0x1234ABCD é a ID curta de sua chave:

encrypt-to 0x1234ABCD

Quando você enviar a mensagem pressionando y, talvez seja necessário especificar quais chaves você deseja usar para quais destinatários, se você não possuir uma única chave para aquele endereço de email.

Além disso, você terá de inserir a senha de sua chave privada, que será requerida pelo programa de entrada de PIN, a menos que um agente já a tenha carregada. A senha é necessária para assinar a mensagem. Quando você a fornecer, a mensagem será enviada e, caso você tenha se inserido no campo Bcc:, você também deve ser capaz de lê-la em seus emails enviados, com alguns cabeçalhos mostrando informações do PGP (se a mensagem foi assinada, criptografada ou ambos):

O destinatário será capaz de descriptografar a mensagem usando sua chave privada, e ninguém mais além de vocês dois poderá lê-la. Note que isso funciona qualquer que seja número de destinatários, desde que você tenha a chave pública de cada um deles.

Lembre-se que os metadados da mensagens, tais como os nomes e endereços dos remetentes e destinatários, o dia e a hora em que foi enviada e (principalmente) o assunto, são enviados em texto plano. Apenas o corpo da mensagem (incluindo os anexos) é criptografado.

Alguns extras úteis

Com o GPGME, o Mutt tenta utilizar a primeira chave secreta disponível no chaveiro privado. Caso você queira utilizar outro par de chaves específico para assinar mensagens, você pode especificá-lo com a opção pgp_sign_as no arquivo .muttrc:

set pgp_sign_as = 0x9876FEDC

Se você deseja assinar automaticamente todas as mensagens que enviar, você pode configurar a opção crypt_autosign:

set crypt_autosign = yes

O primeiro conjunto de opções que configuramos anteriormente irá assinar e/ou criptografar mensagens automaticamente, em respostas para mensagens assinadas, criptografados ou ambos.

Se você desejar incluir um link para a sua chave PGP nos cabeçalhos das mensagens, é possível adicionar uma header personalizada com a opção my_hdr:

my_hdr X-PGP-Key: http://static.sanctum.geek.nz/thomas-ryder.asc

Todos esses aspectos, combinados com a rapidez e a configuração poderosa do Mutt, o tornam um cliente de email PGP conveniente e muito capaz. Como sempre, quanto mais pessoas que você conhecer utilizarem o PGP, e quanto mais chaves públicas você tiver, mais útil ele será.

Essa entrada é a parte 7 de 10 na série Criptografia no Linux.

Criptografia no Linux: Senhas

Rafael Beraldo — Fri, 04 Oct 2013

Este é o sexto post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

É cada vez mais conhecido que o uso de senhas previsíveis ou o uso da mesma senha para mais de uma conta é um sério risco de segurança, pois um invasor pode tomar controle de uma conta (como um email) e causar uma série de prejuízos. Se um invasor conseguir o hash de sua senha para algum serviço na web, convém ter certeza de que o hash é muito difícil de reverter e, mesmo que ele possa ser revertido, é exclusivo o bastante para não dar ao invasor acesso a qualquer outra de suas contas.

Essa crescente percepção contribuiu para a popularidade dos gerenciadores de senhas, ferramentas projetadas para gerar, armazenar e recuperar senhas de forma segura, criptografadas com uma senha ou palavra passe mestra. Em alguns casos, como o KeePass, os dados são armazenados localmente; em outros, como o LastPass, são armazenados em um serviço da web. Ambas são boas ferramentas e funcionam bem no Linux. Pessoalmente, tenho algumas reservas quanto o LastPass, pois não quero minhas senhas armazenadas em um serviço de terceiros, além de não confiar na criptografia com o JavaScript.

Curiosamente, agora que temos uma configuração cuidadosa do GnuPG para lidar com a criptografia, outra opção é a ferramenta [pass(1)][pass], que se autoproclama “o gerenciador de senhas padrão do UNIX”. Ela não passa de um shell script e algumas completações para obash(1)baseados em ferramentas existentes como o [git(1)][git], o [gpg2(1)][gpg2], o [pwgen(1)][pwgen], o [tree(1)][tree], o [xclip(1)][xclip] e seu $EDITOR` de escolha. Se você ainda não investiu em um método de gerenciamento de senhas existente, essa pode ser uma boa aplicação inicial para o seu sistema de criptografia e uma ótima abordagem minimalista para o armazenamento seguro de senhas a partir da linha de comando (e, portanto, SSH).

Em sistemas derivados do Debian, a ferramenta está disponível como parte do pacote pass:

# apt-get install pass

Ela inclui um manual:

$ man pass

Instruções para a instalação em outros sistemas operacionais estão disponíveis no site do projeto. Outras versões também estão disponíveis para o download, bem como um link para o repositório de desenvolvimento. Caso deseje utilizar o programa, certifique-se que as outras ferramentas necessárias citadas acimas estão instaladas, embora o xclip(1) seja necessário apenas se você utilizar o sistema X Windows.

Instalação

Podemos obter um panorama geral do pass(1) invocando-o sem argumentos:

$ pass

Para começar, iremos inicializar nosso armazenamento de senhas. Para nossas próprias senhas, é necessário rodar o comando como o seu usuário e não como root. Uma vez que o pass(1) usa o GnuPG para a criptografia, também precisaremos informá-lo a ID da chave apropriada que ele deve utilizar. Lembre-se que você pode encontrar esse código hexadecimal de oito dígitos digitando gpg --list-secret-keys. Uma sequência de texto exclusiva que identifique sua chave privada, como o seu nome ou endereço de email, também pode funcionar.

$ pass init 0x1FC2985D
mkdir: created directory ‘/home/tim/.password-store’
Password store initialized for 0x1FC2985D.

Notamos que, de fato, o diretório ~/.password-store foi criado, embora no momento esteja vazio exceto pelo arquivo .gpg-id, que mantém um registro da ID de nossa chave:

$ find .password-store
.password-store
.password-store/.gpg-id

Inserindo senhas

Vamos inserir uma senha existente com pass insert, passando ao comando um nome descritivo e hierárquico:

$ pass insert google.com/gmail/exemplo@gmail.com
mkdir: created directory ‘/home/tim/.password-store/google.com’
mkdir: created directory ‘/home/tim/.password-store/google.com/gmail’
Enter password for google.com/gmail/exemplo@gmail.com:
Retype password for google.com/gmail/exemplo@gmail.com:

A senha é digitada e lida na linha de comando, criptografada e colocada em ~/.password-store:

$ find .password-store
.password-store
.password-store/google.com
.password-store/google.com/gmail
.password-store/google.com/gmail/exemplo@gmail.com.gpg
.password-store/.gpg-id

Note que o pass(1) cria uma estrutura de diretórios automaticamente. Podemos obter uma boa visão do armazenamento das senhas com o comando pass, sem argumentos:

$ pass
Password Store
└── google.com
    └── gmail
        └── exemplo@gmail.com

Gerando senhas

Se, ao invés de inserir uma senha existente, você desejar gerar uma senha nova, segura e aleatória, você pode usar o comando generate, incluindo o seu comprimento como último argumento:

$ pass generate google.com/gmail/exemplo@gmail.com 16
The generated password to google.com/gmail/exemplo@gmail.com is:
!Q%i$$&q1+JJi-|X

Se o site não aceitar símbolos na senha, você pode adicionar a opção -n ao comando:

$ pass generate -n google.com/gmail/exemplo@gmail.com 16
The generated password to google.com/gmail/exemplo@gmail.com is:
pJeF18CrZEZzI59D

O pass(1) usa o pwgen(1) para gerar as senhas. Nos dois casos acima, ela é automaticamente inserida no armazenamento.

Se você precisa modificar uma senha existente, você pode tanto sobrescrevê-la com o comando insert, ou usar a operação edit para chamar o $EDITOR de sua escolha:

$ pass edit google.com/gmail/exemplo@gmail.com

Caso utilize a opção edit, você deve ser cuidadoso e ter certeza que seu editor não está configurado para manter arquivos de backup ou de troca, em texto plano, dos documentos que ele edita, em diretórios temporários ou em sistemas de arquivos na memória. Caso esteja utilizando o Vim, eu escrevi um script para tentar resolver esse problema.

Note que a adição ou mudança de senhas não requer a senha de sua chave privada; apenas a sua recuperação a requer, consistente com a maneira como o GnuPG normalmente trabalha.

Recuperando senhas

A senha que adicionamos ao programa pode ser, agora, recuperada e impressa na linha de comando, desde que digitemos a senha correta para nossa chave privada:

$ pass google.com/gmail/exemplo@gmail.com
(...tela do gpg-agent pinentry...)
Tr0ub4dor&3

Se você estiver utilizando o X Windows e o xclip(1) estiver instalado, a senha pode ser colocada temporariamente na área de transferência e colada em formulários online:

$ pass -c google.com/gmail/exemplo@gmail.com
Copied google.com/gmail/exemplo@gmail.com to clipboard. Will clear in 45 seconds.

Note que, em todos os casos, se as completações para o bash estiverem instaladas e funcionando, é possível completar o caminho completo das senhas usando a tecla Tab , como se você estivesse navegando uma hierarquia de diretórios.

Deletando senhas

Quando uma senha não é mais necessária, pode removê-la com pass rm:

$ pass rm google.com/gmail/exemplo@gmail.com
Are you sure you would like to delete google.com/gmail/exemplo@gmail.com? [y/N] y
removed ‘/home/tim/.password-store/google.com/gmail/exemplo@gmail.com.gpg’

Podemos deletar diretórios de senhas inteiros com pass rm -r:

$ pass rm -r google.com
Are you sure you would like to delete google.com? [y/N] y
removed ‘/home/tim/.password-store/google.com/gmail/exemplo@gmail.com.gpg’
removed directory: ‘/home/tim/.password-store/google.com/gmail’
removed directory: ‘/home/tim/.password-store/google.com’

Controle de versão

Para manter a história de nossas senhas, incluindo senhas que foram deletadas, se algum dia precisarmos delas novamente, podemos configurar o controle de versão automático com o comando pass git init:

$ pass git init
Initialized empty Git repository in /home/tim/.password-store/.git/
[master (root-commit) 0ebb933] Added current contents of password store.
 1 file changed, 1 insertion(+)
  create mode 100644 .gpg-id

Esse comando irá atualizar o repositório sempre que uma senha é modificada, o que significa que, sem dúvidas, seremos capazes de recuperar senhas antigas que substituímos ou deletamos:

$ pass insert google.com/gmail/novoexemplo@gmail.com
mkdir: created directory ‘/home/tim/.password-store/google.com’
mkdir: created directory ‘/home/tim/.password-store/google.com/gmail’
Enter password for google.com/gmail/novoexemplo@gmail.com:
Retype password for google.com/gmail/novoexemplo@gmail.com:
[master 00971b6] Added given password for google.com/gmail/novoexemplo@gmail.com to store.
 1 file changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 google.com/gmail/novoexemplo@gmail.com.gpg

Backups

Uma vez que os arquivos contendo as senhas são todos criptografados com apenas nossa chave do GnuPG, podemos armazenar um backup em sites de terceiros e em computadores remotos, de maneira relativamente segura, simplesmente copiando o diretório ~/.password-store. Por outro lado, se os nomes dos arquivos contém informações confidenciais, tais como nomes de usuários ou sites privativos, você pode realizar o backup de uma tarball criptografada do diretório:

$ tar -cz .password-store \
    | gpg --sign --encrypt -r 0x1FC2985D \
    > password-store-backup.tar.gz.gpg

O diretório pode ser restaurado de forma similar:

$ gpg --decrypt \
    < password-store-backup.tar.gz.gpg \
    | tar -xz

Essa entrada é a parte 6 de 10 na série Criptografia no Linux.

Criptografia no Linux: Agentes

Rafael Beraldo — Mon, 30 Sep 2013

Este é o quinto post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

Agora que o GnuPG e o SSH estão configurados seguramente, podemos criptografar, descriptografar, assinar e verificar mensagens, e autenticar seguramente a servidores remotos sem o risco de expor nossas senhas e com uma possibilidade efetivamente nula de ataques de força bruta. Isso tudo é ótimo, mas ainda existe um elo fraco em nossa corrente com o qual lidar — nossas senhas.

Se você usa essas ferramentas com frequência, inserir nossa senha para a maior parte das operações pode se tornar irritante. Podemos ficar tentados a incluir um meio de automatizar a inserção da senha, ou simplesmente não usá-la, deixando nossa chave privada descriptografada. Como usuários preocupados com a segurança, nós definitivamente desejamos evitar a última possibilidade, caso o arquivo de nossa chave privada seja roubado, e é aqui que o conceito de agentes para o SSH e GnuPG entra.

Um agente é um daemon projetado para otimizar o processo de usar chaves privadas descriptografadas, guardando os detalhes seguramente na memória, idealmente por um período limitado de tempo. Ele permite que você insira sua senha do SSH ou GnuPG apenas uma vez e usos subsequentes que requerem a chave privada descriptografada são gerenciados pelo agente.

Neste artigo, discutiremos o básico da configuração de agentes para o SSH e o GnuPG. Depois que você souber como eles funcionam, iremos apresentar uma ferramenta conveniente para iniciá-los e gerenciá-los facilmente.

Agentes para o SSH

O programa ssh-agent(1) vem como parte da suíte OpenSSH. Ele pode ser executado em dois modos, como parte de um processo pai ou daemonizado e rodando no plano de fundo. Iremos discutir o último método, uma vez que é mais comumente usado e mais flexível.

Instalação e configuração

Quando rodamos o ssh-agent(1) pela primeira vez, seu comportamento é curioso: ele não parece fazer nada além de soltar umas linhas de shell script enigmático:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-EYqoH3qwfvbe/agent.28881; export SSH_AUTH_SOCK;
SSH_AGENT_PID=28882; export SSH_AGENT_PID;
echo Agent pid 28882;

No entanto, podemos verificar que o daemon está rodando com o PID que ele menciona:

$ ps 28882
  PID TTY      STAT   TIME COMMAND
  28882 ?        Ss     0:00 ssh-agent

Mas se ele está executando sem problemas, qual o problema do shell script que ele produz? Por que ele não roda o script de uma vez?

A resposta é uma interessante solução alternativa para a rigidez do modelo de processos do Unix; especificamente, um processo não pode modificar seu ambiente pai. As variáveis SSH_AUTH_SOCK e SSH_AGENT_PID são projetadas para permitir que programas como o ssh(1) encontrem o agente e possam se comunicar com ele, então definitivamente precisamos atribuir valores a elas. No entanto, se o ssh-agent(1) tentasse configurá-las automaticamente, as configurações seriam aplicadas apenas para seu próprio processo e não para o shell no qual o executamos.

Assim, além de executar o ssh-agent(1), precisamos executar o código que ele imprime na tela para que as variáveis sejam atribuídas em nosso shell. Um bom método para fazer isso em Bash é usar o eval e a substituição de comando com $(...).

$ eval $(ssh-agent)
Agent 3954

Se executarmos esse comando, vemos não apenas que o ssh-agent(1) está rodando, mas que temos duas novas variáveis em nosso ambiente identificando o caminho de seu socket e a ID do processo:

$ pgrep ssh-agent
3954
$ env | grep ^SSH
SSH_AUTH_SOCK=/tmp/ssh-oF1sg154ygSt/agent.3953
SSH_AGENT_PID=3954

Com isso feito, o agente está pronto e podemos começar a usá-lo para gerenciar nossas chaves.

Uso

O próximo passo é carregar nossas chaves no agente com o ssh-add(1). Dê ao programa o caminho completo da chave privada que o agente deve usar. O caminho é, provavelmente, ~/.ssh/id_rsa ou ~/.ssh/id_dsa:

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/tim/.ssh/id_rsa:
Identity added: /home/tim/.ssh/id_rsa (/home/tim/.ssh/id_rsa)

Você pode deixar esse argumento de lado se desejar que o ssh-add adicione todos os tipos de chave padrão em ~/.ssh caso elas existam (id_dsa, id_rsa e id_ecdsa):

$ ssh-add

De qualquer maneira, sua senha será requerida; isso é esperado, e você deve digitá-la.

Se pedirmos ao ssh-add(1) que liste as chaves que está gerenciando, veremos a chave que acabamos de adicionar:

i$ ssh-add -l
4096 87:ec:57:8b:ea:24:56:0e:f1:54:2f:6b:ab:c0:e8:56 /home/tim/.ssh/id_rsa (RSA)

Agora, caso tentemos conectar a outro servidor utilizando essa chave, não teremos de providenciar nossa senha; seremos conectados imediatamente:

tim@local:~$ ssh remoto
Welcome to remote.sanctum.geek.nz, running GNU/Linux!
tim@remoto:~$

O padrão do agente é manter as chaves permanentemente, até que ele seja parado ou até que as chaves sejam explicitamente removidas, uma a uma, com o comando ssh-add -d <arquivo da chave>, ou até que todas sejam removidas de uma vez com ssh-add -D. Para os cautelosos, você pode configurar um tempo limite com o comando ssh-add -t. Por exemplo, para que o ssh-add esqueça sobre as chaves após duas horas, você pode executar:

$ ssh-add -t 7200 ~/.ssh/id_rsa

Para matar o agente completamente, você pode usar o comando ssh-agent -k, novamente com eval $(...) envolvendo o comando:

$ eval $(ssh-agent -k)
Agent pid 4501 killed

Para se livrar do agente após sair de sua sessão, você pode considerar adicionar o comando acimo ao script ~/.bash_logout ou similares.

Configuração permanente

Se você gostou do agente e ele torna o gerenciamento de suas chaves mais conveniente, faz sentido colocá-lo num script de inicialização como o ~/.bash_profile. Dessa maneira, o agente será iniciado a cada login e seremos capazes de comunicar com ele a partir de qualquer subshell (xterm, screen, ou o tmux, se configurado apropriadamente):

eval $(ssh-agent)
ssh-add ~/.ssh/id_rsa

Em nosso próximo login num TTY, nossa senha será requerida e, a partir daí, poderemos conectar a qualquer máquina usando as chaves gerenciadas pelo agente:

tim@local:~$ ssh remoto
Welcome to remote.sanctum.geek.nz, running GNU/Linux!

Se você deseja utilizar um gerenciador de desktop como o GDM ou o XDM, você pode adicionar uma variável apontando para o programa ssh-askpass(1):

eval $(ssh-agent)
export SSH_ASKPASS=/usr/bin/ssh-askpass
ssh-add ~/.ssh/id_rsa

Se a variável SSH_ASKPASS está atribuída como acima e DISPLAY se refere a um monitor em funcionamento, um simples aviso gráfico aparecerá, pedindo nossa senha:

Esse programa talvez tenha de ser instalado separadamente. Em sistemas derivados do Debian, o nome do pacote é ssh-askpass.

Todos os processos filhos e subshells do shell de login irão herdar as variáveis do agente, uma vez que foram exportadas utilizando o export:

tim@local:~$ screen
tim@local:~$ tmux bash
tim@local:~$ bash
tim@local:~$ ssh remote
Welcome to remote.sanctum.geek.nz, running GNU/Linux!
tim@remote:~$

Dessa maneira, temos que digitar nossa senha apenas uma vez por sessão de login e podemos conectar a todos os servidores aos quais nossas chaves conferem acesso… Muito conveniente!

Agentes do GnuPG

Assim como o ssh-agent(1), existe também um agente para gerenciar chaves do GnuPG, chamado gpg-agent(1). O seu comportamento é muito similar. Em sistemas derivados do Debian, ele pode ser instalado com o pacote gnupg-agent. Você também deve instalar um programa de pinentry [entrada de PIN]; como estamos focando no aprendizado dos aspectos básicos na linha de comando, utilizaremos o pinentry-curses(1):

# apt-get install gnupg-agent pinentry-curses

Configuração

Iniciaremos o agente usando o mesmo truque com eval $(...) que aprendemos com o ssh-agent:

$ eval $(gpg-agent --daemon)

Podemos verificar que o agente está rodando no plano de fundo com o PID infomado e também que temos uma nova variável de ambiente:

$ pgrep gpg-agent
5131
$ env | grep ^GPG
GPG_AGENT_INFO=/tmp/gpg-hbro8r/S.gpg-agent:5131:1

Também iremos atribuir a variável GPG_TTY, que informa o programa pinentry sobre o terminal no qual ele deve desenhar sua tela de inserção de senha:

$ export GPG_TTY=$(tty)
$ echo $GPG_TTY
/dev/pts/2

Finalmente, para estimular o gpg(1) a realmente usar o agente, precisamos adicionar uma linha aqui arquivo ~/.gnupg/gpg.conf. Você pode criar esse arquivo, caso ele não exista.

use-agent

Uso

Isso feito, caso tentemos realizar qualquer operação que requeira nossa chave privada, a senha será requerida não diretamente na linha de comando, mas por nosso programa de entrada de PIN:

$ gpg --armor --sign mensagem1.txt

┌──────────────────────────────────────────────────────────┐
│ You need a passphrase to unlock the secret key for user: │
│ "Timoteo Aspargos (taspargos) <taspargos@exemplo.com.br>"│
│ 4096-bit RSA key, ID 25926609, created 2013-08-22        │
│ (main key ID 1FC2985D)                                   │
│                                                          │
│                                                          │
│ Passphrase ***__________________________________________ │
│                                                          │
│       <OK>                                 <Cancel>      │
└──────────────────────────────────────────────────────────┘

Após inserirmos a senha, a operação é realizada:

$ ls mensagem1*
mensagem1.txt
mensagem1.txt.asc

Mais tarde, se realizarmos outra opção que requeira a chave privada, veremos que a senha não é pedida:

$ gpg --armor --sign mensagem2.txt
$ ls mensagem2*
mensagem2.txt
mensagem2.txt.asc

O agente armazenou nossa chave privada em cache, tornando muito mais fácil realizar uma série de operações utilizando-a. O tempo limite padrão é de 10 minutos, mas você pode mudá-lo com as configurações default-cache-ttl e max-cache-ttl em ~/.gnupg/gpg-agent.conf. Por exemplo, para reter a chave privada por uma hora após o seu último uso, com um máximo de duas horas a partir do primeiro uso, escreveríamos:

default-cache-ttl 3600
max-cache-ttl 7200

Para que esses valores façam efeito, precisamos recarregar o agente:

$ gpg-connect-agent <<<RELOADAGENT
OK

Configuração permanente

Assim como o ssh-agent(1), um local ideal para o código de inicialização do gpg-agent(1) é um script de login como o ~/.bash_profile:

eval $(gpg-agent --daemon)

O agente será iniciado e todas as suas variáveis de ambiente serão atribuídas para todos os subshells, assim como com o ssh-agent.

Se você estiver usando uma ferramenta de entrada de PIN, você também deve adicionar o seguinte ao fim de seu script de inicialização interativo. No Linux, ele é arquivo ~/.bashrc; no Mac OS X, você talvez precise colocá-lo em ~/.bashrc.

export GPG_TTY=$(tty)

Keychain

Para gerenciar tanto o ssh-agent(1) quanto o gpg-agent(1) eficientemente, existe uma ferramenta chamada keychain(1). Ela fornece uma maneira simples de iniciar ambos os agentes com um único comando, incluindo carregar as chaves durante a inicialização. Ele também evita que qualquer um dos agentes seja executado duas vezes, identificando agentes inciados em outros locais do sistema. Muitos ambientes de desktop são configurados para iniciar um ou ambos os agentes, por isso faz sentido reutilizá-los quando possível, e nisso o keychain(1) se sobressai.

Em sistemas baseados no Debian, o programa está disponível no pacote keychain:

# apt-get install keychain

Com o keychain instalado, podemos iniciar ambos os agentes com apenas um comando em ~/.bash_profile:

eval $(keychain --eval)

Opcionalmente, podemos incluir os nomes dos arquivos das chaves SSH em ~/.ssh ou das IDs em hexadecimal das chaves do GnuPG como argumentos para o carregamento imediato das chaves privadas (incluindo a solicitação das senhas) durante a inicialização.

eval $(keychain --eval id_rsa 0x1FC2985D)

Se esse programa estiver disponível em seu sistema, ele é altamente recomendável; gerenciar seus agentes e ambientes pode ser trabalhoso, e o keychain(1) faz todo o trabalho duro, sem que você tenha de se preocupar se um agente está disponível em seu contexto em particular. Confira a página do projeto para mais informações sobre essa ferramenta.

Essa entrada é a parte 5 de 10 na série Criptografia no Linux.

Criptografia no Linux: Chaves SSH

Rafael Beraldo — Fri, 27 Sep 2013

Este é o quarto post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

O método mais comum de autenticação a um servidor OpenSSH é a inserção de sua senha na máquina remota:

tim@local:~$ ssh remoto
The authenticity of host 'remoto (192.168.0.64)' can't be established.
RSA key fingerprint is d1:35:45:a6:d1:b2:e4:08:f8:67:b1:19:fe:04:ca:1c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'remoto,192.168.0.64' (RSA) to the list of known hosts.
tim@remoto's password:

tim@remoto:~$

Esse método é apropriado para o primeiro contato com a máquina e é suportado de fábrica pelo sshd(8) na maior parte das instalações do OpenSSH.

O sshd(8) é um alvo muito comum de ataques, particularmente de ataques automáticos. Bots mal-intencionados tentam se conectar a servidores escutando a porta padrão do SSH, tcp/22, bem como algumas alternativas comuns, como a tcp/2222. Se você impor uma política de senhas altamente seguras em seu sistema, isso geralmente não é um grande problema, especialmente se apenas os usuários apropriados possuírem acesso à linha de comando, ou se você restringir as conexões SSH a certos usuários ou grupos.

Existem outras medidas para se defender contra ataques automáticos, tais como a aplicação de sistemas como o fail2ban, que rejeita clientes que realizam muitas tentativas falhas de conexão. No entanto, a maneira possivelmente mais efetiva de sabotar ataques automáticos é ignorar completamente as senhas e utilizar chaves SSH, permitindo apenas esse método de conexão às máquinas relevantes.

Como as chaves funcionam

Assim como na configuração de chaves para o GnuPG nos dois primeiros artigos desta série, pares de chaves SSH são compostos de uma chave privada e uma chave pública, dois arquivos vinculados criptograficamente. As chaves para autenticação são baseadas na ideia de que se alguém possui sua chave pública, essa pessoa é capaz de autenticá-lo ao requerer operações que podem ser realizadas apenas com a chave privada correspondente; o funcionamento é similar à assinatura criptográfica.

Esse método é efetivo pois requer uma chave pública válida para realizar a autenticação. Com uma chave longa o suficiente, torna-se efetivamente impossível que um invasor adivinhe seus detalhes de autenticação; não existe uma chave privada “comum” para adivinhar. Desse modo, os invasores teriam de testar todas as chaves públicas possíveis, o que não é nem remotamente prático.

O sshd(8) de seu sistema ainda pode ser atacado, mas caso utilize apenas a autenticação por chave pública, você pode estar confortavelmente certo de que é efetivamente impossível descobrir suas credenciais usando ataques de força bruta. Note, no entanto, que isso não necessariamente te protege contra problemas de segurança no próprio ssh(8), e você ainda deve proteger sua chave privada de ser roubada, daí a necessidade de uma senha.

Todas as informações abaixo supõe que você tenha o OpenSSH instalado tanto como cliente quanto como servidor nos sistemas apropriados. Em sistemas derivados do Debian, ambos podem ser instalados com:

# apt-get install ssh
# apt-get install openssh-server

Frequentemente, tanto o cliente quanto o servidor vêm instalados por padrão (por exemplo, no OpenBSD).

Gerando as chaves

Assim como no processo de configuração do GnuPG, começamos gerando um par de chaves na máquina a partir da qual queremos conectar, usando o ssh-keygen(1). Irei utilizar uma chave RSA de 4096 bits neste artigo, já que ela é suportada mesmo em sistemas muito antigos, e deve ser relativamente à prova de quebras no futuro, embora gerar novas chaves caso um dia o RSA se torne inseguro não seja difícil. Se você preferir usar o novo algorítimo ECDSA, que é o padrão em versões recentes do OpenSSH, os passos a seguir ainda irão funcionar. Também utilizarei um comentário para a chave como um identificador não criptografado, para distingui-la de outras chaves, caso eu tenha mais de uma. No meu caso, endereços de email funcionam bem.

$ ssh-keygen -t rsa -b 4096 -C taspargos@exemplo.com.br
Generating public/private rsa key pair.

Primeiramente, a localização onde as chaves devem ser salvadas é solicitada. Recomendo aceitar o padrão pressionando Enter, uma vez que usar a localização padrão torna os próximos poucos passos mais fáceis:

Enter file in which to save the key (/home/tim/.ssh/id_rsa):

A seguir, uma senha é solicitada, e devemos definitivamente adicionar uma para garantir que a chave não será usada caso seja um dia comprometida. As mesmas orientações para senhas aplicam nesse caso, e você deve escolher uma senha diferente:

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Isso feito, uma chave é gerada, incluindo uma representação pictórica que permite o reconhecimento das chaves com um breve olhar. Nunca achei essa representação muito útil, mas o fingerprint da chave é:

Your identification has been saved in /home/tim/.ssh/id_rsa.
Your public key has been saved in /home/tim/.ssh/id_rsa.pub.
The key fingerprint is:
d5:81:8c:eb:c6:c5:a2:b9:6a:ae:32:cc:20:bf:cf:66 tim@local
The key's randomart image is:
+--[ RSA 4096]----+
|         o ..    |
|        . o. .   |
|         o. .    |
|        o.o      |
|       =So       |
|o     o +        |
|=.     o         |
|oo..E .          |
| ooO=.           |
+-----------------+

As chaves devem estar disponíveis em ~/.ssh:

$ ls -l .ssh
-rw-------  1 tim  tim  3326 Apr  2 22:47 id_rsa
-rw-r--r--  1 tim  tim   754 Apr  2 22:47 id_rsa.pub

O arquivo id_rsa contém a chave privada criptografada, e deve ser mantido bloqueado e confidencial. O arquivo id_rsa_pub, no entanto, contém a chave pública, que pode ser distribuída com segurança, da mesma maneira que uma chave pública PGP.

Autenticação baseada em chaves

Agora, podemos nos preparar para usar a chave pública recém-gerada para a autenticação, em lugar de uma senha. Em primeiro lugar, garanta que você consegue se conectar à máquina remota com seu nome de usuário e senha:

$ ssh remoto
tim@remoto's password:

Quando você estiver conectado, garanta que o diretório ~/.ssh existe na máquina remota e que você não tenha chaves já listadas no arquivo ~/.ssh/authorized_keys, uma vez que iremos sobrescrevê-las:

$ mkdir -p ~/.ssh
$ chmod 0700 ~/.ssh

Se os passos acima funcionarem, feche a conexão (exit ou Ctrl-D) para retornar à linha de comando de sua máquina local e copie sua chave pública na máquina remota com o scp(1):

$ scp ~/.ssh/id_rsa.pub remoto:.ssh/authorized_keys
tim@remoto's password:
id_rsa.pub    100%    754    0.7KB/s    00:00

Note que existe uma ferramenta, chamada ssh-copy-ip(1) incluída nas versões mais recentes do OpenSSH que faz as operações acima automaticamente, mas é bom ter uma ideia do que ela faz por trás dos panos.

Com isso feito, sua próxima tentativa de conexão ao servidor remoto deve solicitar a senha da sua chave, ao invés de sua senha de usuário:

$ ssh remote
Enter passphrase for key '/home/tim/.ssh/id_rsa':

Vantagens

A princípio, pode parecer que você não fez nada de útil. Afinal de contas, você ainda tem que digitar algo toda vez que conecta. Do ponto de vista da segurança, a primeira vantagem desse método é que nem a sua senha de usuário, nem a senha da chave, nem sua chave privada são transmitidas ao servidor ao qual você está conectando; a autenticação é feita puramente baseado no par de chaves pública-privada, descriptografado com a senha da chave.

Assim, se a máquina ao qual você estiver conectando for comprometida, ou se o seu DNS for envenenado, ou algum ataque similar induzi-lo a conectar a um daemon SSH falso, projetado para coletar credenciais, sua chave privada e sua senha continuam seguras.

A segunda vantagem vem com o desligamento completo da autenticação por senha na máquina remota, desde que todos os seus usuários estejam usando apenas a autenticação por chave pública. Esse desligamento é feito com as seguintes configurações no arquivo sshd_config(5), geralmente encontrado em /etc/ssh/sshd_config no servidor remoto:

PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no

Reinicie o servidor SSH após aplicar essas configurações:

$ sudo /etc/init.d/ssh restart

Assim, você não será mais capaz de conectar usando senhas, apenas chaves privadas que são, como mencionado acima, efetivamente (mas não literalmente) impossíveis de quebrar usando ataques de força bruta. Para conectar ao servidor com suas credenciais, um invasor teria não apenas de saber sua senha, mas também ter acesso a sua chave privada, tornando as coisas significantemente mais difíceis.

O uso da autenticação por chave pública também permite ao sshd(8) um controle refinado sobre a autenticação, tal como quais computadores podem conectar com quais chaves, se eles podem executar túneis TCP ou X11, e (até um ponto) quais comandos podem ser executados uma vez conectado. Veja a página do manual do authorized_keys(5) para dar uma olhada em alguns exemplos.

Finalmente, existe uma importante vantagem de usabilidade ao usar chaves SSH para a autenticação usando os agentes, que iremos discutir no próximo artigo.

Chaves do servidor e fingerprints

Uma conexão SSH deve ser, idealmente, um processo de autenticação de duas vias. Assim como o servidor ao qual você está se conectando precisa estar certo da sua identidade, você precisa estar certo de que o servidor ao qual você está se conectando é o esperado. Com truques como tunnelling, firewalls, envenenamento de DNS, NAT, sistemas hackeados, entre outros, é apropriado ter cuidado de que você está se conectando aos sistemas certos. É aí que entra o sistema de chaves de servidor do OpenSSH.

A primeira vez que você se conecta a um novo servidor, você deve ver uma mensagem como essa:

$ ssh novoremoto
The authenticity of host 'novoremoto (192.168.0.65)' can't be established.
RSA key fingerprint is f4:4b:f4:8c:c5:50:f6:c8:d3:b2:e9:14:68:86:b5:7b.
Are you sure you want to continue connecting (yes/no)?

Muitos administrados as desligam, mas não faça isso! Elas são muito importantes.

A fingerprint de uma chave é um hash relativamente curto da chave de servidor usada pelo OpenSSH naquela máquina. Ela é verificada pelo seu cliente SSH e não pode ser facilmente falsificada. Se você está se conectando a um novo servidor, é apropriado checar se a fingerprint da chave de servidor corresponde àquela que você vê na primeira tentativa de conexão, ou pedir ao administrador do sistema para que ele o faça.

A fingerprint de chave do servidor pode ser checada no servidor SSH executando ssh-keygen(1):

$ ssh-keygen -lf /etc/ssh/ssh_host_rsa_key
2048 f4:4b:f4:8c:c5:50:f6:c8:d3:b2:e9:14:68:86:b5:7b /etc/ssh/ssh_host_rsa_key.pub (RSA)

Se você desejar, é possível checar a chave sem realizar uma tentativa de conexão com um comando similar no cliente:

$ ssh-keygen -lF novoremoto
# Host 192.168.0.65 found: line 1 type RSA
2048 f4:4b:f4:8c:c5:50:f6:c8:d3:b2:e9:14:68:86:b5:7b novoremoto (RSA)

Se você não consegue checar a chave de servidor, peça ao administrador que a envie num canal seguro e confiável, como em pessoa ou via uma mensagem assinada usando o PGP. Se a fingerprint SSH delimitada por dois pontos não for exatamente a mesma, você pode ser vítima de alguém tentando fraudar sua conexão!

Essa prática pode ser exagerada para máquinas virtuais novas e provavelmente máquinas novas numa LAN confiável, mas para máquina acessadas através da internet pública, ela é muito prudente.

De maneira similar, o ssh(1), por padrão, mantém um registro das chaves de servidor dos computadores aos quais você já se conectou. Por esse motivo, quando uma chave de servidor diferente é apresentada numa tentativa de conexão, o programa mostra um aviso:

$ ssh novoremoto
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d7:06:51:16:80:f6:32:b4:35:7c:53:8d:5a:49:69:ec
Please contact your system administrator.
Add correct host key in /home/tim/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/tim/.ssh/known_hosts:22
RSA host key for novoremoto has changed and you have requested strict checking.

Novamente, esse aviso é algo que usuários do ssh(1) frequentemente desligam, o que é bastante arriscado, especialmente se você estiver usando a autenticação por senha e, consequentemente, pode enviar sua senha a um servidor mal-intencionado ou comprometido!

Essa entrada é a parte 4 de 10 na série Criptografia no Linux.

Criptografia no Linux: Usando o GnuPG

Rafael Beraldo — Mon, 23 Sep 2013

Este é o terceiro post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

Com nossas chaves privada e públicas criadas e guardadas, podemos começar a usar alguns dos recursos do GnuPG para assinar, verificar, criptografar e descriptografar arquivos e mensagens para distribuição em canais não confiáveis, como a internet.

Assinando uma mensagem ou arquivo de texto

Começaremos assinando um simples arquivo de texto, usando a opção --clearsign. Ela inclui a assinatura na mensagem, o que significa que podemos distribuí-la para outras pessoas lerem. Esse é o conteúdo de mensagem.txt:

Essa é uma mensagem pública de Timoteo Aspargos.

Assinamos a mensagem com nossa nova chave privada da seguinte maneira:

$ gpg --clearsign mensagem.txt

Nossa senha da chave privada é solicitada:

You need a passphrase to unlock the secret key for
user: "Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>"
4096-bit RSA key, ID 1FC2985D, created 2013-08-22

Após provê-la, o arquivo mensagem.txt.asc é criado, com seções do PGP e uma assinatura ASCII em texto plano:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Essa é uma mensagem pública de Timoteo Aspargos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQIcBAEBCAAGBQJSFqZjAAoJENq55KAfwphdJcYQAM1xBX1fU91rSKBH05MDpKNp
l+y834JPR4P1Zwp6pK0BMXBxfL+xk4V7DAMXOmw6iFpGsxhW/f3ehnIPghH5PkLs
FbdHTWFrxuGBge0B+f7AwAaVabvbcgSL3H7F3QxxXcrdWCajlbX+zKx5o+DlKYMC
uQK0yczfUS0WBTnRMFb//NW7HrS9DU6hydAjNV3+m/NJXvOmh5H2H6dvJM8hxfPR
MdmEYJ8gHPTXIwd+Xtt+0VlwPLOMD76S3S3rpaC5taM7qbxvya/xmvlxDqRIo3sP
Az1552h86HPJEjDg2j5sF6YCvVl5Aq2dJfPqVy4ZuB7wyaKhk2JIFgIs/M4VFptH
AvJaE5FcMdAhz3eWHdCIqvSuTjmf/ZXn8BlbMugkSitKzbUvxVGoPv/gYzMKJhIl
SFCeyJxGl1t6tKYK3iXh+Ady4AzscjYXcfK9yCPtkITPQyRYN51qBDNWR55Raznf
SybLYbRRdiZz7XuiUozy+CjvduEjw3bmFFOwpE9HCkQeyu+PPf3PszbhFcm8Wav2
OM3fmLhCEcFnIh/mIn/SveTE8Br9tyHJpSmk11sWjPFkT+fAKDTq5YeIZHXVk2Av
X6P8Lxenfuj0+Grk8DEZnA3bTmNP52+kJ0v2UrdjIcheigPXrY5pY0iBOdG+/S1k
MUN9XbXKNxrx4CAwDKXY
=Lmvn
-----END PGP SIGNATURE-----

Note que a mensagem em si é nitidamente legível; ela não está criptografada, apenas verificada como escrita por uma pessoa em particular e não alterada desde então.

Agora, qualquer um que tenha sua chave pública no chaveiro (como nós mesmos) pode verificar que ela foi realmente escrita por nós:

$ gpg --verify mensagem.txt.asc
gpg: Signature made Qui 22 Ago 2013 21:01:39 BRT using RSA key ID 1FC2985D
gpg: Good signature from "Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>"

Se alguém adulterar a mensagem, mesmo que remova apenas um ponto final de uma frase, a verificação falhará, sugerindo que a mensagem foi alterada:

$ gpg --verify mensagem.txt.asc
gpg: Signature made Qui 22 Ago 2013 21:01:39 BRT using RSA key ID 1FC2985D
gpg: BAD signature from "Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>"

Assinando e verificando arquivos binários

Para todos os outros arquivos, provavelmente teremos de criar um arquivo de assinatura separado com uma assinatura avulsa:

$ gpg --armor --detach-sign arquivo.tar.gz

O comando produz um arquivo chamado arquivo.tar.gz.asc no mesmo diretório, contendo a assinatura. Usamos --armor para deixar a assinatura em ASCII, o que a torna mais longa porém mais fácil para a distribuição online.

Nesse caso, tanto o arquivo quanto a assinatura são necessários para a verificação; coloque o arquivo de assinatura em primeiro lugar quando for checar, dessa maneira:

$ gpg --verify arquivo.tar.gz.asc arquivo.tar.gz

Você pode usar esse método para verificar software baixado de fontes confiáveis, como do time de desenvolvimento do Apache HTTPD. Primeiramente, faríamos o download e importaríamos todas as chaves públicas a partir da URL que o time indica:

$ wget http://www.apache.org/dist/httpd/KEYS
$ gpg --import KEYS

Poderíamos, então, baixar uma versão do Apache HTTPD, juntamente de sua chave, de um espelho arbitrário:

$ wget http://www.example.com/apache/httpd/httpd-2.4.4.tar.gz
$ wget https://www.apache.org/dist/httpd/httpd-2.4.4.tar.gz.asc

Podemos, então, usar a chave e a assinatura para verificar que essa é uma cópia não comprometida do arquivo original assinado pelos desenvolvedores:

$ gpg --verify httpd-2.4.4.tar.gz.asc httpd-2.4.4.tar.gz
gpg: Signature made Tue 19 Feb 2013 09:28:39 NZDT using RSA key ID 791485A8
gpg: Good signature from "Jim Jagielski (Release Signing Key) <jim@apache.org>"
gpg:                 aka "Jim Jagielski <jim@jaguNET.com>"
gpg:                 aka "Jim Jagielski <jim@jimjag.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: A93D 62EC C3C8 EA12 DB22  0EC9 34EA 76E6 7914 85A8

Note que a saída do gpg adverte que essa ainda não é uma garantia perfeita de que a versão de fato veio de Jim Jaielski, porque nunca o encontramos e não podemos absolutamente, definitivamente dizer que essa é sua chave pública. No entanto, ao buscá-lo nos servidores públicos de chaves, podemos ver que muitos outros dos desenvolvedores do Apache assinaram sua chave, o que parece promissor. Mas nós sabemos quem eles são?

Quando baixamos de espelhos, apesar da falta de certeza absoluta, essa verificação é muito melhor (e torna mais difícil explorar falhas de segurança) do que simplesmente baixar sem validar ou executar uma soma de verificação, dado que a assinatura e o arquivo KEYS foi baixado do próprio site da Apache.

Você terá de decidir por si só qual o grau de certeza necessário para confiar que a chave pública de alguém realmente corresponde a essa pessoa. Esse grau de certeza pode se estender até o ponto de combinar um encontro com essa pessoa, verificando sua identidade com documentos de identificação expedidos pelo governo!

Criptografando um arquivo

Podemos criptografar um arquivo de maneira que apenas as pessoas nomeadas possam descriptografá-lo e lê-lo. Nesse caso, devemos criptografá-lo não com nossa própria chave privada, mas com a chave pública do destinatário. Dessa maneira, apenas ele será capaz de descriptografar o arquivo usando sua chave privada.

Esse é o conteúdo do arquivo mensagem-secreta.txt:

Essa é uma mensagem secreta de Timoteo Aspargos.

Agora, precisamos de pelo menos um destinatário. Digamos que essa mensagem é destinada ao meu amigo, João Público. Ele me entregou sua chave pública, em pessoa, em um arquivo chamado joao-publico.asc num pendrive; ele trouxe até mesmo a sua carta de motorista e sua certidão de nascimento (o que é estranho, porque o conheço desde que tinha quatro anos de idade).

Para começar, irei importar sua chave para meu chaveiro:

$ gpg --import joao-publico.asc
gpg: key 695195A5: public key "João Público (Chave principal) <joaopublico@exemplo.com.br>" imported
gpg: Número total processado: 1
gpg:               imported: 1  (RSA: 1)

Agora podemos criptografar a mensagem para que apenas o João leia. Gosto de usar o código hexadecimal de oito dígitos para o --recipient, para ter certeza de que selecionei a pessoa certa. Você pode ver esse código na saída acima, ou na saída de gpg --list-keys.

$ gpg --armor --recipient 695195A5 --encrypt mensagem-secreta.txt

A mensagem secreta é gravada em mensagem-secreta.txt.asc.

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)

hQEMAxiBb8eWSupuAQgAgOUQvqbTh60N6RQhDtP/bY9l+gjm4Grx5XcuhgQqK6pn
YtyPTKcpHdPK679lhbv0vE0RYe7pL+nBOngU1hCQYuGbRDZDxIXTIZW/rBvXbtHA
jgeSxrquad2totfh2nc7upePVCqXncPrLraJyDJBLLMrBHVvmOZymDabJbemOFuq
A/NbcmT3+osptvaEPFdlbgAW+J3vGxXMuQQYkT8GSnuutfEhZRb7SEL1ktaXwaMc
AA6NAan5ak7nCyDDHhDSDFMS9SQQHd8TDvQPF6OzRXlq26EOFD8HvlbDcgc51lbS
+N5nWaHM/CiuPh9dIOEV0H4Y8WDBdgkxp6kXKQfqb9JzAdwQ047r82SJAA7MSqCS
HRVtCRf5SNM12HqTRzF9XXum4uG+HXT6Bpy+K/lYpLgmHcHoUVKh8c2OcGaCHWQh
UC9B+aaThKdkxUfD/9tVIRmugjutgj7KdtDTGm+qLeCoJqp6HK5z5SX8Ha+P6/P5
hxinyw==
=kqUG
-----END PGP MESSAGE-----

Note que até mesmo eu não posso lê-la, porque não me adicionei na lista de destinatários e não tenho acesso à chave privada de João:

tim@timbox:~$ gpg --decrypt mensagem-secreta.txt.asc
gpg: encrypted with 2048-bit RSA key, ID 964AEA6E, created 2013-03-10
    "João Público (Chave principal) <joaopublico@exemplo.com.br>"
    gpg: descriptografia falhou: chave secreta não disponível

No entanto, no computador do João, usando sua chave privada, ele pode descriptografar e ler o arquivo:

joao@joaobox:~$ gpg --decrypt mensagem-secreta.txt.asc
gpg: encrypted with 2048-bit RSA key, ID 964AEA6E, created 2013-03-10
    "João Público (Chave principal) <joaopublico@exemplo.com.br>"
Essa é uma mensagem secreta de Timoteo Aspargos.

Se eu quisesse ter certeza de que eu poderia ler a mensagem também, adicionaria minha própria chave pública para me identificar como um destinatário quando criptografasse a mensagem. Assim, ambos poderíamos ler a mensagem com nossas chaves privadas (independentemente um do outro).

$ gpg --recipient 695195A5 --recipient 1FC2985D \
    --armor --encrypt mensagem-secreta.txt

Só para ser completos, podemos também assinar a mensagem para provar que ela veio de nós:

$ gpg --recipient 695195A5 --recipient 1FC2985D \
    --armor --sign --encrypt mensagem-secreta.txt

Quando o João rodar a opção --decrypt, o gpg irá automaticamente verificar a assinatura, desde que ele tenha minha chave pública em seu chaveiro:

$ gpg --decrypt mensagem-secreta.txt.asc
gpg: encrypted with 2048-bit RSA key, ID 964AEA6E, created 2013-03-10
    "João Público (Chave principal) <joaopublico@exemplo.com.br>"
gpg: encrypted with 4096-bit RSA key, ID 1FC2985D, created 2013-08-22
    "Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>"
Essa é uma mensagem secreta de Timoteo Aspargos.
gpg: Signature made Qui 22 Ago 2013 17:23:20 BRT using RSA key ID 1FC2985D
gpg: Good signature from "Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>"

Essas são todas as funções básicas do GnuPG que são úteis para a maior parte das pessoas. Nós não consideramos nesse artigo o envio de nossas chaves a servidores públicos ou a participação em uma rede de confiança. Você deve procurar mais informações sobre esses assuntos apenas quanto que estiver feliz com a configuração e funcionamento de suas chaves e estiver pronto para publicar suas chaves para uso público.

Essa entrada é a parte 3 de 10 na série Criptografia no Linux.

Criptografia no Linux: Chaves do GnuPG

Rafael Beraldo — Fri, 20 Sep 2013

Este é o segundo post de uma série de dez posts traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

Para a lista de posts, veja a introdução.

Muitas ferramentas que usam criptografia no Linux e na internet centram-se no padrão de software Pretty Good Privacy (OpenPGP). O GNU Privacy Guard (GnuPG ou GPG) é uma implementação em software livre popular desse padrão.

No Debian, é possível instalar o GnuPG e sua interface, o gpg(1), da seguinte maneira:

# apt-get install gnupg

Você pode fazer muitas coisas legais com o GPG, mas ele se resume a quatro ideias centrais:

A geração de pares de chaves, ou seja, pares de arquivos gerados aleatoriamente e vinculados matematicamente, um dos quais deve ser mantido permanentemente secreto (a chave privada) e um que deve ser publicado (a chave pública). Essa é a base da criptografia de chave assimétrica.
O gerenciamento de chaves, tanto suas chaves públicas quanto as privadas, além das chaves públicas de outras pessoas, para que você possa verificar as suas mensagens e arquivos, ou criptografá-los para que apenas elas possam ler. Isso pode incluir a publicação de sua chave pública em servidores de chaves online e fazer com que outras pessoas assinem sua chave para confirmar que ela realmente é sua.
A assinatura de arquivos e mensagens com sua chave privada, para que outras pessoas possam verificar que um arquivo ou mensagem foi criado ou assinado por você, e não foi editado durante a transmissão por canais não-confiáveis, como a internet. A mensagem em si ainda é legível por todos.
A criptografia de arquivos e mensagens com as chaves públicas de outras pessoas, para que apenas elas possam, com suas chaves privadas, descriptografar e ler a mensagem. Você também pode assinar essas mensagens com sua própria chave privada para que elas possam verificar que ela foi enviada por você.

Iremos passar pelos fundamentais de cada uma dessas ideias. Não nos preocuparemos demais com a matemática ou os algorítimos por trás dessas operações; o artigo da Wikipédia sobre a criptografia de chave assimétrica explica esse aspecto muito bem para aqueles curiosos por mais detalhes.

Gerando um par de chaves

Vamos começar gerando um par de chaves RSA de 4096 bits, que deve ser mais do que o suficiente para quase todos no momento da escrita deste artigo. Iremos seguir algumas das melhores práticas recomendadas pelos desenvolvedores do Debian.

O ideal é realizar essas operações num computador privado e atualizado uma vez que é mais fácil gerar entropia dessa maneira. Isso ainda é possível num servidor acessível apenas por SSH, mas você pode ter que recorrer a métodos menos sãos, criptograficamente falando, para gerar a aleatoriedade apropriada.

Crie ou edite o arquivo ~/.gnupg/gpg.conf no seu sistema, e adicione as seguintes linhas:

personal-digest-preferences SHA256
cert-digest-algo SHA256
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Essas linhas informarão o GnuPG para usar o algorítimo de hashing SHA256 para assinaturas, que é criptograficamente mais forte, em preferência ao algorítimo SHA1, há muito tempo quebrado.

Isso feito, podemos começar a gerar algumas chaves:

$ gpg --gen-key

Você será solicitado a escolher o tipo de par de chaves que deseja. O padrão deve ser RSA e RSA, o que significa que iremos gerar uma chave mestra para a assinatura, e uma subchave para criptografia:

Por favor selecione o tipo de chave desejado:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (apenas assinatura)
(4) RSA (apenas assinatura)
Sua opção? 1

Para o comprimento da chave, escolha o máximo (RSA 4096 bits):

What keysize do you want? (2048) 4096
O tamanho de chave pedido é 4096 bits

A data de expiração cabe a você: se está apenas brincando com o GnuPG no momento, sinta-se livre para configurar uma validade curta. No entanto, se você pretende usar o GnuPG por bastante tempo e está certo de que pode manter sua chave indefinidamente segura, sinta-se à vontade para configurá-la para nunca expirar, como farei aqui:

Por favor especifique por quanto tempo a chave deve ser válida.
0 = chave não expira
<n>  = chave expira em n dias
<n>w = chave expira em n semanas
<n>m = chave expira em n meses
<n>y = chave expira em n anos
A chave é valida por? (0) 0

A seguir, algumas informações básicas são solicitadas para nomear a chave. Em quase todas as circunstâncias você deveria usar seu nome real, já que sem um meio de verificar sua identidade no mundo real, as chaves públicas são muito menos úteis a longo prazo. Quanto ao comentário, você pode incluir o propósito da chave, seus apelidos públicos ou qualquer outra informação relevante para a chave:

Nome completo: Timoteo Aspargos
Endereço de correio eletrônico: taspargos@exemplo.com.br
Comentário: Apenas para teste
Você selecionou este identificador de usuário:
  "Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>"

Muda (N)ome, (C)omentário, (E)ndereço ou (O)k/(S)air? O

Senha da chave

A seguir, o programa pede uma senha para criptografar a chave. Assim, se ela algum dia cair nas mãos erradas, ninguém poderá usá-la sem conhecer a senha.

Você precisa de uma frase secreta para proteger sua chave.

Escolha uma sequência aleatória de palavras, ou possivelmente uma sentença única que você pode memorizar facilmente em qualquer língua. Quanto maior, melhor. Não escolha nada que possa ser adivinhado na prática, como provérbios ou frases de filmes. Você também terá de lembrar exatamente como digitou a senha; recomendo utilizar todas as letras minúsculas e sem pontuação. A Wikipédia tem algumas orientações aqui.

Você precisará digitar a senha duas vezes para confirmá-la, e o programa não irá mostrá-la no terminal, como se você estivesse digitando uma senha.

Geração de entropia

Finalmente, o sistema irá pedir que geremos alguma entropia:

Precisamos gerar muitos bytes aleatórios. É uma boa idéia realizar outra
atividade (digitar no teclado, mover o mouse, usar os discos) durante a
geração dos números primos; isso dá ao gerador de números aleatórios
uma chance melhor de conseguir entropia suficiente.

Esse passo é necessário para que o computador gere informação aleatória o suficiente para assegurar que a chave privada que está sendo gerada não possa ser viavelmente reproduzida. Mover o mouse e usar o teclado é o ideal, mas gerar qualquer tipo de atividade no hardware (incluindo girar os discos) deve servir. Rodar operações dispendiosas com o find(1) num sistema de arquivos (com conteúdos que não possam ser razoavelmente preditos ou adivinhados) também ajuda.

Esse passo se beneficia de sua paciência. Você pode encontrar discussões online sobre forçar o uso do gerador de números pseudo-aleatórios /dev/urandom ao invés disso, usado uma ferramenta como o rngd(1). Isso definitivamente acelera o processo, mas se você irá usar a sua chave para qualquer atividade séria, recomendo realmente interagir com o computador usando o ruído do hardware para alimentar a aleatoriedade adequadamente, se puder.

Quando entropia o suficiente é lida e a chave terminar de ser gerada, alguns detalhes da sua chave mestra e sua subchave serão apresentados, e as chaves privadas e públicas para cada uma serão automaticamente adicionadas ao seu chaveiro para uso posterior:

gpg: /home/tim/.gnupg/trustdb.gpg: banco de dados de confiabilidade criado
gpg: key 1FC2985D marked as ultimately trusted
chaves pública e privada criadas e assinadas.
gpg: a verificar a base de dados de confiança
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   3  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1  valid:   1  signed:   0  trust: 1-, 0q, 0n, 0m, 0f, 0u
pub   4096R/1FC2985D 2013-08-22
      Key fingerprint = A577 2F62 9827 BCF1 D03C  0817 DAB9 E4A0 1FC2 985D
      uid                  Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>
      sub   4096R/E458D7E5 2013-08-22

Gerenciando chaves

Com isso feito, nossas próprias chaves estão adicionadas ao chaveiro privado e público:

$  gpg --list-secret-keys 
/home/tim/.gnupg/secring.gpg
-----------------------------------
sec   4096R/1FC2985D 2013-08-22
uid                  Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>
ssb   4096R/E458D7E5 2013-08-22

$  gpg --list-public-keys 
/home/tim/.gnupg/pubring.gpg
-----------------------------------
pub   4096R/1FC2985D 2013-08-22
uid                  Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>
sub   4096R/E458D7E5 2013-08-22

O diretório ~/.gnupg contém as chaves gerenciadas. É muito, mas muito importante manter esse diretório privado e fazer o seu backup seguramente, preferivelmente em uma mídia removível que você possa manter em algum local fisicamente seguro. Não o perca!

Na maior parte dos contextos no GnuPG, você pode se referir à chave pelo nome do seu dono ou pela sua identificação hexadecimal de oito dígitos. Eu prefiro o último método. Nesse caso, a identificação curta da minha chave principal é 1FC2985D. Embora você não deva usá-la para fazer nenhum tipo de verificação, ela é suficientemente única para identificar uma chave específica no seu chaveiro.

Por exemplo, se você desejar enviar uma cópia de sua chave púbica a alguém, uma maneira amigável de fazê-lo é exportá-la no formato ASCII com a opção --armor, fornecendo a identificação curta da chave apropriada:

$ gpg --armor --export 1FC2985D > tim-aspargos.public.asc

Embora você possa exportar chaves privadas da mesma maneira, usando a opção --export-secret-key, você nunca, nunca mesmo, deve fornecer sua chave privada a ninguém, então ela não deve ser necessária.

O certificado de revogação

Depois de gerar suas chaves, você deve gerar um certificado de revogação.

gpg --output revoke.asc --gen-revoke 1FC2985D 

sec  4096R/1FC2985D 2013-08-22 Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
0 = Nenhum motivo especificado
1 = A chave foi comprometida
2 = A chave foi substituída
3 = A chave já não é utilizada
Q = Cancel
(Probably you want to select 1 here)
Sua decisão? 1
Enter an optional description; end it with an empty line:
> 
Reason for revocation: A chave foi comprometida
(No description given)
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "Timoteo Aspargos (Apenas para teste) <taspargos@exemplo.com.br>"
4096-bit RSA key, ID 1FC2985D, created 2013-08-22

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

Você deve guardar o arquivo resultante, revoke.asc, em algum local seguro. Você pode usar esse certificado para revogar sua chave mais tarde, caso a chave privada seja comprometida, para que as pessoas saibam que a chave não é mais confiável nem pode ser usada. Você pode até mesmo imprimir e manter uma cópia impressa, como o gpg sugere.

Com a configuração acima concluída, podemos proceder com o uso básico do GnupG, como discutido no próximo artigo.

Subchaves

Na saída de ambos os comandos, é possível notar que na verdade temos duas chaves privadas e duas chaves públicas. A linha sub se refere à subchave de criptografia, gerada automaticamente para você. A chave mestra é usada para a assinatura criptográfica, e a subchave para a encriptação; é assim que o GnuPG opera por padrão com pares de chaves RSA.

Para mais segurança, pode ser apropriado fisicamente mover a chave mestra do seu computador para outro local e usar uma segunda subchave gerada para assinar arquivos. Isso é desejável pois lhe permite manter sua chave mestra segura em alguma mídia removível (preferivelmente com um backup) e não carregada no seu computador principal, caso você seja comprometido.

Dessa maneira, é possível assinar e criptografar arquivos normalmente com sua subchave de assinatura e sua subchave de criptografia. Se essas chaves forem algum dia comprometidas, você pode simplesmente revogá-las e gerar novas com sua chave mestra, que não foi comprometida. Além disso, todos aqueles que já assinaram ou de outra maneira demonstraram sua confiança em sua chave mestra não terão de fazê-lo novamente.

Para detalhes sobre como efetuar esse procedimento, sugiro a leitura desse artigo na Debian Wiki sobre gerenciamento de subchaves. Elas não são, no entanto, necessárias para efetuar operações básicas com o GPG.

Essa entrada é a parte 2 de 10 na série Criptografia no Linux.

rsync options

Rafael Beraldo — Thu, 19 Sep 2013

rsync is a wonderful program. Three days ago, I forgot to use it and used scp instead to transfer the files of this blog from my netbook to the server, destroying my piwik installation in the process. In my defense, it was 7 am and I was in a hurry to upload the first post on the Linux Crypto series.

I learned my lesson and used rsync to transfer the subsequent changes. It has so many options, though, that I’m never sure what to use. To help me with that, I wrote them down on my Moleskine notebook and came up with a mnemonics. Here’s what I use:

rsync -zarc source destination

where -z is --compress, -a is --archive, -r is --recursive and -c is --checksum. According to man rsync, --archive “ensures that symbolic links, devices, attributes, permissions, ownerships, etc. are preserved in the transfer”. It is a shorthand for -rLptgoD!

The mnemonics is pretty simple:

zombies are really careless

Criptografia no Linux: Introdução

Rafael Beraldo — Mon, 16 Sep 2013

Essa é uma série de posts que será publicada em dez partes, traduzindo o original de Tom Ryder, Linux Crypto. Essa série está sob uma licença Creative Commons 3.0.

A criptografia para a autenticação e encriptação é um campo complexo e que muda com frequência e, para alguém novo no assunto, pode ser difícil saber onde começar. Se você é um usuário de Linux confortável com o terminal, mas não tem familiaridade com as ferramentas de criptografia disponíveis em sistemas operacionais abertos estilo UNIX, essa é uma série de posts que visa ajudá-lo a configurar algumas ferramentas básicas que permitirão manter suas informações seguras, autenticar convenientemente e seguramente a servidores remotos e a trabalhar com arquivos online assinados digitalmente e criptografados.

Trabalharei com o Debian GNU/Linux, mas a maior parte dessas ferramentas deve se adaptar bem em outros sistemas abertos no estilo UNIX, incluindo o BSD. Aviso que não sou um expert em algorítimos criptográficos ou em segurança de chaves. Se você é, e encontrar algum erro ou problema de segurança em qualquer uma de minhas explicações ou sugestões, por favor, avise-me que irei corrigi-los e lhe darei o crédito.

Cobrirei os seguintes tópicos:

Se você já conhece sobre um tópico específico, sinta-se livre para pular para os outros artigos.

Iterando por itens em listas do Python

Rafael Beraldo — Wed, 20 Feb 2013

Essa é uma pequena dica para os que são, como eu, newbies em Python.

Para resolver alguns exercícios no Codecademy que envolviam operações nos itens de algumas listas, eu costumava criar uma variável count e atribuir a ela o valor 0. Para acessar cada item das listas, eu utilizava o valor de count para acessar o índice equivalente. Ao final da operação, eu aumentava o valor da variável em 1 e, enquanto (while) o valor de count fosse menor do que o número de itens de lista (determinado por len(sequence)), essa operação seria repetida.

Para vocês entenderem melhor, aqui vai o código para uma função que recebe uma lista como argumento (sequence), remove todos os números ímpares e retorna uma nova lista (out_sequence):

def purify(sequence):
  count = 0
  out_sequence = []
  while count < len(sequence):
    if sequence[count] % 2 == 0:
      out_sequence.append(sequence[count])
    count += 1
  return out_sequence

Uma maneira mais fácil

Para aprender mais maneiras de conseguir o mesmo resultado, li o código de outros usuários do Codecademy e descobri que é possível utilizar um loop for:

def purify(sequence):
  out_sequence = []
  for i in sequence:
    if i % 2 == 0:
      out_sequence.append(i)
  return out_sequence

O loop for itera por cada item (i) da lista sequence e, se i for um número par (ou seja, divisível por 2), ele será adicionado à lista out_sequence. Muito mais elegante, devo admitir!

abnTeX2

Rafael Beraldo — Thu, 07 Feb 2013

Como estudante em uma universidade brasileira, sou eternamente grato ao LaTeX pela ajuda com a tipografia dos meus trabalhos e relatórios e ao (finado) projeto abnTeX pela ajuda com as normas para trabalhos científicos da ABNT.

O projeto abnTeX (ABsurd Norms for TeX) não recebia contribuições ao código desde 2006, no entanto, o que o tornava desatualizado em relação às normas da ABNT. Além disso, o código tinha alguns bugs e incompatibilidades com outros pacotes.

Por isso, foi com grande felicidade que descobri o projeto abnTeX2, liderado pelo Lauro César, da UnB. O novo pacote para LaTeX é baseado na classe memoir, a minha preferida, e uma das classes mais completas para o LaTeX.

Para instalar o pacote no Arch Linux usando o yaourt, rode:

yaourt -S abntex2

Para mais informações sobre como instalar na sua distro, consulte a wiki do projeto abnTeX2.

Li brevemente o manual do pacote, que é bastante completo, e notei algumas mudanças em relação ao antigo pacote abntex. Muitas novidades que eu esperava estão lá, incluindo suporte ao XeLaTeX (e fontspec), ambientes para errata e ficha catalográfica e a nova posição para rótulos e legendas.

Irei testar o pacote durante esse ano letivo para tipografar trabalhos meus e de colegas. Posso até, eventualmente, publicar aqui um pequeno tutorial sobre o pacote, incluindo hacks que descobrir ou desenvolver.

Happy LaTeXing!

Happy New Year

Rafael Beraldo — Fri, 04 Jan 2013

As 3179 YOLD (or 2013) begins, I felt like writing a happy new year post. Happy new year!

Blogging-wise, 2012 was a very good year. I gave Cabaladadá a fresh start and felt generally happier writing for it. I managed to write twelve posts — a small number, but writing a lot wasn’t in my plans anyway. I wanted to write at least once a month, and I got closer than ever.

But I plan to write more. Over the years, as blogs blossomed and were adopted by all kinds of journalists and specialists, blogging became a very professional activity. It doesn’t have to be tiresome for me, though, and I don’t have to demand from myself posts with content and quality that’ll make people want read Cabaladadá. That simply means my posts should be about whatever is bugging me at the moment, or whatever I’m doing with my life, the Universe and everything else. I’d like to write more on cooking and using GNU/Linux, for example. I often discover programs, fonts, podcasts, books and many other things that might be interesting for my fellow hackers and nerds.

This new year will be full of new and exciting challenges. I taught English for one year and a half, and now I’m looking for a new job. Maybe I’ll end up translating or giving English classes again, but I’ll try my best to get a job related to computers in general, be it deploying GNU/Linux systems, taking care of servers, teaching or coding in HTML. Although I currently study languages and literature, I finally accepted that my real passion lies in everything technology (actually, I find computational linguistics quite interesting), so it makes sense to start working in a related area.

My girlfriend and I wrote down some new year resolutions. Here are mine:

Finish college;
Get a new job;
Save about 500 reais;
Be less grumpy;
Cook more;
Finish started projects.

That’s not too ambitious, but still a number of good accomplishments to brag about in the future.

Here’s hoping I’ll be seeing you guys more often! Once more, happy new year!

News

Rafael Beraldo — Mon, 05 Nov 2012

I’ve just uploaded the source code for this blog to GitHub, where I keep the fews lines of code I write and some stuff written in LaTeX. So, if you were ever wondering how I went about implementing Cabaladadá using Jekyll, go and have a check!

I’m also working on internationalizing Cabaladadá. Sometimes (like now), I’d like to write a post in both English and Brazilian Portuguese but I see no need to create separate pages for each language. The solution I’m working on is rather simple: I’ll just include a link to the translation of a post beneath its title on the front page and on the post page, before the text begins.

I’m having some trouble figuring out where to put the translations and how to tell Jekyll not to include them on the main page.

Oh, and there’ll soon be a post on Vimperator and Firefox!

RSS

Rafael Beraldo — Fri, 19 Oct 2012

Thanks to citizenparker’s Incrediblog source code, I was able to add an RSS feed to this very blog. Subscribe using your favorite RSS reader and I promise you’ll never miss a rant!

GNU MediaGlobin

Rafael Beraldo — Wed, 17 Oct 2012

Pelo blog da Free Software Foundation (FSF) conheci o fantástico MediaGlobin, um sistema livre de compartilhamento de imagens, vídeos e áudio. Do site do projeto:

O GNU MediaGlobin é um sistema livre de publicação de mídia para imagens, vídeo e áudio. Estamos planejando suporte a descentralização e grande extensibilidade. Pense nele como um substituto para sistemas como o Flickr, o YouTube ou o SoundCloud que qualquer um pode executar.

Suporte o projeto e ganhe recompensas!

A página de doações tem um ótimo vídeo que discute o que o projeto é, mas também algumas ideias sobre como a Internet funciona. Por uma questão de design, a Internet é descentralizada; por isso, se um computador perde sua conexão, os outros computadores ainda conseguem se comunicar. Por outro lado, muitas das aplicações que usamos, como o YouTube ou o Flickr, são centralizadas. Mas o que aconteceria com todas as suas fotos se o Flickr sumisse? E com os seus vídeos, se o YouTube deixasse de existir?

O MediaGlobin parece ser um projeto bastante sólido, que surgiu para preencher um problema real cuja tendência é crescer. Para os usuários da Internet, a centralização significa maior poder em um só lugar. Com as legislações que vêm sido aceitas ao redor do mundo, como na França, essas ferramentas descentralizadas são cada vez mais bem-vindas.

Mas não se deixe enganar pela palavra “descentralizado”. Como explicado no vídeo acima, o MediaGlobin será descentralizado como o serviço de email é atualmente, ou seja, todos podemos trocar mensagens como se estivéssemos na mesma rede, mesmo que as pessoas usem serviços de email diferentes. Assim, embora o conteúdo possa estar espalhado pela rede, poderemos acessá-lo como se estivesse todo num mesmo lugar.

Iniciativas como o GNU MediaGlobin são fundamentais para o futuro da Internet. Como muitas coisas no mundo real, a tendência parece ser a descentralização e divisão dos recursos. A educação e uso do software livre tem um papel central nesse futuro e é legal saber que já estamos nos preparando.

Snippets

Rafael Beraldo — Sun, 14 Oct 2012

Eu nunca fui um grande fã de modificar o funcionamento dos programas por meio de plugins (especialmente porque isso pode levar a problemas de performance, além de bugs inesperados), então nunca me impressionei muito com a capacidade do vim de usar plugins. Recentemente ouvi um podcast na Hacker Public Radio sobre plugins para o vim e resolvi dar uma chance a um plugin chamado snipMate.

Eu não era um grande fã de plugins. O snipMate é realmente uma mão na roda, especialmente pra quem usa muito LaTeX, como eu. Mas vamos direto ao assunto.

Instalando o snipMate

A melhor forma de instalar o snipMate é clonando o repositório do GitHub:

git clone git://github.com/msanders/snipmate.vim.git
cd snipmate.vim
cp -R * ~/.vim

Isso irá copiar os arquivos README.markdown e plugin-info.txt, então não se esqueça de deletá-los. Pronto, o snipMate está instalado! Para instalar os arquivos de ajuda, basta rodar :helptags ~/.vim/doc dentro do vim.

Usando snippets

Os snippets ficam guardados em ~/.vim/snippets. A sintaxe deles é simples (mais sobre isso abaixo), e é uma boa ideia dar uma olhada nos arquivos padrões para entender o que está acontecendo.

Editando um HTML, você pode digitar div<tab>, e div será expandido para:

<div id="1">
2
</div>

Onde 1 e 2 representam a primeira e segunda posições do cursor. Você pode mover entre essas posições usando a tecla <tab>.

Sintaxe dos snippets

Os snippets são definidos assim:

snippet nome
        texto expandido
        mais texto expandido

Portanto, quando você digitar nome<tab>, o texto expandido aparecerá automaticamente onde estava o cursor.

Para quem escreve muito em LaTeX, é possível criar algo como

snippet article
        \documentclass[${1}]{article}

onde esse ${1} indica a primeira posição do cursor. Você pode especificar as opções da classe ali. Mas digamos que eu queira algo mais complexo, como:

snippet beginfig
        \begin{figure}[h]
          \centering
          \includegraphics[width=.7\textwidth]{${1:filename}}
          \caption{${2}}
          \label{${3}}
        \end{figure}

Ali temos três posições do cursor, mas eu gosto de manter a label das minhas figuras igual ao nome do arquivo. Podemos usar um pouco da mágica do snipMate e:

snippet beginfig
        \begin{figure}[h]
          \centering
          \includegraphics[width=.7\textwidth]{${1:filename}}
          \caption{${2}}
          \label{$1}
        \end{figure}

O $1 depois de \label significa que todo o texto colocado sob ${1:filename} será replicado ali. Muito útil, especialmente para abrir e fechar tags HTML e ambientes no LaTeX:

snippet begin
        \begin{${1:env}}
          ${2}
        \end{$1}

Você também pode criar snippets para textos que repete com frequência, e mesmo deixar espaços em branco para aquelas partes do texto que são variáveis. Chega de digitar ou copiar/colar!

Após escrever um novo snippet, é necessário rodar :call ReloadAllSnippets() ou reiniciar o vim.

gedit

O fantástico gedit vem com um plugin muito parecido por padrão. Vejam esse post no ubuntu-br-sc para mais informações. A sintaxe é idêntica ou muito parecida com a sintaxe acima, mas tem uma interface gráfica legal para você gerenciar seus snippets.

LaTeX: Acentos em fórmulas

Rafael Beraldo — Sun, 09 Sep 2012

Essa é uma breve dica pra quem tem ou teve problemas para escrever fórmulas que contenham variáveis com acentos no LaTeX. Se você escrever uma fórmula como:

\[ Variável = \frac{x}{y} \]

O “á” em “Variável” não será mostrado como esperamos. Para resolver esse problema, basta usar \acute{a}. Assim:

\[ Vari\acute{a}vel = \frac{x}{y} \]

irá produzir o efeito desejado. Para mais acentos, vejam essa imagem que encontrei num site por aí:

Se as variáveis forem muito longas, como

\[ Variável muito longa que vai dar problema = \frac{x}{y} \]

os espaços irão simplesmente desaparecer. Para evitar que isso aconteça, basta encapsular (gostou, ãh?) o texto em \textrm{}, assim:

\[ \textrm{Variável muito longa que vai dar problema} = \frac{x}{y} \]

Nesse caso não é necessário marcar os acentos, apenas os escreva como faria com textos normais.

É isso aí, espero que isso ajude vocês!

Firefox e Vimperator

Rafael Beraldo — Tue, 04 Sep 2012

O browser que usei durante mais tempo até hoje foi, sem dúvida, o Firefox. Na época em que comecei a usar a Internet com frequência, era o melhor browser que existia e foi assim durante muito tempo. Quando comecei a usar o GNU/Linux, nos idos de 2007, com o Ubuntu 7.10 ou 7.04, o Firefox era o browser padrão e nos dávamos muito bem.

Mas tudo mudou em ano, quando o Google Chrome foi lançado. Eu nunca usei o Google Chrome, mas sim o Chromium, o projeto de código aberto no qual o browser do Google é baseado. Em questão de uma semana eu já havia parado de usar o Firefox em favor do novo browser, que era mais rápido, iniciava em segundos e renderizava as páginas em pouco tempo. O programa parecia mais responsivo em geral; foi assim que virei um de seus fãs.

Seja como for, eu sempre senti falta de usar o Firefox. Ele tinha uma magia inexplicável, um carisma único. Eu o instalava e rodava a cada nova release (antes delas se tornarem comuns), mas o browser nunca chegava à mesma velocidade do Chromium, no entanto.

Mesmo quando comprei meu computador atual, há uns três anos, ele ainda rodava melhor. Meu computador é um modesto Asus Eee PC com 2 GB de RAM, um processador Atom de 1,3 GHz e uma placa de vídeo da NVIDIA boa o suficiente para rodar alguns filmes em alta definição. Uma máquina legal, mas longe do padrão dos dias de hoje, onde os computadores têm pelo menos o dobro de RAM e processadores com o dobro da velocidade e núcleos.

Um dia notei como o modo que navegamos pela web me incomodava. Nossos sites dependem demais de mouses, o que não é muito confortável quando se passa 90% do tempo no computador usando um trackpad. Os browsers também endossam bastante esse paradigma. Então busquei por um plugin que permitisse rodar comandos comuns a partir do teclado e foi quando encontrei o Vimium, um plugin para o Chromium. Eu adorei o plugin, e usava ele bastante na época; mas encontrei, também, o fantástico Vimperator.

O Vimperator é um plugin para o Firefox que o transforma completamente. A navegação é feita totalmente pelo teclado, e você pode acessar inclusive o menu do Firefox usando comandos. É baseado no Vim, meu editor favorito, o que lhe rendeu muitos pontos positivos, sem falar do nome cool.

Foi então que me apaixonei pelo Firefox novamente. Uma pena, pois eu não estava disposto a usá-lo.

Quando minha mãe comprou seu novo computador, um tanto mais potente que o meu, instalei o Ubuntu 12.04 para ela. O Firefox veio por padrão, como sempre, e imediatamente instalei o Vimperator no meu usuário. No final de semana passado fiquei uns dias na casa de meus pais, usando bastante o computador de minha mãe, para brincar um pouco com a interface do Ubuntu (sobre a qual tenho algumas ressalvas) e decidi que iria deixar de lado meu preconceito pelo Firefox, fomentado por tantas experiências boas com o Chromium, e simplesmente usar o Firefox com Vimperator durante duas semanas.

Meu sistema já está configurado, e meu atalho no Fluxbox já chama o Firefox quando aperto minha hotkey para iniciar o browser. Vou analisar especialmente a velocidade com que o Firefox e o Vimperator respondem aos meus comandos, que é notavelmente lenta quando comparada à do Chromium, e dizer se vale a pena mudar para ele.

Abraços a todos e fiquem ligados para a minha conclusão daqui duas semanas!

P.S.: Obrigado pela foto, Alex Barros!

Jekyll never finishes compiling and other stuff

Rafael Beraldo — Wed, 29 Aug 2012

I use the monstrous Jekyll for all my blogging, and I love it. It’s simple enough, though you can do some pretty awesome stuff with it. I was away from my blog for quite a while so I completely lost the hang of Jekyll. Any time I’d try to compile my site, it would stop on regenerating: n files changed.

I googled this message and found out that whenever the option auto is on, Jekyll will watch for any changes and recompile the site whenever it finds one. Thus, it will never “finish” compiling, unless you stop it by hitting Ctrl-C. The solution was simple: I just had to change auto: true to auto: false in the _config.yml configuration file. Now it compiles just fine.

As for the “other stuff” in the title of the post, I’d like to know from my readers whether reading this blog is too difficult for you. Being a command line geek myself, I think the readability is OK but I might consider changing the font to a brighter green or even white. Please mail me with your ideas!

And here’s yet another cat by Noah Sussman for your appreciation!

Um dos melhores livros que já li

Rafael Beraldo — Mon, 27 Aug 2012

Durante as férias, estava olhando alguns livros na estante de história de do meu sebo favorito, quando encontrei um livro de H.G. Wells intitulado A Construção do Mundo, uma tradução que não faz jus ao título original, Work, Wealth and Happiness of Mankind. Uma rápida folheada me despertou interesse pelo livro de 1935, que em certo momento discutia locomotivas e barcos a vapor. Passados alguns dias, voltei ao sebo e comprei o tal livro por dez reais.

H.G. Wells foi o escritor de obras notórias como Guerra dos Mundos e A Máquina do Tempo e um homem de ciências, com treinamento em biologia. Antes da publicação de A Construção do Mundo, publicou uma História Universal e uma Ciência da Vida. Sobre a sua História, ele diz em A Construção do Mundo (a grafia original é mantida):

A minha Historia Universal fornece um excelente exemplo do modo como se pode levar o leitor adulto a corrigir as deformações de visão produzidas pelo habito e pratica escolares. Embora tenha logrado uma enorme saida, essa obra não foi planejada e escrita para o publico. Concebeu-a o autor como um simples livro didático.

[…]

Ninguem, mais do que ele proprio [Wells, o autor da História], se espantou com a grande aceitação popular de sua obra. Foi dormir simples reformador educacional e acordou um acontecimento de livraria. Verificou que existia no mundo um imenso publico mal satisfeito com a historia aprendida nos colegios e ansioso exatamente pelo que a Historia Universal prometia ser — um legivel e explicito sumario da aventura humana.

Duas páginas depois, Wells continua:

[…] O segundo trabalho feito foi o escorço da Biologia. Houve razões para dar ao livro o nome Ciencia da Vida. A base da educação do autor havia sido biologica e vivo sempre o interesse que sentia pelo assunto, mas a massa de conhecimentos acumuluados depois dos seus dias de estudante impunha-lhe a necessidade de alta assistencia. Encontrou-a em seu amigo Julian Huxley, neto do grande Huxley e tambem em seu proprio filho, G.P. Wells. Juntos produziram os tres um resumo do que o homem sabe a respeito do seu corpo e e de sua mente, da origem e evolução da vida, do onímodo espetaculo das coisas vivas na terra e no mar, das principais tendencias e correntes do pensamento psicologico e por fim da peculiar biologia da humanidade. A publicação da Ciencia da Vida coroou o trabalho de dois anos de ardua colaboração, e permitiu o empreendimento do mais difícil — este escorço de Economia, esta descrição popular do comercio e do trabalho, do toma-lá-dá-cá dessa estranha e singular especie de creaturas que somos nós.

O projeto de Wells eram esses três livros — um sobre História, outro sobre Biologia e um sobre Economia — a fim de permitir aos homens que compreendessem seu mundo e atuassem nele de forma consciente. Fica clara, durante o livro e nesse projeto, a orientação socialista de Wells. Pessoalmente, há tempos que não me simpatizo pela ideologia, mas a clareza de pensamento de H.G. Wells é tão profunda que não há como não admirar a ideia. Em determinado ponto do livro, o autor discute como essas três matérias, por assim dizer, estão conectadas; a história e economia humanas são produtos da biologia e a biologia das espécies tem uma história entrelaçada com a história e economia humanas.

O livro começa discutindo, portanto, sua própria história. Posteriormente, passa a discutir a história da humanidade, das especulações sobre seus primórdios até a chegada da agricultura, a formação das sociedades e, enfim, o debate grego do Realismo versus Nominalismo. De forma muito clara, Wells nos mostra como esse debate se desenvolveu ao longo do tempo e veio a desembocar no método científico, com a inversão das palavras realidade e realismo.

Jamais serei capaz de resumir a questão como Wells resumiu. Me aventuro com essa breve descrição do caso: na Grécia surge o primórdio do que o autor chama de “pensamento dirigido”, em oposição ao “pensamento do cerebro primitivo”, ou seja, o pensamento de uma época onde o ser humano não dispunha de “nenhum elemento critico que indague: ‘Mas será isto certo? Será verdade?’”. Os gregos foram os primeiros, segundo o livro, a se fazerem essas perguntas. Havia, no entanto, um embate a ser resolvido:

[…] ha tres modos de julgar as palavras; podemos julga-las mais verdadeiras que o fato [pense em platonismo], menos verdadeiras que o fato, ou exatas, isto é, coincidindo com o fato. Para o Realista a palavra era mais verdadeira que o fato; para o Nominalista o fato era mais verdadeiro que a palavra.

E, por mais espanto que isso cause, o Realismo era a visão mais aceita na Grécia, e não só na Grécia, como durante quase toda a Idade Média. Durante todo esse tempo — desde os filósofos gregos até hoje — essa discussão prossegue. O platonismo, ou seja, a ideia de que vivemos em um mundo imperfeito, sombra de um mundo ideal, encaixa-se muito bem com a cisão terra/céu da Igreja Católica, e melhor ainda com algumas concepções, como aquela de que somos feitos à imagem e semelhança de um ser perfeito, Deus, embora nós mesmos sejamos imperfeitos.

Se, de fato, as palavras fossem mais reais que a realidade, e apenas a lógica nos permitisse alcançar um entendimento pleno do mundo, a experiência — o método empírico — era besteira completa. Mas desde o fim da Idade Média o pensamento científico, autocrítico, cético e experimental ganhou força e modificou nosso mundo.

Desse ponto, Wells prossegue dando um rápido panorama da história da ciência. Suas opiniões sobre a ciência são extremamente afinadas com o que eu acredito que ela seja: não uma busca pela Verdade Absoluta, mas uma constante revisão de nossas pequenas verdades, rigorosamente escolhidas por um método que aceita calorosamente qualquer ideia testada, não aquelas que mais gostamos.

A logica podia provar certa coisa; mas a experimentação tinha de dizer se era assim. “Observa, experimenta, registra, especula logicamente, experimenta a tua especulação, confirma-a ou corrije-a, comunica-a a outros investigadores, ouve as suas comunicações, compara-as, discute-as, logicamente, estabelece o que ficar comprovado”, e assim por diante; para todos os propositos praticos, este é o metodo da ciencia.

Mas…

A libertação do espirito humano das prediposições Realisticas permanece incompleta. A humanidade ainda acreditava, até um seculo atrás, na fixidez das especies animais e vegetais — que se supunham variar em torno de um tipo perfeito; e ha apenas vinte e tantos anos admitia a similaridade absoluta dos atomos; e na politica internacional até hoje o Realismo ainda domina por completo. Esse erro intelectual dorme na raiz dos maiores peris que ameaçam a especie humana. Os corações dos homens podem estar no logar certo, as as pobres cabeças dos homens acham-se mergulhadas no nevoeiro dos nomes magicos. Porque é claro que um nominalista que considera a palavra “França” apenas como o nome designador de uma grande area geografica de ais e tais caracteristicas climatericas e sociais e cerca de quarenta milhões de seres humanos das mais diversas qualidades (muitos deles nem sequer falando o francês), ha de ver a politica internacional de um angulo inteiramente diverso do de um Realista que encontra na palavra França algo mais real e vital do que qualquer das coisas ou individuos que contribuem para o conjunto daquela idea. “Russia” é outro termo magico para os Realistas; “Mãe Índia”, outro; outro é “Mãe Patria”, seja qual for a patria. Desde que em nossas escolas não ensinamos a significação dessas palavras — nominalista e Realista — nem damos qualquer especie de treino ao pensamento analitico, seremos nominalistas ou Realistas segundo o nosso temperamento ou a nossa sorte.

Wells prossegue, discutindo como a ciência nada tem a ver com dogmas ou tradição e como, frequentemente, a mídia entende isso ao avesso, dizendo que um ou outro cientista “derrubou um dogma da ciência”. Discute como as universidades tiveram uma aceitação muito ruim da ciência, uma vez que eram tradicionais, e como impuseram graus de conhecimento da ciência — que existem até hoje, e se chamam Bacharel, Mestre e Doutor.

É fascinante como Wells consegue, nesse livro de 1935, ensinar as coisas de forma tão bem entrelaçadas, coisa que minha educação, meio século depois, não conseguiu. O autor britânico compreendia a necessidade de tornar as coisas não só cotidianas como relevantes; fazia isso tão bem, que as partes sobre a conquista das substâncias — parte na qual ele discorre até mesmo sobre os vários tipos de ferro e aço e como sua invenção foi fundamental para o avanço em outras áreas — e sobre a conquista da força (diríamos energia hoje em dia) são extremamente saborosas.

Menti no título desse post; ainda não li o livro, mas estou na metade. Parei na parte em que Wells discute a história da conquista da distância. A máquina a vapor ainda era o grande meio de transporte, e as máquinas a Diesel estavam começando a serem testadas. Vejam esses trechos, sobre o uso de energia:

O Dr. Herbert Levenstein fala da era da força-carvão e da força-petroleo, ou “era da força fossil”, como mero incidente na evolução econômica da humanidade. “Terá durado, quando chegar ao fim, menos tempo que a ocupação moura na Espanha”.

Agora, com a corrente eletrica descoberta e a sua disposição, o homem não tem dificuldades em transmitir a força do moinho de vento ou da roda d’agua aos mais distantes pontos de aplicação.

[…]

Haverá ainda possibilidades não desenvolvidas de se extrair força dos movimentos do ar ou da agua? Um exaustivo Livro da Força teria de resumir a fase atual do problema, ainda não resolvido, da utilização da energia das marés. E descreveria um ou dois dos estranhos e até agora impraticaveis aparelhos para a captura direta da energia radiante do sol. No Instituto Kaiser Wilhelm, em Dahlem, o Dr. Lange fez funcionar um pequeno motor eletrico por meio da luz solar, fazendo-a passar através de uma celula foto-eletrica. Esse pequeno motor do Dr. Lange talvez venha a figurar nas historias economicas do futuro como a maquina a vapor de Hero figura nas de hoje.

As previsões de Wells soam tão fantásticas que é difícil se dar conta de que muitas delas se realizaram. O método de Wells ao escrever seu livro — não contar a história dos reis e Estados, mas das ideias e conquistas da humanidade — produz um efeito maravilhoso de te jogar no meio dessa verdadeira aventura.

Para finalizar, chamo atenção para o terceiro parágrafo citado acima, no qual o autor fala sobre um Livro da Força. Wells frequentemente fala de uma enciclopédia eternamente revisada, expandida, para incluir toda a história do progresso, invenções e ideias humanas, um livro de consultas, a Ciência do Trabalho e da Riqueza, que aparece em trechos como:

Uma enciclopedica Ciencia do Trabalho e da Riqueza, com ilimitadas ilustrações, contaria toda a historia da via ferrea, e encenaria os seus mais vivos episodios. Mostraria, por meio de mapas feitos para cada periodo, o modo como as estradas de ferro se espalharam, á guisa de nervos em um embrião em desenvolvimento.

Fico muito feliz em ver que Wells estava certo.

FLISoL 2012 em São Carlos

Rafael Beraldo — Thu, 08 Mar 2012

São Carlos vai ganhar uma edição do FLISoL, que acontece no quarto sábado de cada ano — que esse ano cai no dia 28 de abril. Entre os objetivos do evento estão a divulgação do software livre e sua filosofia ao público em geral, a realização de palestras e simplesmente ser uma oportunidade para a comunidade local de software livre se encontrar.

O evento em São Carlos deve acontecer no campus do Instituto Federal de São Carlos, que fica dentro da UFSCar. O FLISOL 2012 São Carlos também conta com um grupo no Google Groups e um grupo no Facebook.

Já estou pensando no trabalho que irei enviar, e ainda não me decidi entre LaTeX e as humanidades, ou apenas LaTeX na academia, ou ainda LaTeX e noções básicas de tipografia. Também posso falar sobre o grupo de traduções para português brasileiro do gnu.org, e ver se consigo mais gente para o projeto. De qualquer forma, a chamada para trabalhos, ao que parece, ainda não foi divulgada.

Vai ser o primeiro evento de software livre que vou participar e foi, na verdade, uma surpresa descobrir que haverá uma edição em São Carlos. Nos vemos lá!

E agora uma imagem dos nossos patrocinadores (uma cortesia de protohiro):

The sky above the port

Rafael Beraldo — Wed, 29 Feb 2012

Every story should start with a memorable line. I can quote Gibson’s Neuromancer first sentence from my head:

The sky above the port was the color of television, tuned to a dead channel.

With this single sentence, Gibson sets the mood of his entire book. The first obvious element is the port, which is frequently associated with crime, a suspect place to be, where all kinds of things come from overseas. And Neuromancer has all to do with crime, suspect places and activities, not to mention weird objects.

Color of television is a beautifully crafted expression that caries both the sadness of the gray sky and the mention of technology. Finally, this television is tuned to a dead channel — I think we can all clearly see this image, and how the word dead plays a role here.

I have lots of books here. (I’d have many more, but I don’t have room for more than a few!) I like to browse through them, looking for better opening lines. Today I opened Graham Greene’s The Power and the Glory by chance, only to read this amazing sentence:

Mr Tench went out to look for his ether cylinder, into the blazing Mexican sun and the bleaching dust.

I immediately pictured the vast western movie scenarios and No Country for Old Men. I saw particles of dust sweeping through the sky, sweat, mustaches and bottles of tequila.

But should there be an opening line contest, there’d be already a clear winner. The best opening line of all is from Douglas Adams’ The Hitchhiker’s Guide to the Galaxy:

Far out in the uncharted backwaters of the unfashionable end of the western spiral arm of the Galaxy lies a small, unregarded yellow sun.

Harder, better, faster, stronger

Rafael Beraldo — Sun, 19 Feb 2012

Last month or so I deleted everything I had posted on Cabaladadá so far. For more than a month, Business Cat gave the good news to every visitor.

I finally took a deep breath and decided to start working on the blog again. This is the “final” result. It’ll probably change over the years to come but this is a good starting point for someone who can barely code in CSS.

I wanted to make Cabaladadá more personal. It was too brainy, too serious. I couldn’t write because every time I tried to, it felt overwhelmingly painful. I realized I was trying to rewrite Goethe’s Faust every time I opened vim and I needed a fresh start. Now I can start having fun again (I hope).

There was something else annoying me. WordPress. But don’t get me wrong: I love WordPress, and I really recommend it if you’re new to blogging and wants something that is robust and customizable. It just wasn’t the right tool for me. The upgrades were distressing and, lately, something would often break. Also, my netbook isn’t very powerful, so the admin interface itself was too CPU-consuming.

And then I remembered of jekyll. dudektria introduced me to jekyll a long time ago. He later would recommend nanoc over jekyll but, I don’t know exactly why, I decided to go with the first one. Maybe because I had already installed it on my computer.

jekyll is beautiful. It is simple, I can write my posts in markdown and it converts them automatically to HTML, and I don’t need a fancy administration web interface. I can write plain text files using vim, and then upload a static website to my server. I can use git to keep track of changes. It is blogging the hacker way, and I love it.

It’s exactly what I wanted. Oh, and did I mention it’s written in Ruby?

Another decision that I had taken several months ago was that Cabaladadá should be in English. I probably read more English than Portuguese these days but I don’t get enough writing. Blogging is a great way to correct this. I may eventually publish in Portuguese or translate a few articles, but Cabaladadá will be mostly in Douglas Adams’ language.

Finally, I hope you like the terminal theme. It isn’t perfect yet—maybe the font is too big or too small depending on your browser—but I think it is simple and reflects this new phase of Cabaladadá: more hackerish, still nerdy, a bit technical, and certainly discordian.