Stream Cipher (Panama) & Decoder question

[rums.da...@gmail.com]

Hi,

when decrypting using pipelines I would normally do something like:

StringSource ss(cipher_hex, true, new HexDecoder(new StreamTransformationFilter(dec, new StringSink(recover))));

Now i ran into a problem using the Panama Stream Cipher:

    AutoSeededRandomPool prng;
    std::string plain("High-school students – who have been protesting against changes to colleges and the university system – also seized on the mood of protest and stepped up their blockades.");
    std::string cipher_hex, recover1, recover2, cipher_bin;

    SecByteBlock key(32), iv(32);
    prng.GenerateBlock(key, key.size());
    prng.GenerateBlock(iv, iv.size());

    PanamaCipher<LittleEndian>::Encryption enc;
    enc.SetKeyWithIV(key, key.size(), iv, iv.size());
    PanamaCipher<LittleEndian>::Decryption dec;
    dec.SetKeyWithIV(key, key.size(), iv, iv.size());

    StringSource (plain, true, new StreamTransformationFilter(enc, new HexEncoder(new StringSink(cipher_hex))));

    // works fine, recover1 = plain
    StringSource (cipher_hex, true, new HexDecoder(new StringSink(cipher_bin)));
    StringSource (cipher_bin, true, new StreamTransformationFilter(dec, new StringSink(recover1)));

    dec.Resynchronize(iv, iv.size());

    // does not work, recover2 = "High-school students – who have been protesting against changes –Ö)‘à« ç›áS` ¥¨~]Šm Q­ÿö:Û (...) "
    StringSource (cipher_hex, true, new HexDecoder(new StreamTransformationFilter(dec, new StringSink(recover2))));

Is this expected behaviour? Is it not possible to use a Decoder inside the decryption pipeline of a stream cipher?

Thanks in advance to anyone who might be able to clear this up for me!

[Jeffrey Walton]

No, its not expected behavior.

I can duplicate it with GCC 8.2.1 on Fedora 29. Clang 6.0.1 is OK on Fedora 29.

GCC 6 and Clang 6 are OK on OS X.

Let me see if I can find a workaround in the code.

Jeff

[Jeffrey Walton]

I'm still looking for a solution.

The unusual thing I'm seeing is, it is happening at character 70. I would expect something unusual to happen on a simd-word or block boundary.

   $ echo 'Two: High-school students – who have been protesting against change' | wc -c
   70

For the moment you can work around the issue by opening panama.h, and defining CRYPTOPP_DISABLE_PANAMA_ASM. It is a safety for X32 and Clang, but it works for GCC as well.

Jeff

[rums.da...@gmail.com]

thank you very much! This also works for the current ms compiler. I will use it as temporary fix.

[Jeffrey Walton]

On Wednesday, December 5, 2018 at 8:31:15 AM UTC-5, rums.da...@gmail.com wrote:

thank you very much! This also works for the current ms compiler. I will use it as temporary fix.

Thanks. I was not aware of an issue on MS platforms.

I had some time to look at this in more detail. Confirmed Microsoft is also incorrect.

Both GCC and MS use the inline assembly. Clang is OK because we have to disable ASM for this algorithm. I'm guessing the problem is with the inline assembly.

I also tested back to Crypto++ 5.6.2 and it had the same problem.

We're tracking this at https://github.com/weidai11/cryptopp/issues/758 .

Jeff