Your reply indicated that the encryption switches were supposed to support the N parameter, and it appears that $encode is trying to support that parameter.

In addition to the other bug report where $decode is always ignoring the chunk N parameter - when using encryption switches, the $encode support for the chunk N parameter is not working correctly because:

* the 16-byte "Salted__" or "RandomIV" counts as part of the 45 input bytes to $encode encrypted N=1 chunk.
* Each chunk represents 45 input bytes, which is not a multiple of the 64-bit 8-bytes of the Blowfish cipher's encryption block.

Chunk#1 is shortened and garbled due to an incomplete 8-byte Blowfish block at end of the first 45 bytes, which consists of the 16-byte header + 3 Blowfish blocks @ 8 bytes + 5 bytes of the next Blowfish block being split across 2 chunks. The 3 Blowfish blocks are the only portion of CBC Chunk#1 which decodes correctly:

Code:
//var %chunk 1 , %switch mc , %a $encode($regsubex($str(x,150),/x/g,$base(\n,10,10,3)),%switch,key,%chunk) | echo -a %a -> $chr(22) $decode(%a,%switch,key)


CBC Chunk#1 is shortened and garbled due to incomplete block at end of the first 45 bytes, which is the 16-byte header + 3 Blowfish blocks @ 8 bytes + 5 bytes of the next Blowfish divided across 2 chunks.

Chunk#2 is garbled because the chunk begins at an offset that's not aligned with the 8-byte Blowfish blocks.

Chunk#9 is the first chunk beyond Chunk#1 which does align with the 8-byte Blowfish blocks. While ECB Chunk#9 is not garbled except for the partial Blowfish block at the end, the CBC Chunk#9 is completely garbled. This possibly indicates that later CBC chunks are either ignoring the Salt/IV, or are trying to use the beginning IV for decoding later chunks.

For the non-encryption switches, the chunk#N parameter needs to be a length which encodes an input which is a multiple of 3 for Base64 and UUencode, and a multiple of 5 for Base32. And this is accomplished by the current chunk lengths of 60 and 72.

For the N chunk parameter to be supported by encryption, the chunk's input length needs to be a multiple of 8. It would also need to include a header which could be length zero, 16, or 32. It would need the Salted__ header if a random Salt is being used, and when using CBC encryption it would need to include the IV used to encrypt the Blowfish block at the beginning of that chunk, in a header as if that value is a RandomIV. When the Salt/IV is used to encrypt the data, unless that parameter would be ignored when using the Chunk parameter, there would need to be some way of making the header string dependent on using the correct Salt/IV parameter used.

The Nth chunk would also need to have an indicator that avoids confusion between legitimate padding vs having a portion of the input data at the end of a chunk which happens to match the type of padding. i.e. using the 'p' switch where the last portion of a block decodes to 1 or more spaces but is not near the end of file.

--

Question:

Some of this I was only able to make guesses because I can't find where the CBC encryption is compatible with OpenSSL. Can you give an example of output from $encode CBC encryption which can be decrypted with OpenSSL, or OpenSSL CBC encryption which can be decrypted with $decode?