{"id":15020483,"url":"https://github.com/raspberrypi/sweet-b","last_synced_at":"2025-10-19T16:32:45.806Z","repository":{"id":252268024,"uuid":"839806858","full_name":"raspberrypi/sweet-b","owner":"raspberrypi","description":null,"archived":false,"fork":false,"pushed_at":"2024-08-08T12:43:41.000Z","size":2615,"stargazers_count":3,"open_issues_count":0,"forks_count":1,"subscribers_count":6,"default_branch":"rp2350-bootrom","last_synced_at":"2025-01-29T21:43:32.358Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/raspberrypi.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":"audit/README.md","citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-08-08T11:10:54.000Z","updated_at":"2024-12-21T00:28:00.000Z","dependencies_parsed_at":"2024-08-08T18:50:56.631Z","dependency_job_id":"04f68750-4959-4df0-8ccd-90e69c0e02cc","html_url":"https://github.com/raspberrypi/sweet-b","commit_stats":null,"previous_names":["raspberrypi/sweet-b"],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/raspberrypi%2Fsweet-b","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/raspberrypi%2Fsweet-b/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/raspberrypi%2Fsweet-b/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/raspberrypi%2Fsweet-b/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/raspberrypi","download_url":"https://codeload.github.com/raspberrypi/sweet-b/tar.gz/refs/heads/rp2350-bootrom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":237172208,"owners_count":19266630,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-09-24T19:55:08.301Z","updated_at":"2025-10-19T16:32:39.860Z","avatar_url":"https://github.com/raspberrypi.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003c!--\n \n README.md: yes, the license applies to this file too\n \n SPDX-License-Identifier: BSD-3-Clause\n\n This file is part of Sweet B, a safe, compact, embeddable library for\n elliptic curve cryptography.\n\n https://github.com/westerndigitalcorporation/sweet-b\n\n Copyright (c) 2020 Western Digital Corporation or its affiliates.\n\n Redistribution and use in source and binary forms, with or without\n modification, are permitted provided that the following conditions are met:\n\n 1. Redistributions of source code must retain the above copyright notice,\n this list of conditions and the following disclaimer.\n\n 2. Redistributions in binary form must reproduce the above copyright notice,\n this list of conditions and the following disclaimer in the documentation\n and/or other materials provided with the distribution.\n\n 3. Neither the name of the copyright holder nor the names of its contributors\n may be used to endorse or promote products derived from this software without\n specific prior written permission.\n\n THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\"\n AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE\n IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE\n ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE\n LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR\n CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF\n SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS\n INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN\n CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)\n ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE\n POSSIBILITY OF SUCH DAMAGE.\n \n--\u003e\n\n![Sweet B Logo](sweet-b.svg)\n\nSweet B is a library which implements public key elliptic curve cryptography\n(ECC) using the NIST P-256 and SECG secp256k1 curves. Sweet B is:\n\n* *Safe:* known attack vectors have been accounted for, design decisions have\n  been documented, and the API has been designed to eliminate the possibility of\n  catastrophic misuse when possible.\n* *Clear:* the library is thoroughly commented and unit tested, and is designed\n  to be easy to read and review.\n* *Compact:* the library is compact in code size, uses a minimal 512-byte\n  working context, and does not assume that keys and other intermediary products\n  can be allocated on the stack.\n* *Audited:* a third-party review of the library was carried out prior to public\n release, and the full report and status of remediations are [available\n  publicly](audit/README.md).\n\nYou should consider using Sweet B if you need to implement elliptic curve \nDiffie-Hellman shared-secret generation (ECDH) or elliptic curve digital \nsignature generation and verification (ECDSA) in a memory-constrained \nenvironment. For instance, the P-256 curve is used in Bluetooth Low Energy \nSecurity, and is often implemented on memory-constrained devices for this \npurpose.\n\n## Why is it called Sweet B?\n\nSweet B is a pun on both the Short Weierstrass form of elliptic curves and on\nthe NSA's [Suite B](https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography) set\nof cryptographic algorithms.\n\n## Where did Sweet B come from?\n\nSweet B was developed by [Western Digital](https://www.westerndigital.com/).\n\n## How was Sweet B reviewed?\n\nWestern Digital engaged the security research firm\n[Trail of Bits](https://www.trailofbits.com) to review Sweet B prior to its\n public release. The resulting report and the status of remediations for\n  specific findings are [available publicly](audit/README.md).\n\n## How does Sweet B protect against known attacks on ECC?\n\nSweet B provides mitigation for several classes of known faults and attacks:\n\n* _Timing analyses_ reveal secret information by measuring the time that it\n  takes to perform cryptographic operations. Sweet B prevents this by ensuring\n  that all operations run in constant time with respect to the input data\n  (though different curves have different performance characteristics).\n* _Power analyses_ reveal secret information by measuring the amount of power\n  consumed during cryptographic operations. Sweet B addresses this by using\n  *randomized projective coordinates*, also called Z blinding. The special case\n  of *zero value analysis* has been addressed by representing reduced integers\n  modulo 𝑝 as integers within the range [1, 𝑝], ensuring that the points\n  (0, ±√𝐵 ∙ 𝑍³, 𝑍) on applicable curves do not cause observable multiplications\n  by low-Hamming-weight field elements.\n* _Safe-error analyses_ reveal secret information by causing hardware faults\n  during cryptographic operations and observing whether the fault affects the\n  output. Sweet B mitigates these attacks through the use of a regular\n  Montgomery ladder with no dummy computations prior to the final bit.\n* _Per-message secret reuse_ causes the private key to be revealed to anyone\n  receiving more than one signature with the same secret. Sweet B prevents this\n  by providing an internal implementation of a deterministic random-bit\n  generator (DRBG) using HMAC-SHA256 for per-message secret generation in ECDSA\n  signing. When an externally seeded instance of the DRBG is provided, the\n  private key and message are provided as additional input to the DRBG, ensuring\n  that even in cases of entropy source failure, per-message secrets are never\n  re-used. When no externally seeded instance is provided,\n  [RFC6979](https://tools.ietf.org/html/rfc6979) deterministic signing is used.\n  The internal HMAC-DRBG is also used for projective-coordinate randomization\n  when no external entropy source is available.\n\nIt is impossible to guarantee that side-channel mitigations in a\nportable C implementation will perform correctly with all compilers and with all\ntarget platforms. Please analyze Sweet B and your use case carefully if using\n it on a platform where assembly support is not available.\n\n## What makes Sweet B different than other implementations?\n\nSweet B is designed to be simple, safe, compact, and embeddable. In order to be\nas portable as possible, any word size from 8 to 64 bits may be used; you should\nchoose the word size that corresponds to the size of your hardware multiplier.\nSweet B does not assume that it's possible to store large amounts of working\nstate on the stack; instead, a separately allocated 512-byte working context is\nrequired, which may be placed on the stack, heap allocated, or statically\nallocated per the user's needs.\n\nSimple, compact implementations of SHA256, HMAC-SHA256, and HMAC-DRBG are\nprovided both for internal use and for use in producing digests of data to be\nsigned or verified. You are also encouraged to use the HMAC-DRBG implementation\nfor random number generation in your system, assuming you have access to a\nsufficient source of hardware entropy.\n\nSweet B uses Montgomery multiplication, which eliminates the need for separate\nreduction steps. This makes it easier to produce a constant-time library\nsupporting multiple primes, and also makes Sweet B fast compared with other\nembeddable implementations in C. However, there are faster implementations of\nECC if you have more working memory or more code storage available.\n\nSweet B has been carefully designed to avoid side channel attacks, including\ntiming and power analyses. All field operations and elliptic curve operations\nare designed to run in constant time, and projective coordinate randomization\nconsistently used. All functions take an optional DRBG parameter, and you are\nstrongly encouraged to supply a properly-seeded DRBG whenever possible to\nmitigate power-based side channel attacks.\n\n## How do I get started with Sweet B?\n\n[`sb_sw_lib.h`](src/sb_sw_lib.h) is the main entry point for ECC operations on\nshort Weierstrass curves (P-256 and secp256k1). For hashing and random number\ngeneration, see [`sb_sha256.h`](src/sb_sha256.h) and\n[`sb_hmac_drbg.h`](src/sb_hmac_drbg.h). Each file contains a number of test \ncases; if you compile Sweet B with `-DSB_TEST`, you can run them using the \nmain routine in [`sb_test.c`](src/sb_test.c).\n\nYou can set the word size used in Sweet B with the `SB_WORD_SIZE` preprocessor\nmacro. By default, this is set to 4, meaning that 32-bit multiplies producing\n64-bit results will be used. On 8- or 16-bit microcontrollers, or on 32-bit\nmicrocontrollers without full 64-bit multiply output (such as the Cortex-M0+),\nyou should set this to 1 or 2. On 64-bit x86 systems, you may want to set the\nmultiplication size to 8 to use 128-bit multiplication output.\n\nYou can disable either of the short Weierstrass curves Sweet B supports by\nsetting the preprocessor defines `SB_SW_P256_SUPPORT` or\n`SB_SW_SECP256K1_SUPPORT` to 0. If you have a little more program memory \navailable, you may want to set `SB_UNROLL` to a value between 1 and 3 \n(inclusive); on Cortex-M4, `SB_UNROLL=2` provides the best balance between \nsize and speed.\n\nIf you have ARM support for your processor (see [`sb_fe_armv7.s`](src/sb_fe_armv7.s)\nfor an example of this); define `SB_FE_ASM` to 1 when compiling the code, and\nsupply a separate ARM assembly implementation for the core field-element\narithmetic routines listed in [`sb_fe.h`](src/sb_fe.h) as being supported by\nassembly. The supplied example implementation targets 32-bit ARM Thumb\nprocessors with DSP extensions; examples of this include the Cortex-M4, M7, and\nA5.\n\n[CMake](https://cmake.org/) build support is provided; to use it, create a\ndirectory for your build, run `cmake` with the path to the Sweet B sources, and\nthen run `make` to build. To run the unit tests with the clang undefined\nbehavior and address sanitizers, pass `-DCMAKE_C_COMPILER=clang` to `cmake` if\nclang is not your default compiler.\n\n## Annotated Bibliography\n\nNeal Koblitz. A Course in Number Theory and Cryptography. Springer-Verlag, 1994.\n\n\u003e This is a rather old text, and the section on elliptic curves is dated.\n\u003e However, it remains an outstanding reference for any discussion of finite\n\u003e fields.\n\nAlfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. [Handbook of\nApplied Cryptography](http://cacr.uwaterloo.ca/hac/). CRC Press, 1996.\n\n\u003e Another older text, but the chapter on efficient implementation remains a\n\u003e worthwhile reference for basic field arithmetic algorithms.\n\nJean-Sébastien Coron. [Resistance Against Differential Power Analysis For\nElliptic Curve\nCryptosystems](http://www.crypto-uni.lu/jscoron/publications/dpaecc.pdf). In\n_Cryptographic Hardware and Embedded Systems (CHES) 1999_.\n\n\u003e Introduces several countermeasures against power analyses, the third of which\n\u003e is the randomized projective coordinate technique used in Sweet B (often\n\u003e described as \"Coron's third countermeasure\").\n\nTetsuya Izu, Bodo Möller, and Tsuyoshi Takagi. [Improved Elliptic Curve\nMultiplication Methods Resistant against Side Channel\nAttacks](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.436.831\u0026rep=rep1\u0026type=pdf).\nIn _Progress in Cryptology — INDOCRYPT 2002_.\n\n\u003e Discusses the SPA and DPA-resistance of the Montgomery ladder for elliptic curves.\n\nRaveen R. Goundar, Marc Joye, Atsuko Miyaji, Matthieu Rivain, and Alexandre\nVenelli. [Scalar multiplication on Weierstraß elliptic curves from Co-Z\narithmetic](http://www.matthieurivain.com/files/jcen11b.pdf). In _Journal of\nCryptographic Engineering, Vol. 1, 161 (2011)_.\n\n\u003e Introduces the co-Z Montgomery ladder on Weierstrass curves, and discusses its\n\u003e derivation.\n\n Matthieu Rivain. [Fast and Regular Algorithms for Scalar Multiplication over\n Elliptic Curves](https://eprint.iacr.org/2011/338.pdf). _IACR Cryptology ePrint\n Archive, Report 2011/338_.\n\n \u003e The main reference for Sweet B. Describes the co-Z addition and initial\n \u003e affine-to-Jacobian point doubling formulae implemented in the library.\n\nShay Gueron and Vlad Krasnov. [Fast prime field elliptic-curve cryptography with\n256-bit primes](https://eprint.iacr.org/2013/816.pdf). In _Journal of\nCryptographic Engineering, Vol. 5, 141 (2011)_.\n\n\u003e Discusses the use of Montgomery multiplication with the P-256 field prime,\n\u003e specifically due to its \"Montgomery friendly\" property.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fraspberrypi%2Fsweet-b","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fraspberrypi%2Fsweet-b","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fraspberrypi%2Fsweet-b/lists"}