------------------------------------------------------------------------------ Info for using 32-bit source ------------------------------------------------------------------------------ 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. ------------------------------------------------------------------------------ Comments extracted from source code below. /* > 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/ */ /*** Quickstart ***/ /* 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 & */ /*** Detailed instructions ***/ /** 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 { } * * : Either "test", "mail", "alt" or "batch". * : Something to identify you by e.g., your email address. * : Name of the team you are on e.g., one you just made up! * : The machine name e.g., as given by "uname -n". * : The machine hardware type e.g., as given by "uname -m". * : The OS name e.g., as given by "uname -s". * : 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 * * 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. */ ------------------------------------------------------------------------------