mcrypt_create_iv

(PHP 4, PHP 5, PHP 7 < 7.2.0, PECL mcrypt >= 1.0.0)

mcrypt_create_ivRasgele bir kaynaktan bir ilklendirme vektörü (IV) oluşturur

Uyarı

Bu işlevin kullanımı PHP 7.1.0'dan beri ÖNERİLMEMEKTEDİR ve PHP 7.2.0'da tamamen KALDIRILMIŞTIR.

Bu işlevin yerine kulllanılabilecekler:

Açıklama

mcrypt_create_iv(int $boy, int $kaynak = MCRYPT_DEV_URANDOM): string

Rasgele bir kaynaktan bir ilklendirme vektörü (IV) oluşturur.

IV dizgesi, şifreleme yordamları için ek bir tohum olarak kullanılır. Bu IV'nin gizli olması gerekmediği gibi istenmez de. Hiçbir güvenlik kaybı oluşmadan şifreli metin ile birlikte gönderebilirsiniz.

Bağımsız Değişkenler

boy

IV boyu.

kaynak

Şu değerlerden biri olabilir: MCRYPT_RAND (sistem rasgele sayı üreteci), MCRYPT_DEV_RANDOM (veri /dev/random'dan okunur), MCRYPT_DEV_URANDOM (veri /dev/urandom'dan okunur). Windows (şüphesiz) /dev/random veya /dev/urandom aygıtlarına sahip olmadığından Windows için sadece MCRYPT_RAND desteklenmektedir. PHP 5.3.0 öncesinde, MCRYPT_RAND Windows üzerinde desteklenen tek sabitti.

PHP 5.6.0 öncesinde, bu bağımsız değişkenin öntanımlı değeri MCRYPT_DEV_RANDOM idi.

Bilginize: MCRYPT_DEV_RANDOM daha fazla döküntü sağlanana kadar engellenebilir.

Dönen Değerler

Bir hata durumunda false yoksa ilklendirme vektörünü bir dizge olarak döndürür.

Örnekler

Örnek 1 - mcrypt_create_iv() örneği

<?php
$boy
= mcrypt_get_iv_size(MCRYPT_CAST_256, MCRYPT_MODE_CFB);
$iv = mcrypt_create_iv($size, MCRYPT_DEV_RANDOM);
?>

Ayrıca Bakınız

add a note

User Contributed Notes 2 notes

up
44
Graham
10 years ago
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: http://pastebin.com/sN6buivY

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.
up
16
Chris
18 years ago
>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!
To Top