Dada uma chave pública em hexadecimal, como posso obter um arquivo .asc?

Pelo que entendi, o RSA recebe texto simples (qualquer dado) e a chave pública do receptor (um número longo) e gera texto cifrado. Portanto, não devo precisar de nada mais do que este número para enviar uma mensagem criptografada.

Tecnicamente sim, se você fizer tudo "à mão" e se esperar que o destinatário desfaça tudo à mão. Mas mesmo assim, já existem vários problemas.

Primeiro, o RSA aceita apenas textos simples muito curtos . Você não pode usá-lo para criptografar uma mensagem de e-mail inteira. (Depende do tamanho da chave e do preenchimento usado, que você deve usar para que a criptografia RSA seja segura, mas) o uso geral é que nunca se usaria RSA para criptografar diretamente os dados reais - sempre usaria no "modo híbrido", onde o AES (ou similar) criptografa o texto simples e o RSA criptografa apenas a chave AES.

Portanto, na prática, você precisa concordar com o destinatário sobre qual preenchimento RSA usar, qual cifra simétrica usar, qual modo de cifra de bloco usar (se aplicável), qual esquema MAC usar, em que ordem aplicar as operações (por exemplo, criptografia então-MAC), etc.

Uma das razões para usar "arquivos de chave pública padrão" como .asc(que contém certificados OpenPGP) ou .pem/ .crt(que contém certificados X.509) é que esses sistemas já têm essas coisas definidas. Quando você tem um arquivo .asc e o entrega a um software PGP como o GnuPG, ele não usará RSA bruto, ele já foi projetado para usar o modo híbrido.

Estou tentando usar a chave X.509 em um VCard para enviar um email criptografado.

A segunda coisa é que você já tinha um arquivo de chave pública padrão – você tinha um certificado X.509 perfeitamente bom no vCard (ou seja, um .crtarquivo), pronto para usar para criptografia usando o padrão S/MIME ou CMS. Não há necessidade de extrair sua chave pública e criar um arquivo totalmente novo – é provável que seu aplicativo de e-mail possa importar o certificado X.509 diretamente do vCard e até mesmo usá-lo automaticamente para criptografia.

(A popular suíte GnuPG vem com uma gpgsmferramenta que recebe certificados X.509 e faz criptografia/descriptografia S/MIME assim como gpgo PGP.)

E relacionado a isso: se você recebeu um certificado X.509, isso implica fortemente que o destinatário espera que você criptografe as mensagens no formato S/MIME. Suponha que você extraiu a chave pública RSA (módulo) de qualquer maneira e, em seguida, usou algumas ferramentas para colocá-la em um arquivo .asc – ou seja, um certificado OpenPGP – e procedeu ao envio de uma mensagem de e-mail criptografada no formato PGP. O destinatário não seria capaz de descriptografá-lo, seja porque seu software de e-mail não reconhece PGP/MIME em primeiro lugar (muitos aplicativos só fazem S/MIME), ou porque sabe que não pode corresponder uma mensagem PGP com um par de chaves privado X.509 de qualquer maneira (mesmo as pessoas que usam PGP e S/MIME quase universalmente terão pares de chaves diferentes para ambos).

(Bem, tecnicamente eles poderiam descriptografá-lo seguindo o mesmo procedimento que você fez, convertendo o certificado X.509 e a chave privada nos equivalentes do OpenPGP – mas por que eles se incomodariam em fazer isso, eu realmente não sei. E novamente , isso é algo que eles precisam saber sobre como fazer - ou seja, assim como as cifras a serem usadas, é outro parâmetro que precisa ser acordado.)

Como posso transformar esse número em um arquivo de chave pública padrão (por exemplo, .asc)?

Para completar, é possível pegar uma chave pública RSA bruta existente e envolvê-la em um certificado PGP ou X.509? Sim, quase, mas não exatamente. Há ainda mais problemas aqui.

Primeiro, para o PGP não há muitas ferramentas que possam ser usadas dessa maneira. (E surpreendentemente, o PGP é o formato mais complexo dos dois, então eu não tentaria fazê-lo manualmente.) Se eu precisasse, provavelmente começaria com a biblioteca Sequoia.

Fazer o contrário e criar certificados X.509 é tecnicamente uma tarefa mais fácil, pois o formato é "apenas" ASN.1, então eu usaria o Net::OpenSSL do Ruby ou o python-certbuilder do Python ou algo semelhante. Na verdade, é uma tarefa comum porque é assim que as CAs emitem certificados em primeiro lugar – elas já precisam copiar o pubkey bruto de um .csr em um certificado novo antes de assiná-lo.

Isso leva ao segundo problema. Se você estiver criando um certificado X.509, algo precisa assinar esse certificado para que seus programas S/MIME o aceitem. Ele não pode ser "autoassinado" porque você não tem a chave privada para isso, então você precisará fazer seu próprio certificado S/MIME CA interno para essa finalidade.

E se você estiver criando um certificado PGP, é um pouco mais difícil porque seus subpacotes devem ser autoassinados pela mesma chave (também conhecido como "assinaturas de ligação de subchave"), precisamente para evitar que alguém anexe IDs de usuário falsos ao seu certificado, ou distribuindo um certificado real com subchaves falsas agrupadas. Sem a chave privada correspondente, você não conseguirá criar um .ascarquivo que as ferramentas modernas de PGP aceitem.

(É muito mais fácil se você tiver a chave privada : você pode importar o par de chaves X.509 (arquivo .p12 ou .pfx) para gpgsm, que compartilha seu armazenamento de chave privada com gpg – então use gpg para "gerar" um nova chave PGP no modo especialista e selecione a opção de usar um par de chaves existente quando solicitado. O programa fará tudo por você.)

Portanto, o único formato padrão relevante que você pode produzir é uma chave pública PKCS # 1 ou PKCS # 8 "semi-raw", do tipo com o qual as ferramentas openssl rsae openssl pkeylidam - não possui metadados, apenas o módulo RSA real e o expoente. Agora, esse formato ainda pode ser útil em algumas situações (e você nem precisa criar esse arquivo manualmente - o OpenSSL pode extraí-lo de um certificado X.509, se solicitado), por exemplo, talvez você possa usá-lo com manual openssl cmsinvocação para criar uma mensagem de e-mail S/MIME, mas... você pode usar todo o certificado X.509 para fazer a mesma coisa.