When it comes to evaluating a text steganographic approach, I think we have to consider these things:

  1. How unlikely it is for someone to guess that there is a hidden message in the message being sent?
  2. How large a hidden text can be stored in a cover text of fixed size (larger the better)?
  3. How hard is it for someone to decode a message should it get suspected?

It is easy to quantify 2 and 3.

But how do I arrive at a quantitative way of measuring 1?

PS: Please assume it is a text-in-text steganography approach.

Are there any metrics for that?

  • 4
    "1" seems highly opinion based and will be hard to measure reliably.
    – user42178
    Mar 3, 2015 at 19:32

2 Answers 2


Whether it's text in text or other kind of steganography, you don't care at all about your points 2 and 3. They are incidental factors.

The only thing you should be concerned about when talking steganography is point 1 "Is my steganographied content distinguishable from normal content". If we see the problem as an attacker, you have an infinite number of document to analyse, you know how to break a steganographied content (know the algorithm) but you do not have the time to test all this algorithm on all the documents. So you need to have a program that will analyse the content and output a (kind of) binary answer : "there is a message in there" or "there is no message in there". In the real life, you would rather get a statistic like over 95% certitude there is a message in the document.

There are countless article in the state of the art that describes stego-methods of analyse the resistance against different types of attacks (Andreas Westfeld F5 implementation, Jessica Fridrich et al. steganalysis of F5)

As you can read in the literature, the quantitative way of measuring this point is statistical analysis.


The way to know if it is likely for somebody to suspect that hidden data exists is to establish a checklist of indicators. These indicators are anything that arise when the file is pitted against its non-stego'd variant. This may include:

  • File size being out of bounds of what one would expect
  • TimeStomp detection
  • The contents of the file being suspect (odd spacing, sentences not making sense, etc.)
  • Etc...

Basically, compile a list of forensic techniques, as well as imagine yourself as the recipient of such a file. What indicators would tip you off that the file isn't quite "right?"

This list becomes your checklist, and you can even apply weights to certain ones if you feel they matter more or less. Then use the checklist to quantitatively score a file using your metrics.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .