Call to undefined function mcrypt_create_iv() in
I just upgraded from 1.5.3.1 to 1.5.4.1 . but when I try to run upgrade.php I got this error:
Fatal error: Call to undefined function mcrypt_create_iv() in /var/www/vhosts/abrakadaweb.com/httpdocs/boutique/system/library/encryption.php on line 8
I have access to admin panel,
Somebody can help me on this please?
Sylvio
=================
I ran upgrade.php I think it was an error. Now I just ran intall.php and I see the ugrade instruction. But I have 3 line of error on top:
Notice: Undefined variable: dbuser in /var/www/vhosts/abrakadaweb.com/httpdocs/boutique/install/index.php(28) : eval()’d code on line 1
Notice: Undefined variable: dbpass in /var/www/vhosts/abrakadaweb.com/httpdocs/boutique/install/index.php(28) : eval()’d code on line 1
Notice: Undefined variable: dbname in /var/www/vhosts/abrakadaweb.com/httpdocs/boutique/install/index.php(28) : eval()’d code on line 1
I clic on UPGRADE, after when I refresh page and cleaned cookies twice on admin panet I lost the admin panel and got this error:(I replace my passwords by xxxxxx)
Notice: Error: Unknown column ‘salt’ in ‘where clause’
Error No: 1054
SELECT * FROM user WHERE username = ‘Fleuve Magique’ AND (password = SHA1(CONCAT(salt, SHA1(CONCAT(salt, SHA1(‘xxxxxxxxx’))))) OR password = ‘xxxxxxxxxxxx7’) AND status = ‘1’ in /var/www/vhosts/abrakadaweb.com/httpdocs/boutique/system/database/mysql.php on line 49
Sylvio ^) ^
AbraKadaWeb.Com
Opencart 1.5.3.1 — FR
call to undefined function mcrypt create iv
Я перенесла свою учетную запись хостинга на новый сервер с помощью cPanel. После этого Opencart начал эту ошибку:
Неустранимая ошибка: вызов неопределенной функции mcrypt_create_iv() в /home/arkadas/public_html/system/library/encryption.php в строке 8
Я установил mcrypt на свой новый сервер, но он все тот же. Я проверил все форумы opencart, но не смог найти решения для этого.
Единственная возможная причина такой ошибки. Fatal error: Call to undefined function mcrypt_create_iv() заключается в том, что расширение mcrypt PHP либо 1. не загружено, либо 2. не установлено вообще.
Дела, которые необходимо сделать:
- убедитесь, что mcrypt установлен на сервере — если нет, установите его, если это возможно (если нет, попросите вашего провайдера установить его для вас).
- если да или после установки убедитесь, что он загружен PHP в php.ini — удалите ведущую точку с запятой ; из строки ;extension=mcrypt.
В системе Debian (Debian, (K | U | X) buntu) Вы можете установить его с помощью следующих команд:
2- проверил phpinfo(); и в два раза проверил , что php.ini мой файл приложения конфигурации.
3- получил Mcrypt пути от моего , /usr/local который /usr/local/Cellar/php53-mcrypt/5.3.29/mcrypt.so и включил его в моем php.ini который является иней файла для моего приложения , как следующее: extension=/usr/local/Cellar/php53-mcrypt/5.3.29/mcrypt.so .
4- возобновляется sudo apachectl restart
и после перезапуска Apache все еще появляется ошибка 🙁
PHP Fatal error: Call to undefined function mcrypt_create_iv()
mcrypt_create_iv — Создать инициализирующий вектор (Initialization Vector или IV) из случайного источника
Эта функция объявлена УСТАРЕВШЕЙ в PHP 7.1.0 и УДАЛЕНА в PHP 7.2.0.
Есть следующие альтернативы:
Описание
Создает инициализирующий вектор из случайного источника.
IV предназначен только для задания альтернативного начального случайного числа для процедур шифрования. IV не обязательно должен быть секретным, хотя это и желательно. Вы даже можете отправить его вместе со своим зашифрованным текстом, не теряя при этом в безопасности.
Список параметров
Источник IV. Источним может быть задан одной из констант: MCRYPT_RAND (системный генератор случайных чисел), MCRYPT_DEV_RANDOM (читает данные из /dev/random ) или MCRYPT_DEV_URANDOM (читает данные из /dev/urandom ). До версии 5.3.0, на Windows поддерживался только MCRYPT_RAND .
Обратите внимание, что до PHP 5.6.0 значением по умолчанию было MCRYPT_DEV_RANDOM .
Замечание: Обратите внимание, что MCRYPT_DEV_RANDOM может блокироваться до появления достаточной энтропии.
Возвращаемые значения
Возвращает инициализирующий вектор или FALSE в случае возникновения ошибки.
Список изменений
| Версия | Описание |
|---|---|
| 5.6.0 | Теперь MCRYPT_DEV_URANDOM является значением по умолчанию для source . |
| 5.3.0 | MCRYPT_DEV_RANDOM и MCRYPT_DEV_URANDOM теперь доступны для Windows. |
| 5.3.0 | Теперь не нужно предварительно запускать srand() , так как это происходит автоматически. |
Примеры
Пример #1 Пример использования mcrypt_create_iv()
Смотрите также
User Contributed Notes 13 notes
In relation to all of the crypto «advice» seen here, my suggestion is that you ignore most of it. Some of it is good, some of it is bad, but most of it skips the critical issues.
I had hoped to write out a nice long explanation, but PHP’s commenting system tells me my essay is too long. Instead I will say this:
You should use CBC, with a randomly chosen IV that is unique per key, and you should transmit that IV in the clear along with your ciphertext. You should also perform an authenticity check of that entire data blob, using something like HMAC-SHA256, with another independent key.
Here’s the full-text of what I was going to write:
If you’re interested in this stuff, or just want more information, check out the Wikipedia articles around block cipher modes, block ciphers, HMAC, etc.
I also suggest reading Practical Cryptography by Bruce Schneier, as well as Cryptography Engineering by Niels Ferguson, both of which are very easy-to-digest books on practical cryptography.
>First, the IV should be random and variable. The whole >point of it is to ensure that the same plaintext does not >encrypt to the same ciphertext every time. You most >certainly do lose security if the IV is constant or public.
Wrong, Wrong WRONG! The initialization vector is ALLOWED to be PUBLIC! It is generally sent along with the ciphertext, UNENCRYPTED.
>The ciphertext should be E(IV | plaintext, key)
Wrong again! The initialization vector is NOT prepended to the plaintext before encryption. The IV is used to seed the feedback system! (which is why you don’t need one in ECB mode — there is no feedback)
>Second, the IV should not be part of the decryption >parameters at all. You should be able to decrypt the cipher >text, throw away the initial vector at the front w/o even >reading it, and have your plaintext:
Nope. You need to seed the feedback mechanism during decryption to the SAME state as it was seeded during encryption. This means using the SAME IV!
12 seconds per call, ironically at random. I’m making the assumption that the halts were caused by insufficient random input being currently available in /dev/random due to its intended function to block until enough random input is provided back to the device. I’ve found it to be sufficient for my needs to use a modified version of the alt_mcrypt_create_iv() function found below.
Although untested, I assume using MCRYPT_DEV_URANDOM or a combination of MCRYPT_DEV_RAND with srand() would’ve solved the problem as well; I found out after the fact that /dev/urandom’s intended function is to seamlessly provide cryptographically secure output from the random number generator when the /dev/urandom buffer was empty, and MCRYPT_DEV_RAND would simply use the same rand() function as alt_mcrypt_create_iv().
It is important to note that all cipher modes except ecb require the same IV to be used in decryption as was used in encryption.
You need to pass the key *and* the IV to your decrypt function. Initializing a new IV in the decrypt routine will not work.
Since, «you even can send [the IV] along with your ciphertext without loosing security,» a nice way to handle this is to prepend your IV to your ciphertext. Since the IV is fixed-width, you can then easily recover the IV and original ciphertext using mcrypt_get_iv_size() and substr().
function my_encrypt ( $string , $key ) //end if
>
function my_decrypt ( $string , $key ) //end if
>
// to test:
//print my_decrypt(my_encrypt(«Hello, world.»,»foo»),»foo»);
?>
This does NOT generate randomly distributed IV’s on all systems and therefore poses a big security risk. Using a script (based on the one that Alex Khimch’s posted on the rand() page) one can easily check this:
= mcrypt_module_open ( MCRYPT_RIJNDAEL_256 , «» , MCRYPT_MODE_CBC , «» );
$iv = mcrypt_create_iv ( mcrypt_enc_get_iv_size ( $td ), MCRYPT_DEV_RANDOM );
// header(«Content-type: image/png»);
$img = imagecreatetruecolor ( 255 , 255 );
$ink = imagecolorallocate ( $img , 255 , 255 , 255 );
for( $i = 0 ; $i 255 ; $i ++)
>
imagepng ( $img );
imagedestroy ( $img );
The resulting image should show random noise, but on the windows systems I tested (running PHP 5.3.x) it showed very distinct patterns.
«While it is often said that IV values need only be random-like or unpredictable, and need not be confidential, in the case of CBC mode, that advice can lead to man-in-the-middle attacks on the first plaintext block. If a MITM opponent knows the usual content of the first block, they can change the IV to manipulate that block (and only that block) to deliver a different address, or different dollar amounts, or different commands, or whatever. And while the conventional advice is to use a MAC at a higher level to detect changed plaintext, that is not always desirable or properly executed. But the CBC first-block problem is easily solved at the CBC level simply by enciphering the IV and otherwise keeping it confidential, and that can be reasonable even when a MAC will be used later.»
hans at illis dot nl’s demonstration code is incorrect. In the loop, he uses:
$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND);
When it should actually be:
$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), MCRYPT_DEV_URANDOM);
This produces consistent results on Windows.
Block ciphers, at their core, are a pair of transformation algorithms, called transforms. One encrypts, one decrypts — in some cases the algorithms are one and the same, but that’s not important. A block transform takes a fixed-length block of plaintext, transforms it using a secret key of some chosen size, and produces an identical-length block of ciphertext. Or, of course, vice versa (decryption).
The security model of a block cipher is, simplistically at least, defined to be «if you encrypt one block of plaintext with a randomly chosen key, it will be computationally infeasible for an attacker with knowledge of only the ciphertext (i.e. he does not know the key) to discover information about the contents of the plaintext». The reality is slightly different — there are also clauses around knowing part of the plaintext and not being able to discover any more of it — but that’s another story.
Once you start encrypting more than one block of plaintext using the same block transform and the same key, all bets are off. In the Electronic Codebook (ECB) cipher mode, each block of plaintext is independently transformed using the same key. This leads to a problem: identical plaintext blocks produce identical ciphertext blocks, when the same key is used. This means that «patterns» in the data can be seen, especially in data formats that have repeating patterns or long sequences of identical data. This is best described visually, with an ECB-encrypted bitmap. See the Wikipedia article on ECB for a demonstration of this.
I encrypt a few items on a page in a project i am working on and I have found the IV create function to introduce huge delays in rendering the page too (I noticed someone else here had this problem).
It’s quite common for a 4 second render time for what should be a snappy site. I would recommend that if speed is essential that an alternative method be used to create your IV (such as the one below if you feel it secure enough).
After using an alternative IV creation method my page went from a 4 second render to a 0.01 second render time.
At:
edwardzyang at thewritingpot dot com
19-Jul-2005 10:06
This is because of the fact, that (like described in the manual above) this function does NOT reseed the random number generator, in contrary to rand(). Use srand() like suggested above to get correct IVs.