Yubico Forum

JakobE,

Here is the problem I have with your reply.
You blame the lack of entropy on the use of CryptGenRandom by the personalization software. This software is written by Yubico, not us the end user; thus Yubico’s decision to use CryptGenRandom is truly at the heart of the problem. Why not generate your own RNG and incorporate it into the software to give us far better entropy? Does this mean that if I use the Linux or Mac version I’ll get a better result in that those versions inherently have to use something other than the WIN32 API CryptGenRandom?

I’ll admit that I didn’t go into the bowels of the documentation before buying my Yubikeys for testing and shame on me for not doing so. I simply went off the “Static Password” page on Yubico’s website:

http://www.yubico.com/developers/static/



For reference that is the first statement in the third paragraph of the page. This led me to erroneously believe that I could in fact include any combination of 16 to 64 characters or numbers as my static password. Seeing as I heard of the Yubikey from Steve Gibson’s podcast I know of his passwords page and I have been using that page to generate passwords to secure accounts that I’m responsible for. Based on reading that page I thought that I would be able to go to grc.com/password and generate one phenomenal password to use in the static mode of my Yubikey, and not just mine the ones that I intended to deploy across my company to secure our password databases. Never mind my intent to push Yubikeys into my client locations to secure laptops with TrueCrypt and strong passwords stored in a Yubikey and to champion the use of AuthLite to the same clientele to authenticate to their active directory networks.

You see, there is no mention of a limitation to 16 ModHex characters in that page, and even if there were while I know what this means – does your average target audience know what 16 ModHex means? I never intended to use the Yubikey as a password generator, my intent was to use grc.com/password to generate my passwords and to use the Yubikey to store 1 or 2 of those passwords so that I might be able to use them with KeePass and TrueCrypt and Lastpass. Alas the statement on the page at best is deliberately misleading and at worse completely false.

Do you understand my disappointment? How about when I have to meet with my boss this Friday to explain to her that the project idea that I have been pushing for in the last 6 months and finally got approved last week to test in house for our company won’t be quite as secure as we intended because the page that I used for reference on the capability of the tool that I intended to use was not accurate?

Very sorry to hear that you're disappointed. We'll have to be more consise how we communicate things and update our documentation accordingly. Please help us improve by telling where to make the appropriate updates so this become clear:

a) The static mode does exactly what we say it does: It emits a static string according to the input by the user.

b) The particular tool in question - the Windows config tool (which I assume has been used here) states in section 2.2:

2.2 Random numbers
Where random number generation is used in the application, the random values are generated using the Win32 Crypto API function CryptGenRandom, which should satisfy most needs. There is no special seeding or additional obfuscation added.

c) You can use your own routine to create any input to the static mode and paste that as the public identity and key fields as long as you can get them as hex strings. Then you'll get 32x8 = 256 bit password according to your personal requirements. I don't really see the problem here unless you want more than 256 bits.

d) The scan code mode is currently limited to 16 characters which is also stated in the manual. We'll increase this to 32 or 38 characters in the next firmware release, but you'll have to type them in if you use the configuration tool. At present, we have no intention of making a mapping tool that correctly maps all scan codes according to all available keyboard layouts.

e) The Configuration API can be used if a custom random number generation scheme is needed.

Please let me know if there is anything we can do to turn you into a happy customer. A set of free keys with the new firmware or a full refund ?

With the best regards,

JakobE
Hardware- and firmware guy @ Yubico

JakobE,

I’ll reply using the same outline you use so my answer a) corresponds to your statement a) and so on.

a) This statement is akin to me selling you a V8 engine and telling you that it delivers 400 horsepower without also adding the caveat that “ V8 engine delivers 400HP when all 8 cylinders are enabled, and I only enabled 4”. Your static page reference in the Yubico site need to explicitly say something to the fact that the 64 character password is limited to a ModHex16 and enumerate those characters. The page leads people to believe that one is capable of putting any text string in the static password mode and that is just not the case.

b) Indeed what I used was the Windows Yubikey Configuration Tool. Again I’ll take full responsibility for not diving into the bowels of the documentation before buying Yubikeys instead of only relying on the statements on http://www.yubico.com/developers/static/ .

c) I have used my own seeding the HEX values from separate runs of grc.com/password to input into the public, private and ID. I don’t really want more than 256 bits however repeated testing of using seeds from known good random HEX code from grc.com/passwords, the build in calls to GenCryptRandom, and using the “Single Rand” option the best I can get to output from the final 64 character password in the Yubikey is 157 bits – that is quite shy of 256.

d) 32 or 38 characters clearly increase the depth to the capacity of the static mode password of the yubikey. However if you still have no way to allow the end user to program their own static password without the use of a Hex string it will still be less than the theoretical best it can achieve because it will still rely on either a call to CryptGenRandom or static Hex input from a user.

e) I’d love to have the skillset to program in a relatively modern language and generate a strong RNG that I can share with this community. However I don’t have time to learn a programing language at this time to accomplish this so I’m stuck using the formats available on the Yubico program.

I’m not into getting something for nothing; this is not at all my intent. Can the keys I own be sent back to Yubico to be reprogramed with the new firmware? If not I’ll take responsibility for not reading all the documentation and just suck it up and drive on, for me and my company the money is not the issue here. The issue is that we expected to get a given capability and the device can’t deliver it.

You have no idea how badly I want this to work as advertised. I love the idea of having a self-selected 64 character password in my YubiKey. I want to be able to show this to our clients and explain to them that they must buy this, that they must use it for the sake of securing their data (you know with TrueCrypt full disk encryption).I want to be able to tell them that they need to use a Yubikey OTP for their Active Directory logons and for their Firewall based VPNs (via a RADIUS solution). It pains me that we aren’t there yet.

It seems like we got a bit stuck here. Maybe my response was a bit bullish and I feel I must have missed something.

The rationale behind using the CryptGenRandom function is simple - Instead of us supplying something home-brewed that most likely would rise quite a few questions, we rely on something that's proven and used by several applications and fits most needs. Not all, and it's not perfect. I would prefer to have a hardware RNG in all cases and we use that when we batch generate keys here.

grc.com/password does a better job - agree. What if we would simply add a new option in the config tool where you can paste in your 32 byte hex string and that would be used ? We'll then take half of the string into the fixed part and the remaining half into the AES key.

We like feedback and I would be pleased to offer you two new keys, supporting a 38 character scan-code. Please send an e-mail to jakob at yubico dot com and I'll send them together with an updated config tool. If I then can your feedback and understand if this solves your concerns, it's a deal for me.

With the best regards,
JakobE
Hardware- and firmware guy @ Yubico

JakobE,

I understand the answer behind CryptGenRandom. While the explanation seems reasonable you have to also acknowlege that us, the end users have to trust someone some time and that by the mere fact that we have purchased Yubikeys that we have to trust Yubico in some form or another. If I didn't have the trust (albeit by proxy because of Steve Gibson's endorcement of the product and company) I would not have ordered the YubiKeys I did. To that end it would have been simple to generate the code for a Yubico RNG and make that portion of the software Open Source so it can stand up to the scrutiny of the implementers and users of the keys. Also I think that Steve Gibson would be more than happy to license the code to his Passwords site to Yubico for the purpose of the RNG.

Allowing us to paste a known, high entropy 32 byte hex string would be an outstanding feature. I'd love to try it out.

I belive that the reason for these forums is in fact to have that feedback loop to Yubico and to other users that might have the answers that we seek. So yes I would love to test and feedback the hardware & the new config tool to you and to this forum.