This Is... Horrifyingly Accurate....

This is... horrifyingly accurate....

Going from being an introverted lurker on reddit to trying to post my own stuff here is so wild. I keep typing out a post, deleting it, then retyping because I think it's not good enough but then I look at other posts and why am I so worried?

It's like I'm at a fancy Italian restaurant and keep glancing around the room to see which hand people use to pick up the forks. But then I realize that everyone is shoveling spaghetti into their mouths using their bare hands and I'm like ah okay so I'm clearly overthinking this

Yeeep. Also, Assembly languages is different for every CPU family (And sometimes generations within those) because the assembly instructions (Which is... ALL the keywords in any assembly language) maps 1:1 to "what the CPU can do". So if you know a bit of assembly, suddenly, you have the ability to easily look up "What can this family of CPU's do?".

Reason to learn assembly #1

You will be able to better understand the program output of your compiler (specially if using C, C++ or Rust). Because in the end people using those languages want all the tasty performance their code can achieve, knowing assembly can be pretty useful for evaluating the scope of some optimizations. "Do I really need to do this optmization or does the compiler know it already?", "Does the compiler know how to inline this lambda?", "Is the compiler smart enough to get rid of this loop for me when I enable this thing?" and so on

Not only that, but you will be able to have some intuition when comparing the performance of similar code by its assembly code.

A really cool tool abot the subject is called Compiler Explorer and it basically lets you easily analyse the output of your code online

godbolt.org

Compiler Explorer

Compiler Explorer is an interactive online compiler which shows the assembly output of compiled C++, Rust, Go (and many more) code.

Honestly I have nothing to add. This is just 100% correct and well explained.

Why Not Write Cryptography

I learned Python in high school in 2003. This was unusual at the time. We were part of a pilot project, testing new teaching materials. The official syllabus still expected us to use PASCAL. In order to satisfy the requirements, we had to learn PASCAL too, after Python. I don't know if PASCAL is still standard.

Some of the early Python programming lessons focused on cryptography. We didn't really learn anything about cryptography itself then, it was all just toy problems to demonstrate basic programming concepts like loops and recursion. Beginners can easily implement some old, outdated ciphers like Caesar, Vigenère, arbitrary 26-letter substitutions, transpositions, and so on.

The Vigenère cipher will be important. It goes like this: First, in order to work with letters, we assign numbers from 0 to 25 to the 26 letters of the alphabet, so A is 0, B is 1, C is 2 and so on. In the programs we wrote, we had to strip out all punctuation and spaces, write everything in uppercase and use the standard transliteration rules for Ä, Ö, Ü, and ß. That's just the encoding part. Now comes the encryption part. For every letter in the plain text, we add the next letter from the key, modulo 26, round robin style. The key is repeated after we get tot he end. Encrypting "HELLOWORLD" with the key "ABC" yields ["H"+"A", "E"+"B", "L"+"C", "L"+"A", "O"+"B", "W"+"C", "O"+"A", "R"+"B", "L"+"C", "D"+"A"], or "HFNLPYOLND". If this short example didn't click for you, you can look it up on Wikipedia and blame me for explaining it badly.

Then our teacher left in the middle of the school year, and a different one took over. He was unfamiliar with encryption algorithms. He took us through some of the exercises about breaking the Caesar cipher with statistics. Then he proclaimed, based on some back-of-the-envelope calculations, that a Vigenère cipher with a long enough key, with the length unknown to the attacker, is "basically uncrackable". You can't brute-force a 20-letter key, and there are no significant statistical patterns.

I told him this wasn't true. If you re-use a Vigenère key, it's like re-using a one time pad key. At the time I just had read the first chapters of Bruce Schneier's "Applied Cryptography", and some pop history books about cold war spy stuff. I knew about the problem with re-using a one-time pad. A one time pad is the same as if your Vigenère key is as long as the message, so there is no way to make any inferences from one letter of the encrypted message to another letter of the plain text. This is mathematically proven to be completely uncrackable, as long as you use the key only one time, hence the name. Re-use of one-time pads actually happened during the cold war. Spy agencies communicated through number stations and one-time pads, but at some point, the Soviets either killed some of their cryptographers in a purge, or they messed up their book-keeping, and they re-used some of their keys. The Americans could decrypt the messages.

Here is how: If you have message $A$ and message $B$, and you re-use the key $K$, then an attacker can take the encrypted messages $A+K$ and $B+K$, and subtract them. That creates $(A+K) - (B+K) = A - B + K - K = A - B$. If you re-use a one-time pad, the attacker can just filter the key out and calculate the difference between two plaintexts.

My teacher didn't know that. He had done a quick back-of-the-envelope calculation about the time it would take to brute-force a 20 letter key, and the likelihood of accidentally arriving at something that would resemble the distribution of letters in the German language. In his mind, a 20 letter key or longer was impossible to crack. At the time, I wouldn't have known how to calculate that probability.

