Topic: encrypting seed phrase with a password (Read 657 times)

I read the article, but it's still a lot to process:

1st, this type of attack is only possible if my hardware device has compromised firmware.

2nd, the "Dark Skippy" attack can exfiltrate the private key, wallet descriptor, seed bytes, and/or extended private key in just two or more signatures (depending on the seed entropy, even one), hiding information inside the transaction signatures.

3rd, the exfiltration is done inside the signature itself. Security depends on the integrity of the signing device itself.

4th, the attack occurs at the moment you sign a transaction. This means that, even without knowing it, when signing a transaction, the compromised device may be extracting sensitive information and sending it to the attacker. Therefore, the critical moment of vulnerability is during the signing of the transaction?

5th Even if I'm using an extremely strong and random passphrase, does this just require more signatures than normal, as if the code were to crack the combination needed bit by bit to even exfiltrate the amount needed to build the necessary raw seed bytes of the master private key?

CDN as in Content Delivery Network? If that's the case, just use OpenSSL which installed directly on your computer, rather than on browser.


I think it's hard to know which one is more secure. LibreSSL remove many unused code and support for older stuff, which means potentially less security issue. But it's less popular than OpenSSL, which means less people pay attention to it's code and security. It reminds of discussion which compare Linux and BSD security,

It is turned out that  a strong passphrase added to SEED phrase makes harder to perform Dark Skippy attack which needs substantially increased signatures to be successful. Thus the strong  passphrase along SEED can't hurt OP.

 Feel free to reap the benefits from reading the  content of this  topic on Dark Skippy attack

I think that the backup method using mnemonic words, which is BIP39, is just a form of backup, that is, your seed doesn't necessarily need to be secure, but your passphrase must compensate for its lack of security, although it's unlikely that a user will generate an insecure seed, since most wallets use a secure entropy generator and there are no reports of thefts due to lack of entropy.

Going back to what you mentioned, I still haven't found the best way to protect the passphrase (or extended seed word, as you prefer), but as you mentioned, this can be a good strategy.

At the very least, it's essential to keep the passphrase geographically separated from the recovery seed.

This is like you have a precious item, you pack it in a box and put a lock on it, then you put that box in another box and lock it with another key. Then again you put that big box in another box and lock it with another key. Now losing the key will get you in a lot of trouble 

My suggestion will be to generate an offline seed phrases and extend it with least four words. Now save them on a piece of paper and store it somewhere safe. That's it and you are good to go.
Another precaution can be to secure the extended four word phrase at some other place (paper). This way, even if someone gets your seed phrases paper, that is useless because extended seed phrases are stored in another place.

Interesting. Recently I had a conversation with a guy who made a software for offline text encryption, and he said that openssl is less secure if it utilizes cdn libraries. And also some people say that libessl is more secure that openssl.

Correct me if I am wrong, but MetaMask allows you to import individual private keys as well, doesn't it. If you can't enter a seed + passphrase, you should be able to import the private key of your ethereum account into MetaMask. MetaMask is a hot wallet. I assume it's the same with the other ethereum wallets, so whether you import a seed or private key doesn't really matter. But it does defeat the purpose of generating a seed offline only to use it later with a hot wallet.

Keep your bitcoin separate from your other cryptocurrencies. That's my tip.

Think about it a few seconds longer than you probably did. Many metal backups only stamp (or assemble) the first four characters of the recovery words because it's enough as every recovery word is unambigously identified with that.

Encrypted data or text doesn't give you this reduction for free: probably every single character of your encrypted text is important and shouldn't get lost otherwise decryption is likely to fail miserably.

If on the other hand the encrypted text isn't noticeably longer than the unencrypted source, well then you just need to be careful to avoid any errors. But the problem remains that you have to have a reliable backup of your encryption "key" which needs to be stored well separated from your encrypted text/data.

I have a feeling this is all a bit too fragile. There's no one recipe for all. Make a careful risk assessment and deploy remedies for your main attack vectors/risk you deem important.

@OP Only your first 2 steps make sense. The rest is some dull thinking to do more of the same stuff repetitively and you risk adding complexity. Human memory is very fallible. If you encrypt the seed, you can leave it around anywhere. In fact, I often wonder why the metal plate makers don't allow for saving encrypted strings than literally exposing the entire seed to anyone who finds it.

Krux does this, and it makes it easy.

Step 1: Load a seed into Krux.  Or use Krux to generate a new seed.

Step 2: Save the seed to a micro SD card, or save it as a SeedQR code.

Step 2.5: While saving the seed, choose to encrypt it.  Enter some text to use as a decryption key.  Done!

