UBMS 양자내성암호 기술 보고서

Full-Stack Post-Quantum Cryptography Layer 1

작성자: 한혁진 (bokkamsun@gmail.com)
작성일: 2026년 8월 27일

본 보고서에 대하여

UBMS의 양자내성암호(PQC, Post-Quantum Cryptography) 적용에 대한 외부 기술 질의가 있어, 개발자가 직접 소스코드를 열어 확인한 사실만으로 회신하는 문서. 모든 서술은 실제 코드에서 확인된 것이며, 추정이나 계획은 계획이라고 명시한다.

UBMS는 현재 출시 전 가운영 단계. 가운영 환경에서 실제 데이터를 축적하며 설계를 다듬고 코드를 개선하는 중이다. 본 보고서가 다루는 양자내성 전환은 이 가운영 체인 위에서 실제로 수행되고 완료된 작업이다.

1. 요약

UBMS는 전 계층이 양자내성암호로 동작하는 풀스택 PQC Layer 1 블록체인. 더 중요한 것은 도달 경로다. 백지에서 출발한 신규 체인이 아니라, 운영 중이던 체인의 암호체계를 하드포크(hard fork, 블록체인 규칙의 전면 교체)로 전량 교체했다. 2026년 3월 전환 예고 후 6개월 만이다. 기존 지갑 자산은 전용 이전 체계로 대부분 이전을 마쳤고, 이전 경로는 체인 수명주기 동안 상시 개방된다. 운영 중인 블록체인에서 구 암호를 전량 제거하고 자산 이전까지 진행한 확인된 사례를 찾지 못했다.

전환이 끝난 체인에는 계정 주소 체계부터 트랜잭션 서명, 블록 서명, 합의 투표, 노드 간 통신 암호까지 고전 공개키 암호(RSA, ECDSA, EdDSA 계열)가 어디에도 없다.

2. 왜 풀스택 PQC가 기준인가

양자컴퓨터가 충분히 발전하면 쇼어 알고리즘(Shor algorithm, 양자컴퓨터용 소인수분해 계산법)으로 현행 공개키 암호가 해독된다는 것이 학계의 정설. 더 심각한 것은 수집 후 해독(harvest now decrypt later) 공격이다. 공격자가 오늘 공개키와 서명을 수집해 두면, 양자컴퓨터가 완성되는 순간 과거의 모든 자산이 소급해 노출된다. 모든 기록이 영구 공개되는 블록체인은 이 위협에 가장 취약한 분야다.

위협은 이미 이론을 벗어나 실험 단계다. 2026년 4월, 비트코인이 쓰는 것과 같은 계열의 타원곡선을 15비트로 축소한 시험용 키가 공개된 IBM(아이비엠) 양자컴퓨터에서 약 45분 만에 해독되어 해독 상금이 지급되는 사건이 있었다. 실운용 256비트 키와의 격차는 아직 크지만, 해독 가능한 규모가 해마다 커지고 있다는 사실 자체가 기존 암호 기반 블록체인들의 시한을 앞당기고 있다. NIST(미국 국립표준기술연구소)는 2024년 8월 서명 표준 FIPS 204(ML-DSA)와 키교환 표준 FIPS 203(ML-KEM)을 최종 확정했다. 전환은 선택이 아니라 시한이 정해진 과제가 됐다.

2.1 세계 주요 프로젝트의 대응 세 갈래

어느 갈래에도 완주는 없다. UBMS는 이 세 갈래 어디에도 속하지 않는 네 번째 경우다. 운영 체인을 하드포크로 전환하고 구 암호를 전량 제거했으며, 자산 이전까지 병행하고 있다.

2.2 부분 PQC의 네 가지 유형

블록체인의 양자 취약점은 잔존 지점이 하나만 있어도 전체가 무너진다. 특정 프로젝트를 지칭하지 않고, 시장에서 관찰되는 과장 유형을 구조로 분류한다. 해외 분석들이 문서화한 실태로는 일부 계층 적용을 전체 적용처럼 알린 사례, 양자내성 주장을 내부 개발자가 스스로 철회한 사례, 이더리움 소스를 복제한 채 양자내성 명칭만 앞세운 사례가 있다.

