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

fix Testing Ascon-128 encryption FAIL | File: D:\LibAscon-master\tst\test_aead128_dec.c:343 | Test case: test_decrypt_offline | Ctr: 1024 #1

Open
BreezyEvening opened this issue Jun 29, 2023 · 3 comments
Assignees

Comments

@BreezyEvening
Copy link

BreezyEvening commented Jun 29, 2023

EDITED by TheMatjaz on 2023-07-26 for formatting clarity.

When I execute offline testing cases of test_encrypt_offline in the test_aead128_encryption, the 1024th test case fails every time. I discovered that once the length of the _CT field is greater than 46, this problem will occur. I located this problem and found vecs_aead_next in the test_encrypt_offline, after executing fscan_ciphertext, the first two bytes of testcase.key will be overwritten to 0, causing the key to be modified, resulting in an error in the generated ciphertext. This issue is due to vecs_aead_t. The length of the ciphertext field in the structure vecs_aead_t is 48. Once it overflows, it will overwrite the next field (key), causing this error.

To address this issue from the root cause, this modification method is to fix fsca_variable_hexbytes, so the bytes are modified by not immediately filling the read ciphertext into bytes after fscanf, but by first caching the read 1-byte ciphertext and ensuring that the last byte of the ciphertext is read before writing the data to bytes.

Source original is:

static vecs_err_t fscan_variable_hexbytes(FILE* const handle,
                                          uint8_t* bytes,
                                          size_t* amount)
{
    size_t i = 0;
    while (1)
    {
        if (i >= VECS_MAX_HEXBYTES_LEN)
        {
            return VECS_FORMAT_TOO_LARGE_HEXBYTES;
        }
        const int bytes_read = fscanf(handle, " %2hhx ", bytes++);		
		
        if (bytes_read != 1)
        {
            break;
        }
        i++;
    }
    *amount = i;
    return VECS_OK;
}

Source after fix is:

static vecs_err_t fscan_variable_hexbytes(FILE* const handle,
                                          uint8_t* bytes,
                                          size_t* amount)
{
    size_t i = 0;
    uint8_t bytes_t;
    while (1)
    {
        if (i >= VECS_MAX_HEXBYTES_LEN)
        {
            return VECS_FORMAT_TOO_LARGE_HEXBYTES;
        }
        const int bytes_read = fscanf(handle, " %2hhx ", &bytes_t);		
		
        if (bytes_read != 1)
        {
            break;
        }
	*bytes++ = bytes_t;
        i++;
    }
    *amount = i;
    return VECS_OK;
}
@TheMatjaz TheMatjaz self-assigned this Jun 30, 2023
@TheMatjaz
Copy link
Owner

TheMatjaz commented Jun 30, 2023

Hi @BreezyEvening. Thanks for submitting the bug report. With a quick check I'm unable to reproduce this. All testcases are passing on my side and so are on the CI pipeline on the master branch on 3 OS types. The develop branch is currently experimental (and I have little time to work on it).

A few questions before I can start digging deeper:

  1. Can you please reformat your question? The markdown rendering is barely readable, especially the code blocks and the underscore/italics in the first paragraph.
  2. Which version (tag or commit) of the library are you using?
  3. Where does the testcase fail exactly? (line number)
  4. Is this the only failing testcase?

With this info I might know enough to start debugging. I cannot promise anything, I am short on time at the moment.

@BreezyEvening
Copy link
Author

Hi @BreezyEvening. Thanks for submitting the bug report. With a quick check I'm unable to reproduce this. All testcases are passing on my side and so are on the CI pipeline on the master branch on 3 OS types. The develop branch is currently experimental (and I have little time to work on it).

A few questions before I can start digging deeper:

  1. Can you please reformat your question? The markdown rendering is barely readable, especially the code blocks and the underscore/italics in the first paragraph.
  2. Which version (tag or commit) of the library are you using?
  3. Where does the testcase fail exactly? (line number)
  4. Is this the only failing testcase?

With this info I might know enough to start debugging. I cannot promise anything, I am short on time at the moment.

When I execute test_encrypt_offline in test_aead128_enc.c,the 1024th test case fails every time(test case is in aead128.txt, _Count = 1024). While this process read testcase.ciphertext from aead128.txt into structure vecs_aead_t::ciphertext, the function fscan_variable_hexbytes(in vectors.c) will overwrite the next field(vecs_aead_t::key) causing this error.
The library version is [1.2.1] - 2022-04-30.
This is the only failing testcase.
Testcase is fail in _Count = 1024(aead128.txt, using function test_encrypt_offline).

original source code:
static vecs_err_t fscan_variable_hexbytes(FILE* const handle,
uint8_t* bytes,
size_t* amount)
{
size_t i = 0;
while (1)
{
if (i >= VECS_MAX_HEXBYTES_LEN)
{
return VECS_FORMAT_TOO_LARGE_HEXBYTES;
}
const int bytes_read = fscanf(handle, " %2hhx ", bytes++);

if (bytes_read != 1)
{
    break;
}
i++;

}
*amount = i;
return VECS_OK;
}

after my fix, this test case(_Count = 1024) is OK.

static vecs_err_t fscan_variable_hexbytes(FILE* const handle,
uint8_t* bytes,
size_t* amount)
{
size_t i = 0;
uint8_t bytes_t;
while (1)
{
if (i >= VECS_MAX_HEXBYTES_LEN)
{
return VECS_FORMAT_TOO_LARGE_HEXBYTES;
}
const int bytes_read = fscanf(handle, " %2hhx ", &bytes_t);

if (bytes_read != 1)
{
    break;
}
*bytes++ = bytes_t;
i++;

}
*amount = i;
return VECS_OK;
}

@TheMatjaz
Copy link
Owner

Hi @BreezyEvening. Thanks for the additional info. I'm still unable to reproduce the bug. On my side the encryption works as expected with and without your fix. I'll need some more time to find out what is going on.

Can you please also provide the following?

  • your OS and version
  • your compiler and toolchain and their versions (e.g. GCC, Clang, MSVC, ...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants