Description of the issue:
As a new user, I would like to better understand the internal sync process and assure myself that no “key escrow” system is in use, since I can’t use my own key. I would like to know how the bip39 code / sync seed is generated.
Steps to Reproduce (add as many as necessary): 1. 2. 3.
N/A
Brave Version(See the About Brave page in the main menu):
Version 1.77.100 Chromium: 135.0.7049.100 (Official Build) (64-bit)
Type of devices currently running on the Sync chain in question:
Linux PC
Additional Information:
I have been going through the forum posts and the source code on Git, but despite having looked into this a few times and spending an hour in the source code just today ( brave-core/components/sync/service at master · brave/brave-core · GitHub and brave-core/components/sync/engine at master · brave/brave-core · GitHub primarily), I still don’t understand the full process that generates the sync code:
From the FAQ,
Instead of letting the user pick a passphrase, which may be weak, we force the passphrase to be the BIP39 encoding of the sync seed.
What is the actual security around the sync seed generation (and the following steps of the protocol) to prevent people guessing it or otherwise cracking it?
Looking at the bip39 spec, a word count of 24 seems to imply a 256 bit entropy and that a resulting seed should be 512 bits, but is that what’s actually being used (and what’s it from)?
I’d also like someone to at least say that the resulting seed isn’t shared to the cloud someplace. I’ve not figured out how to run packet capture of TLS, so I have to trust that the implementation is as-stated regardless.
Bonus question: The FAQ also mentions key-stretching (I’m admittedly unfamiliar with this) and then using AES-128, so I’m not sure what the overall “limiting” security level is here even if the seed has a 256-bit source entropy, and I’m somewhat curious why Chrome’s sync protocol was used if it’s using a custom server.