Repository files navigation

opmsg is a replacement forgpg which can encrypt/sign/verifyyour mails or create/verify detached signatures of local files.Even though theopmsg output looks similar, the concept is entirelydifferent.

Features:

• Perfect Forward Secrecy (PFS) by means of ECDH or DH Kex
• native EC or RSA fallback if no (EC)DH keys left
• fully compliant to existing SMTP/IMAP/POP etc. standards;no need to touch any mail daemon/client/agent code
• signing messages is mandatory
• OTR-like deniable signatures if demanded
• easy creation and throw-away of ids
• support for 1:1 key bindings to auto-select source key per destination
• adds the possibility to (re-)route messages differentfrom mail address to defeat meta data collection
• configurable, well-established hash and crypto algorithmsand key lengths (RSA, DH, ECC, AES, Chacha)
• straight forward and open key storage, basically also managable viacat,shred -u andls on the cmdline
• seamless mutt integration
• Key format suitable for easy use with QR-codes
• optional cross-domain ECDH Kex
• PQC-safe operations mode if desired

opmsg builds fine with any of the OpenSSL, LibreSSL and BoringSSL libcrypto libraries.Building against BoringSSL is not recommended due to missing blowfish and ripemd algorithms.

You can use various transports withopmsg such as Mail ordrops.Keys can be exchanged via mail, brainkeys orQR codes.

opmsg requires the crypto primitives fromOpenSSL. Just relax, itsnot using the SSL/TLS proto, just the ciphering and hash algorithms.For standardLinux distros, just typemake.

The compilation requires a C++ compiler that supports-std=c++11.This can be configured with e.g.make CXX=eg++ onOpenBSD.

This project supports bothBN_GENCB_new andBN_GENCB for big numbergeneration. To disableBN_GENCB_new, setHAVE_BN_GENCB_NEW to false:make DEFS=-DHAVE_BN_GENCB_NEW=0. So onOpenBSD, you would runmake CXX=eg++ DEFS=-DHAVE_BN_GENCB_NEW=0. OnOSX you should installyour ownOpenSSL, as Apple marksOpenSSL as deprecated in favor of their owncrypto libs. You may also set all these options in theMakefile.

It successfully builds onLinux,OSX,OpenBSD and probably a lot of others(Solaris,FreeBSD,...).

$ cd src$ make[...]$ cp build/opmsg /usr/local/bin/$ mkdir ~/.opmsg && touch ~/.opmsg/config$ opmsgopmsg: version=1.84 (C) 2021 Sebastian Krahmer: https://github.com/stealth/opmsgUsage: opmsg [--confdir dir] [--native] [--encrypt dst-ID] [--decrypt] [--sign][--verify file] <--persona ID> [--import] [--list] [--listpgp][--short] [--long] [--split] [--new(ec)p] [--newdhp] [--brainkey1/2][--salt1/2 slt] [--calgo name] [--phash name [--name name] [--in infile][--out outfile] [--link target id] [--deniable] [--burn]--confdir,-c(must come first) defaults to ~/.opmsg--native,-REC/RSA override (dont use existing (EC)DH keys)--encrypt,-Erecipients persona hex id (-i to -o, needs -P)--decrypt,-Ddecrypt --in to --out--sign,-Screate detached signature file from -i via -P--verify,-Vvrfy hash contained in detached file against -i--persona,-Pyour persona hex id as used for signing--import,-Iimport new persona from --in--list,-llist all personas--listpgp,-Llist personas in PGP format (for mutt etc.)--shortshort view of hex ids--longlong view of hex ids--splitsplit view of hex ids--newp,-Ncreate new RSA persona (should add --name)--newecpcreate new EC persona (should add --name)--deniablewhen create/import personas, do it deniable--linklink (your) --persona as default src to thistarget id--newdhpcreate new DHparams for persona (rarely needed)--brainkey1/2use secret to derive deniable persona keys--salt1/2optional: use salt when when using brainkeys--calgo,-Cuse this algo for encryption--phash,-puse this hash algo for hashing personas--in,-iinput file (stdin)--out,-ooutput file (stdout)--name,-nuse this name for newly created personas--burn(!dangerous!) burn private (EC)DH key afterdecryption to achieve 'full' PFS

