Support 16 and 32 bit builds

[drbild]

AMCL uses different chunk sizes under the hood for 16, 32, and 64 bit machines. So, we can't hard code things like BIG_256_56 here.

This series

• borrows the WORD_SIZE detection and configuration logic from ACML.
• extends the template expansion logic to support 16 and 32 bit configs.

[zanebeckwith]

This branch is a bit old now (it's taken me too long to work on this), so once we're ready to merge I'll rebase and get it ready.

I'd appreciate any feedback on the CMake approach taken in the new commits, particularly the way I'm installing the new libecdaa-tpm library and its pkgconfig/cmake configuration.

[drbild]

• The export/cmake config should probably still be combined. One ecdaa-config.cmake file can include multiple targets. TPM support (the TPM lib) can be treated as a component --- see amcl-config.cmake.in template for how to do that.

• Separate *.pc files for pkg-config is the correct approach. It works best as one lib per *.pc file.

• The overall organization feels a bit wonky to me. It's not immediately obvious that two libraries are being built.

  include
  include/ecdaa
  include /ecdaa-tpm
  
  src/
  src/amcl-extensions
  src/tpm  # <- This is a separate library, but looks like part of the main library.
  prng.c
  ...

  It's more common to see the two libraries split at the root, with separate include directories.

How about

.travis/
cmake/
examples/
ecdaa/  # or libecdaa/
ecdaa/include/
ecdaa/CMakeLists.txt  # Defines the lib and install targets for ecdaa
ecdaa/prng.c
ecdaa/test/
ecdaa-tpm/ # or libecdaa-tpm
ecdaa-tpm/include/
ecdaa-tpm/tpm_context.c
ecdaa-tpm/CMakeLists.txt #Defines the lib and install targets for ecdaa-tpm
ecdaa-tpm/test/
CMakeLists.txt # Sets options, creates packaging (`ecdaa-cmake.config` and the two `*.pc` files).

[zanebeckwith]

Agree with above, so most recent commit structures project as:

.travis/
cmake/
libecdaa/
libecdaa-tpm/
internal-utilities/
test/

where internal-utilities groups together some utility functions that both regular and TPM variants use (mostly, it's the AMCL extension functions, which I hope to eventually get upstreamed).

@drbild let me know what you think when you have time to take a look

[coveralls]

Coverage decreased (-2.8%) to 93.358% when pulling 583e649dda51acc018c1715b9e32397164692029 on drbild:support-32-bit into e1abd65e69e3e68ad15ff11f79e48fac4b2e03e2 on xaptum:master.

[drbild]

@zanebeckwith I suggest the name common/ instead of internal-utilities since it's a common convention and much shorter.

common
common/amcl-extensions
common/internal-utiltities

Also, are any of the headers in acml-extensions public? That is, do any of them need to be installed?

[zanebeckwith]

No, nothing in amcl-extensions should be public, it should all be getting compiled into the library.

I'll rename to common (good call, I like that).

[zanebeckwith]

This PR does the following:

• Adds the ability to detect word-size of machine
• Uses appropriate version of AMCL BIGNUM type depending on that word-size
• Makes TPM-specific functions templated on curve type (just like other functions), rather than having FP256BN hardcoded
  • Though, FP256BN is still the only curve that is allowed to be used with TPM functions
• Pulls TPM-specific functionality into separate module, which results in separate libecdaa-tpm library

[zanebeckwith]

Fixes #104