Invalid EC key

[ssw112]

Related to #37 but a distinct bug, only visible once #37’s padding fix (or an
equivalent) is applied.

Environment: Python 3.14, firebase-messaging @ main
(dc5acc3), Home Assistant 2026.4.2,
ring-doorbell 0.9.x, Ring Intercom.

What I saw: after locally patching _decrypt_raw_data to pad crypto_key_str/salt_str before decoding (same fix as #37), the padding crash went away, but the listener started dying instead with:

ERROR [firebase_messaging.fcmpushclient] Unknown error: Invalid EC key., shutting down FcmPushClient.
File ".../fcmpushclient.py", line ..., in _handle_data_message
File ".../fcmpushclient.py", line ..., in _decrypt_raw_data
File ".../http_ece/init.py", line ..., in derive_dh
pubkey = ec.EllipticCurvePublicKey.from_encoded_point(ec.SECP256R1(), dh)
ValueError: Invalid EC key.
Root cause: _handle_data_message does:

crypto_key = self._app_data_by_key(msg, "crypto-key")[3:] # strip dh=salt = self._app_data_by_key(msg, "encryption")[5:] # strip salt=
This unconditionally slices off the first 3/5 characters assuming the header value always literally starts with dh=/salt=. When it doesn’t, the slice removes real key bytes instead of a label, producing corrupted data instead of a clean error. This is why it’s easy to miss: the corrupted string is usually also the wrong base64 length, so it dies on Incorrect padding first (the bug #37 already fixes) — you only reach this second bug once padding is no longer the first thing to fail.

Suggested fix:
crypto_key = self._app_data_by_key(msg, "crypto-key").removeprefix("dh=")
salt = self._app_data_by_key(msg, "encryption").removeprefix("salt=")

Plus, independent of the above, wrapping the decrypt+callback portion of _handle_data_message in try/except Exception (log + skip that one message) rather than letting any exception propagate and tear down the whole FcmPushClient — same spirit as #37’s per-message isolation, just covering this path too since it’s easy for some malformed/unexpected message to slip through whatever validation exists today.

Running both changes live against a real Ring Intercom for 3 days with zero full-listener crashes since.

[gentslava]

Hit the same Invalid EC key. on a different downstream (a Home Assistant custom integration for a Russian intercom operator), and captured the header that causes it. The diagnosis here is close but the suggested fix does not cover it.

A diagnostic probe on the live install logged the shapes — lengths and parameter names only, no key material:

crypto-key: len=189 shape=dh=87, p256ecdsa=87
encryption: len=29  shape=salt=24

So the header does start with dh=. What breaks it is that it does not end there: the operator started signing pushes with VAPID, so crypto-key is a two-parameter list — dh=<87>; p256ecdsa=<87>. Crypto-Key and Encryption are ;-separated parameter lists (RFC 8188 §2.1, RFC 8291 §4), and the parameter order is not fixed.

That means removeprefix("dh=") behaves exactly like the current [3:] on this input: the label goes away, but ; p256ecdsa=<87> stays attached to the value. urlsafe_b64decode then silently discards ;, the space and the label characters and decodes the whole thing to 137 bytes, where a P-256 point needs 65 — hence from_encoded_point rejecting it.

Two more details from the capture:

• dh arrives unpadded (87 chars) while salt arrives padded (24 chars). So Harden encrypted push payload decoding #37's padding fix alone turns binascii.Error: Incorrect padding into Invalid EC key. — which matches what you saw after applying it locally. dh only decodes once it is separated from the VAPID parameter.
• Not a regression in this library: _decrypt_raw_data is byte-identical across 0.4.0–0.4.5, and the same code decrypted 16 of that operator's pushes two months earlier, back when crypto-key carried only dh.

Opened #43 with a fix that selects the parameter by name (so order does not matter) and restores the padding. Your second suggestion — isolating the decrypt so one bad message cannot take the listener down — is worth having regardless; #37 does that for the decrypt path.