Support for x25519

[jackivanov]

Hi there,

I would be nice to have curve25519 supported

https://godoc.org/golang.org/x/crypto/curve25519

edit:

I have published a custom provider for now https://registry.terraform.io/providers/jackivanov/x25519/latest/docs

[azrdev]

duplicate(?) of #26

[detro]

This sounds like it's covered by the work ongoing in #150.
Closing, but if it's different, please provide a lot more details of how the desired feature would look like.

Thank you :)

[jackivanov]

@detro curve25519 is kinda different feature than just ED25519

[jackivanov]

@detro Take a look at my draft in this fork

[detro]

OK, I gave a quick read to the RFC but I won't pretend to be "an expert" or anything on the topic.

From what I gather, it's describe a Curve and can be used for implementing Cryptographic functions/tools.

Sorry, but the reason it feels out of place here, is because it's too "low level" compared to what this Provider does: even if we expose the data of such a curve, what would then be the use? It's not a certificate or a key, something that can be fed to other systems during a Terraform Apply.

But if you can document/describe a more concrete end-2-end example of where having such a resource in Terraform would be usable and beneficial, we could revisit this.

Hope it makes sense.

thank you

[jackivanov]

@detro We can use that to generate a private/public key pair and feed to any application that supports it. For example, WireGuard. I'm not an expert too, but you can take a look at my PoC, and the resource codebase in in my previous comment.
WireGuard code has been recently added to the linux kernel natively, and I'm pretty sure there'll be more systems in future.

[detro]

So, I did a quick googling to learn a bit more about X25519 and it's relationship with ED25519: https://words.filippo.io/using-ed25519-keys-for-encryption/

What I'm concerned about here at this point, is that we (HashiCorp) don't want to add new features to this provider unless they are absolutely well established features that "should be here".

It's a delicate balance to chose when something is common enough to be needed. So, what I could do is to re-open the issue, waiting for more input/interest from the community.

[jackivanov]

I can definitely contribute and file a PR for your review if you'd like

[AlexHunterCodes]

If implementing Curve25519 generically would allow Terraform to work with Wireguard keys in the same vein as other SSL/TLS/SSH keys, that would be a huge win for me. Being able to do all this in Vault too without having to use Key/Value would be even better.

[thekev]

What happened to this? PR closed but not merged.

[jackivanov]

It seems that the project maintainers may not have shown much interest in contributions from the community. I'll be happy to rework whatever's required to get this merged.

[jackivanov]

For everyone interested I have published a provider - https://registry.terraform.io/providers/jackivanov/x25519/latest/docs

[ptwohig]

ZeroMQ also uses the Curve25519 and being able to generate the keys would be helpful to me as well.