281–290 of 433 posts
Earlier quoted context omitted.
It's roughly half as fast as 4096, which sounds bad until you realize that 3072 is already 20% as fast as 2048, 3% as fast as 1024, and 1% as fast as 512. In terms of performance tradeoff it's downright mild compared to the other steps up.
If I could waive a magic wand and get a 40-100% performance boost on a service by changing 3-4 characters (s/4096/3072/) why wouldn't I take it? (Assuming I need security go to beyond RSA 2028.)
I’ve gotten a lot of spear phishing attacks, as far back of 2018, with emails that passed many verification checks. Getting representation to this issue is notoriously difficult because people assume an undiscerning victim and end user. They also rely on the false idea that scammers can’t spell or don’t spell correctly, specifically to weed out discerning people. When there is a subset that makes everything as legit and impersonating as possible.
Earlier quoted context omitted.
Yes, I've now read it and it answered those questions. But it also stumbled upon an easier possible solution without realizing it: if you wish to pretend you didn't send some emails, you can still claim that someone stole your password. Whether this claim will be believed or not, is independent of DKIM. Spoofing is a better excuse than a stolen password only in the case of a single email. If there's a conversation sp…
If you publish DKIM keys, you don't have to convince anybody that you were targeted by someone who stole your password, because your stolen email spool no longer reveals to attackers the authenticity of your emails, which is what you as a user want.
Earlier quoted context omitted.
Yes, I've now read it and it answered those questions. But it also stumbled upon an easier possible solution without realizing it: if you wish to pretend you didn't send some emails, you can still claim that someone stole your password. Whether this claim will be believed or not, is independent of DKIM. Spoofing is a better excuse than a stolen password only in the case of a single email. If there's a conversation sp…
If someone lies that their password was stolen to hide them being the originator of a single email, who are they telling the lie? Is it a court? In many cases the person would be caught through behavioral analysis. They didn't change their password, so it wasn't really stolen. No other emails were improperly authored, so it wasn't really stolen. They never reported it to the email server owner, so it wasn't really st…
You change your password only after you realize it got stolen. If you didn't realize it, then it makes sense you didn't change it. And, depending on the specific case, you could find plausible explanations also for the other points.
Earlier quoted context omitted.
I have stopped mentioning frontend performance being my speciality on interviews as it has elicited tepid responses from all but one.
I imagine interviewing at McMaster-Carr to be a very different experience than Home Depot.
Earlier quoted context omitted.
If you publish DKIM keys, you don't have to convince anybody that you were targeted by someone who stole your password, because your stolen email spool no longer reveals to attackers the authenticity of your emails, which is what you as a user want.
But you need to convince someone that someone targeted you and used the published key to forge an email. Where is the difference?
It is wild to see people argue against it! They're basically pleading with email providers to collude with attackers to violate their privacy.
Earlier quoted context omitted.
I am also not a lawyer, but I would suspect it's not criminal to crack a real-world in-use key if you do so using only publicly available information and you don't actually do anything with the result.
Let's say you local coffee shop is featured in a local news piece and the blithe owner happened to get photographed holding the store key. That's now easy to clone from public information. Would you be comfortable actually doing it? Reporting the issue is fine - "Hey you should rekey your locks!". Actually making a clone of the key, and then showing "hey it fits" will get you more traction more quickly ... but there'…
That's exactly what I meant in terms of not actually doing anything with the result. That said, it's obviously somewhat different with a physical key than a cryptographic key.
Earlier quoted context omitted.
That would be true if RSA scaled proportionally with the number of bits, but the exponent involved is much lower than 1. 1024->2048 gives you around the same difficulty as adding 30 bits to a symmetric key.
It's also only true so long as we don't discover more efficient ways of factoring large numbers. We haven't come up with any dramatic improvements lately, but it's always possible that something will come up. Symmetric crypto systems like AES are on much firmer ground, as they don't depend as heavily on the difficulty of any single mathematical problem.
Earlier quoted context omitted.
Yes, I've now read it and it answered those questions. But it also stumbled upon an easier possible solution without realizing it: if you wish to pretend you didn't send some emails, you can still claim that someone stole your password. Whether this claim will be believed or not, is independent of DKIM. Spoofing is a better excuse than a stolen password only in the case of a single email. If there's a conversation sp…
I used to spoof emails to my teachers in high school asking them to come to the principle's office asap, and email the principle from another random teacher at the same time for him to come to the class room, and that random teacher to expect the principal at a certain time. We'd be teacher free for quite awhile because the principal wasn't there, and our teacher was. You don't need a conversation to cause havoc.
Sure, but my point was different: let's say one of your teacher answered the spoofed email from the principal, you wouldn't be able to (properly) answer that email since you wouldn't receive it. So, in the case of an email exchange between two people, one can't claim his/her emails were spoofed, as the spoofer wouldn't be able to answer the other party's emails in a precise and on topic way. This is without even considering that, bh default, most email clients include the previous messages inside a reply. Meaning that the spoofer would somehow be able to know the other party's reply exactly word by word.