I posted SpiceCrypt (<a href="https://github.com/jtsylve/spice-crypt" rel="nofollow">https://github.com/jtsylve/spice-crypt</a>) a few days ago for decrypting LTspice models. It now supports all six PSpice encryption modes as well.<p>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.<p>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.<p>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.<p>This has likely been shipping since PSpice 16.6 in 2014. Fixing it would break every encrypted model created in the last twelve years.<p>The blog post linked above walks through the full details. The repo also has specifications documenting all the encryption schemes: <a href="https://github.com/jtsylve/spice-crypt/tree/v2.0.1/SPECIFICATIONS" rel="nofollow">https://github.com/jtsylve/spice-crypt/tree/v2.0.1/SPECIFICA...</a>
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).<p>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.<p>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.