공격자는 전체가 아니라 가장 약한 고리 하나만 뚫으면 된다. 지갑 서명만 교체하고 블록 서명이나 통신 계층에 구 암호가 남으면 그 지점으로 자산과 합의가 무너진다. PQC를 지원하는 체인과 PQC로 재건된 체인의 차이가 여기서 갈린다.

2.3 계층별 판별표

계층별 적용 비교

2.4 전환 완주 기록

UBMS의 전환은 문서가 아니라 이력이다.

전환 타임라인

3. 알고리즘 명세

3.1 채택 알고리즘

파라미터 선택에 주목할 필요가 있다. FIPS 204는 ML-DSA-44(카테고리 2), ML-DSA-65(카테고리 3), ML-DSA-87(카테고리 5)의 세 파라미터를 정의한다. 서명과 키가 커지는 부담 때문에 대부분의 적용 사례는 하위 파라미터를 택한다. UBMS는 서명 4,627바이트라는 비용을 감수하고 서명과 키교환 모두 최상위 카테고리 5를 채택했다. AES-256과 동급의 장기 보안 마진을 서명 계층에도 확보한다는 설계 판단.

알고리즘 계보도 명확하다. ML-DSA는 CRYSTALS-Dilithium(크리스탈 딜리시움)이라는 이름으로 10년 이상 국제 학계의 공개 검증을 거쳐 NIST 표준이 된 격자 기반 알고리즘이며, 표준 확정 이후 핵심 알고리즘이 깨진 사례가 없다. NSA(미국 국가안보국)의 차세대 국가 암호체계 CNSA 2.0 역시 ML-DSA 계열을 채택했다. UBMS가 쓰는 것은 유행하는 이름이 아니라, 국가 기밀 체계가 선택한 표준의 최상위 파라미터다.

3.2 키와 서명 크기

이 크기들은 감출 수 없는 물리량이다. 어떤 프로젝트가 PQC 적용을 주장하면서 트랜잭션 크기가 고전 체인과 동일하다면, 서명이 실제로는 PQC가 아니라는 뜻이다. UBMS는 이 비용을 직렬화 계층과 블록 구조 설계 단계부터 반영했다. 처리 속도 실측치는 가운영 측정을 거쳐 출시 문서에 포함할 계획이다.

4. 암호 구현체와 상호운용성

UBMS의 원칙은 명확하다. 암호 원시(primitive)는 검증된 표준 구현에 위임하고, UBMS는 그 위의 프로토콜 계층만 소유한다.

• ML-DSA-87, ML-KEM-1024 연산은 전부 OpenSSL 3.5의 FIPS 204/203 표준 provider를 EVP(고수준 암호 인터페이스) API로 호출한다. 키 생성은 EVP_PKEY_Q_keygen(NULL, NULL, "ML-DSA-87"), 캡슐화는 EVP_PKEY_encapsulate 계열
• 규격 정합의 디테일까지 지킨다. ML-DSA는 알고리즘 내부에 메시지 해시 과정을 포함하므로, 외부에서 선해시하는 EVP_DigestSign 경로가 아니라 sign_message_init 경로를 쓴다. 소스 주석에 이 사유가 남아 있다
• 키 직렬화는 PEM(텍스트 키 포맷)을 배제하고 FIPS 규격의 raw 바이트를 그대로 hex로 다룬다. 파싱 계층의 모호성을 없애기 위한 결정

이 구조가 흔한 검증 질문 하나에 대한 답이 된다. 독립적인 표준 구현체와 상호운용되는가. UBMS의 서명은 애초에 표준 구현체(OpenSSL)가 생성하고 검증하는 서명이다. 자체 변형 알고리즘이라는 것이 존재하지 않으므로, 독립 구현체와 어긋날 수학 자체가 없다. UBMS가 소유한 것은 그 서명을 트랜잭션, 블록, 투표, 통신에 어떻게 배선하는가 하는 프로토콜 계층이며, 다음 장에서 그 계층을 추적한다.

5. 전 계층 적용 추적. 지갑에서 블록까지

지갑 하나에서 PQC 서명이 되는 것과 체인 전체가 PQC인 것의 차이를 코드 흐름으로 보인다.

5.1 키 생성과 지갑

