AES-GCM או ChaCha20-Poly1305: בחירת צופן הנתונים של VPN

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

אותה עבודה, ליבות שונות

שני המבנים נותנים סודיות ושלמות במעבר אחד ומאמתים נתונים נלווים, ולכן פרוטוקולי VPN משתמשים בהם לערוץ הנתונים. ההבדל הוא בפנים: AES-GCM הוא צופן הבלוקים AES במצב מונה עם מאמת פולינומיאלי מעל GF(2^128), ואילו ChaCha20-Poly1305 הוא צופן זרם עם מפתח של 256 סיביות ומאמת חד-פעמי נפרד.

מה שחשוב מבחינה תפעולית משותף: שניהם נכשלים באופן קטסטרופלי בשימוש חוזר ב-nonce, שניהם דורשים ניהול מרחב nonce לכל מפתח, ואף אחד מהם אינו מתקן עמית שמאמת את הדבר הלא נכון. פרופיל שאומר AES-256-GCM אינו בטוח יותר מזה שאומר CHACHA20-POLY1305; שניהם חזקים כשהמימוש נכון.

היכן AES-GCM מנצח

ל-AES יש הוראות ייעודיות ברוב המעבדים המודרניים: AES-NI ב-x86, הרחבות ההצפנה ב-ARMv8 ומקבילות בעיצובי POWER ו-RISC-V עדכניים. כשהן קיימות, GCM מריץ כמה בלוקים במקביל לכל מחלקת מחזור, והמימוש בתוכנה הופך ללא רלוונטי. זהו המקרה השכיח בשרתים, במחשבים שולחניים ובטלפונים הנוכחיים, ולכן העצה להשתמש ב-AES היא ברירת מחדל סבירה במרכז נתונים.

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

בדוק מה התהליך באמת רואה, לא מה המעבד תומך בו: grep -o aes /proc/cpuinfo | head -1 בלינוקס, או דגל התכונה המקביל במודל המעבד של ההיפרוויזור.

היכן ChaCha20-Poly1305 מנצח

ChaCha20 מהיר בתוכנה ניידת כי הוא משתמש רק בחיבור, סיבוב ו-XOR, והמימושים שלו נמנעים מלכתחילה מחיפוש בטבלאות התלוי בסוד. במכשיר בלי האצת AES זה יתרון ממשי, וזו הסיבה ש-WireGuard בחר בו: תיאור פרוטוקול WireGuard מונה את ChaCha20-Poly1305 כצופן הנתונים שלו בלי חלופה.

הבחירה האחת הזו אומרת משהו שימושי: בחומרה שבה AES מואץ, WireGuard מוותר על מעט תפוקה לעומת AES-GCM, והמחברים שלו קיבלו זאת בתמורה להתנהגות צפויה בטלפונים, בנתבים ביתיים ובמארחי מכולות. אם הצי שלך הוא בעיקר קופסאות ARM קטנות, העסקה הזו לטובתך.

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

מה הפרוטוקול שלך באמת מאפשר לך לבחור

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

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

החליטו לפי שלוש עובדות על הפריסה

ראשית, האם לנקודות הקצה יש האצת AES? אם לכל עמית יש, AES-GCM הוא הבחירה הזולה יותר ובירת המחדל ברוב התצורות המתוחזקות. אם חלק ניכר הם ראוטרים קטנים או טלפונים ישנים, ChaCha20-Poly1305 מונע מהזנב של הצי להפוך למגבלת הקיבולת.

שנית, האם הפרוטוקול מציע בחירה בכלל? עם WireGuard ההחלטה כבר התקבלה בשבילכם, והעבודה המועילה היא לוודא שהכלים סביבו אינם מחליפים משהו אחר בשקט. עם OpenVPN ו-IPsec התשובה היא שורת תצורה ותוצאה מוסכמת שיש לתעד.

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

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