Cryptography בפועל

הכלל הראשון: אל תמציא קריפטו בעצמך

ב-2012 LinkedIn איבדה 6.5 מיליון סיסמאות. הסיבה לא הייתה האקר גאוני, הייתה שימוש ב-SHA1 ללא salt לאחסון passwords, בעיה ידועה שנים קודם. ב-2013 Adobe נחשפה עם 150 מיליון סיסמאות מוצפנות ב-AES-ECB, מצב שבו תבניות חוזרות ב-plaintext נשארות גלויות ב-ciphertext. הכשלים הגדולים בקריפטוגרפיה כמעט אף פעם לא נובעים ממתמטיקה, הם נובעים מבחירת אלגוריתם שגויה, IV קבוע, או key שנשמר בטעות ב-git. Claude יכול לעזור לך לזהות ולתקן בדיוק את הדברים האלה.

עדכון חשוב מ-2026: Anthropic השיקה את Claude Code Security, כלי שסרק פרויקטים open-source ומצא מעל 500 חולשות אבטחה שנשארו ללא זיהוי שנים, רבות מהן בקוד קריפטוגרפי. כמו שמפתח אחד תיאר בקהילה: 'Claude הצביע על SHA-256 ללא salt בקוד authentication שלי תוך 30 שניות, team review שלם פספס את זה 6 חודשים.'

מפת האלגוריתמים, מה להשתמש ב-2026

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

שלוש הטעויות הנפוצות, ואיך Claude עוזר לתקן

טעות 1: SHA-256 לאחסון passwords. SHA-256 הוא hash מהיר מאוד, GPU מודרני מחשב מיליארדי hash בשנייה. אחסון passwords צריך אלגוריתם שמכוון להיות איטי ולצרוך הרבה זיכרון, כדי שbrute force יהפוך ללא כדאי. Argon2id עם memory-cost של 19MB ו-2 iterations הוא הסטנדרט של OWASP ב-2026. bcrypt עם cost 12+ עדיין קביל אם הספרייה לא תומכת ב-Argon2id.

טעות 2: IV קבוע ב-AES-GCM. ה-IV (Initialization Vector) חייב להיות אקראי לכל הצפנה בנפרד. כשמשתמשים ב-nonce קבוע עם אותו key ב-AES-GCM, תוקף יכול לחשב XOR של שני ciphertexts ולחשוף את שניהם. Claude עוזר לזהות את הבעיה גם בקוד legacy שאין לו tests.

טעות 3: AES-CBC ללא authentication. AES-CBC מוותר על integrity, תוקף יכול לשנות bits ב-ciphertext באופן מכוון, מה שמאפשר Padding Oracle Attack. AES-GCM מוסיף authentication tag שמגלה כל שינוי. כלל פשוט: אם הספרייה מציעה GCM, השתמש בGCM תמיד.

Amendment 13 ואחריות הצפנה בישראל

תיקון 13 לחוק הגנת הפרטיות נכנס לתוקף באוגוסט 2025 ומציב חובות הצפנה מפורשות על מאגרי מידע רגישים. ארגון שמחזיק נתוני לקוחות, נתוני בריאות, או נתוני אשראי ישראלים חייב להצפין אותם, ועם אלגוריתם שניתן להגן עליו בפני רגולטור. 'הצפנו ב-SHA-256' אינה תשובה מקובלת. Claude יכול לעזור להגדיר crypto stack שעומד בדרישות:

• הצפנת שדות רגישים ברמת הDB עם AES-256-GCM
• Envelope encryption: DEK מוצפן ב-KEK שנשמר ב-KMS (AWS KMS, Azure Key Vault, HashiCorp Vault)
• TLS 1.2 לפחות לכל תעבורת רשת, TLS 1.3 מועדף
• Argon2id לpasswords של עובדים ולקוחות

פרומפטים מוכנים לשימוש

ביקורת implementation קיים:

אתה cryptography expert. סקור את ה-implementation הבא ובדוק: (1) password hashing, האם Argon2id או bcrypt עם cost מספיק? (2) symmetric encryption, האם AES-GCM עם IV אקראי? (3) key management, האם keys נפרדים מה-data? (4) nonce reuse, האם יש סכנה שIV חוזר? (5) RNG, האם crypto.randomBytes ולא Math.random? לכל בעיה: חומרה, הסבר מה תוקף יכול לעשות, קוד מתוקן. קוד: [הדבק כאן]

בניית crypto stack לפרויקט חדש:

אני בונה מערכת לניהול נתוני לקוחות של מרפאה פרטית בתל אביב. נדרשת עמידה בAmendment 13. תכנן crypto stack מלא: (1) הצפנה at rest לשדות רגישים ב-PostgreSQL עם envelope encryption ו-KMS (2) TLS configuration ל-nginx כולל cipher suites, HSTS ו-OCSP stapling (3) password hashing לחשבונות עובדים ומטופלים (4) audit trail שלא ניתן לשינוי. לכל נושא: החלטה, הסבר, Node.js code.

סיכום, מה לקחת מהשיעור הזה

• בחירת אלגוריתם: Argon2id לpasswords, AES-256-GCM לsymmetric encryption, Ed25519/ECDSA לחתימות. לא MD5, לא SHA-1, לא AES-CBC ללא authentication.
• IV/Nonce: תמיד אקראי, תמיד חדש לכל הצפנה. IV קבוע = הצפנה שבירה.
• Key management: keys לא ב-git, לא בקוד. KMS (AWS/Azure/GCP) או HashiCorp Vault לproduction. Envelope encryption לdata at rest.
• Claude כ-reviewer: הדבק קוד קריפטו קיים, ספר את ה-use case, ובקש ביקורת מפורטת עם הסבר לכל סיכון וקוד מתוקן. זה יעיל הרבה יותר מ'בדוק אם הקוד בטוח'.
• Amendment 13: אם יש לך נתונים רגישים של ישראלים, הצפנה היא חובה חוקית, לא option.