Better still: Improve the setup by using Krux to create a QR code for the text you're using as a decryption key.

Now, you can load your seed from the micro SD card, where it's encrypted, or by scanning the encrypted seed QR.

I love encrypted seed QR codes.

Scan the encrypted QR.  Scan the decryption key QR.  Done.

...but what if somebody finds your encrypted seed QR?  Nothing happens.  They can't decrypt it without the decryption key.

Here's an encrypted seed QR I made as an example.  I kept the decryption key simple for this example.  It's just a few words, all lowercase with a space between each.

You don't even need Krux to decrypt the QR.  They wrote code to decrypt them & posted the code on their github.

I think people are intelligent enough to understand for what reason such stuff is cloned. Besides, it is explicitly highlighted over there that those copies are backups. I don't  think that any extra words are needed than those ones already said in my topic. All stuff is straightforward for those who read it carefully.

Ok, that's great but I think you should warn people against this risk in your tutorial and recommending them to make several copies as you've done yourself because unfortunately digital safeguards are way more fragile than physical ones, even simple sheets of paper (you can throw a sheet of paper 10 times against a wall it won't be broken). Some people are using cloud services for storing their critical encrypted datas in order to avoid the danger of physical damage(including the electromagnetic one) of their devices  but a cloud service can also be easily shutdown, or datas can be erased from there without notice.

lexar or so is still consumer-grade. i never seen industrial-grade sd card.

I assume you reading of topic I have referred to was inattentive. That is why you have questioned me.

At the moment I have the set of  three cloned pgp dongles. Should one of them get damage it will be easily replaced by the means  of cloning from remaining ones.

Regarding hard disk. I don't use such stuff.  I use flash drives and industrial grade SD cards to hold Tails with all encrypted  stuff. They are  also clones and can be further cloned if needed. Some of these clones are geographically distant and kept by my relatives.  

Are you really sure that you need that much security and are you also sure that you'll be able to handle the responsibility? Keep in mind that the more secure you make it, the higher the responsibility will be on your shoulders.
By the way, Bitcoin seeds already guarantee a very high security and in practice, Bitcoin wallets are uncrackable. If you put a password on your seed phrase, you have to keep in mind that your password must be as strong as your seed phrases because what's the point of setting a weak password if cracking of it will reveal your seed phrases? Also, again, what's the point of setting a strong password (equal to 12 words) on them (i.e. having two 12 words seed phrase)? Just have a one, 12 words seed phrase or 24 if you wish, save it well, keep it securely and live your life. It's meaningless to make things complicated when there is not a necessity of it.

It won't be effective

You should use something like shred command in Linux


You should use GPG or openssl

.

I'm not sure if this scheme is actually great. It looks overly convoluted to me and frankly I don't know why it's that much layered, to be honest. @satscraper could you explain what kind of attack vectors you try to remedy or your reasoning with such a multi-layered approach?

Then indeed more points of potential failure are introduced, at first glance. The hardware keys would need copies otherwise you're pretty much screwed if you've only one and this sole one gets damaged, stolen or lost. (OK, after actually reading SEED storage on digital media., you use three hardware keys from Yubico, so it seems there's redundancy.)

I hope you've a hell of a good instruction manual for those who are supposed to inherit your stuff should something bad happen to you. And don't forget, you know your scheme well enough now, you constructed it. Years later and without much use, this could change as human memory is a fragile and changing thing. For those not involved in your scheme, instructions would need to be much more elaborate.

Don't get me wrong, I'm not per se against digital storage but I'd like to understand why such paths are walked and to what problems it's aimed to be a valid solution. People need to understand why handling such precious data like mnemonic recovery words and/or mnemonic passphrase on digital devices is potentially dangerous and how to do it safely.

And don't do fancy and complicated procedures just for the sake of it and because you can. There should to be a clear purpose and need for every layer of protection!

That's great but what will happen if your hardware dongle is broken or if you lose it? In addition encryption doesn't protect against damage. If your hard disk is damaged(physically or digitally) what will you do? Your private pgp key won't be enough to recover it unfortunately, the strongest the encryption is. Devices will never be as strong as your encryption can be, they can be destroyed or critically damaged at least, quite easily actually.

My SEED phrase is pgp-encrypted. The relevant private key is secured by hardware dongle. Encrypted SEED is inside protected  data base of  KeePassXC  which is placed in  encrypted partition (persistent storage area) of Tails. In fact I use the  four-layered encryption system. Think, nothing would be better. Interested? Then look here.

just using 7.1a right now. portable install.  windows 10.
if it's a problem to find binaries idk. use russian vpn and google for it
About other things you said  : authors make request like this only in one case. Think for yourself it's called