djb provided a link in his blog post to a long history of ECDSA side channel vulnerabilities in ECDSA implementations.[1] It's not that RSA implementations weren't prone to side channel vulnerabilities either[2], but more with EdDSA/X25519, side channel vulnerabilities have finally been largely addressed through design and standardisation, and now PQC proponents are reversing this gain and repeating the mistakes of ECDSA and ignoring side channel vulnerabilities in design and standards.
What's more likely right now:
- Your cryptosystem is compromised at some point in the future if/when quantum computers exist and can effectively attack EdDSA/X25519. Something no one has yet demonstrated or come close to demonstrating.
- Someone implementing PQC in a library/software/hardware follows the standard which does not care at all about side channel resistant implementation of critical algorithms, resulting in your private keys being leaked. Demonstrated repeatedly over 20+ years.
eh, lattice-based stuff is the first time public-key crypto can use word-size arithmetic, vs full bigint (RSA), or "just" 256+bit arithmetic. it's significantly easier to get right in a side-channel resistant way.
this isn't to say everything will go perfect, but the people doing implementations are more experienced now, and the problem is an easier one to do (though in a certain sense, optimizing compilers are making any side-channel resistance a harder goal to achieve. an implementation that is resistant under one compiler version may not be resistant in the future).
ML-KEM encaps/decaps is very fast, as fast/faster than EC. It's large, and adding EC does not meaningfully affect the size, but it meanfully affects encaps/decaps time.
> Only one generation stuck out to me. Simply asking it to make it look like a Qt app - to my tasteless eyes - removed almost all feeling of slop. You can check some of the results out [here](https://envs.net/~volpe/projects/ai-design.html).
All of these examples sites are broken on mobile for me.
The way it automatically connects to your home and presents to your devices as part of your home WiFi. So you bring that device with you and everything else works like you're back home.
I use OPNSense and OpenWRT myself and there's no way you can make travel routers this convenient with them.
Tailscale running in subnet router mode on a GL.iNet router comes close. You can setup Tailscale through the GL.iNet GUI but to have it also route traffic for everything over to your Tailnet you need to flip one setting via an ssh command.
Not as convenient as this travel router sounds though, but comes close-ish for techies. (wish it didn't require that tweak via SSH. Maybe it'll be added)
I wish Eero offered this feature. I bring three eeros to Airbnb’s to replace their crappy WiFi with my same SID, but it would be nice if it connected back through the home internet.
hah, 2nd time in the last couple months I've been compared to that LEGENDARY Dropbox comment...
In my defense, I'd argue that the average Tailscale user would be comfortable running an SSH command! And GL.iNet is just one very minor tweak away to making this entirely possible from the GUI. (though they might be intentionally avoiding it because of the support burden of quirks caused by Tailscale acting as a subnet router...)
Why do you think this would be difficult to do using openwrt? Wouldn't you just set up the travel router to have the same ssid and password as your home network and configure a wireguard tunnel from the travel router to your home network (that is if you want to be in your home network)
Because manually configuring wireguard tunnels on random devices is a simple task for most people lol. Unifi’s whole stack is all about making powerful tools easier to use for people who don’t want to fuck around with networking.
Agreed. I use Tailscale (which the gl.inet devices support, because they're basically a pretty front end for OpenWRT, and it supports Tailscale) for my stuff, because I can do it and it's not a real pain to do, but you do have to know a bit at least about networking. This thing looks extremely promising for the "I know this should be possible and I want to do it but have no idea how" level of knowledge as well as the "I want to spend as little time as possible on configuring things" people.
But you don't need to configure wireguard on the individual devices just on the openwrt router. That's one device and you can keep that on permanently.
Except that sometimes you can’t. I don’t know if the Unifi router checks for this, but I’ve run into more than one network where the VPN conflicted with either the captive portal or the wireless network itself (and at least one in the DFW Admiral’s club that had draconian blocking)
Although it does sound really nice from a user experience perspective I'm really hesitant with carrying a device with me that without any (additional) authentication would gain access to my home network wherever you plug it in. Would hate losing it or have it be taken from me.
Why would you assume there's no additional authentication imposed? You definitely need to establish a connection wherever you are, and most likely you do using a dedicated and pre-authenticated app on your phone.
In a 1 bit environment (==single SSID visible), sure. But most of the time multiple SSIDs are visible, and correlate to each, making detection of abnormalities easier. And the lat/long is also visible to help disambiguate.
It probably needs a panic/border mode to disable all home access in the event of an emergency. You don't want to be crossing borders and give customs officials full access to your home network.
They took an action with the intent of making the website inaccessible in China.
It is political, and it is satirical, and it is discrimination. Better to argue that it is righteous discrimination than that there was no discriminatory intent.
I thought so when I was younger, but I’ve found that it’s often considered worse than words like ‘idiot’ or ‘twit’. Some seem to find it — to my surprise — not just insulting, but crude.
Software bugs is a weak argument for a new hybrid standard, and doesn't justify the additional complexity.
reply