otr_toolkit(1) [debian man page]
OTR_PARSE(1) General Commands Manual OTR_PARSE(1) NAME
otr_parse, otr_sesskeys, otr_mackey, otr_readforge, otr_modify, otr_remac - Process Off-the-Record Messaging transcripts SYNOPSIS
otr_parse otr_sesskeys our_privkey their_pubkey otr_mackey aes_enc_key otr_readforge aes_enc_key [newmsg] otr_modify mackey old_text new_text offset otr_remac mackey flags snd_keyid rcv_keyid pubkey counter encdata revealed_mackeys DESCRIPTION
Off-the-Record (OTR) Messaging allows you to have private conversations over IM by providing: - Encryption - No one else can read your instant messages. - Authentication - You are assured the correspondent is who you think it is. - Deniability - The messages you send do not have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, during a conversation, your correspondent is assured the messages he sees are authentic and unmodified. - Perfect forward secrecy - If you lose control of your private keys, no previous conversation is compromised. The OTR Toolkit is useful for analyzing and/or forging OTR messages. Why do we offer this? Primarily, to make absolutely sure that tran- scripts of OTR conversations are really easy to forge after the fact. [Note that during an OTR conversation, messages can't be forged without real-time access to the secret keys on the participants' computers, and in that case, all security has already been lost.] Easily- forgeable transcripts help us provide the "Deniability" property: if someone claims you said something over OTR, they'll have no proof, as anyone at all can modify a transcript to make it say whatever they like, and still have all the verification come out correctly. Here are the six programs in the toolkit: - otr_parse - Parse OTR messages given on stdin, showing the values of all the fields in OTR protocol messages. - otr_sesskeys our_privkey their_pubkey - Shows our public key, the session id, two AES and two MAC keys derived from the given Diffie-Hellman keys (one private, one public). - otr_mackey aes_enc_key - Shows the MAC key derived from the given AES key. - otr_readforge aes_enc_key [newmsg] - Decrypts an OTR Data message using the given AES key, and displays the message. - If newmsg is given, replace the message with that one, encrypt and MAC it properly, and output the resulting OTR Data Message. This works even if the given key was not correct for the original message, so as to enable complete forgeries. - otr_modify mackey old_text new_text offset - Even if you can't read the data because you don't know either the AES key or the Diffie-Hellman private key, but you can make a good guess that the substring "old_text" appears at the given offset in the message, replace the old_text with the new_text (which must be of the same length), recalculate the MAC with the given mackey, and output the resulting Data message. - Note that, even if you don't know any text in an existing message, you can still forge messages of your choice using the otr_readforge command, above. - otr_remac mackey flags snd_keyid rcv_keyid pubkey counter encdata revealed_mackeys - Make a new OTR Data Message, with the given pieces (note that the data part is already encrypted). MAC it with the given mackey. SEE ALSO
Off-the-Record Messaging, at http://www.cypherpunks.ca/otr/ <http://www.cypherpunks.ca/otr/> AUTHOR
otr_toolkit was written by the OTR Dev Team <otr@cypherpunks.ca>. October 27, 2005 OTR_PARSE(1)
Check Out this Related Man Page
pgpverify(8) System Manager's Manual pgpverify(8) NAME
pgpverify - cryptographically verify Usenet control messages SYNOPSIS
pgpverify [ -test ] DESCRIPTION
The pgpverify program reads (on standard input) a Usenet control message that has been cryptographically signed using the signcontrol pro- gram. pgpverify then uses the pgp program to determine who signed the control message. If the control message was validly signed, pgpver- ify outputs (to stdout) the User ID of the key ID that signed the message. OPTIONS
The ``-test'' flag causes pgpverify to print out the input it is passing to pgp (which is a reconstructed version of the input that suppos- edly created the control message) as well as the output of pgp's analysis of the message. EXIT STATUS
pgpverify returns the follow exit statuses for the following cases: 0 The control message had a good PGP signature. 1 The control message had no PGP signature. 2 The control message had an unknown PGP signature. 3 The control message had a bad PGP signature. 255 A problem occurred not directly related to PGP analysis of signature. AUTHOR
David C Lawrence <tale@isc.org> ENVIRONMENT
pgpverify does not modify or otherwise alter the environment before invoking the pgp program. It is the responsibility of the person who installs pgpverify to ensure that when pgp runs, it has the ability to locate and read a PGP key file that contains the PGP public keys for the appropriate Usenet hierarchy administrators. SEE ALSO
pgp(1) NOTES
Historically, Usenet news server administrators have configured their news servers to automatically honor Usenet control messages based on the originator of the control messages and the hierarchies for which the control messages applied. For example, in the past, David C Lawrence <tale@uunet.uu.net> always issued control messages for the "Big 8" hierarchies (comp, humanities, misc, news, rec, sci, soc, talk). Usenet news administrators would configure their news server software to automatically honor newgroup and rmgroup control messages that originated from David Lawrence and applied to any of the Big 8 hierarchies. Unfortunately, Usenet news articles (including control messages) are notoriously easy to forge. Soon, malicious users realized they could create or remove (at least temporarily) any Big 8 newsgroup they wanted by simply forging an appropriate control message in David Lawrence's name. As Usenet became more widely used, forgeries became more common. The pgpverify program was designed to allow Usenet news administrators to configure their servers to cryptographically verify control mes- sages before automatically acting on them. Under the pgpverify system, a Usenet hierarchy maintainer creates a PGP public/private key pair and disseminates the public key. Whenever the hierarchy maintainer issues a control message, he uses the signcontrol program to sign the control message with the PGP private key. Usenet news administrators configure their news servers to run the pgpverify program on the appropriate control messages, and take action based on the PGP key User ID that signed the control message, not the name and address that appear in the control message's From or Sender headers. Thus, using the signcontrol and pgpverify programs appropriately essentially eliminates the possibility of malicious users forging Usenet control messages that sites will act upon, as such users would have to obtain the PGP private key in order to forge a control message that would pass the cryptographic verification step. If the hierarchy administrators properly protect their PGP private keys, the only way a malicious user could forge a validly-signed control message would be by breaking the RSA encryption algorithm, which (at least at this time) is believed to be an NP-complete problem. If this is indeed the case, discovering the PGP private key based on the PGP public key is computationally impossible for PGP keys of a sufficient bit length. <URL:ftp://ftp.isc.org/pub/pgpcontrol/> is where the most recent versions of signcontrol and pgpverify live, along with PGP public keys used for hierarchy administration. pgpverify(8)