...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...
...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...
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.
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?
...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.
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
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?
...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...
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.
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.
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.
On 11/02/2026 18:50, Rich wrote:
c186282 <c186282@nnada.net> wrote:+1.
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.
Sounds deeply political :-)
Perhaps a C construct ...
void randMicrodelay()
could be constructed in Asssember for every platform...
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.
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.
In the example posted:
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.
...the fault is not of the compiler, but of the programmer. He has
to examine all characters even if he knows there is no point.
On 2026-02-11 19: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.
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.
In the example posted:
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.
...the fault is not of the compiler, but of the programmer. He has to examine all characters even if he knows there is no point.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 11/02/2026 18:50, Rich wrote:
c186282 <c186282@nnada.net> wrote:+1.
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.
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.
In the example posted:
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.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
"Carlos E. R." <robin_listas@es.invalid> writes:
In the example posted:
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.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
Obviously you didnrCOt read the whole article...
On 2026-02-11 19: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...
-a-a Very interesting ! How 'optimization' sometimes ISN'T.
Nope.-a 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).-a But the compiler was not
designed to create "constant time execution" code.-a The writers were
expecting a promise the compiler never promised.
In the example posted:
-a The user types in a password, which gets checked against
-a a database, character by character. Once the first character
-a doesn't match, an error message is returned.
...the fault is not of the compiler, but of the programmer. He has to examine all characters even if he knows there is no point.
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.
On 11/02/2026 22:24, Carlos E. R. wrote:
On 2026-02-11 19:50, Rich wrote:I think the point is that the compiler knows that isn't necessary, and doesnt bother.
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...
-a-a Very interesting ! How 'optimization' sometimes ISN'T.
Nope.-a 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).-a But the compiler was not
designed to create "constant time execution" code.-a The writers were
expecting a promise the compiler never promised.
In the example posted:
-a-a The user types in a password, which gets checked against
-a-a a database, character by character. Once the first character
-a-a doesn't match, an error message is returned.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
On 2026-02-12 13:38, The Natural Philosopher wrote:
On 11/02/2026 22:24, Carlos E. R. wrote:
On 2026-02-11 19:50, Rich wrote:I think the point is that the compiler knows that isn't necessary, and
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...
-a-a Very interesting ! How 'optimization' sometimes ISN'T.
Nope.-a 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).-a But the compiler was not
designed to create "constant time execution" code.-a The writers were
expecting a promise the compiler never promised.
In the example posted:
-a-a The user types in a password, which gets checked against
-a-a a database, character by character. Once the first character
-a-a doesn't match, an error message is returned.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
doesnt bother.
Then don't optimize. Optimization has always been somewhat problematic. Sometimes it introduced bugs that could not be debugged, because
debugging altered the code, possibly removing the optimizations.
Carlos E. R. <robin_listas@es.invalid> wrote:
On 2026-02-12 13:38, The Natural Philosopher wrote:
On 11/02/2026 22:24, Carlos E. R. wrote:
On 2026-02-11 19:50, Rich wrote:
c186282 <c186282@nnada.net> wrote:
On 2/10/26 04:09, The Natural Philosopher wrote:
...more fuel on the fire...
I think the point is that the compiler knows that isn't necessary, and
doesnt bother.
Then don't optimize. Optimization has always been somewhat problematic.
Sometimes it introduced bugs that could not be debugged, because
debugging altered the code, possibly removing the optimizations.
It wasn't the optimizer causing the "skipping" of the rest of the
checks. It was a byproduct of boolean short-circuiting of boolean expressions. Most languages only evaluate just enough of a complex
boolean expression to reach a true or false indication, then skip the
rest of the expression (yes, this is an 'optimization', but not by the
code optimizer but the language specification itself).
The skipping of the remaining character checks in the example posted
here was due to this boolean short-circuit behavior. Once the first
'false' arrived for the first incorrect character, the compiled code
skipped over evaluating the boolean expression for subsequent
characters. So -O0 (no optimizations) or -O3 (full optimizations) made
no difference, portions of the 'constant time execution' were skipped, opening a timing side channel attack.
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:+1.
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.
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 thatrCOs
not necessarily an obstacle to TNPrCOs proposal of inserting random
delays. But there are exceptions, and in practice itrCOs 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 MeuselrCOs 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 itrCOs not a very practical strategy. If you look at OpenSSL yourCOll 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.
"Carlos E. R." <robin_listas@es.invalid> writes:
In the example posted:
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.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
Obviously you didnrCOt read the whole article...
On 11/02/2026 22:24, Carlos E. R. wrote:
On 2026-02-11 19:50, Rich wrote:I think the point is that the compiler knows that isn't necessary, and doesnt bother.
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...
-a-a Very interesting ! How 'optimization' sometimes ISN'T.
Nope.-a 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).-a But the compiler was not
designed to create "constant time execution" code.-a The writers were
expecting a promise the compiler never promised.
In the example posted:
-a-a The user types in a password, which gets checked against
-a-a a database, character by character. Once the first character
-a-a doesn't match, an error message is returned.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
On 2/12/26 04:55, Richard Kettlewell wrote:
"Carlos E. R." <robin_listas@es.invalid> writes:
In the example posted:
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.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
Obviously you didnrCOt read the whole article...
It's "examining" behavior that's the fault :-)
If you ALWAYS process ALL the characters, and/or try
to make fake timing so success/fail will use up the
same amount of CPU time, THEN you're ahead of the game.
c186282 <c186282@nnada.net> wrote:
On 2/12/26 04:55, Richard Kettlewell wrote:
"Carlos E. R." <robin_listas@es.invalid> writes:
In the example posted:
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.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
Obviously you didnrCOt read the whole article...
It's "examining" behavior that's the fault :-)
If you ALWAYS process ALL the characters, and/or try
to make fake timing so success/fail will use up the
same amount of CPU time, THEN you're ahead of the game.
Obviously you didnrCOt read [Richard Kettlewell's posts]
The C code was, if executed literally as written, processing ALL the characters.
But in both the optimized state (-O3) and the "do not optimize" state
(-O0) the GCC output object code was skipping execution of much of the
object code that needed to be executed for a "constant time"
comparison.
On 2026-02-12 13:38, The Natural Philosopher wrote:
On 11/02/2026 22:24, Carlos E. R. wrote:
On 2026-02-11 19:50, Rich wrote:I think the point is that the compiler knows that isn't necessary, and
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...
-a-a Very interesting ! How 'optimization' sometimes ISN'T.
Nope.-a 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).-a But the compiler was not
designed to create "constant time execution" code.-a The writers were
expecting a promise the compiler never promised.
In the example posted:
-a-a The user types in a password, which gets checked against
-a-a a database, character by character. Once the first character
-a-a doesn't match, an error message is returned.
...the fault is not of the compiler, but of the programmer. He has to
examine all characters even if he knows there is no point.
doesnt bother.
Then don't optimize. Optimization has always been somewhat problematic. Sometimes it introduced bugs that could not be debugged, because
debugging altered the code, possibly removing the optimizations.
On 2026-02-12 18:23, Rich wrote:
Carlos E. R. <robin_listas@es.invalid> wrote:
On 2026-02-12 13:38, The Natural Philosopher wrote:
On 11/02/2026 22:24, Carlos E. R. wrote:
On 2026-02-11 19:50, Rich wrote:
c186282 <c186282@nnada.net> wrote:
On 2/10/26 04:09, The Natural Philosopher wrote:
...more fuel on the fire...
I think the point is that the compiler knows that isn't necessary, and >>>> doesnt bother.
Then don't optimize. Optimization has always been somewhat problematic.
Sometimes it introduced bugs that could not be debugged, because
debugging altered the code, possibly removing the optimizations.
It wasn't the optimizer causing the "skipping" of the rest of the
checks.-a It was a byproduct of boolean short-circuiting of boolean
expressions.-a Most languages only evaluate just enough of a complex
boolean expression to reach a true or false indication, then skip the
rest of the expression (yes, this is an 'optimization', but not by the
code optimizer but the language specification itself).
The skipping of the remaining character checks in the example posted
here was due to this boolean short-circuit behavior.-a Once the first
'false' arrived for the first incorrect character, the compiled code
skipped over evaluating the boolean expression for subsequent
characters.-a So -O0 (no optimizations) or -O3 (full optimizations) made
no difference, portions of the 'constant time execution' were skipped,
opening a timing side channel attack.
Ah, yes, I remember that now. Can play havoc when one of the expression
is actually a function and the later code relies on the prior execution
of that code.
On 12/02/2026 18:52, Carlos E. R. wrote:
On 2026-02-12 18:23, Rich wrote:
Carlos E. R. <robin_listas@es.invalid> wrote:
On 2026-02-12 13:38, The Natural Philosopher wrote:
On 11/02/2026 22:24, Carlos E. R. wrote:
On 2026-02-11 19:50, Rich wrote:
c186282 <c186282@nnada.net> wrote:
On 2/10/26 04:09, The Natural Philosopher wrote:
...more fuel on the fire...
I think the point is that the compiler knows that isn't necessary, and >>>>> doesnt bother.
Then don't optimize. Optimization has always been somewhat problematic. >>>> Sometimes it introduced bugs that could not be debugged, because
debugging altered the code, possibly removing the optimizations.
It wasn't the optimizer causing the "skipping" of the rest of the
checks.-a It was a byproduct of boolean short-circuiting of boolean
expressions.-a Most languages only evaluate just enough of a complex
boolean expression to reach a true or false indication, then skip the
rest of the expression (yes, this is an 'optimization', but not by the
code optimizer but the language specification itself).
The skipping of the remaining character checks in the example posted
here was due to this boolean short-circuit behavior.-a Once the first
'false' arrived for the first incorrect character, the compiled code
skipped over evaluating the boolean expression for subsequent
characters.-a So -O0 (no optimizations) or -O3 (full optimizations) made >>> no difference, portions of the 'constant time execution' were skipped,
opening a timing side channel attack.
Ah, yes, I remember that now. Can play havoc when one of the
expression is actually a function and the later code relies on the
prior execution of that code.
the keyword 'volatile' helps in this case
On 12/02/2026 14:14, Carlos E. R. wrote:
On 2026-02-12 13:38, The Natural Philosopher wrote:
On 11/02/2026 22:24, Carlos E. R. wrote:
On 2026-02-11 19:50, Rich wrote:I think the point is that the compiler knows that isn't necessary,
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...
-a-a Very interesting ! How 'optimization' sometimes ISN'T.
Nope.-a 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).-a But the compiler was not
designed to create "constant time execution" code.-a The writers were >>>>> expecting a promise the compiler never promised.
In the example posted:
-a-a The user types in a password, which gets checked against
-a-a a database, character by character. Once the first character
-a-a doesn't match, an error message is returned.
...the fault is not of the compiler, but of the programmer. He has
to examine all characters even if he knows there is no point.
and doesnt bother.
Then don't optimize. Optimization has always been somewhat
problematic. Sometimes it introduced bugs that could not be debugged,
because debugging altered the code, possibly removing the optimizations.
I think you are on a hiding to nothing here.-a No high level language guarantees any particular load of assembler, and no particular load of assembler guarantees an exact timing these days.
-aWe have moved on from the Z80....
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.
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 <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.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 19:24:08 |
| Calls: | 810 |
| Calls today: | 1 |
| Files: | 1,287 |
| D/L today: |
10 files (21,017K bytes) |
| Messages: | 193,978 |