Yubico Forum

I wrote the php anything -> modhex converter. Code is at http://dingoskidneys.com/cgi-bin/hgwebdir.cgi/yubikey

modhex.php provides a function decode_modhex($otp, $to); where $to is the destination alphabet and defaults to standard hexadecimal. It returns a (usually one element) 0-n element array of possible interpretations of $otp. As long as you provide $otp in UTF-8, decode_modhex() can interpret $otp for almost any keyboard layout and give it back to you in standard hexadecimal.

Has there been any progress on getting this integrated into the validation server? As a Dvorak user and new YubiKey owner, it just took me a good hour to figure out that I needed to switch back into QWERTY for my YubiKey to work. I was in the middle of explaining the problem in a support email when the light bulb finally went off

Sorry for keeping all Dvorak guys on the hook in this matter. We've been evaluating several options for not just supporting Dvorak keyboards but also other languages. Given the overall complexity of of the task, it has been somewhat dangling. I hope we'll be able to present a good solution meeting the needs later this spring. That's the best guess for now.

With the best regards,

JakobE
Hardware- and firmware guy @ Yubico

I moved my keyboard layout translation software to http://bitbucket.org/dholth/yubikey/ . It takes a Yubikey OTP from almost any keyboard layout and spits out the possible modhex translations. There is usually only one possibility but occasionally there are a couple of possibilities. The JavaScript version is still demoed at http://dingoskidneys.com/~dholth/yubikey/

The source includes the JavaScript version, a PHP version that could basically replace the "is this a valid yubikey" regex inside the server, a Python version, and some other stuff. If you're running your own validation server you might want to check it out.

For those using X11 >= 1.7.99.901-1, put the following in /etc/X11/xorg.conf to have the yubikey get a us keyboard layout regardless of what layout you normally have:

A bit late late to the discussion, but to throw in my 2 cents; wouldn't the easiest be to just prepend each OTP with each of the modhex characters? That way you can read which character in the current keymap represents each modhex character?

The "language prefix" approach has been thought of long ago, but just makes the entry time even longer.

When making AuthLite we did some calculation and it turns out to be VERY easy to discern Dvorak vs Qwerty with a high level of confidence. There are some very unlikely cases where an OTP could be either language. In these cases we have chosen to ASSUME qwerty. One could also try qwerty first and fail over to dvorak and try again with that.

It seriously took us like, one day to figure all this out in AuthLite and build it in. But that's because I am a dvorak user so any product I work on had better support it

We have the option of sending all modhex characters first by setting the CFGFLAG_SEND_REF flag during configuration. Then, the string "cbdefghijklnrtuv" is sent first in all OTP outputs.

Regards,

JakobE
Hardware- and firmware guy @Yubico

Couldn't you just integrate dholth's code into the main server and then this problem would be solved? That seems the easiest and best solution. Switching back and forth is annoying

Isn't there a way to use udev and xorg.conf file to get ubikey seen as qwerty keyboard whatever layout used by user?
Of course this should be useful only for Linux system.


Sorry for my bad English I don't speak it very often.