UIID v2.11 Released — Encrypted .uiid Files, REST Export Architecture and a Hardened Platform

LINKSPREED ships AES-256-GCM encryption, HMAC-SHA256 signatures, and new REST export endpoints for .uiid files, turning the credential container into a genuine, portable identity that only its owner can open.

Marc Herdina · USA uiidsecurityencryption

Your identity, in a file you own, that nobody else can open.

Friedberg, September 26, 2026 — LINKSPREED today announced the release of UIID v2.11, a platform update that turns the .uiid credential file from a backup artefact into a genuine, secure, portable identity container. The container is now encrypted with a passphrase only the holder knows, signed by the platform to prove it is authentic, and exportable on demand through new REST API endpoints.

Alongside the export architecture, v2.11 adds new endpoints to the UIID API, updates a large number of third-party dependencies, and fixes bugs including one affecting refresh tokens in the API. More about UIID is available at uiid.me.

Changelog — v2.11: encrypted .uiid files and REST export architecture

  • Encrypted .uiid credential container. Upgraded native .uiid credential files with AES-256-GCM encryption and PBKDF2 passphrase protection, securing personal identity backups against unauthorised access.
  • Anti-forgery server signatures. Embedded HMAC-SHA256 platform signatures into .uiid containers to ensure file authenticity and strictly prevent forged or tampered credentials.
  • REST export endpoints. Added secure REST API endpoints (/api/v1/core/uiid/export and /api/v1/aliases/:id/export) allowing authenticated applications to download encrypted .uiid credentials on demand.
  • Enhanced web authentication. Updated login and API authentication workflows with passphrase decryption support for seamless passwordless and credential-based access.

What changed, and why it matters

From backup format to real credential container

In v2.10, and in the follow-up releases v2.10.1 and v2.10.2, .uiid files appeared for the first time. They were useful, and they did what they were designed to do — but they were a backup format. They were not built to be a credential you could authenticate with, and LINKSPREED said so at the time: .uiid files were not recommended for authorising login.

That guidance existed for a good reason. A file that can log you in is a file that can log anyone in who obtains it. Shipping that capability before the container itself was properly protected would have been the wrong order to do things in, and LINKSPREED was not willing to do it.

v2.11 changes the order. The container is now encrypted, authenticated and signed. That is what makes everything else in this release possible.

Encryption: AES-256-GCM with PBKDF2

When you export a .uiid file now, you can encrypt it with a passphrase.

Two mechanisms do the work:

  • AES-256-GCM is the encryption itself. AES-256 is the symmetric cipher standard used for classified and high-assurance data worldwide. The GCM mode matters as much as the key size: it is an authenticated encryption mode, which means the file is not only unreadable without the right passphrase but also detectably modified if anyone alters a single byte. An attacker cannot silently tamper with an encrypted container and hope it decrypts into something subtly different. It simply fails.
  • PBKDF2 is what turns a passphrase into a key. This is the step most people never see and the one that determines how hard the file is to attack. A passphrase on its own is not a cryptographic key — it is short, human-chosen and guessable. PBKDF2 applies a deliberately expensive, repeated derivation process, so that each guess an attacker makes costs them real computation. The effect is to multiply the cost of a brute-force campaign by many orders of magnitude, transforming a passphrase from a weak input into a defensible one.

Together: the file is encrypted with a strong cipher, in a mode that detects tampering, using a key derived through a process designed specifically to punish guessing.

Anti-forgery signatures: proving a file is genuinely from UIID

Encryption answers “can anyone read this?”. It does not answer “is this file genuine?”.

.uiid containers now carry an embedded HMAC-SHA256 platform signature. This is a cryptographic proof that the container was produced by the UIID platform and has not been altered since.

This closes an attack class that would otherwise be obvious and effective: producing a plausible-looking .uiid file, delivering it to a victim or to a relying system, and having it accepted as a real credential. A forged file does not carry a valid signature, and a tampered file invalidates the one it had. Neither is accepted.

REST export endpoints

Two new endpoints make encrypted export a first-class part of the API:

EndpointPurpose
/api/v1/core/uiid/exportExport the Core ID as an encrypted .uiid container
/api/v1/aliases/:id/exportExport a specific alias as an encrypted .uiid container

Both require an authenticated application. Both produce an encrypted container, not a plaintext one.

The alias-level endpoint deserves particular attention, because it reflects how UIID’s identity model actually works. An alias is a self-contained identity context. Exporting one gives you a portable, encrypted container for that context alone — not for the entire identity. A user can move, back up or migrate one slice of their digital life without exposing the rest of it.

Hero Image

Enhanced web authentication

Login and API authentication workflows have been updated with passphrase decryption support, so that encrypted .uiid credentials integrate into passwordless and credential-based access flows rather than sitting outside them as a separate manual process.

