Robert Relyea wrote:
How do I set up the symmetrical key, cipher and digest for PK11_CipherOp to replace the OpenSSL EVP_BytesToKey function?That would be PK11_ImportSymKey(). NOTE: this function is available mostly for compatiblity, it will not work in all cases (hardware tokens, for instance, do not like to accept random key material. FIPs devices (including softoken) will also choke on this function). In general if you have raw key bytes lying around in your application, you need to rethink how your application is doing crypto.Ideally you should get the Bytes for your key as follows:Dervie it: use PK11_DeriveKey to create a new key from and existing key, DH-key pair, or a password.Unwrap it: unwrap the key using another key or an RSA key.Generate it: PK11_GenerateKey creates a new key. You can use PK11WrapKey to export it to pass to someone else.Anyway PK11_ImportSymKey() will get you working, but longer term you will want to push more of the crypto logic out of your application and into NSS.
To give you a bit of a picture of what I am trying to do. Apache httpd trunk now has session support, with the aim of supporting features that use sessions, such as logging in via a form, or using openid.
Because there is no "one size fits all" solution to the problem of storing sessions, a group of session modules have been created that store sessions in different ways, and the admin gets to choose one. The classic "store the session in a database, give the end user a session key" is supported, but for those where a backend database is infeasible (high load, politics, whatever) another session module exists that can store the session data in a cookie.
The obvious problem in the cookie case is that while the cookie doesn't contain anything the end user doesn't already know, a level of protection needs to exist to encrypt the cookie data should the cookie fall into unauthorised hands (CSS, etc). So a further session module exists that encrypts the cookie contents with a symmetrical key. Any webserver that shares this key can decrypt the cookie and the user session can be shared by that server, no backend collaboration required.
At this point, the mod_session_crypto module could have been hard wired to openssl like mod_ssl is, however this makes it difficult for httpd to be deployed to platforms where openssl is not the crypto library of choice.
The solution here is leverage apr-util's support for pluggable modules, which has recently been used to create dbd database modules and the ability to plug and unplug LDAP, and create a number of pluggable crypto modules that perform a basic set of crypto functionality, which httpd (and others) can use without having to care too much about which platform is involved.
This is where NSS comes in - I am currently trying to put together the initial apr_crypto_nss module, with the very first (but not only) feature being the ability to encrypt an arbitrary string of data using a simple pass phrase, from which a key is generated.
In this case the only entities that are aware of the password / key generated from the password is the webserver, end users only see the encrypted cookie.
Ideally I would like the different modules to be interoperable, in other words an httpd/apr backed by NSS using the same pass phrase as a second httpd/apr backed by openssl should result in the same cookie being decrypted correctly in both cases.
Openssl offers EVP_BytesToKey to convert a pass phrase into a key, but the man page for this function says this:"Newer applications should use more standard algorithms such as PKCS#5 v2.0 for key derivation."
I am assuming NSS supports PKCS#5 v2, what functions should I be looking at to achieve this?
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
