Yubico Forum

We've been asked quite a few times now regarding the modhex scheme used by the Yubikey. Why don't you use for example base64 instead as this would allow six bits to be sent for each keytstroke instead of just four for the modhex scheme.

The answer is keyboard layouts - Most countries have different keyboard layouts and what most people don't think about it that the keyboard mapping is not known by the keyboard itself. The keyboard is luckily unaware of what text is printed on top of the keys. It simply just sends the key number or "scan code" and then the computer translates it depending on your keyboard settings.

After quite some investigation we found out that there are a few keys that are mapped to the same scan code for almost all national settings. There we have the modhex codes.

The Hexadecimal "alphabet" goes like:
0123 4567 89ab cdef

And the modhex maps to:
cbde fghi jkln rtuv

An example: The hexadecimal number "4711" would therefore translate to "fibb"

You've probably guessed it already... Modhex stands for... MODified HEXadecimal...

Regards,

JakobE
Hardware- and firmware guy @ Yubico

So it is not perfect...

What hides behind that 'almost'..., nothing to worry about for practical purposes?

One thing this triggered: Will there be problem with asian locals? Happens my company is working against the South Korean marked.

Well - there is a dormant politician in all of us, isn't it... ?

Honnestly, that "almost" is just a humble way to say that we might have missed some specific mapping somehwere. I've not found any good table with keyboard scan codes vs. characters vs. national mapping in a form to allow automated mapping. The work has been manual from graphical layouts of different national keyboards.

Anyone knowing such a table / set of tables anywhere ?

Regards,

JakobE
Hardware- and firmware guy @ Yubico

Ok, so one thing is the physical keyboard and the other is thing is the local.

For example I changed my local to Russian and tried to log in, and failed because I produced something similar to

тлеассвавогртлурвшкдрушдратгммуиаушпдвемгуор

switched back to english and got in.

I guess if you have end users that do use non latin locals but they access your latin local based service it is not an issue: They will
have to change local anyway. But if you are doing a service based on a non latin local you will have to localize your modhex encoding/decoding functions or if you are i18n you need to i18n your modhex methods.

So in the case above if I took the known latin modhex latin alphabet, took what it translated it to a russian alphabet and used that I would be done... perhaps, I have not tried it!

Hm... wonder how generic that can be done...

You're right - for non-latin type keyboards, additional logic is needed on the server. We've not fixed that yet on our server, but it is on the wish list. The Cyrillic characters you supplied in your example is definately something we should consider early on.

Given that one expands the scope beyond ASCII, i.e. to Unicode, the server logic can be more adaptive and probably accept input from most languages.

The key issue with modhex is to remove the ambiguity between different latin keyboards.

Thanks - all input in this matter is appreciated,

Regards

JakobE
Hardware- and firmware guy @ Yubico

Perhaps I'm missing something obvious, but I'm wondering why it wasn't bcde rather than cbde? Other than the cb, the other letters are in alphabetical order in English (and apparently in Swedish as well) .

Dick

Swedish is a strange language, so it could very well have had something to do with that

But it is rather the thing that the character 'c' is the only one that is potentially ambigous. If 'c' maps to a different character not used in the modhex alphabet, that character shall also be treated as hex '0'.

Another way to see it is that the modhex alphabet is

bde fghi jkln rtuv -> 0x1 - 0xf All other characters being 0x0

Regards,

JakobE
Hardware- and firmware guy @ Yubico

Thanks. I think I've got it now.

Regards,

Dick