I guess we know why Intel tried on that benchmarking restriction. Serving static content from Nginx is a 22% drop on Intel, a 7% drop on AMD. That's huge for cloud providers!
2,088 karma · joined April 16, 2016
a) its not supported by the stable release
b) There are no claims about downgrade resistance. The manual specifies the new transport protocol is used if both clients support it and both have changed their configs to enable experimental mode. Can an attacker still force them to connect with legacy mode?
c) Users have to ensure every single config on every client has the correct setting.
d) It still doesn't have the identity hiding features of Wireguard. (Someone observing your network traffic can see which servers you are talking to from the transmitted signatures)
https://www.tinc-vpn.org/documentation/Security.html#Securit...
The default cipher is from 1993 and its creator recommends everyone updates.
32 bit MACs are hilariously tiny.
Home rolled authentication based around RSA.
Their own documentation even states: ”tinc’s security is not as strong as TLS or IPsec."
DO NOT USE tinc!
Wireguard authenticates (or drops) any packets forwarded by udptunnel. Once a packet leaves the Wireguard interface the attacker (or anyone else) can transform it however they like without impacting security properties.
This config does allow the attacker to make a TCP handshake to the server, but the data they send over the TCP wrapped connection could have equally been sent to the UDP port Wireguard is listening on.
Disclaimer: This of course assumes both Wireguard and udptunnel have no remote code exploits or other implementation errors. However, as we discussed, this is a much safer assumption than OpenVPN...
http://manpages.ubuntu.com/manpages/xenial/man1/udptunnel.1....
Setup Wireguard on your server as though everything were normal. However, on the server, run this command (as a service):
udptunnel -s 443 127.0.0.1/51820
Then on your client run:
udptunnel -c [SERVER-ADDR]/443 127.0.0.1 51818
In the Client's Wireguard Config, where you would normally specify the server's address / port. Instead specify 127.0.0.1 51818. Finished!
Don't forget to open the firewall on the server's port 443!
Setting up udptunnel as a systemd service to auto start / restart only involves writing two short files! Wireguard uses a standard service file as well so you can simply require the udptunnel service as a prerequisite!
Personally, I find this style of combining simple components much more satisfying (and secure!) than the gargantuan complexity of OpenVPN/IPSec! Wireguard's simplicity means it is easy to have a mental model around how it functions and how it can be composed!
I also use Jottacloud [1] who provide unlimited (yes unlimited) storage for 7.5 EUR a month. Based in Norway, they keep an up to date warrant canary.
Client side, I backup to both of these services using Duplicati [2] which offers client side encryption, block level deduplication and excellent integration with Jottacloud and SFTP. For synchronisation, I use Syncthing [3] since I don't want to expose plaintext documents to Jottacloud. All in all, I'm very pleased and it has required no maintainence since I set it up a year ago.
[1] https://www.jottacloud.com/en/
The author writes that due to Google Play Services, most Android apps are in fact Google Play apps and couldn't be used on a non-Google version of Android without a significant rework. I believe there's already a significant body of work on providing drop in replacements for Google Play Services, e.g. microG [1]. There is nothing that stops a manufacturer from providing microG instead of Play Services and hence cutting Google out.
Secondly, the author complains that:
> More broadly, the European Commission continues to be a bit too cavalier about denying companies — well, Google, mostly — the right to monetize the products they spend billions of dollars at significant risk to develop.
There's a huge rift in how most Europeans and Americans see the role of regulators but without getting into that, I want to note Android was not Google's effort alone and hardly a significant risk. Android as a software stack is built on the back of the Linux Kernel and a dozen other open source frameworks (Java, sqlite etc). Equally, Google is hardly responsible for the hardware. Manufacturer's like HTC and Samsung invested far more in making Google a success than Google did. The same manufacturers that Google has been screwing over with its anti competitive practices...
Well its certainly beneficial for privacy. There are very few social media sites in the world where publishing other people's contact details without their permissions is allowed. Its banned here. Its banned on Reddit. And a ton of other sites. There is really very little difference.
How would you feel if all HN submitters had to list a personal phone number? Why is running a website any different?
Paraphrased:
Yes, of course you can keep registration data for your own legitimate usage. Contact information for the lifetime of the domain is fine.
Storing it for 2 years after expiry is not necessarily problematic, but you need to document why you legitimately need it.
You can't make private contact information public without consent.
However, you can disclose it to 3rd parties who make a legitimate request, but you should record the request.
Less tangibly, it can prevent an adversary from recording your traffic now, waiting until Quantum Computers are practical, breaking your public key crypto and reading your messages.
Sure, you can't just slap both modes together and claim the adversary has to break both, some care is involved, but it absolutely isn't strange at all.
tl;dr there are plenty of good reasons to use a combination of modes. Both Noise and Wireguard have built on support for strengthening public key crypto with psks.
Maybe I've misunderstood, but aren't Rust's closures [1] exactly what the author is describing? Specifically, you can capture variables from the environment into functions.
[1] https://doc.rust-lang.org/book/first-edition/closures.html
[...]
> You must ask people to actively opt in. Don’t use pre-ticked boxes, opt-out boxes or other default settings.
Source:
https://ico.org.uk/for-organisations/guide-to-the-general-da...
If I use this to communicate with a business (or person!), the carrier can read every word. No thanks.
Hell. You can't even download the standards documents without giving GSMA a name and address and consenting to receive promotional material...
https://www2.mst.dk/Udgiv/publications/2015/09/978-87-93352-...
But nonetheless, the number of people who are security conscious enough to lock their keys into their hardware, but not worried about malicious hardware seems quite limited.
E.g. http://paper.ijcsns.org/07_book/201006/20100623.pdf details how to do it for Elliptic Curves. But its been studied since https://link.springer.com/content/pdf/10.1007%2F3-540-69053-...
The tl;dr is that any device in which you can't check the implementation or get the private key out (i.e. Secure Enclave, TPM etc), can leak your key to a passive attacker in a way that you provably can't detect.
[1] http://www.whatclinic.com/dentists/uk/x-ray [2] http://www.nhs.uk/NHSEngland/Healthcosts/Pages/Dentalcosts.a...
They test an old version of Keepass with an old KDF (they recently switched to Argon2 which is much more resistant to GPU/ASIC attacks. Additionally KeepassDroid is intended to use vaults synched to the device via Google Drive, Dropbox or whatever, so having the vault in private storage makes no sense!
Some of the data from the Appendix on Equality pulled out. The difference between countries is quite astounding!
Sounds like reused passwords!
The key point is that qubits aren't limited to finite "multiple values", they can express an uncountable number of values. The best "short" answer is that a qubit can exist in a superposition (QM Term) of states. LOOSELY put it can have a probability of being a 0 and a probability of being 1 (with both probabilities adding to 1). This ability to encode information as the probability is the key to quantum computing.
When you measure (QM Term) the qubit, it takes on either the value 0 or 1 according to the probabilities you set it up with. This is computationally useful because with clever constructions you can make these probabilities meaningful.
For example Grover's Algorithm allows you to search an unsorted database for a particular item in O(sqrt(N)) time rather than the classical best O(N). The algorithm is successful with very high probability, note that because it uses the probabilistic nature of qubits, it itself can only be probabilistically correct, it just so happens you can make the probability of error very low (in theory lower than the chance your classical computer has a bit flip or similar)
The unfortunate restriction on QC is that you need enough qubits to encode your problem, if you can't hold the database in your "qubit memory" then you can't perform algorithm. In practice, building systems of qubits is extremely difficult and the current record is about 1000 as of 2015 I believe.