0
$\begingroup$

If a standard encryption scheme involves a nonce, as most do, can the nonce be used to hide another small message?

That is, the nonce (rather than being randomly generated) is a hidden message XORed with another secret key. As long as this other secret key is hashed/random and unique for each message, this is equivalent to random, right?

In an extended nonce setup (such as Xsalsa) 192 bits could be sent as a hidden/deniable message. I realise this is still tiny, but it seems truly deniable since you are using a standard encryption scheme, therefore overcoming the issue detailed in the answer here.

Aside from the obvious problem/hassle of exchanging a 2nd secret key and sending small messages as a series of larger ones, is this a viable idea?

$\endgroup$
1
$\begingroup$

You can do this, although the implications are limited.

  • If you have a secret key, an algorithm, and a communication channel that can send bytes, you can send an encrypted message.
  • It doesn't matter what secondary uses (i.e. nonce) that data may have. What matters is that they transmit the message.
  • Algorithms typically provide security proofs based on properties of the nonce. If the nonce is indistinguishable from a random number, it can be used as if it were a random number. If a nonce is not the product of two prime numbers, then it can be used as if it were not the product of two prime numbers. As long as your "nonce" obeys these properties, whatever they are, it will be secure.

In general, this idea is as viable as any stenographic system which hides the content in a protocol. Its validity depends greatly on a threat model. Your adversary clearly has the ability to observe your encrypted traffic (or there would be no need for stenography like this). Can they also require you to use specific algorithms? If your approach was popular, you might run into issues where the adversary mandates an algorithm for nonce. This algorithm may satisfy the proofs needed to ensure the underlying communications are secure, but be insufficient for use in your stenographic approach. (for example, they might require you construct nonce from a merkle tree, and provide them the frontier of the tree at any time to prove you are using their algorthm. This could decrease the bandwidth of your stenographic channel to any arbitrarially small amount)

The most likely issue would be an algorithmic proof of the underlying communication algorithm which depended on a property you no longer had. For example, there are communication schemes which depend on the unpredictability of an initialization value to prevent replay attacks. If your stenographic communications get cracked enough to start predicting the nonce on your future messages, you may become susceptible to replay attacks that you would otherwise be immune to. This is a case-by-case thing, so you'd have to go into the specifics of your underlying message stream to see whether such an exploit might accidentally arise.

$\endgroup$
3
  • $\begingroup$ Thank you for the answer. Very interesting point regarding being forced to use an algorithm for nonce. On your final point I was thinking the nonce algorithm could be built from existing algos. For anyone already exchanging ECC key pairs, they could simply exchange one shared key pair for the nonce/hidden key. You could also use the plaintext in some way, especially if it (or keys) were changing. $\endgroup$
    – Modal Nest
    Nov 30 '20 at 20:25
  • $\begingroup$ @ModalNest On my final point it wasn't the stenographic content I was worried about, but the plain underlying content. If the underlying encrypted communications that you are using to hide your stenographic message are important to you, you have to make sure that you didn't violate any of those rules. The existing algorithms all make clear what the rules are for their nonce, and if you violate them in the name of hiding a stenographic message, all of their proofs are for naught. $\endgroup$
    – Cort Ammon
    Dec 2 '20 at 21:45
  • $\begingroup$ Yes although I don't think you have much to worry about if you are exchanging new keys (for both message and nonce) per message. I suppose it depends on the exact cipher but usually a nonce is to allow for some sort of key reuse. PS. I'm not going to do this, it was just a question inspired by reading about Veracrypt. $\endgroup$
    – Modal Nest
    Dec 3 '20 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.