You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The chacha20 family of ciphers are not considered insecure, and are an order of magnitude more efficient on servers that do not provide hardware acceleration for AES encryption (like all the raspberry pi models). Wireguard uses this cipher, it has been thoroughly analyzed and considered to be secure, so I see no reason why ChaCha20 should not be added to this list:
Unfortunately this was not enough to fix the issue, seadroid seems to not be able to parse the certificate or get any of its parameters thus it prompts me to authorize this "unknown" certificate. The default android certificate store is able to handle connections using these ciphers, as google chrome and Firefox do not have any problems connecting to the site, so we should check on the custom logic that has been put into seadroid to handle certificate exceptions for things like self signed certs and make sure those are also compatible.
Here's a screenshot (Spanish) if what this error looks like:
Adding TLS 1.3 support to the app should fix this. There is even a corresponding pull request available (#913), that would fix the problem once it gets merged.
The chacha20 family of ciphers are not considered insecure, and are an order of magnitude more efficient on servers that do not provide hardware acceleration for AES encryption (like all the raspberry pi models). Wireguard uses this cipher, it has been thoroughly analyzed and considered to be secure, so I see no reason why ChaCha20 should not be added to this list:
seadroid/app/src/main/java/com/seafile/seadroid2/ssl/SSLSeafileSocketFactory.java
Lines 112 to 148 in da6bc0c
This could be a massive performance buff for Raspberry Pi 4s running seafile with https on a gigabit lan.
Link to this topic in the forums:
https://forum.seafile.com/t/use-chacha-encryption-algorithms-instead-of-aes-for-https/14201/5
The text was updated successfully, but these errors were encountered: