Seal v0.1 is a JWT/JWS library, not an encryption library.
JWT headers and payloads are base64url encoded, not encrypted. Anyone holding a token can decode and read its claims.
decode() does not verify signatures. Use verify() before trusting any value from a token.
HS256 uses one shared secret for signing and verification. If the secret is weak, leaked, or extracted, attackers can forge valid tokens.
Use high-entropy secrets and rotate them when compromise is possible.
Secrets stored in firmware can be extracted when physical compromise is in scope. Seal can validate token integrity, but it cannot protect a secret that is available to an attacker through device extraction.
exp, nbf, and maxAgeSeconds validation require a valid epoch clock. If time is required and unavailable, Seal returns SealCode::ClockUnavailable.
exp is expired at the exact expiration timestamp when clock tolerance is zero. nbf and maxAgeSeconds use the configured clockToleranceSeconds without additive timestamp overflow.
Seal requires alg to be exactly HS256. The typ header is ignored by default, so tokens from issuers that use different typ casing or values can still verify when the algorithm, signature, JSON payload, and claims are valid.
Production v0.1 crypto uses mbedTLS behind SealCrypto.h. This boundary exists so the backend can be replaced later without changing the public Seal API.