Topic: Foundation Passport Official Thread - page 12. (Read 6045 times)

Wow, your complication of their simplification taught me more about crypto than I've probably learned in the last 6 years (and yeah, I'm that ignorant of what's under the hood).  Hope it's not too off-topic to thank you for that with a comment and some merits.

I absolutely agree with you, and that pearl of wisdom I'm happy to say I did know.  Ledger announced their recovery thing in an attempt to bring their wallets to the unwashed masses, who probably aren't nearly as paranoid as they should be about crypto.  What I hope is that making devices less secure so as to make them more marketable doesn't become a trend among HW wallet manufacturers--or at least that they make things like cloud backup and recovery via distributed shards and who knows what else optional rather than required.

And that they're transparent about it, too.  I'm lookin' right at you, Ledger.  Tsk tsk.

Your statement is unfortunately somewhat inaccurate. I'm not completely sure about the details, but both platforms require using 2FA, without an option to skip it.

From what I can tell, Apple requires 'hardware 2FA' which as a side effect notifies the user on all their devices when someone tries to log in on a new device:
https://support.apple.com/en-us/HT204915

Google apparently does allow you to use highly insecure SMS 2FA, but at least they advise against it, for what it's worth...

I've also read about the way iCloud encryption keys are generated and to the best of my knowledge, there is no known bypass / successful attack to date, besides (obviously) first- and second-factor compromise. I do think Google Cloud contents have been leaked in the past, although if they use good encryption, that shouldn't be a problem.
Let's keep in mind that we're talking about backing up a hot wallet here. So compromising the second factor for your cloud (your phone) is equivalent to compromising your hot wallet. No added risk through the backup, and added safety against data loss (e.g. through device destruction).

Bottom line is: if you have strong encryption of your files, you can post the backups anywhere you want, even on a public forum. But the question remains: how to back up these encryption keys. In case you have a secure enclave on your hardware that you trust to generate and store such keys, you do 'reduce' (in the logical sense; not quantifying) the security of your seed phrase to the security of this hardware.

I think it's fine to have such a solution, if users are aware of this fact and this circumstance is made explicitly clear.

---

I'm not interested in this cloud backup myself, because I'm happy with my current backup solutions. However I like the idea of having a way to back up the wallet configuration (user settings, account labels, ...) - without private keys. I even pondered about a standardized format for this a while back; something like a universal 'wallet export / import format'.

---

Edit: From what I can tell, this cloud backup only refers to the hot wallet, making it completely 'fine'. To the best of my knowledge, Envoy cannot access Passport's seed phrase at all; that's the whole point of a hardware wallet.

Digital or online/cloud backups as replacement for physical offline copies of seeds isn't and shouldn't become any sort of standard in the future. If it was Ledger that had something like that, everyone would lose their mind. I understand it's optional and you don't have to use it, but it's a dangerous option to have.

Yeah, I had no idea this was a "feature" Envoy offered...


I'm sorry, but this is horrible. You reduce the security of your seed phrase, and therefore all your coins, to the security of your Apple or Google account, which in many cases is only a simple password (and often a leaked or reused one at that!) or an insecure 2FA method which can be fairly easily
intercepted such as SMS. I would also wager that the subset of users who feel they cannot use a seed phrase properly and would back up their seed phrase to the cloud overlaps pretty heavily with the subset of users who have substandard account security or general security practices.

Is this in any way usable with a Passport, or is it confined to Envoy only?

I'm not sure about the new recovery system, but until now, the microSD backups were just encrypted files that you could open on any computer and unzip, giving you a regular old seed phrase to import anywhere you like.

I am not familiar with Envoy or Magic Backups, but I just looked at your YouTube video where you explain the backup process. It involves storing sensitive information in digital form and on Passport servers. Encrypted and hashed but this is still a potential security threat. And it's a less secure way of storing private data than offline physical backups on paper, metal, etc.   

Just to clarify and alleviate some concerns, no solution we come up with for backups would lock a user into our ecosystem, it would always be portable in some way.

Magic Backups for Envoy's mobile wallet (not applicable for Passport) are a perfect example of that, where a user can use Envoy and never realize there is a seed phrase behind it, but can *always* recover funds in any wallet through the settings, where they can find a standard seed phrase. We also will be adding in prompts for users after a certain time period to back up the seed itself for maximum sovereignty, but we want options that allow users to start in a seedless manner.

But nothing we ever build will lock users into a walled garden, and will always have industry standards under the hood and accessible to users in an emergency (like BIP 39).

With seed phrases, you always have the freedom to recover your coins elsewhere for any reason. With a "Foundation Passport Backup System X", you are stuck with that one product because no one else supports your recovery scheme. Unless, of course, you can get some other wallets to implement it as well. And if there is a bug or it malfunctions, you will be required to wait until the devs find a way to fix it. Not to mention the devastation if they completely abandon it or it breaks down for whatever reason.

The problem with coming up with your own system is exactly that - it is your own system, which no one else uses. You therefore lock the user in to your ecosystem and entirely dependent on your products if they want to recover their coins in the future, which is a dangerous scenario to be in. If you give users the option of using a seed phrases alongside your new system, then there are two possibilities. Either the user ignores the seed phrase and just uses your system in which case you are back in the same scenario, or the user uses both systems in which case your system hasn't removed the need for seed phrases at all.

Happy to be proven wrong, but I just don't see how this would work.

I might be a bit old-fashioned but I have always been of the opinion that if it isn't broken, don't fix it. I think that users who aren't capable of writing down and storing 12 English words in paper format are too spoiled and crypto might not be suitable for them. If they can't even do that, I see them struggle with other essential elements of the game.

