We absolutely will be having discussions with these wallets to understand what is valuable for them
Please note, I work for Brave on our security team and I’ve been syncing with our wallet team on this. I’ve also briefly discussed this with Metamask because I’m the person who originally reported the issue of key reuse to them when I was auditing our implementation and realized this wasn’t ideal so reported it to them.
My views represent at least a single wallet here. Additionally, from my brief chats with Metamask during the reporting process my impression was they have similar views to me here. My take away from it was they don’t consider this functionality a massive priority, but are still interested in supporting it if they can justify the effort for the change. I don’t speak for them and could also be misinterpreting their views though, so I’ll let them comment here if they wish.
I’ve also notified the Ethereum Wallets discord server of this topic to get their opinion on this topic (only 3 days ago) and so far no one has taken an interest other than @SamWilsn. I’m trying to provide legitimate feedback here, but I feel like I’m not getting anywhere and I’ve got 3 people who are digging their feet in every time I try and contribute. Right now, it seems it would be a better use of my time to cut my losses and work on a separate EIP. I don’t want to do this, since I’d rather be working with dApp developers who want to use these APIs, but I’m getting no where by doing this.
The EIP provides a sound encryption scheme that leverages only a single curve (the previous implementation juggled two)
Huh, I’m confused here, who only has to use a single curve? The dApp only needs to use a single curve whether it’s Ed25519 or secp256k1. The wallet needs to use multiple curves… sure, but that’s not that big of a deal from our perspective. In fact, we’ve already implemented it as such because we support Solana as well as EVM networks. Similarly, it seems like more wallets are already considering supporting multiple chains as they consider becoming multichain so I don’t think this is that big of a concern.
Originally, the security concern here that I reported to metamask was the reuse of key material for different operations that didn’t have a security proof. It’s not directly vulnerable, but it’s also not a crypto best practice and given millions if not billions of dollars depend on these wallets erroring on the side of caution was the same bet. I appreciate metamask taking the stance they have. With that in mind, this could easily be solved with just using a different salt with the KDF function. This would achieve the domain separation as defined in the papers I originally linked and is a smaller change than what @firnprotocol has proposed.
it also separates out the functionality of signing and encryption keys.
Can you be a bit more detailed in what you mean here? You’ve confused me here with this point because it seems like this contradicts the previous point that a single curve can now be used. The original design meets this requirement as well by supporting signing and encryption but not in a way that’s provably secure because the KDF digest is reused. That’s why I’m confused by this.