Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPECK64 different output if input is passed in chunks #945

Closed
guidovranken opened this issue Apr 22, 2020 · 8 comments
Closed

SPECK64 different output if input is passed in chunks #945

guidovranken opened this issue Apr 22, 2020 · 8 comments
Labels

Comments

@guidovranken
Copy link

Reproducer:

#include <modes.h>
#include <filters.h>
#include <speck.h>

#define CF_CHECK_EQ(expr, res) if ( (expr) != (res) ) { goto end; }

std::vector<uint8_t> Encrypt(const std::vector<uint8_t>& key, const std::vector<uint8_t>& iv, const std::vector<std::vector<uint8_t>>& cleartext) {
    ::CryptoPP::OFB_Mode<::CryptoPP::SPECK64>::Encryption enc(key.data(), key.size(), iv.data());
    ::CryptoPP::StreamTransformationFilter encryptor(enc, nullptr);
    for (const auto& part : cleartext) {
        encryptor.Put(part.data(), part.size());
    }
    encryptor.MessageEnd();
    std::vector<uint8_t> out(encryptor.MaxRetrievable());
    encryptor.Get(out.data(), out.size());
    return out;
}

std::vector<uint8_t> Decrypt(const std::vector<uint8_t>& key, const std::vector<uint8_t>& iv, const std::vector<uint8_t>& ciphertext) {
    ::CryptoPP::OFB_Mode<::CryptoPP::SPECK64>::Decryption dec(key.data(), key.size(), iv.data());
    ::CryptoPP::StreamTransformationFilter decryptor(dec, nullptr);
    decryptor.Put(ciphertext.data(), ciphertext.size());
    decryptor.MessageEnd();
    std::vector<uint8_t> out(decryptor.MaxRetrievable());
    decryptor.Get(out.data(), out.size());
    return out;
}

int main(void)
{
    const std::vector<std::vector<uint8_t>> cleartext{
#if !defined(CHUNKED)
        {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
#else
        {0x00},
              {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
                                                              {0x00, 0x00, 0x00, 0x00, 0x00},
                                                                                            {0x00},
                                                                                                  {0x00},
#endif
    };
    const std::vector<uint8_t> key(16);
    const std::vector<uint8_t> iv(8);
    const auto ciphertext = Encrypt(key, iv, cleartext);

    const auto cleartext2 = Decrypt(key, iv, ciphertext);

    for (size_t i = 0; i < cleartext2.size(); i++) {
        printf("%02X ", cleartext2[i]);
    }
    printf("\n");
end:
    return 0;
}

Compile this with and without -DCHUNKED. Both should output:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

But when compiled with -DCHUNKED, it outputs:

00 00 00 00 00 00 00 00 BD DD D9 80 6A 84 CF 2A

Tested on Linux x64, Crypto++ recent master branch.

@noloader
Copy link
Collaborator

noloader commented Jul 7, 2020

OFB mode look broken at the moment. When opening config_asm.h and adding the define CRYPTOPP_DISABLE_ASM, then I get the following for encryption using full blocks and chunks:

$ ./test.exe
2C 69 2F 27 D5 48 04 68 F0 31 EE 33 DB 5F 63 D9

The CRYPTOPP_DISABLE_ASM result is probably correct. And it does not agree with the other two results using AdvancedProcessBlocks for encryption.

The current scorecard is ECB, CBC and CTR - Ok. OFB and probably CFB - Bad. All of the modes use AdvancedProcessBlocks.

@noloader
Copy link
Collaborator

noloader commented Jul 7, 2020

Cleared at Commit 62ee118379f3.

I don't know when I'll have the time to look at this issue. It is low priority since 64-bit block ciphers are not likely to be used nowadays. The 128-bit ciphers are OK.

@noloader noloader closed this as completed Jul 7, 2020
@mouse07410
Copy link
Collaborator

@noloader this commit appears to break my CI. The tests weren't updated?

mouse07410 added a commit to mouse07410/cryptopp that referenced this issue Jul 7, 2020
@noloader
Copy link
Collaborator

noloader commented Jul 7, 2020

@mouse07410,

Yeah, it broke mine, too.

The ECB tests were generated with SIMON and SPECK reference implementation. Whatever is going on is most likely on our side.

Let me take a look.

@noloader
Copy link
Collaborator

noloader commented Jul 7, 2020

@mouse07410,

So it looks like the SIMON64 and SPECK64 keys were still being pre-splatted on the SSE4 path in UncheckedSetKey even though SSE4 was disabled in AdvancedProcessBlocks.

That break was cleared at Commit 84ab41902908.

@mouse07410
Copy link
Collaborator

Thanks!

BTW, you sure you want to drop SSE4 though? I'd probably prefer to live with chunking issues...?

@noloader
Copy link
Collaborator

noloader commented Jul 7, 2020

@mouse07410,

you sure you want to drop SSE4 though? I'd probably prefer to live with chunking issues...?

Yeah, I know what you mean.

I think the library has to be correct before it can be fast. If it is not correct, then it does not matter if it is fast.

mouse07410 added a commit to mouse07410/cryptopp that referenced this issue Jul 7, 2020
@noloader
Copy link
Collaborator

noloader commented Jul 7, 2020

@mouse07410,

I removed the 64-bit AdvancedProcessBlocks, like AdvancedProcessBlocks64_4x1_SSE. The tempates were used by the 64-bit block ciphers, like SIMON64 and SPECK64.

If they are causing bad code then they are a hazard. Other people should not be using them.

I'll add a note about them in the head notes so someone can revert the change if they want the templates.

noloader added a commit that referenced this issue Jul 7, 2020
mouse07410 pushed a commit to mouse07410/cryptopp that referenced this issue Jul 10, 2020
mouse07410 pushed a commit to mouse07410/cryptopp that referenced this issue Jul 10, 2020
mouse07410 pushed a commit to mouse07410/cryptopp that referenced this issue Jul 10, 2020
guidovranken added a commit to guidovranken/cryptofuzz that referenced this issue Sep 22, 2020
This was reported:
weidai11/cryptopp#945
But it is still an issue, and impeding code
coverage in OSS-Fuzz, so I'm disabling this
for now.
@noloader noloader added the Bug label Dec 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants