Only do the first 2 steps of 2nd freduce_coefficients loop

See the inline comments for an explanation of the implications
here: after you've done the first pass through the coefficients,
carried output[10] forward to output[0], and reduced output[1] and
output[2], you're in a "nearly reduced" state where everything but
output[2] is reduced, and |output[2]| <= 2^26.  (That is, it is
over by at most one.)

Since the largest value we compute before doing a freduce_degree
freduce_coefficients operation is a product of two sums, it's easy
to show that even if output[2] is equal to +/- 2^26, the inputs to
freduce_coefficients will all be under 2^61, which meets our
requirements.

The only operation that requires its inputs in fully-reduced form
is fcontract.  Fortunately, running an extra freduce_coefficients
on a "nearly reduced" value produces a reduced value. This happens
because if the value is fully-reduced, no carry operations will
happen, and if it is reduced except for output[2]=+/-2^26,
output[2] will become 0 and subsequent carry values will be at
most +/-1, thus stopping with output[2] equal to either 1 or 0,
which is then fully reduced.

This patch improves speed-curve25519-donna by about 13-14% on my
core2 laptop building with GCC 4.0.
Remove a needless freduce_degree

fscalar_product cannot increase the degree of a value, but we were
calling freduce_degree after it anyway.
Fix a gcc warning in speed-curve25519.c

It's not kosher to format a uint64_t with %lu: long is quite often
less than 64 bits wide.  Fortunately, the value that we want to format
here is the number of usec per operation, which won't brush up against
LONG_MAX unless you've pessimized the code until it takes over an hour
per call.
Merge pull request #4 from nmathewson/reduce_loosely

Another performance improvement for freduce_coefficients
Merge pull request #5 from nmathewson/fix_printf_warning

Fix a gcc warning in speed-curve25519.c
Use swap_conditional to fix data-dependent timing in cmult

Branching based on secret inputs can leak them to an attacker.  Let's
not do that.  This patch uses the same trick as in
curve25519-donna-c64 to make cmult() run in constant time.

It comes at a price, of course; an 8-18% performance hit, depending on
where I measure.  Still, there's no point in doing crypto fast if we
can't do it securely.
Make fcontract almost time-invariant by replacing the inner loops

We replace the old

           while (input[i] < 0) {
             input[i] += 0x2000000;
             input[i + 1]--;
           }

with

           const limb mask = input[i]>>63;
           const limb carry = -((input[i] & mask)>>25);
           input[i] += carry << 25;
           input[i+1] -= carry;

This requires a compiler where >> does sign extension on negative
numbers, but that's true pretty much everyplace, right?

The "mask" value gives us a way to leave the inputs unchanged if
input[i] >= 0.  The "carry" value works out to the number of times we
would have run through the loop.

This patch actually speeds fcontract() up a little, but fcontract is
not enough of the overal curve25519-donna profile to matter.

There is a remaining data-dependency in fcontract in the outer "do { }
while (input[0] < 0)" loop.
Document and speed up swap_conditional

The speedup is possible because we are only swapping reduced values:
only the low 10 limbs matter.

This patch cuts the cost of my previous const-time branch approximately
in half.
Do swap-conditional with 32-bit arithmetic

Because all of the values in the limb-arrays are in reduced-
coefficient form, we can cheat the swap operation a little by
computing the result on the low 32 bits of the inputs, then
sign-extending back to 64-bit limbs.

This shaves another 2 or 3% off the runtime for me.
Make fcontract fully constant-time
Use s32 operations for borrow propagation in fcontract

This seems to make curve25519-donna slower, not faster, on my AMD64 system,
but on a friend's Atom netbook, it's a noticeable speedup.
Fix typo in Makefile
Fix comment typo
Merge pull request #6 from nmathewson/consttime

Make the 32-bit implementation almost time-invariant
Merge pull request #8 from katmagic/consttime-v2

Consttime v2
run 'ranlib' on .a files, needed to make OS-X (10.6.8) happy

Without it, I get an error when e.g. test-curve25519-donna attempts to link
against curve25519-donna.a built by Snow Leopard's gcc-4.2.1 (as mangled by
Apple):

  ld: in curve25519-donna.a, archive has no table of contents

I vaguely remember modern gcc/ar producing TOCs by default, so ranlib is
redundant these days, but this system's binutils are probably too old. I
believe ranlib is generally harmless on other systems.
Merge pull request #10 from warner/OSX-ranlib

run 'ranlib' on .a files, needed to make OS-X (10.6.8) happy
add all executables to .gitignore
Merge pull request #11 from warner/gitignore

add all executables to .gitignore
Remove the "wrong-length" printf from the python module.

Later pythons, or gcc, complained about a mismatch between
the %ld and the Py_ssize_t. The printf was really just there
for initial debugging anyways, so the simplest thing is to
remove it.