If you want to use additional features, such as fromopmux (opmsg/gpg auto forward) oropcoin(using bitcoin network as a web-of-trust), also typemake contrib. Contrib tools aredocumented in README2.md. You may also want to checkopmsg-qr later on, to im/exportopmsgpersonas via QR codes, once you have set up your working environment.

The key concept ofopmsg is the use of personas. Personas arean identity with either an EC or RSA key bound to it. Communication happens betweentwo personas (which could be the same) which are uniquely identifiedby the hashsum of their EC/RSA keys:

$ opmsg --newp --name stealthopmsg: version=1.2 -- (C) 2015 opmsg-team: https://github.com/stealth/opmsgopmsg: creating new persona.......[...].........................o..o..o..o..o..oOopmsg: Successfully generated persona (RSA + DHparams) with idopmsg: 1cb7992f96663853 1d33e59e83cd0542 95fb8016e5d9e35f b409630694571abaopmsg: Tell your remote peer to add the following RSA pubkey like this:opmsg: opmsg --import --phash sha256 --name stealth-----BEGIN PUBLIC KEY-----MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4Xds/bPlkdqA9VhDBOIEV/Dc94EfL5aPBOQAdTIaZKE69SJdwakFhqOY1PeaeGRDcGTVNLBQ1Udgbc2YCgQh1X5DnveRIGJoGfqWC7zeq/mx6yRer3PTUOA0gr30Uu7IO128fVDxNLYYUuvzhzcdysZAaWkmRflKuaCEMQ3RjcQIDAQAB-----END PUBLIC KEY-----opmsg: Check (by phone, otr, twitter, id-selfie etc.) that above id matchesopmsg: the import message from your peer.opmsg: AFTER THAT, you can go ahead, safely exchanging op-messages.opmsg: SUCCESS.

This is pretty self-explaining. A new persona with namestealth iscreated. The public RSA key of this persona has to be imported bythe remote peer that you want to opmsg-mail with via

opmsg --import --phash sha256 --name stealth

just as hinted above. After pasting the public key of your communication peerinto above commandline - once it told you to do so - you will be given the persona ID,that consists of the hashsum (sha256 in this case) of the public key. ID'smay be presented to you in--short,--long, or--split (default) form,and will be auto-detected in either form as you pass it to the command line.

opmsg does not rely on a web-of-trust which in fact never reallyworked. Rather, due to ubiquious messenging, its much simpler todayto verify the hashsum of the persona viaadditional communicationpaths. E.g. if you send the pubkey via plain mail, use SMSand twitterto distribute the hash, or send a picture/selfie with the hashand something that uniquely identifies you. Usingtwo additionalcommunication paths, which are unrelated to the path thatyou sent the key along, you have a high degree of trust.Side-note: If you want to stay anonymous, do not send selfieswith your persona id and dont use communication paths that canbe mapped to you.

By defaultsha256 is used to hash the pubkey blob but you may also specifyripemd160orsha512. Whichever you choose, its important that your peer knowsabout it during import, because you will be referenced with this hex hash value(your persona ID) in future.

The private part of the keys which are stored inside~/.opmsgare NOT encrypted. It is believed that once someone gained accessto your account, its all lost anyway (except for PFS as explained later),so a passpharse just add a wrong feeling of security here. Keepyour account/box unpwned! Otherwise end2end encryption makes littlesense.

opmsg encourages users for easy persona creation and throwaway.The directory structure below~/.opmsg is easy and straightforward. It just maps the hex ids of the personas and (EC)DH keysto directories and can in fact be edited by hand.

Creation of RSA personas might take some time. Not just an RSA keyis generated in that case - which is not very time consuming - but also DHparameters (2048bit by default) that are used to implement PFSin later messenging (see later chapter).

