How is the same decryption key generated on all devices

[lastmjs]

I've been looking through the code and I have a question. The private key used to do the original encryption to store data in the key sync canister...how is that key shared on other devices?

So if I log in the II and generate an encryption key, and then I completely delete my local storage and log in again with II, how am I able to generate the same key pair so as to decrypt any data stored in the key sync canister?

[timohanke]

It's not the same decryption key on all devices. It's one decryption key per device and there are multiple ciphertexts stored in the canister.

Nevertheless, your observation is correct. If you delete the local storage then you lose access, at least on that device. To recover you have to log in with one of the other devices, remove the device on which the local storage was deleted, and re-register that device.

I would like to find a way to extract a seed from the secure element so that we can get the same seed again any time later, but haven't found a way to do that. WebAuthn is really built for authentication only, not for other interesting things such as encryption/deterministic RNG/secret store/etc.

[lastmjs]

Ah, okay this is what I was getting it. You have confirmed my suspicions on the inability of WebAuthN to provide encryption derived solely from the private key material of the device managed through WebAuthN.

[lastmjs]

Could you provide a deterministic challenge to the secure hardware through WebAuthN, and always get back a deterministic (but still random) signature from the hardware?

[lastmjs]

Hmm...could this not work, assuming I'm thinking about it correctly? You send some deterministic challenge to the device, such as the hash of the public key of the user. Assuming WebAuthN always returns the same signature given the same challenge and device, couldn't you then use that to seed generation of some kind of keypair able to encrypt?

[timohanke]

Yes, but there doesn't seem to be a deterministic signature scheme. It's either EC-based which is by definition not deterministic or RSA-OAEP which is RSA "made non-deterministic". There may be other hacks but none that I was able to find yet.

[lastmjs]

Okay, just to make sure I understand, you're saying that with WebAuthN the signature returned with the challenge is non-deterministic?

[timohanke]

Yes, that's right. In the WebAuthn specification I only found signature schemes that are non-deterministic. You could also use a public key as the seed if you can get that out somehow. However, the WebAuthn interface doesn't seem to let you just ask for a public key. But someone should check again.

Another possible way would be to recover the public key from a signature. But I didn't see that work either at first glance but someone should check again.

[jddllwqa]

Why can Internet identity share a public seed phrase? I can't understand the logic in depth, but I always feel that if handled in this way, it is not perfect, because II itself is safe enough

[jddllwqa]

Sorry, I see that the IC does not really store a seed phrase, but a signed result.

[timohanke]

@jddllwqa I have problems understanding the question or comment. Did you mean to say "What can" or "Why can't"? The term "public seed phrase" seems to be a contradiction in itself. Seed phrases are never public.

Are you saying that some of ICVault's functionality should be provided by II?

[jddllwqa]

Like @lastmjs, I hope II can provide a shared key for all device who login II because II itself is trusted and secure. At present, I am also developing products based on key sync canisters, but due to many steps, it is not very friendly to users! Thank you for your efforts. I hope you can find a better solution together!

[timohanke]

What is the application of the shared key? Is it encryption like here in icvault or is it something else?

[jddllwqa]

https://medium.com/@DstarApp/a-blockchain-notebook-based-on-internet-computer-1bc6d3768892
@timohanke
This is meduim's article. we will indicate the source when we open source!

[jddllwqa]

@timohanke
Because the content on the IC is not encrypted! Therefore, we need a shared key to encrypt. At present, key sync canister are the best solution!