aboutsummaryrefslogtreecommitdiff
path: root/lib/std/crypto/salsa20.zig
AgeCommit message (Collapse)Author
2025-07-13std.crypto: remove `inline` from most functionsAndrew Kelley
To quote the language reference, It is generally better to let the compiler decide when to inline a function, except for these scenarios: * To change how many stack frames are in the call stack, for debugging purposes. * To force comptime-ness of the arguments to propagate to the return value of the function, as in the above example. * Real world performance measurements demand it. Don't guess! Note that inline actually restricts what the compiler is allowed to do. This can harm binary size, compilation speed, and even runtime performance. `zig run lib/std/crypto/benchmark.zig -OReleaseFast` [-before-] vs {+after+} md5: [-990-] {+998+} MiB/s sha1: [-1144-] {+1140+} MiB/s sha256: [-2267-] {+2275+} MiB/s sha512: [-762-] {+767+} MiB/s sha3-256: [-680-] {+683+} MiB/s sha3-512: [-362-] {+363+} MiB/s shake-128: [-835-] {+839+} MiB/s shake-256: [-680-] {+681+} MiB/s turboshake-128: [-1567-] {+1570+} MiB/s turboshake-256: [-1276-] {+1282+} MiB/s blake2s: [-778-] {+789+} MiB/s blake2b: [-1071-] {+1086+} MiB/s blake3: [-1148-] {+1137+} MiB/s ghash: [-10044-] {+10033+} MiB/s polyval: [-9726-] {+10033+} MiB/s poly1305: [-2486-] {+2703+} MiB/s hmac-md5: [-991-] {+998+} MiB/s hmac-sha1: [-1134-] {+1137+} MiB/s hmac-sha256: [-2265-] {+2288+} MiB/s hmac-sha512: [-765-] {+764+} MiB/s siphash-2-4: [-4410-] {+4438+} MiB/s siphash-1-3: [-7144-] {+7225+} MiB/s siphash128-2-4: [-4397-] {+4449+} MiB/s siphash128-1-3: [-7281-] {+7374+} MiB/s aegis-128x4 mac: [-73385-] {+74523+} MiB/s aegis-256x4 mac: [-30160-] {+30539+} MiB/s aegis-128x2 mac: [-66662-] {+67267+} MiB/s aegis-256x2 mac: [-16812-] {+16806+} MiB/s aegis-128l mac: [-33876-] {+34055+} MiB/s aegis-256 mac: [-8993-] {+9087+} MiB/s aes-cmac: 2036 MiB/s x25519: [-20670-] {+16844+} exchanges/s ed25519: [-29763-] {+29576+} signatures/s ecdsa-p256: [-4762-] {+4900+} signatures/s ecdsa-p384: [-1465-] {+1500+} signatures/s ecdsa-secp256k1: [-5643-] {+5769+} signatures/s ed25519: [-21926-] {+21721+} verifications/s ed25519: [-51200-] {+50880+} verifications/s (batch) chacha20Poly1305: [-1189-] {+1109+} MiB/s xchacha20Poly1305: [-1196-] {+1107+} MiB/s xchacha8Poly1305: [-1466-] {+1555+} MiB/s xsalsa20Poly1305: [-660-] {+620+} MiB/s aegis-128x4: [-76389-] {+78181+} MiB/s aegis-128x2: [-53946-] {+53495+} MiB/s aegis-128l: [-27219-] {+25621+} MiB/s aegis-256x4: [-49351-] {+49542+} MiB/s aegis-256x2: [-32390-] {+32366+} MiB/s aegis-256: [-8881-] {+8944+} MiB/s aes128-gcm: [-6095-] {+6205+} MiB/s aes256-gcm: [-5306-] {+5427+} MiB/s aes128-ocb: [-8529-] {+13974+} MiB/s aes256-ocb: [-7241-] {+9442+} MiB/s isapa128a: [-204-] {+214+} MiB/s aes128-single: [-133857882-] {+134170944+} ops/s aes256-single: [-96306962-] {+96408639+} ops/s aes128-8: [-1083210101-] {+1073727253+} ops/s aes256-8: [-762042466-] {+767091778+} ops/s bcrypt: 0.009 s/ops scrypt: [-0.018-] {+0.017+} s/ops argon2: [-0.037-] {+0.060+} s/ops kyber512d00: [-206057-] {+205779+} encaps/s kyber768d00: [-156074-] {+150711+} encaps/s kyber1024d00: [-116626-] {+115469+} encaps/s kyber512d00: [-181149-] {+182046+} decaps/s kyber768d00: [-136965-] {+135676+} decaps/s kyber1024d00: [-101307-] {+100643+} decaps/s kyber512d00: [-123624-] {+123375+} keygen/s kyber768d00: [-69465-] {+70828+} keygen/s kyber1024d00: [-43117-] {+43208+} keygen/s
2025-07-01std.crypto.salsa20: Disable some tests on RISC-V with vector supportAlex Rønne Petersen
https://github.com/ziglang/zig/issues/24299
2024-11-19std.crypto: make the key pair API creation consistent (#21955)Frank Denis
Our key pair creation API was ugly and inconsistent between ecdsa keys and other keys. The same `generate()` function can now be used to generate key pairs, and that function cannot fail. For deterministic keys, a `generateDeterministic()` function is available for all key types. Fix comments and compilation of the benchmark by the way. Fixes #21002
2024-08-09std.crypto: better names for everything in utilsAndrew Kelley
std.crypto has quite a few instances of breaking naming conventions. This is the beginning of an effort to address that. Deprecates `std.crypto.utils`.
2024-07-09std: fix typos (#20560)Jora Troosh
2024-02-25x86_64: implement more shufflesJacob Young
2024-02-25x86_64: implement `@shuffle`Jacob Young
2023-11-19lib: correct unnecessary uses of 'var'mlugg
2023-10-31std.builtin.Endian: make the tags lower caseAndrew Kelley
Let's take this breaking change opportunity to fix the style of this enum.
2023-10-31mem: fix ub in writeIntJacob Young
Use inline to vastly simplify the exposed API. This allows a comptime-known endian parameter to be propogated, making extra functions for a specific endianness completely unnecessary.
2023-10-26x86_64: add missing spillsJacob Young
2023-10-25x86_64: pass more testsJacob Young
* 128-bit integer multiplication with overflow * more instruction encodings used by std inline asm * implement the `try_ptr` air instruction * follow correct stack frame abi * enable full panic handler * enable stack traces
2023-10-23x86_64: implement enough to pass unicode testsJacob Young
* implement vector comparison * implement reduce for bool vectors * fix `@memcpy` bug * enable passing std tests
2023-10-22Revert "Revert "Merge pull request #17637 from jacobly0/x86_64-test-std""Jacob Young
This reverts commit 6f0198cadbe29294f2bf3153a27beebd64377566.
2023-10-22Revert "Merge pull request #17637 from jacobly0/x86_64-test-std"Andrew Kelley
This reverts commit 0c99ba1eab63865592bb084feb271cd4e4b0357e, reversing changes made to 5f92b070bf284f1493b1b5d433dd3adde2f46727. This caused a CI failure when it landed in master branch due to a 128-bit `@byteSwap` in std.mem.
2023-10-21x86_64: fix bugs and disable erroring testsJacob Young
2023-08-14std.crypto.aead: Consistent decryption tail and doc fixes (#16781)e4m2
* Consistent decryption tail for all AEADs * Remove outdated note This was previously copied here from another function. There used to be another comment on the tag verification linking to issue #1776, but that one was not copied over. As it stands, this note seems fairly misleading/irrelevant. * Prettier docs * Add note about plaintext contents to docs * Capitalization * Fixup missing XChaChaPoly docs
2023-06-24all: migrate code to new cast builtin syntaxmlugg
Most of this migration was performed automatically with `zig fmt`. There were a few exceptions which I had to manually fix: * `@alignCast` and `@addrSpaceCast` cannot be automatically rewritten * `@truncate`'s fixup is incorrect for vectors * Test cases are not formatted, and their error locations change
2023-06-16migration: std.math.{min, min3, max, max3} -> `@min` & `@max`r00ster91
2023-04-28update codebase to use `@memset` and `@memcpy`Andrew Kelley
2023-02-18update std lib and compiler sources to new for loop syntaxAndrew Kelley
2022-12-27update uses of overflow arithmetic builtinsVeikka Tuominen
2022-11-06crypto.salsa20: make the number of rounds a comptime parameter (#13442)Frank Denis
...instead of hard-coding it to 20. - This is consistent with the ChaCha implementation - NaCl and libsodium, that this API is designed to interop with, also support 8 and 12 round variants. The 12 round variant, in particular, provides the same security level as the 20 round variant, but is obviously faster. - scrypt currently uses its own non optimized version of Salsa, just because it use 8 rounds instead of 20. This will help remove code duplication. No behavior nor public API changes. The Salsa20 and XSalsa20 still represent the 20-round variant.
2022-03-30replace other uses of `std.meta.Vector` with `@Vector` (#11346)Meghan
2021-10-04migrate from `std.Target.current` to `@import("builtin").target`Andrew Kelley
closes #9388 closes #9321
2021-08-24remove redundant license headers from zig standard libraryAndrew Kelley
We already have a LICENSE file that covers the Zig Standard Library. We no longer need to remind everyone that the license is MIT in every single file. Previously this was introduced to clarify the situation for a fork of Zig that made Zig's LICENSE file harder to find, and replaced it with their own license that required annual payments to their company. However that fork now appears to be dead. So there is no need to reinforce the copyright notice in every single file.
2021-05-20Run `zig fmt` on src/ and lib/std/Isaac Freund
This replaces callconv(.Inline) with the more idiomatic inline keyword.
2021-05-08std: update usage of std.testingVeikka Tuominen
2021-04-20std/crypto: use finer-grained error sets in function signatures (#8558)Frank Denis
std/crypto: use finer-grained error sets in function signatures Returning the `crypto.Error` error set for all crypto operations was very convenient to ensure that errors were used consistently, and to avoid having multiple error names for the same thing. The flipside is that callers were forced to always handle all possible errors, even those that could never be returned by a function. This PR makes all functions return union sets of the actual errors they can return. The error sets themselves are all limited to a single error. Larger sets are useful for platform-specific APIs, but we don't have any of these in `std/crypto`, and I couldn't find any meaningful way to build larger sets.
2021-03-14Use a unified error set for std/crypto/*Frank Denis
This ensures that errors are used consistently across all operations.
2021-02-10Convert inline fn to callconv(.Inline) everywhereTadeo Kondrak
2020-12-31Year++Frank Denis
2020-12-28std/crypto: increment the correct words for vectorized salsa20Frank Denis
Add a test for this by the way. Fixes #7579
2020-12-18std: introduce a thread-local CSPRNG for general useAndrew Kelley
std.crypto.random * cross platform, even freestanding * can't fail. on initialization for some systems requires calling os.getrandom(), in which case there are rare but theoretically possible errors. The code panics in these cases, however the application may choose to override the default seed function and then handle the failure another way. * thread-safe * supports the full Random interface * cryptographically secure * no syscall required to initialize on Linux (AT_RANDOM) * calls arc4random on systems that support it `std.crypto.randomBytes` is removed in favor of `std.crypto.random.bytes`. I moved some of the Random implementations into their own files in the interest of organization. stage2 no longer requires passing a RNG; instead it uses this API. Closes #6704
2020-11-07Add mem.timingSafeEql() for constant-time array comparisonFrank Denis
This is a trivial implementation that just does a or[xor] loop. However, this pattern is used by virtually all crypto libraries and in practice, even without assembly barriers, LLVM never turns it into code with conditional jumps, even if one of the parameters is constant. This has been verified to still be the case with LLVM 11.0.0.
2020-11-05Now that they support vectors, use math.rot{l,r}Frank Denis
2020-10-29std/crypto/x25519: return encoded points directly + ed->mont mapFrank Denis
Leverage result location semantics for X25519 like we do everywhere else in 25519/* Also add the edwards25519->curve25519 map by the way since many applications seem to use this to share the same key pair for encryption and signature.
2020-10-29std/crypto: vectorize Salsa20Frank Denis
20% faster on x86_64, slower on aarch64 as usual :/
2020-10-28PascalCase *box names, remove unneeded comptime & parenthesisFrank Denis
Also rename (salsa20|chacha20)Internal() to a better name. And sort reexported crypto.* names
2020-10-26std/*: add missing MIT license headersFrank Denis
2020-10-25Add (X)Salsa20 and NaCl boxesFrank Denis
The NaCl constructions are available in pretty much all programming languages, making them a solid choice for applications that require interoperability. Go includes them in the standard library, JavaScript has the popular tweetnacl.js module, and reimplementations and ports of TweetNaCl have been made everywhere. Zig has almost everything that NaCl has at this point, the main missing component being the Salsa20 cipher, on top on which NaCl's secretboxes, boxes, and sealedboxes can be implemented. So, here they are! And clean the X25519 API up a little bit by the way.
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-28 15:42:33 +0000