Re: Bitmap Steganography freeware

Bitmap Steganography Utility Version 3.1 Evaluation, Part 2 of 7

The program was run today 1/24/12 using a 499 byte source file to hide
in an image. The output picture looked just like the original and it
delivered the hidden message when the software was used. The software
works well for a 500 byte source file embedded in a 1.1 Megabyte
picture using a 10 Megabyte random digit file. The stego was
successful. Good work.

The next test used a 23 kilobyte .pdf file as the source file.
The .bmp bitmapped picture file was 1181 kbytes and it can be
downloaded on my website. The random number file was 10 Megabytes.
This ran_04.dat file is linked from my website for encrypted random
numbers and you can get your own copy there.

The 23KB test was started and it took 4 minutes to do the "Random
Number Generation". An error message appeared saying "Not enough
random numbers. Random digit file too short." This seems like a fatal
error, but the program continued "Processing output data..." I waited
25 minutes, but it was not finished. I started writing this report and
watching the King Konglomerate window Processing output data...


While I am waiting 27 minutes for a fatally out of bounds program to
give me some indication concerning the calculations of input file
sizes versus the criteria under which it decided that my "Random digit
file is too short", there is plenty of time to dwell upon the various
subtleties of this stego program.

Why .bmp format and not .jpg?
The JPEG format is common on the web. The bear image on my website was
a 61 kbyte .jpg before Gimp was used to make the 1181 kbyte .bmp file.
It is 20 times bigger than the jpeg format! The reason .jpeg is hard
to use for stego is a reason that takes serious study and book
learning. The Hoffman code table, the Discrete Cosine Transform, and
the variable formatting of byte positions within the file are issues
which my work in 1997 culminated in my Maui rental house being burned
up with a gasoline accelerant. Imagine if jpeg pictures could carry
stego as easily as is done with the King Konglomerate menu. OK, now
stop imagining. That much power must never be unleashed.

Back to the “Processing output data...” message. After 40 minutes
stuck in this state, even someone as even tempered and dedicated as
this author will eventually be tempted to push the “Close” button. But
what are my options? The GUI graphical user interface is presenting me
with four buttons. Only one button affers any hope: “Close”.

Question : Is the random bit file always treated as a fresh address
space or is your program keeping a record of past use of the random
digits to avoid the re-use of the same bits during various sessions.?

Conclusion of Part 2
It has been one hour since the program gave the error message and
continued its mysterious labors “processing output data...” Tomorrow,
Part 3 of the evaluation will be posted here, highlighting how long
the program continued and if it never stopped after 24 hours. My
Popular Cryptography Magazine website has links to the files used for
some tests.