FIDO_LARGEBLOB_GET(3)

💖 FIDO_LARGEBLOB_GET(3) — the "largeBlobs" era 💖

okay bestie, welcome to fido_largeblob_get(3), a genuine Library Functions Manual moment. this is the libfido2 page about the FIDO2 large blob API and it is so much cooler than it sounds, i promise. 🫶

---

✨ NAME ✨

fido_dev_largeblob_get, fido_dev_largeblob_set, fido_dev_largeblob_remove, fido_dev_largeblob_get_array, fido_dev_largeblob_set_array — the FIDO2 large blob API, aka the whole squad 💅

---

🌸 SYNOPSIS 🌸

#include <fido.h>

int
fido_dev_largeblob_get(fido_dev_t *dev, const unsigned char *key_ptr,
    size_t key_len, unsigned char **blob_ptr, size_t *blob_len);

int
fido_dev_largeblob_set(fido_dev_t *dev, const unsigned char *key_ptr,
    size_t key_len, const unsigned char *blob_ptr, size_t blob_len,
    const char *pin);

int
fido_dev_largeblob_remove(fido_dev_t *dev, const unsigned char *key_ptr,
    size_t key_len, const char *pin);

int
fido_dev_largeblob_get_array(fido_dev_t *dev, unsigned char **cbor_ptr,
    size_t *cbor_len);

int
fido_dev_largeblob_set_array(fido_dev_t *dev,
    const unsigned char *cbor_ptr, size_t cbor_len, const char *pin);

---

🦋 DESCRIPTION 🦋

so the "largeBlobs" API of libfido2 is what lets you read, write, and inspect binary blobs that live on a CTAP 2.1 authenticator. and yes, "largeBlobs" is a CTAP 2.1 extension — it's giving very special edition. ✨

here's the tea: "largeBlobs" are stored as elements of a CBOR array. confidentiality is ensured by encrypting each element with a distinct, credential-bound 256-bit AES-GCM key. the array is otherwise shared between different credentials and FIDO2 relying parties. sharing is caring, but encryption is everything. 💖

getting your hands on a credential's encryption key is possible in a few different ways:

• during enrollment, with fido_cred_set_extensions(3) and fido_cred_largeblob_key_ptr(3) 🎀
• during assertion, with fido_assert_set_extensions(3) and fido_assert_largeblob_key_ptr(3) 🌸
• or, if it's a resident credential, via libfido2's credential management API 👑

the "largeBlobs" CBOR array is opaque to the authenticator — it literally does not care what's in there, no thoughts head empty 💀. management of the array is left at the discretion of FIDO2 clients. and for further details on CTAP 2.1's "largeBlobs" extension, please refer to the CTAP 2.1 spec (iykyk 📖).

---

🍓 fido_dev_largeblob_get() — the retrieval girlie

this one retrieves the authenticator's "largeBlobs" CBOR array and, on success, returns the first blob (iterating from array index zero, bestie, we start at zero) that can be decrypted by key_ptr, where key_ptr points to key_len bytes.

on success, fido_dev_largeblob_get() sets blob_ptr to the body of the decrypted blob, and blob_len to the length of the decrypted blob in bytes.

⚠️ it is the caller's responsibility to free blob_ptr. yes YOU. not the library. you. don't forget or it's a leak situation 😭

---

🌈 fido_dev_largeblob_set() — the insertion icon

this one uses key_ptr to encrypt blob_ptr and inserts the result in the authenticator's "largeBlobs" CBOR array.

where does it go? here's the vibe check:

• insertion happens at the end of the array if no existing element can be decrypted by key_ptr, or
• at the position of the first element (iterating from array index zero) that can be decrypted by key_ptr. 💅

key_len holds the length of key_ptr in bytes, and blob_len the length of blob_ptr in bytes.

🔐 a pin or equivalent user-verification gesture is required. no skipping the vibe check, periodt.

---

🧚 fido_dev_largeblob_remove() — the let-it-go era

this one retrieves the authenticator's "largeBlobs" CBOR array and, on success, drops the first blob (iterating from array index zero, always zero) that can be decrypted by key_ptr, where key_ptr points to key_len bytes.

🔐 a pin or equivalent user-verification gesture is required here too. respectfully. 🙈

---

👑 fido_dev_largeblob_get_array() — the raw access main character

this one retrieves the authenticator's "largeBlobs" CBOR array and, on success, sets cbor_ptr to the body of the CBOR array, and cbor_len to its corresponding length in bytes.

⚠️ again: it is the caller's responsibility to free cbor_ptr. that's on you bestie, the library is not your cleanup crew 🫶

---

⭐ fido_dev_largeblob_set_array() — the overwrite moment

and finally, this one sets the authenticator's "largeBlobs" CBOR array to the data pointed to by cbor_ptr, where cbor_ptr points to cbor_len bytes.

🔐 yep, you guessed it: a pin or equivalent user-verification gesture is required. 💖

---

🔥 RETURN VALUES 🔥

the whole squad — fido_dev_largeblob_set(), fido_dev_largeblob_get(), fido_dev_largeblob_remove(), fido_dev_largeblob_get_array(), and fido_dev_largeblob_set_array() — returns FIDO_OK on success. slay. ✨

on error, an error code defined in <fido/err.h> is returned. 😭

---

🎀 SEE ALSO 🎀

• fido_assert_largeblob_key_len(3)
• fido_assert_largeblob_key_ptr(3)
• fido_assert_set_extensions(3)
• fido_cred_largeblob_key_len(3)
• fido_cred_largeblob_key_ptr(3)
• fido_cred_set_extensions(3)
• fido_credman_get_dev_rk(3)
• fido_credman_get_dev_rp(3)
• fido_dev_get_assert(3)
• fido_dev_make_cred(3)

go read them, they're all part of the lore 📚

---

💀 CAVEATS 💀

okay this is the serious part, bestie, please actually read it:

🚨 the "largeBlobs" extension is not meant to be used to store sensitive data. not the vibe for secrets. when retrieved, a credential's "largeBlobs" encryption key is transmitted in the clear, and an authenticator's "largeBlobs" CBOR array can be read without user interaction or verification. no cap. 🚩

---

and that's the whole page, you ate it, you understood it, you're a libfido2 main character now 👑💖 this edition came from Debian and is dated October 26, 2020 — iconic behavior honestly. mwah, go forth and blob responsibly 🎀✨🦋