A 4-byte key and a 32-byte key both produce output that looks like ciphertext. Unlike most bugs, crypto bugs don't produce visible errors. That's why this one survived 12 years.
> Unlike most bugs, crypto bugs don't produce visible errors.
TFA mentions that AES is used in ECB mode, which is infamous for being literally visible[1]. It would be interesting to see if the circuit encoding exhibits this.
An image may have large areas of uniform color, so it will definitely leak through ECB, unless the original image was noisy, which prevents repetition, so nothing is revealed after encryption, even when using ECB.
The famous encrypted penguin works only because the original image is a noiseless drawing. Had it been replaced by a photographic image, the ECB-encrypted image might have looked perfectly random and undecipherable. In general, it is enough to use a very simple non-cryptographic PRNG, e.g. a LFSR, to add white noise to an image before using ECB encryption, to make the encryption unbreakable (a.k.a. indistinguishable from a random string by chosen-plaintext attacks).
On the other hand, normal text, such as SPICE model text, even if it has a lot of words that are repeating, it will seldom have 16-byte sequences aligned at 16-byte boundaries, that are repeated.
Even if you see a few such repetitions, it is extremely unlikely that you will succeed to guess even a small part of the model text.
Here the problem was their key generation method, which produced guessable keys, not the use of ECB.
If you know cryptography, it is easy to use ECB in a perfectly secure way, e.g. when encrypting only values that can never repeat. The reason why it is strongly recommended to not use ECB, is that naive users cannot judge when the use of ECB is appropriate and when it is not.
Moreover, even if ECB can be used in a secure way, its hardware implementation is more expensive than of alternatives, because it must implement both the encryption mode and the decryption mode of the block cipher function. So the reason why there is no need for ECB is that the alternatives (i.e. Vernam encryption a.k.a. binary additive synchronous stream ciphers) have a cheaper implementation, even when using the same block cipher function, and not because one cannot use ECB in a secure way.
The ECB penguin is an excellent example of how ECB can be misused. However, people who see this example do not realize how easy such a mistake can be avoided. Like I have said, if the penguin were not a noiseless drawing, but a photography with a small amount of noise, there would have been no leaking of the image through the ECB encryption.
For this SPICE application, ECB was a bad choice anyway.
Like I have said, ECB can be used alone only with values that do not repeat or which have a negligible probability of repetition, like random numbers. Otherwise, ECB must be used only as a component of a more complex mode of operation, e.g. in combination with a PRNG that is combined with the text stream either only before encryption, or both before and after encryption.
However, when encrypting English text or text written in a programming language or something like a SPICE model, which is similar to a program, the use of ECB is very seldom a mistake sufficient to allow decryption. The chances of exploiting ECB for a successful decryption increase only when you have huge amounts of encrypted text, e.g. gigabytes or terabytes.
When you would monitor something like the communications of some spies, even a very small amount of information about the content of their messages may still be of some use, so if they use ECB, that would be a capital mistake for them.
On the other hand even if you would be able to decrypt a half of a SPICE model, it is very unlikely that this would be useful in any way. With SPICE models, what you need is the complete set of parameters, which is something that you cannot obtain when you do not have access to the physical devices that are modeled, to be able to measure them and extract the parameters from the measurements.
Even if you have 80% of the parameters, they are still useless, because that does not allow you to guess which are the missing parameters, which would enable you to model accurately the behavior of a device.
