wnstorm.doc

数据隐藏程序

 [size              ]       |
	 |                  |
	 +------------->----+

     Fig 1.			                       Fig 2


			    - Theory 2 -

===========================================================================
 Data Stream sample:  (This is a simplified fictitious example and not
 based on the actual workings of the program.)

 ===========================
 ||LEGEND:    xx - stream ||
 ||           1  - data1  ||
 ||           2  - data2  ||
 ||           3  - data3  ||
 ||     /\/\/\/\/\/\/\/\  ||
 ||           8  - data8  ||
 ===========================

Pass  DATA  STREAM                                          WinSize
---- ------------------------------------------------------ -------
 0   2 4   1  6  3 8    5     7
     xxxxxxxx xxxxxxxx xxxxxxxxx                              3
     Commands: Swap 2,6 NextWinSize=6

 1   6 4   1  2  3 8    5     7
     xxxxxxxx xxxxxxxx xxxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx   6
     Commands: Rotate bits right, NextWinSize=3

 2    6 4   1  2  3 8    5     7                              3
     xxxxxxxx xxxxxxxx xxxxxxxxx
     Commands: pick new bits, NextWinSize=5

 3    1  6       5     3           7 4         2
     xxxxxxxx xxxxxxxx xxxxxxxxx xxxxxxxx xxxxxxxx            5
     Commands: etc.


			    Fig 3




			    - Theory 3 -


 PORTABILITY:
 ------------

 This code is written for Borland C / Turbo C, however it should be
 portable to other compilers and operating systems.

 This code can be ported over to other operating system, however on non-
 80x86 machines, the rotate functions may have to be rewritten if the
 left shift is eqivalent to divide by two instead of multiply by two.

 Assumptions ARE made about the size of a character byte being 8 bits.
 This should hopefully not be a problem as the AND operator is used
 to trim off everying but the low 8 bits (again assuming little-
 endian processor.)  Should it become a promlem, define CHAR to be int:8

 This program assumes that 1<<1 = 2 and 2>>1 =1 and that bit 0 holds
 the decimal value of 1, bit 7 holds the decimal value of 127.



 -----------------------------------------------------------------------


 Depending on what LIMITCHNL value the user chooses, this program will
 generate a coded file which is approximatly SizeOfFile*LIMITCHNL/2.

 The output of this file is in 8 bit binary.  To use it to send mail,
 you should process the output of this with uuencode, HQX, btoa, or
 some other similar 8-bit binary -> 7 bit coded ascii.


 -----------------------------------------------------------------------

 A lot of this code is arbitrarily written.  The basic premise upon
 which the arbitrary decisions I've made rely upon the functionality
 of data bits.  AND is used to trim off unwanted bits.  IE: x & 7 will
 make sure we trim off all bits so that the result will be a number
 between 0 and 7.  Sometimes a right shift operation is used to get
 at high nibbles (bits 7-4) ie:  (x>>4 & 0x0f.)  XOR is possibly one
 of the most famous and useful encryption methods.  If c=a^b, then
 b=c^a, and simultaneously a=c^b.  With XOR, you can exchange the key
 and the plaintext you wish to encrypt.  But it's operations are not
 used for encrypting only, they are used as primitive decision makers
 between chosing paths.

			    - Theory 4 -


 The raison d'etre of White Noise Storm is data hiding.  This makes it
 a good program to use for steganography.

 The encryption process depends on the random number generator.  It is
 greatly emphasized that you should pick a random number generator that
 does NOT have strong idiosyncracies or a heavy bias.  Random number
 generators based on the time of day are fine, except that most of
 today's operating systems will stamp a creation date on a file.  Hence
 a random number generator based on only a clock may give out some
 information to a cryptographer, aiding him in cracking the coded text.

 Today's technology does however provide the possibility of a hardware
 random number generator based on a very small radioactive particle and
 a sensor and supporting circuitry.  Or a couple of zener diodes.

 Another method of getting random numbers is to record noise off a
 sound port, then take only some of the bits out of the noise to strip
 off 60Hz hums, redundacies, etc...

 The receiving side will be able to decrypt the coded text no matter how
 flawed or biased your random number generator is.  However if the
 RNG is very poor, you will sacrifice some of the security offered by
 this program.

 If WNSTORM is used as part of a stego system, the random number generator
 should be replaced with the actual LSB data.  Keep in mind that the data
 you feed WNS will be lost and replaced by similar data containing the
 hidden text, so the least significant bytes of your picture, sound, etc.
 should be chosen so that they are not important to the integrety of the
 image, sound, etc.

 In addition, there is code which bases the current encryption of the
 data on the previous plaintext character.  That is if you have a stream
 of text "ABCDEFGHIJKL", and you manage to decrypt the code upto "D", but
 miss E, and mistake it for a "Q", the result will be an immediate bunch
 of garbage following the ABCD.  Because of this, and the further nature
 of the algorithms employed by this encryption method, it is vital that
 your medium of transportation be secure and very reliable, for if a
 single bit is changed in the encrypted stream, the remaining file after
 the change is rendered useless and unrecoverable.


 A perfect practical use for WNSTORM and its companion WNINJECT is to
 post up PCX pictures on the usenet groups (alt.binaries.pictures.* or
 whatever it is these days.)  If you manage to agree with someone on
 what key and other parameters you'll use for WNHIDE, you can send
 totally private, hidden messages while benefiting the internet at the
 same time by posting images.








			    - Theory 5 -



 The metaphore of this code is as follows.  Suppose we have a device,
 like a radio, but which uses a varying number of channels.  Sometimes
 two channels, sometimes five, sometimes nine, sometimes any number of
 channels upto a specified limit (LIMITCHNL.)   Let's further suppose
 that most of the time we will be sending random, white noise down
 these channels.  A spy wouldn't be able to make any sense of the data
 sent via these channels because they would simply be random noise.
 (Here is where a good random number generator is VITAL!)  But suppose
 that we had a way, a formula based on a password, to take only some
 pieces of that data and put them back together again.  In this way,
 we could hide valuable data within a stream of gibberish.  But if the
 spy knew this formula, he could try a brute force method with every
 password imagineable on the text until he found the correct text.

 Fortunatly for us, unlike a radio where a spy can monitor ALL
 frequencies and distinguish between them, the way White Noise Storm
 encrypts the data, there is no external way for our spy to find out
 how many channels we are using per iterration, nor which bit of
 data resides in which channel.

 Yet, we must make sure that we limit our suposed spy in his options,
 and force him to use a very large key space to prevent him from
 using brute force.  The current program accepts upto 150 characters as
 the password key.  This restriction can be easily removed.

 Furthermore, most of today's encryption methods rely on a byte level
 operation.  So let's render the spy's tools useless by taking our
 data apart into bits, and scattering the bits across our channels.
 Every once in a while, we'll swap two of the bits, and every once
 in a while we'll also either rotate all the bits to the left, or
 to the right, or do some other sort of scramble operation on them.

 Another thing, since we are using many channels of information, let's
 spread the bits across these channels.  Some of the bits might wind
 up residing in the same byte, others in other bytes, but this would
 depend on our password key.  The larger the number of channels we
 use, the more spread out our bits can be, thus the more secure our
 data can be (also, the larger the resulting cypher text.)

 There are a lot of variables here to prove a major headache to any
 cryptographer or spy.  First we have a very large key (150 chars
 or 1200 bits!)  We then have a number of data channels, which change
 for every character.  For the first plain text character we may have
 5 channels, for the next, we may have 3, for the next 6, and so on.
 The window size depends on our password.  Additionally we may
 specify an upper limit to the window size.  If we use a different
 one than the spy, he will fail.  (In a sense the window size
 limit parameter is part of the passkey.)







			    - Theory 6 -


 A variable number of bytes per window is written.  That is
 if we have a limit of 5 chanels, we don't write 5 bytes for every
 iteration.  That would help give the spy too much information. If
 for a given iteration we happen to have 5 channels, we write 5
 bytes.  If we have 3, we write 3 bytes.  This way our spy cannot
 guess where one window begins or ends.

 We have eight bits of data which may reside anywhere within the
 random number window, and their values are swapped around as
 we go.  That is for each bit, our spy doesn't know it's value
 (1,2,4,8...128,) nor does he know which channel a particular bit
 may reside in.  Bit 1 may become bit 4 in the next window, and
 move from byte 6 in the window to byte 1, etc.

 To make things worse, if he makes a mistake in the begining of his
 guess, he would lose the whole text.  That is even if he were to
 guess a close passkey, the password seeding methods would prevent
 him from noticing it.

 However, our spy is not to assume that we are transferring just
 text.  To protect ourselves, we should compress that text with a
 high quality compressor such as PKZIP, ZOO, ARJ, or even better,
 a proprietary scheme that is unrecognizeable to our spy.   So
 even if he should guess the password, there's no way for him to
 know if he succeeded or not.  We may wish to strip off the headers
 from a compressor as they are a dead giveaway.

 To make matters worse for our spy, we won't waste the random noise
 that makes up the window.  We will use this random garbage in
 conjunction with the password we chose as the function for deciding
 when to swap bits, switch channel size, etc.  The reason for this
 is to prevent our spy from modifying the cypher text bit by bit to
 see which bits are unused.  In WNSTORM, all bits in a window are
 used for the commands of the next round.

 This implementation is the "public" version.  It can be modified
 in several places by replacing certain key values, and certain
 ordered operations to produce private, more secure versions which
 can only be decrypted by the same software.  (This is known as
 security through obscurity, and has its own [dis]advantages.)

 The data is not just hidden, but also encrypted. It would be fairly
 easy to insert a modified version of the DES algorithm to encode and
 decode the data before scattering it or restoring it from the stream,
 thus making this an even stronger crypto-system..











			    - Theory 7 -


 There are several flaws or features (depending on your point of
 view,) which you should be aware of:


  o The encrypted data produced is many times the original size.
    However, the larger the LIMITCHANL size, the more secure your
    data is, though it would require more storage space.  Compress
    your plaintext before encrypting it.  You won't be able to
    compress the encrypted text as random numbers without patterns
    do not compress.  (Similarily, using a high power compressor
    such as a fractal compressor can tell you if an encrypted text
    has patterns in it.  The less the compression, the better the
    encryption, as less patterns are available, the less a spy has
    to go on to decrypt the stream.)