[OpenAFS-devel] Re: configurable cryptosystem support

[Dale Ghent]

To add to this discussion, the Crypto project just opened up on  
opensolaris.org:

http://opensolaris.org/os/project/crypto/

/dale

On Jan 19, 2007, at 12:03 AM, Nicolas Williams wrote:

> [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 <daleg@umbc.edu> 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 security- 
> discuss@opensolaris.org.
>
> Cheers,
>
> Nico
> -- 


--
Dale Ghent
UNIX Systems Specialist
UMBC - Office of Information Technology
ECS 201 - x51705