NSS equivalent of OpenSSL's EVP_CipherUpdate
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
NSS equivalent of OpenSSL's EVP_CipherUpdate
by Graham Leggett
::
Rate this Message:
Hi all,
I am trying to port some symmetrical encryption / decryption code using OpenSSL's EVP_CipherUpdate function to NSS, and I am running into trouble trying to find the API documentation for NSS. So far, the closest to documentation that I have found is a list of the API functions, but none of these functions are in themselves documented. Most specifically, I need to know what #include files are required for each function, as my attempts at guessing have been unsuccessful. http://developer.mozilla.org/en/NSS_functions So far it looks like PK11_CipherOp is the corresponding function that I need to use. Is this correct? How do I set up the symmetrical key, cipher and digest for PK11_CipherOp to replace the OpenSSL EVP_BytesToKey function? I have managed to find references to some test cases that contain code, but the test cases aren't documented either, and the variable names yield few clues as to what each field is used for. Is there a set of documentation I am missing? Regards, Graham -- _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@... https://lists.mozilla.org/listinfo/dev-tech-crypto |
|
|
Re: NSS equivalent of OpenSSL's EVP_CipherUpdate
by Nelson B Bolyard
::
Rate this Message:
|
|
|
|
|
|
Re: NSS equivalent of OpenSSL's EVP_CipherUpdate
by Graham Leggett
::
Rate this Message:
Subrata Mazumdar wrote:
> Apache XML Security C++ library > (http://xml.apache.org/security/c/index.html) provides single C++ based > cryptographic interface with multiple Crypto API (OpenSSL, NSS, MS-CAPI) > based implementation. The Apache XML Security C++ library implements > signing, encryption as well as decryption for XML documents. If you > download the source, you might able to cross check the OpenSSLbased > implementation with the NSS-based implementation for similar functionality. I am currently trying to achieve a similar thing for APR, this time implemented in C rather than C++. The idea I have is to allow the httpd server (and other apps) to depend less on openssl specifically, and support the native APIs of the platform involved, NSS included. Thank you for pointing this out, it will save a significant amount of work for me. Regards, Graham -- _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@... https://lists.mozilla.org/listinfo/dev-tech-crypto |
|
|
Re: NSS equivalent of OpenSSL's EVP_CipherUpdate
by relyea
::
Rate this Message:
Graham Leggett wrote:
Hi all,Yes, PK11_CipherOp is for updating a running cipher. PK11_DigestOp updates a digest (the former returns bytes as you encipher them, the latter just updates and the result is fetched from final. Both take a context which are created by one of the PK11_CreateContext calls. (for ciphers it's PK11_CreateContextBySymKey()). 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.
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@... https://lists.mozilla.org/listinfo/dev-tech-crypto |
|
|
Re: NSS equivalent of OpenSSL's EVP_CipherUpdate
by Graham Leggett
::
Rate this Message:
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. 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 -- _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@... https://lists.mozilla.org/listinfo/dev-tech-crypto |
|
|
Re: NSS equivalent of OpenSSL's EVP_CipherUpdate
by relyea
::
Rate this Message:
Graham Leggett wrote:
> Robert Relyea wrote: > > > "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? Ah, It's a PBE algorithm. That is a perfectly acceptable way of getting a key. The equivalent function in NSS is PK11_PBEKeyGen which takes a slot, algid, password, Bool (which should always be FALSE), and a password arg (for authenticating to the slot - should match your GetPassword Function). You can use PK11_CreatePBEV2AlgorithmID or PK11_CreatePBEAlgorithmID to create your algid. The former allows you to completely specify a PKCS #5 v2 algorithm, the latter will create a PKCS #5 v2 implicitly if you pass a symmetric algorithm instead of a PBE (otherwise it will create a PKCS 5 v2or PKCS 12 PBE, depending on the algid). You probably don't need it for your application, but the resulting algid can be der encoded and passed to a recipient, who would then use it to determine what PBE type to use to recreate a key. bob > > Regards, > Graham > -- > ------------------------------------------------------------------------ > > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@... > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@... https://lists.mozilla.org/listinfo/dev-tech-crypto |
smime.p7s (4K) 
| Free Forum Powered by Nabble | Forum Help |
