ECC in Javascript

[marco.barulli]

Hi,
I'm looking for Javascript implementations of elliptic curve
cryptography (ECC).
While there are plenty of Javascript implementation of RSA, I was
unable to find anything related to ECC.

Many thanks in advance,
Marco

 

[tomstdenis]

Hi,
I'm looking for Javascript implementations of elliptic curve
cryptography (ECC).
While there are plenty of Javascript implementation of RSA, I was
unable to find anything related to ECC.

My hunch is Javascript is way too slow. It only supports 16x16
products and even a GF(2) based ECC implementation would be slow.

I don't think it's impossible just your users may have to wait multiple
seconds [if not minutes] for a point mul to complete...

Tom

 

[Phil Carmody]

My hunch is Javascript is way too slow. It only supports 16x16
products

Hmmmm, never heard of floating point? 40x40 shouldn't be too hard.

and even a GF(2) based ECC implementation would be slow.

I don't think it's impossible just your users may have to wait multiple
seconds [if not minutes] for a point mul to complete...

Interpreted, it'll be a bit poor. P-coded, it should be OK.
I don't know what the usual JS engines do in the real-world.

Phil

 

[Sebastian Gottschalk]

Hmmmm, never heard of floating point? 40x40 shouldn't be too hard.

Beside that, JavaScript support 32 bit integer multiplications JITed.

Interpreted, it'll be a bit poor. P-coded, it should be OK.
I don't know what the usual JS engines do in the real-world.

As long as you don't use eval(), function Objects and document.write(),
it will be JITed. Pretty efficiently if you do static typing.

Well, except on MSIE, but its users don't deserve any website usability
at all (if so, they wouldn't use IE).

 

[VK]

Beside that, JavaScript support 32 bit integer multiplications JITed.


As long as you don't use eval(), function Objects and document.write(),
it will be JITed. Pretty efficiently if you do static typing.

Well, except on MSIE, but its users don't deserve any website usability
at all (if so, they wouldn't use IE).

p-coded JavaScript programs? JITed programs? (and I also presume then
bytecode'd JavaScript programs somewhere). Of course everything
possible in this world, even "JavaScript applet" - I JFed (Just Found)
it at
<http://www.certicom.com/index.php?action=ecc_tutorial,ecc_tut_2_3>

Yet you guys seem landed on the wrong place. JScript.Net compilation
and executable issues fit better to
<microsoft.public.dotnet.languages.jscript>

And if you meant what I think then <comp.lang.java.security> would be a
good place.

 

[Sebastian Gottschalk]

p-coded JavaScript programs? JITed programs? (and I also presume then
bytecode'd JavaScript programs somewhere). Of course everything
possible in this world, even "JavaScript applet" - I JFed (Just Found)
it at
<http://www.certicom.com/index.php?action=ecc_tutorial,ecc_tut_2_3>

Yet you guys seem landed on the wrong place. JScript.Net compilation
and executable issues fit better to
<microsoft.public.dotnet.languages.jscript>

We're talking about normal javascript which is partitially precompiled
on Mozilla, Opera and Konqueror/Safari.

 

[VK]

We're talking about normal javascript which is partitially precompiled
on Mozilla, Opera and Konqueror/Safari.

You mean partitially precompiled /sources/ served to the browser a la
..class bytecode in Java? There is not such in JavaScript (though exists
something similar in JScript.Net).

If you mean the source /parsing/ rules after the script text is served
to the browser, then its described in ECMA-262 specs:- but It has no
effect on performance at runtime.

If you mean that say in
for (var i=0; i<10000; ++i) {
// do a lot of stuff
}
the engine doesn't parse all lines 10000 times but keep it as compiled
binary in the execution stack - then you are finally right, and it
/may/ be called "JITed" as for any other language though - as no one
modern engine acts as a Babbage's machine

Yet using very specific terms of one programming language in
application to another completely different language - without any
indication what you are just making an analogy - is not correct.
Besides being very confusing for readers, it also implies to yourselve
wrong expectations of the results.

Actually the most popular crypto algorithms are rather simple by
themselves, so a relevant sub can be written on any available language.
But they are very math intensive, so an anyhow good security will be
dead slow on any language: JavaScript, Java or C++. It must be an
assembly optimized code to get a good performance. One time Bouncy
Castle for **Java** was known to be good <http://www.bouncycastle.org/>

Still a quick enough **JavaScript** program could be written, but its
cryptography "strength" will have only educational value.

 

[tomstdenis]

If you mean that say in
for (var i=0; i<10000; ++i) {
// do a lot of stuff
}
the engine doesn't parse all lines 10000 times but keep it as compiled
binary in the execution stack - then you are finally right, and it
/may/ be called "JITed" as for any other language though - as no one
modern engine acts as a Babbage's machine

bytecode is not a form of JIT'ing. JIT would mean you compile to native
instructions on the fly. No Javascript implementation I know of does
that.

Tom

 

[Phil Carmody]

You mean partitially precompiled /sources/ served to the browser a la
.class bytecode in Java?

No, when he said, quite correctly, that we were talking about normal
javascript which is partitially precompiled on Mozilla et al., he meant
that we were talking about normal javascript, which he usefully informs
me is partially precompiled on Mozilla et al..

Ta, Sebastian.
Phil

 

[Sebastian Gottschalk]

JIT would mean you compile to native instructions on the fly. No
Javascript implementation I know of does that.

Mozilla does.