SLIP-39

안나는 셋 중 둘로 복구하는 백업을 선택합니다. 지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 지갑은 서로 다른 조각 세 개를 만들고, 어느 두 개든 있으면 복구할 수 있습니다. 이 최소 개수를 임계값이라고 합니다. 같은 조각을 찍은 사진 두 장은 여전히 조각 하나입니다. 간단한 방식은 그룹 하나를 사용합니다. SLIP-39는 더 복잡한 규칙도 지원합니다. 예를 들어 3개 그룹 중 2개가 필요하고, 각 그룹에서도 3개 조각 중 2개가 필요하도록 정할 수 있습니다. A의 두 조각과 B의 두 조각은 충분하지만, A의 세 조각과 B의 한 조각은 A만 조건을 충족하므로 부족합니다. 종이 개수뿐 아니라 구성 방식이 중요합니다. [1] [6]

각 목록에는 서로 다른 데이터와 이를 올바르게 합치는 데 필요한 정보가 담깁니다. SLIP-39는 고정된 영어 단어 1024개를 사용합니다. 지갑 화면이 한국어여도 백업 단어는 번역하지 않습니다. 128비트 비밀은 조각당 20단어, 256비트 비밀은 33단어가 됩니다. 비트는 데이터의 기본 단위이지 추가로 적을 단어가 아닙니다. 조각에는 세트와 그룹, 조각 위치를 나타내는 정보, 필요한 임계값과 암호화 설정도 들어 있습니다. 복구할 때는 정보가 일치하고 조각이 서로 다른지 확인합니다. 따라서 길이가 같은 임의의 목록을 섞을 수는 없습니다. [1]

안나는 직접 정하는 추가 비밀번호인 passphrase도 사용할 수 있습니다. 조각을 충분히 모아도 이를 대신하지 못하며, 올바른 조합 자체가 오타를 알아내지는 못합니다. 다른 passphrase는 다른 마스터 비밀을 만들어 다른 지갑을 열기 때문입니다. 따라서 백업이 유효하다는 메시지만 볼 것이 아니라, 이미 알고 있는 주소와 결과를 대조해야 합니다. Passphrase를 쓰지 않으면 입력은 빈 문자열입니다. SLIP-39는 출력 가능한 ASCII 32–126, 즉 공백을 포함한 기본 라틴 문자와 기호 등을 허용하며 발음 구별 기호가 붙은 문자는 허용하지 않습니다. 이는 이 표준의 규칙이지 모든 지갑의 공통 규칙은 아닙니다. Passphrase는 기기 잠금을 푸는 PIN과 다릅니다. [1]

BIP 39 Seed Phrase는 생성 방식도 단어 목록도 다릅니다. 단어를 여러 종이에 나눠 적는다고 SLIP-39 조각이 되지는 않습니다. 같은 지갑을 유지하려면 변환 과정에서 BIP 32 키 트리의 비밀 입력 데이터인 seed와, 사용하는 키로 이어지는 올바른 Derivation Path를 보존해야 합니다. 단어 생성 전의 무작위 데이터인 원래 엔트로피를 다른 방식으로 표현하는 것만으로는 부족합니다. BIP 39는 단어와 passphrase에서 512비트 seed를 만듭니다. 이를 SLIP-39로 직접 백업하면 조각마다 59단어가 필요합니다. 지갑 하나를 변환해도 다른 passphrase로 여는 다른 지갑까지 자동으로 옮겨지지는 않습니다. 지원되는 구체적인 절차를 먼저 확인해야 합니다. [1] [3] [2]

extendable 표시가 있는 호환 백업은 같은 지갑을 유지하면서 분할 방식을 바꿀 수 있습니다. Trezor는 이 방식으로 단일 조각 백업을 여러 조각으로 바꾸는 과정을 설명합니다. 하지만 종이를 바꿔도 안나의 비밀이 바뀐 것은 아닙니다. 충분한 이전 조합은 여전히 작동합니다. 이전 조각과 새 조각을 섞어서는 안 됩니다. 기술적으로 표시 값이 1이면 salt라는 암호화 보조 입력에서 세트 식별자를 제외합니다. 따라서 같은 encrypted master secret(EMS), 즉 암호화된 마스터 비밀을 passphrase를 모르더라도 새 식별자로 다시 나눌 수 있습니다. 이는 사용 가능한 이전 백업이 유출된 문제를 해결하지 않습니다. [1] [4]

개인키는 지갑이 자금 지출을 승인하는 디지털 서명을 만들 때 사용하는 비밀 숫자 값입니다. 안나의 지갑은 복구 후 평소처럼 서명할 수 있습니다. 조각 보유자가 매번 결제를 승인할 필요는 없습니다. SLIP-39는 비밀 하나를 복구하고, Multisig는 지출 조건에 따라 여러 서명을 요구합니다. 같은 집에 둔 세 조각은 한 번의 화재로 모두 사라질 수 있습니다. 분산 보관은 동시 손실과 공격자의 충분한 조각 수집을 모두 어렵게 해야 합니다. 다만 복잡한 방식은 복구 부담도 늘립니다. 복구 점검은 신뢰할 수 있는 기기에서 지원되는 절차로 해야 합니다. 참조 라이브러리 python-shamir-mnemonic은 개발자가 공개 테스트 예제로 호환성을 확인하는 용도이지 실제 백업을 처리하는 도구가 아닙니다. 이 라이브러리는 비밀을 충분히 보호하지 않는다고 명시적으로 경고합니다. [1] [4] [5] [6]

BIP 32 지갑의 마스터 비밀은 입력 seed이며, 이미 계산된 키 트리의 확장 개인 루트가 아닙니다. 먼저 seed를 암호화한 뒤 결과인 EMS를 나눕니다. 암호화는 Feistel 구조의 네 라운드를 사용합니다. 각 라운드는 PBKDF2-HMAC-SHA256을 2500×2^e회 반복하며 저장된 지수 e가 계산 비용을 정합니다. 이는 정확히 정의된 비밀번호 처리이며 무작위 단어를 추가하는 과정이 아닙니다. 분할은 256개 값을 가진 수학적 구조 GF(256)에서 바이트별로 계산합니다. 다항식의 f(255)에 비밀을 두며, 임계값이 2 이상이면 f(254)에 digest라는 검증값을 둡니다. [1] [2]

조각의 마지막 세 단어는 RS1024 체크섬을 이룹니다. 최대 세 단어에 영향을 주는 오류를 반드시 감지하지만, 백업 작성자의 서명이나 소유권 증명은 아닙니다. 표준은 자동 수정을 권하지 않습니다. 프로그램이 유효하지만 원래와 다른 단어를 만들 수 있기 때문입니다. 조합할 때는 추가적인 32비트 digest가 잘못된 세트를 감지하는 데 도움이 됩니다. 여기에는 이론적인 제약도 있습니다. 임계값보다 한 조각 적게 가진 사람은 전수 탐색으로 일부 비밀 후보를 제외할 수 있습니다. 따라서 임계값 미만에서는 정보가 전혀 새지 않는다는 수학적 주장을 그대로 적용할 수는 없습니다. 쉽게 뚫린다는 뜻은 아니며, 충분히 강한 원래 비밀을 표준이 요구하는 이유를 설명합니다. [1]