# Upstream PR Draft: P-256 Coordinate Zero-Padding

**Target:** [ReSpeak/tsclientlib](https://github.com/ReSpeak/tsclientlib)
**Fork:** [EdisonJwa/tsclientlib](https://github.com/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`.

```rust
// 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.