drwhax / libotr-ci-test Goto Github PK
View Code? Open in Web Editor NEWtravis-ci
License: GNU General Public License v2.0
travis-ci
License: GNU General Public License v2.0
Off-the-Record Messaging Library and Toolkit v4.0.0, 4 Sep 2012 This is a library and toolkit which implements Off-the-Record (OTR) Messaging. OTR 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. For more information on Off-the-Record Messaging, see https://otr.cypherpunks.ca/ LIBRARY USAGE 1. Initialization Before you call any other libotr routine, you need to initialize the library. The easiest way to do that is to include proto.h, and use the macro: OTRL_INIT; somewhere early in your program. This should be called only once. You will also need an OtrlUserState. An OtrlUserState encapsulates the list of known fingerprints and the list of private keys, so it should be "one per user". Many OTR-enabled programs (such as IM clients) only have a single user, so for them, you can just create a single one, and use it thoughout. Create an OtrlUserState as follows: userstate = otrl_userstate_create(); If you need to free an OtrlUserState: otrl_userstate_free(userstate); To read stored private keys: otrl_privkey_read(userstate, privkeyfilename); To read stored instance tags: otrl_instag_read(userstate, instagfilename); To read stored fingerprints: otrl_privkey_read_fingerprints(userstate, fingerprintfilename, add_app_info, add_app_info_data); add_app_info is a function that will be called in the event that a new ConnContext is created. It will be passed the add_app_info_data that you supplied, as well as a pointer to the new ConnContext. You can use this to add application-specific information to the ConnContext using the "context->app" field, for example. If you don't need to do this, you can pass NULL for the last two arguments of otrl_privkey_read_fingerprints. 2. Setting up the UI functions You need to let the library know how to do any UI it might require (error messages, confirming new fingerprints, etc.). To this end, you need to define a number of UI functions, and collect them in a OtrlMessageAppOps struct. The first parameter of every UI function is "void *opdata". This is a pointer you pass to the library, and it will pass back (opaquely) to the UI functions when it calls them. You can use this to keep track of state or any other information. You will need to include proto.h and message.h, and you can find a list of the UI functions in message.h. 3. Sending messages When you have a message you're about to send, you'll need to know four things: you account name, the protocol id, the name of the recipient, their instance tag, and the message. OTR protocol version 3 introduces the notion of "instance tags." A client may be logged into the same account multiple times from different locations. An instance tag is intended to differentiate these clients. When sending a message, you may also specify a particular instance tag, or use meta instance tags like OTRL_INSTAG_MOST_SECURE. The protocol id is just a unique string that is used to distinguish the user foo on AIM from the user foo on MSN, etc. It can be anything you like, so long as you're consistent, but if you've got nothing better to use, you may as well use the ids from gaim. (Programs that use the same protocol ids can share fingerprint and private key files.) The gaim protocol id for AIM/ICQ is "prpl-oscar". Note that a name does not uniquely identify a user (as shown by the "foo" example above). Even if you know both the name and the protocol, it may not identify the user, since there may be multiple "foo" users on IRC, on different servers. But the *three* items (your account name, protocol id, their name) _must_ uniquely identify a user, so your account name needs to include any network identifier, such as a server name. Examples would be "[email protected]" or "[email protected]". Protocols such as AIM that do not have separate networks can just use "foo", of course. To encrypt the message (if necessary; the library keeps track of which users you have secure connections to, so you should *always* call this next function), simply do this: gcry_error_t err; char *newmessage = NULL; err = otrl_message_sending(userstate, &ui_ops, opdata, accountname, protocolid, recipient_name, instag, message, tlvs, &newmessage, fragPolicy, contextp, add_app_info, add_app_info_data); add_app_info and add_app_info_data are as above, and may be NULL. tlvs should usually be NULL. If it's not, then it points to a chain of OtrlTLVs which represent machine-readable data to send along with this message. If contextp is not NULL, it will be set to the context that was used for sending the message. If err is non-zero, then the library tried to encrypt the message, but for some reason failed. DO NOT send the message in the clear in that case. If newmessage gets set by the call to something non-NULL, then you should replace your message with the contents of newmessage, and send that instead. Once the message is encrypted, it may still be too large to send over the network in a single piece. To check the maximum message size and break your message into fragments if necessary, do this: gcry_error_t err; char *extrafragment = NULL; err = otrl_message_fragment_and_send(&ui_ops, opdata, context, message, fragmentPolicy, extrafragment); fragmentPolicy determines which, if any, fragments to return instead of sending them immediately. For example, you may wish to send all fragments except the last one, which is handled differently. Valid policies may be found in proto.h. If err returns a nonzero value from fragment_and_send, the application tried to break your message into fragments but failed for some reason. You may still attempt to send the original message, but it might be rejected if it too large. When you're done with newmessage, you must call otrl_message_free(newmessage) 4. Receiving messages Receiving messages is similarly straightforward. Again, you need to know four things: your account name, the protocol id, the sender's name, and the message. int ignore_message; char *newmessage = NULL; ignore_message = otrl_message_receiving(userstate, &ui_ops, opdata, accountname, protocolid, sender_name, message, &newmessage, &tlvs, contextp, add_app_info, add_app_info_data); add_app_info and add_app_info_data are as above, and may be NULL. If contextp is not NULL, it will be set to the context that was used for receiving the message. If otrl_message_receiving returns 1, then the message you received was an internal protocol message, and no message should be delivered to the user. If it returns 0, then check if newmessage was set to non-NULL. If so, replace the received message with the contents of newmessage, and deliver that to the user instead. You must call otrl_message_free(newmessage) when you're done with it. If otrl_message_receiving returns 0 and newmessage is NULL, then this was an ordinary, non-OTR message, which should just be delivered to the user without modification. If tlvs is set to non-NULL, then there is machine-readable data that was sent along with this message. Call otrl_tlv_free(tlvs) when you're done dealing with it (or ignoring it). 5. Socialist Millionaires' Protocol The Socialist Millionaires' Protocol (SMP) is a way to detect eavesdropping and man-in-the-middle attacks without requiring users to work with fingerprints. This feature was added to OTR starting in version 3.1.0. To learn how to modify your application to use SMP, read the UPGRADING file. TOOLKIT Along with the library, this package comes with the OTR Messaging Toolkit. This toolkit is useful for analyzing and/or forging OTR messages. Why do we offer this? Primarily, to make absolutely sure that transcripts 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 the key was correct. - 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 sender_instance receiver_instance flags keyid 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. NOTES Please send your bug reports, comments, suggestions, patches, etc. to us at the contact address below. In otrl_message_sending, specifying an instance tag allows you to send a message to a particular session of a buddy who is logged in multiple times with an otr-enabled client. The OTRL_INSTAG_RECENT_RECEIVED meta-instance relies on the time that libotr processed the most recent message. Meta- instance tags resolve to actual instance tags before a message is sent. An instant messaging network may not agree on which session of the remote party is the most recent, e.g., due to underlying network race conditions. If the behaviour of an instant messaging network is to only deliver to the most recent, and libotr and the network disagree on which session is the most recent, the other party will not process the given message. That is, the instant messaging network will deliver the message to the session whose actual instance tag does not match the addressed instance tag. Also note that OTRL_INSTAG_BEST also prefers more recent instance tags in the case of multiple instances with the same "best" status (most secure). In this case, the most recent has a resolution of one second. If otrl_message_sending is called with an original_msg that contains the text "?OTR?", this is a signal to initiate or refresh an OTR session. There is currently no way to indicate if this text was actually typed in by a user and part of a conversation (e.g., someone communicating instructions on how to refresh OTR). In the future, we may allow a policy to specify whether "?OTR?" is a signal to start OTR, or just an ordinary message for encrypted and unencrypted conversations. MAILING LISTS There are three mailing lists pertaining to Off-the-Record Messaging: otr-announce: http://lists.cypherpunks.ca/mailman/listinfo/otr-announce/ *** All users of OTR software should join this. *** It is used to announce new versions of OTR software, and other important information. otr-users: http://lists.cypherpunks.ca/mailman/listinfo/otr-users/ Discussion of usage issues related to OTR Messaging software. otr-dev: http://lists.cypherpunks.ca/mailman/listinfo/otr-dev/ Discussion of OTR Messaging software development. LICENSE The Off-the-Record Messaging library (in the src directory) is covered by the following (LGPL) license: Off-the-Record Messaging library Copyright (C) 2004-2012 Ian Goldberg, Rob Smits, Chris Alexander, Willy Lew, Lisa Du, Nikita Borisov <[email protected]> This library is free software; you can redistribute it and/or modify it under the terms of version 2.1 of the GNU Lesser General Public License as published by the Free Software Foundation. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. There is a copy of the GNU Lesser General Public License in the COPYING.LIB file packaged with this library; if you cannot find it, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA The Off-the-Record Messaging Toolkit (in the toolkit directory) is covered by the following (GPL) license: Off-the-Record Messaging Toolkit Copyright (C) 2004-2012 Ian Goldberg, Rob Smits, Chris Alexander, Nikita Borisov <[email protected]> This program is free software; you can redistribute it and/or modify it under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. There is a copy of the GNU General Public License in the COPYING file packaged with this toolkit; if you cannot find it, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA CONTACT To report problems, comments, suggestions, patches, etc., you can email the authors: Ian Goldberg, Rob Smits, Chris Alexander, Lisa Du, Nikita Borisov <[email protected]> For more information on Off-the-Record Messaging, visit https://otr.cypherpunks.ca/
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.