KCAPI_AEAD_STREAM_UP(3)

💖 KCAPI_AEAD_STREAM_UP(3) — bestie, it's the stream-update girlie 💖

okay so this page is from the Programming Interface manual, and it's about one very specific little function that feeds more data into your AEAD stream. sit down, hydrate, let's go 🫶

---

✨ NAME ✨

kcapi_aead_stream_update — send more data for processing (stream). that's it. that's the whole job. she just sends more. no cap.

---

🦋 SYNOPSIS 🦋

ssize_t kcapi_aead_stream_update(struct kcapi_handle * handle,
                                 struct iovec * iov, size_t iovlen);

---

🎀 ARGUMENTS 🎀

• handle — [in] the cipher handle. your main character. the one you got from the init call. hold her gently 💅
• iov — [in] a scatter/gather list holding the data that the cipher operation is gonna process. it's a whole lil list of memory chunks, not one single buffer, so act accordingly 🌸
• iovlen — [in] how many elements are in that scatter/gather list. count them. be honest. 🔢

---

💜 DESCRIPTION 💜

so like, when you call this, you're submitting more plaintext (if you're encrypting) or more ciphertext (if you're decrypting) to the kernel. that's the vibe. that's the whole move. ✨

ngl, watch the order of your input data — the ordering is laid out over in kcapi_aead_stream_init_dec, so go read that before you start yeeting bytes in the wrong sequence 🙈

also important: this call can make the caller sleep if the kernel buffer holding the data is getting full 😴 that's not a bug, that's just backpressure. the process gets woken back up once more buffer space frees up, and that wake-up happens by calling kcapi_aead_stream_op. so it's a lil tag-team situation, okay? 💫

---

🍓 NOTE 🍓

• the last block of input data MUST be handed over with kcapi_aead_stream_update_last instead. the kernel has to be told that the input data is complete — otherwise she's just sitting there waiting for more like 👁️👄👁️
• because kcapi_aead_stream_update and kcapi_aead_stream_op are separate calls, you can build a multi-threaded application: one thread sends data off to be processed, and one thread picks up the data that the cipher operation already processed. two threads, one dream, iconic division of labor 👑

---

🔥 WARNING 🔥

the memory that iov points at is not accessed by the kernel during this call. NOT. TOUCHED. the memory only gets accessed once kcapi_cipher_stream_op is called. so you MUST make sure that referenced memory is still there when kcapi_cipher_stream_op runs. if you freed it early, that's not a slay, that's a disaster 💀

and the return situation, fr fr:

• on success: the number of bytes sent to the kernel
• on error: a negative errno-style error code

---

🌈 AUTHOR 🌈

Stephan Mueller <smueller@chronox.de>

• Author. giving credit where credit is due, periodt 💖

---

👑 COPYRIGHT 👑

that's the whole page bestie!! 🎀 this was the libkcapi Manual version 1.5.0, dated July 2025 — so if you're quoting her, cite her right. mwah 💅✨🦋