PBKDF2

복구 단어는 password라는 입력이 됩니다. 두 번째 입력인 salt는 문자 그대로의 "mnemonic" 뒤에 passphrase, 즉 선택적인 추가 비밀번호를 바로 붙인 값입니다. 사이에 구분자나 복구 단어를 다시 넣지 않습니다. passphrase가 없어도 salt는 "mnemonic"이며 빈 문자열이 아닙니다. 두 입력 모두 특정 문자 표현을 통일하는 NFKD 처리와 UTF-8 인코딩을 거칩니다. BIP39는 HMAC-SHA512를 사용하고, 2048번 반복해 64바이트, 즉 512비트를 출력합니다. 이 결과가 seed입니다. salt는 사용자가 별도로 만들어야 하는 또 하나의 백업이 아닙니다. [1]

내부에서는 키와 메시지를 결합해 계산하는 HMAC을 사용합니다. 매 라운드에서 같은 비밀번호 입력이 키로 쓰입니다. 첫 중간 결과에는 salt와 출력 블록 번호를 사용하고, 다음 라운드부터는 직전 중간 결과를 처리합니다. 각 결과는 대응하는 비트끼리 연산하는 XOR로 합칩니다. HMAC-SHA512는 64바이트를 반환하므로 BIP39에는 이러한 블록 하나면 충분합니다. 텍스트에 SHA-512만 2048번 적용하면 다른 계산이 되어 결과도 달라집니다. [2] [1]

다른 지갑에서 복구한다고 생각해 보세요. 같은 seed를 얻으려면 정규화한 데이터와 설정이 모두 같아야 합니다. 정해진 2048회보다 반복을 늘려도 복구가 개선되는 것은 아닙니다. BIP39 절차를 벗어나 다른 결과를 얻을 뿐입니다. 복구 단어를 다른 단어 목록의 언어로 번역하는 것도 결과에 영향을 주는 변경입니다. 복구에는 일치가 필요하지, 알고리즘을 임의로 바꾸는 일이 필요하지 않습니다. [1]

계산을 반복하면 한 번 시도하는 비용은 커지지만, 새로운 독립적인 무작위성은 생기지 않습니다. 공격자가 백업 단어를 알고 올바른 지갑을 알아볼 정보도 갖고 있다면, 자기 컴퓨터에서 약한 passphrase를 오프라인으로 대입할 수 있습니다. 따라서 seed의 길이가 512비트라고 해서 예측 불가능성도 512비트인 것은 아닙니다. 2048이라는 수도 새로 설계하는 모든 시스템에 대한 권장값이 아니라, 여기서는 특정 복구 표준의 일부입니다. [2] [1]

BIP39의 체크섬은 잘못 옮겨 적은 단어를 찾는 데 도움을 줍니다. PBKDF2는 다른 문제, 즉 주어진 입력으로 seed를 어떻게 계산할지를 다룹니다. 그 계산 자체가 passphrase와 원래 지갑의 일치를 확인해 주지는 않습니다. 이후에는 예를 들어 BIP32가 seed를 처리해 여러 키로 이루어진 체계를 파생할 수 있습니다. 기록 확인, seed로의 변환, 키 생성은 연결된 단계이지만 서로 대체할 수는 없습니다. [1]

개발자는 공개 테스트 벡터, 즉 알려진 입력과 예상 출력으로 결과를 비교할 수 있습니다. BIP39는 원래의 무작위 데이터와 단어, 테스트용 passphrase TREZOR에 해당하는 전체 seed를 공개합니다. 올바른 구현은 NFKD 규칙까지 적용해 그 결과를 재현해야 합니다. 이런 시험에는 실제 백업이 필요하지 않습니다. 반대로 누구나 아는 공개 예제를 돈을 보관하는 데 사용해서는 안 됩니다. 계산 테스트를 통과했다고 애플리케이션 전체의 안전성이 입증되는 것도 아닙니다. [1]