Các yêu cầu kỹ thuật cho cụm mật khẩu WPA-PSK là gì?


8

Tôi đã nghĩ đến việc tạo cụm mật khẩu WPA-PSK và tôi thấy trong trang hướng dẫn OpenBSD cho wpa-psk(8):

The passphrase must be a sequence of between 8 and 63
ASCII-encoded characters.

Chính xác các tiêu chí cho "mã hóa ASCII" ở đây là gì? Chỉ cần chúng phải là ký tự 8 bit với unset bit cao? Các ký tự không in được cho phép?

Nghĩ về nó ... Liệu cách tiếp cận ngẫu nhiên của tôi tạo ra một cụm mật khẩu có ý nghĩa gì không? Sẽ tốt hơn nếu chỉ tạo 64 byte ngẫu nhiên và sử dụng nó làm khóa?

Câu trả lời:


12

> Chính xác các tiêu chí cho "mã hóa ASCII" ở đây là gì? Chỉ cần chúng phải là ký tự 8 bit với unset bit cao? Các ký tự không in được cho phép?

Truy cập được bảo vệ Wi-Fi của Wikipedia cho biết cụm mật khẩu WPA-PSK có từ 8 đến 63 ký tự ASCII có thể in và bao gồm tham chiếu này dưới dạng chú thích:

Mỗi ký tự trong cụm từ phải có mã hóa trong phạm vi từ 32 đến 126 (thập phân), đã bao gồm. (IEEE Std. 802.11i-2004, Phụ lục H.4.1)
Ký tự không gian được bao gồm trong phạm vi này.

> Nghĩ về nó ... Liệu cách tiếp cận ngẫu nhiên của tôi tạo một cụm mật khẩu có ý nghĩa gì không? Sẽ tốt hơn nếu chỉ tạo 64 byte ngẫu nhiên và sử dụng nó làm khóa?

> Tôi nghĩ rằng tôi vẫn sẽ tạo 256 bit bằng RNG an toàn ...

Bộ định tuyến không dây và mọi thiết bị bạn muốn kết nối với mạng không dây có cho phép bạn nhập thủ công khóa WPA-PSK dưới dạng 64 ký tự không? Nếu không, thì bạn có thể phải sử dụng cụm mật khẩu ASCII để có thể nhập nó vào tất cả các thiết bị của mình.


Từ RFC2898 được trích dẫn bởi @studiohack - Trong suốt tài liệu này, mật khẩu được coi là một chuỗi octet có độ dài tùy ý mà việc giải thích là một chuỗi văn bản là không xác định. Tuy nhiên, vì lợi ích của khả năng tương tác, các ứng dụng nên tuân theo một số quy tắc mã hóa văn bản phổ biến. ASCII và UTF-8 [27] là hai khả năng. (ASCII là tập hợp con của UTF-8.)
asveikau

Ngoài ra, có vẻ như OpenBSD, Linux, Windows và Mac OS X đều hỗ trợ sử dụng các phím hex. Vấn đề duy nhất tôi gặp phải là giao diện người dùng Maemo không thích nó - nhưng tệp XML hỗ trợ cấu hình hỗ trợ nó.
asveikau

OK, tôi thấy một phần của 802.11i-2004 nói rằng. Bạn đúng.
asveikau

1

Từ http://www.xs4all.nl/~rjoris/wpapsk.html - "Tính toán khóa WPA - Từ cụm mật khẩu đến khóa thập lục phân Chi tiết của phép tính":

Đối với mã hóa WPA-PSK, khóa nhị phân được lấy từ cụm mật khẩu theo công thức sau:

Hàm PBKDF2 là một phương thức được tiêu chuẩn hóa để lấy khóa từ cụm mật khẩu. Nó được chỉ định trong RFC2898 với lời giải thích rõ ràng về cách tính toán nó. Hàm cần một hàm giả ngẫu nhiên cơ bản. Trong trường hợp của WPA, chức năng cơ bản là HMAC-SHA1. SHA1 là một hàm tính toán hàm băm 160 bit từ một lượng dữ liệu đầu vào tùy ý. Nó được giải thích rõ ràng trong RFC3174. HMAC là một phương pháp được tiêu chuẩn hóa để biến hàm băm mật mã thành chức năng xác thực tin nhắn có khóa. Nó được chỉ định trong RFC2104.

Tóm lại, quy trình phái sinh khóa bao gồm lặp lại hàm HMAC-SHA1 4096 lần, và sau đó thực hiện lại để tạo ra nhiều bit chính hơn. Lượng tính toán liên quan tương đương với tính toán hàm băm SHA1 trên 1 MByte dữ liệu. Có lẽ điều đó giải thích tại sao Javascript trên trang này quá chậm.

Đối với câu hỏi của bạn Does my approach of randomly generating a passphrase make any sense? Would it be better to just generate 64 random bytes and use that as a key?:: Một trong hai sẽ rất mạnh, miễn là bạn sử dụng tất cả các loại ký hiệu, số và ký tự bảng chữ cái ngẫu nhiên trong cụm mật khẩu byte ngẫu nhiên của bạn. Cách tôi nhìn vào nó: cả hai (được tạo ra hoặc ngẫu nhiên) sẽ không thể đoán / hack ...


1
Hừm. Vì vậy, dường như dựa trên việc tôi đọc RFC rằng hàm PBKDF2 không phụ thuộc vào nó là các ký tự ASCII có thể in được và sẽ hoạt động tốt với dữ liệu nhị phân. Tôi nghĩ rằng tôi vẫn sẽ tạo ra 256 bit bằng cách sử dụng RNG an toàn ... (Tôi không tự tin đến mức không thể đoán được. Có những tỷ lệ nhỏ rằng điều này sẽ tạo ra thứ gì đó xảy ra va chạm với một kẻ yếu cụm mật khẩu .: P)
asveikau
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.