mcrypt_create_iv

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

mcrypt_create_ivCrée un vecteur d'initialisation (IV) à partir d'une source aléatoire

Avertissement

Cette fonction est OBSOLÈTE à partir de PHP 7.1.0 et a été SUPPRIMÉE à partir de PHP 7.2.0.

Les alternatives à cette fonction incluent :

Description

mcrypt_create_iv(int $size, int $source = MCRYPT_DEV_URANDOM): string

mcrypt_create_iv() crée un IV (vecteur d'initialisation) à partir d'une source aléatoire.

Le vecteur d'initialisation est le seul moyen de fournir une initialisation de remplacement aux méthodes d'initialisation. Ce vecteur n'a pas besoin d'être particulièrement secret, même si c'est mieux. Vous pouvez l'envoyer avec vos documents chiffrés sans perdre en sécurité.

Liste de paramètres

size

La taille du vecteur.

source

La source d'un IV. La source peut être MCRYPT_RAND (le générateur de nombre aléatoire du système), MCRYPT_DEV_RANDOM (lit les données depuis /dev/random) et MCRYPT_DEV_URANDOM (lit les données depuis /dev/urandom). Avant la version 5.3.0, MCRYPT_RAND était la seule constante supportée par Windows.

Notez que la valeur par défaut de ce paramètre était MCRYPT_DEV_RANDOM avant PHP 5.6.0.

Note: Notez que la constante MCRYPT_DEV_RANDOM peut se bloquer en attendant que d'autre anthropie ne soit disponible.

Valeurs de retour

Retourne le vecteur d'initialisation, ou bien false en cas d'erreur.

Exemples

Exemple #1 Exemple avec mcrypt_create_iv()

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

Voir aussi

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