1999년 Netscape가 신뢰한 E-Certify 512비트 RSA 루트 2개를 데스크톱에서 인수분해

RSA는 비트가 하나 늘 때마다 비용이 정확히 2배가 되는 문제가 아님. Steve Weis 추산으로 1024비트 RSA 인수분해는 약 GPU 2,000년이면 되니, 큰 예산이 있는 곳에는 현실적인 범위일 수 있음.

비트당 2배라는 얘기는 알려진 공격이 사실상 전수 탐색뿐인 대칭키 쪽에 가까움. RSA는 전수 탐색보다 훨씬 빠른 인수분해 기법을 쓰고, 키 길이를 2배로 늘려도 실효 보안이 2배가 되진 않음.

글은 소비자 GPU가 아니라 Ryzen 9 5950X CPU에서 CADO-NFS를 돌린 것으로 보임. CADO-NFS 문서에도 GPU 언급은 없고, 16스레드 벤치마크를 보면 병렬화 여지도 있어 보임.

과거 트래픽은 전방향 보안을 쓰지 않은 경우가 많았음. 지금 암호화된 익명 정치 발언을 저장해 뒀다가 나중에 푸는 정부가 얼마나 있을지 궁금함.

대칭 암호 자체는 전수 탐색 외에 깨기 어려울 가능성이 큼. 결국 임시 키 교환이 중요한데, 최근 이전 통신을 녹화해 둔 공격에는 사후 양자 TLS 전환도 소용없음. Cloudflare 요청의 약 70%가 사후 양자 TLS를 쓴다는 수치는 그나마 다행임.

LLM이 만든 오래된 루트 목록을 '그럴듯하다'고만 두면 안 됨. LLM의 전문이 그럴듯한 출력을 만드는 일이고, 최소한 실제로 검증한 항목만 정확하다고 봐야 함.

작성자가 찾으려던 것은 512비트 RSA 키 하나였으니 전체 목록 검증이 필수는 아니었다고 봄. 설치본이 많아 Netscape UI와 추출 데이터의 신뢰 비트를 전부 대조하지는 않았고, 누락이나 오분류 가능성은 높다고 인정함.

흥미로운 TLS 구현 부분을 AI에 너무 맡겨서 아쉬움. 저장소 주석을 보니 Go crypto/tls는 SSLv3, Netscape 4의 SSLv2 호환 ClientHello, RC4-MD5와 40비트 수출용 스위트를 지원하지 않아 자체 서버를 만든 것이었음.

나는 TLS 구현을 몇 번 해봐서 글에서 길게 다루지 않았음. Go를 쓰려 했는데 필요한 구형 프로토콜과 암호군을 지원하지 않았고, OpenSSL로 Netscape가 받는 인증서를 발급하는 쪽도 꽤 고생했음.

현대 라이브러리가 오래되고 취약한 SSL을 버린 탓임. 하위 호환성보다 보안을 택하는 영역이라 당연한 결과라고 봄.

레트로 인터넷 서비스를 만들면 이 문제가 실제로 나옴. 요즘 Debian의 OpenSSL은 짧은 키와 옛 암호군을 기본 비활성화하고 일부는 아예 컴파일하지 않아서, 구형 SSL을 쓰려면 별도 OpenSSL을 빌드해 Nginx까지 다시 빌드해야 했음.