In order to speed up persona generation and to encourage use- and throwawayand per-project personas, EC support was added toopmsg as ofversion=1.5.Instead of--newp you would just use--newecp and everything else is thesame.opmsg will pick the right crypto transparently to you. No need to addany further switches for encryption or alike. EC personas use the brainpool curves(RFC 5639). The NIST curvesecp521r1 may also be used as a fallback if yourlibcrypto is outdated, but its recommended to use the brainpool curves whichdont keep any secrets about how their group parameters were selected.Also see the chapter about cross-domain ECDH down below.

Although this step is not strictly necessary,it is recommended. As personas are easilycreated, you can (should) create a dedicated persona for each of your "projects" orcontacts. That is, if you have 7 communication partners/peers, you should havecreated 7 personas; one EC/RSA key for each of them. To handle that easily with yourmailer (see later for MUA integration), you should add a proper--name, describing yourid. If you are using email addresses along with names, use the format of--name 'da name <name@address>'so that your MUA can easily pick a list of candidates for you.

Additionally, you should--link your source persona (each of the 7 you created)to the particular destination persona that you wish to communicate with using this source id:

$ opmsg --link b3c32d47dc8b58a6 --persona 1cb7992f96663853opmsg: version=1.2 -- (C) 2015 opmsg-team: https://github.com/stealth/opmsgopmsg: linking personasopmsg: SUCCESS.

This is to avoid the need to specify--persona each time yousend a message to a different target persona, changing your localid back and forth inside the config file or at the command line.Above command says, that each time you send an opmsg tob3c32d47dc8b58a6,the keying material from your local id1cb7992f96663853 is used. To unlinkyour id fromb3c32d47dc8b58a6, remove thesrclink file inside this personasdirectory.

If no link is found for a persona, the config file and given--persona argument is evaluated. Command line arguments override the config file settings.

Given proper mail provider support (e.g. inboxes are created on the flyfor addresses likehexid@example.com), the global surveillance meta graph wouldjust contain pairs of communication partners. No clusters, just islandsof 1:1 mappings.

There may be valid scenarios where you dont want your communication peer to have a way to proofthat you wrote a certain message. Since op messages are always signed with your personakey, peer could proof that you were expressing illegal thoughts. So you want deniable messagesthat are still integrity protected. The OTR protocol is handling this by sharing the public aswell as the private key for a dedicated communication session between both peers.

opmsg allows to do the same. It requires an additional communication step with a peerthat you already imported once and which you suspect to do such back stabbing.(Generally speaking its wise to assume that case.)

It is recommended to use EC personas for that purpose, as its faster. Just add--deniableswitch on the commandline when creating or importing this deniable persona as wellas a--name that reflects deniability for you.This will print or import the private key half of the persona and link it to itself.

As this new persona is linked to itself, whenever you send something to the peer thesigning key is shared withthat peer. You can always deny that you sent this messageas your peer could also have signed it (src-id anddst-id inside the message are the same).Only exchange deniable persona keys across an existing secure (encrypted) channel as itcontains private keying material.Do not share any key material of this dedicated new EC persona to anyone else. Its only forthis dedicated, deniable, communication peer.

Once a deniable peer is established, you may use it as often and as long as you wishand as within normal operation.Deniable op messages are integrity protected and feature all crypto benefits.

Of course for this to work you also want to have fully encrypted your disk to leave noforensic artifacts and dont want to cite your peer in reply-messages as this proofsthat you were able to decrypt a mail from your peer, e.g. you are hold of a certainprivate session key (kex-id). Thats a common mistake people make who dont signtheir emails and think everything is deniable.

Brainkey personas are deniable personas whose key was not generated via RNGinput, but which are derived from a passphrase. They are very similar to theconcept of BTC brainwallets. When generating brainkey personas, the commandlineshould be as explicit as possible in order to have matching personas on both sidesdespite potentially different config-file settings for EC curves or hash algos:

