89

I work at a place that gives Wi-Fi to all the customers, with a password that is 19 characters long. A customer came in and claimed that because the password is long, it slows down the internet speed. Is there any truth to this claim?

unor
  • 1,769
  • 1
  • 19
  • 38
user213838
  • 571
  • 1
  • 4
  • 4
  • 70
    It's worth noting that if the speed of your connection were affected by the length of the password, it would be a very _very_ bad sign about the security of the wireless network connections. – Pavel Aug 06 '19 at 08:50
  • 33
    Did the customer ever explain where (s)he got this idea from? I'm curious to know – BlueCacti Aug 06 '19 at 08:55
  • 8
    Whenever I read "a customer claimed" I can't help but to think about a show called "kids say the darndest things". – Num Lock Aug 06 '19 at 09:04
  • 63
    Is there any possibility that the customer meant "speed to access (i.e., connect to) the Internet"? That would be a much more logical conclusion. – xLeitix Aug 06 '19 at 09:52
  • 5
    No, except the construction of the cryptographic key might take a few cycles extra, but that will only differ a few microseconds, so not noticable at all. – Willem Van Onsem Aug 06 '19 at 10:17
  • 4
    I should very much hope the answer is "no" because my Wifi password is 62 characters long... – Damon Aug 06 '19 at 10:42
  • 15
    Non-technical customers have all kinds of weird beliefs about computers. – dr_ Aug 06 '19 at 11:41
  • 52
    It certainly makes signing in slower. – Dave Newton Aug 06 '19 at 12:34
  • 7
    If anything, your wifi password length is inversely proportional to the observed network speed, insofar as if you have a short password, someone is more likely to brute force guess it and steal your bandwidth. – asgallant Aug 06 '19 at 21:27
  • It is however quite annoying and slow to type a 19 char password, why would you use such a long password if everybody knows it. – eckes Aug 07 '19 at 09:13
  • 4
    @eckes: “It is however quite annoying and slow to type a 19 char password” — that depends hugely on what the 19 characters are. `tomscoffeehouse2019` is barely slower to type than `tomscafe`, and much quicker than `t0M5kafA`. – PLL Aug 07 '19 at 09:45
  • 3
    I'm wondering if the 'customer' was attempting a social engineering attack by trying to get you to weaken the password (IE reduce it's length) making cracking said password proportionately easier. – SE Does Not Like Dissent Aug 07 '19 at 12:55
  • 2
    "The customer is always right," except when they're wrong. – devinbost Aug 07 '19 at 17:05

4 Answers4

167

No.

This is because your password is converted to a cryptographic key which is of fixed length (128 bits). For any length of password, the corresponding crypto generated key (CMAC) would be of fixed size. Many other parameters such as the client and server id, large random values provided by client and server are used to calculate this CMAC.

Encryption and decryption uses this fixed length CMAC.

Rohith K D
  • 1,029
  • 1
  • 7
  • 12
  • 5
    Another answer mentions 256 bits, so what is correct? – Jakuje Aug 06 '19 at 12:40
  • 14
    The other answer by @Gene mentions the process in more details. Pairwise Transient Key (PTK) generated in 4-way handshake is splitted into multiple keys. One of the resulted 128 bit key named Temporal Key is used for encrypting data frames. The KEK and KCK generated are used to protect handshake messages. – Rohith K D Aug 06 '19 at 13:12
  • For any length of password??? You mean, even multi-billion length password also the same length? – I am the Most Stupid Person Sep 26 '19 at 07:01
  • @IamtheMostStupidPerson Yes, because a Key-Derivation Function is used. Think of it like a hash function: You put data of arbitrary length in and get a fixed length output. It doesn't matter if the input is 8 bytes or 8 TB. –  Nov 19 '20 at 13:51
81

Short version: No, it does not. Your password is turned into a fixed-length 256-bit key (the "PSK" in WPA2-PSK), which is further turned into fixed-length temporary keys during the initial "handshake". These temporary keys are the ones used during the actual encryption, and usually change periodically.

No matter what your password, the underlying keys are fixed-length. Therefore, connection speed is unaffected by the password.

The password and the SSID are boiled down by a key derivation function (PBKDF2 for WPA2-PSK), from which we want 256 bits.

This key, called a PMK (Pairwise Master Key) is always 256 bits regardless of password length.

It is then used (along with nonces aNonce, sNonce and MAC addresses) in a 4-way handshake to generate the 512-bit Pairwise Transient Key (PTK), which is then split into multiple keys:

  • 128-bit Temporal Key (TK) - Encrypts data itself
  • 128-bit Key Encryption Key (KEK) - Encrypts keys (e.g. GTK) during transfer
  • 128-bit Key Confirmation Key (KCK) - Involved in EAPoL MIC (part of authentication)
  • 64-bit RX and TX keys, used for message integrity codes (MIC) on data frames

