AES-128 OFB differs using mcrypt (PHP) and pycryptodome (Python) - php

DISCLAIMER: All the examples given here are not safe and are not remotely close to being good practice. The code used here is intended to be used in a CTF challenge and contains multiple vulnerabilities.
Here is my actual concern: The result from encrypting with the same key, iv, mode and padding using mcrypt_encrypt results in a different cipher than doing the same using Crypto.cipher AES in python 2.7, but only when using OFB mode. Here is my example:
$key = 'SUPER_SECRET_KEY';
$iv = '0000000000000000';
$data = "this is a test";
$padding = 16 - (strlen($data) % 16);
$data .= str_repeat(chr($padding), $padding);
echo base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $data, MCRYPT_MODE_OFB, $iv));
The result is: k8Ss4ytOUNvcG96tr+rHdA==
Now the python example:
from Crypto.Cipher import AES
from base64 import b64encode
key = 'SUPER_SECRET_KEY'
iv = '0'*16
data = "this is a test"
padding = 16 - (len(data) % 16)
data += chr(padding)*padding
print(b64encode(AES.new(key, AES.MODE_OFB, iv).encrypt(data)))
The result is: kzFpEHCJB+2k2498DhyAMw==
It only happens in OFB mode. If I were to change the mode to CBC (and change nothing else), both results would be identical. Any idea what is going on?
EDIT: Using openssl_encrypt in PHP gives me the same results as the python code. This leads me to believe there is a bug in mcrypt_encrypt.
$key = "SUPER_SECRET_KEY";
$iv = "0000000000000000";
$data = "this is a test";
$padding = 16 - (strlen($data) % 16);
$data .= str_repeat(chr($padding), $padding);
$cipher = openssl_encrypt($data, "aes-128-ofb", $key, $options=OPENSSL_RAW_DATA, $iv);
echo base64_encode($cipher) ."\n";

I'm not sure why you are trying to do anything with mcrypt or OFB mode - both are blasts from a past most cryptographers are trying to forget. It is also unclear why you use padding for a streaming mode, unless you're working around the PyCrypto bug (see below).
To directly answer your question, from the documentation of PHP:
MCRYPT_MODE_OFB (output feedback, in 8-bit mode) is a stream cipher mode comparable to CFB, but can be used in applications where error propagation cannot be tolerated. It is recommended to use NOFB mode rather than OFB mode.
you probably should be using:
MCRYPT_MODE_NOFB (output feedback, in n-bit mode) is comparable to OFB mode, but operates on the full block size of the algorithm.
where the "N" before "OFB" is the block size of the mode of operation.
No such documentation exists for either PyCrypto, PyCryptoDome or OpenSSL. However, it seems that they process 128 bits at a time (according to a PyCrypto bug report) as it incorrectly requires to receive full plaintext blocks for some reason or other.
OFB will produce different ciphertext if used in 8 bit or 128 bit mode - except for the very first byte, which should be identical. 8 bit mode is as much as a blast from the past as mcrypt or OFB itself; it uses a full block encrypt per byte (!) to allow for reduced error propagation.
If you need a streaming mode, use CTR mode or, preferably, an authenticated cipher such as GCM (which uses CTR mode underneath). This will both be faster (than 8 bit OFB) and more secure.

Related

equivalent of mcrypt_encrypt in PhpSecLib

I have an old piece of code that's written using mcrypt extension and I have to change it to phpseclib. But my code doesn't generate the same output as mcrypt function:
Old code:
$encryptedText =mcrypt_encrypt(
MCRYPT_RIJNDAEL_256,
$myKey,
$data ,
MCRYPT_MODE_CBC,
$myIV
);
My new code:
$aes = new \phpseclib\Crypt\AES(\phpseclib\Crypt\AES::MODE_CBC);
$aes->setKey($myKey);
$aes->setIV($myIV);
$aes->disablePadding();
$seclib = $aes->encrypt( $data );
but $encryptedText and $seclib are not the same.
You're equating Rijndael with AES, a common misconception.
AES is only a subset of it - Rijndael-128, with the difference between AES variations being only the key size:
AES-128 is Rijndael-128 with a 128-bit key.
AES-256 is again Rijndael-128, but with a 256-bit key.
The suffix number in Rijndael variations on the other hand, refers to both key size and block size, so of course you cannot get Rijndael-256 by doing AES, as you need a 256-bit block size.
There's a page on the phpseclib docs, which generates sample code after you input the basic variables (cipher, mode, key size, bit size). It outputs the following for Rijndael, CBC, 256, 256:
<?php
include('Crypt/Rijndael.php');
include('Crypt/Random.php');
$cipher = new Crypt_Rijndael(); // could use CRYPT_RIJNDAEL_MODE_CBC
$cipher->setBlockLength(256);
// keys are null-padded to the closest valid size
// longer than the longest key and it's truncated
//$cipher->setKeyLength(256);
$cipher->setKey('abcdefghijklmnopqrstuvwxyz123456');
// the IV defaults to all-NULLs if not explicitly defined
$cipher->setIV(crypt_random_string($cipher->getBlockLength() >> 3));
$size = 10 * 1024;
$plaintext = str_repeat('a', $size);
echo $cipher->decrypt($cipher->encrypt($plaintext));
I am not sure if the library actually supports this cipher without mcrypt availablity, but it should.
I assume you are doing this because mcrypt is being dropped from PHP, and I strongly suggest that you change your strategy.
Even if the above works, it would be quite slow when using a userland PHP implementation of the algorithm (something which is noted in the phpseclib docs), but more importantly - you'll have no other alternatives if this library stops working, is no longer maintained, etc. Non-AES variations of Rijndael are not ubiquitous, and there are more modern algorithms available today anyway (hint: libsodium being added to PHP 7.2).
If I were you, I'd change the algorithm entirely. Of course, that would mean re-encrypting all of the data, but you'll have to do that eventually and now is really the best time to do it.

AES 256 and Base64 Encrypted string works on iOS 8 but truncated on iOS 7

One of my app needs to download a database with the content encrypted in AES 256. So I've used on server side phpAES to encode the strings in AES CBC with an IV.
On the iOS side I'm using FBEncryptor to decrypt the string.
This is the code on the server side:
$aes = new AES($key, "CBC", $IV);
$crypt = $aes->encrypt($string);
$b64_crypt = base64_encode($crypt);
On the iOS side I'm doing this:
NSString* decrypt = [FBEncryptorAES decryptBase64String:b64_crypt keyString:key iv:iv];
Actually everythings works fine on iOS 8. The problem is on iOS 7 where the decoded string is truncated at random length.
Thoughts?
Don't use phpAES. You're shooting yourself in the foot with an enormous cannon.
From their page:
The free version only supports ECB mode, and is useful for encrypting/decrypting credit card numbers.
This is incredibly wrong and misleading. ECB mode is not suitable for any purpose except as a building block for other modes of operation. You want an AEAD mode; or, failing that, CBC or CTR with HMAC-SHA2 and a CSPRNG-derived IV/nonce. Using unauthenticated encryption is a very bad idea.
For interoperability with iOS, you should use libsodium.
Objective-C: SodiumObjc or NAChloride
PHP: libsodium-php (also available in PECL)
If you cannot use libsodium, your best bet is OpenSSL and explicitly not mcrypt, and a compatible interface on the iOS side.
All currently supported versions (5.4+) of PHP expose openssl_encrypt() and openssl_decrypt() which allow fast and secure AES-CBC and AES-CTR encryption. However, you should consider using a library that implements these functions for you instead of writing them yourself.
The truncation could be the result of incompatible padding.
phpAES uses non-standard null padding similar to mcrypt, this is unfortunate since the standard for padding is PKCS#7. It is unfortunate that one has to read the code to find that out. It is important to supply a 256-bit (32-byte) key since that sets the key size for the algorithm.
FBEncryptor only supports PKCS#7 padding.
So, these two methods are incompatible.
One solution is to add PKCS#7 padding to the string in php prior to calling phpAES which will not then add the null padding. Then FBEncryptor will be compatible with the encrypted data.
PKCS#7 padding always adds padding. The padding is a series by bytes with the value of the number of padding bytes added. The length of the padding is the block_size - (length(data) % block_size.
For AES where the block is is 16-bytes (and hoping the php is valid, it had been a while):
$pad_count = 16 - (strlen($data) % 16);
$data .= str_repeat(chr($pad_count), $pad_count);
Please add to the question working example keys, iv clear data and encrypted data as hex dumps.

