The whole point of this article is that performant Wireguard-over-TCP support in Wireguard simply does not work. You're not fighting the prevalence of an idea, you're fighting an inherent behavior of the system as currently constituted.
In more detail, let's imagine we make a Wireguard-over-TCP tunnel. The "outer" TCP connection carrying the Wireguard tunnel is, well, a TCP connection. So Wireguard can't stop the connection from retransmitting. Likewise, any "inner" TCP connections routed through the Wireguard tunnel are plain-vanilla TCP connections; Wireguard cannot stop them from retransmitting, either. The retransmit-in-retransmit behavior is precisely the issue.
So, what could we possibly do about this? Well, Wireguard certainly cannot modify the inner TCP connections (because then it wouldn't be providing a tunnel).
Could it work with a modified outer TCP connection? Maybe---perhaps Wireguard could implement a user-space "TCP" stack that sends syntactically valid TCP segments but never retransmits, then run that on both ends of the connection. In essence, UDP masquerading as TCP. But there's no guarantee that this faux-TCP connection wouldn't break in weird ways because the network (especially, as you've discovered, any cloud provider's network!) isn't just a dumb pipe: middleboxes, for example, expect TCP to behave like TCP.
Good news (and oops), it looks like I've just accidentally described phantun (and maybe other solutions): https://github.com/dndx/phantun I'd be curious if this manages to sidestep the issues you're seeing with AWS and OVH.
One of the fun things about the median-of-medians algorithm is its completely star-studded author list.
Manuel Blum - Turing award winner in 1995
Robert Floyd - Turing award winner in 1978
Ron Rivest - Turing award winner in 2002
Bob Tarjan - Turing award winner in 1986 (oh and also the inaugural Nevanlinna prizewinner in 1982)
Vaughan Pratt - oh no, the only non-Turing award winner in the list. Oh right but he's emeritus faculty at Stanford, directed the SUN project before it became Sun Microsystems, was instrumental in Sun's early days (director of research and designer of the Sun logo!), and is responsible for all kinds of other awesome stuff (near and dear to me: Pratt certificates of primality).
Four independent Turing awards! SPARCstations! This paper has it all.
Turns out, Niall was also involved in one of the winning ZPrize submissions for fast multi-scalar multiplication (closely related to batch modexp, although over an elliptic curve rather than mod a prime); I assume it inherits from his work on CGBN.
He give a very nice talk about it last year at a Stanford crypto lunch, and it turns out the slides and recording are online!
Maybe we're looking at different things, but the link appears to discuss ElGamal encryption, which is discrete log based (which means modern implementations use elliptic curves; historically it would have been discrete log in a subgroup of a large prime field). It also talks about BLS signatures, which are exclusively elliptic curve based.
By and large, anything whose security relies on discrete log can be implemented using an elliptic curve, but beginning cryptography classes treat that as an implementation detail because mostly all you need is a prime-order group, and elliptic curves can mostly be treated as a black-box prime order group.
(BLS signatures are an exception; they require a bilinear pairing, which in turn requires a special kind of elliptic curve that's not just a black-box prime order group.)
There are all sorts of great algebraic geometry tricks to be played with elliptic curves, but those almost certainly aren't going to be found in an intro crypto class, or maybe any CS class...
EdDSA signatures are specified to use deterministic nonce generation, so you're correct that they do not require randomness. But they certainly do require modular arithmetic in order to implement the elliptic curve operations!
RFC6979 attempts to guarantee that the nonce is unbiased (under the assumption that HMAC's output is indistinguishable from random). It's definitely attempting to give a stronger property than simply preventing a repeated nonce.
See step (h) in Section 3.2. The nonce is selected by rejection sampling. Thus, under the above assumption about HMAC, the result is indistinguishable from uniformly random in the [1, q-1] range.
The nonce is taken modulo the order of the prime-order subgroup. For DSA that's generally a 256ish-bit prime (e.g.: choose a 1024-bit prime p such that a 256-bit prime q divides p-1; then there exists an order-q subgroup of Zp).
For P-521, the base field is 2^521 - 1, but the modulus used when computing the nonce is not that value, it's the order of the P-521 curve. By Hasse's theorem, that's roughly p +- sqrt(p), which is essentially p for such large numbers (the cofactor of P-521 is 1, so the order of the group is prime).
So: both are 521-bit numbers, but the group order is less than 2^521-1. Its hex representation is 0x01fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffa51868783bf2f966b7fcc0148f709a5d03bb5c9b8899c47aebb6fb71e91386409.
This vulnerability has very little to do with P-521 per se. The issue is with ECDSA: any use of ECDSA with biased nonce generation, regardless of the elliptic curve it's implemented over, immediately causes secret key leakage.
(Rant: All these years later, we're all still doing penance for the fact that Schnorr signatures were patented and so everyone used ECDSA instead. It's an absolute garbage fire of a signature scheme and should be abandoned yesterday for many reasons, e.g., no real proof of security, terrible footguns like this.)
I'm sorry to say that your analysis is wildly incorrect.
- 10 billion people =~ 2^33
- 1000 CPUs =~ 2^10
- 1024 cores =~ 2^10
- 10 GHz =~ 2^33
So: one second's computation by all of these people is 2^86 UUIDs generated. UUIDs are 128 bits. With probability essentially 1, there will be a collision within one second.
The reason is known as the birthday paradox. If you sample random values from a set of size k, after you've chosen about sqrt(k) values you will have chosen the same value twice with probability very close to 1/2. By 10*sqrt(k) samples you'll have found a collision with probability well over 90%.
In this case, after sampling 2^64 values you'll have a collision with probability 1/2. That happens in roughly 250 nanoseconds (2^-22 seconds) in your thought experiment.
2^64 sounds like a lot, but in many contexts it's not all that much. Every bitcoin block mined takes well in excess of 2^70 SHA evaluations. Obviously the miners are not dedicated to generating UUID collisions, but if they were they'd easily find thousands of them in the time it takes to mine one block (this neglects the fact that it is much easier to sample a UUID than to evaluate double-SHA256).
The example you give is similar to but not quite the same as "lzAES". The distinction is that in your example, the application is deciding whether to compress or not---the input/output behavior of the cipher doesn't include the compression step, so the cipher it self doesn't suffer from the problem I mentioned in my first note.
But it's still possible for an application to use a cipher incorrectly. In particular, an application-level decision about whether to compress some data before encrypting can have an effect on the application's security. In the case you mention it seems unlikely to be a problem (but that's an application-level question, so it could be).
As an example where it seems like the application-level decision to compress or not matters a lot, imagine an application that sends an encrypted password to a server. If the application compresses the password first, an attacker could learn which values are not my password via guess-and-check-length. (Of course, even without compression the attacker can learn something about the length of my password just by looking at the length of the ciphertext---so probably this is a case where the application should first pad the message to some fixed length before encrypting. But in any case it almost certainly shouldn't compress the password!)
Yes, a correct encryption algorithm can encrypt (essentially) any bit string. But it's quite easy to turn a correct encryption algorithm into an incorrect one by bolting on something seemingly innocuous.
Here's a concrete example. Let's say you decide you want to make AES encryption more efficient by defining a new standard, "lzAES", that is just:
This "works", in the sense that you can correctly decrypt ciphertexts, and it certainly seems innocuous. But it is now an insecure cipher!
Here's why: the definition of a secure cipher is that ciphertexts resulting from the encryptions of any two messages of equal length are indistinguishable. In other words, for any two messages you can choose, if I encrypt both messages under a randomly generated key, you can't tell which ciphertext corresponds to which message. In contrast, lzAES as defined above does not have this property: you could choose one message that's easily compressible (say, a string of zeros) and one that's not (say, a uniformly random string), and then you'd be able to tell which ciphertext corresponds to which plaintext just by looking at the ciphertext lengths.
And this is not just a definitional issue! If you use lzAES to encrypt something, an attacker can guess your message and test whether compressing the guess gives the same length as your ciphertext. Guess-and-check isn't possible with a secure cipher, but it is with lzAES---in other words, it gives away information about your plaintext!
The paper, which is linked from the article, demonstrates a browser "fingerprinting" attack, which is to say, stealing pixels from one iframe using another iframe (which is quite clearly a violation of the safety properties the browser is supposed to provide).
It's unfortunate that this article is poor, but the paper itself is clear and readable.
I completely understand your position, and I'm certainly sympathetic that it's often hard to find good instructional materials. I'll readily admit, however, that I do not know Chegg as anything but a way to cheat. It is well known among the university-level educators I've spoken with (across several institutions) as the place that students go to find material for cheating.
So while it may not be the case that all users of Chegg are cheating, at some schools essentially all cheaters are using Chegg, including to cheat on exams (students post course bibles, test banks, etc.).
It doesn't help that Chegg is slow to take down materials even when explicitly told that the material was obtained illegitimately (which makes sense---empirically, illicit materials are the draw for at least some segment of their customers). I know several folks who have had to involve their university's legal team to get their course materials removed from the site.
Yes, dc/dc conversion is definitely applicable in high-power applications. As one example, high-voltage DC power transmission [1] is in widespread use globally, and always requires a dc/dc conversion step for connection to local grids. In addition to dc/dc conversion during transmission, converting from DC to AC (known as inversion) uses essentially the same techniques.
To answer your question more directly: stepping a battery's output to 10 kV is a good example of an application that would almost always be done with a dc/dc converter in an industrial application.
(Aside: "without an AC step" is slightly tricky. If by AC you mean 50 or 60 Hz, definitely can and should be avoided. But AC is generally used to refer to any non-constant voltage or current, and if that's what you mean then the answer is no since a dc/dc converter works by switching, which by definition means there's some sinusoidal voltage somewhere in the circuit.)
(Source: I used to design integrated circuits for industrial control.)
Well, for one, UDP brings the U. It's called the User Datagram Protocol because (at least on UNIX-like systems) unprivileged programs can almost always send and receive UDP datagrams, but in general cannot send and receive raw IP datagrams.
This memo specifies T/TCP, an experimental TCP extension for
efficient transaction-oriented (request/response) service. This
backwards-compatible extension could fill the gap between the current
connection-oriented TCP and the datagram-based UDP.
I have no illusions about the likelihood it'll ever see use, but I've always thought T/TCP was cool and fun.
Do you have a source for this? I'd really love to read more about it.
My impression from Ray's congressional testimony was "FTX.us might be solvent, but we don't know yet because the forensic accountants are still chipping away". But I was only half focused and am not confident I remember correctly.
But the circuit topology here can't meaningfully be called a discrete implementation of an LM386, unless by LM386 we just mean "a two-stage op-amp capable of driving a small speaker." The two circuits may have the same goals, but they're completely different designs (and the LM386 is a much better design---no shame in that, considering it's professional versus hobbyist).
The simplified diagram of the LM386 shown on Hackaday's website (which appears to be reproduced from the TI datasheet [1]) shows a few distinctive features that the discrete circuit lacks, and which result in better performance; and we can guess at some other details that are probably lost in the simplification.
- The LM386 input devices are a differential pair of PNP Darlingtons [2]. The Darlingtons are there partly because PNPs have worse current gain than NPNs, but they're also a conscious choice that allows the amplifier to be powered from a single supply while taking in a DC-coupled signal that's referenced to ground: the signal inputs (pins 2 and 3) can safely go below ground by roughly a diode drop, by design.
- In contrast, the linked discrete implementation uses NPN transistors for the input diff pair (Q1 and Q2), which means that it requires a separate R-C biasing network (C2, R7, R11, R12) and also means that the bias current in the diff pair depends on the power supply voltage (making power supply rejection tough).
- The LM386 uses a pair of NPNs in the first stage to effect a differential to single-ended conversion. The simplified diagram doesn't show it, but I'd bet that the real circuit matches the bias current in the output stage (the current source above the two diodes in the middle-right of the simplified schematic) with the current through the input stage, in order to hold the collector of the right NPN transistor at roughly the same DC voltage as the collector of the diode-connected NPN [3] on the left. This minimizes mismatch due to finite output impedance of the NPN transistors [4].
- In contrast, there's no differential to single-ended conversion in the discrete circuit. Q2's gain is essentially thrown away, the signal is taken from R4, and there's no attempt to match the collector voltages of Q1 and Q2 (adding a diode-connected device between Q2's collector and the supply would improve matching).
Again: I love when folks build and release their discrete circuit designs! I've done the same multiple times (here's a fun one [5]). It would have been better for the author (and Hackaday) to leave the LM386 out of this.
Finally, it seems like the author didn't actually build the device, just simulated it. I probably wouldn't build the discrete circuit as described. It's going to have some performance issues (poor power supply rejection is one) and will be quite sensitive to temperature, device characteristics, etc.---all things that one should try to minimize in a design.
In more detail, let's imagine we make a Wireguard-over-TCP tunnel. The "outer" TCP connection carrying the Wireguard tunnel is, well, a TCP connection. So Wireguard can't stop the connection from retransmitting. Likewise, any "inner" TCP connections routed through the Wireguard tunnel are plain-vanilla TCP connections; Wireguard cannot stop them from retransmitting, either. The retransmit-in-retransmit behavior is precisely the issue.
So, what could we possibly do about this? Well, Wireguard certainly cannot modify the inner TCP connections (because then it wouldn't be providing a tunnel).
Could it work with a modified outer TCP connection? Maybe---perhaps Wireguard could implement a user-space "TCP" stack that sends syntactically valid TCP segments but never retransmits, then run that on both ends of the connection. In essence, UDP masquerading as TCP. But there's no guarantee that this faux-TCP connection wouldn't break in weird ways because the network (especially, as you've discovered, any cloud provider's network!) isn't just a dumb pipe: middleboxes, for example, expect TCP to behave like TCP.
Good news (and oops), it looks like I've just accidentally described phantun (and maybe other solutions): https://github.com/dndx/phantun I'd be curious if this manages to sidestep the issues you're seeing with AWS and OVH.