Format kabel tink

Halaman ini menjelaskan format wire Tink untuk kunci dan output primitif. Dokumentasi ini ditujukan untuk kriptografer yang ingin menambahkan bahasa tambahan ke Tink dan pengelola library kripto tingkat tinggi lainnya yang menginginkan mode yang kompatibel dengan kabel. Konten ini tidak ditujukan untuk audiens umum.

Serialisasi keyset

Tink menggunakan Google protobuf untuk melakukan serialisasi set kuncinya.

  • Keyset serial biner adalah proto Keyset serial yang ditentukan di tink.proto. Properti nilai KeyData dari kunci adalah proto serialisasi dari jenis kunci yang sesuai.
  • Kumpulan kunci yang diserialisasi JSON adalah proto Kumpulan kunci yang diserialisasi dalam format JSON. Perhatikan bahwa nilai KeyData masih berupa proto serialisasi biner.
  • Keyset terenkripsi adalah proto EncryptedKeyset serial yang ditentukan dalam tink.proto. File ini berisi kumpulan kunci serial biner terenkripsi dan secara opsional beberapa metadata KeysetInfo yang tidak dienkripsi.

Awalan Output Tink

Sebagian besar primitif Tink mendukung awalan output 5 byte yang terdiri dari:

  • Versi 1 byte: 0x01
  • Petunjuk kunci 4 byte: Ini adalah ID kunci yang digunakan.

Beberapa kunci lama mungkin juga mendukung byte versi 0x00.

Perhatikan bahwa awalan ini tidak diautentikasi dan tidak dapat diandalkan untuk tujuan keamanan. Tink menggunakannya sebagai petunjuk untuk mempercepat dekripsi atau verifikasi.

AEAD

Secara umum, Tink memformat ciphertext AEAD sebagai:

prefix || IV || ciphertext || tag

kecuali jika ditentukan lain dalam RFC yang sesuai. prefix kosong atau awalan output Tink 5 byte.

AES-CTR-HMAC

Untuk AES-CTR-HMAC, Tink menghitung MAC dengan data terkait (AD) sebagai berikut:

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

dengan bitlen(AD) adalah panjang AD dalam bit yang direpresentasikan sebagai bilangan bulat tanpa tanda tangan big-endian 64-bit. Skema HMAC ini mengikuti draf untuk AES-CBC-HMAC dari Mcgrew.

AEAD Deterministik

Tink menerapkan RFC 5297 untuk AES-SIV, yang menempatkan vektor inisialisasi sintetis (SIV) di awal ciphertext. Primitif dapat menambahkan awalan output Tink 5 byte.

Meskipun RFC 5297 mendukung daftar data terkait, Tink hanya mendukung satu data terkait, yang sesuai dengan daftar dengan satu elemen di RFC 5297. Data terkait kosong adalah daftar dengan satu elemen kosong, dan bukan daftar kosong.

Streaming AEAD

Lihat AES-CTR HMAC dan AES-GCM-HKDF.

Enkripsi alamat pengiriman

Enkripsi amplop mengenkripsi data dengan kunci enkripsi data DEK menggunakan primitif AEAD Tink. Enkripsi berfungsi sebagai berikut:

  • DEK baru dibuat, menggunakan template kunci (atau parameter kunci) tertentu.
  • DEK diserialisasi menjadi string byte. Serialisasi memformat serialisasi buffering protokol dari proto jenis kunci. Misalnya, ini adalah pesan buffering protokol AesGcmKey yang diserialisasi dan ditentukan dalam aes_gcm.proto untuk DEK jenis kunci AES GCM. Lihat serialisasi buffering protokol untuk mengetahui cara melakukan serialisasi buffering protokol.
  • DEK yang diserialisasi dienkripsi oleh penyedia eksternal (misalnya, GCP), menjadi encrypted DEK.
  • DEK digunakan untuk mengenkripsi teks biasa dengan data terkait ke dalam ciphertext. Jadi, ciphertext memiliki format yang sama persis dengan primitif AEAD yang sesuai dengan DEK.

Format output enkripsi amplop adalah sebagai berikut:

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length adalah 4 byte, yang menyimpan panjang encrypted DEK sebagai bilangan bulat big-endian 32-bit.

MAC

Tink mengikuti RFC yang sesuai. Primitive dapat menambahkan awalan output Tink berukuran 5 byte ke tag.

