Re: A revision of my text stego scheme

On 11-05-21 1:52 PM, Mok-Kong Shen wrote:

That is true, but it shouldn't take more than a few tries with jbriggs'
method. By hiding two bits in each line, you would have quadruple the
number of tries, but it should still be feasible.

It may be my subjectivity, but I still find it difficult to understand
why one wants to try a few times to get one bit right, while, assuming
common competence in language, the modifications are IHMO trivial to do.

I think you are right that it is subjective. But all other things being
equal a deterministic process should be preserved. So I agree that this
is an advantage for your scheme. But it isn't a significant one in my
subjective view.

An advantage of jbriggs' approach is that every bit in the text line
matters instead of just looking in one place. By spreading the
information out it is less likely to be detected.

One need in most cases only to change one word. If that modificaton
is done not too bluntly, I don't think that's easy to be detected.

But because the change is always about one thing (length) it really is
going to be much easier to detect. I am really confident about this, but
I don't have the skill to prove that I am correct.

For one thing, if the message is not random then there will be
statistical artifacts in the line lengths of messages. I know you plan
to have the data well encrypted before it is concealed, but can you
really ensure that people will always use it properly that way.

With the hashing scheme and a shared secret appended to the text before
hashing there should be no statistical clue to the principles of the
stego system.

The hashing scheme also has the advantage, as jbriggs pointed out, that
it isn't limited to lines. You could have a bit encoded in every 50
characters or using some other scheme. This has the advantage that you
could actually have your the scheme ignore whitespace, so that if a
message were reformatted in transit your data would still be extractable.

Furthermore you could add some encryption by having a shared secret that
is appended or prefixed to each line before hashing. This means that
even if someone suspected you were using such a hashing mechanism they
wouldn't be able able to reconstruct your hashes without your shared

I don't need that. As I wrote in OP, the stego bits should preferrably
be encrypted (by a sufficiently strong algorithm).

Fine, I was pointing out that you get some additional crypto practically
for free and that it will make the stego harder to detect.

Keep in mind that if the text doesn't make sense (say in one place you
talk about something happening on Monday and later refer to it as
happening on Tuesday) suspicions of stegonagraphy will be raised.

That depends on context. I don't mean that "generally" you do that
kind of change. If in a message there is only one mention of Bill's
travel, saying that he is arriving on Monday (or Tuesday), what
harm could there result?

You are correct. If a human is making the changes to get this to work
then the human can make sure that the carrier message makes sense. I was
concerned about something that automatically modified the message also
changing the meaning. It would be hard to have an automated system that
changed the meaning but resulted in a plausible meaning.

What I like to stress is that the scheme could be done by everybody 'on
the street'

I would replace "on the street" with "without special tools". Anyone on
the street can be trained to use software as well as they could be
trained in your method. The difference is that yours is a "paper and
pencil" scheme. As long as users take care to destroy the bits of paper
they use in computing these, they have much greater deniability.

and that certain agencies should probably from now on, in
addition to automatically screen emails for certain keywords, develop
appropriate methods to automatically screen emails (also usenet posts
and sources of HTML) for stegos.

We know that at least some people who are of interest to these agencies
prefer to use systems they fully understand instead of systems that
provide more security.

From that article:

Bangladeshi Islamic activists who were in touch with Karim had
rejected the use of common modern systems such as PGP or TrueCrypt in
favour of a system which used Excel transposition tables, which they
had invented themselves.

But the underlying code system they used predated Excel by two
millennia. The single-letter substitution cipher they used was
invented by the ancient Greeks and had been used and described by
Julius Caesar in 55BC.

Karim, an IT specialist, had used PGP, but for storage only.

Despite urging by the Yemen-based al Qaida leader Anwar Al Anlaki,
Karim also rejected the use of a sophisticated code program called
"Mujhaddin Secrets", which implements all the AES candidate cyphers,
"because 'kaffirs', or non-believers, know about it so it must be
less secure".

As I'm mentioned in other threads, it is fun to develop systems that the
users fully understand. But using such systems where it matters is
almost certainly going to be a mistake.



Jeffrey Goldberg
I rarely read HTML or poorly quoting posts
Reply-To address is valid