constant-time-analysis

constant-time-analysis 개요

constant-time-analysis는 암호화 코드에서 타이밍 사이드채널 위험을 찾아, 실제로 악용되기 전에 보안 결함을 잡아내는 보안 감사용 스킬입니다. 비밀값에 의존하는 연산, 분기, 비교, 런타임 명령이 키, 토큰, 기타 민감한 값을 누설할 수 있는지 확인해야 하는 엔지니어, 리뷰어, AI 에이전트에게 특히 적합합니다.

핵심 작업은 “암호 이론을 이해하는 것”이 아니라 “이 코드가 어디서 constant-time을 벗어나는지 찾아내는 것”입니다. 그래서 constant-time-analysis 스킬은 구현 리뷰, 머지 전 보안 점검, 그리고 특정 함수가 타이밍 공격에 안전한지 확인해야 하는 사고 대응 단계에서 가장 유용합니다.

일반적인 프롬프트와의 차별점은, 단순 소스 스캔이 아니라 컴파일된 결과물과 언어별 분석 경로를 중심으로 구성되어 있다는 점입니다. constant-time 문제는 소스 코드만 보면 멀쩡해 보여도, 어셈블리·바이트코드·VM 명령에서 드러나는 경우가 많기 때문에 이 차이가 중요합니다.

Security Audit에서 constant-time-analysis에 가장 잘 맞는 경우

다음 코드를 검토할 때 이 스킬을 사용하세요.

• 비밀값, 인증, 암호학적 primitive를 다루는 코드
• 비밀에서 파생된 값에 대해 나눗셈, 나머지 연산, 비교, 분기를 사용하는 코드
• 소스 의도만이 아니라 컴파일된 산출물까지 검증해야 하는 경우
• C, C++, Go, Rust, Swift, Java, Kotlin, PHP, JavaScript, TypeScript, Python, Ruby를 대상으로 하는 경우

무엇을 잡고, 무엇을 놓치는가

constant-time-analysis는 가변 시간 나눗셈, 비밀 의존 분기, 안전하지 않은 비교처럼 타이밍 누설 패턴을 잘 찾아냅니다. 반면 암호 설계 전반의 오류, 프로토콜 결함, 네트워크·캐시·환경 잡음에서 비롯된 누설은, 그것들이 분석된 코드 경로에 직접 나타나지 않는 한 상대적으로 약합니다.

사용자가 이 스킬을 설치하는 이유

수작업 훑기보다 더 이른 시점에 타이밍 위험을 표시해 주는 반복 가능한 리뷰 흐름이 필요할 때 이 스킬을 설치하세요. 단일 코드 조각에 대한 일회성 의견만 필요하다면 일반 프롬프트로도 충분할 수 있지만, 일관된 보안 리뷰 동작이 필요하다면 이 스킬이 구조를 더해 줍니다.

constant-time-analysis 스킬 사용 방법

올바른 방식으로 설치하고 실행하기

스킬 매니저에서 constant-time-analysis 설치 경로를 사용한 뒤, 대상 언어와 민감한 함수 또는 파일이 포함된 컨텍스트에서 실행하세요. 좋은 트리거 프롬프트는 암호화 목적, 비밀 입력, 언어/런타임을 명시해 스킬이 적절한 분석 경로를 고르게 합니다.

트리거 예시:

• “src/sign.rs의 constant-time 위험을 검토해 주세요. 비밀 입력은 private key scalar이고, division, branches, comparisons에 집중해 주세요.”
• “이 PHP 비밀번호 확인 함수에 constant-time-analysis를 실행하고 opcode 수준의 타이밍 누설 가능성이 있는지 알려 주세요.”

스킬이 제대로 작동하도록 입력 형태 맞추기

이 스킬은 다음 정보를 주면 가장 잘 작동합니다.

• 검사할 파일 또는 함수
• 어떤 값이 비밀인지
• 공격자가 관찰할 수 있는 동작이 무엇인지
• 알려져 있다면 대상 언어와 런타임 버전

더 나은 입력 예시:

• “TypeScript의 verifyToken()을 감사해 주세요. token bytes는 비밀이고, 저장된 HMAC와 비교합니다. Div, Mod, 조기 종료 비교를 확인해 주세요.”
• “이 Rust reduce() 루틴이 x86_64와 arm64에서 비밀 의존 division을 하는지 분석해 주세요.”

먼저 읽어야 할 파일

설치 판단과 작업 흐름을 보려면 다음부터 확인하세요.

