Skip to content

ANKASecure Streaming Encryption/Decryption Micro-Benchmark

Overview

This document describes the methodology and scope of the SecureCore Streaming Encryption/Decryption Micro-Benchmark, a performance test suite designed to evaluate the cryptographic efficiency of the AnkaSecure platform for large file encryption using streaming APIs.

The benchmark systematically measures streaming encryption and decryption performance for symmetric and asymmetric algorithms—both classical and post-quantum (PQC)—across very large payload sizes. All outputs use JWE streaming with multipart output, providing empirical evidence of the platform's ability to handle large file encryption with constant memory footprint.

Objectives

The goals of this benchmark are to:

  • Validate the memory efficiency of SecureCore's streaming encryption operations for large files
  • Compare classical and post-quantum algorithm performance at scale
  • Demonstrate constant memory footprint regardless of payload size

Scope of the heap deltas

Every memory figure on this page is a heap measurement and says nothing about disk. The disk-free property — no uploaded part written to a temporary file — is measured separately (512 MiB through -Xmx256m, zero temporary files observed in flight); see Memory & Performance*.

  • Provide evidence of enterprise-grade performance for large file processing

Scope

  • Operations:

    • Streaming encryption that produces multipart output (JWE header + ciphertext stream)
    • Streaming decryption from multipart input

  • Algorithms Tested: All profiles that implement both encrypt and decrypt, including:

    • Symmetric AEAD modes (classical): AES-GCM-{128,192,256}, AES-CCM-{128,192,256}, ChaCha20-Poly1305, Camellia-GCM-{128,192,256}, SEED-GCM-128, SM4-{GCM,CCM}-128, ARIA-{GCM,CCM}-{128,192,256}
    • Asymmetric – Classical: RSA-{2048,3072,4096,6144,8192}, EC (P-256, P-384, P-521), OKP (X25519, X448)
    • Asymmetric – Post-Quantum KEMs: ML-KEM-{512,768,1024}, FRODO-{640,976,1344}, HQC-{128,192,256}, BIKE-{128,192,256}, SABER, NTRU, NTRUPRIME, Classic McEliece

  • Payload Sizes: Very large payloads optimized for streaming:

    • 5 MiB (5,242,880 bytes)
    • 10 MiB (10,485,760 bytes)
    • 50 MiB (52,428,800 bytes)
    • 100 MiB (104,857,600 bytes)

  • Iteration Strategy:

    • Warm-up iterations: 5 (configurable via sc.perf.warmup)
    • Measurement iterations: 10 (configurable via sc.perf.measurements)

  • Expected Measurements: 200 (50 algorithms × 4 large payload sizes)

Algorithm Taxonomy

Symmetric (classical AEAD encryption modes):

  • AES-GCM-128/192/256
  • AES-CCM-128/192/256
  • ARIA-GCM-128/192/256
  • ARIA-CCM-128/192/256
  • ChaCha20-Poly1305
  • Camellia-GCM-128/192/256
  • SEED-GCM-128
  • SM4-GCM-128, SM4-CCM-128

Asymmetric – Classical:

  • RSA-2048, RSA-3072, RSA-4096, RSA-6144, RSA-8192
  • EC: P-256, P-384, P-521
  • OKP: X25519, X448

Asymmetric – Post-Quantum KEMs:

  • ML-KEM-512, ML-KEM-768, ML-KEM-1024
  • FRODO-976, FRODO-1344
  • HQC-128, HQC-192, HQC-256
  • BIKE-128, BIKE-192, BIKE-256
  • SABER: LIGHTSABER-128, SABER-192, FIRESABER-256
  • NTRU-701, NTRU-1373
  • NTRUPRIME-761, NTRUPRIME-857
  • Classic McEliece variants

How It Works

🔁 Iteration Process

  1. Key Generation: A fresh key is generated for each algorithm
  2. Warm-up Loop: Multiple encrypt/decrypt streaming operations stabilize JIT
  3. Measurement Loop: Metrics collected per iteration:
    • Wall-clock time for encryption and decryption (milliseconds)
    • Thread-level CPU time for encryption and decryption (milliseconds)
    • Heap memory delta during encryption and decryption (KiB)
  4. Validation: Decrypted stream verified against original input

🌊 Streaming Process

Encryption (streaming output):

  1. Read plaintext from InputStream (chunked processing)
  2. Perform encryption in chunks (constant memory)
  3. Write JWE header callback (contains algorithm metadata)
  4. Stream ciphertext to OutputStream
  5. Append authentication tag

