Leaderboard

@kbps Hello! Not really, because the feature is included in our WireGuard setup since the very beginning, when we offered WireGuard as a beta feature some years ago. If you want more information, please see here: https://www.wireguard.com/protocol/ In this way we can implement a recognized as quantum-resistant cipher if needed, according to our customers request . You may ask why don't you pick one PQ cipher right now? You already configured the most part! We have excellent reasons not to do so right now: It's premature. In spite of the hype, currently a quantum computer doesn't work for any practical purpose to break even the weakest encryption algorithm and in the last 40 years or so the expected date to have a working quantum computer capable to perform something more than basic arithmetic have been shifted decade after decade. Research has progressed more slowly than ultra-optimists expected. To break RSA 2048 in a reasonable time a rigorous simulation shows that you need at least 1 million (probably up to 10 millions) of physical qubit (you need probably at least 10'000 logical qubits, and due to the astronomically high error rate of qc, to rely on them you need ~ x100 physical qubits). Nowadays the biggest companies are struggling to beat 433 logical qubits qc (IBM promised 1000 logical qubits machine within the beginning of 2024). It hits performance. Some promising PQ ciphers use 64 KB or larger public and private keys and you will notice a performance hit if you have a Gbit/s line and you're used to the high performance our infrastructure is normally capable to provide. The load both on server and client will increase. It exposes our customers to unnecessary risks. Post-quantum algorithms are far less well-studied. Any PQ algorithm, that today is considered safe, can be compromised tomorrow by "classical" computes.. It happened already to SIKE, which before the spectacular fall was considered one of the strongest and best algorithm for Diffie-Hellman key exchange in a post-quantum world. It was cracked in a matter of hours a few months ago with a program running in a single thread of a single core of a desktop CPU. SIKEp434 was broken within approximately an hour, SIKEp503 cracking required 2 hours, SIKEp610 8 hours and SIKEp751 21 hours. See also https://www.securityweek.com/nist-post-quantum-algorithm-finalist-cracked-using-classical-pc/ So, we have the infrastructure ready to add a PQ cipher, when and above all if it will be necessary, without exposing you to risks of cracking by classical computers and/or "performance hit for nothing". Kind regards

Hello! Nowadays, traffic shaping is a common practice. Several ISPs have evaluated that investing in traffic shaping techniques is better than investing in infrastructure expansion. Overselling becomes easier and the devastating congestion impact gets mitigated by enforcing penalties to all protocols which are rarely used by the majority of customers or that are more onerous for the infrastructure. Protocols and traffic types are discovered in real time via SPI and DPI. A VPN impairs traffic shaping techniques because it makes both SPI and DPI impotent. Therefore, ISPs that share the above vision (wild overselling and traffic shaping) need to shape VPN themselves, unconditionally. OpenVPN has a typical fingerprint, so it's easy to identify it with DPI. However, we provide connection modes which make OpenVPN not discernible. The most effective and at the same time efficient is a connection with "tls-crypt" which encrypts the whole OpenVPN Control Channel. It is available on entry-IP addresses 3 and 4 of our VPN servers. Please test the following one (in Eddie desktop edition): - from Eddie main window select "Preferences" > "Protocols" - untick "Automatic" - select the line with entry-IP address 3, port 443, protocol TCP. The row will be highlighted in blue - click "Save" tls-crypt will circumvent specific OpenVPN shaping, while TCP will get rid of UDP shaping, which is another commonly targeted protocol. UDP might be shaped or not in your line, so it's worth that you try it too. Eddie Android edition 2.0 connects to entry-IP address 3 by default. You might anyway need to change the protocol from UDP to TCP in the "Settings" if UDP is throttled. Kind regards