That's a great way to mask the contents of a seed phrase, but is it really worth the risk of forgetting it?
Keep in mind that most people's hard drives are like museums with a bunch of old lost files and folders relegated to the archives section - where they are never viewed again - after someone opens them once or twice.
Decryption inevitably will store the seed somewhere in plaintext which makes any kind of encryption implementation vulnerable to side-channels (as almost everyone is running this through some 3rd party terminal or GUI).
Hi, the algorithm doesn't store the seed(as I said, there's no information in the crypto file). I don't actually find the vulnerability of side channels attack. I would appreciate if you can point out the vulnerability.
The side channel attack is not present in your algorithm directly, however it can be found indirectly inside the other software the end user is using to run your decryption algorithm inside and store the output. I mean: The terminal, text editor, the clipboard, the filesystem driver, those kind of things.
Hi, thanks for your explain.
In BIP39, all the seed using same word list. So, this cause every backup phase is random.
The idea of the algorithm is every seed has its own word list. So, we can customize our own backup phase to it. And we can prove the word list related to the seed and customized backup phase is fully randomized. And this means, all the information of the seed is just stored in customized backup phase.
The decryption method is same as the BIP39, just mapping the customized backup phase to the word list(related) to get the seed. The decryption method is sample, straightforward, easy.
If this algorithm has the side channel attack problem, the BIP39 also has.(Cause they use same process.)