CLEVIS-ENCRYPT-SSS(1)

💖 CLEVIS-ENCRYPT-SSS 💖

okay so bestie, welcome to clevis-encrypt-sss(1) — the manual page for clevis-encrypt-sss, aka the Shamir's Secret Sharing girlie. this one is genuinely iconic, like she's the friend who organizes the whole group chat. let's get into it 🫶

---

✨ NAME ✨

clevis-encrypt-sss — encrypts using a Shamir's Secret Sharing policy

like. that's her whole thing. she encrypts stuff, but with ✨math✨ and ✨trust✨ instead of just one key.

---

🌸 SYNOPSIS 🌸

clevis encrypt sss CONFIG [-y] < PT > JWE

read it, love it, memorize it. CONFIG goes in, ciphertext comes out, it's giving pipeline core 💅

---

🦋 OVERVIEW 🦋

so the clevis encrypt sss command does the encryption using a Shamir's Secret Sharing policy. its only argument is that JSON configuration object. that's it. one arg. she's low maintenance actually.

now let me tell you about Shamir's Secret Sharing (SSS) because it's genuinely so cool. SSS is the way you mix pins together to build sophisticated unlocking policies and high-availability setups. no cap.

SSS is a thresholding scheme. here's the vibe: it creates a key and divides it into a bunch of pieces. each piece gets encrypted using another pin — and yes, that pin could literally be SSS again, recursively, it's giving inception 🌀. on top of all that, you define the threshold t. and if at least t pieces can be decrypted, then the encryption key can be recovered and decryption succeeds. periodt.

for example, bestie, let's cook up a high-availability setup using Tang:

$ cfg='{"t":1,"pins":{"tang":[{"url":...},{"url":...}]}}'
$ clevis encrypt sss "$cfg" < PT > JWE

so in this policy we're declaring a threshold of 1, but there are multiple key fragments encrypted using different Tang servers. and since our threshold is 1? as long as any of those Tang servers is available, decryption will succeed. main character availability energy honestly 👑

and as always, decryption is simply:

$ clevis decrypt < JWE > PT

---

🎀 CONFIG 🎀

this command uses the following configuration properties:

• t (integer) — number of pins required for decryption (REQUIRED)
• pins (object) — pins used for encrypting fragments (REQUIRED)

yeah both of them are required, no skipping, not optional, don't even try it 😭

the format of the pins property is as follows:

{PIN:CFG,...} OR {PIN:[CFG,CFG,...],...}

and here's the tea: when you use the list version of that format, multiple pins of that type will receive key fragments. so one pin type, many fragments, she's generous 🌈

---

💅 OPTIONS 💅

• -y — automatically answer yes for all questions. for the tang pin, it will skip the advertisement trust check, which can be useful in automated deployments:

$ cfg='{"t":1,"pins":{"tang":[{"url":...},{"url":...}]}}'
$ clevis encrypt sss "$cfg" -y < PT > JWE

just so we're clear bestie: -y = auto-yes, and for tang that means skipping the advertisement trust check. great for automation, but you're literally saying "yes" on autopilot, so know what you're doing 🙈

---

👑 SEE ALSO 👑

• clevis-encrypt-tang(1)
• clevis-decrypt(1)

go read those too, they're the rest of the friend group 🧚

---

and that's the whole page!! this was the CLEVIS-ENCRYPT-SSS(1) manual, version dated 10/16/2026 — thanks for reading, you ate that, no crumbs 💖✨🎀