The latest version is 1.2.2.
Source code is in v122/ecdl2-97.c or v122/ecdl2-97.c.gz.
The only significant change from 1.2.1 is that the inverse() function is made faster by adopting a trick from the 64-bit version.
The overall speed-up is only a few percent so there is no need to upgrade if you're already happily running 1.2.0 or 1.2.1.
Good luck,
Rob.
> ecdl2-97.c
Purpose: Fast arithmetic for computing discrete logs on elliptic curves.
Copyright: Robert J. Harley, 1997-1999.
Contact: Robert.Harley@inria.fr
Legalese: This source code is subject to the GNU Public License (v2).
This is ECDL32, version 1.2.2.
Consult the following URL for more information:
http://pauillac.inria.fr/~harley/ecdl6/
Do this:
cc -O3 ecdl2-97.c -o ecdl
mkdir `uname -n`
cd `uname -n`
nice ../ecdl mail `whoami` MyTeam `uname -n` `uname -m` `uname -s` > log &
1. Compiling
Compile with something like:
gcc ecdl2-97.c -o ecdl -O3 -fomit-frame-pointer -freg-struct-return
You can test the binary like this:
./ecdl test me Testers bla bla bla
The test output should match the sample below except for the number of iterations per second.
If the program complains that it cannot find sendmail, you can add -DSENDMAIL='"/usr/sbin/sendmail"' or something similar.
Test output follows:
ECDL32, version: 122.
Mode ...... test
User ...... me
Team ...... Testers
Machine ... bla
Hardware .. bla
OS ........ bla
Comment ... none
Generating 16 new starting points.
Computing iterations...
TEST|i|00000000F5D9|u|0CE88C78C39716A6D889E4D6F|v|097270894213CD2CBEA285D55|x|0C3C2CDDFF8C4279EC5AAB9BF|y|1290F0B3A000002F531FBCF48|z|1|ECDL32|122|me|Testers|bla|bla|bla|none
Iterations during this run = 1.00699e+06 at 123255 per second.
TEST|i|000000029A81|u|0BA4E82EA6583E60E838CAEEB|v|05B6B313B019235A5B625DCDE|x|121EB4F0B63979CF23C09D141|y|143FABEBA00000DABD7D4D947|z|1|ECDL32|122|me|Testers|bla|bla|bla|none
Iterations during this run = 2.73e+06 at 123251 per second.
TEST|i|000000021E19|u|03CAE5F39F306A6AD65546C8E|v|0EA840FE305582F5BA4579262|x|1EDEBCF29E944196D035CA9C4|y|1173E36A000000325651075A9|z|1|ECDL32|122|me|Testers|bla|bla|bla|none
Iterations during this run = 3.22742e+06 at 123231 per second.
TEST|i|000000038C2D|u|0B82CED105A610870BFA92949|v|09857CC5392EEB909B42284FC|x|0C9B2A1B19035BFED248338DC|y|1B15423D300000637751200A2|z|1|ECDL32|122|me|Testers|bla|bla|bla|none
Iterations during this run = 3.71989e+06 at 123216 per second.
TEST|i|0000000394E7|u|0B12B3E964A4838F5171EFF34|v|0EC332CBBBD928885F68DB32B|x|1181B6278149DA62C19952F60|y|0E29784080000003F1357A460|z|1|ECDL32|122|me|Testers|bla|bla|bla|none
Iterations during this run = 3.75563e+06 at 123176 per second.
TEST|i|000000047FBC|u|0BA7954CF5ED75872199EED48|v|0E01F017DA0B255ECF5A8FFB6|x|029AF42867F438BA63D63CC70|y|1E8A120BE00000582C12DC2DD|z|1|ECDL32|122|me|Testers|bla|bla|bla|none
Iterations during this run = 4.7175e+06 at 123237 per second.
TEST|i|000000049F5A|u|02A08894A33477FAF87B576DD|v|06CAC5498B6A9B16867BBDC64|x|030AD30833783CB041004E04B|y|16054C86F00000AC181007E65|z|1|ECDL32|122|me|Testers|bla|bla|bla|none
Iterations during this run = 4.84701e+06 at 123239 per second.
[...and so on...]
2. Optimising
Good speeds are roughly 120 k iterations per second for a 500 MHz x86, 145 k for a 450 MHz PowerPC G3 and 60 k for a 275 MHz StrongARM. You can compile with various optimisation flags to maximise speed before starting on the real calculations.
You can try defining -DPROD=2 or -DPROD=3 to use different implementations of two speed critical functions. They might or might not be faster depending on your chip and compiler.
You can also try tweaking the value of PARAL. Just add -DPARAL=12, for instance. The default is 16 and useful values are roughly in the range 8 to 20. Note that the test output will no longer exactly match the sample given above.
3. Starting up
When you're ready to start up: on each machine you want to run on make a directory for that machine, cd into it and go.
mkdir `uname -n`
cd `uname -n`
unlimit cputime || (echo Using ulimit instead; ulimit -t unlimited)
nohup nice +15 ../ecdl [...arguments, see below...] > log &
NB: Some shells need nice -15 instead. If you have a machine with several CPUs, make a directory for each CPU and start up an ecdl process in each one.
The arguments have the following syntax:
ecdl <mode> <user> <team> <machine> <hardware> <OS> { <comment> }
<mode>: Either test, mail, alt or batch.
<user>: Something to identify you by e.g., your email address.
<team>: Name of the team you are on e.g., one you just made up!
<machine>: The machine name e.g., as given by uname -n.
<hardware>: The machine hardware type e.g., as given by uname -m.
<OS>: The OS name e.g., as given by uname -s.
<comment>: Optional extra text.
None of these fields should contain the | character but they can contain spaces and stuff as long as you use 'single quotes' around the fields concerned on the command line.
Examples:
ecdl mail 'Robert Harley' INRIA corton '500 MHz 21164a' Linux
ecdl mail biff@skool 'Hackerz from Hell' `uname -n` `uname -m` `uname -s`
ecdl batch anon 'Anonymous People' bla bla bla 'Yo dude, check this out!'
Test mode quickly produces some (useless) output to stdout along with info on iterations per second. This allows you to check that your binary is OK, to compare compiler optimisation flags etc.
Mail mode emails a result back to ecdl2-97@pauillac.inria.fr every few hours or so (as well as writing it to stdout). INRIA's excessively aggressive spam filters might refuse the email; in that case switch to alt mode which sends to ecdl2-97@rupture.net instead.
For machines not permanently connected to the Net, batch mode only writes the results to stdout, so you should redirect that to a log file and email the file (or just the new lines at the end of it) by hand once in a while. Beware of mailers that wrap long lines, though!
4. Shutting down (and saved states)
When the program is running it saves its internal state in a file (called saved.state.new.format) from time to time. The reason each machine should have its own directory is to avoid the saved states getting mixed up! If you want to stop the program, the best way is to find it's PID (first column of the ps output) and send the TERM signal which causes it to save its state and exit:
ps x | grep ecdl
kill -TERM <the PID>
When you restart in the same directory:
nohup nice +15 ../ecdl [...arguments...] >> log &
the program will look for the saved state file. If no saved state is found it will generate a new state and work from there. If one is found, the program reads it, and continues where it left off. Note that it would be wasteful to use a given saved state on more than one CPU because work would just be duplicated. Note also that test mode does not mess with the saved state.