Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #81897 > unrolled thread

For those arguing over languages...

Back to article view | Back to comp.os.linux.misc

Contents

  For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-10 09:09 +0000
    Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-10 13:11 +0000
    Re: For those arguing over languages... Farley Flud <ff@linux.rocks> - 2026-02-10 14:08 +0000
      Re: For those arguing over languages... Marc Haber <mh+usenetspam1118@zugschl.us> - 2026-02-10 15:16 +0100
        Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-10 16:19 +0000
          Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-10 18:20 +0000
        Re: For those arguing over languages... Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-10 11:22 -0500
        Re: For those arguing over languages... John  <john@panix.com> - 2026-02-17 16:23 +0000
          Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-19 19:26 +0000
            Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-22 09:28 +0000
      Re: For those arguing over languages... John Ames <commodorejohn@gmail.com> - 2026-02-10 08:24 -0800
        Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-10 18:16 +0000
    Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-10 22:34 -0500
      Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-11 18:50 +0000
        Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-11 19:28 +0000
          Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-11 21:27 +0000
            Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-12 09:48 +0000
              Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-12 20:48 -0500
        Re: For those arguing over languages... Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-11 16:24 -0500
          Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-11 22:45 +0000
            Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-12 12:42 +0000
        Re: For those arguing over languages... "Carlos E. R." <robin_listas@es.invalid> - 2026-02-11 23:24 +0100
          Re: For those arguing over languages... Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-11 22:48 +0000
          Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-11 22:49 +0000
          Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-12 09:55 +0000
            Re: For those arguing over languages... "Carlos E. R." <robin_listas@es.invalid> - 2026-02-12 11:49 +0100
            Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-12 20:54 -0500
              Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-13 03:20 +0000
                Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-12 23:44 -0500
          Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-12 12:38 +0000
            Re: For those arguing over languages... "Carlos E. R." <robin_listas@es.invalid> - 2026-02-12 15:14 +0100
              Re: For those arguing over languages... Rich <rich@example.invalid> - 2026-02-12 17:23 +0000
                Re: For those arguing over languages... "Carlos E. R." <robin_listas@es.invalid> - 2026-02-12 19:52 +0100
                  Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-13 10:11 +0000
                    Re: For those arguing over languages... Richard Kettlewell <invalid@invalid.invalid> - 2026-02-13 10:20 +0000
              Re: For those arguing over languages... The Natural Philosopher <tnp@invalid.invalid> - 2026-02-13 10:10 +0000
                Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-13 19:57 -0500
            Re: For those arguing over languages... c186282 <c186282@nnada.net> - 2026-02-12 20:56 -0500

Page 1 of 2  [1] 2  Next page →

#81897 — For those arguing over languages...

...more fuel on the fire...

https://www.theregister.com/2026/02/09/compilers_undermine_encryption/

GCC erases code whose delays obfuscates encryption delays because it 
doesn't do anything...

-- 
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

[toc] | [next] | [standalone]

#81901

The Natural Philosopher <tnp@invalid.invalid> writes:
> ...more fuel on the fire...
>
> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>
> GCC erases code whose delays obfuscates encryption delays because it
> doesn't do anything...

It’s a well-known issue, unique neither to C nor GCC. Some other recent
examples:

https://pqshield.com/pqshield-plugs-timing-leaks-in-kyber-ml-kem-to-improve-pqc-implementation-maturity/

https://github.com/RustCrypto/signatures/security/advisories/GHSA-hcp2-x6j4-29j7

