Until 2020, the 340 character cipher remained un-decrypted. There have been no end to the theories about the meaning of the code and the identity of its author from would-be sleuths. With the solution text now out and standing up to scrutiny, it’s a wonderful reminder that internet sleuths need to be taken with a grain of salt.
One of these sleuths, Sam Blake, decided to contact programmer David Oranchak of Roanoke, Virginia after he gave a talk on it at the annual meeting of the American Cryptogram Association. Blake was particularly intrigued by the idea of homophonic substitution where one letter might be swapped for more than one symbol and then re-arranged in a systematic way. This generated a whole host of new ways to read the cypher.
Here’s Oranchak’s talk:
Oranchak took what he’d found to Jarl van Eycke, a Belgian warehouseworker and codebreaker who’d written AZdecrypt, software used for decoding homophonic substitutions. Van Eycke used an updated version of his software to churn through the possibilities. Using misspellings and characteristics from Zodiac’s previous writings things started falling into place.
The code used a tremendous amount of computing power, power that was definitely not available in 1960’s. The techniques involved in cracking it weren’t like the ones used in modern cryptography, so it’s explains why few people have used such statistical models on what is essentially a one-off code.
Oranchak sent their solution to contacts at the FBI, and by the end of 2020, the FBI had verified the methodology and results. In March 2021, Blake wrote about how he’d used Mathematica, a math software package, for his part, and in January, van Eycke made headlines again when he cracked an unsolved 386-year-old code composed by a Dutch scientist.
JDH sits down and writes his own OS from scratch – and it runs in a VM on modern x86 hardware. But what should his OS do? How about play Tetris. With graphics, keyboard input, and even Soundblaster sound. He writes everything from scratch to handle all of this. As someone that grew up with 8086 assembly and programming old DOS based TSR programs, this was a blast from the past and definitely worth a watch.
A whole game in a QR code and Crinkler – a demoscene compressor
MattKC asked himself if he could put a whole game into a QR code. He actually succeeds at it, but with some fascinating turns along the way which include changing linker settings and creating a window in assembly.
One of his other adventures is compressing the executable using an old demoscene tool: Crinkler. Crinkler is not your normal RAR, ZIP, or other self-extracting executable compressors. Crinkler replaces the linker used to generate the executable by a combined linker and compressor. The result is an EXE file which does not do any kind of dropping and decompresses into memory like a traditional executable file compressor.
It also uses context modelling, which produces a far superior compression ratio than most other compressors. The disadvantage of context modelling is that it is extremely slow and needs quite a lot of memory for decompression, but this is not usually a problem with 4k demos.
Retro Game Mechanics Explained is a great series on retro game console programming. If you ever wanted to know how the cake is baked, this is a great channel.
One of the best series up so far is how to program the SNES system. His 16 part series talks about background effects, lag & blanking, DMA and HDMA, memory mapping, color math, hardware registers, background modes 0-6, and the infamous mode 7. It is one of the better explanations of mode 7 that I have seen (though folks with a more formal background in graphics might explain it with with affine transforms alone)
He also covers individual games and topics such as how the Atari 2600 ‘Raced the beam’, Atari quadrascan, pokemon sprite decompression, Pac-Man arcade’s famous kill screen, Mario’s wrong warp, and many other fun topics.
And just like that programmer’s were replaced by machine learning and pressing tab.
GitHub Copilot is a development plugin that uses AI to auto-complete what you’re coding. The AI was trained using github projects as its learning source. You start coding, press tab, and it gives you a list of what it thinks you might want next based on what it matches you might be developing.
Nick Chapsas tries out a number of programming tasks from basic data structures, creating an API, a calculator, and even fully implemented fizzbuzz. It does *shockingly* well.
I think this is the next obvious level of auto-completion we’ve had for years. I bet it almost certainly will come to mainline development tools in the next 5 years. It does, however, bring up some interesting legal points if someone unknowingly auto-completes a blob of code from an GPL or closed source project. This treads the fine line of auto-generated code and downright copying. My guess is that using IP violation code scanning tools to detect problems will be even more important.
If you’re interested in learning intermediate level shader programming, The Art of Code YouTube channel has some really awesome videos to get you going.
As a good example, here’s a really great introduction to programming a shader for a ray marching renderer:
Bitcoin, block chain currencies, and quantum computing
With bitcoin hitting all time highs and lows, it’s interesting to hear self-described pundits go on and on about the promises of crypto-currency. Surprisingly, one thing you don’t hear about is that the life of these currencies might be very limited now that quantum computers are becoming a reality.
Quantum computers are excellent at breaking mathematically difficult problems – which is the underlying technology for almost all of cryptography and block-chain algorithms. In October 2019, Google announced they have achieved quantum supremacy on a certain class of problems. So what does this mean for crypto-currencies?
Interestingly enough, the most vulnerable ones are the ones in the p2pk addresses. The coins in this address range were some of the earliest coins mined. The ones still in that range are largely considered to belong to people who have long since lost their keys. This means they could easily be mined by anyone with a sufficiently large quantum computer – and claim 2 million bitcoins worth almost 70 BILLION dollars (assuming bitcoin is worth the current market price of $35,000).
Not only that, if 25% of a currency is vulnerable to be quietly captured by a single investor with a quantum computer – it represents a tremendous amount of power to manipulate the currency.
So, unused p2pkh coins are safe, right? Not really. The moment you want to transfer coins from such a “safe” address, you reveal the public key, making the address vulnerable. From that moment until your transaction is “mined”, an attacker who possesses a quantum computer gets a window of opportunity to steal your coins. In such an attack, the adversary will first derive your private key from the public key and then initiate a competing transaction to their own address. They will try to get priority over the original transaction by offering a higher mining fee.
The time for mining a transaction is about 10 minutes, calculations show that a quantum computer would take about 30 minutes to break a Bitcoin key. So, as long as that is true, your bitcoin transaction is …probably… safe. But that won’t last forever. It is an almost certainty quantum computing will make crypto-currencies worthless at some point – maybe even in our lifetime at the rate quantum computing is making advances.
Computer scientists spend a lot of time thinking about the most optimal way of doing things. This guy stacks up 79 different kinds of ways of sorting things from smallest to largest and compares number of writes, compares, auxiliary array use, etc.