Stories
Slash Boxes
Comments

SoylentNews is people

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: 5, Insightful) by FatPhil on Wednesday February 12 2020, @01:19PM (20 children)

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Wednesday February 12 2020, @01:19PM (#957173) Homepage
    I disagree. Use algorithms that have withstood repeated attacks from those with a very high incentive (reputation in their field) to succeed in a crack.
    However, don't trust closed source implementations of said algorithms. All the big name algorithms come with reference implementations.
    Also, only use stuff that will run on hardware of your choice.
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    Starting Score:    1  point
    Moderation   +3  
       Insightful=3, Disagree=1, Total=4
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 0) by Anonymous Coward on Wednesday February 12 2020, @04:21PM

    by Anonymous Coward on Wednesday February 12 2020, @04:21PM (#957219)

    Do you use Windows?

  • (Score: 2) by DannyB on Wednesday February 12 2020, @05:01PM (17 children)

    by DannyB (5839) Subscriber Badge on Wednesday February 12 2020, @05:01PM (#957249) Journal

    You can use implementations in multiple programming languages and test them against each other. There are even implementations of common algorithms in . . . JavaScript. Not that I think it is a good idea, but it could be included in testing as yet one more verification that all tested implementations are doing the same thing. And specifically, that the implementation you are interested in, and intend to use, is matching up with many tests in written in other languages by multiple authors.

    And about home grown crypto.

    1. Don't.

    2. If you absolutely feel you must, and can't be talked out of it, then use it in addition to battle tested crypto. Not instead of. In this case, can you be sure that the combination is not weaker?

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.
    • (Score: 2) by maxwell demon on Wednesday February 12 2020, @05:43PM (16 children)

      by maxwell demon (1608) on Wednesday February 12 2020, @05:43PM (#957287) Journal

      In this case, can you be sure that the combination is not weaker?

      Unless your home-made crypto algorithm is somehow related to the professional crypto algorithm, the combination being weaker would imply the professional crypto being weak in the first place. After all, your homegrown crypto text is just the cleartext for the professional encryption algorithm.

      Or in short, I wouldn't worry that my ROT13 encryption step somehow breaks the subsequent AES encryption.

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 2) by DannyB on Wednesday February 12 2020, @06:18PM (15 children)

        by DannyB (5839) Subscriber Badge on Wednesday February 12 2020, @06:18PM (#957308) Journal

        I agree with your thinking here. But a counter argument I've heard / read is that there is no analysis for the strength of the two put together.

        Myself, I would be comfortable chaining several different well known algorithms together in sequence.

        Oh, and always compress your data before encrypting it. After the first encryption algorithm, regardless of compressibility of the plaintext, the ciphertext should statistically resemble randomness. There is no compressing it afterwards. Compression prior to encryption might make it just a bit harder to recognize a successful decryption (in a semi-brute force attempt). You could even compress first, then XOR pad against the output of a pseudo-random generator whose seed is part of your larger "key". Now a successful decryption (in a semi-brute force attempt) might look for certain well know file marks of a compressed file (eg, zip, 7zip, etc) -- but would not find them upon trivial inspection.

        --
        People today are educated enough to repeat what they are taught but not to question what they are taught.
        • (Score: 4, Informative) by maxwell demon on Wednesday February 12 2020, @06:45PM (4 children)

          by maxwell demon (1608) on Wednesday February 12 2020, @06:45PM (#957324) Journal

          Oh, and always compress your data before encrypting it.

          Note however that compression before encryption has been used to break encryption, in a web context where the attacker could add known content to the plaintext. The trick being that the compression got better if the injected text matched parts of the unknown text, and the size could be determined from the ciphertext.

          BTW, an idea for cases where a doubling of size does not matter: Generate a one-time pad (using true randomness), encrypt the message with the one-time pad, then encrypt the one-time pad with one standard algorithm/key, and the OTP-encrypted message with another standard algorithm/key. The total key consists of the two keys, and the total encrypted message of the two individually encrypted parts.

          This way, you need to break both standard algorithms to get at the information (breaking either one without breaking the other just gives you noise uncorrelated to the message), and the plaintext for each of them is just random noise, so no assumptions about the plaintext can be made on breaking either of the standard algorithms.

          --
          The Tao of math: The numbers you can count are not the real numbers.
          • (Score: 2) by DannyB on Wednesday February 12 2020, @07:17PM (1 child)

            by DannyB (5839) Subscriber Badge on Wednesday February 12 2020, @07:17PM (#957336) Journal

            1. Compress plaintext
            2. Prefix compressed binary with, say, four bytes of length
            3. Suffix (length + compressed block) out to some other random length
            4. XOR pad with pseudo random data, whose seed is part of your overall 'key'

            Now length is not easily determined.
            Compressed file indicators or file format not trivially detectable.

            5. encrypt using one (or several in sequence) standard algorithm(s), whose key(s) are part of your overall 'key'

            --
            People today are educated enough to repeat what they are taught but not to question what they are taught.
          • (Score: 0) by Anonymous Coward on Thursday February 13 2020, @01:51PM (1 child)

            by Anonymous Coward on Thursday February 13 2020, @01:51PM (#957701)

            This still leave the weakest link (key distribution) exposed. Now you have two keys that you need to distribute, and you COULD use different channels for each, but the likelyhood of that is low.

            • (Score: 2) by maxwell demon on Thursday February 13 2020, @01:59PM

              by maxwell demon (1608) on Thursday February 13 2020, @01:59PM (#957706) Journal

              What makes you think the key would need to be distributed? Not all encryption is for communication purposes.

              --
              The Tao of math: The numbers you can count are not the real numbers.
        • (Score: 2) by darkfeline on Wednesday February 12 2020, @08:54PM (9 children)

          by darkfeline (1030) on Wednesday February 12 2020, @08:54PM (#957387) Homepage

          Encryption algorithms should compress data already. You can test it, generate a large plaintext file, encrypt it with e.g. GPG, check the size.

          --
          Join the SDF Public Access UNIX System today!
          • (Score: 2) by DannyB on Wednesday February 12 2020, @09:01PM

            by DannyB (5839) Subscriber Badge on Wednesday February 12 2020, @09:01PM (#957393) Journal

            I'm not familiar with behavior of the GPG software.

            But encryption algorithms do not compress data generally, as far as I know.

            They typically take a fixed sized block of data as input and produce another fixed size block of data as output. These block mode ciphers can be run in a "stream" mode.

            --
            People today are educated enough to repeat what they are taught but not to question what they are taught.
          • (Score: 2) by FatPhil on Wednesday February 12 2020, @10:12PM (7 children)

            by FatPhil (863) <pc-soylentNO@SPAMasdf.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
            • (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-soylentNO@SPAMasdf.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.

  • (Score: 2) by JoeMerchant on Wednesday February 12 2020, @05:31PM

    by JoeMerchant (3937) on Wednesday February 12 2020, @05:31PM (#957274)

    a very high incentive (reputation in their field)

    I wonder how that incentive stacks up against state sponsored crypto breaking operations that have, for instance, dedicated power generation stations to feed their in-house developed breaker farms, agents recruited while still in University and retained for the sole purpose of being the best in the world, etc.

    I suppose I was a bit of a troll to not mention: roll in layers, and do put in a good layer of university approved strong crypto, just don't expect that alone to be your best defense against snooping from those who live to snoop.

    Once "the agency" has a crack for ECC (or any other well loved algorithm of your choice), they'll use it to troll every stream they can, in addition to continuing to support the publication of papers touting the algorithms' unbreakability.

    --
    🌻🌻 [google.com]