I was looking through an Electrum wallet file (from Electrum 1.9.6 for Windows if it matters) trying to understand what information was contained in it, and I couldn't initially figure out exactly where the private keys were stored (or even if they were perhaps stored in some other file). I'm guessing the "seed" field in the default_wallet file contains sufficient information for the private keys, public keys, and 12 word mnemonic to be generated. Am I right so far?

To experiment a bit more, I wanted to see if 2 wallet files that use the same 12 word mnemonic would be identical. Not surprisingly, when I did not encrypt the wallets, the same mnemonic appeared to lead to identical wallet files. However, I also tried encrypting each wallet with the same password, and to my surprise, the files had different values in the "seed" field. This surprised me, so I'm wondering if this is expected behavior and why is this happening?

  • If the 12 word mnemonic produces different wallet, that makes the mnemonic useless. Are you sure you didn't mistype the words or something?
    – John T
    Jan 13, 2014 at 7:19
  • I copied and pasted and saw the same effect multiple times. The wallets are the same in that they have the same addresses. Jan 13, 2014 at 7:31
  • 1
    Perhaps the "seed" is a salt/IV used for encryption. The transformation from passphrase to private keys needs to be deterministic, the encryption doesn't need to be. Jan 13, 2014 at 10:50
  • @CodesInChaos That's my guess, but I was hoping for someone with more familiarity with the inner workings to verify. A very, very cursory glance at the code didn't make it obvious to me whether or not this was the case. Jan 13, 2014 at 14:43
  • 2
    Encryption almost always incorporates some random element. Jan 13, 2014 at 22:57

2 Answers 2


It's actually a good question. Let's take a look at what is happening. First, Electrum hashes your mnemonic to generate a seed. The seed indeed contains all the information necessary to generate the Master Public Key and the Master Secret Key, first being used to generate the sequence of public keys (adresses) and the second being used to derive a secret key from a public key (actually it's slightly more complex). Then, Electrum saves the wallet file, which contains the seed and the keys being actually in use, the whole sequence of key pairs unless it hits 5 consecutive unused adresses. It can store it either unenrypted or encrypted. In the first case, the seed value in the file will always look the same, as will private keys. In the second case, however, they won't. Why? The Electrum documentation says:

Electrum uses AES-256-CBC to encrypt the seed and private keys in the wallet.

What does it mean? AES-256 is simply a block cipher. It takes a block of data (128 bit in this case) and a block of key (256 bit) and outputs 128 bits of encrypted data. But it is not what Electrum does. Actually, noone uses block ciphers like that and noone ever should. Instead, so called modes are used. In our case it is Cipher Block Chaining (CBC) mode. Electrum first generates a random initialization vector (IV), mix it (by exclusive or operation) with first 128 bit of input and uses AES-256 on this mixed block to produce first encrypted block. For any subseqent block it does the same, except instead of IV it takes previous encrypted block to mix with the plaintext block. The IV is saved alongside with the file. Finally, that's why you always arrive with a different seed value in a file, even when using the same password (which results in the same key for AES-256-CBC encryption [1]) -- a different IV is used each time.

[1] It is not probably the case either, as Key Derivation Function is likely to be used to deliver a key from your passphrase, in which case additional random salt value is added to the passphrase before hashing it and saved alongside, similarly to the IV.

  • "being used to derive a secret key from a public key". If one can do that then there's not much security? Surely it's the other way around?
    – Squirrel
    Aug 29, 2017 at 21:22
  • @Squirrel Not really. One can derive any private key from it's corresponding public key with extra knowledge. It's secure as long as the user doesn't disclose this extra knowledge. Sep 1, 2017 at 7:58
  • Ah just been reading about this - 'hardened derivation' protects against this. The 'extra knowledge' your referring to is the chain code?
    – Squirrel
    Sep 2, 2017 at 11:25
  • First, sorry for the late reply, it has been a busy time for me. No, hardened derivation is meant to protect against this "attack", but the extra knowledge is something entirely else: it's the master private key which can be effectively extracted from the master public key and any of the individual private keys. I would happily explain this in more details if you ask a question, as it won't fit as nicely in a comment and comments doesn't allow all the math formatting. Just make sure to let me know you have asked it. Oct 3, 2017 at 8:56

The seed is the key that is taken to derive all your addresses deterministically. The encryption is to protect the seed https://electrum.org/faq.html#wallet-encryption


  • I read those links before asking my question...this doesn't answer the question of why the wallet file shows 2 different seeds for the same 12-word mnemonic. It seems there is likely some entropy from the user added to some sort of salt, but I'd like some confirmation on this. Jan 13, 2014 at 14:36
  • You are plain wrong in most of the content of your question, so if you really read all content in those links then you didn't understand anything. Why would that matter if the encrypted seed doesn't match? It just matter that the seeds are the same after decrypting them, that's the way encryption works.
    – rdymac
    Jan 13, 2014 at 21:07
  • If I'm wrong about any of my assumptions then please educate me...that's why this site exists. Jan 14, 2014 at 0:05
  • As for why it matters if the encrypted seed doesn't match, it matters greatly for confirming my understanding of what information is and is not in the default_wallet file. Seeing that they were different surprised me and made me wonder if my understanding of the file was incorrect or if perhaps there were some bug in the implementation. Jan 14, 2014 at 0:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.