At the risk of flogging a dead horse, some additional comments, following the excellent answers (especially from @D.W.)
I have always agreed to the principle of 'Do not roll your own', but now, even more so.
I think it relevant to point out that these 'messages' never transit, but are only stored 'at rest', and that the attack I'm defending against in this exercise is 'they stole my database'. So I'm not sure what
D.W.'s chosen plaintext attack is a real eye-opener.
In this scenario (input, charge, store, perhaps retrieve for refund), I'd like to understand better what advantages authentication would bring me.
I'd welcome further comment on using the TOD clock as an IV. Here are some additional details:
The TOD clock is 64-bit integer representing the elapsed time since 00:00 on Jan 1,1900.
The clock is updated in such a way that bit 51 is guaranteed to be updated once per microsecond. Bits 0-51 are the unsigned number of elapsed microseconds.
On faster machines, bits in the range 52-63 are also updated at their corresponding frequencies.
The system in question runs as a single image on a single real machine.
Clock synchronisation is unlikely to set the clock backwards, but let's analyse that case:
If at peak I'm doing 100 encryptions per second (the real number is a lot less), and I assume the slowest clock (1M per second). Let's suppose that the clock gets set back by 5 seconds (I believe that to be extraordinarily extreme. It's GMT, by the way so there's no daylight saving)
Now, I apply the birthday paradox to 1000 encryptions (5*(100+100)) in 5 million; the probability of two or more synonyms is less than 1.3E-7
