fix(sdk-lib-mpc): replace date:null with tolerance window in OpenPGP calls

[zahin-mohammad]

Summary

Fixes the date: null → tolerance window migration in OpenPGP comms layer. The original change (date: now + 24h) was stricter than default, not more tolerant — it required keys to be valid for 24 more hours instead of tolerating recently-expired keys.

What changed

• encrypt/decrypt: Removed date override entirely (uses default = current time). Normal key expiry and self-signature validation.
• verify: Kept date: now + 24h. Tolerates signatures from OVC devices whose clocks are up to 24h ahead.

Why not now - 24h for encrypt?

OpenPGP's date parameter shifts the reference time for ALL temporal checks simultaneously. Using now - 24h tolerates expired keys but breaks self-signature validation on any key created within the last 24h ("Signature creation time is in the future").

Impact on client SDK with clock skew

Clock ahead (e.g. +4h): Signature verification on the server works fine. But when the client SDK encrypts a message to the server's HSM key, it checks key validity using its wrong clock. If the HSM key expires in 3 hours (real time), the client thinks it expired 1 hour ago → encrypt fails unnecessarily.

Clock behind (e.g. -4h): Everything works fine. Signatures appear slightly old (no problem). Keys appear to have more time left (no problem).

Failure scenarios compared to date: null

1. Server's HSM key is expired → pgp.encrypt rejects it. Client cannot send messages to the server. This is the intended security improvement.
2. Server's HSM key is still valid, but client clock is ahead by more than the key's remaining lifetime → pgp.encrypt rejects it. Unintended collateral — previously tolerated by date: null.
3. A signature is timestamped more than 24h in the future relative to the verifier → pgp.verify rejects it. Practically impossible since the server's clock is correct.

Test plan

• Existing encrypt/decrypt/verify round-trip tests pass
• Existing DKG ceremony tests pass
• New test: expired key is rejected for encryption
• New test: signature from a clock 12h ahead is accepted (within tolerance)
• New test: signature from a clock 25h ahead is rejected (beyond tolerance)

Ticket: WAL-379

🤖 Generated with Claude Code

[linear]

WAL-379 [Security] OpenPGP date: null Disables Signature Expiry — Enables Protocol Message Replay

[Logicwax]

our silencelabs DKLS23 protocol should be tolerant of re-play attacks. and we had issues with this affecting customers before due to clock skew. how about we compromise in the middle and make it like 24 hours? that way it shows we considered this (for future audits), but also enough slack for customers with terrible clocks.