OmniBallot, Another Flawed Attempt At Online Voting

June 14, 2020 by Maya Posch 49 Comments

Although online voting in elections has been a contentious topic for decades already, it is during the current pandemic that it has seen significant more attention. Along with mail-based voting, it can be a crucial tool in keeping the world’s democratic nations running smoothly. This is where the OmniBallot software, produced by Democracy Live, comes into play, and its unfortunate unsuitability for this goal.

Despite already being used by multiple US jurisdictions for online voting, a study by MIT’s [Michael Specter] and University of Michigan researchers points out the flaws in this web-based platform. Their recommendations are to either avoid using OmniBallot completely, or to only use it for printing out a blank ballot that one then marks by hands and sends in by mail.

One of the issues with the software is that it by default creates the marked ballot PDF on the Democracy Live servers, instead of just on the user’s device. Another is that as a web-based platform it is hosted on Amazon Web Services (AWS), with JavaScript sources pulled from both CloudFlare and Google servers. Considering that the concern with electronic voting machines was that of unauthorized access at a polling station, it shouldn’t require a lengthy explanation to see this lack of end-to-end security with OmniBallot offers many potential attack surfaces.

When Ars Technica contacted Democracy Live for commentary on these findings, Democracy Live CEO [Bryan Finney] responded that “The report did not find any technical vulnerabilities in OmniBallot”. Since the researchers did not examine the OmniBallot code itself that is technically true, but misses the larger point of the lack of guarantee of every single voter’s device being secured, as well as every AWS, CloudFlare and Google instance involved in the voting process.

As a result, the recommended use of OmniBallot is to use it for the aforementioned printing out of blank ballots, to save half of the trip time of the usual mail-in voting.

Quantum Computing And The End Of Encryption

June 11, 2020 by Maya Posch 58 Comments

Quantum computers stand a good chance of changing the face computing, and that goes double for encryption. For encryption methods that rely on the fact that brute-forcing the key takes too long with classical computers, quantum computing seems like its logical nemesis.

For instance, the mathematical problem that lies at the heart of RSA and other public-key encryption schemes is factoring a product of two prime numbers. Searching for the right pair using classical methods takes approximately forever, but Shor’s algorithm can be used on a suitable quantum computer to do the required factorization of integers in almost no time.

When quantum computers become capable enough, the threat to a lot of our encrypted communication is a real one. If one can no longer rely on simply making the brute-forcing of a decryption computationally heavy, all of today’s public-key encryption algorithms are essentially useless. This is the doomsday scenario, but how close are we to this actually happening, and what can be done?

Continue reading “Quantum Computing And The End Of Encryption” →

Xilinx Makes MIPI CSI And DSI Controller IP Blocks Free To Use With Vivado

June 9, 2020 by Maya Posch 21 Comments

If you want to use a display or camera with an FPGA, you will often end up with a MIPI-based solution. As of the Xilinx Vivado 2020.1 release, the MIPI DSI (display serial interface) and CSI (camera serial interface) IP blocks are now bundled with the IDE to be used freely with Xilinx FPGAs.

The Xilinx MIPI CSI2 receiver block implements the CSI-2 v1.1 specification, which although a bit older is essentially the same CSI implementation as on the Raspberry Pi boards. This means that it would allow one to use this IP block on an FPGA with many common CSI camera modules out there. The IP block offers a standard AXI4 interface for connecting up to the rest of a design.

Similarly, the Xilinx MIPI DSI transmitter block implements DSI v1.3 specification. This offers a maximum data rate of 1.5 Gbps, with an AXI4-lite interface to communicate with the rest of the design. Both IP blocks are subject to the Core license agreement, which doesn’t appear to preclude it from being used in a specific fashion, whether commercial or personal.

This is not the only way to use MIPI devices with an FPGA, of course. Take for example [Daveshah]’s CSRIx project on Github.

Header image: Kwapix / CC BY-SA 4.0

3D Printing Nuclear Reactors For Fun And Profit

June 8, 2020 by Maya Posch 18 Comments

Over the past decades, additive manufacturing (AM, also known as 3D printing) has become increasingly common in manufacturing processes. While immensely helpful in the prototyping of new products by allowing for rapid turn-around times between design and testing, these days additive manufacturing is used more and more often in the production of everything from small production runs of custom enclosures to hard to machine components for rocket engines.

The obvious advantage of additive manufacturing is that they use generic equipment and common materials as input, without requiring expensive molds as in the case of injection molding, or extensive, wasteful machining of raw materials on a lathe, mill, and similar equipment. All of the manufacturing gets reduced to a 3D model as input, one or more input materials, and the actual device that converts the 3D model into a physical component with very limited waste.

