Ancestors

Written by comex on 2025-01-22 at 02:06

“Clang will now more aggressively use undefined behavior on pointer addition overflow for optimization purposes.” https://github.com/llvm/llvm-project/commit/c2979c58d49b

A whole lot of non-exploitable bugs may become exploitable pretty soon.

=> More informations about this toot | More toots from comex@mas.to

Written by gudenau on 2025-01-22 at 02:45

@comex This needs to be a warning at least. Also shout-out to clang optimizing crypto libraries to no longer be fixed time.

=> More informations about this toot | More toots from gudenau@fosstodon.org

Written by Marcus Müller on 2025-01-22 at 02:47

@gudenau @comex it has been a warning forever.

=> More informations about this toot | More toots from funkylab@mastodon.social

Written by Marcus Müller on 2025-01-22 at 02:49

@gudenau @comex and I'm not sure, but "I use a high level language whose model of the world explicitly says that execution duration is not an observable. My constant-time implementation isn't constant time" is the most "I'm infosec, I don't need to understand how things actually work" thing I keep on reading when it comes to complaining about compiler.

=> More informations about this toot | More toots from funkylab@mastodon.social

Written by void friend on 2025-01-22 at 15:32

@funkylab it is funny you use the sentence about not needing to understand how things actually work because in how things actually work, the high-level language that preserves “constant-time”, as the property is called, doesn't exist, and while OpenSSL developers appear to have the energy to produce assembly versions for all the targets on which one wants to execute cryptographic primitives, many other developers do not. If you factor in the fact that the protocol that uses the crypto primitives must be implemented in “constant time” too, the whole is always at least partly written in a high-level language, and the language in question never understands constant time or secrets that mustn't be copied willy-nilly. This is how things actually work.

=> More informations about this toot | More toots from void_friend@tech.lgbt

Written by Marcus Müller on 2025-01-23 at 03:03

@void_friend I appreciate you pointing that out! Yes, you're right. Any cryptographical protocol that's only secure if you can make a machine that makes no guarantees on timing behave in a specific temporal behavior is of course fundamentally broken for real world application.

Luckily, you can often bound the amount of information leaked on real world machines. I already mentioned hardware timers to delay to remove any mutual information between runtime and data. That doesn't make the...

=> More informations about this toot | More toots from funkylab@mastodon.social

Toot

Written by Marcus Müller on 2025-01-23 at 03:08

@void_friend system safe against e.g. power usage side channels. But in practice, against attackers without physical access, doing cryptography and then waiting until a defined time is over is better than trying to shoehorn C on an superscalar, speculative execution, conditional moves CPU into constant time computation.

These kinds of computers are not built for constant time computation, but the opposite. They are, however, built with reliable timers to allow constant latency.

I'm hence

=> More informations about this toot | More toots from funkylab@mastodon.social

Descendants

Written by Marcus Müller on 2025-01-23 at 03:14

@void_friend … often confused why people mention constant time computation on such machines, where it might be both hard to reliably achieve, and not better than using a timer to erase externally observable computation time altogether.

That being said, same-machine users do have cache usage, frequency scaling, scheduling freedom (and of course spectre-style) side channels. But in these cases: C code won't save you. Use the secure platform elements, as mentioned. They can make guarantees!

=> More informations about this toot | More toots from funkylab@mastodon.social