mcrypt also seems to be implementing OFB and CFB modes identically.  Although the first block produced by either mode should be the same, subsequent blocks should be different. ie. in CFB, the second block is XOR'd with the previous ciphertext, reencrypted with the key, whereas in OFB, the second block is XOR'd with that which the previous text was previously XOR'd with.

Example code:

<?php
$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, '');
mcrypt_generic_init($td, 'aaaaaaaa', 'bbbbbbbb');
echo urlencode(mcrypt_generic($td, str_repeat("\0", 16))) . "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, '');
mcrypt_generic_init($td, 'aaaaaaaa', 'bbbbbbbb');
echo urlencode(mcrypt_generic($td, str_repeat("\0", 16)));
?>

It looks like a libmcrypt problem, if it is a bug. Can you try using the mcrypt cmd line tools? If it fails and you see it as a bug, please report a bug to the mcrypt project. Let us know how it went.

Filing a bug report is going to be a little difficult giving that, near as I can tell, the command line version of mcrypt randomly generates IV's.  My first example requires the IV's be of a known value and my second example requires encrypting the same string with two different modes and with the same IV.

Also, to be honest, I don't know at all how to intreprete the data the command line version of mcrypt is giving me, anyway.  I do the following:

mcrypt --algorithm des --mode ecb --no-openpgp test.txt --verbose --bare

And I get a 100 byte file.  Given that the source file was 16 bytes ("-" repeated sixteen times), that's a bit odd.  Curious to see what the remaining 84 bytes are, I do the following:

<?php
$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, '');
mcrypt_generic_init($td, 'test', "\0\0\0\0\0\0\0\0");
echo mdecrypt_generic($td, file_get_contents('test.txt.nc'));
?>

And that doesn't produce anything even remotely resembling the source text.

A while ago, there was a bug report filed on the mcrypt PHP extension (49561) where someone reproduced the problem in C, using the mcrypt libraries, and filed the bug report themselves.  Can't that be done here?  I don't have the ability to compile PHP or PHP extensions such as mcrypt and if no one reports the bug to the mcrypt developers than both PHP and mcrypt will have this bug.

Of course, then again, given that bug # 49561 hasn't even been touched by the mcrypt developers, it seems safe to assume that any bug report that's filed - by me or anyone else - will be ignored.  If mcrypt has been abandoned by its developers when does PHP abandon mcrypt?

As far as I know, the IV is also used for the first round, so I am not sure if your statement holds up.

As far as I know, the IV is also used for the first round, so I am not
sure if your statement holds up.

Ummm...  the IV - as defined in mcrypt_generic_init - is only used in the first round.  Per wikipedia, the first block against which the plaintext is XOR'd is the IV encrypted with the key.  That's true in both CFB and OFB modes of operation.  The difference between CFB and OFB is what subsequent blocks encrypt for the keystream.  So, per that, the first block should be the same.  And as for my first bug report...

<?php
$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, '');
mcrypt_generic_init($td, 'aaaaaaaa', 'bbbbbbbb');
echo urlencode(mcrypt_generic($td, "\0\0\0\0\0\0\0\0"));

echo "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, '');
mcrypt_generic_init($td, 'aaaaaaaa', 'bbbbbbbb');
echo urlencode(mcrypt_generic($td, "\0\0\0\0\0\0\0\0"));

echo "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, '');
mcrypt_generic_init($td, 'aaaaaaaa', "\0\0\0\0\0\0\0\0");
echo urlencode(mcrypt_generic($td, 'bbbbbbbb'));

echo "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CBC, '');
mcrypt_generic_init($td, 'aaaaaaaa', "\0\0\0\0\0\0\0\0");
echo urlencode(mcrypt_generic($td, 'bbbbbbbb'));

echo "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', 'ctr', '');
mcrypt_generic_init($td, 'aaaaaaaa', 'bbbbbbbb');
echo urlencode(mcrypt_generic($td, "\0\0\0\0\0\0\0\0"));
?>

All of those should produce the same ciphertext.  As it stands, only ecb, cbc and ctr produce the same ciphertext.  ofb and cfb produce the same thing as each other (and, for the first block, they should, as I already mentioned), however, they're not producing the same thing as any of the other modes when, in fact, they should be.

