Small packet encryption

I have an embedded design that will be sending very small packet periodically. The "packets" are 16 to 20 bits. Is there any standar methods for encrypting these "packets"?

Reply to
DGB
Loading thread data ...

Many, many methods. How secure? How much computing power can you commit to en/decryption? How does encryption fit into the overall security scheme? (Don't build a heavy steel door for a canvas tent.)

If you just need to protect from casual eyeballs, simply xor the data stream with a single character (or fixed 16- or 20-bit pattern), which works to encrypt and decrypt. A little harder would be to use a pseudo-random bitstream (e.g., from rand()) on each end.

If you need stronger, look into triple-DES, RSA, and Blowfish.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Can you rely upon the packets being received in order, with no lost packets (corrupted packets are okay, provided that you always know how much data has been sent)? If you can't, you need to use a self-synchronising cipher.

But you should really be asking on sci.crypt.

Reply to
Nobody

One approach is to adding some random padding bits before and after the actual message and then encrypting with a fixed length block cipher.

If this is a point to point communication, you should also consider some one time pad (OTP) encryption possibly with some padding to make it harder to break. Paul

Reply to
Paul Keinanen

That calls for a stream cipher, but without more information about...

- bit error probability

- re-ordering probability

- desidered resistance to tampering (modification)

- desidered resistance to replay

- initial key exchange

... it is not possible to help you. As a general feeling, security issues will show up in the high-level protocol, not in the encryption algorithm itself.

Reply to
Legrandin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.