A Copy-Paste Bug That Broke PSpice AES-256 Encryption(jtsylve.blog)
jtsylve.blog
A Copy-Paste Bug That Broke PSpice AES-256 Encryption
https://jtsylve.blog/post/2026/03/18/PSpice-Encryption-Weakness
20 comments
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 in the green room of a Van Halen concert venue, it's a strong signal that something is off...
And a 27-byte key for AES-256 is also slightly undersized. Far from catastrophic but, like brown M&M's in the green room of a Van Halen concert venue, it's a strong signal that something is off...
To me, it's a sign of crypto being used to tick off a box (and perhaps not arouse concerns around export), and not anything resembling a serious security system. "Locks are for keeping honest people honest," as the saying goes.
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...:
Looks like the DES-related modes were developed back before crypto code export restrictions were relaxed.
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.
I think they concatenate a 4-byte key and a 4 byte versions string to get the full 8-byte DES key.
And the idea for the AES key seems to have been: 27-byte key, 4-byte version, 1 byte null terminator for a total of 32 bytes.
And the idea for the AES key seems to have been: 27-byte key, 4-byte version, 1 byte null terminator for a total of 32 bytes.
TFA says it all in the first sentence describing the problem:
They did use AES-256 though, because using keys that go to 11 for your insecure encryption looks good in the marketing materials.
The Bug
Mode 4 uses AES-256 in ECB mode ...
They did use AES-256 though, because using keys that go to 11 for your insecure encryption looks good in the marketing materials.
While ECB is rather insecure, it doesn't enable full decryption of the message unless you have access to a padding oracle or similar. The 32-bit key is the real problem.
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.
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.
... 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.
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.
What you say is not relevant to discussing ECB.
No method of encryption is secure against active attacks unless it is used together with an authentication method. This is equally true for ECB and for any other mode of operation of a block cipher and for any other method of encipherment.
Of course the use of ECB was inappropriate for this application, but despite this, the weakness of ECB is not enough to allow the decryption of encrypted SPICE models. Repeated blocks of 16 bytes aligned on 16 bytes boundaries would be very rare and even finding such repetitions in the short SPICE models is extremely unlikely to allow the guessing of even a small part of a model, which would still be useless, as only a complete model is useful.
So the use of ECB in this case is weird and it is a red flag about the competence of the implementer, but the use of ECB alone would be pretty much impossible to exploit for the decryption of SPICE models.
No method of encryption is secure against active attacks unless it is used together with an authentication method. This is equally true for ECB and for any other mode of operation of a block cipher and for any other method of encipherment.
Of course the use of ECB was inappropriate for this application, but despite this, the weakness of ECB is not enough to allow the decryption of encrypted SPICE models. Repeated blocks of 16 bytes aligned on 16 bytes boundaries would be very rare and even finding such repetitions in the short SPICE models is extremely unlikely to allow the guessing of even a small part of a model, which would still be useless, as only a complete model is useful.
So the use of ECB in this case is weird and it is a red flag about the competence of the implementer, but the use of ECB alone would be pretty much impossible to exploit for the decryption of SPICE models.
This "encryption" was arguably never for any security anyway, just obfuscation.
Any crypto that prevents casual tinkering is enough to keep most companies from wasting resources on reverse engineering stuff.
Back in the day we wrote a simple byte-level nonce + delta obfuscator for a terrible Node-RED-like programming environment so that we could tick a "must not be human-readable" requirements checkbox.
If the cryptography, proper or not, has been written for DRM purposes, no legal department is going to permit digging into implementation details even with a ten feet pole.
Back in the day we wrote a simple byte-level nonce + delta obfuscator for a terrible Node-RED-like programming environment so that we could tick a "must not be human-readable" requirements checkbox.
If the cryptography, proper or not, has been written for DRM purposes, no legal department is going to permit digging into implementation details even with a ten feet pole.
> so engineers can use lawfully obtained models in any simulator
Hahaha where did I leave my DMCA stamp? -Cadence lawyers probably.
Hahaha where did I leave my DMCA stamp? -Cadence lawyers probably.
Nice find! Have you contacted the vendor to check if they're planning a fix?
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.
[1]: https://words.filippo.io/the-ecb-penguin/
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.
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.
> 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.)
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.
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.
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 extract them.
Mode 4 is the interesting one. It's the only mode with user-supplied key material and uses AES-256 in ECB mode. The key derivation has two base keys: a 4-byte short key (originally for DES) and a 27-byte extended key (intended for AES). The code passes only the short key to the AES engine -- it looks like a copy-paste from the DES path that was never corrected. The short key gets null-terminated and zero-padded to 32 bytes, so 28 of 32 AES key bytes are known. Effective keyspace is 2^32, brute-forceable in seconds with AES-NI.
The first encrypted block after every marker is a metadata header with a known plaintext prefix, which gives you a crib for validation. Once you recover the 4-byte short key, the full user key is also recoverable from the decrypted header.
This has likely been shipping since PSpice 16.6 in 2014. Fixing it would break every encrypted model created in the last twelve years.
The blog post linked above walks through the full details. The repo also has specifications documenting all the encryption schemes: https://github.com/jtsylve/spice-crypt/tree/v2.0.1/SPECIFICA...