$ opmsg --name=nobrainer --deniable --salt1 1234 --brainkey1 --newecp=secp521r1 --phash=sha256opmsg: version=1.80 (C) 2021 Sebastian Krahmer: https://github.com/stealth/opmsgopmsg: Enter the brainkey, 16 chars minimum (echoed): mysupersecretnobodyknowsopmsg: creating new EC persona (curve secp521r1)opmsg: Successfully generated persona with idopmsg: a6da74f688c375d8 96858709ffd1a25f d42e6523bb89d0f2 45cfe554cf7b4e7copmsg: You created a deniable persona.opmsg: Your persona key was derived from a brainkey. No need to exchange keysopmsg: with your peer. Your peer just needs to execute the same command as youopmsg: in order to create the same deniable persona on their side.opmsg: SUCCESS.

Ofcorse, you should use a secret that nobody can guess or bruteforce, includingupper and lower-case, digits and so on. The idea behind brainkey personas is,that you share a secret with your peer once you meet, and both sides canthen generate the same personas independently afterwards. There's no need to verifyfinger prints or exchange keys. The salt parameter doesn't need to be secret and mayalso be omitted. But it is a safety measure to chose a salt in order to make attackswith rainbow tables unfeasable. If you are certain that no other usersare on your box, you may also pass the passphrase as--brainkey1=mysupersecretnobodyknowson the commandline instead of typing it onstdin.Brainkeys will only be used for deniable EC personas. The Kex (aka Session) keyswill nevertheless be generated randomly, just as for other personas.Brainkey personas can then be used just as normal. Once created, you may justforget the brainkey, as you will never need to generate it again.

As ofversion=4 messages,opmsg supports personas who resist quantum computing power.These personas have typepq1 in theopmsg -l listing and are basically brainkeypersonas as above but include a symmetric salt thats used together with the ECDH Kexto derive the session key. The integrity ofversion=4 (and above) messages is not onlyprotected by asymmetric signatures (RSA or ECC) but by also extending the AAD of AES-GCM tothe entire header, including exchanged keys and the Kex part. This ensures that evenwith quantum computing power, an adversary cannot modify the message or break the sessionkeys. PQC-Personas are generated similar tobrainkey1 personas:

$ opmsg --name=quantum-tarantino --deniable --salt2 1234 --brainkey2 --newecp=secp521r1 --phash=sha256[...]

I.e. by using--brainkey2 instead of--brainkey1.Forpq1 personas,opmsg only acceptsaes256gcm andchacha20-poly1305 cipher algos,in order to fully protect the entire message with AAD as described above.This symmetric salt solution is recommended by the BSI (Federal Office of InformationSecurity in good old Germany) durin the transitioning phase. Note, that neitherOpenSSLsupports PQC yet, nor are there any standartized algorithms, nor recommend any of the PQCprojects to use their code in production, so having this transitioning solution is the mostportable way of adding PQC toopmsg.

In order to encrypt messages, you have to specify the persona ID of the recipient:

$ opmsg -E 12344d8921323601 --out msg1.opmsg...

If no--in parameter is given, the message is read fromstdin untilCtrl-C.The fastest way is to use the long form of the persona ID, but its also the mostinconvenient form. Above example uses the short ID of the target persona. It alreadyrequires some searching inside the keystore for that particluar ID, but its still fast.The most convenient, but slowest form allows to use names as recipient. It requires tosearch the entire keybase until a name-match is found. Note, that this is potentiallyambigious and you must not have more than one persona with the same name field in yourkeystore:

$ opmsg --name friend@localhost -E name --in msg2 --out msg2.opmsg...

-E name refers to use names instead of IDs. Still, it is recommended to use the hex-id asrecipient, since its the more bullet-proof approach.

Now for the coolest feature ofopmsg: Perfect Forward Secrecy (PFS).

Without any need to re-code your mail clients or add bloat to theSMTP protocol,opmsg supports PFS by means of (EC)DH Kex out of the box.

For RSA personas, DH Kex is used. For EC personas ECDH Kex is used to derivethe secret, hence the term (EC)DH.

