01-19-2020, 02:19 PM
We decided not to use ASCII characters, because:
Wireless network stacks must still be prepared to handle arbitrary values in the SSID field!
Using HEX instead of ASCII makes it easier to use common tools on a hashline, because we must not take care about character encoding. And there are tons of them. Read more about character encoding here:
https://en.wikipedia.org/wiki/Character_encoding
802.11 allow every value inside an ESSID. Read more here:
https://en.wikipedia.org/wiki/Service_se...1_network)
"Unlike basic service set identifiers, SSIDs are usually customizable. These SSIDs can be zero to 32 octets (32 bytes) long, and are, for convenience, usually in a natural language, such as English. The 802.11 standards prior to the 2012 edition did not define any particular encoding/representation for SSIDs, which were expected to be treated and handled as an arbitrary sequence of 0–32 octets that are not limited to printable characters. The IEEE 802.11-2012 defines a tag that the SSID is UTF-8 encoded and when interpreting could contain any non-ISO basic Latin characters within it. Wireless network stacks must still be prepared to handle arbitrary values in the SSID field."
The new hashline is designed to be published on websites, too - regardless of the character encoding!
The ESSID (salt) is part of PBKDF2 (PBKDF2(PRF, Password, Salt, c, dkLen)). Missing values, due to false character encoding, will lead to unrecoverable hashes.
Wireless network stacks must still be prepared to handle arbitrary values in the SSID field!
Using HEX instead of ASCII makes it easier to use common tools on a hashline, because we must not take care about character encoding. And there are tons of them. Read more about character encoding here:
https://en.wikipedia.org/wiki/Character_encoding
802.11 allow every value inside an ESSID. Read more here:
https://en.wikipedia.org/wiki/Service_se...1_network)
"Unlike basic service set identifiers, SSIDs are usually customizable. These SSIDs can be zero to 32 octets (32 bytes) long, and are, for convenience, usually in a natural language, such as English. The 802.11 standards prior to the 2012 edition did not define any particular encoding/representation for SSIDs, which were expected to be treated and handled as an arbitrary sequence of 0–32 octets that are not limited to printable characters. The IEEE 802.11-2012 defines a tag that the SSID is UTF-8 encoded and when interpreting could contain any non-ISO basic Latin characters within it. Wireless network stacks must still be prepared to handle arbitrary values in the SSID field."
The new hashline is designed to be published on websites, too - regardless of the character encoding!
The ESSID (salt) is part of PBKDF2 (PBKDF2(PRF, Password, Salt, c, dkLen)). Missing values, due to false character encoding, will lead to unrecoverable hashes.