Improving Crypto module

[lprimeroo]

The Crypto module is still a work in progress with some changes to be made as well as some more features to be added. I've jotted down a quick list of the things that could be worked on. This may serve as a starting point for folks looking to contribute to the Crypto module.

Things to improve

• [ ] Thorough testing of ciphers (possibly using NIST Test Vectors if we can?)
• [ ] Adding strict validations regarding IV, key, plaintext, ciphertext, etc sizes.
• [ ] More validations!
• [ ] Improving the docs with usage example (this is always helpful!)

Features:

• [ ] Adding a priv and pub key via a .pem file
• [ ] Diffie-Hellman Key Exchange implementation
• [ ] ECC or El Gamal implementation using OpenSSL's EVP API.
• [ ] Implementation of a secure-seed based random buffer (user should at least have an option to do this)
• [ ] Other ciphers are always welcome [DES, CAST, DES3, ...]
• [ ] Currently, we support only a single KDF. Need to support more irrespective of their security.

I can think of only these as the immediate tasks that this module needs. Will keep adding more.

[SagarB-97]

Hello, I would like to implement Diffie-Hellman Key exchange algorithm.

A rough prototype would be :

class DH {
    /* Variables of this class will be same as that of DH structure in OpenSSL that contains Diffie-Hellman 
        parameters (p,g) as well as private and public keys */

    proc generateParams(primeLen : int, generator : int) {
        /* Procedure to generate Diffie-Hellman parameters ('p' and 'g') */
    }

    proc generateKeys() {
        /* Procedure to generate keys from the parameters.
           This procedure can be called several times for a single set of generated parameters as parameter 
           generation is expensive */
    }

    proc computeKey(publicKey : [] uint(8)){
        /* Procedure to calculate shared key given other party's public key */
    }
}

Planning to wrap around lower level DH APIs described here

(Yet to send CLA. Will do it soon)

[lprimeroo]

@SagarB-97 We need to wrap around the EVP API instead as it gives us the flexibility to add other key-exchange algorithms, is hardware-accelerated and is also more actively maintained compared to the lower-level API. Infact, their docs suggest a similar approach.

Users of the OpenSSL library are expected to normally use the EVP method for working with Diffie Hellman as described above and on the EVP Key Agreement page.

So, try to look into that possibility.

[SagarB-97]

Yeah sure. What about the APIs to be provided? Will the ones mentioned above be sufficient?

[lprimeroo]

Hmm. I'll have to check once considering our CryptoBuffer. Let me inform you accordingly.

[ghost]

Hi @SagarB-97,

first of all, thank you for looking at this issue!

As @saru95 said, we should try to provide an "higher" API to our users, for both portability and future extensibility. In your case, for example, I don't like to require a specific DH object for both generate keys and derive the shared secret. We should have a "shared secret generator" class that, given the correct public keys, can derive a CryptoBuffer containing the shared secret. Using different key types, then the user can, with the same object, uses other algorithms like ECDH without changing the implementation of this "shared secret generator".

Note that this approach is quite similar to the EVP API used by OpenSSL for shared secret derivation. You can find the documentation here:

https://wiki.openssl.org/index.php/Manual:EVP_PKEY_derive(3)

Please note that our current public key implementation should be changed a little for handling this new type of "key" because, if I remember correctly, PKEY are currently encapsulated in a RSAKey object.

[nj2237]

Hi, I would like to implement a part of the following requirement

• a thorough testing of ciphers (using NIST Test Vectors)

I'm planning to start with a test for AES. I will look into https://csrc.nist.gov/csrc/media/projects/cryptographic-algorithm-validation-program/documents/aes/aesavs.pdf and write a test, which compares with the KAT results.

Is that okay? Or do you suggest I look into open source implementations such as libgcrypt?

[lprimeroo]

Yes, sure. I would suggest doing only the KAT for AES first. Just read the .rsp files and match the outputs. I'm not sure why you'd need libgcrypt?

[nj2237]

@saru95 Okay, thank you, I will go ahead with the KAT for AES.

I was thinking either we could write the test from scratch or test the crypto module by implementing a binary that follow the CAVS driver used by OpenSSL and libgcrypt. I think the first approach would be better and more straightforward. I will get back to you in case of doubts or issues..

[nj2237]

@saru95 Hey, I had written a small test for check before proceeding. And after installing openssl, I am unable to compile my test_aes.chpl.

I ran the following command, as mentioned in the beginning of Crypto.chpl: chpl -I/usr/local/openssl/ -L/usr/local/openssl/lib/ -lcrypto test_aes.chpl

And I get this error:

/tmp/chpl-nj-22985.deleteme/test_aes.tmp.o: In function `aesEncrypt_chpl':
_main.c:(.text+0x4f169): undefined reference to `EVP_CIPHER_CTX_init'

It is unable to link the libraries. I have tried compiling in different orders after searching for this issue, but to no avail.

How do you get it to compile?

[lprimeroo]

@nj2237 What OS are you on? Tried upgrading openssl? Are you sure you're not forgetting to import evp.h?

[nj2237]

@saru95 I'm on Xubuntu 16.04, and using the latest stable version, openssl-1.1.0. I have included the openssl/include path in the compilation command, where the evp.h file lies. Is there something else?

[nj2237]

@saru95 You were right. I had installed openssl-1.1.0, but in my configuration options, it was set to use the older one, openssl-1.0.2. It compiles now, thanks!

[ben-albrecht]

Removing [good first issue] label, because these tasks require a lot of background info on cryptography algorithms and the Chapel Crypto module specifically.