이 문서는 본인의 프리세일 지갑에 대한 접근 권한을 복구하는 방법을 안내합니다. 아래의 각 항목은 사용자가 정확히 입력한 비밀번호가 키보드에서 키 도출 함수로 전달되는 과정에서 소프트웨어에 의해 어떻게 변조되었을 수 있는지를 설명합니다. 이러한 변조 과정은 기본이 되는 암호화 방식을 약화시키거나 훼손하지 않으며, 암호화 방식은 여전히 안전합니다. 복구는 오직 사용자가 실제로 입력한 비밀번호를 오류 없이 정확히 재현할 때만 가능합니다.

사전 판매 과정에서 비밀번호가 어떻게 암호화되는지

표준 pyethsaletool 참조 구현을 보면, 처리 과정은 간단합니다. 사용자의 비밀번호는 PBKDF2-HMAC-SHA256을 사용하여 2,000 라운드 동안 확장(16바이트로 잘림)되어 키가 생성되며, 이 키로 encseed를 AES로 복호화한 후, 그 결과를 해시하여 개인 키를 생성하고, 해당 주소와 파일 내의 ethaddr을 비교합니다. 올바른 비밀번호만이 일치하는 주소를 산출합니다. 이것이 바로 hashcat 모드 16300입니다.

복구 페이지에서 반복적으로 언급되고 있으므로 바로잡아야 할 세 가지 오해가 있습니다. 첫째, 사전 판매 단계에서는 scrypt를 사용하지 않습니다 (이는 이후의 V3 키스토어, 모드 15700에 해당합니다). 둘째, 반복 횟수는 의도적으로 낮게 (2,000회) 설정되어 있어, 이를 통해 후보 값 탐색이 관리 가능한 수준이 됩니다. 셋째, 비밀번호는 임의의 값으로 솔트 처리되지 않으며, 비밀번호 자체가 솔트 역할을 합니다. 바로 이 마지막 세부 사항 때문에 입력값의 미세한 변화만으로도 완전히 다른 결과가 도출됩니다.

근본 원인: 생성 대 복호화

인코딩 및 정규화 오류

• 유니코드 정규화(NFC 대 NFD) — 주된 원인. 동일한 문자는 하나의 코드 포인트(NFC: é = U+00E9)일 수도 있고, 문자 하나와 결합 기호(NFD: e + U+0301)의 조합일 수도 있습니다. macOS는 다양한 상황에서 애플리케이션에 NFD 텍스트를 전달하는 반면, Linux와 Windows는 NFC를 사용합니다. 한 방식으로 생성된 텍스트를 다른 방식으로 재입력하면 오류가 발생합니다. 네 가지 형태(NFC, NFD, NFKC, NFKD)를 모두 테스트하면 대부분의 문제를 해결할 수 있습니다.
• UTF-8 대 Latin-1 대 UTF-16 바이트 분기. 브라우저가 움라우트를 처리하는 과정에서, 최신 도구가 가정하는 UTF-8이 아닌 Latin-1 하위 바이트나 원시 UTF-16 단위가 생성되었을 수 있습니다.
• 잘못 디코딩된 ‘생성 후 저장’ 경로로 인한 이중 인코딩/문자 깨짐 (예: ä가 ä로 변형됨).
• 전사. 사용자가 특정 국가 고유의 문자를 한 가지 방식으로 입력했지만, 다른 방식으로 기억하는 경우: 독일어 ä↔ae, ß↔ss; 스웨덴어 å↔aa; 노르웨이어 ø↔o/oe; 스페인어 ñ↔n 등.
• 동형 문자 대체. 키릴 문자나 그리스 문자 배열이 활성화된 상태에서, 화면상으로는 라틴 문자로 보이는 문자( a에 해당하는 키릴 문자 ‘а’ )는 코드 포인트가 완전히 다릅니다.

macOS 입력 관련 특이점

• 스마트 따옴표와 스마트 대시. macOS는 일반 따옴표 ‘ “를 곡선 따옴표 ‘’“”로, 일반 대시 –를 –—로 자동 변환합니다. 비밀번호는 겉보기에는 같아 보이지만, 바이트 값은 다릅니다.
• 데드 키 “고착된 악센트”. macOS에서 악센트(급성/움라우트/중성) 데드 키 뒤에 기본 문자가 아닌 문자가 오면, 해당 악센트 기호와 문자가 결합되어 출력됩니다. 예를 들어, ‘café’가 ‘caf´e’로 저장되었을 수 있습니다.
• 악센트 메뉴를 길게 누르는 동작과 캡스락 기능의 사용 편의성 문제. 악센트 선택기와 캡스락이 켜진 상태(일부 Mac에서는 LED 표시가 명확하지 않음)가 결합되면, 사용자가 의도하지 않은 대소문자 및 악센트 변형이 발생합니다.

키보드 배열 및 지역 설정

