Summary

Add base support for keys, including AES and EC keys.

Review Request #15168 — Created July 14, 2026 and updated July 16, 2026, 4:50 p.m.

Information

Owner

chipx86

Repository

cryptozoology

Branch

master

Bugs

Depends On

15172, 15170

Reviewers

Groups

beanbag-misc

People

Description

This introduces a foundation for encryption/signing keys, with specific

implementations for AES symmetric keys and EC public/private keys.
All keys derive from BaseKey, which can be deserialized from bytes or

serialized to bytes, can optionally perform encryption/decryption and

key wrapping/unwrapping, and has a SHA256 fingerprint and optional key

ID.
There are subclasses for bytes-based keys and for public/private keys.
AES keys are a bytes-based key. They can be generated for a supported

key size, can be derived from another key, or derived from a key

exchange. They support CFB8, GCM, and GCM-SIV modes.
EC public/private key pairs support ECDH key exchange.
Keys can be invalidated, which will clear out state on the key. While

optional, keys should be used as a context manager, which will

automatically invalidate the key once the context manager exits. This is

a precaution to keep key material in memory for as little time as

possible.
All bytes storage for key material is done using bytearrays. These can

be cleared out, affecting all holders of the state. This can help

prevent keys from accidentally staying around in memory long-term (as

best as can be prevented in Python).
Encryption returns a a representation of the encrypted state, providing

a full resulting ciphertext and the component parts. Key wrapping does

similar. This will be used to help with secrets storage and defining

envelopes (in a future change).
All crypto operations take an algorithm, which are standardized. Keys

can indicate their support for different algorithms (which will be used

for secrets management later), validate against them when performing

the operation, and select the appropriate parameters for the operation.
An upcoming change will build upon this to provide higher-level

operations for secrets storage and key type registries, managing

envelope creation and parsing.

Testing Done

Unit tests pass.

Commits

Summary	ID
Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	24628ad7fee460bf2460c6b1d8bbbc7ea11f979c

Summary

Add base support for keys, including AES and EC keys.

This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.

24628ad7fee460bf2460c6b1d8bbbc7ea11f979c

Issues

Description	From	Last Updated
Can we add a round-trip test for each supported algorithm that encrypts with a random nonce and decrypts back to …	david	July 15, 2026, 8:44 a.m.
'cryptozoology.keys.aes.AESKey' imported but unused Column: 1 Error code: F401	reviewbot	July 14, 2026, 3:27 a.m.
'cryptozoology.keys.ec.ECPrivateKey' imported but unused Column: 1 Error code: F401	reviewbot	July 14, 2026, 3:27 a.m.
'cryptozoology.keys.ec.ECPublicKey' imported but unused Column: 1 Error code: F401	reviewbot	July 14, 2026, 3:27 a.m.
blank line at end of file Column: 1 Error code: W391	reviewbot	July 14, 2026, 3:27 a.m.
local variable 'e' is assigned to but never used Column: 9 Error code: F841	reviewbot	July 14, 2026, 3:27 a.m.
This is the only one of these that doesn't inherit from CryptozoologyError. Should we use that here so callers can …	david	July 15, 2026, 3:56 p.m.
This should fit on one line.	david	July 16, 2026, 4:50 p.m.
Typo: bibts -> bits	david	July 15, 2026, 3:56 p.m.
If this isn't passed in, we generate a salt and then discard it (only the key gets returned), making it …	david	July 15, 2026, 4:20 p.m.
Do we want to raise ... from e?	david	July 15, 2026, 4:20 p.m.
Can we recommend in here that callers not use this parameter and keep it reserved for unit tests? If the …	david	July 15, 2026, 4:36 p.m.
With a malformed input, we could get a ValueError. Should we catch that as well to turn it into a …	david	July 16, 2026, 4:25 p.m.
Typo: alt -> alg	david	July 15, 2026, 4:45 p.m.
Can we wrap as: from cryptozoology.utils.invalidation import ( InvalidatableMixin, SensitiveBytes, )	david	July 16, 2026, 4:50 p.m.
Seems like this got truncated.	david	July 15, 2026, 4:45 p.m.
This is returning the internal mutable bytearray. Can we return a copy instead?	david	July 15, 2026, 4:46 p.m.
The standard term is "Elliptic Curve", not "Elliptical Curve". Several throughout the change.	david	July 15, 2026, 4:47 p.m.
The registry isn't part of this change so I can't tell, but this key is duplicated on both ECPublicKey and …	david	July 15, 2026, 4:48 p.m.
Do we want to raise ... from e?	david	July 15, 2026, 4:48 p.m.
Since this is greenfield, can we use pytest test cases and real docstrings instead of a UnitTest subclass? Same for …	david	July 15, 2026, 4:52 p.m.
This docstring doesn't seem to match the function name.	david	July 15, 2026, 4:48 p.m.
This seems like a copy from the test just below. This is hitting the expected error before that triggers, but …	david	July 15, 2026, 4:48 p.m.
There aren't any tests for the methods in this file. Since they sit on the crypto path, it would be …	david	July 15, 2026, 4:51 p.m.
'cryptozoology.utils.random.generate_aes_salt' imported but unused Column: 1 Error code: F401	reviewbot	July 16, 2026, 4:27 p.m.
redefinition of unused 'BytesLike' from line 67 Column: 5 Error code: F811	reviewbot	July 16, 2026, 4:27 p.m.
'typing.TypeAlias' imported but unused Column: 5 Error code: F401	reviewbot	July 16, 2026, 4:27 p.m.

