New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to store wallet in browser storage without exporting the key #1838
Comments
Oooh. Interesting point! At minimum, we must point this out in the README (#1911). I love your proxy key solution, but implementing it would pierced the veil of secrecy between the API and the actual bytes of the private key. Anyone who got a reference to the polyfilled key could just Until there's support for Ed25519 keys everywhere, I think wherever there's an application where you need to store the keys locally you'll just have to do it in the conventional way (eg. generating your own and storing it, using |
Thank you for having taken the time to review this. How about implementing a unique flag at the start of the proxy key, which would prevent key extraction in the polyfilled With a big enough KEY_HEADER (32 bytes?), real-world key collisions should not be an issue. let rand = crypto.getRandomValues(new Uint8Array(32));
let header = KEY_HEADER;
let key = new Uint8Array(header.length + rand.length);
key.set(header);
key.set(rand,header.length);
let proxyKey = await crypto.subtle.importKey('raw', key, 'AES-GCM', true, ['wrapKey']); crypto.subtle.exportKey = async (format, key) => {
let pk = await originalExportKey('raw', key);
if(pk.slice(0, KEY_HEADER.length) == KEY_HEADER) {
throw new Error('can not export key');
}
// ...
} |
Yeah, exactly. And so can an attacker, by grabbing a fresh copy of const frame = document.createElement('iframe');
document.body.appendChild(frame);
const stolenKey = await frame.contentWindow.crypto.subtle.exportKey('raw', proxyKey); |
The current implementation of the ed25519 polyfill does not support storing keys in IndexedDB without exporting them. As per the W3C Web Crypto API, a
CryptoKey
should implement the structured clone algorithm, enabling direct copying without exposing the private key to JavaScript.To address this, I propose to add a CryptoKey directly into the generated keypair instead of using a memory store.
With this approach, we can identify a polyfill key by checking if
_proxyKey
exists. Here's an example of how thesign
function could be implemented:This change allow to create or load wallet from index db like this
The text was updated successfully, but these errors were encountered: