I sign the git tags, but we need GPG signatures that people actually know how to verify. For now, I'll use my email address key, and then we'll switch to my air-gapped key in the future once I get it set up correctly.

We should develop a quick self-test that will have to run once (and pass) before it will encrypt or decrypt anything.

We want this code to be as hard to misuse as possible. We should consider giving it a property like:

• Encrypt() and Decrypt() will only accept a key generated with CreateNewRandomKey()

Hello,

TLDR: is it safe to change the two constants

const ENCRYPTION_INFO = 'DefusePHP|KeyForEncryption';
const AUTHENTICATION_INFO = 'DefusePHP|KeyForAuthentication';

I am concerned about a situation where an attacker has compromised the database, and therefore has access to the encrypted data and ivs. In that situation, if they know the secret used for encryption they can decrypt the data. I would rather not use a hard coded secret that is constant across all copies of this library.

I see a giant comment saying not to change any constants, however these seem different then the others in that they don't change the workings of the encryption at all.

If it is unsafe to change these, how do you recommend addressing my issue above? Am I just applying the library wrong?

Thanks

References:

• http://eprint.iacr.org/2009/317
• http://eprint.iacr.org/2009/374

Attack complexity based on the two papers:

• AES-128 = 126.1 bits
• AES-192 = 172 bits
• AES-256 = 99.5 bits

Given this, I feel that AES-192 is the safest of the three choices.

If everyone agrees, we need to get new test vectors written in the runtime tests then change the key size from 16 to 24.

Hi,

I would like to ask a stupid question: I would like to send a crypted message between nodejs and php applications and I would love to use this lib. However, I'm unsure as how I should decrypt the encrypted message in nodejs and vice versa. As I'm a total beginner in this, any pointer would be extremely appreciated.

Get someone else to look at this code and find all the problems with it.

Make a real life example, showing, most importantly, how error handling should be done.

Can str_repeat fail due to out-of-memory, or something else? What about mcrypt_generic? The docs don't say they can fail, but is this really true?

There is no need for the constants to be global. They should be class constants. Figure out what versions of PHP class constants are supported on.

What happens when mcrypt isn't installed and the mcrypt functions are missing? Does it crash? Does the crash leak information?

I've googled and found theories and CryptDB.

The most sensible approach I found is by indexing keywords and connecting them to the encrypted records, so the searching is actually getting data from those index db, without decrypting the records.

I'd like to hear some thought of the practical way of doing this, or not.
Especially, because this repo is about (en|de)cryption and followed by implementers.

This can be a challenging topic for Documentation.

https://twitter.com/mik235/status/432350134496546816

When decrypting, should we check if the ciphertext length is HMAC + 2*block bytes first, or keep doing it as we do it now? What are the security implications?

@defuse

I came across your library in some of those slim threads and thought it might be great to use, as I've currently been investigating encryption libraries to finish my security module.

That said, two things I noticed immediately:

1. It lacks composer support
2. It takes over the exception handler (I understand this is for security)

I'd like to fix these two problems and make use of your library, but based on the previous composer.json pull request that is open, I'd like to verify that you're interested first.

With respect to the exception handler, it would make more sense, if the exception handler was changed temporarily during the processes which could throw exceptions. Your exception handler could be split to a separate class, and http://php.net/manual/en/function.restore-exception-handler.php can be used to restore the previous one once decrypting is done (for example).

We need to start some sort of campaign to get people using this library instead of either rolling their own or using an existing broken one.

Before we do this, though, we need to:

1. Get Crypto.php on Composer - #44. [DONE]
2. Get Crypto.php on PEAR - #45.
3. Release versioned downloadable tarballs (possibly through github) - #46.
4. Cryptographically sign releases - #47.
5. Version tagging - #34.

This is probably going to be used to encrypt files. Currently, the entire file would have to be loaded into memory. We should support file chunking, once the cool folks over in https://github.com/kaepora/miniLock/issues/2 figure out how to do it safely.

Answer these questions:

• Why does this library exist?
• What's special about this library?
• What are the "core values" of this library?

Add a function for deriving a key from a password with PBKDF2.

We have to think really hard about how to make this usable, since we want to make sure they're doing the salt right (by making it hard to do it wrong).

If the HMAC is invalid, PHP will dump out a stack trace with the key in it. This is obviously not good, because it means an attacker who can corrupt the ciphertext can learn the key.

#0 /[redacted]/php-encryption/Crypto.php(275): Crypto::Decrypt('??+6?G"?????tk?...', '?9M???????l?.j;...')

I've dowloaded the .zip and installed it (one week ago).
My problem is I don't find the way to use it and I don't find any example on internet.

Could you please add a file to the .zip with an example ?

At the top of the code should be some really good documentation for the user. We shouldn't just tell them how to use the code, we should tell them what this code is good for, and what it isn't (e.g. network communication protocol).

We need to provide encoding and decoding functions (hex, base64, etc) that are safe against side channel attacks.

The error check on line 375 returns the exception as a function call, instead of throwing it. This would fatal error (non-existent function) if the branch was ever reached.

Instead, change

return CannotPerformOperationException();

To

throw new CannotPerformOperationException();

Making a note for my own fork.

From the user's perspective, both of these are the same: Something is seriously wrong and a human needs to take a careful look at what's happening. Why are they different exceptions? In what case would the user benefit from being able to distinguish the two?

What is the best way to store the key used to encrypt data?

I used base64_encode/decode my cypher key and then save it to a file, but this is not advised according to the crypto class comments.

Thus, I am asking what are or is the best way to store a cypher key to avoid leaks and attacks.

thanks.

Include the crypto class and exception classes inside a namespace so we're less likely to conflict with other code.

Hello!
I am wondering about what is the best type i should choose for the field i use to store the encrypted data, i chose varchar but encrypted data seems to be corrupted after it is stored in mysql. i Planing to use a blob type, is this a good choice and what size should choose also. I planning to encrypt integers only which should not exceed 8 or 9 digits,
my Mysql database uses innoDB engine with utf8_general_ci

thanks

Hi there,
Firstly, I would like to thank you for the hard work. I'm using this library to do encryption and decryption for my education purposes but unfortunately I'm having trouble with the decrypt part which it keeps showing me this error message: 'DANGER! DANGER! The ciphertext has been tampered with!' . I did not edit anything from the how to use this code example code except the $message which I wish to encode and the ciphertext and key has been saved to the database for future use. It seems like the how to use this code example couldn't use separately; I have verified the output of the ciphertext and key after retrieving from database and finds that the output is indeed match. Below are some of my sample code of using your library:
//...encrypting part...
$content = trim($_POST['content']);

try {
$key = Crypto::CreateNewRandomKey();
// WARNING: Do NOT encode $key with bin2hex() or base64_encode(),
// they may leak the key to the attacker through side channels.
} catch (CryptoTestFailedException $ex) {
die('Cannot safely create a key');
} catch (CannotPerformOperationException $ex) {
die('Cannot safely create a key');
}

$message = $content; //text which grab from end user input
try {
$ciphertext = Crypto::Encrypt($message, $key);
//print $message;
//print $ciphertext;
} catch (CryptoTestFailedException $ex) {
die('Cannot safely perform encryption');
} catch (CannotPerformOperationException $ex) {
die('Cannot safely perform decryption');
}

//...decrypting part...
$query = "SELECT content,seckey FROM contents WHERE site = :site";
$query_params = array(':site' => $site);

try{
global $db;
$stmt = $db->prepare($query);
$result = $stmt->execute($query_params);
}catch(PDOException $ex){
die("Failed to run query: " . $ex->getMessage());
}

$row = $stmt->fetch();

if($row){
$ciphertext = $row['content']; //select the ciphertext which saved earlier
$key = $row['seckey']; //select the secretkey which saved earlier
//print $ciphertext;
//print $key;

try {
$decrypted = Crypto::Decrypt($ciphertext, $key);
} catch (InvalidCiphertextException $ex) { // VERY IMPORTANT
// Either:
// 1. The ciphertext was modified by the attacker,
// 2. The key is wrong, or
// 3. $ciphertext is not a valid ciphertext or was corrupted.
// Assume the worst.
die('DANGER! DANGER! The ciphertext has been tampered with!');
} catch (CryptoTestFailedException $ex) {
die('Cannot safely perform encryption');
} catch (CannotPerformOperationException $ex) {
die('Cannot safely perform decryption');
}

$text = preg_replace("/[\r\n]+/","

",$decrypted);
}

https://www.isecpartners.com/blog/2011/february/double-hmac-verification.aspx

Think about this carefully before changing the code. This post says we can re-use the key again in the second HMAC, instead of generating a random one. That would be a lot better, as it's not prone to RNG failures.

Add the rest of the HKDF test vectors. We have 1, 2, 3, and 7. We're missing 4, 5, and 6.

The test vectors are in The RFC

Since we're using OpenSSL, can we switch from CBC + HMAC-SHA256 and instead use a built-in AEAD mode? (GCM is the one that I'm envisioning)

Currently the only way to get AEAD encryption modes in PHP is with libsodium.

This is a nice-to-have in case anyone wants to encrypt with version 1.x of this library in 2015 then decrypt it with version 3.x in 2025.

Do they affect us? There are $string[$index] stuff going on in this code, so maybe it could?

The 2-clause BSD license would be better for this code than public domain, because of the issues of "public domain" not being defined in some countries, etc. Unfortunately I released the original code as "public domain." Is it too late to change it?

See pull request #22.

Switching to OpenSSL broke 5.2 and 5.3. We don't want to support those versions any more, but we should at least be sure we're not dangerous on those versions. Add travis tests for those versions that make sure they fail somehow safe (e.g. by throwing an exception).

#36

I noticed it only corrupts image data, not mp3 or text files. Any idea how to solve this? I'd like to try and help

The documentation shouldn't be a massive comment at the top of the file (that nobody will read anyway).

ignore this. testing.

I am trying to Encrypt/Decrypt large amounts of data. I am encrypting about 3.56MB of text, and when I try to decrypt it, it fails on line 232 - throw new InvalidCiphertextException();

My end goal is to be able to encrypt very large files perhaps up to 2gb, but at this point I'm stuck at decrypting 3.56MB.

Decide whether or not we should have the ?> closing tag.

Should we encode the cipher and hash function into the ciphertext, so that it can be decrypted even after the algorithms have changed?

Hello this is my first time posting on Github so excuse me if i format the issue wrong!

Using the "example.php" provided with the current version i added the following code/statements;

<Generate keys & encrypt the text>

$encode = base64_encode($ciphertext);

$stmt = "INSERT INTO test (test) VALUES (:test)";

$y = $pdo->prepare($stmt);
$y->execute(array(
':test'=> $encode
));

$sth = $pdo->prepare("SELECT test from test where id = '1' ");
$sth->execute();
$result = $sth->fetch();
$data = $result['test'];

$decode = base64_decode($data);

This returns;

"DANGER! DANGER! The ciphertext has been tampered with!"

This could be just me being new to using encryption with PHP or it could be an issue with the code itself but i was told i should bring it up here;

"http://stackoverflow.com/questions/30226517/encrypting-data-using-the-defuse-php-encryption?noredirect=1#comment48595894_30226517"

Thanks again.

#19 reports a flaw in the HKDF implementation. I'm pretty sure I copied that code from another project, or re-used that code in another project. Which project? Find all the other ones and fix them.

You can't encrypt super-large files with this library because you have to load them into RAM. We could either (1) Have a "stream" sort of API, where you feed it data and it feeds back ciphertext, but there are problems with this, e.g. when decrypting you'll get all of the plaintext and then only the last call will check the MAC, but the damage has already been done, or (2) Support file encryption/decryption only, so that we can encapsulate all of that.