All the ECC (elliptic-curve cryptography) offered are insecure.

[fefafefa]

First of all, I want to say thanks to all the team behind of the Stanford Javascript Crypto Library. It's a wonderful project and I hope that one day all the browsers will have integrated it.

I am writing this issue because I am worried about all the ECC that gives this library are compromised.

The project offer the next ECC: [Project ECC name -> Common name] C192 -> ? C224 -> NIST P-224 C256 -> NIST P-256 C384 -> NIST P-384 K192 -> ? K224 -> ? K256 -> SECP256k1

A reader can see that all those ECC are vulnerable:

http://safecurves.cr.yp.to/

Please support non NIST ECC!

There are a lot others ECC: -> Curve25519 -> Curve383187 -> Curve41417 (formerly named Curve3617) -> Curve511187

Yes, I like Montgomery curves XD

On the page (http://safecurves.cr.yp.to/) are published all the ECC points, formula and prime numbers.

Thanks for all the good work and keep up it! :)

[indutny]

Take a look at this project: https://github.com/indutny/elliptic . It does support Montgomery curves, and is really fast :P

[shelby3]

Note that K256 (secp256k1) is "somewhat rigid" not "fully rigid", meaning there were some unexplained variables in the curve selection process.

http://safecurves.cr.yp.to/rigid.html

Also some of us don't want to trust an industry consortium.

http://secg.org/ http://www.secg.org/collateral/sec2_final.pdf

Given that efficiency claims have been arbitrary.

http://safecurves.cr.yp.to

"Subsequent research (and to some extent previous research) showed that essentially all of these efficiency-related decisions were suboptimal, that many of them actively damaged efficiency, and that some of them were bad for security."

@indutny, apparently your RNG is not as provably secure as the one in SJCL as you appear to rely on the built in browser RNG, which might be compromised.

https://github.com/indutny/elliptic/blob/master/lib/elliptic/rand.js

Some RNGs in operating systems as well as the RNG instruction in CPUs are throught to be potentially compromised.

[indutny]

I'm not using it's output directly, it is fed into the PRNG.

[indutny]

@shelby3 do you have any suggestions for how it could be improved?

[shelby3]

@indutny, perhaps I am mistaken but I am under the impression without having deeply studied the code that SJCL employs the mouse to gather sufficient entropy and does not by default defer to the built-in browser RNG?

Could you copy SJCL's functionality (which afaik is based on Schneier's Fortuna work)?

https://www.schneier.com/blog/archives/2013/10/insecurities_in.html https://www.schneier.com/blog/archives/2012/02/lousy_random_nu.html https://www.schneier.com/blog/archives/2013/09/surreptitiously.html http://www.infowars.com/intel-ceo-refuses-to-answer-questions-on-whether-nsa-can-access-processors/

[indutny]

This is the same kind of entropy that is used in OpenSSL, or anywhere else. I'm not using Math.random().

[shelby3]

@indutny, if OpenSSL is compromised that is no great surprise. SJCL also collects entropy from the mouse.

[Nilos]

For clarification: sjcl is using mouse entropy but it is also using window.crypto.getRandomBytes if available. In fact crypto.getRandomBytes is enough for sjcl to consider our prng seeded.

[shelby3]

@Nilos, yes I had just noted that and linked to a comment where I suggested the offending code could be deleted if one doesn't trust window.crypto.getRandomBytes. In my opinion, the RNG entropy is too critically important to trust to variable platform dependent implementation. I should probably open a new issue, wherein that should be made an option in the API.

[Nilos]

OK :) Instead of copying our prng for elliptic it would be also awesome to get a pull request ready adding those curves to sjcl. Even though I am really slow at merging things lately (and some are stalling for quiet some time) I would put an extra priority on merging those new curves if a PR existed.

[indutny]

@Nilos I think you could try to borrow some stuff from elliptic.js, it is much much faster than sjcl right now. I'd start with porting endomorphisms.

[shelby3]

@indutny, sadly I doubt that is what he meant by a pull request. Thus I am not too optimistic about it happening any time soon. Could we plugin in the PRNG from SJCL to your library?

[indutny]

ah, sorry. I forgot about initial discussion. You could try writing a plugin PRNG to use as a source of random data from elliptic's PRNG. I'll certainly accept this.