Keys in Secryn represent immutable cryptographic assets used for signing, encryption, authentication, and secure system access. Keys are created once and cannot be edited after creation. This immutability ensures cryptographic integrity and prevents accidental or unauthorized changes.

Every key belongs to a vault. People using the web interface are checked against project membership, vault access rules, and user roles. Generated and uploaded private keys are stored in a SECRYN-PRIVATE-V1 envelope encrypted with APP_KEY. Existing installs encrypt older plaintext files with php artisan vault:encrypt-private-material. See the security model.

What Keys Are Used For

Keys are commonly used for:

• encryption or signing in your own applications
• service-to-service authentication
• SSH access
• infrastructure and automation workflows
• secure distribution of cryptographic material

Secryn stores and distributes keys safely—it does not mutate or regenerate keys after creation.

Supported Key Types

• RSA
• Elliptic Curve (EC)
• Ed25519 (EdDSA)

SSH-compatible formats are supported via output format selection rather than separate key types.

Creating Keys

You can either generate a new key in Secryn or upload an existing key (PEM/PKCS). When generating a key, you choose:

• key type and size
• output format
• activation and expiration times
• optional tags and visibility settings

Once saved, the key configuration is locked and cannot be modified.

Key Immutability

Keys cannot be edited or versioned. If a key needs to change, rotate, or be replaced, create a new key and disable or expire the old one. The original data remains unchanged for audit consistency, enforcing explicit rotation workflows.

Output Formats

• Standard (PEM) for general cryptographic use
• SSH (OpenSSH) for SSH-compatible workflows
• Both when working across mixed environments

Format selection controls how the key material is generated and downloaded.

Activation, Expiration, and State

Each key supports lifecycle controls:

• activation time – when the key becomes usable
• expiration time – when the key should no longer be used
• enabled/disabled toggle – temporarily disable usage without deleting the key

Disabling a key preserves history and does not remove it from the vault.

Visibility and Public Access

Keys can optionally be marked public. Public access uses a resource-specific bearer token on GET /api/v1/keys/{key_id}. It does not use the vault access key, and the link does not work with no credential. The response is public material only. It never includes the private key. The vault access key can still download the private key.

Use public visibility only when an external system must fetch that public material. If a public link for this key was enabled before private keys were kept off public responses, rotate the key. Anyone who called the old link may still have the private key.

Tags and Organization

Attach tags to help identify services, environments, or compliance classifications. Tags improve discoverability but do not affect access control.

Permissions and Access Control

Key access depends on:

1. project membership
2. vault access (including restricted vault rules)
3. user role

Depending on role, users may create keys, download them, disable or expire them, or view metadata only.

Best Practices

• treat keys as immutable and disposable
• rotate keys by creating new ones, never editing existing keys
• apply expiration dates whenever possible
• disable keys instead of deleting them abruptly
• store sensitive keys in restricted vaults
• avoid public visibility unless absolutely required

Keys are intentionally rigid in Secryn. This immutability and explicit lifecycle model reduces risk, improves auditability, and encourages safe cryptographic practices across teams and infrastructure.