You’ve just finished your project. Well, not finished, but it works and you’ve solved all the problems worth solving, and you have a thing that works for you. Then you think about sharing your creation with the world. “This is cool” you think. “Other people might think it’s cool, too.” So you have to take pictures and video, and you wish you had documented some more of the assembly steps, and you have to do a writeup, and comment your code, and create a repository for it, maybe think about licensing. All of a sudden, the actual project was only the beginning, and now you’re stressing out about all the other things involved in telling other people about your project, because you know from past experience that there are a lot of haters out there who are going to tear it down unless it’s perfect, or even if it is, and even if people like it they are going to ask you for help or to make one for them, and now it’s 7 years later and people are STILL asking you for the source code for some quick little thing you did and threw up on YouTube when you were just out of college, and of course it won’t work anymore because that was on Windows XP when people still used Java.
Take a deep breath. We’ve all been there. This is an article about finding a good solution to sharing your work without dealing with the hassle. If you read the previous paragraph and finished with a heart rate twice what you started, you know the problem. You just want to share something with the world, but you don’t want to support that project for the rest of your life; you want to move on to new and better and more interesting projects. Here are some tips.
This article is about crypto. It’s in the title, and the first sentence, yet the topic still remains hidden.
At Hackaday, we are deeply concerned with language. Part of this is the fact that we are a purely text-based publication, yes, but a better reason is right there in the masthead. This is Hackaday, and for more than a decade, we have countered to the notion that ‘hackers’ are only bad actors. We have railed against co-opted language for our entire existence, and our more successful stories are entirely about the use and abuse of language.
Part of this is due to the nature of the Internet. Pedantry is an acceptable substitute for wisdom, it seems, and choosing the right word isn’t just a matter of semantics — it’s a compiler error. The wrong word shuts down all discussion. Use the phrase, ‘fused deposition modeling’ when describing a filament-based 3D printer, and some will inevitably reach for their pitchforks and torches; the correct phrase is, ‘fused filament fabrication’, the term preferred by the RepRap community because it is legally unencumbered by patents. That’s actually a neat tidbit, but the phrase describing a technology is covered by a trademark, and not by a patent.
The technical side of the Internet, or at least the subpopulation concerned about backdoors, 0-days, and commitments to hodl, is now at a semantic crossroads. ‘Crypto’ is starting to mean ‘cryptocurrency’. The netsec and technology-minded populations of the Internet are now deeply concerned over language. Cryptocurrency enthusiasts have usurped the word ‘crypto’, and the folks that were hacking around with DES thirty years ago aren’t happy. A DH key exchange has nothing to do with virtual cats bought with Etherium, and there’s no way anyone losing money to ICO scams could come up with an encryption protocol as elegant as ROT-13.
But language changes. Now, cryptographers are dealing with the same problem hackers had in the 90s, and this time there’s nothing as cool as rollerblading into the Gibson to fall back on. Does ‘crypto’ mean ‘cryptography’, or does ‘crypto’ mean cryptocurrency? If frequency of usage determines the correct definition, a quick perusal of the press releases in my email quickly reveals a winner. It’s cryptocurrency by a mile. However, cryptography has been around much, much longer than cryptocurrency. What’s the right definition of ‘crypto’? Does it mean cryptography, or does it mean cryptocurrency?
At what age did you begin learning about electronics? What was the state of the art available to you at the time and what kinds of things were you building? For each reader these answers can be wildly different. Our technology advances so quickly that each successive generation has a profoundly different learning experience. This makes it really hard to figure out what basic knowledge today will be most useful tomorrow.
Do you know the forward voltage drop of a diode? Of course you do. Somewhere just below 0.7 volts, give or take a few millivolts, of course given that it is a silicon diode. If you send current through a 1N4148, you can be pretty certain that the cathode voltage will be that figure below the anode, every time. You probably also have a working knowledge that a germanium diode or a Schottky diode will have a lower forward voltage, and you’ll know in turn that a bipolar transistor will begin to turn on when the voltage between its base and emitter achieves that value. If you know Ohm’s Law, you can now set up a biasing network and without too many problems construct a transistor amplifier.
Hardware and software are certainly different beasts. Software is really just information, and the storing, modification, duplication, and transmission of information is essentially free. Hardware is expensive, or so we think, because it’s made out of physical stuff which is costly to ship or copy. So when we talk about open-source software (OSS) or open-source hardware (OSHW), we’re talking about different things — OSS is itself the end product, while OSHW is just the information to fabricate the end product, or have it fabricated.
The fabrication step makes OSHW essentially different from OSS, at least for now, but I think there’s something even more fundamentally different between the current state of OSHW and OSS: the pull request and the community. The success or failure of an OSS project depends on the community of people developing it, and for smaller projects that can hinge on the ease of a motivated individual digging in and contributing. This is the main virtue of OSS in my opinion: open-source software is most interesting when people are reading and writing that source.
With pure information, it’s essentially free to copy, modify, and push your changes upstream so that others can benefit. The open hardware world is just finding its feet in this respect, but that’s changing as we speak, and I have great hopes. Costs of fabrication are falling all around, open and useful tools are being actively developed to facilitate interchange of the design information. I think there are lessons that OSHW can learn from the OSS community’s pull-request culture, and that will help push the hardware hacker’s art forward.
What would it take to get you to build someone else’s OSHW project, improve on it, and contribute back? That’s a question worth a thoughtful deep dive.
We’ve been having a lively discussion behind the scenes here at Hackaday, about SpaceX’s forthcoming launch of their first Falcon Heavy rocket. It will be carrying [Elon Musk]’s red Tesla Roadster, and should it be a successful launch, it will place the car in an elliptical orbit round the Sun that will take it to the Martian orbit at its furthest point.
On one hand, it seems possible that [Musk]’s sports car will one day be cited by historians as the exemplar of the excesses of the tech industry in the early 21st century. After all, to spend the millions of dollars required to launch the largest reusable space launch platform ever created, and then use it to hurl an electric vehicle into orbit round the Sun seems to be such a gratuitous waste of resources, an act of such complete folly as to be criminal.
Surely even given that there is a reasonable chance of a first launch ending in fiery destruction it must be worth their while canvassing the universities and research institutions of the world with the offer of a free launch, after all there must be a significant amount of science that would benefit from some cost-free launch capacity! It seems a betrayal of the famous “Why explore space” letter from the associate science director of NASA to a nun who questioned the expenditure while so many in the developing world were starving.
But on the other hand, first launches of rockets are a hazardous endeavour, as the metaphorical blue touchpaper is lit on the world’s largest firework for the first time. Satellites are expensive devices, and it would be a foolhardy owner who entrusted their craft to a launch vehicle with a good chance of a premature splashdown.
First launches traditionally carry a ballast rather than a payload, for example NASA have used tanks of water for this purpose in the past. SpaceX has a history of novelty payloads for their test launches; their first Dragon capsule took a wheel of cheese into space and returned it to Earth. We picture Musk looking around a big warehouse and saying, “well, we got a lot of cars!”
There is a fascinating question to be posed by the launch of the car, just what did they have to do to it to ensure that it could be qualified for launch? Satellite manufacture is an extremely exacting branch of engineering, aside from the aspect of ensuring that a payload will work it must both survive the launch intact and not jeopardise it in any way. It’s safe to say that the Roadster will not have to function while in orbit as the roads of California will be far away, but cars are not designed with either the stresses of launch or the transition to zero gravity and the vacuum of space in mind. Will a glass windscreen originally specified for a Lotus Elise on the roads of Norfolk shatter during the process and shower the inside of the craft with glass particles, for example? There must have been an extensive space qualification programme for it to pass, from vibration testing through removal of any hazards such as pressurised gases or corrosive chemicals, if only the folks at SpaceX would share some its details that would make for a fascinating story in itself.
So the Tesla Roadster is a huge publicity stunt on behalf of SpaceX, but it serves a purpose that would otherwise have to have been taken by an unexciting piece of ballast. It will end up as space junk, but in an orbit unlikely to bring it into contact with any other craft. If its space-suited dummy passenger won’t be providing valuable data on the suit’s performance we’d be extremely surprised, and when it is finally retrieved in a few centuries time it will make a fascinating exhibit for the Smithsonian.
Given a huge launch platform and the chance to fill it with a novelty item destined for orbit,the Hackaday team stepped into overdrive with suggestions as to what might be launched were they in charge. They varied from Douglas Adams references such as a heart of gold or a whale and a bowl of petunias should the rocket abort and the payload crash to earth, to a black monolith and a few ossified ape remains to confuse space historians. We briefly evaluated the theory that the Boring Company is in fact a hiding-in-plain-sight construction organisation for a forthcoming Evil Lair beneath the surface of Mars, before concluding that maybe after all the car is a pretty cool thing to use as ballast for a first launch.
It may be reaching towards seven decades since the first space programmes successfully sent rockets beyond the atmosphere with the aim of exploration, but while the general public has become accustomed to them as routine events they remain anything but to the engineers involved. The Falcon Heavy may not have been developed by a government, but it represents every bit as astounding an achievement as any of its predecessors. Flinging an electric vehicle into orbit round the Sun is a colossal act of showmanship and probably a waste of a good car, but it’s also more than that. In hundreds of years time the IoT devices, apps, 3D printers, quadcopters or whatever else we toil over will be long forgotten. But there will be a car orbiting the Sun that remains a memorial to the SpaceX engineers who made its launch possible, assuming it doesn’t blow up before it gets there. What at first seemed frivolous becomes very cool indeed.
While the whole industry is scrambling on Spectre, Meltdown focused most of the spotlight on Intel and there is no shortage of outrage in Internet comments. Like many great discoveries, this one is obvious with the power of hindsight. So much so that the spectrum of reactions have spanned an extreme range. From “It’s so obvious, Intel engineers must be idiots” to “It’s so obvious, Intel engineers must have known! They kept it from us in a conspiracy with the NSA!”
We won’t try to sway those who choose to believe in a conspiracy that’s simultaneously secret and obvious to everyone. However, as evidence of non-obviousness, some very smart people got remarkably close to the Meltdown effect last summer, without getting it all the way. [Trammel Hudson] did some digging and found a paper from the early 1990s (PDF) that warns of the dangers of fetching info into the cache that might cross priviledge boundaries, but it wasn’t weaponized until recently. In short, these are old vulnerabilities, but exploiting them was hard enough that it took twenty years to do it.
Building a new CPU is the work of a large team over several years. But they weren’t all working on the same thing for all that time. Any single feature would have been the work of a small team of engineers over a period of months. During development they fixed many problems we’ll never see. But at the end of the day, they are only human. They can be 99.9% perfect and that won’t be good enough, because once hardware is released into the world: it is open season on that 0.1% the team missed.
The odds are stacked in the attacker’s favor. The team on defense has a handful of people working a few months to protect against all known and yet-to-be discovered attacks. It is a tough match against the attackers coming afterwards: there are a lot more of them, they’re continually refining the state of the art, they have twenty years to work on a problem if they need to, and they only need to find a single flaw to win. In that light, exploits like Spectre and Meltdown will probably always be with us.
Let’s look at some factors that paved the way to Intel’s current embarrassing situation.
The year is almost over, and now it’s time to look back on the last fifty-odd weeks. What happened in this year in hacking? 2017 will go down as the beginning of another AI renaissance, although we’re not going to call it that; this year was all about neural nets and machine learning and advancements resulting from the development of self-driving cars and very beefy GPUs. Not since the 80s have we seen more work in ‘AI’ fields. What will it amount to this time around the hype cycle? Find out in a few years.
Biohacking was big this year, and not just because people are installing RFID tags and magnets in their hands. CRISPR is allowing for Star Trek-style genome hacking, and this year saw in vivo experiments to enable and disable individual genes in rat models. Eventually, someone is going to get a Nobel for CRISPR.
We’re going to Mars, and soon — very soon — a SpaceX Falcon Heavy is going to either lob a Tesla Roadster into solar orbit or the Atlantic Ocean. We learned about the BFR that will take dozens of people to Mars in a single launch. Boeing and Lockheed think they can compete with the Elon Musk PR powerhouse. The Bigelow Aerospace inflatable module passed its in-flight test on the ISS, giving the space station a new storage closet. Even in space, amazing stuff is happening this year.
Is that it? Not by a long shot. This year has seen some of the coolest hacks we’ve ever seen, and some of the dumbest security breaches ever. Hackaday is doing awesome. What else did 2017 have? Read on to find out.