But, why use a key stretching algorithm for this particular scheme to begin with? What is it protecting against here? The master key is presumably high entropy. If someone gains access to the master key and breaks into your server a key stretching algorithm isn't going to help you.
Lots of secrets get sent through the clipboard. Anything handling it either needs to be strictly local or E2EE. Otherwise everything is vulnerable if someone breaks into the server. It's also accessible by you at will regardless of any promises you might make to the contrary.
Seamless cross device sync isn't an excuse. E2EE itself doesn't impede that whatsoever, only certain protocol choices that aren't (or at least don't need to be) relevant here.
100% agree - If this app gets any traction at all, it's only a matter of time before someone's crypto wallet gets leaked and emptied.
If you want to be handling peoples secrets, you have to make sure you know what you are doing and build something bombproof (bombproof from a mathematical perspective, rather than relying on your server being secure)
But, why use a key stretching algorithm for this particular scheme to begin with? What is it protecting against here? The master key is presumably high entropy. If someone gains access to the master key and breaks into your server a key stretching algorithm isn't going to help you.
Lots of secrets get sent through the clipboard. Anything handling it either needs to be strictly local or E2EE. Otherwise everything is vulnerable if someone breaks into the server. It's also accessible by you at will regardless of any promises you might make to the contrary.
Seamless cross device sync isn't an excuse. E2EE itself doesn't impede that whatsoever, only certain protocol choices that aren't (or at least don't need to be) relevant here.