| Age | Commit message (Collapse) | Author |
|---|
|
This allows us to support parsing and serializing BigIntegers to and
from any base N (such that 2 <= N <= 36).
|
|
The fact that this always reads 16 bytes from the input byte stream
for the key data is still a bit on the suspicious side, but at least
it won't crash UBSAN anymore.
|
|
This patch adds support for the NumericLiteralSeparator concept from
the ECMAScript grammar.
|
|
Because MD5 stored a "Bytes {}" wrapper to its internal data buffer,
it was not actually movable. However, its use in several parts of
the system (such as HashManager) assumed it was, leading to crashes.
Fixes #8135
|
|
These can be used to create BigInteger instances from non-decimal
number strings.
|
|
|
|
|
|
These just use hash the underlying bytes that make up the integer words
|
|
Previously ByteBuffer::grow() behaved like Vector<T>::resize().
However the function name was somewhat ambiguous - and so this patch
updates ByteBuffer to behave more like Vector<T> by replacing grow()
with resize() and adding an ensure_capacity() method.
This also lets the user change the buffer's capacity without affecting
the size which was not previously possible.
Additionally this patch makes the capacity() method public (again).
|
|
This only affects malformed RSA keys. Instead of accepting and
continuing with potentially broken pointers (and in ASAN, crashing), we
now consider bitmaps malformed, and stop parsing.
Found by OSS Fuzz: #31698, long-standing-bug:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31698
Fun fact: The "if" only exists because of OSS Fuzz.
8cc279ed74dc0b16a187052d2454c26c8c6ecaf2
|
|
And simplify the code _even further_!
|
|
|
|
|
|
|
|
This is a truncated version of SHA-512, so it was fairly trivial.
|
|
Problem:
- Static variables take memory and can be subject to less optimization
(https://serenityos.godbolt.org/z/7EYebr1aa)
- This static variable is only used in 1 place.
Solution:
- Move the variable into the function and make it non-static.
|
|
|
|
Problem:
- Clang ToT reports an error because `digest_size` cannot be evaluated
at compile-time.
Solution:
- Change from using the member function to the `static` shadow of the
NTTP.
|
|
|
|
The algorithm isn't explicit about what type this needs to be. But this
passes all of the tests, so that's probably fine.
|
|
This adds an `AK::ByteReader` to help with that so we don't duplicate
the logic all over the place.
No more `*(const u16*)` and `*(const u32*)` for anyone.
This should help a little with #7060.
|
|
Just take ReadonlyBytes instead of a raw pointer.
Fixes #7072 (tested with the ASAN build fixed by #7060).
|
|
We never really needed the 512 words in the first place, and this does
reduce the stack allocations in montgomery modular power from 32Kb to
a more manageable 2Kb :^)
Note that the 32 words size doesn't provide any performance benefits or
drawbacks compared to other values. All values seem to have equivalent
performances (the tested values were 1, 2, 4, ..., 512). But since the
previous value of 512 was definitely too big, let's reduce it for now!
|
|
This algorithm allows for much faster computations of modular powers
(around a 5x-10x speedup of the Crypto test). However, it is only valid
for odd modulo values, and therefore the old algorithm must be kept for
computations involving even modulo values.
|
|
This new operation is immediately used in several existing algorithms.
|
|
This makes it clearer which variables are operating on words instead
of directly operating on raw values.
|
|
Since the operations are already complicated and will become even more
so soon, let's split them into their own files. We can also integrate
the NumberTheory operations that would better fit there into this class
as well.
This commit doesn't change behaviors, but moves the allocation of some
variables into caller classes.
|
|
This is working fine for TLS because we have a big enough inline
capacity, but in theory we could have crashed at any time even with
our 512 words of inline capacity.
|
|
Resolves part of #7071.
|
|
This removes all uses of VLAs with either Vectors with inline capacity
for the expected soft upper bound, or the occasional heap allocation.
|
|
|
|
|
|
|
|
I've wasted a silly amount of time in the past fretting over which
of these words to use. Let's just choose one and use it everywhere. :^)
|
|
We had some inconsistencies before:
- Sometimes "The", sometimes "the"
- Sometimes trailing ".", sometimes no trailing "."
I picked the most common one (lowecase "the", trailing ".") and applied
it to all copyright headers.
By using the exact same string everywhere we can ensure nothing gets
missed during a global search (and replace), and that these
inconsistencies are not spread any further (as copyright headers are
commonly copied to new files).
|
|
|
|
|
|
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
|
|
Problem:
- `constexpr` functions are additionally decorated with `inline`
keyword. This is redundant since `constexpr` implies `inline`.
Solution:
- Remove redundancies.
|
|
|
|
|
|
It's much easier to debug things when we can actually *see* them :P
|
|
This is useful for parsing non-universal types.
|
|
|
|
This flag warns on classes which have `virtual` functions but do not
have a `virtual` destructor.
This patch adds both the flag and missing destructors. The access level
of the destructors was determined by a two rules of thumb:
1. A destructor should have a similar or lower access level to that of a
constructor.
2. Having a `private` destructor implicitly deletes the default
constructor, which is probably undesirable for "interface" types
(classes with only virtual functions and no data).
In short, most of the added destructors are `protected`, unless the
compiler complained about access.
|
|
If we don't limit the sizes of the intermediate results, they will grow
indefinitely, causing each iteration to take longer and longer (in both
memcpy time, and algorithm runtime).
While calculating the trimmed length is fairly expensive, it's a small
cost to pay for uniform iteration times.
|
|
Good-bye LogStream. Long live AK::Format!
|
|
|
|
There cannot be more unused bits than the entirety of the input.
Found by OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31706#c1
|
|
|
