Cryptographically-secure super-secret government message transaction machine

-Hello Agent. Are you on a secure line?


-Yes, secured.


-Good, in 30 seconds the launch codes will be in your e-mail's inbox.
You now have the go. Are you ready for the package?


-Yes.


-The key is: "revi3wJAVA-fim++". You should have the codes by now. Be
prepared to take action in T minus 14 minutes.


-Thank you, I accept my mission.

Are you guys ready? We've got the key. We've got the codes. 14 minutes til action time!

The agency is using AES-192 of course, so even if we screw up and the bad guys get these, no way will they crack 'em. Open your inbox, check out these encrypted codes.


bWPpcmX7aXttNz7Dro/LJXhEqEuGFO5FnSITtrUImUoAyRm/6BfT1Ptxzbvdc4MF3K7Pjh4QiiPbKc1ipdVi70EtjreOXKGMZIZuK4K5WBg=

and


t0kBpsCzNBMSxwQ27X6EJqgOp4dENBZOdDzF8UNQjR4YkgB+o7fajMbXMgbtIEprf6QittM3KstX6uB+8Xfh4px/50YQljo/nl2ZIKVnTKU0OWcDqdCH8nwm8zvfT7jDurC5A0vS5Z8=

Whip out your laptop, we're doing some decoding today... Load up these file and visit your host. Of course, edit in our codes and key.

McryptResource.php

```

* @version 1.0.0
* @license http://opensource.org/licenses/MIT The MIT License (MIT)
*/
class McryptResource {

/**
*
* @var resource Encryption descriptor
*/
private $resource;

/**
*
@var string One of the MCRYPT_ ciphers
*/
protected $cipher;

/**
*
@var string One of the MCRYPT_MODE_ modes
*/
protected $mode;

/**
*
* @var int Size of the initialization vector
*/
protected $ivSize;

/**
*
* @var int Size of the encryption key
*/
protected $keySize;

/**
* Get the current encryption descriptor
*
* @since 1.0.0
* @return resource Encryption descriptor
*/
public function getResource() {
return $this->resource;
}

/**
* Create a new mcrypt module
*
* @since 1.0.0
* @param string $cipher Cipher to use
* @param string $mode Mode to use

Well, I don't know much about PHP; but I know a little about security so that is what I am going to review. First I am going to review your encryption algorithm: AES-192.

-
In June 2003, the U.S. Government announced that AES could be used to
protect classified information. So that means you are doing okay/decent with your choice.

-
High speed and low RAM requirements were criteria of the AES selection process. Thus AES performs well on a wide variety of hardware, from 8-bit smart cards to high-performance computers. This isn't necessarily a good thing. The faster the algorithms run, the faster a brute-force method can get to your password.


The agency is using AES-192 of course, so even if we screw up and the
bad guys get these, no way will they crack 'em.

-
Not necessarily. You need to be wary of biclique attacks (currently is the best single-key attack on AES-128, AES-192 and AES-256) and related-key attacks.

I would be most worried about side-channel attacks. Side-channel attacks do not attack the underlying cipher, and thus are not related to security in that context. They rather attack implementations of the cipher on systems which inadvertently leak data. Cache-timing attacks is a popular side-channel attack, with some implementations being able to obtain an entire AES key after only 800 operations triggering encryptions, in a total of 65 milliseconds.


Did I need to salt and hash the key?

-
If I were you, I would forget the key; salt and hash the password
directly. Sure, you will need to modify your software a bit; but
overall it will be more secure. This is because hashes are one-way
functions, it is believed that the text cannot be
transformed back into the original (mathematically, we do not know if secure hash functions actually exist, we just have "candidates": nobody in the world knows how to break it yet). And then you don't have to worry about a key, because you can just compare the hashes directly.

-
We need a slower cryptographic hashing function. SHA-256 is too fast for us too use. With the speed at which hardware can do hashing calculations today, an attacker with off-the-shelf hardware can crack through your salted and hashed password in a few hours, calculating and comparing up to trillions of hashes per second. You've got to slow them down.

So how do we slow them down? The easiest way to slow them down is to just make them do more work. Instead of calculating one hash to check a password, you have to calculate 1000 (or whatever number you feel like). Combining scrypt (CPU and RAM intensive) and bcrypt (more GPU intensive) should do the job for us.

-
Keep in mind that this slower function won't affect an attacker with
rainbow tables. However, the hashes in a rainbow table have to
use the exact same hash function for them to be of any use. This is
where the salting of the password can make a huge difference, since
instead of using one hashing function we use multiple distinct
hashing functions. Properly applied salts will completely thwart rainbow tables.

StackExchange Code Review Q#58457, answer score: 14