מפתח אחרי ה־#: איך קישורים משותפים משאירים את השרת בחוץ

שיתוף בדרך כלל פירושו למסור את המילים שלכם למי שמאחסן את הקישור. הקישורים המשותפים של Undergrove בנויים כך שהשרת מחזיק עותק שהוא לא יכול לקרוא. הטריק ישן ופשוט, ויש לו גבולות שכדאי להכיר.

החלק שאחרי ה־#

כשמשתפים שיחה, הדפדפן שלכם יוצר מפתח אקראי חדש, מצפין עותק עם AES-GCM ומעלה רק את הטקסט המוצפן. המפתח נכנס לקישור, אחרי ה־#. דפדפנים לא שולחים את החלק הזה של הכתובת לשרת כשהם טוענים עמוד, כך שהמפתח מגיע לאדם שאליו שלחתם את הקישור, ואף פעם לא אלינו.

אנחנו שומרים את הטקסט המוצפן ליום אחד, ל־7 או ל־30 ימים. אנחנו רואים את המזהה שלו, את הגודל שלו ומתי הוא נוצר ונפתח. העמוד שפותח אותו מביא את הטקסט המוצפן, קורא את המפתח משורת הכתובת ומפענח אותו בלשונית.

גם סיסמה

קישור יכול לדרוש גם סיסמה. במקרה כזה, המפתח שפותח את העותק נגזר משניהם: הסיסמה נמתחת עם PBKDF2-SHA256 ב־600,000 איטרציות ומשולבת עם המפתח של הקישור באמצעות HKDF. לא הקישור ולא הסיסמה פותחים אותו לבדם, והסיסמה נבדקת בלשונית מול העותק שכבר נמצא שם, כך שאנחנו אף פעם לא רואים אותה.

פתיחה חד־פעמית, ומועדי פתיחה

קישור יכול להיפתח פעם אחת בלבד. השרת מוחק את העותק שלו ברגע שהוא נקרא לראשונה ושומר רק את הזמן שבו הוא נפתח, כך שהקישור יכול לומר שכבר נעשה בו שימוש, ולא שהוא מעולם לא היה קיים. לפני ההבאה, העמוד מבקש אישור, כדי שתצוגה מקדימה של קישור באפליקציית צ׳אט לא תנצל אותו.

קישור יכול גם להיפתח רק מתאריך מסוים. עד אז השרת מסרב למסור את הטקסט המוצפן. זה השרת שעומד במילה שלו, לא קריפטוגרפיה: העותק כבר שמור, והמפתח שלו כבר נמצא בקישור.

ממה קישור לא יכול להגן

• כל מי שיש לו את הקישור המלא יכול לקרוא את העותק. כדאי להתייחס אליו כמו אל השיחה עצמה.
• אפליקציות צ׳אט ודואר אלקטרוני שומרות את ההודעות שאתם שולחים, כולל קישורים, עם ה־# והכול.
• העמוד שמפענח את העותק הוא קוד שאנחנו מגישים. /verify משווה את הקוד הזה למניפסט שפורסם של ה־build.

עמוד הפרטיות מפרט מה נשמר לכל קישור, ומודל האיומים מפרט מי יכול לראות מה.