Hacker News Reader

Comment by paulmd | Hacker News Reader

It's impossible to "reverse-engineer" a cryptographic signature. Properly implemented (and you can bet that Intel has had time to finalize this) it's computationally insurmountable.

View on HN

Not the signature, the payload. It's very complex. I guarantee there are bugs.

Indeed, the blob can be reverse engineered.

Even more, an unbreakable signature can have it's private key stolen by hacking, by agencies inserting personnel into the companies, by agencies blackmailing key personnel and by agencies compelling the companies legally or ex-legally to hand them their keys.

Really, if someone has gone to the trouble of working out an exploit for Intel ME, the most ironic thing they could pull off would be to use that very exploit against Intel's own systems to steal their key, use it to patch the bugs, and release the patch to the world.

It'd be a spectacular successor to that router-patching virus that made the rounds a while back.

just like how DVD Encryption (https://en.wikipedia.org/wiki/Content_Scramble_System) was never reverse engineered because the key was too difficult to crack ?

CSS is only 40 bits, which is ridiculously easy to crack. 56-bit DES keys are pretty unsafe these days, so you want at least 128 bits if you're talking private keys.

If it's using 2048-bit RSA, that's perhaps equivalent to a 256-bit private key.

So entirely different ballpark to CSS.

Wrong. 2048-bit RSA has an effective security level of approximately 112 bits, just like 3-DES. If you want 256 bits of security, you go all the way up to 15360-bit RSA. That's why Elliptic Curve systems are so attractive: they involve operations that are more costly per-bit, but the required key sizes to meet a security level are much less. Ofcourse, Elliptic Curve Cryptography as specified by NIST has its own downsides (e.g. the 3 most common curves, prime256v1, secp384r1, and secp521r1 (128 bits, 192 bits, and 256 bits of security respectively) have constants that were chosen arbitrarily by NSA with no explanation).

Though when the NSA has done things like this in the past, we've found their choices prevented implementation weaknesses that weren't found (by anyone else) for several more years.

When has this happened? I'm curious about things that could cast the NSA in a positive light.

The DES standard's S-Boxes were changed by the NSA in the 1970s. It was long thought that this was to weaken them. However in the 1990's differential cryptanalysis was publicly discovered, and the NSA's changes to the S-boxes were found to have hardend DES agaist differential cryptanalysis.

Now here's something fascinating. According to https://en.wikipedia.org/wiki/Differential_cryptanalysis#His..., IBM discovered differential cryptanalysis in the 1970s when designing DES. They opted to keep it a secret, given its general applicability against ciphers. It is unclear whether IBM shared it with the NSA or the NSA discovered it independently, but there's strong evidence that both IBM and the NSA were aware of differential cryptanalysis well before the public discovery in the 90s.

¹ This has what looks like a good citation but requires a subscription to access the relevant paper (sigh).

Can you follow up on that? I've never heard that story and I'm really curious.

On the narrower point, though, it's been shown that Dual_EC_DRBG is broken, and that the NSA values compromised the implementation instead of strengthening it.

S boxes in DES were originally nonexistent/vulnerable to differential cryptanalysis when IBM first made Lucifer.

It really doesn't matter how many bits, or what cipher they used. The DRM problem is fundamentally broken:

1. Hand the ciphertext to the opponent.

2. Hand the decryption algorithm to the opponent, embedded in a software or hardware device.

3. Hand the key to the opponent, possibly embedded in the hardware.

4. Ask your opponent to decrypt the ciphertext, view the plaintext, and then kindly not copy the plaintext in any other way.

Reply on news.ycombinator.com