지갑 키쌍은 ML-DSA-87로 생성된다(generateKeysDSA). 노드는 서명용 ML-DSA-87 키쌍과 전송암호용 ML-KEM-1024 키쌍(generateKeysKEM)을 각각 보유하며, 두 용도는 publicKeySign / publicKeyEnc로 자료구조 수준에서 분리되어 있다.

5.2 주소 파생. PQC 공개키가 곧 계정이다

ML-DSA-87 공개키 (2,592B)
  → SHA-256
  → RIPEMD-160
  → 메인넷 접두 0x20 부가
  → 2중 SHA-256 체크섬
  → Base58 인코딩 = 지갑 주소

주소의 루트가 ML-DSA-87 공개키다. ECDSA 계정 위에 PQC를 얹은 구조에서는 불가능한 성질이며, 주소 검증기는 접두 판별로 비PQC 주소를 원천 거부한다.

주소 파생 흐름

5.3 트랜잭션과 블록

• 트랜잭션 서명. 모든 거래는 ML-DSA-87로 서명되고, 검증 노드는 서명자의 공개키와 주소의 파생 일치까지 확인한다
• 머클루트 보강. 머클 트리 잎은 txid만이 아니라 SHA256(txid + 서명 공개키)로 서명 키를 함께 결속한다
• 블록 서명. 채굴자는 블록에 ML-DSA-87 서명을 남기고, 블록 해시는 20개 요소를 결속한다
• 합의 투표 서명. 투표자의 찬반 투표 자체가 ML-DSA-87 서명이며, 서명 검증과 중복 투표 검사를 거친다. 서명 생성에 실패한 노드는 방어적으로 반대 투표로 전환된다

5.4 P2P 통신. 전송 계층까지 PQC

노드 간 통신은 자체 암호 프레임 VER=3을 쓴다.

평문 → zlib 압축
     → ML-KEM-1024 캡슐화 (수신자 공개키) → 공유비밀 32B
     → 공유비밀을 AES-256-GCM 키로 사용, 헤더를 AAD로 결속(변조 방지)
     → [헤더 | KEM 암호문 1,568B | GCM 암호문 | 태그]

소스 주석의 표현을 그대로 옮기면 "RSA-OAEP 세션키 포장을 ML-KEM-1024 캡슐화로 완전 대체한다". 전송 계층의 키교환까지 PQC라는 뜻이며, 대부분의 PQC 지원 프로젝트가 건드리지 않는 영역이다.

VER=3 프레임 구조

5.5 암호 인벤토리 (Crypto Inventory)

6. 레거시 암호 잔존 검증

부분 PQC와 풀 PQC를 가르는 최종 기준은 고전 공개키 암호가 한 줄이라도 남았는가이다. PQC 전면 전환 완료 후 전 소스에 대해 다중 관점 전수조사를 수행했다.

7. 자체 검증 체계

서명이 PQC라도 검증 로직이 부실하면 의미가 없다. UBMS는 검증 전용 라이브러리 ubmsinspect를 별도 모듈로 두고 있으며, 잔고, 입력, UTXO, 이중지불, 서명, 블록에 걸쳐 검증 함수 66종을 갖춘다. 블록 하나가 수용되기까지 서명 검증을 포함한 19단계 검증(블록 해시 무결성, 머클루트, 채굴자 서명, 주소와 키의 일치, 투표자 서명, 중복 투표 등)을 통과해야 한다.

변조 내성은 알고리즘 규격이 보장하는 성질 그대로다. 서명된 메시지의 단 1비트가 변해도 ML-DSA-87 검증은 실패하며, 검증 실패 블록은 투표 단계에서 반대 투표로 이어져 체인에 수용되지 않는다. 동일 시나리오의 시연(메시지에 서명 후 한 글자를 변조하고 검증이 INVALID로 떨어지는 확인)은 요청 시 언제든 재현 가능하다.

8. 검증 단계론에 대한 입장

기술 검증을 주장, 구현, 재현, 표준 적합, 시스템 검증, 독립 검증의 단계로 나누는 틀은 타당하다. 다만 이 틀을 적용할 때는 프로젝트가 어느 단계의 산출물을 내야 할 시기인가를 함께 판단해야 한다.

