Why the NIST Curves? Shouldn't we be using 25591, 448?

[DiagonalArg]

This looks like an interesting project, though I see you're using the NIST curves. Perhaps you don't know the history?

Should we trust the NIST-recommended ECC parameters?

My understanding is that we should be sticking with 25519 and apparently now also 448.

Magic-wormhole, for example, which seems similar to your project, uses 25519.

[schollz]

Would happily accept a PR to use 25519

[DiagonalArg]

Would happily accept a PR to use 25519

Would love to be able to, but I don't code!

[github-actions]

Stale issue message

[DiagonalArg]

May be stale, but it's still a relevant enhancement ...

[schollz]

@DiagonalArg , then please make a PR!

[DiagonalArg]

Take 2 of my explaining that I don't code!

Alright, we'll let this request go quietly ...

[joshcangit]

This seems really very tricky, tbh.

May need to PR both schollz/croc and schollz/pake.

The pake repo is using crypto/elliptic in Go 1.13 for the NIST curves.
But, ed25519 and NIST curves are in crypto/internal/edwards25519 and crypto/internal/nistec from 1.19.7 to 1.19.13 or 1.20.2 onwards.

Due to GO-2023-1621, there's a problem with P256 so versions 1.19beta1 to 1.19.6 and 1.20rc1 to 1.20.1 should be avoided.

Therefore, quite a lot of refactoring.

Not sure how to add ed448 as that would need to add 1 more package.

[henrik9999]

there is a pr open in schollz/pake#8 already but that person is asking for help

[github-actions]

This issue has been marked stale because it has been open for 60 days with no activity.