As op-messages arealways signed by its source persona,whenever you send an opmsg to some other persona, a couple of(EC)DH keys are generated and attached to the message. The remoteopmsg will verify its integrity (as it has this persona imported)and add it to this persona's keystore. So whenever this remote peersends you a mail next time, it can choose one of the (EC)DH keys it hasgot beforehand. If your peer runs out of (EC)DH keys,opmsg fallsback to native RSA or EC encryption, depending of the type of persona.The peer deletes used (EC)DH pubkeys to notuse them twice and the local peer marks used keys with aused file within the apropriate key-directory. Once again,sha256 is used by default to index and to (worldwide) uniquelyidentify (EC)DH keys.

Attention: If you keep encrypted op-messages in your mailbox,do not throw away this persona. You wont be able to decrypt these mailsafterwards! Throwing away a persona also means to throw away all keyingmaterial. Thats whyopmsg has no switch to erase personas. You haveto do it by hand, by rm-ing the subdirectory of your choice. Thatseasily done, but keep in mind that any dangling op-messages in yourinbox will become unreadable, as all keys will be lost. If you want tobenefit from PFS, you have to archive thedecrypted messages andthrow awayused keys. After allopmsg is not a crypto containeror a replacement for FDE (which is recommended anyway).opmsg isabout to protect your messages in transit, not on disk.

As ofversion=1.3 there is a--burn option that nukes used DHkeys from storage. Be aware: you can only decrypt the message once.Once the message is successfully decrypted, the (EC)DH key that was usedis overwritten and deleted from storage.

You may skip this section if you are not really paranoid about potentiallybackdoored EC curves and how to cope with it.

There is a (yet experimental) feature, which may be enabled by using protocol version 3and specifying more than one EC curve in the config:

...version=3...curve=brainpoolP384r1curve=secp256k1...

Up to three different curves may be specified. For each curve specified, a dedicated ECDHhandshake is made. That is, the key used for encrypting the message is derived from morethan one ECDH Kex. The 'common' ECDH handshake, as seen in all other protocols like TLS etc.,uses one curve.opmsg by default also uses one curve. But you can use more than one, andhere is why: There is an endless discussion about which curve can be trusted. Some preferthe NIST curves, some prefer Brainpool and some prefer even other curves. As shown invarious papers, it is possible by evil EC-curve designers to choose the curve domain parametersin a way that places backdoors into the curve. That is, by knowing certain seeding parameters,it is possible to create legit looking curves which fullfil all requirements, yet producingweak secrets, if the attacker knows the evil seeding bits. It is not just a theroretical issuethat evil committee members place backdoors into standards (take the dual-EC-DRBG as a warning).

The idea behind cross-domain ECDH is that, even if we assume all EC curves to containbackdoored parameters, the knowledge about it is so well protected that it is not sharedacross each other. Would the NIST share their backdoor seedings with the russians or vice versa?Certainly they wouldn't.In other words, each backdooring party would keep their evil seedingfor themselfs. By using cross-domain ECDH, we exploit this fact and can negotiate a strong secret,even with potentially backdoored EC curves.

This is for the negotiated session keys. The persona keys (used for signing) are still generated using a single curve.But you may use cross-doamin ECDH with RSA personas now, by specifying

...ecdh-rsa...

in the config.

First, add to your~/.gnupg/options file the following line:

keyid-format long

Next, there are two possible ways to integrateopmsg into your MUA. For coolMUAs likemutt, you may build a dedicated.muttrc by adding:

# Add a header so to easy pick opmsg via procmail rulesmy_hdr X-opmsg: version1set pgp_long_ids# use this listing mode if the 'name' aliases are a substring of the email address# to avoid huge listingsset pgp_list_pubring_command="/usr/local/bin/opmsg --listpgp --short --name %r"# otherwise, skip the --name option to list all personas#set pgp_list_pubring_command="/usr/local/bin/opmsg --listpgp --short"set pgp_encrypt_sign_command="/usr/local/bin/opmsg --encrypt '%r' -i %f"set pgp_encrypt_only_command="/usr/local/bin/opmsg --encrypt '%r' -i %f"set pgp_decrypt_command="/usr/local/bin/opmsg --decrypt -i %f"set pgp_verify_command="/usr/local/bin/opmsg --decrypt -i %f"# or set to "^opmsg: SUCCESS\.$" - only required for newer mutt versions#unset pgp_decryption_okay

