Certbot: 기본 RSA 키 비트 길이는 3072여야 합니다.

4096을 제안하기도 합니다(거의 모든 시스템에서 수행합니다).

감사 해요,
남자 이름

4096도 추천합니다.

그러나 몇 달 전, 그들은 기본적으로 4096에 동의하지 않습니다: https://github.com/letsencrypt/letsencrypt/issues/489

기본적으로 보안이 전혀 없는 것과 비교하여 타협(= 3072비트 모듈러스가 있는 RSA)을 선호합니다.

4096도 추천해주세요.
보안은 기본적으로 양호해야 합니다. 표준 사용자는 기본 구성을 변경할 수 없습니다.

그리고 2048/3072 대 4096 비트(매우 작은 속도 오버헤드)에 대한 허용 가능한 인수가 없습니다.
3072비트는 사용자 에이전트가 일부 키 크기를 하드코딩하는 경우 호환성 문제를 일으킬 수 있습니다(2048 및 4096비트가 3072보다 더 잘 지원됨).

최악의 경우 2048비트 키 사용을 정당화하기 위한 90일 키 재생성의 주장은 좋지 않습니다.

• 키 재생성은 DANE/TLSA 또는 HPKP와 같은 다른 많은 TLS 스택 보호를 깨뜨립니다. 강화된 구성은 큰 문제를 피하기 위해 비활성화해야 합니다.
• 키 재생은 "과거의 파괴"를 말하지 않습니다. 웹 서버가 PFS 암호 제품군만으로 올바르게 구성되지 않은 경우 NSA와 같은 기관은 2048비트 키로 보호되는 네트워크 통신을 가로채어 저장할 수 있으며 해당 키가 파괴되더라도 20년 또는 30년 내에 암호를 해독할 수 있습니다. 4096비트 키는 더 긴 비 PFS 통신을 보호합니다.
• PFS 전용 암호를 사용하는 경우에도 웹 서버는 일반적으로 개인 키 크기에 따라 협상된 DH 매개변수를 기반으로 합니다. 2048비트 개인 키만 사용하는 경우 DH 매개변수는 2048비트만 사용하므로 LogJam에 취약할 수 있습니다.

4096에 대한 또 다른 +1은 제가 요즘 항상 사용하는 것입니다.

이 문제에 대한 많은 논의는 #489를 참조하십시오.

LE의 기본 설정인 RSA 2048비트, 90일, 크랙을 시도하시겠습니까? 이 문제를 종료하는 것이 좋습니다.

문제는 «크랙할 수 있다는 증거»(또는 1024비트로 유지, 지금은 아무도 크랙하지 않음)가 아니라 « 모든 권장 사항/최신 기술에서는 최소 3072비트를 요구합니다»(NSA, NIST, ANSSI, FIPS, Qualys 및 더).
기본적으로 4096 비트로 업그레이드하는 데 유효한 단점은 없습니다.

(그리고 90일 키 갱신이 있더라도 PFS를 사용하지 않으면 기술적 유효 기간이 90일에 불과하더라도 수십 년의 실질적인 키 유효 기간을 가지며 90일 키 갱신은 다른 많은 TLS 스택(TLSA, HPKP, 인증서 고정), 따라서 정상적인 시스템 관리자는 이를 비활성화하고 실제로 최소 120일 및 1년 동안 키를 재사용 해야 합니다)

그러나 Alexa 상위 1,000,000개 웹 사이트에서 SSL/TLS 지원 웹 사이트의 89% 이상이 많은 온라인 뱅킹 웹 사이트를 포함하여 RSA 2048비트를 사용합니다.

예, https://imirhil.fr/tls/#Banques %20en%20ligne을 원하는 경우 은행에도 SSLv3 및 MD5가 있습니다.
그리고 구글/유튜브도 https://imirhil.fr/tls/alexa.html
그리고 포르노 사이트에는 TLS가 전혀 없습니다 https://imirhil.fr/tls/porn.html
CA에도 SSLv3, MD5, RC4 또는 SSLv2(예, 올바르게 읽었습니다...) 및 40비트 EXPORT 제품군이 있습니다. https://imirhil.fr/tls/ca.html

TLS 구성은 야생에서 매우 나쁩니다. 이것은 계속해서 크랩을 하는 것이 아닙니다.

@devnsec-com 그래서 그들은 안전하지 않습니다. IPv6과 DNSSEC는 좋은 기술이지만 아직 대규모로 배포되지는 않았습니다. RSA 4096비트에서도 동일하게 발생합니다. 물을 밟는 대신 앞으로 나아가야 합니다.

RSA 3072 또는 4096(또는 그 이상)을 사용하는 유일한 이유는 미래 보장이지만 90일만 인증서를 사용하는 경우 모든 사용자에게 기본적으로 2048보다 긴 RSA가 정말로 필요합니까? 당신이 정말로 편집증이라면 더 긴 키를 찾으십시오. 매개 변수가 있으며 변경할 수 있습니다.

모든 사용자는 기본적으로 3072+ 키가 필요합니다.

자신이 하는 일을 실제로 알고 있는 사람들은 결국 크기를 줄일 수 있지만 기본적 으로 Let's encrypt는 최신 호환 구성을 제공해야 합니다.
표준 사용자(실제로는 99%)는 구성을 살펴보거나 생성된 키의 크기에 신경 쓰지 않거나 TLS가 실제로 무엇인지조차 알지 못합니다.

우리는 SSL/TLS 인증서에 대해 이야기하고 있으며 서버에서 PFS를 지원할 수 있으며 필요한 경우 취소할 수 있음을 기억하십시오. 20년 이상 사용할 수 있는 OpenGPG 키 또는 SSH 키에 대해 이야기하는 것이 아닙니다.

그리고 몇 년 후 RSA 2048이 실제로 더 이상 안전하지 않다는 것이 입증되면 LE 기본값을 RSA 4096으로 변경할 수 있습니다. 거의 모든 사용자는 90일 이내에 RSA 4096으로 변경됩니다.

OpenGPG에 대해 언급했기 때문에 OpenGPG도 기본적으로 RSA 2048이라고 말하고 싶습니다.
이것을 읽으십시오: https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

당신 은 할 수 있습니다 . PFS도 없을 수 있습니다. 그리고 2048비트 키라면 안전 하지 않습니다 . 90d 리뉴를 해도. 그리고 PFS가 없다면 키 파괴는 쓸모가 없으며 데이터는 이미 자연 상태에 있으며 수십 년 안에 해독되어야 합니다.

그리고 키가 아닌 인증서만 해지할 수 있습니다.
키는 GPG/SSH 키와 정확히 같습니다. 생성 후 PFS인 경우 지표면이 물리적으로 파괴될 때까지, PFS가 없는 경우 영원히 처리해야 합니다.

OpenGPG에 대해 언급했기 때문에 OpenGPG도 기본적으로 RSA 2048이라고 말하고 싶습니다.

GPG는 4096개 키를 사용하는 데 실질적인 단점이 있습니다(2048개 이상의 스마트카드 지원, 모바일 장치…). TLS에는 없습니다.

그리고 GPG에서 모든 사람은 현재 4096비트 키를 생성하며 모든 자습서 및 권장 사항은 이를 요구합니다.

RSA 2048 이상의 기본값을 주장하는 대신 PFS를 활성화하는 기본값에 대해 이야기해야 합니다. 키의 길이에 관계없이 조만간 해독될 것이기 때문에 RSA 2048도, RSA 4096도 해독됩니다.

네, 하지만 Let's Encrypt로 PFS를 보장할 수 있는 방법은 없습니다(그리고 더 나쁜 것은 PFS 암호뿐 아니라 PFS 암호 제품군을 협상할 수 있지만 서버는 PFS 없음 또는 내보내기를 지원할 수 있습니다...).

그리고 현재 PFS 암호 제품군만 사용하는 주요 단점이 있습니다(브라우저 호환성, https://tls.imirhil.fr/suite/EECDH+AES:EDH+AES+aRSA 참조).

모든 경우에 이것은 CA의 작업이 아닙니다.

여기서 CA가 아니라 클라이언트 소프트웨어에 대해 이야기하는 것입니다. 맞습니까?

아니요. TLS는 스택이 많고 매우 복잡합니다.
어떤 소프트웨어도 완전히 처리할 수 없습니다.

사용자에게 DNSSec 또는 TLSA가 있는지, IE 호환성을 보장해야 하는지, 표준 사용자 에이전트가 아닌지, 어떤 버전의 OpenSSL이 사용되는지 등을 추측할 방법이 없습니다.
LE가 할 수 있는 유일한 일은 키 크기를 높이는 것뿐입니다...

아니요, LE가 기본적으로 RSA 3072 또는 4096을 사용할 때 누군가는 모든 사용자에게 기본적으로 RSA 8192를 원한다고 말할 것입니다. 이것은 끝없는 군비 경쟁입니다.

@devnsec-com 아니요. NSA, NIST, ANSSI, FIPS, Qualys는 RSA 8192를 권장하지 않지만 최소한 RSA 3072를 권장합니다.

아니요, 누군가 8192를 요청하면 4096이 현재 안전하고 모든 곳에서 권장된다고 말할 수 있습니다.
현재 이것은 2048의 경우가 아닙니다.

나는 또한 Yubico , Cisco 및 많은 회사들이 우리가 말하는 시점에서 RSA 2048을 권장하고 있다고 말할 수 있습니다.

키 길이가 길수록 더 안전하지만 비즈니스 회사는 이 주제에 대해 더 실용적입니다. 다시 말하지만, 필요할 때 더 긴 키를 지원하는 한 RSA 2048은 현재 단계에서 기본값으로 충분합니다.

이 대화를 위한 좋은 리소스 - keylength.com

@devnsec-com Yubico 및 Cisco 입장은 하드웨어 문제가 있기 때문에 유효합니다(HSM, PKI 및 스마트 카드는 4096비트를 잘 지원하지 않음).

Yubico에서 : « 이것은 Yubico의 제약이 아니라 YubiKeys 내에서 사용되는 NXP A700x 칩의 하드웨어 제한입니다. »
Cisco에서: 4096비트는 Cisco IOS XE Release 2.4에서만 사용 가능하고(하드웨어는 업그레이드하기 어렵습니다) 주어진 페이지가 매우 오래되었습니다(2.4 릴리스(2009) 이후 업데이트되지 않은 것 같습니다. 최소 2.X 릴리스 이후 동일한 기본값). …).

그리고 이것은 우리가 따라야 할 다른 양들이 모두 절벽을 향해 달리고 있기 때문이 아닙니다...

@devnsec-com 또한 Cisco 문서가 PKI 및 CA 관리에 관한 것이며 이 분야(최종 사용자 인증서가 아닌 CA 인증서)에서 CA/B-forum 은 최소 2048비트를 권장 한다고 덧붙였습니다.

그리고 2014년부터 4096개의 내포물에 대한 내부 논쟁 도 있습니다.

키 크기에 대한 권장 사항을 포함하시겠습니까? 어떤 사람들은 의도적으로 4096비트 키를 사용하려고 합니다. 그들이 조언을 받을까요? 문서는 보안, 호환성 및 기타 요소 간의 균형을 설명할 수 있습니다.

그러나 하드웨어 라우터는 2048(Cisco) 이상의 루트 를 지원하지 않는 것 같습니다.

