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...
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.
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.
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.
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 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...
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...
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.
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.
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.
TFA says it all in the first sentence describing the problem:
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.