| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Compensate for PyCrypto's weird inversion of p and q when calculating
CRT coefficients, and add key the key components PyCrypto doesn't
bother pre-calculating to our test data.
|
|
Theorem. Not yet tested, and given the number of moving parts I would
be astonished if this version actually worked, but it does compile.
Added some timing code to tests/test-rsa.c so we can see whether this
is doing anything useful once it does work.
|
