SoylentNews is people
SoylentNews
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.
(Score: 3, Insightful) by JoeMerchant on Wednesday February 12 2020, @12:08PM (36 children)
Homegrown crypto is the only way you can be truly sure that it hasn't been laced with stuff you don't want.
It may not be as potent as the University lab academically cultivated varieties, but unless you're going to grind it down and analyze every bit before you use it... you just don't know.
After all, crypto is for the paranoid.
🌻🌻 [google.com]
(Score: 5, Insightful) by FatPhil on Wednesday February 12 2020, @01:19PM (20 children)
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
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @04:21PM
Do you use Windows?
(Score: 2) by DannyB on Wednesday February 12 2020, @05:01PM (17 children)
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?
The lower I set my standards the more accomplishments I have.
(Score: 2) by maxwell demon on Wednesday February 12 2020, @05:43PM (16 children)
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)
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.
The lower I set my standards the more accomplishments I have.
(Score: 4, Informative) by maxwell demon on Wednesday February 12 2020, @06:45PM (4 children)
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)
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'
The lower I set my standards the more accomplishments I have.
(Score: 2) by fido_dogstoyevsky on Thursday February 13 2020, @12:56AM
Bad guy: decrypt using $5 spanner.
It's NOT a conspiracy... it's a plot.
(Score: 0) by Anonymous Coward on Thursday February 13 2020, @01:51PM (1 child)
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
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)
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
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.
The lower I set my standards the more accomplishments I have.
(Score: 2) by FatPhil on Wednesday February 12 2020, @10:12PM (7 children)
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)
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
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)
"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
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)
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
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
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
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]
(Score: 3, Interesting) by zocalo on Wednesday February 12 2020, @02:14PM (8 children)
For everyone else, there *are* a few open source libraries out there that are generally pretty well trusted and have had their code independently audited, but that's still no guarantee that there are not some flaws in the underlying algorithm, or even obscure enough to be cleverly slipped into the code, that might be known to intelligence agencies, but that would still seem to be best starting point. Pick your library carefully (and ideally from a team based in a country you don't care about should it actually turn out to be backdoored), and if your data really matters maybe consider double-encrypting with two different libraries, implementing two different algorithms, from teams in two different locales. Either way, RFTM and make sure that you don't mess up the config / key generation - just because you're using a good algorithm doesn't automatically mean you're secure.
UNIX? They're not even circumcised! Savages!
(Score: 2) by Mojibake Tengu on Wednesday February 12 2020, @02:19PM (4 children)
Me. I use my own crypto for family business and communication. Not open, though.
I think all families/clans should develop their own software, instead of commodity stuff.
It's only way to trust.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2) by DannyB on Wednesday February 12 2020, @05:03PM (3 children)
Why not use well recognized standard algorithms in addition to custom crypto?
The lower I set my standards the more accomplishments I have.
(Score: 3, Insightful) by Mojibake Tengu on Wednesday February 12 2020, @05:23PM (2 children)
Because, some of those well recognized standard algorithms may be, or truly are, not to be trusted, and possible fallback to them may serve as an exploit.
For this very reason, broken algorithms are often removed from standard libraries even in classic methodology.
Frankly, I consider this well recognized standard algorithms a pure dogma, pushed and spinned by intelligence communities mostly.
They understand well when world adopts a massive fragmentation strategy in cryptography, their own game is over.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 3, Touché) by JoeMerchant on Wednesday February 12 2020, @05:34PM
It's like the difference between guerrilla warfare and standing up your army in a nice green field in pretty rows to be counted.
🌻🌻 [google.com]
(Score: 2) by Bot on Thursday February 13 2020, @12:00AM
I tend to trust parent poster when it comes down to crypto.
>Mojibake Tengu
Look, even the name looks like cyphertext.
Account abandoned.
(Score: 2) by JoeMerchant on Wednesday February 12 2020, @02:27PM (2 children)
And, as long as these can be assured to not exfil data, they make a good layer. They're still well known and therefore will be subject to more heavily resourced attack than a DIY layer that only protects a limited subset of data...
🌻🌻 [google.com]
(Score: 2) by zocalo on Wednesday February 12 2020, @02:56PM (1 child)
UNIX? They're not even circumcised! Savages!
(Score: 2) by JoeMerchant on Wednesday February 12 2020, @04:34PM
I fall back on the old proverb: the tallest tree is the first cut down.
Luckily, crypto stacks, so you can use a very tall tree, plus a bush of your own devising, and when the big tree falls (and don't kid yourself, academics aren't the only ones - or the best resourced ones - chopping away...) that home grown fig leaf will actually provide more security than DES / TwoFish / whatever well trusted standards you have hung your hat on.
The problem in the article is that people just bought a solution off the shelf and trusted the buzzwords - and be sure the CIA knows all the right buzzwords to put on the shrink-wrap to appeal to their target population of paranoids.
🌻🌻 [google.com]
(Score: 3, Disagree) by ledow on Wednesday February 12 2020, @02:20PM (2 children)
Homegrown crypto is a terrible idea.
Well-established, well-published, very-open, oft-attacked, well-tested encryption is literally out there for the taking. There are entire books about how to do it, and software and source to just download. I'm a mathematician. I wouldn't *attempt* to make my own, in the fact of that.
The lesson here is: Don't trust someone else to do the encryption for you. Every third-party VPN, encryption product, key-manager, cloud service, etc. is at risk of infiltration or outright purchase.
Further: People who use password management software that isn't entirely offline and has any online sync capability at all, or is closed-source are *insane*. People who let third-party antivirus / internet suite software run riot over every file, website, etc. they access, with full administrator rights, and unimpeded Internet access are literally just handing their keys to places like Kaspersky, McAfeee, Symantec, etc.
Don't trust encryption to a third party. But trying to do it yourself is like trying to knock up a secure operating system by yourself, it's never going to work or do what you need, and will be laughed out by those who break into such things for a living.
Get the verified source of a well-known and well-attacked encryption system, and utilise that, offline. What untrusted medium you then send those files by really doesn't matter at all, that's the point of encryption. But encrypt/decrypt only on your own machines, under your own control, and with no third-party snooping possible.
Hell, you should even be running that software as a limited user with no rights to anything else, including networking. There's no telling what might be talking home without you knowing.
If you seriously care about encryption, "buying it in" is an utter, 100%, complete nonsense.
The vast majority of people, things, etc.? It really doesn't matter. But if you care enough to buy a third-party crypto product? Then you should NOT be buying a third-party crypto product.
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @08:47PM (1 child)
You are confused. So we must not roll our own but use a well-tested thing, but now also not buy such a product from what seems to be a legit vendor? So I am caught between the extreme of buying ROT-13 from IBM or eliptical AES tri-doublechucky 4K key but handcoded in Visual BASIC by the guy in the alley who also sells joints? Or...?
(Score: 3, Insightful) by ledow on Thursday February 13 2020, @12:24AM
Don't roll your own encryption algorithm. Use a well-published and attacked one.
Don't use a commercial implementation. They can change under you and thus you can't audit the code for every change - they are also under the control of a third-party.
There are plenty of source-level, heavily tested implementations, that are free and you can use on your own. Use one of those.
Hence, download a well-tested encryption library, with available source code, and compile it yourself. Do NOT try to write one yourself - there are far too many pitfalls in doing so.
(Score: 0) by Anonymous Coward on Wednesday February 12 2020, @08:44PM
XOR, have been using it for years! Combine it in a double-cipher with ROT-13 and you are good to go.
Hmm... today's updated prong 2 of the devil's fork... Avast and their spyware. Could it be the same TLA?
(Score: 3, Insightful) by edIII on Thursday February 13 2020, @02:27AM
If you want to be sure what is going on, and want to
writeroll your own, use the reference implementations. They're there specifically to make sure they don't have stuff you don't want, and allow vetting by the crypto community at large. There not obfuscated, and are open code. This allows us to have some trust in the code, as long as we have some trust in the academic community.Crypto is just way too complicated a subject for any ordinary programmer to tackle. It's hubris to think that you not only have the programming chops to make sure there are no security holes in your implementation, but also that you have the mathematical chops to grok all the math, the algorithms, the timing, .etc. Do you understand oracle padding enough to inspect an encryption implementation to make sure it isn't possible? This is why the reference implementations are nice, because much smarter people than you or I, vetted them.
All that being said, home grown crypto is 100% impossible to break by anyone, under a very specific set of circumstances:
- Alice uses the SBC with the phrase "Rocky & Bullwinkle"
- Cipher text is generated and sent
- Bob receives cipher text with plaintext "Rocky & Bullwinkle" as a label
- Bob uses the SBC to receive original plaintext after feeding in the label as the parameter.
That's the big ol' brick version of it. Not very practical, but it's sure as hell secure. From what I understand the military does the same damn thing (HDs full of entropy) in top secret planes. Drive space is cheap. You just load up enough OTP along with the ordnance for the mission parameters. Telemetry is decoded with a local copy on the base.
A 10TB HD is a large number of communications, even ones with a few seconds of video attached. You can go years without exchanging again. For situations in which physical contact is regular, additional exchanges are easily possible to refresh OTP "reserves" as it were.
Other than OTP, which is so damn simple a child can do it, there doesn't exist anything else simple enough for the common programmer or sysadmin to be able to code without vulnerabilities. Which is why we need to rely very public, very transparent, and very much discussed and reviewed, reference implementations. Those need to be used by competent people to contribute to our various libraries so we can have some reasonable levels of trust. As most exploits seem to work against poor implementations, and not core insights into breaking the math, it makes a lot more sense for us to have a robust process ensuring people have access to vetted code and libraries.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 0) by Anonymous Coward on Sunday February 16 2020, @02:22AM
I hope you also write your own compiler to compile said homegrown crypto and use your own homegrown hardware to run it on.