Vulnerability in Crypt::CBC Perl module, versions <= 2.16 Feb 23 2006 10:38PM
Lincoln Stein (lstein cshl edu)
Perl Module Security Advisory

   Title: Crypt::CBC ciphertext weakness when using certain block algorithms
Severity: High
Versions: All versions <= 2.16.
    Date: 23 February 2006


The Perl Crypt::CBC module versions through 2.16 produce weak
ciphertext when used with block encryption algorithms with blocksize >
8 bytes.


Crypt::CBC implements the Cipher Block Chaining Mode (CBC) [1].  CBC
allows block ciphers (which encrypt and decrypt chunks of data of a
fixed block length) to act as though they are stream ciphers capable
of encrypting and decrypting arbitrary length streams. It does this by
randomly generating an initialization vector (IV) the same length as
the cipher's block size. This IV is logically XORed with the first
block of plaintext prior to encryption. The block is encrypted, and
the result is used as the IV applied to the next block of plaintext.
This process is repeated for each block of plaintext.

In order for ciphertext encrypted by Crypt::CBC to be decrypted, the
receiver must know both the key used to encrypt the data stream and
the IV that was chosen. Because the IV is not secret, it can safely be
appended to the encrypted message. The key, of course, is kept in a
safe place and transmitted to the recipient by some secure means.

Crypt::CBC can generate two types of headers for transmitting the
IV. The older, deprecated, header type is known as the "RandomIV"
header, and consists of the 8 byte string "RandomIV" followed by 8
bytes of IV data. This is the default header generated by Crypt::CBC
versions through 2.16. The newer, recommended, type of header is known
as the "Salted" header and consists of the 8 byte string "Salted__"
followed by an 8 byte salt value. The salt value is used to rederive
both the encryption key and the IV from a long passphrase provided by
the user. The Salted header was introduced in version 2.13 and is
compatible with the CBC header generated by OpenSSL [2].


The RandomIV style header assumes that the IV will be exactly 8 bytes
in length. However, the IV must be the same length as the underlying
cipher's block size, and so this assumption is not correct when using
ciphers whose block size is greater than 8 bytes. Of the ciphers
commonly available to Perl developers, only the Rijndael algorithm,
which uses a 16 byte block size is the primary cipher affected by this
issue. Rijndael is the cipher that underlies the AES encryption


Ciphertext encrypted with Crypt::CBC using the legacy RandomIV header
and the Rijndael cipher is not secure. The latter 8 bytes of each
block are chained using a constant effective IV of null, meaning that
the ciphertext will be prone to differential cryptanalysis,
particularly if the same key was used to generate multiple encrypted
messages. Other >8-byte cipher algorithms will be similarly affected.

The difficulty of breaking data encrypted using this flawed algorithm
is unknown, but it should be assumed that all information encrypted in
this way has been, or could someday be, compromised.


There are no active exploits known at this time.


If using Crypt::CBC versions 2.16 and lower, pass the -salt=>1 option
to Crypt::CBC->new(). This will generate and process IVs correctly for
ciphers of all length.


Upgrade to Crypt::CBC version 2.17 or higher. This module makes the
Salted header the default behavior and refuses to encrypt or decrypt
with non-8 byte block size ciphers when in legacy RandomIV mode.

In order to decrypt ciphertext previously encrypted by pre-2.17
versions of the software with Rijndael and other >8-byte algorithms,
Crypt::CBC provides an -insecure_legacy_decrypt option that will allow
such ciphertext to be decrypted. The default is to refuse to decrypt
such data.

The most recent version of Crypt::CBC can be downloaded from the
Comprehensive Perl Archive Network (CPAN; http://www.cpan.org).


For further information about this issue, please contact the author of
Crypt::CBC, Lincoln Stein <lstein (at) cshl (dot) edu [email concealed]>.


The author gratefully acknowledges the contribution of Ben
Laurie<ben (at) algroup.co (dot) uk [email concealed]>, who correctly identified the issue and
suggested the resolution.


[1] http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
[2] http://www.openssl.org/
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
SANDRA MICHELSEN, AT michelse (at) cshl (dot) edu [email concealed]

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus