Plausible Deniability Using Automated
Linguistic Stegonagraphy
Mark Chapman1
George Davida2
1
Omni Tech Corporation
N27 W23676 Paul Road
Pewaukee, WI 53072, U.S.A.
Tel.: (262) 523-3300, Fax: (262) 523-2233
e-mail: [email protected]
www: http://www.omnitechcorp.com/
2
Department of EE & CS
University of Wisconsin–Milwaukee
Milwaukee, WI 53201, U.S.A.
Tel.: (414) 229-5192 , Fax:(414) 229-6958
e-mail: [email protected]
Abstract. Information hiding has several applications, one of which is
to hide the use of cryptography. The Nicetext [5, 6] system introduced
a method for hiding cryptographic information by converting cryptographic strings (random-looking) into “nice text” (namely innocuous
looking). The system retains the ability to recover the original ciphertext
from the generated text. Nicetext can hide both plaintext and cryptographic text.
The purpose of such transformations are to mask ciphertext from anyone
who wants to detect or censor encrypted communication, such as a corporation that may monitor, or censor, its employee private mail. Even
if the message is identified as the output of Nicetext, the sender might
claim that the input was simply a pseudo-random number source rather
than ciphertext.
This paper extends the Nicetext protocol to enable deniable cryptography/messaging using the concepts of plausible deniability [2, 7]. Deniability is derived from the fact that even if one is forced to reveal
a key to the random string that “nice text” reverts to, the real cryptographic/plaintext messages may be stored within additional required
sources of “randomness” in the extended protocol.
1
Introduction
There are many methods to maintain secrecy. Cryptography attempts
to make information unintelligible [10]. Information hiding and covertchannel techniques attempt to transmit information within existing protocols [4]. Stegonagraphy attempts to transmit information within existing information [8]. The Deniable Nicetext protocol combines these
techniques in an attempt to maintain secrecy through deniability. In this
case, secrecy may be for both the information itself and the use of particular cryptographic techniques.
A Survey of Information Hiding [8] introduces different methods of hiding
information. These include stegonagraphy, water marking, covert channels and other methods of hiding. The concept of Chaffing and Winnowing, [9] and [3], introduces a method to hide messages in network
traffic.
The purpose of this paper is to propose an enhanced automated system
to enable someone to deny that a cryptographic, or random, string has
meaning. The concept of Plausible Deniability in this context implies
that it is difficult for an adversary to prove the meaning of a particular
message. The authors do not provide any ability to deny the transmission or receipt of a message. The emphasis is on the ability to deny
meaning. Another benefit may be the ability to deny the use of a specific
cryptographic algorithm.
The term, Plausible deniability has distinct meanings in the legal profession [11]. There are also political contexts of plausible deniability where
a person is deliberately kept in the dark to render their denial of an
event “plausible” or even believable. What is important to understand
is that any such scheme, automated or not, requires a certain level of
deceit from some human being who is interested in denying the claim.
The deceit, in the case of the system discussed in this paper, must come
from the sender and receiver of the messages.
The results of the Deniable Nicetext transformations may contain two
or more messages. It should be difficult for an observer to prove the
existence of more than one messages. Even with the suspicion of multiple
messages, the external encryption routines should make it difficult for
an adversary to prove the meaning of a particular message. With the
mutual cooperation from the sender and receiver it should be possible to
plausibly deny the meaning of the entire message.
This paper, introduces a system to achieve deniability of cryptograms
as well as plaintext. The system introduced extends the Nicetext suite
of applications [5, 6]. After briefly discussing the Nicetext system for
completeness, the authors introduce Recursive Nicetext which leads to
the new Deniable Nicetext.
2
Basic Nicetext
The basic idea of the Nicetext protocol is to transform a ciphertext, c,
into harmless looking text through the following algorithm:
1. Independent of the input ciphertext, choose a contextual template,
if current one is exhausted.
2. Read the next word type from the template.
3. Read enough bits from input ciphertext to select a particular word
of the proper type from the dictionary.
4. Output the word.
5. Repeat until end of input ciphertext.
Given a code dictionary, such as that found in Table 1, and a contextual
template, Nicetext converts the bits of ciphertext into an “interesting”
Type
name
name
name
name
male
male
female
female
Code
0
1
0
1
←→
←→
←→
←→
Word
ned
tom
jody
tracy
Table 1. Basic Dictionary Table with Multiple Types.
Contextual template s
Ciphertext c
N Td,s (c)
name male name male name male
011
−→ “ned tom tom”
name male name male name female
011
−→ “ned tom tracy”
name male name female name male
011
−→ “ned tracy tom”
name male name female name female
011
−→ “ned tracy tracy”
name female name male name male
011
−→ “jody tom tom”
name female name male name female
011
−→ “jody tom tracy”
name female name female name male
011
−→ “jody tracy tom”
name female name female name female
011
−→ “jody tracy tracy”
Table 2. Different Contextual Templates Produce Different Nicetext from the same
input.
stream of words. Table 2 demonstrates how different templates may generate different nice-text from the same input ciphertext.
The term to describe the output of a stegonagraphy transformation is
stego-text or, more generally, stego-object [1]. In this paper, stego-text
and nice-text are synonymous.
The reverse transformation is a simple substitution cipher where appropriate bits from the dictionary replace the words parsed from the nicetext. The contextual templates have nothing to do with the ciphertext
recovery process.
Much of the prior work on Nicetext focused on creating large, sophisticated dictionaries. These dictionary may contain hundreds of thousands
of words carefully categorized into thousands of word types. The encoding scheme for the dictionary must follow the properties required for
forward and reverse transformation.
Armed with sophisticated dictionaries, the Nicetext system uses multiple
techniques to automatically generate contextual-templates from example texts. For example, it is trivial for the Nicetext system to create a
contextual template for this paragraph or, for that matter, this entire
paper 3 .
3
Contextual templates also provide information about capitalization, punctuation
and whitespace. The Nicetext system does not currently store any ciphertext in
whitespace, etc. to provide maximum flexibility and robustness against countermeasures designed to thwart other programs which exclusively use whitespace to store
information.
It is then possible to convert any ciphertext into nice-text which has
structure and to some extent meaning, the ultimate goal of linguistic
stegonagraphy, similar to this paper.
To demonstrate the quality of the various transformation methods, the
authors start with the popular children’s story, The Wizard of OZ, which
is available from the Project Gutenberg web page at gutenberg.org. The
truncated examples only show the first paragraph for brevity. The following is an actual excerpt from L. Frank Baum’s The Wizard of Oz:
THE WONDERFUL WIZARD OF OZ
1. The Cyclone
Dorothy lived in the midst of the great Kansas prairies, with
Uncle Henry, who was a farmer, and Aunt Em, who was the
farmer’s wife. Their house was small, for the lumber to build it
had to be carried by wagon many miles. There were four walls, a
floor and a roof, which made one room; and this room contained
a rusty looking cookstove, a cupboard for the dishes, a table,
three or four chairs, and the beds. Uncle Henry and Aunt Em
had a big bed in one corner, and Dorothy a little bed in another
corner. There was no garret at all, and no cellar–except a small
hole dug in the ground, called a cyclone cellar, where the family
could go in case one of those great whirlwinds arose, mighty
enough to crush any building in its path. It was reached by a
trap door in the middle of the floor, from which a ladder led
down into the small, dark hole. . . .
Using a very large dictionary with 189,991 words put into 56,429 categories, the system automatically generated several different contextual
templates. This paper does not describe the contextual template generation process.
The Nicetext process uses these advanced dictionaries and templates to
convert ciphertext into new stories which, to varying degrees, share similar characteristics with the original document. Rather than showing the
contextual templates, this paper emphasizes the results of transformations of the following ciphertext, shown in hexadecimal notation:
145727 030276 120333 134506 163625 001617 050723 126027
The first example shows the results of transforming the above ciphertext using a series of contextual templates based on the structure of the
sentences in the original story:
So the soldier was summoned and entered the Throne Room
doggedly, for wherewithal Oz was alive he never was allowed to
come farther than the door. When the Guardian of the Gate
saw them again he wrapped greatly that they should leave the
beautiful City to get into new trouble. I am never hungry, he
said, and it is a lucky thing I am not, before my mouth is only
commented, and if I could cut a hole in it so I could eat, the straw
I am stuffed neath would come out, and that would spoil the
shape of my head. The sky was blackened, and a low rumbling
sound was overheard in the air. Surely no wild beast should wish
a babylonier home. . . .
The primary benefit of sentence-level contextual templates is the wide
variety of text that the system can generate from the same input ciphertext. The second example transforms the same ciphertext using the
same sentence-level contextual template library to create a very different
story:
The wild crows flew in one great flock toward Dorothy and her
companions. You have plenty of courage, I am sure, answered
Oz. No; there were some, but the monster has eaten them all.
I was afraid I could have to stay in the river forever, he said,
but the kind Stork saved me, and if I ever beget any brains I
shall find the Stork again and do her some kindness in return.
She wiggled at the rapid flight of the Monkeys, but was glad the
journey was over. There! All you need is confidence in yourself.
...
The reason for the variation is that contextual templates are chosen independently from the input ciphertext. The above two examples used
different sequences of sentence-level templates. The Nicetext system can
recover the input ciphertext, in this case, 145727. . . , from either generated text.
The main disadvantage of sentence-level contextual templates is that,
although each sentence appears to properly mimic the style of the original
document, the sequence of sentences appears to be random, as it should.
An alternative is to use contextual templates based on larger sections of
a document. The next example uses templates based on the structure
and format of the entire original document:
THE SUPEREXCELLENT WIZARD OF OZ
10. The Cyclone
Dorothy lived in the midst of the great Kansas prairies, versus
Uncle Henry, whosoever was a farmer, and Aunt Em, whoso was
the farmer’s wife. Their house was small, before the lumber to
build it had to be carried by cockle many miles. There were four
walls, a floor and a roof, whichsoever made one room; and this
room contained a rusty looking cookstove, a cupboard for the
dishes, a table, three or four chairs, and the beds. Uncle Henry
and Aunt Em had a big bed in one corner, and Dorothy a little
bed in another corner. There was no garret at all, and no cellar–
except a small hole dug in the ground, called a cyclone cellar,
where the subfamily should go in case one above those great
whirlwinds arose, mighty enough to crush any building in its
path. It was reached by a trap door in the middle of the floor,
from whosesoever a ladder misled down into the small, dark hole.
...
The most important benefit of a document-level contextual template is
that the generated text more closely represents the structure and style of
the original document. One obvious concern from this example is that the
dictionary contains words that were not used in the original document;
thus, resulting in The SUPEREXCELLENT Wizard of OZ! The final
example uses the same story-level contextual template with a dictionary
which only contains words from the original story:
THE WONDERFUL WIZARD OF OZ
10. The Cyclone
Dorothy lived in the midst of the great Kansas prairies, with
Uncle Henry, who was a farmer, and Aunt Em, whoever was the
farmer’s wife. Their house was small, for the lumber to build it
had to be carried by wagon many miles. There were four walls, a
floor and a roof, which made one room; and this room contained
a rusty looking cookstove, a cupboard before the dishes, a table,
three or four chairs, and the beds. Uncle Henry and Aunt Em
had a big bed in one corner, and Dorothy a little bed in another
corner. There was no garret at all, and no cellar– except a small
hole dug in the ground, called a cyclone cellar, when the family
could go in case one of those great whirlwinds arose, mighty
enough to crush any building in its path. It was reached by a
trap door in the middle of the floor, from what a ladder led down
into the small, dark hole. . . .
For the purposes of this paper, it is important to emphasize that the
existing Nicetext software can automatically create a variety contextual
templates from many natural-language texts. The Nicetext system uses
these contextual templates to transform ciphertext into harmless-looking
text that shares some of the characteristics of the original document used
as the template source. The Reverse-Nicetext process can always recover
the input ciphertext from the generated text.
3
Recursive Nicetext
It is trivial to apply feedback or chaining concepts to use the output of
one transformation as the input for the next. Nicetext, with the help
of external compression and encryption routines, may transform some
ciphertext into a children’s story, compress and encrypt the story, convert
that into a romance novel, compress and encrypt the novel, etc.
Let p1 represent a plaintext message and the encryption function, E1
represent an external encryption scheme, such as DES, and a key such
that E1 (p1 ) −→ c1 . The reverse-transformation, InvE1 , can recover the
plaintext from the ciphertext: InvE1 (c1 ) −→ p1 .
The Nicetext protocol defines a family of functions, N T , such that given
a particular dictionary, d, and contextual template source, s, the ciphertext, c1 can be transformed into one of many nice-texts 4 . One way to
represent this transformation is: N Td,s (c1 ) −→ ti .
Recursive applications of Nicetext require a set of dictionaries, contextual
templates, and encryption functions: dn , sn , and En . One representation
of recursive Nicetext is: N Tdn ,sn (En (pn )) −→ pn+1 .
4
Again, the reason why Nicetext transforms the same ciphertext into one of many
nice-texts using the same dictionary and the same contextual template source is due
to the variation in the sequence of contextual templates. See Table 2 for a simple
example. See the first two examples from Section 2 for a practical view.
To recover the alleged ciphertext, cn which may be En (pn ), the InvN T
function uses just the dictionary, dn , as follows:
InvN Tdn (pn+1 ) −→ cn = En (pn ). The recovery of pn , of course, simply
requires the appropriate decryption function and key for InvEn . One
source of deniability is the ability for the sender and receiver to claim that
cn is not ciphertext, but gibberish! The strength of this claim depends
on the strength of the external encryption routine and the decryption
key.
Nicetext does not provide any compression, encryption or decryption
functions beyond the actual substitution cipher used for stegonagraphy
purposes 5 . In fact, the original intent of the Nicetext system was to
cover up the use of such functions and to allow a certain amount of
deniability as to whether or not a valid decryption function exists to
expose a suspected plaintext. The “plausible” alternative is that someone
interested in the “entertainment value” of the generated nice-text simply
used a pseudo-random number source as input.
To simplify the discussion as it pertains to this paper, the authors assume that all encryption functions, En , are the same, meaning the same
algorithm and the same key, unless otherwise specified. Additionally,
each level of recursion uses the same dictionary and contextual template
source. In practice, it may be interesting to convert a message into a
story, then a novel, then a business plan! It also may be interesting to
use a complicated sequence of encryption keys to further thwart efforts to
prove meaning. By adding such complexity the concept of key-exchange
becomes more difficult between sender and receiver. Somehow they must
secretly agree on the sequence of algorithms, keys and dictionaries. For
brevity, it is not a focus of this paper to explore and exploit such complexity.
That said, the recursive application of Nicetext should be straightforward. Take some ciphertext, turn it into nice-text, encrypt the nice-text,
repeat.
4
Deniable Nicetext
The purpose of the original Nicetext protocol is to conceal ciphertext, c1
using a particular code dictionary and a particular contextual template.
The contextual template describes the types of words, such as nouns,
verbs, etc., to be picked in some “interesting” order and formatted in
some “interesting” way.
Analysis of the simplified algorithm shown in the very beginning of Section 2 reveals that it is unlikely that the number of bits in c1 will exactly
match the number of bits required to terminate the generated text at the
end of a template, or for that matter, the end of a word. One symptom of
this problem would be that a generated story, for example, would end in
the middle of a sentence. One way to solve the problem, as implemented
5
Due to the inevitable expansion of the size of the generated nice-text compared
to the size of the input ciphertext, it is desirable to compress all plaintext before
encryption.
in the current software package, is to append enough random bits, r1 , to
the end of the ciphertext, c1 , to be able to finish the current contextual
template. The modified algorithm prepends the length of c1 , designated
as |c1 |, so that the reverse process knows when it has fully recovered c1 .
Nicetext now uses the function, I(c1 ) = |c1 | + c1 + r1 , as the input in
place of c1 . The slightly modified algorithm is:
1. Independent of the ciphertext choose a contextual template, if current one is exhausted.
2. Read the next word type from the template.
3. Read enough bits from input, I(c1 ), to select a particular word of
the proper type from the dictionary.
4. Output the word.
5. Repeat until end of input, c1 AND end-of-contextual template.
In the original protocol the length of r1 depends on the size of the contextual template stream and the complexity of the dictionary used during
a transformation. The number of bits used to encode different words in
the dictionary may be different. In this context, it is not because the
number of bits to represent the letters of word. It is due to the length of
the code used to differentiate between words within a type category 6 .
The initial hope was that the quality of the generated text was so good
that it would harmlessly pass through censors. If the text was identified as
encoded ciphertext, the censor would have to prove that c1 was actually
ciphertext. The sender may choose to claim that c1 was actually just a
stream of pseudo-random bits. The protocol specifies that it may need to
append r1 – which always actually was a stream of pseudo-random bits!
These observations lead the authors to the conclusion that it would be
trivial to hide additional ciphertext within r1 .
To allow the hiding of additional ciphertext of arbitrary length, the first
extension to the Nicetext protocol is to add an additional parameter,
l, which defines the minimum length of r. The “Repeat until end-ofc1 AND end-of-contextual template” step now includes the additional
“AND |r| > l”. The sender now can add an arbitrary minimal number
of bits to I with the plausible intent of generating more text. Observe
that |r| will most likely be longer than l because Nicetext still does not
want to stop in mid-sentence.
Now that Nicetext uses the function, I(c1 ) = |c1 | + c1 + rl , as the input,
it is interesting to consider that the sender may want to encode an additional ciphertext, c2 in place of rl ! As long as the length of c2 , |c2 |, is
smaller than l, the modified function 7 becomes:
I(c1 ) = |c1 | + c1 + |c2 | + c2 + r(l−|c2 |) .
6
7
The number of letters in each word contributes to the expansion rate of ciphertext
to nice-text. There is a direct correlation to the ratio of the number of bits in the
ASCII representation of the letters of the word and the number of ciphertext bits
consumed by the code for the word in the dictionary. A more complete analysis
of the expansion rate requires an understanding of the impact of white-space and
punctuation.
The purpose of the (l−|c2 |) is to show that the minimal length of r would be reduced
by the actual size of c2 as well as the number of bits required to represent the length
of c2 , |c2 |. The rest of this discussion will simply specify r without the subscripts for
simplification.
Now the sender uses the Nicetext protocol to generate some harmless
text, t1 from ciphertext c1 and c2 and some additional random bits.
The Nicetext protocol requires a dictionary, d, and a contextual template, s, to generate one of many ti ’s from c1 . The transformation is
N T(d,s) (I(c1 )) −→ ti .
Assume that anyone with the reverse protocol, InvN T , and the appropriate dictionary, d, can recover I(c1 ) from any one of the possible ti ’s,
InvN Td (ti ) −→ I(c1 ). The protocol specifies that I(c1 ) = |c1 | + c1 + rl ;
thus, it is trivial to recover c1 . The original claim that it is unknown if
c1 is really ciphertext still applies. Additionally, it is trivial to recover
rl from I(c1 ). The new question is whether or not rl contains additional
pseudo-random bits or if it is actually |c2 | + c2 + r?
One clue is to see if the first few bits after c1 represent a plausible
length of c2 . One solution is to use an encryption algorithm (and key),
E2 to encrypt the length of c2 . That changes the definition of I to be
I(c1 ) = |c1 | + c1 + E2 (|c2 |) + c2 + r. Because Nicetext does not intend to
be anything more than a creative simple-substitution cipher, E2 is any
externally-supplied algorithm, such as DES, RSA, IDEA, etc [10].
Multiple ciphertexts could be hidden the same way, so that I(c1 ) =
|c1 |+ c1 + E2 (|c2 |) + c2 + E3 (|c3 |) + c3 + ...+ Em (|cm |)+ cm + r. Additional
trickery may include creative uses of XOR’ing combinations of ci ’s or
using error correcting codes to contain the real ciphertext. For clarity, the
authors sometimes limit the discussion to only one additional ciphertext
message, c2 .
The goal of the Nicetext research is not to develop strong cryptographic
algorithms. The purpose is to cover up the use of such algorithms. By
extending the protocol to allow a minimum number of pseudo-random
bits to be added to the input stream, there are more places to possibly
hide information.
If a sender or receiver of a nice-text message is forced to “turn over the
keys”, it is now possible for them to say, “okay - you got me, the file
c1 is actually and encrypted message - not just plain text.” This still
leaves the question as to whether or not the remaining part of I(c1 ) =
E2 (|c2 |) + c2 + r or if I(c1 ) simply contains random bits, r.
In fact, this works so well, that it is possible that the receiver may not be
certain if there is a second message! If there is more than one message,
the receive may have a problem knowing which is the real thing. To solve
this problem, the system requires a secret hash function, H, which will
generate a hash, hi of ciphertext ci through: H(c1 ) −→ h1 .
It is imperative that the hash function is a shared secret between the
sender and receiver of the nice-text. The Nicetext system itself does not
provide a hash function. MD5 or SHA1 or even the use of a block-cipher
such as DES may work well.
In any case, the I(c1 ) function must append a fixed-length secret hash of
any ciphertext that is meaningful and an incompatible hash of the same
length for any ciphertext which is not useful ; thus,
If c2 contains valid ciphertext, then
I(c1 ) −→ |c1 | + H 0 (c1 ) + c1 + |c2 | + H(c2 ) + c2 + r.
If c1 contains valid ciphertext, then
I(c1 ) −→ |c1 | + H(c1 ) + c1 + |c2 | + H 0 (c2 ) + c2 + r.
In either case, with the proper hash functions and the proper adjustments
to the minimum lengths of r to allow for the fixed-length fields required
to hide c2 , it still looks like
I(c1 ) −→ |c1 | + (somerandombits) + c1 + r.
Assume that from a plaintext, p2 , it is trivial to recover I(c1 ). If you
choose the correct secret hash function, it is now possible to determine
if c2 exists as a valid message by the following the protocol in Figure 1.
1. Transform the nice-text, p2 , into I(c1 ) through simple substitution (read each word
from p2 , output the corresponding code from the dictionary, d, to recover the bits
from I(c1 ) . . . ).
2. Read the length of c1 , |c1 |.
3. Read the hash of c1 , H(c1 ).
4. Read c1 and compute the secret hash of c1 .
5. If the hash of c1 matches the secret hash, then c1 is the real message.
6. If not, then read the next few bits of what may have been r - which really is |c2 |.
7. Read the hash of c2 , H(c2 ).
8. Read c2 and compute the secret hash of c2 .
9. If the hash of c2 matches the secret hash, then c2 is the real message.
10. etc.
Fig. 1. Recovery of the appropriate ciphertext from the plaintext.
Communication is achieved by using the secret hash function to determine the existence and selection of the correct ciphertext message. Deniability can only be achieved if the sender and receiver do not disclose
the existence of the proper secret hash function.
5
Recursion with Deniability
It is interesting to combine the concepts of recursive applications of Nicetext and the Deniable Nicetext protocol. The combination provides a
framework for deniability.
At any level of recursion, the process begins with a plaintext, p1 , which
encrypts to ciphertext c1 . It is possible to to append one or more additional ciphertexts, c2 , · cn .
The secret hash function applies only to “real message”. For the other
ciphertext, the system uses a random number in place of the hash 8 .
The results are that the sender and receiver can plausibly deny that a
message other than the first one at each level exists.
Suppose that Alice wants to send Bob a message, pi , 1 < i ≤ n which
says “Sell all my stock.”. Alice must choose a bogus message, p1 , such
as “Do NOT sell any stock”, or an irrelevant message such as “let’s do
lunch” to act as the cover message. This cover message is the one which
might be surrendered with artificial trepidation.
8
Another option is to choose to apply a different secret hash function - which could
be surrendered under duress.
Alice and Bob have previously agreed to use a particular hash and encryption function (and key), H and E. H will identify the true ciphertext
among the c2 , ....cn . The key for the bogus message, c1 , will be different
than the encryption key for the rest of the messages. Of course it is trivial
to use more than one key for the other ciphertext messages. The authors
do not deal with such things as key exchange and encryption here. These
are well known.
When Alice sends the text to Bob, he will receive, for example, a love
poem. He will run the Reverse-Nicetext process to recover the I(c1 ). He
will then apply the algorithm in Figure 1 to determine which ciphertext,
contains the actual message.
If Alice want to be more clever, she can simply use the generated nicetext as a new plaintext message. In such a recursive scheme, it is also
possible to hide the real message in one of the many levels of recursion.
Further tricks Alice may try would be to use Nicetext to simulate past
e-mails to Bob. She first would generate a contextual template library
from the past e-mails. She then could choose to use that template library instead of the love-poem. This may provide more opportunity for
deniabilty.
6
Remarks
There are many methods to maintain secrecy. By applying the disciplines of cryptography, information hiding and stegonagraphy the enhanced Nicetext system attempts to maintain secrecy through plausible
deniability. The secrecy of the message itself ultimately depends on the
strength of the encryption. The use of certain levels of encryption is
sometimes prohibited through corporate policy. The enhanced Nicetext
system may provide a way to deny the use of strong encryption.
Outside of the research community one may wonder who should be interested in such a scheme? One group may be information security professionals, system administrators and managers who need to understand
some of the limitations of particular filtering, firewalling and intrusion
detection techniques. For example, it would be trivial to hide ciphertext
within the headers and content exchanged between a web server and a
browser. With a little stegonagraphy work, it would also be trivial to
make the ciphertext look just like valid hypertext mark-up language. Do
the rules change when a rogue employee can easily create a deniable encrypted tunnel to the Internet from inside the corporate firewall (where
the traffic simply looks like normal browsing behavior)? It is highly likely
that there are readily available automated software techniques for tunneling TCP/IP through hypertext transfer protocol, HTTP. Other protocols, such as ICMP, mail, etc. also may be prone to such cleverness.
At this point, deniability does not appear to be the focus of these tools,
but as they become more sophisticated, the responsible people need to
become aware of the possibilities.
Other groups who may be interested in applying this research include
whistle-blowers or other under-cover operatives, who may need to share
information with the confidence in deniability.
The basic Nicetext software may be made available for research purposes.
Please contact the authors for further information.
References
1. Ross J. Anderson and Fabien A.P. Peiticolas. On the limits of
steganography. IEEE Journal of Selected Areas in Communications,
16(4):474–481, May 1998.
2. Donald Beaver. Plausible deniability. In Jiri Pribyl, editor, Proceedings of Praguocrypt 96, 1996.
3. M. Bellare and A. Boldyreva. The security of chaffing and winnowing. pages 517–530. Springer-Verlag, 2000.
4. M. Burmester, Y. Desmedt, and M. Yung. Subliminal-free channels:
a solution towards covert-free channels. In Symposium on Computer
Security, Threats and Countermeasures, pages 188–197, 1991. Roma,
Italy, November 22-23, 1990.
5. Mark Chapman and George Davida. Hiding the hidden: A software
system for concealing ciphertext as innocuous text. In Sihan Qing
Yongfei Han, tatsuaki Okamoto, editor, Information and Communications Security – First International Conference, ICICS 97 Proceedings, volume 1334, pages 335–345. Springer-Verlag, 1997.
6. Mark Chapman and George Davida. A practical and effective approach to large-scale automated linguistic steganography. In Information Security Conference 01 Proceedings, pages 156–170. SpringerVerlag, 2001.
7. Ran Cynthia Dwork Moni Naor and Rafail Ostrovsky. Deniable
encryption. In Proceedings of CRYPTO 97, pages 90–104. Springer,
1997.
8. Fabien A. P. Petitcolas, Ross J. Anderson, and Markus G. Kuhn. Information hiding — A survey. Proceedings of the IEEE, 87(7):1062–
1078, 1999.
9. R. L. Rivest. Chaffing and winnowing: Confidentiality without encryption. CryptoBytes, 4(1), 1998.
10. Bruce Schneier. Applied Cryptography Second Edition: protocols, algorithms, and source code in C. John Wiley and Sons, New York.,
1996.
11. Douglas Walton. Plausible deniability and evasion burden of proof.
Argumentation, 10:47–58, 1996.