Re: How to do secure coding and create secure software

[Amit <amitchoudhary0523 () gmail com>]

On Mon, 29 Sept 2025 at 01:21, Jeffrey Walton <noloader () gmail com> wrote:

> 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>.
To sum it all up, people have raised two points:

1. Secure functions can't secure the software if the logic inside the
function is not secure or if there is a bug.
2. Wrong ordering of secure function calls can lead to insecure software.

The above point number 1 is already addressed in my article. I will copy
paste the lines that handle this issue:

=======================
2. The function body should also be secure. After writing code, you should
review your code for security issues and also get it peer reviewed for
security
issues. In general, you should always get your code peer reviewed for
security
issues, bugs, company coding guidelines, etc.
=======================

So, it looks like people didn't read this point.

So, now point number 1 is addressed.

Also, if I say that a function should be secure then it definitely implies
that the whole function should be secure and the function body should also
be secure.

If the function's body is not secure then we can't call it a secure
function.

If a function's body has bugs that will lead to hacking then obviously we
can't call that function a secure function.

Secure function means secure function in all respects. I don't understand
why people are thinking that a secure function can have bugs, insecure
logic, etc.

If someone tells me that a function is secure then I will assume that the
function is secure in all respects - checking arguments, no bugs in body,
etc. and I have already made this clear in point 2 of my article.

Now, coming to the above point number 2:

An example of openssh is given that it first does authentication and then
it does encryption and this is insecure. I will investigate this and reply
later.

----------------------------------------------------------------------------------------------------------------