Type Safety: TFHEType and TKMSType use any for all properties

[evmparser]

Type Safety: TFHEType and TKMSType Use 'any' for All Properties

Files: src/tfheType.ts & src/tkmsType.ts

Description

The core type definitions TFHEType and TKMSType use any for all their properties, completely negating TypeScript's type-checking benefits for the most critical cryptographic objects in the SDK. This is a fundamental design issue that undermines type safety throughout the entire codebase.

Impact

• No type checking: Operations on encrypted data have no compile-time validation
• Critical objects untyped: The most important types in an FHE SDK lack proper type definitions
• Cascading type issues: Using any in core types spreads type unsafety throughout the codebase
• No IntelliSense: Developers get no autocomplete or hints when working with encrypted values
• Runtime errors: Type mismatches in cryptographic operations only discovered at runtime
• Difficult debugging: Without proper types, tracking down issues becomes much harder
• Poor developer experience: Using the SDK feels like working with plain JavaScript
• Increased bug risk: More likely to pass wrong data types to encryption/decryption functions

Current Implementation

// src/tfheType.ts
export interface TFHEType {
  handles: any;
  ciphertexts: any;
  publicKeys: any;
  metadata: any;
  // ... all properties use 'any'
}

// src/tkmsType.ts
export interface TKMSType {
  keys: any;
  parameters: any;
  operations: any;
  // ... all properties use 'any'
}

This defeats the entire purpose of using TypeScript for a cryptographic SDK.

Suggested Fix

Define proper, specific types for all properties:

Option 1: Strong Type Definitions

// src/tfheType.ts
export type Handle = string; // Or more specific type
export type CiphertextId = string;

export interface Ciphertext {
  handle: Handle;
  type: 'uint8' | 'uint16' | 'uint32' | 'uint64' | 'uint128' | 'uint256' | 'address' | 'bool';
  data: Uint8Array;
}

export interface PublicKey {
  key: Uint8Array;
  serialized: string;
}

export interface TFHEType {
  handles: Map<Handle, Ciphertext>;
  ciphertexts: Map<CiphertextId, Uint8Array>;
  publicKeys: Map<string, PublicKey>;
  metadata: {
    version: string;
    chainId: number;
    contractAddress?: string;
  };
}

Option 2: Type Parameters for Flexibility

// src/tfheType.ts
export interface TFHEType<T = unknown> {
  handles: Record<string, CiphertextHandle>;
  ciphertexts: Map<string, EncryptedValue<T>>;
  publicKeys: ReadonlyArray<PublicKeyInfo>;
  metadata: FHEMetadata;
}

export interface CiphertextHandle {
  id: string;
  type: FHEDataType;
}

export type FHEDataType = 
  | 'uint8' 
  | 'uint16' 
  | 'uint32' 
  | 'uint64' 
  | 'uint128' 
  | 'uint256' 
  | 'bool' 
  | 'address';

Option 3: Gradual Type Improvement

// Start with basic structure, improve over time
// src/tkmsType.ts
export interface TKMSType {
  keys: Record<string, KeyInfo>;
  parameters: EncryptionParameters;
  operations: readonly Operation[];
}

export interface KeyInfo {
  id: string;
  type: 'public' | 'private' | 'signing';
  data: Uint8Array;
}

export interface EncryptionParameters {
  securityLevel: number;
  plaintextModulus?: bigint;
  polyModulusDegree?: number;
}

export interface Operation {
  type: 'encrypt' | 'decrypt' | 'reencrypt';
  timestamp: number;
  status: 'pending' | 'completed' | 'failed';
}

Benefits

• Type safety: Catch errors at compile-time, not runtime
• Better IDE support: Full autocomplete and IntelliSense throughout the codebase
• Self-documenting code: Types serve as inline documentation
• Easier refactoring: TypeScript can help track all usages when making changes
• Prevent bugs: Invalid operations caught before code runs
• Professional quality: Demonstrates commitment to code quality and safety
• Better onboarding: New developers understand the API through types

Implementation Steps

1. Audit all usage of TFHEType and TKMSType throughout the codebase
2. Document what each property actually contains and its structure
3. Create proper TypeScript interfaces for each property
4. Update function signatures to use the new types
5. Fix any type errors that surface (they're bugs waiting to happen!)
6. Add JSDoc comments to explain complex types
7. Update documentation and examples to reflect typed API

Migration Path

This can be done gradually without breaking changes:

1. Define new types alongside existing any types
2. Mark old types as @deprecated
3. Update internal code to use new types
4. Provide migration guide for users
5. Remove deprecated types in next major version

Labels

• enhancement
• type-safety
• critical
• developer-experience

---

This issue is part of a comprehensive security audit of the relayer-sdk codebase.