I was comparing mcrypt against openssl_encrypt() and...  well, either OpenSSL is wrong or mcrypt is wrong:

<?php
$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_OFB, '');
mcrypt_generic_init($td, 'aaaaaaaa', "\0\0\0\0\0\0\0\0");
echo bin2hex(mcrypt_generic($td, "\0\0\0\0\0\0\0\0"));

echo "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CFB, '');
mcrypt_generic_init($td, 'aaaaaaaa', "\0\0\0\0\0\0\0\0");
echo bin2hex(mcrypt_generic($td, "\0\0\0\0\0\0\0\0"));

echo "\r\n";

echo bin2hex(openssl_encrypt("\0\0\0\0\0\0\0\0", 'DES-OFB', 'aaaaaaaa', true)) . "\r\n";
echo bin2hex(openssl_encrypt("\0\0\0\0\0\0\0\0", 'DES-CFB', 'aaaaaaaa', true)) . "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_ECB, '');
mcrypt_generic_init($td, 'aaaaaaaa', "\0\0\0\0\0\0\0\0");
echo bin2hex(mcrypt_generic($td, "\0\0\0\0\0\0\0\0"));

echo "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', MCRYPT_MODE_CBC, '');
mcrypt_generic_init($td, 'aaaaaaaa', "\0\0\0\0\0\0\0\0");
echo bin2hex(mcrypt_generic($td, "\0\0\0\0\0\0\0\0"));

echo "\r\n";

$td = mcrypt_module_open(MCRYPT_DES, '', 'ctr', '');
mcrypt_generic_init($td, 'aaaaaaaa', "\0\0\0\0\0\0\0\0");
echo bin2hex(mcrypt_generic($td, "\0\0\0\0\0\0\0\0"));
?>

ie. mcrypt, in CTR, CBC and ECB modes equal OpenSSL in OFB and CFB modes but not mcrypt in OFB and CFB modes.  In other words, OpenSSL's OFB != mcrypt's OFB and they should.

You're using the wrong OFB mode, you need to use MCRYPT_MODE_NOFB.
MCRYPT_MODE_OFB is per-byte, while MCRYPT_MODE_NOFB is per-block and gives the 
result you were expecting.

What does it even mean to do OFB at the byte-level?  Per <http://en.wikipedia.org/wiki/File:Ofb_encryption.png>, in OFB, you encrypt the IV with the key with the chosen block cipher algorithm and then XOR that against the plaintext to get the ciphertext.   How do you do that at the "byte level"?  Do you do substrings or something?

Also, there's still the matter of CFB.  So NOFB is what most everything else refers to as OFB but CFB'a wrong, as well, and it has no NCFB counter part.

To answer your first question, performing the encryption per-byte is kind of odd, I haven't done much 
testing but I don't think it actually consumes the entire input vector, only the first byte, just think of 
it as running with an 8-bit wide state, rather than the more typical 128-bit wide state.
I've never had the time to confirm that this is the exact case, though, but I believe it's compatible with 
other cryptography solutions that can operate per-byte.


For your second point; sorry I should have pointed out that there is no predefined constant for 
MCRYPT_MODE_NCFB, you can however just enter it manually as 'ncfb' like so:

mcrypt_module_open('rijndael-128', '', 'ncfb', '');


So if there's a failing on the PHP side it's that we need an MCRYPT_MODE_NCFB, and that MCRYPT_MODE_CFB 
and MCRYPT_MODE_OFB should be properly documented so people don't keep using them expecting different 
results!

I can't believe what I was reading about ncfb above.  That was the solution to decrypt my OpenOffice files.  I had it working in Java, with openssl on the command line but I couldn't get it to work with php no matter what I tried.  I had no idea that such a mode exists.  So please, document this and define a constant for it.

This addition might come as very low quality as I am still trying to understand AES128 and CFB, but I think it is important to have the additional information one can gather. I hope it helps.

I was stuck trying to get mcrypt to cipher a string with AES128 in CFB mode, to be used by the corresponding code in ASP.NET. I first thought ASP was the erroneous part, but apparently not.

