šŸ§™Tsatnosk is a user on manowar.social. You can follow them or interact with them if you have an account anywhere in the fediverse.
šŸ§™Tsatnosk @zatnosk

: Given a private key (priv-A) and an unrelated public key (pub-B), is it then possible to create a translation key (trans-A->B), such that a ciphertext encrypted with pub-A can be translated ("transcrypted") to the corresponding ciphertext encrypted with pub-B without being able to decrypt the ciphertext with just trans-A->B?

Such a construction would make one-to-many end-to-end encryption just as easy as one-to-one.

Ā· Tusky Ā· 1 Ā· 0

This would make it possible to redirect messages to another device owned by the same recipient, without sharing private keys between devices, and without exposing metadata about number of devices owned and which device is used for a given communication.

@zatnosk

Not without knowing both priv-b and priv-trans.

The typical use for asymmetric keys are for setting up a stream cipher. You typically create a new stream cipher for every session, using each other's public keys for the negotiation phase only.

If you were broadcasting an encrypted message to many recipients, you would use each one's public key to send each a copy of the stream cipher key, then just broadcast.

@ghedipunk I was afraid of that. The problem is when you want to send to my device A, but that device is down, so I receive it on device B that wasn't involved in creating the stream cipher. Then it would be practical to have a translation key of some sort to translate the encrypted message to something device B can decrypt.

@zatnosk

Why not give device B the private key that's on A?

There are plenty of reasons why you wouldn't want to... but generally, if B can be authorized to decrypt messages for A while A is down. I treat my keys as identifying people and applications, rather than identifying servers.

Otherwise, if B shouldn't have A's private key, then either the sender can retry with B as the recipient or B can store the ciphertext until A is available again.

@ghedipunk I'm looking at this from a P2P perspective. I don't want to have a key on more than one of my devices (I have more than three), and if I brought my phone on a trip, I don't want to wait until I can get home and turn on my desktop just to decrypt messages.

But at the same time, I don't want to tell anyone I talk to how many devices I have, and which device I'm using right now.

Ideally they should send to one key, which I could then decrypt regardless of which device I use.

@zatnosk When I saw your earlier question, I wondered whether it might be possible to find some relationship between secret keys (privkey_a and privkey_b) such that the person possessing both keys might be able to create a transformation function that would enable them to decrypt messages encrypted with pubkey_a using privkey_b ... but I suspect that might also lead to a discoverable relationship between pubkey_a and pubkey_b and weaken the particular version of asymetric encryption in use.

@zatnosk

The first couple of things that come to mind are

1) Use a dedicated crypto USB device (U2F or similar) that can decrypt and sign messages without leaking the private key to the host it's attached to.

2) Have a server that has its own key pair, that will then encrypt the message to each device for the final hop. (Might be able to also have a web interface on that server with TLS and read the owasp.org cheat sheets on authorization and authentication, if you don't want to re-encrypt.)

@ghedipunk good suggestions, but...
1) can't be used on phones and tablets
2) suddenly not peer2peer anymore, dependent on one or more servers, and can't be used offline / over LAN.