Help with cryptographic algorithm

[Solidus]

Alright guys, I've got a bit of a conundrum here and I'd be interested to see any of your solutions as to how to deal with it.

Put simple (and confusing, ironically), I need to find a way to pack an AES-256 or -128 encrypted plaintext into 16 bits of data such that after transmission over a line, there is a manner by which to decode all 256 bits of the data to reverse the cipher.

In a nutshell, I'm working on a project for research on the feasibility of using the Rijndael cipher for audio encryption. Problem is, the small sampling data width of most ADCs rule this out (intuitively), as 16-bit data widths could be BFA'd (exhausted) within the sampling frequency by a powerful enough machine (for example, it would not out of the question for FPGA arrays). My question being, is there a possibility by way operations could be applied to each 16-bit 'chunk' of the output to relate it to each other such that a system on the receiving end could reconstruct the main function.

Here's what I've considered (give me your thoughts; I'll be thinking out-loud):

// Suppose we split the 256-bit output into 16 16-bit chunks called:
od[15:0] [15:0];

// Then, we XOR each chunk with the next number lower in the series:
output 'N' = od[i] ^ od[i-1];

Eventually, by looking at a simple ladder topology and iterating the above sequence enough, we'd get down to two values. By limiting our input speech bandwidth to 1.55kHz, we could then insert the second 'nonsense' value into the speech pipeline to get the full 3.1kHz voice bandwidth. This is a simple enough operation in theory. But, would this be a reversible process on the end side? This relies on the reversal of a XOR, that it be 'distributive'. Not being thorough in boolean logic, is

a = b ^ c 
equal to 
b = a ^ c?

It's pretty apparent we couldn't simply truncate the other bits, as that would mean upon decryption we'd have a vastly different result, as AES/Rijndael is a scrambling algorithm.

 

[(*steve*)]

What you are proposing is the generation of a hash.

Whilst it is not possible to determine what all of the 256 bits were that made it up, you can use the hash to tell you if some other 256 bits are different (note that you can't tell that they're the same due to hash collisions, but where there is no hash collision you know its different).

 

[Solidus]

What you are proposing is the generation of a hash.

Whilst it is not possible to determine what all of the 256 bits were that made it up, you can use the hash to tell you if some other 256 bits are different (note that you can't tell that they're the same due to hash collisions, but where there is no hash collision you know its different).

That makes sense. Instead of a hash that returns an output of arbitrary length longer than the key via padding and other methods, it would have to be one that would shorten it.

I had to refresh my memory on that one - haven't worked with hash functions in a good bit.

Do you know of any other ways that all 256 bits could be fit in? I've thought of using the 128-bit key size instead, and 'squeezing' all 8 16-bit parts into the DAC output. It would mean that for GSM audio I would have a maximum vocal bandwidth of 3.1kHz/8 though, which isn't exactly a friendly number in terms of speech.