You need only cryptographic common sense: it seems you have no idea how much it is easy to modify a mainstream cryptographic software to add basic and robust cryptographic modifications...

Are you an AI?

▲

blincoln 2 days ago | parent | next [-]

I've been assessing systems that use cryptography for about 20 years as part of my work in information security, and I've never seen a customization that increased the security of a cryptographic algorithm over following the best practices.

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.

▲

jamesnorden 2 days ago | parent | prev [-]

>You need only cryptographic common sense

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.

▲

sylware 2 days ago | parent [-]

Doing such "customizations" (which are actually crypto 101) will break all attacks designed specifically for a crypto algo in mind. Even better if you lie on the crypto algorithm.

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.

▲

blincoln 2 days ago | parent [-]

Algorithms like AES-GCM are standards because - when used according to best practices - there are no known practical attacks against them.

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.

	▲	sylware a day ago \| parent [-]
		Ofc, the code modifications and additional data are not public, neither they are online. And we are talking air gap transfer. 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...