feat(crypto): allow running without PyCryptodome (for embedded targets)

[cgoudie]

Summary

Add an optional fallback to PyCA's cryptography library for the single AES-128-CTR decryption call in Device.decrypt. Behaviour is unchanged for users who already have PyCryptodome installed; the fallback only kicks in when PyCryptodome is unavailable.

Motivation

On some embedded platforms — most concretely Victron's own Venus OS running on the Cerbo GX, where I've been deploying victron_ble for fleet monitoring — the cryptography package ships with the base image (Victron's own services use it) but PyCryptodome does not, and binary wheels are not published on PyPI for the target architecture (armv7l). Installing PyCryptodome from source requires gcc plus Python development headers, neither of which is present on the device.

Allowing cryptography as a backend lets victron_ble run on these platforms with no native build step at install time.

Implementation

• Both libraries are detected at import time with independent try / except ImportError blocks setting _HAVE_* flags. An explicit ImportError is raised only if neither is available.
• The PyCryptodome decrypt path is preserved verbatim as the reference implementation.
• The cryptography path drives AES-ECB manually and generates the keystream block-by-block from a little-endian-encoded counter. This is necessary because cryptography.modes.CTR follows NIST SP 800-38A and increments big-endian, whereas the Victron Instant Readout protocol uses Counter.new(128, initial_value=iv, little_endian=True) which increments little-endian. The two backends produce byte-identical output when both are installed.
• Device.decrypt now calls the backend-agnostic _aes_ctr_decrypt helper.

requirements.txt is intentionally left untouched — PyCryptodome remains the default install dependency for everyone using pip install victron-ble. Users who would rather avoid PyCryptodome can install with --no-deps and provide cryptography themselves.

If you'd prefer, the next step could be to relax requirements.txt so that PyCryptodome becomes one of two acceptable extras (e.g. pip install victron-ble[pycryptodome] or pip install victron-ble[cryptography]) — but I wanted to keep this PR minimal and let you decide that direction separately.

Tests

Five new tests in tests/test_base.py, written in the existing class-based style:

• test_at_least_one_backend_available — sanity check.
• test_known_vector — captured PyCryptodome output, runs against whichever backend is selected at runtime.
• test_short_ciphertext_padded_to_block — exercises _pkcs7_pad16 for sub-block ciphertexts.
• test_backends_agree_single_block — when both libraries are installed, single-block output is byte-identical.
• test_backends_agree_multi_block — exercises 16 blocks of plaintext, catching any backend that mis-handles counter increments.
• test_backends_agree_across_le_carry — chooses an iv that triggers a low-byte LE carry on the first increment, which would diverge if the cryptography fallback used a big-endian counter.

This last test caught a real bug in my first draft of the patch: a naive cryptography.modes.CTR(nonce=iv.to_bytes(16, "little")) looked correct but disagreed with PyCryptodome past the first block, because cryptography increments big-endian (per NIST) while PyCryptodome with little_endian=True increments low byte first. The block-by-block ECB approach in this PR matches PyCryptodome byte-for-byte, including across the 8-bit and 16-bit carry boundaries.

Local verification

$ make lint
... All done! ✨ 🍰 ✨
$ make test
... ============================== 54 passed in 0.30s ==============================
victron_ble/devices/base.py     223      5    98% coverage

Test plan for reviewers

• CI lint/test passes
• Existing PyCryptodome users see no behaviour change
• pip install --no-deps victron-ble cryptography (no PyCryptodome) — verify decrypt still works
• Decrypt against a known Instant Readout payload with both backends installed and confirm the data matches

Made with Cursor