Skip to content

fix(pcapng): a short ZigBee key in a Decryption Secrets Block rebuilds at full width #1986

Closed

Description

@JarryShaw

A Decryption Secrets Block (DSB) holding a ZigBee NWK or APS key shorter than its fixed width parses fine, but rebuilds at full width. The rebuilt bytes differ from the original. Under the rule that every round trip must match, this is a defect.

  • Repro (on main): build a DSB of type 0x5A4E574B (ZigBee NWK) with secrets_length=10 and 10 key octets, parse it, then call PCAPNG.from_data(parsed.info, ...).
  • Result: a 40-octet block in place of the original 32, with secrets_length=18 and the key zero-padded.
  • Cause: the ZigBee key schema has a fixed width. The make path pads to that width and does not keep the declared length.

Fix: a short key must rebuild byte-exact. Either keep the declared length and the held octets on make, or reject the short key on parse with a warning, consistently in both directions.

Found while reviewing #1983 (#1980).

Activity

  1. added
    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)
    fixPull requests that fix a defect (fix: subject prefix)
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 20, 2026
  2. JarryShaw commented on Oct 20, 2026

    @JarryShaw
    OwnerAuthor

    Blocked until #1983 merges, because the fix touches the same DSB build and schema code.

  3. moved this to Blocked in PyPCAPKiton Oct 20, 2026
  4. JarryShaw commented on Oct 20, 2026

    @JarryShaw
    OwnerAuthor

    #1983 has merged. This now waits on #1985's fix, which edits the same DSB data models and _make_block_dsb. It stays blocked until that PR merges.

  5. JarryShaw commented on Oct 20, 2026

    @JarryShaw
    OwnerAuthor

    #1989 has merged, so this is unblocked. A worker has started: a short ZigBee key will rebuild byte-exact, in both the parse and make directions.

  6. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Oct 20, 2026
  7. moved this from Blocked to WIP in PyPCAPKiton Oct 20, 2026
  8. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Oct 21, 2026
  9. added this to the PyPCAPKit v1.5 milestone on Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugIssues reporting a defect (set by the bug report template; a default, not an assessment)fixPull requests that fix a defect (fix: subject prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions