| Age | Commit message (Collapse) | Author |
|---|
|
PyCrypto is no longer present in Debian Bullseye and is abandonware in
anycase. PyCryptodome is about 98% of a drop-in replacement (but that
last 2% can be tricky), so convert the most critical stuff to use
PyCryptodome.
A bunch of the test scripts and so forth still need to be converted,
for today the goals are just to have the package install properly and
to be able to run the unit tests.
|
|
This is a short term kludge to let the old unit test code continue to
work under Python 3.8.
Medium term, we should replace all use of PyCrypto with PyCryptodome
(API-compatible successor package).
Long term we might want a newer API, but that can wait.
|
|
|
|
Really just one bug, but confusingly masked by an interaction between
generators and our XDR context manager, so don't use the context
manager in the one generator method in the cryptech.libhal API.
Also run reindent.py on a few old test modules.
|
|
There's still something wrong with XDR for attribute lists in Python
3, XDR complains that there's unconsumed data and attributes coming
back are (sometimes truncated). Python 2 works. Probably data type
issue somewhere but haven't spotted it yet.
|
|
|
|
|
|
|
|
over a year ago.
|
|
|
|
|
|
|
|
We were XORing the low 32 bits of R[0] instead of the full 64 bits.
Makes no difference for small values of n, so we never detected it.
|
|
|
|
|
|
|
|
Turns out there are a couple of known minor bugs in PyCrypto's ASN.1
decoder, simple dumb things that never could have worked. Debian's
packaging includes a patch for these bugs, but for some reason the
patch is marked as not needing to be sent upstream, dunno why. So
these methods work fine, but only on Debian. Feh.
Simplest approach is to work around the bugs on all platforms,
particularly given that this is just unit test support code.
|
|
|
|
|
|
|
|
|
|
pkey_open() now looks in both keystores rather than requiring the user
to know. The chance of collision with randomly-generated UUID is low
enough that we really ought to be able to present a single namespace.
So now we do.
pkey_match() now takes a couple of extra arguments which allow a
single search to cover both keystores, as well as matching for
specific key flags. The former interface was pretty much useless for
anything involving flags, and required the user to issue a separate
call for each keystore.
User wheel is now exempt from the per-session key lookup constraints,
Whether this is a good idea or not is an interesting question, but the
whole PKCS #11 derived per-session key thing is weird to begin with,
and having keystore listings on the console deliberately ignore
session keys was just too confusing.
|
|
|
|
Now that we use PKCS #8 format for private keys, all key formats we
use include ASN.1 AlgorithmIdentifier field describing the key, so
specifying key type and curve as arguments to hal_rpc_pkey_load() is
neither necessary nor particularly useful.
|
|
|
|
|
|
|
|
|
|
A few parsing problems remaining, mostly with objects large enough
that PKCS #8 may have pushed them over some buffer size or another.
These are all with RSA, where the Python code (PyCrypto) already
supported PKCS #8, so most likely it's a problem in the new C code.
Python ECDSA PKCS #8 shim code is nasty and could use some cleanup.
If practical, we might want to sub-class ecdsa.keys.SigningKey; we
might also want to flesh this out into something we can send upstream
to the author of the Python ecdsa library.
|
|
|
|
|
|
Log exceptions immediately when failing a test; doesn't replace
backtrace at end of test run, but since a full test run can take a
while it's useful to know what failed closer to when it happened.
More conditionals to skip tests which require external Python crypto
packages when those packages aren't installed.
|
|
|
|
PKCS #11 supports zero-length attributes (eg, CKA_LABEL) so hack of
using zero length attribute as NIL value won't work, instead we use a
slightly more portable version of the hack PKCS #11 uses (PKCS #11
stuffs -1 into a CK_ULONG, we stuff 0xFFFFFFFF into a uint32_t).
ks_attribute.c code was trying too hard and tripping over its own
socks. Instead of trying to maintain attributes[] in place during
modification, we now perform the minimum necessary change then re-scan
the block. This is (very slightly) slower but more robust, both
because the scan code has better error checking and because it's the
scan code that we want to be sure is happy before committing a change.
Rename hal_rpc_pkey_attribute_t to hal_pkey_attribute_t.
|
|
hal_rpc_pkey_list() was a simplistic solution that worked when the
keystore only supported a handful of keys and we needed a quick
temporary solution in time for a workshop. It doesn't handle large
numbers of keys well, and while we could fix that, all of its
functionality is now available via more robust API functions, so
simplifying the API by deleting it seems best.
Since this change required mucking with dispatch vectors yet again, it
converts them to use C99 "designated initializer" syntax.
|
|
|
|
pkey attribute API is now just set_attributes() and get_attributes().
|
|
Passes minimal unit-testing and the same minimal tests report that it
does deliver the desired performance speed-up. More testing and much
cleanup still needed.
Attribute API not quite stable yet, we're probably going to want to
remove all the singleton attribute operations from the RPC protocol,
and it turns out that ks_delete_attributes() has enough code in common
with ks_set_attributes() that it makes more sense to handle the former
as a special case of the latter.
|
|
This is not yet complete, only the ks_volatile driver supports it,
ks_flash will be a bit more complicated and isn't written yet.
At the moment, this adds a complete duplicate set of
{set,get,delete}_attributes() functions in parallel to the earlier
{set,get,delete}_attribute() functions. We will almost certainly want
to get rid of the duplicates, probably (but not necessarily) the
entire single-attribute suite. At the moment, though, we want both
sets so we can compare execution speeds of the two sets of functions.
|
|
Result of running all these timing tests is about what theory would
have predicted: read time does not vary significantly between RAM and
flash, but write time sure does.
|
|
|
|
|
|
Watching the pinwheel makes it clear that the painfully slow execution
of test_attribute_bloat_flash_many() isn't a single hidously long
delay anywhere, rather it's a long steady stream of slow operations
and it's the cumulative time that's hurting us. Most likely this is
entirely dominated by flash write time, and suggests that it may be
worth the additional API and implementation complexity to handle
setting a complete set of attributes in a single operation, so that we
only have to pay the flash write toll once.
Will probably require further testing before we can make an informed
decision.
|
|
New test class to thrash the keystore attribute mechanism.
Added wrapper classes to encapsulate the more obscure bits of the
multiple Python public key APIs we're using in a single uniform API,
which lets us simplify some of the tests considerably.
|
|
|
|
|
|
|
|
Incidental minor refactoring of hal_rpc_server_dispatch().
|
|
PKey objects can now be used as context managers, in which case the
key handle will be closed when the block exits.
HSM.pkey_find() now returns a generator which will iterate through the
full set of results, making additional RPC calls as necessary.
NIST ECDSA test vector test refactored to remove duplicated code.
|
|
The debugging code was for tracking down what turned out to be a race
condition in the Alpha's flash driver code (see sw/stm32); much of
this was temporary, and will be removed in a (near) future commit, but
some of the techniques were useful and belong in the repository in
case we need to pull them back for something similar in the future.
hal_ks_index_fsck() attempts to diagnose all the things I found wrong
in the ks_flash index after one long series of errors. As presently
written, it doesn't attempt to fix anything, just diagnose errors: the
intent is that we can call this, before and after every modification
if necessary, to poinpoint exactly which calls introduce errors. Once
things stablize a bit, we may want to crank down the number of calls
to this (it's a bit expensive, since it checks the entire index), and
perhaps add the ability to clean up whatever errors it might find; the
latter might be a good candidate for a CLI command.
|
