🔢 mathematics

Canonical Byte-String Encoding for Finite-Ring Cryptosystems

이 논문은 유한환 암호 시스템에서 바이트 문자열을 모듈로 m 의 잔여 리스트로 매핑하는 rANS 기반의 표준 인코딩 프로토콜을 제안하고, Rust 구현체와 Lean 4 를 통한 기계 검증된 증명 및 성능 벤치마크를 제시합니다.

원저자: Kyrylo Riabov, Serhii Kryvyi

게시일 2026-03-25

📖 3 분 읽기🧠 심층 분석

CC BY 4.0

원저자: Kyrylo Riabov, Serhii Kryvyi

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

📦 핵심 아이디어: "수학적인 우편물 포장법"

상상해 보세요. 여러분이 친구에게 비밀 편지를 보낼 때, 편지 내용 (텍스트나 파일) 을 그대로 보내면 누군가 훔쳐볼 수 있습니다. 그래서 친구와 약속한 **특수한 수학 규칙 (유한 링 암호)**을 사용하기로 했습니다. 이 규칙은 편지 내용을 **특정 숫자 (예: 50 으로 나눈 나머지)**로만 바꿔야만 작동합니다.

하지만 문제는 이렇습니다:

"내 편지에는 '안녕하세요'라는 한글도 있고, 사진 파일도 있는데, 이걸 어떻게 이 특수한 숫자 규칙에 맞춰서 넣지?"

기존에는 이걸 수동으로 하나하나 변환하거나 작은 표를 만들어서 해결했는데, 이 논문은 **"어떤 길이의 데이터든, 어떤 내용이라도 자동으로 이 숫자 규칙에 맞춰서 포장해주는 표준화된 기계"**를 개발했습니다.

🏭 이 기계가 어떻게 작동할까요? (3 단계 과정)

이 기계 (코덱) 는 데이터를 보내기 위해 3 단계로 포장합니다.

1. "우편물 크기 라벨" (Fixed-Width Header)

먼저, "이 편지가 총 몇 바이트 (글자 수) 인가?"를 정해진 규칙에 따라 숫자로 적습니다.

비유: 택배 상자에 "이 박스 안에는 물건이 100 개 들어있다"라고 미리 적어두는 것과 같습니다.
중요한 점: 이 라벨의 크기는 항상 일정합니다. 편지가 10 자든 100 만 자든, 라벨을 읽는 기계는 항상 같은 크기의 숫자만 보면 됩니다.

2. "상태 확인용 주머니" (State Prefix)

데이터를 변환하는 과정에서 기계 내부에 잠시 쌓아두는 '중간 상태'를 숫자로 적어 넣습니다.

비유: 공장을 가동할 때, 기계가 멈추지 않고 다음 작업을 위해 필요한 '초기 설정값'을 함께 보내는 것과 같습니다.

3. "본문 내용 변환" (Payload Stream)

이제 실제 편지 내용 (바이트) 을 하나씩 집어넣습니다.

작동 원리: 편지 내용을 뒤에서부터 하나씩 꺼내서, 친구와 약속한 숫자 규칙 (나머지) 에 맞춰 변환합니다.
비유: 마치 레고 블록을 뒤집어서 쌓듯이, 데이터를 뒤집어서 특수한 숫자 블록으로 바꾸는 과정입니다.

🔄 도착해서 어떻게 읽나요? (해독 과정)

친구가 이 우편물을 받으면 다음과 같이 읽습니다.

라벨 읽기: 먼저 "우편물 크기 라벨"을 보고, "아, 이 편지는 총 100 바이트구나"라고 알아냅니다.
상태 확인: 그다음 "상태 확인용 주머니"를 열어 기계의 초기 설정을 맞춥니다.
본문 읽기: 이제 100 바이트만큼만 숫자 블록을 하나씩 꺼내서 원래의 글자로 되돌립니다.
남은 것 무시: 만약 편지 뒤에 불필요한 숫자가 더 붙어있다면 (예: 실수로 붙은 숫자), "아, 내가 읽어야 할 100 바이트는 다 읽었으니 나머지는 무시하자"라고 하고 멈춥니다.

🌟 이 기술의 특별한 점 (왜 이 논문이 중요한가요?)

