SirensOfTitan
commented
6 years ago Hey Peter! You're right, and I think it's doubtful we'll see anything other than the r1 curve being supported the SE.
What we're doing today is essentially: we generate a k1 private key and an r1 private key, then we encrypt the k1 private key using a symmetric encryption strategy and we store that k1 key inside the Apple keychain. This means we need the decrypted key inside main computer memory when we sign transactions, but only momentarily before we can throw it away. I'm about to clean up our key generation process, and want to be a little cleaner so at the very least we explicitly autorelease the decrypted key in memory so it's only there for the very small moment we need it to compute signatures (eliminating typical attacks like memory dumps, although these are already much more difficult to execute on non-jailbroken iOS than other platforms).
I looked into the smart contract solution, but without support for the r1 as a pre-computed curve, it would be incredibly expensive to do any manual validation inside a smart contract (AFAIK), and of course this opens us up to a lot of bugs by writing our own mechanisms for doing this, so the benefit honestly is questionably worth it even if we did have a pre-computed curve.
Support of the NIST 256r1 curve would be wonderful in some capacity, but there's just still so much resistance because a lot of people think it has a backdoor (I haven't looked recently, but there's some discussion in https://github.com/ethereum/EIPs/issues/28). It's unfortunate, as while the backdoor hypothesis is only rumors and whispers, the security benefits for almost any typical user would skyrocket for support of this curve. If I were an idealist, I would love to see the community (both hardware and software) rally behind curves like Curve25519 as it's safe, super fast, and has really awesome implementations.
If you have any ideas, please say!, we just want a secure, easy to use library for building good crypto apps on mobile.
ptrwtts
In your blog post, you mention this:
Is this true? I was under the impression that the Secure Enclave used secp256r1 to generate signatures, whereas Ethereum used secp256k1 (r vs k). Therefore, the only way to use a Secure Enclave generated key would be with a smart contract wallet, that did it's own verification of signed messages. Is this correct, or do you have some way to generate Ethereum compatible keys in the Enclave (cool if so!)?