MASC-256

MASC-256 (Memory Accumulator Stack Cipher 256-bit) is an experimental authenticated stream-cipher research project. Version 2 keeps the original 256-bit accumulator and memory-mixing design, then wraps it in a safer API that is harder to misuse.

Security status:

• Research cipher, not production-approved cryptography.
• Public review is required before serious use.
• For production systems today, use AES-256-GCM or ChaCha20-Poly1305 from a mature cryptographic library.

What v2 Improves

• Authenticated encryption API: masc256_seal and masc256_open.
• Output format: nonce || ciphertext || tag.
• 128-bit random nonce generated by the library for normal encryption.
• HKDF-style key separation using HMAC-SHA256.
• Encrypt-then-MAC authentication with a 256-bit HMAC-SHA256 tag.
• Associated data (AAD) support.
• No legacy unauthenticated encrypt/decrypt functions in the public header.
• Deterministic test vector coverage for ciphertext and tag stability.

Architecture

The internal state is a 256-bit accumulator:

ACC = (a, b, c, d)
       64  64  64  64 bits

The public v2 API derives independent subkeys from the caller's key and a per-message nonce:

master key + nonce
        |
        v
HKDF/HMAC-SHA256
        |
        +-- stream key -> MASC accumulator keystream
        |
        +-- MAC key    -> HMAC-SHA256 tag over nonce, AAD, ciphertext

masc256_open verifies the tag before returning plaintext. If ciphertext, nonce, AAD, or tag changes, it returns MASC256_ERR_AUTH.

Recommended API

Use masc256_seal and masc256_open. They store the nonce beside the ciphertext and tag, reducing the chance of nonce reuse mistakes.

#include "acc_crypto.h"

uint8_t key[] = "UltraEncryptedKey";
uint8_t aad[] = "file header or protocol metadata";
uint8_t plaintext[] = "Advanced Memory Encryption System";

uint8_t sealed[(sizeof(plaintext) - 1U) + MASC256_OVERHEAD];
uint8_t opened[sizeof(plaintext)];
size_t sealed_len = 0;
size_t opened_len = 0;

int rc = masc256_seal(sealed, sizeof(sealed), &sealed_len,
                      plaintext, strlen((char *)plaintext),
                      key, strlen((char *)key),
                      aad, strlen((char *)aad));
if(rc != MASC256_OK) {
    /* abort */
}

rc = masc256_open(opened, sizeof(opened), &opened_len,
                  sealed, sealed_len,
                  key, strlen((char *)key),
                  aad, strlen((char *)aad));
if(rc != MASC256_OK) {
    /* authentication failed or input was invalid */
}

The sealed output format is:

16-byte nonce || ciphertext || 32-byte authentication tag

Advanced API

masc256_encrypt and masc256_decrypt are still available for protocols that already manage nonces. They require a fresh unique nonce for every message under the same key.

Rules:

• Never reuse the same key + nonce pair.
• Store or transmit the nonce with the ciphertext.
• Authenticate all protocol metadata through AAD.
• Treat MASC256_ERR_AUTH as a hard failure and discard the output buffer.

Build and Test

Using make:

make all
make run
make test

Using CMake directly:

cmake -B build -S . -DBUILD_TESTING=ON
cmake --build build
ctest --test-dir build --output-on-failure
./build/acc_crypto

On Windows, CMake links bcrypt for secure nonce generation.

Expected demo behavior:

Sealed:   <nonce+ciphertext+tag hex>
Tamper test: rejected
Decrypted: Advanced Memory Encryption System

Open Source Position

Publishing this project as open source is the right direction for cryptography. Closed custom cryptography rarely earns trust. Public code lets researchers review the design, reproduce tests, write independent implementations, and find weaknesses before real users depend on it.

Be precise in public claims:

• Good: "experimental authenticated stream cipher research project."
• Good: "seeking public cryptanalysis and test vectors."
• Bad: "unbreakable."
• Bad: "stronger than AES/SHA-256."
• Bad: "government-ready" or "Bitcoin-ready."

Validation Roadmap

Before claiming production-grade security:

1. Add independent test vectors for SHA-256, HMAC-SHA256, HKDF, and MASC.
2. Run fuzzing for malformed sealed buffers and API misuse.
3. Run keystream statistical tests such as NIST SP 800-22 and PractRand.
4. Write a formal specification independent of this C implementation.
5. Invite public cryptanalysis and document every attack attempt.
6. Commission an independent cryptographic review.

Design References

• RFC 5116: Authenticated Encryption with Associated Data interface.
• RFC 8439: ChaCha20 and Poly1305 AEAD construction.
• RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function.
• NIST FIPS 180-4: Secure Hash Standard.
• NIST FIPS 197: Advanced Encryption Standard.
• NIST SP 800-38D: GCM and GMAC authenticated encryption modes.