Zero width character's can be used to hide text in plain sight.I am building a system where user's can provide their secret message , cover message and a password (key) which I would encrypt and give an output back with only the cover message which has encrypted secret message embedded as zero width characters invisible.When the receiver provides the key with the message, the system would decrypt and translate the zwc's back to the original secret message.

The cost of zwc's is that every two bits can contain one zwc as there are only 4zwc's available in unicode.So to represent a character 'b',it takes 4zwc's (ZWJ,ZW-NJ,ZWS,ZW-No break space).

I have been using AES with ebc mode and I encrypt the secret message with the key given by the user,but due to padding even if the user's secret message is 'hi' its padded as 16bytes when encryption due to aes block size.This means to convey 'hi', I needed 16bytes and due to zwc inclusion its 16*4 =64chars.So I researched more to find cipher text stealing where len(p)=len(cipher text) eliminating padding which is exactly what I needed.But during this process I came to know that EBC mode is insecure and CBC should be used (pretty late realization).CBC requires an IV which takes one byte again imposing more restrictions on my zwc situation.If I don't use a fixed IV, every message is suddenly two bytes 128 characters with zwc.

According to my research,fixed IV's can be used if you key changes in my case user's give the keys to encrypt so technically key changes but as its a password two messages from the same user is encrypted with the same key cause same password.Is it safe to use a fixed IV In my situation.

And I dont understand according to wiki,len(p)=len(ct) for cipher text stealing but if a fixed iv is not used len(p) is never equal to the length of the cipher text?

Can I use cbc with fixedIV and cipher text stealing for my situation?

Is this the right way to design this ? Cause this is my first crypto project


1 Answer 1


First of all, the use of zero-width characters is what we call obfuscation and indeed stenography. The encryption part that is described seems separate from it.

Generally we don't encrypt each element separate, we encrypt the plaintext and then try to hide the plaintext. Encryption generally needs something to make the key / IV unique otherwise you would get the same ciphertext for identical messages. In your situation it is only safe to use a fixed IV if a unique salt is used for each key that you derive from the password using a password based key derivation function or PBKDF. Of course, instead of having to store an IV you'd now have to store a salt.

CTR mode only requires a nonce rather than an unpredicatable IV. The nonce is a unique value of any size. Because of that the overhead of using the IV is much smaller. Alternatively, if you're stuck to CBC + CTS, you can use a nonce as IV for CBC by encrypting that initial IV with AES to derive the actual IV. IN both cases you might need to right pad the (initial) nonce with zero bytes before you can use it.

I don't see anything about a PBKDF in your description so your design probably still needs a lot of work. However, you are seeing the problems and you ask the right questions, and at this stage that might be more important.

  • $\begingroup$ Thanks for the reply ! if we use a random IV and embed it as the first block while having a fixed salt and generating a key using PBKDF, will it provide the desired security over using a fixed IV and a random salt.I guess both of em are the same. CTR looks great and it has no padding as its a stream cipher but can u elaborate on the nonce part why iv is better than nonce and the alternative you provided . Thanks again $\endgroup$ Apr 25, 2020 at 16:44
  • $\begingroup$ #1 No, you should always use a random salt. A good PBKDF will add a unique salt and a work factor so that validating the key derived from the password is hard. The random IV does not protect against that. #2 IV is not necessarily better, but many programming interfaces require a full 16 byte IV for CTR. $\endgroup$
    – Maarten Bodewes
    Apr 25, 2020 at 17:50
  • $\begingroup$ Completed the lib. THANKS! for the help Design : davidwalsh.name/demo/2020/05/steganography-5.png Git: github.com/kurolabs/stegcloak $\endgroup$ Jun 26, 2020 at 11:58
  • $\begingroup$ @MohanSundar OK, that part looks OK, except maybe that 32 + 8 doesn't equal 48 in my book. $\endgroup$
    – Maarten Bodewes
    Jun 27, 2020 at 0:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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