Format kabel tink

Halaman ini menjelaskan format kabel Tink untuk kunci dan output primitif. Dokumentasi ini ditujukan bagi kriptografer yang ingin menambahkan bahasa lain 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 protobuf Google untuk membuat serialisasi keyset.

  • Keyset serial biner adalah proto Keyset serial yang ditentukan di tink.proto. Properti nilai KeyData dari sebuah kunci adalah proto serial dari jenis kunci yang sesuai.
  • Keyset serial JSON adalah proto Keyset yang diserialisasi dalam format JSON. Perhatikan bahwa nilai KeyData masih merupakan proto serial biner.
  • Keyset terenkripsi adalah proto EncryptedKeyst serial yang ditentukan di tink.proto. File ini berisi keyset 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 utama 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 tujuan keamanan. Tink menggunakannya sebagai petunjuk untuk mempercepat dekripsi atau verifikasi.

AEA

Secara umum, Tink memformat teks tersandi AEAD sebagai:

prefix || IV || ciphertext || tag

kecuali dinyatakan 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 big-endian tanpa tanda tangan 64-bit. Skema HMAC ini mengikuti draf untuk AES-CBC-HMAC dari Mcgrew.

AEAD deterministik

Tink menerapkan RFC 5297 untuk AES-SIV, dengan 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 kosong terkait adalah daftar dengan satu elemen kosong, 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 akan dibuat menggunakan template kunci (atau parameter kunci) tertentu.
  • DEK diserialisasi ke dalam string byte. Serialisasi memformat serialisasi buffering protokol dari proto jenis kunci. Misalnya, ini adalah pesan buffering protokol AesGcmKey serial yang ditentukan dalam aes_gcm.proto untuk DEK jenis kunci AES GCM. Lihat serialisasi buffering protokol untuk cara melakukan serialisasi buffer protokol.
  • DEK yang diserialisasi dienkripsi oleh penyedia eksternal (misalnya, GCP), ke dalam 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 integer big-endian 32-bit.

MAC

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

Set PRF

Tink mengikuti RFC yang sesuai. Perhatikan bahwa untuk PRF Set, jenis kunci berbeda dengan jenis kunci MAC pada algoritma yang sama karena tidak menyertakan panjang output. Kunci PRF Set tidak pernah menambahkan awalan output Tink. Hal ini untuk memastikan bahwa {i>output-<i}nya adalah 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 jumlah byte yang akan diurai, dan cara mengurai byte tersebut dari encapsulated_key.

HPKE (Enkripsi Kunci Publik Hybrid)

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

  • Mekanisme enkapsulasi kunci (KEM)
  • Fungsi turunan 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 yang diserialisasi pengirim
    • Ditetapkan sebagai enc di 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)
    • Ditetapkan sebagai ct di RFC 9180, Bagian 4
    • Format yang ditentukan oleh HPKE AEAD tertentu yang digunakan
X25519 KEM berbasis Diffie-Hellman

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

ECIES-AEAD-HKDF

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

KEM

Bergantung pada jenis kunci, Tink menggunakan titik kurva eliptis yang dikompresi dan tidak dikompresi, sesuai dengan standar encoding RFC 8422/ANSI.X9-62.2005. Untuk titik yang tidak dikompresi, byte 0x04 diikuti oleh koordinat x dan y sebagai bilangan bulat ukuran tetap. Untuk koordinat terkompresi, byte 0x02 atau 0x03 dan koordinat x sebagai bilangan bulat ukuran 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. Termasuk di antaranya menentukan IV.

Turunan 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 penuh sebagai byte.

Tanda tangan digital

Tink mengikuti RFC yang sesuai. Primitif dapat menambahkan awalan output Tink 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 dengan padding nol dan memiliki ukuran yang sama dalam byte dengan urutan kurva. Misalnya, untuk kurva NIST P-256, r dan s diberi padding nol hingga 32 byte.

Tanda tangan DER dienkode menggunakan ASN.1:

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

Secara khusus, encoding tersebut 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 berenkode BER alternatif tidak valid).

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