and work with your mails as you would it withPGP/GPG before. If youuse a mix ofGPG andopmsg peers, its probably wise to createa dedicated.muttrc file foropmsg and routeopmsg mails toa different inbox, so you can easily work with GPG andopmsg inparallel. Note that some mutt installs (neomutt) require the-n switchif you load your own config via-F in order to skip processing of system-wideconfig files. This would otherwise overload all of your pgp variables.

But theres also another option: Usingopmux:

set pgp_long_ids# OPMUX_MUA env setting is optional and only required if you use 'pgp_decryption_okay' in newer muttsset pgp_decode_command="OPMUX_MUA=mutt /usr/local/bin/opmux --passphrase-fd 0 --quiet --batch --output - %f"set pgp_verify_command="OPMUX_MUA=mutt /usr/local/bin/opmux --quiet --batch --output - --verify %s %f"set pgp_decrypt_command="OPMUX_MUA=mutt /usr/local/bin/opmux --passphrase-fd 0 --quiet --batch --output - %f"set pgp_encrypt_only_command="/usr/local/bin/opmux --batch --quiet --output - --encrypt \                              --textmode --armor --always-trust -r '%r' %f"set pgp_encrypt_sign_command="/usr/local/bin/opmux --passphrase-fd 0 --batch --quiet --textmode \                  --output - --encrypt --sign %?a?-u %a? --armor --always-trust -r '%r' %f"set pgp_list_pubring_command="/usr/local/bin/opmux --batch --quiet --with-colons --list-keys %r"# Be sure to not override it later on. This regex may also be unset.set pgp_decryption_okay="^opmux: SUCCESS\.$"

opmux is a wrapper foropmsg andgpg, which transparently forwards encryption and decryptionrequests to the right program, by checking message markers and persona ids.This way you may use youropmsg andgpg setup in parallel and the correct (de)crypt program isautomagically invoked. When you send a Mail and anopmsg persona is found for the destination,opmsg is used for encryption, otherwisegpg is used.This requires your personas to be properly--linked or having a validmy_id in youropmsg config.

Forenigmail or other MUAs you would just configure the gpg-path to be/path/to/opmux and youare done (but dont forget thekeyid-format long from the first step).

opmux prefers thegpg2 over thegpg binary if both gpg versions are installed. If youhave both gpg versions installed in parallel but for whatever reason want to work with your (old) gpg1 keys,you have to change the call order inopmux.cgpg() function.

All this however is just for convenience. The more GUI and layering you add to youropmsg setup, the more chance you have to use wrong destination or source personas. Sobe sure to thoroughly test your setup. Again, make sure your personas are properly linkedand you have a clean default persona id assigned in the config.

Sinceversion=1.65 opmsg supports Cc/Bcc from mails, e.g. you may specify more thanone-E persona recipient. However if you used to Cc messages to yourself forarchiving, you must not use--burn because in fact you are referencing sessionkeys that were initially generated for someone else. Then at times when this peersend you encrypted messages, you will miss that key.

Please note that in general using crypted mails and Cc is leaking privacy, asthe destination personas see whats in your keystore and which key ids you arereferencing. Its also asking for headache if you did not set up your keystore properly(linking personas and keeping the link ids up to date, removing dead personas etc.)

If you are operating, you may also consider a dedicated account (machine) with a dedicated opmsgsetup so that you dont accidently sign operational messages with source personas thatlink to a publically known profile. Deniable messages wont help in that case.

You need to setp up your local~/.opmsg/config to reflectthe source persona you are using when sending your mail viamutt,unless you specify it via-P on the commandline or used--link:(linking personas is recommended, see above)