• 전체 키보드 레이아웃 재매핑 — 재단 자체 조사에서 확인된 가장 명확한 단일 메커니즘입니다. 입력 또는 전송 시점에 OS의 입력 언어가 영어가 아닌 경우, 시스템이 키를 재매핑하여 입력란에 입력된 문자가 키캡에 표시된 문자와 다르게 나타났습니다.
• QWERTZ y/z 키 위치 오류 및 생성 시와 재진입 시 간의 기타 키 배열 변경.
• Geth 콘솔의 비-ASCII 문자 제거 문제. 사전 판매용 지갑을 나중에 Geth로 가져올 경우, 일부 로케일에서 콘솔이 코드 포인트 127을 초과하는 문자를 아무런 경고 없이 제거하여, 특수 문자가 포함된 비밀번호가 축소되거나 비워질 수 있었습니다. (이는 특정 경로에서 발생하는 버그이며, 2014년 브라우저 버그와는 무관합니다.)

입력, 하드웨어 및 파일 관련 오류

• 엔트로피 단계의 “실수”. 프리세일 과정에서 마우스 움직임으로부터 초기 엔트로피를 수집했는데, 이 단계에서 비밀번호 입력란이 항상 비활성화되어 있지는 않았습니다. 마우스를 움직이는 도중 실수로 키를 누르면, 사용자가 의도하지도 않았고 기억조차 하지 못할 문자가 추가될 수 있었습니다. 이는 프리세일의 사용자 경험(UX)에 특정한 문제입니다.
• 붙여넣기 시 발생하는 공백 및 줄바꿈 (필드에 붙여넣을 때 포착된 앞/뒤 공백 또는 \n/\r\n ).
• 키가 달라붙거나 튀는 현상으로 인해 의도하지 않은 문자가 두 번 입력되는 경우.
• 검증 후 내용 잘림 / 비어 있는 비밀번호 — 양식 검증을 통과한 후 편집된 필드.
• 재암호화 시 발생하는 차이점. 지갑을 MyEtherWallet, Mist 또는 Geth로 가져오면 새로운 암호화 키로 재암호화됩니다. 이로 인해 한 복사본은 열리지만 다른 복사본은 열리지 않을 수 있으며, 재가져오기 과정에서 손상된 경우 영구적으로 열 수 없게 될 수도 있습니다. 모든 복사본을 보관하고 테스트해 보십시오.
• 다운로드 중단 / 파일 무결성 문제. 속도가 느린 페이지에서 다운로드가 중단되면 압축 파일이 불완전하게 저장될 수 있으며, 이 경우 어떤 비밀번호로도 해당 파일을 복호화할 수 없습니다. 시간을 들이기 전에 파일의 무결성을 먼저 확인하십시오.

이것이 경기 회복에 어떤 의미를 갖는가

실질적인 결과는 고무적입니다. 비밀번호를 기억하고 있다면, 프리세일 지갑을 복구하는 것은 수백만 개의 비밀번호를 추측하는 것이 아니라, 알려진 하나의 문자열에 대해 이러한 변환 과정을 일일이 시도해 보는 문제일 뿐입니다. 합리적인 순서는 다음과 같습니다:

• JSON 파일의 모든 사본을 찾아보세요. 프리세일 측에서 이메일로 보내드렸을 테니, 과거 이메일, 저장 장치, 클라우드 백업 및 예전 사용하던 기기를 확인해 보세요. 재암호화된 사본은 서로 다르기 때문에, 사본이 많을수록 성공할 확률도 높아집니다.
• 각 파일에 시간을 투자하기 전에 (유효한 JSON인지, encseed 길이가 적절한지) 먼저 검증하십시오.
• 비밀번호 관리 앱에서 2014년 이더리움 크라우드세일과 관련된 항목이 있는지 확인해 보세요. 또한 저장된 값이 나중에 수정되었을 수도 있으므로, 해당 비밀번호의 변경 내역도 함께 확인해 보시기 바랍니다.
• 당시 사용했던 운영 체제와 키보드에 맞춰, 가장 유력한 후보를 위의 인코딩 및 입력 방식 변형들을 모두 적용해 보세요.

파일 자체가 사라진 경우라면 누구도 도와드릴 수 없습니다. 하지만 파일이 아직 남아 있다면, 대부분의 소유자가 생각하는 것보다 복구 가능성이 훨씬 높습니다. 이것이 바로 저희가 하는 일입니다. 이더리움 프리세일 복구 가이드를 확인해 보세요.

출처

이 카탈로그는 단순한 의견이 아닌 1차 자료들을 종합하여 작성되었습니다. 여기에는 표준 이더리움/pyethsaletool 참조 구현체와 프리세일 프론트엔드(ethereum/www), 이더리움 재단의 자체 “비밀번호 오류” 조사(Mist 이슈 #3513 스레드 및 관련 보고서), 인코딩 및 콘솔 입력 처리에 관한 go-ethereum 이슈; hashcat 모드 16300 구현; 그리고 John the Ripper의 ethereum2john 등이 포함됩니다. 상기 동작들은 해당 자료들과 계정에 접근이 차단된 참가자들의 증언을 통해 기록되어 있습니다.

자주 묻는 질문