flake8 failed.

JSHint passed.

flake8

cryptozoology/keys/__init__.py (Diff revision 1)
The issue has been resolved. Show all issues
```
'cryptozoology.keys.aes.AESKey' imported but unused

Column: 1
Error code: F401
```

cryptozoology/keys/__init__.py (Diff revision 1)

The issue has been resolved. Show all issues

'cryptozoology.keys.ec.ECPrivateKey' imported but unused

Column: 1
Error code: F401

cryptozoology/keys/__init__.py (Diff revision 1)

The issue has been resolved. Show all issues

'cryptozoology.keys.ec.ECPublicKey' imported but unused

Column: 1
Error code: F401

cryptozoology/keys/__init__.py (Diff revision 1)
The issue has been resolved. Show all issues
```
blank line at end of file

Column: 1
Error code: W391
```
cryptozoology/keys/aes.py (Diff revision 1)
The issue has been resolved. Show all issues
```
local variable 'e' is assigned to but never used

Column: 9
Error code: F841
```

Change Summary:


Fleshed out the cryptozoology.base module.
Removed an unused variable.

Commits:

	Summary	ID
	Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	a88b39f4db40ab39258ad6b6b3ea873fc3672ca7
	Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	6122b473b03b2d05890b3456b28b90daf2ce2892

Diff:

Revision 2 (+8330)

Show changes

	cryptozoology/errors.py
	cryptozoology/keys/__init__.py
	cryptozoology/keys/aes.py
	cryptozoology/keys/base.py
	cryptozoology/keys/ec.py
	cryptozoology/keys/tests/__init__.py
	cryptozoology/keys/tests/test_aes_key.py
	cryptozoology/keys/tests/test_base.py
	5 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:

Updated to use InvalidatableMixin.

Commits:

	Summary	ID
	Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	6122b473b03b2d05890b3456b28b90daf2ce2892
	Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	a2af5cad3f78c8ff07335d2a71ed2cda1c7da1f3

Depends On:

15170 - Add a common mixin class for handling invalidation.

Diff:

Revision 3 (+8320)

Show changes

	cryptozoology/errors.py
	cryptozoology/keys/__init__.py
	cryptozoology/keys/aes.py
	cryptozoology/keys/base.py
	cryptozoology/keys/ec.py
	cryptozoology/keys/tests/__init__.py
	cryptozoology/keys/tests/test_aes_key.py
	cryptozoology/keys/tests/test_base.py
	5 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Fix it!

An issue was opened. Show all issues

Can we add a round-trip test for each supported algorithm that encrypts with a random nonce and decrypts back to plaintext?

chipx86

July 15, 2026, 4:54 p.m.

We effectively have that. It's the same encrypted payloads being used for the decryption tests. I didn't think it'd be worth duplicating all that.

cryptozoology/errors.py (Diff revision 3)

The issue has been resolved. Show all issues

This is the only one of these that doesn't inherit from CryptozoologyError. Should we use that here so callers can just catch that one thing?

chipx86

July 15, 2026, 4:54 p.m.
```
Yep, not sure how I missed that.
```

cryptozoology/keys/aes.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Typo: bibts -> bits
```

cryptozoology/keys/aes.py (Diff revision 3)

The issue has been resolved. Show all issues

If this isn't passed in, we generate a salt and then discard it (only the key gets returned), making it so the derived key can never be reproduced. This means data encrypted with this key could never be decrypted.
We should either require that the salt be passed in, or return it along with the key so the caller can save it. I'd lean towards requiring it.

Same with the derive_from_key_exchange API.

chipx86

July 15, 2026, 4:54 p.m.
```
Yeah, agreed.
```

cryptozoology/keys/aes.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Do we want to raise ... from e?
```

