Stream: contributing

Topic: Cryptography built-ins

Matthew Heath (Jun 10 2024 at 14:57):

On the introductions channel @Luke Boswell suggested that, since I have a strong mathematical background, it would be a good a idea for me to try to make a start on this idea to add built-in cryptography.
I have not contributed before so am likely to need a lot of help getting started.

Anton (Jun 10 2024 at 15:32):

@Richard Feldman @Brendan Hansknecht what are the first steps here? Do we start with bcrypt and call the zig implementation? Probably also need to add some plumbing to setup compiling crypto stuff to llvm IR

Brendan Hansknecht (Jun 10 2024 at 15:34):

That's definitely an easy start. Instead of rewriting a crypto impl, just use what already exists in zig and should be fast.

Richard Feldman (Jun 10 2024 at 15:44):

are we sure we specifically want bcrypt?

Richard Feldman (Jun 10 2024 at 15:45):

I think sha256 is the least controversial one I can think of

Richard Feldman (Jun 10 2024 at 15:45):

and yeah I think using zig (or C, via Zig) implementations is the way to go here! :100:

Anton (Jun 10 2024 at 15:53):

sha256 is good for me

Anton (Jun 10 2024 at 15:57):

So in crates/compiler/builtins/roc do we create a folder Crypt with Sha256.roc as first module?

Richard Feldman (Jun 10 2024 at 20:20):

sounds good to me!

Matthew Heath (Jun 10 2024 at 22:33):

Would the plan be to just have a pure version of Sha256.hash or would there also be a need for the streaming versions with updateand finalResult?

Richard Feldman (Jun 11 2024 at 03:13):

that’s a good question; I’d guess both

Agus Zubiaga (Jun 11 2024 at 11:12):

It seems good to have SHA256 for message digest, but I think those aren’t recommended for password hashing which I expect would be a common use case

Richard Feldman (Jun 11 2024 at 12:09):

yeah I just think that use case needs more design work to figure out which algorithm(s) to recommend, which to include for backwards compatibility, etc

Matthew Heath (Jun 12 2024 at 21:01):

Is the process: Create issue on the main repo -> create a fork -> create a branch on the fork-> make the changes -> create a pull request on the main repo , from the forked branch -> link the PR to the issue ?

Brendan Hansknecht (Jun 12 2024 at 21:02):

That works

Brendan Hansknecht (Jun 12 2024 at 21:02):

Though no need to make an issue specifically

Luke Boswell (Jun 12 2024 at 21:02):

That works.

In this case I'm not sure we need an Issue though.

Also you can make the changes in a fork too, not sure if everyone has write permissions to roc.

Brendan Hansknecht (Jun 12 2024 at 21:02):

If it is work to be done, you can just do it, but tracking in issues can be nice

Albert (Jun 15 2024 at 07:07):

Is there a concept of std libs in Roc yet? What's the difference between built-ins and platform APIs?

Brendan Hansknecht (Jun 15 2024 at 07:11):

There are 3 current types of libraries I guess.

1. Builtins. They are written or roc or zig, part of the compiler, and always available. Are trusted to be pure but have the ability to be unsafe.
2. Roc libraries. 100% pure roc code. Can be imported by any app. May depend on being passed task builder functions to generate tasks to run.
3. Platform libraries. Untrusted and must always be accessed through effects/task. Can be written in any language and can do essentially anything. (Note, a platform can also include pure roc code that is equivalent to a roc library)

Matthew Heath (Jul 03 2024 at 21:45):

Hi. Just an update that I have finally found some time to work on this at this fork,. It doesn't work currently but I think I can see what I am doing wrong

Last updated: Jul 06 2025 at 12:14 UTC