feat: implement secure storage unlock with password verification

- Implement SecureStorageManager.unlock(password) that returns boolean
- Add master salt management (16-byte persistent salt)
- Implement PBKDF2 key derivation (100k iterations, SHA-256)
- Add password verification using verification payload
- Encryption key stored only in memory, never persisted
- Returns true for valid passwords, false for invalid passwords
- Add comprehensive security tests (108 tests total, 100% coverage)
- Maintain backward compatibility with existing encrypted data
- Fix ESLint configuration for Jest globals and Web Crypto API types
- Replace 'any' types with 'unknown' for better type safety

Closes #116

Author: winnpxl

.kiro/specs/secure-storage-unlock/.config.kiro

@@ -0,0 +1 @@
+{"specId": "9a008c19-7adb-4bf7-89f3-f671527e11df", "workflowType": "requirements-first", "specType": "feature"}

.kiro/specs/secure-storage-unlock/design.md

@@ -0,0 +1,382 @@
+# Design Document: Secure Storage Unlock
+
+## Overview
+
+This design enhances the SecureStorageManager's unlock mechanism to provide secure password verification without exposing plaintext data on incorrect passwords. The current implementation stores a base PBKDF2 key in memory and uses per-payload salts for encryption, but throws errors when wrong passwords are used during decryption. This design introduces:
+
+1. A persistent master salt for consistent key derivation
+2. A verification payload mechanism for password checking before data access
+3. Boolean return values from unlock() to indicate password correctness
+4. Enhanced security guarantees preventing plaintext exposure
+
+The design maintains backward compatibility with existing encrypted data while adding robust password verification capabilities.
+
+## Architecture
+
+### Current Architecture
+
+The existing SecureStorageManager uses a two-tier key derivation approach:
+- **Base Key**: Derived directly from the password using PBKDF2, stored in memory
+- **Per-Payload Keys**: Derived from the base key using random salts stored with each encrypted payload
+
+```
+Password → PBKDF2 → Base Key (in memory)
+                         ↓
+Base Key + Random Salt → PBKDF2 → AES-GCM Key → Encrypt/Decrypt Payload
+```
+
+### Enhanced Architecture
+
+The new architecture introduces a master salt and verification payload:
+
+```
+First Run:
+  Password + Master Salt → PBKDF2 → Encryption Key (in memory)
+                                          ↓
+                                    Create Verification Payload
+                                          ↓
+                                    Store to Storage Adapter
+
+Subsequent Runs:
+  Password + Master Salt → PBKDF2 → Encryption Key (in memory)
+                                          ↓
+                                    Decrypt Verification Payload
+                                          ↓
+                                    Success → return true
+                                    Failure → clear key, return false
+```
+
+### Key Changes
+
+1. **Master Salt Storage**: A single persistent salt (16 bytes) stored under key "master_salt"
+2. **Verification Payload**: A lightweight encrypted payload under key "verification_payload" containing known plaintext
+3. **Encryption Key**: Derived from password + master salt (replaces the base key concept)
+4. **Per-Payload Salts**: Maintained for backward compatibility with existing EncryptedPayload structure
+
+## Components and Interfaces
+
+### Modified SecureStorageManager Class
+
+```typescript
+export class SecureStorageManager {
+  private encryptionKey: CryptoKey | null = null;
+  private storage: StorageAdapter;
+
+  constructor(storage: StorageAdapter);
+  
+  // Modified method signature
+  public async unlock(password: string): Promise<boolean>;
+  
+  // Existing methods (unchanged)
+  public lock(): void;
+  public get isUnlocked(): boolean;
+  public async saveAccount(account: AccountData): Promise<void>;
+  public async getAccount(): Promise<AccountData | null>;
+  public async saveSessionKeys(sessionKeys: SessionKeysData): Promise<void>;
+  public async getSessionKeys(): Promise<SessionKeysData | null>;
+  
+  // New private methods
+  private async initializeMasterSalt(): Promise<Uint8Array>;
+  private async loadMasterSalt(): Promise<Uint8Array | null>;
+  private async deriveEncryptionKey(password: string, masterSalt: Uint8Array): Promise<CryptoKey>;
+  private async createVerificationPayload(): Promise<void>;
+  private async verifyPassword(): Promise<boolean>;
+}
+```
+
+### Storage Keys
+
+The Storage Adapter will contain these keys:
+
+- `"master_salt"`: Base64-encoded 16-byte master salt
+- `"verification_payload"`: EncryptedPayload structure containing known plaintext
+- `"account"`: EncryptedPayload structure containing account data (existing)
+- `"sessionKeys"`: EncryptedPayload structure containing session keys (existing)
+
+### Data Structures
+
+#### Master Salt Storage Format
+```typescript
+// Stored as base64 string in Storage Adapter
+type MasterSaltStorage = string; // base64-encoded 16 bytes
+```
+
+#### Verification Payload Content
+```typescript
+interface VerificationContent {
+  marker: "KIRO_VERIFICATION_V1";
+  timestamp: number; // Creation timestamp
+}
+```
+
+The verification payload uses the same EncryptedPayload structure as other encrypted data.
+
+## Data Models
+
+### EncryptedPayload (Unchanged)
+
+```typescript
+export interface EncryptedPayload {
+  iv: string;      // Base64-encoded Initialization Vector (12 bytes)
+  salt: string;    // Base64-encoded per-payload salt (16 bytes)
+  data: string;    // Base64-encoded ciphertext + auth tag
+}
+```
+
+This structure remains unchanged for backward compatibility. The per-payload salt is still used for deriving the final AES-GCM key from the encryption key.
+
+### Key Derivation Flow
+
+```
+Step 1: Derive Encryption Key (once per unlock)
+  password (string) + master_salt (16 bytes)
+    → PBKDF2(100k iterations, SHA-256)
+    → encryption_key (AES-256-GCM capable)
+
+Step 2: Derive Per-Payload Key (per encrypt/decrypt operation)
+  encryption_key + payload_salt (16 bytes from EncryptedPayload)
+    → PBKDF2(100k iterations, SHA-256)
+    → aes_key (AES-256-GCM)
+    → encrypt/decrypt with IV
+```
+
+### Unlock Flow State Machine
+
+```
+State: LOCKED
+  ↓ unlock(password)
+  ↓
+Check if master_salt exists
+  ↓
+  NO → Generate master_salt → Store master_salt
+  YES → Load master_salt
+  ↓
+Derive encryption_key from password + master_salt
+  ↓
+Check if verification_payload exists
+  ↓
+  NO → Create verification_payload → Store verification_payload → State: UNLOCKED → return true
+  YES → Attempt decrypt verification_payload
+          ↓
+          SUCCESS → State: UNLOCKED → return true
+          FAILURE → Clear encryption_key → State: LOCKED → return false
+```
+
+
+## Correctness Properties
+
+*A property is a characteristic or behavior that should hold true across all valid executions of a system—essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
+
+### Property Reflection
+
+After analyzing all acceptance criteria, I identified the following redundancies:
+- Properties 3.2, 3.3, 4.1, and 4.2 all test unlock return values and can be consolidated into comprehensive properties
+- Property 5.3 is redundant with 3.3 (both test key clearing on wrong password)
+- Properties 2.5 and 5.4 both test that storage contains no plaintext and can be combined
+- Properties 3.1, 3.2, and 3.3 can be combined into a single verification property
+
+### Property 1: Master salt format consistency
+
+*For any* master salt stored in the Storage Adapter, it should be a valid base64-encoded string representing exactly 16 bytes of data.
+
+**Validates: Requirements 1.4**
+
+### Property 2: Encryption key derivation enables decryption
+
+*For any* password and master salt, if an encryption key is derived and used to encrypt data, then deriving a key with the same password and master salt should successfully decrypt that data.
+
+**Validates: Requirements 2.1**
+
+### Property 3: Encryption keys never persisted
+
+*For any* state of the Storage Adapter after any sequence of operations, inspecting the storage should reveal no plaintext encryption keys or sensitive secrets.
+
+**Validates: Requirements 2.5, 5.4**
+
+### Property 4: Password verification through verification payload
+
+*For any* password, when a verification payload exists in storage, unlock should attempt to decrypt it and return true if decryption succeeds or return false and clear the encryption key if decryption fails.
+
+**Validates: Requirements 3.1, 3.2, 3.3**
+
+### Property 5: Verification payload structure consistency
+
+*For any* verification payload created by the system, it should have the same EncryptedPayload structure (iv, salt, data fields) as other encrypted data.
+
+**Validates: Requirements 3.6**
+
+### Property 6: Correct password returns true
+
+*For any* correct password, calling unlock should return true and leave the SecureStorageManager in an unlocked state.
+
+**Validates: Requirements 4.1**
+
+### Property 7: Incorrect password returns false
+
+*For any* incorrect password, calling unlock should return false and leave the SecureStorageManager in a locked state with no encryption key in memory.
+
+**Validates: Requirements 4.2, 4.4**
+
+### Property 8: Unlock idempotence
+
+*For any* correct password, calling unlock multiple times should always return true without re-deriving keys after the first successful unlock.
+
+**Validates: Requirements 4.3**
+
+### Property 9: No plaintext exposure on wrong password
+
+*For any* incorrect password, calling unlock or attempting to decrypt data should not expose any plaintext secrets through return values, error messages, or accessible state.
+
+**Validates: Requirements 5.1, 5.2**
+
+### Property 10: EncryptedPayload structure preservation
+
+*For any* data encrypted by the SecureStorageManager, the resulting EncryptedPayload should contain exactly three fields: iv, salt, and data, all as base64-encoded strings.
+
+**Validates: Requirements 6.2**
+
+### Property 11: Per-payload salt uniqueness
+
+*For any* two distinct encryption operations, the resulting EncryptedPayloads should have different salt values, demonstrating that each payload uses its own random salt.
+
+**Validates: Requirements 6.3**
+
+### Property 12: Master salt independence
+
+*For any* encrypted payload and the master salt, the payload's salt field should be different from the master salt, demonstrating independence between master salt and per-payload salts.
+
+**Validates: Requirements 6.4**
+
+## Error Handling
+
+### Error Scenarios
+
+1. **Storage Adapter Failures**
+   - If Storage Adapter operations fail (get/set/remove), propagate the error to the caller
+   - Do not catch or suppress storage errors
+   - Maintain locked state if unlock fails due to storage errors
+
+2. **Decryption Failures**
+   - When decryption fails (wrong password or corrupted data), throw error: "Invalid password or corrupted data"
+   - Clear encryption key from memory before throwing
+   - Ensure error messages contain no sensitive information
+
+3. **Locked State Access**
+   - When encrypt/decrypt operations are attempted while locked, throw error: "Storage manager is locked"
+   - This prevents accidental access attempts without proper authentication
+
+4. **Crypto API Failures**
+   - If Web Crypto API operations fail, propagate the native error
+   - These are typically programming errors (invalid parameters) rather than user errors
+
+### Error Recovery
+
+- After any error during unlock, the manager should remain in a locked state
+- Users can retry unlock with a different password
+- Storage corruption should be detectable through decryption failures
+- No automatic retry or recovery mechanisms (caller decides retry strategy)
+
+## Testing Strategy
+
+### Dual Testing Approach
+
+This feature requires both unit tests and property-based tests for comprehensive coverage:
+
+- **Unit tests**: Verify specific examples, edge cases, and error conditions
+- **Property tests**: Verify universal properties across all inputs
+
+Both approaches are complementary and necessary. Unit tests catch concrete bugs and verify specific scenarios, while property tests verify general correctness across a wide range of inputs.
+
+### Unit Testing Focus
+
+Unit tests should cover:
+
+1. **First-run initialization**
+   - Master salt generation and storage
+   - Verification payload creation
+   - Successful unlock on first run
+
+2. **Subsequent unlock scenarios**
+   - Correct password returns true
+   - Incorrect password returns false
+   - Already unlocked returns true immediately
+
+3. **State transitions**
+   - Lock/unlock cycles
+   - Multiple manager instances sharing storage
+
+4. **Error conditions**
+   - Accessing encrypted data while locked
+   - Storage adapter failures
+   - Corrupted data handling
+
+5. **Backward compatibility**
+   - Loading and decrypting data encrypted with previous implementation
+   - Migrating from old to new unlock mechanism
+
+### Property-Based Testing Configuration
+
+**Library Selection**: Use `fast-check` for TypeScript/JavaScript property-based testing
+
+**Configuration**:
+- Minimum 100 iterations per property test (due to randomization)
+- Each property test must reference its design document property
+- Tag format: `// Feature: secure-storage-unlock, Property {number}: {property_text}`
+
+**Property Test Coverage**:
+
+1. **Property 1**: Master salt format consistency
+   - Generate random byte arrays, encode as base64, verify decoding produces 16 bytes
+
+2. **Property 2**: Encryption key derivation enables decryption
+   - Generate random passwords and data, verify encrypt/decrypt round trip
+
+3. **Property 3**: Encryption keys never persisted
+   - Generate random operations, inspect storage, verify no plaintext keys
+
+4. **Property 4**: Password verification through verification payload
+   - Generate random correct/incorrect passwords, verify unlock behavior
+
+5. **Property 5**: Verification payload structure consistency
+   - Generate random verification payloads, verify structure matches EncryptedPayload
+
+6. **Property 6**: Correct password returns true
+   - Generate random passwords, verify unlock returns true for correct password
+
+7. **Property 7**: Incorrect password returns false
+   - Generate random incorrect passwords, verify unlock returns false and clears state
+
+8. **Property 8**: Unlock idempotence
+   - Generate random passwords, call unlock multiple times, verify consistent behavior
+
+9. **Property 9**: No plaintext exposure on wrong password
+   - Generate random incorrect passwords, verify no plaintext in errors or state
+
+10. **Property 10**: EncryptedPayload structure preservation
+    - Generate random data, encrypt, verify payload structure
+
+11. **Property 11**: Per-payload salt uniqueness
+    - Generate random data, encrypt multiple times, verify different salts
+
+12. **Property 12**: Master salt independence
+    - Generate random data, verify master salt differs from payload salts
+
+### Test File Organization
+
+```
+packages/core-sdk/src/storage/__tests__/
+  ├── manager.test.ts (existing unit tests - update for new unlock signature)
+  ├── unlock.test.ts (new comprehensive unlock tests)
+  └── unlock.properties.test.ts (new property-based tests)
+```
+
+### Backward Compatibility Testing
+
+Create a test that:
+1. Uses the old implementation to encrypt data
+2. Stores the encrypted data
+3. Uses the new implementation to unlock and decrypt
+4. Verifies data integrity
+
+This ensures existing users can upgrade without losing access to their encrypted data.
+