검증 요구 중에는 대상 착오도 있다. NIST의 ACVP/CAVP(암호 알고리즘 검증 프로그램)는 블록체인 프로젝트가 받는 인증이 아니라 암호 모듈과 라이브러리가 받는 인증이다. 표준 라이브러리를 채택한 응용 시스템에 ACVP 시험 결과를 요구하는 것은, 완성차 제조사에 볼트의 규격 인증서를 요구하는 것과 같다. 볼트는 인증받은 것을 사다 쓰는 것이고, 그 인증은 볼트 제조사의 몫이다. UBMS의 ML-DSA-87, ML-KEM-1024 연산은 OpenSSL 3.5 표준 provider가 수행하므로 알고리즘 수준의 적합성 검증은 그 계층이 담당하고, UBMS가 답할 몫은 그 위의 프로토콜 배선이다. 본 보고서 5장이 그 답이다.

소스코드 공개, 제3자 보안감사, 공인시험은 출시 단계의 산출물이다. UBMS는 현재 출시 전 가운영 단계이며, 개발 중인 비공개 코드베이스에 공개 감사 보고서를 요구하는 것은 검증 단계론을 프로젝트 생애주기와 무관하게 적용한 범주 오류다. 상용 시스템이 출시 전 코드를 비공개로 두는 것은 표준 관행이고, 공개 여부는 개발 모델의 선택이지 기술력의 증명이 아니다. 반대로, 출시된 뒤에도 이 산출물들을 내지 못한다면 그때는 정당한 비판이 된다. UBMS는 출시 시점에 기술문서와 검증 자료를 단계적으로 공개할 계획이다.

9. 결론

양자내성을 표방하는 프로젝트를 평가하는 올바른 질문은 PQC 라이브러리를 쓰는가가 아니라, 고전 공개키 암호가 어디에 남아 있는가이다.

UBMS의 답은 간단하다. 어디에도 남아 있지 않다.

• 주소는 ML-DSA-87 공개키에서 파생되고
• 거래, 블록, 합의 투표는 전부 ML-DSA-87로 서명되며
• 노드 간 통신은 ML-KEM-1024 키교환과 AES-256-GCM으로 암호화되고
• 모든 암호 원시는 자체 구현이 아닌 OpenSSL 3.5 표준 구현이며
• 서명과 키교환 모두 NIST 보안 카테고리 5, 최상위 파라미터이고
• 이 상태는 백지 출발이 아니라, 운영 중인 체인의 하드포크 전환을 6개월에 완주하고 자산 이전까지 진행해 도달한 것이다

기존 체인 위에 PQC를 이름표처럼 얹은 프로젝트와, 운영 체인의 암호를 전량 걷어내고 PQC로 재건한 체인의 차이는 마케팅이 아니라 구조이자 이력이다. 구조와 이력은 본 보고서가 보인 것처럼 계층별로 추적하고 검증할 수 있다.

UBMS Post-Quantum Cryptography Technical Report

Full-Stack Post-Quantum Cryptography Layer 1

Author: Han Hyukjin (bokkamsun@gmail.com)
Date: August 27, 2026

About This Report

This document responds to external technical inquiries about UBMS's post-quantum cryptography (PQC) adoption. It is written by the developer, from facts verified directly in the source code. Everything stated here was confirmed in the actual code; anything that is a plan is labeled as a plan.

UBMS is currently in a pre-release trial operation stage, accumulating real data in a live trial environment and refining the design and code from that feedback. The post-quantum transition covered in this report was actually performed and completed on that live chain.

1. Summary

UBMS is a full-stack PQC Layer 1 blockchain in which every layer operates on post-quantum cryptography. What matters more is how it got there. UBMS is not a blank-slate new chain: it hard-forked a live, operating chain to replace its entire cryptographic scheme, six months from the March 2026 announcement. Most existing wallet assets have been migrated through a dedicated migration system, and the migration path stays open throughout the chain's lifecycle. We have not found a confirmed case of another live blockchain removing its classical cryptography entirely while carrying out asset migration.

In the converted chain, classical public-key cryptography (RSA, ECDSA, EdDSA) exists nowhere: not in the address scheme, transaction signatures, block signatures, consensus voting, or node-to-node transport.

2. Why Full-Stack PQC Is the Standard

It is settled science that a sufficiently developed quantum computer breaks today's public-key cryptography via Shor's algorithm. Worse is the harvest-now-decrypt-later attack: an adversary collecting public keys and signatures today retroactively exposes all past assets the moment a quantum computer matures. A blockchain, whose entire record is permanently public, is the most exposed class of system.