• SKILL.md: 트리거, 범위, 언어 선택
• README.md: 지원 언어와 출력 목표
• references/compiled.md: C/C++, Go, Rust
• references/javascript.md, references/python.md, references/php.md, references/ruby.md, references/swift.md, references/kotlin.md: VM별 규칙

참조 파일을 하나만 훑는다면, 소스 언어 이름이 아니라 실제 런타임 경로와 맞는 파일을 고르세요.

한 번 훑고 끝내지 말고, 리뷰 흐름으로 사용하기

실용적인 constant-time-analysis 사용 흐름은 다음과 같습니다.

1. 비밀값을 다루는 함수를 식별한다
2. 적절한 언어 가이드를 실행한다
3. division, modulo, comparisons, branches, 수상한 helper 호출을 확인한다
4. 리팩터링이나 컴파일러/런타임 변경 후 다시 실행한다
5. 결과를 기계 검증하고 싶다면 CI 친화적 출력을 요청한다

소스에서 고친 내용이 compiled language에서는 여전히 unsafe instruction으로 바뀔 수 있기 때문에 이 과정이 중요합니다.

constant-time-analysis 스킬 FAQ

constant-time-analysis는 암호화 전용인가요?

아닙니다. 비밀 데이터에 따라 타이밍 차이가 의미를 갖는 코드라면 모두 대상입니다. 다만 실제로는 주로 crypto, auth, key handling, token verification에 해당합니다. 코드가 공용 데이터만 처리한다면 이 스킬은 보통 필요하지 않습니다.

어셈블리나 바이트코드 전문 지식이 꼭 필요한가요?

처음부터는 아닙니다. 이 스킬의 장점은 적절한 런타임 산출물과 언어별 참조로 안내해 준다는 데 있습니다. 모든 명령어를 읽을 필요는 없지만, 어떤 함수나 파일이 보안적으로 민감한지는 알고 있어야 합니다.

일반 프롬프트보다 constant-time-analysis가 더 나은가요?

반복 가능한 보안 리뷰 동작이 필요하다면 그렇습니다. 일반 프롬프트도 눈에 띄는 위험은 잡을 수 있지만, constant-time-analysis는 언어 선택, compiled output, 구체적인 누설 패턴을 기준으로 정리돼 있어서 repository 작업에 더 유용합니다.

언제는 사용하지 말아야 하나요?

일반적인 비즈니스 로직, UI 코드, 공용 데이터 변환에는 쓰지 마세요. 또한 라이브러리가 이미 constant-time 동작을 보장하고 있고, 별도의 비밀 의존 로직이 없는 고수준 API 사용만 묻는 경우에도 생략하는 편이 낫습니다.

constant-time-analysis 스킬 개선 방법

비밀값과 공격자 모델을 분명히 하기

가장 좋은 constant-time-analysis 결과는 무엇이 정확히 비밀이어야 하는지, 공격자가 무엇을 관찰할 수 있는지를 분명히 적었을 때 나옵니다. 위험이 원격 타이밍인지, 로컬 프로세스 타이밍인지, 아니면 컴파일된 코드 검사인지까지 밝혀 주세요. 그렇지 않으면 스킬이 무해한 분기에 과하게 반응하거나, 실제 제약을 놓칠 수 있습니다.

가장 작은 위험 경로만 제공하기

저장소 전체보다 실제로 비밀 데이터를 만지는 함수를 주는 편이 좋습니다. 경로 안에 helper가 있더라도, 분기·산술·비교에 영향을 주는 경우에만 포함하세요. 이렇게 하면 노이즈가 줄고 결과를 바로 적용하기 쉬워집니다.

언어별 근거를 요청하기

가장 좋은 결과를 얻으려면 관련 런타임 산출물을 확인해 달라고 요청하세요.

• C/C++, Go, Rust: assembly
• JavaScript, TypeScript, Python, Ruby, PHP: bytecode
• Kotlin: JVM behavior

타이밍 누설은 소스 수준 아래에서 드러나는 경우가 많기 때문에, 이렇게 해야 constant-time-analysis의 활용도가 높아집니다.

수정할 때마다 다시 실행하기

흔한 실패 패턴은 소스 코드를 고친 뒤 누설이 사라졌다고 가정하는 것입니다. 알고리즘, compiler flags, optimization level, runtime version을 바꾼 뒤에는 다시 테스트하세요. Security Audit용 constant-time-analysis에서는 두 번째 점검에서 실제 보안 상태를 확인하는 경우가 많습니다.