Sameh Abouelsaad
9dce815daa
- Added basic project structure with workspace and crates: `kvstore`, `vault`, `evm_client`, `cli_app`, `web_app`. - Created initial `Cargo.toml` files for each crate. - Added placeholder implementations for key components. - Included initial documentation files (`README.md`, architecture docs, repo structure). - Included initial implementaion for kvstore crate(async API, backend abstraction, separation of concerns, WASM/native support, testability) - Included native and browser tests for the kvstore crate
74 lines
2.9 KiB
Markdown
74 lines
2.9 KiB
Markdown
# What’s Improved in the New Implementation
|
||
|
||
_and why Encryption and Password Protection should be implemented in the Vault crate_
|
||
|
||
---
|
||
|
||
## 1. Introduction
|
||
|
||
This document compares the old and new designs of the key-value store (kvstore) module, highlights improvements in the new implementation, and explains the architectural decision to move encryption and password protection to the vault crate.
|
||
|
||
---
|
||
|
||
## 2. Improvements in the New Implementation
|
||
|
||
### a. **Async/Await API**
|
||
- All operations are asynchronous, enabling non-blocking I/O.
|
||
- Essential for WASM/browser and scalable server environments.
|
||
|
||
### b. **Backend Abstraction**
|
||
- The `KVStore` trait abstracts over multiple storage backends (native and WASM).
|
||
- Enables cross-platform support and easier testing.
|
||
|
||
### c. **Separation of Concerns**
|
||
- The storage layer (`kvstore`) is now focused solely on key-value persistence.
|
||
- No longer mixes storage with cryptography or user authentication.
|
||
|
||
### d. **WASM and Native Support**
|
||
- Out-of-the-box support for both browser (IndexedDB) and native (sled) environments.
|
||
- Easy to extend with new backends in the future.
|
||
|
||
### e. **Cleaner, More Testable Design**
|
||
- Each layer is independently testable and mockable.
|
||
- Simpler to reason about and maintain.
|
||
|
||
---
|
||
|
||
## 3. Why Encryption and Password Protection Belong in the Vault Crate
|
||
|
||
### a. **Single Responsibility Principle**
|
||
- `kvstore` should only handle storage, not cryptographic operations or user authentication.
|
||
- `vault` is responsible for security: encryption, decryption, password management.
|
||
|
||
### b. **Flexibility and Extensibility**
|
||
- Different applications may require different encryption schemes or policies.
|
||
- By implementing encryption in `vault`, you can easily swap algorithms, add multi-user support, or support new crypto features without touching the storage backend.
|
||
|
||
### c. **Security Best Practices**
|
||
- Keeping cryptography separate from storage reduces the attack surface and risk of subtle bugs.
|
||
- All key material and secrets are encrypted before being handed to the storage layer.
|
||
|
||
### d. **Cross-Platform Consistency**
|
||
- The same vault logic can be used regardless of storage backend (sled, IndexedDB, etc).
|
||
- Ensures consistent encryption and password handling on all platforms.
|
||
|
||
### e. **Easier Upgrades and Auditing**
|
||
- Security code is isolated in one place (`vault`), making it easier to audit and upgrade.
|
||
|
||
---
|
||
|
||
## 4. Summary Table
|
||
|
||
| Layer | Responsibility | Encryption | Passwords | Storage Backend |
|
||
|-----------|------------------------|------------|-----------|----------------|
|
||
| kvstore | Persistence/Storage | ❌ | ❌ | sled, IndexedDB|
|
||
| vault | Security, Key Mgmt | ✅ | ✅ | Uses kvstore |
|
||
|
||
---
|
||
|
||
## 5. Conclusion
|
||
|
||
- The new design is more modular, secure, and maintainable.
|
||
- Encryption and password logic in `vault` enables strong, flexible security while keeping storage simple and robust.
|
||
|