[HN Gopher] Cracking a 512-bit DKIM key for less than $8 in the ...
___________________________________________________________________
Cracking a 512-bit DKIM key for less than $8 in the cloud
Author : awulf
Score : 534 points
Date : 2025-01-08 12:32 UTC (10 hours ago)
(HTM) web link (dmarcchecker.app)
(TXT) w3m dump (dmarcchecker.app)
| bell-cot wrote:
| Technically, this is very nice work.
|
| But as a security generality - email is vastly less secure* than
| human nature wants to assume that it is. Human nature usually
| wins.
|
| *Outside of a carefully run org's own network, and a few other
| edge cases
| xmodem wrote:
| Yeah, so I guess there's no point in picking any of the low
| hanging fruit to make it more secure.
| sam_lowry_ wrote:
| Email is actually quite secure, just in a different way that
| web.
|
| For instance, once you disregard so called transactional mail
| and spam, real email is almost all encrypted for all
| practical purposes.
|
| DKIM and DMARC also work quite well for spoofing protection,
| aside from the corner cases like the above.
|
| Average Software Engineers have an outdated idea of email,
| formed by 1990 era Internet.
| tredre3 wrote:
| I think your view of email is romanticized, or perhaps
| skewed because of your social circle. Email servers
| sometimes use TLS to talk with eachother, and emails are
| signed. But that's the extent of encryption when it comes
| to "real email". Email content is not encrypted in "almost
| all" of "real email" because almost nobody uses PGP.
| bell-cot wrote:
| Depends on context.
|
| If you're in IT at a carefully run org: You ditched 512-bit
| keys years ago. This article is nothing but a 20-second
| story, to help explain to PHB's and noobs why they got an
| error message, or what sorta important stuff you're always
| busy keeping your org safe from.
|
| If you're in IT at a scraping-by org: Maybe today's a good
| day to ditch 512-bit keys. And if you get push-back...gosh,
| here's a how-to article, showing how a "forged corporate
| signature stamp" can be made for only $8.
|
| If you're trying to teach senior citizen how to avoid being
| scammed on the internet: You've got zero visibility or
| control, so you're stuck with "sometimes these can be forged,
| depending on technical details" generalities.
| xoa wrote:
| > _But as a security generality - email is vastly less secure
| than human nature wants to assume that it is._
|
| I don't think this has to do with "human nature" anymore than
| http did. It's a very important, powerful form of communication
| without any secure replacement. Just as we switched to https,
| ideally an "xmail" or the like would get created as an open
| standard with open software that was email with better security
| by default. Sadly I'm not sure we collectively have the ability
| to do that kind of thing any longer, powerful entities have
| realized it's just too attractive to lock it up. But even many
| open source organizations don't seem to feel like bothering.
| Plenty of security experts even just prefer new shiny and will
| spout ridiculous "move to instant messaging". So status quo
| rules for the foreseeable future.
| immibis wrote:
| Email is one of a great number of internet communication
| systems. It happens to be one that was created before
| security was much of a concern (and before it was a problem
| we could solve), and also one that is highly asynchronous.
| Newer systems have their own different sets of tradeoffs.
| None of them happen to be email plus security. But that makes
| sense: now that everyone is online most of the time, why
| would you design a highly asynchronous store-and-forward-ish
| system? Of course you want a recipient to receive a message
| as soon as you sent it and the sender to confirm the
| recipient received the message. Designing a new system any
| other way would be leaving value* on the table. (*actual
| value not economics value)
|
| We can extend email, though. Why isn't there an SMTP GETKEY
| command to return a PGP key corresponding to an email
| address? Sure, the sender might not support the same version
| of PGP, and sure, the connection might be intercepted
| (hopefully you'd not trust the output of this command except
| over TLS), but like most of the email system, it would be a
| big improvement and good enough most of the time.
| avian wrote:
| As a small mail server admin I see this less about security of
| messages originating from me and more about the possibility of
| spammers sending DKIM-authenticated mail as coming from me (and
| resulting in shadow bans at gmail, etc. which is a huge pain to
| deal with)
| zelphirkalt wrote:
| Some DNS providers suck and only let you set 1024 bit long keys.
| For example wordpress.com.
| Avamander wrote:
| Yikes. NIST wants to forbid even 2048-bit RSA by 2035, because
| it doesn't offer a good enough security level.
| tptacek wrote:
| 2048 achieves the same security level NIST requires from
| AEADs, doesn't it? What plausibly attacks it? Pushing people
| past 2048 seems counterproductive.
| Avamander wrote:
| It should achieve the same level, yes. It's not exactly
| described what could attack it. Right now it seems that
| 2048-bits would be the last allowed step and they're not
| going to push people past 2048, they want to phase out RSA
| in general.
| daneel_w wrote:
| Counterproductive how and to what/whom? For the sake of
| keeping DNS TXT entries and e-mail headers compact? Would
| you stand by this statement also in the context of a
| certificate authority's root signing key, or an RSA host
| key for an ssh daemon?
| tptacek wrote:
| There is no plausible threat to 2048, but you'd still
| rather people switch off RSA, either to curves (because
| they're more resilient) or to lattices (for post-
| quantum). Pushing people to higher RSA key sizes is a
| waste of effort.
| littlestymaar wrote:
| 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...
| DarkmSparks wrote:
| There are several open source GNFS tools that can do 1024
| very efficiently on GPUs, and even cheap consumer GPUs have
| 10s of thousands of cores now, even by your measure "2700
| core-years" is only around a month or so on a single consumer
| grade GPU.
|
| Not "free", but any malicious actor has access to a lot more
| than a single GPU.
|
| The UK government also has several huge arm based solutions
| dedicated to cracking internet encryption, zero chance that
| isn't breaking mostly everything, for sure the Chinese and
| Russians have similar.
| upofadown wrote:
| >There are several open source GNFS tools that can do 1024
| very efficiently on GPUs, ...
|
| Reference? Why has no one demonstrated this?
| littlestymaar wrote:
| Yet nobody is collecting the RSA-numbers bounties?
|
| RSA-270 (much, much easier than 1024 compute-wise) has a
| bounty of $75k, why would it be unclaimed then when you can
| spend three years worth of cloud rented H100 (I'm being
| conservative here and count $3/h which is far from the best
| deal you can get) and still make a profit?
|
| Also a GPU core and CPU cores really aren't comparable
| individually, so your "consumer graphic card having
| thousands of core already" is comparing apples to oranges.
| DarkmSparks wrote:
| had a bounty. the RSA challenge unexpectly finished in
| 2007, task is left to the reader to speculate what
| happened in 2007.
| littlestymaar wrote:
| Oh, I wasn't aware of the end of the challenge. But 1024
| was definitely not broken by then, at least not by brute
| force.
| DarkmSparks wrote:
| none of it is "brute force", GNFS is a process that
| rapidly excludes numbers from the search space that
| cannot be the answer, in principle similar to the way
| they broke enigma.
|
| numberphile has a great video on that one
| https://www.youtube.com/watch?v=V4V2bpZlqx8
|
| Also, taking the OP as a "worse case", afaik:
|
| 512bit = $8
|
| so
|
| 1024 = 8^2 = $64
|
| 2048 = 8^2^2 = $4,096
|
| 4096 = 8^2^2 = $16,777,216
|
| noting $8 for 512 seems very expensive to me.
| daneel_w wrote:
| You and I aren't the ones in immediate danger. The service
| providers we rely on are. In discussions like these we have a
| "tragicomic" tendency to forget mankind's unstoppable
| progress. RSA-1024 offers 80 symmetric equivalent bits of
| security and we've been heading down this path for decades at
| an exponentially increasing pace.
| littlestymaar wrote:
| Those service providers have had plenty of time to migrate
| to 2048 and most of them have already.
|
| > a "tragicomic" tendency to forget mankind's unstoppable
| progress
|
| When it comes to compute, it's no faster than Moore's Law,
| which means roughly one bit of symmetric encryption every
| two years.
|
| > and we've been heading down this path for decades at an
| exponentially increasing pace.
|
| Given that the encryption security is itself exponential in
| bit length, we are in fact heading down this path linearly!
| (A doubling in compute power means the ability to crack
| twice as hard cryptosystems, which means ones that have 1
| bit more of security).
|
| Key must be extended over time, and they are, and have been
| for decades. A PoC of an attack of a security system broken
| since 1999 should be treated exactly like how we are amazed
| at little computing power was available to the Apollo
| program: this is a cool bit of trivia that shows the growth
| of available computing power, but not a display of any kind
| of security issue.
| GuB-42 wrote:
| RSA-1024 seems to be about 8 million times better than RSA-512,
| so cracking that would be $64 million in compute.
|
| Not NSA-proof, but should be more than enough to keep spammers
| out, especially considering that DKIM is just one layer of
| protection.
| zahlman wrote:
| 512 extra bits of key only gets you 23 bits of entropy?
| GuB-42 wrote:
| Yep, the formula is a bit complicated, it comes from the
| general number field sieve (GNFS) algorithm, you can find
| some equivalences online between symmetric key algorithms
| and RSA and 23 bits seems about right. I have also seen
| lists where they give RSA-512 64 bits and RSA-1024 80 bits,
| just a 16 bit difference, but it looks a bit arbitrary to
| me. I think the NIST doesn't even look at RSA-512 anymore,
| as it is definitely broken, it only starts at 1024.
|
| A RSA key is the product of two primes, not any number, so
| you need a lot more bits to get equivalent security to,
| say, AES. That's also a reason for elliptic-curve
| cryptography, which needs a lot less bits than RSA for the
| same level of security.
| upofadown wrote:
| That's just the extra compute required. There is a large
| increase in required memory that needs to be quickly
| accessible in a particular way. One estimate I saw claimed
| that breaking 1024 bit RSA would take more than 2 billion
| dollars over a period of years.
| mjl- wrote:
| DKIM records are just DNS TXT records. Do they have a limit on
| the size of TXT records? Or are they going out of their way to
| try to parse the TXT records you're adding that look like DKIM
| records, failing on them, and then refusing to add them?
| nyrikki wrote:
| RFC1035 imposes a 255 character limit per string on TXT
| records .
| mjl- wrote:
| Yes, so you use multiple strings (in a single record) if
| you need longer values:
|
| "first 255 bytes" "second 255 bytes" "etc"
|
| DNS clients combine the 255-byte strings back into a single
| string.
| Havoc wrote:
| Could someone help me understand why we're not dramatically
| ramping up key sizes across the board on all encryption? Not as a
| solution, but as a buy-some-time measure.
|
| Compute is rapidly increasing, there is continuous chatter about
| quantum and yet everyone seems to be just staring at their belly
| buttons. Obviously bigger keys are more expensive in compute, but
| we've got more too...why only use it on the cracking side, but
| not on defense?
|
| Even simple things like forcing TLS 1.3 instead of 1.2 from
| client side breaks things...including hn site.
| Suzuran wrote:
| Because the only way to _force_ their use is to break things,
| mostly this means transferring the pain directly to the user
| instead of the service operators in the hope that they will
| bitch loudly enough for the service operator to care, and this
| has a good chance of instead causing the user to move to your
| competitors instead, who will be more than willing to not let a
| little thing like security get between them and revenue.
| bananapub wrote:
| > why we're not dramatically ramping up key sizes across the
| board on all encryption?
|
| because no one thinks there is a reason to, no one has any fear
| that classical computers will catch up with RSA-2048/AES-128
| before their grand children are dead.
|
| post-quantum crypt stuff is happening and people are planning
| how to migrate to it.
| EVa5I7bHFq9mnYK wrote:
| Well, even MD4 hasn't been cracked yet.
| kbolino wrote:
| What is your definition of cracked? Collisions are easy to
| produce; there's one right on the Wikipedia page.
| EVa5I7bHFq9mnYK wrote:
| Collisions are not interesting. Millions of leaked
| passwords hashed with MD4/MD5 are of very practical
| interest.
| kbolino wrote:
| Ok, preimage resistance is still pretty strong, but it
| has been reduced enough that I wouldn't trust it
| remaining above practical attacks beyond the next decade.
| croes wrote:
| > Even simple things like forcing TLS 1.3 instead of 1.2 from
| client side breaks things...including hn site.
|
| That's the reason, it breaks things, and some of them are
| important and can't simply be updated.
| wolrah wrote:
| > That's the reason, it breaks things, and some of them are
| important and can't simply be updated.
|
| IMO this is not a valid excuse.
|
| If it's exposed to the internet it needs to be able to be
| updated with relative ease to respond to a changing threat
| landscape. Especially if it's "important". If it cannot be
| then it is already broken and needs to be fixed. Whether that
| fix is doing a hard upgrade to get to the point that future
| upgrades can be easier, entirely replacing the component, or
| taking the thing offline to a private non-Internet network
| depends on the situation, but "we aren't going to change, the
| rest of the internet should conform to us" has never been a
| reasonable response.
|
| This is particularly true in the contexts of public mail
| servers where DKIM matters and anything involving public use
| of TLS. The rest of the internet should not care if your
| company refuses to update their mail servers or replace their
| garbage TLS interception middleboxes. We should be happy to
| cause problems for such organizations.
| bawolff wrote:
| > IMO this is not a valid excuse.
|
| The world is full of things that aren't "valid excuses".
| Explaining why something is the way it is is not the same
| as justifying it.
| daneel_w wrote:
| Probably because RSA 2048 is not yet broken, and once there we
| still have RSA 4096 to lean back on which is since quite some
| time the most common key size for most things using RSA (DKIM
| being one of the exceptions).
|
| In the context of DKIM we're waiting for Ed25519 to reach major
| adoption, which will solve a lot of annoyances for everyone.
| throw0101c wrote:
| > _Probably because RSA 2048 is not yet broken_ [...]
|
| 3072 has been recommended by various parties for a few years
| now:
|
| * https://www.keylength.com
| bluGill wrote:
| RSA 2048 isn't broken, but experts consider it a matter of
| time. How long I don't know, but since the attacks are
| known (prime numbers) someone (read not me) can make an
| estimate with error bars that are concerning enough to
| consider it as good as broken.
| tptacek wrote:
| What expert considers it a matter of time before 2048 is
| broken? 2048 is 112-bit-equivalent security.
| bluGill wrote:
| https://www.keylength.com/en/4/ NIST says 2048 bit RSA is
| good until 2030. I'm not sure what that means, perhaps
| that it will be broken considering advances, perhaps just
| that someone (read governments) who cares to spend 5
| years on the problem will break your key.
| tptacek wrote:
| No, we are not in fact 5 years from breaking RSA-2048.
| lostmsu wrote:
| AFAIK even RSA 1024 isn't broken yet.
| daneel_w wrote:
| RSA-1024 is "only" 80 symmetric equivalent bits. It's a
| space requiring a tremendous amount of energy to explore,
| though I personally consider it very likely that the NSA
| and/or the MSS et al. have poured immense funds into
| accelerators specifically targeting RSA, and for them
| there'd be no obstacles at all to be granted an
| allocation for such energy consumption.
| jandrese wrote:
| Is there a compelling reason to use 3072 instead of 4096?
| If you're going to kick the can down the road you might as
| well put some effort into it. The difference in memory
| use/compute time has to be marginal at this point. It's not
| like the old days when jumping from 512 to 4096 made the
| encryption unusably slow.
| daneel_w wrote:
| There's no good reason at all, which is why RSA-3072 is
| the rarely seen "oddball".
| throw0101c wrote:
| > _There 's no good reason at all_
|
| Operations per second?
|
| * https://wiki.strongswan.org/projects/strongswan/wiki/Pu
| blicK...
|
| Running MacPorts-installed `openssl speed rsa` on an
| Apple M4 (non-Pro): version: 3.4.0
| built on: Tue Dec 3 14:33:57 2024 UTC options:
| bn(64,64) compiler: /usr/bin/clang -fPIC -arch
| arm64 -pipe -Os -isysroot/Library/Developer/CommandLineTo
| ols/SDKs/MacOSX15.sdk -arch arm64 -isysroot
| /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk
| -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT
| -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG
| -I/opt/local/include -isysroot/Library/Developer/CommandL
| ineTools/SDKs/MacOSX15.sdk CPUINFO:
| OPENSSL_armcap=0x87d sign
| verify encrypt decrypt sign/s verify/s encr./s
| decr./s rsa 512 bits 0.000012s 0.000001s
| 0.000001s 0.000016s 80317.8 973378.4 842915.2 64470.9
| rsa 1024 bits 0.000056s 0.000003s 0.000003s 0.000060s
| 17752.4 381404.1 352224.8 16594.4 rsa 2048 bits
| 0.000334s 0.000008s 0.000009s 0.000343s 2994.9 117811.8
| 113258.1 2915.6 rsa 3072 bits 0.000982s
| 0.000018s 0.000019s 0.000989s 1018.4 54451.6 53334.8
| 1011.3 rsa 4096 bits 0.002122s 0.000031s
| 0.000032s 0.002129s 471.3 31800.6 31598.7 469.8
| rsa 7680 bits 0.016932s 0.000104s 0.000107s 0.017048s
| 59.1 9585.7 9368.4 58.7 rsa 15360 bits
| 0.089821s 0.000424s 0.000425s 0.090631s 11.1 2357.4
| 2355.5 11.0
|
| (Assuming you have to stick with RSA and not go over to
| EC.)
| jandrese wrote:
| 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.
| throw0101c wrote:
| 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.)
| jrpelkonen wrote:
| Well, in typical use cases RSA usage is very limited (eg
| some operations during TLS handshake), so the 40-100%
| boost wouldn't be across the board, but likely shave some
| milliseconds per connection.
| bawolff wrote:
| Its not a 40-100% performance boost overall, its just
| during one specific step that is a very small part of the
| entire overall system.
| daneel_w wrote:
| These are contrived benchmarks at the extreme end of
| things. In real world usage the difference is drowned-out
| by the delays of so many other things happening in order
| to complete a handshake and key exchange. The mildly
| higher performance of RSA 3072 versus RSA 4096 wasn't
| even a big bonus during the CPU performances we had 15
| years ago.
| upofadown wrote:
| But perhaps with not a very solid justification to do so:
|
| * https://articles.59.ca/doku.php?id=em:20482030
| daneel_w wrote:
| Nobody is recommending RSA-3072 per se. The recommendation
| if wanting to stick with RSA is to move beyond RSA-2048,
| and the world at large jumped all the way to RSA-4096 long
| ago.
| woodruffw wrote:
| Ed25519 has seen broad adoption in TLS and other stacks that
| are used pervasively where DKIM is also used. What's blocking
| it for DKIM uniquely?
|
| (This isn't intended as a leading question.)
| daneel_w wrote:
| Everyone has to be onboard before the switch can be made,
| and not everyone is happy about the somewhat messy solution
| of running dual-stack RSA+Ed25519 setups in the interim -
| it's a bit different than e.g. supporting multiple methods
| for key exchange or multiple ciphers for symmetric crypto.
| It's just one of those things that take time to happen.
| bluGill wrote:
| If the big players (gmail, outlook) jump onto it the rest
| will be forced to follow. Outlook would probably jump in
| with a checkbox, and perhaps gmail will make at an option
| for the paid tier while everyone on the free tier gets no
| choice - but that is still enough. SmallCompany.com
| cannot do it alone, probably not even a fortune100.com
| (if any of them even care - their sales staff probably
| will overrule the few who do), but there are enough
| players if they all agree on something.
|
| Getting the big players to agree and execute though is a
| lot like herding cats. I'm sure some in the big players
| are trying.
| paulnpace wrote:
| > What's blocking it for DKIM uniquely?
|
| Mail server administrators.
| Avamander wrote:
| X25519 has seen broad adoption (in the key exchange).
| Ed25519 has not, you can't actually use an Ed25519
| certificate on the web. It's in a deadlock between CAs,
| browsers and TPM manufacturers (and to some extent NIST,
| because Ed25519 has not been approved by them).
|
| It's not being blocked per se, you can use it mostly (98%)
| without any issues. Though things like Amazon SES
| incorrectly reject letters with multiple signatures. Google
| and Microsoft can't validate them when receiving. It's more
| that a few common implementations lack the support for them
| so you can't use _just_ Ed25519.
| throw0101c wrote:
| > _(and to some extent NIST, because Ed25519 has not been
| approved by them)._
|
| Ed25519 (and Ed448) have been approved for use in FIPS
| 186-5 as of February 2023:
|
| * https://en.wikipedia.org/wiki/EdDSA#Standardization_and
| _impl...
| xondono wrote:
| We are doing that, just not everyone is as concerned by safety
| and make different tradeoffs against things like ease of use or
| accessibility. Different applications have different tolerances
| and that's fine.
|
| If and when anything quantum is able to yield results (I
| wouldn't worry much about this), increasing key size is pretty
| much meaningless, you need to move to other encryption schemes
| (there's lots of options already).
| daneel_w wrote:
| In the case of RSA it's not meaningless to increase key size
| to fend off quantum computers. Quantum computing vs RSA is a
| case of being the largest contender, because quantum
| computing in itself doesn't definitively unravel the integer
| factorization problem.
| bawolff wrote:
| That seems suspect to me.
|
| Getting a working qc to reasonable scale is the hard part.
| Once you have done that most of the hard engineering
| problems are solved. I doubt doubling its size at that
| point would be very much of a problem.
|
| If we are making (uninformed) predictions, i bet we wont
| see QC solving 1024 bit RSA in the next 15 years (at
| least), but once it does it will only take a year or two
| more to solve 4096.
| elif wrote:
| 512 DKIM was exceedingly rare even 8 years ago when I worked in
| email.
|
| You're essentially asking "why aren't we doing what we're
| doing"
| littlestymaar wrote:
| > Could someone help me understand why we're not dramatically
| ramping up key sizes across the board on all encryption? Not as
| a solution, but as a buy-some-time measure.
|
| We've been doing it for decades now... (DES used 56bits back
| then, AES started at 128).
|
| Also, keep in mind that increasing the key length by 1 means
| that you need twice as much compute to crack it through brute
| force (that is, unless cryptanalysis shows an attack that
| reduces the difficulty of the scheme, like for instance with
| the number field sieve on RSA) so you don't need to increase
| key size too often: following Moore's law, you need to increase
| it by on bit every two years, or 5 bits every decades.
| Additionally key size generally account for many years of
| compute progress and theoretical advance, so that you really
| don't need to worry about that over a short period (for the
| record higest RSA factorization to date is 829 bits, yet people
| started recommending migration away from 1024 bit RSA a decade
| ago or so, and the industry is in the process in deprecating it
| entirely even though it's probably going to take years before
| an attack on it becomes realistic.
| formerly_proven wrote:
| Compare the time it takes to generate or decrypt/encrypt 4096
| bit RSA versus 16384 bit RSA (it's not four times slower).
| Havoc wrote:
| Indeed. There has got to be some middle ground there though
| that is both an incremental improvement and still within
| reason on cost
| paulnpace wrote:
| In the case of DKIM, Ed25519.
| marcosdumay wrote:
| 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?
| RobotToaster wrote:
| It's not quantum-safe though.
| Avamander wrote:
| It's not quantum-broken though, it might just make it a bit
| faster. Just half a Dyson sphere.
| marcosdumay wrote:
| Larger keys won't make the algorithms quantum-safe either.
| Tostino wrote:
| If I'm not mistaken, larger keys require more qbits in a
| machine to all be coherent together to be able to break
| it.
|
| So it would be a slight increase in complexity, but if we
| are able to build a machine with enough qbits to crack
| 1024 keys, I don't think the engineering is all that far
| off from slightly scaling things up 2x-10x.
| dist-epoch wrote:
| Which is why post-quantum algos were invented.
| TacticalCoder wrote:
| > Which is why post-quantum algos were invented.
|
| Yup. And I don't even think quantum resistance was the
| goal of some of the algos that, yet, happen to be
| believed to be quantum resistant. Take "Lamport
| signatures" for example: that's from the late seventies.
| Did anyone even talk about quantum computers back then? I
| just checked and the word "quantum" doesn't even appear
| in Lamport's paper.
| bawolff wrote:
| > Did anyone even talk about quantum computers back then?
|
| Not unless they have a time machine. Shor's algorithm was
| discovered in the 90s (sure the concept of a quantum
| computer predates that, but i don't think anyone really
| realized they had applications to cryptography)
| tptacek wrote:
| We are. 1024-bit keys are being retired across cryptosystems
| everywhere, and have been for over a decade (don't get me
| started on the one laggard). Nothing threatens 2048 bit keys
| other than QC, which threatens RSA altogether. Progress isn't
| linear; it's not like 2048 falls mechanically some time after
| 1024 (which itself is not practical to attack today).
| 1oooqooq wrote:
| we are definitely not.
|
| most countries registrar's won't support DNS hacks requied
| for larger dkim.
|
| we still use the minimum key size in most countries.
| Avamander wrote:
| What? Just use normal name servers. The registrar doesn't
| matter one bit, they delegate the zone to whatever name
| servers you specify. Those can serve whatever records
| properly.
| sedatk wrote:
| People might be assuming that 2048-bits is only twice as
| strong as 1024-bits, but it's in fact _a billion times_
| better. (corrected, thanks!)
| AlotOfReading wrote:
| 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.
| sedatk wrote:
| I stand corrected, thanks! 2^30 still means a billion
| times better.
| duskwuff wrote:
| 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.
| tptacek wrote:
| By "lately" you mean...
| duskwuff wrote:
| I'm hedging a little because I'm not an expert. :) As far
| as I'm aware, the last major algorithmic development was
| GNFS in 1993.
| 1oooqooq wrote:
| because everyone recommending those things work on both sides.
|
| they recommend 2048 and use 4096 themselves because if they
| need to ever break your 2048 it's less bad than if you were
| recommended to use 4069. wink wink
|
| same with everyone recommending ed22519 when ed448 is as good
| and as fast to encode. but all the arguments point to encode
| speed from a Bernstein paper which used a pentium iii!
|
| https://cr.yp.to/ecdh/curve25519-20060209.pdf
| inetknght wrote:
| > _Could someone help me understand why we 're not dramatically
| ramping up key sizes across the board on all encryption? Not as
| a solution, but as a buy-some-time measure._
|
| I am acutely aware that there are SOME places where software
| only supports RSA and only supports up to 1024-bit or 2048-bit
| keys, and that is a legal requirement. Ramping up key sizes
| would be great but even 2048-bit keys aren't quite secure
| against certain kinds of actors (even disregarding hammer-to-
| head style of attacks)
|
| > _Even simple things like forcing TLS 1.3 instead of 1.2 from
| client side breaks things_
|
| ... kind 've a case in point about the pace of required
| improvements.
| tonymet wrote:
| Key rotation tooling has never been given adequate attention
| since you only do it every few years. Something ends up
| breaking, even if it's just the name of the key .
|
| keys are stateful content like DB schemas, but they don't
| receive daily attention, so the tooling to maintain them is
| usually ad-hoc scripts and manual steps.
| layer8 wrote:
| Linear bit size increases require exponential compute increases
| to break. RSA with 1024 bits is still beyond any practical
| capability to break. The current practical limit is considered
| to be around 800-something bits. Still the recommendation is to
| use at least 3000 bits nowadays, to defend against possible
| mathematical advances.
| Retr0id wrote:
| This is incorrect. Factoring algorithms like GNFS are super-
| polynomial but sub-exponential. RSA-1024 is likely breakable
| at practical-but-very-expensive costs.
| hannob wrote:
| "dramatically ramping up key sizes" is not done, because it's
| overly expensive, and not needed.
|
| What people don't realize: key size recommendations are
| surprisingly stable over long timeframes, and have not changed
| for a very long time. In the early 2000s, some cryptographers
| started warning that 1024 bit RSA is no longer secure enough,
| and in the following years, recommendations have been updated
| to 2048 bit minimum. That's now been a stable recommendation
| for over 20 years, and there's not the slightest sign that 2048
| bit can be broken any time soon.
|
| The only real danger for RSA-2048 is quantum computers. But
| with quantum computers, increasing your RSA key sizes does not
| buy you much, you have to move to entirely different
| algorithms.
| JackSlateur wrote:
| Old but still relevant:
| https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
| These numbers have nothing to do with the technology of the
| devices; they are the maximums that thermodynamics will allow.
| And they strongly imply that brute-force attacks against
| 256-bit keys will be infeasible until computers are built from
| something other than matter and occupy something other than
| space.
|
| Long story short, brute forcing AES256 or RSA4096 is physically
| impossible
| dspillett wrote:
| How common are such small DKIM keys?
|
| I'm pretty sure mine are 2048-bit, though I'd have to check as
| they were last set a fair while ago.
| sva_ wrote:
| First sentence:
|
| > In our study on the SPF, DKIM, and DMARC records of the top
| 1M websites, we were surprised to uncover more than 1,700
| public DKIM keys that were shorter than 1,024 bits in length
| unwind wrote:
| So 1,700 out of 1,000,000, i.e. around 0.2%. "Not common" is
| one way of putting it, I guess.
| croemer wrote:
| Those 1,700 are easy to find though, just need to dig a
| bunch of domain names and you'll find plenty vulnerable
| ones that you can spoof.
|
| Yahoo Mail has a market share on the order of 3%. So a
| black hat could then target a decent chunk of users with
| @yahoo addresses specifically.
|
| Has anyone heard of this being exploited in the wild? Would
| be interesting to find out whether there are some reputable
| domains among the 1.7k vulnerable ones.
| elif wrote:
| Your claim that yahoo uses a 512bit key are
| counterfactual.
|
| Please adhere to honesty and good faith arguments.
| croemer wrote:
| 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.
| 1oooqooq wrote:
| remember when yahoo mail was the first one to implement
| DKIM validation and then all mailing list owners added a
| footer telling their subscribers not to use yahoo mail
| because it was broken, instead of calling their mailing
| list providers to upload a key? yeah nobody remembers,
| but yahoo probably do. i doubt they will err on the side
| of security again.
| jaza wrote:
| The Yahoo that built Yahoo Mail no longer exists, so
| actually they probably don't remember.
| awulf wrote:
| I agree, but to be precise, it was 1,726 out of 476,617
| DKIM keys found across those 1M domains, or about 0.36%.
| Since it's impossible to determine all DKIM records a
| domain might have from the outside, I used a list of
| commonly used selectors (e.g., "default' or 'key1") for the
| search. It's likely there are additional short keys under
| selectors I didn't check.
| philipwhiuk wrote:
| The top million domains are more likely to be on top of
| their security than less prominent domains. 0.2% is
| therefore a fairly strict lower bound for the overall
| internet.
| mrweasel wrote:
| The interesting question is: Did these sites forget that they
| have these records, or have they perhaps forgot how to rotate
| their keys.
| 1oooqooq wrote:
| dns server limitations.
|
| txt records are 1024bits... add the prefix for the key and
| you get <1024.
|
| to use a larger key you must combine many txt records in a
| never ending comical interoperability issues. the first one
| usually being that your regional monopoly scoundrel, a.k.a.
| registrar, run a server which doesn't even allow more than
| one entry.
| kbolino wrote:
| TXT records are 255 bytes or 2040 bits. This is plenty of
| space to support RSA-1024 keys even with a small prefix
| and after base64 encoding them. However, it is obviously
| not enough to support RSA-2048 which is the minimum
| recommended size according to NIST right now. It's also
| not quite enough even for RSA-1536 (not widely used) due
| to base64 expanding the key by 33%.
|
| There actually is a standard for adding more than 255
| bytes to a TXT record and it's fairly widely supported,
| but it can be tricky to configure properly on a name
| server.
| awulf wrote:
| I guess most of these keys are decades old and no longer in
| use. They're likely just sitting in the DNS because someone
| forgot to delete them. Now, no one's sure if they're still
| needed and is afraid to remove them in case it breaks
| something. Or maybe they're still used by a legacy system,
| and no one realizes the impact an old DKIM record could
| have.
| dspillett wrote:
| I must do something about my short-term memory/attention. I
| must have read that and promptly blanked it during the
| scanning of the rest of the article.
| daneel_w wrote:
| Not common. 1024-2048 bit RSA is the most common DKIM scheme.
| It's been 6 years since Ed25519 was labeled "required" in a
| drafted RFC, but adoption is as usual taking an unfortunately
| long time.
| jgrahamc wrote:
| 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.
| begueradj wrote:
| 2010, Nostradamus :)
| jgrahamc wrote:
| Depends if you're rounding up or down.
| raverbashing wrote:
| > "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
| chias wrote:
| 86h, wasn't it? But regardless your point stands.
| bee_rider wrote:
| 86 hours. 8 dollars. I wonder how scalable it is. They only
| used:
|
| > 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?
| andix wrote:
| I'm wondering if this process can be GPU optimized. It's
| possible to rent really beefy GPU cloud instances for a few
| bucks per hour. <1 hour seems to be in reach.
| ryan-c wrote:
| I'm pretty sure I can do it in two hours.
| matthewdgreen wrote:
| 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 not all
| bad.)
|
| DKIM deniability is a particular hobbyhorse of mine [1]. These
| short keys are obviously not the way to achieve it, but I view
| this kind of thing as a result of the muddled thinking that's
| been associated with DKIM and the community's lack of desire to
| commit to the implications of an all-email signing mechanism.
|
| [1] https://blog.cryptographyengineering.com/2020/11/16/ok-
| googl...
| linsomniac wrote:
| 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.
| rsc wrote:
| In the link in the parent comment. :-)
| jabart wrote:
| Doing this only provides deniability in public. If this was
| brought to a court there are enough server logs to build
| out if that DKIM record was valid along with a number of
| DNS history providers.
| singpolyma3 wrote:
| As if courts care about any of that. They'll just ask the
| witness "did you send this email"
| irrational wrote:
| https://xkcd.com/538/
| speerer wrote:
| Counter-example: I've used DKIM as evidence in court.
| withinboredom wrote:
| Counter-example example: I've been an expert witness in
| court to prove an email was a forgery; using DKIM.
| cbozeman wrote:
| That would be a counter-counterexample, wouldn't it?
| jonas21 wrote:
| Nah, it supports the counter-example, so it's a counter-
| example example.
| speerer wrote:
| It'd be funny if we were working together and just
| telling the same story behind our aliases.
| withinboredom wrote:
| My case was a family court dispute where one parent
| forged an email from the other parent about the child's
| care. It was a pretty wild case. After that, I was pretty
| convinced some people are just evil.
| jillyboel wrote:
| Which is why you say "No". Then when they try to prove
| that you did in fact send it, this comes up.
| qingcharles wrote:
| Well, if you did send it then you just perjured yourself,
| so you better hope you don't get caught :)
| SmellTheGlove wrote:
| Right. There's generally going to be other evidence.
| Rotating the DKIM isn't going to save anyone relying on
| the shaggy defense.
| tptacek wrote:
| This isn't about evidence. In a court case, discovery and
| court orders can authenticate email messages even if
| providers publish their keys; the provider will have a
| record of having verified the email when it was received.
| But ATO attackers will not have access to those records.
| Ar-Curunir wrote:
| That was Matt Green, the person you replied to =)
| ryan-c wrote:
| I've been doing this since around 2018, and have seen a few
| others implement it.
|
| https://rya.nc/dkim-privates.html
| GTP wrote:
| Isn't deniability at odds with DKIM's goal? What would be the
| point of setting DKIM then? Sure, it helps with spam scores.
| But most companies rely on a major email provider to send
| emails, so maybe they wouldn't have deliverability issues
| anyway?
| marcosdumay wrote:
| Yes.
|
| Deniability and perfect forward secrecy are at odds with
| how people use email anyway. But that doesn't stop people
| from demanding both very loudly, and some people from
| promising them.
| matthewdgreen wrote:
| I don't know what you're saying. Most email isn't
| encrypted so PFS wouldn't apply to the content of email
| messages. When you mention PFS are you talking about
| email encrypted with something like GPG/PGP? Or are you
| talking about PFS in the context of the TLS connections
| used to protect SMTP? I'm not sure what "deniability"
| refers to in your post and how you think people use email
| in ways that would contraindicate it. Once I understand
| what you're saying, I guess we could move on to who the
| demanders and promisers are and what you think they're
| doing.
| dfc wrote:
| You should read the blog post Prof. Green linked to. All of
| your questions are addressed there.
| GTP wrote:
| 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
| spanning multiple messages, a spoofer wouldn't be able to
| properly answer the messages of the other party, as he
| doesn't receive them.
| tptacek wrote:
| 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.
| GTP wrote:
| But you need to convince someone that someone targeted
| you and used the published key to forge an email. Where
| is the difference?
| tptacek wrote:
| No you don't. You just say "that email is fake and you
| can't prove otherwise", and you're right. What's almost
| more important is: there is no reason not to give users
| that affordance. They literally do not benefit from the
| non-repudiability of their email archive. The OTR paper
| got this right 20 years ago, and in the process basically
| created the entire field of secure messaging.
|
| It is wild to see people argue against it! They're
| basically pleading with email providers to collude with
| attackers to violate their privacy.
|
| https://otr.cypherpunks.ca/otr-wpes.pdf
| GTP wrote:
| I think here is where the problem isn't purely a
| technical one anymore. You're right that, from a legal
| perspective, there is a difference as the burden of proof
| would now be on someone else. But, if this actually
| matters or not, depends entirely on the situation. If
| you're a criminal trying to get away with something then
| the change in the burden of proof is all you need. If
| instead you're a politician trying to avoid some
| imbarassment, the situation isn't any different: you're
| claiming in both cases that someone is trying to frame
| you for something you didn't say. In one case, this
| person stole your password, in the other he/she used an
| old and by now publicly available DKIM key. But if people
| believe you or not (and this would be everything a
| politician would care about) depends on factors outside
| the scope of cryptography. Regarding OTR: IIRC it is
| based on a shared secret. This can work for IM, but it
| wouldn't scale for emails as it would pose the key
| distribution issues that made us discover public key
| cryptography.
| tptacek wrote:
| If you are a politician trying to get away with
| something, the public might have an interest in your
| secure messaging system being bad, but you yourself do
| not. Secure messaging systems generally take the side of
| their users, not the public.
| IncRnd wrote:
| 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 stolen.
|
| Lying isn't a stronger defense to perform abuse than weak
| keys are for stopping abuse.
| GTP wrote:
| > They didn't change their password, so it wasn't really
| stolen
|
| 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.
| withinboredom wrote:
| 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.
| GTP wrote:
| > 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.
| CodesInChaos wrote:
| When using deniable authentication (e.g. Diffie-Hellman
| plus a MAC), the recipient can verify that the email came
| from the sender. But they can't prove to a third party that
| the email came from the sender, and wasn't forged by the
| recipient.
| jagged-chisel wrote:
| Mallory sends a message, forged as if from Alice, to Bob.
| How can Bob determine that it came from Alice and wasn't
| forged by Mallory?
| commandersaki wrote:
| This is always a possibility but I'm guessing the happy
| path is the more likely believable scenario and could be
| verified OOB.
| tialaramex wrote:
| No, no, in these systems Alice and Bob both know a
| secret. Mallory doesn't know the secret, so, Mallory
| can't forge such a message.
|
| However, Bob can't prove to the world "Alice sent me this
| message saying she hates cats!" because everybody knows
| Bob knows the same secret as Alice, so, that message
| could just as easily be made by Bob. _Bob_ knows he didn
| 't make it, and he knows the only other person who could
| was Alice, so he knows he's right - but Alice's cat
| hatred cannot be proved to others who don't just believe
| what Bob tells them about Alice.
| TomK32 wrote:
| Now it makes sense why Alice was sending me that kitten
| in a mixer video.
|
| But seriously, in a case before a court or jury, wouldn't
| there be much more evidence? Down to your own lawyer
| sending a complete dump of your phone with all those
| Sandy-Hooks-conspiracies and hate messages to the
| opposing side?
| reaperman wrote:
| Sometimes instead of a complete dump, you might mutually
| agree on a third party forensic lab to analyze your phone
| and only provide relevant details to the opposing side.
| Usually there's a few rounds of review where you can
| remove some details/records that are not relevant before
| the distilled records are sent to the opposing counsel.
| tialaramex wrote:
| Deniability is just that, the opportunity to deny. Will
| denying change what people believe? Well, maybe or maybe
| not. I'm sure you can think of your own examples without
| me annoying the moderators.
| Ar-Curunir wrote:
| The idea is to use a MAC instead of a signature. As long
| as Alice isn't compromised and sharing her key with
| Mallory (which she could do even in the signature case),
| when Bob receives a message with a valid MAC on it, he
| knows that Alice authorized the message.
| ralferoo wrote:
| That's not quite what he's saying.
|
| DKIM's goal is that the receiving system can trust that the
| message presented to it has come from a host that knows the
| key, and so could sign it. At the time that message is
| received, you should be able to assume that only people
| authorised to send from that domain are able to do so.
|
| By publishing older keys, you gain deniability back,
| because anybody could have forged the message and signed
| it. Even if you have timestamps that show when you received
| the message, the onus is one you to prove that those
| timestamps are not fabricated. This is a much harder
| problem because secrets can be revealed later but not
| forgotten.
|
| To be able to prove that you did it fact receive the
| message on that date, you'd probably have to record e.g.
| the message ID, signature and timestamp (perhaps all
| encrypted with a key that you can reveal later) on a
| blockchain, which would then serve as proof of when the
| message was received. Even then, you'd still have to prove
| that the key hadn't been disclosed before that time.
| tptacek wrote:
| No. DKIM is meant to apply to emails in transit; it is part
| of the transaction of exchanging emails. But DKIM
| signatures are verifiable long after that transaction has
| completed. That was not an intended feature of DKIM, and
| it's a grave privacy violation.
|
| To satisfy DKIM's design goal, you only need a "current"
| DKIM key that is secure for a window of time. When that
| window of time passes, you rotate the secret and publish
| your own key, repairing (hopefully) much of the privacy
| injury.
| jonahx wrote:
| > To satisfy DKIM's design goal, you only need a
| "current" DKIM key that is secure for a window of time.
| When that window of time passes, you rotate the secret
| and publish your own key, repairing (hopefully) much of
| the privacy injury.
|
| If this occurs, is DKIM privacy safe? To make sure I
| understand, by publishing the private key after a period,
| that allows for repudiation, since any real email at that
| point _could_ have been faked using the published private
| key?
| ryan-c wrote:
| Repudiation is the goal.
| rstuart4133 wrote:
| Repudiation doesn't work if the receive discards the
| email if it isn't signed, or marks it as DKIM validated
| when it is received. Many receivers using independent
| email providers like gmail, so the sender has no control
| over whether it happens or not. Both practices are common
| today, so it likely it does happen.
|
| Rotating the key does make the claim "I have proof he
| sent it" a litter weaker, as it's no longer as easy to
| prove. But only a little as "your honour, it is marked as
| DKIM verified by the independent email provider he uses"
| is pretty solid.
| tptacek wrote:
| Rotating the key and publishing the private key
| _destroys_ the ability of an after-the-fact attacker
| (someone who pilfers older mails out of your inbox) to
| prove they obtained a real email. It 's not an "only a
| little" thing; it's categorical.
| withinboredom wrote:
| The point of DKIM is to provide DURING TRANSIT that a
| server is the server is allowed to send emails from that
| domain. Once the transaction is completed, it doesn't
| matter if the key even continues to exist: it was
| verified during transit.
|
| The fact that people do not rotate keys or use secure
| keys means that you can use it for other things as well,
| like detecting forgeries. It wasn't meant for humans, but
| for machines.
| rstuart4133 wrote:
| > it's a grave privacy violation.
|
| I'm missing something here. DKIM mostly proves an email
| from person@from.me was sent by a server @from.me
| controls. There is also a bloody great audit trail inside
| of the email with together with SPF can do a pretty good
| job of proving the same thing.
|
| I'm struggling to see how an email sent to me, that
| presumably was always intended to be readable by me could
| suddenly become a privacy violation because it's signed.
| That is doubly so if I won't receive it if it isn't
| validly signed when it is received, which is often the
| case.
| tptacek wrote:
| It's nobody else's business whether the emails in your
| inbox are valid or not, and that's basically all non-
| deniable DKIM signatures do: durable secure verifiable
| DKIM signatures are "security feature" with real-world
| value _exclusively for attackers_.
| singleshot_ wrote:
| If you're under Rule 26 discovery or disclosure
| requirements, it absolutely might be my business whether
| emails in your client are valid, but I suppose you could
| classify opposing counsel as an "attacker," so you're not
| wrong.
| tptacek wrote:
| Note, just to rub this in: you don't even get the
| verification you're looking for, because DKIM verifies
| domains and not users.
| A1kmm wrote:
| I'm not sure privacy violation is necessarily the right
| term to help people understand why long-term non
| repudiation is an undesirable property for some people.
|
| It comes down to if a third party gets access to your
| emails (e.g. through a server compromise), should they be
| able to prove to a fourth party that the emails are
| legitimately yours, vs completely faked? Non repudiation
| through strong DKIM keys enables this.
|
| Example: Third party is a ransomware gang who releases
| your emails because you didn't pay a ransom after your
| email server was compromised. Fourth party is a
| journalist who doesn't trust the ransomware gang, but
| also wants to publish juicy stories about your company if
| there is one, but doesn't want to risk their reputation /
| a defamation case if the ransomware gang just invented
| the emails.
| tptacek wrote:
| Non-repudiation is virtually always undeniable in
| general-purpose messaging systems. Revealing to a
| stranger whether a message is valid is a concession to
| that stranger, not a benefit to the email's owner. This
| property is called "deniability" and most secure
| messaging systems go way out of their way to have it.
| matthewdgreen wrote:
| Do take a look at the blog post I cited above, where I go
| into this in loads of detail. The TL;DR is that DKIM only
| needs to ensure origin authenticity for the time it takes
| to deliver an email, which is usually a few hours or a day
| at most.
|
| The unintentional problem DKIM is causing is that it
| actually provides non-repudiation for many years. Those
| signed emails can sit in someone's mailbox for years, then
| get stolen by a hacker. The hacker can then blackmail the
| owner by threatening to dump the email trove, or for
| newsworthy targets they can just do it. Reasonable people
| (e.g., high-integrity newspapers, courts of law) will say
| "how can we trust that these stolen emails are authentic
| given that there's no chain of custody?" DKIM signatures
| nearly answer that question, which makes stolen emails much
| more valuable than they would be otherwise.
| dotancohen wrote:
| > Reasonable people (e.g., high-integrity newspapers,
| courts of law) will say "how can we trust that these
| stolen emails are authentic given that there's no chain
| of custody?" DKIM signatures nearly answer that question,
| which makes stolen emails much more valuable than they
| would be otherwise.
|
| Thank you for clarifying where the vulnerability chain
| begins and ends.
| lupusreal wrote:
| Meanwhile in the real world, screenshots of emails without
| any cryptographic authentication at all are good enough to
| send people to prison.
| anonym29 wrote:
| I absolutely believe you - lawyers, judges, and juries
| alike tend to be technologically illiterate, but do you
| have any references/links to this happening?
| OJFord wrote:
| In particular where the defendant denies the veracity of
| the screenshot.
| matthewdgreen wrote:
| If you read the blog post, you'll see that newspapers
| frequently verify DKIM signatures on stolen email corpora
| before they publish about them. Eg:
| https://www.propublica.org/nerds/authenticating-email-
| using-...
| tsimionescu wrote:
| They were asking for evidence that people have been
| convicted based on screenshots of emails, almost the
| opposite of using DKIM to authenticate emails.
| tptacek wrote:
| The issue here isn't rules of evidence, it's user privacy.
| In the real world, DKIM has repeatedly been used to violate
| privacy. More importantly: latent verifiable secure DKIM
| signatures on archived emails offer _no value_ to users;
| they literally only have real-world value to attackers.
| tsimionescu wrote:
| > More importantly: latent verifiable secure DKIM
| signatures on archived emails offer no value to users;
| they literally only have real-world value to attackers.
|
| I don't think this is quite true. First of all, this is
| not only valuable to attackers, it's also valuable in a
| court of law to establish the truth of what happened.
| Secondly, it can be valuable to me to be able to prove
| that you sent me an email, even if you wished to deny it,
| also mostly in legal contexts.
| tptacek wrote:
| Those are cases where DKIM is working _against_ the user!
| I get that we can come up with cases where we 're glad
| some hapless user is undone by DKIM, but when we're
| discussing messaging security, we generally take the side
| of the hapless user, not the courts and tort lawyers!
| reaperman wrote:
| Only if the defendant doesn't challenge the evidence. If
| I'm the defendant and I know I sent those emails, I'm not
| going to challenge the screenshot. If I know I did not send
| those emails, then I'll do my best to pay for forensic
| analysts to generate evidence to exonerate me.
| qingcharles wrote:
| Experts are expensive. Most defendants never get them.
| phkahler wrote:
| What's the problem with verifiable email? You can just delete
| old emails (if gmail or whoever archives them that's another
| problem). Most people probably operate under the assumption
| that email is verifiable in some way anyway. If you receive
| malicious email, isn't it a good thing to be able to verify
| where it came from? Doesn't that benefit senders and
| receivers alike? Or is this a case of "I want to verify you,
| but I don't want you to verify me"?
| infogulch wrote:
| 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.
| meindnoch wrote:
| 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.
| kstrauser wrote:
| The idea is that for spam filtering purposes, you can
| prove this morning that the email I sent you this morning
| came from me, because I'm the only person who had the
| signing key on it. Anyone else could validate that too.
|
| But let's say I publish that signing key tomorrow. Once I
| do that, you can't prove I sent today's mail because
| anyone could've used that published key tomorrow forget
| the signature.
| meindnoch wrote:
| Ok, so there's a time window where it's possible to prove
| that you were the sender. And if I use a qualified
| timestamp service to sign all messages arriving in my
| inbox, then I can prove that you were the sender
| indefinitely.
| kstrauser wrote:
| Something like that, as long as you can also prove I
| hadn't published the key prior to that. If I publish at
| random times and to random URL, that may be challenging.
| freedomben wrote:
| Yes, but then it also encroaches on ability to verify
| that you were the sender when receiving the original
| email. Basically, unless the recipient also checks
| whether the current DKIM key has been published, then
| they can't trust it because it may be published. If it's
| being published at random times and to a random URL, then
| it's nearly impossible to actually check.
|
| So I agree that it brings deniability, but I don't agree
| that it still meets the original purpose of verifying the
| sender.
| kstrauser wrote:
| That's all true, but I bet 99.99% of all email is
| delivered within a minute or so of being send. There are
| exceptions, of course, but in practice the whole thing is
| pretty fast.
|
| So there's some threat modeling, too. Are you trying to
| email someone highly adversarial? Maybe you're at a law
| office or such and that's the case! This wouldn't help a
| lot there. Not everyone is immediately forwarding all
| inbound mails to a timestamping service though.
|
| (I don't have skin in this game, so I'll probably duck
| out after this. I don't have opinions on whether
| publishing old DKIM keys is good or bad.)
| devmor wrote:
| Imagine that yesterday, I had only one house key, and I
| left a copy of it in your mailbox so you could come into
| my house to borrow a cup of sugar while I was out. You
| can be sure I allowed it, because you know I had only one
| key.
|
| Today, I made 3 copies of my housekey and gave them to
| friends. You still know that I was the one that allowed
| you entry into my house, but you can not prove to anyone
| else that I was the one that made the copy, because there
| are now 3 other people that could do that.
|
| (For this example, imagine I made the key copies at home
| and didn't go to a locksmith who could verify when they
| were made, since we don't need a locksmith to do software
| crypto)
| infogulch wrote:
| Yes it seems crazy, but besides the obvious "leak your
| own key" as other comments mentioned, this is actually
| possible. This is one of the biggest discoveries in
| cryptography in the last decades and its implications are
| still being researched. I dug around and found this
| article which seems to do a pretty good job describing
| the cryptographic concepts of "non-transferability" /
| "deniability" / "deniable authentication" for a lay
| audience: https://dinhtta.github.io/zkp/ Also:
| https://en.wikipedia.org/wiki/Deniable_authentication
| meindnoch wrote:
| Hmm. So basically any protocol with a shared key?
|
| I.e. a symmetric key is shared between you and me. If I
| receive a message with that key, I know it's from you
| because the key is only known by you and me, and I know I
| wasn't the sender, so it must be you. But any third party
| can only say that the message was by one of us.
| d1sxeyes wrote:
| Simple, I tell you that in my message, if it's genuine,
| I'll use the word "apple" somewhere.
|
| You tell me that you'll use the word "banana".
|
| Provided no-one except you knows that my secret word is
| "apple", you know the message came from me.
|
| But it's perfectly possible for _you_ to fake a secret
| message and sign it "Love d1sxeyes, P.S. apples", and so
| our approach only works between the two of us. A third
| party probably can't even confirm that "apples" was the
| correct keyword, and even if they could, that can only
| prove that one of us wrote it, they can't definitively
| say which one of us.
|
| Now extrapolate this to using some more sensible
| mechanism than dictionary words.
| erikerikson wrote:
| Both parties use the same key:
| https://en.m.wikipedia.org/wiki/Symmetric-key_algorithm
| toast0 wrote:
| It's pretty simple with a couple concepts.
|
| If Alice and Bob each have a public/private key pair,
| they can do a diffie-hellman key exchange to form a
| common secret. If they use that secret to authenticate a
| message, then it can be shown that only Alice or Bob sent
| the message. If you're Alice or Bob, this is what you
| want to know --- either you or your corespondent sent it,
| and if you didn't send it, your correspondent did.
|
| But if Alice or Bob asks Carol to validate it, Carol can
| only determine that Alice or Bob sent it, and perhaps not
| even that. Anyone in possession of the secret used to
| authenticate the message can also make a message that
| would be deemed authentic. If you have participation of
| Alice or Bob, you can show that the secret was derived
| from DHE with Alice and Bob's key pairs, but that's all.
|
| This is nifty and useful, but it's more appropriate for
| end to end communication, which is not the domain of
| DKIM. Email is a multi point store and forward system,
| where each point would like to know if a message is
| authentic; deniability like this would probably mean
| either
|
| a) only the final destination could determine
| authenticity and therefore intermediates would not be
| able to use authenticity as a signal to reject mail
|
| b) only the first intermediate could determine
| authenticity; it could be used to reject mail, but the
| end user would have to trust the intermediate
|
| Both of these are workable systems, but DKIM provides
| that all intermediates and the end user can know the mail
| was authorized (to some degree) by the origin system.
| matja wrote:
| I don't think this rationale is correct. DKIM doesn't
| authenticate a user, since the user doesn't the private key -
| DKIM authenticates that the MTA knows the private key on
| behalf of the domain owner, which isn't necessarily the users
| using that domain to send email.
|
| What's more dangerous is that a jury wouldn't know the
| difference.
| JackSlateur wrote:
| Ha, at least ! Thank you for the comment.
|
| If there is some mail from my addr, with a valid DKIM
| signature, it proves nothing: - perhaps the mail was sent
| by somebody else on the same plateform, but in my name
| (identity usurpation of the user part of the mail) -
| perhaps somebody got illegal access to my email account,
| without me knowing - .. ?
|
| In no case it proves that I, as a human, sent this email.
|
| But of course, justice is a fiction that cannot exist:
| there is no justice, only probabilities (and feelings :( ).
| rstuart4133 wrote:
| From the blog:
|
| > The fix would cost you basically nothing, and would remove
| a powerful tool from hands of thieves.
|
| Maybe that was true a while ago, but it becoming much less
| true now. Most people and organisations outsource the email
| handling to the likes of Google and Microsoft. They tend to
| reject email that isn't DKIM signed, and add a "DKIM
| validated" header to those that are. "Tend" is probably too
| weak a word now - email that isn't signed isn't likely to be
| delivered.
|
| So the mostly likely scenario now is "someone steaks email
| that can no longer be DKIM validated, but it is possible
| prove it was DKIM validated when it was received". If that's
| true rotating keys doesn't help.
| tptacek wrote:
| The idea isn't to stop Google from signing and validating
| DKIM. It's that the major players who do DKIM should rotate
| and publish their keys, so that at any given instant their
| current DKIM key is only valid for N hours, and after that
| it's public, so anyone can forge backdated messages.
| brightball wrote:
| Reminds me of the story of a guy cracking one thinking it was a
| Google headhunting challenge.
|
| https://www.wired.com/2012/10/dkim-vulnerability-widespread/
| stingraycharles wrote:
| Just as an interesting FYI for those who care: the parent
| poster is the CTO of CloudFlare.
| codegladiator wrote:
| Your blog got a mention in the comments of
| http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-...
| littlestymaar wrote:
| First time a 512-bits RSA number (RSA-155) was factored was in
| 1999!
| qwertox wrote:
| Because we need that compute for our React frameworks.
| pjmlp wrote:
| Don't forget Electron as well.
| undersuit wrote:
| My Chromebook all of the sudden needs compute to serve ads.
| RIP uBlock.
| dang wrote:
| " _Eschew flamebait. Avoid generic tangents._ "
|
| We detached this subthread from
| https://news.ycombinator.com/item?id=42633787.
| viviansolide wrote:
| Thanks for this
| kingforaday wrote:
| Love the practicality demonstrated here. It is unclear how old
| this article is. Based on the poster's previous submissions, I
| assume today?
| awulf wrote:
| I published the article today, though it was written a few
| months ago (when the DKIM record was still online).
| philipwhiuk wrote:
| Was redfin aware you were trying to break their DKIM record?
| Avamander wrote:
| It was already broken.
|
| This comment also serves as a public notice that I'm going
| to factor all the 512-bit DKIM RSA keys out there from now
| on. Start migrating.
| TheChaplain wrote:
| Anyone know or have experience how well supported ECDSA is for
| DKIM?
| paulnpace wrote:
| DKIM supports Ed25519-SHA256.
|
| https://datatracker.ietf.org/doc/html/rfc8463
| 1oooqooq wrote:
| specs supports many things. I believe the question was more
| about the real world.
| paulnpace wrote:
| In the real world, DKIM specs only support Ed25519 and RSA.
| asim wrote:
| I think the cynic in me says "so what" mostly because dkim as an
| ancient technology is hardly secure. I don't think we're any less
| prone to email fakery and spam. I'd be interested to see a
| possible new solution or a revamping of email as a protocol but
| that's unlikely. We're more likely to keep it like snail mail as
| we prioritise different forms of communication. Unfortunately
| nothing has beat the universal email address on the internet.
| Here's hoping we come up with a chat standard that sticks and
| people run a user@server.com chat server where you can
| communicate from anywhere. Sorry xmpp, you don't count.
| alt227 wrote:
| 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.
|
| Changing any addressing on the internet is tough because you
| always have to have backwards compatibilty, which kind of ruins
| the point of moving forward.
| lazide wrote:
| Haha, definitely not true outside of the US and Western
| Europe.
|
| Most of Asia (and probably Africa) uses phone #.
| alt227 wrote:
| Thats because those are mostly developing countries which
| were late to the internet party, and are accessed mainly
| through mobile. Phone # could well be a replacement for
| email globally in the future, once all the younger
| generation grow up and rule the world.
| MattJ100 wrote:
| Of course XMPP doesn't count... even though it's a standard,
| allows people to run their own server, have an email-like
| address of user@server, allows you to communicate from
| anywhere, and is how I, my family, and many many others chat
| online? :)
| wolrah wrote:
| Email-style user@host.domain addressing is also used in SIP.
|
| At one point in time you could reach me on email, XMPP, and SIP
| all using the same identifier. We dropped XMPP about a decade
| ago when all the major service providers stopped federating
| with it, but if you know my work email address you can also
| call my desk phone using the same identifier.
| jedisct1 wrote:
| That can be done locally on a laptop, no need for the cloud.
| colmmacc wrote:
| Breaking a 512-bit key for a good demonstration is very valuable
| security research, even if it's been done before. It's also legit
| to call out "Hey, here's a list of folks still using 512 bit,
| they should move off." ... but for me, actually cracking a real-
| world in-use key crosses an ethical line that makes me
| uncomfortable. IANAL but it might even be criminal. Just seems a
| bit unnecessary.
| michaelmior wrote:
| 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.
| colmmacc wrote:
| 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's
| also plenty of Police Departments who might well arrest you
| for that.
| michaelmior wrote:
| > showing "hey it fits"
|
| 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.
| phoe-krk wrote:
| _> for me, actually cracking a real-world in-use key crosses an
| ethical line that makes me uncomfortable_
|
| They've contacted the company with the vulnerability and
| resolved it before publishing the article - search the original
| article for the substring "now no longer available".
|
| Usually, you demonstrate that an online system is vulnerable by
| exploiting that vulnerability in good faith, documenting the
| research, and submitting it for review. It does not matter if
| you're cracking an encryption scheme, achieving custom code
| execution for a locked-down game console, proving that you can
| tamper with data in a voting machine, or proving that you can
| edit people's comments on a Google Meet Q&A session - the
| process is the same.
|
| If you _say_ something 's vulnerable, people can shrug it off.
| If you say _and prove_ something 's vulnerable, the ability to
| shrug it off shrinks. If you say and prove something's
| vulnerable and that _you 'll publish the vulnerability_ -
| again, using the industry standard of disclosure deadlines and
| making the vulnerability public after 60-or-so days of
| attempting to contact the author - the ability to shrug it off
| effectively disappears.
| colmmacc wrote:
| I read the article, and I don't think it changes it. If you
| crack someone's key, they might be well within their rights
| to pursue a criminal prosecution. Of course it would also
| have a Streisand effect and there's reasons not to, but I
| personally wouldn't allow or recommend a security researcher
| to do it. It's needlessly risky.
|
| In general, subverting security and privacy controls tends to
| be illegal in most jurisdictions. Best case is when you have
| clear permission or consent to do some testing. Absent that
| there's a general consensus that good faith searching for
| vulnerabilities is ok, as long as you report findings early
| and squarely. But if you go on to actually abuse the
| vulnerability to spy on users, look at data etc ... you've
| crossed a line. For me, cracking a key is much more like that
| second case. Now you have a secret that can be used for
| impersonation and decryption. That's not something I'd want
| to be in possession of without permission.
| Avamander wrote:
| They can pursue what they want, it doesn't mean it will go
| through.
|
| Looking at public data, using some other public knowledge
| to figure out something new does not make it inherently
| illegal. They didn't crack it on their systems, they didn't
| subvert it on their systems, they did not use it against
| their systems. I'd love to see some specific examples under
| what it could be prosecuted under specifically. Because
| "that door doesn't actually have a lock" or "the king
| doesn't actually have clothes" is not practically
| prosecutable anywhere normal just like that.
|
| Especially in the EU, making such cryptographic blunders
| might even fall foul of NIS2, should it apply to you.
|
| In general this also quickly boils down to the topic of
| "illegal numbers"
| (https://en.wikipedia.org/wiki/Illegal_number) as well.
| colmmacc wrote:
| It's more like the door has a weak lock that can be
| picked. Just like many real world doors do. Here's how it
| would go in court:
|
| "Are you aware that this key could be used to decrypt
| information and impersonate X?"
|
| "Are you aware that this key is commonly called a Private
| key?"
|
| "Are you aware that this key is commonly called a Secret
| key?"
|
| "Are you aware that it is common to treat these with high
| sensitivity? Protecting them from human eyes, using
| secure key management services and so on?"
|
| "Was it even necessary to target someone else's secret
| private key to demonstrate that 512-bit keys can be
| cracked?"
|
| "Knowing all of this, did you still willfully and
| intentionally use cracking to make a copy of this secret
| private key?"
|
| I wouldn't want to be in the position of trying to
| explain to a prosecutor, judge, or jury why it's somehow
| ok and shouldn't count. The reason I'm posting at all
| here is because I don't think folks are thinking this
| risk through.
| Avamander wrote:
| If you want to continue with the analogies, looking at a
| lock and figuring out it's fake does not constitute a
| crime.
|
| That key can not be used to decrypt anything. Maybe
| impersonate, but the researchers haven't done that. It's
| also difficult to claim something is very sensitive,
| private or secure if you're publicly broadcasting it, due
| to the fact that the operation to convert one to an
| another is so absolutely trivial.
|
| And they did not make a copy of their private key, they
| did not access their system in a forbidden way. They
| calculated a new one from publicly accessible
| information, using publicly known math. It's like
| visually looking at something and then thinking about it
| hard.
|
| I wouldn't want to explain these things either, but such
| a prosecution would be both bullshit and a landmark one
| at the same time.
| alt227 wrote:
| > If you crack someone's key, they might be well within
| their rights to pursue a criminal prosecution.
|
| If that were true there would be no market for white hat
| hackers collecting bug bounties. You need to be able to
| demonstrate cracking the working system for that to be of
| any use at all. No company will listen to your theoretical
| bug exploit, but show them that you can actually break
| their system and they will pay you well for disclosure.
| colmmacc wrote:
| Bug bounties are a form of consent for testing and
| usually come with prescribed limits. Prescribed or not,
| actually getting user data tends to be a huge no go.
| Sometimes it can happen inadvertently, and when that
| happens it's best to have logs or evidence that can
| demonstrate you haven't looked at it or copied it beyond
| the inadvertent disclosure.
|
| But to pursue data deliberately crosses a bright line,
| and is not necessary for security research. Secret keys
| are data that be used to impersonate or decrypt. I would
| be very very careful.
| yellow_lead wrote:
| You can say this about a lot of security research, i.e "Showing
| a bug is exploitable is one thing, but writing a POC is
| crossing the line!" The problem is that most people won't
| listen to your security research unless you demonstrate that
| something is actually possible.
| mmastrac wrote:
| Breaking a key isn't criminal. It's just math. Sending emails
| that would constitute fraud or a violation of another
| jurisdictional law, relying on that math, is illegal. But again
| -- it's not the math, it's the action and intent.
|
| Pointing out that someone is doing something stupid is also not
| illegal, though they make try to make your life painful for
| doing so.
| colmmacc wrote:
| Secrets themselves are often regarded as sensitive
| information, and often also categorized in the highest
| classifications for information protection. This stuff isn't
| just a game, and in my experience it's not how law
| enforcement authorities or courts see things.
|
| Just as if you made a copy of the physical key for a
| business's real-world premises, you could well find yourself
| in trouble. Even if you never "use" it.
| cafeinux wrote:
| As mentioned in the article, the key's no longer available and
| I presume the article has been released only after responsible
| disclosure was done and with the approval of the key owner
| (hope so). At this point, it's not more unethical than any
| other security research performed in the same conditions and
| with the same outcome.
| croemer wrote:
| They only called out 1 out of the ~1.7k domains they found with
| keys shorter than 1024bits.
|
| They _did_ call out the 3 of 10 tested major email providers
| that don't follow the DKIM RFC properly: Yahoo, Tuta, Mailfence
| (after having notified them).
| DarkmSparks wrote:
| "as RSA keys shorter than 1,024 bits are considered insecure, and
| their use in DKIM has been deprecated since the introduction of
| RFC 8301 in 2018."
|
| LOL. One of my favourite internet flame wars was circa 2007 (in
| and around discussing the incoming financial crises) and we got
| talking about encryption and how none of it actually "works".
|
| Particularly vile troll, and iirc also owner of the site bet me
| $50,000 I couldn't reverse the 512 RSA key he posted (created by
| openssl).
|
| He got the factorisation less than an hour after he made the
| post.
|
| Strangely, the entire site disappeared pretty quickly after that
| (and it's not on wayback machine).
|
| given where the math guys are now with GNFS I'm not sure I would
| trust 8192 bit RSA in 2024, 2018 for dropping 512 bit was already
| more than a decade late.
| matja wrote:
| Was it a key affected by CVE-2008-0166 ? :)
| bmenrigh wrote:
| CADO-NFS makes this surprisingly easy to do. A few weeks back I
| factored a 512bit RSA DKIM key for work using my desktop computer
| in only 28 hours. Specifically, an AMD Zen 5 9900X.
|
| Unfortunately 1024 bit keys are still out of reach of a hobbyist
| effort but could be pulled off by academics roughly of the same
| scale as the 2010 effort to factor a 768 bit key
| (https://eprint.iacr.org/2010/006.pdf)
| austin-cheney wrote:
| In case anybody is wondering about whether the 512bit number is
| big or small it depends on whether it is symmetric or asymmetric
| encryption technique. Always presume asymmetric encryption is 8x
| weaker than symmetric encryption.
|
| DKIM is asymmetric. So a 512bit DKIM equivalent symmetric hash
| would be 64bits, which is long broken. Even 160bit SHA1 is
| considered broken. A DKIM of roughly equivalent strength to a
| 512bit SHA3 would be at least 4096bits and still does not include
| SHA3's techniques for mitigating replay attacks.
| bmenrigh wrote:
| DKIM is not an encryption algorithm. It is a standard for
| embedding and validating signatures in email headers.
|
| Unfortunately DKIM only supports rsa-sha1 and rsa-sha256
| signatures
| (https://datatracker.ietf.org/doc/html/rfc6376/#section-3.3).
| It'd be nice to see DKIM get revised to allow Ed25519 or
| similar signatures.
| Avamander wrote:
| Ed25519-SHA256 support has existed for a while now.
|
| https://datatracker.ietf.org/doc/html/rfc8463
| bmenrigh wrote:
| Oh excellent. I didn't realize rfc6376 had been superseded.
| austin-cheney wrote:
| Wikipedia says it is a correlation check based upon a public
| key based signature. How is that not a form of encryption?
| Google says encryption is a process that scrambles data into
| a secret code that can only be decoded with a unique digital
| key, which is exactly what public keys are for.
| dist-epoch wrote:
| > Always presume asymmetric encryption is 8x weaker than
| symmetric encryption.
|
| RSA encryption is 10x weaker than Elliptic curve (224 bits ECC
| ~= 2048 bits RSA). Both are asymmetric.
|
| Alternatively, asymmetric Elliptic curve is as strong as AES
| symmetric encryption. But it's quantum vulnerable, of course.
| dizhn wrote:
| > Although most providers correctly identified the 512-bit key as
| insecure and rejected our DKIM signature, three major providers
| -- Yahoo Mail, Mailfence, and Tuta -- reported a dkim=pass
| result.
|
| Did google really FAIL because of DKIM signature being insecure
| or because SPF failed?
| awulf wrote:
| The DKIM verification failed with the result "dkim=policy (weak
| key)," as it should according to RFC 8301: "Verifiers MUST NOT
| consider signatures using RSA keys of less than 1024 bits as
| valid signatures."
| andix wrote:
| Any tips on how to easily fetch the key length of DKIM-Keys from
| DNS? Just by looking at the DNS entries I can't easily determine
| the key length ;)
| awulf wrote:
| An easy way is to check the length of the p= value in the DKIM
| record. If it's around 216 characters, it's likely a 1024-bit
| key. A 2048-bit key usually has about 388 characters.
| zorgmonkey wrote:
| If you're going to do this you should also check for k=rsa
| since other key types will be different lengths. But I'd
| really recommend something like in the other comment where
| you base64 decode and parse it with something like openssl.
| deathanatos wrote:
| Fetch the TXT record; you should see something like,
| k=rsa; ... p=<a bunch of base64 data>
|
| The base64 data is an RSA public key. You can print in textual
| form with something like, your-clipboard-paste-
| command | base64 -d | openssl rsa -pubin -noout -inform der
| -text
|
| The first line of output will be something like,
| Public-Key: (2048 bit)
|
| Which is the key length.
|
| If you fetch with `dig`, note that sometimes dig will do this:
| example.com. 1800 IN TXT "k=rsa; t=s; p=blahblahblahblah"
| "blahblahblah"
|
| I.e., it breaks it up with a `" "`; remove those, that's not
| part of the data. I.e., concat the strings dig returns, then
| parse out the p=, then base64 decode, then openssl.
|
| (You can also do what the article does, but without Python,
| which is jam that base64 between some PEM header guards like
| the article does, and then feed it to openssl. Same command,
| but you don't need the -inform der b/c the "in[put] form[at]"
| is now pem, which is the default.)
| cchance wrote:
| why aren't people just defaulting to 2048?
| daneel_w wrote:
| They are defaulting to 1024-2048. Systems signing with 512 bit
| keys are an outlier.
| briffle wrote:
| They are, but someone set this up in 2016 or so, and nobody has
| changed it :) Most likely the person got laid off, or went
| somewhere else, and nobody on the team has any idea about it.
| croemer wrote:
| Slight change of title. The leading "How" was dropped. Original:
| "How We Cracked a 512-Bit DKIM Key for Less Than $8 in the Cloud"
| Uriopass wrote:
| Dropping the How is part of Hackernews guidelines
| layer8 wrote:
| There's no such guideline. It's just part of the default
| title normalization. The submitter can adjust it afterwards.
| gauravphoenix wrote:
| I don't understand why didn't Yahoo fail due to SPF check
| failure.
| jaza wrote:
| Considering that Yahoo doesn't really exist anymore, and that
| Yahoo Mail is just a relic of Yahoo's heyday that is somehow
| still hanging around, I assume nobody has bothered to actually
| maintain its handling of security protocols for about a decade.
| fortran77 wrote:
| I got an email from Bank of America yesterday about a problem
| setting up my account. I had set up a new account, and this email
| knew that, and knew the name of the company, etc. There were no
| links in the email, just a note to call the BofA business number.
| I verified the number on the BofA website -- it was the same
| number -- and I called them.
|
| They couldn't tell me why I got the email, and what the problem
| was with my account. The representative couldn't see a record of
| this email set.
|
| I'm 100% certain this email came from Bank Of America. There was
| nothing in the email that was phishing -- no links, no bad phone
| numbers.
|
| The SPF, DKIM, and DMARC all passed googles's ARC-Authentication-
| Results. The DKIM key is 2048 bits long.
|
| I asked Bank of America to investigate, and they said "it must
| have been a phishing message" and sent me a link on how to look
| out for phishing.
|
| I'm pretty sure this was just a glitch; some system that does
| some consistancy check ran too early while the account was being
| set up and generated that email.
|
| However, because they told me it was "phishing" I just sent a
| FedEx to the CTO with the complete paper trail advising them that
| EITHER their DKIM keys were compromised and they need to issue a
| public warning immediately OR their incompetent staff and IT
| system gave me the runaround and wasted an hour of my time.
| Either way, I want a complete investigation and resolution.
| prophesi wrote:
| This is the reason I had to stop using Hover for DNS management.
| They don't support TXT records longer than 255 characters, and
| I've not found any instance of someone getting split records to
| work with Hover. Ended up using Digital Ocean for it. I would
| love for elliptic curve crypto to become the status quo if this
| is going to continue to be an issue for yet another decade.
| dusted wrote:
| If you want to try something fun:
|
| Provision a 4096-bit DKIM key.
|
| Every online DKIM/SPF checker will say all is good when looking
| at your DNS.
|
| They will also fail any test email you send, with more or less
| excellent descriptions such as:
|
| STATUS: Fail
|
| DKIM: Pass
|
| SPF: Pass
|
| There's this fun thing that, apparently:
|
| It's permitted and valid to use keys larger than 2048 bits in
| your DKIM entry.
|
| It is not, however, required to process keys larger than 2048
| bits.
|
| This cost me some hair to learn the hard way.
| yieldcrv wrote:
| Thanks for sharing this article, I think people have been doing
| this for some time!
|
| 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.
___________________________________________________________________
(page generated 2025-01-08 23:00 UTC)