aboutsummaryrefslogtreecommitdiff
path: root/lib/std/crypto/bcrypt.zig
AgeCommit message (Collapse)Author
2022-06-20std.crypto: fix invalid pass by valueVeikka Tuominen
2022-06-12std: disable failing tests, add zig2 build test-std to CIVeikka Tuominen
2022-01-28std: break up some long linesAndrew Kelley
This makes packaging Zig for Debian slightly easier since it will no longer trigger a Lintian warning for long lines.
2021-12-27Bcrypt pbkdf (#10331)daurnimator
* Make bcrypt State struct public This is useful to implement the various protocols outside of the standard library * Implement bcrypt pbkdf This variant is used in e.g. SSH The OpenBSD implementation was used as a reference
2021-11-30allocgate: std Allocator interface refactorLee Cannon
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-08-24add scrypt kdf (#9577)lucky
add phc encoding parser add password hash functions to benchmark change bcrypt to be consistent with scrypt Co-authored-by: lucky <>
2021-06-21std, src, doc, test: remove unused variablesJacob G-W
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-24zig fmt the std libAndrew Kelley
2021-01-02std: Use {s} instead of {} when printing stringsLemonBoy
2020-12-31Year++Frank Denis
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-10-26std/*: add missing MIT license headersFrank Denis
2020-10-25std/crypto: add the bcrypt password hashing functionFrank Denis
The bcrypt function intentionally requires quite a lot of CPU cycles to complete. In addition to that, not having its full state constantly in the CPU L1 cache causes a massive performance drop. These properties slow down brute-force attacks against low-entropy inputs (typically passwords), and GPU-based attacks get little to no advantages over CPUs.