Crypto

The crypto command group lets you encrypt and decrypt content standalone — outside of sending a message. Useful for testing encryption, pre-encrypting payloads, or integrating with other tools.

The CLI always derives the encryption identity from the configured keypair using the wallet-derived Ed25519-to-X25519 algorithm. It does not manage custom registered Key account private material.

---

Packet Envelope Interaction

crypto encrypt encrypts one plaintext string. With --content, that plaintext is exactly the string you pass. With --text and/or --file, the CLI first builds a Packet envelope, then encrypts the encoded envelope string.

That means this command:

packet crypto encrypt --to <pubkey> \
  --subject "Report" \
  --text "See attached." \
  --file ./report.pdf

encrypts a Packet envelope shaped like:

{
  subject: "Report",
  message: [
    { contentType: "text/plain", encoding: "utf8", content: "See attached." },
    { contentType: "application/pdf", encoding: "base64", content: "..." }
  ]
}

crypto decrypt does the reverse. It decrypts the encrypted JSON, parses the plaintext as a Packet envelope when possible, prints text parts as display text, and can save binary parts with --full-view <dir>.

---

crypto encrypt

Encrypt content for a specific recipient wallet.

packet crypto encrypt --to <pubkey> (--content <text> | --text <text> | --file <path>) [options]

Required:

Flag	Description
--to <pubkey>	Target recipient's Solana wallet public key

Content input:

Exactly one input mode is required.

Flag	Default	Description
--content <message>	—	Exact plaintext to encrypt. Cannot be combined with --text or --file.
--text <message>	repeatable	Add a text/plain Packet envelope part.
--file <path>	repeatable	Add a file Packet envelope part.

--text and --file can be combined. They build one Packet envelope, so you can encrypt multiple text parts and files in one payload.

Options:

Flag	Default	Description
--subject <subject>	—	Optional Packet envelope subject for --text/--file input.
--dont-include-sender	false	Exclude the sender from the reader list. The sender will not be able to decrypt.
--out <path>	—	Write encrypted JSON to a file instead of printing to stdout.
--upload	false	Upload the encrypted JSON to Irys and print the URL.

Output:

By default, the encrypted JSON envelope is printed to stdout:

{
  "version": 1,
  "algorithm": "x25519-xsalsa20-poly1305",
  "nonce": "...",
  "readers": [...],
  "ciphertext": "..."
}

Examples:

# Encrypt a message for a recipient
packet crypto encrypt --to 3xK...abc --content "Secret message"

# Encrypt a multi-part Packet envelope and save output
packet crypto encrypt --to 3xK...abc \
  --subject "Private report" \
  --text "Notes are attached." \
  --file ./report.pdf \
  --out ./report.enc.json

# Encrypt and upload to Irys
packet crypto encrypt --to 3xK...abc --content "Secret" --upload

---

crypto decrypt

Decrypt Packet-encrypted content using the configured wallet's private key.

packet crypto decrypt (--text <json> | --file <path> | --url <url>) [--json]

Input (exactly one required):

Flag	Description
--text <json>	Encrypted JSON body as a string
--file <path>	File containing the encrypted JSON
--url <url>	URL pointing to the encrypted JSON

Options:

Flag	Default	Description
--full-view <dir>	—	Save binary Packet envelope parts to a target folder.
--json	false	Print structured JSON output instead of display text.

Examples:

# Decrypt from a file
packet crypto decrypt --file ./doc.enc.json

# Decrypt from a URL
packet crypto decrypt --url https://gateway.irys.xyz/<cid>

# Decrypt and get JSON output
packet crypto decrypt --file ./doc.enc.json --json

---

Notes

• The CLI uses the wallet-derived Ed25519-to-X25519 algorithm: the Ed25519 signing key is converted to an X25519 key deterministically. This means any wallet can encrypt/decrypt without a separate key registration step.
• The sender is included as a reader by default, so you can decrypt messages you sent.
• For CLI-only wallets, you usually should not create a registered Key account. If a wallet has a registered Key account, senders that resolve it encrypt to that registered public key and the matching private encryption identity is required to decrypt.
• For browser UI wallets that use password/signature-derived encryption, avoid reusing the same wallet in CLI unless you understand the key-mode conflict.