Certbot: O comprimento de bits padrão da chave RSA deve ser 3072

Eu até sugeriria 4096 (eu faço isso em quase todos os meus sistemas).

Obrigado,
Martinho

Sugiro também 4096.

Mas alguns meses atrás, eles discordam do 4096 por padrão: https://github.com/letsencrypt/letsencrypt/issues/489

Eu prefiro um compromisso (= RSA com módulo de 3072 bits) em comparação com nenhuma segurança por padrão.

Sugira 4096 também.
A segurança deve ser boa por design e padrão: nenhum usuário padrão altera a configuração padrão.

E não há argumento aceitável para 2048/3072 vs 4096 bits (apenas uma sobrecarga de velocidade muito pequena).
3072 bits podem levar a problemas de compatibilidade se o agente do usuário codificar alguns tamanhos de chave (2048 e 4096 bits serão mais bem suportados do que 3072).

Pior, o argumento da regeneração de chave de 90 dias para justificar o uso de chave de 2048 bits não é bom:

• A regeneração de chave quebra muitas outras proteções de pilha TLS, como DANE/TLSA ou HPKP, a configuração reforçada deve desativá-la para evitar grandes problemas.
• A regeneração de chaves não diz "destruição do passado". Se o servidor web não estiver configurado corretamente apenas com o conjunto de cifras PFS, as agências do tipo NSA podem interceptar e armazenar comunicações de rede protegidas com chave de 2048 bits e descriptografá-las em 20 ou 30 anos, mesmo que as chaves correspondentes sejam destruídas. As chaves de 4096 bits protegem a comunicação não PFS mais longa.
• Mesmo com cifras somente PFS, os servidores web geralmente baseiam o parâmetro DH negociado no tamanho da chave privada. Se você usar apenas uma chave privada de 2048 bits, seu parâmetro DH será apenas de 2048 bits e, portanto, possivelmente fraco para LogJam.

Outro +1 para 4096, é o que sempre uso hoje em dia.

Veja #489 para muita discussão sobre este assunto.

Com as configurações padrão do LE, RSA 2048 bits, 90 dias, tente decifrá-lo? Sugiro encerrar este assunto.

A questão não é "prova de que você pode decifrá-lo" (ou ficar em 1024 bits, ninguém o decifra desde agora), mas "toda recomendação / estado da arte pede pelo menos 3072 bits" (NSA, NIST, ANSSI, FIPS, Qualys e mais).
Não há desvantagens válidas para atualizar para 4096 bits por padrão.

(E repito, mesmo com renovação de chave de 90 dias, se nenhum PFS for usado, você terá uma validade de chave prática de muitas décadas, mesmo que a validade técnica seja de apenas 90 dias, e a renovação de chave de 90 dias quebra muitas outras pilhas TLS (TLSA, HPKP, cert pinning), portanto, o administrador de sistema sensato DEVE desativá-lo e reutilizar uma chave por pelo menos 120 dias e 1 ano na prática)

No entanto, nos 1.000.000 principais sites da Alexa, mais de 89% dos sites habilitados para SSL/TLS usam RSA 2048 bits, incluindo muitos sites de bancos online.

Sim, o banco também tem SSLv3 e MD5 se você quiser https://imirhil.fr/tls/#Banques %20en%20ligne
E Google/Youtube também https://imirhil.fr/tls/alexa.html
E site pornô sem TLS https://imirhil.fr/tls/porn.html
Mesmo CA tem SSLv3, MD5, RC4 ou SSLv2 (sim, você leu corretamente…) e suites EXPORT de 40 bits https://imirhil.fr/tls/ca.html

A configuração do TLS é MUITO ruim na natureza, isso não é um apelo para continuar a fazer dados.

@devnsec-com Portanto, eles não são seguros. Mesmo que o IPv6 e o ​​DNSSEC sejam boas tecnologias, eles ainda não foram implantados massivamente. Acontece o mesmo para RSA 4096 bits. Temos que avançar em vez de pisar na água.

A única razão para usar RSA 3072 ou 4096 (ou até mais) é a prova futura, mas com um certificado de apenas 90 dias, todos os usuários realmente precisam de RSA maior que 2048 por padrão? Se você é realmente paranóico, opte por teclas mais longas, existe um parâmetro e você pode alterá-lo.

Todos os usuários precisam de 3072+ chave por padrão .

As pessoas que realmente sabem o que fazem podem eventualmente reduzir o tamanho, mas por padrão , o Let's encrypt deve fornecer configuração compatível com o estado da arte.
O usuário padrão (99% na verdade) nem olha para a configuração ou se preocupa com o tamanho da chave gerada ou mesmo sabe o que o TLS realmente é…

Lembre-se, estamos falando de um certificado SSL/TLS, você pode ter suporte a PFS em seu servidor e pode ser revogado se necessário. Não estamos falando de uma chave OpenGPG ou chave SSH que você pode usar por 20 anos ou até mais.

E muitos anos depois, quando o RSA 2048 estiver provando que não é mais seguro, podemos alterar os padrões do LE para RSA 4096, quase todos os usuários serão alterados para RSA 4096 em 90 dias.

Como mencionei o OpenGPG, diria que mesmo o OpenGPG é o padrão para RSA 2048.
Leia isto: https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

Você pode . Você não pode ter PFS também. E se chave de 2048 bits, você não está seguro. Mesmo com 90d renovar. E se não houver PFS, a destruição de chaves é inútil, seus dados já estão na natureza e devem ser descriptografados em poucas décadas.

E apenas o certificado pode ser revogado, não a chave.
As chaves são exatamente como a chave GPG/SSH: após a geração, você tem que lidar com elas até a destruição física da superfície da terra se PFS e eternamente se não houver PFS.

Como mencionei o OpenGPG, diria que mesmo o OpenGPG é o padrão para RSA 2048.

O GPG tem uma desvantagem real de usar 4096 chaves (apenas alguns smartcards suportam mais de 2048, dispositivo móvel…). No TLS, não há nenhum.

E no GPG, todos atualmente geram chaves de 4096 bits, todos os tutoriais e recomendações pedem isso.

Você acabou de fazer um ponto, em vez de argumentar padrão para RSA 2048 ou mais, devemos falar sobre padrão para habilitar o PFS. Porque não importa quanto tempo a chave seja, ela será descriptografada em breve ou mais tarde, RSA 2048, RSA 4096 também.

Sim, mas você não tem como garantir o PFS com Let's Encrypt (e pior, apenas cifras PFS, você pode negociar um conjunto de cifras PFS, mas o servidor pode suportar no-PFS ou EXPORT…).

