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) — a possible cause. The same character can be one code point (NFC: é = U+00E9) or a letter plus a combining mark (NFD: e + U+0301). The normalization form depends on the application and input path; it should not be inferred from the operating system alone. Created one way, retyped the other, it fails. Testing normalization variants can help when there is evidence that the creation and recovery paths produced different input.
• 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.

Frequently asked questions