[Interest] TLS/SSL XML encryption security

[Thiago Macieira]

On Monday, 7 October 2019 15:43:21 PDT Roland Hughes wrote:
> No. This technique is cracking without cracking. You are looking for a
> fingerprint. That fingerprint is the opening string for an xml document
> which must be there per the standard. For JSON it is the quote and colon
> stuff mentioned earlier. You take however many bytes from the logged
> packet as the key size the current thread is processing and perform a
> keyed hit against the database. If found, great! If not, shuffle down
> one byte and try again. Repeat until you've exceeded the attempt count
> you are willing to make or found a match. When you find a match you try
> key or key+salt combination on the entire thing. Pass the output to
> something which checks for seemingly valid XML/JSON then either declare
> victory or defeat.

That DOES work with keys produced by OpenSSL that was affected by the Debian 
bug you described. That's because the bug caused the problem space to be 
extremely restricted. You said 32768 (2^15) possibilities.

A non-broken random generator will produce 2^128 possibilities in 128 bits. 
You CANNOT compare fast enough

> These attacks aren't designed for 100% capture/penetration. The workers
> are continually adding new rows to the database table(s). The sniffed
> packets which were not successfully decrypted can basically be stored
> until you decrypt them or your drives fail or that you decide any
> packets more than N-weeks old will be purged.

You seem to be arguing for brute-force attacks until one gets lucky. That is 
possible. But the chances of being lucky in finding a key are probably worse 
than winning $1 billion in the lottery. Much worse.

So it can happen. But the chance that it does happen and that the captured 
packet contains critical information is infinitesimal.

> The success rate of such an attack improves over time because the
> database gets larger by the hour. Rate of growth depends on how many
> machines are feeding it. Really insidious outfits would sniff a little
> from a bunch of CC or mortgage or whatever processing services,
> spreading out the damage so standard track back techniques wouldn't
> work. The only thing the victims would have in common is that they used
> a credit card or applied for a mortgage but they aren't all from the
> same place.

Sure, it improves, but probably slowly. This procedure is limited by computing 
power, storage and the operating costs. Breaking encryption by brute-force 
like you're suggesting is unlikely to produce a profit: it'll cost more than 
the gain once cracked.

Crackers don't attack the strongest part of the TLS model, which is the 
encryption. They attack the people and the side-channels.

> If correct that means they (the nefarious people) could have started
> their botnets, or just local machines, building such a database by some
> time in 2011 if they were interested. That's 8+ years. They don't _need_
> 100% coverage.

No, they don't need 100% coverage. But they need coverage such that the 
probability of matching is sufficient that it'll pay the operating costs. In 8 
years, assuming 1 billion combinations generated every second, we're talking 
about 242 quadrillion combinations generated. Assuming 64 bits per entry and 
no overhead, that's 2exabytes to store. Current cost of Amazon S3 Infrequent 
Access storage is 1¢/GB, so it would cost $20M per month.

And that amounts to 1.3% of the problem space. Which is why we don't use 64-
bit keys.

If we talk about 128-bit keys, it's $40M per month for a coverage rate of 7.5 
* 10^(-22). You'll reach 1 part per billion coverage in 10 trillion years, 
assuming constant processing power.

Calculating assuming an infinite Moore's Law is left as an exercise for the 
reader.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products