-
Notifications
You must be signed in to change notification settings - Fork 0
Storage Encryption Subsystem
SolaceCore provides a robust mechanism for encrypting data at rest within its storage module. This subsystem, located in the io.github.solaceharmony.core.storage.encryption package in jvmMain, ensures the confidentiality and integrity of stored values and their metadata.
This interface defines the fundamental contract for encryption and decryption operations, allowing for different cryptographic algorithms to be used.
- Purpose: To abstract the specific encryption algorithm, enabling pluggable encryption strategies.
-
Key Methods:
-
fun encrypt(data: ByteArray): ByteArray: Takes raw byte data and returns its encrypted form. -
fun decrypt(data: ByteArray): ByteArray: Takes encrypted byte data and returns its decrypted (original) form.
-
A concrete implementation of EncryptionStrategy utilizing the Advanced Encryption Standard (AES).
-
Algorithm: Employs AES in Galois/Counter Mode (GCM) with no padding (
AES/GCM/NoPadding). GCM provides both encryption and authentication (AEAD - Authenticated Encryption with Associated Data). -
Key Management:
- Constructor:
AESEncryptionStrategy(private val key: SecretKey = generateKey()). It can accept ajavax.crypto.SecretKeyor generate a 256-bit AES key by default. - Companion object provides utilities:
generateKey(),createKeyFromBytes(keyBytes: ByteArray), andcreateKeyFromBase64(keyBase64: String).
- Constructor:
-
Encryption Process (
encrypt()):- Generates a random 12-byte Initialization Vector (IV) required for GCM mode.
- Initializes an AES cipher for encryption using the provided key, the generated IV, and a GCM tag length of 128 bits.
- Encrypts the input data.
- Returns a byte array containing the IV prepended to the ciphertext (
IV + Ciphertext).
-
Decryption Process (
decrypt()):- Extracts the 12-byte IV from the beginning of the input data.
- Initializes the AES cipher for decryption using the key, the extracted IV, and the 128-bit GCM tag length.
- Decrypts the remaining portion of the input data (the ciphertext).
- GCM mode inherently verifies the authenticity tag during decryption, throwing an exception if the data has been tampered with or the key/IV is incorrect.
A decorator class that wraps an existing Storage implementation to provide transparent encryption and decryption of stored data.
-
Implements:
Storage<K, V>. -
Constructor:
EncryptedStorage(storage: Storage<K, ByteArray>, encryptionStrategy: EncryptionStrategy, valueSerializer: (V) -> String, valueDeserializer: (String) -> V)-
storage: Storage<K, ByteArray>: The crucial point here is that the underlying storage must be capable of storingByteArrayvalues, as the encrypted content is a byte array. -
encryptionStrategy: EncryptionStrategy: The strategy used for cryptographic operations (e.g., an instance ofAESEncryptionStrategy). -
valueSerializer: (V) -> String: A lambda function to serialize the original value of typeVinto a JSON string before it's encrypted. Defaults to a generic JSON serialization. -
valueDeserializer: (String) -> V: A lambda function to deserialize a JSON string (obtained after decryption) back into an object of typeV. Defaults to a generic JSON deserialization.
-
-
Operation:
-
store(key, value, metadata):- The
value(typeV) is serialized to a JSON string usingvalueSerializer. - The
metadata(typeMap<String, Any>) is serialized to a JSON string. - These two JSON strings are combined into a single JSON object structure (e.g.,
{"value": "...", "metadata": "..."}). - This combined JSON string is converted to a
ByteArray. - The byte array is encrypted using
encryptionStrategy.encrypt(). - The resulting encrypted
ByteArrayis stored in the underlyingstorageinstance (which is of typeStorage<K, ByteArray>).
- The
-
retrieve(key):- Retrieves the encrypted
ByteArrayfrom the underlyingstorage. - Decrypts it using
encryptionStrategy.decrypt(). - Converts the decrypted byte array back to the combined JSON string.
- Parses this JSON to extract the original value's JSON string and the metadata's JSON string.
- Deserializes the value's JSON string back to type
VusingvalueDeserializer. - Deserializes the metadata's JSON string back to
Map<String, Any>. - Returns the deserialized
valueandmetadata.
- Retrieves the encrypted
- Other methods like
listKeys(),delete(), andexists()primarily delegate to the underlying storage, as keys themselves are not encrypted by this wrapper.updateMetadatainvolves a decrypt-update-encrypt cycle.
-
-
Thread Safety: Uses separate
Mutexinstances forstore,retrieve, andupdateMetadataoperations to manage concurrent access, though cryptographic operations and JSON serialization/deserialization are often performed outside these specific storage locks.
classDiagram
direction LR
package "io.github.solaceharmony.core.storage" {
interface "Storage<K, V_OUT>" { <<Interface>> }
}
package "io.github.solaceharmony.core.storage.encryption" {
interface EncryptionStrategy {
<<Interface>>
+encrypt(data: ByteArray): ByteArray
+decrypt(data: ByteArray): ByteArray
}
class AESEncryptionStrategy {
-key: SecretKey
+AESEncryptionStrategy(key: SecretKey)
+encrypt(data: ByteArray): ByteArray
+decrypt(data: ByteArray): ByteArray
}
EncryptionStrategy <|-- AESEncryptionStrategy
class "EncryptedStorage<K, V_APP>" {
-storage: Storage<K, ByteArray> // Underlying storage takes byte arrays
-encryptionStrategy: EncryptionStrategy
-valueSerializer: (V_APP) -> String
-valueDeserializer: (String) -> V_APP
+store(key: K, value: V_APP, metadata: Map): Boolean
+retrieve(key: K): Pair<V_APP, Map>?
}
"Storage<K, V_APP>" <|-- "EncryptedStorage<K, V_APP>"
"EncryptedStorage" o-- "Storage" : decorates (specifically Storage<K, ByteArray>)
"EncryptedStorage" o-- EncryptionStrategy : uses
}
note for "EncryptedStorage" "V_APP is the application-level value type.\nInternally, it's serialized to JSON String, then to ByteArray, then encrypted."
This encryption layer provides a robust mechanism for securing sensitive data within the storage system, ensuring that both values and their metadata are protected.
SolaceCore SSOT wiki · published from wiki/ by .github/workflows/publish-wiki.yml · edit the source in the repo, not the wiki.
Orientation
- Architectural Deep Dive
- Architecture Overview
- Design vs Implementation
- Framework Actor System
- Framework Architectural Vision
- Framework Concurrency and Communication
- Framework Data Storage and Management
- Framework Deployment and Containerization
- Framework Development Roadmap
- Framework Hot-Pluggable System
- Framework Implementation Status
- Framework Observability and Monitoring
- Framework Port System
- Framework System Architecture
- Framework Workflow Management
- Project Status
- Project Status Report
- Quick Status
- Solace Core Framework Architecture
- SolaceCore Architecture Overview
- Vision & Solace AI
Runtime
- Actor Builder
- Actor Communication Sequence Diagram
- Actor Core Definitions
- Actor Graph View
- Actor Metrics
- Actor Module Architecture
- Actor Queue Hibernation and Correlation
- Actor Roadmap
- Actor State Recovery Subsystem
- Actor State Serialization Subsystem
- Actor Supervision Module
- Actor System Architecture
- Actor System Class Diagram
- Actor Usage Examples
- Compose App Features
- JVM Scripting Implementations
- Kernel & Ports
- Kernel Channel System
- Kernel Future Enhancements
- Kernel Module Architecture
- Kernel Port Implementations and Exceptions
- Kernel Port Usage Example
- Kernel Testing Strategy
- Lifecycle Class Diagram
- Lifecycle Management Architecture
- Pipeline DSL
- Real-Time UI Implementation
- Scripting Module Architecture
- Scripting Module Design
- Scripting Supporting Components
- Shared Memory
- Storage & Persistence
- Storage Abstractions Architecture
- Storage Caching Subsystem
- Storage Checklist
- Storage Compression Subsystem
- Storage Core Interfaces
- Storage Encryption Subsystem
- Storage File-Based Architecture
- Storage File-Based Implementations
- Storage In-Memory Architecture
- Storage In-Memory Implementations
- Storage JVM Serialization Utilities
- Storage Module Architecture
- Storage Serialization Compression Encryption
- Storage Specialized Interfaces Architecture
- Storage Status and Future Plans
- Storage Testing
- Storage Thread Safety Guide
- Storage Thread Safety and Deadlock Prevention
- Storage Transactions
- Storage Usage Examples
- Supervisor and Hot Swap
- SupervisorActor
- System Architecture Diagram
- Workflow Management Architecture
- Workflow Management Design Concept
- Workflow Orchestration
Solace AI
- Confusion Corrector
- Inference Cube
- Inference Cube Technical Architecture
- Long-Term Memory
- MCP and Tool Format
- Memory & Reflection
- Memory Compression
- Memory Feature Overview
- Memory Retrieval
- Mood & Emotional Model
- Mood Module Implementation
- Mouth Tool Technical Spec
- Multimodal Nudging
- Perception Actors
- Provider Specs
- Reflection Memory
- Solace AI Overview
- Supervisor AI
- Supervisor Emotional Model Integration
- Time Actor
- Voice & Mouth Tool
- Working Memory
- Zoom Level Technical Spec
- Zoom Levels
Reference
- Advanced Workflow Example
- Basic Actor Usage
- Build System and Dependencies
- Development Tooling and Practices
- Documentation Catalog
- Documentation Index
- Feature Index
- Glossary
- How the Wiki Publishes
- JVM Utilities
- Kotlin Implementation Details
- Kotlin-Aligned Architecture Overview
- Kotlin-Aligned Contributing
- Kotlin-Aligned Core Architectural Principles
- Kotlin-Aligned Daily Development Workflow
- Kotlin-Aligned Development Examples
- Kotlin-Aligned Development Workflow
- Kotlin-Aligned Documentation
- Kotlin-Aligned Implementation Status
- Kotlin-Aligned Key Concepts
- Kotlin-Aligned Known Issues
- Kotlin-Aligned Quick Start
- Kotlin-Aligned Running the System
- Kotlin-Aligned System Architecture
- LangChain Actor Code Changes
- LangChain Actor Usage Improvements
- LangChain ActorInterface Code Changes
- LangChain Best Practices
- LangChain Bugs
- LangChain Chain Implementation
- LangChain Code Changes
- LangChain Code Changes Rollout and Impact
- LangChain Configuration Management Improvements
- LangChain Configuration Recommendations
- LangChain Core Architecture Recommendations
- LangChain Directory Structure Changes
- LangChain Documentation Improvements
- LangChain Dynamic Wiring Rollout Notes
- LangChain Fix Proposal
- LangChain Implementation Priorities
- LangChain Lifecycle Management Improvements
- LangChain Memory Integration Recommendations
- LangChain Metrics and Observability Recommendations
- LangChain Migration Strategy
- LangChain New Files Needed
- LangChain New Packages to Add
- LangChain Package-by-Package Improvements
- LangChain Patterns
- LangChain Port Code Changes
- LangChain Port System Recommendations
- LangChain Port Usability Improvements
- LangChain Prompt Management Recommendations
- LangChain Recommendations
- LangChain Recommendations Rollout Plan
- LangChain Required Interface Changes
- LangChain Testing Changes
- LangChain Testing Improvements
- LangChain Testing Recommendations
- LangChain Tool Integration Recommendations
- LangChain Type-Safe Dynamic Wiring
- LangChain Type-Safe Dynamic Wiring System
- LangChain Usage Design Improvements
- Master Checklist
- Roadmap
- Roadmap Issues
- Roadmap Phase 1 Stability and Testing
- Roadmap Phase 2 Production Infrastructure
- Roadmap Phase 3 Documentation and Developer Experience
- Roadmap Phase 4 Graph Database Integration
- Roadmap Phase 5 Security Framework
- Roadmap Phase 6 Distributed System
- Roadmap Phase 7 Advanced Features
- Roadmap Phase 8 Ecosystem Development
- Roadmap Timeline and Success Metrics
- Setup Instructions
- Sketch Architecture
- Status Documentation
- Task 1 Core Tests
- Task 2 Connection Wiring
- Task 3 Concurrency Issues
- Task 4 Dynamic Registration
- Task 5 Integration Tests
- Task 6 Deadlock Detection
- Task Documentation
- Test Coverage Checklist
- Testing Strategy