Iñigo는 Cisco의 최신 제품이 SHA-1 및 4096비트 루트를 지원하지 않는다고 말했습니다. Kelvin은 이를 변경하기 위해 Cisco와 협력할 수 있다고 말했습니다.

@devnsec-com CA/B-forum에 대한 또 다른 내부 의견 입니다.

보안/성능 향상을 위한 다음 변경 세트의 목표 날짜 설정(RSA-4096/ECC/SHA-512/etc)

안녕하세요 여러분, 이 스레드를 계속 유지하고 LE 직원의 답변을 듣는 것이 좋을 것입니다.
내가 읽을 수 있는 한 @aeris 인수는 유효하고 모순되지 않는 것 같습니다. 우리가 뭔가를 놓친 경우를 제외하고는 LE가 기본 RSA 키를 곧 4096비트로 전환할 것으로 예상합니다.

기본적으로 RSA 3072비트의 경우 +1입니다.

언급했듯이 RSA 2048비트는 112비트의 대칭 키 보호와 동일합니다. 이는 오늘날 널리 사용되는 최소 128비트보다 낮습니다. RSA 3072비트는 128비트와 동일하므로 현재로서는 충분합니다(2016년 1월 현재 NSA에서 권장하는 최소값).

키 크기의 수명에 대한 이전의 모든 추정은 일반적으로 키 해독의 선형 개선을 가정하지만 새로운 공격은 보안을 훨씬 더 빠르게 감소시킬 수 있기 때문에 건전한 회의론으로 받아들여야 합니다.

2048비트를 초과하는 RSA 키는 현재 Amazon Web Services와 호환되지 않습니다. Amazon CloudFront 개발자 안내서 에서:

SSL/TLS 인증서에서 공개 키의 최대 크기는 2048비트입니다.

이 추가 요점을 대화에 추가할 것이라고 생각했습니다.

2048비트보다 큰 RSA를 원하는 사람은 --rsa-key-size 3072 또는 --rsa-key-size 4096 를 입력하여 이러한 키 크기를 요청할 수 있습니다.
더 큰 RSA 키는 생성하는 데 기하급수적으로 더 오래 걸리며 4096보다 크면 이전 Apple 브라우저가 충돌할 수 있습니다.

#2632가 구현되었을 때 성능상의 단점은 대다수에게 거의 영향을 미치지 않을 것입니다.
따라서 EC 256과 3072 RSA(또는 기본적으로 선호하는 것)를 결합하여 둘 다에 동일한 강도를 제공할 수 있습니다.

그건 그렇고, EC 키를 지원하기 위한 제안으로 --ec-key-type 와 같은 명령으로 EC 키를 생성하고 인증서를 요청하십시오.
현재 certbot을 사용하여 RSA 키를 생성하고 셸 스크립트를 사용하여 EC 키를 서명합니다.

@WilliamFeely #2625

감사 해요.
RSA 키 크기에 관해서는 RSA 2048이 여전히 업계 표준이고 PCI-DSS 준수에 대한 승인을 받은 것으로 추측됩니다. 따라서 여전히 기본값인 이유는 무엇입니까?

최신 PCI-DSS 문서( v3.2, 2016년 4월 )는 다음과 같습니다.

강력한 암호화 및 보안 프로토콜(예: NIST SP 800-52 및 SP 800-57, OWASP 등)에 대한 정보는 업계 표준 및 모범 사례를 참조하십시오.

다행히도 용어집 은 강력한 암호화 를 다음과 같이 정의합니다.

업계에서 테스트되고 승인된 알고리즘과 최소 112비트의 효과적인 키 강도 및 적절한 키 관리 방식을 제공하는 키 길이를 기반으로 하는 암호화. 암호화는 데이터를 보호하는 방법이며 암호화(가역적)와 해싱("단방향", 즉 되돌릴 수 없음)을 모두 포함합니다. 해싱을 참조하십시오.

