| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
Attempts to use Pavel's ecdsa256 base point multiplier instead of
software point multiplier when selecting new random points (that is,
when generating P-256 keys or P-256 signatures). Resulting points
pass the point validation test (point_is_on_curve()) but the resulting
signatures are invalid. Don't know why yet. Seems like an odd
combination, as one would expect random garbage to fail validation.
In any case: this commit is intended to archive progress so far, and
perhaps see if somebody else can spot what's wrong. As presently
coded, this wouldn't be suitable for production use even if it worked.
NB: As I understand it, the ecdsa256 core is *not* a general purpose
point multiplier even just for the P-256 curve. Rather, it is
strictly a base point multiplier: it takes a single scalar as input,
and returns the X,Y affine coordinates of the curve's base point
multiplied by that scalar. This is essentially the eliptic curve
portion of the computation involved in picking a random point for key
or signature generation, but is not useful for signature validation.
See the README.md in Pavel's source repository for further details.
|
|
|
|
|
|
|
|
moment this is all-or-nothing, but could easily be tweaked to allow
compile-time selection of particular hashes.
|
|
- Joachim says always check entropy and csprng for 'valid' before reading.
- Harmonize RNG status valid bit with other cores.
- Clean up compiler warnings about printf formats.
|
|
|
|
Compiles, not yet tested.
|
