It happens to pretty much everyone who gets into keyboards. No commercial keyboard can meet all your needs, so you start building them. Use them a while, find problems, build a new keyboard to address them. Pretty soon you think you have enough user experience to design the perfect keeb — the be-all, end-all magnum opus clacker you can take to the grave. This time, it happened to [aydenvis]. We must say, the result is quite nice. But will it still be perfect in six months?
As you might expect, this board uses an Arduino Pro Micro. We can’t say for sure, but it looks like [aydenvis] created a socket with a second Pro Micro board populated only with female header. That’s definitely a cool idea in case the board fails. It also has two rotary encoders and a pair of toggle switches to switch controller and secondary designations between the PCBs.
We like the philosophy at play in this 36-key ‘board that states that prime ergonomics come when each finger must only travel one key distance from the home row. This of course requires programming layers of functionality into the firmware, which is easy enough to set up, but can be tricky to memorize. One thing that will help is the color-coded RGB underglow, which we’re going to call sandwich glow because it is emanating from the middle of a stacked pair of PCBs floating on 7 mm standoffs. We only wish we could hear how loudly those jade Kailh choc switches can clack. The board files are up on GitHub, so we may just have to make our own.
The big news this week is the huge flaw in Microsoft’s Active Directory, CVE-2020-1472 (whitepaper). Netlogon is a part of the Windows domain scheme, and is used to authenticate users without actually sending passwords over the network. Modern versions of Windows use AES-CFB8 as the cryptographic engine that powers Netlogon authentication. This peculiar mode of AES takes an initialization vector (IV) along with the key and plaintext. The weakness here is that the Microsoft implementation sets the IV to all zeros.
It’s worth taking a moment to cover why IVs exist, and why they are important. The basic AES encryption process has two inputs: a 128 bit (16 byte) plaintext, and a 128, 192, or 256 bit key. The same plaintext and key will result in the same ciphertext output every time. Encrypting more that 128 bits of data with this naive approach will quickly reveal a problem — It’s possible to find patterns in the output. Even worse, a clever examination of the patterns could build a decoding book. Those 16 byte patterns that occur most often would be guessed first. It would be like a giant crossword puzzle, trying to fill in the gaps.
This problem predates AES by many years, and thankfully a good solution has been around for a long time, too. Cipher Block Chaining (CBC) takes the ciphertext output of each block and mixes it (XOR) with the plaintext input of the next block before encrypting. This technique ensures the output blocks don’t correlate even when the plaintext is the same. The downside is that if one block is lost, the entire rest of the data cannot be decrypted Update: [dondarioyucatade] pointed out in the comments that it’s just the next block that is lost, not the entire stream. You may ask, what is mixed with the plaintext for the first block? There is no previous block to pull from, so what data is used to initialize the process? Yes, the name gives it away. This is an initialization vector: data used to build the initial state of a crypto scheme. Generally speaking, an IV is not secret, but it should be randomized. In the case of CBC, a non-random IV value like all zeros doesn’t entirely break the encryption scheme, but could lead to weaknesses. Continue reading “This Week In Security: AD Has Fallen, Two Factor Flaws, And Hacking Politicians”→
Electronic devices can be surprisingly leaky, often spraying out information for anyone close by to receive. [Docter Cube] has found another such leak, this time with the speakers in iPhones. While repairing an old AM radio and listening to a podcast on his iPhone, he discovered that the radio was receiving audio the from his iPhone when tuned to 950-970kHz.
[Docter Cube] states that he was able to receive the audio signal up to 20 feet away. A number of people responded to the tweet with video and test results from different phones. It appears that iPhones 7 to 10 are affected, and there is at least one report for a Motorola Android phone. The amplifier circuit of the speaker appears to be the most likely culprit, with some reports saying that the volume setting had a big impact. With the short range the security risk should be minor, although we would be interested to see the results of testing with higher gain antennas. It is also likely that the emission levels still fall within FCC Part 15 limits.
While the full steampunk aesthetic might be a bit much for most people, those antique gauges do have a certain charm about them. Unfortunately, implementing them on a modern project can be somewhat tricky. Even if you’ve got a stock of old gauges laying around, you’ve still got to modify the scale markings and figure out how to drive them with digital electronics. While we’ve seen plenty of people do it over the years, there’s no debating it’s a lot harder than just wiring up an I2C display.
But maybe it doesn’t have to be. With his Rad-O-Matic, [Hans Jørgen Grimstad] created a pretty convincing “analog” gauge using a small e-ink panel. Of course it won’t fool anyone who gives it a close look, but at a glance, you could certainly be forgiven for thinking it was some kind of vintage indicator. Especially with the cracked and stained Fresnel lens he put in front of it.
For this project [Hans] used a LilyGo T5, which combines an ESP32 with a 2.13 inch electronic paper display. These are presumably meant to be development boards for digital signage applications, but they occasionally show up in hacker projects since they’re so easy to work with. The board pulls data from a RD200M radon sensor over a simple UART connection, and the current reading is indicated by a “needle” that moves across a horizontal scale on the display.
On its own, it wouldn’t look very vintage. In fact, quite the opposite. But [Hans] really helped sell the look on this project by designing and 3D printing a chunky enclosure and then weathering it to make it look like it’s been kicking around since the Cold War.