[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 : 756 points
Date : 2025-01-08 12:32 UTC (1 days 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.
| sam_lowry_ wrote:
| I don't know what social circle I should be part of to
| consider email unsecure.
|
| Even Russian spies use mail.ru and their emails are
| compromised not by SMTP MitM but by weak passwords,
| google for "moscow1 moscow2 password" to see what I am
| talking about )
|
| Anyway. Back to the technical point. Email servers pretty
| much always use TLS to talk to each other. The connection
| may degrade to non-encrypted for backwards compatibility,
| unlike HTTPS. But it's vanishingly rare.
|
| So, for all practical purposes that affect ordinary
| citizens: injection, scanning and sensitive information
| extraction, email in transit is quite secure.
| 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.
| btdmaster wrote:
| That's not correct. Consider, for example, a processor
| that can handle 2^31 computations per second. 2^32
| operations can be computed in 2 time units, whereas 2^64
| operations will take 2^33 time units.
|
| search_space(n: number_of_bits) = 2^n * k
|
| so search_space(1024)/search_space(512)=2^512, not 2^2.
|
| Asymptotics in GNFS are better[0], but only on the order
| of e^(cbrt(512 * 64/9)) times more work, not 2^2.
|
| This would give an approximation of
| math.exp(math.cbrt(512 * 64/9))*$8 = $40 million for 1024
| bits.
|
| [0]
| https://en.wikipedia.org/wiki/General_number_field_sieve
| DarkmSparks wrote:
| Pretty sure the search cost of GNFS is (bits)^2, the
| search cost of brute force is 2^(bits), if it was
| 2^(bits) GNFS would be no better than brute force.
|
| ->but only on the order of e^(cbrt(512 * 64/9))
|
| e^(log(n)) = n
| littlestymaar wrote:
| Come on! Not only your math is ridiculous (you can't just
| square amounts of money, just consider how it would work
| if you changed currency: $8 is 1260Y=, squares it makes
| it 1587000Y= which is $10k != $64) but believing that
| RSA-2048 is factorizable in $4k is hilarious.
|
| > none of it is "brute force"
|
| It's not exhaustive search like it would be for symmetric
| encryption, but it's still somewhat brute-force
| (especially since RSA keys are inflated in size compared
| to symmetric encryption to accommodate for their
| vulnerabilities), put more clearly what I meant was "not
| without theoretical breakthrough unknown to the public".
|
| BTW, it's not a very good idea to lecture people with
| actual crypto knowledge (even though mine is quite rusty
| now for I have not done any serious stuff for 15 years)
| when your own comes from ill-understood YouTube
| vulgarization videos.
| DarkmSparks wrote:
| I personally factored 512 bit numbers in 2007 for a lot
| less than $8, so tbh I'm going to say your overestimation
| of your knowledge of cryptology is far more hilarious
| than my paranoia about the potential truth of claims made
| by people claiming to be experts in cryoptology.
|
| Your claim that factoring a 256bit number would cost
| fractions of a cent rather than my claim of roughly $3 is
| also very easily verifiable.
|
| Further I'll note you sound exactly like the kind of
| person insisting diffie hillman was a good key exchange
| mechanism prior to Snowdens disclosures. good luck with
| that.
| littlestymaar wrote:
| I'm charitably sharing this to you:
| https://news.ycombinator.com/item?id=42645216 because
| someone actually interested in learning things asked the
| right question. May you sleep less ignorant tonight.
|
| > Further I'll note you sound exactly like the kind of
| person insisting diffie hillman was a good key exchange
| mechanism prior to Snowdens disclosures. good luck with
| that.
|
| Before or after Snowden, Diffie-Hellman (it's Martin
| _Hellman_ with an "e") _is_ a good key exchange
| mechanism! When using it on Z /pZ as field it's not the
| most practical one nowadays because you need big keys to
| get the desired security level (exactly the same problem
| as RSA), but you if you use an elliptic curves instead
| you can use shorter keys again (and this is exactly what
| ECDH is doing: it litterally means Elliptic Curve Diffie
| Hellman! Diffie-Hellman went nowhere).
| DarkmSparks wrote:
| ->Before or after Snowden, Diffie-Hellman (it's Martin
| Hellman with an "e") is a good key exchange mechanism!
|
| Meanwhile, ~10 years ago https://weakdh.org/imperfect-
| forward-secrecy-ccs15.pdf
|
| After a week-long precomputation for a specified 512-bit
| group, we can compute arbitrary discrete logs in that
| group
|
| in about a minute.
|
| We find that 82% of vulnerable servers use a single
| 512-bit group, allowing us to compromise connections to
| 7% of Alexa Top Million HTTPS sites. In response, major
| browsers are being changed to reject short groups. We go
| on to consider Diffie-Hellman with 768- and 1024-bit
| groups. We estimate that even in the 1024-bit case, the
| computations are plausible given nation-state resources.
| littlestymaar wrote:
| 512 was known to be too low for a looong time, why do you
| think it was the export-grade security?
|
| 1024 being at risk against state-level adversaries isn't
| shocking to anyone, but there's a significant gap between
| this and costing $64, and this gap is _much_ bigger than
| 10 years of Moore 's Law (NSA had much more than 32*$64
| of available compute ;).
|
| You're making grandiose claims and there's nothing that
| holds in your reasoning, it really feels like I'm
| discussing physics with a flat-earther...
| bmacho wrote:
| > (you can't just square amounts of money, just consider
| how it would work if you changed currency: $8 is 1260Y=,
| squares it makes it 1587000Y= which is $10k != $64)
|
| What can you square then? For example, can you square
| lengths? E.g. 1km is 1000m, what is its square?
| littlestymaar wrote:
| 1km2 aka 1,000,000m2, note how the resulting units aren't
| km and m but square kilometers and square meters.
|
| > What can you square then?
|
| In that case it's the number of operations (which is
| unitless) that must be squared and then multiplied by the
| cost of each operation. For instance (figures are
| completely made up for illustration purpose) if one
| individual operation costs 0.1 cent, and you have 8000
| ops for the factorization, it costs $8, and the operation
| number squared means you have 64,000,000 operations, and
| the total cost is $64k. In practice we're talking about
| trillions of very cheap operations but when you square
| that number you get an insanely big number which even
| multiplied by a small individual cost ends up costing
| trillions of dollars, putting it out of reach of
| factorization from anyone.
| DarkmSparks wrote:
| the search space is p1xp2 = cost therefore
|
| (p1^2) x (p2^2) = (p1xp2)^2 =cost^2
|
| and gnfs search cost increases in cost by (roughly) the
| square of the number of bits.
| littlestymaar wrote:
| I'll keep trying to explain it to you: you _cannot_ take
| the square of a price.
|
| If my Yuan exchange rate example didn't convince you,
| let's have a few thoughts experiments:
|
| - let say you can do can do some amount of work for less
| than $1 (maybe even factoring a 512 bits number) let's
| call that amount of work X, and you do it for say $0.9.
| Do you think you can do X2 work for price^2, which is
| $0.81 ? Yes, much more work for less than the price of
| doing X, isn't that magical?
|
| - a hard drive with 1TB of storage costs $40. Do you
| think you can have 1 Yottabyte (10^12 squared is 10^24)
| of storage for just $1600?
|
| There's a reason to all these paradoxes, it simply makes
| no sense to take the square of a sum of money, because
| you can't pay it in square dollars.
| cryptizard wrote:
| That is because "square length" is its own unit, which we
| call area. Square money is not meaningful as a unit, that
| is the problem. You can square anything you want but it
| turns it into a different unit, which the original
| commenter did not do (they presumed squaring dollars
| still gives you dollars back).
| SahAssar wrote:
| > 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.
|
| So you seriously think that almost all current RSA is being
| decrypted in real time by at least UK, China and Russia
| (and I would assume US)? Do you have any source or
| reference for this at all?
| 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.
| Dylan16807 wrote:
| > A RSA key is the product of two primes, not any number,
| so you need a lot more bits to get equivalent security
|
| This explanation doesn't seem right to me. For 1024 bit
| numbers, about 0.14% are prime. So that difference only
| loses a handful of bits. There are more than 2^2000
| usable RSA-2048 keys, and simply guessing and dividing
| would require more than 2^1000 guesses. Those few bits
| lost to the prime number restriction aren't why the level
| of security is so low.
| 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.
| teddyh wrote:
| > _DNS clients combine the 255-byte strings back into a
| single string._
|
| No, _DKIM_ clients and _SPF_ clients do that. Generic
| _DNS_ clients, however, are in theory free to ascribe any
| semantic meaning they like to the string separations.
| 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.
| lo0dot0 wrote:
| If you use the same password on different sites despite
| password managers and now passkeys you are asking for it.
| 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.
| bluGill wrote:
| I have no idea what NIST means when they give 5 years for
| 2048 bit keys, but in generally I trust them more than
| some random poster on the internet.
| littlestymaar wrote:
| Maybe check who you're responding to then ;).
|
| He's not djb but definitely not a "random poster" either.
| coppsilgold wrote:
| RSA2048 is 112-bit-equivalent symmetric security under
| currently known methods. Number theory advances may
| change that. It is hard to imagine any significant
| advances in the breaking of symmetric cryptography
| (mathematically-unstructured permutations).
|
| Cryptographically-relevant quantum computers (CRQC's)
| will also break smaller RSA keys long before (years?) the
| bigger ones. CRQC's can theoretically halve symmetric
| cryptography keys for brute force complexity (256-bit key
| becomes 128-bit for a CRQC cracker).
| 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...
| Avamander wrote:
| Oh, great to know. That gives me hope that we'll see
| Ed25519 certificates at some point then.
| brohee wrote:
| THE CABForum just updated its guidelines (in December)
| and elliptic curve wise only NIST P-256, NIST P-384 and
| NIST P-521 are accepted. (See
| https://cabforum.org/working-groups/server/baseline-
| requirements/requirements/#615-key-sizes)
|
| So on the general web it seems remote at best.
| throw0101c wrote:
| > _THE CABForum just updated its guidelines (in December)
| and elliptic curve wise only NIST P-256, NIST P-384 and
| NIST P-521 are accepted._
|
| NIST P-curve certs were acceptable per the Base
| Requirements all the way back in 2012
|
| * https://cabforum.org/uploads/Baseline_Requirements_V1_1
| .pdf
|
| See "Appendix A - Cryptographic Algorithm and Key
| Requirements (Normative)", (3) Subscriber Certificates.
| 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.
| Avamander wrote:
| > 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.
|
| Except that now the recommendation by NIST at least is to
| switch to 2048-bit by 2030 and then deprecate RSA altogether
| by 2035.
|
| But yeah, not being on at least 1024-bit RSA is weird and
| careless.
| 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
| nmadden wrote:
| That's true for AES-256. But brute force attacks are not the
| most efficient way to attack RSA, so it's not true in that
| case. (Eg quantum computers would break RSA-4096 but not
| AES-256).
| ironhaven wrote:
| Grover's algorithm could be described as quantum brute
| force that is able to break AES-128 but not AES-256
| nmadden wrote:
| Yes (although practically speaking it's very unlikely
| that Grover will ever break AES-128), but that's still a
| brute force attack and still subject to the physical
| limits mentioned in the Schneier quote. Whereas attacks
| on RSA like the number field sieve or Shor's algorithm
| are much more efficient than brute force. (Which is why
| you need such big keys for RSA in the first place).
| 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.
| dspillett wrote:
| _> but it can be tricky to configure properly on a name
| server._
|
| I wouldn't say it is tricky with a good name server: for
| instance with bind just split the value into multiple
| quoted strings and it'll do the rest1.
|
| Though while it is well known, it doesn't seem to be
| _well documented_ away from many forum posts discussing
| the matter: after a little searching I can 't find
| reference to the issue in bind documentation or relevant
| RFCs. The RR format allows RDATA to be longer than 255
| octets (RDLENGTH is an unsigned 16-bit value, not 8-bit)
| so presumably the limit is imposed by the zonefile
| format. The only reference to 255 octet limits in RFCs
| 1034 & 1035 is the length of a full name (with individual
| labels making up a name being limited to 63 octets).
|
| Of course many UIs for editing zone files or other stored
| RR information, or other DNS management interfaces, might
| implement longer RDATA support in a worse way or not
| support longer RDATA values at all.
|
| ----
|
| [1] I'm not sure what "the rest" is (I might look deeper
| later)
| kbolino wrote:
| You're only halfway there. Also from RFC 1035:
| TXT-DATA One or more <character-string>s.
|
| Looking up what a character-string is:
| .... <character-string> is a single length octet
| followed by that number of characters. <character-
| string> is treated as binary information, and can
| be up to 256 characters in length (including the
| length octet).
|
| So the 255-byte limit for each string within the TXT
| record is a core part of DNS. But so is having more than
| one such string in the record data (which I thought was a
| later extension). I have no idea why this strange format
| was chosen when, as you noted already, the RDATA is
| already sized by the RDLENGTH, which is 16 bits. However,
| it is not a mere artifact of the zonefile format; indeed
| the format follows from the spec.
|
| I'm not sure that _all_ clients and servers out there
| handle more than one string in the record properly,
| though in my experience, _most_ do. Still, having to
| split the values, and being able to split them before
| exactly 255 bytes, makes it trickier than it needed to be
| to administer and validate such configurations manually.
| 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.
| raverbashing wrote:
| > 86 hours
|
| I stand corrected
| 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/
| danesparza wrote:
| The same is true for breaking into a building. An
| expensive lock won't protect you against a determined
| attacker.
| 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.
| singpolyma3 wrote:
| I'd say it refutes the counter-example. The court doesn't
| care about DKIM, they care about witness testimony.
|
| DKIM might have convinced the witness sometimes though.
| speerer wrote:
| Courts typically do not care as much about what an expert
| witness thinks, as rather why they think it - and whether
| their reasons hold up enough that the conclusions they
| support should be accepted.
| inopinatus wrote:
| The stacking of either term is unnecessary, because all
| counter-examples are also examples, thus:
|
| * an example supporting the counter-example is simply
| another counter-example, and
|
| * an example contradicting the counter-example is, by
| definition, also another counter-example.
|
| Corollary: all examples that can be opposed or
| contradicted by counter-examples are themselves also
| counter-examples.
| 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.
| Groxx wrote:
| Yea, stuff with kids involved sometimes makes it SUPER
| unambiguous. Some people are very clearly willing to do
| anything to anyone, and are doing so as much as possible.
| 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 :)
| jillyboel wrote:
| You'd be lying to the court either way if you did send it
| and meant to conceal it.
| 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 =)
| linsomniac wrote:
| There is a better than even chance that you are correct.
| :-)
| 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
| Groxx wrote:
| /me skims, reaches footnotes
|
| Sometimes you've just gotta love those auto-shortened
| URLs: security.googleblog.com/2013/12/internet-wide-
| efforts-to-fight-email.html
|
| Hopefully one day we'll win the fight.
| 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.
| GTP wrote:
| Sorry, I'm missing what you're trying to say here, maybe
| that a politician would be more careful about which
| message system he's using? I don't think that's
| necessarily the case.
|
| Anyway, to further add to my point, depending on the
| context you don't even need to claim that someone stole
| your password. In the company where I am now , it is
| custom that, if someone finds out someone else didn't
| lock their computer, that someone sends an email (from
| the victim's account) to the whole office saying that the
| victim is going to bring cake to the office. DKIM is
| meant to prove that a message comes from an authorized
| server, but to prove the identity of the sender as well
| you need something more.
|
| Edit: to be fair, I do get that with DKIM deniability
| gets harder. But I think that, for the average person,
| you would gain more in terms of spam and phising
| protection than what you loose. High profile targets have
| to take different security measures than the masses
| anyway.
| tptacek wrote:
| What I'm saying is that the "crooked politician" use case
| you're talking about for DKIM is a way in which you're
| pleased that a messaging system is _insecure_ , because
| that insecurity works in your favor (because you're not
| the user; you just want to violate that user's privacy).
| But no rational user would want that property for
| themself; they can only lose from it.
| GTP wrote:
| Thank you, I get it now. The reason why I focused on that
| specific example, is because it is used in the blog post
| as proof that DKIM is being actively used to prove that
| someone actually sent an email.
| 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.
| rstuart4133 wrote:
| Yes, it's a pretty good way of proving the server sent
| the email. That's all it proves. If the email came from
| gmail.com, it's up to Google to prove the person in the
| From: address composed the email. The signature can't
| prove that. Nonetheless almost everyone will accept that
| is what happened.
|
| If Gmail received the email, it's likely they simply drop
| email with no or bad DKIM signatures. So if it's in your
| gmail inbox but a has signature that doesn't check out,
| to be categorically certain it was signed you would have
| to ask Google. But it's the same deal as the From:
| address - almost everyone is going to assume it was
| validly signed because that's gmail's policy.
|
| TL/DR, I think your wrong. Rotating the key only weakens
| the proof slightly. The only thing that is destroyed is
| the cryptographic proof, but only in a fanatical
| cryptographers world is that the only form of acceptable
| proof. That fanatical cryptographer is wrong of course.
| Things outside of the mathematical certainty also matter.
| The rubber hose joke _is_ funny, and the butt of that
| joke is fanatical cryptographers making that very
| assumption.
| tptacek wrote:
| I really don't follow what you're trying to say here. The
| point is that the durable verifiable signature has no
| value to users, but lots of value to attackers; in other
| words: it only has value to attackers. People are
| confused because in a formal analysis, journalists
| getting stories from leaked mail spools are attackers;
| they are a thing secure messengers are designed to
| thwart.
| 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.
| singleshot_ wrote:
| I get the verification the email actually came from the
| domain (i.e., someone, who has the credentials of an
| insider) vs. an email that was totally spoofed, from the
| outside, without any creds of the purported sender org.
| (Right?)
|
| Hands on keyboard? You're right, absolutely not. But I
| can learn something useful via DKIM nevertheless.
| 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 undesirable 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!
| tsimionescu wrote:
| An email exchange has two users: one is the sender, the
| other the receiver. As the receiver, having proof that I
| received an email from you is potentially a feature, not
| a problem.
|
| More generally, authenticated communication has a long
| history of being considered a useful thing for society.
| Physical mail includes delivery confirmations where the
| receiver must sign for the receipt, proving to anyone
| that they did receive the letter. People would often add
| hard-to-forge personal seals to letters in even older
| days, that could prove to anyone that they were the ones
| who sent that document. And even common letters were
| usually signed rather, even when typewritten, again
| making it hard to later repudiate.
|
| While I absolutely see the value in making it possible to
| securely send repudiatable email in some specific
| circumstances, I think having non-repudiatable email as
| the default is a net benefit to society, and has been the
| de facto standard for at least a few hundred years before
| email ever came along.
| tptacek wrote:
| This is the classic argument in favor of verifiable DKIM
| signatures: because it benefits the consumers of hacked
| mail spools. Consider that as a security engineering
| decision, enabling that use case is a _bad thing_.
| sharpshadow wrote:
| It would then make sense to encrypt the email content.
|
| Repudiation of clear text messages looks like the easier
| implementation.
| Avamander wrote:
| That creates other problems. Content analysis is a large
| part of anti-spam. Which is a much more important problem
| than (non-)repudiation and all that.
| 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.)
| jcgl wrote:
| > I bet 99.99% of all email is delivered within a minute
| or so of being send
|
| No doubt that is true. However, given the total volume of
| email, even that tiny, tiny remaining fraction still
| represents actual mail with legitimate use-cases. So it's
| good to bear that fact in mind and not roughly implement
| 80-20 stuff that tramples on those.
| 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.
| phkahler wrote:
| Sounds nefarious. Why would a sender want the recipient
| to verify authenticity while being able to deny it to a
| 3rd party. Sending threats or blackmail come to mind as
| top uses. Breaking confidentiality agreements is another.
| What's a legit honest above board use?
| 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 :( ).
| password4321 wrote:
| For 20 years Fastmail allowed any customer to spoof From:
| another
|
| https://news.ycombinator.com/item?id=42536750#42539217
| 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.
| lazide wrote:
| Users in those countries already vastly outnumber users
| in other countries. And are growing much, much faster
| too.
| alt227 wrote:
| Yep, but it will never replace email address as universal
| identifier until it is adopted by all.
|
| In addition to that, reports show that the majority of
| Asian and African users access the internet via a shared
| device. Therefore phone number cannot be a universal
| identifier there as it generally identifies a group of
| people rather than in indivdual. This is why google and
| outlook accounts with SSO are still generally the most
| used identifying systems in the world.
| lazide wrote:
| By what metric?
|
| In India, it is exceptionally rare for any services
| (gov't and commercial) to use email address. They use
| mobile.
|
| One of many examples [https://web.umang.gov.in/landing/de
| partment/aadhaar.html]
|
| That accounts for 1.3+ billion distinct accounts in 2023
| right there.
|
| [https://uidai.gov.in/en/about-uidai/unique-
| identification-au...]
|
| Do you think those folks in Asia and Africa sharing
| mobile devices have email accounts they can use instead?
| 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.
| tga_d wrote:
| What if the private key were accidentally exposed via
| public API, behind ROT13?
|
| Also, I don't think DKIM is used for encryption, just
| signatures.
| alt227 wrote:
| > I would be very very careful.
|
| I see it the other way around. If some hacker contacted
| me and proved they had cracked my businesses encryption
| keys and was looking for a reward, I dont think I would
| be looking to prosecute them and antagonise them further.
| jeroenhd wrote:
| What is or isn't illegal depends on where you live. Where
| I live, using any kind of digital secret to do something
| you shouldn't be doing is technically illegal. Guessing
| admin/admin or guest/guest is illegal, even if they're
| public knowledge, as long as you could reasonably know
| you're not supposed to log in.
|
| Generally, law enforcement and judges don't blame you as
| long as you use best practices, but you need to adhere to
| responsible disclosure very strictly in order for this
| not to be something the police might take an interest in.
|
| Demonstrating the insecurity of a 512 bit key is easy to
| do without cracking a real life key someone else owns;
| just generate your own to show it can be done, then use
| that as proof when reporting these issues to other
| companies. The best legal method may be to only start
| cracking real keys if they ignore you or deny the
| vulnerability, or simply report on the fact you can do it
| and that the company/companies you've reached out to deny
| the security risk.
|
| Companies that pay for disclosure won't get you into
| trouble either way, but companies that are run by
| incompetent people will panic and turn to law enforcement
| quickly. White-hat hackers get sued and arrested all the
| time. You may be able to prove you're right in the court
| room, but at that point you've already spent a ton of
| money on lawyers and court fees.
|
| In this case, the risk is increased by not only cracking
| the key (which can be argued is enough proof already,
| just send them their own private key as proof), but also
| using it to impersonate them to several mail providers to
| check which ones accept the cracked key. That last step
| could've easily been done by using one's own domains, and
| with impersonation being a last resort to prove an issue
| is valid if the company you're reporting the issue to
| denies the risk.
| alt227 wrote:
| > Demonstrating the insecurity of a 512 bit key is easy
| to do without cracking a real life key someone else owns;
| just generate your own to show it can be done
|
| As I said in my post, no company will listen to your
| hypothetical exploit. Show them youve hacked their system
| and they listen.
| 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).
| Tutanota wrote:
| Actually, we did not get notified, but we did see this
| message - so thanks! We have now fixed the issue and the fix
| will go live in the next days.
|
| Matthias, co-founder of Tuta Mail
| tptacek wrote:
| I don't think there's a way to make it criminal, any more than
| publishing a vulnerability that got you code execution on their
| servers could be. Actually exploiting it, of course, would be.
| colmmacc wrote:
| I think many in cryptography would see cracking a key as a
| precondition to "actually exploiting it" ... because you've
| only gotten a cryptographic secret, not "actual data".
|
| But I think many others, and many in law enforcement, will
| see cracking a key as "actually exploiting it". You've
| exploited the cracking vulnerability to target a particular
| key, is how they'll see it. Law enforcement also have a
| natural incentive to want possession of harm-adjacent
| paraphernalia to carry substantial liability.
|
| I think they have a point; that key _is_ private data, and
| there 's a reason people lock keys up in KMSs and HSMs; they
| can have a large blast radius, and be hard for companies to
| revoke and rotate. Importantly, a compromise of a key will
| often trigger notification requirements and so now it is a
| breach or an incident, in a way that a good faith security
| vulnerability report is not.
|
| To make an extreme example; if you were to crack an important
| key for a government agency, good luck with that is all I'll
| say. I sure wouldn't.
| tptacek wrote:
| The US law most at play in criminal prosecution of computer
| usage is CFAA, and a clear CFAA predicate is intentional
| access to a protected _computer_ (18 USC 1030(a)(2)). This
| distinction is what makes vulnerability research on things
| like Chrome vulnerabilities generally safe (as long as you
| don 't knowingly spirit exploits to people who are actually
| attacking people), while vulnerability research on other
| people's websites (looking for SQLI and SSRF) is risky.
|
| The CFAA has a clause about "trafficing in passwords or
| similar information" (18 USC 1030(a)(6)), but the mental
| state requirements are very high: that trafficking has to
| be knowing and with intent to defraud (that intent will be
| something prosecutors will have to prove at trial).
|
| There might be some state law somewhere that makes this
| risky, but virtually every hacking prosecution in the US
| anyone has heard of happens under CFAA. I'm not a lawyer,
| but I've spent a lot of time with CFAA, and I think
| cracking DKIM keys is pretty safe.
| 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 ? :)
| SahAssar wrote:
| > not sure I would trust 8192 bit RSA in 2024
|
| Do you have any proof/quote for that? Some pretty knowledgeable
| and well-known people in this thread 2048 bit RSA is quite safe
| with current capabilities[1]
|
| 1: https://news.ycombinator.com/item?id=42635066
| DarkmSparks wrote:
| https://www.bbc.com/news/world-us-canada-23981291
| 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.
| ClassyJacket wrote:
| Altering headlines automatically is really irresponsible.
| croemer wrote:
| Is there any documentation on this? @dang?
| dang wrote:
| It is if you only count the cases it gets wrong.
| croemer wrote:
| Couldn't find it in the guidelines. Can you quote the
| relevant part?
| dang wrote:
| "How we X'd a Y" is a linkbait trope. We edited that in
| accordance with the site guidelines: " _Please use the original
| title, unless it is misleading or linkbait_ ".
| https://news.ycombinator.com/newsguidelines.html
| croemer wrote:
| Thanks for clarifying. Interestingly, in the guidelines,
| there's an example of where you _add_ "How" instead of
| removing it: "E.g. translate '10 Ways To Do X' to 'How To Do
| X'". That tripped me.
| dang wrote:
| We don't remove "how" from "how to". There are a bunch of
| exceptions like that. It's all pretty simplistic though.
| 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.
| jabroni_salad wrote:
| "existing" is basically all it does. They make 8B a year and
| have the 12th most popular website globally.
|
| The email product has gobbled up both AOL and Verizon and
| they also whitelabel to a bunch of other ISPs. Just because
| they are never in the news for anything cool and hackernews
| commenters dont use them doesnt mean they dont exist.
| SahAssar wrote:
| Yahoo mail still has plenty of users and yahoo still have
| many employees. It'd be borderline criminal to not have
| somebody at yahoo oversee their email security.
| 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.
| dusted wrote:
| Addendum: You need to set a strict dmarc policy for the checks
| to fail. Interestingly, the sites will tell you all three are
| correct and valid, but still fail the mail.. This is probably
| due to different pieces of software doing the dns record
| checking and the email validation.
| 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.
| supernova87a wrote:
| This is a little bit of a layman's question but maybe someone is
| interested:
|
| When people go searching for prime numbers / bitcoin with massive
| compute, I assume that there are huge libraries of "shortcuts" to
| reduce the searching space, like prime numbers only appear with
| certain patterns, or there are large "holes" in the number space
| that do not need to be searched, etc. (see videos e.g. about how
| prime numbers make spirals on the polar coord. system, etc). I.e.
| if you know these you can accelerate/reduce your search cost by
| orders of magnitude.
|
| For whatever various encryption algorithm that people choose to
| test or attack (like this story), is there somewhere such
| libraries of "shortcuts" are kept and well known? To reduce the
| brute force search need?
|
| And is the state of sharing these to the point that the
| encryption services are designed to avoid the shortcut
| vulnerabilities?
|
| Was always wondering this.
| tomesco wrote:
| There exist certain classes of prime numbers that should not be
| used for some cryptographic operations because algorithms exist
| that reduce the computation required for factoring attacks.
| This more often applies to cases where smaller primes are
| applied. Sources for this king of knowledge are mathematics or
| cryptography textbooks.
|
| For other cryptographic operations, almost any sufficiently
| large prime can be used. Even a 50% reduction on a computation
| that will take trillions of years, has no practical impact.
| cryptizard wrote:
| That's not really how it works. There aren't any noticeable
| patterns in prime numbers (besides trivial ones like they are
| all odd numbers) and they remain dense (no big gaps) even for
| very large numbers like what are used in RSA. The best
| algorithm for generating prime numbers is to just pick a really
| big random odd number and then test if it is prime, repeat
| until you find one.
|
| Now, factoring large numbers is a separate thing. You don't
| brute force all the possible factors, that would be a really
| bad approach. Modern algorithms are called "sieves," this is a
| gross oversimplification but essentially they keep picking
| random numbers and computing relations between them until they
| come up with enough that have a certain property that you can
| combine them together to find one of the factors. It doesn't
| have anything to do with shortcuts or patterns or tricks, it is
| just a fundamental number theory algorithm.
| loeg wrote:
| Reminds me of factoring 512-bit RSA signing keys used on Ti
| calculators in 2009:
| https://en.wikipedia.org/wiki/Texas_Instruments_signing_key_...
| fernvenue wrote:
| Don't know how Apple's iCloud Email will handle it, after all,
| Apple has always prided itself on being extremely attentive to
| user privacy and data security.
| jgalt212 wrote:
| While the DKIM passes, the SPF fails (per the Yahoo screenshot),
| so if I have this right a bad actor would still need to hack the
| legitimate senders DNS records (assuming DMARC rules are set up
| somewhat strictly). Do I have this right?
|
| Of course, if you can modify the SPF records, you can make the
| DMARC record say whatever you want.
| lakomen wrote:
| What a misleading title
___________________________________________________________________
(page generated 2025-01-09 23:00 UTC)