aboutsummaryrefslogtreecommitdiff
path: root/lib/std/crypto/siphash.zig
AgeCommit message (Collapse)Author
2025-08-28std.Io: delete GenericWriterAndrew Kelley
2025-07-07std.io: deprecated Reader/Writer; introduce new APIAndrew Kelley
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-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-06-02Fix std.hash benchmarks (#15917)Frank Denis
2023-05-20Zir: eliminate `field_call_bind` and `field_call_bind_named`mlugg
This commit removes the `field_call_bind` and `field_call_bind_named` ZIR instructions, replacing them with a `field_call` instruction which does the bind and call in one. `field_call_bind` is an unfortunate instruction. It's tied into one very specific usage pattern - its result can only be used as a callee. This means that it creates a value of a "pseudo-type" of sorts, `bound_fn` - this type used to exist in Zig, but now we just hide it from the user and have AstGen ensure it's only used in one way. This is quite silly - `Type` and `Value` should, as much as possible, reflect real Zig types and values. It makes sense to instead encode the `a.b()` syntax as its own ZIR instruction, so that's what we do here. This commit introduces a new instruction, `field_call`. It's like `call`, but rather than a callee ref, it contains a ref to the object pointer (`&a` in `a.b()`) and the string field name (`b`). This eliminates `bound_fn` from the language, and slightly decreases the size of generated ZIR - stats below. This commit does remove a few usages which used to be allowed: - `@field(a, "b")()` - `@call(.auto, a.b, .{})` - `@call(.auto, @field(a, "b"), .{})` These forms used to work just like `a.b()`, but are no longer allowed. I believe this is the correct choice for a few reasons: - `a.b()` is a purely *syntactic* form; for instance, `(a.b)()` is not valid. This means it is *not* inconsistent to not allow it in these cases; the special case here isn't "a field access as a callee", but rather this exact syntactic form. - The second argument to `@call` looks much more visually distinct from the callee in standard call syntax. To me, this makes it seem strange for that argument to not work like a normal expression in this context. - A more practical argument: it's confusing! `@field` and `@call` are used in very different contexts to standard function calls: the former normally hints at some comptime machinery, and the latter that you want more precise control over parts of a function call. In these contexts, you don't want implicit arguments adding extra confusion: you want to be very explicit about what you're doing. Lastly, some stats. I mentioned before that this change slightly reduces the size of ZIR - this is due to two instructions (`field_call_bind` then `call`) being replaced with one (`field_call`). Here are some numbers: +--------------+----------+----------+--------+ | File | Before | After | Change | +--------------+----------+----------+--------+ | Sema.zig | 4.72M | 4.53M | -4% | | AstGen.zig | 1.52M | 1.48M | -3% | | hash_map.zig | 283.9K | 276.2K | -3% | | math.zig | 312.6K | 305.3K | -2% | +--------------+----------+----------+--------+
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
2023-01-07std.crypto.siphash: add finalResult() and peek()Andrew Kelley
Useful for avoiding mutable state when using this API.
2022-12-13update usages of `@call`Veikka Tuominen
2022-05-16Fixes comptime 'error: cannot assign to constant' error in siphash.Felix "xq" Queißner
2021-11-20std: add `writer` methods on all crypto.hash types (#10168)Meghan
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-08std: update usage of std.testingVeikka Tuominen
2021-02-02fix typo in commentRocknest
2021-02-02siphash: update the link to the SipHash paperFrank Denis
2020-12-31Year++Frank Denis
2020-10-17std/crypto: make the whole APIs more consistentFrank Denis
- use `PascalCase` for all types. So, AES256GCM is now Aes256Gcm. - consistently use `_length` instead of mixing `_size` and `_length` for the constants we expose - Use `minimum_key_length` when it represents an actual minimum length. Otherwise, use `key_length`. - Require output buffers (for ciphertexts, macs, hashes) to be of the right size, not at least of that size in some functions, and the exact size elsewhere. - Use a `_bits` suffix instead of `_length` when a size is represented as a number of bits to avoid confusion. - Functions returning a constant-sized slice are now defined as a slice instead of a pointer + a runtime assertion. This is the case for most hash functions. - Use `camelCase` for all functions instead of `snake_case`. No functional changes, but these are breaking API changes.
2020-09-16std.crypto siphash: fix assertion on the size of output bufferAndrew Kelley
the logic was backwards
2020-08-22Improve documentation on siphash recommended parametersFrank Denis
2020-08-22Promote hash/siphash to crypto/siphashFrank Denis
SipHash *is* a cryptographic function, with a 128-bit security level. However, it is not a regular hash function: a secret key is required, and knowledge of that key allows collisions to be quickly computed offline. SipHash is therefore more suitable to be used as a MAC. The same API as other MACs was implemented in addition to functions directly returning an integer. The benchmarks have been updated accordingly. No changes to the SipHash implementation itself.