Large blobs

What it is

CTAP 2.1 keys can hold a small, key-global large-blob array: a place where relying parties stash data that is too big to live inside a credential ID (an SSH certificate, for example). keyroost surfaces it in the Storage sub-view of the FIDO2 tab, showing every stored entry and letting you keep your own text notes alongside.

Where to find it

Open the FIDO2 tab, unlock with your PIN, then choose the Storage tab. It appears only when the key reports largeBlobs support in its getInfo options. The array loads automatically when you open the tab; the top bar's Refresh reads it again. Reading needs no PIN, but adding, editing, or deleting entries does — those are writes.

What you can do

View entries. Each stored entry is shown as a card. View bytes expands a side-by-side hex + ASCII dump of its contents. Genuine relying-party entries are labeled relying-party data and cannot be edited — they are encrypted by the website that created them, so keyroost never rewrites them.

Add a note. The Add button opens a composer; type text and save it. keyroost stores it as its own entry, marked so it can be recognized and read back here later. This is not encryption — the text is stored in the clear.

Edit a note. keyroost's own notes have an Edit button that replaces the text in place. Relying-party entries cannot be edited.

The key's name. A name stored on the key (see Naming) is one entry in this array, shown as key name: "…". Change it with Rename (or keyroostctl name set), not here: its Edit is disabled. Deleting it removes the key's name, and keyroost says so first.

Delete an entry. Any entry can be deleted, and every delete is confirmed: the CLI asks y/N in a terminal and needs --yes in a script or when the PIN is piped in (the desktop app asks you to confirm). Deleting an entry a relying party owns may break the service that stored it, so keyroost prints a warning before it asks or proceeds. keyroost then rewrites the array without the entry.

Erase everything. A separate wipe-all action clears the entire array — relying-party data included, not just keyroost notes. It is irreversible, needs your PIN, and is double-confirmed in the app (y/N or --yes on the CLI). The key's name goes too, and the warning names it, unless you keep it: Keep the key's name in the app, --keep-name on the CLI.

How writes stay safe

The large-blob array is not a flat byte buffer: it is a CBOR array of entries followed by a 16-byte truncated SHA-256 checksum over the whole serialization. A naive raw edit that left a stale checksum would make the key reject the array, and could break future credential writes until a reset.

keyroost therefore edits the array structurally — it parses the entries, applies your add / edit / delete, then re-serializes and recomputes the checksum before writing. Each write re-reads the key's current array first, so concurrent relying-party entries are preserved. Writes are authenticated with a Large-Blob-Write token derived from your PIN.

Every entry keyroost doesn't change is written back byte for byte, in its original order, including fields keyroost doesn't know. An element that isn't in the standard entry format is skipped when reading (the listing says how many, and the rest of the array still shows) and kept unchanged when writing.

Command line

keyroostctl fido blob list
keyroostctl fido blob show 0
keyroostctl fido blob add "spare key in the desk drawer"   # asks for the PIN (hidden)
keyroostctl fido blob edit 2 "moved to the safe"
keyroostctl fido blob export 1 --out entry.bin            # raw bytes, no PIN
keyroostctl fido blob export 1 -o id_ecdsa_sk-cert.pub --as-cert
keyroostctl fido blob delete 1                            # asks y/N; RP-owned entries also print a warning
keyroostctl fido blob clear                               # wipes the whole array, asks y/N
keyroostctl fido blob clear --keep-name                   # ...but keeps the key's name
keyroostctl fido blob delete 1 --pin stdin --yes          # in a script: piped PIN, so --yes

Reading (list, show, export) needs no PIN — the array is world-readable. Note that add and edit take the note text as an argument, so it is visible to other local processes in the process list while the command runs; that is fine for a note and unacceptable for a secret, which is another reason not to put one here. If the --out file of export already exists, a terminal asks "overwrite? [y/N]"; a script must add --overwrite.

SSH certificates

The commonest real occupant of the large-blob array is an OpenSSH certificate: tools like ssh-keygen and fido2-token store the certificate for a resident SSH credential here so it travels with the key instead of living in a file you have to carry. keyroost can read one back out.

Each such entry is encrypted under a per-credential largeBlobKey that only the key can hand over, so extraction goes through credential management and needs your PIN (no touch). It is read-only — keyroost never writes or rewrites a relying party's certificate.

keyroostctl fido ssh list                         # asks for the PIN (hidden)
keyroostctl fido ssh export --rp ssh:demo --out id_ecdsa_sk-cert.pub

--rp (the SSH credential's RP ID) is needed only to disambiguate when the key holds several SSH credentials, and --out defaults to a sanitized <rp-id>-cert.pub. If that file exists, a terminal asks before replacing it; a script must pass --overwrite. In the desktop app the same thing is Save certificate… on the Passkeys tab, next to the SSH credential it belongs to.

Cautions

Nothing here is secret. Anyone who plugs in the key can read the array, including your notes. Don't store passwords, recovery codes, or anything sensitive. If a write is rejected, the key may be out of large-blob storage or busy; keyroost reports the CTAP status with a readable hint, and the array is left unchanged.