DJB와 설계 기반 보안: qmail부터 Curve25519까지

설계 기반 보안(보안-by-construction)이 의미하는 바(전문 용어 없이)\n\n설계 기반 보안은 흔히 하는 실수를 만들기 어렵게 설계하고, 피할 수 없는 실수의 피해 범위를 제한하는 시스템을 구축하는 것을 의미한다. 긴 체크리스트(“X를 검증하라, Y를 정화하라, Z를 설정하라…” )에 의존하는 대신, 가장 안전한 경로가 가장 쉬운 경로가 되도록 소프트웨어를 설계한다.\n\n어린이 보호 포장과 비슷하게 생각하라: 모든 사람이 완벽히 주의한다고 가정하지 않는다. 사람은 피곤하고 바쁘며 때로 실수한다. 좋은 설계는 개발자·운영자·사용자에게 요구되는 ‘완벽한 행동’의 수준을 줄여준다.\n\n### 왜 단순성이 위험을 낮추는가\n\n보안 문제는 종종 복잡성 속에 숨어 있다: 너무 많은 기능, 너무 많은 옵션, 구성 요소 사이의 너무 많은 상호작용. 추가되는 설정 하나마다 새로운 실패 모드—시스템이 깨지거나 오용될 예기치 못한 방식—를 만들 수 있다.\n\n단순성은 두 가지 실용적 이점을 제공한다:\n\n- 감사할 코드가 줄어든다: 분기와 특수 사례, 숨겨진 동작이 줄어든다.\n- 잘못 설정할 가능성이 줄어든다: 유연한 선택지 열 개 대신 하나의 안전한 기본값이 있을 때, 우발적 취약점의 여지가 줄어든다.\n\n이것은 단순함 자체를 위한 미니멀리즘이 아니다. 이해하고, 테스트하고, 무언가 잘못됐을 때 무슨 일이 일어나는지 추론할 수 있을 정도로 동작 집합을 작게 유지하는 것이다.\n\n### 이 글의 범위(그리고 범위 외)\n\n이 글은 Daniel J. Bernstein의 작업을 구체적 예로 삼아 설계 기반 보안이 어떻게 적용되는지 보여준다: qmail가 어떻게 실패 모드를 줄이려 했는지, 상수 시간 사고가 보이지 않는 유출을 어떻게 피하는지, Curve25519/X25519와 NaCl이 어떻게 오용하기 어려운 암호를 지향하는지 등.\n\n하지 않는 것: 암호학의 전체 역사를 제공하거나 알고리즘의 수학적 안전성을 증명하거나 모든 제품에 ‘단 하나의 최고 라이브러리’가 있다고 주장하지는 않는다. 좋은 원시 알고리즘이 모든 문제를 해결해주지 않는다는 점도 숨기지 않는다—실제 시스템은 키 취급, 통합 실수, 운영 공백 때문에 여전히 실패한다.\n\n목표는 단순하다: 암호학 전문가가 아니더라도 안전한 결과가 나오기 쉬운 설계 패턴을 보여주는 것이다.\n\n## Daniel J. Bernstein는 누구이며 왜 그의 작업이 자주 인용되는가\n\nDaniel J. Bernstein(종종 “DJB”)는 qmail 같은 이메일 시스템, Curve25519/X25519 같은 암호 원시, NaCl 같은 실제 사용을 위한 라이브러리 등 실용적 보안 엔지니어링에서 자주 언급되는 수학자이자 컴퓨터 과학자다.\n\n사람들이 DJB를 인용하는 이유는 그가 ‘유일한 옳은 방법’을 제시해서가 아니다. 그의 프로젝트들에는 실패할 수 있는 경로를 줄이는 일관된 엔지니어링 직관이 있다.\n\n### 엔지니어들이 DJB식 작업에서 빌려오는 것들\n\n반복되는 주제는 작고 타이트한 인터페이스다. 시스템이 적은 진입점과 적은 설정 선택을 노출하면 검토하기 쉽고, 테스트하기 쉬우며, 우발적 오용이 어려워진다.\n\n또 다른 주제는 명시적 가정이다. 보안 실패는 종종 무언의 기대(난수성, 타이밍 동작, 오류 처리, 키 저장 방식 등)에서 온다. DJB의 글과 구현은 위협 모델을 구체화하는 경향이 있다: 무엇을, 누구로부터, 어떤 조건에서 보호하는가.\n\n마지막으로 더 안전한 기본값과 지루한 정확성을 선호하는 편향도 있다. 이 전통의 많은 설계는 모호한 매개변수, 선택적 모드, 정보 유출을 일으키는 성능 최적화 같은 예리한 모서리를 제거하려고 시도한다.\n\n### 전기 전기가 아닌—엔지니어링 관점으로\n\n이 글은 전기(전기전기?)나 인물 논쟁이 아니다. qmail, 상수 시간 사고, Curve25519/X25519, NaCl에서 관찰할 수 있는 패턴과 그 패턴이 실제 운영에서 덜 깨지기 쉬운 시스템을 만드는 방식에 대한 엔지니어링 관점이다.\n\n## qmail: 실패 모드를 줄이기 위한 실무적 예\n\nqmail은 매우 실용적인 문제를 해결하기 위해 만들어졌다: 메일을 신뢰성 있게 전달하면서 메일 서버를 높은 가치의 타깃으로 취급하는 것. 메일 시스템은 인터넷에 노출되어 악의적 입력을 계속 받으며 민감한 데이터(메시지, 자격증명, 라우팅 규칙)에 접근한다. 역사적으로 모놀리식 메일 데몬의 한 버그가 전체 시스템 권한 탈취나, 아무도 눈치채지 못하는 메시지 손실로 이어지곤 했다.\n\n### 작업을 분리해 블래스트 반경을 줄여라\n\nqmail의 핵심 아이디어는 “메일 전달”을 수신, 큐잉, 로컬 전달, 원격 전달 등 한 가지 작업만 하는 작은 프로그램으로 분리하는 것이다. 각 부분은 좁은 인터페이스와 제한된 책임을 가진다.\n\n이 분리는 실패가 국지화된다는 점에서 중요하다:\n\n- 한 컴포넌트가 충돌해도 큐를 자동으로 손상시키거나 전체 시스템을 다운시키지는 않는다.\n- 한 컴포넌트에 보안 버그가 있어도 공격자가 모든 다른 부분의 권한을 즉시 얻지는 못한다.\n- 컴포넌트를 개별적으로 추론할 수 있으면 테스트와 감사가 더 쉬워진다.\n\n이것은 실용적인 형태의 설계 기반 보안이다: “한 번의 실수”가 “전면적 실패”가 되기 어렵게 시스템을 설계하라.\n\n### 모방할 만한 설계 습관\n\nqmail은 이메일을 넘어 잘 전파되는 습관을 보여준다:\n\n- 명확한 경계: 컴포넌트가 어떤 입력을 받고 어떤 출력을 산출하는지 정확히 정의하라. 작고 명시적인 계약은 강제하기 쉽다.\n- 엄격한 입력 처리: 네트워크에서 오는 모든 것을 잠재적으로 악의적인 것으로 다뤄라; 일찍 검증하고 이상한 경우를 거부하며 “도움이 되는” 추측을 피하라.\n- 최소 권한 원칙: 컴포넌트를 필요한 권한만으로 실행해 버그가 전체 권한 탈취로 이어지지 않게 하라.\n\n요점은 “qmail을 써라”가 아니다. 실패 모수가 적은 쪽으로 재설계하면—더 많은 코드를 쓰거나 더 많은 설정을 추가하기 전에—큰 보안 이득을 얻을 수 있다는 것이다.\n\n## 공격 표면을 줄이는 타이트 인터페이스\n\n“공격 표면”은 시스템을 쿡쿡 찌르거나 속여 잘못 동작하게 만드는 모든 지점의 합이다. 집을 비유로 들면 문, 창문, 차고 도어, 여분 열쇠, 배달 구멍 등이 잠재적 진입점이다. 더 좋은 자물쇠를 다는 것도 가능하지만, 진입점을 줄이는 것 자체가 더 안전하다.\n\n소프트웨어도 마찬가지다. 여는 포트, 허용하는 파일 포맷, 노출하는 관리자 엔드포인트, 추가하는 구성 노브, 지원하는 플러그 훅이 많을수록 실패할 수 있는 방식이 늘어난다.\n\n### 타이트 인터페이스: 더 작은 API, 더 적은 실패 모드\n\n“타이트 인터페이스”는 덜 하고 더 적은 변형을 허용하며 애매한 입력을 거부하는 API다. 제약적이라고 느껴질 수 있지만 보안 측면에서는 감사해야 할 코드 경로가 적고 놀라운 상호작용이 적어 더 쉽다.\n\n두 디자인을 비교해보자:\n\n- 넓은 인터페이스: “아무 파일도 업로드하세요; 포맷을 감지하겠습니다; 선택적 압축; 선택적 암호화; 선택적 메타데이터; 여러 인증 방식.”\n- 타이트 인터페이스: “바이트를 업로드하세요; 허용 목록의 콘텐츠 타입을 선언해야 함; 최대 크기 고정; 암호화는 내부에서 처리; 인증 방식은 하나.”\n\n두 번째 디자인은 공격자가 조작할 수 있는 것을 줄인다. 또한 팀이 우발적으로 잘못 설정할 수 있는 여지도 줄인다.\n\n### 왜 선택지가 적은 것이 더 안전한가\n\n선택지는 테스트를 곱셈한다. 10개의 토글을 지원하면 10개의 동작이 아니라 조합들이 생긴다. 많은 보안 버그는 그런 이음새(“이 플래그가 검사를 비활성화한다”, “이 모드가 검증을 건너뛴다”, “이 레거시 설정이 속도 제한을 우회한다”)에서 발생한다. 타이트 인터페이스는 “선택지로 보안하기”를 잘 정비된 하나의 경로로 바꾼다.\n\n### 복잡성이 조용히 숨어있는 곳 체크리스트\n\n다음은 공격 표면이 조용히 커지는 곳을 찾는 데 도움이 된다:\n\n- 많은 입력 타입: 여러 파일 포맷, 인코딩, 자동 감지 파싱\n- 너무 많은 진입 경로: 추가 네트워크 포트, 관리자 패널, 디버그 엔드포인트, 웹훅\n- 보안 로직을 바꾸는 기능 플래그: 검증, 인증 또는 암호화 동작을 바꾸는 토글\n- 플러그성: 런타임에 평가되는 스크립트, 템플릿, 플러그인, 사용자 표현식\n- 하위 호환 모드: 레거시 프로토콜, 오래된 암호, 폐기된 API 버전\n- 암묵적 기본값: 환경 변수나 누락된 구성에 따라 동작이 바뀌는 경우\n\n인터페이스를 줄일 수 없을 때는 엄격하게 만들어라: 일찍 검증하고, 알 수 없는 필드를 거부하며, “파워 기능”은 별도의 명확한 엔드포인트 뒤에 두어라.\n\n## 상수 시간 사고: 보이지 않는 유출을 방지하기\n\n“상수 시간” 동작은 연산이 비밀값(프라이빗 키, 논스, 중간 값 등)에 관계없이(대체로) 동일한 시간에 실행되도록 하는 것이다. 목표는 빠르게 만드는 것이 아니라 ‘지루하게(boring)’ 만드는 것이다: 공격자가 런타임과 비밀을 연관짓지 못하면 관찰을 통해 비밀을 추출하기가 훨씬 어렵다.\n\n타이밍 유출은 공격자가 수학을 깰 필요 없이 동일한 연산을 여러 번 실행하거나 공유 하드웨어에서 관찰할 수 있을 때 문제가 된다. 마이크로초·나노초, 캐시 효과 같은 아주 작은 차이가 패턴으로 드러나 키 회복으로 이어질 수 있다.\n\n### 타이밍 가변성이 숨어드는 곳\n\n일반적인 코드도 데이터에 따라 다르게 동작할 수 있다:\n\n- 비밀 데이터에 따른 분기: if (secret_bit) { ... }는 제어 흐름과 실행 시간을 바꾼다.\n- 비밀로 인덱스되는 테이블 조회: 비밀 의존 인덱스가 서로 다른 캐시 라인을 건드릴 수 있다.\n- 캐시 및 메모리 효과: 비밀 의존 메모리 접근 패턴은 CPU 캐시, 페이지 폴트, 프리페칭을 통해 유출될 수 있다.\n- 가변 시간 명령: 일부 큰 수 연산, 나눗셈, 조기 종료 루프는 특정 입력에서 더 오래 걸릴 수 있다.\n\n### 타이밍 위험을 감사하는 높은 수준의 방법\n\n어셈블리를 읽을 필요 없이도 감사에서 가치를 얻을 수 있다:\n\n1. 비밀의 영향 추적: 어떤 변수가 비밀인지(프라이빗 키, 공유 비밀, 인증 태그 등) 목록화하고 어디로 흐르는지 추적하라.\n2. 레드 플래그 검색: 비밀 의존 if 문, 배열 인덱스, 비밀 기반 종료 루프, “빠른 경로/느린 경로” 로직을 찾아라.\n3. 의존성도 위협 모델의 일부로 보라: 사용 중인 암호 라이브러리가 관련 연산에 대해 상수 시간 동작을 명시하는지 검증하라.\n4. 분산 테스트: 서로 다른 비밀로 연산을 여러 번 실행해 분포를 측정하라; 일관된 큰 차이는 경고 신호다.\n\n상수 시간 사고는 영웅적 행위가 아니라 규율이다: 비밀이 타이밍을 조종하지 못하도록 코드를 설계하라.\n\n## Curve25519와 X25519: 오용하기 어려운 암호\n\n타원 곡선 키 교환은 두 장치가 네트워크상에 공개적으로 보이는 값만 주고받으면서 동일한 공유 비밀을 생성하는 방법이다. 각 쪽은 비밀로 유지되는 개인값과 네트워크에 안전하게 보낼 수 있는 공개값을 생성한다. 공개값을 교환한 후 각자 자신의 개인값과 상대의 공개값을 결합해 동일한 공유 비밀을 얻는다. 도청자는 공개값만 보지만 공유 비밀을 현실적으로 복원할 수 없으므로 양측은 대칭 암호 키를 유도해 비공개 통신을 할 수 있다.\n\n### Curve25519/X25519가 인기 있는 이유\n\nCurve25519는 기본 곡선이고 X25519는 그 위에 정의된 표준화된 특정 키 교환 함수다. 이들의 매력은 주로 설계 기반 보안에 있다: 발사(foot) 실수를 줄이고 파라미터 선택을 줄이며 안전하지 않은 설정을 실수로 고르는 길을 줄였다.\n\n또한 폭넓은 하드웨어에서 빠르며, 이는 많은 연결을 처리하는 서버와 배터리를 아껴야 하는 모바일에서 중요하다. 설계는 상수 시간 구현이 쉬운 구조를 장려해(타이밍 공격에 대한 저항을 높여) 공격자가 미세한 성능 차이로 비밀을 추출할 위험을 줄인다.\n\n### 그것이 제공하는 것과 제공하지 않는 것\n\nX25519는 *키 합의(key agreement)*를 제공한다: 두 당사자가 대칭 암호화를 위한 공유 비밀을 도출하도록 돕는다.\n\n하지만 그 자체로 인증을 제공하지는 않는다. 인증서, 서명, 사전 공유 키 같은 방식으로 상대의 신원을 검증하지 않으면 X25519만으로는 잘못된 상대와 안전하게 대화할 수 있다. 즉, X25519는 도청을 방지하지만 위장(impersonation)을 스스로 막지는 못한다.\n\n## NaCl의 큰 아이디어: 선택지 줄이기, 실수 줄이기\n\nNaCl(네트워킹 및 암호화 라이브러리)은 애플리케이션 개발자가 우연히 취약한 암호 조합을 만들지 못하게 하는 간단한 목표로 만들어졌다. 수많은 알고리즘, 모드, 패딩 규칙, 구성 노브를 제공하는 대신 NaCl은 이미 안전하게 연결된 소수의 고수준 연산을 사용하도록 강제한다.\n\n### 안전한 빌딩 블록으로서의 box와 secretbox\n\nNaCl의 API는 여러분이 무엇을 하고 싶은지(무엇을 하려는지)를 이름으로 따르고, 어떤 원시를 조합할지 이름으로 따르지 않는다.\n\n- crypto_box (box): 공개키 인증형 암호화. 비밀 키, 수신자 공개 키, 논스, 메시지를 주면 메시지를 숨기고 발신자가 적절한 키를 알고 있음을 증명하는 인증된 암호문을 얻는다.\n- crypto_secretbox (secretbox): 공유키 인증형 암호화. 같은 아이디어지만 단일 공유 비밀 키를 사용한다.\n\n주된 이점은 암호화 모드와 MAC 알고리즘을 따로 선택해 올바르게 조합해야 하는 부담이 사라진다는 점이다. NaCl의 기본값은 현대적이고 오용에 강한 합성(예: encrypt-then-authenticate)을 강제하므로 무결성 검사를 빼먹는 등의 일반적 실패 모드를 줄인다.\n\n### 단점: 선택지 감소 vs 유연성\n\nNaCl의 엄격함은 레거시 프로토콜, 특수 형식, 규정상 요구되는 알고리즘과의 호환성이 필요할 때 제한적으로 느껴질 수 있다. “모든 매개변수를 조정할 수 있다”는 것과 “암호 전문가가 아니어도 안전하게 배포할 수 있다”는 것 중 하나를 선택하는 것이다.\n\n많은 제품에겐 후자가 바로 핵심이다: 설계 공간을 제약해 버그가 존재할 수 있는 범위를 줄인다. 진정한 커스터마이징이 필요하다면 낮은 수준의 원시로 내려가면 되지만 — 그건 다시 예리한 모서리로 들어가는 선택이다.\n\n## 안전한 기본값과 너무 많은 노브의 비용\n\n“기본적으로 안전”하다는 것은 아무 것도 하지 않았을 때 가장 안전하고 합리적인 옵션이 주어지는 것을 의미한다. 개발자가 라이브러리를 설치하고 빠른 예제를 복사하거나 프레임워크 기본값으로 실행하면 결과가 오용하기 어렵고 약화되기 어렵도록 해야 한다.\n\n기본값은 중요하다. 대부분의 실제 시스템은 기본값으로 실행된다. 팀은 빠르게 움직이고 문서는 대충 읽히며 구성은 유기적으로 성장한다. 기본값이 “유연”이라면, 이는 종종 “잘못 설정하기 쉽다”는 뜻이다.\n\n### 기본값이 조용히 위험을 만드는 방식\n\n암호 실패는 항상 “수학이 잘못되었다”에서 발생하지 않는다. 위험한 설정을 사용 가능하거나 익숙하거나 쉬워서 골랐기 때문에 실패하는 경우가 많다.\n\n일반적인 기본값 함정:

\n- : 비암호학적 PRNG 사용, 시드 재사용, 컨테이너/VM에서 낮은 엔트로피 원천으로 폴백. 키 생성이 불안정한 난수에 의존하면 그 위에 쌓인 모든 것이 약해진다.\n- : , , 오래된 RSA 크기 등이 그대로 남아 실제로 협상되어 사용되는 경우.\n- : 블록 암호 모드, 패딩 규칙, 논스 처리, 자체 제작 스킴에 대한 많은 노브 제공. 선택지가 많을수록 ‘암호화된 것처럼 보이지만 안전하지 않은’ 프로토콜을 만들 가능성이 높아진다.\n\n### 실용 규칙: 선택지를 줄이면 결과가 더 안전하다\n\n보안 경로를 가장 쉬운 경로로 만드는 스택을 선호하라: 검증된 원시, 보수적 파라미터, 취약한 결정을 요구하지 않는 API. 라이브러리가 열 개의 알고리즘, 다섯 개 모드, 여러 인코딩 중 골라라고 하면, 당신은 구성으로 보안 엔지니어링을 하라는 요청을 받고 있는 것이다.\n\n가능하면 다음을 선택하라: \n- 현대적이고 널리 검토된 알고리즘을 기본값으로 제공하는 라이브러리\n- 폐기된 옵션을 ‘고급 설정’ 뒤에 숨기지 말고 제거하는 정책\n- 위험한 작업을 불가능하게 하거나 최소한 명확히 위험함을 드러내는 API\n\n설계 기반 보안은 모든 결정을 드롭다운으로 바꾸는 것을 거부하는 행위이기도 하다.\n\n## 실제 코드에서 “단순하고 검증 가능”이란 어떤 모습인가\n\n“검증 가능하다(verifiable)”는 대부분의 제품 팀에서 “형식적으로 증명되었다”는 뜻은 아니다. 대신 빠르고 반복 가능하게 자신감을 쌓을 수 있고 코드가 무엇을 하는지 오해할 기회가 적은 것을 의미한다.\n\n### 실무적으로 “검증 가능”이 될 수 있는 것들\n\n코드베이스가 더 검증 가능해지는 조건: \n- : 작은 함수, 명확한 이름, 최소한의 마법. 새로운 엔지니어가 예외 없이 흐름을 설명할 수 있다.\n- : 입력이 주어졌을 때 출력이 고정되고 문서화되어 있음(특히 암호에 중요). 이는 우발적 변경을 잡아낸다.\n- : 같은 소스는 같은 바이너리를 생성하므로 리뷰한 코드가 실제 실행되고 있음을 확인할 수 있다.\n- : 싸지는 않지만 범위가 정해져 있어 감사자가 옵션과 구성 상태에 압도당하지 않고 중요한 경로를 커버할 수 있다.\n\n### 왜 단순한 코드 경로가 리뷰하기 쉬운가\n\n브랜치, 모드, 선택 기능은 검토자가 고민해야 할 상태를 곱셈한다. 단순한 인터페이스는 가능한 상태 집합을 좁혀 리뷰 품질을 두 가지 방식으로 향상시킨다:\n\n1. 리뷰어는 경계 사례를 쫓느라 시간 낭비하지 않고 몇 가지 보안 중요 흐름에 집중할 수 있다.\n2. 예기치 않은 할당, 위험한 파싱 단계, 타이밍 민감한 비교 같은 ‘이상한 것’을 알아채기 쉽다.\n\n### 채택할 수 있는 경량 검증 워크플로우\n\n지루하고 반복 가능하게 유지하라:\n\n- : 유닛 테스트와 함께 사용하는 모든 원시에 대한 테스트 벡터를 추가하고, 변경 시 CI에서 실행하라.\n- : 키, 난수화, 직렬화, 비교를 건드리는 변경에 대해 보안 중심 체크리스트를 요구하라.\n- : 비밀이 아닌 수준의 실패 원인 로깅, 복호화/검증 실패 급증에 대한 경보, 의존성 버전 추적으로 암호 코드가 언제 변경되었는지 파악하라.\n\n이 조합이 전문가 리뷰를 대체하지는 못하지만 최소선을 끌어올린다: 놀라움이 줄고 탐지 속도가 빨라지며 추론 가능한 코드가 된다.\n\n## 좋은 원시를 써도 암호 시스템이 실패하는 지점들\n\nX25519 같은 잘 알려진 원시나 NaCl 스타일의 간결한 API를 선택했더라도 통합·인코딩·운영 단계에서 실패한다. 실제 사건의 대부분은 “수학이 틀렸다”가 아니라 “수학을 잘못 사용했다”이다.\n\n### 통합 함정(흔한 용의자들)\n\n: 장기 키를 에페메랄(임시) 키로 재사용, 키를 소스 코드에 저장, 공개키와 비밀키 바이트 배열을 혼동(둘 다 배열이기 때문에) 등.\n\n: 많은 인증형 암호화 스킴은 키당 고유한 논스를 요구한다. 논스 중복(카운터 리셋, 멀티프로세스 경쟁, “충분히 랜덤” 가정으로 인한 재사용)은 기밀성이나 무결성 상실로 이어질 수 있다.\n\n: base64 vs hex 혼동, 선행 0 손실, 일관성 없는 엔디언, 여러 인코딩을 받아들여 다른 방식으로 비교되는 경우. 이런 버그는 “검증된 서명”을 “다른 무언가가 검증됨”으로 바꿀 수 있다.\n\n: 공격자에게 도움이 되는 상세 오류를 반환하거나, 검증 실패를 무시하고 계속 진행하는 것은 둘 다 위험하다.\n\n### 운영상의 함정이 좋은 암호를 무력화함\n\n비밀은 , 크래시 리포트, 분석, 디버그 엔드포인트를 통해 유출된다. 키는 , VM 이미지, 범위가 너무 넓은 에 들어간다. 또한 누락(또는 업데이트로 인한 깨짐)은 설계가 옳더라도 취약한 구현에 발이 묶이게 한다.\n\n### 비암호학자들을 위한 완화 체크리스트\n\n- 논스를 설계 요건으로 다뤄라: 고유성 규칙을 문서화하고 재사용 테스트를 하라.\n- 키/메시지의 단일 표준 인코딩을 정의하고 다른 것은 거부하라.\n- 검증 실패 시 닫는(fail-closed) 동작을 하라: 멈추고 일반적 오류를 표면화하라.\n- 로그에 비밀이 남지 않도록 자동화된 로그 마스킹 테스트를 추가하라.\n- 비밀은 전용 비밀 관리자에 저장하고 접근 권한을 회전·범위화하라.\n- 암호 의존성은 고정(pinning)하고 검토하라; 업데이트와 감사를 일정에 넣어라.\n\n## 제품에 맞는 암호 엔지니어링 접근법 선택하기\n\n좋은 원시가 자동으로 안전한 제품을 만들어주지는 않는다. 더 많은 선택지를 노출할수록(모드, 패딩, 인코딩, 커스텀 튜닝) 팀이 실수로 취약한 시스템을 만들 수 있는 길이 늘어난다. 설계 기반 보안 접근은 의사결정 지점을 줄이는 엔지니어링 경로를 선택하는 것에서 시작한다.\n\n### 실용적 의사결정 프레임워크\n\n하라, 다음과 같은 경우:\n\n- 명확한 프로토콜 명세와 상호운용 요구가 있다.\n- 리뷰, 테스트 벡터, 장기 유지보수의 소유권을 지정할 수 있다.\n- 이미 존재하는 프로토콜을 재발명하지 않는다는 확신이 있다.\n\n유용한 규칙: 설계 문서에 “모드는 나중에 고르겠다” 또는 “논스는 그냥 조심하겠다”가 적혀 있다면 이미 너무 많은 노브를 허용하고 있는 것이다.\n\n### 벤더와 내부 팀에 묻는 질문들\n\n마케팅 문구가 아닌 구체적 답변을 요구하라:\n\n- API가 안전하지 않은 상태를 표현하기 어렵게 만드는가? 논스 크기, 키 크기, 알고리즘 선택이 제약되는가?\n- 개발자가 키와 평문만 제공하면 어떤 동작이 발생하는가? 암호화가 항상 인증(예: AEAD)되는가, 아니면 우연히 ‘암호화만’이 가능한가?\n- 어떤 연산이 상수 시간으로 의도되는가? 타이밍, 캐시, 분기 유출에 대한 위협 모델은 무엇인가?\n- 키는 어떻게 생성·저장·회전·제로라이즈(zeroize)되는가? 키 포맷은 명시적이고 버전이 매겨져 있는가?\n- 최근 독립 감사 시기는 언제인가? 취약점은 어떻게 처리되는가? 보안 관련 변경 사항을 보여주는 변경 로그가 있는가?\n\n### 효과가 큰 엔지니어링 위생 습관\n\n암호를 안전성 중요 코드처럼 다뤄라: API 표면을 작게 유지하고 버전을 고정(pin), 알려진 응답 테스트를 추가하고 파싱/직렬화에 퍼징을 실행하라. 지원하지 않을 항목(알고리즘, 레거시 포맷)을 문서화하고, ‘호환성 스위치’가 영원히 남지 않도록 마이그레이션을 구축하라.\n\n## 실행 가능한 요약: 이번 주에 설계 기반 보안을 적용하는 방법\n\n설계 기반 보안은 사서 구매하는 새로운 도구가 아니다—범주 전체의 버그를 만들기 어렵게 하는 습관의 집합이다. DJB식 엔지니어링 전반의 공통점은: 추론 가능한 수준으로 단순하게 유지하라, 오용을 제약하는 타이트한 인터페이스를 만들라, 공격하더라도 동작이 같도록 코드를 작성하라, 실패 안전한 기본값을 선택하라.\n\n### 화이트보드에 붙여둘 요점들\n\n- 더 작은 컴포넌트, 더 적은 상태, 더 적은 구성 분기는 놀라운 동작의 여지를 줄인다.\n- 여러 ‘거의 맞는’ 입력을 허용하는 API보다 하나의 올바른 형식을 받는 API를 선호하라.\n- 원시가 안전해도 주변 코드가 타이밍·분기·메모리 접근 패턴을 통해 비밀을 유출할 수 있다.\n- 각 노브는 테스트해야 할 새 조합과 보통 우발적 오용 방식을 추가한다.\n\n### 팀을 위한 1주 실행 리스트\n\n1. TLS 설정, 패스워드 해싱, 토큰 서명, 키 교환, 난수 생성 등 암호를 사용하는 모든 곳을 목록화하라. 사용 중인 라이브러리와 구성까지 적어라.\n2. 홈브루 암호화, ‘영리한’ 인코딩/디코딩, 남용 가능한 풍부 기능 API를 제거하라. 소수의 의견이 뚜렷한 원시로 표준화하라.\n3. 암호 호출을 매개변수 적은 내부 모듈 뒤에 래핑해 표면적을 최소화하고 강한 타입과 명확한 입력 검증을 적용하라.\n4. 원시의 알려진 응답 테스트, 파서 퍼즈 테스트, 핫 경로에서의 “비밀 의존 분기 없음” 검사 등을 추가하라.\n5. 안전한 기준을 코드(위키가 아니라) 안에 고정하고, 벗어나려면 명시적 리뷰를 요구하라.\n\n구조화된 체크리스트를 원하면 내부 보안 문서 옆에 “암호 인벤토리” 페이지(예: )를 추가하는 것을 고려하라.\n\n### 빠른 개발에서의 “설계 기반 보안”에 대한 메모\n\n이 아이디어들은 암호 라이브러리뿐 아니라 소프트웨어를 어떻게 설계하고 배포하는지에도 적용된다. 채팅을 통해 웹/서버/모바일 앱을 생성하는 워크플로(예: Koder.ai 같은 툴)를 쓰는 경우에도 같은 원칙이 제품 제약으로 나타난다: 지원 스택을 적게 유지(웹은 React, 백엔드는 Go + PostgreSQL, 모바일은 Flutter), 변경을 생성하기 전에 계획 강조, 롤백을 싸게 만드는 것 등.\n\n실무적으로 , , 같은 기능은 실수의 블래스트 반경을 줄이는 데 도움이 된다: 변경이 반영되기 전에 의도를 검토하고, 문제가 생기면 빠르게 되돌리고, 실행 중인 것이 생성된 것과 일치하는지 검증할 수 있다. 이는 qmail의 분할 격리 본능을 현대 전달 파이프라인에 적용한 것과 같다.