Which is Which? - Answers

Here are the answers to the question from the last post:

• Clip 1 is the original sound file
• Clip 2 is encoded with AES-ECB and scrambled lower 1 bits
• Clip 3 is has nothing encoded, but scrambled lower 1 bits

If you look at the clips visually with a sound editing program they all appear the same even at extreme zooms:


The audio clips sound the same as well, so how can you tell them apart? As it turns out the original WAV file compresses better than the files with the scrambled lower bits (43% vs. 38%). After you narrow down the data to clips 2 and 3 you could then extract the lower 1 bits from each and perform an analysis on them. The AES encyption method that we used (and are replacing) is block based and leaves a detectable pattern. Once you figure out how big the block of data is you could then turn to traditional means of breaking AES.

From here on we are working on replacing AES ECB with a better AES algorithm in an effort to reduce detectability. We are also investigating ways to reduce the randomness of our random data padding so that the compression ratio is the same as or similar to the original file's ratio.

Which is which?

Last night I took an audio clip and I ran it through Awesome-WAV two times. Once was with a 80 byte data file, and once was without any data (to scramble the lower bits).

The clips

Is it possible to determine which clip is which? If you can figure it out, then send an email to awesomewav@gmail.com with your answer. In your email note which clip is the original, which contains data, and which contains no data. Also let us know how you figured it out.

*It is pretty easy to determine which file is the original

awesome-wav 1.1.0

I am pleased to announce the release of awesome-wav 1.1.0. This is an intermediary release that mostly adds new features and fixes a few small bugs in behavior.

There are two major changes in this release. The first is supporting compression with quicklz as well as zlib, with options to not include zlib compression. This decreases compression time, though increases file-size by a bit. The other significant change is allowing wav files with unknown wav chunks. The current implementation just discards the unknown chunks, something that will be changed by the next major release.

This release also fixes various behavior bugs and will allow the chunks of the riff file to be read in any order instead of a fixed order.

awesome-wav 1.0.1

I am pleased to announce the release of awesome-wav 1.0.1. This is primarily a bug-fix release, fixing issues with wav file validation and a few other random minor bugs. This release also includes the somehow forgotten --version argument.

the argument processor was also back-ported from the under-development 1.1/1.2/1.5 code as it is a little more flexible and includes some other various code modifications that have no effect on the actual operation of the program.

cmake

I've been working on adding cmake as an option to assist with building awesome-wav. Currently the only target that works right (only been tested by me on Debian Squeeze) seems to work right at the moment.

If anyone would like to test it on mac os or windows, that would be greatly appreciated, and input on improving the CMakeLists.txt file would be appreciated as well.

How AES Encyption Works

I was doing some research a couple of days ago and I found a very nice visualization of the Rijndael Cipher. It was chosen as the Advanced Encryption Standard (AES) by the National Institute of Standards and Technology (NIST) in 2001.

awesome-wav 1.0.0

awesome-wav 1.0.0 has been released. It supports encoding into 8, 16, 24, and 32 bit PCM WAV files, 32 and 64 bit IEEE float WAV files, compressing the input data using zlib and data encryption with ECB AES.

Release includes 32 & 64-bit *nix binaries and 32-bit Windows binary.

awesome-wav download

Release 1.0 Prep

We've been fighting with a couple barriers to the planned 1.0 release of awesome-wav. Currently the biggest project is setting up cmake as suggested by David Doria among other things. Hopefully the release will be ready in the next week or so.

Recent Progress

Much progress has been made towards our goal of releasing version 1.0. This week we will be cleaning up our code and making last minute checks for memory issues, stupid code issues, and possible places where our program could break. The plan for now is to release 1.0 this Saturday or Sunday, after which we will begin making more major changes.

Back from Summer

And we're back! After a long summer of very slow development we are back to developing more and are currently cleaning up the code/comments/output to ensure usability. no new features will be added from here until we 'release' version 1.0 which should be in the next week or so after we do a cleanup of code.

After that, we will begin work on the next version which will have considerably better encryption, a compression library that can be built into the executable, actual large file support, and many other nifty features.