pyca/cryptography, OpenSSL의 문제점을 지적하며 탈(脫) OpenSSL 선언

pyca/cryptography는 OpenSSL 3.0에서 성능 저하(Performance Regression)가 심각하다고 지적하며, 특히 X.509 인증서 파싱(X.509 Certificate Parsing)에서 10배의 성능 저하가 발생했다고 밝혔다. 이러한 성능 저하는 OpenSSL 3.0의 새로운 API 도입과 내부 구조 변경에서 기인하며, OpenSSL 개발팀은 이러한 성능 저하를 인지하고도 개선 의지를 보이지 않았다고 비판했다. 성능 저하의 근본 원인(Root Cause)은 불필요한 복사, 할당, 해시 테이블, 간접 호출, 락(lock) 사용 등 단순한 최적화 미흡에 있다고 분석했다.

OpenSSL 3.0은 OSSL_PARAM을 이용한 새로운 API를 도입하면서 API의 복잡성을 증가시켰다. OSSL_PARAM은 키-값 쌍의 배열을 함수에 전달하는 방식으로, 이는 성능 저하, 컴파일 타임 검증 감소, 코드 가독성 저하를 야기한다. 특히, ML-KEM 캡슐화(ML-KEM encapsulation)의 경우, BoringSSL은 19줄로 구현되는 반면, OpenSSL은 37줄로 구현되어 API의 비효율성(API Inefficiency)을 보여준다. 또한, OpenSSL 내부 구현을 파악하기 어렵게 만들어 개발자들의 소스 코드 분석(Source Code Analysis)을 어렵게 만든다고 비판했다.

pyca/cryptography는 OpenSSL의 테스트 및 검증(Testing and Verification) 부족 문제를 심각하게 지적했다. OpenSSL의 테스트 커버리지가 부족하여, CI(Continuous Integration)에서 버그가 제대로 감지되지 않는 경우가 많다고 비판했다. 특히, AVX-512를 지원하는 CPU에서 발생하는 RSA 구현의 버퍼 오버플로우(Buffer Overflow) 버그가 CI에서 감지되었음에도 불구하고, CI의 불안정성으로 인해 무시되었다는 점을 강조했다. 이러한 문제 해결을 위해 Intel SDE와 같은 도구의 활용을 제안했다.

pyca/cryptography는 OpenSSL에 대한 의존도를 줄이기 위해 여러 가지 조치를 취할 계획이다. 첫째, 새로운 기능 구현 시 OpenSSL 대신 LibreSSL, BoringSSL, AWS-LC 등 OpenSSL 포크(fork)를 사용할 예정이다. 둘째, 바이너리 아티팩트(binary artifacts)인 휠(wheel)에서 OpenSSL 대신 OpenSSL 포크를 링크하는 방안을 모색하고 있다. 셋째, 장기적으로는 OpenSSL을 완전히 지원 중단하는 방안을 고려하고 있으며, Graviola와 같은 대체 암호화 라이브러리(Alternative Cryptography Libraries)를 검토하고 있다.

pyca/cryptography는 메모리 안전성을 확보하기 위해 Rust 코드 사용을 확대하고 있다. Rust 코드를 활용하여 X.509 파싱(X.509 Parsing) 및 관련 연산을 구현함으로써 OpenSSL의 CVE(Common Vulnerabilities and Exposures)를 회피하고 성능을 향상시켰다. 이는 메모리 안전성을 확보하면서도 성능을 유지할 수 있음을 보여주는 사례이다. pyca/cryptography는 향후에도 Rust 코드 사용을 확대하여 메모리 안전성(Memory Safety)을 강화할 계획이다.