Có một nguyên tắc cốt lõi trong mật mã học, trong đó đầu ra có thể là tất định hoặc không tất định. Với đầu ra tất định, chúng ta luôn nhận được cùng một đầu ra cho cùng một đầu vào. Ví dụ: chúng ta có thể tạo một mật mã từ văn bản thuần túy và đầu ra sẽ luôn là cùng một văn bản mật mã. Với không tất định, chúng ta không thể dự đoán đầu ra sẽ được sử dụng, vì một số hình thức ngẫu nhiên hóa đã được sử dụng trong quá trình này. Với chữ ký, ECDSA là không tất định và EdDSA là tất định.

Khi nói đến các phương pháp khóa đối xứng, bản chất tất định có thể hữu ích trong việc tìm kiếm dữ liệu, nhưng nó sẽ yếu hơn về mặt bảo mật, vì đối thủ có thể ánh xạ đầu vào với đầu ra. Trong trường hợp này, chúng ta sẽ kết hợp bản chất tất định với Authenticated Encryption with Associated Data (Deterministic AEAD) và sử dụng chế độ AES-SIV.

SIV — Synthetic Initialization Vector (Véc-tơ khởi tạo tổng hợp)

Chúng ta tiết lộ quá nhiều bí mật của mình và thường không bảo vệ một trong những bí mật quan trọng nhất của chúng ta… khóa mã hóa của chúng ta. Để khắc phục điều này, chúng ta có thể sử dụng một phương pháp gọi là key wrapping (gói khóa) để bảo vệ khóa. Điều này đặc biệt quan trọng khi chúng ta truyền khóa qua các kênh không đáng tin cậy hoặc lưu trữ nó ở những nơi không có kiểm soát truy cập mạnh mẽ. Đối với key wrapping, Rogaway et al đã đề xuất phương pháp SIV (Synthetic Initialisation Vector) [here] để xác thực và mã hóa, cùng với việc xác thực bất kỳ dữ liệu bổ sung nào liên quan đến khóa:

Phương pháp này hiện được tiêu chuẩn hóa với RFC 5297 [here]. Với các phương pháp mã hóa nâng cao, chúng ta có thể vừa xác thực mật mã vừa chứng minh tính toàn vẹn của nó. Điều này được gọi là Authenticated Encryption with Associated Data (AEAD). Đối với điều này, chúng ta cung cấp dữ liệu bổ sung để xác thực quá trình mã hóa và chúng ta có thể xác định nơi văn bản mật mã đã bị sửa đổi, để nó không thể được giải mã. Với hầu hết các phương pháp AEAD thông thường, chúng ta tạo một giá trị nonce và thêm dữ liệu bổ sung (AD) được xác thực nhưng không được mã hóa. Với phương pháp không cần nonce, chúng ta có thể sử dụng phương pháp key wrapping, phương pháp này thường được sử dụng để bảo vệ khóa mã hóa. Dữ liệu bổ sung có thể bao gồm [here]:

addresses, ports, sequence numbers, protocol version numbers, and other fields that indicate how the plaintext or ciphertext should be handled, forwarded, or processed

Bằng cách này, chúng ta có thể liên kết các gói mạng với dữ liệu được mã hóa và cung cấp tính toàn vẹn để kẻ xâm nhập không thể sao chép và dán văn bản mật mã hợp lệ từ các lần truyền khác. Ví dụ: nếu chúng ta liên kết với số thứ tự gói và cổng, thì quá trình xác thực sẽ không thành công đối với một số thứ tự khác hoặc một cổng khác.

Trong đoạn mã sau, chúng ta sẽ sử dụng thông tin bổ sung "101112131415161718191a1b1c1d1e1f2021222324252627", nhưng trong thực tế, nó có thể có bất kỳ độ dài nào. Trong SIV, chúng ta cũng có thể có nhiều nguồn dữ liệu bổ sung này (được gọi là một vectơ chuỗi). Thông tin này có thể được trải rộng trên nhiều nguồn và có thể khó khăn cho kẻ xâm nhập để nắm bắt và sao chép. Đây là một trong những tính năng đặc biệt của SIV và cho phép sử dụng nhiều chuỗi để xác thực, thay vì phải hợp nhất chúng thành một chuỗi duy nhất để có thêm thông tin:

byte[] plaintext = pl.getBytes();
	      
String additional="101112131415161718191a1b1c1d1e1f2021222324252627";
byte[] ciphertext = daead.encryptDeterministically(plaintext, Hex.decode(additional));

Các phương pháp AEAD truyền thống có thể yếu về mặt tái sử dụng nonce và lạm dụng nonce. Trong nhiều hệ thống, chúng ta sử dụng một phương pháp không tất định để tạo nonce, vì vậy không có cách nào biết liệu các giá trị đã tạo trước đó có chưa được sử dụng hay không. Một điểm yếu khác là nonce có thể bị "phát lại" bằng cách quay lại máy ảo và khám phá giá trị nonce đã sử dụng. Do đó, hầu hết các phương pháp AEAD đều an toàn với một nonce duy nhất, nhưng không có gì đảm bảo về tính bảo mật nếu nonce không phải là duy nhất. Vì giá trị nonce có kích thước giới hạn, nên sẽ luôn có cơ hội sử dụng lại nó với cùng một khóa và do đó, chúng ta có thể phải thay đổi khóa của mình một cách thường xuyên. SIV cung cấp khả năng bảo vệ tốt hơn cho việc tái sử dụng/lạm dụng nonce và kẻ tấn công chỉ có thể xác định rằng một giá trị văn bản thuần túy nhất định và một tập hợp dữ liệu liên kết nhất định đã được bảo vệ bằng khóa và giá trị nonce đã xác định.

Coding (Mã hóa)

Trong đoạn mã sau, chúng ta tạo một khóa SIV, sau đó tạo các giá trị văn bản mật mã và cả hai giá trị này phải giống nhau [here]:

package main

import (
       "fmt"
 "os"

 "github.com/tink-crypto/tink-go/v2/daead"
 "github.com/tink-crypto/tink-go/v2/keyset"


)

func main() {

 msg:="Hello"
 associated:="Hello"

 argCount := len(os.Args[1:])
 if (argCount>0) {msg = os.Args[1]}
 if (argCount>1) {associated =os.Args[2]}

 handle, _ := keyset.NewHandle(daead.AESSIVKeyTemplate())

 primitive, _ := daead.New(handle)

 plaintext := []byte(msg)
 associatedData := []byte(associated)


 ciphertext1, _:= primitive.EncryptDeterministically(plaintext, associatedData)
 ciphertext2, _:= primitive.EncryptDeterministically(plaintext, associatedData)

 res, _ := primitive.DecryptDeterministically(ciphertext1, associatedData)

 fmt.Printf("Plaintext is %s\n",msg)
 fmt.Printf("Associated data is %s\n\n",associated)

 fmt.Printf("Key is %s\n\n",handle)

 fmt.Printf("Cipher1 is %x\n\n",ciphertext1)
 fmt.Printf("Cipher2 is %x\n\n",ciphertext2)
 fmt.Printf("Decrypted is %s",res)


}

Một lần chạy mẫu cho thấy rằng chúng ta có cùng một mật mã khi chúng ta mã hóa một cách tất định [here]:

Plaintext is Testing 123
Associated data is qwerty123

Key is primary_key_id:1537855825 key_info:{type_url:"type.googleapis.com/google.crypto.tink.AesSivKey" status:ENABLED key_id:1537855825 output_prefix_type:TINK}

Cipher1 is 015ba9d1518f3a5d213ce9630294f87af76ce86011c8631842aa96571d0dee03

Cipher2 is 015ba9d1518f3a5d213ce9630294f87af76ce86011c8631842aa96571d0dee03

Decrypted is Testing 123

10s Hiểu rõ thị trường crypto

Điều khoảnChính Sách Bảo Mật của chúng tôiSách trắngXác minh chính thứcCookieBlog