-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Export/Load seed via encrypted file on microSD card #31
Comments
Yes I would definitely use this to move between devices and create multiple encrypted backups. Great idea! |
I like this. Additionally, adding the option to export the seed into two or three seeds generated using Coldcard's XOR feature. Its similar in that you need multiple pieces to reveal the seed but with XOR you can use the individual seeds as decoy wallets. Downsides being that its obvious its a seed phrase. |
Sounds like a good feature and agree that it would work very well together with SeedXOR (see SeedSigner/seedsigner#43) The encryption password can be problematic as it needs to be long and be verified. In any case an encryption password verification step is needed to avoid ending up with the false security of an unusable backup. Would be great to be able to use this 2of3 like scheme with the SeedSigner also: https://github.com/openoms/bitcoin-tutorials/blob/master/backups/coldcard.md#coldcard-single-seed-multi-location-backup-scheme edit: a long password should be enforced |
Scrappiness is such a desirable trait, imo. I like this thread, and this activity. Thanks folks for letting your voices be heard! I'll share my thoughts on this after I've chewed on them a while.
|
recommendation: have a few options to manage the MicroSD. Such as
|
@Semisol great point. A LUKS encrypted partition (with a long password) is the best to not run into information leaks whenever the SDcard gets lost or reused. In this case I think the long password (eg. the CC style 12 words) should be enforced. |
Yes, I can see how this would make it easy for this particular use-case.
I'm good with giving the user the choice to either have a password generated for them, similar to how the Passport does, or allowing the user to supply their own password (and accept the risk that it may not be as strong). It should ultimately be up to the user if they want to use different passwords for the same or different seeds. The SeedSigner itself, being stateless, cannot even determine if the user is doing this. |
If the user can input their own password OR use a 12 word password we could possibly use the same menu for inputting a seed for the password (and checksumming!) |
ColdCard also uses an encrypted backup file. Similar to the Passport, they both use 7z for file encryption and the contents are similarly formatted. |
Very well written and described Feature Request. Well done ! And agree that is it needed and eliminate the hassle to have to bring a plaintext seed if necessary to travel or move and use the SeedSigner which is not very practical. However one thing I would remove from the above requirements is that the seed would not be stored in the same SD Card as the SeedSigner one. I don't see that as a big issue really. It is still very secure as long stored in a encrypted file by a passphrase. And it can encourage people to move from HotWallets stored seeds in their PCs to SeedSigner with this feature to improve security which is a very significant thing. This still makes SeedSigner usage a lot more secure than a traditional HotWallet by not having it to ever connect to the Internet and completely offline. |
Optionally as mentioned above one alternative to the encrypted file is to have a small LUKS encrypted partition with passphrase which would use well know technology and open-source software available. |
Just a note that supporting and challenging opinions were shared in the telegram community group today. |
@jdlcdl thanks for the update. Would you mind replicate the main points here as this is probably the most appropriate tool to achieve this improvement so everybody following can be aware and contribute ? |
@jdlcdl can you share the details please ? |
The reason I don't cut and paste directly from the telegram group is that it's for those users to do themselves. I hint to those members to share it in github if they so choose, so that it's easier to find and work on as a developer. But if they don't decide to do that, then I only leave a pointer for those here who are willing to go find it in telegram... and I usually give a fair time frame. That there were discussions around this topic on May 22nd in telegram is all that I want to share, and everyone is welcome in telegram to see what that discussion was about. The group link is: https://t.me/joinchat/GHNuc_nhNQjLPWsS |
Hi @jdlcdl If they don't decide to do you could do yourself. What matters the most are that the ideas and possible solutions to be brought for discussion in this appropriate tool and be implemented if they make sense. You can even ask if you can do on their behalf or if they wish credit for it or not, but the most import is to share with community and have an ideal solution for this feature request that is very needed. |
A common criticism against SeedSigner is the requirement for the seed phrase to be in plaintext form, either as words typed manually or as a SeedQR code. This limits the storage options of the seed's physical backup for users that spend frequently. The response to this has been to use strong passphrases to protect the wallet and/or use multisig, but this does not solve the issue of being able to improve the physical backup's security.
Additionally, traveling with a SeedSigner requires bringing the plaintext seed phrase (as words or in QR form) with you, or to memorize them. When a traditional hardware wallet user can bring the device only, and leave their backup at home (or in a safe place). This still creates a risk to those users, though, because hardware wallets are becoming more popular and can be easily identified. Storing an encrypted seed on a microSD card raises almost zero alarms on the traveler, since they are general purpose and extremely common. The user would have to be specifically targeted in order for any authorities to even know that there is encrypted data on the card.
This proposal/feature request provides the user with an additional option for seed storage, but is likely to break the "single location of a key" property, which is popular in the community. This option also allows the project to avoid secure elements entirely, which have been discussed in the community on several occasions, by storing the keys in an encrypted state on a microSD card. It should also be stressed that this is not a replacement for BIP39 passphrases, and as will be shown in the user workflows, passphrases can (and should) still be used.
Foundation Devices recently made a blog post on encrypted microSD backups which provides more information on the benefits and tradeoffs. Their format for storing the seed is available in their docs. There exists an opportunity to work with the Foundation Devices team to develop a standard for both encrypting/decrypting backups, and the format in which the data is stored (currently a simple text file).
High-Level Points
A final point that needs more detail: this is not a replacement for multisig or passphrases, is not specific to singlesig setups, and should still fully support multisig setups. Loading a seed from an encrypted backup is simply another option for loading a seed, and can be used in combination with multiple encrypted seeds stored on multiple microSD cards, written/memorized mnemonics, and SeedQRs.
Downsides
User Workflows
Exporting Workflow
Loading Workflow
The text was updated successfully, but these errors were encountered: