On 10/8/19 5:00 AM, Thiago Macieira wrote:
On Monday, 7 October 2019 18:08:27 PDT Roland Hughes wrote:
There was a time when a Gig of storage would occupy multiple floors of
the Sears Tower and the paper weight was unreal.
Have you ever heard of Claude Shannon?
Nope.
Anyway, you can't get more data into storage than there are possible states of
matter. As far as our*physics* knows, you could maybe store a byte per
electron. That would weigh 5 billion tons to store 16 * 2^128 bytes.
The same physics, when incorrectly applied "prove" bumblebees cannot fly?
https://www.snopes.com/fact-check/bumblebees-cant-fly/
What I really loved was the science text my generation had in 4th grade
which taught kids meat naturally contained maggots. Scientists had
"proven" if you just left meat out maggots would magically grow from it.
https://www.google.com/search?client=ubuntu&hs=2Tv&channel=fs&ei=CbicXZO3GJCo_QaUrJCoBQ&q=spontaneous+meat+naturally+contained+maggots&oq=spontaneous+meat+naturally+contained+maggots&gs_l=psy-ab.3...15501.20615..21681...1.2..0.164.1803.0j13......0....1..gws-wiz.......0i71.mkiA8iHPvYk&ved=0ahUKEwjT37W5iY3lAhUQVN8KHRQWBFUQ4dUDCAo&uact=5
>
How about you do some math before spouting nonsense?
Considering and attempting to prove nonsense is what is required when
you are at the architect level. At the Chicago Stock Exchange when they
were running PDP machines they wanted to use 2 machines to run the
trading floor having process shared memory between them. Digital
Equipment Corporation, makers of the PDP and its operating system told
them it was nonsense, couldn't be done. They did it. Ported it to the
VAX (completely different hardware and OS), the Alpha ("same" OS,
different hardware) and the Godforsaken Itanium.
At Navistar (though it wasn't named Navistar then) they wanted the IBM
order receiving system to directly send orders to the VMS based order
processing/inventory management/picking ticket system. Both DEC and IBM
told them it was complete nonsense, couldn't be done. We did it. Long
before RJE was talked about.
At any rate, enough rows in the DB to achieve a 1% penetration rate
gives them 10,000 compromised credit cards via an automated process. A
tenth of a percent is 1,000. Not a bad haul.
Sure. How many entries in the DB do you need to generate a 0.1% hit rate?
I don't know how to calculate that, so I'm going to guess that you need one
trillionth of the total space for that.
Depends on what you find when testing and probing. Some were richly
rewarded with the Debian bug limiting keys to a range of 32768. If the
current OpenSSL library isn't blocking keys below 32769, the database
and tools created to exploit that weakness still work for any key in
that range.
If there is a ToD sensitivity in the random generator, shouldn't be, but
on this Debian system looks like there might be, then one can
dramatically reduce the DB size needed and reduce the target range to
all traffic within a window.
I don't doubt that there are hackers that have dedicated DCs to cracking
credit card processor traffic they may have managed to intercept. But they are
not doing that by attacking the encryption.
Some are and some aren't. The fact so many deny the possibility is the
reason.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
