Encryption and Decryption in and out of codeigniter

Question

I am creating an application based on codeigniter and will work as a API Centric application, i want to implement security , so that the user accessing the API from their own portal should get a public and private key from my portal and then every request they send to my server to get data should be encrypted by the public key and the server should decrypt the data using the private key getting the private key stored in the database

Now the problem is that how can i implement that, so that the user shouldn't go to hard proceedures to encrypt the data using the public key, and i should also be able to decrypt the information using private key within the codeigniter. and also if the encryption is made by javascript still it should be decrypted via codeigniter. I need some secure method to do that, so that i can avoid man in middle attacks and other threats

Thanks

Answer 1

The easy answer is, use TLS.

If you've implemented your server interface as a web API, then this is as simple as configuring your web server front-end to accept connections over HTTPS. Your web server (and the browser / HTTPS client library on the client side) will then take care of most of the complicated handshaking, authentication and encryption details for you.

TLS is far from a perfect security protocol, but if used properly, it generally does the job, and it does it with much less hassle or opportunities for mistakes than designing your own protocol would.

---

If you really want to "roll your own" secure communications scheme, you're first going to have to familiarize yourself with the theory of cryptography and the various available algorithms. In particular, to implement an effective hybrid cryptosystem, you're going to need:

1. an authenticated public-key based key agreement protocol (preferably something based on the Diffie–Hellman key exchange, and thus providing forward secrecy) to provide the client and server with a temporary shared key;

2. an authenticated symmetric encryption algorithm, to provide a secure channel between the client and the server using the shared key; and

3. if the data is transmitted as discrete messages within the secure channel, a communications protocol capable of detecting message replay attacks (e.g. through the use of sequential message numbers).

While all of these can be implemented using only a few discrete crypto primitives — a block cipher (e.g. AES), a public-key encryption/signature algorithm (e.g. RSA), and possibly a hash function (e.g. SHA-256) and some way to do modular exponentiation for Diffie–Hellman — it's generally easier to use protocols and schemes that you crypto library already implements a high-level interface for.

Unfortunately, the most widely implemented schemes also tend to be the older ones, which may be slower and have weaker security guarantees than more modern schemes. That said, if I had the choice (and keep in mind that I'm by no means a true crypto expert), here's what I'd pick:

• If the client needs to authenticate itself using a password, I'd pick SRP for the key agreement protocol. If both sides have public signature keys known to the other, the problem is somewhat simpler, and could be handled simply by using raw Diffie–Hellman and then having both parties sign the D–H shared secret, or by using something like STS. (Note that, even with SRP, you may still want the server to authenticate itself to the client using something stronger than just knowledge of the client's password verifier.)

  For the signature algorithm, any of RSA (with proper padding), DSA or ECDSA should do, as long as the key length is sufficient. (What counts as sufficient depends on the algorithm.) Where hash algorithms are required, I would, for now, use SHA-2; once the SHA-3 standard is finalized, it should also be a valid choice.

• For the symmetric encryption part, I'd go with SIV (RFC 5297) for maximum fool-proofness, or with GCM if speed is critical or "on-line" encryption of large messages is required (and you don't have to implement it yourself). OCB could also be an option, if the patent exemptions are enough for your purposes, and EAX is perfectly good too, if not the absolute fastest. See also How to choose an Authenticated Encryption mode.

  Generic composition of a block cipher (e.g. in CTR mode) and a MAC would also work, as long you make sure to apply the MAC to the message after encryption (end verify it before decryption). Any decent MAC should do, but HMAC is generally a safe and robust choice, if you have a good hash function available and don't need extreme speed. (If you do, a fast Carter–Wegman MAC like poly1305-AES may be worth considering.) Try to avoid the old CBC-MAC if you can; CMAC is much better.

• In any case, I see no good reason to choose anything other than AES for the underlying block cipher at the moment, although it's always good to design your protocol so that new cipher options may be easily introduced (and old insecure ones deprecated) in the future.

• To derive the symmetric encryption key(s) from the D–H / SRP shared secret, you'll generally need a key derivation function; HKDF (RFC 5869) is a good choice for this job, especially if you already use a hash function anyway. (It shouldn't be used — alone, at least — for hashing passwords, though; for that, you need a key-stretching KDF like PBKDF2 or scrypt.)

• Also, as noted, I would design my communications protocol so that all messages carry a sequential message number and explicit sender/receiver designations, and so that messages with duplicate message numbers or invalid designations are discarded as forgeries. Conveniently, these message numbers + designators can also be used as nonces for the symmetric encryption protocol (possibly after hashing, if they would otherwise be too long).

  These message numbers and designators don't necessarily have to be encrypted (although they do need to be authenticated as "associated data"); not encrypting them has the advantage that you can immediately reject any messages with bogus numbers or designators, even before attempting decryption.

• Finally, always keep in mind that there may be exploitable gaps in what I've suggested above, or in the way you choose to apply my suggestions. Make sure to get as many competent security experts as possible to review your protocol and implementation before you use it for anything actually important.

As for specific crypto libraries or APIs in the various languages you mention, I'm not particularly familiar with those, and thus cannot offer detailed advice. Just look at the documentation of standard crypto libraries and see what they offer.

Answer 2

Create Signature for the both end client and server.

$key='any key';

$timestamp='current time stamp'

$url='url to access the file'

$signature = $sha1($key,$timestamp,$url);

use this function at both end and match the signature value and then let it access the data.