# opmsg sample config# 1 or 2. Default is 2. The KDF in version=2 is hardened against evil maid attacks.# Only use version=2 if you know your peer uses opmsg >= 1.60 that can handle version=2.# Your peer then automatically chooses right version. Theres no config change needed# for your peer.version=2# Using the long format optimizes keystore loading, as an exact lookup takes place,# and  searching the keystore is avoided.# Also see 'linking personas' in README. It is recommended to use different ID# for each communication peer.my_id = 50973f3cfc3e0f3f1a7d4047aa6fa7645510f3b4ddc486a4b72bcacdf3aad570# defaultrsa_len = 4096# defaultdh_plen = 2048calgo = aes128ctr# the ID output format (default)idformat = splitnew_dh_keys = 3# EC curve to be used for EC personas (prefered since its faster)# Default. Other choices: secp521r1 (be aware: NIST curve!), brainpoolP320t1, brainpoolP384r1,# brainpoolP384t1, brainpoolP512r1, brainpoolP512t1curve = brainpoolP320r1# Check on decrypt whether the sender (src-id) used a kex-id that was once sent to him# as a dst-id.# This allows you detect cross-references for people using different src personas to# to contact a single persona of yours. This way you can detect/enforce isolation.# By default its disabled.peer_isolation=1

$ opmsg -C inv -Dopmsg: version=1.64 -- (C) 2015 opmsg-team: https://github.com/stealth/opmsgopmsg: Invalid crypto algorithm. Valid crypto algorithms are:opmsg: aes128cbc (default)opmsg: aes128cfbopmsg: aes128ctropmsg: aes128gcmopmsg: aes256cbcopmsg: aes256cfbopmsg: aes256ctropmsg: aes256gcmopmsg: bfcbcopmsg: bfcfbopmsg: cast5cbcopmsg: cast5cfbopmsg: nullopmsg: FAILED.

$ opmsg --list --shortopmsg: version=1.2 -- (C) 2015 opmsg-team: https://github.com/stealth/opmsgopmsg: persona list:opmsg: Successfully loaded 1 personas.opmsg: (id)     (name)  (has-RSA-priv)  (#DHkeys)opmsg: 1cb7992f96663853 stealth 1       0opmsg: SUCCESS.

Creating a detached signature for a file:

$ echo foo>foo$ opmsg --sign -i foo --persona 1cb7992f96663853|tee -a foo.signopmsg: version=1.2 -- (C) 2015 opmsg-team: https://github.com/stealth/opmsgopmsg: detached file-signing by persona 1cb7992f96663853opmsg: SUCCESS.-----BEGIN OPMSG-----version=1-----BEGIN SIGNATURE-----U822A12k1IZiWqRKAr6uLKT/7HGR4inKpkqzz49xLNjBf4mo91HUxcPMFGQTDB/MbE9HqtdCgHNexfIyGCC6Jb6egt2D70nIyhWfksW9KljdqwQzUbXp9CubxRAz5EqTS0n0ze092LuXxV4SuKV628CTBr5siIcfza6g3Sfh+vg=-----END SIGNATURE-----rythmz=sha256:sha256:sha256:null:DOauqyrqoH4zslO4gr3FFI7EMbcLtRzUsrc-id=1cb7992f966638531d33e59e83cd054295fb8016e5d9e35fb409630694571abadst-id=1cb7992f966638531d33e59e83cd054295fb8016e5d9e35fb409630694571abakex-id=00000000-----BEGIN OPMSG DATA-----b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c-----END OPMSG-----

Verifying it:

$ sha256sum foob5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c  foo$ opmsg -V foo -i foo.signopmsg: version=1.2 -- (C) 2015 opmsg-team: https://github.com/stealth/opmsgopmsg: verifying detached fileopmsg: GOOD signature and hash via persona 1cb7992f96663853 1d33e59e83cd0542 95fb8016e5d9e35f b409630694571abaopmsg: SUCCESS.$ opmsg -V foo -i foo.sign --shortopmsg: version=1.2 -- (C) 2015 opmsg-team: https://github.com/stealth/opmsgopmsg: verifying detached fileopmsg: GOOD signature and hash via persona 1cb7992f96663853opmsg: SUCCESS.

If you care about meta data collection and want to reduce your data-trackseven further, check outdrops.drops is a p2p transport network foropmsg. It allows you to anonymouslydrop end2end encrypted op-messages without leaking meta-data such as mail headers.