[Enhancement] The payload position should not be predictable

[lcotonea]

The payload is now somewhere in the string instead of the first location candidate

[nandahkrishna]

First, thanks for taking the time to contribute @lcotonea!

This is something we were discussing earlier as well. I'm just adding small comment here with the potential issues we'd have to discuss. I think @mohanpierce99 and @JyothishmathiCV can elaborate and add their points too.

If the secret is hidden at the last possible space, it would be easily discovered when people just try to delete the text (with backspaces). They'd encounter a chain of backspaces after deleting the last word, which is a clear indication that something's probably been hidden there. This is something we'd have to address.

Placing the secret in the first position is comparatively better, as you'd reach it last when you're just deleting text. However, many previous projects and research use this approach, and people who have heard of StegCloak would certainly know where to look. So randomness would help, provided we can agree on a position limit – IMO it's okay for the secret to be in the first few spaces but definitely not the last few. How do we decide this limit? Looking forward to your views on this.

Finally, just a note on where I see this being useful. When you have just two or three words, or very short sentences in the cover text, the position doesn't really matter much. But with larger cover texts, randomness is appreciated, provided it's not easily discoverable (like at the end).

I hope I've articulated my views clearly here, but as I always say, the other maintainers know more and can add more valuable points to this discussion.

Finally, a couple of nitpicks as well, which I've pointed out (should've fixed them earlier but let's get them done here).

[JyothishmathiCV]

This discussion was something we were having for quite some time and therefore I thank @lcotonea for bringing it up so that we could get other's insight regarding the same. I will mention my views regarding this.

As stated by @nandahkrishna, the invisible stream must be present in the first few spaces and preferably the first one.

I would like to point out that the invisibility of StegCloak lies in the fact that people do not know the existence of such characters. This is achieved due to their invisible presence on the display.

However, if the presence of such characters is detected or considered, the position of the characters will not enhance their security. In fact if their existence is to be verified, It could easily be done so by using Ramda intersect function of the message and Stegcloak's array (like your Bruteforce check) where the position of these characters will not increase the difficulty in their detection.

The reason we chose the first space was because it doesn't really matter which space it is present in as long as nobody knows of their presence since the detection can be a simple intersection check. Therefore it is convenient to fix the first space for embedding.

So I would conclude it is not going to change anything, but if you have a valid justification please comment your thoughts :).

[lcotonea]

I thank you for your feedback.
I now understand the choice of the first character for the location of the payload.
I believe that steganography relies on discretion by using a public channel to expose encrypted information. It is true that the information is detectable, if you know where to look.
However I think that there are cases of use where the location of the payload must be random. The idea is not to strengthen the cache of information, but rather to free oneself from the constraint of the location of the ⁤⁣⁢‌⁣‌‍⁡⁢‍⁤⁡‌⁤⁡‍⁢⁣‌‍⁣‍‌⁢⁡‍‌‌⁡‍⁢⁣‍⁡⁤‍⁤⁡‍‍⁣‌⁢‌⁢‍⁤⁡‍‌‍⁡‍‌‌⁡‌⁡⁤‍⁤⁡‍‍⁣‍‌‍⁢‍⁤⁡‌⁡⁢⁡‍‍⁢⁡‍⁣⁢‍⁤⁡‍⁡‍⁡‍‍⁣‌⁢‍⁡‌⁢‌⁡‌⁡⁤‍⁤⁡‍‌⁢⁡‍‌‌⁡‍⁢‌⁡‍⁢⁣‌⁡⁢⁡‍‍⁣‍‌‌⁡‍‌‍⁢‍⁤⁢‌‍‍⁢‍‍⁡payload.
Example: let's say I receive several irc messages with a hidden message in one of them (I don't know which one). I'll copy the whole thing and run it through the reveal function. In this case, it is necessary not to look only at the first location where you expect to get the payload.
In conclusion, maybe the hide function can take an option to change the location of the payload (no use case in mind), so I leave it up to you. Nevertheless, I think the reveal function should be able to read the payload wherever it is in the text.

