[Interest] TLS/SSL XML encryption security

[Roland Hughes]

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
> infinitesimal.

It's a long way from infinitesimal.

>
>> 56TB - ~9lbs
>> https://www.bhphotovideo.com/c/product/1466481-REG/owc_other_world_computing
>> _owctb2sre56_0s_56tb_thunderbay_4_raid.html/specs
> 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.

https://www.nytimes.com/2018/03/19/technology/uber-driverless-fatality.html

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.

https://www.historic66.com/

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

https://techcrunch.com/2017/03/08/storing-data-in-a-single-atom-proved-possible-by-ibm-researchers/

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.

https://phys.org/news/2018-12-storage-individual-molecules.html
Xenon atoms state changes - 2018

This year brought DNA storage into the fold.

https://pubs.acs.org/doi/full/10.1021/acscentsci.9b00210
Molbits and Molbytes using small organic molecules - 2019

https://blocksandfiles.com/2019/07/09/molecular-storage-makes-waves/
Kilobyte-scale data storage in synthetic metabolic molecules, smaller 
than DNA. - 2019

https://www.forbes.com/sites/johncumbers/2019/08/03/dna-data-storage-is-about-to-go-viral/#25ef7d6b7721
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.

https://news.microsoft.com/innovation-stories/hello-data-dna-storage/
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?
>> Nope.
> 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 
reading.

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 
"Peopleware"

https://www.barnesandnoble.com/w/peopleware-tom-demarco/1119329330?ean=9780321934116


"Software Conflict - Essays on the art and Science of Software Engineering"

ISBN 0-13-826157

"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 
encryption failure.

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
> encryption.
>
> 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.

https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

https://www.darkreading.com/iot/insecure-home-iot-devices-a-clear-and-present-danger-to-corporate-security/d/d-id/1335002

Been asked to poke so I'm poking.

-- 
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