Isaac Van Doren (May 20 2024 at 14:15): Isaac Van Doren (May 20 2024 at 14:15):@Kiryl Dziamura Can you say more about why Roc is more vulnerable to timing attacks than other languages?
Also, I started working on implementing bcrypt in Roc for hashing passwords because it seems like a nice thing to have as a package, rather than requiring each platform to expose a function. As far as I can tell, timing attacks are not a concern for bcrypt because it does not use any secrets, but I’m curious to hear if there are other reasons I’m overlooking that suggest it should not be implemented in Roc.
Agus Zubiaga (May 20 2024 at 14:30):What I understood when that discussion happened was that you’d basically need inline assembly to make sure that timing is constant regardless of what branches are taken.
You could attempt to get the Roc code just right by looking at the produced assembly, but that would be extremely brittle as it would depend on the optimizations that LLVM makes.
Agus Zubiaga (May 20 2024 at 14:33):It could produce different operations based on heuristics and the result of those could change depending on context or in future versions.
Richard Feldman (May 20 2024 at 14:35):yeah that's exactly right
Richard Feldman (May 20 2024 at 14:36):it's not that Roc is uniquely vulnerable, but rather that every language which doesn't compile to 100% predictable machine instructions (e.g. any language with an optimizer) is vulnerable
Richard Feldman (May 20 2024 at 14:37):if we had inline assembly, or maybe a way to selectively turn off optimizations and get completely predictable machine instruction output, it could be possible
Richard Feldman (May 20 2024 at 14:37):(in theory, I'm not sure about in practice)
Richard Feldman (May 20 2024 at 14:38):here's an article written by the author of one of the most widely used Rust cryptography packages calling for Rust to introduce primitives like that; currently Rust is in the same category of languages that Roc is (that is, you can't implement cryptography routines that are safe from timing attacks in pure Rust either)
https://briansmith.org/rust-cryptography-should-be-written-in-rust-01
Richard Feldman (May 20 2024 at 14:39):from that article:
Rust should provide safe, direct access to architecture-specific instructions that are required to implement cryptography with optimal performance.
I don't think architecture-specific instructions are necessarily a good idea for Roc, but since we're in #ideas, a potentially interesting idea to explore might be the idea of a package being able to opt out of optimizations
Richard Feldman (May 20 2024 at 14:40):e.g. even if you used it as a dependency and were compiling with --optimize, maybe it wouldn't get optimized anyway
Richard Feldman (May 20 2024 at 14:40):by default that would be worse for performance, of course, but maybe if you're writing cryptographic code extremely carefully and verifying the output machine instructions by hand, maybe it's worth it
Richard Feldman (May 20 2024 at 14:41):on the other hand, maybe you still need lower-level primitives than what we have to completely rule out timing attacks (I don't personally have any hands-on experience trying to do that, so I don't know what exactly is necessary there) and also maybe the resulting code ends up being unacceptably slow in practice
Oskar Hahn (May 20 2024 at 15:07):Would it be possible to add a crypto module to the builtins? That could be implemented in zig or something, zig can import.
Isaac Van Doren (May 20 2024 at 17:01):Interesting!
Isaac Van Doren (May 20 2024 at 17:02):Having crypto in the builtins does sound nice
Richard Feldman (May 20 2024 at 18:29):that's interesting, definitely a possibility...tricky to figure out which algorithms to support though :sweat_smile:
Richard Feldman (May 20 2024 at 18:30):could be a long list!
Richard Feldman (May 20 2024 at 18:30):I guess Go's stdlib crypto list is not that long https://pkg.go.dev/golang.org/x/crypto
Richard Feldman (May 20 2024 at 18:31):an annoying thing about cryptography compared to other types of builtins is that the list of entries in the module will grow forever and never shrink
Richard Feldman (May 20 2024 at 18:31):so eventually it's basically guaranteed to be the biggest module
Hristo (May 20 2024 at 18:32):Seems like a good candidate for an officially maintained library living outside the standard library?
Hristo (May 20 2024 at 18:33):Conversely, would crypto be considered as a pro, when thinking in terms of "batteries included"?
Richard Feldman (May 20 2024 at 18:34):Hristo said:
Seems like a good candidate for an officially maintained library living outside the standard library?
if it's outside builtins it wouldn't be able to use Zig, unless it was implemented in platforms, in which case it would have to use Task
Richard Feldman (May 20 2024 at 18:34):which wouldn't be desirable for cryptography :sweat_smile:
Hristo (May 20 2024 at 18:38):Right, I see - thanks!
Hristo (May 20 2024 at 18:38):Richard Feldman said:
so eventually it's basically guaranteed to be the biggest module
Is this a big enough concern, then?
Or is it more of an acknowledgement regarding something that Roc would have to live with?
Richard Feldman (May 20 2024 at 18:39):yeah I think we'd have to live with it
Richard Feldman (May 20 2024 at 18:39):but it might be worth it
Richard Feldman (May 20 2024 at 18:40):there's certainly a security concern about trusting crypto libraries in general
Hristo (May 20 2024 at 18:40):It's an inevitable evil, because it's a cat and mouse game :sweat_smile:
Richard Feldman (May 20 2024 at 18:40):so even separately from performance, having them as builtins means we can provide a stronger promise of security
Richard Feldman (May 20 2024 at 18:41):and also makes it easier to reach for the more secure thing
Hristo (May 20 2024 at 18:42):we can provide a stronger promise of security
Technical considerations aside, I'd think that this would be also the case if the library was under the official Roc umbrella :thinking:
Richard Feldman (May 20 2024 at 18:44):kinda - I mean yes we could give a stronger promise of like "we didn't backdoor this" - but if it was implemented in pure Roc under the roc-lang organization, we couldn't give any kind of assurance that it would be hardened against timing attacks (for all the reasons discussed earlier) and if it was just an API for platform authors to implement, then we couldn't give any meaningful assurance that the platform author didn't implement a backdoor or something :sweat_smile:
Richard Feldman (May 20 2024 at 18:44):so I think the security angle only really works if we're implementing it as a builtin
Hristo (May 20 2024 at 18:45):Sure, yes, just to confirm - I wasn't proposing going the alternative route. Basically, trying to improve my understanding - hence the questions. Thanks for clarifying further!
Last updated: Jun 16 2026 at 16:19 UTC