Điểm:1

Sử dụng Chaskey làm mật mã luồng

lá cờ cz

chó săn (https://eprint.iacr.org/2014/386.pdf) là một MAC an toàn, nhỏ gọn và hiệu quả cho các hệ thống nhúng và đã giành được nhiều điểm chuẩn. Nó được xây dựng bằng mật mã khối Even-Mansour. Mật mã khối này XOR một văn bản gốc với một khóa, áp dụng một hàm hoán vị công khai, sau đó XOR kết quả với cùng một khóa để tạo ra bản mã. Thật không may, bài báo chỉ thảo luận về trường hợp sử dụng MAC chứ không phải trường hợp sử dụng mã hóa. Trang web (https://mouha.be/chaskey/) tuy nhiên cũng đề cập đến các trường hợp sử dụng khác:

  1. Một PRF nhẹ.
  2. Có thể được sử dụng để đảm bảo tính toàn vẹn của thông báo bằng mật mã (dưới dạng MAC).
  3. Để xác thực người dùng (trong giao thức challenge-response).
  4. Để tạo số ngẫu nhiên (ở chế độ truy cập).

Điều tôi băn khoăn là liệu nó cũng có thể được sử dụng, theo cách an toàn, để mã hóa hay không, tức là sử dụng nó ở chế độ bộ đếm để tạo mật mã luồng. Điều này có nghĩa là chúng ta có thể tạo thuật toán Encrypt-then-MAC chỉ sử dụng Chaskey làm nguyên mẫu, thuật toán này sẽ rất hiệu quả đối với các hệ thống nhúng (tất nhiên là kết hợp với nonce cho mỗi thông báo).

Vì nó có thể được sử dụng như một PRF và để tạo các số ngẫu nhiên trong chế độ bộ đếm, nên có vẻ như điều này thực sự khả thi.

Điểm:0
lá cờ in

Chế độ CTR ban đầu được thiết kế cho PRF.

Bất kỳ PRF nào* có thể được chuyển thành mật mã dòng với chế độ CTR.Tuy nhiên, không nên sử dụng một hàm nặng được xây dựng cho MAC để sử dụng làm mật mã luồng. Sử dụng ChaCha cho mật mã dòng được tạo từ PRF hoặc sử dụng mật mã dòng trực tiếp như Trivium.

Nếu bạn thực sự muốn sử dụng thì hãy sử dụng đầu vào như $$F_k(\text{nonce_block}\mathbin\|\text{counter_block})$$ dưới dạng chế độ CTR và mã hóa dưới dạng

$$c_i = m_i \oplus F_k(\text{nonce_block}\mathbin\|\text{counter_i})$$

Đảm bảo rằng

  • $\text{counter_i}$ không bao giờ vượt quá kích thước của $\text{counter_block}$,
  • không bao giờ trở lại trạng thái ban đầu nếu bộ đếm đạt đến mức tối đa $2^{\text{counter_block_size}}-1$
  • không phức tạp với việc nối lại bộ đếm cho mã hóa khác.
  • Dưới đây, mới hơn let an $(IV,khóa)$ lại xuất hiện ở đâu $IV = (\text{nonce_block}\mathbin\|\text{counter_i})$

* Trên thực tế, bất kỳ là không đủ cho mật mã, kích thước khóa và kích thước đầu vào và đầu ra mới là quan trọng. Ngày nay, chúng tôi thích xChaCha20 hơn vì nó cho phép các nonce 192-bit để tránh xung đột nonce dưới cùng một khóa và có kích thước đầu vào/đầu ra 512-bit. Bảo mật 128 bit của Chaskey là đủ cho mật mã nhẹ, tuy nhiên, đối với các mục đích khác, nó không đủ an toàn.

lá cờ cz
Tuyệt quá! Câu hỏi tiếp theo: CCM sử dụng cùng một khóa cho cả mã hóa CTR và MAC bằng cách xây dựng cẩn thận đầu vào cho mật mã khối. Chúng ta có thể sử dụng một cách tiếp cận tương tự ở đây để tránh phải có hai khóa không?
kelalaka avatar
lá cờ in
Nó cần một phân tích. Sẽ luôn tốt hơn nếu tạo hai từ một bằng KDF như [HKDF](https://crypto.stackexchange.com/a/76589/18298) và mở rộng sẽ đủ cho bạn nếu bạn có một khóa ngẫu nhiên thống nhất.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.