Tiếng Việt

Văn bản & công cụ hàng ngày · Trình tạo mật khẩu

Giải thích về khuynh hướng Modulo: chọn một từ ngẫu nhiên từ danh sách mà không bị lệch

· Cách thức hoạt động

mật khẩu sự ngẫu nhiên mật mã

Các thùng được đánh số không đồng đều bên cạnh một bộ chẵn được tạo ra sau khi loại bỏ đuôi
Hình minh họa vector ToolAcre gốc

Hiển thị lý do 'độ dài danh sách modulo số ngẫu nhiên' ưu tiên một số từ hơn các từ khác khi phạm vi không chia đều, độ lệch lớn như thế nào và cách lấy mẫu từ chối loại bỏ nó.

Một con súc sắc công bằng và một con đường tắt không công bằng — tại sao việc lấy một số ngẫu nhiên theo modulo 7,776 lại không giống như việc tung xúc xắc

Một nguồn công bằng vẫn có thể nuôi dưỡng một thói quen lựa chọn không công bằng. Nếu một chương trình đọc một số nguyên và ngay lập tức lấy phần còn lại sau khi chia cho độ dài danh sách, thì một số chỉ mục sẽ nhận được nhiều giá trị nguồn hơn bất cứ khi nào phạm vi nguồn không chia hết chính xác cho độ dài đó. Lỗ hổng nằm ở bước rút gọn chứ không nhất thiết ở số byte. ToolAcre tránh lối tắt đó trước khi chọn bất kỳ từ EFF nào.

Xúc xắc vật lý chỉ cung cấp sự so sánh trực quan khi các nhóm kết quả hoàn chỉnh được ánh xạ đồng đều. Việc triển khai trình duyệt có phạm vi thô khác nhau, do đó, nó tính toán khoảng thời gian chấp nhận cho giới hạn được yêu cầu. Bài viết này thảo luận về cơ chế được vận chuyển đó thay vì tuyên bố rằng các byte của trình duyệt tái tạo năm viên xúc xắc theo đúng nghĩa đen. Cả hai đều có thể lựa chọn các chỉ số, nhưng thủ tục và bằng chứng kiểm toán của chúng là khác nhau.

Xu hướng xuất phát từ đâu — giá trị 32-bit không chia đều cho các nhóm 7,776, do đó, một vài từ đầu tiên sẽ có thêm một cơ hội

Đối với một byte và giới hạn 100, phạm vi thô có 256 giá trị có thể có. Hai nhóm hoàn chỉnh gồm 100 phù hợp, để lại các giá trị 56. Việc giảm mỗi byte modulo 100 sẽ cung cấp cho các chỉ số từ 0 đến 55 ba hình ảnh trước, trong khi các chỉ mục 56 đến 99 chỉ nhận được hai. Các byte đầu vào có thể đồng nhất nhưng phân phối nhóm được chọn thì không.

Nhận xét triển khai cũng xuất phát từ vấn đề phạm vi hữu hạn tương ứng đối với danh sách mục nhập 7,776 khi hai byte được giảm trực tiếp. Những số liệu đó đến từ phạm vi thực tế có tên trong nguồn, không phải từ tỷ lệ tấn công giả định. Câu hỏi đánh giá quan trọng là liệu các giá trị còn lại có được sử dụng hay không, chứ không phải liệu độ lệch có vẻ nhỏ trong một số cụm từ được tạo hay không.

Hiệu ứng này lớn đến mức nào - nhỏ đối với một phạm vi ngẫu nhiên lớn, nhưng khác 0 và tại sao mã mật mã từ chối chấp nhận nó

Các thử nghiệm xác định làm cho phần đuôi không đều có thể quan sát được. Các giới hạn 3, 5, 7, 100 và 7,776 cố tình gây khó xử, trong khi giới hạn lũy thừa hai thể hiện trường hợp không từ chối. Một biện pháp kiểm soát thống kê khác sử dụng cùng một nguồn Web Crypto cho chức năng chính xác và một trình trợ giúp modulo đơn giản, do đó thử nghiệm sẽ tách biệt chiến lược giảm bớt thay vì đổ lỗi cho nguồn entropy.

ToolAcre không chuyển những lần kiểm tra phân phối đó thành dự đoán về thời gian bẻ khóa. Xu hướng làm giảm tính đồng nhất, nhưng việc chuyển mức giảm đó thành chi phí cụ thể của kẻ tấn công đòi hỏi phải có một mô hình mối đe dọa hoàn chỉnh. Yêu cầu kỹ thuật rõ ràng hơn: mọi chỉ mục đủ điều kiện phải có cùng số lượng giá trị thô được chấp nhận và mã có thể thực thi chính xác điều đó.

Các ví dụ về độ lệch đã được xác minh trong các nhận xét triển khai và kiểm tra xác định

`secureRandomInt` tìm toàn bộ số byte nhỏ nhất có khả năng biểu thị chỉ mục hợp lệ cao nhất. Nó tính toán phạm vi byte, trừ phần còn lại sau khi chia cho giới hạn và gọi kết quả là `limit`. Các giá trị dưới giới hạn đó thuộc về các nhóm hoàn chỉnh; các giá trị bằng hoặc cao hơn nó sẽ bị loại bỏ trước khi phép toán modulo được phép chạy.

