Walter.Native.Wrapper 2024.9.12.1923

WALTER

Introducing the WALTER Framework: Workable Algorithms for Location-aware Transmission, Encryption Response. Engineered for the demands of modern development, WALTER is a comprehensive suite of NuGet packages optimized for .NET Standard 2.0, 2.1, Core 3.1, and .NET 6, 7, 8, supporting a wide array of platforms including Android, iOS, UNIX, and Windows in both C# and C++ environments. Boasting full AoT support and reflection-free operations, WALTER stands as a benchmark for performance and stability in the software development realm.

WALTER excels in networking, encryption, and secure communication tasks, providing developers with unmatched efficiency and precision, making it an indispensable tool for those prioritizing speed and effective memory management.

About this Nuget Package

This package serves as a critical wrapper for the WALTER suite, designed not for standalone use but to empower the main Walter package with enhanced future-proofing capabilities. By ensuring encrypted data remains secure and accessible for over a decade, this wrapper solidifies the foundation for long-term, resilient applications.

Currently, the package includes binaries for:

• win-x64
• linux-x64
• android-arm64
• ios-x64
• ios-arm64
• osx-x64

Facilitating upgrades across all .NET versions, this package ensures seamless adaptation to future framework evolutions.

Supported Frameworks

This package boasts precompiled binaries for:

• netstandard2.0, netstandard2.1
• net6.0, net7.0, net8.0

Additionally, we offer OS-specific implementations for:

• net8.0-windows
• net8.0-android
• net8.0-ios
• net8.0-maccatalyst
• net8.0-macos

These provisions underscore our commitment to wide-ranging platform support, enabling developers to deploy across diverse environments with confidence.

Cross-Platform Native Libraries

Enhance your application with critical functionalities like advanced encryption through our cross-platform native libraries. Tailored to each operating system, these libraries ensure your project remains robust against the future landscape of quantum computing:

• Windows: {NuGetPackageName}Native.dll
• Linux: {NuGetPackageName}Native.so
• macOS & Apple platforms: {NuGetPackageName}Native.dylib

Integration is streamlined across all deployment strategies—AoT, trimmed binaries, or standard deploys—affirming a cohesive user experience irrespective of the target OS.

Publishing to GetIt

Beyond NuGet, we extend our offerings to Embarcadero's GetIt platform, catering to Delphi developers with a preffered selection for stability and memory safety. Our dedication to producing stable, secure solutions is unwavering, ensuring your applications endure beyond a decade.

Why Delphi?

Choosing Delphi for its superior memory safety and long-livity, especially for high-security and stable applications, aligns with the Department of Defense's endorsement of Delphi as a Memory Safe Language. For an in-depth exploration of memory safety principles, refer to the Department of Defense's guidelines.

Avoiding C/C++

Our preference for Delphi over C/C++ stems from the latter's noted memory management challenges. Endorsed by the Department of Defense for secure and stable application development, Delphi ensures our commitment to long-term application reliability and safety.

Frequency of updates

We place immense value on the trust you place in our binaries, which is why we are committed to an active maintenance schedule for the WALTER Framework. We frequently update the framework to ensure the generated builds remain secure, particularly in response to any updates made to the .NET framework. This includes not only the security vulnerabilities we discover and report ourselves but also those identified and addressed by the broader .NET community. Our proactive approach to updates and security ensures that your use of the WALTER Framework is backed by the latest in security practices, keeping your applications safe in an ever-evolving digital landscape.

WalterNative Interaction

The WalterNative library exposes a comprehensive API through its signed binaries (.dll for Windows, .so for Linux, .dylib for macOS, and libraries within the libs folder for Android). These APIs facilitate secure and efficient operations such as encryption, decryption, HTTP requests, hashing, and logging. Below are the key interaction points, as utilized within our wrapper classes:

These API calls are documented to illustrate how our wrapper classes interact with the native binaries. It's important to note that direct usage of these functions outside our provided wrappers is not the intended use case, as our wrappers are designed to ensure optimal integration and security practices.

By encapsulating complex operations within easy-to-use wrapper functions, we streamline the development process, allowing you to focus on building robust and secure applications without delving into the intricacies of native code interactions.

/* 

The compile-time constants `_fileName` and entry point names (designated as `_encryptBytes`, `_decryptBytes`, etc.) 
are critical for the dynamic linkage of platform-specific native library files and their respective entry points. 
These constants vary by platform to ensure seamless integration and functionality across diverse operating systems. 
By defining these at compile time, we maintain a uniform interface for our .NET code to interact with native libraries, 
regardless of the underlying platform. This approach ensures that our wrapper functions, such as `EncryptBytes`, 
`DecryptBytes`, and others, reliably invoke the correct native operations. Users should rely on the provided 
wrapper methods rather than directly interfacing with the native API, as the wrappers manage platform-specific 
variations and memory management intricacies, offering a stable and efficient integration point.
*/


