Điểm:1

Cách trích xuất ít tốn kém nhất 1 byte entropy được phân phối đồng đều từ điểm Curve25519 EC 32 byte

lá cờ es

Tôi đang tìm hàm băm đơn giản nhất và rẻ nhất với các thuộc tính sau:

Đầu vào: Điểm EC Curve25519 32 byte chứa khoảng 125 bit entropy phân bố không đều (được tạo ra do trao đổi ECDH).

Đầu ra: 1 byte chứa 8 bit entropy, phân bố đều.

Paul Uszak avatar
lá cờ cn
XOR điểm 31 lần.
knaccc avatar
lá cờ es
@PaulUszak Cách tốt nhất để chứng minh tính hợp lệ của phương pháp của bạn là gì? Có bất kỳ giấy tờ có thể được trích dẫn? Tôi sẽ cần thuyết phục những người sợ làm bất cứ điều gì khác ngoài việc cắt bớt đầu ra của hàm băm bảo mật bằng mật mã thành 1 byte
knaccc avatar
lá cờ es
@kelalaka hàm băm nhanh nhất có thể chế ngự tính không đồng nhất là gì, với điều kiện là đầu ra một byte có nghĩa là chúng tôi không bị hạn chế đối với các hàm băm mang lại khả năng chống va chạm? Tôi hy vọng rằng việc thiếu hạn chế này có nghĩa là các phương pháp băm đơn giản hơn và nhanh hơn có sẵn cho trường hợp sử dụng này
Điểm:2
lá cờ in

Mã hóa thông thường của các điểm có cấu trúc và không đồng nhất vì nó phải thỏa mãn phương trình đường cong. Trong Curve25519 với $x \in \mathbb Z(2^{255} - 19)\mathbb Z$ và sử dụng phương trình đường cong $x^3 + 486662 x^2 + x$ luôn luôn là một hình vuông cho các điểm. Có một lời khuyên phổ biến là sử dụng KDF trên đầu ra ECDH để sử dụng các khóa AES vì nó có thể tấn công các điểm tấn công quan trọng liên quan.

Một giải pháp cho yêu cầu này là sử dụng PRF nhanh như ChaCha8 trong đó khóa là khóa của DHKE với 0 IV.

func exact_one_byte( Điểm P):
  
   mộtByte = 0  
   out512 = ChaCha8(key,00..00, x(P)||y(P))
   
   quay lại512[0:8] 
knaccc avatar
lá cờ es
Bạn đang nói rằng các đặc điểm của BLAKE3 là nếu nó bị cắt bớt thành một byte, thì byte đó sẽ không đáp ứng yêu cầu là ngẫu nhiên đồng nhất? Xin vui lòng bạn có thể cho lý do của bạn?
kelalaka avatar
lá cờ in
Đầu ra của hàm băm mật mã dự kiến ​​sẽ không thể phân biệt được với ngẫu nhiên thống nhất. Trừ khi, người ta có thể chứng minh điều ngược lại, tất cả các byte, tất cả các bit đều không thể phân biệt được. Do đó, x-or của họ cũng vậy.
knaccc avatar
lá cờ es
Vậy thì tại sao lại thực hiện XOR, nếu byte đầu tiên của đầu ra BLAKE3 đã là ngẫu nhiên đồng nhất?
kelalaka avatar
lá cờ in
Bạn có thể không cần nó, tuy nhiên, việc cô đặc chúng thành một byte không có nguy hiểm và hầu như không tốn chi phí.
knaccc avatar
lá cờ es
Nếu tôi coi điểm EC là một bí mật với độ mạnh bit là 125 bit và nếu tôi lo ngại về việc rò rỉ thông tin về bí mật này, thì độ mạnh bit của bí mật này sau khi xuất bản hàm băm 1 byte sẽ là bao nhiêu? Và nếu câu trả lời là tôi nên mong đợi nó là 125-8=117 bit sau khi xuất bản hàm băm 1 byte, thì tại sao lại có vấn đề nếu sử dụng hàm băm bảo mật bằng mật mã thay vì tổng kiểm tra đơn giản hơn? Tôi nghĩ đây là lý do mà @PaulUszak đã nói chỉ XOR các byte của điểm EC và hoàn toàn không băm
kelalaka avatar
lá cờ in
Phương pháp này nhóm các điểm thành 256 nhóm thống nhất một cách ngẫu nhiên. Có, điều này cung cấp cho kẻ tấn công kiến ​​thức 8-bit về (các) điểm. Tổng kiểm tra có thể cung cấp mối quan hệ đơn giản về điểm có thể được khai thác hoặc liên kết với phương trình đường cong mà tôi không thể nhìn thấy hoặc chứng minh. Tôi sẽ dính vào băm.
kelalaka avatar
lá cờ in
Ngoài ra, đồng phục ngẫu nhiên cần được chứng minh cho tổng kiểm tra, đây là phần khó.
knaccc avatar
lá cờ es
Cảm ơn, tôi sẽ để câu hỏi mở trong vài ngày và sẽ chấp nhận câu trả lời của bạn nếu ai đó không đề xuất điều gì đó ít tính toán hơn
kelalaka avatar
lá cờ in
@knaccc về việc sử dụng chacha8 với khóa được trích xuất của DHKE và sử dụng 0 IV? Nó sẽ rất nhanh. Bạn muốn sử dụng cái này ở đâu?
knaccc avatar
lá cờ es
Monero hiện đang tranh luận về cách triển khai một thứ gọi là "thẻ xem": https://github.com/monero-project/monero/pull/8061 Sau đó, người ta nhận ra rằng điều quan trọng là hàm băm của hai lần xuất hiện khác nhau của cùng một bí mật ecdh với các int khác nhau được nối cần phải không thể liên kết được khi kiểm tra các giá trị băm của từng loại, do đó loại bỏ hoàn toàn việc bỏ qua hàm băm. Cảm ơn về mẹo chacha8. Chúng tôi đã điểm chuẩn Blake3 và điều đó có vẻ hứa hẹn nếu các nhà phát triển muốn giới thiệu một loại hàm băm mới (ngoài keccak mà chúng tôi hiện đang sử dụng ở mọi nơi)
kelalaka avatar
lá cờ in
@knaccc [vulture](https://chat.stackexchange.com/transcript/message/60312478#60312478) của chúng tôi đã cảnh báo tôi về điều này. Bạn biết đấy, hầu hết các lần tôi đã liên kết với câu trả lời của họ cho câu hỏi của bạn.
knaccc avatar
lá cờ es
Hãy để chúng tôi [tiếp tục cuộc thảo luận này trong cuộc trò chuyện](https://chat.stackexchange.com/rooms/133712/discussion-between-knaccc-and-kelalaka).

Đă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.