Encrypted back up

General
1

Hi,
I am trying to understand the workflow of the encrypted back up on microSD. I think it’s a great feature with the 20 digits decryption key. It makes the feature very user friendly comparing to what Coldcard does (12 words decryption keys).
However, I don’t get how it’s secure enough to use 20 digits, here is my understanding :

  • 20 digits = 10²⁰ => log2(10^20) =66,439 bits of entropy
  • 12 words (used by Coldcard) as encryption key = 132 bits of entropy

Am I missing something ? Thank you in advance for your answer !

2

While I’m not positive how Coldcard handles their backup, here you have a response from our CTO regarding the diffculty of breaking a 20 digit code.

Besides that, you can head over to our blogs area to read more on why we use encrypted backups.

Hope this helps!

3

The calculations Foundation Passport claims are not correct. Ifindpass.com is not a source that can overwrite basic mathematics.

10^18 possibilities you say in your pages. Well, Antminer can do 200+ TH/s, which is 20^12. You put up 50 of those running and you get 10^15 per second. In 1000 seconds or 16,7 minutes you get it open. With just 1 Anthminer power it takes about 16 hours to get it open. Ofcourse Anthminer does not crack open 7zip passphrase protections, but you get the basic idea of the numbers we are talking about.

If you must use digits as keys, you should have about 48 digits like Bitlocker recovery keys. Or atleast 40 digits if you want to trust 7zip password hashing = key creation scheme.

ALSO ONE OTHER THING:
However, this points out that Passport and ifindpass claims about 7zip password hashing are incorrect and that it is indeed much weaker that claimed and it only offers about 61 (from 20 numbers of Passport encrypted backup) +19 = 80 bits of encryption strenght:
“7zip, the encryption key is derived by running the password through the SHA256 hash function 2^19 = 524,288 times.”
https://www.loduarte.com/7z-aes.html

ALSO SECOND THING:
What version of 7zip does Passport use? 7zip have had numerous security vulnerabilities that can compromise the security of the device and even the strenght of the encryption, such as:

https://sourceforge.net/p/sevenzip/bugs/2176/

1 Like
4

Thank you Jack for your answer !
However I am not very convinced with the CTO message regarding the difficulty of breaking 20 digit code.
In my opinion, to secure data as critical as seed phrase, the decryption key need to be at least as strong as the seed phrase complexity (which is at least 128 bits).
I tend to be agree with anonfinn about the minimum of 40 digits to properly secure the back up (which represents about 132 bits of entropy).
Thank in advance for your responses.

Ps : I am not English native speaker, fill free to tell me of you don’t understand my post.

1 Like
5

If they wanted to upgrade their protection, one could use something like 8x5 (=40) digits, where the every 5th digit could be a checksum of the previous 4 digits incase user types in them wrong etc. This would provide effective strenght of 32 digits = 96 bits + 19 bits from hashing = 115+ bits that could be enought, yet still managed easily since its just numbers. That would mean in essense doubling the lenght of the encrypted backup digits. Ofcourse without every 5th digit being checksum of the previous 4 digits, you would get about 128 bit security from 40 digits alone (even without hashings) as it should be in optimal situation.

Other option to maintain compatibility with 7z manual decryption would be ofcourse to allow user to select their own passphrase for the backup instead of 40 digits given by Passport.

Anyway, the point Im more concerned about is the knowledge of the designers of the Passport devices, since they have competely missed this obvious security vulnerability, that shows their lack of basic understanding of encryption security: They have given wrong numbers in terms of the encryption strenght and only source they have is one webpage (and not the original source or the math). What else have they missed? What other basic errors have they made? How do those errors affect the security of the hardware and software of their products? What else is wrong? THIS is the main concern I have now.

6

Hi takeshi and anonfinn,

Thank you for your analysis of our backup encryption mechanism. Let me clarify several technical points about the implementation.

The 7zip format uses PBKDF2-HMAC-SHA256 with 2^19 iterations for key derivation, meaning each password guess requires 524,288 HMAC operations that must be performed sequentially. Each round of the HMAC requires two SHA256 calculations (in addition to some HMAC and decryption overhead), bringing us up over 1 million SHA256 operations per password guess. While Bitcoin ASICs like the Antminer S19 XP Hydro can perform 255 TH/s, they cannot be repurposed for password cracking as they are hardwired specifically for Bitcoin mining. The algorithm is literally etched into the silicon and they cannot be “reprogrammed” to perform PBKDF2-HMAC-SHA256.

Current high-end GPUs can perform around 80,000-100,000 complete password guesses per second of PBKDF2-HMAC-SHA256. With our 20-digit, truly-random passwords (10^20 possibilities), a single GPU would take approximately 31.7 million years to try all combinations. So an attacker focused on cracking the password in a 1-year period would need to commit 31.7 million GPUs for an entire year, just for that one wallet. Attempting to crack it in 6 months would require 63.4 million GPUs, etc.

The cost of these GPUs would be billions of dollars, not to mention the electricity costs, facility costs and personnel costs. This is obviously not even remotely feasible.

Regarding implementation details, we use Python code to read/write the 7zip file format rather than the 7zip program itself. Our initialization vectors (IVs) are generated using three independent true random number generator (TRNG) sources with a length of 16 bytes, so we are not subject to the IV-related vulnerabilities you cited. The LostMyPass comparison was just a way to show that another company, whose entire business is attempting to brute force passwords, validates our crack-time calculations, confirming our security margin calculations are accurate.

While longer passwords would indeed provide additional security margin, our current implementation balances strong security against practical attacks with usability. The key derivation function’s sequential nature, combined with our random 20-digit passwords, ensures that even well-funded adversaries with significant computational resources would find cracking attempts impractical to say the least.

Let’s keep in mind here that the use case is to secure a microSD card that you should keep stored in a safe place (your literal home safe or a safe deposit box, or in a box hidden in your basement). This file is not online, and nobody will have access to it unless they get physical access to your storage location. And even then, if you simply rotate your bitcoin every 1,000 years or so to a new wallet, you will be fine.

3 Likes