Changeset 3ad8036
- Timestamp:
- 2010-10-04T21:55:18Z (14 years ago)
- Branches:
- master
- Children:
- 508588a
- Parents:
- 88de0c9
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/user-guide/commands.xml
r88de0c9 r3ad8036 416 416 417 417 <para> 418 If an SMP challenge has already been received from the given user, responds with the specified secret. Otherwise, a challenge for the secret will be sent. If the protocol succeeds (i.e. both parties gave the same secret), the fingerprint will be trusted. 418 If an SMP challenge has been received from the given user, responds with the specified secret/answer. Otherwise, sends a challenge for the given secret. 419 </para> 420 421 <para> 422 Note that there are two flavors of SMP challenges: "shared-secret" and "question & answer". This command is used to respond to both of them, or to initiate a shared-secret style exchange. Use the <emphasis>otr smpq</emphasis> command to initiate a "Q&A" session. 423 </para> 424 425 <para> 426 When responding to a "Q&A" challenge, the local trust value is not altered. Only the <emphasis>asking party</emphasis> sets trust in the case of success. Use <emphasis>otr smpq</emphasis> to pose your challenge. In a shared-secret exchange, both parties set their trust according to the outcome. 419 427 </para> 420 428 … … 433 441 434 442 <para> 435 When initiating SMP, this is an alternative to the 'otr smp' command. The shared secret is provided as the answer to a specific question. The question is transmitted with the initial SMP packet and used to prompt the other party. If the protocol succeeds (i.e. they give the correct answer), the fingerprint will be trusted. 443 Initiates an SMP session in "question & answer" style. The question is transmitted with the initial SMP packet and used to prompt the other party. You must be confident that only they know the answer. If the protocol succeeds (i.e. they answer correctly), the fingerprint will be trusted. Note that the answer must be entered exactly, case and punctuation count! 444 </para> 445 446 <para> 447 Note that this style of SMP only affects the trust setting on your side. Expect your opponent to send you their own challenge. Alternatively, if you and the other party have a shared secret, use the <emphasis>otr smp</emphasis> command. 436 448 </para> 437 449 -
otr.c
r88de0c9 r3ad8036 1129 1129 otrl_sm_state_free(context->smstate); 1130 1130 } else { 1131 /* SMP3 received, otrl_message_receiving will have sent SMP4 and set fp trust */ 1132 /* as noted above, fp trust SHOULD have been set by libotr. 1133 * however at least version 3.2.0 seems to forget it when 1134 * responding to an smp session that was initiated with SMP1Q 1135 * (question and answer); other cases appear to work fine. 1136 * as a workaround, we explicitly set it below. 1137 */ 1131 /* SMP3 received, otrl_message_receiving will have sent SMP4 */ 1138 1132 if(context->smstate->sm_prog_state == OTRL_SMP_PROG_SUCCEEDED) { 1139 otrl_context_set_trust(context->active_fingerprint, "smp"); 1140 irc_usermsg(irc, "smp %s: secrets proved equal, fingerprint trusted", 1141 u->nick); 1133 if(context->smstate->received_question) { 1134 irc_usermsg(irc, "smp %s: correct answer, you are trusted", 1135 u->nick); 1136 } else { 1137 irc_usermsg(irc, "smp %s: secrets proved equal, fingerprint trusted", 1138 u->nick); 1139 } 1142 1140 } else { 1143 otrl_context_set_trust(context->active_fingerprint, ""); 1144 irc_usermsg(irc, "smp %s: secrets did not match, fingerprint not trusted", 1145 u->nick); 1141 if(context->smstate->received_question) { 1142 irc_usermsg(irc, "smp %s: wrong answer, you are not trusted", 1143 u->nick); 1144 } else { 1145 irc_usermsg(irc, "smp %s: secrets did not match, fingerprint not trusted", 1146 u->nick); 1147 } 1146 1148 } 1147 1149 otrl_sm_state_free(context->smstate);
Note: See TracChangeset
for help on using the changeset viewer.