פורמט חוט Tink

בדף הזה מתואר הפורמט של חוט Tink למפתחות ולפלט פרימיטיבי. מיועד לקריפטוגרפים שרוצים להוסיף שפות Tink ומתחזקים של ספריות קריפטו אחרות ברמה גבוהה שרוצים חוט במצב תאימות. הוא לא מיועד לקהל הרחב.

סריאליזציה של ערכות מפתחות

Tink משתמש ב-protobuf של Google כדי ליצור סריאליזציה לערכות המפתחות שלו.

• קבוצת מפתחות בינארית עם סריאליזציה היא פרוטו של קבוצת מפתחות סריאלית שמוגדר ב- tink.proto. מאפיין הערך KeyData של מפתח הוא סריאלי ב-proto של סוג המפתח התואם.
• מערך מפתחות עם סריאליזציה ל-JSON הוא אב טורי של קבוצת מפתחות בפורמט JSON. שימו לב שהערך של KeyData הוא עדיין אב טורי בינארי.
• מערך מפתחות מוצפן הוא Proto EncryptedKeyst בפורמט טורי מוגדר ב- tink.proto. הוא מכיל קבוצת מפתחות בינארית עם הצפנה טורית מוצפנת ואופציונלי, מטא-נתונים לא מוצפנים של KeysetInfo.

קידומת פלט Tink

רוב הפרימיטיביים ב-Tink תומכים בקידומת פלט של 5 בייטים, הכוללת:

• גרסה בבייט אחד: 0x01
• רמז למפתח עם 4 בייטים: זה מזהה המפתח של המפתח שנעשה בו שימוש.

חלק מהמפתחות מהדור הקודם עשויים גם לתמוך בגרסה בבייט 0x00.

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

AEAD

באופן כללי, Tink מעצב מידע מוצפן (ciphertexts) מסוג D כך:

prefix || IV || ciphertext || tag

אלא אם צוין אחרת ב-RFC המתאים. השדה prefix ריק או קידומת של פלט Tink בגודל 5 בייטים.

AES-CTR-HMAC

בשביל AES-CTR-HMAC, Tink מחשב את ה-MAC עם נתונים משויכים (AD) באופן הבא:

AD || IV || ciphertext || bitlen(AD)

bitlen(AD) הוא אורך ה-AD בביטים שמיוצגים כ-Big-endian של 64 ביט מספר שלם לא חתום. סכימת ה-HMAC הזו עוקבת אחר הטיוטה עבור AES-CBC-HMAC של Mcgrew.

דטרמיניסטי D

Tink מיישם את RFC 5297 ל-AES-SIV, מהו וקטור האתחול (SIV) בתחילת הטקסט המוצפן. רכיב זה עשוי להוסיף קידומת פלט Tink של 5 בייטים.

RFC 5297 תומך ברשימה של נתונים משויכים, אבל ב-Tink יש תמיכה מדויקת בלבד. נתון משויך אחד, שתואם לרשימה עם רכיב אחד ב-RFC 5297. נתונים משויכים ריקים הם רשימה עם רכיב ריק אחד, ולא פריט ריק חדשה.

סטרימינג של AEAD

ראו AES-CTR HMAC וב- AES-GCM-HKDF.

הצפנת מעטפות

הצפנת מעטפת מצפינה את הנתונים עם מפתח להצפנת נתונים DEK באמצעות עקרונות ה-D של Tink. ההצפנה פועלת באופן הבא:

• השדה DEK החדש נוצר באמצעות תבנית מפתח נתונה (או פרמטרים מרכזיים מסוימים).
• הערך של DEK עובר סריאליזציה למחרוזת של בייטים. בפורמט הסדרתי סריאליזציה של מאגר נתונים זמני בפרוטוקול ב-Proto של סוג המפתח. לדוגמה, זו הנחיה הודעה מאגר נתונים זמני של פרוטוקול AesGcmKey סריאלית מוגדרת ב aes_gcm.proto ל-DEK מסוג מפתח AES GCM. במאמר סריאליזציה של מאגר הנתונים הזמני של הפרוטוקולים מוסבר איך לעשות זאת בסדרה מאגר נתונים זמני לפרוטוקול.
• המספר הסידורי DEK מוצפן על ידי ספק חיצוני (לדוגמה, GCP), לencrypted DEK.
• השדה DEK משמש להצפנת הטקסט ללא הצפנה עם הנתונים המשויכים ciphertext. כלומר, הפורמט של ciphertext זהה לפורמט של רכיב ה-AEAD שתואם ל-DEK.

פורמט הפלט של הצפנת המעטפה הוא:

encrypted DEK length || encrypted DEK || ciphertext

הערך של encrypted DEK length הוא 4 בייטים, והאורך של encrypted DEK מאוחסן בתור מספר שלם Big Endian ב-32 ביט.

