On 04/10/2019 20.17, Roland Hughes wrote: > On 10/3/19 5:00 AM, Matthew Woehlke wrote: >> On 01/10/2019 20.47, Roland Hughes wrote: >>> 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? > > _ALL_ electronic encryption is security by obscurity. > > Take a moment and let that sink in because it is fact. > > 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.
Well... sure, if you want to get pedantic. However, as I see it, there are two key differences: - "Encryption" tries to make it computationally hard to decode a message. - "Encryption" (ideally) uses a different key for each user, if not each message, such that compromising one message doesn't compromise the entire protocol. (Okay, granted this isn't really true for SSL/TLS unless you are also using client certificates.) ...and anyway, I think you are undermining your own argument; if it's easy to break "strong encryption", wouldn't it be much *easier* to break what amounts to a basic scramble cipher? > One of the very nice things about today's dark world is that most are > script-kiddies. If they firmly believe they have correctly decrypted > your TLS/SSL packet yet still see garbage, they assume another layer of > encryption. They haven't been in IT long enough to know anything about > data striping or ICM (Insert Character under Mask). So... again, you're proposing that replacing a "hard" (or not, according to you) problem with an *easier* problem will improve security? I suppose it might *in the short term*. In the longer term, that seems like a losing strategy. > He came up with a set of test cases and sure enough, this system which > worked fine with simple XML, JSON, email and text files started > producing corrupted data at the far end with the edge cases. Well, I would certainly be concerned about an encryption algorithm that is unable to reproduce its input. That sounds like a recipe guaranteed to eventually corrupt someone's data. > Even if all of that stuff has been fixed, you have to be absolutely > certain the encryption method you choose doesn't leave its own tell-tale > fingerprint. Some used to have visible oddities in the output when they > encrypted groups of contiguous spaces, nulls, etc. Plus, there are quite > a few places like these showing up on-line. Again, though, it seems like there ought to be ways to mitigate this. If I can test for successful decryption without decrypting the *entire* message, that is clear grounds for improvement. -- Matthew _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
