Asymmetric encryption and decryption support

[AndreasGassmann]

I can see that there is support for encryption and decryption for nacl using secretbox. But it looks like it is symmetric because the encrypt method needs the secret key.

Are there plans to add asymmetric encryption (encrypt with public key, decrypt with public key) as well?

I'm specifically looking for support for a sr25519 keypair. But I haven't found any other implementations that do this. Are there plans to do this, if even possible?

The use case is basically that this would allow you to encrypt a message for a specific address owner.

[jacogr]

There are the naclSeal & naclOpen methods which have been contributed. I believe they fit the bill. (Have not tried myself, so cannot vouch for sr25519 compat)

Will take a play though, it may make sense to expose some seal/open methods on the keypairs itself if sufficient compat. can be achieved. No promises atm.

[AndreasGassmann]

Thanks for the response. I have to admit that I don't have a deep understanding of cryptography, but what exactly is the difference between sr25519 and ed25519? If I understood correctly, then sr25519 has improved signatures in comparison to ed25519, but does the encryption/decryption still work the same way?

In our library I was able to successfully add encryption/decryption for ed25519 using libsodium, but when I try to use the method with the sr25519 keypair I get an error (I don't remember which one).

I didn't see the naclSeal and naclOpen methods, thanks for pointing them out. However I'm a bit confused because it looks like the naclOpen method needs the senders public key.

export default function naclOpen (sealed: Uint8Array, nonce: Uint8Array, senderBoxPublic: Uint8Array, receiverBoxSecret: Uint8Array): Uint8Array | null {
  return nacl.box.open(sealed, nonce, senderBoxPublic, receiverBoxSecret) || null;
}

Also in the test, it seems that there is a step missing where the sender sends over his public key:

    const sender = naclKeypairFromString('sender');
    const receiver = naclKeypairFromString('receiver');

    // Make id key for identifying each other
    const senderIdKey = fromPath(sender, keyExtractPath('//1//1//1//1').path, 'ed25519');
    const receiverIdKey = fromPath(receiver, keyExtractPath('//2//2//2//2').path, 'ed25519');

    // Receiver sends encrypting public key to receive message to decrypt with his private key
    const receiverIdBoxKey = naclBoxKeypairFromSecret(receiverIdKey.secretKey);

    console.log(`Receiver sends receiver's public key to sender ${receiverIdBoxKey.publicKey.toString()}`);

    // Sender encrypts message to send with the public key the receiver sent and send it to receiver
    const senderIdBoxKey = naclBoxKeypairFromSecret(senderIdKey.secretKey);
    const message = new Uint8Array([1, 2, 3, 4, 5, 4, 3, 2, 1]);
    const { nonce, sealed } = naclSeal(message, senderIdBoxKey.secretKey, receiverIdBoxKey.publicKey);

    console.log(`Sender sends encrypted message to receiver ${sealed.toString()}, ${nonce.toString()}`);

    // Receiver opens encrypted message from the sender
    // Question: How did the receiver get the senderIdBoxKey.publicKey? Is this even necessary?
    let opened = naclOpen(sealed, nonce, senderIdBoxKey.publicKey, receiverIdBoxKey.secretKey);

In my own implementation with libsodium I'm using my own publicKey and secretKey to open the box and that seems to work. So it's probably not necessary to send over the senders public key? If that's the case maybe you could rename the parameter in naclOpen to make that clearer.

[jacogr]

Not a cryptographer... however, sr/ed both use the same curves, but sr uses a different (more sane) clamped range. There is some compat, but you cannot use ed keys as sr (range difference), will ask around on the reverse. (And the availability of encrypt/decrypt on the schnorrkel library).

So the answer on the compat -

"No. It's the same curve but not the same subgroup of the curve, ristretto used the prime order subgroup, and not the same representation for that prime order subgroup. The point is ristretto only permits serializing and deserializing prime order points. "

So cannot use the existing ed* functions.

[AndreasGassmann]

Thanks for clarifying that.

Did they say why there is no encrypt/decrypt for sr*?

It sounds like I will have to put this on hold until there is an implementation available :)

[jacogr]

schnorrkel does provide it via the aead module, https://github.com/w3f/schnorrkel/blob/master/src/aead.rs - not exposed in the wasm, but can be.

The only caveat is that it is not deemed stable atm.

[AndreasGassmann]

Thanks, so we'll wait until that is deemed stable and is exposed in the wasm.

[jacogr]

This issue has been open for 21 days with no activity and is not labelled as an enhancement. It will be closed in 7 days.

[AndreasGassmann]

You are free to close this issue if it's not something that you are looking into, but we are still eagerly waiting for this feature to be available (and stable) so we can include it into AirGap Vault.

[polkadot-js-bot]

This issue has been open for 21 days with no activity and is not labelled as an enhancement. It will be closed in 7 days.

[polkadot-js-bot]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.