From: Paul M Foster on
I've got a file of passwords I'd like to encrypt/decrypt using blowfish. I'd
like to be able to do so with PHP and via the command line. I have a
Linux utility call "bcrypt" which encrypts/decrypts files using
blowfish. And I'm using the following code under PHP to do
encryption/decryption:

$raw_data = file('junk');
$input = implode('', $raw_data);

$td = mcrypt_module_open(MCRYPT_BLOWFISH, '', MCRYPT_MODE_ECB, '');
$iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
mcrypt_generic_init($td, $key, $iv);
$encrypted_data = mcrypt_generic($td, $input);
file_put_contents('encjunk', $encrypted_data);
mcrypt_generic_deinit($td);
mcrypt_module_close($td);


Now, here's the problem. I'm using bcrypt to encrypt my junk file and
dump it out to an encrypted file. And I'm using the above PHP code to
encrypt the same file out to a different file. Using the same keys in
both cases, I get different encrypted files.

My logic: using the same encryption method and the same key, two
different implementations should produce equivalent files.

Yet they don't. I'm guessing that the "initialization vector" is
different between the two implementations, resulting in the difference
between the encrypted files.

For those who know more about encryption than I do, does that sound
right?

Paul

--
Paul M. Foster
From: Adam Richardson on
On Mon, Jun 7, 2010 at 11:20 PM, Paul M Foster <paulf(a)quillandmouse.com>wrote:

> I've got a file of passwords I'd like to encrypt/decrypt using blowfish.
> I'd
> like to be able to do so with PHP and via the command line. I have a
> Linux utility call "bcrypt" which encrypts/decrypts files using
> blowfish. And I'm using the following code under PHP to do
> encryption/decryption:
>
> $raw_data = file('junk');
> $input = implode('', $raw_data);
>
> $td = mcrypt_module_open(MCRYPT_BLOWFISH, '', MCRYPT_MODE_ECB, '');
> $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
> mcrypt_generic_init($td, $key, $iv);
> $encrypted_data = mcrypt_generic($td, $input);
> file_put_contents('encjunk', $encrypted_data);
> mcrypt_generic_deinit($td);
> mcrypt_module_close($td);
>
>
> Now, here's the problem. I'm using bcrypt to encrypt my junk file and
> dump it out to an encrypted file. And I'm using the above PHP code to
> encrypt the same file out to a different file. Using the same keys in
> both cases, I get different encrypted files.
>
> My logic: using the same encryption method and the same key, two
> different implementations should produce equivalent files.
>
> Yet they don't. I'm guessing that the "initialization vector" is
> different between the two implementations, resulting in the difference
> between the encrypted files.
>
> For those who know more about encryption than I do, does that sound
> right?
>
> Paul
>
> --
> Paul M. Foster
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
ECB (Electronic Code Book) mode works without an initialization vector.
Imagine having a big, thick code book, and every possible 8-letter
combination in the book. To encrypt the message, you thumb through the book
and find the plain text "THE KIDS", and write down its cipher text
representation, "JKWSCTFI." Easy to implement, and easy to maintain (you
don't have to make sure an IV is shared between the exchanging parties.)

If one has multiple samples of encrypted emails, it's likely that the
several of the samples will end using the same cipher text, as many people
end their emails with a consistent signature. This repeated cipher text
improves the ability of those trying to attack (decrypt the message.)
Hence, most professionals recommend avoiding ECB mode.

Now, looking at your PHP code, I see that it appears your mixing and
matching some of the families of calls in ways that might lead to unexpected
results. Try the below:

$ciphertext = mcrypt_encrypt(
$cipher = MCRYPT_BLOWFISH,
$key,
$plaintext,
$mode = 'cbc', // I just tossed this in as an example, but you should
match the mode bcrypt is using
$iv = 'use only once, sometimes a count, or a date' // needed for
decryption, too, although it doesn't have to remain a secret.
);

Hope this helps,

Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
From: Paul M Foster on
On Mon, Jun 07, 2010 at 11:59:14PM -0400, Adam Richardson wrote:

> On Mon, Jun 7, 2010 at 11:20 PM, Paul M Foster <paulf(a)quillandmouse.com> wrote:
>
> I've got a file of passwords I'd like to encrypt/decrypt using blowfish.
> I'd
> like to be able to do so with PHP and via the command line. I have a
> Linux utility call "bcrypt" which encrypts/decrypts files using
> blowfish. And I'm using the following code under PHP to do
> encryption/decryption:
>
> $raw_data = file('junk');
> $input = implode('', $raw_data);
>
> $td = mcrypt_module_open(MCRYPT_BLOWFISH, '', MCRYPT_MODE_ECB, '');
> $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($td), MCRYPT_RAND);
> mcrypt_generic_init($td, $key, $iv);
> $encrypted_data = mcrypt_generic($td, $input);
> file_put_contents('encjunk', $encrypted_data);
> mcrypt_generic_deinit($td);
> mcrypt_module_close($td);
>
>
> Now, here's the problem. I'm using bcrypt to encrypt my junk file and
> dump it out to an encrypted file. And I'm using the above PHP code to
> encrypt the same file out to a different file. Using the same keys in
> both cases, I get different encrypted files.
>
> My logic: using the same encryption method and the same key, two
> different implementations should produce equivalent files.
>
> Yet they don't. I'm guessing that the "initialization vector" is
> different between the two implementations, resulting in the difference
> between the encrypted files.
>
> For those who know more about encryption than I do, does that sound
> right?
>
> Paul
>
> --
> Paul M. Foster
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> ECB (Electronic Code Book) mode works without an initialization vector.
> Imagine having a big, thick code book, and every possible 8-letter combination
> in the book. To encrypt the message, you thumb through the book and find the
> plain text "THE KIDS", and write down its cipher text representation,
> "JKWSCTFI." Easy to implement, and easy to maintain (you don't have to make
> sure an IV is shared between the exchanging parties.)

