Score:2

Crypto

Which service provider can create (claimable) accounts for managing Ed25519 keypairs (zero-knowledge fashion) by email

Ilya Nevolin

11/28/23, 8:35 PM

The title is a mouthful, allow me to explain my situation.

I have a SaaS with many users.
When new users join the platform, I want to create a cryptographic keypair for them (Ed25519).
But I don't want to have any knowledge about their private key.
This means the keypair must be generated and stored by a third-party service.

So I'm looking for a service, which has an API endpoint that works as such:

Calling that API endpoint with the email address of my new user
That service creates an account, a keypair, and returns me their public key.
The user gets notified by email, and is able to login to manage their own keypair (the claimable part).

Does a service like this exist? Maybe there's an SSL Cert provider which has something like this already?

No-goes:

I am legally not allowed to host/manage this service myself. The keypair ownership must be separated from my SaaS, so ideally I need to use a reputable third-party service.

1 + 3

ed25519

fgrieu

11/28/23, 8:52 PM

If you do not need to verify the id of new users, the standard solution is to have the keypair generated and stored on the client device. Even a browser with JavaScript can do this. If that's unsuitable please [edit](https://crypto.stackexchange.com/posts/103030/edit) the question with details of the requirement explaining why that can't be. If the user uses a mobile phone or a PC less than 10 years old, it has JavaScript and can generate, likely store keys using JavaScript code sent by your server to the browser.

Ilya Nevolin

11/28/23, 8:53 PM

@fgrieu unfortunately it's not an installable app, it's a SaaS. Storing these keys in the browser is not okay. And we also have users which have been invited to the platform, but have not yet joined. These "phantom" users need their key pair such that they can receive encrypted messages within the platform.

JAAAY

11/29/23, 9:13 AM

I don't think outsourcing the key management to a third party is a good solution. I think you better use the user's id and password as a seed to a kdf in order to generate a symmetric key to encrypt the key pair client side and store it in your server. This is something similar to what protonmail does.

Score:1

Crypto

JAAAY

11/29/23, 9:27 AM

I don't think outsourcing your key management to a third party makes any difference in the security of your application than doing the key management on your server. However, as you mention, you are not allowed to do the key management on your server.

In both cases, I think it is better to do the key management on your client without storing any data on it.

Assuming any user has a username/id and password, I propose you the following key management process:

For the key generation, a client generates the key pair locally. Using its user id and password as an input in a KDF a symmetric key is generated which can be used to symmetrically encrypt the private key of the pair. Now the private key can be send back to the server and stored there locally. The public key can be sent plain back to the server to process it as you mention.
In the case of an invitation, a client can retrieve its private key from the server and decrypt it using its id and password as an input to the KDF to obtain the symmetric key. Then a user can sign an appropriate message and send it to another user. Finally the other user the only thing that has to do it to provide the signed message he obtained to the server that will check if it is signed by a pre-existing user and allow the new user to use the service.

+ 5

Ilya Nevolin

11/29/23, 2:16 PM

Thanks for the comment @JAAAY ! Unfortunately this won't work. We don't want to ask our "users" to generate anything, all must be automatic. We also have "invited" users (which have not used our platform yet), but they need to have a keypair too, so their "limbo" accounts can receive encrypted messages within the platform. Which is why we need a third-party service to keep the keys for our users.

Ilya Nevolin

11/29/23, 2:19 PM

Also security wise it does have benefits. The separation of KMS and encrypted data has its benefits. If the encrypted data ever gets leaked, the keys will be with another service, so it's not a big deal. But if I did both KMS and data storage myself, that would be dramatic.

JAAAY

11/29/23, 2:35 PM

@IlyaNevolin Regarding to your first comment what you are talking about is called or is at least similar to Identify Based Encryption. I know that IBE using a Trusted Third Party has been solved from the beginning, you can search for a paper from Shamir. I don't know about the latest updates on the field and if you can do any better than this. Regarding your second comment, first I want to clarify you that this SE is mostly focused on theoretical security. From a theoretical perspective you don't achieve any more security through the separation, IMO it's more like security through obscurity.

JAAAY

11/29/23, 2:42 PM

Also a few other thoughts, in the setting that you mention where uninvited users have a keypair (that they don't acknowledge that exists) and also be able to have messages encrypted with this keypair I don't think that there can exist a secure scheme without a TTP.

Ilya Nevolin

11/29/23, 4:07 PM

I have users which own and manage their own keypairs, but there are many more which don't do this, so I "host" their keypairs myself on the platform; similarly for the "invited" users. I disagree about the security, because the data is sensitive and needs to be protected. If my platform ever gets hacked, the data remains encrypted as long as I am not in possession of the decryption keys. Likewise if some users lose their keys to an attacker, the attacked would also need to obtain their data ( so they need to attack 2 systems rather than one ). In both scenarios the data is more protected.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Which service provider can create (claimable) accounts for managing Ed25519 keypairs (zero-knowledge fashion) by email

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.