When I challenged his assertion that it would be "uncrackable", he created two messages that were written in German, and pasted them into the program we had been using in class, with a randomly generated key of undisclosed length. He gave me the encrypted output.

Instead of brute-forcing keys, I decided to apply what I knew about re-using one time pads. I wrote a program that takes some of the most common German words, and added them to sections of $(A-B)$. If a word was equal to a section of $B$, then this would generate a section of $A$. Then I used a large spellchecking dictionary to see if the section of $A$ generated by guessing a section of $B$ contained any valid German words. If yes, it would print the guessed word in $B$, the section of $A$, and the corresponding section of the key. There was only a little bit of key material that was common to multiple results, but that was enough to establish how long they key was. From there, I modified my program so that I could interactively try to guess words and it would decrypt the rest of the text based on my guess. The messages were two articles from the local newspaper.

When I showed the decrypted messages to my teacher the next week, got annoyed, and accused me of cheating. Had I installed a keylogger on his machine? Had I rigged his encryption program to leak key material? Had I exploited the old Python random number generator that isn't really random enough for cryptography (but good enough for games and simulations)?

Then I explained my approach. My teacher insisted that this solution didn't count, because it relied on guessing words. It would never have worked on random numeric data. I was just lucky that the messages were written in a language I speak. I could have cheated by using a search engine to find the newspaper articles on the web.

Now the lesson you should take away from this is not that I am smart and teachers are sore losers.

Lesson one: Everybody can build an encryption scheme or security system that he himself can't defeat. That doesn't mean others can't defeat it. You can also create an secret alphabet to protect your teenage diary from your kid sister. It's not practical to use that as an encryption scheme for banking. Something that works for your diary will in all likelihood be inappropriate for online banking, never mind state secrets. You never know if a teenage diary won't be stolen by a determined thief who thinks it holds the secret to a Bitcoin wallet passphrase, or if someone is re-using his banking password in your online game.

Lesson two: When you build a security system, you often accidentally design around an "intended attack". If you build a lock to be especially pick-proof, a burglar can still kick in the door, or break a window. Or maybe a new variation of the old "slide a piece of paper under the door and push the key through" trick works. Non-security experts are especially susceptible to this. Experts in one domain are often blind to attacks/exploits that make use of a different domain. It's like the physicist who saw a magic show and thought it must be powerful magnets at work, when it was actually invisible ropes.

Lesson three: Sometimes a real world problem is a great toy problem, but the easy and didactic toy solution is a really bad real world solution. Encryption was a fun way to teach programming, not a good way to teach encryption. There are many problems like that, like 3D rendering, Chess AI, and neural networks, where the real-world solution is not just more sophisticated than the toy solution, but a completely different architecture with completely different data structures. My own interactive codebreaking program did not work like modern approaches works either.

Lesson four: Don't roll your own cryptography. Don't even implement a known encryption algorithm. Use a cryptography library. Chances are you are not Bruce Schneier or Dan J Bernstein. It's harder than you thought. Unless you are doing a toy programming project to teach programming, it's not a good idea. If you don't take this advice to heart, a teenager with something to prove, somebody much less knowledgeable but with more time on his hands, might cause you trouble.

Good luck! I hope it turns out how you imagine it! :D I have this… great love for diagrams. I mainly use UML-ish ones but I love all types!

They are like… the middle point between the pure idea in your head (That may have missing parts you do not realize, because brains are silly like that) and the finished product.

They are the shaping of ideas and inspiration into reality. Taking shape like trying to fit a formless blob into one or more boxes so it can become real, without harming the core of the idea. It really is... very neat to get this view into peoples head, in a way I have trouble articulating.

This is one of mine(which had to go into a "real" report, so it is a bit formal):

Making wireframes again

Tuesday 8th August 2023

My head has too many ideas that it has come to me making terrible sketch wireframes, hopefully converting this to code makes sense and looks pretty（˶′◡‵˶）

I'm sure there's a quote out there that talks about something ugly can be turned into something beautiful - yeah, that's what's going to happen to these awful sketches.

Wish me luck o(*^▽^*)┛

>> note: have a nice day/night and good luck with your studies and in life!

I finally switched to firefox and I've seen a lot of posts about the effortless importing of preferences from chrome and how it's important to support non-chromium platforms, but nobody is talking about the loss of productivity that happens when beautiful women come to your house to kiss you on the mouth because they heard you use firefox now. nobody's talking about this

If you do ANY C++, You need to watch Jason Turners!

Oh my god, I just realized I have never plugged Jason Turners youtube channel on this blog!!! This must immediately be remedied!

YouTube

C++ Weekly With Jason Turner

Making C++ Fun and Accessible.

Not only is this man VERY easy to listen to, and give great examples of everything he talks about, from super basic begginer concepts and up to stuff about how C++ compilers decide what template classes to implement for any given use of the function. Can only be recommended. It is FACINATING how all the tiny details of C++ clicks and pops, and make that glorus optimized, and smooth machine that is C++ run. Love it