The threat has already moved from theory to experiment. In April 2026, a test key on the same family of elliptic curves used by Bitcoin, reduced to 15 bits, was broken in about 45 minutes on a publicly accessible IBM quantum computer, and a bounty was paid out. The gap to production 256-bit keys remains large, but the breakable scale is growing year over year, and that fact alone is shortening the clock for blockchains built on classical cryptography. NIST finalized the post-quantum standards in August 2024: FIPS 204 (ML-DSA) for signatures and FIPS 203 (ML-KEM) for key encapsulation. Transition is no longer a choice; it is a deadline.

2.1 Three Global Response Tracks

In none of these tracks does a completed transition exist. UBMS is a fourth case belonging to none of them. It hard-forked its operating chain, finished removing the classical cryptography entirely, and carries asset migration alongside.

2.2 Four Types of Partial PQC

A blockchain's quantum vulnerability collapses the whole system through even a single residual point. Without naming projects, the exaggeration patterns observed in the market classify structurally. Documented cases include partial-layer adoption publicized as full coverage, quantum-resistance claims retracted by a project's own developers, and chains cloning Ethereum's source while leading with a quantum-resistant name.

An attacker needs only the single weakest link, not the whole. Replace wallet signatures alone while classical crypto remains in block signing or transport, and assets and consensus collapse through that point. This is where a chain that supports PQC and a chain rebuilt on PQC part ways.

2.3 Layer-by-Layer Comparison

Layer-by-layer coverage

2.4 The Transition Record

UBMS's transition is a history, not a document.

Transition timeline

3. Algorithm Specification

The parameter choice deserves attention. FIPS 204 defines ML-DSA-44 (Category 2), ML-DSA-65 (Category 3), and ML-DSA-87 (Category 5). Most deployments choose the lower parameters to avoid the size cost. UBMS pays the cost of a 4,627-byte signature to secure Category 5 for both signing and key exchange: the same long-term security margin as AES-256, applied to the signature layer.

The pedigree is equally clear. ML-DSA, known as CRYSTALS-Dilithium, underwent more than a decade of open academic scrutiny before becoming a NIST standard, and its core algorithm has never been broken since finalization. The NSA's next-generation national cryptography suite, CNSA 2.0, likewise adopts the ML-DSA family. UBMS uses not a fashionable name but the top parameter set of the same standard chosen for national-security systems.

These sizes are physical quantities that cannot be hidden. If a project claims PQC while its transactions stay the size of a classical chain's, its signatures are not PQC. UBMS accounted for this cost from the serialization and block-structure design stage onward. Measured throughput figures will follow from trial-operation measurement and be included in the release documentation.

4. Cryptographic Implementation and Interoperability

UBMS's principle is explicit. Cryptographic primitives are delegated to verified standard implementations; UBMS owns only the protocol layer above them.

• All ML-DSA-87 and ML-KEM-1024 operations call OpenSSL 3.5's standard FIPS 204/203 providers through the EVP API. Key generation via EVP_PKEY_Q_keygen(NULL, NULL, "ML-DSA-87"), encapsulation via the EVP_PKEY_encapsulate family
• Specification details are honored. Since ML-DSA hashes the message internally, UBMS uses the sign_message_init path rather than external pre-hash signing; the rationale is recorded in the source comments
• Key serialization rejects PEM in favor of the raw FIPS byte encoding handled as hex, eliminating parser ambiguity

This answers a standard verification question: does it interoperate with independent implementations? UBMS signatures are produced and verified by a standard implementation in the first place. There is no in-house variant that could diverge. What UBMS owns is the protocol wiring of those signatures into transactions, blocks, votes, and transport, traced in the next section.

5. Full-Layer Coverage. From Wallet to Block

5.1 Key Generation and Wallet

Wallet keypairs are ML-DSA-87 (generateKeysDSA). Each node also holds an ML-KEM-1024 keypair for transport encryption (generateKeysKEM); the two roles are separated at the data-structure level as publicKeySign / publicKeyEnc.

5.2 Address Derivation. The PQC Key Is the Account

ML-DSA-87 public key (2,592B)
  → SHA-256
  → RIPEMD-160
  → mainnet prefix 0x20
  → double SHA-256 checksum
  → Base58 encoding = wallet address

