| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Various fixes extracted from the abandoned(-for-now?) reuse-cores
branch, principally:
* Change hal_core_alloc*() to support core reuse and to pick the
least-recently-used core of a particular type otherwise;
* Replace assert() and printf() calls with hal_assert() and hal_log(),
respectively. assert() is particularly useless on the HSM, since it
sends its error message into hyperspace then hangs the HSM.
|
|
Generating new RSA blinding factors turns out to be relatively
expensive, but we can amortize that cost by maintaining a small cache
and simply mutating old values after each use with a cheaper
operation. Squaring works, pretty much by definition.
Blinding factors are only sort-of-sensitive: we don't want them to
leak out of the HSM, but they're only based on the public modulus, not
the private key components, and we're only using them to foil side
channel attacks, so the risk involved in caching them seems small.
For the moment, the cache is very small, since we only care about this
for bulk signature operations. Tune this later if it becomes an issue.
|
|
Failing to clear the temporary buffer used to transfer bits from the
TRNG into a bignum was a real leak of something very close to keying
material, albeit only onto the local stack where it was almost certain
to have been overwritten by subsequent operations (generation of other
key components, wrap and PKCS #8 encoding) before pkey_generate_rsa()
ever returned to its caller. Still, bad coder, no biscuit.
Failing to clear the remainders array was probably harmless, but
doctrine says clear it anyway.
|
|
This branch was sitting for long enough that master had been through a
cleanup pass, so beware of accidental reversions.
|
|
|
|
|
|
Snapshot of mostly but not entirely working code to include the extra
ModExpA7 key components in the keystore. Need to investigate whether
a more compact representation is practical for these components, as
the current one bloats the key object so much that a bare 4096-bit key
won't fit in a single hash block, and there may not be enough room for
PKCS #11 attributes even for smaller keys.
If more compact representation not possible or insufficient, the other
option is to double the size of a keystore object, making it two flash
subsectors for a total of 8192 octets. Which would of course halve
the number of keys we can store and require a bunch of little tweaks
all through the ks code (particularly flash erase), so definitely
worth trying for a more compact representation first.
|
|
|
|
|
|
|
|
|
|
Work in progress. Probably won't even compile, much less run.
Requires corresponding new core/math/modexpa7 core.
No support (yet) for ASN.1 encoding of speedup factors or storage of
same in keystore.
No support (yet) for running CRT algorithm in parallel cores.
Minor cleanup of ancient bus I/O code, including EIM and I2C bus code
we'll probably never use again.
|
|
At least for now, the speed tradeoff between software ModExp and our
Verilog ModExp core differs significantly between signature and key
generation. We don't really know why, but since key generation does
not need to be constant time, we split out control over whether to use
the software or FPGA implementation, so that we can use the FPGA for
signature while using software for key generation.
Revisit this if and when we figure out what the bottleneck is, as well
as any time that the FPGA core itself changes significantly.
|
|
Trying to make RSA key generation run in constant time is probably
both futile and unnecessary, so we can speed it up a bit by switching
the ModExpA7 core to use "fast" mode rather than "constant time" mode.
Sadly, while this change produces a measureable improvement, it
doesn't bring FGPA ModExp anywhere near the speed of the software
equivalent in this case. Don't really know why.
|
|
|
|
Algorithm suggested by a note in Handbook of Applied Cryptography,
motivated by profiling of libtfm fp_isprime() function showing
something close to 50% of CPU time spent running Montgomery reductions
in the small primes test, before we even get to Miller-Rabin.
|
|
|
|
Compiles, not yet tested. Existing tests need conversion to PKCS #8
before we can do anything useful with this.
Once everything uses PKCS #8 instead of algorithm-specific formats, we
can revisit API issues like whether hal_rpc_pkey_load() should still
be taking `type` and `curve` arguments.
|
|
|
|
Find a suitable core, and mark it busy. Don't forget to release it as soon
as you're done. This has a knock-on effect of un-const'ing core arguments
and struct fields in a lot of places, and it moves some core checks around.
|
|
|
|
|
|
|
|
|
|
|
|
forma hal_core_t* argument.
|
|
|
|
|
|
public key extraction functions on hold pending ASN.1 cleanup.
|
|
|
|
Compiles, not yet tested.
|
|
bit more obvious when we've forgotten to do this than when we've
forgotten to call fp_init() or memset(). Convert rsa.c to use the
one-element-array idiom so we can get stop prefixing every bignum
reference with "&".
|
|
This required a bit of manual cleanup in hal.h, hash.c, and rsa.c. No
intended changes to functionality provided by parent comments, just a
few tweaks to track API changes beyond git's ken.
|
|
|
|
|
|
RSA code; use simpler model (pointer to incomplete structure) used in
ECDSA code. Refactor RSA code to use shared ASN.1 routines.
|
|
|
|
issues in ModExp core.
|
|
constraints to allow any key size within our supported range, since
hsmbully seems to want to twist this knob to every possible setting.
|
|
|
|
|
|
cleanup and commenting within RSA module.
|
|
testing other code and don't want to wait for the as-yet-unoptimized
FPGA ModExp core.
|
|
drag in all of TFM's Montgomery just to support the Miller-Rabin test.
|
|
long, since that's the form we'll need for PKCS #11.
|
|
|
|
|
|
|