[LibraryImport(_fileName, EntryPoint = _encryptBytes, StringMarshalling = StringMarshalling.Utf16)]
[return: MarshalAs(UnmanagedType.Bool)]
private static partial bool EncryptBytes(IntPtr handler,
                                        byte[] clearBytes,
                                        int protection,
                                        [MarshalAs(UnmanagedType.LPWStr)] string password,
                                        out IntPtr encryptedBytes,
                                        out int outputSize);

[LibraryImport(_fileName, EntryPoint = _decryptBytes, StringMarshalling = StringMarshalling.Utf16)]
[return: MarshalAs(UnmanagedType.Bool)]
private static partial bool DecryptBytes(IntPtr handler,
                                        byte[] encryptedBytes,
                                        int protection,
                                       [MarshalAs(UnmanagedType.LPWStr)] string password,
                                        out IntPtr clearBytes,
                                        out int outputSize);



[LibraryImport(_fileName, EntryPoint = _httpGet, StringMarshalling = StringMarshalling.Utf16)]
[UnmanagedCallConv(CallConvs = [typeof(System.Runtime.CompilerServices.CallConvStdcall)])]
[return: MarshalAs(UnmanagedType.Bool)]
internal static partial bool HttpGet([MarshalAs(UnmanagedType.LPWStr)] string url
                                , [MarshalAs(UnmanagedType.LPWStr)] string headers
                                , out IntPtr outputData // Use IntPtr to receive the allocated memory
                                , out int outputSize,
                                , out int statusCode
                                , out IntPtr statusText
                                , out int statusTextSize);

[LibraryImport(_fileName, EntryPoint = _httpPost, StringMarshalling = StringMarshalling.Utf16)]
[UnmanagedCallConv(CallConvs = [typeof(System.Runtime.CompilerServices.CallConvStdcall)])]
[return: MarshalAs(UnmanagedType.Bool)]
internal static partial bool HttpPost([MarshalAs(UnmanagedType.LPWStr)] string url
                                    , [MarshalAs(UnmanagedType.LPWStr)] string headers
                                    , [MarshalAs(UnmanagedType.LPWStr)] string json
                                    , out IntPtr outputData // Use IntPtr to receive the allocated memory
                                    , out int outputSize
                                    , out int statusCode
                                    , out IntPtr statusText
                                    , out int statusTextSize);

[LibraryImport(_fileName, EntryPoint = _hashData, StringMarshalling = StringMarshalling.Utf16)]
[UnmanagedCallConv(CallConvs = [typeof(CallConvStdcall)])]
[return: MarshalAs(UnmanagedType.Bool)]
internal static partial bool Encrypt(
                            [MarshalAs(UnmanagedType.LPWStr)] string password,
                            int iterations,
                            [MarshalAs(UnmanagedType.LPWStr)] string inputData,
                            out IntPtr outputData, // Use IntPtr to receive the allocated memory
                            out int outputSize);

[LibraryImport(_fileName, EntryPoint = _unhashData, StringMarshalling = StringMarshalling.Utf16)]
[UnmanagedCallConv(CallConvs = [typeof(CallConvStdcall)])]
[return: MarshalAs(UnmanagedType.Bool)]
internal static partial bool Decrypt(
                            [MarshalAs(UnmanagedType.LPWStr)] string password,
                            int iterations,
                            [MarshalAs(UnmanagedType.LPWStr)] string encryptedData,
                            out IntPtr outputData, // Use IntPtr to receive the allocated memory
                            out int outputSize);


[LibraryImport(_fileName, EntryPoint = _initializeLogger)]
[UnmanagedCallConv(CallConvs = new Type[] { typeof(System.Runtime.CompilerServices.CallConvStdcall) })]
protected internal static partial void InitializeLogger([MarshalAs(UnmanagedType.LPWStr)] string fileName);


[LibraryImport(_fileName, EntryPoint = _freeMemory)]
[UnmanagedCallConv(CallConvs = new Type[] { typeof(System.Runtime.CompilerServices.CallConvStdcall) })]
protected internal static partial void FreeMemory(ref IntPtr ptr);

Use the wrapper not the above code

We strongly advise against direct interaction with the native API. This caution stems from the possibility of API changes as we adapt to different platforms or update versions of existing platforms. However, our wrappers are designed to absorb these changes, ensuring that their signatures remain stable and consistent across updates.

It's crucial to recognize that both C# and Delphi are memory-managed languages. A thorough understanding of memory management can be complex, but our wrappers are specifically engineered to handle this aspect efficiently on your behalf, ensuring optimal memory usage and management without requiring direct intervention