121–130 of 433 posts
Earlier quoted context omitted.
The key sizes we use today are expected to hold against a Dyson sphere focused on breaking them with the best exploit we know today. What size do you suggest?
It's not quantum-safe though.
Because we need that compute for our React frameworks.
[flagged]
Loads of developers everywhere, frontend and backend, go to lengths to optimise their programs. Loads of other developers also don't care.
Earlier quoted context omitted.
Your claim that yahoo uses a 512bit key are counterfactual. Please adhere to honesty and good faith arguments.
I never suggested that Yahoo uses 512bit keys, that's a misunderstanding. The article clearly states that Yahoo is one of the 3 clients that didn't reject 512bit keys the way they should per RFC. Yahoo Mail inbox users are vulnerable _receivers_ of spoofed emails.
Me writing over 14 years ago: https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b... This was doable 14 years ago for 512-bit keys.
> "Keys of 512 bits have been shown to be practically breakable in 1999 when RSA-155 was factored by using several hundred computers and are now factored in a few weeks using common hardware." So we went to a few weeks to 8h in 14 years give or take
> We chose a server with 8 dedicated vCPUs (AMD EPYC 7003 series) and 32 GB of RAM from Hetzner
Not very beefy really. Beating this time is easily in range of, what, millions of people high end gaming machines?
Some DNS providers suck and only let you set 1024 bit long keys. For example wordpress.com.
1024 is still many orders of magnitude hard to crack than 512. For the record, the last RSA number having been broken was RSA-250 (829 bits) and it took 2700 core-years to crack back in 2020[1]. In comparison, RSA-155 (512 bits) was factorized as early as 1999! You aren't in danger. [1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
Earlier quoted context omitted.
Well, backend is our precious server resources and front end resources belong to the lowly user. It's a matter of scale though, frontend is optinized for one concurrent user. Plenty of small websites using slow and bloated frameworks on the backend because it's easy.
Man, users are the worst. Sometimes I think that they only exist to stress out my precious beautiful servers.
Earlier quoted context omitted.
It's more "I want you to be able to verify I sent an email to you, but I don't want you to be able to prove to a third party that I sent it." The fact that this is possible is some cryptography black magic.
I don't see how this could be possible. If I have some information which I can use to prove that you were the sender, then I can just share the same information with a third party, and they can verify just the same.
Earlier quoted context omitted.
For a number of years it was (non-officially) thought to be a feature to use weak DKIM keys. Some folks argued that short keys allowed you to preserve deniability, since DKIM signatures would only be short-lived and nobody would be able to use DKIM signatures to prove that any email was authentic. (I’m not saying that this is why most companies used short keys, just that there was a general view that short keys were…
I forget where but someone proposed regularly rotating your DKIM key and publishing old keys for deniability. So you can still use strong keys and provide a level of deniability.
Earlier quoted context omitted.
You hit the nail on the head with the word 'Universal'. Because email addresses have existed since the begining of the web, anyone who has ever been on the internet has one and uses it for identification purposes. This will not change without another universal standard which everybody automatically has. Its like IPv4, we all have the ability to use IPv6 but do we? Hell no we just use NAT as its an easier quick fix. C…
Haha, definitely not true outside of the US and Western Europe. Most of Asia (and probably Africa) uses phone #.