2
\$\begingroup\$

I am finding a lot of conflicting information with regards to the data that can be contained in the SSID and passwords of a WiFi network.

I would like to conform to the 802.11 standard and not only accept UTF-8 characters. I only intend to support WPA2 (definitely) and WPA3 (possibly).

I am having a hard time finding a source for the specification document.

I am using a ESP32-S3 with IDF v5.1.

In the STA structure there are only 2 fields for the SSID and password with no length fields.

    uint8_t ssid[32];                         /**< SSID of target AP. */
    uint8_t password[64];                     /**< Password of target AP. */

In the AP structure there are the same 2 fields for the SSID and only a length field for the SSID.

    uint8_t ssid[32];           /**< SSID of soft-AP. If ssid_len field is 0, this must be a Null terminated string. Otherwise, length is set according to ssid_len. */
    uint8_t password[64];       /**< Password of soft-AP. */
    uint8_t ssid_len;           /**< Optional length of SSID field. */

From what I understand thus far. Just about any data can be used in the SSID field (0x00-0xFF). I know the password must contain at least 8 bytes for data for WPA2 authentication. I am not aware of any restrictions with regards to the data that can be used in the password.

In the case where the SSID and password is set to all zeros. Then some binary data is set as the SSID and password but less than the capacity of the of the array thus having trailing zeros. Will the first zero be used as a terminator similar to a C string? If not how will length be determined?

In the case when the entire array is filled for the SSID or password. I assume it will read the entire length of the array.

Something like this.

for(i = 0; i < size; ++i){
  if(array[i] == 0){
    brake;     
  }
}

Additional information.

I have looked at the Unicode for Cyrillic and Chinese Character. If I look at this Unicode chart and the system encodes the data in little endian it will work with zero termination.

The idea is to build a binary payload and send it to a web server to set the Wi-Fi credentials. So whatever the user inputs will get converted to a binary buffer with JavaScript regardless of the character encoding.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ My understanding is that this is quite different in the various security methods, and you don't say which you are using. I'm not sure if it applies to your situation, but have a read of section H.4 (p165) of 802.11i amendment 6 which may throw some light on it for you. \$\endgroup\$
    – jonathanjo
    Sep 5, 2023 at 10:15
  • \$\begingroup\$ @jonathanjo I did state that I am having a hard time finding the spec doc. Now I have read it and stuff makes sense to a degree. Where did you source this doc please? I keep clinking around on standards.ieee.org to no avail. I assume this is the official source. \$\endgroup\$
    – Binder
    Sep 5, 2023 at 20:38

2 Answers 2

4
\$\begingroup\$

Ethernet in general and wifi in particular are now large, very complex protocols.

You can read all except the most recent the standards for free at IEEE's Get 802 program by registering at its site. The document you want is currently the 2020 version if 802.11, which is about 4,500 pages:

802.11-2020 - IEEE Standard for Information Technology--Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications

SSID Length

The SSID has a limit of 32 octets, and thei are either explicitly UTF-8, or unspecified.

enter image description here
From IEEE 802.11-2204

Pre Shared Key

The passphrase isn't actually transmitted: it's used to compute a hash per algorithm PBKDF2 (defined in PKCS #5: Password-Based Cryptography Specification, Version 2.1, RFC 8018). And so the passphrase doesn't have any real limit, it's computing a hash such as SHA-1 (varies per Wi-Fi detail), and these have fixed sizes.

The 64-limit you show appears to be a library implementation limit, which is defined in Expressif's source code esp_wifi_types.h You can check the source, but I would expect this to be considered as null-terminated string of unspecified encoding. (Note that UTF-8 encodes the ASCII subset of Unicode in the same way as ASCII; and specifically introduces no extra null bytes.)

\$\endgroup\$
3
  • \$\begingroup\$ Thanks for the mention of the IEEE's Get 802 program, as wasn't previously aware of it. \$\endgroup\$ Sep 9, 2023 at 18:52
  • \$\begingroup\$ It's vital that both WAP and client use the same character encoding to arrive at the same hash. \$\endgroup\$
    – Zac67
    Sep 9, 2023 at 21:25
  • \$\begingroup\$ @Zac67 Certainly. I'd be extremely surprised though to see anything other than UTF8 for modern equipment, and plain ASCII for old equipment. \$\endgroup\$
    – jonathanjo
    Sep 10, 2023 at 8:45
1
\$\begingroup\$

I had some time to run some unit test.

It seems to be true that the ESP32 is using null (0) terminated characters to determine the length of both the SSID and password.

In the case where the limit is reached of either the SSID and password with no null termination, the array is treated as null terminated. Effectively the code snippet I provided in my question.

For language support, the characters need to encoded to the equivalent of the UTF-8. It is up to the implementer to do the translation.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.