התשובות הנכונות בקריפטוגרפיה עודכנו ל-2026: המועד לפוסט-קוונטי נקבע ל-2029

עדכון 2026 למסורת הקריפטוגרפית

Filippo Valsorda פרסם גרסה חדשה של "Cryptographic Right Answers", המעדכנת את הסדרה שהותחלה ב-2009 על ידי Colin Percival, הורחבה ב-2015 על ידי Thomas Ptacek ונמשכה ב-2018 ו-2024 על ידי Latacora. המהדורה של 2026 משקפת שינוי משמעותי בלוחות הזמנים למעבר פוסט-קוונטי: הקונסנסוס מתגבש כעת סביב מועד של סוף 2029. הקריפטוגרפיה הסימטרית כמעט ולא השתנתה, שכן אלגוריתם גרובר לא משנה מהותית את דרישות האבטחה, אולם בהשוואה למהדורות קודמות כמעט כל ההמלצות לקריפטוגרפיה א-סימטרית הוחלפו.

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

ההמלצות הסימטריות נותרו ללא שינוי

להצפנת נתונים השתמשו ב-cloud KMS אם אפשר, אחרת ב-XAES-256-GCM או XChaCha20Poly1305, עם nonce אקראיים באורך מינימום 128 ביטים. להודעות גדולות של כמה מגה-בייט, Cobblestone-128, וריאנט של STREAM שנגזר מ-TLS, עדיף על העברת מכתם AEAD אחד וגדול. ההמלצה לאורך מפתח סימטרי נותרה ללא שינוי: השתמשו במפתחות באורך 256 ביטים, שכן גרובר לא משנה את המשמעות ו-256 ביטים משלילים התקפות רב-מטרתיות. HMAC-SHA-256 נשאר הבחירה לחתימה סימטרית, ו-SHA-2 עדיין תקף לגיבוב; היכן שניתן, מומלץ השימוש בהרחבות עמידות לאורך SHA-512/256. מזהים אקראיים צריכים להיות 32 בתים אקראיים שנלקחו מה-CSPRNG של מערכת ההפעלה.

הקריפטוגרפיה הא-סימטרית משתנה משמעותית

להחלפת מפתחות מומלץ להשתמש ב-X25519 בשילוב עם ML-KEM-768 בפרוטוקול סטנדרטי כמו TLS, SSH או HPKE. החלפת מפתחות שאינם פוסט-קוונטיים נחשבת כעת לסיכון פעיל ודחוף בשל התקפות harvest-now-decrypt-later. ההמלצה הראשית להצפנה א-סימטרית היא HPKE MLKEM768-X25519 (X-Wing) עם הרכבת HKDF-SHA256 ו-AES-128-GCM, או age עם מפתחות חדשים בקידומת age1pq. לחתימות א-סימטריות השתמשו ב-ML-DSA-44 ולא באלגוריתם קלאסי, כולל Ed25519, RSA או ECDSA. סכימות חתימה היברידיות אינן מומלצות ברוב המקרים, אך מפתחות SSH הם יוצא דופן: OpenSSH 10.6 כבר תומך ב-ssh-mldsa44-ed25519.

אבטחת תעבורה וגיבויים

לאבטחת אתרים ואפליקציות לקוח-שרת השתמשו ב-cloud ALB/NLB בענן, אחרת ב-rustls, crypto/tls של Go, BoringSSL, AWS-LC או s2n-tls עם לקוח ACME נתמך היטב. הימנעו מ-OpenSSL ככל האפשר; המחבר מסביר זאת בבחירות לא מובנות לאורך מספר שנים. כל פריסת TLS צריכה להעניק עדיפות להחלפת מפתחות X25519MLKEM768, כפי ש-TLS 1.3 דורש. לגיבויים מקוונים מומלץ restic עם סיסמה אקראית ארוכה ולא Tarsnap, שכן השכבה הא-סימטרית שלו המבוססת על RSA מסומנת כמלכודת מסוכנת על רקע הקירבה של מחשבים קוונטיים, למרות העיצוב ההגיוני של 2008.

מקורות: Lobsters