[Cryptech Tech] cryptlib HAL for EIM
Rob Austein
sra at hactrn.net
Wed Apr 22 17:39:49 UTC 2015
At Wed, 22 Apr 2015 12:11:14 -0400, Paul Selkirk wrote:
>
> b) Does the library build make sense to you? Note that this is a static
> library with position-independent code for cryptlib, which is kosher AFAIK.
Static library of position independent code is indeed kosher, and it's
what I'd do. I'm not sure why compilers even bother to default to
non-PIC code anymore, but in any case PIC code should be harmless.
Shared libraries are almost always more trouble than they're worth
except (sometimes) when presenting an external interface. We can
always add a shared library configuration later if we need it.
> c) Since 'make test' only uses cryptlib's python interface, I hacked
> GNUmakefile to patch build/bindings/setup.py. We might want/need a more
> complete solution in the future, e.g. embedding libcryptech.a in
> libcl.a, but I didn't want to go too far down that rat-hole on the first
> pass.
Should be OK for now. I wouldn't bother trying to merge libraries at
this stage.
> d) The API functions are all tc_* (for "test case", from their origins
> in hash_tester). It's probably time to rename them all to ct_* (for
> "cryptech"), unless you have a better idea.
[Bikeshed warning]
"ct_" makes me think "content type", not "Cryptech", and there might
be significant other bits of Cryptech code in any case.
Perhaps something like "hwc_" for "hardware crypto"?
More information about the Tech
mailing list