[Apologies for breaking threading. The mbox on the archive site hasn't been updated yet and mailman does not show message IDs.]
On January 18, 2007, Marcus Watts wrote: > Dale Ghent <[EMAIL PROTECTED]> writes: > ... > > Dunno if this is exactly what you're looking for, but Solaris has > > SCF, the Solaris Crypto Framework which provides kernel-based crypto > > (either in hardware or as a software kernel driver) to both userland > > and kernel callers. > > > > http://www.sun.com/bigadmin/xperts/sessions/12_crypt/ > > > > The programming interfaces are still undocumented, though... at least > > for userland, but the cryptoadm(1M) man page is a decent place to start. The user-land bits are certainly documented: the PKCS#11 spec is the documentation (plus, the docs.sun.com Solaris Security Developer Guide has plenty of documentation as well). > ... > > Um, yes. Nope, that's not "kerberos 5". It's probably a perfectly > good underlying set of cryptographic primitives. The AES code there > presumably doesn't do ciphertext stealing, but that's a relatively > simple elaboration on cbc, which it does provide. > > Sounds like documentation could be an issue. I hate to ask, but I > suppose I should -- are these actually "supported" interfaces despite > the lack of documentation? The user-land bits of the Solaris Cryptographic Framework are just PKCS#11 (libpkcs11.so.1), and that is a Committed (stable) interface (i.e., you can use it to your heart's content). Committed interfaces are also documented interfaces (see above and below). The kernel-land bits of it are not, IIRC, a part of the DDI yet, but that doesn't mean that OpenAFS couldn't get a contract to use them, if desired. (A contract meaning that OpenAFS would get suitable warning prior to any backwards incompatible releases; this should have come up in the context of VOP interfaces.) No, support for CTS mode is not included in the SCF, so the caller has to fashion CTS out of CBC or ECB mode. And yes, the Solaris krb5 code currently implements CTS mode fairly inefficiently (with as many calls into the SCF as there are blocks to encrypt/decrypt; it should really never do more than two calls into the SCF, and, really, with the benefit of hindsight I'm starting to wonder at the wisdom of CTS). OpenSolaris' krb5 crypto bits use the SCF, and the same source (MIT + CDDL licensed) (with #ifdef KERNELs all over) is used to build the user- land and kernel-land bits of the GSS-API Kerberos V mechanism. The kernel-land mechanism only includes the per-msg token functions and everything needed to make that work (i.e., the krb5 crypto framework), but none of the raw krb5 PDUs. http://docs.sun.com/app/docs/doc/816-4863 http://opensolaris.org/os/community/security/projects/ef/ http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/gssapi/mechs/krb5/ If you need more info feel free to ask on [EMAIL PROTECTED] Cheers, Nico -- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
