shield-halvedget_encryption

Derive encryption state from TEE public key using ECDH

Derive encryption state from a TEE public key using ECDH key exchange.

Overview

get_encryption() performs ECDH key exchange between a client private key and the TEE's public key to derive a shared AES-GCM key. It returns an EncryptionState object containing the AES key, client public key, and client private key.

This is a pure computation function with no I/O - it works in both sync and async contexts.

Signature

def get_encryption(
    network_pk: CompressedPublicKey,
    client_sk: PrivateKey | None = None,
) -> EncryptionState

Parameters

Parameter
Type
Required
Description

network_pk

Yes

The TEE's 33-byte compressed secp256k1 public key

client_sk

No

Optional 32-byte client private key. If None, a random ephemeral key is generated

Returns

Type
Description

Fully initialized encryption state with AES key and keypair

Examples

Basic Usage

With Custom Client Key

In Client Factory

Random Ephemeral Key

Verify Key Derivation

How It Works

The function performs three steps:

  1. Generate client key if needed

  2. Derive AES key via ECDH + HKDFarrow-up-right

    This performs:

    • ECDH: Compute shared secret from client_sk and network_pk

    • HKDF: Derive 32-byte AES key from shared secret

  3. Derive client public key

  4. Return EncryptionState

ECDH Key Exchange

The ECDH key exchange works as follows:

The client sends client_pk in the transaction's SeismicElements, allowing the TEE to derive the same AES key and decrypt the calldata.

Random vs Deterministic Keys

Key Type
Pros
Cons

Random ephemeral

No key management needed, fresh key per session

Cannot recreate encryption state, no key persistence

Deterministic

Can recreate same state, key persistence, backup via mnemonic

Requires secure key storage, key management complexity

The SDK defaults to random ephemeral keys for simplicity. Use deterministic keys only if you need to recreate the same encryption state across sessions.

Notes

  • Pure computation - no RPC calls or I/O

  • Works in both sync and async contexts

  • If client_sk is None, generates a cryptographically secure random key via os.urandom(32)

  • The AES key is derived using ECDH + HKDF (NIST SP 800-56C)

  • You rarely need to call this directly unless implementing custom client logic

Security Considerations

  • Random key generation - Uses os.urandom() which is cryptographically secure on all platforms

  • Forward secrecy - Each encryption session can use a different ephemeral key

  • Key storage - If using deterministic keys, store client_sk securely (encrypted at rest, never logged)

  • ECDH security - Based on secp256k1 elliptic curve discrete logarithm problem

  • HKDF - Uses SHA-256 for key derivation

Common Patterns

Ephemeral Session Keys

Persistent Keys

Rotate Keys

See Also

Last updated