Why would a company without cryptographic expertise modifying an existing algorithm without any particular goal in mind just to be different, produce something more secure than the winning solution in an open cryptographic competition?
> directory names
And file structure too, preferably. Incremental sync could be done with XTS mode.
Are you an AI?
Usually, non-specialists fiddling with cryptographic algorithms makes them much less secure. Developers who aren't cryptographic mathematicians should generally use a well-respected algorithm, follow current best practices, and treat that component as a magic box that's not to be tampered with.
Sounds like the "I know a guy" kind of thing that shouldn't be done if you really care about security.
>Are you an AI?
Non-sequitur.
Ofc, that must be encrypted on systems which "cannot connect" (and you can go overkill with EM protection with a very good faraday cage).
If you are making such a technical pain for attackers, they will switch to social engineering anyway.
If someone has an attack that would defeat the cryptographic protection in a particular piece of software, the software is likely doing one or more of the following:
* Not using a modern, well-tested algorithm (e.g. using DES, a hokey custom XOR stream cipher, AES-ECB, etc.).
* Not following general cryptographic best practices (e.g. hardcoded or predictable key/IV/nonce, insecure storage of keys).
* Not following best practices for the specific algorithm (e.g. using AES-GCM, but reusing a key/nonce combination; using AES-CBC without applying an integrity-protection mechanism).
* The software is doing something that doesn't make sense, cryptographically (e.g. using symmetric encryption to encrypt sensitive data, but the data and the keys are necessarily accessible to the same set of users/service accounts, so there's no net change in security).
If such an attack fails because a developer has made changes to the cryptographic algorithm, a motivated attacker is likely just going to look at the code in Ghidra, x64dbg, etc. and figure out how to account for the changes. It's not a strong security control. I've been decrypting content stored using that kind of software for something like 20 years.
The correct approach is to verify that the use of a particular type of cryptography makes sense in the first place, then use a well-tested modern algorithm and follow the current best practices. i.e. using code from years-old forum posts will likely result in an insecure product.
I repeat: the second you are online, you are cooked. Everything else is BS, probably somebody is trying to sell you something.
All you can do is to find compromise depending on the classification of the data.
And as I said, if you are making it too much hell for attackers, they will switch to social engineering.
Come on...
Everything else is, I am sorry to say, BS.