Yubico Forum

Re: Test vectors

2008-06-10T09:33:42+01:00

I'm not sure I understand perfectly here, but I really hope that nobody has reached the 2^15 limit for a real yubikey -- since I gave away the AES key for that yubikey, a software implementation will be able to "kill" that yubikey as far as the server believes. But if you give away the AES key, the security is gone... so this is all to be expected, right?

/Simon

Statistics: Posted by Simon — Tue Jun 10, 2008 9:33 am

Re: Test vectors

2008-06-09T21:15:48+01:00

Key is absolutely dead when this happens. (unless the admins manually rewrap the key back to 0 everything on the server.)

Note, Just the 8 hz timer is enough to detect that the key has not been replayed, even if the other counters has not wrapped, but once that reaches 16777215, with button press counter at 255, and insert counter at 65535 (Actually detected as 32767 with caps lock activation), and that OTP is played, no further OTPs from that key will ever work, without a reset. This condition has already been met, by my hands.

Statistics: Posted by caitsith6502 — Mon Jun 09, 2008 9:15 pm

Re: Test vectors

2008-06-09T19:16:31+01:00

caitsith6502: Ups it's already up to 60000 now (giving me a NON-REPLAY-OTP)... wonder what happens when it reaches 65535 wrap around?
Well I am not going to spoil that virtual yubikey. But whenever someone hits the magic 2^16 - lets see how yubico's servers handle that

Best regards,
Alex

Statistics: Posted by hasterguf — Mon Jun 09, 2008 7:16 pm

Re: Test vectors

2008-06-09T18:18:32+01:00

