Yes, I also know about the lizardmen from Phobos who can crack SSL/TLS
keys instantly.
If you can show some code all this would be much more credible. After
all, this is a Qt mailing list, not a science fiction one.
Rgrds Henry
On 2019-10-07 16:06, Roland Hughes wrote:
On 10/7/19 5:00 AM, Thiago Macieira wrote:
You do realise that's not how modern encryption works, right? You do
realise
that SSL/TLS rekeys periodically to avoid even a compromised key from
going
further? That's what the "data limit for all ciphersuits" means:
rekey after a
while.
yeah.
You're apparently willfully ignoring the fact that the same cleartext
will not
result in the same ciphertext when repeated in the transmission, even
between
two rekey events.
No. We are working from two completely different premises. It appears
to me your premise is they have to be able to decrypt 100% of the
packets 100% of the time. That's not the premise here.
The premise here is they don't need it all to work today. They just
need to know that a Merchant account service receives XML/JSON and
responds in kind. The transaction is the same for a phone app, Web
site, even when you are standing at that mom & pop retailer physically
using your card. They (whoever they are) sniff packets to/from the IP
addresses of the service logging them to disk drives.
The dispatch service hands 100-1000 key combinations out at a time to
worker computers generating fingerprints for the database. These
computers could be a botnet, leased from a hosting service or machines
they own. The receiver service stores the key results in the database.
A credit card processing service of sufficient size will go through a
massive number of salts and keys, especially with the approaching
Holiday shopping season. 1280 bytes "should" be more than enough to
contain a credit card authorization request so this scenario is only
interested in fast cracking a single packet. Yes, the CC number and
some other information may well have additional obfuscation but that
will also be a mechanical process.
Periodically a batch job wakes up and runs the sniffed packets against
the database looking for matching fingerprints. When it fast cracks
one it moves it to a different drive/raid array, storage area for the
next step. This process goes in steps until they have full CC
information with a transaction approval, weeding out the declined cards.
When the sniffed packet storage falls below some threshold the sniffer
portion is reactivated to retrieve more packets.
This entire time workers are adding more and more entries to the
fingerprint database.
These people don't need them all. They are patient. This process is
automated. They might even configure it to send an email when another
100 or 1000 valid CCs so they can either sell them on the Dark Web or
send them through the "buying agent" network.
Yeah, "buying agent" network might need a bit of explanation. Some of
you may have seen those "work from home" scams where they want a
"shipping consolidation" person to receive items and repackage them
into bulk packs for overseas (or wherever) shipping. They want a fall
person to receive the higher end merchandise which they then bulk ship
to someone who will sell it on eBay/Amazon/etc.
The CC companies constantly scan for "unusual activity" and call you
when your card has been compromised. This works when the individuals
are working with limited information. They have the CC information,
but they don't have the "where you shop" information. The ones which
have the information about where you routinely use the card can have a
better informed "buying agent" network and slow bleed the card without
tripping the fraud alert systems. If you routinely use said card at
say, Walmart, 2-3 times per week for purchases of $100-$500 they can
make one more purchase per week in that price range until you are
maxed out or start matching up charges with receipts.
The people I get asked to think about are playing a long game. They
aren't looking to send a crew to Chicago to take out $100 cash
advances on a million cards bought on the Dark Web or do something
like this crew did:
https://www.mcall.com/news/watchdog/mc-counterfeit-credit-cards-identity-theft-watchdog-20160625-column.html
Or the guy who just got 8 years for running such a ring in Las Vegas.
That's the most recent one turning up in a quick search.
Maybe they are looking to do just that, but are looking for more
information?
At any rate, the "no-breach" scenario is being seriously looked at.
Yes, the Salt will change with every packet and the key might well
change with every packet but these players are only looking to crack a
subset of packets. Most organizations won't have the infrastructure to
utilize a billion compromised credit cards. They can handle a few
hundred to a few thousand per month.
In short, they don't need _everything_. They just need enough to get
that much
And don't forget the Initialisation Vector. Even if you could compute
the
fingerprint database, you still need to multiply it by 2^128 to
account for
all possible IVs.
Perhaps. A few of those won't be used, such as low-values and
high-values. That also assumes none of the desalination chatter pans
out. Maybe it does and maybe it doesn't. One thing is certain. We now
have the storage and computing power available to create the database
or 2^128 database tables if needed.
The people I get asked to think about are playing a very long game. If
they are using a botnet the machines to generate the database content
cost them nothing. They are only on the hook for a bit of coding and
what is becoming cheaper by the month storage.
https://venturebeat.com/2014/07/13/hackers-only-need-to-get-it-right-once-we-need-to-get-it-right-every-time/
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
