AES-256 מול OFB: בחרו מבנה צופן VPN שלם
צופן בלוקים, גודל מפתח ומצב הם בחירות שונות. העריכו סודיות ושלמות יחד, ואז פעלו לפי מדיניות הערוץ הנתמכת.
AES-256 ו-OFB עונים על שאלות שונות, וכאן בדיוק נכשלות סקירות צופן כשמתייחסים אליהם כאפשרויות מתחרות. האחד נוקב בשם צופן בלוקים עם גודל מפתח; האחר מתאר כיצד צופן בלוקים הופך לזרם עבור הודעה ארוכה יותר. ספר הפעלה לבחירת הגנה חייב להסתכל על המבנה כולו, כולל כיצד המקבל מזהה חבילה ששונתה.
נמקו את ארבעת חלקי המבנה
כל סקירה מצטמצמת לארבע שאלות: איזה פרימיטיב וגודל מפתח, כיצד מעבדים הודעות איתו, כיצד המקבל דוחה שינוי לא מורשה, וכיצד הפרוטוקול מנהל קלטים, מפתחות ותוקפם. רשימה של שמות מוכרים עונה רק על הראשונה. השנייה והשלישית הן המקום שבו נמצאים ההבדלים האמיתיים, והרביעית היא המקום שבו מימושים נפרדים בשקט. שאלו אותן בסדר הזה ורשמו את התשובות.
OFB מופיע בין מצבי הסודיות בפרסום NIST על מצבי צופן בלוקים, והסודיות היא כל מה שהוא מספק. פרוטוקול שמצמיד מצב הצפנה ל-MAC נפרד חייב להרכיב אותם נכון, ושם אלגוריתם אינו מוכיח את ההרכבה הזו. לכן שם המצב לבדו אינו יכול להכריע החלטת פריסה.
השאלה הרביעית היא זו שמפעיל יכול באמת לאמת במערכת הפועלת.
העדיפו מבנה מאומת
הצפנה מאומתת מספקת סודיות ושלמות יחד, ומבני AEAD גם מגינים על נתונים משויכים מפני שינוי בלי להצפין אותם. זו תכונה של הגנת חבילות, ואין לה קשר לשאלה אם אדם התחבר בהצלחה.
ה-הנחיות Netgate להגדרות ההצפנה של OpenVPN מפנה לאפשרויות AEAD, ובהן AES-GCM, עבור ערוץ הנתונים, וזו סוג המדיניות הנתמכת שיש לפעול לפיה. השתמשו בבחירות שהגרסה המותקנת ולקוחות העמית תומכים בהן, במקום להעתיק דירוג מצבים היסטורי לפריסה חדשה. תאימות לאחור, מנועי הצפנה ותמיכת offload מגבילים את מה שבאמת זמין.
מבנה נתמך מנצח הרכבה מתוחכמת בכל פעם.
קראו את התוצאה המוסכמת, לא את ההצעה
צופן שמופיע ברשימה מקובלת לא אומר דבר על ההפעלה הנוכחית. קראו את הגנת ערוץ הנתונים המוסכמת מהלקוח או מהשער, ואז השוו אותה למדיניות שרציתם לאכוף. תצורה שעדיין מפרטת אפשרות היסטורית עבור עמית ישן היא החלטת תאימות, לא הצהרה על ההפעלה שלפניכם.
openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'
בשער הפלט המקביל הוא אסוציאציית האבטחה או פרטי ההצפנה של החיבור, בהתאם לפלטפורמה. בשני המקרים ההצעה והתוצאה הן עובדות שונות. רשימה שכוללת אפשרות היסטורית עבור עמית ישן אינה אומרת שכל הפעלה משתמשת בה, וההפעלה שכן משתמשת בה היא מה שהייתם צריכים לדעת.
רשמו את שתי העובדות יחד, עם התאריך וגרסת הלקוח.
מדדו רק את מה שאפשר להשוות
התפוקה תלויה בחומרה של הקצוות, במימוש, בהאצה, בגדלי החבילות ובתצורה שנבחרה. לא אורך המפתח ולא המילה OFB יגידו לכם איזו פריסה תהיה מהירה יותר. לכן מדידה מאתר אחר היא לכל היותר רמז על חומרה שמישהו אחר מחזיק. המספרים שלכם מתחילים בקצוות שלכם.
להשוואה מורשית החזיקו את הקצוות, את עומס העבודה ואת המדיניות הנדרשת קבועים, ורשמו את ההגנה המוסכמת יחד עם גרסאות המימוש. אחר כך שפטו את התוצאה לפי האם היישום סיים, כמה איבד ומה הקצוות עשו, במקום להסיק עלות הצפנה מבדיקת מהירות אחת. מספר שהופק בתנאים אחרים הוא סיפור, לא מדידה.
אם עמית ישן אינו יכול לעמוד במדיניות, זו החלטת תאימות לבעליו.
השאירו את השלמות מחוץ לעסקה
כיבוי בדיקות שלמות או קבלת שרת לא מאומת אינם אופטימיזציית ביצועים ואינם תיקון תאימות. הם משנים את תכונת האבטחה שלשמה נבחר המבנה. כך גם הרחבת רשימת הצפנים המקובלת עד שעמית ישן מתחבר: החיבור מצליח והמדיניות כבר אינה קיימת.
רשמו את המבנה המקובל ואת בעליו בספר ההפעלה, כדי שהשינוי הבא יתחיל מהחלטה ולא מהעדפה.
מה שאתם רוצים הוא מדיניות ששני הקצוות יכולים לאכוף. הוויכוח על איזה שם הוא החזק ביותר הוא שיחה אחרת, והוא בדרך כלל נגמר בלי החלטה.