The practical result: a .uiid file is no longer something to store and hope never to need. It is something that can actually be used.

Choosing a passphrase: what LINKSPREED recommends and why

LINKSPREED strictly recommends a passphrase of at least 16 characters.

That number is not arbitrary. Here is the reasoning in plain terms.

A 16-character passphrase drawn from a full character set represents roughly 105 bits of entropy. Combined with PBKDF2’s deliberate slowness, an attacker attempting to exhaust that space would need an amount of computation that does not meaningfully exist. Even under an absurdly generous assumption — that an adversary could command every GPU on the planet and sustain a trillion passphrase attempts per second, which PBKDF2 alone makes wildly unrealistic — the expected time to find the right one runs to hundreds of billions of years. The practical probability of success is, for any real-world purpose, zero.

The universe is roughly 13.8 billion years old. The attack takes considerably longer than that.

A memorable sentence is an excellent way to reach that length. A passphrase like:

I love the company called LINKSPREED

is 36 characters, trivial to remember, and enormously stronger than the eight-character password with a number and an exclamation mark that most people would otherwise choose.

One honest caveat, because protecting users matters more than sounding clever: do not use that exact example. Any passphrase published in a release note — including this one — is, from that moment, a known string that an attacker will try first. Use the pattern, not the string. Pick a personal sentence, make it long, make it something that would not be found in a book or a blog post, and do not reuse it anywhere else.

And a second, equally important one: a passphrase that protects an encrypted file is a passphrase that nobody can recover for its owner. That is the entire point. LINKSPREED cannot open a user’s container, cannot reset a passphrase and cannot help if it is lost. Encryption that a provider can bypass is not encryption. Write it down and store it somewhere physically safe, or use a credential manager that can be trusted.

Beyond .uiid: what else is in v2.11

New API endpoints, with more in development

v2.11 adds new endpoints to the UIID API beyond the export architecture, and a significant number of further endpoints are currently in development and in the planning phase.

The direction here is deliberate. The UIID API is intended to be complete enough that an entire product can be built on top of it — as UIID Mail demonstrates. Every endpoint added narrows the gap between what the platform can do internally and what a third-party developer can do with it.

Details will be published in the developer documentation and at help.linkspreed.com as they ship.

Hero Image

Third-party dependency updates

LINKSPREED has updated a large number of third-party dependencies in this release.

This is unglamorous work and it never makes a headline, but it is one of the highest-value security activities any platform performs. The overwhelming majority of real-world compromises exploit known vulnerabilities in outdated components, not novel attacks against custom code. Keeping the dependency tree current is how that entire category of risk is managed.

For an identity platform, this is not optional maintenance. It is a core obligation, and dependency currency is treated as a continuous process rather than a periodic cleanup.

Bug fixes, including refresh tokens

v2.11 includes bug fixes across the platform. Among them is a fix affecting refresh token handling in the API.

Refresh tokens sit at the heart of session management: they are what allows a signed-in session to continue without repeatedly re-authenticating. Correct behaviour here directly affects both reliability and security, and it is exactly the kind of component where a subtle defect produces symptoms that are hard to diagnose from the outside. LINKSPREED would rather name it in a release note than leave developers guessing.

Availability

UIID v2.11 is available now for all existing UIID holders and for applications building on the UIID API. No action is required to receive the platform update; encrypted export requires setting a passphrase before first use. Any .uiid files exported under v2.10, v2.10.1 or v2.10.2 remain readable but were produced before container encryption existed, and LINKSPREED recommends exporting fresh, encrypted containers under v2.11 and retiring the older files.

What this means in practice

  • For UIID holders: a UIID can now be exported — the Core ID or any individual alias — into an encrypted file under the holder’s full control. Choosing a long passphrase and storing it safely means nobody, including LINKSPREED, can open that container without it.
  • For developers building on the UIID API: the two new export endpoints are available now, passphrase decryption is supported in the authentication workflows, and more endpoints are on the way.
  • For anyone focused on digital sovereignty: this release is the practical expression of a claim that is easy to make and hard to implement. An identity that cannot be exported is an identity someone else holds on a person’s behalf. As of v2.11, a UIID is a file — encrypted with a key only its owner knows, signed so it cannot be forged, and portable because it belongs to them.

Resources

About LINKSPREED

LINKSPREED (Linkspreed UG) is the company behind UIID, the Universal Integrated Identity platform. UIID splits a person’s digital identity into an immutable Core ID and flexible, context-specific aliases, letting people and organizations hold, encrypt and export their own identity credentials instead of depending on a third party to store them. The platform also powers UIID Mail, currently in development. More information is available at uiid.me.

Press contact

[email protected]