sjcl
sjcl copied to clipboard
bitwiseshiftleft
Add more curves for ecc
There have been a lot of demands for different curves for ecc. I would like this ticket to keep track of all of those to be able to close the different requests.
Currently there are the following requests: ~~secp256k1: #153~~ ~~NIST P-521: #140~~ non-weiestrass: #147
Since we're on the topic -- any chance you could add DJB's Curve25519? It's now the default in OpenSSH 6.5.
EDIT: I see others have requested this as well. Sorry for the dupe!
NIST P521 and 256K1 should be very simple to add, the primitives have been provided, they just need it to be validated now. Curve25519 isn't a Weierstrass curve, and it would require a pretty decent modification to the ECC library. That being said, I'd like to see it be supported as well!
I know that implementing new primitives could be scary, but please support curve25519 and ed25519
+1 for curve25519 and ed25519. There's currently no sane implementation for JavaScript around that doesn't pollute the name space and that integrates nicely.
+1 on supporting ed25519. I'm willing to help fund development if there is interest.
The parameters for curve NIST P521 proposed by @alax in ticket #140 are correct, according to my experience. These are:
c521: new sjcl.ecc.curve( sjcl.bn.prime.p521, "0x1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA51868783BF2F966B7FCC0148F709A5D03BB5C9B8899C47AEBB6FB71E91386409", -3, "0x051953EB9618E1C9A1F929A21A0B68540EEA2DA725B99B315F3B8B489918EF109E156193951EC7E937B1652C0BD3BB1BF073573DF883D2C34F1EF451FD46B503F00", "0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66", "0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650")
BTW, I had posted those parameters more than two years ago at the SJCL Google Groups discussion area. Here's the link: https://groups.google.com/forum/#!searchin/sjcl-discuss/sjcl$20521-bit/sjcl-discuss/_kTL0iu2o7s/AE_FvbVkY4MJ.
Back then, ecc.js used the difference between the field modulus p and the order r, rather than the value of r itself, hence the different parameter in the Google Groups posting, but it amounts to the same.
My own application based on SJCL, PassLok (you can find it on Github), has used these parameters ever since. I can tell you that it works fine, as far as performance. I haven't tried any test vectors, though.
Can anyone offer the correct numbers for those who want ed25519 and are willing to hard code it into their JavaScript?
ed25519: new sjcl.ecc.curve(
sjcl.bn.prime.p25519, // Yes, this is there already [^1]
"0xIDONTKNOW",
-1, // I think that's correct by looking at elliptic source [^2]
"0xMORESECRETS",
"0xWHYISTHISSOHARD",
"0xAGAINHOWWOULDIKNOW"
)
Lastly, why not just have progressive iteration for each addition rather then make everyone wait for all the curves before merging? Or don't include them in the code base but offer the correct code for them in a Wiki page or CustomCurves.md file? Then people could use them without the insane number lookup on http://cr.yp.to/ and paying some mathematician to decipher them into SJCL expected inputs.
EDIT: Looks as if ed25519 is a different curve then sjcl.ecc.curve suggesting the naming of the API is not universal. I don't know, I just know the systems/specs I wanted to work with use ed25519. So guess I'll check out elliptic and wait. ¯_(ツ)_/¯
The problem if I remember correctly is, that just adding the parameters is not enough, as the curve algorithm in the background expects a montgomery-type curve but ed25519 is a edward-type curve and thus would require more work. Of course progressive iteration is always welcome, I do not expect all curves in a single PR and would surely merge a PR with just one more curve.
You probably shouldn't use this but here's an implementation of Ed25519: http://pastebin.com/dR9xTUP0
Just use "sjcl.ecc.curves.ed25519" like the others. Last time I checked there wasn't any code that breaks this.
@Sc00bz Why is that in a pastebin and not a pull request? Even if it is not ready for production yet, I would still prefer it in a PR where we can discuss it and work on the coding style than in a pastebin where it is even hard to see the differences.
It was written for #273 and there's a lot of changes to ecc.js that aren't related to Ed25519.
For the curious I've had good success with libsodium-wrappers which compiles libsodium to Web Assembly and libsodium supports ed25519.