projected unsupported. small amounts of rot in core components.

[sevenrats]

*edit: The differences between the code this repo was based on and the modern wireguard-go codebase are significant enough that moderate amounts of repair will need to be done to use it in any modern implementation.

*original: disagreement between the module path and the github path is the worst.

[PizzaWhisperer]

I see that it can be an artifact of the archival of the crystal-go library... @tgkudelski since you handled it, do you know what happened/how to fix that 🤞?

[sevenrats]

I'm having trouble building anything that depends on this project. Do you mind explaining to me how you do it when all the imports recursively point to /kudelskisecurity/wireguard? I've tried basically every combination of forking, local copies, and replace commands that I can think of. it feels broken. am I missing something?

[PizzaWhisperer]

Hey I know there is a problem but I do not know how to fix it that's why I asked a colleague for help :) Just give us a bit of time

[PizzaWhisperer]

I appreciate you pointing it out tho!

[sevenrats]

no worries mate, sorry for coming off as pushy. I just wanted to make sure my golang noobishness wasn't the problem.
rt this started as one of those golden github moments where I started to write this exact implementation and you had already done it for me, so, thanks for saving me weeks of my life, lol. I'm psyched to try it out.

[tgkudelski]

Hello, unfortunately I'm not sure I can help with this. The crystals-go library was officially discontinued last January following the Kyberslash incident (but TBH it should have been discontinued earlier), I did not touch the pq-wireguard repo so I don't know what happened here. Last update I see is from @PizzaWhisperer from 3 years ago. Actually I think I should also archive pq-wireguard as it is not maintained from our side. Please feel free to fork!

[sevenrats]

@tgkudelski ah, that makes sense then. yes, archival would be helpful in that case. may I have the benefit of your expertise? would it be worth my time to reimplement on CIRCL? I don't know the ins and outs of the exploit you mentioned. If it would be worth my time, would this work still serve as a reasonable roadmap? It looks like Cloudlfare provides a fork of go that patches crystals into the crypto libs. Would that be a reasonable approach?

[tgkudelski]

@sevenrats you mean, using crystals-go as a base to implement CRYSTALS in CIRCL? I cannot advise on such decision, because I was not involved in the development of crystals-go or pq-wireguard. AFAIK crystals-go is basically a Go translation/reimplementation of the reference C code of CRYSTALS, but it's based on an old version of such reference code. Over the years, many implementation issues have been found in the reference code and fixed, some parameters changed, etc. Maybe @PizzaWhisperer can chime in, but I think it would be a lot of error-prone work to sanitize the crystals-go code to make sure that it is compliant with the currently approved NIST standards.

[tgkudelski]

But I will archive this repo in a couple of days anyway.

[sevenrats]

I'm sorry, I'm not being clear. I would love a chime-in from PizzaWhisperer on this as well.
What I'm asking is, do either of you think it would be reasonable to reimplement this wireguard-go work using CIRCL to provide CRYSTALS instead of crystals-go.