cryptozoology/keys/aes.py (Diff revision 3)

The issue has been resolved. Show all issues

Can we recommend in here that callers not use this parameter and keep it reserved for unit tests? If the nonce isn't properly random, it's Very Bad™ for GCM and CFB8.
Even better would be for this public method to not have the parameter, and delegate (mostly) to a private method that we can use for the tests.

chipx86

July 15, 2026, 4:54 p.m.

Going to keep it as an option because it's useful during ECIES (basically, letting a unit test pass it in there and then it passes it in here), but I'll change the documentation around it.

cryptozoology/keys/aes.py (Diff revision 3)

The issue has been resolved. Show all issues

With a malformed input, we could get a ValueError. Should we catch that as well to turn it into a DecryptionError?

chipx86

July 15, 2026, 4:54 p.m.

I haven't been able to get a ValueError out of this. Got a repro case?

david

July 16, 2026, 9:07 a.m.

I think you should be able to get it with ciphertext that's shorter than 16 bytes.

cryptozoology/keys/aes.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Typo: alt -> alg
```
cryptozoology/keys/base.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Seems like this got truncated.
```

cryptozoology/keys/base.py (Diff revision 3)

The issue has been dropped. Show all issues

This is returning the internal mutable bytearray. Can we return a copy instead?

chipx86

July 15, 2026, 4:54 p.m.

No, the internal one is correct. The goal is to actively avoid copies of sensitive data. I plan to remove the mutability aspect but as later work.

cryptozoology/keys/ec.py (Diff revision 3)

The issue has been resolved. Show all issues

The standard term is "Elliptic Curve", not "Elliptical Curve". Several throughout the change.

chipx86

July 15, 2026, 4:54 p.m.

You know what's funny? I had Elliptic Curve everywhere, and then changed it at like 3AM because I thought I had it backwards in that moment.

cryptozoology/keys/ec.py (Diff revision 3)

The issue has been dropped. Show all issues

The registry isn't part of this change so I can't tell, but this key is duplicated on both ECPublicKey and ECPrivateKey. Is that ok?

chipx86

July 15, 2026, 4:54 p.m.

Yeah, that's okay. Only the private keys will end up registered, but this is ensuring that either key will map to the type of key (regardless of public/private) being used.

cryptozoology/keys/ec.py (Diff revision 3)
The issue has been resolved. Show all issues
```
Do we want to raise ... from e?
```
cryptozoology/keys/tests/test_aes_key.py (Diff revision 3)
The issue has been resolved. Show all issues
```
This docstring doesn't seem to match the function name.
```

cryptozoology/keys/tests/test_aes_key.py (Diff revision 3)

The issue has been resolved. Show all issues

This seems like a copy from the test just below. This is hitting the expected error before that triggers, but can we change this to be AES-256-GCM just to keep it so the only "incorrect" thing about this is the key?

chipx86

July 15, 2026, 4:54 p.m.

I think you commented on the wrong test. I assume you mean the unsupported algorithm vs. key size? They should be separate, but where I had messed up was a change to move to constants for the key bytes coming in. I'll fix that up. One test is indeed meant to choose an unsupported algorithm, the other a supported but with wrong key size.

david

July 16, 2026, 9:07 a.m.

This is in the test about invalidated keys, but this algorithm doesn't exist. Would be good to have a correct algorithm name for this test.

chipx86

July 16, 2026, 4:27 p.m.
```
Ahhh I see.
```

cryptozoology/utils/encoding.py (Diff revision 3)

The issue has been resolved. Show all issues

There aren't any tests for the methods in this file. Since they sit on the crypto path, it would be nice to have (especially the padding calc in b64u_decode)

chipx86

July 15, 2026, 4:54 p.m.

I had initially intended to fold those into a separate commit. I do have unit tests for those, so I'll pull this out and rebase on top of that.

cryptozoology/keys/tests/test_aes_key.py (Diff revision 3)

The issue has been dropped. Show all issues

Since this is greenfield, can we use pytest test cases and real docstrings instead of a UnitTest subclass? Same for the other test files here.

chipx86

July 15, 2026, 4:54 p.m.

I started with that, but moved away from it. I intentionally want to keep all this unittest. Class-level test setup/teardown, class-namespaced tests, and the flexibility with mixins are very helpful here and for upcoming work.

