encryption

25 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Don't perform encryption in client-side code

Use TLS/SSL and encrypt on the server. Do not perform encryption in client-side code.

Debug build compiler flags for GCC

For GCC debug builds, use the compiler flags: -O0 -g3 -ggdb. -O0 turns off optimizations, -g3 ensures maximum debug information including symbolic constants and #defines, and -ggdb includes GDB extensions. Additionally define DEBUG and ensure NDEBUG is not defined. Use -fno-omit-frame-pointer to ensure frame pointers exist for easier stack trace decoding. Debug builds are not shipped so symbols can remain in the executable without performance penalty.

Release build compiler flags for GCC

For GCC release builds, use compiler flags: -On -g2 where -On is -O2, -Os, or similar for optimization level, and -g2 ensures debugging information is created. Debug information should be stripped and retained separately for symbolication of crash reports. Define NDEBUG and ensure DEBUG is not defined. Release builds should also consider -mfunction-return=thunk and -mindirect-branch=thunk as Retpoline mitigations against Spectre and Meltdown speculative execution vulnerabilities.

Test build preprocessor defines for GCC

For GCC test builds using configuration CFLAGS and CXXFLAGS, include: -Dprotected=public -Dprivate=public. Also change __attribute__((visibility("hidden"))) to __attribute__((visibility("default"))). Use -O2 optimization with debug symbols -g2 -ggdb. This allows testing of private interfaces and internal functions which is necessary for comprehensive security testing despite object-oriented principles.

Windows MSVC debug and release build optimizations

For Visual Studio/MSVC: use /Od for debug builds and /Ox, /O2, or /Os for release builds. These are the compiler optimization flags for Visual Studio equivalent to GCC's -O flags.

NDEBUG and DEBUG configuration macros

Use two explicit, mutually exclusive configuration macros: NDEBUG for release builds and DEBUG for debug builds. Both defined simultaneously should trigger a compilation error. If neither is defined, default to release configuration. Vendors and libraries (Carnegie Mellon Mach uses DEBUG, Microsoft CRT uses _DEBUG, Wind River uses DEBUG_MODE) use DEBUG-style macros, so explicit DEBUG macro aids integration. NDEBUG is the only macro recognized by the C/C++ Committees and POSIX, while DEBUG provides explicit debug configuration.

Custom ASSERT implementation with SIGTRAP for debug builds

Implement a custom ASSERT macro that raises SIGTRAP instead of calling abort() when assertions fail during debugging. For ESAPI C++ on Unix/Linux: when ESAPI_BUILD_DEBUG is defined, ASSERT prints assertion details to stderr and raises SIGTRAP. On Windows, use standard assert(). Outside debug builds, ASSERT evaluates to void. Install a SIGTRAP handler at program startup with sigaction() to handle the signal. This enables self-debugging programs while allowing continued execution during negative tests rather than terminating. Live production code must always define NDEBUG to disable assertions and prevent auto-termination.

GCC compiler warning flags for secure C code

Use GCC C compiler warning flags: -Wall, -Wextra, -Wconversion, -Wformat=2, -Wformat-security, -Wstrict-overflow (GCC 4.2+), -Wtrampolines (GCC 4.3+), -Wlogical-op (GCC 4.4+), -Wint-conversion (GCC 5.0+), -fstack-protector-all (GCC 4.1+), -fno-strict-overflow, -fwrapv. Suppress spurious warnings selectively with -Wno-unused-parameter and -Wno-type-limits. The flags enable static analysis to catch mistakes like uninitialized variables, signed/unsigned comparison issues, and buffer overflows during compilation.

GCC linker flags for hardened executables

Use GNU LD linker flags for hardened executables: -z,nodlopen (LD 2.10+), -z,nodump (LD 2.10+), -z,noexecstack (LD 2.14+), -z,noexecheap (LD 2.14+), -z,relro (LD 2.15+), -z,now (LD 2.15+), -pie and -fPIE (LD 2.16+). These enable: prevent dlopen() calls, prevent memory dumps, disable code execution on stack, disable code execution on heap, enable read-only relocation table, disable lazy binding, and enable Position Independent Executable (PIE/ASLR). DEP (data execution prevention) must be explicitly enabled via linker flags on Linux as DEP is not the default.

