humungus - reop

i am gravely disappointed

i understand your pain

overview - files - changes - downloads

reop - reasonable expectation of privacy


reop is a simple, semi-modern wannabe PGP clone.

For early history and background, consult the original flak post:


Supported operations include signing -S and verifying -V messages, plus a
variety of options for encrypting messages (-D -E). It does everything you’d
expect a PGP program to do. More accurately, it does everything I expect you
to expect a PGP program to do. I may be wrong, but it kills me to see people
reaching for the gpg or openssl hammer of infinite possibilities for the
simplest of tasks. Limitations below.

There is a (short) manual, of course, but there aren’t so many options that
you should need to consult it more than once. Usually the short help text
should be sufficient to get you started. I’ve tried to keep the option
mnemonics reasonable.

reop -G -i tedu # create tedu key pair
reop -E -i ralph -m message # encrypt a message for ralph
reop -D -x message.enc # ralph decrypts my message

The full manual is in reop.1. Also available preformatted as reop.txt.

I had a short lived plan to support the real OpenPGP standard, but as I was
scrolling through it, I came across the words “ASN.1 Object Identifiers” and
my monitor went blank to prevent permanent damage. As it is, reop implements
a sort of look-alike/feel-alike facsimile of the standard.


"So, you're the UNIX guru."
At the time, Randy was still stupid enough to be flattered by this attention,
when he should have recognized them as bone-chilling words.

A reop key technically consists of two keys (one for signing, one for
encrypting). The interesting part of a reop public key fits in a tweet
(the ----- decoration stuff is too much though).


You don’t get to pick your algorithms. I pick them (sort of; nacl picked
them). There is theoretical support for future algorithm changes. In general,
reop only asks questions that only the user can answer, and which the user
should be able to answer. Fewer features -> fewer feature options -> fewer
commands to edit, adjust, and otherwise tweak those options.


All the crypto comes from nacl (indirectly via libsodium). Specifically,
reop uses crypto_sign (Ed25519), crypto_box (Curve25519, Salsa20, and
Poly1305) and crypto_secretbox (Salsa20 and Poly1305). I have not personally
vetted these functions. Internet told me they were safe.

While it's possible to use these constructions to provide sender
confidentiality, I'm not sure it's a good fit for reop. It doesn't
align with how the tool is likely to be used, and sender identity will most
likely leak some other way. Better IMO to simply not make that promise.

Nonces, where necessary, are generated randomly.


There’s no support for key revocation, or long chains of certificates, or
partial trust, or key servers. For the most part, I think this is feel good
wankery that doesn’t accomplish as much as one would like. I wonder how many
people have ever revoked their PGP keys to see how it works in practice. The
reop trust model is very simple. You can probably even understand it.

Keys don’t expire. If we expand the scope of inquiry slightly to TLS certs,
I’ve lost count of the problems I’ve seen caused by prematurely expiring
certs.  Number of times an expired cert has saved my ass? Zero. This is
arguably shortsighted, I know.

You can’t embed a JPG selfie into reop keys. Not even a tiny one.

reop doesn’t include a Tempest resistant font for viewing top zecret messages.


Should build on most unix platforms. sh configure; make. Be sure to have
libsodium installed first.

The current code should always build and mostly work, but tagged releases
(with tarballs) probably work better, or at least are a known quantity.

Refer to the devnotes.txt file for more information about technical innards.

history (notable versions and changes)

Initial release

Binary encrypted messages (-b option)

More secure encrypted message format (default)

3.0 (unreleased)
Passwords can be passed in REOP_PASSPHRASE. Remove passwords on stdin support.

recent changes

8977db77e8e3 on 2018-08-17 16:22:45 +0000 UTC by Ted Unangst <>


00fcdec6f5ed on 2018-08-17 16:18:59 +0000 UTC by Ted Unangst <>

Added tag reop-2.1.1 for changeset f9a2f4457e34

f9a2f4457e34 on 2018-08-17 16:15:40 +0000 UTC by Ted Unangst <>

make sure ident is nul terminated.
found by Carlin Bingham

61b448583aa3 on 2018-08-17 16:11:59 +0000 UTC by Ted Unangst <>

make sure ident is nul terminated.
found by Carlin Bingham

9937626da070 on 2017-04-24 20:07:25 +0000 UTC by Ted Unangst <>

remove the -1 compat encryption option.

e272b2653b98 on 2017-04-24 20:03:57 +0000 UTC by Ted Unangst <>

pull in man page improvements

4bc94e77c870 on 2017-04-24 19:54:56 +0000 UTC by Ted Unangst <>

raw import of the 3.0 snapshot so it's not entirely lost

cc8888b54d79 on 2017-03-31 23:42:20 +0000 UTC by Ted Unangst <>

build uses configure now

17f5a3771bf6 on 2017-03-31 23:40:36 +0000 UTC by Ted Unangst <>

simplify readkeyfile and quiet warning

17e9fdd0483a on 2017-03-31 23:36:56 +0000 UTC by Ted Unangst <>

reconvert to "configure" based build from git repo