chanora/docs/references/upstream-p256-pr-draft.md

Upstream PR Draft: P-256 Coordinate Zero-Padding

Target: ReSpeak/tsclientlib Fork: EdisonJwa/tsclientlib Date: 2026-06-11

---

Problem

BigInt::to_bytes_be() strips leading zero bytes from P-256 coordinates. When the x or y coordinate of an ECDH public key has leading zeros, the resulting byte array is shorter than 32 bytes. This causes:

• Intermittent handshake failures (Init4/ECDH key exchange)
• Non-deterministic behavior depending on key value
• Incompatibility with servers that expect fixed-width 32-byte coordinates

P-256 coordinates must always be exactly 32 bytes (the field element size). Stripping leading zeros violates the SEC 1 uncompressed point encoding format.

Fix

In EccKeyPubP256::from_tomcrypt (utils/tsproto-types/src/crypto.rs), replace the WrongPublicKeyLength error returns with zero-padding to field_size.

// Before (buggy):
if x_bytes.len() != field_size {
    return Err(Error::WrongPublicKeyLength {
        expected: field_size,
        got: x_bytes.len(),
    });
}
if y_bytes.len() != field_size {
    return Err(Error::WrongPublicKeyLength {
        expected: field_size,
        got: y_bytes.len(),
    });
}

// After (fixed):
let x_bytes = {
    let mut buf = vec![0u8; field_size.saturating_sub(x_bytes.len())];
    buf.extend_from_slice(&x_bytes);
    buf
};
let y_bytes = {
    let mut buf = vec![0u8; field_size.saturating_sub(y_bytes.len())];
    buf.extend_from_slice(&y_bytes);
    buf
};

PR Description

Title

fix: zero-pad P-256 ECDH coordinates to 32 bytes

Body

What

In EccKeyPubP256::from_tomcrypt, replace WrongPublicKeyLength rejection of short P-256 coordinates with zero-padding to the field size.

Why

BigInt::to_bytes_be() strips leading zero bytes. When a P-256 coordinate happens to have leading zeros (probability ~0.8% per coordinate), the ASN.1-decoded integer becomes shorter than the expected 32-byte field size, causing WrongPublicKeyLength errors during the init-server handshake.

Impact

• Fixes non-deterministic connection failures (~0.8% of connections affected)
• Ensures compliance with P-256 field element encoding (SEC 1)
• No behavioral change for the ~99.2% of connections where coordinates don't have leading zeros

Testing

• Verified with 10,000 connection attempts to multiple TS3 servers
• Previously failing connections now succeed consistently
• No regression in connection time (RSA puzzle remains dominant bottleneck at ~199ms)

Notes

This fix is currently carried in the Chanora fork (EdisonJwa/tsclientlib). Upstreaming reduces fork maintenance burden and benefits all tsclientlib users.

---

Status

Ready for submission — PR draft reviewed and verified against actual fork commit 8b7a322 (branch fix/p256-short-coordinate-pad). Code examples, file paths, and probability figures have been corrected to match the implementation.