Good explanation. Thanks.

>
> If one has multiple samples of encrypted emails, it's likely that the several
> of the samples will end using the same cipher text, as many people end their
> emails with a consistent signature. This repeated cipher text improves the
> ability of those trying to attack (decrypt the message.) Hence, most
> professionals recommend avoiding ECB mode.

Well, bcrypt mentions CBC in the (brief) documentation, but the C code
contains a couple of tables, one containing probably 1024 32-bit long
integer values. Based on your description, that sounds like ECB, right?

Bcrypt doesn't all the specification of what mode enc/dec is done in.
That is, I can't specify to the program ECB, CBC or other.

Also, according to the docs for bcrypt, it hashes your password out to
he maximum size for the cipher (448 bytes?). This sounds like an
implementation-specific decision which may not be echoed by PHP's mcrypt
functions. Does that sound reasonable?

>
> Now, looking at your PHP code, I see that it appears your mixing and matching
> some of the families of calls in ways that might lead to unexpected results.
> Try the below:
>
> $ciphertext = mcrypt_encrypt(
> $cipher = MCRYPT_BLOWFISH,
> $key,
> $plaintext,
> $mode = 'cbc', // I just tossed this in as an example, but you should match
> the mode bcrypt is using
> $iv = 'use only once, sometimes a count, or a date' // needed for
> decryption, too, although it doesn't have to remain a secret.
> );

Another point: my code above is actually from a post by someone else on
this list. Now, the iv above is based on a random number. If I encrypt
the file on Monday, and then attempt to decrypt it on Tuesday using a
different (random-number-based) iv, will the file decrypt properly?

Paul

--
Paul M. Foster
From: Adam Richardson on
Hi Paul,


> > If one has multiple samples of encrypted emails, it's likely that the
> several
> > of the samples will end using the same cipher text, as many people end
> their
> > emails with a consistent signature. This repeated cipher text improves
> the
> > ability of those trying to attack (decrypt the message.) Hence, most
> > professionals recommend avoiding ECB mode.
>
> Well, bcrypt mentions CBC in the (brief) documentation, but the C code
> contains a couple of tables, one containing probably 1024 32-bit long
> integer values. Based on your description, that sounds like ECB, right?
>

I provided the description of ECB merely to provide a general theoretical
understanding of ECB (i.e., there is a one-to-one correspondence between any
chunk of plaintext and any resulting ciphertext that is always the same.)
However, in practical terms, tables you see in code usually have to do with
S-boxes, or some other type of the implementation. So, seeing tables in the
implementation code gives you no more info as to the mode.


>
> Bcrypt doesn't all the specification of what mode enc/dec is done in.
> That is, I can't specify to the program ECB, CBC or other.
>

Sounds likely, given the goal for portability.


>
> Also, according to the docs for bcrypt, it hashes your password out to
> he maximum size for the cipher (448 bytes?). This sounds like an
> implementation-specific decision which may not be echoed by PHP's mcrypt
> functions. Does that sound reasonable?
>
>
You'll have to match the hashing process to generate your key.


