Security

​

Security Model

1. Client-Side Encryption: All encryption happens in your browser before upload
2. Zero-Knowledge Proofs: Verify without revealing sensitive data
3. Decentralized Storage: IPFS ensures no single point of failure
4. On-Chain Verification: Immutable proof storage on Solana and Starknet

​

Cryptography

1. Groth16 (zkStorage): Trusted setup via Powers of Tau, ~100ms verification
2. STARK (zkID): Transparent setup, no trusted ceremony needed

​

zkToolkit Security

1. hash: Poseidon, Pedersen, MiMC hash functions
2. commit: Pedersen commitments (hiding + binding properties)
3. nullifier: Double-spend prevention via Poseidon(secret, scope)
4. range: Range proofs using bit decomposition
5. sign: EdDSA over Baby Jubjub curve
6. merkle: Merkle tree construction and proofs
7. field: BN254 prime field arithmetic
8. ec: Baby Jubjub elliptic curve operations
9. shamir: Secret sharing (k-of-n threshold)
10. proof: Groth16 proof generation

​

Threat Model

• Man-in-the-Middle: TLS encryption + client-side crypto
• Server Compromise: Server never sees passwords or private keys
• Replay Attacks: Nonce-based signatures
• Brute Force: bcrypt slow hashing + rate limiting
• Data Tampering: IPFS content addressing + SHA-256 checksums
• Double Spend: Nullifier sets with Poseidon hashing

• Quantum Computers: Ed25519 is vulnerable (post-quantum research in progress)
• Client Malware: If your device is compromised, keys can be extracted
• Social Engineering: Phishing attacks targeting users
• Lost Passwords: No password recovery by design (user controls keys)

​

Best Practices for Users

1. Use 16+ character passwords
2. Include numbers, symbols, uppercase letters
3. Never reuse passwords across services
4. Use a password manager
5. No password recovery exists - store passwords safely

1. Export private keys to secure offline location
2. Never share private keys with anyone
3. Store backups on encrypted USB or hardware wallet
4. Consider hardware wallet for high-value operations

1. Verify checksums after downloading files
2. Keep backup of important file IDs
3. Use unique passwords for each file
4. Never upload sensitive data without encryption enabled

1. Verify transaction details before signing
2. Use hardware wallet for large amounts
3. Double-check contract addresses
4. Monitor gas prices before transactions

​

Best Practices for Developers

// Always use HTTPS and include credentials
const response = await fetch('/api/endpoint', {
  credentials: 'include',
  headers: {
    'Content-Type': 'application/json'
  }
});

// Validate all inputs
if (!password || password.length < 12) {
  throw new Error('Password must be at least 12 characters');
}

// Don't expose sensitive error details to users
try {
  await zkStorage.download(fileId, password);
} catch (error) {
  // Log full error server-side only
  console.error('[Server]', error);
  // Return generic message to user
  throw new Error('Decryption failed');
}

// Implement exponential backoff
const delay = Math.min(1000 * Math.pow(2, attempts), 30000);
await new Promise(resolve => setTimeout(resolve, delay));

​

Memory Safety

1. Private Key Zeroization: Keys are zeroed from memory after use
2. ArrayBuffer Usage: Sensitive data stored in ArrayBuffer (can be zeroed)
3. Wallet Mutex Locking: Prevents concurrent transactions on same wallet
4. Session Isolation: Express sessions with PostgreSQL storage

​

Smart Contract Security

• Immutable proof storage (write-once)
• Owner-only verification
• Gas-optimized felt252 operations
• Deployed on Starknet Sepolia (mainnet planned)

• Uses Solana’s built-in ed25519 program
• Transaction memo for proof anchoring
• Deployed on Solana Mainnet

​

Incident Response

1. Do NOT disclose publicly
2. Report via GitHub security advisories or X DM @zkterm
3. Include steps to reproduce and impact assessment
4. We will respond within 48 hours
5. Credit given to researchers (with permission)

​

Compliance

• Privacy by Design: No personal data stored on servers
• Client-Side Encryption: User data encrypted before leaving browser
• Decentralized Storage: Files stored on IPFS, not centralized servers
• User-Controlled Keys: Only users can decrypt their data

​

Stay Updated