Why we started Seceq
Every website visit, message and payment relies on cryptography, and implementing it correctly is still one of the hardest problems in software engineering. Working on security-critical systems, we kept running into the same three problems:
- Performance vs. safety: fast implementations in C/C++ are prone to memory safety vulnerabilities, while safe ones in high-level languages are too slow for production use.
- Complexity vs. correctness: cryptographic algorithms are intricate, and small implementation mistakes (an off-by-one error, a timing variation, a forgotten edge case) can completely compromise security.
- Legacy vs. future: the industry needs to migrate to post-quantum cryptography, but most libraries either don't support it or perform poorly.
We started Seceq to fix them.
Our approach
1. Rust for memory safety
Every line of code in our libraries is written in Rust, whose ownership system eliminates entire classes of vulnerabilities (buffer overflows, use-after-free, data races) at compile time. Memory safety bugs account for 70% of security vulnerabilities in major software projects, and by choosing Rust we eliminate them before they can occur.
2. Formal verification for correctness
Testing can find bugs but can't prove their absence. For cryptographic code, where a single mistake can expose millions of users, we need stronger guarantees. We use formal verification to prove our implementations mathematically correct: when a proof succeeds, we know the code works correctly for every possible input, including ones we didn't think to test.
3. Performance
Safety and performance are often seen as a trade-off; we don't accept that. Careful algorithm design, architecture-specific optimizations and compiler tuning give OpenCrypt performance competitive with C libraries, with full memory safety.
What we're building
OpenCrypt: high-performance cryptographic library
Our flagship project, OpenCrypt, is a broad cryptographic library:
- Symmetric cryptography: AES-GCM (128/192/256-bit), ChaCha20-Poly1305, and AES-GCM-SIV for nonce-reuse resistance
- Hash functions: SHA-2 family (SHA-256, SHA-384, SHA-512), SHA-3 family (SHA3-256, SHA3-512, SHAKE128, SHAKE256), and BLAKE3 for maximum performance
- Post-quantum cryptography: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) for hash-based signatures
- Classical public-key cryptography: X25519 for key exchange, Ed25519 for digital signatures, and RSA for legacy compatibility
SecTLS: secure communication
Building on OpenCrypt, we're developing SecTLS, a TLS 1.3 implementation with native post-quantum support. It provides hybrid key exchange (X25519 + ML-KEM), post-quantum cipher suites, QUIC support and zero-copy record processing.
OpenZKVM: zero-knowledge infrastructure
Our research project OpenZKVM explores a new approach to zero-knowledge proofs: a custom instruction set architecture optimized for STARK proving. With it we achieve significant efficiency improvements over existing zkVMs.
Our values
- Security first: every design decision starts there. Performance, usability and features matter, but never at the expense of security.
- Open source: all our code is open source, because security through obscurity doesn't work. Public scrutiny, academic review and community contributions make our implementations stronger.
- Quality over quantity: we'd rather provide five well-implemented algorithms than fifty poorly tested ones. Every primitive we ship is thoroughly tested, benchmarked and documented.
- Honest communication: we don't make claims we can't back up. If we say code is formally verified, we provide the proofs; if we publish benchmarks, we share the methodology and make the results reproducible.
The team
Seceq was founded by engineers with deep experience in cryptography, systems programming and security, with backgrounds in cryptographic library development, formal verification research, high-frequency trading systems, and security auditing and penetration testing. We've contributed to open-source cryptographic projects, published research on implementation security, and built production systems that handle sensitive data.
Roadmap
We're at an early stage, with an ambitious roadmap:
- 2024: OpenCrypt 1.0 release with core primitives, full documentation and examples, and a security audit by an independent firm.
- 2025: OpenCrypt 2.0 with post-quantum algorithms, a SecTLS beta release, and a ZK IR research publication.
- 2026 and beyond: enterprise support offerings, hardware security module integration, and expanded algorithm coverage.
Getting involved
Try OpenCrypt in your projects and tell us what works and what doesn't; real-world use gives the best feedback. Our repositories accept code, documentation and bug reports, and every contribution helps. If you find our work valuable, tell others: security improves when good tools are widely adopted.
Our goal is good cryptography for every developer, whatever their security background. As quantum computing advances, the need for it will only grow.