Logs: liberachat/#haskell
| 2025-10-13 08:08:34 | <tomsmeding> | dminuoso: to be fair, while that holds for Haskell, that holds for C too |
| 2025-10-13 08:09:11 | <dminuoso> | tomsmeding: Yes, and openssl has loads of code paths with these attacks in mind and defenses. |
| 2025-10-13 08:10:11 | <tomsmeding> | I was thinking of the timing attacks in your list -- compilers normalloy do stuff with branches that may compromise attempts to write e.g. branchless code |
| 2025-10-13 08:10:17 | <tomsmeding> | and even C compilers can do that |
| 2025-10-13 08:10:35 | <dminuoso> | tomsmeding: Much of the timing attacks require very explicit consideration and approaches. |
| 2025-10-13 08:10:42 | <tomsmeding> | I'm not saying that openssl has not accounted for this somehow |
| 2025-10-13 08:11:47 | × | Enrico63 quits (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
| 2025-10-13 08:14:49 | → | __monty__ joins (~toonn@user/toonn) |
| 2025-10-13 08:15:52 | <dminuoso> | tomsmeding: For starters openssl handwires various primitives in assembly not just for performance but also to thwart compiler optimizations. https://github.com/openssl/openssl/tree/master/crypto/bn/asm |
| 2025-10-13 08:16:55 | <tomsmeding> | right -- I was thinking you need something like that |
| 2025-10-13 08:17:04 | × | Adeon quits (sid418992@id-418992.lymington.irccloud.com) (Server closed connection) |
| 2025-10-13 08:17:16 | → | Adeon joins (sid418992@id-418992.lymington.irccloud.com) |
| 2025-10-13 08:17:33 | → | gustrb joins (~gustrb@191.243.134.87) |
| 2025-10-13 08:18:15 | <tomsmeding> | interesting that these are perl scripts |
| 2025-10-13 08:19:43 | <tomsmeding> | it seems everyone invents their own assembly macro language; with gmp using m4 if I remember correctly |
| 2025-10-13 08:20:03 | <fgidim> | woah, using assembly to get around compiling wrong code is hardcore. |
| 2025-10-13 08:20:04 | → | Zemy_ joins (~Zemy@syn-076-184-041-021.res.spectrum.com) |
| 2025-10-13 08:20:26 | <tomsmeding> | it _is_ reliable -- the assembler is not really going to introduce branches when you aren't looking |
| 2025-10-13 08:20:47 | × | merijn quits (~merijn@77.242.116.146) (Quit: Reconnecting) |
| 2025-10-13 08:21:02 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-10-13 08:21:05 | <tomsmeding> | also, it's not just for safety, it's also for performance -- see the comment at the top of e.g. https://github.com/openssl/openssl/blob/master/crypto/bn/asm/x86-mont.pl#L27-L28 |
| 2025-10-13 08:21:52 | <tomsmeding> | oh and there's even also a bunch of C inline assembly! https://github.com/openssl/openssl/blob/master/crypto/bn/asm/x86_64-gcc.c |
| 2025-10-13 08:24:10 | × | Zemy quits (~Zemy@2600:100c:b0a0:ef26:645d:40ff:fe60:28b8) (Ping timeout: 256 seconds) |
| 2025-10-13 08:26:18 | <fgidim> | dang, twice as fast? that is something |
| 2025-10-13 08:26:30 | <__monty__> | Is it also in part to avoid timing side channels? |
| 2025-10-13 08:26:57 | → | fp joins (~Thunderbi@2001:708:20:1406::10c5) |
| 2025-10-13 08:27:49 | <tomsmeding> | yes -- the "compiler optimisations" that dminuoso mentioned are mostly ones that inadvertently introduce timing side channels, I think |
| 2025-10-13 08:29:07 | <mauke> | https://cr.yp.to/talks/2025.10.07/slides-djb-20251007-pickthree-4x3.pdf |
| 2025-10-13 08:29:28 | <dminuoso> | fgidim: well "wrong code" depends on how you look at it. Generally the semantics of programming languages have nothing to say about performance, and often they do the opposite: they leave holes for compilers to exploit. |
| 2025-10-13 08:29:40 | <dminuoso> | For most programs you them to execute as fast as possible. |
| 2025-10-13 08:29:51 | <dminuoso> | But this goes very much against what you'd want in cryptography. |
| 2025-10-13 08:29:57 | → | bitterx joins (~marko@user/bitterx) |
| 2025-10-13 08:30:04 | <dminuoso> | You want cryptographic primitives to go as fast as you *require*. |
| 2025-10-13 08:30:21 | <dminuoso> | Consider the most naive of cases: comparing two strings for equality. |
| 2025-10-13 08:30:48 | <dminuoso> | A naive "character by character with shortcircuit" is very easily exploitable for timing analysis. |
| 2025-10-13 08:32:18 | <dminuoso> | mauke's slike are really good :) |
| 2025-10-13 08:32:27 | <dminuoso> | Or well, Bernstein's. |
| 2025-10-13 08:34:38 | <tomsmeding> | that list on slide 6 is funny |
| 2025-10-13 08:34:38 | × | synchromesh quits (~john@2406:5a00:2412:2c00:3507:235a:4a6c:ccc6) (Read error: Connection reset by peer) |
| 2025-10-13 08:35:53 | → | synchromesh joins (~john@2406:5a00:2412:2c00:3507:235a:4a6c:ccc6) |
| 2025-10-13 08:36:23 | × | tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-10-13 08:38:19 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Ping timeout: 256 seconds) |
| 2025-10-13 08:39:18 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2025-10-13 08:41:24 | <tomsmeding> | okay yeah it's a good slide deck |
| 2025-10-13 08:41:41 | <tomsmeding> | a lot of text for a talk, but that only makes it more readable after-the-fact :) |
| 2025-10-13 08:42:48 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2025-10-13 08:43:13 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2025-10-13 08:44:48 | × | xstill_ quits (xstill@fimu/xstill) (Quit: Ping timeout (120 seconds)) |
| 2025-10-13 08:46:09 | → | xstill_ joins (xstill@fimu/xstill) |
| 2025-10-13 08:47:00 | × | xstill_ quits (xstill@fimu/xstill) (Client Quit) |
| 2025-10-13 08:47:29 | → | xstill_ joins (xstill@fimu/xstill) |
| 2025-10-13 08:51:57 | × | xstill_ quits (xstill@fimu/xstill) (Client Quit) |
| 2025-10-13 08:52:30 | × | trickard quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-13 08:52:44 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 2025-10-13 08:53:11 | → | xstill_ joins (xstill@fimu/xstill) |
| 2025-10-13 08:57:04 | × | xstill_ quits (xstill@fimu/xstill) (Client Quit) |
| 2025-10-13 08:57:28 | → | xstill_ joins (xstill@fimu/xstill) |
| 2025-10-13 09:00:07 | <endokqr> | This may be the wrong place to ask but I'll try anyway. I have a Haskell development shell set up with Nix, where I have managed to install the profiling-enabled versions of the libraries I depend on. However, when I try to cabal build an executable with profiling enabled, I still get errors relating to missing .p_dyn_hi files for a few libraries. Some Google searches indicate that GHC shouldn't |
| 2025-10-13 09:00:10 | <endokqr> | be dynamically linking when running with profiling and that the error is a red herring. However, even if I add -static to ghc-flags in the Cabal file, I still get the same error. Am I misunderstanding something? |
| 2025-10-13 09:01:46 | × | trickard_ quits (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-13 09:02:49 | <dminuoso> | Besides, much of crypton(ites) is based on a single person who has abandoned the project. |
| 2025-10-13 09:03:29 | → | trickard_ joins (~trickard@cpe-54-98-47-163.wireline.com.au) |
| 2025-10-13 09:03:50 | <dminuoso> | While Kazu Yamamoto has picked up the maintainer flag, there arent really any crypto folks around to actively work on this project |
| 2025-10-13 09:04:19 | × | xstill_ quits (xstill@fimu/xstill) (Quit: Ping timeout (120 seconds)) |
| 2025-10-13 09:05:30 | <dminuoso> | The state of crypton right now is, if you supplied a PR that satisfied the tests it would likely get accepted. |
| 2025-10-13 09:06:00 | <dminuoso> | It's dead trivial to inject malicious backdoors of any kind right now. |
| 2025-10-13 09:06:43 | <dminuoso> | This isn't critique on behalf of Kazu Yamamoto, mind you. He's just trying to keep it alive because a fair chunk of hackage depends on crypto(nite) |
| 2025-10-13 09:07:31 | × | img quits (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-10-13 09:07:48 | → | xstill_ joins (xstill@fimu/xstill) |
| 2025-10-13 09:08:48 | → | img joins (~img@user/img) |
| 2025-10-13 09:13:36 | × | xstill_ quits (xstill@fimu/xstill) (Quit: Ping timeout (120 seconds)) |
| 2025-10-13 09:16:22 | → | AlexNoo__ joins (~AlexNoo@178.34.151.169) |
| 2025-10-13 09:17:28 | × | xff0x quits (~xff0x@2405:6580:b080:900:842d:f141:edde:28dd) (Quit: xff0x) |
| 2025-10-13 09:18:00 | × | AlexZenon quits (~alzenon@178.34.151.169) (Ping timeout: 256 seconds) |
| 2025-10-13 09:19:42 | × | AlexNoo_ quits (~AlexNoo@178.34.151.169) (Ping timeout: 256 seconds) |
| 2025-10-13 09:21:39 | → | xff0x joins (~xff0x@2405:6580:b080:900:f3f6:c4a2:4d90:7f3d) |
| 2025-10-13 09:22:11 | → | AlexZenon joins (~alzenon@178.34.151.169) |
| 2025-10-13 09:25:16 | → | chele joins (~chele@user/chele) |
| 2025-10-13 09:29:38 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 2025-10-13 09:34:49 | trickard_ | is now known as trickard |
| 2025-10-13 09:59:36 | × | gustrb quits (~gustrb@191.243.134.87) (Ping timeout: 244 seconds) |
| 2025-10-13 10:03:56 | → | gustrb joins (~gustrb@191.243.134.87) |
| 2025-10-13 10:05:43 | → | dhil joins (~dhil@5.151.29.137) |
| 2025-10-13 10:06:42 | <jackdk> | The main guy who was working on the botan bindings has come back from hiatus, we should fund him to do another round of work |
| 2025-10-13 10:09:05 | → | xstill_ joins (xstill@fimu/xstill) |
| 2025-10-13 10:09:52 | <Hecate> | jackdk: I just read your blog post on Handles and free applicatives, well-written and well-done, thank you. |
| 2025-10-13 10:10:42 | <Hecate> | jackdk: btw, don't hesitate to open discussion threads on the Effectful repo if you ever have some "exotic" use-cases / needs at Bellroy, we'd be happy to help you figure things out (and add stuff to make things easier) |
| 2025-10-13 10:12:25 | × | xstill_ quits (xstill@fimu/xstill) (Client Quit) |
| 2025-10-13 10:12:31 | → | divlamir_ joins (~divlamir@user/divlamir) |
| 2025-10-13 10:12:46 | × | divlamir quits (~divlamir@user/divlamir) (Ping timeout: 246 seconds) |
| 2025-10-13 10:13:21 | <jackdk> | Hecate: I'm glad you liked it. I personally really like effectful as I think it's closest to the sweet spot of type safety, performance, support for higher-order stuff, and zany type system features, but we'll see whether it's something we end up adopting at work. We try to keep an upper bound on the sort of Haskell that we write, and manual handles are an easier sell at this stage. |
| 2025-10-13 10:13:22 | divlamir_ | is now known as divlamir |
| 2025-10-13 10:14:09 | <jackdk> | (Hecate is referring to https://discourse.haskell.org/t/free-applicatives-the-handle-pattern-and-remote-systems/13110 . I'll probably send it to the other aggregators in the morning because I like to give d.h.o a head start) |
| 2025-10-13 10:15:40 | <Franciman> | jackdk: do you use GADTs in your lib? |
| 2025-10-13 10:16:26 | <jackdk> | Franciman: yeah OneQuery is a GADT, is that what you meant? |
| 2025-10-13 10:16:42 | <Franciman> | can you do without GADTs? |
| 2025-10-13 10:16:56 | <Hecate> | jackdk: my own question would be: Do you use GADTSyntax or do you need the local existential proofs? |
| 2025-10-13 10:18:49 | <jackdk> | Franciman, Hecate: for internal reasons which might have been shaved off too much when writing that post, we do need to carry around the internal `FromJSON x` dictionary. |
| 2025-10-13 10:19:50 | <Hecate> | jackdk: got it ;) |
| 2025-10-13 10:20:10 | × | koz quits (~koz@121.99.240.58) (Ping timeout: 248 seconds) |
All times are in UTC.