1
$\begingroup$

The setup is shortly this: There are two custom switches (think of an FPGA for example), both are handling 10-100 Gb/s orders of traffic from their outside facing interfaces. This is normal traffic. Then, they have a link between each other. I want to apply AEAD to secure this link, so that an eavesdropper will not be able to analyse the traffic. The restriction is this: The traffic is streaming fast and obviously there is not much time to encrypt or authenticate.

I own both switches, so pre-configuring certificates, symmetric-keys etc. are all allowed. After bootstrapping, I can asynchronously exchange keys in-band, but no out-of-band exchange is allowed.

I am not looking for an unbreakable system, I just want to protect the traffic as much as possible.

What would be the best approach in this case? So far my approach is: I can install certificates to both sides (for authentication), I do not know if or how I should renew them as time goes by. For encryption, I will XOR the plaintext with symmetric keys on both sides (I guess this is the fastest way). However, I consume keys much faster than I can produce. Somehow I should stretch keys or find a way to produce key streams very fast. After this point I get lost.

$\endgroup$
  • $\begingroup$ Do you have the computational budget for eg AES(-CTR) or ChaCha20? (And yes, repeatedly xoring the same symmetric key into your keystream isn't very strong). $\endgroup$ – SEJPM Oct 16 '18 at 19:39
4
$\begingroup$

Don't roll your own crypto

So far my approach is: I can install certificates to both sides (for authentication), I do not know if or how I should renew them as time goes by.

This does not provide authentication in a cryptographic sense. A MITM attacker will still be able to modify data on the wire at will if the underlying encryption is not authenticated. Alone, a certificate can only be used to sign a very small value, the size of a symmetric key. It takes more than the presence of a certificate to ensure that data cannot be tampered with on the wire. For example, you would need to sign an HMAC key which ensures integrity of the messages. If this is not obvious to you, then you should not be trying to design your own cryptosystem!

I will XOR the plaintext with symmetric keys on both sides (I guess this is the fastest way).

This is called an XOR cipher and is extremely insecure, requiring just a tiny amount of known plaintext to break (the same amount as the size of the key). When you have known plaintext the same size as the key, you can simply XOR the known plaintext with the observed ciphertext to recover the key itself. Not to mention, it is highly malleable and does not provide any authentication, even if it was secure.

However, I consume keys much faster than I can produce. Somehow I should stretch keys or find a way to produce key streams very fast.

You have just invented a stream cipher. This is a cipher that takes a single key and expands it to a virtually unlimited stream of pseudorandom data called the keystream which is then added to the plaintext or ciphertext, usually via the XOR operation. A raw stream cipher, like ChaCha20 or AES in CTR mode, is malleable and not authenticated, making it insecure for your purposes. It is so malleable, in fact, that toggling a single ciphertext bit will toggle the corresponding plaintext bit. Such tampering would not be detected or prevented without a properly-implemented authentication algorithm like HMAC, GCM, or Poly1305.

Just use MACsec!

All is not lost! There is already a solution, called MACsec (IEEE 802.1ae). This is an extension to the Ethernet protocol which allows end-to-end authenticated encryption at a low computational cost. It uses AES as a cipher, run in the GCM mode for authentication. It is supported by a number of switches, routers, and operating systems, and is considered very secure.

If you are writing the HDL for the FPGAs, you can use pre-designed IP cores for MACsec, for example this FPGA core. You can also implement MACsec yourself from the published standard if you are confident in your FPGA design skills or can hire someone who is.

An additional benefit of MACsec is that, because this is a standard, it will work out-of-the-box with other compatible switches, such as Cisco's Catalyst 4500. You will not be limited to only using in-house custom switches with your own FPGAs and will not need to go through extensive and expensive cryptanalysis of your own protocol.

Any mentions of or links to commercial products should not be construed as an endorsement of the product of company.

$\endgroup$
  • $\begingroup$ thank you for your detailed response. I know about MACsec, and I definitely do not want to design my own cryptosystem. My only problem is this: I want to do what MACsec does, to only my protocol header. In other words, I need an AEAD system (I guess AES-GCM is one), but my input is around 40-50 bytes. Since for each packet I should run the algorithm, there is a huge overkill. Do you have a solution to this? I more lightweight AEAD that I can implement? $\endgroup$ – Ninja Bug Oct 17 '18 at 19:19
  • $\begingroup$ @NinjaBug MACsec is lightweight. Unfortunately, if you want to design your own, you will need to do a lot more research. For example, there is absolutely no way around running the algorithm for every input. If you are using an algorithm with 16 byte blocks, you will have to run the algorithm for every 16 bytes. Thankfully, a good stream cipher (like AES-GCM or ChaCha20-Poly1305) is very efficient. After all, you can use an FPGA to process 40 Gbit MACsec! But why do you not want to use MACsec? Why do you want to use your own protocol? $\endgroup$ – forest Oct 18 '18 at 3:50
  • $\begingroup$ I analyzed the problem until this, if you can give me an insight or direct me to necessary terminology or resources it would be great, because I am very stuck and new to cryptography: I can asynchronously create a stream cipher with a powerful hardware, and load it into the cache of my main device. This main device does not have enough computational power to create the stream cipher, it can XOR it with the plain-text though very easily. After XORing the already stored stream cipher, the main device needs to authenticate the resulting cipher text. Thus, must be lightweight. $\endgroup$ – Ninja Bug Oct 18 '18 at 12:52
  • $\begingroup$ @NinjaBug Both devices need to be able to run the stream cipher. But why do you say that it doesn't have enough computational power? Stream ciphers can be very lightweight. Also, authentication is usually as heavy, or heavier, than running a stream cipher. $\endgroup$ – forest Oct 19 '18 at 3:33
  • $\begingroup$ I need as high throughput as possible, this is why; not because the device is not capable of encryption. In this case, if I do everything in the main device, assuming I need EA; what is the highest throughput EA? AES-GCM seems like the best option so far to me. It is the standard in similar applications (like MACsec). Is there another more lightweight solution? If you think there is why is MACsec using the AES-GCM? $\endgroup$ – Ninja Bug Oct 19 '18 at 11:29

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.