On this page
Documentation / Reference
Mechanisms & limits.
The operations implemented by the current firmware, and the details that matter when integrating with other software.
Operation matrix
| Key type | Size / curve | Usage | Operation |
|---|---|---|---|
| AES | 128 / 256 bits | ENCRYPT | AES-GCM encryption and decryption |
| HMAC | 256 / 512 bits | SIGN | HMAC-SHA-256 / SHA-512 creation and verification |
| RSA | 1024 / 2048 / 4096 bits | SIGN | RSA-PSS with SHA-256 |
| RSA | 1024 / 2048 / 4096 bits | ENCRYPT | RSA-OAEP decryption with SHA-1 |
| EC | P-256 / P-384 / P-521 | SIGN | ECDSA with SHA-256 / SHA-384 / SHA-512 |
| EC | P-256 / P-384 / P-521 | DERIVE | ECDH + HKDF-SHA-256 → persistent AES-256 key |
This table describes implementation support, not a test matrix or a recommendation to use every listed key size. Hardware interoperability checks have covered P-256 ECDSA, ECDH/HKDF, and RSA-2048 signing and OAEP decryption. The custom PCB remains pending validation.
AES-GCM
The firmware returns a binary blob with this layout:
nonce (12 bytes) || ciphertext || authentication tag (16 bytes)The firmware handles nonce generation. The current operation does not accept additional authenticated data (AAD). Binary data stays binary in the host library; base64 is a presentation choice used by some applications.
AES and HMAC keys are derived internally with HKDF from an SE-held master established during provisioning. Customer secret key material is not returned to the host.
Signatures and HMAC
RSA signing uses PSS with SHA-256. ECDSA uses the hash associated with the selected NIST curve. The host API accepts a message; the firmware performs hashing and signing.
Preserve signature bytes returned by the firmware. ECDSA integration must account for the actual DER signature encoding; do not silently treat it as fixed-width r || s.
The verify command is for HMAC verification. RSA and ECDSA verification can be performed on the host using an exported public key.
RSA decryption
The installed secure-element backend uses OAEP with SHA-1 for RSA decryption. A peer encrypting for the stick must use compatible OAEP and MGF1 parameters. SHA-256 OAEP is not the current device mechanism.
RSA key generation can be slow. The C header notes roughly 30 seconds for RSA-4096, while the current Rust library has a fixed 10-second USB transaction timeout. Avoid treating that combination as a reliable host workflow until timeout handling is extended.
ECDH followed by HKDF
Provide a local EC DERIVE-key ID and a peer public key on the matching curve, encoded as DER SubjectPublicKeyInfo. The SE051 performs ECDH and HKDF-SHA-256 Extract+Expand internally to create a persistent AES-256 object.
The result contains a key ID, public salt, and info string. A peer needs the exported local public key plus those returned parameters to reproduce the derived AES key. The current info string is enigma/ecdh/aes256/v1; consume the returned value rather than hard-coding it.
Public keys
RSA and EC public-key export uses DER SubjectPublicKeyInfo, encoding value 1. The CLI can convert that to PEM. No private or customer symmetric-key export is exposed.
Transport and scope
The firmware accepts at most 1,024 bytes of incoming payload, including operation fields and length prefixes. This is not a 1,024-byte plaintext allowance. RSA inputs also have algorithm-specific limits.
The protocol has no bulk file-streaming operation. Seal builds a host-side file format around small device operations. General key import/export, backup/wrapping, PKCS#11, and a complete SSH agent are not exposed as finished integrations.