Building a Sovereign Cryptography Suite in .NET: 11 Engines, Multi-Jurisdictional Hashes, and Anti-Keylogger Shields

1. 🚀 Introduction & Background

In modern software engineering, data security is often treated as a solved problem through a mono-cultural lens. The vast majority of cryptographic utilities operating on desktop platforms rely exclusively on standard Western primitives, primarily AES and the SHA-2 family. While these algorithms remain robust, contemporary data protection requirements have evolved beyond unipolar trust models. Modern systems frequently demand cross-border compliance, multi-jurisdictional data accessibility, and resilience against systemic cryptographic monoculture.

Claude Shannon’s foundational maxim states that:

"The enemy knows the system. One ought to design systems under the assumption that the enemy will immediately gain full familiarity with them."

In the context of modern endpoint security, this maxim must be extended: we must design cryptographic software under the assumption that the underlying operating system environment itself might be compromised, untrusted, or subject to localized surveillance vectors.

---

🛠️ The Architecture of Speedcrypt 2.0.0.0

This article introduces the architectural design and implementation details of Speedcrypt 2.0.0.0, an advanced, open-source cryptographic suite built for 64-bit Windows architectures running on the .NET Framework 4.8.

Rather than relying on a single federal standard, Speedcrypt implements a deeply decoupled, multi-engine architecture comprising:

• 11 distinct encryption engines
• 7 specialized string processing engines
• 49 password derivation hash functions

Crucially, the suite bridges the gap between disparate global cryptographic frameworks by natively integrating sovereign standards from the Russian Federation (including the GOST-compliant Kuznyechik and Magma ciphers, alongside Streebog 256/512 hashing) and the People's Republic of China (the SM3 hashing standard managed by OSCCA). This approach ensures true multi-jurisdictional compliance and mathematical diversification.

🛡️ Endpoint Vulnerability Mitigation

Furthermore, because cryptographic strength is irrelevant if the keys are intercepted at the user-interface layer, this implementation addresses endpoint vulnerability directly. Throughout this article, we will explore the integration of:

• Anti-Keylogger Shield: Low-level mitigation mechanics.
• Print Screen Obfuscation: Anti-screenshot engineering to thwart host-based screen-scraping malware.

---

2. 🔒 Hardening User Input: Win32 Desktop Isolation and Memory Zeroization

To mitigate the architectural vulnerabilities of user-space input tracking, Speedcrypt 2.0.0.0 bypasses the standard Windows execution desktop. When processing sensitive credentials like the Master Key, the suite implements a strict cryptographic isolation paradigm leveraging native Win32 Desktop Segregation and immediate memory destruction.

🧩 Phase 1: Subsystem Segregation & UI Isolation

The core vulnerability of Windows desktop applications lies in the shared user-space session. Any background malware or commercial keylogger executing within the standard desktop context (Default) can easily monitor keystrokes by placing low-level global hooks via SetWindowsHookEx.

To completely invalidate this attack vector, Speedcrypt dynamically instantiates an independent desktop subsystem. Because Windows isolates desktops via distinct security descriptors, processes running on the standard desktop are physically and architecturally barred from intercepting:

• Window messages
• UI events
• Mouse movements

All of these events are safely contained within the new secure context.
Here is the architectural setup from the original source code:

