1

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 <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.

jameshfisher
  • 111
  • 4

4 Answers4

2

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.

Sean
  • 51
  • 5
2

Firstly, if your plaintext is bigger than the block size of your symmetric cipher, then you can use a mode of operation which is compatible with your purpose.

If you wish to simply have the timestamp and the plaintext at the end, you could use CBC for instance and encrypt a message which consists in the concatenation of your timestamps and of your plaintext, but if you really want to use the timestamps as IVs, then CBC is broken, because IVs must be unpredictable for it to be safe. If you really wish to use the timestamps as IVs, on the other hand, you may use another mode of operation which simply requires the IV to be nonces (numbers used only once), since you won't be going back to a past timestamp, never ever. For instance CTR would then be a good choice, fairly easy to implement and it simply requires its IVs to be used only once, which is completely compatible with the IVs being timestamps.

The next things you are wanting is authenticity, so it means you want to be able to make sure the cipher hasn't been tampered. CTR mode isn't enough to ensure it. You mentioned using a MAC, that's a good idea, but you don't have to reinvent the wheel and could simply use a mode of operation which provides you with this feature. For instance, GCM is such a mode which is, like CTR, requiring a nonce instead of an unpredictable IV.

So it seems to me that you could choose the GCM mode of operation, with the block cipher you wish to and be confident you have a reasonably solid scheme.

PS: I would never even consider ECB as a possible scheme, because of the answers to this question.

Community
  • 1
Lery
  • 7,819
  • 1
  • 27
  • 46
0

If you like it more secure take Certified PRNG Generators for Random Values. There are a lot available and its best to check the Generators before use it but i think Salsar oder AESR as example works ok.AES is not the best on Encryption but for PRNG its absolutely ok to use it but there are so much more and at best have a look to NIST.If you work much with encryptions for Customers its good to look sometimes on changes,some Algorithms ar disalowed to use and its better to hold on this Standard but you can do some more as only standard use it but its better to work with this :-) The difference is that the Random is Crypted and harter to read out from Man in the Middle attacks and so scarry things

Dirk Müller
  • 1
  • 2
-1

It sounds like what you are looking for is essentially a (possibly lightweight) Authenticated Encryption scheme. AE schemes are the focus of a lot of academic interest at this moment. With the CAESAR competition many new efficient and secure schemes have been proposed to be adopted as standards. If you want an earlier example of a very good Authenticated Encryption scheme, look at GCM (Galois/Counter Mode), as mentioned by Lery above.

Unless you are a specialised researcher yourself, it would probably be more advisable to choose a scheme endorsed by the Crypto community (which translates to being around for a while enjoying some publicity without being broken, like the third-round CAESAR candidates), rather than designing your own.

As for you questions regarding timestamps and counters, there's not enough information to answer those. If you have some concrete constructions in mind, I suggest you add more details (and preferably a diagram).

Ritam Bhaumik
  • 142
  • 3