Một trận hòa mới theo sau mỗi lần từ chối. Vòng lặp có trần cố định cao nên nguồn bơm vào bị hỏng không thể treo tab mãi được; sau khi lặp lại các giá trị ngoài phạm vi, nó sẽ ném ra thay vì trả về một câu trả lời sai lệch. Đường dẫn lỗi này là một phần của tính đúng đắn: việc từ chối một nguồn đáng ngờ sẽ duy trì lời hứa rằng chỉ mục được trả về đến từ cửa sổ chấp nhận thống nhất.

Các lựa chọn thay thế - vẽ đủ số bit chính xác và loại bỏ các giá trị ngoài phạm vi hoặc sử dụng hàm số nguyên thống nhất của thư viện

Có thể sử dụng các thiết kế số nguyên thống nhất khác, nhưng chúng không phải là hoạt động của gói này và do đó không được trình bày dưới dạng các tùy chọn ToolAcre có thể hoán đổi cho nhau. Động cơ hiển thị một đường dẫn được kiểm tra. `secureRandomChoice` xác thực rằng đầu vào của nó là một mảng khác trống và ủy quyền cho `secureRandomInt(items.length)`, làm cho việc lựa chọn từ trở thành người tiêu dùng trực tiếp của hợp đồng số nguyên giới hạn.

Trình tạo mật khẩu ngẫu nhiên sử dụng cùng một đường dẫn cho các ký tự, sau đó thực hiện xáo trộn Fisher–Yates được điều khiển bởi các hoán đổi giới hạn an toàn. Nó không sử dụng `sort` với bộ so sánh ngẫu nhiên. Việc giữ một bản gốc bên dưới một số tính năng giúp việc đánh giá nguồn trở nên dễ dàng hơn: sửa hoặc kiểm tra mức giảm thống nhất một lần, sau đó theo dõi người gọi nó.

Các thiết kế thay thế nằm ngoài mô-đun này; đường dẫn vận chuyển sử dụng lấy mẫu từ chối

Kiểm tra hồi quy ràng buộc-100 cung cấp mọi byte đuôi từ 200 đến 255 và sau đó là 42 cuối cùng. Mã đúng sẽ sử dụng tất cả 56 byte bị từ chối và câu trả lời từ 42. Trường hợp tập trung thứ hai cung cấp 200 và 7; bởi vì 200 modulo 100 sẽ bằng 0, việc trả về 7 chứng tỏ rằng byte đầu tiên đã bị từ chối thay vì giảm dần.

Ví dụ hoạt động này được xác định theo thiết kế và không chứa thông tin xác thực. Các byte sản xuất vẫn ở chế độ riêng tư đối với lệnh gọi trình duyệt và không được ghi lại. Nguồn kiểm tra chỉ có thể được tiêm vào nên hành vi có thể bị ép buộc ở ranh giới; gói công khai không cung cấp chế độ hạt giống sản xuất có thể tạo lại cụm mật khẩu được tạo.

Ví dụ đã hoạt động: bị ràng buộc 100 từ chối byte 200 và chấp nhận 7 sau

Giảm ngẫu nhiên dấu phẩy động, API thống nhất dành riêng cho thư viện và các thuật toán xáo trộn không liên quan nằm ngoài việc triển khai này. Việc đánh giá chúng sẽ yêu cầu nguồn và hợp đồng của chúng. Mã của ToolAcre dựa trên số nguyên và được giới hạn rõ ràng, do đó, việc thêm khảo sát về các lựa chọn thay thế sẽ làm mờ đi tuyên bố hẹp mà các thử nghiệm thực sự chứng minh.

Bài viết cũng không suy luận rằng mật khẩu được tạo thống nhất sẽ phù hợp với mọi chính sách hoặc thiết bị. Lựa chọn chỉ mục thống nhất giải quyết một cơ chế. Lưu trữ, tái sử dụng, xử lý clipboard, phần mềm độc hại và các hạn chế về đích đến vẫn là những câu hỏi riêng biệt ngay cả khi mọi thành phần trong danh sách đều có cơ hội lựa chọn như nhau.

Bài học rút ra - trình tạo cụm mật khẩu phải chọn các từ thống nhất; kiểm tra ghi chú Kỹ thuật của công cụ để biết cách Trình tạo Mật khẩu thực hiện nó

Trình tạo cụm mật khẩu không được ưu tiên các mục nhập sớm chỉ vì phạm vi thô của nó để lại phần còn lại. ToolAcre lấy byte từ Web Crypto, từ chối phần đuôi không đầy đủ và chỉ giảm các giá trị bên trong các nhóm hoàn chỉnh có kích thước bằng nhau. Các thử nghiệm buộc cả ranh giới từ chối và chấp nhận nên tuyên bố không dựa trên việc kiểm tra trực quan các kết quả đầu ra.

Khi xem lại mã tương tự, hãy tính phạm vi thô cho độ rộng byte đã chọn, chia nó cho giới hạn được yêu cầu và tìm phần còn lại bị loại bỏ. Nếu không có đuôi nào bị từ chối, hãy yêu cầu một bằng chứng khác về tính đồng nhất. Danh sách từ có thể được công khai và mã hóa nguồn trong khi việc giảm bớt bất cẩn vẫn gây ra sai lệch có thể tránh được.