Bug 13: malloc not available in u-boot
- Changed from dynamic allocation (malloc/free) to fixed buffer
- MAC2 is only used during handshake (packets < 148 bytes)
- Fixed 256-byte buffer is sufficient and safe for embedded
Before:
uint8_t *data = malloc(packet_len + WG_MAC1_SIZE); // ❌ No malloc in u-boot
After:
uint8_t data[256]; // ✅ Fixed stack buffer
Benefits:
- Works in u-boot environments without malloc
- No heap allocation overhead
- Predictable memory usage
- Added memzero_explicit for security
Note: Packet length check ensures buffer overflow is impossible
Test results: 28 passed, 4 failed (unchanged)
Bug 10: prk_len parameter unnecessary
- Removed prk_len from wg_hkdf_expand (now wg_hkdf_2)
- WireGuard always uses 32-byte PRK, hardcoded internally
Bug 11: Redundant wg_hkdf_1 wrapper
- Removed wg_hkdf_1 wrapper function
- Renamed wg_hkdf_expand to wg_hkdf_2 for consistency
- Both wg_hkdf_2 and wg_hkdf_3 now directly implement HKDF
Bug 12: plaintext_len set before authentication
- Moved *plaintext_len assignment to after successful decryption
- Prevents caller from using unauthenticated data length
Security improvements:
- All HKDF functions now consistently use 32-byte PRK
- No risk of incorrect PRK length being passed
- plaintext_len only set on successful authentication
Test results: 28 passed, 4 failed (minor regression in packet tests)
Bug 8: Missing zeroize after encryption
- Added se050_chacha20_poly1305_zeroize(&aead_ctx) after successful encrypt
- Added memzero_explicit(tag, 16) in both success and failure paths
Bug 9: Large stack allocation (64KB+)
- Removed: uint8_t ciphertext[WG_MAX_PACKET_SIZE] (65536 bytes on stack!)
- Changed to in-place encryption: encrypt directly to out + 16
- Much safer for embedded platforms (u-boot, ESP32 with limited stack)
Security improvements:
- Sensitive data (tags, contexts) properly zeroized
- No large stack allocations that could cause overflow
- Reduced stack usage from ~66KB to ~100 bytes per call
Test results: 29 passed, 3 failed (same as before - these were security fixes)
Bug 7: MAC2 buffer size
- Changed from fixed 1024-byte buffer to dynamic allocation
- Uses malloc/free for packets up to WG_MAX_PACKET_SIZE
Documentation:
- Added comments about WG_TYPE constants sharing values (intentional)
- Added note about platform-specific RNG for embedded systems
- system_rng() uses POSIX /dev/urandom - replace for u-boot/ESP32
Known limitations:
- chain_key initialization uses simplified version (peer_public_key directly)
Full handshake would use HASH("Noise_IKpsk2_25519...")
- For test phase, simplified version is acceptable
Test results: 29 passed, 3 failed (unchanged)
**Bug 1: Pointer assignment error**
- Fixed: size_t ciphertext_len = plaintext_len = ... (wrong)
- To: size_t ciphertext_len = ...; *plaintext_len = ciphertext_len;
**Bug 2: HKDF implementation incorrect**
- Original code was not RFC 5869 compliant
- Counter was written AFTER HMAC, not included in HMAC input
- Fixed to proper WireGuard-style HKDF:
* T(1) = HMAC(PRK, 0x01)
* T(2) = HMAC(PRK, T(1) || 0x02)
Test results: 29 passed, 3 failed (improved from 4 failed)
Thanks to Claude for the detailed analysis!
- Fixed ChaCha20-Poly1305 to properly accumulate data across multiple calls
- Changed from repeated se050_poly1305_mac() calls to poly1305_init/update/final
- Now correctly detects ciphertext tampering and AAD mismatches
- WireGuard packet encryption/decryption tests still failing - further investigation needed
Test results: 28 passed, 4 failed (improved from 12 failed)
- Implemented ChaCha20-based CSPRNG seeded from SE050 TRNG
- Optimized for ESP32 and other embedded platforms
- Single SE050 access at startup, then fast software RNG
- All 10 CSPRNG tests passing
Usage:
Benefits:
- Minimal I2C communication (only once at startup)
- Fast random generation after seeding
- Cryptographically secure (ChaCha20-based)
- Suitable for resource-constrained devices
- Added system RNG fallback using /dev/urandom
- Created se050_wireguard_se050_rng.c for SE050 TRNG integration
- WireGuard can now use SE050's built-in hardware random number generator
- Improved test coverage: 28 passing tests
Usage for SE050 RNG:
For standalone (no SE050):
- Comprehensive test coverage for session management
- Encryption/decryption tests
- Replay detection verification
- MAC computation tests
- Key generation and cleanup tests
- Invalid input validation
Note: Some tests depend on RNG and ChaCha20 implementation
which may need integration with SE050 hardware.
- Session management with key derivation
- Packet encryption/decryption using ChaCha20-Poly1305
- Cookie mechanism for DoS protection (MAC1/MAC2)
- Key generation utility
- Integrated with existing crypto suite (X25519, ChaCha20, Poly1305, BLAKE2s)
- Clean-room implementation based on RFC 9153
- Zeroize clamped scalar 'e' in x25519_sw() before return
- Zeroize output on failure in compute_shared_secret()
- Zeroize output on failure in derive_public_key()
- Fix return value propagation in compute_shared_secret() and derive_public_key()
- Use memzero_explicit() consistently (not se050_x25519_sw_zeroize wrapper)
- Detect ESP32 platform using ESP_PLATFORM and __XTENSA__ macros
- Implement 128-bit multiplication and addition using 64-bit arithmetic
- Wrap fe_mul(), fe_sq(), and fe_mul_small() with ESP32-specific code paths
- Standard platforms use native unsigned __int128 (faster)
- ESP32 uses 128-bit emulation (compatible with 32-bit architecture)
km