[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230529094842.10a6291b@inria.fr>
Date: Mon, 29 May 2023 09:48:42 +0200
From: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
To: NRK <nrk@...root.org>
Cc: musl@...ts.openwall.com
Subject: Re: [C23 string conversion 1/3] C23: add the new
memset_explicit function
Hi,
on Sun, 28 May 2023 16:13:18 +0600 you (NRK <nrk@...root.org>) wrote:
> On Fri, May 26, 2023 at 11:25:43AM +0200, Jens Gustedt wrote:
> > By having a slow bytewise copy, we intent also to have predictable
> > timing, such that we can avoid side-channel attacks.
>
> I don't believe `volatile` provides any guarantee of emitting
> constant-time operations (which can be CPU dependent). But even if it
> happens to work out in practice, from a user/non-cryptographer's
> perspective, I feel like claims like "avoiding side-channel attacks"
> needs much more substantiation than just slapping a `volatile` on top
> of a pointer.
>
> But as I've said, not a cryptographer,
I am not a cryptographer either, I wrote that code in best effort
mode: doing anything that I can that doesn't harm the goals of this
function. Very likely, this code will sit there unattended for the
next 20 years. I personnally do not know what the future brings, what
compilers will be capable of, and what the expectation of users will
be. In my opinion putting `volatile` in here is worth it, even if it
only might inhibit one single exploit in the next 20 years.
The same holds for stronger synchronization, I don't know about the
capabilities (or bugs) of future systems where an external agent from
a different thread, process or outside tool might guess addresses and
peek into storage, caches, whatever, before the information is
erased. Closing the window for this as much as possible seems a valid
strategy to me.
`memset` and `memset_explicit` have quite orthogonal goals. The
first is to put a buffer in a known state *before* you use it, it is
used often and performance is crucial.
The second is to put a buffer back into a known state *after* you use
it, to remove all the traces that your application migh have left
there, and avoid any unintended outflow of information. It will be
used rarely, probably on small bits of data (pathwords and such) and
performance is irrelevant.
So I think that the arguments should go just in an opposite direction
for this particular function than we usually have it.
> so please *do* correct me if I'm wrong or am being unnecessarily
> paranoid.
In the contrary, you may not be sufficiently paranoid. Paranoia is key
for this function.
> P.S: even if the claim is correct, other major implementation would
> also have to agree to provide such guarantee in a documented manner
> for this to be useful to the users. Otherwise, users will have to
> resort to hard-coded libc checks or simply not rely on this property
> at all.
I don't buy that argument either. This function is not there for
specific guaratees that a platform gives. It is a best effort attempt
by *us* to avoid information leakage. This is our responsability here,
nothing else.
Thanks
Jₑₙₛ
--
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
