1
$\begingroup$

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.

Improve this question
$\endgroup$

4 Answers 4

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Hi Sean - I was suggesting that my scheme would work if the message fits in a single block. I'll edit to clarify that. $\endgroup$
    – jameshfisher
    Nov 19, 2016 at 19:44
  • 2
    $\begingroup$ I'm assuming we're talking AES here. A block is only 16 bytes. You suggested your messages could be up to 1kb. In any case, it's really hard to imagine a practical system where using ECB mode is safe. $\endgroup$
    – Sean Comeau
    Nov 19, 2016 at 19:56
2
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ This is pretty close to an answer, but I'd remove the whole part about CBC. CBC is not a good mode of operation for this kind of protocol. Assuming that the time stamp is never repeated is tricky in real life. A random IV would probably be better, but it depends on the system if random numbers are available. $\endgroup$
    – Maarten Bodewes ♦
    Nov 19, 2016 at 23:00
0
$\begingroup$

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

Improve this answer
$\endgroup$
-1
$\begingroup$

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

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ Your answer does not provide anything meaningful. By that I mean that you don't mention the fact that ECB is crap, you don't mention the possibility to use a stream cipher with poly1305 (another example rather than GCM which is a pain to implement... which you should not even consider...) You give a link to the Authenticated Encryption Competition but some of the ciphers are not even lightweight. Ketje can be considered as such but not Keyak. The definition of Lightweight is still being discussed in NIST, one of the consideration is that if you can use AES, you don't need lightweight. $\endgroup$
    – Biv
    Dec 21, 2016 at 9:03
  • $\begingroup$ ECB or CTR are not considered to be stand-alone modes. Rather they act as design components. As such, in this age of parallelisation, ECB can be very useful, if properly used. EME by Halevi and Rogaway, for example, uses two layers of ECB with a layer of mixing, as does the CAESAR candidate ELmD (now merged into COLM). As for GCM, it has been revived in various forms, like the GCM-SIV. $\endgroup$
    – Ritam Bhaumik
    Dec 21, 2016 at 9:22
  • $\begingroup$ As for streamcipher-based Authenticated Encryption, they are not very interesting from a provable security standpoint, since they have to be ideally modelled as random streams in a nonce-respecting scenario, which is already a very strong assumption. So I haven't worked with them, or even studied them myself. (I only know a little about the erstwhile CAESAR candidate Trivia, based on the streamcipher Trivium.) If you have some interesting proposals, please go ahead. $\endgroup$
    – Ritam Bhaumik
    Dec 21, 2016 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.