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.
|
|
gcc 10 whines about forward references to enums.
gcc 10 correctly dings zero length array variables as illegal.
|
|
in time, at least on this platform) is sometimes overly aggressive about
garbage collecting, including some things that are not garbage. Replace it
with a regular dict, and have RPCIOStream.rpc_input manage both adding and
removing queues.
|
|
|
|
|
|
|
|
out writing 4 bytes into a 1-byte value is probably not a good idea.
So sscanf the string into an array of uint16_t, and copy out the low
bytes. It's a kludge, but the alternatives are worse (e.g. bypass sscanf,
and parse raw bytes).
|
|
PyCrypto is past EOL and we really should move on, but not this close
to a release. Working around the deprecated time.clock function is
sick but appears to be harmless given the way that function is used in
PyCrypto's internal RNG. Would be better just to use os.urandom() but
that would be a much larger change.
In theory, PyCryptodome is a drop-in replacement for PyCrypto which
would solve this problem for us. Unfortunately, it's much less of a
drop-in than its documentation suggests, even before one gets into
Debian and pip disagreeing on what its name should be. Maybe someday,
but not today.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
that talks to that core out of aes_keywrap.c. The HSM will now be built
with just the keywrap core, with no user access to aes or mkmif.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in stm_init, and the checks add unneccesary delays to critical code paths.
|
|
|
|
|
|
|
|
|
|
|
|
over a year ago.
|
|
buffer, because hal_hashsig_sign assembles the signature incrementally,
and will overwrite the digest before it's ready to sign it.
|
|
|
|
just call memcpy here.
(Although it turns out to be more efficient to use an inline version of
memcpy than the library function.)
|
|
|
|
- Add support for null pointer arguments in RPCs for get_digest_algorithm_id
and get_public_key. This is years overdue, and would have obviated the need
for get_public_key_len as a separate RPC.
- Refactor pkey_local_get_public_key_len in terms of pkey_local_get_public_key.
- Add more parameter sanity checks to rpc_api.c.
- Add a len_max parameter to hal_xdr_decode_variable_opaque, rather than
having len be an in/out parameter. This brings xdr slightly more in line
with the rest of the code base (again after literal years), and slightly
simplifies several calls in rpc_client.c.
|
|
- Move hashsig.h contents into hal.h.
- Uppercase lmots and lms algorithm types, because we have a convention
that enum values are uppercase.
- Change all I to hal_uuid_t, because that how we're using them, and it
seems silly to have two different 16-byte array types.
- Change all "memcpy(&this, &that, sizeof(this))" to "this = that",
because it's more succinct, more type-safe, and harder to get wrong.
- Slightly tighten up lmots_generate, lmots_sign, and
lmots_public_key_candidate.
- Remove verbatim draft text, now that I'm pretty sure I implemented it
correctly.
|
|
|
|
|
|
method, and it's missing one or more lmots keys, those keys can be
regenerated.
OTOH, if an lms key is damaged or missing, it's still a fatal error,
because that's the only place we record the current q value.
|
|
|
|
|
|
|
|
This forces each hal_mkmif_* function to alloc/free the core, which is a
miniscule performance hit, but the only sane thing to do in a tasking
environment. Otherwise (with a stored/shared core pointer), one task will
initiate a read, yield in hal_io_wait, another task will initiate a read,
and both will be unhappy.
|
|
|
|
rebuilding the hash tree.
|
|
supports it.
In particular, the version of newlib distributed by Ubuntu is not
configured with --enable-newlib-io-c99-formats, and now includes guard
code that treats %hhx as an error, rather than silently interpreting it as
%hx. The net effect was to break hal_uuid_parse.
(Ironically, vfprintf.c does not (yet) include this guard code, but it's
probably only a matter of time, and it seemed expedient to change
hal_uuid_format at the same time.)
|
|
Found when upgrading Ubuntu to 18.10.
|