Copyright © 1999 by The Free Software Foundation
É permitido copiar, distribuir e/ou modificar este documento desde que sob os termos da GNU Free Documentation License, Versão 1.1 ou posterior publicada pela Free Software Foundation; sem alterações em seu conteúdo. Uma cópia da licença está incluída na seção "GNU Free Documentation License".
Por favor envie perguntas, reportagens de bugs ou sugestões sobre este manual para o mantenedor, Mike Ashley (<jashley@acm.org>). Quando referir-se ao manual por favor especifique a versão usando a string: $Name: v1_1 $.
Colaboradores deste manual incluem Matthew Copeland, Joergen Grahn, e David A. Wheeler. J Horacio MG traduziu o manual para o espanhol.
Tradução para o português do Brasil: Samuel Dias Neto ( sdiasneto@yahoo.com.br )
GnuPG é uma ferramenta para comunicação segura. Este capítulo é um guia rápido que aborda o coração da funcionalidade do GnuPG. Ele inclui a criação do par de chaves, troca e verificação de chaves, encriptação e decriptação de documentos, e autenticação de documentos com assinatura digital. Ele não explica em detalhes os conceitos por trás da criptografia de chave pública, encriptação e assinatura digital. Isto será abordado no Capítulo 2. Ele também não explica como usar GnuPG profundamente. Isto é abordado nos Capítulos 3 e 4.
GnuPG usa criptografia de chave pública para que os usuários possam comunicar-se com segurança. Em um sistema de chave pública, cada usuário tem um par de chaves consistindo de uma chave privada e uma chave pública. A chave privada do usuário é mantida em segredo; ela não pode ser revelada. A chave pública pode ser dada a todos com quem o usuário quer comunicar-se. GnuPG usa um esquema no qual o usuário tem um par de chaves principal e zero ou mais pares de chaves subordinadas adicionais. Os pares de chaves principal e subordinada são empacotados para facilitar o gerenciamento e este empacotamento pode ser considerado como um único par de chaves.
A opção --gen-key é usada para criar um novo par de chaves.
alice% gpg --gen-key
gpg (GnuPG) 0.9.4; Copyright (C) 1999 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection?GnuPG é capaz de criar vários tipos diferentes de pares de chaves, mas a chave principal deve ser capaz de fazer assinaturas. Existem, então, apenas três opções. A opção 1 cria dois pares de chaves. Um par de chaves DSA é um par de chaves principal usado apenas para fazer assinaturas. Um par de chaves subordinado ElGamal também é criado para encriptação. A opção 2 é semelhante, mas cria apenas o par de chaves DSA. A opção 4[1] cria apenas um par de chaves ElGamal usado para assinar e executar encriptação. Em todos os casos é possível, posteriormente, adicionar pares de chaves para encriptação e assinatura. Para a maioria dos usuários a opção padrão é boa.
Você também deve escolher o tamanho da chave. O tamanho de uma chave DSA deve ser entre 512 e 1024 bits, e uma chave ElGamal pode ter qualquer tamanho. GnuPG, porém, requer que as chaves não sejam menores que 768 bits. Então, se a opção 1 foi escolhida e você escolher um tamanho de chave maior que 1024 bits, a chave ElGamal terá o tamanho escolhido, mas a chave DSA terá 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024)Uma chave maior é mais segura contra ataques, mas para quase todos os objetivos o tamanho padrão é adequado uma vez que é mais vantagem cercá-la que tantar quebrá-la. Além disso, a encriptação e decriptação serão mais lentas quanto maior for o tamanho da chave e uma chave maior pode afetar o comprimento da assinatura. Uma vez selecionado, o tamanho da chave nunca poderá ser alterado.
Finalmente, você deve escolher a data de validade. Se a opção 1 foi escolhida, a data de validade será usada para as duas chaves, a ElGamal e a DSA.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) Para a maioria dos usuários uma chave que não expira o prazo de validade é adequado. Porém, o prazo de validade deve ser escolhido com cuidado, pois embora seja possível alterá-lo posteriormente, pode ser difícil comunicar uma alteração para os usuários que tem sua chave pública.
Você deve fornecer uma identificação de usuário (ID). A ID é usada para associar a chave que está sendo criada com sua pessoa.
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: Apenas uma ID é criada no momento de criação da chave, mas é possível criar IDs adicionais se você quer usar a chave em dois ou mais contextos, isto é, como um funcionário da empresa num contexto e como um ativista político em outro. Sua ID deve ser criada com cuidado pois não poderá ser editada depois.
GnuPG precisa de uma senha para proteger suas chaves.
You need a Passphrase to protect your private key.
Enter passphrase: Não há limite para o tamanho da senha e ela deve ser escolhida com cuidado. Da perspectiva da segurança, a senha para desbloquear a chave privada é o ponto mais sensível do GnuPG (e de outros sistemas de encriptação de chave pública) uma vez que ela é a única proteção que você tem contra o acesso a sua chave. O ideal é que a senha não use palavras de um dicionário e seja uma mistura de caracteres alfabéticos maiúsculos e minúsculos junto com caracteres não alfabéticos. Uma boa senha é crucial para o uso seguro do GnuPG.
Após seu par de chaves ser criado você deve imediatamente gerar um certificado de revogação para a chave primária usando a opção --gen-revoke. Se você esquecer sua senha ou se sua chave privada for comprometida ou perdida, este certificado de revogação pode ser publicado para notificar outros que a chava pública não deve mais ser usada. Uma chave pública revogada ainda pode ser usada para verificar assinaturas feitas no passado, mas não pode ser usada para encriptar mensagens futuras para você. Ela também não afeta sua habilidade para decriptar mensagens enviadas no passado se você ainda tem acesso a chave privada.
alice% gpg --output revoke.asc --gen-revoke mykey
[...]O argumento mykey deve ser um especificador de chave, que pode ser a ID de sua chave primária ou qualquer parte da ID que identifica seu par de chaves. O certificado gerado será colocado no arquivo revoke.asc. Se a opção --output for omitida, o resultado será colocado na saída padrão. Como o certificado é pequeno, você pode imprimir uma cópia para guardar em local seguro. O certificado não deve ser guardado onde outros possam acessar uma vez que qualquer um pode publicar o certificado de revogação e tornar a correspondente chave pública inútil.
Para comunicar-se com outras pessoas você deve trocar as chaves públicas. Para listar as chaves em seu chaveiro público use a opção --list-keys.
alice% gpg --list-keys
/users/alice/.gnupg/pubring.gpg
---------------------------------------
pub 1024D/BB7576AC 1999-06-04 Alice (Judge) <alice@cyb.org>
sub 1024g/78E9A8FA 1999-06-04
Para enviar sua chave pública para uma pessoa você deve primeiro exportá-la. A opção de comando --export é usada para isto. Ela requer um argumento adicional que identifica a chave pública a ser exportada. Assim como a opção --gen-revoke , ela também aceita a ID da chave ou qualquer parte da ID do usuário para identificar a chave a ser exportada.
alice% gpg --output alice.gpg --export alice@cyb.orgA chave é exportada em um formato binário, mas isto pode ser inconveniente quando a chave será enviada por email ou publicada numa página web. GnuPG então suporta a opção --armor[2] que faz com que a saída seja gerada em formato ASCII-armored. Em geral, qualquer saída do GnuPG, isto é, chaves, documentos encriptados e assinaturas, podem sair no formato ASCII-armored através do uso da opção --armor.
alice% gpg --armor --export alice@cyb.org
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v0.9.7 (GNU/Linux)
Comment: For info see http://www.gnupg.org
[...]
-----END PGP PUBLIC KEY BLOCK-----
Uma chave pública pode ser adicionada ao seu chaveiro público com a opção --import.
alice% gpg --import blake.gpg
gpg: key 9E98BC16: public key imported
gpg: Total number processed: 1
gpg: imported: 1
alice% gpg --list-keys
/users/alice/.gnupg/pubring.gpg
---------------------------------------
pub 1024D/BB7576AC 1999-06-04 Alice (Judge) <alice@cyb.org>
sub 1024g/78E9A8FA 1999-06-04
pub 1024D/9E98BC16 1999-06-04 Blake (Executioner) <blake@cyb.org>
sub 1024g/5C8CBD41 1999-06-04Depois de importada uma chave deve ser validada. GnuPG usa um poderoso e flexível modelo de certificação que não exige que você pessoalmente tenha que validar cada chave importada. Porém, algumas chaves podem necessitar que você pessoalmente execute a validação. Uma chave é validada pela verificação da impressão digital e pela assinatura para certificá-la como uma chave válida. A impressão digital da chave pode ser rapidamente visualizada com a opção --fingerprint , mas para certificar a chave você deve editá-la.
alice% gpg --edit-key blake@cyb.org
pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/q
sub 1024g/5C8CBD41 created: 1999-06-04 expires: never
(1) Blake (Executioner) <blake@cyb.org>
Command> fpr
pub 1024D/9E98BC16 1999-06-04 Blake (Executioner) <blake@cyb.org>
Fingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16A impressão digital da chave é verificada com o proprietário da chave. Isto pode ser feito em pessoa ou por telefone ou através de outros meios que possam garantir que você está realmente comunicando-se com o verdadeiro proprietário da chave. Se a impressão digital que você pegou é a mesma que o provável proprietário lhe passou então você pode ficar certo que tem uma cópia correta da chave.
Após checar a impressão digital você pode assinar a chave para validá-la. Como a verificação da chave é um ponto fraco na criptografia de chave pública, você deve ser extremamente cuidadoso e sempre verificar a impressão digital da chave com o proprietário antes de assiná-la.
Command> sign
pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/q
Fingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16
Blake (Executioner) <blake@cyb.org>
Are you really sure that you want to sign this key
with your key: "Alice (Judge) <alice@cyb.org>"
Really sign?Uma vez assinada, você pode checar a chave para listar as assinaturas dela e ver a assinatura que você adicionou. Toda ID de usuário numa chave terá uma ou mais assinaturas próprias (self-signature) assim como uma assinatura para cada usuário que tenha validado a chave.
Command> check
uid Blake (Executioner) <blake@cyb.org>
sig! 9E98BC16 1999-06-04 [self-signature]
sig! BB7576AC 1999-06-04 Alice (Judge) <alice@cyb.org>
A chave pública e a chave privada tem papéis específicos na encriptação e decriptação de documentos. Uma chave pública pode ser imaginada como um cofre aberto. Quando alguém encripta um documento usando uma chave pública é como se estivesse colocando o documento dentro do cofre e fechando-o. A chave privada correspondente é a combinação para abrir o cofre e pegar o documento. Em outras palavras, apenas a pessoa que tem a chave privada pode recuperar o documento encriptado com a referente chave pública.
O procedimento para encriptar e decriptar documentos é simples e direto. Se você quer encriptar uma mensagem para Alice, você usa a chave pública dela e só ela irá decriptar a mensagem usando a chave privada. Se Alice quer enviar uma mensagem para você, ela encripta usando sua chave pública e você decripta usando sua chave privada.
A opção usada para encriptar um documento é --encrypt. Você deve ter a chave pública do destinatário. O software espera o nome do documento a ser encriptado como entrada; se omitido, ele lê a entrada padrão (normalmente o teclado). O resultado é colocado na saída padrão ou onde for especificado pela opção --output. Como segurança adicional o documento é compactado.
alice% gpg --output doc.gpg --encrypt --recipient blake@cyb.org docA opçãp --recipient é usada para cada um dos destinatários e deve receber um argumento extra que especifica a chave pública com a qual o documento deve ser encriptado. O documento só poderá ser decriptado por alguém que tenha uma chave privada referente a uma das chaves públicas utilizadas na encriptação. Assim, até mesmo você não poderá decriptar um documento a não ser que inclua sua própria chave pública na lista dos destinatários.
Para decriptar uma mensagem é usada a opção --decrypt. Você precisa da chave privada para a qual a mensagem foi encriptada. Semelhante ao processo de encriptação, o documento encriptado é usado como entrada e o documento decriptado é a saída.
blake% gpg --output doc --decrypt doc.gpg
You need a passphrase to unlock the secret key for
user: "Blake (Executioner) <blake@cyb.org>"
1024-bit ELG-E key, ID 5C8CBD41, created 1999-06-04 (main key ID 9E98BC16)
Enter passphrase: Documentos também podem ser encriptados sem usar a criptografia de chave pública. Em vez disto, você pode usar uma cifra simétrica para encriptar um documento. A chave usada para direcionar a cifra simétrica é derivada de uma senha fornecida quando o documento é encriptado, e para boa segurança, não deve ser a mesma senha usada para proteger sua chave privada. Encriptação simétrica é útil para segurança de documentos quando a senha não precisa ser comunicada a outros. Um documento pode ser encriptado com uma cifra simétrica usando a opção --symmetric.
alice% gpg --output doc.gpg --symmetric doc
Enter passphrase:
Uma assinatura digital certifica a integridade de um documento. Se o documento foi modificado, a verificação da assinatura falha. Uma assinatura digital pode servir para os mesmos propósitos que uma assinatura convencional além de verificar se o documento foi modificado. A distribuição fonte do GnuPG, por exemplo, é assinada de modo que os usuários podem verificar se o código fonte foi modificado após o empacotamento.
Criar e verificar assinaturas usa o par de chaves pública/privada em uma operação diferente da encriptação e decriptação. A assinatura é criada usando a chave privada do emissor. Ela é verificada usando a correspondente chave pública. Por exemplo, Alice poderia usar sua própria chave privada para assinar seu último pedido do Jornal. O editor do jornal poderia usar a chave pública de Alice para checar a assinatura, verificando se realmente o pedido veio dela e, também, se o pedido não foi modificado após Alice ter enviado. Uma consequência do uso da assinatura digital é que é difícil negar que foi você que fez a assinatura digital uma vez que isto implicaria em sua chave privada ter sido compromentida.
A opção --sign é usada para fazer a assinatura digital. O documento a ser assinado é a entrada e a saída é o documento assinado.
alice% gpg --output doc.sig --sign doc
You need a passphrase to unlock the private key for
user: "Alice (Judge) <alice@cyb.org>"
1024-bit DSA key, ID BB7576AC, created 1999-06-04
Enter passphrase: O documento é comprimido antes de ser assinado e a saída é em formato binário.
Dado um documento assinado, você pode apenas checar a assinatura ou checar a assinatura e recuperar o documento original. Para checar a assinatura use a opção --verify. Para verificar a assinatura e extrair o documento use a opção --decrypt. O documento assinado a ser verificado e recuperado é a entrada e o documento recuperado é a saída.
blake% gpg --output doc --decrypt doc.sig
gpg: Signature made Fri Jun 4 12:02:38 1999 CDT using DSA key ID BB7576AC
gpg: Good signature from "Alice (Judge) <alice@cyb.org>"
Um uso comum das assinaturas digitais é assinar mensagens de email ou da usenet. Nestas situações é indesejável comprimir o documento. A opção --clearsign envolve o documento em uma assinatura ASCII-armored mas não modifica o documento.
alice% gpg --clearsign doc
You need a passphrase to unlock the secret key for
user: "Alice (Judge) <alice@cyb.org>"
1024-bit DSA key, ID BB7576AC, created 1999-06-04
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.7 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1
oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k
=y6kj
-----END PGP SIGNATURE-----
Um documento assinado tem utilidade limitada. Outros usuários recuperam o documento original a partir da versão assinada e, mesmo com a assinatura em claro, o documento assinado deve ser editado para recuperar completamente o original. Assim existe um terceiro método para assinar um documento que cria uma assinatura destacada, a qual é um arquivo separado. Uma assinatura separada é criada usando a opção --detach-sig.
alice% gpg --output doc.sig --detach-sig doc
You need a passphrase to unlock the secret key for
user: "Alice (Judge) <alice@cyb.org>"
1024-bit DSA key, ID BB7576AC, created 1999-06-04
Enter passphrase: Para verificar a assinatura são necessários o documento e a assinatura. A opção --verify é usada para checar a assinatura.
blake% gpg --verify doc.sig doc
gpg: Signature made Fri Jun 4 12:38:46 1999 CDT using DSA key ID BB7576AC
gpg: Good signature from "Alice (Judge) <alice@cyb.org>"
GnuPG faz uso de diversos conceitos de criptografia incluindo cifras simétricas, cifras de chave pública e one-way hashing. Você pode usar basicamente o GnuPG sem entender nada destes conceitos, mas para usá-lo sabiamente algum conhecimento destes conceitos é necessário.
Este capítulo introduz os conceitos básicos de criptografia usados no GnuPG. Outros livros cobrem estes tópicos com mais detalhes. Um bom livro para estudar isto é ``Applied Cryptography'' de Bruce Schneier .
Uma cifra simétrica é aquela que usa a mesma chave para encriptação e decriptação. Para duas partes usarem uma cifra simétrica devem, antes, combinar uma chave. Uma vez escolhida a chave, o emissor encripta a mensagem usando a chave, envia a mensagem ao receptor e este decripta a mensagem usando a chave. Como exemplo, a Enigma Alemã é uma cifra simétrica e chaves diárias eram distribuídas em um livro de códigos. Diariamente, um emissor ou receptor podia consultar sua cópia do livro de códigos para saber qual era a chave do dia. O tráfego de mensagens via rádio para aquele dia era então encriptado e decriptado usando esta chave do dia. Exemplos modernos de cifras simétrias incluem 3DES, Blowfish, e IDEA.
Uma boa cifra coloca toda a segurança em uma chave e não no algoritmo. Em outras palavras, saber qual cifra está sendo usada não deve ajudar um atacante. Somente se ele obter a chave, o conhecimento do algoritmo será útil e necessário. As cifras usadas no GnuPG tem esta propriedade.
Uma vez que toda a segurança está na chave, então é importante que ela seja difícil de descobrir. Em outras palavras, o conjunto de chaves possíveis, isto é, o universo da chave, precisa ser grande. Em Los Alamos, Ricahrd Feynman ficou famoso por sua habilidade em abrir cofres sem saber a combinação. Para mistificar a coisa ele sempre carregava um conjunto de ferramentas incluindo um velho estetoscópio. Na realidade, ele usava várias dicas para reduzir o número de combinações que ele tinha que tentar para um número bem reduzido e então simplesmente tentava até encontrar a combinação correta. Em outras palavras, ele reduzia o tamanho do universo da chave.
Ingleses usaram máquinas para tentar descobrir chaves durante a Segunda Guerra. A Enigma Alemã tinha um grande universo de chave, mas os ingleses construíram engenhos especializados, as Bombas, para mecanicamente tentar as chaves até encontrar a chave do dia. Isto significa que algumas vezes eles encontravam a chave diária algumas horas após o início do seu uso, mas também significa que alguns dias eles não conseguiram encontrar a chave correta. As Bombas não eram computadores de uso geral mas foram precursoras dos computadores atuais.
Hoje os computadores podem tentar descobrir as chaves rapidamente e é por isto que o tamanho da chave é importante em modernos criptosistemas. A cifra DES usa uma chave de 56 bits, o que significa que existem 256 chaves possíveis. 256 equivale a 72,057,594,037,927,936 chaves. São muitas chaves, mas um computador de uso geral pode checar todo este universo em alguns dias. Um computador especializado pode checar em horas. Por outro lado, cifras mais recentes como a 3DES, blowfish e IDEA usam uma chave de 128 bits, o que significa que existem 2128 chaves possíveis. Existem assim muito mais chaves e mesmo todos os computadores do planeta trabalhando juntos levariam um tempo maior que a idade do universo para encontrar a chave.
O principal problema das cifras simétricas não é a segurança em si, mas a troca de chaves. Uma vez que emissor e receptor tenham trocado a chave, esta pode ser usada para uma comunicação segura. Mas, que canal de comunicação segura foi usado para comunicar a chave ? Poderia ser mais fácil para um atacante trabalhar para interceptar a chave em vez de tentar todas as chaves de um determinado universo. Outro problema é o número de chaves necessárias. Se existem n pessoas que precisam comunicar-se, então n(n-1)/2 chaves são necessárias para cada par de pesoas comunicar-se confidencialmente. Isto pode não ser problema para um pequeno número de pessoas mas rapidamente torna-se difícil para um grande número.
Cifras de chave pública foram inventadas para evitar o problema da troca de chaves completamente. Uma cifra de chave pública usa um par de chaves para enviar mensagens. As duas chaves pertencem a pessoa que receberá a mensagem. Uma é a chave pública e pode ser passada para qualquer um. A outra é a chave privada e é mantida em segredo pelo proprietário. O emissor encripta a mensagem usando a chave pública e, uma vez encriptada, só a chave privada pode decriptá-la.
Este protocolo resolve o problema da troca de chaves existente com as cifras simétricas. Não há necessidade do emissor e receptor combinarem uma chave. Tudo que é preciso é que algum tempo antes da comunicação secreta o emissor pegue uma cópia da chave pública do receptor. Além disso, uma chave pública pode ser usada por qualquer pessoa que deseja comunicar-se com o receptor. Assim, apenas n pares de chaves são necessários para n pessoas comunicar-se secretamente com outras.
Cifras de chave pública são baseadas em funções one-way trapdoor. Uma função one-way é uma função que é fácil de computar, mas seu inverso é difícil de computar. Por exemplo, é fácil multiplicar dois números primos juntos formando um número composto, mas é difícil fatorar um número composto em seus componentes primos. Uma função one-way trapdoor é similar, mas tem um trapdoor. Isto é, se algum pedaço da informação é conhecido, torna-se fácil computar o inverso. Por exemplo, se você tem um número formado a partir de dois fatores primos, então conhecendo um dos fatores torna-se fácil computar o segundo. Dada uma cifra de chave pública baseada na fatoração de primos, a chave pública contém um número composto formado de dois grandes fatores primos, e o algoritmo de encriptação usa o número composto para encriptar a mensagem. O algoritmo para decriptar a mensagem requer o conhecimento dos fatores primos, assim a decriptação torna-se fácil se você tem a chave privada contendo um dos fatores, mas, extremamente difícil se você não tem.
Assim como em toda boa cifra simétrica, numa boa cifra de chave pública toda segurança está na chave. Consequentemente o tamanho da chave é a medida da segurança de um sistema, porém não se pode comparar o tamanho de uma chave de cifra simétrica com o tamanho de uma chave de cifra de chave pública como a medida de segurança relativa entre as cifras. Em um ataque de força bruta contra uma cifra simétrica com uma chave de 80 bits , o atacante deve enumerar 280 chaves para encontrar a chave correta. Em um ataque de força bruta contra uma cifra de chave pública de 512 bits, o atacante deve fatorar um número composto de 155 dígitos. O trabalho para o atacante é fundametalmente diferente dependendo da cifra que ele está atacando. Enquanto 128 bits são suficientes para cifras simétricas, devido a tecnologia atual da fatoração, chaves públicas com 1024 bits são as recomendadas para os diversos objetivos.
Cifras de chave pública não são a solução para tudo. Muitas cifras simétricas são fortes e a encriptação e decriptação de chave pública são mais demoradas que as operações correspondentes em sistemas simétricos. Cifras de chave pública, porém, são uma ferramenta ideal para a distribuição de chaves de cifras simétricas, e é assim que elas são usadas em um sistema de cifras híbrido.
Uma cifra híbrida usa a cifra simétrica e a cifra de chave pública. Ela trabalha usando uma cifra de chave pública para compartilhar uma chave para a cifra simétrica. A mensagem atual é encriptada usando a chave e é enviada ao receptor. Assim, o compartilhamento da chave simétrica é seguro. Além disso para cada mensagem uma chave simétrica diferente é enviada. Isto é chamado algumas vezes de sessão de chave.
PGP e GnuPG usam cifras híbridas. A sessão da chave, encriptada usando uma cifra de chave pública, e a mensagem enviada, encriptada com a cifra simétrica, são automaticamente combinadas em um pacote. O receptor usa sua chave privada para decriptar a sessão de chave e a sessão de chave é então usada para decriptar a mensagem.
Uma cifra híbrida não é mais forte que a cifra de chave pública ou a cifra simétrica que ela usa, qualquer uma delas é fraca. No PGP e no GnuPG, a cifra de chave pública é provavelmente a mais fraca. Felizmente, se um atacante conseguir decriptar uma sessão de chave, ela só será útil para ler a mensagem encriptada com ela. Para ler qualquer outra mensagem o atacante terá que decriptar outra sessão de chave.
Uma função hash é uma função do tipo many-to-one que mapeia sua entrada para um valor em um conjunto finito. Tipicamente este conjunto é uma variação de números naturais. Uma simples hash function é f(x) = 0 para todo inteiro x. Uma função hash mais interessante é f(x) = x mod 37, que mapeia x para o resto da divisão de x por 37.
A assinatura de um documento digital é o resultado da aplicação de uma função hash ao documento. Para ser útil, porém, a função hash precisa satisfazer duas importantes propriedades. Primeiro, deve ser difícil encontrar dois documentos que misturem o mesmo valor. Segundo, dado um valor hash, deve ser difícil recuperar o documento que o produziu.
Algumas cifras de chave pública [3] podem ser usadas para assinar documentos. Ao ser assinado, um documento é encriptado com a chave privada. Qualquer um que desejar checar a assinatura e ver o documento simplesmente deverá usar a chave pública correspondente para decriptar o documento. Este algoritmo satisfaz as duas necessidades para uma boa função hash, mas na prática, este algoritmo é muito lento para ser útil.
Uma alternativa é usar funções hash projetadas para satisfazer estas importantes propriedades. SHA e MD5 são exemplos disto. Usando um algoritmo deste tipo, um documento é assinado e o valor hash gerado é a assinatura. Outra pessoa pode checar a assinatura fazendo o mesmo com sua cópia do documento e comparando o valor hash gerado pela cópia com o valor hash do documento original. Se os valores corresponderem, é quase certo que os documentos são idênticos.
É claro que o problema agora é usar uma função hash para assinaturas digitais sem permitir a um atacante interferir com a checagem da assinatura. Se o documento e a assinatura não são enviados encriptados, um atacante poderia modificar o documento e gerar nova assinatura sem o conhecimento do receptor. Se apenas o documento é encriptado, um atacante poderia interferir na assinatura e provocar uma falha na checagem. Uma terceira opção é usar uma encriptação híbrida de chave pública para encriptar a assinatura e o documento. O emissor usa sua chave privada, e qualquer um pode usar a chave pública para checar a assinatura e o documento. Isto parece bom mas, atualmente não é. Se este algoritmo realmente protegesse o documento, ele também poderia protegê-lo contra alterações e não haveria necessidade da assinatura. O problema mais sério, porém, é que ele não protege a assinatura ou o documento contra alterações. Com este algoritmo, apenas uma sessão de chave para a cifra simétrica é encriptada usando a chave privada do emissor. Qualquer um pode usar a chave pública e recuperar a sessão de chave. Então, é possível a um atacante recuperar a sessão de chave e usá-la para encriptar outro documento e assinatura e enviá-los como se fosse o emissor original.
Um algoritmo melhor é o que usa a chave pública para encriptar apenas a assinatura. O valor hash é encriptado usando a chave privada do emissor e qualquer um pode checar a assinatura usando a chave pública. O documento assinado pode ser enviado usando qualquer outro algoritmo de encriptação incluindo nenhum se é um documento público. Se o documento é modificado, a verificação da assinatura falhará. A Digital Signature Standard (DSA) é um algoritmo de assinatura de chave pública que trabalha assim. Ele é o algoritmo de assinatura usado no GnuPG.
A alteração de chaves é o maior problema de segurança da criptografia de chave pública. Um intruso pode alterar o chaveiro de um usuário ou forjar uma chave pública e postá-la para outros baixarem e usarem. Por exemplo, suponha que Chloe quer monitorar as mensagens que Alice envia para Blake. Ela deve montar o chamado “a man in the middle attack”. Neste ataque, Chloe cria um novo par de chaves. Ela substitui a cópia que Alice tem da chave pública de Blake com sua nova chave pública. Ela então intercepta a mensagem que Alice envia para Blake. Para cada interceptação, ela decripta usando a nova chave privada, reencripta usando a verdadeira chave pública de Blake e reenvia a mensagem para Blake. Todas as mensagens enviadas de Alice para Blake podem ser lidas por Chloe.
Um bom gerenciamento de chaves é crucial para garantir não apenas a integridade do seu chaveiro mas também a integridade dos chaveiros dos outros usuários. O coração do gerenciamento de chaves no GnuPG é a noção de assinatura de chaves. Assinatura de chaves tem dois propósitos: detectar alterações em seu chaveiro e certificar que a chave realmente pertence a pessoa identificada pela ID da chave. Assinatura de chaves também são usadas em um esquema conhecido como rede de certificação para certificar chaves não assinadas diretamente por você, mas assinadas por outros que você confia. Usuários responsáveis que praticam um bom gerenciamento de chaves podem derrotar um ataque que visa alterar suas chaves numa comunicação segura com o GnuPG.
Um par de chaves tem uma chave pública e uma chave privada. Uma chave pública consiste da parte pública da chave principal de assinatura, na parte pública das chaves subordinadas de assinatura e encriptação e um conjunto de IDs de usuário usadas para associar uma chave pública com uma pessoa real. Cada pedaço destes tem dados sobre ele mesmo. Para uma chave, estes dados incluem sua ID, quando ela foi criada, sua data de validade, etc. Para cada ID, estes dados incluem o nome da pessoa, um comentário opcional e um endereço de email. A estrutura da chave privada é similar, exceto que ela contém apenas a parte privada das chaves, e não há informações referentes a ID do usuário.
A opção --edit-key pode ser usada para visualizar um par de chaves. Por exemplo,
chloe% gpg --edit-key chloe@cyb.org
Secret key is available.
pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u
sub 2048g/0CF8CB7A created: 1999-06-15 expires: never
sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14
sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14
(1) Chloe (Jester) <chloe@cyb.org>
(2) Chloe (Plebian) <chloe@tel.net>
Command>A chave pública é mostrada com uma indicação referente a existência ou não de uma chave privada. Então, informações sobre cada componente da chave pública são listadas. A primeira coluna indica o tipo de chave. A palavra-chave pub identifica a assinatura principal da chave pública e a palavra-chave sub indica uma chave pública subordinada. A segunda coluna indica o tamanho da chave em bits, o tipo e a ID. O tipo é D para uma chave DSA, g para uma chave ElGammal só de encriptação, e G para uma chave ElGammal que pode ser usada para encriptação e assinatura. A data de criação e a data de validade são dadas nas colunas três e quatro. As IDs do usuário são listadas abaixo das chaves.
Mais informação sobre a chave pode ser obtida com comandos interativos. O comando toggle alterna entre os componentes públicos e privados de um par de chaves se ambos estiverem disponíveis.
Command> toggle
sec 1024D/26B6AAE1 created: 1999-06-15 expires: never
sbb 2048g/0CF8CB7A created: 1999-06-15 expires: never
sbb 1792G/08224617 created: 1999-06-15 expires: 2002-06-14
sbb 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14
(1) Chloe (Jester) <chloe@cyb.org>
(2) Chloe (Plebian) <chloe@tel.net>A informação fornecida é similar a listagem dos componentes da chave pública. A palavra chave sec identifica a assinatura principal da chave privada, e a palavra-chave sbb identifica as chaves privadas subordinadas. As IDs de usuário da chave pública também são listadas por conveniência.
Quando você distribui sua chave pública, você está distribuindo os componentes públicos de suas chaves principal e subordinada assim como sua ID. Distribuir este material sozinho, porém, é um risco à segurança uma vez que é possível para um atacante interceptar a chave. A chave pública pode ser modificada pela adição ou substituição de chaves ou pela adição ou alteração de IDs. Com a alteração da ID, um atacante pode redirecionar o email para ele. Pela alteração de uma das chaves de encriptação, o atacante pode também ser capaz de decriptar as mensagens redirecionadas para ele.
Usar a assinatura digital é a solução para este problema. Quando os dados são assinados por uma chave privada, somente a chave pública correspondente pode ser usada para verificar a assinatura e garantir que os dados não foram modificados. Uma chave pública pode ser protegida de alterações através do uso de sua correspondente chave privada principal para assinar os componentes da chave pública e a ID. Assinar os componentes de uma chave pública com a assinatura da chave privada principal correspondente é chamado autenticar a assinatura, e uma chave pública que está assinada assim é chamada de chave certificada.
Como exemplo, Chloe tem duas IDs e três subchaves. As assinaturas das IDs podem ser checadas com o comando check.
chloe% gpg --edit-key chloe
Secret key is available.
pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u
sub 2048g/0CF8CB7A created: 1999-06-15 expires: never
sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14
sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14
(1) Chloe (Jester) <chloe@cyb.org>
(2) Chloe (Plebian) <chloe@tel.net>
Command> check
uid Chloe (Jester) <chloe@cyb.org>
sig! 26B6AAE1 1999-06-15 [self-signature]
uid Chloe (Plebian) <chloe@tel.net>
sig! 26B6AAE1 1999-06-15 [self-signature]Como esperado, a assinatura de chave para cada assinatura é a assinatura principal da chave com ID de chave 0x26B6AAE1. As autenticações de assinaturas de subchaves estão presentes na chave pública, mas não são exibidas na interface do GnuPG.
Tanto novas subchaves como novas IDs de usuários podem ser adicionadas ao seu par de chaves após ele ter sido criado. Uma ID é adicionada usando o comando adduid. Quando você faz isto é pedido o nome, email e um comentário. Uma subchave é adicionada usando o comando addkey. A interface é similar a usada quando da criação do par de chaves inicial. A subchave pode ser uma chave de assintaura DSA e uma ElGamal apenas para encriptação, ou uma ElGamal para assinatura e encriptação. Quando uma subchave ou ID é gerada, ela é autenticada usando sua assinatura principal, é por isso que você deve fornecer sua senha quando a chave é gerada.
IDs adicionais são úteis quando você precisa de várias identidades. Por exemplo, você pode ter uma identidade para seu trabalho e outra para sua atuação como ativista político. Os companheiros do trabalho te conhecerão pela ID do trabalho. Os companheiros do partido te conhecerão pela ID do ativista político.
Subchaves adicionais também são úteis. As IDs associadas com sua chave pública principal são validadas por pessoas com quem você se comunica e alterar a chave principal requer um recertificação. Isto pode dificultar e consumir tempo se você comunica com muitas pessoas. Por outro lado, é bom periodicamente alterar as subchaves de encriptação. Se uma chave é quebrada, todos os dados encriptados com esta chave estarão vulneráveis. Alterando as chaves, porém, apenas os dados encriptados com a chave quebrada serão revelados.
Subchaves e IDs também podem ser deletadas. Para deletar uma subchave ou ID você deve primeiro selecioná-la usando os comandos key ou uid respectivamente. Estes comandos são chaves liga-desliga. Por exemplo, o comando key 2 seleciona a segunda subchave e invocar key 2 novamente deseleciona a mesma. Se nenhum argumento extra é passado, todas subchaves ou IDs são deselecionadas. Uma vez que uma ID a ser deletada for selecionada, o comando deluid apagará a ID de sua chave. Da mesma maneira, o comando delkey apagará toda subchave selecionada para ambas as chaves, pública e privada.
Para o gerenciamento do seu chaveiro, deletar componentes é uma boa maneira de enxugar as chaves públicas das outras pessoas removendo material desnecessário. Deletar IDs e subchaves de sua própria chave, porém, não é uma boa opção uma vez que é complicado distribuir a chave. Por padrão, quando um usuário importa sua chave pública atualizada ela é fundida com a cópia antiga de sua chave pública se ela existir no chaveiro. Os componentes de ambas as chaves são combindos e isto efetivamente restaura qualquer componente anteriormente deletado. Para atualizar corretamente uma chave, o usuário deve primeiro deletar a versão antiga de sua chave e então importar a nova versão. Isto cria uma dificuldade extra para as pessoas com quem você se comunica. Além disso, se você envia sua chave para um servidor de chaves, a fundição acontecerá de qualquer maneira, e qualquer um que baixe sua chave do servidor nunca verá sua chave com os componentes deletados. Consequentemente, para atualizar sua chave é melhor revogar os componentes em vez de deletá-los.
Para revogar uma subchave ela deve estar selecionada. Uma vez selecionada ela pode ser revogada com o comando revkey. A chave é revogada através da adição de uma assinatura de revogação. Diferente do comando --gen-revoke, o efeito da revogação de uma subchave é imediato.
Command> revkey
Do you really want to revoke this key? y
You need a passphrase to unlock the secret key for
user: "Chloe (Jester) <chloe@cyb.org>"
1024-bit DSA key, ID B87DBA93, created 1999-06-28
pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/u
sub 2048g/B7934539 created: 1999-06-28 expires: never
sub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28
rev! subkey has been revoked: 1999-06-29
sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28
(1) Chloe (Jester) <chloe@cyb.org>
(2) Chloe (Plebian) <chloe@tel.net>Uma ID é revogada de maneira diferente. Normalmente, uma ID coleta assinaturas que atestam que ela descreve a pessoa associada a respectiva chave. Em teoria, uma ID descreve a pessoa para sempre, uma vez que a pessoa não mudará. Na prática, porém, elementos da ID como o email e comentários podem ser alterados com o tempo, então invalidam a ID.
A especificação OpenPGP não suporta revogação de ID, mas uma ID pode efetivamente ser revogada pela revogação da assinatura de autenticação. Por razões de segurança descritas anteriormente, não se deve confiar em uma ID com autenticação inválida.
A assinatura é revogada usando o comando revsig. Como você pode ter assinado muitas IDs, a interface lhe pergunta, para cada assinatura, se você deseja revogá-la ou não.
Command> revsig
You have signed these user IDs:
Chloe (Jester) <chloe@cyb.org>
signed by B87DBA93 at 1999-06-28
Chloe (Plebian) <chloe@tel.net>
signed by B87DBA93 at 1999-06-28
user ID: "Chloe (Jester) <chloe@cyb.org>"
signed with your key B87DBA93 at 1999-06-28
Create a revocation certificate for this signature? (y/N)n
user ID: "Chloe (Plebian) <chloe@tel.net>"
signed with your key B87DBA93 at 1999-06-28
Create a revocation certificate for this signature? (y/N)y
You are about to revoke these signatures:
Chloe (Plebian) <chloe@tel.net>
signed by B87DBA93 at 1999-06-28
Really create the revocation certificates? (y/N)y
You need a passphrase to unlock the secret key for
user: "Chloe (Jester) <chloe@cyb.org>"
1024-bit DSA key, ID B87DBA93, created 1999-06-28
pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/u
sub 2048g/B7934539 created: 1999-06-28 expires: never
sub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28
rev! subkey has been revoked: 1999-06-29
sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28
(1) Chloe (Jester) <chloe@cyb.org>
(2) Chloe (Plebian) <chloe@tel.net>Uma ID revogada é indicada pela assinatura de revogação na ID quando as assinaturas são listadas.
Command> check
uid Chloe (Jester) <chloe@cyb.org>
sig! B87DBA93 1999-06-28 [self-signature]
uid Chloe (Plebian) <chloe@tel.net>
rev! B87DBA93 1999-06-29 [revocation]
sig! B87DBA93 1999-06-28 [self-signature]Revogar as subchaves e assinaturas de autenticação em IDs adiciona a revogação de autenticação da chave. Desde que assinaturas estão sendo adicionadas e nenhum material é deletado, a revogação sempre estará visível para outros quando sua atualização da chave pública é distrbuída e fundida com cópias antigas. A revogação então garante que todos tem uma cópia consistente de sua chave pública.
A data de expiração de uma chave pode ser atualizada com o comando expire. Se nenhuma chave é selecionada, a data de expiração da chave primária é atualizada. Caso contrário a data de expiração da chave subordinada selecionada é atualizada.
A data de expiração de uma chave é associada com sua assinatura de autenticação. A data de expiração é atualizada deletando a assinatura de autenticação antiga e adicionando uma nova. Se os comunicantes não apagarem suas antigas assinaturas de autenticação, eles verão uma assinatura de autenticação adicional na chave quando atualizarem sua cópia. Porém, a última assinatura de autenticação tem precedência, assim todos comunicantes terão certeza da data de expiração das chaves.
No Capítulo 1 foi mostrado um procedimento para validar uma chave pública: uma chave pública é validada checando sua impressão digital e então, assinando esta chave pública com sua chave privada. Pela checagem da impressão digital você pode certificar-se se a chave realmente pertence a referida pessoa, e uma vez que você tenha assinado a chave, você pode detectar qualquer modificação no futuro. Infelizmente este procedimento não é operacional quando você tem que checar muitas chaves ou quando comunicar-se com pessoas que não conheçe pessoalmente.
GnuPG resolve este problema com um mecanismo popularmente conhecido como rede de certificação. No modelo de rede de certificação, a responsabilidade por validar uma chave pública é delegada a uma pessoa que você confia. Por exemplo, suponha
Alice assinou a chave de Blake, e
Blake assinou a chave de Chloe e de Dharma.
Se Alice confia em Blake para validar as chaves que ele assina, então Alice pode concluir que as chaves de Chloe e Dharma são válidas sem ter que pessoalmente checá-las. Ela simplesmente usa sua cópia validada da chave pública de Blake para checar se as assinaturas de Blake nas chaves de Chloe e Dharma são válidas. A idéia geral é que qualquer chave assinada com uma chave válida é também considerada válida.
Na prática confiar na certificação de outra pessoa é subjetivo. Por exemplo, a chave de Blake é válida para Alice porque ela assinou esta chave, mas ela pode não confiar tanto em Blake ao ponto de validar as chaves que ele assina. Neste caso, ela poderia não aceitar as chaves de Chloe e Dharma como válidas apenas pela assinatura de Blake. Para isto, o modelo de rede de certificação conta com uma indicação do nível de confiança para cada chave pública em seu chaveiro. Existem quatro níveis.
O nível de confiança de uma chave é algo que só você determina e é considerado uma informação privada. Ele não é empacotado com a chave quando esta é exportada; ele é sempre guardado separadamente do seu chaveiro em um banco de dados separado.
O editor de chaves do GnuPG pode ser usado para ajustar o nível de confiança de um determinado proprietário de chave. O comando é trust. Neste exemplo Alice edita o nível de confiança em Blake e atualiza o banco de dados para recomputar quais chaves são válidas baseadas na nova certificação de confiança de Blake.
alice% gpg --edit-key blake
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) <blake@cyb.org>
Command> trust
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) <blake@cyb.org>
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?
1 = Don't know
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
s = please show me more information
m = back to the main menu
Your decision? 3
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: m/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) <blake@cyb.org>
Command> quit
[...]O nível de confiança no proprietário da chave e a validade da chave são indicados a direita quando a chave é exibida. O nível de confiança é exibido primeiro e a validade da chave depois[4]. Os quatro níveis de confiança/validade são abreviados: unknown (q), none (n), marginal (m), e full (f). Neste caso, a chave de Blake tem o nível full. A chave de Blake é completamente válida uma vez que ela foi assinada pela própria Alice. Inicialmente ela não tinha referência sobre a confiança em Blake e o nível de confiança dele para assinar outras chaves era era unknown mas, ela decidiu alterar este nível para marginal.
A rede de certificação permite a utilização de um algoritmo mais elaborado para validar uma chave. Anteriormente, uma chave era considerada válida apenas se você a assinava pessoalmente. Um algoritmo mais flexível agora pode ser usado: uma chave K é considerada válida se ela atende duas condições:
ela é assinada por um número suficiente de chaves válidas:
você a assinou pessoalmente,
ela foi assinada por uma chave com nível de confiança full, ou
ela foi assinada por, no mínimo, três chaves com nível de confiança marginal; e
o caminho de chaves assinadas que conduzem K de volta a sua própria chave é de cinco passos ou menos.
O tamanho do caminho (path), o número de chaves com nível marginal e o número de chaves com nível full requeridos pode ser ajustado. Os números dados acima são os valores padrão usados pelo GnuPG.
A figura 3-1 mostra uma rede de certificação adotada por Alice. O gráfico ilustra quem assinou a chave de quem. A tabela mostra quais chaves Alice considera válidas baseada em sua certificação e na certificação de outros membros da rede. Este exemplo assume que duas chaves com nível marginal ou uma com nível full é necessário para validar outra chave. O tamanho máximo do caminho é 3.
Quando computando chaves válidas no exemplo, as chaves de Blake e Dharma são consideradas com nível full uma vez que elas foram assinadas diretamente por Alice. A validade das outras chaves depende do nível de confiança. No primeiro caso, Dharma está com nível full, o que implica que as chaves de Chloe e Francis são consideradas válidas. No segundo exemplo, Blake e Dharma tem o nível marginal. Uma vez que duas chaves com nível marginal são necessárias para validar uma chave, a chave de Chloe é considerada com nível full, mas a chave de Francis é considerada apenas marginal. No caso onde Chloe e Dharma estão no nível marginal, a chave de Chloe terá o nível marginal uma vez que a chave de Dharma tem nível full. Francis, porém, também será marginal pois somente uma chave full pode ser usada para validar outra chave e a chave de Dharma é a única chave full que foi usada para assinar a chave de Francis. Quando o nível marginal é adicionado a chave de Blake, a chave de Chloe torna-se full e pode então ser usada para validar a chave de Francis como full e a de Elena como marginal. Por último, quando Blake, Chloe e Elena estão no nível full, isto ainda é insuficiente para validar a chave de Geoff uma vez que o caminho máximo para certificação é três e o tamanho do caminho de Geoff até Alice é quatro.
O modelo de rede de certificação é uma abordagem flexível para o problema de troca de chaves públicas em segurança. Ele lhe permite sintonizar o GnuPG para refletir como você o usa. Em um extremo voçê pode insistir em vários pequenos caminhos de sua chave para outra chave K para certificá-la. De outra maneira, você pode estar satisfeito com longos caminhos e talvez um caminho direto de sua chave para outra chave K. Requerer pequenos caminhos é uma forte garantia que K realmente é de quem você imagina que seja. O preço é claro, é que é mais difícil validar chaves uma vez que você deve pessoalmente assinar mais chaves que se você aceitar alguns poucos e longos caminhos.
Figura 3-1. Uma hipotética rede de certificação
|
nível de confiança |
validade |
||
|---|---|---|---|
|
marginal |
full |
marginal |
full |
|
|
Dharma |
|
Blake, Chloe, Dharma, Francis |
|
Blake, Dharma |
|
Francis |
Blake, Chloe, Dharma |
|
Chloe, Dharma |
|
Chloe, Francis |
Blake, Dharma |
|
Blake, Chloe, Dharma |
|
Elena |
Blake, Chloe, Dharma, Francis |
|
|
Blake, Chloe, Elena |
|
Blake, Chloe, Elena, Francis |
O ideal é você distribuir sua chave pessoalmente para as pessoas com as quais vai comunicar-se. Na prática, porém, as chaves são sempre distribuídas via email ou algum outro meio de comunicação eletrônico. Distribuição por email é uma boa prática quando você tem apenas alguns correspondentes, e mesmo se você tem muitos correspondentes, você pode usar um meio alternativo como postar sua chave pública em sua home page. Isto é inaceitável, porém, se as pessoas que precisam de sua chave pública não sabem onde encontrá-la na Web.
Para resolver este problema, servidores de chave pública são usados para coletar e distribuir chaves públicas. Uma chave pública recebida pelo servidor é adicionada ao banco de dados do servidor e fundida com uma chave já existente, se for o caso. Quando uma chave é requerida ao servidor, este consulta seu banco de dados e retorna a chave pública encontrada.
Um servidor de chaves também é valioso quando muitas pessoas estão freqüentemente assinando as chaves de outras. Sem um servidor de chaves, quando Blake assinasse a chave de Alice ele emitiria para ela uma cópia da chave pública assinada por ele de modo que Alice poderia adicionar a chave atualizada ao seu chaveiro e distribuí-la para todos seus correspondentes. Este esforço de Alice de Blake é importantíssimo para construir certificados válidos e confiáveis e aumentar a segurança do PGP. Porém, é incômodo assinar chaves frequentemente.
Usar um servidor de chaves torna este processo bem mais fácil. Quando Blake assina a chave de Alice ele envia a chave assinada para o servidor de chaves. O servidor adiciona a assinatura de Blake a sua cópia da chave de Alice. Pessoas interessadas em atualizar sua cópia da chave de Alice então consultam o servidor. Alice não precisa se envolver com a distribuição e pode recuperar assinaturas em sua chave simplesmente pesquisando um servidor de chaves.
Uma ou mais chaves podem ser envidaas para um servidor de chaves usando a opção de comando --send-keys. Esta opção pega uma ou mais chaves e as envia para o servidor. O servidor de chaves é especificado com a opção --keyserver. Da mesma maneira, a opção --recv-keys é usada para recuperar chaves de um servidor, mas a opção --recv-keys requer que uma ID de chave seja usada para especificar a chave. No exemplo seguinte Alice atualiza sua chave pública com novas assinaturas dos servidor de chaves certserver.pgp.com e então envia sua cópia da chave pública de Blake para o mesmo servidor a fim de contribuir com novas assinaturas.
alice% gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC
gpg: requesting key BB7576AC from certserver.pgp.com ...
gpg: key BB7576AC: 1 new signature
gpg: Total number processed: 1
gpg: new signatures: 1
alice% gpg --keyserver certserver.pgp.com --send-key blake@cyb.org
gpg: success sending to 'certserver.pgp.com' (status=200)Existem vários servidores de chaves ao redor do mundo. Os maiores servidores estão sincronizados entre eles, assim é uma boa idéia escolher um próximo de você e usá-lo para enviar e receber chaves.
GnuPG é uma ferramenta complexa com aspectos técnicos, sociais e legais. Tecnicamente, ela foi projetada para ser usada em situações com necessidades diversas de segurança. Isto complica o gerenciamento de chaves. Socialmente, usar o GnuPG não é estritamente uma decisão pessoal. Para usar o GnuPG efetivamente as duas partes da comunicação deve usá-lo. Finalmente, como em 1999, leis sobre encriptação digital, e em particular sobre se ou não usar o GnuPG é legal, variam de país para país e atualmente são um assunto que está sendo debatido por muitos governos.
Este capítulo aborda estes aspectos. Ele aconselha como usar o GnuPG para descobrir suas necessidades de segurança. Ele também sugere maneiras de promover o uso do GnuPG para implementar comunicações seguras entre você e seus amigos quando estes não estão usando o GnuPG. Finalmente, o status legal do GnuPG é esboçado dando uma visão das leis de encriptação no mundo.
GnuPG é uma ferramenta que você usa para proteger sua privacidade. Sua privacidade está protegida se você pode corresponder-se com outros sem que os curiosos ou abelhudos leiam as mensagens.
Como você deve usar o GnuPG depende da determinação e perseverança daqueles que podem querer ler suas mensagens encriptadas. Um curioso pode ser um inescrupuloso administrador de sistemas casualmente scaneando sua caixa de correios, pode ser um espião industrial tentando coletar os segredos de sua empresa, ou pode ser um agente da lei tentando te encriminar. Usar o GnuPG para proteger-se contra um curioso casual é diferente de usá-lo para proteger-se contra um adversário determinado. Seu objetivo, finalmente, é fazer com que a consquista dos dados pelo inimigo custe bem mais caro que o valor real destes dados.
A personalização do uso do GnuPG gira em torno de quatro fatores:
escolha do tamanho do seu par de chaves pública/privada,
proteção de sua chave privada,
seleção da data de expiração e uso de subchaves, e
gerenciamento de seus certificados.
A escolha de um bom tamanho de chave protege você contra ataques de força bruta em mensagens encriptadas. Proteger sua chave privada evita que um atacante simplesmente use-a para decriptar mensagens e assinar mensagens em seu nome. Gerenciar corretamente seus certificados evita que atacantes consigam disfarçar como se fossem pessoas com as quais você se comunica. Finalmente, gerenciar estes fatores respeitando suas próprias necessidades de segurança é como você conduzirá o trabalho extra requerido para usar o GnuPG com toda a privacidade que ele oferece.
Selecionar um tamanho de chave vai depender da chave utilizada. No OpenPGP, um par de chaves pública/privada normalmente tem várias chaves. No mínimo ele tem uma chave de assinatura principal e provavelmente uma ou mais subchaves adicionais para encriptação. Usando o GnuPG com as opções padrão de geração de chaves, a chave principal será uma chave DSA e as subchaves serão chaves ElGamal.
O DSA permite uma chave de até 1024 bits. Isto não é bom devido a tecnologia atual, mas é o que o padrão especifica. Sem dúvidas, você deve usar chaves DSA de 1024 bits.
Chaves ElGamal, por outro lado, podem ter qualquer tamanho. Uma vez que o GnuPG é um sistema de chave pública híbrido, a chave pública é usada para encriptar uma sessão de chaves de 128 bits e a chave privada é usada para decriptá-la. Porém, o tamanho da chave afeta a velocidade de encriptação e decriptação uma vez que o tempo de execução destes algoritmos cresce exponencialmente de acordo com o tamanho da chave. Chaves maiores também levam mais tempo para serem geradas e ocupam mais espaço de armazenamento. Finalmente, existe o fator da segurança extra que uma chave maior oferece a você. Assim, se a chave é grande o bastante para resistir a um ataque de força bruta, um atacante provavelmente procurará outro método para obter seus dados. Exemplos de outros métodos incluem invadir sua casa ou escritório e atacá-lo. Então, 1024 bits é o tamanho de chave recomendado. Se você precisa de um tamanho de chave maior que isto você provavelmente já sabe do seu problema e deve consultar um expert em segurança de dados.
Proteger sua chave privada é a coisa mais importante para usar o GnuPG corretamente. Se alguém consegue sua chave privada, então todos os dados encriptados com ela podem ser decriptados e assinaturas podem ser feitas em seu nome. Se perder sua chave privada, você não será capaz de decriptar documentos encriptados para você no futuro ou no passado, e você não poderá fazer assinaturas. Em suma, perder sua chave privada é catastrófico.
Seja qual for o modo como você usa o GnuPG, você deve copiar seu certificado de revogação da chave e uma cópia de sua chave privada em uma mídia protegida contra escrita e guardar esta em um lugar seguro. Por exemplo, você poderia queimar um CD-ROM, colocá-lo num envelope lacrado e guardar o envelope num local seguro (cofre, gaveta, armário, etc.). Outra alternativa é copiar num disquete e guardar este num local secreto. Seja como for, estes dados devem ser colocados numa mídia pelo tempo que você usar a chave e guardados com mais cuidado que a própria chave privada que você usa diariamente.
Para ajudar a salvaguardar sua chave, GnuPG não armazena sua chave no estado original. Em vez disso ele encripta a chave usando um algoritmo de encriptação simétrico. É por isso que você precisa de uma senha para acessar a chave. Assim existem duas barreiras que um atacante deve transpor para poder acessar sua chave: (1) ele deve realmente pegar a chave, e (2) deve pegá-la antes da encriptação.
Guardar sua chave privada em segurança é importante, mas há um custo. O ideal seria você manter a chave privada em um disco removível protegido contra gravação, como um disquete, e usá-lo em uma máquina não conectada a uma rede. Isto pode ser inconveniente ou impossível para você. Por exemplo, você pode não possuir uma máquina e ter que usar um computador no trabalho ou na escola, ou pode significar que você tenha que desconectar fisicamente seu computador do modem toda vez que quiser usar o GnuPG.
Isto não significa que você não pode ou não deve usar o GnuPG. Isto significa apenas que você tem que decidir que os dados que você está protegendo são importantes o bastante para serem encriptados mas não tão importantes que exijam passos extra para tornar a primeira barreira mais forte. Esta é uma escolha sua.
Uma boa senha é absolutamente crítico ao usar o GnuPG. Qualquer atacante que descubra a senha e ganhe acesso a sua chave privada não precisará quebrar a encriptação dela. Em vez do ataque de força bruta contra a chave, certamente um atacante tentará supor qual é a senha dela.
A motivação para tentar descobrir a senha é que a maioria das pessoas escolhe senhas mais fáceis de serem descobertas do que uma chave de 128 bits aleatória. Se a senha é uma palavra, é bem melhor tentar todas as palavras em todos os dicionários do mundo. Mesmo se a palavra está com as letras trocadas, por exemplo k3widood, ainda é fácil tentar um dicionário de palavras com um catálogo de permutações. O mesmo problema aplica-se as citações. Em geral, senhas baseadas num idioma são senhas fracas uma vez que há pouca aleatóriedade e muita redundância num idioma natural. Você deve evitar senhas baseadas em idiomas naturais.
Uma boa senha é aquela que você pode lembrar-se mas que é difícil de alguém adivinhar. Ela deve incluir caracteres de todo o conjunto de caracteres imprimíveis do seu teclado. Isto inclui usar letras maiúsculas e minúsculas, números e caracteres especiais como } e |. Seja criativo e gaste um pouco de tempo criando sua senha; uma boa escolha é importante para garantir sua privacidade.
Por padrão, uma chave principal DSA de assinatura e uma subchave ElGamal de encriptação são geradas quando você cria um novo par de chaves. Isto é conveniente porque as funções das duas chaves são diferentes e você pode, então, querer que o tempo de vida destas chaves sejam diferentes. A chave principal de assinatura é usada para fazer assinaturas digitais e também coleta as assinaturas dos outros que tem sua identidade confirmada. A chave de encriptação e usada apenas para decriptar documentos encriptados enviados para você. Tipicamente, uma assinatura digital tem um longo tempo de vida, por exemplo, para sempre, e você também não quer perder as assinaturas que você demorou muito para juntar. Por outro lado, a subchave de encriptação pode ser alterada periodicamente para uma segurança extra, uma vez que se ela for quebrada, um atacante poderá ler todos os documentos encriptados para aquela chave no futuro e no passado.
É quase certo que você nunca vai querer que sua chave principal expire. Existem duas razões pelas quais você pode querer uma data de expiração. Primeiro, você pode ter a intenção que a chave tenha um tempo de vida limitado. Por exemplo, ela está sendo usada para um evento como uma campanha política e não será usada mais após o término da campanha. Outra razão é que se você perder o controle sob a chave e não tiver um certificado de revogação para revogar a chave, ter uma data de expiração garante que a chave eventualmente caia em desuso.
Alterar as subchaves de encriptação é fácil mas pode ser inconveniente. Se você gerar um novo par de chaves com uma data de expiração para a subchave, esta expirará. Logo, antes da expiração você adicionará uma nova subchave e divulgará sua chave pública atualizada. Uma vez que a subchave expire, aqueles que desejam corresponder-se com você devem encontrar a atualização da sua chave pois eles não serão mais capazes de encriptar para a chave que expirou. Isto pode ser inconveniente dependendo de como você distribui sua chave. Felizmente, porém, nenhuma assinatura extra é necessária uma vez que a nova subchave será assinada com sua chave principal de assinatura, a qual provavelmente já foi validada por seus correspondentes.
A inconveniência pode ou não valer a segurança extra. Assim como você, um atacante ainda pode ser todos os documentos encriptados para uma subchave expirada. Alterar as subchaves apenas protege os documentos futuros. Para ler documentos encriptados com a nova subchave, o atacante teria que montar um novo ataque usando as mesmas técnicas que ele usou contra você da primeira vez.
Finalmente, é sensato ter apenas uma subchave de encriptação válida em um chaveiro. Não há nenhum ganho adicional de segurança em ter duas ou mais subchaves ativas. Naturalmente pode existir qualquer número de chaves expiradas em um chaveiro para que os documentos encriptados no passado ainda possam ser decriptados, mas apenas uma subchave precisa estar ativa.
Assim como proteger sua chave privada, gerenciar seus certificados é outro aspecto do uso do GnuPG que requer equilíbrio entre segurança e facilidade de uso. Se você está usando o GnuPG para proteger-se contra eventuais curiosos e picaretas então você pode até confiar relativamente nos certificados de assinaturas de outras pessoas. Por outro lado, se você está desconfiado que pode existir um atacante determinado interessado em invadir sua privacidade, então você deve confiar menos em outras assinaturas e gastar mais tempo verificando pessoalmente estas.
Qualquer que seja seu nível de necessidade de segurança, você sempre deve ser cuidadoso quando assinar outras chaves. É muito importante ter certeza da confiabilidade da chave ao assiná-la. Outros, com necessidades de seguranaça maiores podem depender da sua assinatura. Se eles não puderem confiar em você então o sistema de rede de certificação não será confiável e isto dificultará a comunicação entre os usuários do GnuPG. Tenha a mesma responsabilidade que você quer que os outros tenham ao assinar chaves das quais você dependerá.
Na prática, gerenciar seus certificados reduz-se a certificar as assinaturas de outros e configurar as opções --marginals-needed e --completes-needed. Qualquer chave que você assinou pessoalmente é considerada válida, mas exceto para pequenos grupos, não será prático assinar pessoalmente as chaves de todas as pessoas com as quais você se comunica. Então, você terá que certificar as assinaturas que outros fizeram.
É muito importante ser cuidadoso quando certificar assinaturas e quando usar as opções de configuração que ditam como o GnuPG irá tratar as validações de chaves. Como um exemplo concreto, você pode confiar completamente em alguns poucos amigos que você realmente sabe que são cuidadosos com assinaturas de chaves e não confiar tanto nos outros. Assim, você pode configurar --completes-needed para 1 e --marginals-needed para 2. Se você quer mais segurança pode escolher os valores 1 e 3 ou 2 e 3 respectivamente. Se você está menos preocupado com ataques e quer apenas uma razoável privacidade, use os valores 1 e 1. Em geral, números maiores que estes implicam que seriam necessárias mais pessoas para conspirar contra você e lhe passar uma chave validada que realmente não pertence a pessoa que você imagina.
Querer usar o GnuPG não é o bastante. Para comunicar-se com segurança com outras pessoas você deve ter uma rede de certificados. A primeira vista, porém, construir uma rede de certificados é uma tarefa desencorajadora. As pessoas com as quais você se comunica precisam usar o GnuPG[5] e elas devem ter muitas chaves assinadas para que estas sejam consideradas válidas. Estes não são problemas técnicos; são problemas sociais. Entretanto, você deve superar estes problemas se quiser usar o GnuPG.
Ao iniciar o uso do GnuPG é importante observar que você não necessita comunicar-se seguramente com todos os seus correspondentes. Inicie com um pequeno círculo de pessoas, talvez apenas você e uma ou duas pessoas que também querem exercer seu direito de privacidade. Gere suas chaves e assine cada uma das chaves públicas dos outros. Esta é sua rede de certificados inicial. Fazendo isto você apreciará o valor de uma pequena e robusta rede de certificados e será mais cauteloso quando aumentar sua rede no futuro.
Aumentando sua rede inicial você pode querer comunicar-se seguramente com outros que também usam o GnuPG. Fazer isto, porém, pode ser difícil por duas razões: (1) você nem sempre sabe quando alguém usa ou está disposto a usar o GnuPG, e (2) se você sabe que alguém usa, ainda tem o problema da validação da chave. O primeiro motivo ocorre porque as pessoas nem sempre avisam que usam o GnuPG. A maneira de alterar este comportamento é dar o exemplo e avisar que você mesmo usa. Existem no mínimo três maneiras de fazer isto: você pode assinar as mensagens de email para outros ou postar para message boards, você pode colocar sua chave pública em uma web page, ou, se você colocar sua chave em um servidor de chaves, pode adicionar a ID de sua chave na assinatura do email. Se você divulgar sua chave então ela estará acessível aos outros e provavelmente eles divulgarão suas chaves. Além disso, você facilitou aos outros iniciar uma comunicação segura com você uma vez que você tomou a iniciativa e deixou claro que usa o GnuPG.
A validação das chaves é mais difícil. Se você não conheçe pessoalmente o correspondente cuja chave quer assinar, então não é possível assiná-la você mesmo. Você terá que confiar nas assinaturas dos outros e ter esperança de encontrar uma cadeia de assinaturas que leve da chave em questão até a sua. Para ter alguma chance disto dar certo, você deve tomar a iniciativa e pegar sua chave assinada por outros fora da rede inicial de certificados. Uma maneira efetiva para isto é participar de grupos de assinatura de chaves. Se você entrar num grupo de assinatura de chaves e ver que ele não está sendo mantido, ofereça-se para mantê-lo. Você também pode ser mais passivo e carregar sua impressão digital com você para a troca de chaves pessoalmente. Nesta situação a pessoa a quem você der sua impressão digital poderá verificá-la e assinar sua chave pública quando retornar para casa.
Porém, tenha em mente que isto é opcional. Você não tem obrigação de divulgar publicamente sua chave ou assinar as chaves de outras pessoas. O poder do GnuPG é que ele é flexível o bastante para adaptar-se às suas necessidades de segurança quaisquer que sejam elas. A realidade social, porém, é que você precisa tomar a iniciativa se quiser aumentar sua rede de certificados e usar o GnuPG o máximo possível.
As implicações legais dos softwares de encriptação variam de país para país e as leis referentes a isto estão evoluindo rapidamente. Bert-Japp Koops tem o execelente Crypto Law Survey o qual você deve consultar para saber sobre a parte legal acerca dos softwares de encriptação em seu país.
Este capítulo cobre tópicos que não se enquadraram em outro lugar neste manual. Quando são adicionados, os tópicos podem ser colocados em seus próprios capítulos. Se você gostaria de ver um tópico em particular, dê a sugestão. Ou melhor, seja voluntário para escrever o primeiro esboço do tópico sugerido!
Alma Whitten e Doug Tygar fizeram um estudo sobre a interface NAI's PGP 5.0 e chegaram a conclusão que os iniciantes achavam o PGP confuso e frustrante. Das doze pessoas sujeitas ao teste, apenas quatro gerenciaram corretamente o envio de email encriptado para os membros de sua equipe e três enviaram o segredo sem encriptação. Além disso, metade dos participantes tinha formação técnica.
Estes resultados não surpreendem. O PGP 5.0 tem uma boa interface que é excelente se você já entende como a encriptação de chave-pública trabalha e está familiarizado com o modelo de gerenciamento de certificados especificado pelo OpenPGP. Infelizmente, iniciantes não entendem nem a encriptação de chave-pública nem o gerenciamento de chaves e a interface quase não ajuda neste caso.
Certamente se você está escrevendo uma interface deve ter lido o relatório de Whitten e Tygar. Ele fornece comentários específicos sobre cada dificuldade encontrada pelos participantes e estas são ressaltadas. Por exemplo, parece que muitos dos participantes do estudo acreditavam que a mensagem enviada deveria ser encriptada com sua chave pública. Pare um minuto e você verá que isto é fácil de confundir. Em geral os iniciantes tem dificuldade de entender as funções das chaves pública e privada ao usar o GnuPG. Como projetista de interface você deve tentar deixar bem claro qual das duas chaves está sendo usada naquele momento. Você também pode introduzir tutores ou outras técnicas de GUI para guiar o usuário através das tarefas mais comuns, como a geração de chaves onde passos extra como a gerar um certificado de revogação e fazer um backup são essenciais para o uso correto do GnuPG. Outros comentários interessantes acerca do relatório são:
Segurança é normalemente um objetivo secundário; as pessoas querem enviar email, navegar e só. Não pense que os usuários estarão motivados para ler manuais ou procurar por controles de segurança.
A segurança de um computador em rede pode ser muito forte, mas também pode ser seu componente mais fraco. Usuários precisam ser orientados para atender a todos os aspectos de sua segurança, não devem ser deixados livres para explorar todas as potencialidades do programa como podem fazer com os processadores de texto ou as planilhas eletrônicas.
Utilize os mesmos termos para as mesmas ações. Não alterne entre sinônimos como “encriptar” e “cifar”.
Para usuários inexperientes, simplifique a tela. Muita informação esconde a informação importante. Uma tela de configuração inicial poderia concentrar ou dar ao usuário o modelo correto do relacionamento entre a chave pública e a chave privada e clarear o entendimento das funções para aquisição e distribuição das referidas chaves.
Desenhar uma interface de usuário eficaz para o gerenciamento de chaves é realmente mais difícil. O modelo de rede de certificados do Open-PGP infelizmente é bem complicado. Por exemplo, a especificação impõe três arbitrários níveis de confiança ao usuário: nenhum, marginal e completo. Todos os graus de confiança devem estar num destes três níveis. O algoritmo de validação de chaves também é muito difícil para quem não é técnico na área entender, particularmente as noções de “necessidade marginal” e “necessidade completa”. Como este modelo é bem específico e não pode ser alterado, você terá que projetar o melhor e fazer uma interface que ajude a clarear tudo isto para o usuário. Um aperfeiçoamento definitivo, por exemplo, poderia ser gerar um diagrama de como uma chave foi validada quando requisitado pelo usuário. Comentários relevantes do relatório incluem:
Usuários não tem certeza de como e quando garantir acessos.
Coloque em alta prioridade garantir que os usuários entendam sua segurança o bastante para prevenir erros potenciais. Erros potenciais incluem apagar a chave privada, publicar a chave privada, acidentalmente revogar a chave, esquecer a senha e não conseguir recuperar as chaves do chaveiro.
Version 1.1, March 2000
Copyright (C) 2000 Free Software Foundation,
Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone
is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.
The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).
State on the Title page the name of the publisher of the Modified Version, as the publisher.
Preserve all the copyright notices of the Document.
Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
Include an unaltered copy of this License.
Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.
Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers arou