Hector Martin

So, what's the right SMTP/IMAP client to use on iOS? I use K-9 Mail on Android, but asking for a friend who uses iOS...

There's bugs, and then there's "major app feature is literally unusable for the entire non-English-speaking world and also English speakers can't use apostrophes or emoji". For years. Google, you're good at killing things. If you don't care about IMAP/SMTP support, kill it.

I just found out that GMail on iOS has been completely broken for IMAP/SMTP accounts for years, turning anything non-ASCII into ????? when sending messages. Multiple people have complained since 2018 with no answer. What the hell, @google?

News: "Evil Google is listening in on people having sex!!!" Reality: the hotword detector is just crap. Also, turn on the accessibility mode to hear that blip every time it triggers (i.e. when it starts sending audio to home base, even if it later decides it was a false trigger)

Is there really no way to forward an internal TLD with BIND without sticking `rndc nta -lifetime 2d <tld>` into your crontab? Because this is ridiculous. Yes, I know I'm hijacking a nonexistent TLD for local use. Everyone does this with authoritative zones. Let me use forward.

Worth noting that RFC5480 disallows custom ECC curves for PKIX, and of course they are also verboten in the WebPKI. But both crypt32 and OpenSSL seem to support it.

It just goes on to show that in the absence of detailed official information, people are perfectly happy to make up an explanation without never mind verifying it, but not even trying to see if it is consistent or reasonable! This is wrong.

I don't understand how everyone is falling into the trap of talking about "validating" ECC params or using the wrong ones or whatever, and completely handwaving the way this actually works. If you *think* about how this should work, it doesn't make sense.

And by the way, the fact that I had to come out and make this explanation is *yet again* another example of the sorry state of tech security reporting, by both media and infosec folks themselves. Like every single article about this bug is wrong and makes no sense.https://twitter.com/marcan42/status/1217803207084134401 …

(And we can already do this exact thing for FDE on desktops/laptops, so it's not like it's novel)

I don't know why nobody offers this option of split FDE/unlock codes by default (neither iPhones nor stock Android). It's such a massive no-brainer to increase security to basically "unbreakable" under an entire class of practical attack scenarios.

Sure, you can try to attack my phone from a powered-but-locked state, but if you screw up and it reboots, or if you attempt any boot chain attacks, or if the battery runs out, you are *not* getting in. Period.

Thread about numeric passcode strength on iPhones. And *this* is why I consider my rooted Android phone to be more secure than iPhones under a whole category of attack scenarios. Because I can use separate 25-character full ASCII *startup* password and an 8-digit *unlock* code.https://twitter.com/matthew_d_green/status/985885001542782978 …

So it's not that Windows uses the wrong curve parameters or anything like that, it's that at some point the key used to index into a validated cert cache is (serial, pub) when it should be (serial, pub, params). As they say, one of the hardest problems in CS is caching.

To clarify the Windows crypto fail: The problem isn't in signature validation. The problem is the *root store/cache*. CryptoAPI considers an (attacker-supplied) root CA to be in the trust store if its public key and serial match a cert in the root store, Ignoring curve params.

Reminds me of setting the RSA sig to all-0 on the Wii and bruteforcing a hash that starts with 00 (because they used strncmp and no padding check and 0^e=0 mod n). Degenerate crypto exploits are fun.https://twitter.com/CasCremers/status/1217510293040844800 …