Re: [kitten] New EncTypes?

[Rick van Rein <[e-mail]>]

Hello Benjamin,

>> For instance, AES-CTS-HMAC [...] ought to be possible to
>> implement with PKCS #11 (not that I've already actually tried, but it
>> looks possible).
>
> The argument would be more compelling if there was some prior art for it,
> though -- I don't know of any hardware devices implementing such a scheme
> at present.
I made a working demonstration that generates the test vectors for
AES128-CTS based on PKCS #11 stored AES key,
https://github.com/arpa2/kerberos-pkcs11

The demo comes to the boring conclusion that a diff between what it
generates and what was stripped from the RFC is empty:

shell> make
gcc -ggdb3 -DDEBUG -I
/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/cryptoki_compat/ 
-Wl,-rpath=/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/.libs
/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/.libs/libsofthsm.so  -o
aes128-cts-pkcs11 aes128-cts-pkcs11.c
./aes128-cts-pkcs11 > output.txt
Token PIN: sekreet
diff -u testvectors.txt output.txt
shell>

I ran this against SoftHSMv2 from the OpenDNSSEC project, but there is
no reason why it would not work on hardware tokens that implement the
same API; it only relies on CKK_AES and CKM_AES_CBC, which are not
special at all.

Enjoy,
 -Rick