Re: How to do secure coding and create secure software

[Jeffrey Walton <noloader () gmail com>]

On Sun, Sep 28, 2025 at 10:53 AM Amit <amitchoudhary0523 () gmail com> wrote:
> On Sun, 28 Sept 2025 at 03:11, Solar Designer <solar () openwall com> 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