מיסור שלא לפרסום
מוטיבציה ומאפיינים כלליים > מהלכי הפרוטוקול

כדי לצמצם את חלון הזמן שבו מפתח השיחה חשוף להתקפה, מנסים להחליף אותו בתדירות הגבוהה ביותר האפשרית. במרבית המכשירים בימינו קיים מעבד די חזק המסוגל לבצע פעולות אריתמטיות במספרים ארוכים בתוך זמן מאוד קצר, כמספר מילישניות. עובדה זו מאפשרת החלפת מפתח שיחה בשיטת דיפי-הלמן לאחר כל הודעה. כל מהלך של שיתוף מפתח דורש בסך הכול שתי העלאות בחזקה מודולו מספר ראשוני גדול. אפילו התקנים בעלי משאבים מאוד נמוכים יכולים לבצע זאת מבלי שהמשתמש יבחין בעיכוב כלשהו. כדי לחסוך בהודעות הפרוטוקול מנצל את ההודעות המכילות את מסרים בין אליס ובוב כדי להעביר גם את החומר המיועד להכנת מפתח השיחה הבא. למעשה הודעה מאליס לבוב תכיל את המסר אותו היא מעוניינת להעביר לו יחד עם מפתח ציבורי חדש שישמש את בוב כדי לגזור ממנו מפתח משותף בשיטת דיפי הלמן להצפנת ההודעה הבאה וכאשר הוא מחזיר לה תגובה, הוא מצרף אליה את החלק שלו להכנת המפתח המשותף הבא וכן הלאה. כזכור מפתח השיחה הוא כפולה של המפתחות הציבוריים עם המפתחות הפרטיים הנגדיים (מודולו המספר הראשוני), לכן אין במפתח הזה כל מידע שיכול לשמש את המצותת איב אפילו שהוא מכיל מחצית מהמידע הדרוש להכנת מפתח השיחה. כל עוד המפתחות הפרטיים של שני הצדדים לא נחשפו הסוד המשותף נותר בטוח.
לצורך תיאור הפרוטוקול, נניח שאליס רוצה לשלוח את המסר "HELLO" כשהוא מוצפן לבוב. נניח שהמפתח הציבורי הטרי ביותר של אליס הוא  g^{x_{i}} אליו משויך המספר הסידורי  kIDa_{i}, נניח עוד שבוב שלח לאליס קודם לכן את המפתח הציבורי שלו  g^{y_{j}} יחד עם המזהה הייחודי שלו (המפתח האחרון של כל אחד מהם יכול להיות זה שנוצר בעת הרצת פרוטוקול AKE המתואר להלן או שהוא מפתח חדש שהתקבל במסגרת חילופי ההודעות ביניהם). היא מבצעת את המהלכים הבאים:
תחילה נוטלת את המפתח הציבורי האחרון שקיבלה מבוב  g^{y_{j}} מכפילה במפתח הפרטי שלה  x_{i} כדי לקבל את המפתח המשותף הבא  k_{ij} ומכינה את מפתח האימות הבא  mk_{i}=H(k_{ij}) (מפתח האימות מופק באמצעות פונקציית הגיבוב של המפתח המשותף) וכן מקדמת את המונה  c לצורך ההצפנה הסימטרית של גוף ההודעה. שלושת הערכים הללו יהיו חד פעמיים, איתם אליס תשתמש רק עבור הודעה אחת ואז תמחוק אותם.
כמו כן היא מייצרת מפתח דיפי-הלמן חדש; בוחרת שלם אקראי חדש  x_{i+1} שמקבל את המספר הסידורי  kIDa_{i+1} ומחשבת את  g^{x_{i+1}}.
ואז היא שולחת לבוב את המסר הבא:
במילים, אליס שולחת לבוב מסר המורכב ממספר חלקים; החלק הראשון מכיל את גוף ההודעה כשהוא מוצפן באמצעות הצופן הסימטרי במצב מונה עם המפתח והמונה שהכינה, את המפתח הציבורי שלה לצורך ההודעה הבאה, מזהי המפתחות הציבוריים שלה ושל בוב והמונה ששימש אותה להצפנת ההודעה. החלק השני מכיל את תג האימות של ההודעה שהוכן באמצעות פונקציית MAC. והחלק השלישי הוא מפתח האימות הישן שאיתו השתמשה כדי לאמת את ההודעה הקודמת ואין לה צורך בו יותר. המטרה של שליחת המפתח היא רק כדי לחשוף אותו כך שאף אחד לא יכול להוכיח בעתיד מי היה מקור ההודעה. כי אם מפתח האימות הסימטרי ידוע לכולם, כל אחד יכול להכין הודעה מזויפת ולייצר לה תג אימות מתאים עם מפתח זה, אך מרגע שהמפתח נחשף אין בזה כל הוכחה לכך שמקור ההודעה מאליס. בוב מצידו מייצר מפתח דיפי הלמן חדש מהמפתח הציבורי של אליס המסומן בתווית  kIDa_{i} והמפתח הפרטי שלו המסומן בתווית  kIDb_{i} ומקבל את מפתח ההצפנה  k_{ij} (אותו מפתח בדיוק שיצרה אליס) איתו הוא מפענח את החלק המוצפן של ההודעה  T_{a}, בודק שהיא תקינה על ידי תג האימות המצורף וקורא את ההודעה המיועדת אליו. ואותו תהליך חוזר על עצמו באופן דומה הפעם מצד בוב.
באופן תמציתי שיחת OTR יכולה להראות כך:
וכן הלאה. כאשר  E(M,k) מייצג הצפנה באמצעות AES במצב מונה.
במהלכי הפרוטוקול המתוארים מתרחש תהליך שיש המכנים אותו מחגר משונן (ראצ'ט) בדומה לכלי העבודה לחיזוק ברגים שמסתובב רק בכיוון אחד. בכל הודעה, השולח מצרף אליה את מפתח שלו להצפנת ההודעה הבאה והמקבל מצידו כאשר הוא מחזיר הודעה לשלוח הוא מצרף אליה את המפתח שלו להצפנת ההודעה הבאה וכן הלאה. כך הפרוטוקול "מסתובב" באופן חד כיווני. בכל נקודת זמן, אם התגלה מפתח שיחה אחד, אין בו די מידע המאפשר לנחש את מפתח השיחה הקודם כי הוא נוצר מחדש בתהליך דיפי-הלמן והמפתח שלפניו הושמד. כדי שאליס או בוב יהיו משוכנעים שהם מקבלים מפתח ציבורי אחד של השני ולא של מתחזה שנכנס באמצע, כל מפתח דיפי הלמן חדש מאומת באמצעות תג אימות שנגזר מהמפתח הקודם. אם המתחזה אינו יודע מהו מפתח השיחה כי הוא מעולם לא נשלח בגלוי, תהיה לו בעיה לשכנע אחד מהם שהמפתח שייך לבוב או אליס כי תג האימות יגלה  מיד אם זה נכון. במילים אחרות, תהליך האימות מתבצע בשני מישורים, תחילה מבוצע אימות מלא של המפתח הראשון המסתמך על חתימה דיגיטלית של שני הצדדים המתקשרים. במישור השני מתבצע אימות חלקי באמצעות תג אימות סימטרי המסתמך על ההנחה שמפתח השיחה הראשוני לא נחשף. וכמובן בנוסף לאמור לעיתים אחד מהצדדים ידרוש לבצע את פרוטוקול SMP המתואר כדי לסכל ליתר ביטחון התקפת אדם באמצע.
ממהלכי הפרוטוקול המתוארים הושמטו מספר אלמנטים הקשורים בניהול ותחזוקה כמו תוויות, דגלים ושדות מידע מיוחדים. למעשה פרוטוקול OTR תומך בשמונה סוגי הודעות מיוחדות שקשורות בניהול ותחזוקה: הודעת אפס שמורה שממנה מתעלמים בדרך כלל, הודעת ניתוק או הודעת סיום שיחה, שש הודעות שונות המוקדשות לפרוטוקול SMP המתואר להלן וכן הודעת מפתח נוסף המיועדת להעברת מפתחות הצפנה סימטריים מאחד לשני. כמו כן כחלק ממהלכי הפרוטוקול שני הצדדים מחויבים לנהל מפתחות שיחה ומפתחות אימות, להיפטר מהם כאשר פג תוקפם או במידה שחלק מההודעות טרם הגיעו ליעדן לאחסן אותם זמנית במקום שמור. חיסרון בולט של הפרוטוקול הוא הצורך בפנקסנות והוא נעשה מסורבל במיוחד כאשר לא כל המשתתפים בשיחה מקוונים. למשל אם צד אחד שולח הודעה לצד השני שנמצא במצב אוף ליין ההודעה לא מגיעה מיד ליעדה, לכן השולח חייב לשמור את המפתחות המתאימים עד שיתקבל אישור שההודעה נקראה.