Depends On:: 15172 - Add a class for storing sensitive bytes.

Change Summary:


Moved the utils code out of this change.
An explicit salt is now required for key derivation and exchange.
Documentation for encrypt() now has strong guidance on randomly-generating nonces.
Fixed DecryptionError to inherit from CryptozoologyError.
Fixed error handling (and a test) when a ciphertext is truncated.
Some exceptions now raise .. from e.
Fixed several typos.

Commits:

	Summary	ID
	Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	a2af5cad3f78c8ff07335d2a71ed2cda1c7da1f3
	Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	4600299fef0f9eba6b51d0f8cefc777a6c582b4d

Diff:

Revision 4 (+8004)

Show changes

	cryptozoology/errors.py
	cryptozoology/keys/__init__.py
	cryptozoology/keys/aes.py
	cryptozoology/keys/base.py
	cryptozoology/keys/ec.py
	cryptozoology/keys/tests/__init__.py
	cryptozoology/keys/tests/test_aes_key.py
	cryptozoology/keys/tests/test_base.py
	2 more

Checks run (1 failed, 1 succeeded)

flake8 failed.

JSHint passed.

flake8

cryptozoology/keys/aes.py (Diff revision 4)

The issue has been resolved. Show all issues

'cryptozoology.utils.random.generate_aes_salt' imported but unused

Column: 1
Error code: F401

cryptozoology/keys/aes.py (Diff revision 4)
The issue has been resolved. Show all issues
```
redefinition of unused 'BytesLike' from line 67

Column: 5
Error code: F811
```
cryptozoology/keys/base.py (Diff revision 4)
The issue has been resolved. Show all issues
```
'typing.TypeAlias' imported but unused

Column: 5
Error code: F401
```

Change Summary:

Removes unused/duplicate imports.

Also missed in the previous update:

Removed KeyBytesLike in favor of the centralized BytesLike.
Used SensitiveBytes for storage and sensitive results to support invalidation.
More functions take a BytesLike instead of just bytes.

Commits:

	Summary	ID
	Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	4600299fef0f9eba6b51d0f8cefc777a6c582b4d
	Add base support for keys, including AES and EC keys. This introduces a foundation for encryption/signing keys, with specific implementations for AES symmetric keys and EC public/private keys. All keys derive from `BaseKey`, which can be deserialized from bytes or serialized to bytes, can optionally perform encryption/decryption and key wrapping/unwrapping, and has a SHA256 fingerprint and optional key ID. There are subclasses for bytes-based keys and for public/private keys. AES keys are a bytes-based key. They can be generated for a supported key size, can be derived from another key, or derived from a key exchange. They support CFB8, GCM, and GCM-SIV modes. EC public/private key pairs support ECDH key exchange. Keys can be invalidated, which will clear out state on the key. While optional, keys should be used as a context manager, which will automatically invalidate the key once the context manager exits. This is a precaution to keep key material in memory for as little time as possible. All bytes storage for key material is done using `bytearray`s. These can be cleared out, affecting all holders of the state. This can help prevent keys from accidentally staying around in memory long-term (as best as can be prevented in Python). Encryption returns a a representation of the encrypted state, providing a full resulting ciphertext and the component parts. Key wrapping does similar. This will be used to help with secrets storage and defining envelopes (in a future change). All crypto operations take an algorithm, which are standardized. Keys can indicate their support for different algorithms (which will be used for secrets management later), validate against them when performing the operation, and select the appropriate parameters for the operation. An upcoming change will build upon this to provide higher-level operations for secrets storage and key type registries, managing envelope creation and parsing.	24628ad7fee460bf2460c6b1d8bbbc7ea11f979c

Diff:

Revision 5 (+8002)

Show changes

	cryptozoology/errors.py
	cryptozoology/keys/__init__.py
	cryptozoology/keys/aes.py
	cryptozoology/keys/base.py
	cryptozoology/keys/ec.py
	cryptozoology/keys/tests/__init__.py
	cryptozoology/keys/tests/test_aes_key.py
	cryptozoology/keys/tests/test_base.py
	2 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it! Fix it!

cryptozoology/keys/aes.py (Diff revisions 3 - 5)
An issue was opened. Show all issues
```
This should fit on one line.
```

cryptozoology/keys/base.py (Diff revisions 3 - 5)

An issue was opened. Show all issues

Can we wrap as:

from cryptozoology.utils.invalidation import (
    InvalidatableMixin,
    SensitiveBytes,
)