Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by Fnord666 on Wednesday February 12 2020, @11:03AM   Printer-friendly
from the put-all-your-secrets-in-one-basket dept.

'The intelligence coup of the century'

In case of paywall...
CIA Secretly Owned Crypto, the Swiss Company That Ruled Global Spy Comms for Decades, Says Report

For more than half a century, governments all over the world trusted a single company to keep the communications of their spies, soldiers and diplomats secret.

The company, Crypto AG, got its first break with a contract to build code-making machines for U.S. troops during World War II. Flush with cash, it became a dominant maker of encryption devices for decades, navigating waves of technology from mechanical gears to electronic circuits and, finally, silicon chips and software.

The Swiss firm made millions of dollars selling equipment to more than 120 countries well into the 21st century. Its clients included Iran, military juntas in Latin America, nuclear rivals India and Pakistan, and even the Vatican.

But what none of its customers ever knew was that Crypto AG was secretly owned by the CIA in a highly classified partnership with West German intelligence. These spy agencies rigged the company's devices so they could easily break the codes that countries used to send encrypted messages.

For the most goodest security, use only one commercial crypto system. Trust it with all your secrets.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by FatPhil on Wednesday February 12 2020, @10:12PM (7 children)

    by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Wednesday February 12 2020, @10:12PM (#957430) Homepage
    Compression being part of encryption is a terrible idea, for the reasons mentioned above - it leaks the entropy of the plaintext. If it compresses much, that's a big leak, and if it doesn't compress much, there's no point in doing it.
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Wednesday February 12 2020, @11:52PM (1 child)

    by Anonymous Coward on Wednesday February 12 2020, @11:52PM (#957485)

    From my understanding it's better to compress before encrypting as long as the encryption algorithm used doesn't have any predictable information (ie: predictable headers or patterns). IIRC there are compression algorithms specifically intended to be used with cryptography that resist having predictable prints. If the encryption cypher is stronge it should be difficult to crack regardless as the ciphertext should look random. Using block ciphers like AES would make it more difficult to determine the exact input length as well or to exactly correlate the possible plaintext locations from the ciphertext.

    • (Score: 0) by Anonymous Coward on Wednesday February 12 2020, @11:54PM

      by Anonymous Coward on Wednesday February 12 2020, @11:54PM (#957488)

      Sorry, there was a typo. I meant to say

      ... as long as the compression* algorithm used doesn't have any predictable information (ie: predictable headers or patterns).

  • (Score: 0) by Anonymous Coward on Thursday February 13 2020, @12:14AM (1 child)

    by Anonymous Coward on Thursday February 13 2020, @12:14AM (#957495)

    "it leaks the entropy of the plaintext."

    I don't see how compression leaks the entropy of the plaintext. Yeah, the person doing the compressing knows the entropy of the plaintext (highly compressible = lower entropy) but once it's compressed and encrypted the person with the ciphertext has no clue what the compressed or the uncompressed document looks like to know its entropy. The only thing they are left with is this high entropy ciphertext that shouldn't tell them anything about the compressed or uncompressed plaintext. A compressed document appears to have higher entropy than an uncompressed one and would be more difficult to crack into an easy to recognize plaintext as it needs to be uncompressed first.

    • (Score: 0) by Anonymous Coward on Thursday February 13 2020, @12:18AM

      by Anonymous Coward on Thursday February 13 2020, @12:18AM (#957497)

      That is it would be more difficult to crack a compressed encrypted document as it would be more difficult to find a recognizable pattern when trying to crack a compressed encrypted document since the document needs to be uncompressed first.

  • (Score: 2) by darkfeline on Thursday February 13 2020, @12:56AM (2 children)

    by darkfeline (1030) on Thursday February 13 2020, @12:56AM (#957515) Homepage

    It's only a terrible idea if an attacker can control part of the input, and the rest of the input should be hidden from the attack, which is a very specific case that mostly applies only to modern websites.

    Compression and encryption are very similar: you're trying to maximize entropy, that is, minimize redundant information. The only distinction is how easy the process is to reverse.

    If you compress a file with e.g. Huffman coding, then delete the tree, then what you're left with is effectively your ciphertext and the prefix tree is your encryption key. Vice versa, if you encrypt something and distribute the key along with the ciphertext, then you've effectively compressed it.

    Now of course compression and encryption algorithms are different, they prioritize very different things when trading off properties in the algorithm design. But from an information theory perspective they are very similar.

    There's no use arguing this with me, like I said, try the plain text example. Encryption DOES compress. You can of course pad the ciphertext, and that does in fact happen in various cryptosystems.

    for i in {1..1000000}; do echo $i >> /tmp/tmp; done

    gpg --output /tmp/tmp.gpg --symmetric /tmp/tmp

    stat /tmp/tmp; stat /tmp/tmp.gpg

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 2) by FatPhil on Thursday February 13 2020, @08:11AM

      by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Thursday February 13 2020, @08:11AM (#957643) Homepage
      > you're trying to maximize entropy

      False, you're trying to maximise entropy density.

      > Encryption DOES compress.

      False. The GPG example you use is using an optional "also compress" feature of that GPG implementation, which is an *optional* part of the standard. It will create output that other implementations which do not support compression, cannot read. Your statement is as correct as saying "tarballs ARE compressed". That is to say, it's false.

      > There's no use arguing this with me

      That explains why you persist in holding incorrect views.
      --
      Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    • (Score: 0) by Anonymous Coward on Saturday February 15 2020, @11:13PM

      by Anonymous Coward on Saturday February 15 2020, @11:13PM (#958621)

      Well, something with high entropy tends to be difficult to compress but something difficult to (further) compress doesn't necessarily tend to be high in entropy.