Steganographic key transfer in fake encrypted e-mails

Users who are unable to meet in person have difficulties securely exchanging public keys. Adversaries are blocking transmission of DeltaChat QR codes and invite links. This is cheaper than MITM attacks, and a more feasible way of accomplishing mass surveillance.

I suggest the obvious: deniably disguising public keys as encrypted e-mails. I would not be surprised if there is already a standard for this somewhere.

User experience

  1. Alice and Bob are aware they both use Deltachat. Alice knows an e-mail address for Bob. They have a shared secret, which they can agree on by context code.*
  2. Alice sends Bob a steganographic invite, typing in a shared secret.
  3. Bob gets a nonsense e-mail. He clicks on “extract key”, and types in the shared secret.
  4. Alice and Bob now have an E2EE connection.
  5. Optionally, they verify fingerprints.

*for instance, if the shared secret is the incredibly stupid thing Alice once said to Bob about cheesegraters (which she knows he’ll remember verbatim a decade later), then Bob says “I got a message from you, but I didn’t understand part of it”, and Alice says “Oh, it’s about that incredibly stupid thing I said about cheesegraters”.

What happens

Alice’s client takes some info, say:

  1. The shared secret
  2. The addresses of sender and recipient
  3. The UTZ date of sending
  4. An arbitrary and variably-long string of padding-salt
  5. Alice’s public key

…and hashes it into a fixed-length string that looks like the contents of an encrypted e-mail. The client then cats this hash to the padding-salt, and uses the resulting string as the body of the fake encrypted e-mail.

Alice sends this fake encrypted e-mail to Bob.

Bob’s client runs the inverse of the hash algorithm. Crucially, this inverse algorithm should produce something that looks plausibly like a public key when you run any encrypted e-mail through it, and it should be moderately compute-intensive.

Alice and Bob rotate keys.

Mallory

Mallory, assuming she knows in advance that Alice and Bob are attempting to swap keys, could block one specific e-mail, in which case Alice and Bob could try again. Assuming Mallory also somehow knows what terribly silly thing Alice said about cheesegraters, she has one chance to launch a MITM attack.

If Mallory guesses wrong, she will be deleting a random encrypted e-mail and replacing it with one containing nonsense, which is a pretty conspicuous behaviour and will alert Alice and Bob. On a large scale, MITM attempts also have substantial costs.

Alice could also tell Bob that her key is the fifth message among eight decoy emails, upping costs further.

Making such a deniable steno hash standard adapt to future longer keys might be tricky.

What is your threat model?

If Delta Chat usage is illegal?

If A and B both have a shared secret - why not use it directly for encryption?

Why do you need steganography at all?
There are existing solutions for public key distributions.

How exactly they do it? Is it purely theoretical, or there are some real live situations?

This is a real situation. Deltachat QR codes and invite links are easily recognized, and blocked, cheaply; this seems to be happening.

Threat model: authoritarian government with substantial control over communications, including ability to intercept and modify, but with limited resources, and unwilling to block all encrypted mail.

A shared secret is useless if your comms are blocked. I assume the secret is not prearranged but preexisting, and may not have any specific trait, like length.

So I asked “What is an easy way to transmit a key between DC clients in a form that won’t get blocked?”

1 Like

There are no details.
In short - I’ts hard to block specific text or image.
It’s much easier to block specific server or whole protocol.

I’m sorry, I shouldn’t have linked to that. An example from the news: the PRC government silently dropped all messages on Weibo that contained the word “Beijing”, for some hours. I think if they can do that, they can drop all links in the delta.chat domain.

I didn’t answer your question about legality. If it is not safe to send encrypted mails, it is not safe to use Deltachat. This method looks like an encrypted mail and can therefore be used anywhere Deltachat can be used.

The shared secret is not strictly necessary. Even if it is absent it makes life harder for Mallory. But if I asked you, and a friend of yours, to pick a shared secret without communicating at all, you’d stand a chance of success.

Sure.
But it’s trivial to cut the link to pieces and give instruction how to assemble it back.
Or send a password-protected document or archieve.
You need to trick the parser, that’s easy.
Steganography is really overkill here.
And if it is really needed - there are already tools for it.

Ok, alternative proposal: create long mail logins, use them as public keys (private key should be created first), use that public key for initial mail.
But it will lower the barrier for spammers…

that is unrealistic, I think you misunderstood that person, I think they are worried about government blocking opening the links, ex. in Cuba https://delta.chat and https://i.delta.chat pages are blocked, this means if people try to open an invite link in the browser the page will just fail to load, but people can still share links the same way they would share any other piece of data in private using platforms not in the control of the government, some platforms try to open the links directly with internal webview instead of just letting the system open the link normally, that is a problem (I am looking at you, Facebook and Telegram) but otherwise the link will open directly with delta chat without using network at all, people can still open the link going to the QR screen in delta chat and using the menu option “paste from clipboard” there or just sending the link in “Saved Messages” and clicking it

1 Like

I think you may be right that I misunderstood. I think the user had this misconception. I remember reading a report that looked into what people wanted from encrypted comms, and found devs more worried about surveillance capitalism and open-source, while users didn’t much care as long as it didn’t expose them to state or quasi-state oppression. Physical safety reasonably trumps more abstract ideals.

This is a solution to the “I have no secure channel to transmit my keys” problem. If the problem is not there, the solution is useless. :slightly_smiling_face:

I think it could be implemented as a webXDC app.