Using a block cipher with timestamp instead of counter I have a system where machine A sends updates to machine B. The updates are sent over the internet, where each update is a single UDP datagram. Machine A sends a local timestamp in each update (we can assume that the timestamp increments for each message). Messages can vary in length, but there is a maximum size (consider it &lt;1kb).

I would like to secure this communication. Specifically I require that:


Machine B can verify that an update is from machine A, and no tampering has occurred.
An attacker cannot decrypt the updates.
The implementation on machine A is simple and lightweight.


It's okay for an attacker to drop, reorder and replay the updates. (The timestamp in the update mitigates such attacks.)

I can arrange for both machines to share a symmetric key.

My initial thought is to encrypt each message with a block cipher in ECB mode, where each message fits in a single block. I believe the timestamp in the message mitigates the problems with ECB, performing a similar function to the incrementing counter in CTR mode. Are there problems with substituting a timestamp in place of a counter?

One problem here is that the messages are larger than most cipher block sizes. I could instead use a stream cipher, but I'm not sure of the consequences of doing so. Alternatively, there are apparently constructions to make a block cipher with a larger block size, but I'm not sure how they work either.
A timestamp in the message won't fix the problem with ECB mode. ECB mode uses the same key for each block, so you will leak the fact that blocks are the same within the same message, and if you use the same key static key for every update, between different messages as well.

Consider a higher level library such as libsodium or spiped from tarsnap to avoid worrying about these details.