serendipitous
serendipitous on Hacker News
> Now your cache/registers/SRAM are maintained. Power up with JTAG or a custom/debugging bootrom/mode that hopefully doesn’t overwrite much/any and dump away.
If you care about security, you'd be disabling these. Every product I've worked on disables JTAG and other debug features on production boards and enables secure boot.
To get 192-bit security with RSA you'd need 7680-bit RSA key and with ECC you need 384-bit key as mentioned in the article. That assumes classical attacks only. For quantum attacks, the smaller key sizes used with ECC do make it weaker.
What the article describes is not particularly difficult to implement. But claiming that storing the firmware in a way that prevents the user from updating it via software somehow makes the device more "free" is absurd.
> That's why so few of them tend to advertise transmit capabilities.
Any SDR that has transmit capability freely advertises it and there are many of them. The makers of one of them (bladeRF) also develops an open source 802.11 PHY that can run on their SDR's FPGA if you want to run an open source WiFi radio. (and you don't mind using $700 hardware to run older generation WiFi) Legality of the transmission may be a concern for users of the SDRs but is not for those selling them.
This polling is not done by the CPU, this is a common misconception. In a typical modern system the only polling that happens with USB is done by the USB host controller and only when there is actual data the host controller generates interrupts for the CPU to process it. Obviously, when you configure the mouse at higher frequency you will get more interrupts and hence higher CPU usage but that has nothing to do with the polling.
This has nothing to do with "weakening of ECC". Dual_EC_DRBG is an RNG that happens to use Elliptic Curves but its problems have nothing to do with that, they have to do with the design of the RNG itself. And those problems don't say anything about the strength of ECC used for encryption and digital signatures.
Yes, for a wifi client (like in the article) you're right. manuel_w was talking about bridging on the AP and for that you do just enable bridging and it works fine.
The 802.11 header has 4 MAC addresses: Source Address (SA), Destination Address (DA), Transmitter Address (TA), Receiver Address (RA). The TA and RA are those of the Wifi station and SA and DA are the Ethernet addresses. This allows bridging Ethernet and Wifi interfaces and it is how many (most?) Linux-based Wifi routers work.
> Until spoofing, amplification attacks on UDP are properly tackled
This is already addressed by QUIC (the transport protocol used by HTTP/3). Those things are no more of a problem for HTTP/3 than they are for HTTP/2 or HTTP/1.
Firewall changes are only needed if your firewall rules were unreasonable to begin with.
> connection tracking in routers may not work anymore
What do you mean by this? Tracking of UDP flows has been supported by routers for decades.
> if your users are untrusted and not under your direct administrative control (e.g. students in a dorm, hotel guests, et c) then default-allow-everything jeopardizes your upstream transit connection (e.g. if they start spamming).
How is that different from an ISP? Or do you think ISPs should also block everything except TCP ports 80 and 443?
The mathematics of Shor's algorithm have been known for decades. The challenge is in building the hardware, not in the math.
There are tens of billions of dollars worth of abandoned Bitcoins in addresses with exposed public keys. It would be trivial to get those if you can break ECDSA. Yes, there is much more outside of Bitcoin but I don't see why someone who had this capability wouldn't go after the easy targets first.
> it still has the decryption keys
No, they (usually) work similar to PGP/GPG, i.e. each file is encrypted with a different AES key and the AES key is encrypted with a public RSA key. The original AES key for a particular file is immediately deleted from memory after the file is encrypted and the private RSA key (needed for decrypting the AES key that is stored in the file) only ever gets delivered to the system if the ransom is paid.
The UID is 256-bit. With a proper random number generator you don't do anything additional to avoid collisions. Hardware random number generators are standard for crypto processors like the secure enclave and there are standard tests used to test the output of a RNG for problems like the one you're talking about (e.g. the NIST test suite).
The ECC algorithms used today rely on the "Elliptic Curve Discrete Logarithm Problem" and are very much vulnerable to (a version of) Shor's algorithm. Some would even say they are more vulnerable than RSA due to the much smaller key sizes (requiring less qubits).
> because I can compromise the thing without opening it (just press the button and reflash with non-signed images).
I don't think so. With RDP enabled the only thing the bootloader lets you do is erase all flash. After that RDP is disabled and you can write your own image but at that point the keys are already gone.
Yes, but if you want your sessions that are captured today to remain confidential when quantum computers do become reality then you need to use post-quantum key exchange methods today.
Symantec already agreed to start using Certificate Transparency in the near future, as per Google's request. This is a good thing.
Firefox packages its own copy of the libraries it uses, including the stagefright library. They patched their copy in the new release.