public void ProtectionMode(dynamic secMasKey, Action callMastKey, dynamic secPasw = null)
{
     // Save handle of current desktop to allow safe reversion later
     IntPtr hOldDesktop = GetThreadDesktop(GetCurrentThreadId());

     // Create a highly isolated desktop subsystem with full generic access rights
     IntPtr hNewDesktop = CreateDesktop(
         "SecureDesktop",
         IntPtr.Zero,
         IntPtr.Zero, 0, (uint)DESKTOP_ACCESS.GENERIC_ALL, IntPtr.Zero
     );

     // Instantly route the user interface execution layer to the secure desktop
     SwitchDesktop(hNewDesktop);

     // Instantiate a volatile char array buffer to bypass immutable string allocations
     char[] MasterkeyBuffer = null;
     CheckBox chkExportPass = null;

     // Execute the input dialogue thread within the newly segregated desktop space
     Task.Factory.StartNew(() =>
     {
         SetThreadDesktop(hNewDesktop);

         // [Form and UI Controls Initialization omitted for brevity]

         // UI Hardening: Neutralize common accessibility and sub-classing vectors
         TextBox txtPassw = new TextBox { PasswordChar = '\u2022' };
         txtPassw.ContextMenuStrip = new ContextMenuStrip(); // Invalidate standard context menu injections
         txtPassw.ShortcutsEnabled = false;                  // Suppress unmanaged control flows
         txtPassw.KeyDown += (s, e) =>
         {
             // Force strict enforcement against clipboard scraping and cross-process message stuffing
             if (e.Control && (e.KeyCode == Keys.C || e.KeyCode == Keys.V || e.KeyCode == Keys.X || e.KeyCode == Keys.A))
                 e.SuppressKeyPress = true;
         };

---

🔍 Technical Analysis of Phase 1

By assigning the password execution thread to hNewDesktop via SetThreadDesktop, the input controls are rendered inside a separate kernel-level object.

Notice the assignment txtPassw.ContextMenuStrip = new ContextMenuStrip(); and the suppression of the control keys: this prevents specialized memory injectors or background automation tools from:

• Simulating paste actions
• Utilizing the Windows API to read the text box handle externally

---

🔄 Phase 2: Volatile Buffer Capture and Deterministic Zeroization

Isolating the user interface is useless if the secret key remains exposed within the application's memory pool. In the .NET Framework, standard System.String objects are immutable. When a user types into a standard string object, the data stays resident in the managed heap indefinitely until the non-deterministic garbage collection sweep occurs. If an attacker performs a physical RAM dump during this window, the plaintext Master Key can be extracted.

Speedcrypt 2.0.0.0 addresses this by minimizing the lifetime of the string instance to mere milliseconds. The data is:

1. Pulled directly into a volatile char[] buffer
2. Committed immediately to the unmanaged memory segments of SecureString
3. Destructively cleared Here is how the destruction lifecycle is enforced in the original implementation:

        // Phase 2 Enforcement: Extracting from volatile control to SecureString
        btnSubmit.Click += (s, e) =>
        {
            // Allocate volatile temporary buffer directly from the control
            MasterkeyBuffer = txtPassw.Text.ToCharArray();

            // Instantly transition to unmanaged cryptographic memory pool
            unsafe
            {
                fixed (char* pChars = MasterkeyBuffer)
                {
                    // SecureString instantiation using the unmanaged pointer
                    secMasKey = new System.Security.SecureString(pChars, MasterkeyBuffer.Length);
                    secMasKey.MakeReadOnly();
                }

                // Deterministic Zeroization: Overwrite the volatile buffer instantly
                for (int i = 0; i < MasterkeyBuffer.Length; i++)
                {
                    MasterkeyBuffer[i] = '\0';
                }
            }

            // Clean up UI state and exit isolated thread loop
            txtPassw.Text = string.Empty;
            Application.ExitThread();
        };

        Application.Run(frmSecureInput);
     });

     // Critical Subsystem Reversion: Safely return the user to the default desktop session
     SwitchDesktop(hOldDesktop);
     CloseDesktop(hNewDesktop);

     // Delegate core execution flow back to the primary cryptographic engines
     callMastKey();
}

🎯 Conclusion

By pairing Win32 subsystem isolation with deterministic memory zeroization, Speedcrypt 2.0.0.0 builds a resilient defense matrix directly at the endpoint layer. It eliminates the reliance on non-deterministic garbage collection for sensitive assets and breaks the global hook vectors exploited by standard user-space keyloggers.

When developing desktop security utilities, moving beyond standard cryptographic primitives into active environmental hardening is no longer optional—it is a baseline architectural requirement.

🌐 Open Source & Source Code Availability

The complete architecture of Speedcrypt 2.0.0.0 is fully transparent and available for peer review. You can download the compiled binaries (including the portable edition) and inspect the original implementation directly from the official repository:

👉 SourceForge Repository Link:
https://sourceforge.net/projects/speedcrypt-file-encryption/files/Speedcrypt/2.0/

📂 Repository File Structure:

• Source Code: Speedcrypt 2.0.0.0 Source Code.zip
• Portable Version: Speedcrypt 2.0.0.0 Portable.zip
• Installer: Speedcrypt Ver 2.0.0.0-Setup.exe

"Cryptography is notoriously difficult to implement, and the only way to know if something was done right is to examine it."
— Bruce Schneier

We highly encourage developers, security researchers, and cryptography enthusiasts to clone the repository, audit the Win32 subsystem bindings, and test the multi-engine implementation against localized memory injection vectors.

---

Written by Mariano Ortu

---

👉 Official Distribution Integrity & PGP Signatures: https://speedcrypt.info
👉 Author's Official Website: https://sicurpas.it

🔮 Coming Up Next: Visual Surveillance Defenses

In our next article, we will deep-dive into the final defensive subsystem of Speedcrypt: Print Screen Obfuscation. We will examine how to actively block host-based screen-scraping malware, unmanaged screen-capture loops, and video-surveillance vectors at the window manager layer. Thank you all!