AES-CTS, SHA-96bit in Kerberos are FIPS 140-2 Compliant ?

[Marcus Watts]

Somebody naming themselves "Kerberos Athena" claimed:
> Date:    Sat, 06 Mar 2010 12:00:10 +0900
> To:      kerberos at mit.edu
> From:    Kerberos Athena <athena.kerberos at gmail.com>
> Subject: AES-CTS, SHA-96bit in Kerberos are FIPS 140-2 Compliant ?
> 
> Hi
> 
> Does anyone know AES-CTS and SHA-96bit (mandatory cipher suites for
> Kerberos) are FIPS 140-2 compliant or not ?
> 
> AES-CBS and SHA1 (160bit) are listed in the NIST FIPS140-2 approved
> crypto/hash list,
> but AES-CTS and SHA-96bit are NOT listed in the list.
> 
> In case of Windows Vista/7/Sever 2k8, Kerberos is FIPS140-2 compliant and
> AES128/256-CTS-SHA-96 is available in FIPS140-2 compliant mode.
> 
> Regards,

AES-CTS = AES-CBC.  There is no difference.  You
do mean AES-CBC and not AES-CBS, right?

CBC by itself is a multiple block protocol.  It specifies nothing
about how messages that are not integral multiples of the block size
are to be encoded.

There are several popular methods for stuffing messages into
blocks.  The simplest one, and the one used in kerberos for des-cbc-crc,
is to pad the last block with 0's.   It turns out that if you do this
padding, when you decode the ciphertext of the last block,
the portion of the last block that corresponds to the pad bytes
will contain exactly the ciphertext of the block preceeding.
That means you actually don't need to ship that part of the immediately
preceding block.  That is all there is to ciphertext stealing = CTS.

There's a more complete description of CTS (and kerberos and many other
things) in Schneier's _Applied Cryptograph_, a standard reference:
http://www.schneier.com/book-applied.html

What you call SHA-96bit is exactly SHA1 (160bit).  SHA1 always
generates 160 bits of output.  96 bit means that only 96 bits
gets used.  SHA1 is defined to generate "up to 160 bits" of usable
output.  The standard goes on to define that if you don't need that
many bits of output, you should drop the bits on the right.  It's
still SHA1 and (since it's a recommended practice in a NIST standard)
must surely qualify as "approved".

Note that FIPS-2 covers a software+hardware implementation, it does not
cover the protocol.  So, "kerberos the protocol" will never appear as
being FIPS compliant.  A particular software *implementation* of kerberos
might qualify as FIPS 140-2 "security level 1" compliant, if you pay the
big bucks for the testing.  In the case of MicroSoft, they did spring for
the big bucks,
http://technet.microsoft.com/en-us/library/cc750357.aspx
You'd have to ask them what that means in terms of kerberos.
If you are correct that microsoft provides AES128/256-CTS-SHA-96 in "FIPS140-2
compliant mode", then I don't understand why you think that AES-CBC or
SHA-1 (as used in kerberos) might not be approved algorithms.
Are you thinking the documentation exemption for proprietary systems on
page 13 applies?

Sometime back folks elsewhere talked about how OpenSSL had "fips 140-2"
compliance.  What was tested and what was "in compliance" was a peculiar
form of the object code.  Not the source.  If you're curious, read,
http://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf
There's additional interesting info there as well, and pointers to more.

				Marcus Watts