Customizable Crypto Algorithms in Hardware

Question

Several companies offer customized cryptographic algorithms, for example Crypto AG (www.crypto.ch/en/company):

The individually created customer algorithms are unknown to anyone else and are not used by anyone else. A cryptographic attack is not possible, even from an identical unit.

Only the customers know the algorithms:

Autonomous profiling of algorithms: you are the only one who knows the algorithm. Not even Crypto AG has access to it. Moreover, you can use a second additional algorithm when collaborating with other organisations.

These algorithms are hardware-based:

Hardware-based encryption is the foundation for maximum cryptographic diversity – for speed reasons on the one hand and for its immunity to tampering on the other (no readout of data). This approach also ensures that the encryption processes remain cryptographically separated from the network. No common operating system is needed (viral resistance).

Thales offers something similar and calls it Programmable Cryptography (www.thales-esecurity.com/solutions/by-technology-focus/programmable-cryptography)

A company called Mils offers customized algorithms as well (www.mils.com/en/technology/customized-algorithms/)

How does this work? How can they offer a cryptographic algorithm that can be customized by non-specialist customers without support and not run the risk of creating an insecure algorithm? (Ignoring the assumption that this might be the goal)

Note that Crypto AG states that the algorithms runs on hardware. Depending on what they mean by hardware (I understand it as a non-programmable logic circuit with fixed gate connectivity), this severely narrows the available algorithms.

Answer 1

Your doubts are absolutely valid. Disguising the algorithm is not a valid argument for security. It also contradicts to Kerckhoffs Law.

It (the algorithm) should not require secrecy, and it should not be a problem if it falls into enemy hands;

Designing cryptographic algorithms (ciphers, hashfunctions, ...) is a long and complicated process. In academia such algorithms are proposed and are analyzed afterwards by other researchers for a long time trying to break them. For AES, it took about two years from publishing to standardization.

If you take a look at linear or differential cryptanalysis, you will notice that innocent looking S-boxes for example can be highly biased reducing the cipher's security drastically. Same applies to other parts of the cipher.

This contradicts highly to the promised security. I would not trust these algorithms at all, nor a machine designing them.

For the hardware part. They could use some sort of FPGA-based HW. This would allow the company to implement the different algorithms on the same boards easily. Speed is a valid point. However, I doubt that their generated algorithms are side-channel proof, which means one could get information about the algorithm itself or the payload that gets en-/decrypted by measuring power, timing or EM for example. If so, the point of "unkown algorithm" would be broken.

TL;DR

• Hiding the algorithm is not a good idea.
• Refrain from inventing your own crypto.
• Do not trust companies that break both :P

Hope this helps

Answer 2

As the other answer correctly stated, this is likely a bad idea and they are essentially selling only a perception of high security. People who don't have a cryptographic background may be mislead.

How does this work? How can they offer a cryptographic algorithm that can be customized by non-specialist customers without support and not run the risk of creating an insecure algorithm?

This could be done securely in the case of algorithms that have enough constants whose value does not matter. E.g. SHA-256 is most likely either secure or insecure regardless of the IV (since the "IV" changes with multi-block messages). You could allow the customer to "customize the algorithm" by choosing the IV (or other constant). Essentially that just amounts to an additional key, stored in the hardware.

I have no idea if that's what they are doing, but it seems feasible and not necessarily insecure, if they choose the right algorithms. It would not be more secure than simply storing a key in the device (since that's what it amounts to), but may be more "marketable" to non-expert customers.