SYD-KEY(1)

πŸ“¦ version 3.51.2, in nixos 26.05

πŸŽ€ SYD-KEY(1) β€” the key-making one, bestie πŸŽ€

okay so this is a page from the General Commands Manual, and it's all about syd-key πŸ’…


✨ NAME ✨

syd-key β€” a little utility that generates encryption keys and saves them to keyrings(7) πŸ—οΈβœ¨


🌸 SYNOPSIS 🌸

syd-key [-hpP] [-d keydesc] [-t keytype] [-k keyring]

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so here's the vibe: syd-key generates random 256-bit encryption keys, and it does it using the Linux Kernel's random number generator (yes, the real one, no cap πŸ”₯).

Then it saves that key to Linux keyrings(7) and prints the key serial ID to standard output as a decimal 32-bit integer. That's it. That's the whole job. Iconic behavior honestly πŸ‘‘


πŸ’– OPTIONS πŸ’–

  • -h β€” displays help. cute, quick, does what it says 🫢
  • -p β€” reads the passphrase from the controlling TTY (and NOT stdin(3), bestie, pay attention) and derives key material from it. So like β€” syd-key will flat-out refuse to read the passphrase from stdin(3) for safety reasons, unless you explicitly pass -P. The passphrase gets hashed using SHA3-256, and the resulting digest is what gets stored with the keyrings(7) interface. The passphrase buffer is zeroized after use (so no leftovers, we love a clean kitchen 🧼). The key serial ID is printed on stdout(3). And if you supply neither -p nor -P? Then a random key is generated using getrandom(2) with the GRND_RANDOM flag instead. slay πŸ’«
  • -P β€” reads the passphrase from stdin(3) and derives key material from it. This one is intended for non-interactive use β€” like piping a passphrase in from a password manager, iykyk. But use it with caution, fr fr: reading a passphrase from stdin(3) can be less secure than reading from the controlling TTY, because it may be observable by other processes, recorded in shell constructs, or otherwise leaked by the environment 😭. The passphrase is hashed using SHA3-256, and the resulting digest is stored with the keyrings(7) interface. The passphrase buffer is zeroized after use. Key serial ID gets printed on stdout(3). Same deal as above: if none of -pP is supplied, a random key is generated using getrandom(2) with the GRND_RANDOM flag instead.
  • -d kdesc β€” specify an alternative key description. The default is SYD-3-CRYPT πŸŽ€
  • -t ktype β€” specify an alternative key type. The default is user 🌸
  • -k kring β€” specify an alternative key ring ID. The default is KEY_SPEC_USER_KEYRING. It may be exactly one of thread, process, session, user or user-session. It may also be a 32-bit decimal number specifying a keyring ID πŸ‘‘

πŸ’€ CAVEATS πŸ’€

Okay this part matters, so listen up bestie 🫢

Keys in keyrings(7) are identified by their (type, description) pair. So when syd-key invokes add_key(2) with a type/description combo that already exists in the target keyring, the kernel will update the existing key's payload instead of creating a brand new key. Not a new key. It just updates the old one. πŸ™ˆ

So if you actually want to force creation of a new key, use a unique description β€” for example by appending a UUID or a timestamp. Do that and you're golden ✨


🌈 SEE ALSO 🌈

syd(1), syd(2), syd(5), syd-aes(1), getrandom(2), add_key(2), keyrings(7)

syd homepage: https://sydbox.exherbo.org/ 🌐


πŸ‘‘ AUTHORS πŸ‘‘

Maintained by Ali Polatel. Up-to-date sources can be found at https://gitlab.exherbo.org/sydbox/sydbox.git and bugs/patches can be submitted to https://gitlab.exherbo.org/groups/sydbox/-/issues. Wanna discuss? Come hang in #sydbox on Libera Chat or in #sydbox:mailstation.de on Matrix πŸ’¬πŸ’œ


and that's the whole page, babe πŸŽ€ this was SYD-KEY(1), dated 1980-01-01, with SYD-KEY(1) sitting pretty in that footer spot β€” go make some keys, you've got this πŸ’…βœ¨πŸ¦‹

πŸ“¦ where this page comes from