Recommendation for lightweight algorithm for partial message encryption

Question

I have designed a specific client and server program, which sends a file from client to server in 32k chunks. I want to encrypt only part of the data. More specifically: in each 32k chunk passing from client to server I want to encrypt only 500 bytes. This, in a non-continuous way (meaning: partial encryptionhere and there in the chunk of 32k, totally forming 500 bytesof encrypted data within the 32k block). Here client is a constrained sensor and server is an Arduino board used for Internet of Things concept, to save of energy of the constrained device(client) i want to encrypt only parts of data.

Are there any lightweight(here refers to C.P.U consumption) cryptographic algorithms or methods which offer the option to set an “offset” and a parameter defining how much partial data we want to encrypt?

For example encrypt (bufptr, random_num, ENCRYPT_LENGTH); where bufptr is a 32k chunk with information, random_num is the random number smaller than the bufptr pointing to the bufptr, ENCRYPT_LENGTH is the length we want to encrypt (like 20 bytes from the number pointed by the random_num).

You really need to describe your use case in more detail. For example, it is probable that encryption alone (especially CTR mode, but really any) will not suffice, but you need a MAC too, unless authenticity is verified somehow already. — otus, Jan 18 '16 at 20:02
What does lightweight mean for you? What is your target hardware platform at what speeds? Is the memory footprint important or just the pure performance? What does this have to do with TLS? — Artjom B., Jan 19 '16 at 08:21

score 1 · Answer 1 · edited Jan 19 '16 at 12:32

It's trivial to code your own wrapper function if you really want to use such API. Here is a Python-inspired pseudo code:

def mywrapper(data, offset, encspecs):
    subdata = data[0:offset]
    ciphertext = whatever_enc_function(subdata, encspecs)
    return ciphertext

encspecs = ... 
plaintext = "...etc"
ciphertxt = mywrapper(plaintext, offset, encspecs)
cipher_plain_mixed = ciphertxt + plaintext[offset:]

But either way, it's not an algorithmic/methodology problem as much as it is an implementation.

Side note: I sense that you are about to allow for replay attacks, or other similar ones. Make sure to include a unique initialization vector (e.g. a simple counter or timestamp) that is always different, so that you never (extremely rarely) get same cipher again even when the content plaintext is repeated. This prevents an attacker from fraudulently re-sending a previously captured block of encrypted data.

score 0 · Answer 2 · 2016-01-24T09:55:09.337

0

My recommendation will be to use a stream cipher consisting of any block algorithm in CTR mode. You could use block ciphers like AES, or hash functions like BLAKE2.

Stream ciphers are very efficient and light weight, hence it is the preferred cipher for encrypting phone calls. It should be good enough for your project.

Block ciphers and hash functions make really powerful and fast PRNGs, especially AES, which has itself implemented in various hardware devices (I am not sure about Aurduino).

You might find Implementing Security in a Personal Security Device useful.

edited Jan 24 '16 at 09:55

answered Jan 19 '16 at 13:32

1

"or hash functions like SHA-3" - SHA-3 (especially the -512 version) is rather slow (because SHA-3-512 was tuned for security rather than speed) and AES should be strongly preferred. – SEJPM Jan 19 '16 at 18:58
1

@SEJPM I have edited my answer to recommend BLAKE2 instead. – Jan 24 '16 at 09:56
1

I'd rather use ChaCha over BLAKE2 in CTR mode. ChaCha is faster and is build from some kind of hash function in CTR mode already. – CodesInChaos Jan 24 '16 at 11:03

Recommendation for lightweight algorithm for partial message encryption

2 Answers2