27610b0a0f
ECDSA is the most commonly used signature scheme today, mainly for historical and conformance reasons. It is a necessary evil for many standard protocols such as TLS and JWT. It is tricky to implement securely and has been the root cause of multiple security disasters, from the Playstation 3 hack to multiple critical issues in OpenSSL and Java. This implementation combines lessons learned from the past with recent recommendations. In Zig, the NIST curves that ECDSA is almost always instantied with use formally verified field arithmetic, giving us peace of mind even on edge cases. And the API rejects neutral elements where it matters, and unconditionally checks for non-canonical encoding for scalars and group elements. This automatically eliminates common vulnerabilities such as https://sk.tl/2LpS695v . ECDSA's security heavily relies on the security of the random number generator, which is a concern in some environments. This implementation mitigates this by computing deterministic nonces using the conservative scheme from Pornin et al. with the optional addition of randomness as proposed in Ericsson's "Deterministic ECDSA and EdDSA Signatures with Additional Randomness" document. This approach mitigates both the implications of a weak RNG and the practical implications of fault attacks. Project Wycheproof is a Google project to test crypto libraries against known attacks by triggering edge cases. It discovered vulnerabilities in virtually all major ECDSA implementations. The entire set of ECDSA-P256-SHA256 test vectors from Project Wycheproof is included here. Zero defects were found in this implementation. The public API differs from the Ed25519 one. Instead of raw byte strings for keys and signatures, we introduce Signature, PublicKey and SecretKey structures. The reason is that a raw byte representation would not be optimal. There are multiple standard representations for keys and signatures, and decoding/encoding them may not be cheap (field elements have to be converted from/to the montgomery domain). So, the intent is to eventually move ed25519 to the same API, which is not going to introduce any performance regression, but will bring us a consistent API, that we can also reuse for RSA.
A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Resources
- Introduction
- Download & Documentation
- Chapter 0 - Getting Started | ZigLearn.org
- Community
- Contributing
- Code of Conduct
- Frequently Asked Questions
- Community Projects
Installation
- download a pre-built binary
- install from a package manager
- build from source
- bootstrap zig for any target
License
The ultimate goal of the Zig project is to serve users. As a first-order effect, this means users of the compiler, helping programmers to write better software. Even more important, however, are the end-users.
Zig is intended to be used to help end-users accomplish their goals. Zig should be used to empower end-users, never to exploit them financially, or to limit their freedom to interact with hardware or software in any way.
However, such problems are best solved with social norms, not with software licenses. Any attempt to complicate the software license of Zig would risk compromising the value Zig provides.
Therefore, Zig is available under the MIT (Expat) License, and comes with a humble request: use it to make software better serve the needs of end-users.
This project redistributes code from other projects, some of which have other licenses besides MIT. Such licenses are generally similar to the MIT license for practical purposes. See the subdirectories and files inside lib/ for more details.