If you have a completely deterministic encryption algorithm, then it's vulnerable to dictionary attacks.
For example, if "password" always encrypts to "qbttxpse", then an attacker can look through a list of encrypted passwords, and know that wherever he sees "qbttxpse" the plain password is "password".
I've encountered a messaging system in which messages were stored encrypted without a salt. One customer frequently sent identical messages. Although you couldn't tell what the content was, you could tell how many of the messages were identical. An attacker could exploit this.
Of course there are plenty of more subtle ways that this property can be exploited.
To avoid this, we introduce a salt to proceedings.
- The input to the encryption contains the plaintext, a key, and a randomly generated salt value.
- The payload sent to the intended recipient contains the ciphertext and the salt
- The input to the decryption contains the ciphertext, a key and the salt
So, you need to randomly generate your 16 byte salt for each message, and you need to make room in your transmission protocol to communicate it along with the ciphertext. It could be as simple as just prepending it to the ciphertext.
If you hard-code a fixed salt, and use it at both ends, it will "work" in the sense that you'll be able to encrypt and decrypt ending up with the same message -- but you'll have the vulnerability I described.
By the way - designing protocols around encryption algorithms is fraught with extremely subtle pitfalls, and is probably best left to real experts (I have 20 years experience working at a fairly low level with secure internet protocols -- and I wouldn't trust myself to design a bulletproof encryption layer). Use something established (e.g. SSL or S/MIME) if at all possible.
