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.
A Copy-Paste Bug That Broke PSpice AES-256 Encryption
11–20 of 21 posts
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#12A 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.
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#13Nice find! Have you contacted the vendor to check if they're planning a fix?
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#14TFA says it all in the first sentence describing the problem: The Bug Mode 4 uses AES-256 in ECB mode ... ECB is the least secure encryption mode you can use, the one that's warned against in every beginner text. Seeing this is a bit like seeing "We vibe-coded our firewall in PHP...", it's pretty much a written guarantee that the rest of it will be a catalogue of wrong. They did use AES-256 though, because using keys…
The problem with ECB is that you must know when to use it. It is not recommended only for the people who do not know cryptography, so they are not able to judge when the use of ECB is right and when it is wrong.
ECB is as secure as any other mode of operation if you only encrypt values that are never repeated, e.g. values produced by a counter, or if you encrypt values that have negligible probability of repeating, e.g. random values, such as secret keys. The defect of ECB is that if the adversaries would ever see the encrypted form of 2 identical values, they will know that those values were identical, which may help them to decrypt the message, or not, but such a risk must be avoided.
As another poster has said, here the main problem was the key derivation method used by them, which produced low-entropy keys that can be found by brute-force search.
In general, it is quite rare to be able to break even the weakest methods of encryption that are used today, when they use appropriate secret keys.
The method used for secret key generation is almost always the weakest part, which can frequently be broken.
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#15A 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. [1]: https://words.filippo.io/the-ecb-penguin/
ECB leaks the identity of aligned 16-byte blocks.
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.
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#16Earlier quoted context omitted.
> 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. [1]: https://words.filippo.io/the-ecb-penguin/
ECB leaks the identity of aligned 16-byte blocks. 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 i…
> Here the problem was their key generation method, which produced guessable keys, not the use of ECB.
I didn't say ECB was the issue. I was just riffing on the ECB penguin being a famous example of cryptographic failures being literally visible.
(I have no idea how SPICE models are encoded.)
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#17Earlier quoted context omitted.
ECB leaks the identity of aligned 16-byte blocks. 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 i…
> Here the problem was their key generation method, which produced guessable keys, not the use of ECB. I didn't say ECB was the issue. I was just riffing on the ECB penguin being a famous example of cryptographic failures being literally visible. (I have no idea how SPICE models are encoded.)
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.
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#18I posted SpiceCrypt ( https://github.com/jtsylve/spice-crypt ) a few days ago for decrypting LTspice models. It now supports all six PSpice encryption modes as well. PSpice is Cadence's SPICE simulator. Vendors encrypt component models with it, which locks them to PSpice and prevents use in NGSpice, Xyce, etc. Modes 0-3 and 5 derive keys entirely from constants in the binary, so those are straightforward once you ext…
The key sizing seems very odd - 4 bytes for DES? Even in the bad old days of 40-bit export crypto you'd get at least 5 bytes. For full-strength single-DES I'd expect either 7 or 8 bytes (56 bits of key used by the algorithm, but there's an quirk around key parity that means keys are commonly represented in 8 bytes). And a 27-byte key for AES-256 is also slightly undersized. Far from catastrophic but, like brown M&M's…
It's even worse than the key derivation. from the poster's Github repo, https://github.com/jtsylve/spice-crypt/blob/v2.0.1/SPECIFICA...:
Modes 0–2 use a custom DES variant that retains the standard 16-round Feistel network structure but differs from FIPS 46-3 in its permutation tables, S-boxes, and key rotation direction.
Looks like the DES-related modes were developed back before crypto code export restrictions were relaxed.
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#19> so engineers can use lawfully obtained models in any simulator
Hahaha where did I leave my DMCA stamp? -Cadence lawyers probably.
Re: A Copy-Paste Bug That Broke PSpice AES-256 Encryption
#20TFA says it all in the first sentence describing the problem: The Bug Mode 4 uses AES-256 in ECB mode ... ECB is the least secure encryption mode you can use, the one that's warned against in every beginner text. Seeing this is a bit like seeing "We vibe-coded our firewall in PHP...", it's pretty much a written guarantee that the rest of it will be a catalogue of wrong. They did use AES-256 though, because using keys…
The problem with ECB is that you must know when to use it. It is not recommended only for the people who do not know cryptography, so they are not able to judge when the use of ECB is right and when it is wrong. ECB is as secure as any other mode of operation if you only encrypt values that are never repeated, e.g. values produced by a counter, or if you encrypt values that have negligible probability of repeating, e…
... and you're not worried about an attacker swapping around any block of ciphertext they want at their leisure, for example the block containing someone else's encrypted bank account number for the actual payee's bank account number. Or several other issues, look up "ECB penguin" for an example.
But the main issue with it is that it's a huge red flag. Seeing ECB being used is a signal that whoever wrote the code has no idea what they're doing, which in turn is an invitation to look further for all the other things they'll have got wrong.