deajan
commented
1 year ago I guess I found the offending line, in https://github.com/nextcloud/desktop/blob/e83c2c86e699b39d8c93f721da1824f6117020c9/src/libsync/clientsideencryption.cpp#L1380 where specifically SHA-1 is used.
I'm not a C++ guy, but I've seen that evp_sha1() and evp_sha256() functions both exist in the source code.
Mind having a look at this ? I cannot imagine using E2EE without proper encryption settings.
Also, I've seen in https://github.com/nextcloud/desktop/blob/e83c2c86e699b39d8c93f721da1824f6117020c9/src/libsync/clientsideencryption.cpp#L1284 that a 2048 bits RSA key is used. Since the certificates are signed for 7300 days in NC server, that gives us certificate validity until 2030. Security specialsts say that 2048 bits keys won't be secure anymore by those dates.
Here's a quick speed test between 2048, 3072 and 4096 bit keys on a Xeon 6338 hosted VM:
# openssl speed rsa2048 rsa3072 rsa4096
version: 3.0.7
built on: Thu Jul 13 00:00:00 2023 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" -DREDHAT_FIPS_VERSION="\"3.0.7-38f89367593abbfc\"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"
CPUINFO: OPENSSL_ia32cap=0xfffa32274fabffff:0x415f5ef1bf07ab
sign verify sign/s verify/s
rsa 2048 bits 0.000442s 0.000026s 2261.9 38745.5
rsa 3072 bits 0.002708s 0.000055s 369.3 18232.5
rsa 4096 bits 0.006066s 0.000094s 164.9 10668.4As you can see, signature is really slower between various RSA keys (factor 6 up to 13), but verification speed isn't that highly impacted (factor 2 to 3).
So I'm advocating to higher the default RSA key size to at least 3072 bits to be future proof.
[EDIT] I've (quickly) read the rest of your encryption code. Looks like the code uses RSAES-OAEP with MGF1 mask generation, with a SHA256 hash for RSA encryption, and AES-GCM for symmetric encryption under the hood.
Both algorithm are secure AFAIK in 2023. But then again, AES-GCM key is 128 bits, which should be at least 256 bits to be "industry standard", ie being FIPS 140-2 validated.
Changing the RSA key size shouldn't have any implications as it would only be used for new encryption setups. Changing the AES key size would need to have a fallback scheme I guess, for 128 bit legacy keys. [/EDIT]
mgallien
⚠️ Before submitting, please verify the following: ⚠️
Bug description
I've been trying to activate E2EE for a couple of weeks now on a fresh NC 27 setup, without luck. After fidling around, I extracted the CSR sent by NC desktop app, and realized it uses SHA-1 algorithm.
Since my Nextcloud server is RHEL 9, it doesn't allow SHA-1 usage since Redhat deprecated it because of collision attacks (beginning with 2011, more viable attacks succeed in 2019).
So far, I cannot get E2EE to work unless I reconfigure my server to allow legacy crypto algorithms, which I obviously won't.
Steps to reproduce
Expected behavior
NC Desktop client should generate a 2048 bits (or 4096) private key, and create a CSR based on that key, using SHA-256 hashing algorithm. This CSR can be signed by current versions of openssl.
Which files are affected by this bug