I 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 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 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...
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.
Why would you need a custom DES variant? Did Cadence have a cryptographer on staff? Or did they license this DES-variant? Or was a three-letter US government agency involved?
Looks like the DES-related modes were developed back before crypto code export restrictions were relaxed.
TFA 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 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.
... 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.
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.
12 comments
[ 7.8 ms ] story [ 44.0 ms ] threadPSpice 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...
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...
Looks like the DES-related modes were developed back before crypto code export restrictions were relaxed.
They did use AES-256 though, because using keys that go to 11 for your insecure encryption looks good in the marketing materials.
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.
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.
Hahaha where did I leave my DMCA stamp? -Cadence lawyers probably.