완벽한 정확성 (Formal Verification):
- 이 기계가 설계대로 작동한다는 것을 컴퓨터가 직접 수학적으로 증명했습니다. (Lean 4 라는 도구를 사용)
- 비유: 단순히 "우리가 테스트해봤으니 잘 작동해요"가 아니라, "수학 공식을 통해 이 기계가 절대 고장 나지 않는다는 것을 증명했어요"라고 말하는 것과 같습니다.
유연성 (Suffix Tolerance):
- 데이터 뒤에 불필요한 숫자가 붙어 있어도, 원래 데이터를 정확히 찾아냅니다.
- 비유: 편지 봉투에 불필요한 낙서가 있어도, 봉투 안의 편지 내용만 정확히 꺼낼 수 있는 마법의 봉투입니다.
빠른 속도:
- 컴퓨터가 데이터를 처리할 때 매우 빠릅니다. 특히 큰 파일을 다룰 때 기존 방식보다 훨씬 효율적입니다.

🛡️ 보안에 대한 오해 (중요!)

이 기술은 비밀을 감추는 자물쇠가 아닙니다.

비유: 이 기계는 편지를 특수한 숫자 언어로 번역하는 번역기일 뿐입니다. 번역된 숫자만으로는 내용을 알 수 없지만, 이 번역기 자체가 암호는 아닙니다.
이 번역된 숫자를 **진짜 암호 (암호화 알고리즘)**에 넣어야만 비로소 보안이 확보됩니다. 이 논문은 그 암호화 과정을 위한 '준비 단계'를 완벽하게 정리해 준 것입니다.

📝 한 줄 요약

**"어떤 데이터든, 친구와 약속한 '숫자 언어'로 빠르고 정확하게, 그리고 수학적으로 100% 보장되게 변환해주는 표준 번역기"**를 만들었습니다.

이 기술은 향후 더 안전한 암호 시스템, 데이터 암호화, 그리고 복잡한 수학 계산을 필요로 하는 미래 기술들의 기초가 될 것입니다.

1. 연구 배경 및 문제 정의 (Problem)

문제의 핵심: 링 매핑 (Ring-mapping) 암호 시스템 (예: $\mathbb{Z}_m$ 위의 대칭 암호, FHE, ZKP 등) 은 암호화/복호화 전에 메시지를 유한 링 (Finite Ring) 의 원소인 잔여 (Residue) 로 변환해야 합니다.
기존의 한계: 기존 연구들은 소규모 고정 심볼 테이블이나 수동으로 구축된 알파벳을 사용하여 메시지를 표현했으나, 이는 임의의 UTF-8 텍스트나 이진 데이터를 $\mathbb{Z}_m$ 으로 변환하는 일반적인 문제를 해결하지 못했습니다.
필요성: 암호학적 변환을 시작하기 전에 임의의 바이트 스트링을 $\mathbb{Z}_m$ 의 잔여 리스트로 변환하는 표준화 (Canonical) 된 계층이 필요합니다.

2. 방법론 (Methodology)

저자들은 Base- $m$ -len이라고 명명된 새로운 인코딩/디코딩 코덱 (Codec) 을 제안했습니다. 이는 Duda 가 제안한 rANS 기반 시스템을 변형하여 결정론적이고 자기 구분 (self-delimiting) 가능한 잔여 형식을 만듭니다.

핵심 구조 (Wire Format):
1. 길이 접두어 (Length Prefix): 바이트 스트링의 길이를 고정된 너비 ( $k$ ) 의 $m$ 진수 숫자로 인코딩합니다. ( $k$ 는 $m^k \ge 2^{64}$ 를 만족하는 최소 정수)
2. 상태 접두어 (State Prefix): 최종 페이로드 상태를 $k$ 개의 $m$ 진수 숫자로 인코딩합니다.
3. 페이로드 스트림 (Payload Stream): 입력 바이트를 역순으로 스캔하며 균일한 $m$ 진수 전환 (transduction) 을 통해 생성된 잔여 숫자 스트림입니다.
알고리즘 원리:
- 인코딩: 입력 바이트를 역순으로 처리하며, 상태 값이 임계값을 초과할 때마다 $m$ 진수 숫자를 방출합니다. 이는 rANS 의 정규화 (renormalization) 개념을 차용하되, 확률적 엔트로피 코딩이 아닌 결정론적 변환에 초점을 맞춥니다.
- 디코딩: 먼저 고정된 길이의 접두어에서 바이트 길이를 읽은 후, 해당 길이에 해당하는 페이로드 숫자만 소비하여 원본 바이트를 복원합니다.
- 특징: 디코딩은 선언된 길이만큼만 처리하므로, 뒤에 붙은 유효한 접미사 (suffix) 는 무시됩니다 (Suffix Tolerance).