OpenSSL hardening configuration

When configuring OpenSSL as an integrated library, disable insecure features: disable SSLv2 and SSLv3 (both cryptographically broken), disable compression (vulnerable to CRIME attacks), disable dynamic linking if using static linking. Example OpenSSL configure command: Configure darwin64-x86_64-cc -no-hw -no-engine -no-comp -no-shared -no-dso -no-ssl2 -no-ssl3. Use `nm` or `openssl s_client` to verify symbols within OPENSSL_NO_COMP are present if -no-comp was used. Note: may want engines on Ivy Bridge for rdrand instruction via ENGINE_load_rdrand() for cryptographic random number generation.

Additional platform and library preprocessor macros for hardening

Define platform and library-specific hardening macros: _FORTIFY_SOURCE=2 (Linux), _GLIBCXX_DEBUG (libstdc++ debug mode - watch for ABI incompatibilities with pre-compiled libraries), _GLIBCXX_DEBUG_PEDANTIC (libstdc++ strict checking), _STLP_DEBUG (STLport), SQLITE_SECURE_DELETE (SQLite zeroization - required for FIPS 140-2 Level 1 and US Federal). Undefine or reject: _CRT_SECURE_NO_WARNINGS, _SCL_SECURE_NO_WARNINGS, _ATL_SECURE_NO_WARNINGS, STRSAFE_NO_DEPRECATE (Windows), -U_FORTIFY_SOURCE (Linux). Define _N file permissions for SQLite appropriately (default 0644 means world-readable which may be insecure).

Clang compiler flags and -Weverything option

Clang accepts most GCC/Binutil flags and switches. Clang supports -Weverything to enable all warnings (use with care as it produces significant noise). Clang 3.3+ supports -fsanitize=integer and -fsanitize=shift for integer overflow detection (Integer Overflow Checker/IOC functionality). Use -Weverything for production builds and make non-spurious issues a quality gate. Clang's static analyzer capabilities are documented at clang-analyzer.llvm.org.

Visual Studio compiler warning and linker options table

Visual Studio warning options include: /W4 (enable level 4 warnings), /Wall (enable all warnings), /WX (treat warnings as errors), /Wp64 (64-bit portability warnings deprecated in newer versions). Runtime security options: /GS (buffer security check with security cookie - disabled if no stack buffer, optimizations off, or function is naked/inline), /GS- (disable), /Qspeedy (faster but less thorough), /sdl (enable additional security checks), #pragma strict_gs_check(on) for high-risk input parsing. Linker options: /DYNAMICBASE (ASLR), /NXCOMPAT (DEP), /SAFESEH (exception handling). See Microsoft's Protecting Your Code with Visual C++ Defenses for details.

Unused parameter suppression macro in C/C++

To suppress compiler warnings about unused function parameters without turning off warnings: define an UNUSED_PARAMETER(x) macro that expands to ((void)x). This informs the compiler the parameter is intentionally unused, which is common in C++ interface programming and function parameter requirements. Example: #define UNUSED_PARAMETER(x) ((void)x). Use in function signatures like: int main(int argc, char* argv[]) { UNUSED_PARAMETER(argc); UNUSED_PARAMETER(argv); ... }

Safe type conversion from signed to unsigned for comparison

When converting signed to unsigned integers for comparison due to -Wconversion warnings: first perform range validation before casting. C/C++ promotion rules cause signed values to promote to unsigned, making -1 > 1 after promotion. Pattern: assert(signed_value >= 0); if(!(signed_value >= 0)) throw exception; if(static_cast<unsigned>(signed_value) > unsigned_value) { ... }. Never blindly cast signed to unsigned without range testing.

snprintf return value validation for truncation detection

Do not ignore snprintf return values or cast to void. snprintf returns -1 on error or the number of characters that would be written if buffer was large enough. Validate for truncation: int ret = snprintf(buffer, size, format, ...); ASSERT(ret != -1); ASSERT(!(ret >= sizeof(buffer))); if(ret == -1 || ret >= sizeof(buffer)) throw exception. Silent truncations are problematic security issues. Example failure case: snprintf(path, sizeof(path), format, ...); open(path, O_RDWR) may open unintended file if path was silently truncated.