Simon: when was the last time you used the yubikey that you gave test vector samples of? A few simulated inserts later, and this is the end result. (And check the test your key page, in OTP mode only. (Remove and reinsert till you get in.) (Although You may be able to get that info directly.).

(Note, all yubikey OTPs that were used to get me here, were generated on http://zyz.dk/yk/generator_0.2/yubi_generator.php.) As a result, the real physical yubikey, that is in Simon's possession, will end up hitting on the REPLAYED_OTP error for the next few inserts.

Statistics: Posted by caitsith6502 — Mon Jun 09, 2008 6:18 pm

Re: Test vectors

2008-06-09T16:21:30+01:00

Hi,

if you need more testvectors

You can make all the test-vectors you like here: http://zyz.dk/yk/generator_0.2/yubi_generator.php
And you can test-decode otp's here: http://zyz.dk/yk/class_0.5/yubikey_test_decode.php

Best regards,
Alex

Statistics: Posted by hasterguf — Mon Jun 09, 2008 4:21 pm

Re: Test vectors

2008-06-09T12:47:53+01:00

There have been requests for more test vectors for real OTPs, so here is a bunch from a key with this AES key:

Code:

B64 secret: BoKVLTNj8iVlS1inOxMSWQ==
Hex secret: 0682952d3363f225654b58a73b131259
Modhex secret: chjdkgdteehevddghgfngjlienbebdgk

A few OTPs are:

Code:

ndgtriluugngkuhguutjdfihfkleuvnjtjiljkbtbngb
ndgtriluugnghggtkhvrbbrrgtdfeivgklbkviteggcu
ndgtriluugngvlbnjllchllugvhhftndludrjubuuvkh
ndgtriluugngvukkrdlbvnettvhdhcjfgtjljkufulfe
ndgtriluugngnfdeicbdnfhlinhjvkufikdvbunjjvbn
ndgtriluugngbclrcivunvrbghicrfkeflvgrkdrfbve
ndgtriluugngvkdlfkvljfcvbehdvbtelhuutgdhfdku

You should be able to print debug info using the 'tool' program from the yubico-c project, see: http://code.google.com/p/yubico-c/

Outputs for the first two OTPs are:

Code:

jas@mocca:~$ tool chjdkgdteehevddghgfngjlienbebdgk ndgtriluugngkuhguutjdfihfkleuvnjtjiljkbtbngb
warning: overlong token, ignoring prefix: ndgtriluugng
Input:
  token: kuhguutjdfihfkleuvnjtjiljkbtbngb
          9e 65 ee d8 24 76 49 a3 ef b8 d8 7a 89 1d 1b 51 
  aeskey: chjdkgdteehevddghgfngjlienbebdgk
          06 82 95 2d 33 63 f2 25 65 4b 58 a7 3b 13 12 59 
Output:
          c5 fc 55 c3 76 7f 0d 00 00 00 00 00 1a 33 6d 9d 

Struct:
  uid: c5 fc 55 c3 76 7f 
  counter: 13 (0x000d)
  timestamp (low): 0 (0x0000)
  timestamp (high): 0 (0x00)
  session use: 0 (0x00)
  random: 13082 (0x331a)
  crc: 40301 (0x9d6d)

Derived:
  cleaned counter: 13 (0x000d)
  modhex uid: rgvrggreihiv
  triggered by caps lock: no
  crc: F0B8
  crc check: ok
jas@mocca:~$ 

Code:

jas@mocca:~$ tool chjdkgdteehevddghgfngjlienbebdgk ndgtriluugnghggtkhvrbbrrgtdfeivgklbkviteggcu
warning: overlong token, ignoring prefix: ndgtriluugng
Input:
  token: hggtkhvrbbrrgtdfeivgklbkviteggcu
          65 5d 96 fc 11 cc 5d 24 37 f5 9a 19 f7 d3 55 0e 
  aeskey: chjdkgdteehevddghgfngjlienbebdgk
          06 82 95 2d 33 63 f2 25 65 4b 58 a7 3b 13 12 59 
Output:
          c5 fc 55 c3 76 7f 0d 00 16 00 00 01 5f 97 0b 46 

Struct:
  uid: c5 fc 55 c3 76 7f 
  counter: 13 (0x000d)
  timestamp (low): 22 (0x0016)
  timestamp (high): 0 (0x00)
  session use: 1 (0x01)
  random: 38751 (0x975f)
  crc: 17931 (0x460b)

Derived:
  cleaned counter: 13 (0x000d)
  modhex uid: rgvrggreihiv
  triggered by caps lock: no
  crc: F0B8
  crc check: ok
jas@mocca:~$ 

Happy hacking,
Simon

Statistics: Posted by Simon — Mon Jun 09, 2008 12:47 pm

Test vectors

2008-05-19T11:13:18+01:00

To make it easier to port the basic server libraries to other languages, we publish below some test vectors that can be used to detect errors in your code. People have expressed a desire to port our libraries to Python and Perl, and we'd certainly like to see that happen!

Code:

Test vectors for Yubikey
------------------------

The YubiKey output consists of a two fields concatenated with each
other:

YubiKey = [identity]

The "identity" field is a variable-length ModHex encoded identity
field.  If no static identity is wanted, it may be omitted (i.e., of
zero length).

The "otp" field is a 32 characters fixed-size ModHex encoded field
with a AES encrypted plaintext block of a specific format.

Test vectors are needed for ModHex, AES in ECB mode, and internal
parsing of the plaintext.

In this file, we'll use the sample YubiKey
'dteffujehknhfjbrjnlnldnhcujvddbikngjrtgh' for demonstration purposes.

Modhex
------

Modhex is an encoding mechanism, much similar to hex-encoding but the
alphabet is the alphanumeric string 'cbdefghijklnrtuv' instead.

The input is an arbitrary binary string.  The output is a ASCII
string, twice as large as the input.

INPUT:     hknhfjbrjnlnldnhcujvddbikngjrtgh
DECODE:    69b6481c8baba2b60e8f22179b58cd56 (in hex)

More test vectors:

INPUT:     test
ENCODE:    ifhgieif

INPUT:     test
ENCODE:    hhhvhvhdhbid

AES-ECB
-------

This is standard AES-128 in "raw" mode, i.e. Electronic Code Book.  It
is assumed that the same input is never encrypted twice.  We only use
key sizes of 128 bits.

INPUT:    69 b6 48 1c 8b ab a2 b6 0e 8f 22 17 9b 58 cd 56 
AESKEY    ec de 18 db e7 6f bd 0c 33 33 0f 1c 35 48 71 db 

OUTPUT:   87 92 eb fe 26 cc 13 00 30 c2 00 11 c8 9f 23 c8 

Plaintext
---------

The following plaintext converted into a structure:

PLAINTEXT:  87 92 eb fe 26 cc 13 00 30 c2 00 11 c8 9f 23 c8 

  uid: 87 92 eb fe 26 cc 
  counter: 19 (0x0013)
  timestamp (low): 49712 (0xc230)
  timestamp (high): 0 (0x00)
  session use: 17 (0x11)
  random: 40904 (0x9fc8)
  crc: 51235 (0xc823)

The CRC value is not used for cryptographic authentication, just as a
sanity check.  It is CRC-16 checksum computed on the entire structure
(including the provided crc value from the plaintext), and the residue
should be 0xf0b8.  The CRC-16 value computed on the above PLAINTEXT
would be:

  crc: F0B8

This matches the expected residue.

Questions?
----------

Talk to .

-- 
$Id: test-vectors.txt,v 1.3 2008-04-03 14:50:25 jas Exp $

Statistics: Posted by Simon — Mon May 19, 2008 11:13 am