[Interest] TLS/SSL XML encryption security
roland at logikalsolutions.com
Thu Oct 17 15:56:41 CEST 2019
On 10/9/19 5:00 AM, Thiago Macieira wrote:
> On Tuesday, 8 October 2019 09:26:19 PDT Roland Hughes wrote:
>>> A non-broken random generator will produce 2^128 possibilities in 128
>>> bits. You CANNOT compare fast enough
>> Does not matter because has nothing to do with how this works. Not the
>> best, not the worst, just a set it and forget it automated kind of
>> thing. It's taking roughly 8 bytes out of the packet and doing a keyed
>> hit on the database. If found great! If not, it slides the window down
>> one byte and performs a new 8 byte keyed hit.
> First of all, you don't understand how modern cryptography works. AES, for
> example, is usually encrypted in blocks of 16 bytes. You can't slide down one
> byte. You can only slide down by block granularity.
I understand plenty Thiago. While I may not barn dance anymore, this is
a looooong way from my first rodeo. This isn't a lark either. It came
through proper channels. I will work on it. The last request of this
type coming through those channels turned out to be the IP Ghoster
project where Bill Gates' next door neighbor happily paid $250/hr for as
many hours as I could give him June through October of 2012. Bill Gates
told them the part I was working on couldn't be done just like you are
telling me this cannot be done. Guess what? It got done and became the
foundation for multiple products.
On this particular topic I won't respond again. Those who issue such
requests also lurk here and while I can write a couple more blog posts
on it, no further open discussion about what we are exploring. Sounds
like they found something and want me to independently confirm.
> That doesn't mean you can decode it. The chance of a random match is still
It's a long way from infinitesimal.
>> 56TB - ~9lbs
> 4 kg / 56 TB = 71.4 picograms/byte. That's actually pretty good.
I hate Wikipedia. You can never find the same thing twice. Somewhere on
there is a page about all of the current drive storage technologies an
they discuss the 4-bit stacking used by some drive manufacturers for the
mega drives. This drive didn't do that. I was also was looking for the
synthetic molecule with 9 electrons article someone sent me. It was
something which I believe fell out of the synthetic motor oil research.
They could read and write the electrons just fine but were having
difficulty keeping it stuck to a spinning platter.
On your road to becoming an architect you have to learn one thing. Don't
focus on the minutia.
We have hundreds, possibly thousands of Qt consultants and developers
taking low paying contracts in Michigan, California and a few other
states working on "autonomous vehicles." None of these vehicles can be
truly viable until the storage problem is solved. Oh sure, that fleet of
tractor trailers which runs 10 miles down an Interstate from factory to
warehouse is doable. Shouldn't need more than 4TB total storage for
everything it needs to know. You can even forcibly put
antenna/transmitters down the length of it to ensure 100% wireless
coverage so the trucks can remain relatively simple applications themselves.
Uber will keep using AGILE and mowing people down because they refuse to
create the 4 Holy Documents up front, but others are doing the
development correctly. Really smart people have been working on this
storage problem since 2013 or before.
First off, definition of VIABLE:
The vehicle must be able to make 3 round trips within a year the full
length of Route 66.
The first must be during the peak of summer storm/tornado season.
The second must be during deer season.
The third must be during the winter after snow has begun falling in both
Chicago and the mountains.
This presents the perfect challenge. Once "The Mother Road" it is now
difficult to navigate having many turns, stops and 30 MPH stretches.
Most importantly there are huge sections without cellular/wireless
coverage. Some sections satellite coverage doesn't work. The vehicle
will have to retain all of the knowledge it needs for the trip because
updates will be sparse.
The smart people working on such things know this is the test. They have
architected for it. Deer season also provides the perfect randomization.
That's when deer are running scared and most likely to total out a ride.
Really smart people been working on this for a long time. We are less
than 5 (most likely 3) years from having seemingly limitless data storage.
IBM single atom data storage - 2017
If it dampens your enthusiasm somewhat that they’re thinking of looking
into molecules rather than single atoms for more practical setups of
this idea, don’t worry. One experiment from 2016 exceeding a terabit per
square inch used magnetic grains just 5 nanometers in diameter.
A Holmium atom is around 200 picometers across; you could line up 25 of
them end to end on that grain — or you could, if atoms had “ends.” Of
course, it’s much more complicated than that, but the fact is this is
about as small a thing in which you can expect to store anything.
Sticking two of them together doesn’t change much.
Xenon atoms state changes - 2018
This year brought DNA storage into the fold.
Molbits and Molbytes using small organic molecules - 2019
Kilobyte-scale data storage in synthetic metabolic molecules, smaller
than DNA. - 2019
DNA storage Microsoft has been working on - 2019
“Think of compressing all the information on the accessible Internet
into a shoebox,” says Karin Strauss, a principal researcher at
Microsoft. “With DNA data storage, that’s possible.”
The information density of DNA is remarkable — *just one gram can store
215 petabytes*, or 215 million gigabytes, of data. For context, the
average hard drive in a laptop can house just one millionth of that amount.
The Microsoft article about it
It won't be a spinning disk drive and Microsoft (thankfully) isn't the
only one working on DNA storage. Packaging isn't as big of a challenge
as one would think, what they haven't determined is the lifespan of the
data and media.
>>> Have you ever heard of Claude Shannon?
> Maybe you should read up on the Father of Information Theory. Seems kind of
> relevant for your profession.
During my 30+ year career so far in IT, I can't say having knowledge of
Claude Shannon has ever been relevant. In the 20 or so I have left, that
knowledge still won't be relevant. I can give you a list of relevant
Anything published by Ed Yourdon. Most of them you will have to find in
used book stores now.
Any book where Tom DeMarco is listed as one of the authors, especially
"Software Conflict - Essays on the art and Science of Software Engineering"
"The Secrets of Consulting" ISBN 0-932633-01-3
"Wicked Problems, Righteous Solutions" ISBN 0-13-590126-X
"How to Be a Successful Computer Consultant" ISBM 0-07-057554-1
>> 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.
> That's a side-channel attack: exploiting a flaw in the random generator to
> reduce the problem space. That's exactly what I've been arguing: attacks
> aren't done against the strongest part of the system, they are done against
> the flaws.
> If you tell me that there are vulnerabilities known to only a few people in
> the deepest Dark Web, the NSA and maybe one or two more state actors, who can
> exploit that vulnerability and decrypt ciphertext that is affected, I'll
> believe you. I don't doubt there's an operation somewhere running a dedicated
> DC to exploit such flaws.
> But the more people know about the flaw, the greater the risk it'll become
> public knowledge, then get fixed. So no script kiddie is going to be
> decrypting packets any time soon.
Here we will have to professionally disagree. This is what I really hate
about discussing such things outside of my world. It always brings out a
Prior of the Ori.
Neither a ToD sensitivity nor the 32768 cap introduced by the
12-year-old-boy "Heppin out" the developers by getting rid of those
pesky Valgrind messages are a side-channel attack. They are both an
A side-channel attack is someone walking in, seeing your car keys just
laying on the desk and stealing your ride. Putting it in encryption
terms someone gained access to your system and stole your certificate or
the found the batch script you use to encrypt a file before
transmission. In that script they found the password used for encryption
is "Fred" and the date in YYYYMMDD format.
That's a side channel attack. It requires no flaw in the scripture of
the encryption algorithm or its implementation. Someone found your car
keys and used them to steal your ride.
In my world calling encryption implementation flaws side-channel attacks
is much akin to the faith healer at the revival tent claiming the reason
a child wasn't healed is that "their faith wasn't strong enough" or
"parents did not lead their lives strictly according to scripture."
> I repeat: no one is attacking by brute-forcing the strongest part of the
> Want me to repeat again?
Repeat as often as you want. I'm done with this particular topic.
Someone either found something or is worried about +-3 years from now
when 215 petabytes can be stored in a gram is on the market along with
billions of basically insecure IoT devices on the market which spend
most of their day idle.
Been asked to poke so I'm poking.
Roland Hughes, President
More information about the Interest