ValdikSS [Thu, 26 Jun 2025 14:24:28 +0000 (10:24 -0400)]
tls: Set TLSv1.3 ciphers to preserve ciphersuites order
This commit fixes two issues:
1. ciphers.inc has TLSv1.3 ciphers prefixed with "TXT", while current version
has "RFC". TLS1_3_RFC_AES_128_GCM_SHA256 should be instead of
TLS1_3_TXT_AES_128_GCM_SHA256, in both define and CIPHER() macro.
2. Tor calls only SSL_set_cipher_list() in tlstls_openssl.c, this sets only
TLSv1.2 ciphers, while TLSv1.3 ciphers stay in default state. TLSv1.3
ciphersuites are set with SSL_set_ciphersuites(), but the list require to
contain only TLSv1.3 suites (no v1.2).
Contrary to SSL_set_cipher_list(), TLSv1.3 SSL_set_ciphersuites() does NOT
accept finalizing :, so it should be stripped out.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Waldemar Zimpel [Mon, 9 Jun 2025 12:07:33 +0000 (14:07 +0200)]
Logging / Channel padding delay
Reduce the amount of messages being logged related to
channel padding delay when log level is "notice".
Log the channel padding delay as "info" as soon as the
delay occurs. Log "notice" on each heartbeat only
containing the average channel padding delay and the
amount of delays (that exceeded the allowed time window)
occurring between heartbeats or, if first heartbeat
since startup, between startup and heartbeat.
Nick Mathewson [Tue, 10 Jun 2025 16:29:40 +0000 (12:29 -0400)]
Remove circuit_sendme_cell_is_next
We needed this function previously, when we only computed a SENDME
tag conditionally, depending on whether we were about to need it.
But as part of the CGO refactoring, we now compute and store SENDME
tags unconditionally, whenever a cell is originated or recognized.
Therefore this function is no longer needed anywhere.
Nick Mathewson [Mon, 2 Jun 2025 21:05:08 +0000 (17:05 -0400)]
Make extend_info_supports_ntor_v3 correct.
Previously it returned true if the extend_info was for an exit where we
intended to use congestion control, which is not exactly the same thing
as supporting ntor v3.
Nick Mathewson [Wed, 28 May 2025 14:02:38 +0000 (10:02 -0400)]
Refactor and simplify save_sendme logic in tor1.
Every time that we want a sendme_digest, we have already computed it
once, either to originate a cell or to recognize a cell. Rather
than figuring out when to compute the digest a second time, we
instead refactor our tor1 digest code to _always_ store such digests
in the relay_crypto_t.
This saves a bit of complexity, and shouldn't involve a performance
hit; rather, it has potential to speed things up by saving a sha1
call.
Nick Mathewson [Wed, 28 May 2025 12:27:58 +0000 (08:27 -0400)]
Rename two "record_*_digest functions to "save".
This makes an important distinction: "recording" a digest puts
it in the expected-sendme queue, whereas "saving" a digest makes
a temporary copy inside the relay_crypto_t.
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.
projects / thirdparty / tor.git / log