Triple DES initialization vector

I have a working code to generate encrypt data using PHP:
$cipher_alg = MCRYPT_TRIPLEDES;
$iv = mcrypt_create_iv(mcrypt_get_iv_size($cipher_alg,MCRYPT_MODE_ECB), MCRYPT_RAND);
$encrypted_string = mcrypt_encrypt($cipher_alg, $pKey, $string, MCRYPT_MODE_ECB, $iv);
Question is, I run this code multiple time, if the same inputs and always give me the same output for $encrypted_string and a different output for $iv.
So why my encrypt data is always the same if the IV changes?
ECB mode does not use an IV, so it doesn't matter what you pass in or that it's different every time. The documentation for mcrypt_encrypt itself indirectly says so:
iv
Used for the initialization in CBC, CFB, OFB modes, and in some algorithms in STREAM mode. If you do not supply an IV, while it is
needed for an algorithm, the function issues a warning and uses an IV
with all its bytes set to "\0".
You would need to use a chainable mode (CBC etc) to see different results on each iteration -- and in general, ECB mode is a very bad choice. Don't use it.

AES encryption inconsistency in PHP using the Open SSL library and coding CBC mode from scratch

I suppose I should deal with my first statement first. Is there an inconsistency in the way PHP does AES-128-CBC encryption when you use the Open SSL library?
I am asking this because if you look through RFC3602 for AES then you'll find some test vectors in section 4. The first one I tried was:
Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
Key : 0x06a9214036b8a15b512e03d534120006
IV : 0x3dafba429d9eb430b422da802c9fac41
Paintext : "Single block msg"
Cphertext: 0xe353779c1079aeb82708942dbe77181a
Using the open SSL library with the following code:
echo bin2hex(openssl_encrypt($str, 'aes-128-cbc', $key, OPENSSL_RAW_DATA, $iv));
You actually get back:
e353779c1079aeb82708942dbe77181ab97c825e1c785146542d396941bce55d
Now this is all well and good and decrypts back just fine, and the first 32 bytes are the expected cipher text "e353779c1079aeb82708942dbe77181a". However, there appears to be another 32 bytes at the end of the cipher text returned from the Open SSL library. Why is this? This question becomes relevant next.
As part of something I am doing for fun I am trying to implement AES CBC mode encryption sort of from scratch. The code I currently have for doing this is (based on the RFC previously referenced and on CBC diagrams at the "Block cipher mode of operation" Wikipedia page):
public function cbcEncrypt($str, $iv, $key) {
$bl = 16;
$bs = str_split($str,$bl);
$pv = null;
$r = '';
foreach($bs as $b) {
if($pv === null) $pv = $iv;
if(strlen($b)<$bl) $b = $this->pkcs7Pad($b, $bl);
$pv = openssl_encrypt($b^$pv, 'aes-128-ecb', $key, OPENSSL_RAW_DATA);
$r .= $pv;
}
return $r;
}
At the moment I'm pretty sure this code wont work on strings longer than the current test 16 byte string anyway, however, I ran this code side by side with the Open SSL implementation to compare. The return value from by CBC implementation is:
e353779c1079aeb82708942dbe77181a8b1ccc6f8cd525ffe22d6327d891a063
When called via:
$crypto = new CryptoTools();
$enc = $crypto->cbcEncrypt('Single block msg',hex2bin("3dafba429d9eb430b422da802c9fac41"),hex2bin("06a9214036b8a15b512e03d534120006"));
Again, the first 32 bytes are correct, but the second 32 bytes are again added but completely different from the Open SSL implementation of CBC. Any clues as to why?
Also, the Open SSL implementation of ECB mode returns a 32 byte string, which means CBC encrypting strings currently greater than 16 bytes in length the new value of $pv will be 32 bytes in length and then it will be XOR'd against the second plain text block when in reality shouldn't $pv always be 16 bytes in length? Is it usually just accepted that you truncate $pv from 32 to 16 bytes?
Just in case it helps, the pkcs7Pad method in the code above looks like:
public function pkcs7Pad($str, $b = 8) {
if(trim($str) == '') return false;
if((int)$b < 1) return false;
$p = $b - (strlen($str) % $b);
return $str . str_repeat(chr($p),$p);
}
Any help would be greatly appreciated. Needless to say there's not much documentation on this as people aren't usually stupid enough to try and reinvent the wheel, certainly in PHP...
This has to do with padding. The test vectors don't use any padding at all, while the openssl_encrypt function and your function apply PKCS#7 padding.
PKCS#7 padding is specified so that padding is added in all cases. When the plaintext length is a multiple of the block size, a full block of padding is added, which is why the ciphertext is 32 bytes long when the plaintext is 16 bytes.
Can't immediately see anything wrong with your function (though I'm not familiar with PHP), but you could try padding $str before splitting it instead of checking whether each block requires padding.
Ah ha! Got it! Thanks to ntoskrnl's answer and this Stackoverflow question I managed to come up with a solution! If you do:
echo bin2hex(base64_decode(openssl_encrypt($str, 'aes-128-cbc', $key, OPENSSL_ZERO_PADDING, $iv)));
You will match the test case provided by the RFC! You just need to remember that because you're now not doing OPENSSL_RAW_DATA you will get back a base64 encoded string and so will need to base64 decode it before converting it to hex to match the test case!
TLDR: it was a padding issue, just not an obvious one!