> >
> > Now, looking at your PHP code, I see that it appears your mixing and
> matching
> > some of the families of calls in ways that might lead to unexpected
> results.
> > Try the below:
> >
> > $ciphertext = mcrypt_encrypt(
> > $cipher = MCRYPT_BLOWFISH,
> > $key,
> > $plaintext,
> > $mode = 'cbc', // I just tossed this in as an example, but you should
> match
> > the mode bcrypt is using
> > $iv = 'use only once, sometimes a count, or a date' // needed for
> > decryption, too, although it doesn't have to remain a secret.
> > );
>
> Another point: my code above is actually from a post by someone else on
> this list. Now, the iv above is based on a random number. If I encrypt
> the file on Monday, and then attempt to decrypt it on Tuesday using a
> different (random-number-based) iv, will the file decrypt properly?
>

NO, if you're using a mode other than ECB. If you're using CBC or some
other mode that utilizes the IV, the same IV must be used for encryption AND
decryption. However, when using ECB, the IV isn't used, so it wouldn't
matter (if you pass in an IV, it's just ignored.)

The IV is used to make sure no two plaintexts will be represented by the
same cipher texts, and must be shared between those wishing to encrypt and
decrypt the message. However, it doesn't have to kept secret.


>
> Paul
>
> --
> Paul M. Foster
>

Sounds like you're making progress :) I'm busy today (off to the doctor for
a bum knee), but I'll probably look through bcrypt later this week just to
better understand its implementation (that is to say, sorry I don't have
more implementation details of that particular encryption scheme right now,
but maybe later.)

Adam

--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
From: Paul M Foster on
On Tue, Jun 08, 2010 at 09:48:43AM -0400, Adam Richardson wrote:

> Hi Paul,
>
>
> > If one has multiple samples of encrypted emails, it's likely that the
> several
> > of the samples will end using the same cipher text, as many people end
> their
> > emails with a consistent signature. This repeated cipher text improves
> the
> > ability of those trying to attack (decrypt the message.) Hence, most
> > professionals recommend avoiding ECB mode.
>
> Well, bcrypt mentions CBC in the (brief) documentation, but the C code
> contains a couple of tables, one containing probably 1024 32-bit long
> integer values. Based on your description, that sounds like ECB, right?
>
>
> I provided the description of ECB merely to provide a general theoretical
> understanding of ECB (i.e., there is a one-to-one correspondence between any
> chunk of plaintext and any resulting ciphertext that is always the same.)
> However, in practical terms, tables you see in code usually have to do with
> S-boxes, or some other type of the implementation. So, seeing tables in the
> implementation code gives you no more info as to the mode.

Makes sense. In the code, they're labeled that way (e.g. S[4][256]).

>
>
>
> Bcrypt doesn't all the specification of what mode enc/dec is done in.
> That is, I can't specify to the program ECB, CBC or other.
>
>
> Sounds likely, given the goal for portability.
>
>
>
> Also, according to the docs for bcrypt, it hashes your password out to
> he maximum size for the cipher (448 bytes?). This sounds like an
> implementation-specific decision which may not be echoed by PHP's mcrypt
> functions. Does that sound reasonable?
>
>
>
> You'll have to match the hashing process to generate your key.
>
>
> >
> > Now, looking at your PHP code, I see that it appears your mixing and
> matching
> > some of the families of calls in ways that might lead to unexpected
> results.
> > Try the below:
> >
> > $ciphertext = mcrypt_encrypt(
> > $cipher = MCRYPT_BLOWFISH,
> > $key,
> > $plaintext,
> > $mode = 'cbc', // I just tossed this in as an example, but you should
> match
> > the mode bcrypt is using
> > $iv = 'use only once, sometimes a count, or a date' // needed for
> > decryption, too, although it doesn't have to remain a secret.
> > );
>
> Another point: my code above is actually from a post by someone else on
> this list. Now, the iv above is based on a random number. If I encrypt
> the file on Monday, and then attempt to decrypt it on Tuesday using a
> different (random-number-based) iv, will the file decrypt properly?
>
>
> NO, if you're using a mode other than ECB. If you're using CBC or some other
> mode that utilizes the IV, the same IV must be used for encryption AND
> decryption. However, when using ECB, the IV isn't used, so it wouldn't matter
> (if you pass in an IV, it's just ignored.)
>
> The IV is used to make sure no two plaintexts will be represented by the same
> cipher texts, and must be shared between those wishing to encrypt and decrypt
> the message. However, it doesn't have to kept secret.
>
>
>
> Paul
>
> --
> Paul M. Foster
>
>
> Sounds like you're making progress :) I'm busy today (off to the doctor for a
> bum knee), but I'll probably look through bcrypt later this week just to better
> understand its implementation (that is to say, sorry I don't have more
> implementation details of that particular encryption scheme right now, but
> maybe later.)

Yeah, this is great. Thanks so much for your help. I really know very
little about encryption. If you think of something else, feel free to
comment.

Paul

--
Paul M. Foster