Security principles

Security with fewer assumptions.

Giblex products are designed around a small number of security principles that guide every system decision.

These principles exist to reduce unnecessary trust assumptions and keep control as close to the user as possible.

View architecture Read threat model

Local-first by default

Sensitive data should remain on systems users control whenever possible.

Possession as a boundary

Trusted device presence can become part of the access path.

Fewer trusted systems

Security improves when fewer external systems must be trusted.

Explicit models

Users should understand what access depends on.

Local-First by Default

Sensitive data should remain on systems users control whenever possible.

Rather than storing encrypted data on remote infrastructure by default, Phantom systems prioritise local storage and local enforcement of security conditions.

Remote systems may assist with distribution or updates, but they are not placed at the centre of sensitive workflows.

Possession as a Security Boundary

Digital authentication alone is often insufficient for protecting sensitive systems.

Phantom products can incorporate physical device presence into the access path, meaning sensitive environments can require a trusted hardware device before access is granted.

This creates a real-world boundary around digital access.

Minimise Trusted Systems

Security improves when fewer systems must be trusted.

Remote authentication services
Cloud storage providers
Third-party infrastructure
External identity systems

Model clarity

Explicit security models

Security systems should be understandable.

What conditions unlock data
What components participate in access
What must be present for access to succeed

Clear models create predictable security behaviour.

Composability

Composable security tools

Each Phantom product is designed to function independently but integrate cleanly with other Phantom systems.

This allows users to build security environments appropriate for their needs without requiring an all-or-nothing system.

Implementation Detail

Representative security model snippets

The principles page should still show concrete examples of how the security model is enforced in code.

// AES-GCM encryption with authenticated data
// Vault data remains encrypted until unlock conditions are met

private static byte[] EncryptWithAesGcm(
    AesGcm aes,
    byte[] nonce,
    byte[] aad,
    byte[] plain)
{
    var tag = new byte[16];
    var ct = new byte[plain.Length];

    aes.Encrypt(nonce, plain, ct, tag, aad);

    var result = new byte[ct.Length + tag.Length];
    Buffer.BlockCopy(ct, 0, result, 0, ct.Length);
    Buffer.BlockCopy(tag, 0, result, ct.Length, tag.Length);
    return result;
}

// Argon2id key derivation for local root trust
// User secrets are stretched before they ever touch vault encryption

public static byte[] DeriveKey(
    ReadOnlySpan<byte> password,
    ReadOnlySpan<byte> salt,
    KdfParams p)
{
    var cfg = new Argon2Config
    {
        Type = Argon2Type.HybridAddressing,
        Version = Argon2Version.Nineteen,
        TimeCost = Math.Max(1, p.Ops),
        MemoryCost = Math.Max(8, p.MemMiB) * 1024,
        Password = password.ToArray(),
        Salt = salt.ToArray(),
        HashLength = 32
    };

    using var hash = new Argon2(cfg).Hash();
    return hash.Buffer[..32].ToArray();
}

Technical detail where it matters

Security principles are only credible when they are backed by implementation detail and a realistic threat model.

Architecture Threat model Phantom Obscura