The root of every address is an ML-DSA-87 public key, a property impossible for structures layered over ECDSA accounts. The address validator rejects non-PQC prefixes outright.

Address derivation flow

5.3 Transactions and Blocks

• Transaction signatures. Every transaction is signed with ML-DSA-87; validators additionally check that the signer's key derives the claimed address
• Hardened Merkle root. Leaves commit to SHA256(txid + signing public key), binding the key into the tree
• Block signatures. The miner signs the block with ML-DSA-87; the block hash binds 20 elements
• Consensus vote signatures. Each voter's vote is itself an ML-DSA-87 signature, checked for validity and duplication. A node that fails to produce its own signature defensively converts to a NO vote

5.4 P2P Transport. PQC Down to the Wire

plaintext → zlib compression
         → ML-KEM-1024 encapsulation (receiver's public key) → 32B shared secret
         → shared secret used as AES-256-GCM key, header bound as AAD
         → [header | KEM ciphertext 1,568B | GCM ciphertext | tag]

Quoting the source comments directly: "the RSA-OAEP session-key wrapping is completely replaced by ML-KEM-1024 encapsulation." Even transport key exchange is PQC, a layer most PQC-enabled projects never touch.

Frame VER=3 structure

5.5 Crypto Inventory

6. Residual Legacy Crypto Audit

The final criterion separating partial PQC from full PQC is whether a single line of classical public-key cryptography remains. After completing the transition, the entire source tree was audited from multiple angles.

7. Internal Validation System

PQC signatures mean little if the validation logic is weak. UBMS maintains a dedicated validation library, ubmsinspect, with 66 validation functions spanning balances, inputs, UTXOs, double-spends, signatures, and blocks. A block must pass a 19-step validation, including block-hash integrity, Merkle root, miner signature, address-key match, voter signatures, and duplicate-vote checks, before acceptance.

Tamper resistance follows the algorithm's own guarantee. Flip a single bit of a signed message and ML-DSA-87 verification fails; a failed block draws NO votes and never enters the chain. A live demonstration of this scenario, signing a message, altering one character, and watching verification return INVALID, can be reproduced on request at any time.

8. On Verification Staging

Framing verification as claim, implementation, reproduction, standards conformance, system validation, and independent validation is sound, provided it is applied with the project's lifecycle stage in mind.

Some verification demands also miss their target. NIST's ACVP/CAVP (algorithm validation programs) certify cryptographic modules and libraries, not blockchain projects. Demanding ACVP test results from an application system that adopts a standard library is like demanding a bolt's certification papers from a car manufacturer: the bolts are bought certified, and that certification belongs to the bolt maker. UBMS's ML-DSA-87 and ML-KEM-1024 operations are performed by OpenSSL 3.5's standard providers, so algorithm-level conformance belongs to that layer. What UBMS answers for is the protocol wiring above it, and Section 5 of this report is that answer.

Source disclosure, third-party audits, and accredited testing are release-stage deliverables. UBMS is in closed pre-release development; demanding public audit reports for an unreleased private codebase applies the verification ladder with no regard for lifecycle. Keeping code private before release is standard practice for commercial systems, and whether to develop in the open is a choice of development model, not a proof of capability. Conversely, failing to produce these after release would be fair criticism. UBMS plans to publish its technical documentation and verification materials in stages at release.

9. Conclusion

The right question for evaluating a quantum-resistance claim is not whether it uses a PQC library, but where classical public-key cryptography remains.

UBMS's answer is simple: nowhere.

• Addresses derive from ML-DSA-87 public keys
• Transactions, blocks, and consensus votes are all signed with ML-DSA-87
• Node-to-node transport is encrypted with ML-KEM-1024 key exchange and AES-256-GCM
• Every primitive is the standard OpenSSL 3.5 implementation, not in-house math
• Both signing and key exchange sit at NIST Security Category 5, the highest parameter set
• And this state was reached not from a blank slate, but by completing a live-chain hard fork in six months with asset migration carried alongside

The difference between a chain that wears PQC like a nameplate and a chain that stripped out its running cryptography and rebuilt itself on PQC is not marketing. It is structure and history, and both can be traced and verified layer by layer, as this report has shown.