Content for Solaris 10
For Solaris 10 and beyond the SUNWcry and SUNWcryr packages add support for AES, Blowfish and RC4 with keylengths greater than 128-bit. These are delivered as plugins for the Solaris Cryptographic Framework, and for OpenSSL as a library filter.
They are not part of core Solaris for Solaris 10 03/05 through Solaris 10 11/06 due to import restrictions in some countries. As those restrictions were actually lifted, and Solaris 10 had been reviewed for import with full strength crypto, Solaris 10 08/07 and beyond will include full strength crypto.
In previous releases the SUNWcry and SUNWcryr packages had slightly different meaning. In all releases up to and including Solaris 8 they were primarily used for delivering content that could not easily be distributed to all Sun's non US customers. To this end the terms Domestic and International/Global were often used to describe some parts of Solaris. Those terms are not applicable from Solaris 9 onwards, even if there are still occasional remnants of them in filesystem paths.
For Solaris 10 all of the content for the encryption kit comes from the ON consolidation, that wasn't true of the encryption kit for older releases.
What about Solaris update releases ?
There needs to be a patch issued any time the base objects that are in SUNWcry/SUNWcryr are redelivered. Ideally this would mean that as long as none of the sources for these are changed no patch is needed. Unfortunately in reality it means any time the base binaries are patched then so SUNWcry/SUNWcryr needs to be as well. This is extreme but mixed versions of SUNWcry/SUNWcryr with the base libraries can cause problems just because the code compiled/linked differently even if there is no source change. This can happen due to external header changes or changes in build tools.
Starting with Solaris 10 08/07, since these packages are included, so are the latests patches. Also, now the bug fixes for SUNWcry and SUNWcryr ship with the regular crypto patches, so all modules should be kept up to date more automatically now.
Solaris Nevada
Since the integration of
6498066 PSARC/2006/610 Data Encryption Kit (SUNWcry) Removal
in Nevada build 85, strong crypto is now part of the base operating system. There is no need to install SUNWcry or SUNWcryr anymore, doing so would downrev your system, since those packages are no longer being built. You will no longer see modules like "aes256" on your system, as those longer key lengths are now included in the base modules, like "aes".
Live upgrade, standard upgrade and bfu will all do the right thing with respect to cleaning up your strong crypto installations whether you are upgrading from Solaris 10 or a Nevada release.
How does this impact OpenSolaris ?
With the integration of 6498066 PSARC/2006/610 Data Encryption Kit (SUNWcry) Removal, there is no longer the concept of CRYPTO_UNLIMITED in the builds.
Due to US export restrictions with the binary Solaris product all crypto modules in OpenSolaris are delivered both as source and as signed binaries. This pertains to what is commonly known as "crypto-with-a-hole" in the cryptographic industry.
If you upgrade with bfu you automatically upgrade your crypto using the versions from the closed-bins tar ball. All of the signed cryptographic modules are in the closed-bins tar ball, even though their source is most likely open.
Solaris upgrade and live upgrade can now handle upgrading all of the Solaris cryptographic modules, with the exception of n2cp.esa, which is not shipped as part of the base operating system.
What about unsigned crypto modules in OpenSolaris ?
Since OpenSolaris is open source it is not bound by the same crypto-with-a-hole problem that the binary Solaris product is. We hope to make changes to the source tree that will drop the requirement that binaries be signed for OpenSolaris built versions of the framework, and that the full strength of the crypto algorithms is always the default for the OpenSolaris builds of the crypto providers.
We have a few ideas on how to do this and hope to have the first version of this available before the end of 2005. [This date has long past, and work with Legal
is making it apparent this will not be a simple procedure. We are still
pursuing, but it is not as easy as we had hoped and opening the source does not absolve us of all issues related to crypto-with-a-hole. See discussion below about IPsec and hardware acceleration.]
What is SUNWcryptoint ?
It is an internal package for delivery between ON and the ONPIT testing group. It contains test code (the dprov driver) and test certificates and is nominally actually part of the STC2 test gate but needs to be in ON for code level reasons to allow building of the STC2 gate on a machine that hasn't been bfu'd to latest ON. The build dependency could have changed when the header files for the crypto framework were added to SUNWhea, however the dprov module still needs to be signed (see above).
This package is also required for internal Sun users who are generating their own build archives, or their resultant installed machine will not work correctly for things like SunSSH, OpenSSL, IPsec, IKE, libsasl, encrypt, decrypt, telnet (kerberos), or anything that uses the cryptographic framework. bfu will take care of installing this for the developer, but if that is not available then the developer will need to manually install the package.
External developers will get what they need from the binaries for closed-source modules. If the developer wants to modify their own cryptographic modules, then they can use the "request" option from elfsign(1) to get their own signing certificate.
In particular, this package is not a work around to enable use of older versions of the Encryption Kit; this is not supported and any bugs logged because you have mismatched SUNWcry and Solaris Express bits will be closed. The SUNWcryptoint package is NOT part of the Solaris Data Encryption Kit and is an internal to Sun only package only that is not needed outside of Sun, even for people building their own OpenSolaris distributions.
What if I build my own Distro ?
At this time the easiest thing to do is use the binaries from the closed
bins area for the signed cryptographic modules. If you are interested in making changes to the cryptographic modules in your distribution, then you will need to acquire your own signing certificate. Please see the elfsign (1) man page for details of the "request" subcommand.
