Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #82005
| Date | 2026-02-12 20:48 -0500 |
|---|---|
| Subject | Re: For those arguing over languages... |
| Newsgroups | comp.os.linux.misc |
| References | (1 earlier) <azKdnRQU0p54ZRb0nZ2dnZfqnPWdnZ2d@giganews.com> <10mij0u$rimo$1@dont-email.me> <10mil9m$sd7n$5@dont-email.me> <10mis8n$v5p4$1@dont-email.me> <wwv8qcy8f7r.fsf@LkoBDZeT.terraraq.uk> |
| From | c186282 <c186282@nnada.net> |
| Organization | wokiesux |
| Message-ID | <21CdnSc99bpHHxP0nZ2dnZfqn_GdnZ2d@giganews.com> (permalink) |
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).
Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web