Nick Mathewson [Thu, 22 May 2025 13:54:09 +0000 (09:54 -0400)]
Fix a bug with less optimized polyval variants.
Using "0" to mean "doesn't support multi-block processing"
ran us into trouble: (n > 0 * 16) is always true for n > 0,
so we were always running a loop with no termination condition.
Additionally, the >s in this block should have been >=s,
since we want to process multi-blocks as long as there are any.
This won't have a performance impact for our current input sizes,
but it's nice to be correct.
Nick Mathewson [Thu, 15 May 2025 16:21:49 +0000 (12:21 -0400)]
Optimize the everloving heck out of OpenSSL AES as used by CGO.
Optimizations:
1. Calling EVP_CryptInit with a cipher returned by
e.g. EVP_aes_128_ctr() is quite slow, since it needs to look
up the _actual_ EVP_CIPHER corresponding to the given EVP,
which involves grabbing locks, doing a search through a
provider, and so on. We use EVP_CIPHER_fetch to speed
that up a lot.
2. There is not in fact any need to EVP_CIPHER_CTX_Reset a
cipher before calling EVP_CryptInit on it a second time
2. Using an ECB cipher + CRYPTO_ctr128_encrypt was not in fact
the most efficient way to implement a counter mode with an
adjustable IV. Instead, the fastest way seems to be:
- Set the IV manually
- Ensure that we are always aligned to block boundary
when we do so.
Nick Mathewson [Thu, 15 May 2025 14:00:21 +0000 (10:00 -0400)]
Speed up polyval through pipelining.
This optimization helps because:
- We're not blocking the computation of each block on the computation of the
previous one, which leads to fewer pipeline stalls.
- We're deferring reduction until the end of handling a bunch of blocks.
Nick Mathewson [Sun, 20 Apr 2025 22:17:22 +0000 (18:17 -0400)]
Support for counter mode with raw AES.
We'll want this for CGO because we want the ability to use the same AES
key several times with multiple different IVs: neither OpenSSL's EVP
interface nor NSS's PK11 API has a good interface to do that.
(This is usually expressed in terms of "seeking" to a new position
on the stream, but there isn't an API for that either.)
Nick Mathewson [Mon, 19 May 2025 01:11:00 +0000 (21:11 -0400)]
Fix a new GCC warning about strings.
When we say something like
```
const char foo[3] = "foo";
```
GCC now complains, because there is no space for the terminating NUL.
But we use this construction in a lot of places in our tests to
initialize test digests, keys, and so on. So to resolve the issue,
we have to mark these strings with a new attribute.
Nick Mathewson [Tue, 13 May 2025 12:39:42 +0000 (08:39 -0400)]
Fix linking on systems without a working stdatomic.h
Static libraries need to be sorted in a dependency order, with the
most low-level libraries last. When we added an atomic counter to
util_bug.c in !760, we introduced a dependency from "log" to
"threads". This didn't show up immediately, since the dependency
only exists when we're emulating atomic operations due to lack of
platform support.
Previously, one of these checks had the parentheses in the wrong
place, given an incorrect result. The code is hard enough to read
that I refactored both instances to be more obviously right.
I've grepped for similar errors elsewhere, but didn't find them.
Nick Mathewson [Tue, 6 May 2025 13:01:37 +0000 (09:01 -0400)]
Remove attempt to override TLS 1.3 server ciphersuites
This was unnecessary _and_ broken!
It was unnecessary because the default list of TLS 1.3 ciphersuites
has always been pretty reasonable.
It was broken because:
- SSL_CTX_set_cipher_list only affects the list of TLS 1.2 ciphersuites.
- There have _never_ been a set of macros named TLS1_3_TXT_*
in any openssl version, as far as I can tell.
Nick Mathewson [Tue, 6 May 2025 12:36:19 +0000 (08:36 -0400)]
OpenSSL: Require TLS ≥ 1.2
TLS 1.2 was added in OpenSSL version 1.0.1,
which was our minimal supported openssl version for a long time:
so we can be sure that all clients and relays have it.
(I'd like to require TLS 1.3, but that would break everybody
who built with 1.0.1.)
Nick Mathewson [Tue, 6 May 2025 00:38:55 +0000 (20:38 -0400)]
relay_msg: Document and enforce length invariants.
This takes a slightly different approach from suggested in the MR:
we document that a relay_msg_t must _always_ have a valid length,
and note that this warning still applies for relay_msg_copy.
Nick Mathewson [Fri, 18 Apr 2025 01:15:30 +0000 (21:15 -0400)]
Change relay_msg_t to _not_ hold a copy of the message.
Previously we had to memdup every time we parsed a relay_msg_t;
but that's unnecessary, since (most) every time we use it, we have
a longer-lived cell object.
This _did_ require some hacking in relay_msg_copy, but I think the
gain in simplicity is worth it.
Nick Mathewson [Fri, 18 Apr 2025 00:26:20 +0000 (20:26 -0400)]
Fix a bug in conflux_send_switch_command.
Using RELAY_PAYLOAD_SIZE(_MAX) here would send a relay message that used up
more than the actual length of the cell. Instead, send only the actual
CONFLUX_SWITCH message.
Nick Mathewson [Fri, 18 Apr 2025 00:21:06 +0000 (20:21 -0400)]
Rename and hand-audit all users of RELAY_PAYLOAD_SIZE.
Since the maximum number of bytes you can put in a relay message
is no longer constant, it doesn't make sense to have a "size" for this.
Instead, we can only have a "max" or "min" size.
Nick Mathewson [Thu, 17 Apr 2025 17:15:04 +0000 (13:15 -0400)]
prop359: Implement relay cell encoder/decoders
I decided not to use a codec-based approach here.
Since we aren't implementing prop340, there is exactly one cell
per message, so we don't need to keep any state
in between cells or messages.