Decryption (streaming input):

  1. Parse JWE header (algorithm metadata)
  2. Read ciphertext from InputStream (chunked processing)
  3. Decrypt in chunks (constant memory)
  4. Stream plaintext to OutputStream
  5. Verify authentication tag

🧠 Memory Efficiency

Key advantage of streaming: Memory footprint remains constant regardless of payload size (typically <100 MiB heap even for 100 MiB payloads).

Metrics Reported

Metric Description Units
KTY Key type (oct, EC, OKP, RSA, etc.) String
ALG Algorithm name String
BYTES Payload size in bytes Integer
ENC Median wall-clock time for encryption Milliseconds
DEC Median wall-clock time for decryption Milliseconds
CPU-E Median thread CPU time for encryption Milliseconds
CPU-D Median thread CPU time for decryption Milliseconds
MEM-E Median heap delta for encryption Kibibytes
MEM-D Median heap delta for decryption Kibibytes

Execution Notes

  • Streaming APIs process data in chunks (constant memory footprint)
  • Test is implemented using JUnit 5 with @ParameterizedTest
  • All runs are sequential (@Execution(SAME_THREAD))
  • Thread CPU-time measurement is required; test skipped if unavailable
  • Expected CSV file: benchmark_stream_enc_YYYYMMDD_HHMMSS.csv

Benchmark Results

Execution Time Notice

This benchmark has not been executed yet due to its extensive runtime requirements.

Estimated execution time: ~50-80 hours with default settings (5 warm-up + 10 measurement iterations)

Reason for delay:

  • 50 algorithms × 4 large payload sizes (5-100 MiB) × 15 iterations = 3,000 operations
  • Each operation processes up to 100 MiB of data
  • Total data processed: ~300 GB (3,000 operations × ~100 MiB average)
  • Sequential execution required for accurate measurements

Status: Pending execution in dedicated benchmark run

Alternative: For immediate performance validation, see:

Expected Performance Characteristics

Based on extrapolation from compact encryption and streaming signature benchmarks:

🎯 Projected Performance

Small streaming payloads (5-10 MiB):

  • Symmetric AEAD (AES-GCM, ChaCha20): 50-200ms encryption/decryption
  • Classical asymmetric (X25519, P-256): 100-300ms encryption/decryption
  • PQC KEMs (ML-KEM-768): 150-400ms encryption/decryption

Large streaming payloads (50-100 MiB):

  • Symmetric AEAD: 500-2000ms encryption/decryption
  • Classical asymmetric: 1000-3000ms encryption/decryption
  • PQC KEMs: 1500-4000ms encryption/decryption

📊 Memory Efficiency

Expected heap deltas (constant regardless of payload size):

  • Symmetric algorithms: <10 MiB heap delta
  • Classical asymmetric: <50 MiB heap delta
  • PQC algorithms: <100 MiB heap delta (larger keys)

Key insight: Streaming maintains constant memory footprint—100 MiB payload consumes similar heap as 10 MiB payload.

Test Execution

Running the Benchmark

Default settings (5 warm-up, 10 measurement iterations):

cd ankasecure-core-api
mvn test -Dtest=SCPerformanceEnhancedStreamingEncryptionTest

Reduced iterations for faster execution (2 warm-up, 3 measurement):

mvn test -Dtest=SCPerformanceEnhancedStreamingEncryptionTest \
  -Dsc.perf.warmup=2 \
  -Dsc.perf.measurements=3

Expected runtime:

  • Default settings: ~50-80 hours
  • Reduced settings (2+3): ~15-25 hours

Output Location

CSV file will be exported to:

/tmp/sc_bench_<random>/benchmark_stream_enc_YYYYMMDD_HHMMSS.csv

Implementation Details

Test class: SCPerformanceEnhancedStreamingEncryptionTest.java

Location: ankasecure-core-api/src/test/java/co/ankatech/ankasecure/core/controller/

Key APIs used:

  • SecureCoreController.encryptStreamJwe() - Streaming JWE encryption
  • SecureCoreController.decryptDetachedJweStream() - Streaming JWE decryption

Thread safety: Single-threaded execution (@Execution(SAME_THREAD))

Lifecycle: Per-class instance (@TestInstance(Lifecycle.PER_CLASS))

Changelog

Date Change Author
2026-01-18 Created streaming encryption performance benchmark documentation ANKASecure Performance Team
2026-01-18 Benchmark execution pending due to runtime constraints ANKASecure Performance Team
* restricted content — see higher-tier documentation