5

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 '14 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. – Michael McGowan Jan 13 '14 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. – CodesInChaos Jan 13 '14 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. – Michael McGowan Jan 13 '14 at 14:43
  • 2
    Encryption almost always incorporates some random element. – David Schwartz Jan 13 '14 at 22:57
3

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 '17 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. – Hubert Jasieniecki Sep 1 '17 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 '17 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. – Hubert Jasieniecki Oct 3 '17 at 8:56
-2

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

https://electrum.org/faq.html#seed

  • 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. – Michael McGowan Jan 13 '14 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 '14 at 21:07
  • If I'm wrong about any of my assumptions then please educate me...that's why this site exists. – Michael McGowan Jan 14 '14 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. – Michael McGowan Jan 14 '14 at 0:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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