humungus - reop

overview - downloads - files - changes - changes rss

reop - reasonable expectation of privacy

intro

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

For early history and background, consult the original flak post:
http://www.tedunangst.com/flak/post/reop

reop

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.

Example:

-----BEGIN REOP SIGNED MESSAGE-----
"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.
-----BEGIN REOP SIGNATURE-----
ident:tedu
RWS1l0sm+eG0IZ7/JZ7V3Ct584XleF33BQkIiXmHNHjHKWTBZprpVPeiLsCpkRFL1m0y3z7xFBkx
nzoNVbTELwB932C1rdllJwQ=
-----END REOP SIGNED MESSAGE-----

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).

-----BEGIN REOP PUBLIC KEY-----
ident:tedu
RWRDU7WXSyb54bQhy9CZ7Qq6kUZMeOkxDeFNDOU/jl6oQp+vfgGbIP9mRinCQ/pnpvqCMjLnDG7I
I8gMZw/P6zJ+jEaFZX+9pTyCYA==
-----END REOP PUBLIC KEY-----

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.

crypto

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.

limitations

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.

code

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)

1.0
Initial release

1.1.1
Binary encrypted messages (-b option)

2.1
More secure encrypted message format (default)

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

recent changes