Xcode runtime diagnostics for debugging

In Xcode, enable additional runtime diagnostics through Products > Scheme > Edit > Diagnostics tab: Scribble guards (detect use of freed/uninitialized memory), Edge guards (buffer overflow detection), Malloc guards (heap corruption detection), Zombies (detect use-after-free). These instruments are available for simulator but historically not for device in some Xcode versions. Enable for development/debugging cycle to catch memory errors and object use problems.

Windows runtime hardening with Defender Exploit Guard

Windows Defender Exploit Guard replaces EMET and provides advanced exploit protection features for runtime hardening. Use Process Mitigation Management Tool (ProcessMitigations PowerShell module) to configure exploit mitigation policies via PowerShell and Group Policy. This enables administrators to harden running processes and system-wide exploitation defenses on Windows.

BinScope binary verification for Visual Studio builds

Use BinScope, Microsoft's binary verification tool, to analyze compiled executables and verify they were built in compliance with Microsoft Security Development Lifecycle (SDLC) requirements. BinScope checks that hardening settings specified during compilation and linking were actually applied to the final binary. Download available from Microsoft's BinScope Binary Analyzer page.

Checksec tool for verifying Linux security features

Use Checksec (checksec.sh script by Tobias Klein) to verify that standard Linux OS and PaX security features have been applied to compiled executables. Available at trapkit.de/tools/checksec.html. For hardened projects compiled and linked with security flags, checksec validates that features like DEP, ASLR, and other defenses are present in the final binary.

Build configuration strategy for Debug, Release, and Test

Configure projects with three distinct build configurations: Debug (for development with full instrumentation, no optimizations, full debug symbols), Release (for production with optimizations and minimal debug info), and Test (special case of Release making all interfaces public for testing). Debug uses -O0 -g3, Release uses -On -g2, Test uses -O2 with -Dprivate=public -Dprotected=public. Configuration differences are primarily optimization level and debug level. Test configuration allows testing of private/protected interfaces to ensure reliability.

Makefile override pattern for CFLAGS and LDFLAGS

In Makefiles, use `override` to honor user-supplied command-line flags while enforcing project security flags: override CFLAGS := $(PROJECT_CFLAGS) $(CFLAGS); override CXXFLAGS := $(PROJECT_CXXFLAGS) $(CXXFLAGS); override LDFLAGS := $(PROJECT_LDFLAGS) $(LDFLAGS). This ensures project flags are applied first, then user flags follow with higher precedence. Without override, Make may ignore user options entirely, defeating security hardening passed on command line.

Verify GCC and LD versions in Makefile for feature availability

Use Makefile patterns to detect compiler and linker versions before applying version-specific flags. Example pattern: GCC41_OR_LATER = $(shell $(CXX) -v 2>&1 | $(EGREP) -i -c '^gcc version (4\.[1-9]|[5-9])'); then conditionally apply flags like: ifeq ($(GCC41_OR_LATER),1) MY_CC_FLAGS += -fstack-protector-all; endif. This ensures makefile adapts to available toolchain features rather than failing on systems without specific compiler capabilities.

Code must be correct; security is secondary to correctness

Foundational principle from Dr. Jon Bentley and Dr. Gary McGraw: 'Code must be correct. It should be secure. It can be efficient.' Dr. Gary McGraw states security is an emergent property of the entire system and relies on building and integrating all parts properly. Security through toolchain hardening is one piece of an overall engineering strategy, complementing static analysis, dynamic analysis, secure coding practices, negative test suites, and tools like Valgrind and Helgrind. A secure toolchain is not a silver bullet.

Data leakage - always use HTTPS for communications

Extensions must always use HTTPS for all external communications to prevent data interception. Limit data collection and be transparent by clearly stating what data is collected in a Privacy Policy. Implement user consent mechanisms before collecting or sending any personal data.

Give your agent this brain