# 이더리움 개인정보보호에 대한 양자역학적 위협
*초안 작성에 도움을 주신 Alex, Andy, Keewoo, Miha, Moven, Nico, Oskar, Sora, Thore, Vitalik, Yanis, Zoey 님께 감사드립니다. 본 게시글은 AI의 도움을 받아 조사 및 작성되었습니다.*
요약
수집 후 복호화하는 방식에 노출되는 장기적인 기밀성 표면의 경우, 개인정보 보호 마이그레이션은 인증 마이그레이션보다 시간적 제약이 더 큽니다. 미래에 공격자가 양자 컴퓨터를 사용하여 수집된 암호문을 복호화하는 것을 막을 방법은 없지만, 서명 위조는 하드 포크와 키 마이그레이션을 통해 부분적으로라도 해결할 수 있습니다(단, 상당한 모호성, 출처 파악 문제, 롤백 비용이 발생합니다). 업계에서는 PQ 키 교환을 먼저 광범위하게 도입했습니다(Chrome, iMessage, AWS, Cloudflare). PQ 인증은 특히 기본 공개 웹 PKI에서 아직 초기 단계입니다. 이더리움은 일부 표면(Go 1.24를 통한 TLS 기반 HTTPS/JSON-RPC)에 대해 PQ 전송 암호화를 계승하지만, 스텔스 주소, zkID, 기밀 거래와 같이 오프코드나 사전 컴파일에서 기본적으로 지원되는 것이 아니라 EVM 위에 구축된 암호화 프로토콜인 애플리케이션 계층 개인정보 보호는 이더리움 관련 작업이 필요합니다.
| # | 문제 | 상태 |
|—|---------|--------|
| 1 | PQ Stealth 주소 지정 확장성 | 활발한 연구 진행 중; 통화 데이터 증가 및 OMR 메모리 비용 문제가 남아 있음 |
| 2 | zkTLS용 MPC/2PC 내 ML-KEM | 실질적인 타임아웃 내에 프로토콜 없음 |
| 3 | zkID 가져오기를 위한 NIST PQ 서명 산술화 | 131배 차이 vs. 양자 전 SNARK |
| 4 | zkID 가져오기를 위한 PQ 자격 증명 검증 비용 | 131배 SNARK 격차; [EIP-8051]( EIP-8051: ML-DSA 서명 검증을 위한 사전 컴파일 )/[8052]( EIP-8052: Falcon 지원을 위한 사전 컴파일 )(초안) 활성화 인프라로 제안됨 |
| 5 | 지정된 감사자에게 검증된 암호화 방식 | 탐지 및 표시만으로도 충분할 수 있음; 프로토콜 강제 모델은 미해결 |
--
## 소개
블록체인에 대한 양자 컴퓨팅 이후의 위협은 널리 인식되어 왔으며, 크게 **진위성** 과 **개인정보 보호** 의 두 가지 범주로 나눌 수 있습니다. 진위성은 디지털 서명 및 그보다 더 광범위한 형태인 영지식 증명의 위조를 의미합니다. 개인정보 보호는 온체인 및 오프체인 데이터의 기밀성, 사용자 및 사용자 활동의 익명성 및 연결 불가능성을 의미합니다.
진위성 위협을 완화하기 위해 상당한 노력이 기울여졌습니다. 2024년 8월, NIST는 최초의 세 가지 양자 후 암호화( PQC) 표준인 ML-KEM(FIPS 203), ML-DSA(FIPS 204), SLH-DSA ( FIPS 205)를 최종 확정했습니다. 2026년 초, 이더리움 재단은 프로토콜 로드맵에서 PQ 보안을 강화하고 전용 공개 PQ 워크스트림을 조직하기 시작했습니다.
이에 비해, 개인정보 침해 위협은 특히 '지금 수집하고 나중에 복호화(HNDL)' 전략 때문에 더욱 시급합니다. HNDL 전략이란 암호화된 데이터를 지금 확보하여 충분히 강력한 양자 컴퓨터가 암호를 해독할 때까지 비축해 두는 것을 의미합니다. 기존 네트워크에서는 공격자가 암호문을 수집하기 위해 적극적으로 트래픽을 도청해야 하지만, 블록체인은 공개된 추가 전용 원장입니다. 애플리케이션 계층에서 암호화된 데이터(온체인 암호문, 스텔스 주소 공지, 암호화된 메모, 보기 키)는 이미 모든 사람이 영구적으로 볼 수 있습니다. 가로채기 단계가 필요 없으며, 블록체인 자체가 아카이브 역할을 합니다. 오늘 게시된 개인정보 관련 암호문은 기본적으로 수집 가능하며 원장의 수명 동안 노출된 상태로 유지됩니다. 인증 실패는 비상 조정을 통해 적어도 부분적으로 복구할 수 있지만(상당한 모호성과 롤백 비용이 발생함( 양자 비상 상황에서 대부분의 사용자 자금을 보호하기 위한 하드 포크 방법 )), 개인정보 침해는 돌이킬 수 없습니다. 미래의 양자 공격자가 암호문을 해독하면 어떤 프로토콜 업그레이드로도 다시 암호화할 수 없습니다. 업계는 이러한 비대칭성을 인식하고 있습니다. Chrome, Apple iMessage(PQ3), AWS 및 Cloudflare는 이미 양자 컴퓨팅(PQ) 키 교환을 제공하고 있지만, 기본 공개 웹 PKI에서 PQ 인증은 아직 대부분 배포되지 않았습니다. 키 교환은 HNDL(Hardware -in-the-Laws) 공격으로부터 보호하지만 인증은 실시간 위조 공격에만 저항하면 되기 때문입니다([ethresear.ch PQ tasklist](양자 후 ETH 작업 목록 ), [F5 Labs]( 웹에서의 양자 후 암호화(PQC) 현황 | F5 Labs )).
## 이더리움이 무료로 얻는 것과 그렇지 않은 것
모든 PQ 개인정보 보호 마이그레이션이 이더리움 관련 연구를 필요로 하는 것은 아닙니다. 업계 전반의 암호화 마이그레이션은 이미 일부 전송 표면을 포괄하고 있습니다. Geth는 Go로 작성되었으며, Go 1.24는 기본적으로 하이브리드 PQ TLS(X25519MLKEM768)를 제공합니다. [Kubernetes v1.33]( Post-Quantum Cryptography in Kubernetes | Kubernetes )은 Go를 업그레이드하는 것만으로 PQ 키 교환이 자동으로 이루어졌습니다. HTTPS JSON-RPC 엔드포인트, 브라우저-dApp 연결, 그리고 Go의 TLS 스택을 통해 TLS 1.3을 사용하는 모든 libp2p 배포는 이더리움 프로토콜 변경 없이 PQ 암호화 전송을 상속받습니다. (이더리움의 네이티브 DevP2P/RLPx 스택은 TLS가 아닌 TCP에서 실행되므로 자동으로 이점을 얻지 못하며, libp2p는 보안 채널 옵션으로 Noise도 지원하는데, 이를 위해서는 별도의 PQ 업그레이드가 필요합니다.)
이더리움이 계승 할 수 없는 것은 **애플리케이션 계층** 개인정보 보호입니다. 즉, 오프코드나 사전 컴파일을 통해 기본적으로 지원되는 것이 아니라 EVM 위에 구축된 암호화 프로토콜이 여기에 해당합니다. 온체인 암호문, 노트 검색(키 보기)을 위한 ECDH 기반 키 파생, ECDH 기반 스텔스 주소 생성, ZK 검증 암호화(규정을 준수하는 보호 전송에 사용되는 특정 공개 키로 암호문이 올바르게 생성되었음을 ZK 회로 내에서 증명), 접근 패턴 숨기기(관찰자가 사용자가 어떤 온체인 기록을 읽거나 쓰는지, 예를 들어 어떤 노트를 스캔하거나 사용하는지 알 수 없도록 방지)는 모두 블록체인 고유의 문제이며, 업계에서 이에 상응하는 기술이 없습니다. 이 글의 나머지 부분에서는 이러한 격차에 대해 자세히 살펴보겠습니다.
## 익명성 및 연결 불가능성
스텔스 주소, zkID, zkTLS와 같은 기술은 익명성과 연결 불가능성을 제공하는 데 있어 우수한 사용자 경험을 제공하며, 오늘날 대부분의 사용 사례에 충분합니다. 문제는 이러한 기능이 양자 컴퓨팅 이후에도 유효한지 여부입니다.
### 은밀한 주소
스텔스 주소는 양자 컴퓨터로 해독 가능한 타원 곡선 디피-헬만 키 교환(ECDHKE)에 의존합니다. ECDHKE는 오프체인에서 ML-KEM으로 대체할 수 있지만, ML-KEM-768 암호문은 1,088바이트로 압축된 ECDH 포인트보다 33배 더 큽니다. EIP-4844 블롭은 약 18일 후에 삭제되므로, 이를 스텔스 주소 암호문에 사용하려면 수신자가 해당 기간 내에 암호문을 수신해야 합니다. 이는 현재의 스텔스 주소 설계에는 없는 활성성 요건을 추가합니다.
콜데이터에 부담을 주지 않는 잠재적 해결책은 오프체인 사이드카로서의 OMR(Oblivious Message Retrieval)입니다. 이는 온체인 스텔스 주소에는 없는 데이터 가용성 신뢰 가정을 도입합니다. 즉, 수신자는 암호문을 저장하고 제공하는 사이드카 운영자에 의존합니다. 운영자가 오프라인 상태가 되거나 데이터를 제공하지 않으면 수신자는 자신의 메모를 스캔할 수 없습니다. ML-KEM은 ECDH보다 OMR과 구조적으로 더 호환됩니다. Module-LWE 기반 스텔스 주소 프로토콜( Post-Quantum Stealth Address Protocols )은 스캔 시간에서 기존 ECPDKSAP보다 약 66.8% 우수한 성능을 보이며, 하이브리드 프로토콜인 "Efficient Curvy" 프로토콜( [2504.06744] More Efficient Stealth Address Protocol )은 약 3배 빠른 스캔 속도를 달성합니다. OMR 자체는 초기 버전( Oblivious Message Retrieval )에서 PerfOMR( PerfOMR: 통신 및 계산량을 줄인 Oblivious Message Retrieval )(메시지당 약 40ms, 키 크기 235배 축소) 및 HomeRun( HomeRun: 제한 없는 고효율 Oblivious Message Retrieval )(실행 시간 3,830배 단축)으로 개선되었습니다. 그러나 OMR의 메모리 사용량(약 20GB 이상)은 경량 인프라에 적용하기에는 여전히 비효율적입니다.
### zkTLS
TLS 서버가 하이브리드 PQ 키 교환(X25519MLKEM768)으로 마이그레이션됨에 따라 zkTLS도 이를 따라야 합니다. 사용자와 Notary 간의 MPC/2PC는 세션 키를 어느 쪽에도 노출하지 않고 핸드셰이크의 X25519 및 ML-KEM-768 부분을 모두 공동으로 수행해야 합니다. TLSNotary와 같은 현재 zkTLS 프로토콜은 TLS 1.2에서 작동합니다. X25519MLKEM768 협상이 이루어지는 TLS 1.3 지원은 로드맵에 있지만 아직 출시되지 않았습니다. TLS 1.3 MPC/2PC 내의 기존 X25519 키 교환조차도 상용 zkTLS 구현이 존재하지 않습니다. 일반적인 MPC 프레임워크에서 NTT 다항식 연산 비용이 많이 드는 ML-KEM-768을 추가하면 이러한 어려움은 더욱 커집니다. 구체적인 구현을 위해서는 일반적인 프레임워크를 사용하는 대신 ML-KEM의 대수적 구조를 고려하여 MPC를 공동 설계해야 할 수도 있습니다.
### zkID
zkID는 사용자가 자신의 기기에 있는 ZK 회로 내부에서 서명을 정확하게 검증했음을 증명한 다음, 자격 증명이 아닌 증명만 검증자에게 제출하도록 요구합니다. 완전한 양자 컴퓨팅(PQ) zkID는 두 단계의 양자 후 보안을 필요로 합니다. (1) 서명 체계 자체가 양자 컴퓨팅 환경에서 안전해야 하며(양자 공격자가 자격 증명을 위조할 수 없도록), (2) ZK 증명을 생성하는 증명 시스템 또한 양자 컴퓨팅 환경에서 안전해야 합니다(양자 공격자가 증명을 위조할 수 없도록). 실제 배포를 위한 핵심 질문은 양자 컴퓨팅 증명 시스템 내부에서 양자 컴퓨팅 서명 검증을 얼마나 저렴하게 연산화할 수 있는가입니다.
해시 기반 방식(XMSS, Winternitz, SPHINCS+)은 전적으로 해시 평가로 구성됩니다. 내부 해시(SHA-256: 약 25,000개 이상의 R1CS 제약 조건)를 Poseidon과 같은 ZK 네이티브 대안(약점 약 240개 - [ZKPlus 벤치마크]( ZoKrates의 해싱 알고리즘 벤치마크 - ZKPlus ), [Guo 외]( [2409.01976] EVM 호환 블록체인을 위한 ZK 친화적 해시 함수 및 SNARK 증명 시스템 벤치마킹 ) 참조)으로 대체하면 검증 회로가 약 100배 축소됩니다. 이는 해시 기반 서명이 해시 함수에 대해 *일반적* 이기 때문입니다. 즉, 특정 대수 연산이 아닌 충돌 및 역상 저항성만 필요합니다. 서명은 PQ 보안을 유지하면서 ZK에서 증명 비용이 저렴해집니다. 격자 기반 서명(ML-DSA, FN-DSA)은 이러한 속성이 부족합니다. 즉, NTT 다항식 연산은 연산 비용이 많이 들기 때문에 ZK 회로 내에서 정확성을 증명하는 것(즉, 사용자가 자격 증명을 공개하지 않고 영지식 방식으로 "이 서명을 검증했습니다"라고 증명하는 것)보다는 사전 컴파일을 통한 온체인 직접 검증에 더 적합합니다([EIP-8051]( EIP-8051: ML-DSA 서명 검증을 위한 사전 컴파일 ), [EIP-8052]( EIP-8052: Falcon 지원을 위한 사전 컴파일 )).
#### 이더리움 ID 내보내기
이 문제는 해결 가능합니다. 생태계는 포세이돈 내부 구조를 활용하여 이더리움 네이티브 해시 기반 PQ 서명을 설계할 수 있으며, 사용자는 자신의 기기에 설치된 STARK 내부에서 검증을 수행할 수 있습니다. 중요한 점은 이것이 이더리움에 특화된 맞춤형 설계이며, 표준화된 SLH-DSA(FIPS 205는 SHAKE/SHA2 기반 파라미터 세트만 명시)를 준수하지 않는다는 것입니다. 따라서 외부 PKI와 상호 운용되지 않으며, NIST 승인 알고리즘을 요구하는 규정 준수 프레임워크를 충족하지 못합니다. 이 접근 방식은 서명자와 검증자 모두를 생태계가 제어할 수 있다는 점에서 매력적이지만, 표준을 준수하는 방식이 아니라 이더리움 고유의 설계 방식으로 이해해야 합니다.
#### 실제 ID 가져오기
이 문제는 어렵습니다. 발급자는 포세이돈이 아닌 표준화된 ML-DSA 또는 SLH-DSA와 SHA-256/SHAKE를 사용할 것이기 때문입니다. SHA-256/SHAKE 및 (ML-DSA의 경우) 래티스 NTT를 포함한 전체 검증 과정을 그대로 산술 연산해야 합니다. 더 근본적인 차이점은 다음과 같습니다. 실제 서명 체계는 일반적으로 빠른 서명(서버가 여러 자격 증명에 서명)에 최적화되어 있지만, 검증 비용(단일 클라이언트가 검증)은 상대적으로 높습니다. 이는 검증이 온체인 또는 ZK 회로 내에서 이루어지고 비용 효율성이 중요한 블록체인 환경과는 정반대입니다. 이러한 설계 비대칭성 때문에 실제 자격 증명을 가져오는 데 본질적으로 비용이 많이 드는 것입니다. Wu 등이 개발한 격자 기반 지정 검증자 zkSNARK( https://www.cs.utexas.edu/~dwu4/papers/LatticeDVSNARKs.pdf )는 약 16KB 크기의 증명을 생성하는데, 이는 Aurora보다 10.3배 작지만 Groth16보다는 131배 더 큽니다. 지정 검증자 설정은 증명이 비밀 키를 보유한 특정 검증자만 확인할 수 있고 온체인에서 공개적으로 검증되지 않는다는 것을 의미하며, 이는 블록체인 사용 사례에 추가적인 제약 조건으로 작용합니다. STARK는 가장 실용적인 양자 컴퓨팅(PQ) 방식이지만(충돌 방지 해시만 사용하고 격자나 페어링 가정이 필요 없음), Groth16과 같은 양자 컴퓨팅 이전 시대의 SNARK보다 훨씬 큰 증명을 생성합니다. 남은 과제로는 131배에 달하는 PQ/양자 컴퓨팅 이전 시대 SNARK 간의 격차 해소, NIST PQ 서명 검증의 효율적인 연산화, 그리고 자격 증명 검증을 위한 상용 PQ SNARK 개발 등이 있습니다.
## 기밀 유지
기밀성, 즉 거래 금액, 잔액 및 계약 상태를 숨기는 것은 Aztec(Ignition Chain은 2025년 11월에 출시되었지만 메인넷 1단계에서는 아직 사용자 거래가 실행되지 않음)과 같은 개인 정보 보호에 초점을 맞춘 이더 리움 L2 인프라와 Railgun 및 Privacy Pools와 같은 애플리케이션 계층 도구의 핵심 기능입니다. 상태 커밋먼트(머클 트리, 노트 해시)는 Poseidon과 같은 PQ 안전 해시를 사용할 수 있지만, 취약점은 *암호화* 계층에 있습니다. 두 가지 별개의 하위 문제가 발생합니다.
- **노트 검색 및 키 교환** : Aztec과 같은 시스템에서 키를 확인하는 것은 EC 기반 키 파생에 의존합니다. 발신자는 수신자의 공개 키로 암호화하여 수신자가 자신에게 온 노트를 식별할 수 있도록 합니다. ML-KEM은 여기서 ECDHKE를 대체할 수 있습니다(스텔스 주소와 동일한 33배 암호문 크기 증가, 동일한 OMR 기반 완화 경로). 하지만 이 키 교환은 ZK 회로 *외부*에서 발생하며 회로 내 증명이 필요하지 않습니다.
- **지정된 감사자/규정 준수 수신자에게 검증된 암호화** : 규정을 준수하는 차폐 전송에서 선택적 공개를 위해 발신자는 지정된 수신자의 알려진 공개 키로 직접 암호화하고 ZK 회로 내에서 정확성을 검증합니다. 수신자는 규제 기관, 기관 규정 준수 부서, DAO 재무 감사자 또는 프로토콜에서 지정하는 모든 당사자가 될 수 있습니다. 양자 컴퓨팅 이전에는 ElGamal이 이를 저렴하게 구현했습니다(단일 EC 스칼라 곱셈, ZK 친화적). 양자 컴퓨팅 이후에는 발신자가 격자 기반 PKE(예: Kyber.CPAPKE 또는 일반 LWE Regev 암호화)를 사용합니다. 대부분의 실제 설계에서 발신자는 회로 *외부* 에서 격자 PKE를 수행하고 대칭 키를 생성한 다음, Poseidon의 스펀지 모드(순열당 약 240개의 제약 조건, 양자 컴퓨팅 안전성, Aztec에서 이미 노트 암호화에 사용됨)를 사용하여 회로 *내부*에서 대칭 암호화의 정확성을 검증할 수 있습니다. 송신자가 속임수를 쓰면(더미 키로 암호화하면), 감사자는 잘못된 데이터를 얻고 해당 거래에 플래그를 지정합니다. 이는 탐지 및 플래그 지정 모델입니다. 지정된 수신자가 복호화할 수 있음을 프로토콜이 *보장하는* 더 강력한 모델은 ZK 회로 내에서 격자 PKE의 정확성을 증명해야 하는데, 이는 필드 불일치(q=3,329에 대한 격자 연산과 BN254와 같은 증명 시스템 필드)로 인해 여전히 비용이 많이 들지만, 완전한 ML-KEM보다는 간단합니다. 약한 탐지 및 플래그 지정 모델이 충분한지는 암호학적 문제일 뿐만 아니라 정책적 문제이기도 합니다.
## 클라이언트 측 증명을 의존성으로 사용
zkID와 기밀성 모두 사용자가 *자신의 장치에서* ZK 증명을 생성해야 합니다. 서버에 위임하면 증명이 보호해야 하는 매우 개인적인 입력값이 유출됩니다. GPU 가속은 모든 증명 백엔드에 도움이 되지만, PQ 증명 시스템은 다음 두 가지 이유로 특히 큰 이점을 얻을 수 있습니다. (1) 현재 CPU 성능으로 인해 클라이언트 측에서 PQ 증명 생성이 불가능해지므로 양자 이전 시스템보다 GPU 가속에 대한 의존성이 더 높아졌습니다. (2) PQ 기본 요소(소수 필드에 대한 NTT 기반 다항식 연산)는 순차적인 캐리 체인 의존성으로 인해 [이론적 가속 상한]( Metal MSM v2: Apple GPU에서 MSM 가속 탐색 | PSE )에 직면하는 그룹 기반 타원 곡선 연산보다 GPU 아키텍처와 더 자연스럽게 부합합니다. NTT는 STARK 증명과 격자 연산 전반에 걸쳐 공유되는 기본 요소 이며, 소규모 필드 PQ 방식(M31, q = 3,329)은 모바일 GPU에서 BN254의 1 Gops/s 미만에 비해 100 Gops/s 이상의 처리량을 달성합니다( ZK를 위한 클라이언트 측 GPU 가속: 일상적인 이더리움 개인 정보 보호를 위한 경로 | PSE ). 따라서 순수 처리량은 충분합니다.
GPU 가속은 이더리움 네이티브 ID 경로(STARK에서 검증된 포세이돈 내부 해시 기반 서명)와 실제 ID 가져오기 경로(SNARK에서 검증된 NIST PQ 서명) 모두에 적용됩니다. 하지만 이더리움 네이티브 경로는 클라이언트 측 개인정보 보호를 훨씬 쉽게 달성할 수 있는 방법을 제공합니다. 서명 체계를 직접 제어함으로써, 생태계는 외부에서 부과된 알고리즘을 계산하는 대신 처음부터 PQ 안전성과 GPU 친화성을 모두 갖춘 기본 요소를 선택할 수 있습니다. 따라서 이더리움 ID 설계 공간을 우선시하는 것은 실용적인 클라이언트 측 검증 전략이기도 합니다.
클라이언트 측 GPU 증명은 양자 후 프라이버시에만 국한된 것이 아니라 검열 저항성, 유효성 증명 등 더 광범위한 이더리움 인프라 과제입니다. 여기서는 이를 필수적인 요소로 언급합니다. 양자 후 프라이버시는 GPU 증명 없이는 구현될 수 없습니다. 하지만 [GPU ZK 생태계]( GitHub - zkmopro/awesome-client-side-gpu: 클라이언트 측 GPU 생태계 관련 유용한 기능들 · GitHub )와 [양자 후 프라이버시 로드맵]( ZK용 클라이언트 측 GPU 가속: 일상적인 이더리움 프라이버시를 향한 길 | PSE )은 일반적인 증명 인프라 구축 노력으로 접근하는 것이 가장 적절합니다.
## 단기 로드맵 권장 사항
위에서 언급한 문제들은 성숙도 수준이 각기 다릅니다. 일부는 PQ 대체 솔루션이 알려져 구현 단계로 넘어갈 수 있지만, 다른 일부는 여전히 연구가 필요한 상태입니다. 유용한 로드맵은 출시 가능한 것과 획기적인 해결책이 필요한 것을 구분하고, 기다리는 동안 불필요한 위험 부담을 줄이는 데 도움이 됩니다.
**설계 원칙: 새로운 고전적 프라이버시 부채 금지.** 기밀성 부채는 되돌릴 수 없습니다 . 키 순환이나 비상 포크를 통해 부분적으로 해결할 수 있는 인증성 부채와는 다릅니다. 장기간 유지되는 ECDH 기반 암호문을 저장하는 모든 새로운 프라이버시 프로토콜은 HNDL 노출 기간을 영구적으로 연장합니다. 새로운 설계는 단일 세션을 넘어 지속되는 모든 기밀성 표면에 대해 기본적으로 PQ 키 교환을 사용해야 하며, PQ 대안이 아직 실용적이지 않은 경우에는 명시적으로 문서화된 예외를 두어야 합니다.
1. **개인정보 보호 허니팟을 정량화하세요.** 양자 허니팟은 충분히 강력한 양자 컴퓨터가 도착했을 때 추출할 수 있는 총 가치를 의미합니다. 인증 허니팟(양자 취약점이 있는 키를 사용하는 계정의 총 가치)은 크지만 한계가 있습니다. 커뮤니티는 [긴급 하드 포크]( 양자 비상 상황에서 대부분의 사용자 자금을 보호하기 위한 하드 포크 방법 )를 통해 노출된 계정을 동결하고 PQ 서명으로 마이그레이션할 수 있습니다.
프라이버시 허니팟은 구조적으로 다르며 이 글의 핵심 주제입니다. 이는 블록체인 최초 생성 이후 온체인에 누적된 암호화 데이터로, 블록이 생성될 때마다 증가합니다. 어떤 포크도 과거의 암호문을 다시 암호화할 수 없습니다. 각 노출 유형은 독립적으로 누적됩니다.
- **보호된 거래 및 암호화된 메모:** 양자 컴퓨팅 공격자는 보호된 풀에 예치된 모든 잔액, 이체 금액 및 계약 상태를 소급하여 해독할 수 있습니다. 즉, 모든 참가자의 전체 금융 내역을 확인할 수 있습니다.
- **은밀 주소 연결:** ECDH에서 파생된 은밀 주소는 수신자를 추적할 수 있게 되어, 은밀 주소 체계가 제공하도록 설계된 연결 불가능성이 무너집니다.
- **선별적으로 공개된 자격 증명:** 지정된 감사인을 위해 공개된 규정 준수 보호 정보가 양자 컴퓨터를 가진 사람이라면 누구나 읽을 수 있게 되어, KYC 데이터, 기관 지분, 신원 연결 정보가 의도치 않은 당사자에게 노출될 수 있습니다.
- **키 보기 및 노트 검색:** 노트 스캔을 위한 EC 기반 키 파생을 통해 어떤 노트가 어떤 수신자에게 속하는지 확인할 수 있으며, 금액이 대칭 암호화로 숨겨져 있더라도 전체 거래 그래프의 익명성을 해제할 수 있습니다.
사회적 영향은 단순한 절도와는 다릅니다. 정치 기부자의 신원 비공개 해제, 개인 및 기관의 금융 프라이버시 침해, 규정 준수 관계 노출 등이 그 예입니다. 진위 여부를 확인하는 함정은 제거 후 차단할 수 있지만, 개인정보를 노리는 함정은 더 이상 커지지 않도록 막을 수밖에 없습니다. 차단할 때마다 돌이킬 수 없는 노출이 발생하기 때문입니다.
*성과물:* 개인정보보호 허니팟에 대한 정량화되고 정기적으로 업데이트되는 추정치(위험에 처한 데이터 범주, 범주별 증가율 및 개선 일정 포함)를 제공하여 거버넌스 부서가 마이그레이션의 시급성을 판단할 수 있는 구체적인 근거를 제시합니다. 진위성 허니팟에 대한 유사한 추정치(위험 가치, 포크 준비 상태)는 유용한 맥락을 제공하지만 이미 더 잘 이해되고 있습니다.
2. **기밀성 표면 레지스트리를 구축합니다.** 암호문이나 키 자료가 단일 세션보다 오래 지속되는 모든 개인정보 보호 표면을 열거합니다. 여기에는 은밀한 공지, 보기 키, 암호화된 메모, 애플리케이션 계층 암호문, 자격 증명 가져오기, 선택적 정보 공개 흐름 등이 포함됩니다. 각 표면에 저장 수명, 암호화 가정, PQ 교체 가능 여부를 태그로 지정합니다. 결과물은 팀이 마이그레이션 우선순위를 정하는 데 활용할 수 있는 구조화된 레지스트리이며, 서술적인 위협 모델이 아닙니다.
레지스트리를 최신 상태로 유지하기 위해 기밀성 표면을 도입하거나 이에 의존하는 새로운 EIP 및 프로토콜 사양에는 기존의 보안 고려 사항 요구 사항과 유사한 **PQ 위협 모델 섹션**이 포함되어야 합니다. 이 섹션에서는 양자 컴퓨팅에 취약한 가정, HNDL에 노출된 데이터 및 마이그레이션 경로를 식별해야 합니다. 이를 통해 PQ 준비 상태를 사후 감사에서 영구적인 설계 제약 조건으로 전환할 수 있습니다.
3. **처리 가능한 표면에 대한 참조 라이브러리 및 벤치마크를 배포합니다.** 두 개의 표면에 대해 알려진 PQ 기본 요소가 있으므로 이제 구현 단계로 넘어갈 수 있습니다.
- *ML-KEM 노트 검색:* 암호문 생성 및 스캔, 지갑/인덱서 인터페이스, OMR 검색 사이드카.
- *이더리움 네이티브 zkID:* STARK 검증 회로를 사용하는 포세이돈 내부 해시 기반 PQ 서명으로, 클라이언트 측 증명 시간 및 증명 크기 측면에서 벤치마킹되었습니다.
목표는 공통 기준선을 구축하는 것이지, 실제 운영 환경에 바로 적용하는 것이 아닙니다. 이상적으로는 벤치마크만으로는 파악할 수 없는 통합 문제를 발견하기 위해 최소한 하나의 개인정보 보호 중심 L2 또는 애플리케이션 스택을 대상으로 엔드투엔드 검증을 거쳐야 합니다.
4. **연구 진행을 방해하지 않는 연구 트랙으로 미해결 문제를 범위로 설정하십시오.** 세 가지 중요한 영역이 있지만 아직 해결되지 않았습니다. PQ 호환 zkTLS(ML-KEM 핸드셰이크를 통한 MPC/2PC), 실제 환경에서의 zkID 가져오기(NIST PQ 서명 검증의 산술 연산), 그리고 지정된 감사자를 위한 프로토콜 기반 검증된 정확성 암호화입니다. 이러한 영역에 대한 구체적인 프로토콜은 아직 존재하지 않습니다. 이러한 문제에 자금을 지원하고 진행 상황을 추적하되, 레지스트리, 참조 라이브러리 또는 위의 설계 원칙에 대한 진행을 방해하지 마십시오.
--
*피드백을 환영합니다. 특히 개인정보 보호 허니팟 프레임워크, 실행 가능성 평가, 그리고 저희가 놓쳤을 수 있는 PQ 개인정보 보호 관련 사항에 대한 의견을 기다립니다.*
