On Sun, Sep 28, 2025 at 10:53 AM Amit <[email protected]> wrote: > > > On Sun, 28 Sept 2025 at 03:11, Solar Designer <[email protected]> wrote: >> >> >> You claim that "If functions/methods are secure then the whole software >> is secure." If we talk C where main() is also a function, and limit the >> definition of "whole software" to one program, then I'd agree - your >> claim can as well directly say "if [all functions including] main() are >> secure then the whole software [meaning this one program only] is >> secure." While true, under those definitions this isn't a useful claim. >> >> However, if in "functions/methods are secure" you refer only to smaller >> building blocks, then no, the program built from them may still be >> insecure. Also "the whole software" isn't necessarily just one program. > > [...] > But the point is that this is what people have said and this is all > theoretical. > > Can someone give an example as to how a software made up of secure functions > can be hacked?
Authenticated Encryption. You might have a module that performs AES encryption, and another module that performs MAC'ing using SHA-256. But if you combine them incorrectly, you have an insecure system. If interested, the way to combine them so they are provably secure is Encrypt-then-Authenticate (EtA) as used in IPSec. And the counterexamples... The way SSH combines them is insecure, and the way TLS combines them is insecure. SSH and TLS combine them in a way that sets up an oracle. In crypto engineering speak, SSH and TLS are _not_ IND-CCA2. (IND-CCA2 is a strong notion of security). And it gets worse. Some developers use encryption alone -- they do not provide an authentication tag. That is, the developer completely omits the MAC step. So all cipher texts are vulnerable to tampering. Also see Hugo Krawczyk's paper "The Order of Encryption and Authentication for Protecting Communications" (2001), <https://www.iacr.org/archive/crypto2001/21390309.pdf>. Jeff
