From 87ece54cf2ea6b19c29815076967af8cd595a14d Mon Sep 17 00:00:00 2001 From: Nicolas Iooss Date: Tue, 5 Nov 2024 16:44:29 +0100 Subject: [PATCH] Fix some misspellings Some files contained English misspellings or math issues (`lamba` instead of `lambda`). --- CMakeLists.txt | 2 +- configure.ac | 4 ++-- src/scalar_impl.h | 4 ++-- src/util.h | 2 +- src/wycheproof/ecdsa_secp256k1_sha256_bitcoin_test.json | 8 ++++---- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 5d3c9061cd..aba6e51259 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -55,7 +55,7 @@ option(SECP256K1_INSTALL "Enable installation." ${PROJECT_IS_TOP_LEVEL}) ## Modules # We declare all options before processing them, to make sure we can express -# dependendencies while processing. +# dependencies while processing. option(SECP256K1_ENABLE_MODULE_ECDH "Enable ECDH module." ON) option(SECP256K1_ENABLE_MODULE_RECOVERY "Enable ECDSA pubkey recovery module." OFF) option(SECP256K1_ENABLE_MODULE_EXTRAKEYS "Enable extrakeys module." ON) diff --git a/configure.ac b/configure.ac index 22a7ac0d14..c62a391d78 100644 --- a/configure.ac +++ b/configure.ac @@ -254,8 +254,8 @@ fi print_msan_notice=no if test x"$enable_ctime_tests" = x"yes"; then SECP_MSAN_CHECK - # MSan on Clang >=16 reports unitialized memory in function parameters and return values, even if - # the uninitalized variable is never actually "used". This is called "eager" checking, and it's + # MSan on Clang >=16 reports uninitialized memory in function parameters and return values, even if + # the uninitialized variable is never actually "used". This is called "eager" checking, and it's # sounds like good idea for normal use of MSan. However, it yields many false positives in the # ctime_tests because many return values depend on secret (i.e., "uninitialized") values, and # we're only interested in detecting branches (which count as "uses") on secret data. diff --git a/src/scalar_impl.h b/src/scalar_impl.h index dbb5b0a01c..0232a8c223 100644 --- a/src/scalar_impl.h +++ b/src/scalar_impl.h @@ -90,11 +90,11 @@ static void secp256k1_scalar_split_lambda_verify(const secp256k1_scalar *r1, con #endif /* - * Both lambda and beta are primitive cube roots of unity. That is lamba^3 == 1 mod n and + * Both lambda and beta are primitive cube roots of unity. That is lambda^3 == 1 mod n and * beta^3 == 1 mod p, where n is the curve order and p is the field order. * * Furthermore, because (X^3 - 1) = (X - 1)(X^2 + X + 1), the primitive cube roots of unity are - * roots of X^2 + X + 1. Therefore lambda^2 + lamba == -1 mod n and beta^2 + beta == -1 mod p. + * roots of X^2 + X + 1. Therefore lambda^2 + lambda == -1 mod n and beta^2 + beta == -1 mod p. * (The other primitive cube roots of unity are lambda^2 and beta^2 respectively.) * * Let l = -1/2 + i*sqrt(3)/2, the complex root of X^2 + X + 1. We can define a ring diff --git a/src/util.h b/src/util.h index 88a4149421..5f29f4076c 100644 --- a/src/util.h +++ b/src/util.h @@ -232,7 +232,7 @@ static SECP256K1_INLINE void secp256k1_memclear(void *ptr, size_t len) { * As best as we can tell, this is sufficient to break any optimisations that * might try to eliminate "superfluous" memsets. * This method is used in memzero_explicit() the Linux kernel, too. Its advantage is that it - * is pretty efficient, because the compiler can still implement the memset() efficently, + * is pretty efficient, because the compiler can still implement the memset() efficiently, * just not remove it entirely. See "Dead Store Elimination (Still) Considered Harmful" by * Yang et al. (USENIX Security 2017) for more background. */ diff --git a/src/wycheproof/ecdsa_secp256k1_sha256_bitcoin_test.json b/src/wycheproof/ecdsa_secp256k1_sha256_bitcoin_test.json index 9c90747993..af2331768e 100644 --- a/src/wycheproof/ecdsa_secp256k1_sha256_bitcoin_test.json +++ b/src/wycheproof/ecdsa_secp256k1_sha256_bitcoin_test.json @@ -10,7 +10,7 @@ "notes" : { "ArithmeticError" : { "bugType" : "EDGE_CASE", - "description" : "Some implementations of ECDSA have arithmetic errors that occur when intermediate results have extreme values. This test vector has been constructed to test such occurences.", + "description" : "Some implementations of ECDSA have arithmetic errors that occur when intermediate results have extreme values. This test vector has been constructed to test such occurrences.", "cves" : [ "CVE-2017-18146" ] @@ -47,7 +47,7 @@ "InvalidSignature" : { "bugType" : "AUTH_BYPASS", "description" : "The signature contains special case values such as r=0 and s=0. Buggy implementations may accept such values, if the implementation does not check boundaries and computes s^(-1) == 0.", - "effect" : "Accepting such signatures can have the effect that an adversary can forge signatures without even knowning the message to sign.", + "effect" : "Accepting such signatures can have the effect that an adversary can forge signatures without even knowing the message to sign.", "cves" : [ "CVE-2022-21449", "CVE-2021-43572", @@ -57,7 +57,7 @@ "InvalidTypesInSignature" : { "bugType" : "AUTH_BYPASS", "description" : "The signature contains invalid types. Dynamic typed languages sometime coerce such values of different types into integers. If an implementation is careless and has additional bugs, such as not checking integer boundaries then it may be possible that such signatures are accepted.", - "effect" : "Accepting such signatures can have the effect that an adversary can forge signatures without even knowning the message to sign.", + "effect" : "Accepting such signatures can have the effect that an adversary can forge signatures without even knowing the message to sign.", "cves" : [ "CVE-2022-21449" ] @@ -95,7 +95,7 @@ }, "SignatureMalleabilityBitcoin" : { "bugType" : "SIGNATURE_MALLEABILITY", - "description" : "\"BitCoins\"-curves are curves where signature malleability can be a serious issue. An implementation should only accept a signature s where s < n/2. If an implementation is not meant for uses cases that require signature malleability then this implemenation should be tested with another set of test vectors.", + "description" : "\"BitCoins\"-curves are curves where signature malleability can be a serious issue. An implementation should only accept a signature s where s < n/2. If an implementation is not meant for uses cases that require signature malleability then this implementation should be tested with another set of test vectors.", "effect" : "In bitcoin exchanges, it may be used to make a double deposits or double withdrawals", "links" : [ "https://en.bitcoin.it/wiki/Transaction_malleability",