Subject: rijndael test vectors

From: Marcus Watts <[email-masked]>
Date: Tue, 04 Sep 2001 21:36:30 -0400

I read through draft-raeburn-krb-rijndael-krb-01.txt and couldn't help
but notice the rather vague "test" vectors at the end.  So following is
what I got.  I actually wrote several versions of code to generate test
vectors; one used bits of openssl (not as pretty as I had hoped), and
the following was produced with code that I think is quite close to
what would be needed in k5 to implement the draft.

I also have more notes on what I thought after reading through the
draft & writing code to produce the following, which I'll post as soon
as I clean it up a bit.

				-Marcus Watts
				UM ITCS Umich Systems Group

> salt ""
Salt:
000000:
> pass -z -e rijndael -k 16 test
pass <test> iter=2 keylen=16
password (hex):
000000: 7465 7374                               test
000004:
intermediate key:
000000: 2c61 eea6 fffb 2999 b5d1 71b7 54ce 789a ,a....)...q.T.x.
000010:
rijndael128 final key:
000000: c41a f385 5e3c e9f0 3fe0 166d 540d  835 ....^<..?..mT..5
000010:
> pass -x -e serpent -k 16 test
serpent128 final key:
000000: 98b8 9b81 dd70 f7b7 4001 62b9 f244 7faf .....p..@.b..D..
000010:
> pass -x -e twofish -k 16 test
twofish128 final key:
000000: c678 dd26 c566 193d 92d0 ebaf 1aae bef9 .x.&.f.=........
000010:
> pass -z -e rijndael -k 24 test
pass <test> iter=2 keylen=24
password (hex):
000000: 7465 7374                               test
000004:
intermediate key:
000000: b2b6 3a06 d54e 861b 8add 5fbe 8d7f b5ff ..:..N...._.....
000010: 85ac 9eaa c50f f813                     ........
000018:
rijndael192 final key:
000000: c0fd 9060 2f8a 3a7b 2f85 ac4c 3425 caf7 ...`/.:{/..L4%..
000010: c140 5f9f 4165 4ec7                     [email-masked].
000018:
> pass -x -e serpent -k 24 test
serpent192 final key:
000000:  63a 180e a11c a7ac 544e a6d2 6c23 d58d .:......TN..l#..
000010: eb6e 8427  55a a082                     .n.'.Z..
000018:
> pass -x -e twofish -k 24 test
twofish192 final key:
000000: 825f 1c3f cd50 ba36  7d5 c140 2790 9919 ._.?.P.6...@'...
000010: 9843 cc73 e157 2bf2                     .C.s.W+.
000018:
> pass -z -e rijndael -k 32 test
pass <test> iter=2 keylen=32
password (hex):
000000: 7465 7374                               test
000004:
intermediate key:
000000: 1e28 9113 48b6 aced 7958 e2e8 3bbb 6709 .(..H...yX..;.g.
000010: 208d 787f ad31 ee71 ca0e 3741 3044   12  .x..1.q..7A0D..
000020:
rijndael256 final key:
000000: f125 f788 9fc0 df44 14a3 6a9d 1dfc a9a7 .%.....D..j.....
000010: 36bd 5c92 9ff5 fa0f 2021 ce8d 1772 285a 6.\..... !...r(Z
000020:
> pass -x -e serpent -k 32 test
serpent256 final key:
000000: a66a d411 78ed 31fc f3d8 2123 e96d 1e58 .j..x.1...!#.m.X
000010: bf4d 40f4  5a0 90b5 4c87 1fc4  fd6 f246 .M@.....L......F
000020:
> pass -x -e twofish -k 32 test
twofish256 final key:
000000: 33c6 2b0b 8f73 c9fd 71cb 387f cf63 ca8f 3.+..s..q.8..c..
000010: aa25 ac67 b68e 5496 7a6d 8682 bb3e 72f3 .%.g..T.zm...>r.
000020:
> salt "ATHENA.MIT.EDUraeburn"
Salt:
000000: 4154 4845 4e41 2e4d 4954 2e45 4455 7261 ATHENA.MIT.EDUra
000010: 6562 7572 6e                            eburn
000015:
> pass -z -e rijndael -k 16 password
pass <password> iter=2 keylen=16
password (hex):
000000: 7061 7373 776f 7264                     password
000008:
intermediate key:
000000: 262f b72e a65b 44ab 5ceb a7f8 c8bf a781 &/...[D.\.......
000010:
rijndael128 final key:
000000: 9e50  3a6 38af 5bed 162b f15d  b97 fbb2 .P..8.[..+.]....
000010:
> pass -x -e serpent -k 16 password
serpent128 final key:
000000: fc37 510c 3768 4956 da7b 7ecc 58cf c58e .7Q.7hIV.{~.X...
000010:
> pass -x -e twofish -k 16 password
twofish128 final key:
000000: f4a8  2b8 650d 7232 722f 3795 7e47 5dcf ....e.r2r/7.~G].
000010:
> pass -z -e rijndael -k 24 password
pass <password> iter=2 keylen=24
password (hex):
000000: 7061 7373 776f 7264                     password
000008:
intermediate key:
000000: 9c2c ef96 51c6 f0bf 1d4a b2b4 7e33 aa42 .,..Q....J..~3.B
000010: 10bc  4e5 ae73  f7d                     .....s.}
000018:
rijndael192 final key:
000000: 6f21 73b3 751b 7cd0 58ed 8afd a29c db4f o!s.u.|.X......O
000010: a03c 4714 60f6 e28f                     .<G.`...
000018:
> pass -x -e serpent -k 24 password
serpent192 final key:
000000: b007 5ecc  e12 48d2 fd5a f412 ac6e e13e ..^...H..Z...n.>
000010: 4045 73aa d290 629f                     @Es...b.
000018:
> pass -x -e twofish -k 24 password
twofish192 final key:
000000: 95d3  280 c647 c10d 83b6 bfb8 1c4d d978 .....G.......M.x
000010: c2d0 3460 5d2a d956                     ..4`]*.V
000018:
> pass -z -e rijndael -k 32 password
pass <password> iter=2 keylen=32
password (hex):
000000: 7061 7373 776f 7264                     password
000008:
intermediate key:
000000: 59f7 2373 fb55 73d1 b95e  7f8 22ff ac82 Y.#s.Us..^.."...
000010: b95a ec3f 8099 c943 eeae b304 5bff bdc1 .Z.?...C....[...
000020:
rijndael256 final key:
000000: 6793 d32f e27d 7c63 ea66 98eb 2d05 7f48 g../.}|c.f..-..H
000010: 256b 4eae 7466 1634 d48a ab30 e5ce 83bc %kN.tf.4...0....
000020:
> pass -x -e serpent -k 32 password
serpent256 final key:
000000: b71c 1233 a148 59b3 2d2a 2af5 ae29 9447 ...3.HY.-**..).G
000010: a31a 236e 5a65 1e8a 65d9 82b2 f85a 7b00 ..#nZe..e....Z{.
000020:
> pass -x -e twofish -k 32 password
twofish256 final key:
000000: 2166 1778 6009 4117 2bb0 d1ac dffa b25b !f.x`.A.+......[
000010: f50c d937 859f a0fc 6260 8332 c508 e6c4 ...7....b`.2....
000020:
> salt 415448454e412e4d49542e4544554a757269c5a169c487
Salt:
000000: 4154 4845 4e41 2e4d 4954 2e45 4455 4a75 ATHENA.MIT.EDUJu
000010: 7269 c5a1 69c4 87                       ri..i..
000017:
> pass -z -e rijndael -k 16 eszett
pass <eszett> iter=2 keylen=16
password (hex):
000000: 6573 7a65 7474                          eszett
000006:
intermediate key:
000000: 4a5b 6bdd a281 81bd db0a c679 343b 7d31 J[k........y4;}1
000010:
rijndael128 final key:
000000:  b93 477a 82af eaee b752 46e1 eee2 e089 ..Gz.....RF.....
000010:
> pass -x -e serpent -k 16 eszett
serpent128 final key:
000000: 6c13  7f0 f6d8 bc9e d0bf d596 58ce a3e3 l...........X...
000010:
> pass -x -e twofish -k 16 eszett
twofish128 final key:
000000: df7e 3527 5ba5 a99b 6b03 7d51 a18a 42a7 .~5'[...k.}Q..B.
000010:
> pass -z -e rijndael -k 24 eszett
pass <eszett> iter=2 keylen=24
password (hex):
000000: 6573 7a65 7474                          eszett
000006:
intermediate key:
000000: 9980 bada c3b8 7dc4 7eb3 4402 df91 4d33 ......}.~.D...M3
000010: 2026 3fcc b754 9a94                      &?..T..
000018:
rijndael192 final key:
000000: 11c5 110c be31 26e2 3b81 edf0 7396 868b .....1&.;...s...
000010: d035 dbe5 c341 5130                     .5...AQ0
000018:
> pass -x -e serpent -k 24 eszett
serpent192 final key:
000000: 928a 4499 1247 3790 c7c1 8304 658b 6610 ..D..G7.....e.f.
000010: 6789 a813 36e8 dd12                     g...6...
000018:
> pass -x -e twofish -k 24 eszett
twofish192 final key:
000000: 1758 3a04 8834 220a 340d d722 f4f5 ca89 .X:..4".4.."....
000010: 69d9 c4da 8505 e1c0                     i.......
000018:
> pass -z -e rijndael -k 32 eszett
pass <eszett> iter=2 keylen=32
password (hex):
000000: 6573 7a65 7474                          eszett
000006:
intermediate key:
000000: 6c0e bd81 5c11 c8e6 2d63 9317 d29a b94a l...\...-c.....J
000010: 22c3 2fe1 be23 f6e0 8c1d  d93 b47f  a8e "./..#..........
000020:
rijndael256 final key:
000000: e0ba a91b 6357 15b9 293d c3c9 9bd6 3ef6 ....cW..)=....>.
000010: 9efa 63d1 cf41 a567 8e95 4346 3527 d548 ..c..A.g..CF5'.H
000020:
> pass -x -e serpent -k 32 eszett
serpent256 final key:
000000: a04c 9c27 b91b e9c4 880b 209a ad55 414b .L.'...... ..UAK
000010: b464 3079 bf8e 937a 32a0 5480 ed88 c4a9 .d0y...z2.T.....
000020:
> pass -x -e twofish -k 32 eszett
twofish256 final key:
000000: cc3d 27db 216d 5a72 dae1  37a  d8f bf76 .='.!mZr...z...v
000010: c214 68d5 e58b 59e4 fa33 8f53 cf56 d766 ..h...Y..3.S.V.f
000020:

---

From: Ken Raeburn <[email-masked]>
Date: 05 Sep 2001 18:45:18 -0400

> what would be needed in k5 to implement the draft.

Thanks!  The string-to-key algorithm is still under discussion,
though; the number of iterations at least will probably be larger in
the next version.  John Brezak was going to look into some performance
issues and talk to some crypto folks at Microsoft.  Also, the 192-bit
versions are likely to just go away.

> draft & writing code to produce the following, which I'll post as soon

Great.

> 000000: 6573 7a65 7474                          eszett

This is supposed to be one UTF-8 character (two bytes, hex C3 9F), the
German eszett (looks like a lowercase Greek beta).

---

From: Marcus Watts <[email-masked]>
Date: Wed, 05 Sep 2001 19:46:51 -0400

> versions are likely to just go away.

I'd be disappointed if the iterations went up; the small number was
actually one of the things I liked about the current draft.  All
iterations does is burn CPU cycles on the client, and there's not
enough room between today's slowest clients and server farms accessible
to vandals N years from now to make this very effective.  If the goal
is to be able to stop a dictionary attack, this isn't going to work.
There are better ways to secure passwords, and supporting long
passwords, doing password quality checking, & storing longer key sizes
are just a start.  It might be nice to store the iterations as part of
the salt, if there are people who still like this.  At least, that way,
it can be increased over time without breaking code.

I hadn't bothered to measure performance of this, but I guess maybe I
should.  I can say right off though that sha256 is about 5 times slower
than md5, & sha384/512 8 times slower.

I'll shed no tears if the 192 bit variants go away.  So far as that
goes, I'm not particularly attached to the 256 bit variants.  I expect
the 128 bit versions to last until the end of the world (in 2038, when
Unix time goes negative,) and and by then we'll probably have even
better symmetric algorithms anyways.

> German eszett (looks like a lowercase Greek beta).

One of the comments I wanted to make is there ought to have been
test vectors for a 64 character password, and a 65 character one,
and perhaps 128 characters and 129 characters, because those exercise
some interesting boundary conditions in hmac.

Oops about eszett.  Er, how about:
> pass -z -e rijndael -k 16 -h c39f
pass <\303\237> iter=2 keylen=16
password (hex):
000000: c39f                                    ..
000002:
intermediate key:
000000:  84d 5998 94c4 1df7 adb0 b1ee 7e17 444b .MY.........~.DK
000010:
rijndael128 final key:
000000: 8a7a 3cc0 42ec 71ae 122d 2271 b4a8 3afa .z<.B.q..-"q..:.
000010:
> pass -x -e serpent -k 16 -h c39f
serpent128 final key:
000000: 4348 9b07 ab57 ef91 c9fa 5c21 22dc 396d CH...W....\!".9m
000010:
> pass -x -e twofish -k 16 -h c39f
twofish128 final key:
000000: dc09 a20c  6c1  b9d 5207 5507 806e a1a9 ........R.U..n..
000010:
> pass -z -e rijndael -k 32 -h c39f
pass <\303\237> iter=2 keylen=32
password (hex):
000000: c39f                                    ..
000002:
intermediate key:
000000: f578 35eb 64d4 c784 6366 c64b 642f 51ff .x5.d...cf.Kd/Q.
000010: c1fe 3a87 15fd e694 6483 3aea faca 9056 ..:.....d.:....V
000020:
rijndael256 final key:
000000: 74b5 e6e7 6d61 2fe8 43c3 e13f 448e 42ed t...ma/.C..?D.B.
000010: e0f0 f052 3e9e ca24 8278 219b cbda bc7a ...R>..$.x!....z
000020:
> pass -x -e serpent -k 32 -h c39f
serpent256 final key:
000000:  fc8 1dcf 7e2a b87f 86c3 5dc3 4717 b669 ....~*....].G..i
000010:  ab4 9816 ba37 3040 6c1a bd2b 2cfa 27bf .....70@l..+,.'.
000020:
> pass -x -e twofish -k 32 -h c39f
twofish256 final key:
000000: e3a1 2b50 a0b6 51f3 eeaa e797 9b4c 2b90 ..+P..Q......L+.
000010: 11a9 b4ac 3c2e 8eca  e4d 5c00 f6e5 3495 ....<....M\...4.
000020:

?
				-Marcus Watts

---

From: Ken Raeburn <[email-masked]>
Date: 10 Sep 2001 13:13:31 -0400

> to vandals N years from now to make this very effective.  If the goal

I'm more than a little skeptical of the simple factor-of-N slowdown as
a deterrent to determined attackers; the change from simple hash to
HMAC seems like the big step to me.  If the difference in computing
power you describe isn't a very small multiplier compared to the
dictionary size, I think we've got a problem, and that's not very
dependent on the cost of a single attempt.  This is why we need the
extra protection for the initial ticket exchange that John Brezak and
I and others have been talking about, whether it be SRP, EKE, or
whatever.

On the other hand, as long as it doesn't slow down the legitimate
clients too much (including cell phones and PDAs, at 16MHz or less),
raising the bar for the attacker may still be a good thing; even if
it's not high enough for a determined attacker, we may discourage the
script kiddies.

I can certainly see arguments on both sides; what I don't know is if
there's something more the crypto gurus know that I don't...  John's
been talking to some crypto folks at Microsoft; that's where the
suggestion to use PKCS #5 came from in the first place.

> some interesting boundary conditions in hmac.

An excellent idea.  I'll add some test cases with that in mind.

Ken

P.S.  Anyone know what the available cpu power is on a typical (not
high-end) cell phone these days?