This is my code snippet (note that padding is made with PKCS7 method). I use an IV identical to my key, which is OK considering the key is 16 bytes long:

$password = 'not ciphered';
$key = '-+*%$({..})$%*+-';
$blockSize = 16;
$padding = $blockSize - (strlen($password)%$blockSize);
$password .= str_repeat(chr($padding),$padding);
$cipher = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $password,  MCRYPT_MODE_CFB, $key);
$arr = preg_split('//', $cipher, -1, PREG_SPLIT_NO_EMPTY);
foreach ($arr as $char) {
    echo ord($char).',';
}

The generated $cipher is the following sequence of (16) bytes:
179,90,167,188,65,82,212,108,133,15,161,49,142,222,207,167

However, the correct sequence of bytes should be as defined below, and can easily be generated using phpseclib:

    $password = 'not ciphered';
    $key = '-+*%$({..})$%*+-';
    $blockSize = 16;
    $padding = $blockSize - (strlen($password)%$blockSize);
    $password .= str_repeat(chr($padding),$padding);
    $cipher = new Crypt_AES(CRYPT_AES_MODE_CFB);
    $cipher->setKeyLength(128);
    $cipher->setKey($key);
    $cipher->setIV($key);
    $cipheredPass = $cipher->encrypt($password);
    $arr = preg_split('//', $cipheredPass, -1, PREG_SPLIT_NO_EMPTY);
    foreach ($arr as $char) {
        echo ord($char).',';
    }

This last code generates the following sequence of (16) bytes:
179,15,83,71,111,104,118,215,159,221,153,228,153,148,69,164

Now, as I said, I'm still wrapping my brains around the whole AES128 (and in particular CFB), but this last result is also what you get in ASP (and apparently in C, C++, etc).

There's a guy who apparently understands the problem better and put me in the right direction here: http://stackoverflow.com/a/4054017/1406662
I found a few other references linking to mcrypt, but not specifically with CFB (for some reason people seen to try CBC and NOFB first).
Apparently, the problem comes down to the default "feedback" size, which would not be set properly in either PHP or mcrypt.

Also, somehow, phpseclib got it right, and it's MIT-licensed, so maybe a source of inspiration?
http://phpseclib.sourceforge.net/index.html

The problem might effectively come from mcrypt, and I'd be happy to report there if confirmed and if you point me in the right direction as to where that is done most efficiently.

Sorry, I forgot to mention (if that has any incidence on this report) I use PHP 5.5.3 (mod_php5) with the mcrypt module for 5.4.6.
How is that even possible, I don't know, but that's what my dear Ubuntu is telling me... moving back to Debian soon, I swear :-p

Closing because it's not PHP implementing the encryption modes, it's libmcrypt which is unmaintained.

The assumption that encrypting in OFB and decrypting in ECB should yield the IV at the start of the plaintext (where the original plaintext is entirely null bytes) is correct. If mcrypt does not do this, it is a problem with the third party library, the PHP module is just a wrapper.

I'm sorry but I believe this has been closed prematurely; as I have pointed out, mcrypt is in fact operating correctly, the issue here is that the behaviour of its CFB and OFB modes is misleading as it is per-byte, rather than per-state size block.

The solution is to use the MCRYPT_MODE_NOFB constant, or to request ncfb mode via string, as the n signifies that these are scaled to the size of the state/key, so 128, 192 or 256 bits.

As I stated in my earlier comment, the problem is in fact on the PHP side in so far as there is no MCRYPT_MODE_NCFB constant, and that the documentation for the CFB and OFB constants do not clarify that these are per-byte modes of operation. I believe that these are therefore issues with PHP's libmcrypt wrapper, not libmcrypt itself, and should be resolvable (especially after nearly seven years!)

Ok, so what this boils down to is:

1) A documentation issue that mcrypt's implementation of OFB and CFB (as represented by MODE_OFB and MODE_CFB) operate in 8-bit mode, and that NCFB operates on full blocks.

2) A feature request to wrap mcrypt's MODE_NCFB constant.

Reclassifying as documentation problem for part 1). As the mcrypt extension has been killed, we won't be adding new constants -- the documentation should state that the string should be passed directly for this.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.