These multiple keys change periodically and are, again, fixed length regardless of the password. Specifically, your data is always encrypted by the Temporal Key (TK) and signed off by the TX/RX keys, which are always 128 bits and 64 bits respectively regardless of password length.

Password -> [PMK -> PTK -> Encryption keys]. Items in brackets are fixed length.

*GTK not discussed. Essentially the same as PTK, but multicast/broadcast, sans KCK KEK.

Aloha
  • 910
  • 7
  • 14
  • 5
    if by AKA you mean "also known as" please spell it out as it kind of appears to be yet another encryption acronym. – CGCampbell Aug 06 '19 at 13:33
  • Just to be clear: the derivation of the 128 bit PSK is also constant time, right? An 8 character password (shortest allowed) takes equally long to derive a PSK as a 64 character password? – Nzall Aug 06 '19 at 14:30
  • 1
    @CGCampbell I bet just 'aka' in lower case would be good enough. – Spencer Aug 07 '19 at 14:04
29

Password verification process is not linked to the connection speed. So the answer is no, the speed is not affected.

Community
  • 1
marcusaurelius
  • 365
  • 2
  • 4
  • 18
    No sources make this a poor answer, down-voted – Cloud Aug 06 '19 at 10:21
  • 12
    @Joe I dunno, the other answers are able to motivate why the answer is "no" just fine... – marcelm Aug 06 '19 at 10:32
  • 1
    @marcelm IMHO explaining how each process works is out of scope here. The important part is that password verification is a punctual ( whatever how it is done) check, and therefore doesn’t affect the speed. I tried to answer simply to a simple question that didn’t seem to require technical depth in both concepts. – marcusaurelius Aug 06 '19 at 12:09
  • 14
    @marcusaurelius Stack Q&A aren't here only to answer the question, but also to help others searching for answers to their own questions. The more details you get, the more helpful your answer will be and the more people you'll help. – Zoma Aug 06 '19 at 13:00
  • 8
    @marcusaurelius I disagree that such explanations are out of scope. But, more importantly, I think answers stating something as fact without backing that up aren't particularly helpful. It may not be necessary to detail the entire process, but I feel it would be better to mention the names of some relevant steps of the process, or provide links to sources with a more in-depth explanation. This way readers can _verify_ your answer, or _learn more_ if they so desire. Quoting the [help center](/help/how-to-answer): _"Brevity is acceptable, but fuller explanations are better."_ – marcelm Aug 06 '19 at 17:12
  • 1
    @marcusaurelius, I would argue that providing sources and an explanation is particularly important in this case. OP is gonna be disputing a customers claim "Longer password = slow connection". A simple no would most likely not suffice. – Tejas Kale Aug 08 '19 at 17:41
  • Finding a "source" to debunk this ridiculous claim is extremely unlikely, just as I'm very unlikely to find a reliable source that states that pianos are not edible. – barbecue Aug 09 '19 at 01:33
  • @barbecue [This source](https://en.wikipedia.org/wiki/Piano#Construction_and_components) explains that the chief material used in piano construction is wood, and [this page](http://meatfreemafia.com/humans-cant-digest-cellulose/) begins to explain why humans can't digest wood. This allows me to build a credible answer explaining that, no, piano's aren't edible. – marcelm Aug 09 '19 at 09:10
  • @barbecue Also, I don't think it helps anyone to call the claim discussed here "ridiculous"; I find it perfectly understandable that someone who doesn't know how wifi encryption works might think that. Yes, they're wrong, but instead of ridiculing the claim, we can explain _why_ they're wrong. – marcelm Aug 09 '19 at 09:11
  • @marcusaurelius I'm looking forward to your contributions here! – jpaugh Aug 12 '19 at 14:53
2

No.

When discussing this it is important to note that there are many links between your device and the server it is connecting to. Each link in that path has its own throughput rate and is limited in a variety of ways - none of which have to do with a password length.

Each physical medium, WiFi, Ethernet, Microwave, Fiber, have data rates associated with them. The devices at each end of the links also have limitations both physical and through the software controlling them. But once again, none of those limitations have anything to do with the length of a password.

Physical conditions are the only other things that can limit link rates. For wireless links, the RF conditions rule. For Fiber, it can depends on the laser, the bending of the fiber, the cleave of the ends, etc. For wires, it depends on the connectors, the cable, etc. And again, the password length has nothing to do with these conditions.

The customer may have been confusing password length with key length. But even then, computers are so fast and the implementations so efficient, users are not going to notice the latency associated with those algorithms.

My company, for example, uses AES-256 to do real-time video encryption and decryption at more than 20Mbps with an end to end latency of less than 60ms. The encryption is a very minor part of that 60ms. The encoding and decoding of the H.264 and H.265 (HVEC) video is by far more computationally intensive than the encryption.

Tracy Cramer
  • 853
  • 5
  • 10