Điểm:3

Tôi có thể thoát khỏi việc tạo 512-bit k (và d) cho ECDSA dựa trên P-521 không?

lá cờ vu

Tôi đã triển khai một thư viện mật mã theo sở thích và tôi đang ở phần triển khai mật mã đường cong elip. Tôi đã triển khai và thử nghiệm ECDSA với P-256 và P-384, trong đó các khóa riêng tĩnh và tạm thời là 256 bit và 384 bit, cho đến nay vẫn rất tốt.

Điều làm phiền tôi là P-521. Tôi đang lên kế hoạch tạo tĩnh 512-bit ($d$) và các khóa phù du ($k$) để dễ triển khai, vì hầu hết các hàm băm (không bao gồm XOF) có tối đa đầu ra 512 bit (Tôi không sử dụng hàm băm để tạo khóa trực tiếp, tôi chỉ phân bổ không gian ngăn xếp theo độ dài đầu ra của các hàm băm thông thường ).

Nếu tôi làm điều này, thành phần chữ ký kết quả $s$ có thể có một số loại sai lệch, nhưng vì sản phẩm của $d \cdot k^{-1}$ sẽ tràn $n$, Tôi có niềm tin giả tạo rằng đây không phải là vấn đề quá nghiêm trọng.

Vì vậy, tôi hỏi 2 câu hỏi liên quan:

Q1: tôi có thể thoát khỏi việc tạo các khóa tạm thời và tĩnh 512-bit cho ECDSA qua P-521 và không gây hại cho bảo mật không?

quý 2: đối với trường hợp chung, được cung cấp một mô đun nguyên tố $n$, một đối thủ được đưa ra $s = k \cdot r + d \pmod n$$r$, ở đâu $d$ là tĩnh và $r$ được tính ngẫu nhiên một cách xác định từ $k$; cả hai $k$$d$ có ít hơn $\lceil {\log_2{n} \trên 4} \rceil$ của các bit trên cùng bị cắt nhỏ; kẻ thù có thể có được bất kỳ phần nào của $d$ hoặc $k$?

kelalaka avatar
lá cờ in
Tại sao bạn không chọn các bit ngẫu nhiên thống nhất? Bạn có định tạo khóa bí mật $d$ từ mật khẩu của người dùng không? Không phải $s = k^{-1} (z + rd)$ Bạn có định triển khai ECDSA tất định không?
DannyNiu avatar
lá cờ vu
@kelalaka Bạn đã bỏ lỡ quan điểm của tôi. Tôi dự định chỉ tạo entropy 512 bit trên đường cong P-521, nhưng tôi không chắc liệu điều này có an toàn hay không.
kelalaka avatar
lá cờ in
Tôi nhận thức được điều đó. Tôi chỉ hỏi tại sao bạn muốn điều này?
DannyNiu avatar
lá cờ vu
@kelalaka, để dễ dàng triển khai, như tôi đã nói trong câu hỏi. Khóa 521 bit yêu cầu mặt nạ bổ sung sau khi tạo 65 byte ngẫu nhiên, vì vậy tôi muốn bỏ qua điều đó. Điều này cũng tiết kiệm một chút dung lượng ngăn xếp và tốt hơn cho việc căn chỉnh mốc.
DannyNiu avatar
lá cờ vu
@kelalaka Tôi đã sử dụng một công thức khác trong Q2 vì nó dễ phân tích hơn và kết quả của nó có thể được áp dụng cho công thức DSS khác dễ dàng hơn hoặc ít nhất là tôi nghĩ vậy.
kelalaka avatar
lá cờ in
Bạn không biết về ["Cuộc tấn công thiên vị-k" trên (EC)DSA hoạt động như thế nào?](https://crypto.stackexchange.com/q/44644/18298)
DannyNiu avatar
lá cờ vu
Chà, tôi không rành về toán học tiền điện tử lắm, và tôi nghĩ đây sẽ là một kiểu thiên vị khác.
kelalaka avatar
lá cờ in
Đây là video https://www.youtube.com/watch?v=6ssTlSSIJQE
Điểm:6
lá cờ ru

Đừng làm điều này!

Xu hướng trong các nonce ECDSA trên nhiều chữ ký sẽ làm rò rỉ khóa ký theo thời gian. Xem ví dụ bài báo Biased Nonce Sense: Mạng tấn công chống lại chữ ký ECDSA yếu trong tiền điện tử của Breiner và Heninger.

Q2 tổng quát được gọi là bài toán ẩn số và thực sự bài toán này đã được giải trong bài báo khi nhiều $r$$s$ được cung cấp.

Điểm:4
lá cờ cn

Không! Ngay cả khi tạo 520-bit $k$ có khả năng là một lỗ hổng có thể khai thác.

Một kết quả năm 2020 về chủ đề này là LadderLeak: Phá vỡ ECDSA với ít hơn một chút rò rỉ nonce. §5 thảo luận về ước tính chi phí cho cuộc tấn công: không thực sự khả thi đối với độ lệch một bit ngoài P256, nhưng độ lệch lớn hơn cho phép các cuộc tấn công rẻ hơn và các cuộc tấn công chỉ trở nên tốt hơn theo thời gian.

Sử dụng ECDSA xác định trừ khi bạn có lý do chính đáng để sử dụng ECDSA ngẫu nhiên. ECDSA xác định có thể sử dụng HMAC_DRBG làm hộp đen: bạn chỉ cần khởi tạo HMAC_DRBG với các tham số cần thiết. Một lợi thế của thuật toán xác định này là nếu các bài kiểm tra câu trả lời đã biết của bạn cho kết quả như mong đợi, thì bạn có độ tin cậy khá cao rằng bạn đã thực hiện nó một cách chính xác.Hầu hết các hệ thống tạo chữ ký đều có RNG và HMAC_DRBG là một DRBG khá tốt (không phải là nhanh nhất, nhưng tương đối dễ triển khai và tuân thủ FIPS).

Nếu bạn sử dụng ECDSA ngẫu nhiên, tôi khuyên bạn nên triển khai nó bằng cách thực hiện ECDSA xác định và cung cấp thêm tính ngẫu nhiên vào HMAC_DRBG. Bằng cách này, nếu bạn làm sai phần ngẫu nhiên, tệ nhất là nó sẽ xuống cấp thành ECDSA xác định mà không có bất kỳ nguy cơ rò rỉ nonce nào. Có hai lý do tại sao bạn có thể thích ECDSA ngẫu nhiên hơn: nếu đó là mục tiêu bảo mật mà kẻ thù không thể biết liệu hai chữ ký được tạo riêng biệt có xảy ra cho cùng một thông báo hay không (mục tiêu bảo mật không phổ biến) hoặc vì nó có thể tạo ra một số kênh phụ hoặc điểm yếu tiêm lỗi khó khai thác hơn (mặt khác, nó cũng có thể làm cho một số điểm yếu dễ khai thác hơn).

DannyNiu avatar
lá cờ vu
Cảm ơn. Dự án của tôi có một bộ mô-đun triển khai các đường cong băm, prng và ecc và mỗi thành phần có thể dễ dàng được sử dụng lại. Tôi muốn đảm bảo rằng tôi không mắc lỗi bảo mật khi thêm p521 vào p256 và p384 hiện có.
kelalaka avatar
lá cờ in
Tôi muốn lưu ý rằng LadderLeak sử dụng kênh phụ để cải thiện độ lệch 2 bit thành $

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