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.
on 2018-08-17 12:22:45 -0400 EDT by Ted Unangst <email@example.com>
on 2018-08-17 12:18:59 -0400 EDT by Ted Unangst <firstname.lastname@example.org>
Added tag reop-2.1.1 for changeset f9a2f4457e34
on 2018-08-17 12:15:40 -0400 EDT by Ted Unangst <email@example.com>
make sure ident is nul terminated.
on 2018-08-17 12:11:59 -0400 EDT by Ted Unangst <firstname.lastname@example.org>
make sure ident is nul terminated.
on 2017-04-24 16:07:25 -0400 EDT by Ted Unangst <email@example.com>
remove the -1 compat encryption option.
on 2017-04-24 16:03:57 -0400 EDT by Ted Unangst <firstname.lastname@example.org>
pull in man page improvements
on 2017-04-24 15:54:56 -0400 EDT by Ted Unangst <email@example.com>
raw import of the 3.0 snapshot so it's not entirely lost
on 2017-03-31 19:42:20 -0400 EDT by Ted Unangst <firstname.lastname@example.org>
build uses configure now
on 2017-03-31 19:40:36 -0400 EDT by Ted Unangst <email@example.com>
simplify readkeyfile and quiet warning
on 2017-03-31 19:36:56 -0400 EDT by Ted Unangst <firstname.lastname@example.org>
reconvert to "configure" based build from git repo