Subject: Re: [Ietf-krb-wg] camellia-cts-cmac expert review request

From: Ken Raeburn <[email-masked]>
Date: Mon, 13 Dec 2010 00:25:00 -0500

It looks good to me so far, Greg.  One minor point: The cipher state is only described in terms of use of a component; it's not explicit that the IV is the only thing in the cipher state, though that'd be my assumption.

I'm curious how long 32768 iterations take for string-to-key on modern hardware.  Have you done any timing tests?

Ken
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Wed, 15 Dec 2010 13:08:07 -0500

On Mon, 2010-12-13 at 00:25 -0500, Ken Raeburn wrote:
> It looks good to me so far, Greg.  One minor point: The cipher state
> is only described in terms of use of a component; it's not explicit
> that the IV is the only thing in the cipher state, though that'd be my
> assumption.

Okay, for the next version I added:

  Cipher state: a 128-bit CBC initialization vector.

I also removed the field name syntax from the pseudo-code, so for
example the encryption artwork just says:

  (C, newstate) = E(Ke, conf | plaintext, oldstate)

> I'm curious how long 32768 iterations take for string-to-key on modern
> hardware.  Have you done any timing tests?

I measured 73 milliseconds averaged over 1000 tests on a Xeon X5450
(with current code, compiled with -O2, single-threaded).

I'm reluctant to bump up the default iteration count too far as it
penalizes legitimate users as much as attackers.  There are scenarios
where legitimate users perform many string-to-key operations (a busy
password-change server, a server verifying passwords against a KDC, a
Kerberos test suite).