Qual é a diferença de desempenho de PKI para criptografia simétrica?

StackOverflow https://stackoverflow.com/questions/118463

Pergunta

Estamos procurando fazer alguns requisitos de segurança pesado em nosso projeto, e precisamos fazer um monte de criptografia que é altamente performance.

Eu acho que eu sei que PKI é muito mais lento e mais complexo do que a criptografia simétrica, mas não consigo encontrar os números para fazer backup de meus sentimentos.

Foi útil?

Solução

Sim, a criptografia assimétrica puramente é muito mais lento do que cifras simétricas (como DES ou AES), razão pela qual aplicações reais usar híbrido criptografia: as operações de chave pública-caros são realizados apenas para criptografar (e troca) uma chave de criptografia para o algoritmo simétrico que vai ser usado para criptografar a verdadeira mensagem

.

O problema que de chave pública resolve criptografia é que não há nenhum segredo compartilhado. Com uma criptografia simétrica você tem que confiar todas as partes envolvidas para manter o segredo chave. Esta questão deve ser uma preocupação muito maior do que o desempenho (que podem ser atenuados com uma abordagem híbrida)

Outras dicas

em um MacBook rodando Mac OS X 10.5.5 e um aumento dos stocks de OpenSSL, relógios "velocidade OpenSSL" AES-128-CBC em 46.000 1.024 blocos de bits por segundo. Essa mesma caixa de relógios de 1024 bits RSA em 169 assinaturas por segundo. AES-128-CBC é o "livro" algoritmo de criptografia bloco, e RSA 1024 é o algoritmo de chave pública "livro". É de maçãs com laranjas, mas a resposta é:. RSA é muito, muito mais lento

Não é por isso que você não deve estar usando criptografia de chave pública, no entanto. Eis as verdadeiras razões:

  1. operações de criptografia de chave pública são não destinado a dados brutos de criptografia . Algoritmos como Diffie-Hellman e RSA foram concebidos como uma forma de troca de chaves para algoritmos de criptografia bloco. Assim, por exemplo, você pode usar um gerador de números aleatórios seguro para gerar uma chave de 128 aleatória para bit AES, e criptografar esses 16 bytes com RSA.

  2. Algoritmos como RSA são muito menos "user-friendly" do que AES . Com uma chave aleatória, um bloco de texto simples que você alimenta a AES vai sair aleatoriamente para qualquer pessoa sem a chave. Isso não é realmente o caso com a RSA, que é --- mais do que AES --- apenas uma equação matemática. Assim, além de armazenamento e gerenciamento de chaves corretamente, você tem que ser extremamente cuidadoso com a maneira que você formatar os blocos de texto simples RSA, ou você acaba com vulnerabilidades.

  3. Chave pública não funciona sem uma infra-estrutura de gerenciamento de chave . Se você não tem um sistema para verificar as chaves públicas, os atacantes podem substituir os seus próprios pares de chaves para os reais para lançar "man in the middle" ataques. É por isso que SSL obriga a passar pela rigamarole de certificados. Bloco algoritmos de criptografia como AES do sofrem com este problema também, mas sem uma PKI, AES não é menos seguro do que RSA.

  4. operações de criptografia de chave pública são suscetíveis a mais vulnerabilidades de implementação do que AES . Por exemplo, ambos os lados de uma transação RSA tem que concordar com parâmetros , que são números alimentados à equação RSA. Há valores maus invasores podem substituir-se para criptografia silenciosamente desativar. O mesmo vale para Diffie Hellman e ainda mais para Elliptic Curve. Outro exemplo é a vulnerabilidade Falsificação RSA Assinatura que ocorreu 2 anos em várias implementações de SSL high-end.

  5. Usando chave pública é prova de que você está fazendo algo "fora do comum" . Fora do comum é exatamente o que você não quero estar com criptografia; além de apenas os algoritmos, cripto projeta são auditados e testados por anos antes de serem considerados seguros.

Para os nossos clientes que querem usar criptografia em seus aplicativos, fazemos duas recomendações:

  • Para "dados em repouso", o uso PGP . Realmente! PGP foi batida por mais de uma década e é considerada segura com os erros de implementação mudos. Há código aberto e variantes comerciais do mesmo.

  • Para "dados em vôo", o uso de TLS / SSL . Nenhum protocolo de segurança no mundo é melhor compreendida e melhor testado que TLS; instituições financeiras em todos os lugares aceitá-lo como um método seguro para mover os dados mais sensíveis.

Aqui está uma decente writeup [Matasano. com] mim e Nate Lawson, um criptógrafo profissional, escreveu-se há alguns anos atrás. Abrange esses pontos com mais detalhes.

Use o OpenSSL speed comando para referência os algoritmos e veja para si mesmo. 

[dave@hal9000 ~]$ openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 26126940 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 7160075 aes-128 cbc's in 3.00s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     139343.68k   152748.27k   155215.70k   155745.61k   157196.29k


[dave@hal9000 ~]$ openssl speed rsa2048
Doing 2048 bit private rsa's for 10s: 9267 2048 bit private RSA's in 9.99s
Doing 2048 bit public rsa's for 10s: 299665 2048 bit public RSA's in 9.99s
...
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.001078s 0.000033s    927.6  29996.5

sistemas de codificação baseados em PKI prático utilizar a criptografia assimrica para cifrar uma chave simétrica, e, em seguida, a criptografia simétrica com aquela chave para encriptar os dados (tendo dito que, alguém irá apontar um contra-exemplo).

Assim, a sobrecarga adicional imposta pelos algoritmos de criptografia assimétrica em relação à de simétrica é fixo -. Não depende do tamanho dos dados, apenas os tamanhos de chave

A última vez que testei isso, validar uma cadeia de 3 ou mais X.509 certificados [editar para acrescentar: e os dados que estavam assinando] estava tomando uma fração de segundo em um ARM rodando a 100MHz ou assim (em média mais muitas repetições, obviamente). Não me lembro o quão pequeno -. Não desprezível, mas bem menos de um segundo

Infelizmente não me lembro os detalhes exatos, mas o resumo é que a menos que você está em um sistema muito restrito ou fazendo um monte de criptografia (como se você quer aceitar o maior número possível de conexões SSL por segundo), NIST-aprovado métodos de criptografia assimétrica são rápidos.

Aparentemente, é 1000x pior. ( http://windowsitpro.com/article/articleid/93787 /symmetric-vs-asymmetric-ciphers.html ). Mas a menos que você está realmente trabalhando através de uma grande quantidade de dados que não vai importar. O que você pode fazer é usar a criptografia assimétrica para trocar uma chave de criptografia simétrica.

Talvez você pode adicionar alguns detalhes sobre seu projeto para que você obtenha melhores respostas de qualidade. O que você está tentando proteger? De quem? Se você pudesse explicar os requisitos de sua segurança, você vai ter uma resposta muito melhor. Desempenho não significa muito se o mecanismo de criptografia não é proteger o que você pensa que é.

Por exemplo, certificados X509 são uma forma padrão industrial de proteger endpoints cliente / servidor. PGP blindagem pode ser usado para proteger arquivos de licença. Para simplificar, Cipher Block encadeamento com Blowfish (e uma série de outras cifras) é fácil de usar em Perl ou Java, se você controlar ambos os pontos finais.

Graças.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top