3. 주요 기여 (Key Contributions)

표준 코덱 정의: 유한 링 프로토콜을 위한 모듈러스 파라미터화된 바이트 - 잔여 코덱을 정의하고, Base- $m$ -len wire 포맷을 제안했습니다.
정확성 보장:
- 지원되는 모듈러스 ( $m$ ) 와 $2^{64}$ 미만의 길이를 가진 모든 바이트 스트링에 대해 정확한 디코딩을 보장합니다.
- 고정된 너비의 헤더를 역으로 해석할 수 있으며, 유효한 접미사가 붙은 경우에도 원본을 정확히 복원합니다.
구현 및 형식적 검증 (Formal Verification):
- Rust 라이브러리: sym-adv-encoding 라이브러리를 공개하여 실제 성능을 검증했습니다.
- Lean 4 형식화: 추상 코덱의 명세를 Lean 4 로 작성하고 **기계 검증 (Machine-checked proofs)**을 수행했습니다. 이는 헤더 역변환, 페이로드 상태 경계 ( $< 2^{64}$ ), 스트림 수준의 왕복 정확성 (Roundtrip correctness) 등을 수학적으로 증명했습니다.

4. 평가 및 결과 (Results)

복잡도 및 비용:
- 인코딩/디코딩은 스트림 길이에 대해 선형 시간 ( $O(n)$ ) 을 소요합니다.
- 페이로드 비용: 모듈러스 $m$ 이 클수록 바이트당 필요한 잔여 숫자 (digits) 가 줄어듭니다 (예: $m=257$ 일 때 약 0.9993 개/바이트).
- 헤더 비용: 길이를 나타내는 고정 헤더 크기는 $2k$ 개의 숫자입니다. $m$ 이 커질수록 $k$ 가 감소하여 헤더 오버헤드가 줄어듭니다.
성능 (Native Performance):
- Apple M3 Pro 환경에서의 벤치마크 결과, 제안된 네이티브 구현은 전체 페이로드를 변환하는 기존 BigUint 방식보다 훨씬 빠릅니다.
- 예시: 1 KiB 데이터 인코딩 시, $m=65$ 에서 네이티브 구현은 163.6 MiB/s, BigUint 방식은 25.2 MiB/s 로 약 6 배 이상 빠른 성능을 보였습니다.
- $m=257$ 설정은 바이트당 약 1 개의 잔여 숫자를 생성하여 압축 효율이 높으면서도 길이 복구가 가능합니다.

5. 의의 및 결론 (Significance)

암호학적 역할: 이 코덱은 암호학 원시 (Primitive) 가 아니라 결정론적 직렬화 (Serialization) 계층으로 설계되었습니다. 이는 링 기반 암호 시스템 (Ring-based cryptosystems) 이 메시지를 전송하기 위한 표준적인 표현 계층을 제공합니다.
실용성: Lean 4 를 통한 형식적 검증은 프로토콜 구현의 신뢰성을 높이며, Rust 라이브러리는 실제 시스템 통합을 가능하게 합니다.
한계 및 주의사항:
- 인코딩 자체는 기밀성, 무결성, 인증을 제공하지 않습니다 (외부 암호 프로토콜이 필요함).
- 길이 정보가 노출되므로, 길이 숨기기가 필요한 경우 프로토콜 계층에서 패딩을 적용해야 합니다.
- Lean 검증은 추상 명세에 국한되므로, 실제 Rust 구현의 파서 경화 (hardening) 및 메모리 할당 제한은 구현자의 책임입니다.

요약하자면, 이 논문은 유한 링 암호 시스템에서 임의의 바이트 데이터를 안전하게 변환하기 위한 표준화되고 수학적으로 검증된 인코딩 계층을 제안하며, 높은 성능과 형식적 정확성을 동시에 확보했습니다.