מדוע חבילת VPN מוצפנת עשויה לעלות פחות ממה שנדמה לכם

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

התסמין: הפרופיל האיטי אינו זה שמוצפן

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

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

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

ספרו פעולות, לא תוויות

בניית AEAD, כמתואר ב-RFC 5116, נותנת למימוש ממשק יחיד שמחזיר את הטקסט המוצפן ואת התג יחד. AES-GCM הוא דוגמה אחת: הצפנה במצב מונה משולבת עם מאמת Galois. הממשק אינו הופך את השלמות לחינמית; הוא הופך את השילוב למוגדר היטב, וזה מה שמאפשר למימוש למטב את הזוג כיחידה אחת.

Separate authentication path:
  payload -> independent HMAC -> framed packet

AEAD path:
  payload -> authenticated encryption with tag -> framed packet

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

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

מה המצב שנקבע באמת מאפשר

ב-Community OpenVPN, צופן נתונים מסוג AEAD פירושו שהאפשרות auth אינה תורמת עוד HMAC נפרד משלה לערוץ הנתונים. ההפניה לאפשרות ההצפנה מתארת את ההיקף הזה, וזו הסיבה ששתי קונפיגורציות שנראות דומות בקובץ טקסט יכולות להיבדל בעבודה לכל חבילה.

קראו את המצב שנקבע ולא את רשימת המשאלות. רשימת צפנים מותרים ושם חבילת TLS לא אומרים לכם אילו פעולות רצות על המטען, ושורת cipher ישנה עשויה שלא לתאר מה בחר החיבור הנוכחי.

openvpn --show-ciphers | head -20
sudo grep -E 'cipher|auth' /etc/openvpn/server.conf

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

מדדו את העומס שאתם באמת מריצים

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

openssl speed -evp aes-256-gcm
openssl speed -evp sha1

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

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

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