# Why do wireless keyboards only use 128-bit AES? Why not 256?

I've looked for 256-bit AES encrypted wireless keyboards, and apparently they don't exist. Can anybody explain why this is from a cryptographic point of view?

Why wouldn't they just opt-in to the highest standard of encryption, instead of settling for the runner-up? Is there any cryptographic (or closely related) reason why industrial producers might have decided to use AES-128 instead of AES-256?

• Comments are not for extended discussion; this conversation has been moved to chat. Please use the chat for further discussions… – e-sushi Sep 15 '17 at 11:18
• – leonbloy Sep 16 '17 at 17:49
• use a with-wire keyboard, and don't care. ;) – daruma May 15 '18 at 1:20

AES-256 isn't "better" than AES-128 in any practical sense. A crack of AES-128 will almost certainly bring down AES-256 anyway, and there's no practical difference between 128-bit keys and 256-bit keys — nobody will crack a 128-bit key in the future of humanity as a species.

On the other hand, AES-256 likely requires more power draw than AES-128 for this piece of hardware. I'll take an extra hour of battery life over a meaningless difference in security. Hell, I'd take an extra five minutes of battery life.

• Comments are not for extended discussion (20+ comments!); this conversation has been moved to chat. Please use the chat for further discussions… – e-sushi Sep 15 '17 at 11:17

I believe that the answer actually lies in 0.5 cents. It costs me about 0.05 dollars per $mm^2$ on die. If AES-128 is adequate for an application, there's not a compelling business reason to use AES-256 considering that it increases cost. Furthermore, because you are doing hardware, AES-256 is a bit of a hassle as you have to fill out arms export forms when you fab your ICs.

Pretty much, all ICs and specifications are around a minimally viable VLSI implementation. In this case, some one made an extra \$500k on \$100m in IC sales.

• Do you have a pointer for that regulation that makes it harder to export AES-256 then AES-128? I'm genuinely interested. Aside: I would be surprised if AES was in hardware on a keyboard; and in software, the cost difference between AES-128 and AES-256 is inexistent. – fgrieu Sep 14 '17 at 15:47
• @fgrieu Most of the bluetooth ICs I am aware of have the AES support in hardware. An example from Qualcomm: qualcomm.com/documents/csr1010-data-sheet (it's in the keyboard I have). Regarding export control, it's crazy, but here's the short list for the USA: first we have ITAR, but for encryption you need to follow: bis.doc.gov/index.php/forms-documents/doc_view/320-76-fr-1059 after that, I need to have ECCN numbers. My 128-bit work was 3E001 and 3A001 and the 256-bit work was 3E991 and 3A991. The fabs enforce the paperwork before I can get my ICs back. – b degnan Sep 14 '17 at 23:35
• Sorry to be anal, but 0.05 dollars is 5 cents, not 0.5 cents. – user45623 Sep 15 '17 at 19:12
• @user45623 I was making a guestimate at the area required on 45nm to increase the size from 128 to 256 with the H(x) transform and 2x the shift registers. That's the origin of the 0.5 cents. I didn't explain that. In theory, it doesn't take much to make a 256 bit key, but it makes things surprisingly large at lower nodes due to just the complexity of the nodes. – b degnan Sep 15 '17 at 20:38
• D'oh! I should have thought that through more. – user45623 Sep 15 '17 at 20:42

It's about balancing security and usability.

AES-128 is more than secure enough to protect your data, and it's a lot faster than AES-256 is. Why would they opt for an arguably more useless security margin when the drawbacks would be a worse response time for keyboard.

I'd bet a lot more people will complain about poor response time than having an insane security margin.

• If you can notice the difference in responsiveness of a keyboard between AES-128 and AES-256, whatever device is inside the keyboard must use an unbelievably slow implementation of AES, as if it were intentionally designed to be bad. What is this, a homomorphic encryption AES circuit? – Squeamish Ossifrage Sep 13 '17 at 19:51
• More important is that it takes more power. – Stephen Touset Sep 13 '17 at 20:06
• @SqueamishOssifrage, the priorities for the CPU in a wireless keyboard are that it be 1) cheap and 2) low-power. I wouldn't be surprised to find that it's an 8-bit microcontroller running at 1 MHz. – Mark Sep 13 '17 at 22:46

In a keyboard, that is doubly true. First, your threat model is that someone can intercept, eavesdrop and/or manipulate your keyboard input. Which is fleeting. So your attacker either listens and records a lot, or is attacking you at the exact right moment. Neither of which is likely to give him the top ultra highest level state secrets that would warrent an attack where the difference would even come into play theoretically.

Considering the threat, even a weaker encryption would be absolutely fine. However, right now AES-128 is actually closer to AES-256 than most people think, because there exist attacks on AES-256 and AES-192 that reduce their effective key length to about 176 and 119 respectively. This attack does not affect AES-128. (see, e.g. Schneiers post).

A practical attack on any of these key lengths is not feasable for the forseable time, even for state actors.

Combine that with the threat model and there is simply no reason whatsoever to use AES-256 in a keyboard if it costs even one cent more.

• A better attack vector would be a pinhole camera aimed at the keyboard to record your fingers' motion. – Wildcard Sep 15 '17 at 23:57

AES-128 is not insecure, it is just less secure than AES-256, simply because the later uses more bits. Currently no known attack vector exists, that can crack either or even come close to cracking any.

If you have to choose a security method you also need to consider how important a strong cryptographic algorithm is vs the time it takes to calculate it. A keyboard has limited CPU power, the data transmitted is usually of low value and is also very volatile. The low CPU power makes a faster algorithm desirable, and the low risk and high volatility makes AES-128 completely sufficient.

An important document on a PC has a high value, is usually stored for a very long time and sufficient CPU power is available. There is no need for a particular fast algorithm, so the more secure one should be chosen, which is AES-256.