PS: an unencrypted payload is hidden in this text :)

[nandahkrishna]

I think that there’s value in the random placement. It takes effort to discover where the secret is hidden (even if that’s easily done with a function, still is effort nonetheless). Currently no such effort is required.

@lcotonea in my opinion we just need some minor tweaks with respect to the bounds for placement, such as not hiding in the last space. Any thoughts on this, and maybe a nice heuristic that scales based on the cover text size?

[lcotonea]

@lcotonea That makes sense. So what do you say if we keep the first space constraint but with Bruteforce check of the invisible stream instead of fixing it? By this, the reveal function would now be able to read the payload wherever it is in the text. Solving this use case of yours which I think is really good cause I've had similar problems at the same time maintaining the location.Kinda best of both worlds

For me it doesn't matter where. Besides, if I know that stegcloak encodes the payload in the first place, I'll know how to get the payload back.
As ⁤⁣⁢‍⁡⁢‍⁡‌⁡‍‌⁡⁢‍⁤⁡‍‌⁢⁡‍‍⁣‍‍‌⁡‍⁣⁢‍⁤⁡‍⁢⁡⁢‍⁤⁡‌⁢‌⁡‍⁣⁡‍⁢‌⁡‌⁢‍⁡‍⁣⁡‌⁡⁤‍⁤⁡‍⁢⁣‍⁡‌⁡‍⁣⁡‍‌‍⁡‌⁡⁤‍⁤⁡‌⁡‌⁡‍‍⁢⁡‍‌‌⁢‍⁤⁡‌⁢‌⁡‍⁣⁡‍‌‍⁡‍⁡⁤‍⁤⁡‍‌⁣‍⁣⁡‌⁢‌⁡‌⁢‌⁡‍⁢⁣‍⁡‌⁡‍⁣⁢‍⁤⁡‌⁡⁢⁡‍‍⁢⁡‌⁢‍⁡‍‌‌⁡‌⁣⁡‍⁡‌⁡‍‍⁤‍⁤⁡⁢‍⁣‍‌‍⁡‌⁡⁢⁡‍⁣⁡‌⁢‍⁡‍‌‍⁡‍⁣⁡‌⁡⁤‍⁤⁢‌‍‍⁢‍‍⁡soon as one knows the technique of steganography using UTF-8 hidden characters, it is easily detectable.
Finally, if stegcloak doesn't offer a reveal function that searches in any location, someone else will. The security of the "hiding place" cannot be based on the principle of secrecy.

@lcotonea in my opinion we just need some minor tweaks with respect to the bounds for placement, such as not hiding in the last space. Any thoughts on this, and maybe a nice heuristic that scales based on the cover text size?

Yeah, that's a good idea. Can you give me more information on the heuristics? I'd like to better understand your idea.

[nandahkrishna]

If we have just about five words in a sentence (and hence 4 spaces), we could use the first 3. But as the text gets larger, say 50 words, we could avoid not just the last one space but the last few spaces. How does that sound?

I haven’t really thought about the math but this is just us trying to make it slightly harder for a person to detect it. There are downsides to this too, so if we think that avoiding just the last place is better, then we’ll go ahead with that. Thoughts @mohanpierce99?

[JyothishmathiCV]

Maintaining a bound in such a way that the embedding will be within the first half of the text would be a good idea.

@lcotonea I think modifying the embed function to include this bound as follows would be great.

const targetIndex = Math.floor(Math.random() * Math.floor(arr.length/2));

[lcotonea]

@JyothishmathiCV @mohanpierce99 @nandahkrishna I'm ok with the embed modification.

[nandahkrishna]

Same here, I’m okay with the changes proposed.

[lcotonea]

Thank to you.
And what about the reveal?

Example: let's say I receive several irc messages with a hidden message in one of them (I don't know which one). I'll copy the whole thing and run it through the reveal function. In this case, it is necessary not to look only at the first location where you expect to get the payload.