In some large part this essay is a follow-on to the “You Are the Security Breach” essay. It’s a result of a knock-down drag-out I got into on a technology mailing list. True I have quite a discussion about security in my upcoming “The Minimum You Need to Know About the Phallus of AGILE” book, but this particular discussion needed to be had in a more general context. Each and everyone of you is being put at risk by a combination of greed and stupidity. Yes, I know, in today’s politically correct world we aren’t supposed to use the word stupidity, but it fits. Ignorance is curable, stupidity is not.
Time and time again you will hear the mantra
There are three factors to security:
- authentication
- authorization
- encryption
Well, they are wrong. The fourth and most important factor is “don’t be stupid.” This is also the most often ignored factor because it is 100% fixable but it is not a one and done checkbox. In the previous post I told you about using things like
<ssn>123-45-6789</ssn>
in data transmissions. I also told you a bit about data striping. It’s time I also told you a bit about the dark world claims of tools which can breach TLS/SSL at will. During the knock-down drag-out I took about five minutes to think about how they are doing it, especially since most of the stories out there aren’t about breaching the sites, they are about decrypting a puddle of sniffed packet traffic. As far as I can tell there is absolutely no way to stop someone from parking software on the Internet saving copies of all packets passing through their location. They aren’t tampering, just logging. It should set off no alarms.
The classic argument that “it would take a super computer N years running full tilt to crack that encryption” is generally made by people talking out their ass. With botnets and server farms for lease, you can have the equivalent of 10,000 super computers at your disposal for very little money. According to this 2017 article the smallest of the top 4 botnets discovered and shut down had 6,000,000 infected computers and the largest 30,000,000. The owner of the one with a reported 30 million infected computers was earning US $139,000/month leasing out the net. So, if someone really wants to perform a brute force cracking attempt the computing power is out there. I haven’t done the math to find out just how many potential key values there are when combined with the number of supported encryption methods TLS/SSL has, but if you can make 30 million attempts per second, a trillion permutations won’t take long to run through. (Keep this bit of knowledge in mind as we approach this discussion from a different yet related direction.)
We will start with XML and why you should never use it.
Every conforming XML document successfully transmitted will start with the following line:
<?xml version="1.0" encoding="UTF-8"?>
Oh, the version number will change as may the encoding string, but the first 14 characters are required to be there per w3schools an wikipedia. The wikipedia link will also show you an optional second line:
<!DOCTYPE example [<!ENTITY copy "©">]>
I will make the following uneducated assumptions:
- Once a “secret” is negotiated during TLS/SSL handshake and the encryption method set, it remains in effect for the duration of the conversation.
- You can use the same encryption method as is coded in the OpenSource code either without getting “wrapper bytes” or these bytes can be easily identified and stripped off.
“Wrapper bytes” might need a bit of explanation. Back in the days of DOS, if you used PKZip to compress a text file, it used to put a “pkzip” string at the beginning of the output with a version number, hashed password, yadda yadda. Some encryption methods will put wrapper bytes in front of or around the target output.
You need a PostgreSQL database (possibly multiple depending on disk size). One table.
| Column name | Data type | Key Number | Description |
|---|---|---|---|
| encrypted_value | text/varchar | 0 | Encrypted value of first 12 characters |
| encryption_key_value | text/varcahr | 1.2 | Key fed into encryption algorithm |
| encrypted_length | int | Length of the encrypted_value text. Used to determine how many threads needed. | |
| algorithm | int | 1.1 | Subscript into algorithm list. |
| hit_count | int | Number of times this encrypted value matched a packet. | |
| completed | text/varchar | Timestamp string identifying when the encrypted_value column was filled in. | |
| Dispatched | text/varchar | Timestamp string identifying when this record was dispatched to generate an encrypted value. |
It is possible some encryption libraries/functions will generate more than the original 12 characters so we need the encrypted_length column. This allows us to determine all of the sliding windows we need. The column is initialized to zero.
The general idea is to use the database to drive everything. When you create the empty table you populate it with all permutations of encryption_key_value and algorithm. All other columns will be empty/null/zero depending on datatype. Populating the machine requires a work-dispatcher service and a results-receiver service. The dispatcher receives a request for work and performs
SELECT encryption_key_value, algorithm FROM encrypted_xml_table WHERE dispatched = “” LIMIT 100;
If it gets rows back it sends them out. If it comes up empty it has to select all rows dispatched over N hours ago which have completed = “” to get more work for the worker.
The results-receiver gets back a packet of records containing algorithm, encrypted_key_value, encrypted_value and encrypted_length. It uses the alternate key of algorithm (1.1) and encrypted_key_value (1.2) to update rows with these values and fill in the completed time as the current time.
While you need to fully populate all of the potential alternate key values, you do not need to have all of the encrypted_value fields filled in to begin using this. You just need a sufficient quantity to start having successes. Remember: computers suck at random. No matter how hard the developers try there will be a natural distribution (bell curve) of key+algorithm pairs which prove successful.
Now would be a good time for you to revisit the botnet portion of the discussion. A nefarious organization with access to a large botnet could get tens of millions of rows filled in over a short period of time. One could also have a batch of cast-off i5 and i7 gen4+ machines they choose to stick some NVIDIA cards in and use the CUDA cores. The “how” doesn’t matter. Yes, you have some programming to do, but it is not overly complex. All of the encryption methods are already in the OpenSource for TLS/SSL and you just need to pull them in and use them. Every worker is encrypting the same 12 characters over and over again. Your really bottleneck will be the database. You might have to do transactions of 1000 at a time so you aren’t constantly waiting for the database. (depending on how/where you hosted it)
Assuming you don’t use a botnet, you’ve done nothing illegal at this point. You’ve just created a personal research project to see how long it would take to generate all possible encryptions of a single 12 character string via the TLS/SSL algorithms. Heck you could even do some extra programming and create a BOINC project.
Once you have a few million records you can start the second part of the code and that will be a later post.