In the nuclear power industry, these benefits haven’t gone unnoticed, which has led to 3D printed parts being developed for everything from keeping existing plants running to streamlining spent fuel reprocessing and even the printing of entire nuclear reactors.

Continue reading “3D Printing Nuclear Reactors For Fun And Profit” →

A Look Behind The Canvas Of The “60 Billion Lights” Project

June 8, 2020 by Maya Posch 17 Comments

In May of this year, [Erich Styger] shows his project called “60 Billion Lights” off to the world. Now he has published an update on the making of this impressive work of art. As a quick recap, “60 Billion Lights” is a canvas art piece, which has 60 dual shaft stepper motors integrated into it. Each stepper motor has forty 24-bit RGB LEDs, making for a total of 60 billion position and light combinations on the entire canvas.

With the dual shaft stepper motors, one can control the position of laser-cut acrylic rods inside each of the forty depressions that make up a unit. Each unit has its WS2812B LEDs positioned around the inside edge.

As the embedded video (after the break) shows, it can be used to create a wide variety of effects. The whole of it is driven by 15 controller boards that run FreeRTOS on an NXP LPC845 (Cortex-M0+), connected via RS-485.

In the ‘Making Of’ video (embedded after the break) and article, more details are shown of the individual components, including the dual shaft stepper motors, stepper motor PCBs, the LED ring PCBs, and countless images of the construction, painting and assembly.

If the original article gave one the impression that this was an easy project, it is this behind the scenes look that gives one a good impression of the full scale. From the countless PCBs, controller boards, wiring, programming to the assembly and testing. Not to mention the painting of the canvas itself, which is an original work.
Continue reading “A Look Behind The Canvas Of The “60 Billion Lights” Project” →

Lattice Semiconductor Targets Bitstream Reverse Engineering In Latest Propel SDK License

June 5, 2020 by Maya Posch 42 Comments

The topic of reverse engineering is highly contentious at best when it comes to software and hardware development. Ever since the configuration protocol (bitstream) for Lattice Semiconductor’s iCE40 FPGAs was published in 2015 through reverse engineering efforts, there has been a silent war between proponents of open bitstream protocols and FPGA manufacturers, with the Lattice ECP5’s bitstream format having been largely reverse-engineered at this point.

Update: About eight hours after this article was published, Lattice Semiconductor issued a statement retracting the EULA language that banned bitstream reverse engineering. Please check out Hackaday’s article about this reversal.

Most recently, it appears that Lattice has fired a fresh shot across the bow of the open source projects. A recently discovered addition to the Propel SDK, which contains tools to program and debug Lattice devices, specifically references bitstream reverse engineering. When logged in with an account on the company’s website the user must agree to the Lattice Propel License Agreement for Lattice Propel 1.0 prior to download. That document includes the following language:

In particular, no right is granted hereunder […] (3) for reverse engineering a bitstream format or other signaling protocol of any Lattice Semiconductor Corporation programmable logic device.

Continue reading “Lattice Semiconductor Targets Bitstream Reverse Engineering In Latest Propel SDK License” →

Turning A MicroKORG Into A MicroKORG S With This Speaker Mod

June 5, 2020 by Maya Posch 11 Comments

When [Michael Wessel] bought his MicroKORG synthesizer/vocoder, he felt less than amused when two years later the MicroKORG S was released, with the ‘S’ standing for ‘sound’, apparently, for the 2+1 speaker system that was added to it. Undeterred, [Michael] figured out that both synthesizers are similar enough that one could likely add a similar speaker system to the original MicroKORG.

The similarities between the two products become apparent when one compares the original with its successor, with the latter seemingly mostly adding said speakers and more presets, along with a snazzy new exterior. (Although the 1970s styling of the original may have more fans.) As the embedded video shows, this mod is fairly clean.

At the core of this mod is a PAM8403-based class D amplifier board. The PAM8403 is a 3 W audio amplifier, originally produced by Power Analog Microelectronics (now Diodes). While not an amazing amplifier, it lends itself well for battery-powered applications like the MicroKORG. Rounding out the build is a 7805 linear regulator to get 5 V for the PAM8403, a few filter capacitors, a switch to turn the speakers on/off, and of course the speakers.

Although there’s quite a bit of space in the enclosure, most speakers tend to be large enough that this can be a bit of a squeeze. [Michael] found some low-profile 20 W full-range speakers that seem to work well for this purpose. To finish wiring this up, all it takes is a hole saw and a way to get the audio output from the MicroKORG.

In this mod, [Michael] opted to get the audio from the output jack on the back, but for a cleaner result it probably could be wired straight into the on-board header.

Continue reading “Turning A MicroKORG Into A MicroKORG S With This Speaker Mod” →