Sometimes the compiler helps instead of hinders, for example in the
ML-DSA Decompose() case, GCC can eliminate the variable-latency division
and replace it with a multiplication and a couple of shifts (see
https://godbolt.org/z/zaY5WEEdx), but it does that because it’s faster,
not because it’s trying to generate constant-time code.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#81904

On Tue, 10 Feb 2026 09:09:00 +0000, The Natural Philosopher wrote:

> ...more fuel on the fire...
> 
> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
> 
> GCC erases code whose delays obfuscates encryption delays because it
> doesn't do anything...

A complete non issue.  Click bait.

Just shut off optimization, either en masse or selectively via the dozens
of switches.

Knowing how to compile is just as important as knowing how to program.


-- 
Gentoo/LFS: Is there any-fucking-thing else?

[toc] | [prev] | [next] | [standalone]

#81905

Farley Flud <ff@linux.rocks> wrote:
>On Tue, 10 Feb 2026 09:09:00 +0000, The Natural Philosopher wrote:
>> ...more fuel on the fire...
>> 
>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>> 
>> GCC erases code whose delays obfuscates encryption delays because it
>> doesn't do anything...
>
>A complete non issue.  Click bait.
>
>Just shut off optimization, either en masse or selectively via the dozens
>of switches.
>
>Knowing how to compile is just as important as knowing how to program.

Does GCC have pragmas so that the programmer can turn off optimization
for only those code parts? That would probably be the wise thing to do
(at least that's what occurs to me, who happens to have zero
experience with serious C programming of time- oder security-critical
code).

Turning off optimization completely doesn't sound like the right
thing. We learned in the 1990ies to code for readers, and rely on the
compiler to opimize away the inefficiencies of the readable code. I
guess that things are still taught this way. Are they?

Greetings
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#81909

Marc Haber <mh+usenetspam1118@zugschl.us> writes:
> Does GCC have pragmas so that the programmer can turn off optimization
> for only those code parts? That would probably be the wise thing to do
> (at least that's what occurs to me, who happens to have zero
> experience with serious C programming of time- oder security-critical
> code).

No.

https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html

> Turning off optimization completely doesn't sound like the right
> thing.

It’s not the right thing for the simple and obvious reason that it
doesn’t solve the problem.

https://godbolt.org/z/ePPbca91P is the example from Meusel’s slides,
translated to C[1] and compiled with -O2. The early exit can be seen at
L13 in the asm.

https://godbolt.org/z/YvYn34dn7 is the same source compiled at -O0.  It
no longer has an early exit, but instead, once match=false, every
iteration of the loop branches past the update to match (L17). The side
channel remains, just in a slightly different form. As a free gift to
the attacker the side channel is also amplified by the poor performance,
i.e. they don’t need such an accurate clock to extract any signal from
it.


[1] I translated to C because the unoptimized object code from the C++
    example in the slides has a huge amount of irrelevant noise in it
    due to the all the extra abstraction used in the C++ version.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#81913

Richard Kettlewell <invalid@invalid.invalid> writes:
> Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>> Does GCC have pragmas so that the programmer can turn off optimization
>> for only those code parts? That would probably be the wise thing to do
>> (at least that's what occurs to me, who happens to have zero
>> experience with serious C programming of time- oder security-critical
>> code).
>
> No.
>
> https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html

Looks like I was wrong about this detail - but the point that disabling
optimization has nothing to do with this problem remains.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#81910

Marc Haber wrote this post by blinking in Morse code:

> Farley Flud <ff@linux.rocks> wrote:
>>On Tue, 10 Feb 2026 09:09:00 +0000, The Natural Philosopher wrote:
>>> ...more fuel on the fire...
>>> 
>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>> 
>>> GCC erases code whose delays obfuscates encryption delays because it
>>> doesn't do anything...
>>
>>A complete non issue.  Click bait.
>>
>>Just shut off optimization, either en masse or selectively via the dozens
>>of switches.
>>
>>Knowing how to compile is just as important as knowing how to program.
>
> Does GCC have pragmas so that the programmer can turn off optimization
> for only those code parts? That would probably be the wise thing to do
> (at least that's what occurs to me, who happens to have zero
> experience with serious C programming of time- oder security-critical
> code).

    <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html>

It has an assload of __attribute__ (xxx, ....) specifiers for
functions. Maybe this one would do the trick:

    __attribute__((optimize(0))) void test(int n)

No promises.

Also there are CPU attributes:

    <https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>

But man!

> Turning off optimization completely doesn't sound like the right
> thing. We learned in the 1990ies to code for readers, and rely on the
> compiler to opimize away the inefficiencies of the readable code. I
> guess that things are still taught this way. Are they?


-- 
Boys are beyond the range of anybody's sure understanding, at least
when they are between the ages of 18 months and 90 years.
		-- James Thurber

[toc] | [prev] | [next] | [standalone]

#82072

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Farley Flud <ff@linux.rocks> wrote:
>> The Natural Philosopher wrote:
>>> ...more fuel on the fire...
>>> 
>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>> 
>>> GCC erases code whose delays obfuscates encryption delays because it
>>> doesn't do anything...
>>
>>A complete non issue.  Click bait.
>>
>>Just shut off optimization, either en masse or selectively via the dozens
>>of switches.
>>
>>Knowing how to compile is just as important as knowing how to program.
> 
> Does GCC have pragmas so that the programmer can turn off optimization
> for only those code parts? That would probably be the wise thing to do
> Turning off optimization completely doesn't sound like the right
> thing.

Don't know whether or not this was suggested downthread:
write your delay code as a callable function, compile it
separately without optimization, and then link that
delayfunc.o file with your other code, which has been
modified to call delayfunc() as needed. As already stated,
a complete non-issue.
-- 
John

[toc] | [prev] | [next] | [standalone]

#82117

John  <john@panix.com> wrote:
> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> Farley Flud <ff@linux.rocks> wrote:
>>> The Natural Philosopher wrote:
>>>> ...more fuel on the fire...
>>>> 
>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>> 
>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>> doesn't do anything...
>>>
>>>A complete non issue.  Click bait.
>>>
>>>Just shut off optimization, either en masse or selectively via the dozens
>>>of switches.
>>>
>>>Knowing how to compile is just as important as knowing how to program.
>> 
>> Does GCC have pragmas so that the programmer can turn off optimization
>> for only those code parts? That would probably be the wise thing to do
>> Turning off optimization completely doesn't sound like the right
>> thing.
> 
> Don't know whether or not this was suggested downthread:
> write your delay code as a callable function, compile it
> separately without optimization, and then link that
> delayfunc.o file with your other code, which has been
> modified to call delayfunc() as needed. As already stated,
> a complete non-issue.

Look at the examples posted by Richard Kettelwell in the message with
Message-ID: <wwvcy2cbmh6.fsf@LkoBDZeT.terraraq.uk>

Even with no optimizations, due to normal boolean logic 
short-circuiting defined by the C spec, the output assembly by the 
compiler still skips over much of the "constant time" activity that 
must be executed for the code to be "constant time".

The end result is: compilers do not guarantee "constant runtime" object 
code, regardless of optimization settings.

[toc] | [prev] | [next] | [standalone]

#82162

Rich <rich@example.invalid> writes:
> John  <john@panix.com> wrote:
>> Don't know whether or not this was suggested downthread: write your
>> delay code as a callable function, compile it separately without
>> optimization, and then link that delayfunc.o file with your other
>> code, which has been modified to call delayfunc() as needed. As
>> already stated, a complete non-issue.
>
> Look at the examples posted by Richard Kettelwell in the message with
> Message-ID: <wwvcy2cbmh6.fsf@LkoBDZeT.terraraq.uk>
>
> Even with no optimizations, due to normal boolean logic 
> short-circuiting defined by the C spec, the output assembly by the 
> compiler still skips over much of the "constant time" activity that 
> must be executed for the code to be "constant time".
>
> The end result is: compilers do not guarantee "constant runtime" object 
> code, regardless of optimization settings.

It’s possibly worth noting that the ‘random delay’ strategy does not
work in general.  In many real designs a given secret is used many times
(e.g. an https site will generate a new signature, using the same key,
for every new connection). Instead of a single timing, the attacker gets
a collection of timings and gets to draw inferences from their
distribution. The attacker’s cost goes up, for sure, but the attack
doesn’t go away.

If this was truly trivial to solve then nobody would be talking about
it. The people claiming it’s a non-issue have not engaged with the issue
at all.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#81911

On Tue, 10 Feb 2026 14:08:00 +0000
Farley Flud <ff@linux.rocks> wrote:

> > ...more fuel on the fire...
> > 
> > https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
> > 
> > GCC erases code whose delays obfuscates encryption delays because it
> > doesn't do anything...  
> 
> A complete non issue.  Click bait.
> 
> Just shut off optimization, either en masse or selectively via the
> dozens of switches.

Seriously. It's funny in an "oh *right,* hadn't thought of that" kinda
way, but it should *maybe* be common knowledge that if your techniques
require perfect literality from the compiler, you disable optimization?

[toc] | [prev] | [next] | [standalone]

#81912

John Ames <commodorejohn@gmail.com> writes:
> Farley Flud <ff@linux.rocks> wrote:
>> > ...more fuel on the fire...
>> > 
>> > https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>> > 
>> > GCC erases code whose delays obfuscates encryption delays because it
>> > doesn't do anything...  
>> 
>> A complete non issue.  Click bait.
>> 
>> Just shut off optimization, either en masse or selectively via the
>> dozens of switches.
>
> Seriously. It's funny in an "oh *right,* hadn't thought of that" kinda
> way, but it should *maybe* be common knowledge that if your techniques
> require perfect literality from the compiler, you disable optimization?

But the requirement isn’t “perfect literality”, whatever that means for
C.  The requirement is that the code be constant-time (or more
accurately, have running time independent of the value of any secret
parameters). Disabling optimization doens’t give you that (and you
shouldn’t expect it to). See my other post for a concrete example.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#81927

On 2/10/26 04:09, The Natural Philosopher wrote:
> ...more fuel on the fire...
> 
> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
> 
> GCC erases code whose delays obfuscates encryption delays because it 
> doesn't do anything...
> 

   Very interesting ! How 'optimization' sometimes ISN'T.

   And encryption IS hyper-important these days ...

   "The user types in a password, which gets checked against
   a database, character by character. Once the first character
   doesn't match, an error message is returned.

   For a close observer trying to break in, the time it takes
   the system to return that error indicates how many letters
   of the guessed password the user has already entered correctly.
   A longer response time indicates more of the password has
   been guessed.

   This side-channel leak has been used in the past to facilitate
   brute-force break-ins."

   Brute-force is STILL a thing ... although "insiders",
   stupid humans or spybots, seem to be very prevalent
   these days.

[toc] | [prev] | [next] | [standalone]

#81944

c186282 <c186282@nnada.net> wrote:
> On 2/10/26 04:09, The Natural Philosopher wrote:
>> ...more fuel on the fire...
>> 
>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>> 
>> GCC erases code whose delays obfuscates encryption delays because it 
>> doesn't do anything...
>> 
> 
>   Very interesting ! How 'optimization' sometimes ISN'T.

Nope.  As Richard Kettlewell has pointed out, what the encryption code 
writers want is "constant time execution, regardless of inputs" which 
is not a promised output from gcc, no matter the optimization level 
chosen.

The compiler is "properly optimizing" given the meaning of 
"optimization" it uses ("make code run as fast as possible" or "make 
code as small as possible" -- with -Os).  But the compiler was not 
designed to create "constant time execution" code.  The writers were 
expecting a promise the compiler never promised.

[toc] | [prev] | [next] | [standalone]

#81945

On 11/02/2026 18:50, Rich wrote:
> c186282 <c186282@nnada.net> wrote:
>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>> ...more fuel on the fire...
>>>
>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>
>>> GCC erases code whose delays obfuscates encryption delays because it
>>> doesn't do anything...
>>>
>>
>>    Very interesting ! How 'optimization' sometimes ISN'T.
> 
> Nope.  As Richard Kettlewell has pointed out, what the encryption code
> writers want is "constant time execution, regardless of inputs" which
> is not a promised output from gcc, no matter the optimization level
> chosen.
> 
+1.

> The compiler is "properly optimizing" given the meaning of
> "optimization" it uses ("make code run as fast as possible" or "make
> code as small as possible" -- with -Os).  But the compiler was not
> designed to create "constant time execution" code.  The writers were
> expecting a promise the compiler never promised.

Sounds deeply political :-)

Perhaps a C construct ...

void randMicrodelay()

could be constructed in Asssember for every platform...

-- 
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman

[toc] | [prev] | [next] | [standalone]

#81949

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 11/02/2026 18:50, Rich wrote:
>> c186282 <c186282@nnada.net> wrote:
>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>> ...more fuel on the fire...
>>>>
>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>
>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>> doesn't do anything...
>>>>
>>>
>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>> 
>> Nope.  As Richard Kettlewell has pointed out, what the encryption 
>> code writers want is "constant time execution, regardless of inputs" 
>> which is not a promised output from gcc, no matter the optimization 
>> level chosen.
>> 
> +1.
> 
>> The compiler is "properly optimizing" given the meaning of 
>> "optimization" it uses ("make code run as fast as possible" or "make 
>> code as small as possible" -- with -Os).  But the compiler was not 
>> designed to create "constant time execution" code.  The writers were 
>> expecting a promise the compiler never promised.
> 
> Sounds deeply political :-)
> 
> Perhaps a C construct ...
> 
> void randMicrodelay()
> 
> could be constructed in Asssember for every platform...

For crypto work that likely would not be considered sufficient.  Unless 
the randomness for the "delay" came from a true random source it would 
likely still leak side-channel data.  It would make the attackers job 
harder, but not fully close the leak.

[toc] | [prev] | [next] | [standalone]

#81973

Rich <rich@example.invalid> writes:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 11/02/2026 18:50, Rich wrote:
>>> c186282 <c186282@nnada.net> wrote:
>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>> ...more fuel on the fire...
>>>>>
>>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>>
>>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>>> doesn't do anything...
>>>>>
>>>>
>>>>    Very interesting ! How 'optimization' sometimes ISN'T.
>>> 
>>> Nope.  As Richard Kettlewell has pointed out, what the encryption 
>>> code writers want is "constant time execution, regardless of inputs" 
>>> which is not a promised output from gcc, no matter the optimization 
>>> level chosen.
>>> 
>> +1.
>> 
>>> The compiler is "properly optimizing" given the meaning of 
>>> "optimization" it uses ("make code run as fast as possible" or "make 
>>> code as small as possible" -- with -Os).  But the compiler was not 
>>> designed to create "constant time execution" code.  The writers were 
>>> expecting a promise the compiler never promised.
>> 
>> Sounds deeply political :-)
>> 
>> Perhaps a C construct ...
>> 
>> void randMicrodelay()
>> 
>> could be constructed in Asssember for every platform...
>
> For crypto work that likely would not be considered sufficient.  Unless 
> the randomness for the "delay" came from a true random source it would 
> likely still leak side-channel data.  It would make the attackers job 
> harder, but not fully close the leak.

Cryptographic code often needs a good random source anyway, so that’s
not necessarily an obstacle to TNP’s proposal of inserting random
delays. But there are exceptions, and in practice it’s not a common
strategy. More common is to avoid constructions that the compiler emits
branches for (which is a bit fragile) and more effectively,
constructions that the compiler contractually cannot optimize
through. This can be found in Meusel’s slides, but people might have to
actually read links rather than just comment on them to notice that.

Some cryptographic implementations do use pure assembler for this and
other reasons, but it’s not a very practical strategy. If you look at
OpenSSL you’ll find the most popular algorithms and the most popular CPU
architectures are well-covered by assembler implementations, but for
anything else it falls back to C.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#82005

On 2/12/26 04:48, Richard Kettlewell wrote:
> Rich <rich@example.invalid> writes:
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 11/02/2026 18:50, Rich wrote:
>>>> c186282 <c186282@nnada.net> wrote:
>>>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>>>> ...more fuel on the fire...
>>>>>>
>>>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>>>>
>>>>>> GCC erases code whose delays obfuscates encryption delays because it
>>>>>> doesn't do anything...
>>>>>>
>>>>>
>>>>>     Very interesting ! How 'optimization' sometimes ISN'T.
>>>>
>>>> Nope.  As Richard Kettlewell has pointed out, what the encryption
>>>> code writers want is "constant time execution, regardless of inputs"
>>>> which is not a promised output from gcc, no matter the optimization
>>>> level chosen.
>>>>
>>> +1.
>>>
>>>> The compiler is "properly optimizing" given the meaning of
>>>> "optimization" it uses ("make code run as fast as possible" or "make
>>>> code as small as possible" -- with -Os).  But the compiler was not
>>>> designed to create "constant time execution" code.  The writers were
>>>> expecting a promise the compiler never promised.
>>>
>>> Sounds deeply political :-)
>>>
>>> Perhaps a C construct ...
>>>
>>> void randMicrodelay()
>>>
>>> could be constructed in Asssember for every platform...
>>
>> For crypto work that likely would not be considered sufficient.  Unless
>> the randomness for the "delay" came from a true random source it would
>> likely still leak side-channel data.  It would make the attackers job
>> harder, but not fully close the leak.
> 
> Cryptographic code often needs a good random source anyway, so that’s
> not necessarily an obstacle to TNP’s proposal of inserting random
> delays. But there are exceptions, and in practice it’s not a common
> strategy. More common is to avoid constructions that the compiler emits
> branches for (which is a bit fragile) and more effectively,
> constructions that the compiler contractually cannot optimize
> through. This can be found in Meusel’s slides, but people might have to
> actually read links rather than just comment on them to notice that.
> 
> Some cryptographic implementations do use pure assembler for this and
> other reasons, but it’s not a very practical strategy. If you look at
> OpenSSL you’ll find the most popular algorithms and the most popular CPU
> architectures are well-covered by assembler implementations, but for
> anything else it falls back to C.

   Really damned good randomness can be had by mushing
   together things like CPU temperature, process numbers,
   they used to use video-refresh timing and mouse coords.
   Put together they'll yield a number pretty impossible
   to guess/duplicate. It's not "perfect" randomness, there
   may be no such thing, but it's close.

   ASM, obviously, can be used to write anything. The
   trade off is "how easily ?". Often not worth it in
   today's environment. I used to do a fair amount of
   ASM, for microcontrollers and even the early IBM-PCs
   when they didn't have much clever software. I don't
   use ASM any more though - 'C' is more than good
   enough for almost anything (REALLY tiny uC's
   may still warrant ASM work - still think the PIC
   12xxx 8-pin jobbies are cool).

[toc] | [prev] | [next] | [standalone]

#81948

Rich wrote this post by blinking in Morse code:

> c186282 <c186282@nnada.net> wrote:
>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>> ...more fuel on the fire...
>>> 
>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>> 
>>> GCC erases code whose delays obfuscates encryption delays because it 
>>> doesn't do anything...
>>> 
>> 
>>   Very interesting ! How 'optimization' sometimes ISN'T.
>
> Nope.  As Richard Kettlewell has pointed out, what the encryption code 
> writers want is "constant time execution, regardless of inputs" which 
> is not a promised output from gcc, no matter the optimization level 
> chosen.

Isn't that something programmer needs to code?

    <https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html>

... in asssembler.

> The compiler is "properly optimizing" given the meaning of 
> "optimization" it uses ("make code run as fast as possible" or "make 
> code as small as possible" -- with -Os).  But the compiler was not 
> designed to create "constant time execution" code.  The writers were 
> expecting a promise the compiler never promised.

I'm happy I don't need to worry about this... I think.

-- 
  May I ask a question?

[toc] | [prev] | [next] | [standalone]

#81953

Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
> Rich wrote this post by blinking in Morse code:
> 
>> c186282 <c186282@nnada.net> wrote:
>>> On 2/10/26 04:09, The Natural Philosopher wrote:
>>>> ...more fuel on the fire...
>>>> 
>>>> https://www.theregister.com/2026/02/09/compilers_undermine_encryption/
>>>> 
>>>> GCC erases code whose delays obfuscates encryption delays because it 
>>>> doesn't do anything...
>>>> 
>>> 
>>>   Very interesting ! How 'optimization' sometimes ISN'T.
>>
>> Nope.  As Richard Kettlewell has pointed out, what the encryption code 
>> writers want is "constant time execution, regardless of inputs" which 
>> is not a promised output from gcc, no matter the optimization level 
>> chosen.
> 
> Isn't that something programmer needs to code?
> 
>     <https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html>
> 
> ... in asssembler.

If they wanted to be assured the compiler did not change the intent for 
them, yes.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web