Hi, on Sun, 28 May 2023 16:13:18 +0600 you (NRK ) 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 ::