발행 당시 업계에서 테스트되고 승인된 표준 및 알고리즘의 예에는 AES(128비트 이상), TDES/TDEA(3중 길이 키), RSA(2048비트 이상), ECC(224비트 이상)가 포함됩니다. 및 DSA/DH(2048/224비트 이상). 암호화 키 강점 및 알고리즘에 대한 자세한 지침은 NIST 특별 간행물 800-57 파트 1(http://csrc.nist.gov/publications/)의 최신 버전을 참조하십시오.

_ 참고 : 위의 예는 카드 소지자 데이터의 영구 저장에 적합합니다. PCI PIN 및 PTS에 정의된 트랜잭션 기반 작업에 대한 최소 암호화 요구 사항은 노출 수준을 줄이기 위한 추가 제어가 있기 때문에 보다 유연합니다.
모든 새로운 구현은 최소 128비트의 유효 키 강도를 사용하는 것이 좋습니다._

웹 서버와 함께 사용되는 RSA 키에 대해 기본값을 3072로 설정할 필요는 없습니다.

우선 FS를 제공하는 암호만 사용해야 합니다. 이렇게 하면 개인 키가 나중에 발견되더라도 기록된 과거 세션이 여전히 안전합니다.

GnuPG와 같은 것을 사용하면 FS가 옵션이 아니기 때문에 더 큰 것을 사용하고 싶을 수도 있습니다(4096 사용). 클라이언트와 서버는 연결이 설정될 때 자체 키를 협상하지 않습니다. GnuPG를 사용하는 경우에도 > 2048이 실제로 필요하지 않으며, 그렇게 하면 EC가 더 많은 비용을 지불하지만 아직 클라이언트에서 제대로 지원되지 않고 GnuPG 암호화 메시지가 수십 년 동안 민감할 수 있기 때문에 4096은 최소한 정당화할 수 있는,

FS를 사용하는 경우 HTTPS로 정당화할 수 없습니다. FS를 사용하는 경우 클라이언트와 서버 간에 사용되는 키가 더 강력하도록 가능한 ECDHE 암호를 사용해야 합니다. 서버가 여전히 DHE 키를 지원하는 경우 비트 수에 대해 걱정해야 하는 곳은 DH 그룹이며 대부분의 사람들은 RFC에 게시된 미리 정의된 2048 DH 그룹을 사용합니다. 고유한 2048비트 DHE 그룹을 생성하는 것이 합리적입니다.

서버 개인키는 2048비트로 쉽게 크랙이 되지 않으므로 충분합니다. 3072 또는 4096의 기본값을 제안하는 것은 15파운드 대신 20파운드 문진을 제안하는 것과 같습니다. 예, 20파운드는 더 무겁지만 실질적인 이점은 없으며 2048비트 RSA 키는 더 이상 안전하지 않게 되기 전에 오랫동안 교체될 것입니다.

항상 순방향 비밀성을 사용하고 가능하면 ECDHE 암호를 사용하십시오. 개인 키인 RSA 2048이면 충분하며 더 나은 성능을 원한다면 키에 RSA가 아닌 ECDSA를 사용하십시오.

내가 말하려고 하는 것, 그리고 내가 틀렸다면 정정해 주세요. TLS에 Forward Secrecy를 사용하는 암호가 필요한 경우 서버의 장기 개인 키의 유일한 실제 목적은 ID라는 것입니다.

수행되는 클라이언트와 서버 간의 실제 암호화는 x.509 인증서와 함께 사용된 키와 관련이 없는 클라이언트와 서버 간에 협상된 임시 키를 사용합니다.

2048 미만의 DH 매개변수를 사용하지 말고 가급적 ECDHE를 사용하는 것이 좋습니다. 그런 다음 서버의 개인 키는 서버의 ID를 설정하는 데만 관련이 있으며 2048비트 RSA는 특히 모범 사례를 따라 1년에 한 번 이상 새 키를 생성하는 경우 확실히 충분합니다.

따라서 이 문제는 종결되어야 하며 적절한 암호 제품군 선택에 보안에 중점을 두어야 합니다.

흥미롭긴 하지만 Applebaum과 Snowden이 모두 나에게 RSA 키 크기 4096비트를 사용하도록 권장할 때 음, 음, 잘 모르겠습니다. 그 조언을 따를 수 있을 것 같습니다. 여기서 우리가 숨기고 보호하려는 것이 바로 정체성이 아닙니까?

@jult 특히 GnuPG를 사용하는 경우 4096비트를 사용하세요. 모든 사람이 2.1로 업그레이드할 때까지는 ed25519 OpenPGP 키에 액세스할 수 없습니다. 그리고 그들은 그렇게 강하지 않습니다. (저는 제 ed25519 SSH + GPG 키를 좋아하므로 모든 사람이 RSA에서 벗어나도록 권장하십시오!)

2048비트 RSA 키는 앞으로 몇 년 안에 많은 양의 계산 리소스를 가진 공격자에 의해 깨질 수 있을 것으로 예상됩니다. 768-1024비트는 이미 일상적으로 손상되었습니다.

나는 3072가 합리적인 기본값이라고 생각하지 않습니다. 그것은 일종의 평범하지 않은 것입니다.

2048비트는 2030년 이후에는 권장되지 않습니다. 보장합니다. 일몰은 SHA-1의 경우와 같이 점진적입니다. 정부 표준 문서 등을 많이 읽었습니다.

한동안 사람들은 8192비트 이상의 키를 만드는 연습을 하고 있었습니다. 소스를 두세 줄로 변경하는 것은 재미있는 일이지만 다른 사람들과 얼마나 잘 작동하는지 잘 모르겠습니다.

. @WikiLeaks 는 제출을 위해 비정상적으로 강력한 8192비트 RSA PGP 암호화 키를 게시합니다. https://t.co/xGnu72HTUN pic.twitter.com/8TZyql1NN6

— KM Gallagher(@ageis) 2015년 5월 27일

@ageis 또한 16384에는 상당히 엄격한 제한이 있습니다. 더 커지려면 *훨씬* 더 많은 해킹이 필요합니다. 나는 시도했다.

— isis agora lovecruft (@isislovecruft) 2014년 9월 8일

@jult 저는 Appelbaum과 Snowden에 대해 다루지 않겠습니다. 나도 그들에 대해 느슨하게 알고 있지만 당신이 만들고 있는 권위에 대한 일종의 록스타 어필이라고 생각합니다. 모든 출처를 살펴보십시오. 특히 몇 가지를 추천할 수 있습니다.

• 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/

개인적으로 저는 모두가 더 빠른 kbx 형식으로 GnuPG 2.1로 업데이트되고 새로운 ed25519 키( @dkg 또는 @floodyberry?)를 생성하는 데 더 열중하며 다음 Yubico 시리즈에서 이를 지원하기를 바랍니다. 사실 확인하기 위해 연락할 수 있습니다. YubiKey 4에 대한 몇 가지 베타 테스트를 수행했을 때. 스마트 카드로 가져오기를 어렵게 만들기 때문에 키를 내보내기 위해 보호/암호화하는 방법이 마음에 들지 않습니다.

이 문제를 해결하는 동안 NIST Special Publication 800-57의 훌륭한 차트를 삭제하겠습니다. 그 출처가 더 많습니다. 토요일 밤에 시작하기에 딱이죠?

다시 말하지만, 클라이언트 핸드셰이크 중 크기에 대한 추가 로드는 더 작은 키 크기로 인해 추가 위험을 감수할 가치가 없습니다. 4096비트 RSA를 사용하지 말 것을 권장하는 사람들은 유효한 인수를 제시하지 못합니다. 우리가 키의 적절한 생성에 의존하고 있다는 사실은 말할 것도 없고, 결국 결함이 있는 경우 4096비트 키를 사용하는 것이 훨씬 좋습니다.
이것을 확인하십시오. https://github.com/certbot/certbot/issues/489#issuecomment-114083162
다음과 같은 >=4096비트의 Diffie Helman 키도 생성해야 합니다.
openssl dhparam -dsaparam -out /etc/ssl/dh4096.pem 4096
사이퍼 제품군에서 DH(E)를 활성화했을 때 의미가 있기를 원한다면.

방금 RSA 서명에 대한 합성 벤치마크를 실행했으며 다음을 확인했습니다.

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

첫 번째 숫자는 모듈러스 크기이고 두 번째 숫자는 서명 작업당 필요한 평균 시간(초)입니다.

나는 순방향 비밀성에 대한 @AliceWonderMiscreations 의 의견이 다소 설득력이 있음을 발견했습니다. 오늘날 다양한 암호 그룹과 협상되는 TLS 연결의 비율에 대한 최신 통계를 알고 있는 사람이 있습니까? 현재 PFS가 아닌 암호를 사용하는 사람이 거의 없다면 RSA 키 길이 매개변수는 장기적 보안 결과를 최소화합니다.

FS와 non-FS는 별개의 문제입니다. 예, FS 암호 제품군을 권장해야 하며 클라이언트와 서버 모두 비 FS 암호 제품군을 비활성화할 수 있다고 알고 있는 경우 비활성화해야 합니다. (TLS 1.3에는 FS가 아닌 암호 그룹이 남아 있지 않습니다. 예!) 그렇다고 해서 강력한 암호화 ID 키의 중요성을 무시해야 하거나 서로 경쟁해야 한다는 의미는 아닙니다. 위조된 ID 키를 사용하면 FS 연결에서도 MiTM이 가능하다는 점을 기억하십시오.

RSA 3072는 권장 사항(ENISA 및 NIST와 같은)이 향후 10년 동안 사용할 키에 대한 강력한 보안 마진으로 내려오는 최적의 지점으로 보입니다.

안녕하세요 @dkg 님

FS와 non-FS는 별개의 문제입니다. 예, FS 암호 제품군을 권장해야 하며 클라이언트와 서버 모두 비 FS 암호 제품군을 비활성화할 수 있다고 알고 있는 경우 비활성화해야 합니다. (TLS 1.3에는 FS가 아닌 암호 그룹이 남아 있지 않습니다. 예!) 그렇다고 해서 강력한 암호화 ID 키의 중요성을 무시해야 하거나 서로 경쟁해야 한다는 의미는 아닙니다. 위조된 ID 키를 사용하면 FS 연결에서도 MiTM이 가능하다는 점을 기억하십시오.

기본 경우에는 현재 60일 동안 개별 RSA 주제 키만 사용하고(인증서의 90일 수명 동안 활성 MITM 위험이 지속됨) 다른 것으로 전환합니다. "90일 안에 2048비트 키를 깰 수 있는 공격자가 능동 공격을 할 수 있다"와 "언제든지 2048비트 키를 깰 수 있는 공격자가 예전 세션의 평문을 복구할 수 있다"는 상당한 차이가 있는 것 같다. 에 관여했다". FS 암호 스위트의 경우 전자는 사실이고 후자는 사실이 아닙니다.

키 길이에 대한 권장 사항은 일반적으로 공격자가 키를 사용한 후 일정 시간이 지나면 공격자가 키를 손상시키는 위협 모델을 가정하는 것으로 보입니다. 예를 들어 아래에 언급한 권장 사항은 공격자가 손상되는 데 몇 년 이 걸리는 위협 모델을 기반으로 하는 것으로 보입니다. 개별 키. FS 암호 제품군을 사용하면 해당 위협 모델이 ID 키의 길이를 결정하는 것과 관련이 없어야 합니다. 왜냐하면 주어진 ID 키가 더 이상 사용되지 않기 때문입니다.

RSA 3072는 권장 사항(ENISA 및 NIST와 같은)이 향후 10년 동안 사용할 키에 대한 강력한 보안 마진으로 내려오는 최적의 지점으로 보입니다.

@AliceWonderMiscreations 의 주장에서 내가 감사하는 요점은 우리가 생성하는 2048비트 키가 10년 동안 개별적으로 사용하기 위한 것이 아니라 몇 개월 동안 사용하기 위한 것이라는 것입니다. Diffie-Hellman 협상을 인증하는 데 사용됩니다. 따라서 이러한 권장 사항은 대부분의 경우 다른 보안 컨텍스트를 고려할 수 있습니다. 아마도 우리는 대부분의 위협 모델에서 DH 모듈러스에 대해 더 걱정해야 합니다. 왜냐하면 이것이 장기적인 보안 수준에 직접적인 영향을 미치는 제한 매개변수이기 때문입니다.

FS 암호 제품군의 사용 빈도와 2048 및 3072비트 키가 서버 성능에 미치는 영향에 대한 실용적인 데이터를 얻으려고 합니다.

업데이트로 저는 "약 10%", "10% 미만" 및 "약 1%"의 HTTPS 연결이 현재 비FS 암호 제품군을 사용한다는 몇 가지 다른 출처로부터 대략적인 추정치를 들었습니다. 이것은 브라우저의 관점에서, 서버의 관점에서, 특정 국가에서, 특정 웹사이트에서, 특정 유형의 웹사이트 등에서 등에 따라 달라지기 때문에 정의하기 매우 어려운 대상입니다. 차이는 1%-10% 불일치를 설명하는 것으로 보입니다.

개인적으로 나는 우리가 오래된 개인 키를 디스크에 보관한다는 사실과 관련하여 더 우려하고 있습니다(https://github.com/certbot/certbot/issues/4635에 대해 별도의 문제를 제출했습니다). 나는 공격자가 오래된 트래픽을 읽기 위해 서버를 손상시키는 것이 일반적으로 그렇게 하기 위해 2048비트 RSA를 깨는 공격자보다 훨씬 더 가능성이 높다고 생각하기 때문에 이것이 더 높은 우선순위가 되어야 한다고 생각합니다.

다음을 제안합니다.

• @dkg 가 일반적으로 TLS에서 DH 키 교환의 보안에 대해 많은 작업을 하고 있다는 것을 알고 있습니다. 클라이언트가 각 사이트¹에 연결할 때 발생할 가능성이 있는 DH 교환의 강도를 추정하기 위해 사이트를 스캔하는 데 도움이 되는 도구를 만들거나 찾을 수 있습니까? (당신이 우려하는 일부 영역에서 우리는 클라이언트 측에서 교환이 얼마나 안전한지 실제로 말할 수 없다는 것을 알고 있지만, 나는 단지 DH 교환의 강점을 우리는 그것을 보고 결정할 수 있습니다.) 우리는 또한 이런 종류의 주제에 관심이 있는 많은 학술 연구원을 알고 있습니다...

• 더 이상 사용되지 않는 오래된 개인 키가 웹 서버에 존재하지 않도록 https://github.com/certbot/certbot/issues/4635 를 수정하려고 합니다.

• TLS에서 사용되는 DH의 양을 늘리기 위해 사용자가 웹 브라우저를 업그레이드하도록 권장하는 지속적인 단계에 대해 생각할 수 있습니다.

이를 염두에 두고 기본적으로 생성되는 2048비트 키는 일반적으로 세션 키의 기밀성을 직접 보호하는 데 사용되지 않고 공격이 온라인에서 이루어져야 하는 DH 키 교환을 인증하는 데 사용됩니다. , 인증서의 90일 유효 기간 내에 대화식, 활성 공격. 그렇지 않으면 공격자는 대신 다른 공격 방법을 선택해야 합니다. 키 길이 조언의 출처에서 2048비트 키가 90일 기간 동안 인증에 적합하지 않다고 주장하는 것을 보기는 어렵습니다. 이는 연결의 1%-10%라는 장기적인 기밀성과 더 직접적인 관련이 있지만 아마도 그 비율을 줄이기 위해 더 많은 노력을 기울일 수 있습니다.

¹ 예를 들어 알고리즘 및 공개 매개변수 크기 및 재사용과 관련하여

나는 RSA 키에 대한 관련 제안에 대해 더 많은 연구를 하고 있지만, 가장 최근 답변에서 내 세 가지 제안에 대한 응답이 없는 한 곧 이 문제를 종료할 계획입니다.

#3349가 완료된 후에 이것을 닫는 것은 어떻습니까?

#3349가 완료된 후에 이것을 닫는 것은 어떻습니까?

저는 #6492가 더 관련성이 있으며 #6492가 완료된 후(및 #4635) 이것을 닫아야 한다고 말하고 싶습니다.

여러분, 4096비트 암호화는 공짜가 아닙니다. 저전력 CPU에서는 엄청나게 느립니다. 현대 전화조차도 사용할 때 문제가 있습니다. 해독할 수 없는 암호에서 훨씬 더 해독할 수 없는 암호로 전환하는 것이 모든 사람의 성능과 배터리 수명을 망칠 가치가 있다고 확신하십니까?

4096비트 키 길이는 이 장치의 CPU 전력이 매우 제한적인 경우가 많기 때문에 IoT에서 큰 문제입니다.

이전 임베디드 장치 중 하나에서 2048에서 4096으로 이동하는 개인 RSA 탱크의 속도는 3.6에서 0.6입니다.

앞서 언급했듯이 하드웨어 가속이 없는 IoT 및 기타 장치는 ECDSA(#6492)를 사용할 수 있습니다.

앞서 언급했듯이 하드웨어 가속이 없는 IoT 및 기타 장치는 ECDSA(#6492)를 사용할 수 있습니다.

많은 장치에 RSA의 하드웨어 가속이 있습니까? 아니면 여전히 일반적으로 소프트웨어를 통해 처리됩니까?

하드웨어 가속은 일부 MCU에서 사용할 수 있지만 대부분은 사용할 수 없습니다(더 비쌉니다). 또한 권장 사항이므로 3072로 제한되는 경우가 많습니다(https://www.keylength.com/).
RSA 검증은 매우 빠릅니다. 생성 및 서명만 매우 느립니다.

OPENSSL_TLS_SECURITY_LEVEL=3 에는 최소 3072비트가 필요합니다.

이 문제가 여전히 열려 있는 이유는 무엇입니까? 요청하는 사용자가 특히 2020년에 TLS의 관련성을 오해하고 있는 것 같습니다.

TL;DR

• RSA 인증서 는 신뢰할 수 있는 서버의 ID를 증명하는 데만 중요하며 90일마다 교체됩니다 . 당신을 가장하기 위해 그 시간 내에 2048비트의 키 길이로 인해 손상되지 않습니다.
• 보안을 매우 중요하게 생각하기 때문에 FS(DHE/ECHDE)를 제공하는 암호 제품군만 허용하고 웹 사이트의 경우 최신 웹 브라우저가 더 이상 키 교환 (Safari 및 Chrome은 2016년경에 지원 중단).
• 1024비트 RSA 대 2048비트 RSA는 공격하기가 40억 배 더 어렵습니다 . 768비트 RSA는 2010년에 깨졌습니다(단일 머신의 2000년에 해당하는 병렬 컴퓨팅으로 2년이 걸렸습니다). 2020년에는 829비트에 도달했습니다. 512비트 대 1024비트는 10억 2048비트 대 3072비트는 65,000배만 더 어려운 반면 ...
• 인증서 ID는 유효 기간이 더 길지만 여전히 2048비트 RSA인 CA 인증서 에 대한 신뢰 체인에서 확인 되므로 이를 제어할 수 없습니다 . 공격자는 사용자를 가장하려는 경우 인증서가 다른 용도로 사용되지 않을 때 키 길이를 그 이상으로 늘려도 추가 이점을 제공하지 않는 것을 목표로 합니다.

대부분의 배포에서는 PFS 암호 제품군만 확인해야 합니다. RSA 인증서는 2048비트를 넘어서는 이점이 없습니다. 추가 오버헤드로 인해 서버가 동시에 지원할 수 있는 핸드셰이크의 양을 줄이는 것뿐입니다. 맹목적으로 앵무새처럼 보이는 것이 아니라 조언의 맥락을 고려해야 합니다.

키 교환에만 DHE/ECDHE를 사용하세요. 웹 서버에서는 2015년부터 브라우저에서 DHE에 대한 지원도 점차적으로 제거하고 있다는 사실을 알게 될 것입니다. Safari는 2015년 Logjam에 대한 응답으로 그렇게 했으며 Chrome은 2016년( Chrome 53(2016년 8월) ) 1024비트 DH 그룹과 협상 중인 서버 수 때문에 DHE 지원을 중단했으며 Firefox는 올해 마침내 합류했습니다( Firefox 78( 2020년 6월) ). 따라서 기본적으로 웹의 경우 어떤 이유로 웹 브라우저가 ECC를 오랫동안 지원해 온 것을 실제로 지원할 수 없는 클라이언트를 알고 있지 않는 한 ECDHE만 다루고 있습니다.

지금 걱정할 수 있는 걱정거리가 무엇입니까? 귀하의 인증서는 3개월 이내에 갱신/교체됩니다. RSA 인증서의 유일한 보안 문제는 신원이며, 일부 공격자가 귀하를 가장할 수 있지만 그렇게 하려면 공격자가 해당 <90일 창 내에 성공해야 합니다.

2020년에 지금까지의 기록은 829비트 RSA (768비트가 깨질 수 있다는 사실을 인지한 지 10년)를 경신하는 것입니다. 795비트 RSA의 이전 기록은 더 나은 알고리즘과 하드웨어를 사용하여 약 절반의 결과를 얻을 수 있다고 말합니다. 계산 시간. 900-2000년 계산 연도를 보십시오. 이러한 성과는 병렬 계산 능력(768비트의 경우 2년으로 단축됨)과 동일합니다.

512비트 RSA는 보안에서 대략 50비트의 대칭 키 강도입니다. 1024비트 RSA는 80비트, 2048비트 RSA는 112비트로 알려져 있지만 이 호에서 언급한 3072비트는 128비트입니다. 2010년에 768비트 RSA(대칭 보안의 50-80비트 사이 어딘가에 있음)는 2년과 1톤의 돈에 걸쳐 깨질 수 있습니다. 동등한 비트 더. 이것이 횡설수설하게 들리는 사람의 경우 대칭 키 강도의 각 추가 비트는 모든 가능성을 무차별 대입하려는 경우 계산해야 할 작업의 양을 두 배로 늘립니다(평균적으로 모든 처리의 절반 정도는 성공할 수 있음) .

이제 512비트 RSA를 1024비트와 비교하면 대칭 보안에서 대략 30비트의 차이가 있습니다. 2^30은 약 10억, 즉 50비트(1,125,899,906,842,624개의 잠재적 키)에 10억(1,19062480,0,0,0,2,0,2,0,0,2)을 곱한 것입니다. , 10억 배 더 많은 노력/파괴 시간. RSA 1024비트 대 2048비트의 경우 32비트 차이가 있으며 2^32는 40억이 조금 넘습니다. 그래서 우리는 (4,503,599,627,370,496,000,000,000,000,000,000)을 얻었습니다. 이제 3072비트로 올리는 것은 2^16 == 65,536... 네, 40억 승수만큼의 도약이 아니라 "안전"하게 만들 것입니다. 하지만 이미 2048비트 RSA의 난이도가 상당히 높아졌습니다.

이제 그것을 흡수하고 생각하자. 2010년 768비트 RSA는 단일 시스템에서 2000년에 해당하는 병렬 처리에 2년이 걸렸고 10년 후에는 그 이후의 모든 발전으로 조금 더 나아질 수 있습니다. 많은 돈과 시간을 낭비하는 사람이 RSA 인증서를 깨고 싶어하지 않는 한 1024비트 RSA와는 거리가 멉니다. 공유 DH 그룹과 다릅니다. 터무니없이 가치가 있고 물리적 고문/공갈과 같은 값싼 수단을 통해 얻을 수 없는 일부 데이터.

누군가가 RSA 인증서를 깨는 데 낭비하는 리소스가 있다고 해도 1024비트가 아닙니다. 2048비트의 난이도는 40억 배입니다. 주요 돌파구 없이는 발생하지 않을 것입니다. 키 길이가 다음과 같은 약점이 있을 수 있습니다. 걱정할 필요가 없습니다(이를 해결한 TLS의 다른 모든 취약점을 살펴보세요). 3072비트 RSA를 넘어 128비트 키를 사용한 암호화에 사용된 경우 RSA 인증서는 중요하지 않으며 AES용 128비트 암호화 키가 대신 공격을 받을 수 있습니다.

그 모든 것은 제쳐두고 언급한 바와 같이 PFS 암호 제품군만 사용하는 경우 RSA가 ID와 관련이 있다는 것뿐입니다. 리소스가 무엇이든 간에 2048을 깨는 비용보다 서버 또는 사용자를 손상시키는 더 좋은 방법이 있습니다. -비트 RSA 인증서를 90일 이내에...

OPENSSL_TLS_SECURITY_LEVEL=3 에는 최소 3072비트가 필요합니다.

그리고 이것은 왜 관련이 있습니까? 15360비트의 최소 RSA 키 길이를 요구하는 레벨 5가 있습니다. 왜 그 논리로 3072비트에서 멈추나요?

연결된 문서에서 알 수 있듯이 달리 구성하지 않는 한 기본값은 1 입니다. OpenSSL을 레벨 3으로 컴파일하는 주류 소프트웨어를 알고 있습니까? OpenSSL을 사용할 때 대부분의 경우 시스템 복사본에 연결되어 있습니다. 각 응용 프로그램이 자체 번들 복사본을 업데이트하는 것에 의존하지 않고 보안 업데이트를 받기를 원하기 때문입니다(소프트웨어가 처음부터 정기적으로 유지 관리/업데이트된다고 가정하면, 이 시나리오에서 항상 발생하는 것은 아닙니다).

클라이언트가 각 사이트에 연결할 때 발생할 가능성이 있는 DH 교환의 강도를 추정하기 위해 사이트를 스캔합니다.

@schoen Chrome은 2016년에 DHE 지원을 중단했으며 DHE 연결의 95%가 1024비트 DH 매개변수를 사용하는 것으로 나타났습니다. 최신 브라우저가 더 이상 DHE 암호 제품군을 지원하지 않기 때문에 지금은 그다지 중요하지 않습니다.

메일과 같은 다른 서버의 경우 여전히 유용할 수 있습니다(ECDHE 지원은 한때 꽤 좋았지만 RHEL과 같은 일부 Linux 배포판은 2014년경 6.5까지 지원하지 않음). DHE는 최소 2048비트를 포함하는 RFC 7919의 공식 FFDHE 그룹을 사용해야 합니다. 1024비트 제한이 있는 이전 클라이언트는 중요하지 않습니다. 틈새 상황의 경우 시스템 관리자가 이를 해결하기 위해 유급 위치에 있지만 잠재적인 체인을 포함하여 해당 시점에서 실행할 수 있는 보안 문제의 호스트가 있습니다. 시스템의 만료된 루트 인증서로 인한 신뢰 문제.

TLS에서 사용되는 DH의 양을 늘리기 위해 사용자가 웹 브라우저를 업그레이드하도록 권장하는 지속적인 단계에 대해 생각할 수 있습니다.

이 제안을 했을 때 Safari와 Chrome은 더 이상 DHE afaik을 제공하지 않았습니다. 이것은 사용자가 오래된 소프트웨어를 실행하는 장치에서 브라우저/클라이언트를 업그레이드할 수 있다고 가정할 때 DHE를 줄이는 반대 결과를 가져옵니다. 일부 오래된 OS 또는 소프트웨어는 TLS 버전 지원, 지원되는 암호화 제품군(macOS에는 2015년 후반 릴리스 IIRC까지 AES-GCM이 없음)에 영향을 미치는 이전 TLS 구현(예: macOS/iOS 보안 전송)에 잠겨 있습니다.

OCSP 및 CT 로그와 같은 다른 보호 장치를 무시하고 2048비트 RSA가 90일 동안의 ID 보호에 충분하지 않다고 생각하는 사람에 대해 신뢰 체인을 알고 있습니까? 인증서는 LetsEncrypt 루트 및 중간 인증서에 대해 확인됩니다. 누군가 인증서를 공격하려는 경우 특정 사이트에 발급된 인증서보다 손상시키는 것이 더 중요합니다.

인증서가 진정성을 위해서만 사용되고 기록된 트래픽을 해독하기 위해 손상되지 않은 경우 웹사이트 키 길이를 원하는 만큼 늘릴 수 있지만 이전보다 더 안전한 이 이론적인 공격으로부터 보호하여 무엇을 얻을 수 있습니까? 신뢰 체인의 인증서가 손상되고 있습니까? (2048비트 RSA 사용, ~LE 루트 포함~ ( 편집: 내 잘못, LE RSA 루트는 4096비트 임), 유효 기간이 훨씬 더 길고 중급의 경우 5년, LE 루트의 경우 2035년까지)

이 문제가 여전히 열려 있는 이유는 무엇입니까? 요청하는 사용자가 특히 2020년에 TLS의 관련성을 오해하고 있는 것 같습니다.

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.

X.509(TLS :rofl: 아님)를 더 잘 이해하지 못하는 것 같습니다... :rofl:
Cert가 문제가 아니라 핵심입니다. 그리고 X.509 세계에서는 키를 취소할 수 없습니다... 그래서 90일 롤오버가 항상 관련이 있는 것은 아니며 ECDHE/DHE를 사용하지 않고 일반 이전 RSA 인증을 사용하지 않는 서버의 문제입니다. 그리고 이것은 2020년에도 꽤 많이 발생합니다...

당신은 또한 RSA-2048의 힘에 대해 잘못 계산합니다. 주어진 키를 깨는 가장 좋은 현재 방법 시간뿐만 아니라 키가 더 이상 의미가 없는 미래 시점의 미래 방법도 계산해야 합니다. ECDHE/DHE가 아닌 경우(반복하지만 그렇게 드물지는 않음) 90d가 아니라 10-30y입니다. 그리고 고려해야 할 시간일 뿐만 아니라 비용, 기술 발전 및 암호 약점/트릭 발견도 고려해야 합니다. 그리고 그것은 귀하의 설명 사례에서 특별히 볼 수 있습니다.
RSA-256은 2019년 9월에 1000달러의 표준 노트북에서 60년대에 크랙이 발생했습니다. 그러나 RSA-512는 2015년에 ~4시간 만에 ~$75에 크랙되었습니다.
https://www.doyler.net/security-not-included/cracking-256-bit-rsa-keys
https://eprint.iacr.org/2015/1000.pdf
확실히 둘 사이에는 [여기에 큰 숫자 삽입] 배 차이가 없지만 일정한 비용으로 1.8배 정도 차이가 납니다.
RSA 키를 인수분해하기 위한 cado-nfs 벤치마크에서도 꽤 볼 수 있습니다. RSA-120은 1.9h, RSA-130은 7.5h(예상대로 81d가 아님), RSA-140은 23h(227y가 아님), RSA-155는 5.3d(7452 millenium 아님)입니다.

이것이 ANSSI 또는 NIST와 같은 엔티티가 최신 컴퓨터 능력 또는 암호화 지식뿐만 아니라 키 사용/의미의 기간 내에 발생할 것으로 예상되는 향후 개선 사항을 기반으로 권장하는 이유입니다.

ECDHE/DHE를 사용하지 않고 일반 이전 RSA 인증을 사용하지 않는 서버의 문제입니다. 그리고 이것은 2020년에도 꽤 많이 발생합니다.

따라서 여기서 보안을 개선하기 위한 조언은 PFS 전용 암호 제품군을 권장하는 대신 더 큰 키 크기를 사용하도록 권장하는 것입니다. 왜요?

RSA-2048 강도에 대해서도 잘못 계산했습니다.
주어진 키를 깨는 가장 좋은 현재 방법 시간뿐만 아니라 키가 더 이상 의미가 없는 미래 시점의 미래 방법도 계산해야 합니다.

더 자세히 설명해주세요. 어떤 경우에 지난 10년 동안 이것이 잘못되었다는 것을 알고 있습니까? 대칭 키 강도를 볼 때 엔트로피가 2^32비트 더 많은 2048비트는 고사하고 1024비트 RSA가 인수분해/파손되는 알려진 사례가 없습니다.

1. 2048비트 RSA는 1024비트 RSA보다 40억 배 더 강력합니다.
2. 3072비트는 ~65,000배만 더 강력합니다(NIST에서 공식적으로 정의한 대칭 보안의 112비트와 128비트를 비교할 때).
3. 1024비트(80비트 대칭 키 강도)가 1년 컴퓨팅 성능 범위 내에서 손상될 수 있다고 가정하면. 2048비트의 경우 40억 년입니다.
4. 알려지지 않은 기술 발전이 계산 시간을 크게 줄일 수 있지만 3072비트 RSA를 위협하지는 않는다고 주장하고 있습니까?

1024비트를 1초 이내에 깨질 수 있는 것으로 비교할 수 있으며 2048비트는 여전히 136년과 같습니다( (1/31536000) * 2^32 ). 그런 성취가 일어나기까지는 먼 이야기입니다. 어떻게든 타당한 문제라고 주장하고 싶다면 512비트라도 1초에 인수분해된다는 사실을 알고 계십니까? 512비트 RSA는 1999년에 처음으로 6개월에 걸쳐 인수분해되었으며 , 2015년부터 $100 미만으로 AWS를 쉽게 활용할 수 있는 Github 프로젝트(FaaS) 가 있어 512비트 RSA를 인수분해하는 데 몇 시간이 소요됩니다.

이를 염두에 두고 1024비트 RSA는 약 2^28(~250k) ~ 2^30(10억) 배 더 어렵습니다(정확한 수치는 없지만 그 정도인 것 같습니다). 현재 학계에서는 아직 멀었지만 1024비트 RSA가 그렇게 빨리 계산될 수 있다고 생각하는지 잘 모르겠습니다. .

여기서 일반적인 접근 방식은 GNFS(General Number Field Sieve)로, 키 크기가 클수록 필요한 리소스가 많아지면 실행 불가능해집니다 . RSA 인수분해 히스토리에 대한 이 멋진 차트 도 있으며, 이를 기반으로 2048비트 RSA를 2048로, 1024비트를 2015-2020년까지 인수분해로 고정한 관련 답변 은 아직 학문적으로 달성되지 않았습니다.

위의 내용을 고려하여 3072비트 RSA가 추가 보안 이점을 훨씬 더 많이 제공하는 방법을 백업해 주셨으면 합니다. 2048비트 RSA가 다른 방식으로 공격을 받거나 기술적으로 이러한 속도로 발전한다면 3072비트 RSA가 얼마나 많은 추가 보호 기능을 제공할지 알 수 없습니다.

ECDHE/DHE가 아닌 경우(즉, 반복하지만 그렇게 드물지는 않음)

나는 그것이 "아주 드물지 않다"고 주장하는 방식을 좋아합니다. 요즘 DHE 또는 ECDHE 대신 RSA 키 교환을 사용하는 핸드셰이크를 만나는 것이 얼마나 일반적입니까? 한 가지 예라도 있습니까?

90d가 아니라 10-30y입니다.

인증서의 목적이 키 교환이 아닌 인증만 제공할 때 인증서에 대한 90일 갱신 기간을 명시한 것이 꽤 명확했다고 생각합니다.

그리고 고려해야 할 시간일 뿐만 아니라 비용, 기술 발전 및 암호 약점/트릭 발견도 고려해야 합니다. 그리고 그것은 귀하의 설명 사례에서 특별히 볼 수 있습니다.

예, 비용. 리소스 GNFS를 수행하는 데 테라바이트의 RAM이 필요한 1024비트 RSA를 인용하도록 링크했으며 선형 감소 단계는 처리하기에 가장 비용이 많이 들고 어려운 부분입니다. 그것은 기하급수적인 어려움이 있는 것입니다. 저렴하고 쉬운 것이 매우 빠르게 어려움을 겪을 수 있습니다.

RSA-256은 2019년 9월에 1000달러의 표준 노트북에서 60년대에 크랙이 발생했습니다. 그러나 RSA-512는 2015년에 ~4시간 만에 ~$75에 크랙되었습니다.

AWS에서 512비트 팩토링을 수행할 수 있는 Github 프로젝트에 이미 연결했습니다. 256비트 RSA, 아마도 30비트 정도의 대칭 엔트로피 비트의 정확한 양을 모릅니다. (따라서 512비트 RSA 사이에 대략 1,048,576배 차이가 납니다). 링크한 512비트 문서에는 432개의 CPU(각각 36개의 vCPU + 60GiB RAM이 있는 12개의 인스턴스) 및 1.5-2GB의 메모리 또는 매트릭스용 스토리지가 포함된 총 2770 CPU 시간이 언급되어 있습니다. 당신이 차임을 자유롭게 느끼면).

내 수학은 아마도 여기에서 좋지 않을 수 있지만 해당 정보를 기반으로 두 시스템의 컴퓨팅 성능을 비교해 보겠습니다. 2770시간에서 분은 2770 * 60 = 166200 이며 256비트 RSA의 1분을 log2(166200) = 17.34 로 비교할 수 있습니다.

1991년에 330비트 RSA는 며칠 만에 인수 되었지만 이후의 단일 Intel Core2Duo CPU는 1시간이 조금 넘는 시간에 이를 처리할 수 있습니다. 256비트 RSA는 그보다 적었을 것입니다. 낙관적인 60분을 주고 ~30년 이내에 ~1분으로 진행하여 60배의 대폭 감소라고 가정해 보겠습니다. 이는 2^6(64)... 6비트와 같습니다. 앞서 지적했듯이, RAM 요구 사항 증가와 같은 리소스가 아닌 시간을 고려하면 유효한 위협이 되기에는 아직 멀었습니다. 향후 30년 동안 6비트를 추가로 제거하면 256비트 RSA의 1초 인수분해를 관리했습니다. 축하합니다. 합리적인 시간 프레임에 2048비트 RSA에 도달하려면 먼 길을 가야 합니다.

6개월에서 4시간으로 개선되는 512비트 RSA의 경우 15년이라도 24hr * (6month * 30day) = 4320hr / 4hr = log2(1080hr) = 10 ~2^10입니다. 그것은 감소보다 확실히 더 낫습니다. ~1,000배 더 낫지만 여전히 비교할 만한 놀라운 비율은 아닙니다. 학자들이 더 큰 RSA 키 크기를 인수분해할 수 있게 되면서 진행 속도가 얼마나 느려졌는가가 이를 뒷받침한다고 생각합니다.

RSA 키를 인수분해하기 위한 cado-nfs 벤치마크에서도 꽤 볼 수 있습니다. RSA-120은 1.9h, RSA-130은 7.5h(예상대로 81d가 아님), RSA-140은 23h(227y가 아님), RSA-155는 5.3d(7452 millenium 아님)입니다.

이러한 계산 예상 시간의 출처는 어디입니까? RSA-155(일명 512비트 RSA)는 6개월 전인 1999년에 인수되었으며 , RSA-120(397비트 RSA) 및 RSA-130(430비트 RSA)도 마찬가지로 약 1-2개의 대칭 비트만 다를 수 있습니다. ? 그럼 약 4배의 증가가 예상되는군요...?

이것이 ANSSI 또는 NIST와 같은 엔티티가 최신 컴퓨터 능력 또는 암호화 지식뿐만 아니라 키 사용/의미의 기간 내에 발생할 것으로 예상되는 향후 개선 사항을 기반으로 권장하는 이유입니다.

2048비트 RSA가 거의 약하다는 것을 나타내는 실질적인 내용을 제공하지 않았습니다. 역사적 맥락에서 눈에 띄게 개선된 경우에도 기하급수적으로 증가하는 것과 관련이 없는 것처럼 보입니다. 다소 선형적인 관점을 취하는 것 같습니까? 128비트 AES가 안전한 것으로 간주되는 이유(어느날 그로버의 알고리즘을 사용하는 양자 컴퓨터에 약할 수 있음)와 256비트 AES를 사용하려면 태양계의 전체 에너지가 다음과 같아야 합니다. 무차별 대입에 지쳤습니다.

또한 PFS 가능 암호 제품군만 사용하는 것과 같은 모범 사례를 고려하지 않고 보호하려는 민감한 데이터를 고려하십시오. 민감한 데이터는 현재처럼 수십 년 후에도 중요하지 않습니다.

TL;DR

이 정도까지 나옵니다. 2048비트를 깨는 것은 지금부터 수십 년 후에도 여전히 터무니없이 비싸지만 낙관적으로 100만 달러와 10년(또는 원하는 경우 1년)이라고 말합시다.

• 이 공격자는 N명의 사용자에 대한 서버 트래픽을 기록할 수 있는 장비를 갖추게 될 지금 당신에게 특히 관심이 있습니까? .
• 이 트래픽은 X년 동안 기록될 예정입니다. 여기서 90일마다 인증서가 변경되어 각각에 대해 별도의 공격이 필요합니다(시간 및 $$$$)? 아니면 공격자가 암호화를 깨뜨릴 수 있다고 믿기까지는 수십 년이 걸리더라도 관심 있는 특정 데이터를 언제 기록해야 하는지 미리 알고 있습니까?
• 이것은 어떻게 든 서버 또는 사용자 클라이언트를 직접 해킹하고 해당 시스템을 손상시키는 것보다 저렴하고 더 나은 전략입니다. ), 더 실용적인 공격을 선택할 수 있는 리소스가 없습니까?
• RSA 개인 키에 액세스하기 위해 누군가를 직접 위협하거나 협박하는 것이 더 저렴하고 쉽지 않을까요? 그런 다음 키 길이는 중요하지 않습니다. 똑똑하고 PFS 전용 암호 제품군을 사용한 경우 이 전략은 관련이 없습니다.

쏘우 기본적으로...

반창고의 잘못된 보안 관행에 대한 사소한 개선이 아닌 PFS 암호 제품군(DHE/ECDHE)을 권장합니다.

따라서 여기서 보안을 개선하기 위한 조언은 PFS 전용 암호 제품군을 권장하는 대신 더 큰 키 크기를 사용하도록 권장하는 것입니다. 왜요?

LE는 httpd 구성이 아니라 기본 키 크기에 손을 대고 있기 때문입니다. 그리고 LE는 httpd 구성을 시행하는 대신 이미 과거에 조치를 취했습니다(HTTP-01에서 https 비활성화, TLS-SNI-01 제거…).

더 자세히 설명해주세요.

확신하는. 그리고 간단하게 cado-nfs의 벤치마크를 참조하십시오. 크래킹 시간은 이론상 예상되는 시간이 아닙니다.
이론상의 난이도 차이는 두 가지 편향으로 인해 실제로 관찰되지 않습니다. 주어진 최신 기술 과 현재 시간 에 대한 균열 시간만 비교할 수 있으며 이론적인 격차를 예상할 수 있습니다(실제로는 그렇지 않습니다. cado-nfs 참조). 그러나 X+1 비트가 2임을 보장하는 것은 없습니다. 현재의 지식과 계산력을 1개월 후의 것과 비교한다면 X보다 몇 배는 어렵다.
그리고 내가 제공하는 2개의 예도 참조하십시오. 동일한 전력 및 비용을 감안할 때 2015년과 2019년 사이에 256비트와 512비트 크랙 사이에는 2배의 갭이 있으며, 이론적으로 1077번의 갭이 있습니다.
그리고 우리는 4096비트가 더 안전하게 유지되는 3072 RSA 브레이크 트릭이 내일 없을 것이라고 보장할 수 없습니다.

AWS에서 512비트 팩토링을 수행할 수 있는 Github 프로젝트에 이미 연결했습니다. 256비트 RSA, 아마도 30비트 정도의 대칭 엔트로피 비트의 정확한 양을 모릅니다. (따라서 512비트 RSA 사이에 대략 1,048,576배 차이가 납니다). 링크한 512비트 문서에는 432개의 CPU(각각 36개의 vCPU + 60GiB RAM이 있는 12개의 인스턴스) 및 1.5-2GB의 메모리 또는 매트릭스용 스토리지가 포함된 총 2770 CPU 시간이 언급되어 있습니다. 당신이 차임을 자유롭게 느끼면).

예, 그것은 엄청난 숫자이고 비실용적인 것 같습니다... 최초의 512비트 브레이크(1999) 당시에는 아무도 가지고 있지 않은 슈퍼 컴퓨터가 필요했기 때문에 비실용적인 것으로 간주되었습니다. 그러나 실제로 2015년 해당 인프라에 대한 AWS 청구서는 4시간 동안 100달러이고 몇 년 후 IS 가 실용적으로 사용되며, 이는 1999년에 예상된 수십억억의 격차보다 훨씬 더 빠릅니다.
https://arstechnica.com/information-technology/2015/10/breaking-512-bit-rsa-with-amazon-ec2-is-a-cinch-so-why-all-the-weak-keys/

동일한 전력 및 비용을 감안할 때 2015년과 2019년 사이에 256비트와 512비트 크랙 사이에는 2배의 갭이 있으며, 이론적으로 1077번의 갭이 있습니다.

뭐... 아니. 나는 256비트와 512비트의 차이가 2^256(기본 10, 10^77)이 아니라 2^20 이하( 내가 인용한 두 가지 인수분해 예를 비교했을 때 약 2^17이었습니다).

나는 당신이 "2 배의 격차"를 주장하는 방법을 잘 모르겠습니다. 동일한 전력과 비용? 256비트 RSA는 약 1분에 인수분해되었으며 512비트 RSA는 166,200분에 해당합니다(수학은 제 이전 게시물에서 인용되었습니다. 제가 실수를 한 경우 언제든지 수정해 주세요).

그리고 우리는 4096비트가 더 안전하게 유지되는 3072 RSA 브레이크 트릭이 내일 없을 것이라고 보장할 수 없습니다.

2048비트 RSA는 말 그대로 괜찮을 것이고, 3072비트 RSA는 보안이 "미미한" 개선이 됩니다. 이미 설명했지만 건너뛰거나 잘못 이해한 것 같습니까? 2048비트 RSA가 훨씬 더 짧은 시간에 안전하지 않게 되는 유일한 방법은 3072비트 RSA가 발전 속도에서 위협을 받을 때입니다.

더 안전하게 하려면 키 교환에 RSA를 사용하지 마십시오. RSA 키 교환이 필요한 웹사이트((EC)DHE는 어떤 이유로든 지원/협상되지 않음)를 인용 하도록 요청했습니다. 왜 이에 대해 답변할 수 없었습니까? 기본 RSA 키 길이? 그 진술을 뒷받침하십시오. RSA를 키 교환으로 제공하는 서버를 찾을 수 있지만 서버 암호 제품군 선택이 활성화되어 있을 가능성이 높지만 PFS 암호 제품군을 지원할 수 있는 클라이언트는 이를 협상하지 않습니다.

그러나 실제로 2015년 해당 인프라에 대한 AWS 청구서는 4시간 동안 100달러이고 몇 년 후 IS가 실용적으로 사용되며, 이는 1999년에 예상된 수십억억의 격차보다 훨씬 더 빠릅니다.

하드웨어 비용은 100달러보다 상당히 높으며 터무니없는 금액은 아니지만 그렇습니다. 그런 컴퓨팅 리소스를 쉽게 임대/액세스할 수 있는 가용성으로 인해 더 쉽게 액세스할 수 있습니다. 사용된 하드웨어는 저렴하거나 작은 EC2 인스턴스가 아니었고 컴퓨팅 리소스를 임대할 때 상당히 큰 시스템이었습니다. 우리는 10년 넘게 768비트 RSA를 고려했지만 FaaS가 싸게 처리할 수 있습니까? 2048비트 RSA는 갈 길이 멉니다.

512비트를 계산하는 데 10억 개 이상이 필요하다고 주장하는 사람이 있습니까? 1999년의 하드웨어 자원을 단 6개월로 계산하면 수십억 달러에 달하는 비용과는 거리가 멉니다. 이 가격은 어디에서 오는가? 더 높은 수준의 보안에 대한 보다 최근의 진술에서? 이는 더 많은 계산 시간이 필요할 뿐만 아니라 RAM과 같은 다른 리소스가 필요한 기하급수적인 난이도 증가 때문입니다. 해당 512비트 RSA 팩터링 AWS 인스턴스에는 각각 60GB의 RAM이 있었습니다(총 720GB)...

몇 가지 처리 인사이트를 간단히 살펴보세요.

2020년에 인수된 RSA-250(829비트 RSA)은 수만 대의 컴퓨터로 3개월 만에 달성한 것으로, 여러분이 좋아하는 CADO-NFS를 이용해 인수분해를 ~대략 달성한 것 같다. 2015년에 달성한 512비트 RSA의 AWS 인수분해(약 2700 CPU 시간, 참조된 Intel Xeon Gold 6130 2.1GHz로 AFAIK 정규화)와 동일한 양의 컴퓨팅 시간~( 편집: 시간이 아니라 몇 년이 아닌 내 실수). 2019년 12월에 인수된 RSA-240(795비트 RSA)은 2010/2016년(CADO-NFS도 사용)에 768비트 RSA를 인수한 동일한 팀과 동일한 하드웨어에 있다는 점 에서 흥미롭습니다. 그들은 CADO-NFS 소프트웨어의 알고리즘 개선이 ~3배의 성능 향상을 허용했기 때문에 언급했습니다.

다음은 2010년 768비트 RSA 인수분해에 대한 문서입니다 . RAM 요구 사항을 살펴보세요.

첫 번째 단계는 해당 클러스터에서 병렬로 실행되는 8개의 독립적인 작업으로 분할되었으며, 8개의 시퀀스 각각은 214단계마다 한 번씩 검사합니다. 첫 번째(또는 세 번째) 단계 시퀀스를 실행 하려면 180GB RAM이 필요 하고 단일 64비트 너비 ¯b에는 1.5GB가 필요하며 단일 mi 매트릭스는 8KB가 필요하며 이 중 평균적으로 첫 번째 단계 시퀀스당 565,000개가 유지되었습니다. 3단계 평가 중 각 부분 합계에는 12GB가 필요합니다 .

대부분의 경우 사용 가능한 896GB RAM이면 충분하지만 계산의 핵심 부분에서 더 많은 메모리가 필요했습니다(최대 약 1TB).

512비트 RSA 인수분해(2015년 AWS가 아닌 2009년) 와 대조해 보겠습니다.

2009년까지 Benjamin Moody는 공개 소프트웨어(GGNFS)와 그의 데스크톱 컴퓨터(1,900MHz CPU의 듀얼 코어 Athlon64)만을 사용하여 RSA-512 비트 키를 73일 만에 인수분해할 수 있었습니다. 5GB 미만의 디스크 스토리지가 필요했고 체질 프로세스에는 약 2.5GB의 RAM이 필요했습니다.

이는 키 길이가 증가함에 따라 확장되는 RAM 요구 사항의 대략적인 규모를 제공해야 합니다. 특히 분산 방식으로 수행할 때 처리에 대해 알아야 할 다른 병목 현상이 있을 것이라고 확신합니다. 더 자세히 살펴보고 2048비트 RSA를 공격하는 데 필요한 RAM의 양을 확인하십시오.

귀하 또는 귀하의 사용자 트래픽을 특별히 기록하고 지금부터 수십 년 후에 공격을 수행하기 위해 장비를 갖춘 그로부터 실제로 자신을 보호하려고 하는 사람은 누구입니까?

100달러 AWS 솔루션을 기다리는 스크립트 꼬마가 아니라, 그들은 그때쯤 더 나은 것으로 옮겨갔을 것이고 트래픽을 기록하기 위해 네트워크를 손상시키면 훨씬 더 많은 비용이 들 것입니다. 그렇지 않으면 특정 대상이 아닌 일부 맬웨어입니다. 기록된 데이터가 분할된 것을 축하합니다. RSA 키당 트래픽의 90일 기간은 이제 수천, 수백만, 아마도 100달러 AWS의 바다에 있습니다. 돈을 버리는 쓰레기가 많습니다.

아니요, 누군가가 당신의 비밀을 원한다면 더 저렴한 방법이 있습니다.

어떤 이유로 1024-bit에서 2048-bit RSA로의 40억 배 더 강력한 보안은 부적절하지만 2048-bit에서 3072-bit RSA로의 65,000배 더 강력한 보안은 충분하다고 생각합니다. 귀하의 주장은 2048비트가 계산상 안전하다는 보안 이론은 유효하지 않지만 3072비트 RSA에 대한 동일한 논리가 적용되지 않고 훨씬 더 안전하다는 점입니다. 더 크고 더 안전한 자물쇠를 추가하기 때문에 유리문이 더 안전합니까?

TL;DR

이전 TL;DR을 살펴보십시오. 그러나 다시 반복하겠습니다.

• 누군가 약한 2048비트 RSA 키를 사용하여 암호화된 트래픽을 기록하려고 합니다.
• 그들은 이 MitM 공격을 수행할 수 있으므로 기술이나 돈이 있고 아마도 표적 공격일 것입니다.
• 귀하의 데이터는 귀하의 추정치에 따라 20년 이상 후에 해독될 수 있지만 지금 획득하는 것이 바람직한 미래의 가치를 유지해야 합니다.
• 공격은 비밀의 가치를 얻기 위해 수행하는 비용에 대해 정당화될 필요가 있고, 캡처할 90일 기간을 알아야 합니다. 그렇지 않으면 해당 비밀을 얻기 위해 공격을 여러 번 계산해야 합니다.
• 이 공격은 더 빠르고/저렴한 수단으로 해당 데이터를 획득하는 다른 어떤 방법보다 더 효과적입니까?

누가 제정신으로 그런 짓을 할 것인가? 이는 해당 정보를 얻을 수 있는 다른 수단이 없는 고가치 목표에서만 실용적입니다. 이 목표는 어떻게든 그러한 귀중한 비밀을 소유하고 있지만 전문가에게 비용을 지불하거나 보안을 위한 모범 사례를 고려하지 않습니다(그들은 분명히 Mozilla의 암호 제품군 조언의 복사/붙여넣기를 사용하여 서버를 설정할 수 없습니다).

이것은 그다지 설득력이 없습니다. 이것은 LetsEncrypt가 아닙니다. 귀중한 비밀을 가진 사용자가 서버에서 지원하는 RSA 전용 키 교환 암호 제품군과 함께 Certbot을 사용하고(기본 구성에서는 이 작업을 수행하지 않음) 2048비트 RSA가 이보다 훨씬 약하다고 가정하고 있습니까? 이 사용자가 누구이든, 다른 곳의 보안 방식은 사용자를 직접적으로 손상시킬 만큼 충분히 취약할 수 있습니다. 능동적인 공격을 수행하고 현재의 모든 유용한 데이터를 얻을 수 있는데 데이터를 해독하는 데 20-30년을 기다려야 합니까?

올바른 솔루션은 암호 제품군을 적절하게 설정하는 것이며, 이 프로젝트 Certbot 은 해당 분야에 대한 경험이 없고 알아서 처리해 주기를 원하는 경우 정확히 그 작업을 수행합니다. 그러나 어떤 이유에서인지 그것은 이 토론에 적용되지 않습니까?

RSA 키 교환이 필요한 한 웹사이트를 인용 하도록 요청했습니다((EC)DHE는 어떤 이유로든 지원/협상되지 않음)

https://cryptcheck.fr/https/bankofamerica.com (예, 올바르게 읽었습니다)
https://cryptcheck.fr/https/caf.fr (프랑스의 주 정부, 미국의 추가 보장 소득에 해당)
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

내 CryptCheck v2에서는 7221개의 핸드셰이크 분석(~0.9%)을 통해 68개의 비 PFS 도메인을 계산하고 내 v1에서는 349,961개 이상의 핸드셰이크 분석(~0.6%)을 통해 2091개를 계산합니다.

https://www.bankofamerica.com/

프로토콜: TLS 1.2
키 교환: ECDHE_RSA
키 교환 그룹: P-256
암호: AES_128_GCM
CA: 위탁

https://cryptcheck.fr/https/bankofamerica.com 은 ECDHE 키 교환을 제공하지 않는 동일한 도메인에 대한 추가 서버 IP를 식별하고 있다고 가정합니까?

https://www.caf.fr/

프로토콜: TLS 1.2
키 교환: RSA
암호: HMAC-SHA1이 있는 AES_128_CBC
CA: 서팅가

이 웹사이트가 무엇에 관한 것인지 또는 이 웹사이트가 악용해야 하는 민감한 비밀이 무엇인지 전혀 모릅니다.

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

프로토콜: TLS 1.2
키 교환: RSA
암호: HMAC-SHA1이 있는 AES_128_CBC
CA: 글로벌사인

나는 누군가가 직접 방문하여 이름의 합법/신뢰할 수 있는 것으로 간주할 것이라고 상상할 수 없는 이상하게 보이는 도메인 이름에서 이 주소로 리디렉션되었습니다.

이것은 다른 많은 사람들과 마찬가지로 분명히 정부 웹 사이트입니다. 그들은 종종 뒤쳐지고 광범위한 청중이 액세스할 수 있어야 합니다. 하지만 RSA가 기본 키 교환이 되어서는 안 됩니다. 하지만 여기서도 자신을 보호하기 위해 어떤 통신이 일어나고 있습니까? 정부 스스로도 크게 걱정하지 않는 것 같습니다.

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

프로토콜: TLS 1.2
키 교환: RSA
암호: AES_128_GCM
CA: 서팅가

다시 말하지만, 이것이 로그인이 있는 정부 서비스 외에는 어떤 단서가 없습니다. 로그인 정보 외에 민감한 정보가 있습니까? 지금부터 20~30년 후 민감한 정보에 대한 액세스와 관련하여 우려되는 사항은 무엇입니까? 다른 곳에서 동일한 사용자 이름과 비밀번호를 사용하고 있으며 20-30년 후에도 계속 사용하고 있습니까?

로그인 세부 정보(및 계정 데이터의 가치)가 필요한 경우 피싱 사기만큼 효과적이지 않을까요? RSA 인증서를 공격하는 것보다 더 짧은 시간이나 더 적은 예산으로 달성할 수 있습니까?

https://reader.xsnews.nl/

URL을 로드/확인하는 데 1분이 넘게 소요되어 이 웹사이트에 액세스할 수 없습니다.

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

프로토콜: TLS 1.2
키 교환: RSA
암호: AES_128_GCM
CA: 겐트

이것은 구매 결정을 내리는 데 사용할 수 있는 일부 소프트웨어에 대한 웹사이트인 것 같습니다. 여기에 어떤 민감한 정보가 위험에 처해 있습니까?

https://www.tiscali.it/

프로토콜: TLS 1.2
키 교환: RSA
암호: HMAC-SHA1이 있는 AES_256_CBC
CA: 해빙

뉴스 사이트? 이 웹사이트와 상호 작용할 때 어떤 민감한 정보가 우려됩니까?

요약

이러한 결과에서 2048비트 RSA가 손상되는 것으로 추정되는 20-30년이 지난 후에도 민감한 통신을 보호해야 할 필요성을 나타내는 것은 없습니다. 이러한 웹사이트는 클라이언트와 서버 사이에 유효한 문제가 아닌 트래픽을 캡처하기 위해 여전히 효과적인 MitM 공격이 필요합니까?

이들 중 어느 것도 LetsEncrypt 발급 인증서를 사용하지 않습니다. Certbot을 변경하는 것은 해당 웹 사이트에서 Certbot을 해당 CA에 대한 ACME 클라이언트로 사용하고 있다는 것을 확실히 알고 있는 경우에만 유용합니다(제3자 ACME 지원이 있다고 가정).

RSA가 협상된 키 교환인 일부 웹사이트를 실제로 지적해 주셔서 감사합니다(실제 민감한 교환이 아닌 공개 웹사이트에 대한 암호 제품군으로만 검증된 잘못된 것으로 보이는 Bank of America 제외).

내 CryptCheck v2에서는 7221개의 핸드셰이크 분석(~0.9%)을 통해 68개의 비 PFS 도메인을 계산하고 내 v1에서는 349,961개 이상의 핸드셰이크 분석(~0.6%)을 통해 2091개를 계산합니다.

자, 그럼 귀하의 "희귀하지 않음"은 CryptCheck로 스캔한 7,221개 및 349,961개 웹사이트 중 1% 미만입니까? 이제 이러한 통신을 보호하기 위해 대신 3072비트 RSA를 사용하여 제공하는 청중과 실제 측정 가능한 가치를 고려하십시오. 실제로 가치 있는 것을 보호하고 있으며 보안을 손상시키는 더 저렴한 대안에 대해 더 이상 안전할까요? (3072비트가 공격의 하한을 높이는 다른 대체 표적 공격보다 2048비트가 더 약하고 저렴했습니다)

Alexa 상위 100만 사이트 중 RSA 키 교환을 협상 중인 사이트는 몇 개입니까? 발견된 것 중 몇 개나 LetsEncrypt를 CA로 사용합니까?

512비트 및 256비트 RSA(NIST 방정식 기반)에 대한 대칭 비트를 계산했으며 40비트(256비트 RSA) 및 57비트(512비트 RSA)를 얻습니다.

흥미롭게도 이는 두 가지 컴퓨팅 측면을 최근 발전과 비교할 때 앞서 언급한 17비트 차이와 일치합니다(내가 참조한 NIST 문서가 2020년에 마지막으로 업데이트된 것으로 나타남).

또한 1024비트 RSA까지의 거리는 동등한 대칭 키 강도(8,388,608)의 23비트에 불과하다는 것을 보여줍니다. 그리고 768비트 및 795비트 RSA 또는 829비트 RSA의 현재 레코드에 대한 현재 진행 상황을 볼 수 있습니다.

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

• 2010년 이후 768비트 RSA 기록, 2020년 기록으로 829비트 RSA, 10년 동안 3비트 미만 개선. 2000 대 2700 CPU 연도(단일 코어). 795비트 RSA는 2019년 11월에 900 CPU 연도로 떨어졌습니다.
• 57비트(512비트 RSA)에서 72비트(829비트 RSA)로 ~2700컴퓨팅 시간~( 편집: 시간 대 년, 맙소사) 2015년과 2020년 사이. ~15비트(32,768) 개선~? (829비트 RSA는 3개월이 걸렸고 그에 비해 수만 대의 시스템이 필요했습니다). 768비트(2009년 12월) 및 795비트(2019년 11월) RSA 인수분해는 소프트웨어/알고리즘 개선만으로도 약 3배 더 빠릅니다.
• 1991년 이후 256비트 RSA 개선에 대한 2^6(64) 추정치입니다.
• ~2^10 (1024) 16년(1999 - 2015)에 걸쳐 512비트와의 1080 x 차이, 6개월 대 4시간, 비교가 얼마나 정확한지는 불분명, 일반적으로 Intel CPU의 8,000 MIPS 년 대 2770년 참조. 여기서 주요 차이점은 아마도 시간을 줄이기 위해 클라우드 컴퓨팅을 사용하여 저렴하게 하드웨어를 임대하는 것과 그 이후로 15년 동안 소프트웨어에 대한 HW 개선 및 알고리즘 개선을 활용했기 때문일 것입니다.

방금 전에 829비트 RSA 인수분해를 인용하고 AWS 512비트 RSA 인수분해 시간과 비교할 때 실수를 저질렀다는 것을 깨달았습니다. 둘 다 ~2700 컴퓨팅 단위 시간을 인용하지만 829비트 RSA는 년이고 512비트 RSA는 시간입니다. 그것은 약 8,760( (8760hrs * 2700yrs) / 2700hrs , 여기서 8,760은 1년의 시간) 곱하기(2^13)로 4년( (4hrs * 8760hrs) / 24hrs / 365days )에 가깝다고 생각합니다. AWS에서 백만 달러의 컴퓨팅 시간? (아마도 더 많은 RAM이 필요하다는 사실을 무시)

256비트 RSA 1분 계산 시간 대 829비트 RSA 2700년 계산 시간 = log2(525600mins * 2700yrs) (1년의 분)은 대략 2^30에 해당합니다. 다시 말하지만, 512비트 RSA 계산 난이도와 유사하게 이는 가정된 2^32비트 강도 차이에 대한 델타에 매우 가깝습니다. RSA 키를 더 빠르게 인수분해할 수는 있지만 계산 난이도는 대략 유지되는 것 같습니까?

최고의 정보는 아니지만 진행 및 개선 속도에 대한 대략적인 아이디어를 얻을 수 있을 만큼 충분합니다.

• 계산의 어려움은 수십 년 동안 대략 정확하고 일관성이 있습니까?
• 인수분해를 더 빠르게 수행하기 위한 개선된 계산 비율은 훌륭하게 개선되었지만 상당한 양은 아니었습니까?

1024비트는 여전히 손이 닿지 않는 상태로 유지될 것이며 2048비트는 위에서 다룬 역사적 진행 상황을 기반으로 더욱 그렇습니다. 3072비트 RSA에 2^16(65k) ~ 2^22(4백만) 비트의 추가 난이도가 2^30(10억) ~ 2^보다 훨씬 더 많은 보안 이점이 있다는 증거는 거의 없습니다. 32(40억) 2048비트에는 1024비트 RSA가 있습니다. (눈에 띄는 추가 어려움을 추가하지 않는다는 것이 아니라 2048비트 RSA 자체가 그래야 할 때 충분히 견디지 못할 것이라는 가정을 기반으로 함)

현재 829비트 RSA 노력을 기반으로 하며 2048비트 RSA의 비트 보안 수준과 대략 38비트 차이가 있습니다. 829비트 RSA를 3개월(1년에 4개의 3개월 기간)로 인수한 일정한 컴퓨팅 성능을 취하면 1로 낮추기 위한 발전이 있더라도 68,719,476,736년( 2^38 / 4 )이 됩니다. 10억 배 적은 작업(2^30), 여전히 약 64년이고 수만 대의 기계가 있습니다 .

수학, 비용-편익 분석, 상식적인 추론에도 불구하고 3072비트가 여전히 가치가 있다고 생각한다면 다른 방법으로 당신을 설득하는 데 기여할 수 있는 것이 없다고 생각합니다. .

LetsEncrypt가 발행할 최소값을 적용하는 것이 아니라 Certbot을 사용한 변경을 옹호하고 있다는 점을 기억하십시오. Certbot은 이미 전체 문제를 피하는 적절한 암호 제품군을 구성하여 사용자를 돕습니다. 따라서 여기서 누가 실제로 혜택을 보게 될까요? RSA를 키 교환으로 사용하지 않는 다른 모든 사람들(Certbot 사용)은 더 많은 부하와 대역폭을 추가하고 있습니다. 그들의 서버(대부분의 경우 사소한 경우에도).

문제를 닫아야 합니다.

https://www.keylength.com/

https://www.keylength.com/

당신 은 이미 4 년 전에 이 스레드 에서 정보 를 제공 했습니다 . 당신은 그 웹사이트의 조언의 맥락과 그것이 여기에 어떻게 적용되는지 이해하지 못하는 것 같습니다.

인증서에 대해 3072비트 RSA 또는 더 긴 키 길이가 더 편안하고 이미 할 수 있는 것과 같이 명시적으로 옵트인하려면 3072비트를 새로운 기본값으로 채택하기 위해 실용적인 보안에 신경을 쓸 이유가 없습니다. . 2048비트 RSA면 충분 합니다.

당신 은 이미 4 년 전에 이 스레드 에서 정보 를 제공 했습니다 . 당신은 그 웹사이트의 조언의 맥락과 그것이 여기에 어떻게 적용되는지 이해하지 못하는 것 같습니다.

당신은 더 이해하지 않습니다. ANSSI 조언은 예를 들어

행정부와 사용자 간의 원격 서비스 및 전자 교환 개발의 일환으로, 행정 당국은 이러한 서비스의 구현을 담당하는 정보 시스템의 보안을 보장해야 합니다.
일반 안전 참조는 특히 행정 당국이 서로 간의 관계 및 사용자와의 관계에서 구현한 정보 시스템에 대해 부과됩니다(이는 행정부에 벌금을 부과하는 것과 같은 원격 서비스).
간접적으로 일반 보안 참조는 관리 당국이 구현하는 전자 교환을 보호하는 데 도움을 주는 모든 서비스 제공업체와 제품을 제공하는 활동을 하는 제조업체를 대상으로 합니다. 보안의.
일반적으로 정보 시스템 및 전자 교환의 보안 관리를 조직하려는 다른 조직의 경우 일반 보안 참조가 최신 기술에 따른 모범 사례 지침으로 제공됩니다.

따라서 프랑스에서는 모든 목적과 수단 에 적용할 수 있으며 군사 목적과 같은 합리적인 맥락에 전혀 제한되지 않습니다.

그리고 조언 중 하나는 " 2030을 초과하지 않는 사용을 위해서라도 최소 3072 비트의 모듈을 사용하는 것이 좋습니다"입니다. 그리고 3072비트는 더 이상 조언이 아니지만 2030년 이후에 사용/영향이 예상되는 경우 필수입니다.

개인 정보 보호 및 모범 사례에 대한 프랑스 기관인 CNIL도 ANSSI 문서 를 모든 웹사이트에 대한 표준 권장 사항으로 사용합니다. https://www.cnil.fr/fr/securite-securiser-les-sites-web

ANSSI는 TLS 구현 또는 웹사이트 보안을 위한 특정 권장 사항을 사이트에 게시했습니다.

(그리고 you must authorize only incoming IP network flows on this machine on port 443 and block all the other ports. 를 해야 한다고 명시하기 때문에 Let's Encrypt에도 반대합니다. 하지만 이것은 )

NIST 조언은 정보 전달의 감수성에 구속되지 않지만 키 또는 인증서도 관리해야 하는 거의 모든 경우에 적용할 수 있는 일반적인 조언입니다.

LE가 정부 기관이나 기타 기관의 최신 조언에 반대하여 기본 구성을 사용한 것은 이번이 처음이 아닙니다.

아, 그리고 BSI는 올해 조언을 검토합니다. 그것은보다

중요 참고 사항: 모든 비대칭 메커니즘에 대해 동일한 보안 수준을 달성하려면 RSA, DH 및 DSS에 대해 3000비트의 키 길이를 사용하는 것이 좋습니다 . 2023년부터 이 기술 지침을 준수해야 하는 암호화 구현을 위해 최소 3000비트의 키 길이가 필요합니다.

@aeris 프랑스가 3072비트 RSA를 의무적으로 부과하더라도 다른 곳에서는 법이 아닙니다. 조언 및 권장 사항은 필수 요구 사항과 동일하지 않습니다.

보안/개인 정보 보호를 위한 모범 사례로 암호 제품군에서 RSA 키 교환을 사용하도록 제안하는 경우에도 놀랄 것입니다. 보안 및 개인 정보를 올바르게 처리하려면 PFS 전용 암호 제품군을 채택하십시오. RSA 인증서는 인증에서만 역할을 하기 때문에 그 시점부터 관련이 없습니다.

어쨌든, 나는 여기에서 나 자신을 반복하고 있다고 느끼고 끝없는 앞뒤로 관심이 없습니다. 특정 보안 당국/권고를 준수해야 하는 경우 명시적으로 준수하십시오. 나는 이미 2048비트가 안전하고 가까운 미래에도 그렇게 될 것이라고 자세히 설명했습니다. 그렇지 않다면 3072비트 RSA도 더 이상 안전하지 않을 것입니다.

당신이 이 주제에 대해 다소 열정적이므로 NIST / ANSSI / BSI 등을 암송하는 대신 내가 당신에게 전달한 내용을 이해하려고 노력하고 파악하십시오. AES- 128은 AES의 가장 낮거나 약한 보안 수준으로 도입 되었지만 그 자체로 상당히 안전합니다.

3072비트에서 얻는 것은 "더 안전하다"는 잘못된 인식뿐입니다. 2048비트가 충분하지 않은 경우 3072비트가 더 이상 안전할 것이라고 생각할 이유가 없기 때문입니다. 추가 16비트 보안은 이러한 발전을 따라가지 못할 것입니다. 현명한 일을 하고 RSA를 키 교환으로 계속 사용하지 마십시오... 다른 곳에 보안 관행을 적용하는 대신 더 큰 RSA 키 길이에만 의존하면 자신을 속이는 것입니다.

실제 보안상의 이점이 아니라 규정 준수를 위해 계속 논쟁하고 싶다면 맡기겠습니다. 개인적으로 기본값으로 설정하는 것은 가치 있는 변경 사항이 아니며, 대다수의 Certbot 사용자는 단점과 실제 보안에서 실질적인 이득이 없기 때문에 원하지 않을 수 있습니다.

LE가 정부 기관이나 기타 기관의 최신 조언에 반대하여 기본 구성을 사용한 것은 이번이 처음이 아닙니다.

아마도 당신이 생각하는 것과는 달리 그들이 더 잘 알기 때문일 것입니다. 이전에 제공된 모든 정보에도 불구하고 관심이 없거나 전혀 열려 있지 않은 것 같습니다.

더 이상 확신할 수는 없지만 성공적으로 공격하려면 2^128비트 대칭 강도가 필요합니다 .

현재 세계의 총 에너지 소비량은 연간 약 500EJ(5×10^20J)입니다(또는 이 기사에 나와 있음).

이것은 2040년에 총 2^138 이 될 것입니다. 이것은 전체 행성 의 모든 자원을 동원하는 단일 10년 계산 에 대한 것입니다.

또 다른 재미있는 통찰력 :

요약하자면 , 세상의 모든 달러 (누적 부채 등 존재하지 않는 달러 포함)를 사용하고 그 과정에서 지구 전체 를 불 태워도 1000분의 1의 철저한 키 검색을 할 수 없습니다.

256비트 대칭 암호화 키 btw 는 우리 태양계 내에서 해독할 수 있는 모든 에너지를 초과합니다 .

물리적 우주의 법칙은 이러한 적당한 크기의 키라도 절대 강제로 사용하지 않을 것임을 의미합니다. 절대 깨지지 않는다는 말은 아닙니다. 알고리즘에서 결함을 발견할 수 있습니다.

"파괴할 수 없다"는 것보다 더 강한 것은 없으므로 100비트 정도를 초과하는 강도를 비교하는 것은 어쨌든 의미가 없습니다 . - 소스

이제 이러한 모든 인용문은 3072비트 RSA와 같은 128비트 키에 초점을 맞추고 있지만 2048비트 RSA의 110-112비트는 여전히 상당히 중요합니다. 그러나 XKCD가 권장하는 경로 를 선택하는 것이 훨씬 저렴합니다. :)

주장이 보안에서 규정 준수로 이동한 것 같습니다.

주장이 보안에서 규정 준수로 이동한 것 같습니다.

아니면. 이것은 최소한 10년 이후로 TLS/X.509 세계에서 정기적으로 볼 수 있는 것처럼 발에 총격을 피하기 위해 기본적으로 무엇을 사용해야 하는지에 대한 보안 생태계와 관련된 잘 알려진 기관의 최신 조언입니다.