E, atualmente, há uma grande desvantagem em usar apenas conjuntos de cifras PFS (compatibilidade do navegador, consulte https://tls.imirhil.fr/suite/EECDH+AES:EDH+AES+aRSA).

Em todos os casos, este não é o trabalho de uma CA.

Não estamos falando de CA aqui, mas de um software cliente, certo?

Não. TLS é muito complicado, com muita pilha.
Nenhum software pode lidar com isso completamente.

Você não tem como adivinhar se o seu usuário tem DNSSec ou TLSA, deve garantir a compatibilidade do IE ou não user-agent padrão, qual versão do OpenSSL é usada, etc.
A única coisa que o LE pode fazer é aumentar o tamanho da chave…

Não, quando o LE usa RSA 3072 ou 4096 por padrão, alguém dirá que quer RSA 8192 por padrão para todos os usuários, esta é uma corrida armamentista sem fim.

@devnsec-com Não. NSA, NIST, ANSSI, FIPS, Qualys não recomenda RSA 8192, mas pelo menos RSA 3072.

Não, se alguém pedir 8192, você pode dizer que 4096 é atualmente seguro e recomendado em todos os lugares.
Atualmente, este não é o caso de 2048.

Também posso dizer que Yubico , Cisco e muitas empresas estão recomendando o RSA 2048 no momento em que estamos falando.

Quanto maior o comprimento da chave, mais seguras elas são, mas as empresas comerciais são mais pragmáticas nesse tópico. Novamente, o RSA 2048 é suficiente no estágio atual como padrão, desde que suportemos chaves mais longas quando necessário.

Bom recurso para esta conversa - keylength.com

@devnsec-com As posições Yubico e Cisco são válidas, pois possuem problemas de hardware (HSM, PKI e smartcard não suportam muito bem 4096 bits).

De Yubico : « Esta não é uma restrição do Yubico, mas sim uma limitação de hardware do chip NXP A700x usado no YubiKeys »
Da Cisco: 4096 bits disponíveis apenas no Cisco IOS XE versão 2.4 (e hardware é difícil de atualizar), e a página fornecida é muito antiga (parece não atualizada desde a versão 2.4 (2009), mesmo valor padrão desde pelo menos a versão 2.X …).

E não é porque todas as outras ovelhas estão correndo em direção ao precipício que devemos seguir…

@devnsec-com Acrescento também que a documentação da Cisco é sobre gerenciamento de PKI e CA e, neste campo (certificado de CA, não certificado de usuário final), o CA/B-forum recomenda pelo menos 2048 bits .

E há um debate interno sobre 4.096 inclusões também, desde 2014.

Incluiríamos recomendações sobre o tamanho da chave? Algumas pessoas querem intencionalmente usar a chave de 4096 bits. Eles aceitariam conselhos? O documento pode explicar o trade-off entre segurança, compatibilidade e outros fatores

Mas parece que os roteadores de hardware não suportam raízes mais de 2048 (Cisco)

Iñigo disse que os produtos mais recentes da Cisco não suportam raízes SHA-1 e 4096 bits. Kelvin disse que poderia tentar trabalhar com a Cisco para mudar isso.

@devnsec-com Outro comentário interno no CA/B-forum.

Definir datas-alvo para o próximo conjunto de alterações para melhorar a segurança/desempenho (RSA-4096/ECC/SHA-512/etc)

Olá pessoal, Seria ótimo manter este tópico e ouvir a equipe do LE.
Tanto quanto posso ler, os argumentos da @aeris parecem ser válidos e não contrariados. Exceto se perdermos alguma coisa, também espero que o LE mude a chave RSA padrão para 4096 bits em breve.

+1 para RSA 3072bit por padrão.

Como foi mencionado, RSA 2048bit é equivalente apenas a 112bits de proteção de chave simétrica. Isso fica abaixo do mínimo amplamente difundido de 128 bits usado hoje. O RSA 3072bit é apenas equivalente a 128 bits, o suficiente para agora (e o mínimo recomendado pela NSA em janeiro de 2016).

Observe que todas as estimativas anteriores de longevidade para tamanhos de chave devem ser consideradas com ceticismo saudável, porque geralmente pressupõem uma melhoria linear na quebra de chaves, mas novos ataques podem diminuir a segurança muito mais rapidamente.

As chaves RSA com >2048 bits são atualmente incompatíveis com o Amazon Web Services. Do Guia do desenvolvedor do Amazon CloudFront :

O tamanho máximo da chave pública em um certificado SSL/TLS é 2048 bits

Apenas pensei em adicionar esse ponto extra na conversa.

Qualquer pessoa que deseje ter um RSA maior que 2048 bits pode simplesmente digitar --rsa-key-size 3072 ou --rsa-key-size 4096 para solicitar esses tamanhos de chave.
Observe que chaves RSA maiores levam muito mais tempo para serem geradas, e qualquer coisa maior que 4096 pode travar navegadores Apple mais antigos.

Quando o #2632 for implementado, a desvantagem de desempenho quase não terá impacto para a maioria.
Assim, podemos combinar EC 256 com 3072 RSA (ou o que preferirmos como padrão) para fornecer força igual para ambos.

A propósito, como sugestão de suporte a chaves EC, tenha um comando como --ec-key-type para gerar uma chave EC e solicitar o certificado.
Atualmente, gero e assino minhas chaves RSA usando certbot e minhas chaves EC usando um script de shell.

@WilliamFeely é #2625

Obrigado.
Quanto ao tamanho da chave RSA, acho que o RSA 2048 ainda é o padrão do setor e ainda está autorizado para conformidade com PCI-DSS e, portanto, por que ainda é o padrão?

Veja o que diz a documentação mais recente do PCI-DSS ( v3.2, abril de 2016 ):

Consulte os padrões do setor e as melhores práticas para obter informações sobre criptografia forte e protocolos seguros (por exemplo, NIST SP 800-52 e SP 800-57, OWASP, etc.)

Felizmente, o glossário define a Criptografia Forte da seguinte forma:

Criptografia baseada em algoritmos testados e aceitos pela indústria, juntamente com comprimentos de chave que fornecem um mínimo de 112 bits de força de chave efetiva e práticas adequadas de gerenciamento de chave. A criptografia é um método para proteger dados e inclui tanto a criptografia (que é reversível) quanto o hashing (que é “unidirecional”, ou seja, não reversível). Consulte Hashing.

No momento da publicação, exemplos de padrões e algoritmos testados e aceitos pela indústria incluem AES (128 bits e superior), TDES/TDEA (chaves de comprimento triplo), RSA (2048 bits e superior), ECC (224 bits e superior) , e DSA/DH (2048/224 bits e superior). Consulte a versão atual da Publicação Especial NIST 800-57 Parte 1 (http://csrc.nist.gov/publications/) para obter mais orientações sobre algoritmos e pontos fortes de chave criptográfica.

_ Nota : Os exemplos acima são apropriados para armazenamento persistente de dados do titular do cartão. Os requisitos mínimos de criptografia para operações baseadas em transações, conforme definido no PCI PIN e PTS, são mais flexíveis, pois há controles adicionais para reduzir o nível de exposição.
Recomenda-se que todas as novas implementações usem um mínimo de 128 bits de força de chave efetiva._

Não há necessidade de usar como padrão 3072 para uma chave RSA usada com um servidor web.

Em primeiro lugar, você deve usar apenas cifras que fornecem FS. Dessa forma, as sessões anteriores que são registradas ainda são seguras, mesmo que sua chave privada seja descoberta posteriormente.

Com algo como GnuPG você pode querer usar maior (eu uso 4096) porque FS não é uma opção, o cliente e o servidor não negociam sua própria chave quando a conexão é estabelecida. Mesmo com o GnuPG, você realmente não precisa de > 2048 e, se precisar, o EC oferece mais retorno, mas como ainda não é bem suportado pelos clientes e uma mensagem criptografada pelo GnuPG pode ser sensível por décadas, 4096 é pelo menos justificável,

Não é justificável com HTTPS se o FS for usado. Quando o FS é usado, você deve usar cifras ECDHE quando possível para que a chave usada entre cliente e servidor seja mais forte. Se o seu servidor ainda suporta chaves DHE, é no grupo DH que você deve se preocupar com quantos bits, e lá, a maioria das pessoas usa o grupo 2048 DH predefinido que é publicado na RFC. Gerar seu próprio grupo DHE de 2048 bits é razoável.

Para a chave privada do servidor, 2048 bits não podem ser facilmente quebrados e, portanto, são suficientes. Sugerir um padrão de 3072 ou 4096 é como sugerir um peso de papel de 20 libras em vez de 15 libras. Sim, as 20 libras são mais pesadas, mas não, não há nenhum benefício real e sua chave RSA de 2048 bits será substituída por muito tempo antes que não seja mais segura.

Sempre use sigilo de encaminhamento e use cifras ECDHE sempre que possível. A chave privada, RSA 2048 é boa o suficiente e se você realmente quiser melhor, use ECDSA e não RSA para a chave.

Acho que o que estou tentando dizer, e me corrija se estiver errado, é que quando seu TLS requer cifras que usam Forward Secrecy, o único propósito real da chave privada de longo prazo do servidor é a identidade.

A criptografia real entre cliente e servidor que ocorre usa uma chave temporária negociada entre cliente e servidor que não está relacionada à chave usada com o certificado x.509.

É com isso que você precisa se preocupar, nunca usando parâmetros DH < 2048 e preferencialmente usando ECDHE. A chave privada para o servidor só tem relevância no estabelecimento da identidade do servidor, e o RSA de 2048 bits certamente é bom o suficiente para isso, especialmente se você seguir as práticas recomendadas para gerar uma nova chave pelo menos uma vez por ano.

Assim, esse problema deve ser encerrado e a ênfase na segurança deve ser colocada na seleção adequada do conjunto de cifras.

Interessante, mas quando Applebaum e Snowden me recomendam usar o tamanho de chave RSA de 4096 bits, bem, hmm, não sei, acho que devo seguir esse conselho. A identidade não é exatamente o que estamos tentando esconder/proteger aqui?

@jut Apenas fique com 4096 bits, especialmente se você estiver usando o GnuPG. Até que todos atualizem para a versão 2.1, teremos acesso às chaves ed25519 OpenPGP. e eles não são muito mais fortes. (Eu amo minhas chaves ed25519 SSH + GPG, então encoraje todos a se afastarem do RSA!)

Espera-se que as chaves RSA de 2.048 bits sejam quebráveis ​​por um invasor com uma grande quantidade de recursos computacionais nos próximos anos. 768-1024 bits já quebrados rotineiramente.

Eu não acho que 3072 seja um padrão razoável, é meio fora do comum.

2048 bits não serão recomendados após 2030, garanto, e o pôr do sol será gradual como foi para SHA-1. Eu li muitos desses documentos de padrões governamentais e tal...

Por um tempo as pessoas estavam na prática de fazer chaves de 8192 bits e acima... É apenas uma mudança divertida de duas ou três linhas para a fonte, mas não tenho certeza de quão bem elas funcionam com outras pessoas.

. @WikiLeaks publica uma chave de criptografia RSA PGP de 8192 bits excepcionalmente forte para envios https://t.co/xGnu72HTUN pic.twitter.com/8TZyql1NN6

— KM Gallagher (@ageis) 27 de maio de 2015

@ageis Além disso, há um limite bastante rígido em 16384. Seria necessário *muito* mais hacking para aumentar; Eu tentei.

— isis agora lovecruft (@isislovecruft) 8 de setembro de 2014

@jult Não vou abordar a coisa de Appelbaum e Snowden. Eu também os conheço vagamente, mas vejo isso como uma espécie de apelo de estrela do rock à autoridade que você está fazendo. Olhe para todas as fontes, posso recomendar algumas especialmente:

• http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
• https://pages.nist.gov/800-63-3/sp800-63b.html
• http://www.secg.org/sec2-v2.pdf
• http://www.ecc-brainpool.org/download/Domain-parameters.pdf
• http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf
• https://safecurves.cr.yp.to/

Pessoalmente, estou mais interessado em atualizar todos para o GnuPG 2.1, com o formato kbx mais rápido, e gerar novas chaves ed25519 (pensamentos @dkg ou @floodyberry?), e espero que a próxima série Yubico os suporte. Na verdade, posso entrar em contato para verificar; como fiz alguns testes beta para o YubiKey 4. No entanto, não gosto de como as chaves devem ser protegidas/senhadas para serem exportadas, porque torna a importação para o smartcard um desafio.

Enquanto estou em torno desta edição, vou lançar um ótimo gráfico da Publicação Especial do NIST 800-57. Muitos mais de onde isso veio. Coisa perfeita para começar em um sábado à noite, hein?

Novamente, a carga extra no tamanho durante o handshake do cliente não vale o risco extra com um tamanho de chave menor. Os que não recomendam o uso de RSA de 4096 bits não apresentam argumentos válidos para não fazê-lo. Sem mencionar o fato de que estamos contando com a geração adequada das chaves , e se isso acabar sendo falho, estamos muito melhor com chaves de 4096 bits.
Verifique isso; https://github.com/certbot/certbot/issues/489#issuecomment-114083162
Você quer ter certeza de gerar chaves Diffie Helman de >=4096 bits também, coisas assim
openssl dhparam -dsaparam -out /etc/ssl/dh4096.pem 4096
se você quiser que faça algum sentido quando você habilitou o DH(E) em seus conjuntos de criptografia.

Eu executei um benchmark sintético para assinaturas RSA agora e vi isso:

(1024, 0.0008035948276519776)
(2048, 0.0025235090255737304)
(3072, 0.006322009086608887)
(4096, 0.013043954849243164)

O primeiro número é o tamanho do módulo e o segundo é o número médio de segundos necessários por operação de assinatura.

Achei os comentários de @AliceWonderMiscreations sobre sigilo de encaminhamento um tanto persuasivos; alguém tem algumas estatísticas atuais sobre as frações de conexões TLS que são negociadas com vários ciphersuites hoje? Se muito poucos estiverem usando cifras não PFS, o parâmetro de comprimento de chave RSA terá consequências mínimas de segurança a longo prazo.

FS e não FS é uma questão separada. Sim, devemos encorajar os ciphersuites FS, e tanto os clientes quanto os servidores devem desabilitar os ciphersuites não-FS onde eles sabem que é possível fazê-lo. (TLS 1.3 não tem mais nenhum conjunto de criptografia não-FS, yay!) Isso não significa que devemos ignorar a importância de uma chave de identidade criptográfica forte, ou que devemos jogar uma contra a outra. Lembre-se de que uma chave de identidade forjada possibilita ao MiTM até mesmo uma conexão FS.

A RSA 3072 parece ser o ponto ideal onde as recomendações (como ENISA e NIST) apresentam uma forte margem de segurança para chaves destinadas ao uso na próxima década.

Olá @dkg ,

FS e não FS é uma questão separada. Sim, devemos encorajar os ciphersuites FS, e tanto os clientes quanto os servidores devem desabilitar os ciphersuites não-FS onde eles sabem que é possível fazê-lo. (TLS 1.3 não tem mais nenhum conjunto de criptografia não-FS, yay!) Isso não significa que devemos ignorar a importância de uma chave de identidade criptográfica forte, ou que devemos jogar uma contra a outra. Lembre-se de que uma chave de identidade forjada possibilita ao MiTM até mesmo uma conexão FS.

No caso padrão, atualmente usamos apenas uma chave de assunto RSA individual por 60 dias (com o risco MITM ativo continuando durante a vida útil de 90 dias do certificado) e, em seguida, mudamos para uma diferente. Parece que há uma diferença considerável entre "um invasor que pode quebrar a chave de 2048 bits em 90 dias pode realizar um ataque ativo" e "um invasor que pode quebrar a chave de 2048 bits a qualquer momento pode recuperar o texto simples de sessões antigas que estava envolvido". A primeira é verdadeira e a segunda não é verdadeira no caso de ciphersuites FS.

As recomendações sobre comprimento de chave geralmente parecem assumir um modelo de ameaça em que o invasor quebra uma chave algum tempo depois que a chave é usada—por exemplo, as recomendações que você menciona abaixo parecem ser baseadas em um modelo de ameaça em que um invasor leva anos para quebrar uma chave individual. Com os ciphersuites FS, esse modelo de ameaça não deve ser tão relevante para decidir o comprimento da chave de identidade porque uma determinada chave de identidade deixou de ser usada há muito tempo.

A RSA 3072 parece ser o ponto ideal onde as recomendações (como ENISA e NIST) apresentam uma forte margem de segurança para chaves destinadas ao uso na próxima década.

O ponto que eu aprecio no argumento de @AliceWonderMiscreations é que as chaves de 2048 bits que geramos não são destinadas individualmente para uso por um período de uma década, mas sim para uso por um período de vários meses, quando são usado para autenticar as negociações Diffie-Hellman. Portanto, essas recomendações podem considerar um contexto de segurança diferente na maioria dos casos. É concebível que deveríamos estar mais preocupados com o módulo DH na maioria dos modelos de ameaças porque é o parâmetro limitante que afeta diretamente o nível de segurança de longo prazo.

Tentarei obter alguns dados práticos sobre a frequência de uso de conjuntos de cifras FS e o impacto das chaves de 2048 vs. 3072 bits no desempenho do servidor.

Como atualização, ouvi estimativas aproximadas de algumas fontes diferentes de que "cerca de 10%", "menos de 10%" e "cerca de 1%" das conexões HTTPS agora usam conjuntos de criptografia não FS. Este é um alvo muito difícil de definir porque depende se é da perspectiva do navegador, da perspectiva do servidor, em um país específico, em um site específico, para um tipo específico de site etc., e esses tipos de diferenças parecem explicar a discrepância de 1%-10%.

Pessoalmente, estou mais preocupado a esse respeito com o fato de mantermos chaves privadas antigas em disco (sobre o qual arquivei um problema separado, https://github.com/certbot/certbot/issues/4635). Acho que essa deve ser uma prioridade mais alta porque acho que os invasores que comprometem um servidor para ler o tráfego antigo geralmente são muito mais prováveis ​​do que os invasores que quebram o RSA de 2048 bits para fazê-lo.

Sugiro o seguinte:

• Eu sei que o @dkg tem feito muito trabalho na segurança das trocas de chaves DH no TLS em geral. Você pode fazer ou encontrar algumas ferramentas que ajudam a analisar sites para estimar a força da troca DH que provavelmente ocorrerá quando um cliente se conectar a cada site¹? (Sei que em algumas das áreas com as quais você está preocupado, não podemos dizer do lado do cliente quão segura é a troca, mas estou pensando em tentar mapear a força da troca DH na medida em que que podemos ver e determinar.) Também conhecemos muitos pesquisadores acadêmicos que se interessaram por esse tipo de tópico...

• Ainda tentarei corrigir https://github.com/certbot/certbot/issues/4635 para que as chaves privadas antigas e não mais usadas não estejam presentes nos servidores da web.

• Talvez possamos pensar em etapas contínuas para incentivar os usuários a atualizar seus navegadores da Web, para aumentar a quantidade de DH que é usada no TLS.

Com isso em mente, reitero que as chaves de 2048 bits que geramos por padrão geralmente não são usadas para proteger diretamente a confidencialidade das chaves de sessão, mas sim para autenticar trocas de chaves DH, onde um ataque teria que ser um , ataque interativo e ativo dentro da validade de 90 dias do certificado. Caso contrário, o invasor terá que escolher outra via de ataque. É difícil para mim ver que qualquer fonte de aconselhamento sobre o tamanho da chave está argumentando que as chaves de 2048 bits não são adequadas para autenticação durante uma janela de 90 dias. Eles são mais diretamente relevantes para a confidencialidade de longo prazo de 1% a 10% das conexões, mas talvez possamos nos esforçar mais para reduzir esse percentual.

¹ por exemplo, com relação ao algoritmo e com relação ao tamanho do parâmetro público e reutilização

Estou pesquisando mais sobre uma sugestão relacionada sobre chaves RSA, mas pretendo encerrar esse problema em breve, a menos que alguém tenha alguma resposta às minhas três sugestões na minha resposta mais recente.

Que tal fechar isso depois que o #3349 foi feito?

Que tal fechar isso depois que o #3349 foi feito?

Eu diria que o nº 6492 é mais relevante e que devemos fechar isso depois que o nº 6492 for feito (e o nº 4635).

Pessoal, a criptografia de 4096 bits não é gratuita. É massivamente lento em CPUs de baixa potência. Até os telefones modernos sofrem ao usá-lo. Você tem certeza de que passar de uma criptomoeda indecifrável para uma criptomoeda ainda mais indecifrável vale a pena arruinar o desempenho e a duração da bateria de todos?

O comprimento de chave de 4096 bits é um grande problema na IoT porque esses dispositivos geralmente têm uma potência de CPU muito limitada.

A velocidade dos tanques RSA privados de 3,6 a 0,6 para ir de 2048 a 4096 em um de nossos dispositivos embarcados mais antigos.

Como mencionado anteriormente, a IoT e outros dispositivos sem aceleração de hardware podem usar o ECDSA (#6492).

Como mencionado anteriormente, a IoT e outros dispositivos sem aceleração de hardware podem usar o ECDSA (#6492).

Existe aceleração de hardware do RSA em muitos dispositivos ou isso ainda é geralmente tratado via software?

A aceleração de hardware está disponível em alguns MCUs, mas não na maioria deles (é mais caro). Também é frequentemente limitado a 3072, como é a recomendação (https://www.keylength.com/)
Observe que a verificação RSA é bastante rápida. Apenas a geração e assinatura são muito lentas.

OPENSSL_TLS_SECURITY_LEVEL=3 requer pelo menos 3072 bits.

Por que esta questão ainda está em aberto? É bastante claro que os usuários que estão solicitando parecem não entender a relevância do TLS, especialmente em 2020.

TL;DR

• Os certificados RSA só importam para provar que a identidade do servidor é confiável e são substituídas a cada 90 dias . Ele não será comprometido devido ao comprimento da chave de 2048 bits nesse período apenas para se passar por você.
• Isso supondo que, como você se preocupa tanto com a segurança, está permitindo apenas conjuntos de criptografia que oferecem FS (DHE/ECHDE), e o DHE também não é uma preocupação para você, pois para sites, nenhum navegador da Web moderno oferece suporte a DHE para troca de chaves (o Safari e o Chrome abandonaram o suporte por volta de 2016).
• RSA de 1024 bits vs RSA de 2048 bits é ~4 bilhões de vezes mais difícil de atacar . O RSA de 768 bits foi quebrado em 2010 (demorou 2 anos com computação paralela equivalente a 2000 anos de uma única máquina), em 2020 só conseguimos atingir 829 bits, 512 bits versus 1024 bits é ~ 1 bilhão vezes em dificuldade, enquanto 2048 bits vs 3072 bits é apenas ~ 65k vezes mais difícil ...
• A identidade do seu certificado é verificada em uma cadeia de confiança em relação aos certificados da CA , que têm duração de validade mais longa, mas ainda são RSA de 2048 bits, você não tem controle sobre isso . Um invasor terá como alvo se quiser se passar por você, aumentar o comprimento da chave além disso não fornecerá nenhum benefício adicional quando o certificado não for usado para mais nada.

Para a maioria das implantações, você deve garantir apenas conjuntos de cifras PFS, seu certificado RSA não tem nenhum benefício aqui além de 2048 bits, você está apenas reduzindo a quantidade de handshakes que o servidor pode suportar simultaneamente devido à sobrecarga adicional. O contexto do conselho precisa ser levado em consideração, não apenas repetido cegamente.

Use DHE / ECDHE apenas para troca de chaves, com servidores da Web, você descobrirá que , desde 2015, os navegadores também removem progressivamente o suporte para DHE . O Safari fez isso como uma resposta ao Logjam em 2015, o Chrome abandonou o suporte a DHE em 2016 ( Chrome 53 (agosto de 2016) ) por causa de quantos servidores ainda negociavam com grupos DH de 1024 bits e o Firefox finalmente ingressou neste ano ( Firefox 78 ( junho de 2020) ). Então, basicamente para a web, você está lidando apenas com ECDHE, a menos que você esteja realmente ciente de clientes que não podem suportar isso por algum motivo, os navegadores da web suportam ECC há muito tempo .

Com qual possível preocupação você ficou para se preocupar agora? Seus certificados estão sendo renovados/substituídos dentro de 3 meses, a única preocupação de segurança com os certificados RSA é a identidade, que algum invasor pode se passar por você, mas para que isso aconteça, o invasor precisa ser bem-sucedido dentro dessa janela de <90 dias.

Em 2020, o recorde até agora é quebrar RSA de 829 bits (10 anos desde que sabíamos que 768 bits era quebrável), o recorde anterior de RSA de 795 bits cita ter melhores algoritmos e hardware disponíveis para atingir seus resultados em cerca de metade o tempo de cálculo. Basta olhar para os 900-2000 anos de computação a que essas conquistas foram equivalentes em seu poder de computação paralela (que para 768 bits foi reduzido para 2 anos).

O RSA de 512 bits é aproximadamente cerca de 50 bits de força de chave simétrica em segurança. O RSA de 1024 bits é conhecido como 80 bits e o RSA de 2048 bits, 112 bits, enquanto o de 3072 bits, conforme observado neste problema, é de 128 bits. Certo, fantástico, então o RSA de 768 bits (que está em algum lugar entre 50-80 bits de segurança simétrica) em 2010 poderia ser quebrado ao longo de 2 anos e uma tonelada de dinheiro, uma década depois, conseguimos fazer alguns bits equivalentes mais. Para qualquer um em que isso soe como uma bobagem, cada bit adicional na força da chave simétrica está dobrando a quantidade de trabalho para calcular se você deseja forçar todas as possibilidades (em média, você teria sucesso na metade de todo esse processamento) .

Agora compare o RSA de 512 bits com o de 1024 bits, há uma diferença de aproximadamente 30 bits na segurança simétrica, 2^30 é cerca de 1 bilhão, ou seja, 50 bits (1.125.899.906.842.624 chaves potenciais) multiplicado por 1 bilhão (1.125.899.906.842.624.000.000.000), ou simplesmente , 1 bilhão de vezes mais esforço/tempo para quebrar. Com RSA 1024-bit vs 2048-bit, você tem uma diferença de 32 bits, 2^32 é um pouco mais de 4 bilhões. Então temos (4.503.599.627.370.496.000.000.000.000.000.000). Agora, aumentar para 3072 bits é mais modesto 16 bits de segurança extra, 2^16 == 65.536... sim, isso o tornará mais "seguro", não exatamente o mesmo salto que nosso multiplicador de 4 bilhões, mas já temos um aumento significativo na dificuldade com RSA de 2048 bits.

Agora deixe isso absorver e pensar. O RSA de 768 bits em 2010 levou 2 anos de processamento paralelo equivalente a 2.000 anos de uma única máquina e, uma década depois, podemos fazer um pouco melhor com todos esses avanços desde então. Ainda muito longe do RSA de 1024 bits, a menos que alguém com muito dinheiro e tempo a perder queira quebrar seu certificado RSA, não é como grupos DH compartilhados, o valor é consideravelmente menor de retorno, a menos que você esteja de posse de alguns dados que são ridiculamente valiosos e não podem ser obtidos por meios mais baratos, como tortura física / chantagem.

Mesmo se alguém tivesse tantos recursos para desperdiçar ao quebrar seu certificado RSA, não é 1024 bits, a dificuldade de 2048 bits é 4 bilhões de vezes maior, não vai acontecer sem algum grande avanço, provavelmente uma fraqueza onde o comprimento da chave é não é uma preocupação (basta olhar para todas as outras vulnerabilidades no TLS que resolveram isso). Se você foi além do RSA de 3072 bits e isso foi usado para sua criptografia, que por acaso usava chaves de 128 bits, seu certificado RSA não importa, e a chave de criptografia de 128 bits para AES pode ser atacada apenas afaik.

Tudo isso de lado, porém, como afirmado, estamos falando apenas de RSA ter relevância apenas para identidade se você estiver usando apenas conjuntos de cifras PFS, sejam quais forem seus recursos, existem maneiras melhores de comprometer seu servidor ou usuários do que o custo para quebrar 2048 -bit RSA cert em menos de 90 dias...

OPENSSL_TLS_SECURITY_LEVEL=3 requer pelo menos 3072 bits.

E isso tem relevância por quê? Há um nível 5 exigindo um comprimento mínimo de chave RSA de 15360 bits, por que parar em 3072 bits com essa lógica?

Como o documento vinculado indica, o padrão é 1 , a menos que configurado de outra forma. Você conhece algum software convencional que esteja compilando OpenSSL com nível 3? Na maioria das vezes, quando o OpenSSL é usado, ele está vinculado à cópia do sistema, pois você deseja receber atualizações de segurança sem depender de cada aplicativo atualizar suas próprias cópias agrupadas (supondo que o software seja mantido/atualizado regularmente para isso, em primeiro lugar, o que nem sempre acontece neste cenário).

verificar sites para estimar a força da troca DH que provavelmente ocorrerá quando um cliente se conectar a cada site

@schoen Chrome em 2016 abandonou o suporte DHE , eles observam que 95% das conexões DHE estavam com parâmetros DH de 1024 bits. Não que isso deva importar muito agora, já que os navegadores modernos não suportam mais conjuntos de cifras DHE.

Para outros servidores como mail, ainda pode ser útil (embora o suporte ECDHE tenha sido muito bom por algum tempo, com algumas distribuições Linux como o RHEL não tendo suporte até 6.5 por volta de 2014). O DHE deve usar os grupos FFDHE oficiais da RFC 7919, que possuem no mínimo 2048 bits. Nenhum dos clientes antigos com o limite de 1024 bits deve importar, para situações de nicho em que o administrador do sistema estaria em uma posição paga para resolvê-lo, mas há uma série de problemas de segurança que podem ser encontrados nesse ponto, incluindo potencial cadeia de problemas de confiança devido a certificados raiz expirados em um sistema.

Talvez possamos pensar em etapas contínuas para incentivar os usuários a atualizar seus navegadores da Web, para aumentar a quantidade de DH que é usada no TLS.

Quando você fez essa sugestão, o Safari e o Chrome não ofereciam mais o afaik DHE. Isso teria o resultado oposto, reduzindo o DHE, supondo que os usuários sejam capazes de atualizar os navegadores/clientes em dispositivos que executam software desatualizado. Alguns sistemas operacionais ou softwares antigos estão bloqueados para implementações TLS antigas (como macOS / iOS Secure Transport), o que afeta o suporte à versão TLS, conjuntos de cifras suportados (macOS não tinha AES-GCM até a versão IIRC do final de 2015).

Em relação a quem acha que o RSA de 2048 bits é insuficiente para proteção de identidade por 90 dias, ignorando outras salvaguardas, como logs de OCSP e CT, você conhece a cadeia de confiança? Seu certificado é verificado em relação aos certificados raiz e intermediários do LetsEncrypt, se alguém quiser atacar um certificado, é mais valioso comprometer aqueles do que um emitido para um site específico.

Se o certificado estiver sendo usado apenas para autenticidade e não estiver sendo comprometido para descriptografar qualquer tráfego registrado, você poderá aumentar o tamanho da chave de seus sites o quanto quiser, mas o que você está ganhando em proteção contra esse ataque teórico em que você está mais seguro do que um anterior? cert na cadeia de confiança sendo comprometido? (que usam RSA de 2048 bits, ~incluindo LE root~ ( EDIT: My bad, LE RSA root is 4096-bit ), que tem períodos de validade muito mais longos, 5 anos para intermediário e até 2035 para a raiz LE)

Por que esta questão ainda está em aberto? É bastante claro que os usuários que estão solicitando parecem não entender a relevância do TLS, especialmente em 2020.

TL;DR

* RSA certs only matter for **proving the identity of the server can be trusted**, and are being **replaced every 90 days**. It won't be compromised due to key length of 2048-bit within that time just to impersonate you.

Parece que você não entende melhor o X.509 (e não o TLS :rofl:)… :rofl:
Cert não é o problema, mas a chave é. E no mundo X.509, a chave não é possível de revogar... Portanto, o rollover de 90 dias nem sempre é relevante aqui, e é um problema para o servidor que não usa ECDHE/DHE, mas sim a velha autenticação RSA. E isso é bastante o caso também em 2020…

Você também conta errado para a força do RSA-2048. Você tem que calcular não apenas o momento da melhor maneira atual de quebrar uma determinada chave, mas também a futura no momento em que sua chave não for mais significativa. No caso de não ECDHE/DHE (que é, repito, não tão raro), não é 90d, mas 10-30y. E não é apenas o momento a ser levado em consideração, mas também o custo, a evolução da tecnologia e a descoberta de fraquezas/truques criptográficos. E é especialmente visível no seu caso de explicação.
O RSA-256 foi crack em ~ 60s em um laptop padrão ~ $ 1000 em 09/2019. Mas o RSA-512 foi crack em ~4h e ~$75 em 2015.
https://www.doyler.net/security-not-included/cracking-256-bit-rsa-keys
https://eprint.iacr.org/2015/1000.pdf
Definitivamente não há diferença [insira aqui um grande número] vezes entre ambos, mas mais ou menos 1,8 a custo constante.
Também é bastante visível no benchmark cado-nfs para fatorar a chave RSA. RSA-120 é 1,9h, RSA-130 é 7,5h (e não 81d como esperado), RSA-140 é 23h (e não 227y) e RSA-155 é 5,3d (e não 7452 milênio).

É por isso que entidades como ANSSI ou NIST baseiam suas recomendações não apenas no estado da arte atual das habilidades de computador ou conhecimentos de criptografia, mas também em melhorias futuras que devem ocorrer no período de uso/significado da chave

é um problema para o servidor que não usa ECDHE/DHE, mas a autenticação RSA simples. E isso é bastante o caso também em 2020

Portanto, seu conselho para melhorar a segurança aqui é incentivar o uso de um tamanho de chave maior em vez de incentivar conjuntos de criptografia somente PFS? Por quê?

Você também conta errado para a força do RSA-2048
Você tem que calcular não apenas o momento da melhor maneira atual de quebrar uma determinada chave, mas também a futura no ponto no futuro em que sua chave não é mais significativa

Por favor, elabore mais. Em que caso você está ciente de que na última década isso estava errado. Não há nenhum caso conhecido de RSA de 1024 bits sendo fatorado/quebrado, muito menos de 2048 bits que tem 2 ^ 32 bits a mais de entropia ao analisar a força da chave simétrica.

1. O RSA de 2048 bits é aproximadamente 4 bilhões de vezes mais forte do que o RSA de 1024 bits.
2. 3072 bits é apenas ~65k vezes mais forte (ao comparar 112 bits a 128 bits de segurança simétrica conforme definido oficialmente pelo NIST).
3. Se assumirmos que 1024 bits (força de chave simétrica de 80 bits) podem ser comprometidos no período de 1 ano de poder de computação. São 4 bilhões de anos para 2048 bits.
4. Você está alegando que algum avanço tecnológico desconhecido poderia reduzir bastante esse tempo de computação, mas não ameaçar o RSA de 3072 bits?

Poderíamos comparar 1024 bits como quebráveis ​​em 1 segundo, então 2048 bits equivalem a 136 anos ainda ( (1/31536000) * 2^32 ). Tal conquista está muito longe de acontecer, se você quiser insistir que é de alguma forma uma preocupação válida, você está ciente de até 512 bits sendo fatorado em 1 segundo? O RSA de 512 bits foi fatorado pela primeira vez em 6 meses em 1999 , desde 2015 existe um projeto Github (FaaS) que permite alavancar facilmente a AWS por menos de US$ 100 e poucas horas para fatorar o RSA de 512 bits.

Com isso em mente, o RSA de 1024 bits sendo cerca de 2^28 (~250k) a 2^30 (1 bilhão) vezes mais difícil (não tenho números exatos, desculpe, mas parece estar em torno disso), e os acadêmicos atuais ainda longe disso, não tenho certeza de como você acha que o RSA de 1024 bits está perto de ser calculado tão rápido, o que precisaria ser antes que o RSA de 2048 bits seja algo para se preocupar em ser quebrado dessa maneira .

A abordagem usual aqui é GNFS (General Number Field Sieve), que se torna mais inviável com os recursos necessários quanto maior o tamanho da chave . Há também este bom gráfico do histórico de fatoração de RSA e uma resposta relacionada que fixou o RSA de 2048 bits sendo fatorado em 2048 com base nisso e 1024 bits em 2015-2020, que academicamente ainda não foi alcançado.

Considerando o que foi dito acima, gostaria que você fizesse backup de como o RSA de 3072 bits está oferecendo muito mais vantagens de segurança adicionais. Se o RSA de 2048 bits for atacado de qualquer outra forma ou avançar em tal ritmo tecnologicamente, não vejo como o RSA de 3072 bits ofereceria muita proteção adicional?

No caso de não ECDHE/DHE (o que é, repito, não tão raro)

Eu gosto de como você afirma que "não é tão raro", quão comum é que você encontre seu handshake usando uma troca de chave RSA em vez de DHE ou ECDHE nos dias de hoje? Você tem mesmo um exemplo?

não é 90d, mas 10-30y

Acredito que fui bem claro ao declarar o período de renovação de 90 dias para o certificado quando sua finalidade era apenas servir à autenticação, não à troca de chaves.

E não é apenas o momento a ser levado em consideração, mas também o custo, a evolução da tecnologia e a descoberta de fraquezas/truques criptográficos. E é especialmente visível no seu caso de explicação.

Sim, custo. Recursos que vinculei a você para citar RSA de 1024 bits exigindo Terabytes de RAM para executar GNFS, com a etapa de redução linear sendo a parte mais cara/difícil de lidar. Essa é a coisa com dificuldade exponencial, algo que é barato/fácil pode aumentar a dificuldade muito rápido.

O RSA-256 foi crack em ~ 60s em um laptop padrão ~ $ 1000 em 09/2019. Mas o RSA-512 foi crack em ~4h e ~$75 em 2015.

Já vinculei ao projeto do Github que pode realizar a fatoração de 512 bits na AWS. Eu não sei a quantidade exata de bits de entropia simétrica de RSA de 256 bits, talvez em torno de 30 bits? (portanto, aproximadamente 1.048.576 vezes diferem entre RSA de 512 bits). O documento de 512 bits ao qual você vincula menciona 432 CPUs (12 instâncias com 36 vCPUs + 60 GiB de RAM cada) e um total de 2770 horas de CPU com 1,5-2 GB de memória ou armazenamento para a matriz (não estou muito familiarizado com esse cálculo, se você estiver à vontade para entrar em contato).

Minha matemática provavelmente é ruim aqui, mas vamos tentar comparar o poder de computação dos dois sistemas com base nessa informação, 2770 horas para minutos seria 2770 * 60 = 166200 que podemos comparar com 1 minuto do RSA de 256 bits como log2(166200) = 17.34 , ~2^17, não muito longe da estimativa de 2^20, e como não sei os bits simétricos exatos para nenhum deles, pode ser bastante preciso, com alguma margem de manobra para melhorias na tecnologia e algoritmos , mas nada chocante?

Em 1991, o RSA de 330 bits foi fatorado em poucos dias , uma única CPU Intel Core2Duo posterior poderia lidar com isso em pouco mais de uma hora. O RSA de 256 bits teria sido menor do que isso, vamos dar uns 60 minutos otimistas e dizer que dentro de ~30 anos ele progrediu para ~1 minuto, uma grande redução de 60 vezes. Isso é equivalente a dizer 2^6 (64)... 6 bits. Como apontado anteriormente, apenas considerando o tempo, não recursos como o aumento dos requisitos de RAM, isso ainda está longe de ser uma ameaça válida. Elimine mais 6 bits nos próximos 30 anos e você conseguiu a fatoração de 1 segundo do RSA de 256 bits, parabéns, um longo caminho a percorrer para chegar ao RSA de 2048 bits em um período de tempo razoável.

Mesmo os 15 anos para RSA de 512 bits melhorando de 6 meses para 4 horas é 24hr * (6month * 30day) = 4320hr / 4hr = log2(1080hr) = 10 ~2^10. Essa é certamente uma redução melhor, ~1k vezes melhor, mas ainda não é uma taxa alarmante em comparação. Acho que isso é apoiado ainda mais pela forma como o progresso diminuiu com os acadêmicos sendo capazes de fatorar tamanhos de chave RSA maiores.

Também é bastante visível no benchmark cado-nfs para fatorar a chave RSA. RSA-120 é 1,9h, RSA-130 é 7,5h (e não 81d como esperado), RSA-140 é 23h (e não 227y) e RSA-155 é 5,3d (e não 7452 milênio).

De onde esses tempos esperados para calcular estão sendo originados? RSA-155 (também conhecido como RSA de 512 bits) foi fatorado em 6 meses em 1999 , RSA-120 (RSA de 397 bits) e RSA-130 (RSA de 430 bits) também são provavelmente apenas cerca de 1-2 bits simétricos diferentes ? Então, um aumento de aproximadamente 4 vezes é esperado...?

É por isso que entidades como ANSSI ou NIST baseiam suas recomendações não apenas no estado da arte atual das habilidades de computador ou conhecimentos de criptografia, mas também em melhorias futuras que devem ocorrer no período de uso/significado da chave

Você não forneceu nada substancial que indique que o RSA de 2048 bits esteja perto de fraco, mesmo com o contexto histórico em que foram feitas melhorias notáveis, que não parece tão relevante com o aumento exponencial. Você parece estar tendo uma visão um tanto linear? Espero que você saiba por que o AES de 128 bits é considerado seguro (aparentemente pode ser fraco para um computador quântico um dia usando o algoritmo de Grover) e que se diz que o AES de 256 bits exige que toda a energia do nosso sistema solar seja exausto para quebrar por força bruta.

Além disso, leve em consideração quais dados são confidenciais que você está tentando protegê-los sem considerar as práticas recomendadas, como usar apenas conjuntos de criptografia compatíveis com PFS, onde esses dados também são considerados problemáticos para serem descriptografados daqui a muitas décadas (um pouco de dados confidenciais não são tão importantes daqui a décadas como são no presente).

TL;DR

Isso se resume muito a isso. Quebrar 2048 bits, mesmo daqui a décadas, ainda será ridiculamente caro, mas vamos ser otimistas e dizer 1 milhão de dólares e 10 anos (ou 1, se você preferir).

• Este invasor está interessado em você especificamente agora que eles serão equipados para registrar o tráfego de seus servidores para N usuários (onde N não importa além dos requisitos de armazenamento, já que você está usando de forma insegura a mesma chave para toda a criptografia de qualquer maneira) .
• Esse tráfego vai ficar registrado por X anos, onde a cada 90 dias seu certificado está mudando exigindo um ataque separado para cada um (tempo e $$$$)? Ou o invasor sabe com antecedência quando registrar dados específicos nos quais está interessado, mesmo que demore várias décadas antes de acreditar que pode quebrar a criptografia?
• Esta é de alguma forma uma estratégia melhor e mais barata do que hackear seu servidor ou cliente de usuários diretamente e comprometer esse sistema (quero dizer, eles já se colocaram em um ataque MitM para capturar tráfego e estão determinados a acessar seus segredos com financiamento adequado, certo? ), eles não teriam os recursos disponíveis para escolher o ataque mais prático?
• Não seria mais barato e mais fácil ameaçar ou chantagear alguém diretamente para obter acesso à chave privada RSA? Então o tamanho da chave não importa, se você fosse inteligente e usasse apenas pacotes de criptografia PFS, essa estratégia seria irrelevante.

Soo basicamente...

Incentive os conjuntos de cifras PFS (DHE / ECDHE) e não pequenas melhorias para evitar práticas de segurança ruins

Portanto, seu conselho para melhorar a segurança aqui é incentivar o uso de um tamanho de chave maior em vez de incentivar conjuntos de criptografia somente PFS? Por quê?

Porque LE tem as mãos no tamanho da chave padrão, não na configuração httpd. E o LE já tomou providências no passado (https desabilitando em HTTP-01, removível de TLS-SNI-01…) em vez de impor a configuração httpd.

Por favor, elabore mais.

Certo. E simples veja o benchmark do cado-nfs. O tempo de craqueamento não é o tempo teórico esperado.
A lacuna de dificuldade teórica não é observada na prática devido a dois vieses. Podemos apenas comparar o tempo de crack para um dado estado da arte e ao mesmo tempo atual e esperar o gap teórico (e na prática, não é o caso, veja cado-nfs), mas nada garante que X+1 bits seja 2 vezes mais difícil do que X se compararmos o conhecimento atual e o poder de cálculo e o que teremos 1 mês depois.
E veja também os 2 exemplos que dou. Há apenas uma lacuna de 2 vezes entre 256 e 512 bits de crack entre 2015 e 2019, dada a mesma potência e custos, onde, em teoria, há uma lacuna de 10⁷⁷ vezes.
E não podemos garantir que não haverá um truque de quebra de 3072 RSA amanhã, onde 4096 bits permanecerão mais seguros.

Já vinculei ao projeto do Github que pode realizar a fatoração de 512 bits na AWS. Eu não sei a quantidade exata de bits de entropia simétrica de RSA de 256 bits, talvez em torno de 30 bits? (portanto, aproximadamente 1.048.576 vezes diferem entre RSA de 512 bits). O documento de 512 bits ao qual você vincula menciona 432 CPUs (12 instâncias com 36 vCPUs + 60 GiB de RAM cada) e um total de 2770 horas de CPU com 1,5-2 GB de memória ou armazenamento para a matriz (não estou muito familiarizado com esse cálculo, se você estiver à vontade para entrar em contato).

Sim, parece ser um número enorme e impraticável… Na época da primeira quebra de 512 bits (1999), era considerado impraticável porque exigindo super-computador ninguém tem. Mas, na verdade, a fatura correspondente da AWS para essa infraestrutura em 2015 é de US$ 100 por 4h e é prático alguns anos depois, muito mais rápido do que a lacuna de bilhões de bilhões de bilhões esperada em 1999.
https://arstechnica.com/information-technology/2015/10/breaking-512-bit-rsa-with-amazon-ec2-is-a-cinch-so-why-all-the-weak-keys/

Há apenas uma lacuna de 2 vezes entre 256 e 512 bits de crack entre 2015 e 2019, dada a mesma potência e custos, onde, em teoria, há uma lacuna de 10⁷⁷ vezes.

O que não. Eu fui muito claro sobre isso para você em meus posts que a diferença entre 256 bits e 512 bits não é 2^256(sua base 10, 10^77), mas mais como 2^20 ou menos (no comparação que fiz de seus dois exemplos de fatoração citados foi cerca de 2^17).

Também não tenho certeza de como você está reivindicando um "intervalo de 2 vezes"? Mesmo poder e custos? O RSA de 256 bits foi fatorado em aproximadamente 1 minuto, com o RSA de 512 bits sendo equivalente a 166.200 minutos (a matemática foi citada em meu post anterior, sinta-se à vontade para me corrigir se eu cometer um erro).

E não podemos garantir que não haverá um truque de quebra de 3072 RSA amanhã, onde 4096 bits permanecerão mais seguros.

Você literalmente vai ficar bem com o RSA de 2048 bits, o RSA de 3072 bits tem uma melhoria "marginal" na segurança, eu já expliquei isso, você parece ter pulado ou entendido mal? A única maneira de o RSA de 2.048 bits se tornar inseguro em um período de tempo muito menor é quando o RSA de 3.072 bits for ameaçado pela taxa de avanço.

Se você quiser estar mais seguro, não use o RSA para troca de chaves. Pedi para você citar um site onde a troca de chaves RSA é necessária ((EC)DHE não é suportado/negociado por qualquer motivo), por que você não conseguiu responder isso, você alegou que é uma ocorrência tão comum que justifica aumentar o comprimento de chave RSA padrão? Por favor, apoie essa afirmação. Você pode encontrar servidores que oferecem RSA como uma troca de chaves, mas eles provavelmente terão a seleção do conjunto de cifras do servidor habilitada e não serão negociadas por nenhum cliente que possa oferecer suporte a conjuntos de cifras PFS.

Mas, na verdade, a fatura correspondente da AWS para essa infraestrutura em 2015 é de US$ 100 por 4 horas e é prático alguns anos depois, muito mais rápido do que a lacuna de bilhões de bilhões de bilhões esperada em 1999.

O custo do hardware é consideravelmente superior a US$ 100, não são quantias ridículas, mas sim a disponibilidade para alugar/acessar facilmente recursos de computação como esse o tornou mais acessível. Observe o hardware usado, não eram instâncias EC2 baratas/pequenas, eram máquinas bastante grandes quando se trata de alugar recursos de computação, temos RSA de 768 bits fatorado há mais de uma década, mas você não vê FaaS sendo capaz de lidar com isso de forma barata? O RSA de 2048 bits é um longo caminho a percorrer.

Você tem uma fonte de alguém alegando que 512 bits exigia mais de um bilhão para computar? Tenho certeza de que os recursos de hardware em 1999, que incluíam meros 6 meses, estavam muito longe dos bilhões em custo. De onde vem esse preço? De declarações mais recentes sobre bits mais altos de segurança? Isso se deve ao aumento exponencial da dificuldade, que requer não apenas mais tempo de computação, mas outros recursos como a memória RAM. Essas instâncias de fatoração RSA de 512 bits da AWS tinham 60 GB de RAM, cada uma (720 GB no total)...

Veja rapidamente alguns insights de processamento:

O RSA-250 (RSA de 829 bits) que foi fatorado em 2020 foi alcançado em 3 meses com dezenas de milhares de computadores e usando o CADO-NFS que você gosta de trazer, parece que eles alcançaram a fatoração em aproximadamente o mesma quantidade de tempo de computação ~ ( EDIT: meu erro, anos, não horas) que a fatoração da AWS de RSA de 512 bits em 2015 alcançou (aproximadamente 2700 horas de CPU, AFAIK normalizado para um Intel Xeon Gold 6130 2,1 GHz referenciado). O RSA-240 (RSA de 795 bits) fatorado em dezembro de 2019 é interessante, pois foi da mesma equipe e no mesmo hardware que fatorou o RSA de 768 bits em 2010/2016 (também usando CADO-NFS). Eles notaram melhorias de algoritmo no software CADO-NFS, pois é o que permitiu um ganho de desempenho de ~ 3x.

Aqui está o artigo sobre a fatoração de 2010 do RSA de 768 bits , veja os requisitos de RAM:

O primeiro estágio foi dividido em oito tarefas independentes executadas em paralelo nesses clusters, com cada uma das oito sequências apontando uma vez a cada 214 etapas. A execução de uma sequência de primeiro (ou terceiro) estágio exigia 180 GB de RAM , um único ¯b de 64 bits de largura levou 1,5 gigabytes e uma única matriz mi 8 kilobytes, dos quais 565.000 foram mantidos, em média, por sequência de primeiro estágio. Cada soma parcial durante a avaliação do terceiro estágio exigia 12 gigabytes .

Na maioria das vezes, os 896 GB de RAM disponíveis eram suficientes, mas durante uma parte central do cálculo era necessária mais memória (até cerca de 1 TB)

E vamos contrastar isso com a fatoração RSA de 512 bits (2009, não a AWS em 2015) :

Em 2009, Benjamin Moody poderia fatorar uma chave RSA-512 bits em 73 dias usando apenas software público (GGNFS) e seu computador desktop (um Athlon64 dual-core com uma CPU de 1.900 MHz). Pouco menos de cinco gigabytes de armazenamento em disco foram necessários e cerca de 2,5 gigabytes de RAM para o processo de peneiramento.

Isso deve fornecer uma escala aproximada de dimensionamento de requisitos de RAM à medida que o comprimento da chave aumenta. Tenho certeza de que provavelmente há outros gargalos a serem observados no processamento, especialmente ao fazê-lo de maneira distribuída. Sinta-se à vontade para analisar mais a fundo e identificar quanta RAM seria necessária para atacar o RSA de 2048 bits.

De quem você está realmente tentando se proteger que está equipado para direcionar o tráfego de você ou de seus usuários especificamente para gravá-lo e realizar um ataque daqui a décadas?

Não é um script kiddy esperando por uma solução de US $ 100 da AWS, eles teriam mudado para coisas melhores até então e comprometer sua rede para registrar o tráfego custaria muito mais, caso contrário, é algum malware onde ninguém específico foi direcionado, parabéns seus dados gravados segmentados em períodos de 90 dias de tráfego por chave RSA está agora em um mar de muitos outros, milhares, milhões talvez, $ 100 AWS mesmo se possível não seria muito barato atacar tudo isso, especialmente quando os dados têm valor desconhecido, haveria um muito lixo para jogar dinheiro fora.

Não, se alguém quiser seus segredos, há maneiras mais acessíveis.

Por alguma razão, você acredita que uma segurança 4 bilhões de vezes mais forte de RSA de 1.024 bits a 2.048 bits é inadequada, mas 65k vezes mais segurança de RSA de 2.048 bits a 3.072 bits é adequada. Seu argumento é que a teoria de segurança de 2048 bits sendo segura computacionalmente é inválida, mas de alguma forma essa mesma lógica para RSA de 3072 bits não se aplica e é muito mais segura? Uma porta de vidro é mais segura porque adiciono fechaduras maiores e mais seguras?

TL;DR

Por favor, reveja o TL;DR anterior, mas vou reiterar.

• Alguém quer gravar seu tráfego criptografado usando uma chave RSA fraca de 2048 bits.
• Eles são capazes de realizar esse ataque MitM, portanto, eles têm habilidades ou dinheiro e provavelmente é um ataque direcionado.
• Seus dados devem manter o valor no futuro que é desejável adquirir agora, mesmo que só possam ser descriptografados em mais de 20 anos por suas estimativas.
• O ataque precisa ser justificável pelo custo de execução para obter o valor do segredo, deve-se saber qual janela de 90 dias capturar, caso contrário, o ataque deve ser computado várias vezes na esperança de adquirir o referido segredo.
• Este ataque é de alguma forma mais eficaz do que qualquer outro método para adquirir esses dados de forma mais rápida / barata?

Quem em sã consciência vai fazer isso? Isso só será prático em um alvo de alto valor, onde nenhum outro meio de obter essa informação é viável. O referido alvo está de alguma forma na posse de tais segredos valiosos, mas não se preocupa em pagar um profissional ou considerar as melhores práticas para protegê-los (eles aparentemente não podem configurar um servidor com o conselho de copiar/colar do pacote de criptografia da Mozilla).

Isso não é muito convincente. Este não é o LetsEncrypt, você está assumindo que um usuário com segredos valiosos usa o Certbot junto com os conjuntos de criptografia de troca de chaves somente RSA suportados por seu servidor (nenhuma configuração padrão faz isso) e que o RSA de 2048 bits é muito mais fraco do que é? Quem quer que seja esse usuário, suas práticas de segurança em outros lugares provavelmente são fracas o suficiente para comprometê-los diretamente, por que esperar 20 a 30 anos para descriptografar dados quando você pode executar um ataque ativo e obter todos os dados interessantes no presente?

A solução correta é configurar os conjuntos de cifras corretamente, e este projeto Certbot faz exatamente isso se você não tiver experiência na área e quiser confiar que ele cuida disso para você. Mas por alguma razão, isso não se aplica a esta discussão?

Pedi para você citar um site onde a troca de chaves RSA é necessária ((EC)DHE não suportado/negociado por qualquer motivo)

https://cryptcheck.fr/https/bankofamerica.com (sim, você leu corretamente)
https://cryptcheck.fr/https/caf.fr (administração estadual para a França, equivalente ao US Supplement Security Income)
https://cryptcheck.fr/https/xn--trkiye-3ya.gov.tr
https://cryptcheck.fr/https/pfisng.dsna-dti.aviation-civile.gouv.fr
https://cryptcheck.fr/https/reader.xsnews.nl
https://cryptcheck.fr/https/protecpo.inrs.fr
https://cryptcheck.fr/https/tiscali.it

Eu conto 68 domínios não PFS no meu CryptCheck v2 sobre 7221 análise de handshakes (~0,9%) e 2091 sobre 349961 análise de handshakes (~0,6%) no meu v1.

https://www.bankofamerica.com/

Protocolo: TLS 1.2
Troca de chaves: ECDHE_RSA
Grupo de troca de chaves: P-256
Cifra: AES_128_GCM
CA: Confiar

https://cryptcheck.fr/https/bankofamerica.com supostamente está identificando IPs de servidor adicionais para o mesmo domínio que não fornecem a troca de chaves ECDHE?

https://www.caf.fr/

Protocolo: TLS 1.2
Troca de chaves: RSA
Cifra: AES_128_CBC com HMAC-SHA1
CA: Certinga

Não tenho ideia do que trata este site ou quais segredos confidenciais ele deve explorar?

https://www.turkiye.gov.tr/

Protocolo: TLS 1.2
Troca de chaves: RSA
Cifra: AES_128_CBC com HMAC-SHA1
CA: GlobalSign

Fui redirecionado para isso a partir do seu nome de domínio de aparência estranha que não consigo imaginar que alguém visitaria diretamente e consideraria um nome legítimo / confiável.

Este, como muitos outros a seguir, é claramente um site do governo. Eles geralmente estão atrasados ​​e precisam ser acessíveis a um público amplo, mas o RSA não deve ser a troca de chaves padrão, mas, novamente, quais comunicações estão acontecendo aqui das quais você deseja se proteger? O próprio governo não parece estar muito preocupado, obviamente.

https://pfisng.dsna-dti.aviation-civile.gouv.fr/jts/auth/authrequired

Protocolo: TLS 1.2
Troca de chaves: RSA
Cifra: AES_128_GCM
CA: Certinga

Novamente, não faço ideia do que seja, além de um serviço do governo com login. Há alguma informação sensível além dos detalhes de login? Quais são as preocupações aqui em relação ao acesso a informações confidenciais daqui a 20-30 anos? Que eu use o mesmo nome de usuário e senha em outro lugar e ainda continue a fazê-lo em 20-30 anos?

Um golpe de phishing não seria tão eficaz se os detalhes de login fossem desejados (e o valor dos dados nas contas). Isso poderia ser alcançado em menos tempo ou orçamento menor do que atacar o certificado RSA?

https://reader.xsnews.nl/

Mais de um minuto gasto tentando carregar/resolver o URL, não consegui acessar este site.

https://protecpo.inrs.fr/ProtecPo/jsp/Accueil.jsp

Protocolo: TLS 1.2
Troca de chaves: RSA
Cifra: AES_128_GCM
CA: GEANT

Este parece ser um site de algum software que você pode usar para ajudar a tomar uma decisão de compra. Quais informações confidenciais estão em risco aqui?

https://www.tiscali.it/

Protocolo: TLS 1.2
Troca de chaves: RSA
Cifra: AES_256_CBC com HMAC-SHA1
CA: Thawte

Um site de notícias? Novamente, quais informações confidenciais são preocupantes na interação com este site?

Resumo

Não há nada em nenhum desses resultados que indique a necessidade de proteger comunicações confidenciais além dos 20 a 30 anos estimados de comprometimento do RSA de 2.048 bits. Esses sites ainda exigiriam um ataque MitM eficaz para capturar esse tráfego entre o cliente e o servidor, o que provavelmente não é uma preocupação válida para nenhum deles?

Nenhum deles usa certificados emitidos pela LetsEncrypt. Fazer uma alteração para o Certbot só é benéfico se você tiver certeza de que esses sites estão usando o Certbot especificamente como um cliente ACME para essas CAs (supondo que eles tenham suporte ACME de terceiros).

Obrigado por apontar alguns sites onde o RSA é a troca de chaves negociada (exceto o Bank of America que parece estar incorreto e só foi validado como conjunto de cifras para o site público, não quaisquer trocas confidenciais reais).

Eu conto 68 domínios não PFS no meu CryptCheck v2 sobre 7221 análise de handshakes (~0,9%) e 2091 sobre 349961 análise de handshakes (~0,6%) no meu v1.

Ok, então o seu "não raro" é menos de 1% dos 7.221 e 349.961 sites que você escaneou com o CryptCheck? Agora, considere o público e o valor real mensurável oferecido pelo uso de RSA de 3072 bits para proteger essas comunicações. Será que isso realmente vale a pena e seria mais seguro contra alternativas mais baratas para comprometer a segurança? (como em, era 2048 bits mais fraco/mais barato do que qualquer outro ataque direcionado alternativo, onde 3072 bits aumenta o limite inferior do ataque)

Quantos dos 1 milhão de principais sites da Alexa estão negociando a troca de chaves RSA? Quantos dos encontrados usam LetsEncrypt como CA?

Calculei bits simétricos para RSA de 512 bits e 256 bits (com base na equação do NIST), e obtemos 40 bits (RSA de 256 bits) e 57 bits (RSA de 512 bits).

Curiosamente, isso corresponde à diferença de 17 bits citada anteriormente ao comparar os dois cálculos com os avanços recentes (parece que o documento NIST que mencionei foi atualizado pela última vez em 2020).

Ele também revela que a distância para RSA de 1024 bits é de apenas 23 bits de força de chave simétrica equivalente, 8.388.608. E podemos ver que o progresso atual para RSA de 768 bits e 795 bits ou o registro atual de RSA de 829 bits é:

768 == 69.74588053597235
795 == 70.91595938496408
829 == 72.35600867501326

• Registro RSA de 768 bits desde 2010 com RSA de 829 bits como registro em 2020, melhoria de menos de 3 bits ao longo de uma década. 2000 vs 2700 anos de CPU (single-core). O RSA de 795 bits caiu para 900 anos de CPU em novembro de 2019.
• 57 bits (512 bits RSA) a 72 bits (829 bits RSA) com ~2700 horas de computação~ ( EDIT: horas vs anos, whoops) entre 2015 e 2020. ~15 bits (32.768) melhoria~? (O RSA de 829 bits levou 3 meses e dezenas de milhares de máquinas em comparação). As fatorações RSA de 768 bits (dezembro de 2009) e 795 bits (novembro de 2019) destacaram ser cerca de 3 vezes mais rápidas devido apenas às melhorias de software/algoritmo.
• 2^6 (64) estimativa para a melhoria RSA de 256 bits desde 1991.
• ~2^10 (1024) para a diferença de 1080 x com 512 bits ao longo de 16 anos (1999 - 2015) 6 meses vs 4 horas, não está claro o quão preciso é uma comparação, 8.000 MIPS anos vs 2770 anos da CPU Intel normalmente referenciado. A principal diferença aqui provavelmente foi devido ao acesso ao aluguel de hardware mais barato com computação em nuvem para reduzir o tempo, aproveitando 15 anos de melhorias de HW e melhorias de algoritmo no software desde então.

Acabei de perceber que cometi um erro anteriormente ao citar a fatoração RSA de 829 bits e compará-la ao tempo de fatoração RSA de 512 bits da AWS. Ambos citam ~ 2700 unidades de computação de tempo, mas eu tropecei com RSA de 829 bits sendo anos e RSA de 512 bits sendo horas. Isso parece ser uma diferença de cerca de 8.760 ( (8760hrs * 2700yrs) / 2700hrs , onde 8.760 são horas em um ano) vezes (2^13) o que eu acho que é 4 anos ( (4hrs * 8760hrs) / 24hrs / 365days ) o que seria próximo de um milhão de dólares de tempo de computação na AWS? (ignorando o fato de que você provavelmente precisa de um pouco mais de RAM)

RSA de 256 bits Tempo de computação de 1 minuto vs RSA de 829 bits Tempo de computação de 2.700 anos = log2(525600mins * 2700yrs) (minutos em um ano) equivale a aproximadamente 2^30. Novamente, semelhante à dificuldade de computação RSA de 512 bits, isso é muito próximo de um delta da diferença assumida de 2 ^ 32 bits na força. Podemos ser capazes de fatorar as chaves RSA mais rapidamente, mas a dificuldade de computação parece ser mantida aproximadamente?

Não é a maior informação, mas o suficiente para termos uma ideia aproximada da taxa de progresso e melhorias.

• A dificuldade de calcular é aproximadamente precisa e consistente ao longo de décadas?
• A taxa de computação aprimorada para realizar a fatoração mais rapidamente melhorou bem, mas não em uma quantidade significativa?

1024 bits ainda permanecerão fora de alcance por algum tempo, e 2048 bits ainda mais com base no progresso histórico abordado acima. Há poucas evidências de que o RSA de 3072 bits com seus 2^16 (65k) adicionais a 2^22 (4 milhões) bits de dificuldade extra representará muito mais vantagem de segurança do que os 2^30 (1 bilhão) a 2^ 32 (4 bilhões) de 2048 bits tem mais de 1024 bits RSA. (não que isso não adicione uma dificuldade adicional notável, mas com base na suposição de que o próprio RSA de 2048 bits não aguentará o suficiente quando deveria)

Com base no esforço atual de RSA de 829 bits e que há uma diferença de aproximadamente 38 bits no nível de segurança de bits para RSA de 2048 bits. Se considerarmos o poder de computação constante que fatorou o RSA de 829 bits em 3 meses (4 durações de três meses em um ano), obteremos 68.719.476.736 anos ( 2^38 / 4 ), mesmo que tivéssemos avanços para reduzir para 1 bilhões de vezes menos trabalho (2^30), ainda são cerca de 64 anos, e isso com dezenas de milhares de máquinas .

Se você ainda acha que 3072 bits no mínimo vale a pena, apesar da minha (possivelmente ruim?) matemática, análise de custo-benefício e raciocínio de bom senso ... então acho que não tenho mais nada que possa contribuir para convencê-lo do contrário .

Apenas lembre-se de que você está defendendo uma mudança com o Certbot, não com o LetsEncrypt impondo um mínimo para emitir. O Certbot já ajuda os usuários configurando conjuntos de criptografia adequados que evitam todo o problema de qualquer maneira, então quem realmente vai se beneficiar aqui - enquanto todos os outros (usando o Certbot) que não têm RSA sendo usado como troca de chaves estão adicionando mais carga e largura de banda em seus servidores (mesmo que menores para a maioria).

A questão deve ser encerrada.

https://www.keylength.com/

https://www.keylength.com/

Você já contribuiu com essa informação há 4 anos neste tópico . Parece que você não entende o contexto do conselho desse site e como ele se aplica aqui.

Se você se sentir mais confortável com RSA de 3072 bits ou comprimentos de chave maiores para seus certificados, opte explicitamente por tal como você já pode, não há razão justificada ao se preocupar com segurança pragmática para adotar 3072 bits como um novo padrão . RSA de 2048 bits é suficiente .

Você já contribuiu com essa informação há 4 anos neste tópico . Parece que você não entende o contexto do conselho desse site e como ele se aplica aqui.

Você não entende mais. O conselho ANSSI é, por exemplo,

No âmbito do desenvolvimento dos telesserviços e das trocas eletrónicas entre a administração e os utilizadores, as autoridades administrativas devem garantir a segurança dos seus sistemas de informação encarregados da implementação destes serviços.
A Referência Geral de Segurança é imposta especificamente aos sistemas de informação implementados pelas autoridades administrativas nas suas relações entre si e nas suas relações com os utentes (estes são os telesserviços como o pagamento de multas à Administração).
Indiretamente, a Referência Geral de Segurança destina-se a todos os prestadores de serviços que auxiliam as autoridades administrativas na segurança das centrais eletrónicas que implementam, bem como aos fabricantes cuja atividade seja a oferta de produtos. de segurança.
Em geral, para qualquer outra organização que pretenda organizar a gestão da segurança dos seus sistemas de informação e intercâmbios eletrónicos, a Referência Geral de Segurança apresenta-se como um guia de boas práticas de acordo com o estado da arte.

E assim é aplicável na França para QUALQUER PROPÓSITO E QUALQUER MEIO , e não está restrito a contextos sensíveis como propósito militar.

E um dos conselhos é "Recomenda-se usar módulos de pelo menos 3072 bits, mesmo para um uso não superior a 2030 ". E 3072 bits não é mais um conselho, mas é obrigatório se o uso/impacto for esperado após 2030.

Mesmo a CNIL, entidade francesa sobre privacidade e boas práticas, usa o documento ANSSI em sua recomendação padrão para qualquer site : https://www.cnil.fr/fr/securite-securiser-les-sites-web

A ANSSI publicou em seu site recomendações específicas para implementar o TLS ou para proteger um site.

(E também está em oposição ao Let's Encrypt porque afirma que você tem que you must authorize only incoming IP network flows on this machine on port 443 and block all the other ports. mas isso )

Os conselhos do NIST não estão vinculados à sensibilidade de transmitir informações, mas são conselhos gerais aplicáveis ​​em todos os casos em que você também precisa gerenciar a chave ou o certificado.

Não é a primeira vez que o LE usa a configuração padrão em oposição a conselhos de última geração de agências governamentais ou outros…

Ah, e a revisão do BSI aconselha este ano. Ele afirma que

Nota importante: É razoável usar um comprimento de chave de 3000 bits para RSA , DH e DSS, a fim de obter um nível de segurança homogêneo para todos os mecanismos assimétricos. A partir de 2023, é necessário um comprimento de chave de pelo menos 3.000 bits para implementações criptográficas que devem estar em conformidade com esta Diretriz Técnica.

@aeris , mesmo que a França estivesse impondo o RSA de 3072 bits como obrigatório, isso não é lei em outros lugares. Observe que o conselho e a recomendação também não equivalem a um requisito obrigatório.

Eu ficaria surpreso se eles também sugerissem o uso da troca de chaves RSA em conjuntos de cifras como prática recomendada para segurança/privacidade. Se você deseja lidar com segurança e privacidade corretamente, adote conjuntos de criptografia somente PFS, seu certificado RSA será irrelevante a partir desse ponto, pois ele desempenha apenas um papel na autenticação.

Enfim, sinto que estou me repetindo aqui e não estou interessado em um vai e vem sem fim. Se você tiver que cumprir determinadas autoridades/avisos de segurança, faça-o sendo explícito sobre isso. Eu já detalhei muito bem que 2048 bits é seguro e assim permanecerá no futuro próximo, se não for, o RSA de 3072 bits provavelmente também não será seguro.

Como você é bastante apaixonado por este tópico, tente entender o que eu transmiti a você, em vez de recitar NIST / ANSSI / BSI / etc, é do interesse deles aconselhar um pouco mais do que o necessário, semelhante a como AES- 128 foi introduzido como o nível de segurança mais baixo/mais fraco para AES, mas consideravelmente seguro por si só.

Tudo o que você está ganhando com 3072 bits é uma falsa sensação de "mais seguro", devido ao fato de 2048 bits ser mais do que suficiente que, se não fosse, não há razão para pensar que 3072 bits será mais seguro, pois é 16 bits adicionais de segurança não acompanharão esses avanços. Faça a coisa inteligente e não continue usando o RSA como uma troca de chaves... se você confiar apenas em um comprimento de chave RSA maior como sua sensação de segurança em vez de aplicar práticas de segurança em outro lugar, você está se enganando.

Se você quiser continuar discutindo por uma questão de conformidade, em vez de benefício real de segurança, vou deixá-lo com isso. Pessoalmente, não vale a pena mudar para o padrão e, para a maioria dos usuários do Certbot, provavelmente é indesejado devido a desvantagens e nenhum ganho pragmático na segurança real.

Não é a primeira vez que o LE usa a configuração padrão em oposição a conselhos de última geração de agências governamentais ou outros…

Provavelmente porque eles sabem melhor, apesar do que você possa pensar. Mesmo com todas as informações apresentadas a você anteriormente, você não parece interessado ou aberto a isso.

Embora provavelmente não o convença mais, é isso que a força simétrica de 2^128 bits exige para atacar com sucesso :

O consumo total de energia mundial atual é de cerca de 500 EJ (5×10^20 J) por ano (ou assim diz este artigo).

Isso levaria a um total geral de 2^138 no ano de 2040 - e isso é para uma única computação de dez anos que mobiliza todos os recursos de todo o planeta .

Outro insight divertido :

Resumindo: mesmo que você use todos os dólares do mundo (incluindo os dólares que não existem, como dívidas acumuladas) e frite o planeta inteiro no processo, você mal consegue fazer 1/1000 de uma busca exaustiva de chaves em Chaves de 128 bits .

As chaves de criptografia simétricas de 256 bits excederiam toda a energia disponível em nosso sistema solar para quebrar:

As leis do universo físico significam que mesmo chaves desses tamanhos modestos nunca serão forçadas com força bruta . Isso não quer dizer que eles nunca podem ser quebrados. Falhas podem ser descobertas em algoritmos

não há nada mais forte do que "não pode quebrá-lo", então comparar forças além de 100 bits ou mais não tem sentido de qualquer maneira. - Fonte

Agora, todas essas citações estão focadas em chaves de 128 bits como RSA de 3072 bits, mas os 110-112 bits de RSA de 2048 bits ainda são bastante consideráveis. No entanto, é muito mais barato apenas seguir a rota recomendada pelo XKCD :)

Parece que os argumentos mudaram de segurança para conformidade.

Parece que os argumentos mudaram de segurança para conformidade.

Ou não. Estes são apenas conselhos de última geração de entidades conhecidas relacionadas ao ecossistema de segurança sobre o que usar por padrão para evitar tiros nos pés, como vemos regularmente no mundo TLS/X.509 há pelo menos uma década.