I am new to cryptography. My questions is this: I process packets on runtime. I do not have time for advanced encryption or decryption techniques that take a long time.

As far as I know, going with OTP is the first option for this restriction. However, I also have another soft restriction which is this: I do not want to send keys that are as long as my messages. I can afford to produce long keys if I will only share a seed/ initialization vector between devices. However, in this case I have little processing power, so the generation of streaming keys should be as simple as possible.

What would be a good strategy in this case. I know that my terminology or understanding may be lacking; I can clarify or answer questions if you have.

  • 3
    $\begingroup$ "... that take a long time"; what is "a long time" to you? Is it a nanosecond, or an hour, or something between the two? $\endgroup$ – poncho Sep 22 '18 at 20:32
  • 4
    $\begingroup$ Of course, a "modern communication link" can mean anything between a few Mbps, and 160Gbps... $\endgroup$ – poncho Sep 22 '18 at 21:06
  • 2
    $\begingroup$ @NinjaBug It is important to know your exact setup since some architectures are better at some operations than others. For example, some architectures cannot do multiplication. Others can, but have very slow memory accesses (making lookup tables a pain). Some architectures are very bad at accessing arrays and need to invoke the ALU to do any address offset arithmetic. What instruction set are you using? Is it an ARM7? Zilog Z80? Atmel 8051? Some ancient Intel 4004? How much fast memory do you have? How many registers? How many cycles can you dedicate to crypto? Etc. $\endgroup$ – forest Sep 23 '18 at 1:18
  • 3
    $\begingroup$ Without knowing that, there's no way to give you a tailored answer. On my low-power embedded system, I'm completely fine running a fat TLS suite on a MIPS32r1 system with 64 MiB RAM, and ARM7TDMI with 4 MiB RAM, but I have to carefully optimize Salsa20/8 to run on an 8051 with only 128 bytes of memory, and can't do key exchange on it. Usually, you will be able to run full AES on an embedded system. If memory lookups are particularly slow (making lookup tables inefficient), then you might want something lighter. If it's 8-bit, Speck or TEA would work well. If it's 32-bit, Salsa20/8. $\endgroup$ – forest Sep 23 '18 at 1:31
  • 1
    $\begingroup$ What is your specific budget, in joules or cycles or nanoseconds per byte? Did you try using AES-GCM or crypto_secretbox_xsalsa20poly1305 and confirm by measurement that they are unfit? $\endgroup$ – Squeamish Ossifrage Apr 21 '19 at 4:46

As a huge fan and champion of one time pads, I'm very sorry to tell you that this is absolutely not the use case for them. Your restrictions also seems to preclude this: "I do not want to send keys that are as long as my messages." The key exchange would be a huge problem in a high bandwidth link. By the way, how would you send keys that large? You can't send them over the same link unencrypted so that would be a catch 22 communications situation.

Other contributors will suggest more appropriate symmetric methods, but I'll just reiterate that one time pads are not the encryption technique you're looking for. You probably have the same feeling as you've used the "stream-cipher" tag.

|improve this answer|||||
  • $\begingroup$ Thank you for the response. In short, I have primitive computational power and instruction capabilities. I need to do something in hardware that will protect my channel against wiretapping. I control both devices. Is there any advice, anything for this case? I do not know much about cryptography so I do not know where to look at. $\endgroup$ – Ninja Bug Sep 22 '18 at 21:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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