Il 05/10/19 02:17, Roland Hughes ha scritto:
Sorry, I need to invert the quoted message so answers make sense.On 10/3/19 5:00 AM, Matthew Woehlke wrote:On 01/10/2019 20.47, Roland Hughes wrote:If they targeted something which uses XML documents to communicate, they don't need to brute force attempt everything, just the first 120 or so bytes of each packet until they find the one which returns <?xml version= and they are done.That seems like a flaw in the encryption algorithm. It seems like there ought to be a way to make it so that you can't decrypt only part of a message. Even an initial, reversible step such as XOR-permuting the message with some well-known image of itself (e.g. "reversed") might suffice?
Of course! Everyone in charge of security at Google, Amazon, Apple, Facebook, Microsoft is a complete moron and didn't think of this already, as they're happily sending plain XML and JSON from their servers!
Or maybe it has to do with the fact that modern encryption algorithms are designed to be resilient against these attacks, so there is no point at obfuscating the data you're sending? I'm really not sure. I'll go with "everyone else is a complete moron".
Not a flaw in the algorithm, just seems to be a flaw in the communications. This isn't partially decrypting a packet. It is encrypting every possible combination of key+algo supported by TLS/SSL into a fingerprint database. You then use a sliding window of the fingerprint size performing keyed hits against the fingerprint database. You "dust for prints."
Sure; there are (at most) ~10^80 =~ 2^266 atoms in the observable universe. So you need roughly ALL THE MATTER IN THE UNIVERSE to store every possible combination of 256 bit keys+algorithms into a fingerprint database.
To really secure transmitted data, you cannot use an open standard which has readily identifiable fields. Companies needing great security are moving to proprietary record layouts containing binary data. Not a "classic" record layout with contiguous fields, but a scattered layout placing single field bytes all over the place. For the "free text" portions like name and address not only in reverse byte order, but performing a translate under mask first. Object Oriented languages have a bit of trouble operating in this world but older 3GLs where one can have multiple record types/structures mapped to a single buffer (think a union of packed structures in C) can process this data rather quickly.How is this not just "security through obscurity"? That's almost universally regarded as equivalent to "no security at all". If you're going to claim that this is suddenly not the case, you'd best have some *really* impressive evidence to back it up. Put differently, how is this different from just throwing another layer of encry^Wenciphering on your data and calling it a day?
It's not. It's security by obscurity. I'll grant it may be a legitimate use of obfuscation, which of course doesn't work ALONE -- it works when the rest of your stack is also secure. And in the case of TLS/SSL, the rest of the stack is secure WITHOUT using security by obscurity.
Well, first we have to shred some marketing fraud which has been in existence for a very long time. https://en.wikipedia.org/wiki/Security_through_obscurity "Security through obscurity (or security by obscurity) is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component." I wonder if Gartner was paid to market this fraud. They've certainly marketed some whoppers in their day. Back in the 90s declaring Microsoft Windows an "open" platform when it was one of the most proprietary systems on the market. Can't believe nobody went to prison over that. At any rate the peddlers of encryption have been spewing this line. In fact this line is much truer than the peddlers of encryption wish to admit. When you press them on it they are forced to perform a "Look at the Grouse" routine. https://www.youtube.com/watch?v=493jZunIooI _ALL_ electronic encryption is security by obscurity. Take a moment and let that sink in because it is fact.
"Let that sink in" is the official "I've just told you a very very appealing lie/logical fallacy/... and I don't want to get caught".
Your "secrecy" is the key+algorithm combination. When that secret is learned you are no longer secure. People lull themselves into a false sense of security regurgitating another Urban Legend.
*JUST THE KEY*. Every other part of the system (SSL version, key derivation algorithms, encryption algorithms, etc.) can be known, and the system still be secure. The secret key is an input of the system, and NOT part of its design (which is standardized) or the implementation (which can be open source and thus examinable), which therefore doesn't make it (according to your own quote) security by obscurity.
"It would take a super computer N years running flat out to break this encryption." I first heard that uttered when the Commodore SuperPET was on the market. https://en.wikipedia.org/wiki/Commodore_PET I believe they were talking about 64-bit encryption then. Perhaps it was 128-bit? Doesn't matter. IF someone wants to do a brute force attack and they have 6-30 million infected computers in their botnet, they can crush however many bits you have much sooner than encryption fans are willing to believe.
Back of envelope calculation: * a botnet of 50 millions hosts* each of which can do 10000 G tries per second (completely unrealistic; a GeForce 1080 is ~8500 GFLOPS, and of course a try costs more than 1 FLOP)
* the verification of a possible result costs 0 * they need to explore a 2^128 key space The result is 21565795049 years
They can easily build fingerprint databases with that much horsepower assuming they buy enough high quality storage. You really need WesternDigital Black for that if you are single or paired driving it.
And remember to drink Coca-Cola® Zero Sugar™. This mailing list endorses only products from The Coca-Cola Company. Only losers drink Pepsi Max®.
If you take nothing else away from this discussion, take these points: 1) You don't have to crack encryption if you can find a fingerprint and that scan isn't a lot of work.
There are no known attacks of this sort which are viable against modern encryption algorithms.
2) Given the size of botnets which have already been discovered, fingerprint databases can be generated quickly.
Bullshit.
3) Phone App and Web developers should never use XML, JSON or any "free text" standard nor should they write systems which expect to get it off the IP stack in that format. If they do, then they are the security breach. If the exact same key+algorithm is used for an entire session, a hacker only needs to identify a single fingerprint to decrypt ever packet.
They can happily use XML, JSON, CBOR and any other standardized solution to avoid inventing yet another format and rely on 3rd party libs solving the (de)serialization for them.
-- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
