Vì các lý do cũ, một trong các hệ thống của tôi không có tùy chọn sử dụng chế độ AEAD, chúng tôi bị hạn chế sử dụng AES ở chế độ CBC hoặc CTR đơn giản cộng với MAC.
Nhiệm vụ điển hình là truyền dữ liệu từ nút này sang nút khác trong khi vẫn đảm bảo tính toàn vẹn và bảo mật. Tôi thấy mình liên tục chỉ định thành phần sau:
- CSPRNG để tạo bí mật bootstrap
- KDF để lấy khóa mã hóa và MAC - Tôi sử dụng HKDF
- CSPRNG một lần nữa nhận được một iv
- Chế độ CTR để mã hóa dữ liệu
- MAC over bootstrap secret, iv, cipherspec và ciphertext - Tôi sử dụng HMAC
Vì vậy, tôi đang thực hiện Encrypt-then-MAC và tôi đang xác thực tất cả các đầu vào để tính toán bản mã. Nhưng tôi đã hoàn toàn cho rằng thành phần này là an toàn.
Tôi chưa bao giờ thực sự thấy thành phần đầy đủ này bao gồm cả KDF được mô tả là nguyên thủy có thể tái sử dụng.
TLS làm điều gì đó rất giống nhau, nhưng nó không hoàn toàn giống nhau (ví dụ: nó sử dụng HKDF theo cách khác).
Các lược đồ IES như ECIES và DLIES trông giống nhau về mặt khái niệm, nhưng khác nhau về chi tiết, đặc biệt là cách các đầu vào của KDF được lấy.
Vì vậy, câu hỏi của tôi là: vấn đề này có đủ tổng quát để đảm bảo một giải pháp sách dạy nấu ăn không? Hoặc có thể một cái gì đó đã tồn tại mà tôi đã bỏ qua? Nếu không, làm thế nào tôi có thể tin tưởng vào giải pháp? (Khi nói đến tiền điện tử, tôi luôn thận trọng).
Trong trường hợp các chi tiết hữu ích, quy trình là:
Nút gửi thực hiện như sau:
- Lấy 256 bit bí mật
hạt giống từ CSPRNG
- mã hóa
hạt giống cho nút khác sử dụng khóa công khai của nó như mã hóa_seed
- Tách ra
hạt giống thành 128 bit Muối và 128 bit khóa_vật liệu
- Lấy 384 bit bí mật bằng cách gọi
HKDF-HMAC-SHA-256(length=384b, ikm=key_material, salt=salt, info=<id nút nguồn || id nút đích>)
- Chia thành 128 bit
mã hóa_key, 256 bit HMAC_key
Đối với mỗi tin nhắn được gửi:
- Lấy 128 bit từ CSPRNG dưới dạng
mã hóa_iv
- Mã hóa bản rõ bằng cách sử dụng
AES-128-CTR(iv=encryption_iv, key=encryption_key)
- Tính toán thẻ như
HMAC-SHA-256(key=HMAC_key, data=encrypted_seed ||crypto_iv || cipherspec=AES-128-CTR || ciphertext)
- Gửi đến nút khác:
được mã hóa || mã hóa_iv || mật mã || bản mã || nhãn
Nút nhận thực hiện như sau:
- Phân tích tin nhắn nhận được thành các thành phần của nó
mã hóa_seed vân vân.
- giải mã
mã hóa_seed sử dụng khóa riêng của nút nhận, lấy hạt giống
- Tách ra
hạt giống thành 128 bit Muối và 128 bit khóa_vật liệu
- Lấy 384 bit bí mật bằng cách gọi
HKDF-HMAC-SHA-256(length=384b, ikm=key_material, salt=salt, info=<id nút nguồn || id nút đích>)
- Chia thành 128 bit
mã hóa_key, 256 bit HMAC_key
- Tính toán thẻ như
HMAC-SHA-256(key=HMAC_key, data=<thông báo nhận được từ nút gửi không có thẻ>)
- Giao phó
tag_valid := true nếu thẻ khớp với thẻ trên tin nhắn đã nhận, sai nếu không thì
- Giao phó
k := mã hóa_key nếu tag_valid, nếu không thì gán k := <một số hằng số ngẫu nhiên>
- Giải mã bản mã dưới dạng
[cipherspec](iv=encryption_iv, key=k)
- Xuất một bộ
(tag_valid, bản rõ) - người gọi có trách nhiệm kiểm tra tag_valid trước khi sử dụng bản rõ
Vì vậy, những gì có thể đi sai? Vâng, đối với một hạt giống giá trị được sử dụng trước khi thẻ MAC được kiểm tra. Tôi có thể ký nó bằng khóa riêng của nút gửi, nhưng điều đó không thực sự ràng buộc hạt giống vào thẻ MAC. Ngoài ra, điều này đang bắt đầu trở nên lộn xộn, do đó tôi cảm thấy khó chịu.