Cryptography libraries conflict (MCrypt, libgcrypt)

I'm trying to perform encryption and decryption (Rijndael 256, ecb mode) in two different components:
1. PHP - Server Side (using mcrypt)
2. C + + - Client Side (using gcrypt)
I ran into a problem when the client side could not decrypt correctly the encrypted data (made by the server side)
so... i checked the:
1. initial vector - same same (32 length)
2. the key - again the same key on both sides..
so i wrote some code in C++ that will encrypt the data (with the same parameters like in the php)
and i found out that the encrypted data contains different bytes (maybe encoding issue??)
I'll be more than glad to get some help
PHP - MCrypt
// Encrypt Function
function mc_encrypt($encrypt, $mc_key) {
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$iv = "static_init_vector_static_init_v";
echo "IV-Size: " . $iv_size . "\n";
echo "IV: " . $iv . "\n";
$passcrypt = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $mc_key, $encrypt, MCRYPT_MODE_ECB, $iv);
print_hex($passcrypt);
return $encode;
}
mc_encrypt("Some text which should be encrypted...","keykeykeykeykeykeykeykeykeykeyke");
I'll post the C++ code in a comment
Thanks,
Johnny Depp
OK. I'll make my comment an answer:
An Initialization Vector (IV) isn't used in ECB mode. If it is provided different implementations might work differently.
If you want to be sure the implementations will work correctly then use an IV of 0 (zero). Even though you provide the IV, both implementations SHOULD ignore it but one can never be sure about that. Not providing an IV in ECB mode should work aswell but again, it all depends on the implementations.
According to the PHP documentation MCrypt will ignore it. GCrypt I'm not sure about.
mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB) should actually return 0 since you specify ECB mode.
Edit:
Do not call mcrypt_get_iv_size or mcrypt_create_iv.
Instead call mcrypt_encrypt without an IV. According to the PHP documentation all bytes in the IV will be set to '\0'.
Same goes for the C++ code. No need to set any IV at all. The libgcrypt code is complex but from glancing at the source of version 1.4.5 then in ECB mode it seems the IV isn't used at all.
If the resulting ciphertext still differs then the problem is something else.
A couple of possibilities comes to mind:
Encoding - Is the same encoding used in both the server and the client?
Endianness - What type of systems are the server and the client? Big- vs Little-endian?

Categories