mcrypt_create_iv

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

    mcrypt_create_iv — Creates an initialization vector (IV) from a random source

    Aviso

    Esta função tornou-se DEFASADA a partir do PHP 7.1.0 e foi REMOVIDA a partir do PHP 7.2.0.

    Alternativas a esta função incluem:

    Descrição

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

    Creates an initialization vector (IV) from a random source.

    The IV is only meant to give an alternative seed to the encryption routines. This IV does not need to be secret at all, though it can be desirable. You even can send it along with your ciphertext without losing security.

    Parâmetros

    size

    The size of the IV.

    source

    The source of the IV. The source can be MCRYPT_RAND (system random number generator), MCRYPT_DEV_RANDOM (read data from /dev/random) and MCRYPT_DEV_URANDOM (read data from /dev/urandom). Prior to 5.3.0, MCRYPT_RAND was the only one supported on Windows.

    Note that the default value of this parameter was MCRYPT_DEV_RANDOM prior to PHP 5.6.0.

    Nota: Note that MCRYPT_DEV_RANDOM may block until more entropy is available.

    Valor Retornado

    Returns the initialization vector, or false on error.

    Exemplos

    Exemplo #1 mcrypt_create_iv() Example

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

    Veja Também

    Melhore Esta Página

    Aprenda Como Melhorar Esta Página • Envie uma Solicitação de Modificação • Reporte um Problema
    ＋adicione uma nota

    Notas Enviadas por Usuários (em inglês) 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!
    ＋adicione uma nota
    To Top