PHP 라이브러리 sodium_compat도 이번 문제의 영향을 받았음
관련 내용은 security-advisories PR #756에서 확인 가능함
오늘 저녁에는 오픈소스 생태계 내 다른 Ed25519 구현체들을 모두 점검해, 동일한 검증 누락이 있는지 확인해볼 예정임
몇몇 라이브러리에서 아예 검증 로직이 빠져 있음을 발견했음
하지만 위에서 언급된 취약점처럼 잘못된 방식으로 구현된 사례는 없었음
내가 이메일을 보내지 않았다면, 아마 ianix의 Ed25519 배포 목록에 없거나, 내가 놓쳤거나, 혹은 안전한 구현일 가능성이 높음
오픈소스에 기여해줘서 고맙다는 말을 전하고 싶음
지난 4개월 동안 Lean4용 sodium 바인딩을 개발 중임
이제 Ristretto255 단계에 도달했는데, 왜 저자가 이 기술에 열광하는지 이해하게 되었음
Ristretto는 Curve25519 위에서 임의의 다항식을 구성할 수 있는 정교한 API로, 실험하는 과정이 정말 즐거움
혹시 저자가 이 글을 본다면, 진심으로 감사의 말을 전하고 싶음
혹시 이 프로젝트의 공개 저장소가 있는지 궁금함
Libsodium의 목표는 저수준 함수가 아니라 고수준 API를 제공하는 것이었음
사용자는 내부 알고리즘을 몰라도 되도록 설계되었지만, 시간이 지나면서 점점 저수준 함수들을 직접 사용하는 사례가 늘어남
결국 Libsodium이 알고리즘 툴킷처럼 쓰이게 되었음
중요한 점은 사용자가 원하는 방향을 인식하고, 프로젝트를 특정 방식으로만 강요하지 않는 것임
일부 프로젝트는 이런 점에서 독단적으로 변하며 실패를 겪음
모든 내부 함수를 API 계약으로 간주하면, 거의 모든 변경이 호환성 깨짐으로 이어짐
따라서 일부 기능을 private 또는 internal로 제한하는 것이 맞는 선택일 때가 많음
Libsodium이 그 경계를 잘 잡았는지는 확신할 수 없지만, 균형이 중요함
예전에 CeeFIT이라는 C++ 테스트 프레임워크를 만들었는데, 컴파일 타임에 fixture를 등록하는 방식이 자랑스러웠음
그런데 일부 사용자가 이를 배치 실행기처럼 사용하더라
그들의 요구를 지원하기 위해 몇 가지 버그를 수정했음
결국 사용자가 있다는 사실 자체가 기뻤음
이번 버그는 미묘하지만 중요한 암호 검증 오류임
“유효한지 확인”이라는 단순한 검사가 실제로는 매우 복잡함
소수 차수 부분군 밖의 점을 허용하면, 즉각적인 취약점이 없어 보여도 상위 계층의 가정을 무너뜨릴 수 있음
또한 저수준 원시 함수는 의도보다 훨씬 널리 재사용되므로, 작은 검증 누락이 큰 파급력을 가질 수 있음
다만 X25519와 Ed25519는 애초에 이런 검증이 필요 없도록 설계되었음
Curve25519 위에서 더 복잡한 프로토콜을 만들 때만 부분군 문제가 생김
그래서 나는 가능한 한 모든 점을 소수 차수 부분군으로 다시 사상함 Monocypher에는 이런 고급 함수들이 있음
예를 들어 crypto_x25519_dirty_fast()나 crypto_elligator_map() 같은 함수들임
이런 “dirty” 함수는 전체 곡선을 덮는 공개키를 생성해, 무작위성과 구분되지 않게 함
이후 X25519 키 교환 시에도 동일한 공유 비밀을 얻을 수 있음
이는 DJB의 설계 덕분으로, 공개키가 비정상적이어도 공유 비밀이 소수 차수 부분군으로 사상됨
결국 Ristretto는 이런 재사상이 불가능한 경우에만 필요함
물론 소수 차수 그룹 추상화는 유용하지만, 그런 프로토콜을 설계할 수 있는 사람이라면 비자명한 cofactor를 다루는 것도 가능해야 함
대기업에 근무한다면 Frank를 회사 차원에서 후원하는 것을 고려해보길 권함
나는 Apple에 근무하지만, Frank가 누구인지 모르겠고, 후원 절차도 모름
설령 안다고 해도 회사 계좌가 아니라 내 개인 돈으로 후원해야 할 것 같음
libnacl도 영향을 받는지 궁금함
나는 매일 libnacl로 컴파일된 소프트웨어를 쓰지만, “libsodium”으로 컴파일된 것은 없음
Hacker News 의견들
PHP 라이브러리 sodium_compat도 이번 문제의 영향을 받았음
관련 내용은 security-advisories PR #756에서 확인 가능함
오늘 저녁에는 오픈소스 생태계 내 다른 Ed25519 구현체들을 모두 점검해, 동일한 검증 누락이 있는지 확인해볼 예정임
하지만 위에서 언급된 취약점처럼 잘못된 방식으로 구현된 사례는 없었음
내가 이메일을 보내지 않았다면, 아마 ianix의 Ed25519 배포 목록에 없거나, 내가 놓쳤거나, 혹은 안전한 구현일 가능성이 높음
지난 4개월 동안 Lean4용 sodium 바인딩을 개발 중임
이제 Ristretto255 단계에 도달했는데, 왜 저자가 이 기술에 열광하는지 이해하게 되었음
Ristretto는 Curve25519 위에서 임의의 다항식을 구성할 수 있는 정교한 API로, 실험하는 과정이 정말 즐거움
혹시 저자가 이 글을 본다면, 진심으로 감사의 말을 전하고 싶음
Libsodium의 목표는 저수준 함수가 아니라 고수준 API를 제공하는 것이었음
사용자는 내부 알고리즘을 몰라도 되도록 설계되었지만, 시간이 지나면서 점점 저수준 함수들을 직접 사용하는 사례가 늘어남
결국 Libsodium이 알고리즘 툴킷처럼 쓰이게 되었음
중요한 점은 사용자가 원하는 방향을 인식하고, 프로젝트를 특정 방식으로만 강요하지 않는 것임
일부 프로젝트는 이런 점에서 독단적으로 변하며 실패를 겪음
비전문가가 암호학적 원시 함수를 직접 사용하는 것은 위험함
Libsodium은 사용자가 스스로를 위험에 빠뜨리지 않도록 설계되었음
라이브러리는 잘못된 사용이 불가능하도록 만드는 것이 이상적임
관련 글로 “If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong”을 추천함
따라서 일부 기능을 private 또는 internal로 제한하는 것이 맞는 선택일 때가 많음
Libsodium이 그 경계를 잘 잡았는지는 확신할 수 없지만, 균형이 중요함
그런데 일부 사용자가 이를 배치 실행기처럼 사용하더라
그들의 요구를 지원하기 위해 몇 가지 버그를 수정했음
결국 사용자가 있다는 사실 자체가 기뻤음
이번 버그는 미묘하지만 중요한 암호 검증 오류임
“유효한지 확인”이라는 단순한 검사가 실제로는 매우 복잡함
소수 차수 부분군 밖의 점을 허용하면, 즉각적인 취약점이 없어 보여도 상위 계층의 가정을 무너뜨릴 수 있음
또한 저수준 원시 함수는 의도보다 훨씬 널리 재사용되므로, 작은 검증 누락이 큰 파급력을 가질 수 있음
Curve25519 위에서 더 복잡한 프로토콜을 만들 때만 부분군 문제가 생김
그래서 나는 가능한 한 모든 점을 소수 차수 부분군으로 다시 사상함
Monocypher에는 이런 고급 함수들이 있음
예를 들어
crypto_x25519_dirty_fast()나crypto_elligator_map()같은 함수들임이런 “dirty” 함수는 전체 곡선을 덮는 공개키를 생성해, 무작위성과 구분되지 않게 함
이후 X25519 키 교환 시에도 동일한 공유 비밀을 얻을 수 있음
이는 DJB의 설계 덕분으로, 공개키가 비정상적이어도 공유 비밀이 소수 차수 부분군으로 사상됨
결국 Ristretto는 이런 재사상이 불가능한 경우에만 필요함
물론 소수 차수 그룹 추상화는 유용하지만, 그런 프로토콜을 설계할 수 있는 사람이라면 비자명한 cofactor를 다루는 것도 가능해야 함
대기업에 근무한다면 Frank를 회사 차원에서 후원하는 것을 고려해보길 권함
설령 안다고 해도 회사 계좌가 아니라 내 개인 돈으로 후원해야 할 것 같음
libnacl도 영향을 받는지 궁금함
나는 매일 libnacl로 컴파일된 소프트웨어를 쓰지만, “libsodium”으로 컴파일된 것은 없음
정말 훌륭한 라이브러리임
Frank Denis에게 감사의 마음을 전함