Why a “correct” presale password fails

This is a reference for recovering access to your own presale wallet. Every entry below describes how an honestly-typed password may have been altered by software between the keyboard and the key-derivation function. None of it weakens or breaks the underlying cryptography, which remains sound — recovery only ever works by reproducing the password you actually used without errors.

How the presale encrypts your password

From the canonical pyethsaletool reference implementation, the chain is short: your password is stretched with PBKDF2-HMAC-SHA256 for 2,000 rounds (truncated to 16 bytes) to make a key; that key AES-decrypts the encseed; the result is hashed to a private key and its address is compared to the ethaddr in the file. Only a correct password yields a matching address. This is hashcat mode 16300.

Three myths worth clearing, because recovery pages repeat them: the presale does not use scrypt (that’s the later V3 keystore, mode 15700); the iteration count is deliberately low (2,000), which is what makes candidate sweeps tractable; and the password is not salted with a random value — the password salts itself. That last detail is why a tiny change in the input produces a completely different result.

The root cause: create vs. decrypt

Encoding & normalisation bugs

• Unicode normalisation (NFC vs NFD) — the dominant cause. The same character can be one code point (NFC: é = U+00E9) or a letter plus a combining mark (NFD: e + U+0301). macOS hands applications NFD text in many contexts; Linux and Windows use NFC. Created one way, retyped the other, it fails. Testing all four forms (NFC, NFD, NFKC, NFKD) resolves a large share of cases.
• UTF-8 vs Latin-1 vs UTF-16 byte forks. The browser’s handling of an umlaut may have produced Latin-1 low bytes or raw UTF-16 units, not the UTF-8 a modern tool assumes.
• Double-encoding / mojibake (e.g. ä mangled to ä) from a mis-decoded create-then-store path.
• Transliteration. A user typed a national character one way and recalls it another: German ä↔ae, ß↔ss; Swedish å↔aa; Norwegian ø↔o/oe; Spanish ñ↔n, and so on.
• Homoglyph substitution. With a Cyrillic or Greek layout active, a character that looks Latin on screen (Cyrillic а for a) is a different code point entirely.

macOS input quirks

• Smart quotes and smart dashes. macOS auto-substitutes straight ‘ “ into curly ‘’“”, and – into –—. The password looks the same; the bytes differ.
• Dead-key “stuck accent.” On macOS an acute/umlaut/grave dead key, if followed by a non-base letter, emits the bare diacritic plus the letter — a remembered café may have been stored as caf´e.
• Press-and-hold accent menu, and Caps-Lock ergonomics. The accent picker and a Caps-Lock left on (no obvious LED on some Macs) produce case and accent variants the user never intended.

Keyboard layout & locale

• Full-keyboard layout remap — the clearest single mechanism reproduced in the Foundation’s own investigation. If the OS input language was non-English at the moment of entry or transfer, the system remapped keys, so the characters that reached the field were not the ones on the keycaps.
• QWERTZ y/z slip and other layout swaps between creation and re-entry.
• The geth-console non-ASCII strip. If a presale wallet was later imported into geth, its console silently dropped characters above code point 127 on some locales — a special-character password could be reduced or emptied. (A path-specific bug, not a 2014-browser one.)

Entry, hardware & file bugs

• The entropy-phase “fidget.” The presale gathered seed entropy from mouse movement, and the password field was not always disabled during that step — a stray keystroke while jiggling the mouse could append a character the user never intended and won’t recall. This one is specific to the presale’s UX.
• Whitespace and newlines from paste (a leading/trailing space, or a \n/\r\n captured when pasting into the field).
• Sticky or bouncing keys producing an unintended doubled character.
• Post-validation truncation / empty password — the field edited after it passed the form check.
• Re-encryption differences. Importing the wallet into MyEtherWallet, Mist or geth re-encrypted it with new material — one copy may open while another fails, and a corrupted re-import can be permanently un-openable. Keep and test every copy.
• Truncated download / file integrity. An interrupted download over a slow page could leave the encseed incomplete; then no password will ever decrypt it. Validate the file before spending any effort.

What this means for recovery

The practical upshot is encouraging: if you remember your password, recovering a presale wallet is mostly a matter of enumerating these transforms of one known string — not guessing millions of passwords. A sensible order:

• Find every copy of the JSON — the presale emailed it to you; check old email, drives, cloud backups and old machines. Re-encrypted copies differ, so more copies mean more chances.
• Validate each file (valid JSON, a sane encseed length) before spending time on it.
• Check your password manager for any 2014 entry referencing the Ethereum crowdsale — and its password history, since the stored value may have been edited later.
• Sweep your best candidate through the encoding and input-quirk variants above, matched to the operating system and keyboard you used at the time.

If the file itself is gone, no one can help — but if you still have it, the odds are far better than most owners believe. This is the work we do; see our Ethereum presale recovery guide.

Sources

This catalog is synthesised from primary sources rather than opinion: the canonical ethereum/pyethsaletool reference implementation and the presale front-end (ethereum/www); the Ethereum Foundation’s own “wrong password” investigation (the Mist issue #3513 thread and related reports); go-ethereum issues on encoding and console input handling; the hashcat mode 16300 implementation; and John the Ripper’s ethereum2john. The behaviours above are documented there and in the accounts of locked-out participants.

よくある質問