Format kabel tink

Halaman ini menjelaskan format kabel Tink untuk kunci dan output primitif. Tujuan dokumentasi ditujukan untuk kriptografer yang ingin menambahkan bahasa tambahan ke Tink dan pengelola perpustakaan kripto tingkat tinggi lainnya yang memerlukan kabel mode yang kompatibel. Konten ini tidak ditujukan untuk audiens umum.

Serialisasi keyset

Tink menggunakan protobuf Google untuk menserialisasi set kunci-nya.

  • {i>Keyset<i} berseri biner adalah prototipe {i>Keyset<i} berseri yang ditentukan di tink.proto. Properti nilai KeyData pada kunci adalah proto dari jenis kunci yang sesuai.
  • Keyset serial JSON adalah proto Keyset yang diserialisasi dalam format JSON. Perlu diperhatikan bahwa nilai KeyData masih merupakan proto serial biner.
  • Keyset terenkripsi adalah proto EncryptedKeyst berseri yang ditentukan di tink.proto. Mengandung keyset serial biner terenkripsi dan secara opsional beberapa metadata KeysetInfo yang tidak terenkripsi.

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 dari kunci yang digunakan.

Beberapa kunci lama mungkin juga mendukung byte versi 0x00.

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

AEAD

Secara umum, Tink memformat teks tersandi 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 big-endian 64-bit bilangan bulat tanpa tanda tangan. Skema HMAC ini mengikuti draf AES-CBC-HMAC dari Mcgrew.

AEAD determenistik

Tink menerapkan RFC 5297 untuk AES-SIV, yang menempatkan initialization vector (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 yang kosong adalah daftar dengan satu elemen kosong, dan bukan elemen kosong daftar.

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 tertentu (atau parameter kunci).
  • DEK diserialisasi ke dalam string byte. Format serialisasi serialisasi buffering protokol dari proto jenis kunci. Sebagai contoh, ini adalah pesan buffering protokol AesGcmKey serial yang ditentukan di aes_gcm.proto untuk DEK jenis kunci AES GCM. Lihat serialisasi buffering protokol untuk mengetahui cara melakukan serialisasi sebuah penyangga protokol.
  • Serial DEK dienkripsi oleh penyedia eksternal (misalnya GCP), menjadi encrypted DEK.
  • DEK digunakan untuk mengenkripsi teks biasa dengan data terkait menjadi ciphertext. Jadi, ciphertext memiliki format yang sama persis dengan primitif AEAD yang sesuai dengan DEK.

Format output enkripsi envelope adalah sebagai berikut:

encrypted DEK length || encrypted DEK || ciphertext

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

MAC

Tink mengikuti RFC yang sesuai. Primitif dapat menambahkan output Tink 5 byte pada tag.

Kumpulan PRF

Tink mengikuti RFC yang sesuai. Perhatikan bahwa untuk Kumpulan PRF, jenis kunci berbeda dari jenis kunci MAC dari algoritma yang sama dengan tidak memasukkan panjang {i>output<i}. Kunci Kumpulan PRF tidak pernah menambahkan awalan output Tink. Hal ini memastikan output benar-benar PRF.

Enkripsi hybrid

Format kabel umum untuk enkripsi hybrid Tink adalah sebagai berikut:

prefix || encapsulated_key || encrypted_data

prefix kosong atau awalan output Tink 5 byte. Setiap jenis kunci berisi informasi tentang berapa banyak {i>byte<i} yang akan diurai, dan cara mengurai {i>byte<i} tersebut dari encapsulated_key.

HPKE (Enkripsi Kunci Publik Hybrid)

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 dari Tink menggunakan hal berikut Nilai encapsulated_key dan encrypted_data.

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

Untuk DHKEM X25519, nilai enc adalah file publik Diffie-Hellman 32 byte milik pengirim tombol.

ECIES-AEAD-HKDF

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

KEM

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

DEM

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

Turunan kunci

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

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

di mana encapsulated_key adalah output KEM penuh sebagai byte.

Tanda tangan digital

Tink mengikuti RFC yang sesuai. Primitif dapat menambahkan output Tink 5 byte pada tag yang dibuat.

ECDSA

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

Format tanda tangan IEEE P1363 adalah r || s, dengan r dan s tanpa padding dan memiliki ukuran yang sama dengan urutan kurva. Sebagai misalnya, untuk kurva NIST P-256, r dan s akan ditambahkan 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 verifikasi tanda tangan, dengan hanya menerima Tanda tangan ECDSA yang dienkode dengan DER (tanda tangan berenkode BER alternatif tidak valid).

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