Set PRF

Tink mengikuti RFC yang sesuai. Perhatikan bahwa untuk PRF Set, jenis kunci berbeda dari jenis kunci MAC dari algoritma yang sama dengan tidak menyertakan panjang output. Kunci Set PRF tidak pernah menambahkan awalan output Tink. Tindakan ini memastikan output sebenarnya adalah PRF.

Enkripsi campuran

Format wire umum untuk enkripsi hybrid Tink adalah sebagai berikut:

prefix || encapsulated_key || encrypted_data

prefix kosong atau merupakan awalan output Tink 5 byte. Setiap jenis kunci berisi informasi tentang jumlah byte yang akan diuraikan, dan cara mengurai byte tersebut dari encapsulated_key.

HPKE (Enkripsi Kunci Publik Hibrid)

Tink mengikuti standar HPKE yang ditentukan dalam RFC 9180. Ciphersuite HPKE mencakup tiga primitif berikut.

  • Mekanisme enkapsulasi kunci (KEM)
  • Fungsi derivasi kunci (KDF)
  • Enkripsi yang diautentikasi dengan data terkait (AEAD)

Standar HPKE tidak menentukan format kabel umum dalam RFC 9180, Bagian 10. Implementasi HPKE Tink menggunakan nilai encapsulated_key dan encrypted_data berikut.

  • encapsulated_key
    • Kunci publik serialisasi pengirim
    • Ditentukan sebagai enc dalam RFC 9180, Bagian 4.1
    • Format ditentukan oleh KEM HPKE tertentu yang digunakan
  • encrypted_data
    • Ciphertext dan tag (yaitu, ciphertext || tag tanpa IV)
    • Ditentukan sebagai ct dalam RFC 9180, Bagian 4
    • Format ditentukan oleh AEAD HPKE tertentu yang digunakan
KEM berbasis Diffie-Hellman X25519

Untuk DHKEM X25519, nilai enc adalah kunci publik Diffie-Hellman 32 byte pengirim.

ECIES-AEAD-HKDF

Untuk implementasi ECIES-AEAD-HKDF Tink, encapsulated_key adalah output Key Encapsulation Mechanism (KEM) dan encrypted_data adalah output Data Encapsulation Mechanism (DEM).

KEM

Bergantung pada jenis kunci, Tink menggunakan titik kurva eliptis terkompresi dan tidak terkompresi, dengan mengikuti standar encoding RFC 8422/ANSI.X9-62.2005. Untuk titik yang tidak dikompresi, byte 0x04 diikuti dengan koordinat x dan y sebagai bilangan bulat berukuran tetap. Untuk koordinat yang dikompresi, byte 0x02 atau 0x03 dan koordinat x sebagai bilangan bulat berukuran tetap digunakan. Untuk X25519, definisi RFC 7748 digunakan (koordinat x sebagai bilangan bulat ukuran tetap).

DEM

Untuk encrypted_data, Tink menggunakan format yang sama dengan AEAD. Hal ini mencakup menentukan IV.

Derivasi kunci

Pertama, koordinat x x_ss dari titik bersama dihitung. Kunci untuk AEAD kemudian ditetapkan ke:

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

dengan encapsulated_key adalah output KEM lengkap sebagai byte.

Tanda tangan digital

Tink mengikuti RFC yang sesuai. Primitive dapat menambahkan awalan output Tink berukuran 5 byte ke tag yang dihasilkan.

ECDSA

Bergantung pada kolom EcdsaSignatureEncoding dalam kunci, format tanda tangan ECDSA adalah IEEE P1363 atau ASN.1 DER.

Format tanda tangan IEEE P1363 adalah r || s, dengan r dan s diisi dengan nol dan memiliki ukuran yang sama dalam byte seperti urutan kurva. Misalnya, untuk kurva NIST P-256, r dan s diisi dengan nol hingga 32 byte.

Tanda tangan DER dienkode menggunakan ASN.1:

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

Secara khusus, encoding-nya adalah:

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

Tink mengikuti praktik terbaik untuk verifikasi tanda tangan, dengan hanya menerima tanda tangan ECDSA yang dienkode DER (tanda tangan alternatif yang dienkode BER tidak valid).

Hal ini membantu mencegah serangan fleksibilitas tanda tangan, yang sering kali memengaruhi sistem mata uang kripto.