Still, it's good that you trying to simplify an already simple process. How is that going btw? What would you like to replace seeds with but still not impact the security of the new storage method?

128 bits of security. Their bits of entropy will depend on how they were generated, for a maximum of 256 bits.

My only concern with using 12 words is you cap your entropy at a maximum of 128 bits. If your entropy is generated properly, then your private keys will have 128 bits of entropy and 128 bits of security. But if your entropy generation process is flawed, you can reduce the entropy and therefore the security of your keys below 128 bits.

If you use 24 words and your entropy generation process is flawed, you can reduce your entropy much below 256 bits while still keeping 128 bits of security.

Spot on with the analogy!

The user experience of seed phrases can be quite poor, so we're continually looking for ways that we can abstract away the seed phrase experience for new users especially. Not an easy problem to solve, though!

Well, since Bitcoin private keys have 128 bits of entropy, you aren't improving the security of those keys by increasing the entropy of your seed. That's the gist of it. It's like making your wall stronger without realizing you have a glass window that is easier to break through. The security of Bitcon private keys isn't comparable to glass windows, I am just trying to make a point.

What did you mean when you said the following in your blog post:
Do you not like the term "seed" and would like to see a different one? Or, do you not like the seed itself, as in the 12/24 words we use for backups?

Thank you, those are excellent corrections! You're correct that they're all technically true and I was oversimplifying a bit to make it approachable, but took your advice and found ways to integrate it without overcomplicating the messaging, I think.

Can I suggest some corrections? I suspect you already know these things, but it is better to be precise rather than to attempt to simplify things and end up presenting inaccurate information.

The range is not 1 to 2²⁵⁵, but rather 1 to just under 2²⁵⁶. If you wanted to be really precise, 1 to 2^{255.999999999999...}. By saying 2²⁵⁵, you are actually cutting the number of valid private keys in half. 2²⁵⁵ also doesn't match with the 115 quattuorvigintillion figure you then use (which is indeed 2²⁵⁶).

That's not accurate either. If we assume all private keys are generated randomly, then half of them will have a leading zero and therefore be at most 255 bits. A quarter of them will have two leading zeroes and will be at most 254 bits. And so on. These keys aren't any less secure. If you force all private keys to be 256 bits long (i.e. start with a 1 rather than a 0), then again you are excluding half of all possible private keys.

I think you mean "fully functional public key" here. That one number is your private key. The private key does not need to be generated from that number, only the public key does.

This should read "private keys".

This isn't strictly correct since with a 12 word seed phrase, 15 of every 16 possibilities on average can be immediately discarded due to an invalid checksum. The number used should be 2¹²⁸, not 2048¹² (which is 2¹³²).

I think that this kind of commentary is fair to the topic of any product that has competitors (and if they are similar or sharing code), and very well and seemingly fairly presented by RickDeckard.. as usual RD provides sources for his assertion and seems to describe what is going on in a mostly reasonable way - even if some of it might be tied to his opinion, too.

One of the matters regarding the creation of an "official thread" should have been to create this thread as "Self-Moderated," and so it seems that OP had made the mistake of not making this thread self-moderated (which I believe cannot be changed after the thread has been started as not self-moderated), but OP could make a new self-moderated thread if he believes that some of the criticisms and/or drama might be going too far, too distracting and taking away from the topic overall (or maybe his preference to promote the product without having some potentially heavy hitting contrary statements....and if he would like to have a more clean thread that he is able to control any kind of controversial commentary that might come into the thread, then he would likely need to create a new self-moderated thread (unless there is a way to change it to self-moderated after it had already been created, which I doubt.. I think that the forum does not like to change threads in the self-moderated kind of a way after they have already been started). 

Surely, I had heard some of the accusations that Foundation had stole the code from the cold card, and whether those are fair-game criticisms may well be taken into account in any thread that is not self-moderated...so long as there are attempts to otherwise stay topical.. and whether or not personalities might be relevant to the conversation, too.

FE does run the latest firmware, yes.

There are some high-level block diagrams on GitHub (of course also the actual schematics), but the general architecture has barely changed:

Founders Edition:
You have to look more into the hardware repos I linked to, but from what I recall, the new hardware is only very slightly different. The codebase is now identical for both devices.

We dropped a new blog post that I thought was worth sharing here, as we're coupling it with a commitment to transition Passport to 12 words by default in an upcoming firmware release and in new packaging (as well as any future hardware wallets):

https://foundationdevices.com/2023/06/make-12-words-the-standard/

Would love to hear all of your thoughts on the topic! We will of course never force anyone to transition an existing 24 word seed, and will always give the option of 24 words for those who want to use one. This will just affect the default for new users 

Nice work!
It's interesting that Coldcard also appeared on WalletScrutiny website, and I don't remember I noticed it before.
Cypherock X1 wallet also made it in top 7 list of reproducible HW.

I see Passport Founder's Edition is showing Discontinued note, but can they still be used with latest firmware updates, and what are the main difference compared with Batch2 in main board level?
Case is much better in new model, as well as display, but I was asking about chips, processors and code.

He would probably be terrible in role of Satoshi.  
I don't want to talk about NVK, and I don't know what is in his head, but I think he felt his business was going down after Passport appeared and he didn't like that someone else (other than him) is using open source code.
Let's get back on topic - Passport wallet.

Thanks for the info, but let's try to refrain from turning this thread into a "He said, She said" bickering match.  I know some members can't refrain themselves from stirring drama, but so far this thread has been steadfast in sticking to the topic at hand, and it would be disrespectful and shameful for it to get derailed.