MAC

קוד ה-Tink תואם ל-RFCs התואמים. משתמשים ראשיים עשויים להוסיף פלט Tink של 5 בייטים בקידומת לתג.

הגדרת PRF

קוד ה-Tink תואם ל-RFCs התואמים. שימו לב שעבור PRF, סוג המפתח שונה מסוג מפתח MAC של אותו אלגוריתם, על ידי אי הכללת אורך הפלט. מקשי PRF Set אף פעם לא מוסיפים קידומת לפלט Tink. כך מוודאים שהפלט PRF.

הצפנה היברידית

הפורמט הכללי של חוטים להצפנה היברידית ב-Tink הוא:

prefix || encapsulated_key || encrypted_data

השדה prefix ריק או שהוא מתחיל בקידומת פלט של Tink בגודל 5 בייטים. כל סוג מפתח מכיל מידע על מספר הבייטים לנתח, וכיצד לנתח את הבייטים האלה encapsulated_key

HPKE (הצפנת מפתחות ציבוריים היברידית)

Tink תואם לתקן HPKE שמוגדר ב-RFC 9180. הצפנת הצפנה של HPKE כוללת את שלושת האלמנטים הבסיסיים הבאים.

• מנגנון הצפנת מפתחות (KEM)
• פונקציית גזירה של מפתחות (KDF)
• הצפנה מאומתת עם נתונים משויכים (AEAD)

תקן HPKE לא מגדיר פורמט חוטים כללי ב-RFC 9180, סעיף 10. בהטמעת HPKE של Tink נעשה שימוש בשיטות הבאות encapsulated_key ו-encrypted_data.

• encapsulated_key
  • המפתח הציבורי הסידורי של השולח
  • מוגדר כ-enc ב- RFC 9180, סעיף 4.1
  • הפורמט נקבע על סמך ה-HPKE KEM הספציפי שבו נעשה שימוש
• encrypted_data
  • מידע מוצפן (ciphertext) ותג (למשל, ciphertext || tag בלי העירוב)
  • מוגדר כ-ct ב- RFC 9180, סעיף 4
  • הפורמט שנקבע על ידי ה-HPKE AEAD הספציפי שבו נעשה שימוש

KEM מבוסס X25519 Diffie-Hellman

למעבדי X25519 DHKEM, הערך enc הוא Diffie-Hellman ציבורי בגודל 32 בייטים של השולח מקש.

ECIES-AEAD-HKDF

בהטמעה של ECIES-AEAD-HKDF של Tink, הערך encapsulated_key הוא הפלט של מנגנון אנקפסולציית המפתחות (KEM) ו-encrypted_data הוא הפלט של מנגנון אנקפסולציית הנתונים (DEM).

KEM

בהתאם לסוג המפתח, Tink משתמש בעקומה אליפטית דחוסה ולא דחוסה לפי תקני הקידוד RFC 8422/ANSI.X9-62.2005. עבור נקודות לא דחוסות, הבייט 0x04 ואחריו x ו-y יוצרים קואורדינטות כמספרים שלמים בגודל קבוע. לקואורדינטות דחוסות, הבייט 0x02 או 0x03 והמערכת משתמשת בקואורדינטה x כמספר שלם קבוע. של X25519, המערכת משתמשת בהגדרה של RFC 7748 (קואורדינטה x כמספר שלם קבוע).

מִפְתח DEM

ב-encrypted_data, Tink משתמש בפורמט זהה לזה של AEAD. המידע הזה כולל שמציין מהו IV.

נגזרת מפתח

תחילה מחושבת קואורדינטת ה-x x_ss של הנקודה המשותפת. המפתח עבור הגדרת AEAD היא:

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

כאשר encapsulated_key הוא פלט ה-KEM המלא כבייטים.

חתימות דיגיטליות

קוד ה-Tink תואם ל-RFCs התואמים. משתמשים ראשיים עשויים להוסיף פלט Tink של 5 בייטים קידומת לתג שנוצר.

ECDSA

בהתאם לשדה EcdsaSignatureEncoding במפתח, הפורמט של חתימת ECDSA הוא IEEE P1363 או ASN.1 DER.

הפורמט של החתימה IEEE P1363 הוא r || s, כאשר r ו-s הם הם ללא משטח, והגודל שלהם זהה בבייטים לסדר העקומה. עבור לדוגמה, בעקומה NIST P-256, r ו-s נוספים אפס ל-32 בייטים.

חתימת ה-DER מקודדת באמצעות ASN.1:

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

באופן ספציפי, הקידוד הוא:

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

Tink פועל בהתאם לשיטות המומלצות לאימות חתימה, בכך שהוא מאשר רק חתימות ECDSA בקידוד DER (חתימות חלופיות בקידוד BER לא תקינות).

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