I'd like to transmit a small amount of data, typ. 4 - 16 Byte through a channel that can be eavesdropped at any time.
The behaviour, the way the data changes, should be protected too.
I could encrypt it using XOR with a 4 - 16 Bytes key like this:
c = m x k
c is the same for the same
m. When observing the cipher, it's actually not interesting to decrypt the actual data because the cipher reveals enough information about the data source.
When observing the data - encrypted or not - it should ...
... NOT LOOK LIKE THIS: t=0 12587200 t=1 12587200 t=2 12587200 t=3 97387419 ... BUT LIKE THIS: t=0 23443623 t=1 53453566 t=2 91372718 t=3 18347444
The data either
- lineary increases (with variable increment) or
- over a long time period, changes around a relatively fixed average value or
- does not not change at all over a long period of time or
- is guessable with not much effort
It's clear to me that, since the data might not or little change, it should be randomized before encryption.
- No security by obscurity - the algorithm is known to an eavesdropper
- The data may be
- broadcasted by the source (updated in a defined interval, during this time period an eavesdropper may see the same data) or
- get actively read by one peer
- The receiver/reader may miss a message update so it should be able to sync
- Message loss is acceptable for the receiver
- Both peers cannot rely on a stable and tamper-free timebase
- CPU power and memory requirement is limited
- The data and the behaviour can be seen unconfidential after a while
I see one option, suitable for broadcasting and active read: combine the data with a pseudo random factor derived from a confidential IV known to both sides. That combination is then encrypted using the also confidential key.
It could look like this:
T = 5 mins # Update interval, e.g. 5 mins (unconfidential) K = 0x1BC07410 # Key (confidential) IV = 0xB9EF72E5 # LFSR seed (confidential) r = 1000 # initial rounds (unconfidential) R = 0 # LFSR round counter n = IV # pseudo noise from LFSR def HIDE(m): n = LFSR(n) return m x n def ENC(m): return m x K # initialize once while R < r: n = LFSR(n) R = R + 1 while True: R = R + 1 m = READ_FOUR_BYTE_MESSAGE() Feed to broadcasting or store for retrieval: ( ENC(HIDE(m)), R ) sleep(T)
It's clear to me that an eavesdropper might brute force probe IVs cycled
R times through the LFSR and XOR it with the cipher to know that the message did not change between the update intervals.
Have I missed other attacking vectors?
Is there anything to improve the security but increasing IV and key lengths?
Please guide me what basics I should learn