KCAPI_CIPHER_STREAM_(3)

💖 NAME 💖

okay bestie, this one's kcapi_cipher_stream_op — it's the function that obtains processed data (stream). literally it's the "gimme the output" call. 🎀

---

✨ SYNOPSIS ✨

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

---

🌸 ARGUMENTS 🌸

• handle — [in] your cipher handle, the little passport your cipher lives in. 🫶
• iov — [out] a scatter/gather list pointing at the buffers that get filled with the resulting data from a cipher operation. this is where the good stuff lands, bestie. 💅
• iovlen — [in] how many scatter/gather list elements you're handing over.

---

🦋 DESCRIPTION 🦋

so here's the vibe: you can call this thing interleaved with kcapi_cipher_stream_update to fetch the processed data. like, they're a duo. one feeds, one collects. ✨

this function may cause the caller to sleep if the kernel buffer holding the data is empty 😴 — no cap, it'll just nap on you. and the process gets woken up once more data is sent by calling kcapi_cipher_stream_update. so like, don't panic if it's just vibing there.

heads up though: when you supply buffers that are not a multiple of block size, the buffers will only be filled up to the maximum number of full block sizes that fit into the buffer. it's giving "partial fill energy" and honestly it's just how it is. 🙈

---

👑 the multithreaded tea 👑

the kernel supports multithreaded applications where one or more threads send data via the kcapi_cipher_stream_update function and another thread collects the processed data via kcapi_cipher_stream_op. multitasking slay. 🔥

but — and this is the part nobody warns you about — the kernel will return data via kcapi_cipher_stream_op as soon as it has some data available. it does not wait around for the whole thing. 😭

for example: one thread sends 1000 bytes to be encrypted and another thread already waits for the ciphertext. the kernel may send only, say, 500 bytes back to the waiting process during one kcapi_cipher_stream_op call. and then in subsequent calls to kcapi_cipher_stream_op more ciphertext is returned.

this implies that when the receiving thread shall collect all data there is, kcapi_cipher_stream_op must be called in a loop until all data is received. LOOP. IT. PERIODT. 💀

---

🌈 what you get back 🌈

return number of bytes obtained from the kernel upon success; a negative errno-style error code if an error occurred. so like, positive number = we ate 🍓, negative number = something went wrong, go check your errno.

---

🧚 AUTHOR 🧚

Stephan Mueller <smueller@chronox.de> — Author. (the icon who wrote this, show some respect 💜)

---

⭐ COPYRIGHT ⭐

libkcapi Manual 1.5.0 — July 2025

---

okay that's the whole page bestie, go forth and collect your streamed ciphertext, love u, mwah 💖🎀🦋