Developed on Hackaday: Olivier’s Design Rundown

The Hackaday writers and readers are currently working hand-in-hand on an offline password keeper, the Mooltipass. A few days ago we presented Olivier’s design front PCB without even showing the rest of his creation (which was quite rude of us…). We also asked our readers for input on how we should design the front panel. In this new article we will therefore show you how the different pieces fit together in this very first (non-final) prototype… follow us after the break!

[Read more...]

Developed on Hackaday: The Top PCB dilemna

The Hackaday community offline password keeper is slowly coming together. A few days ago we received the top PCB for Olivier’s design (shown above). If you look at the picture below, you may see the problem we discovered when opening our package: the soldermask was the wrong color! Given the board is meant to be placed behind a tinted acrylic panel, this was quite a problem…

After using some spray paint, we managed to get to the point shown in the bottom left of the picture. The next task was to find the best way to illuminate the input interface with reverse mount LEDs. Using a CNC mill we machined openings (top right PCB) but also removed some epoxy on both PCB’s sides, thinking it would provide a better light diffusion. We then wrote part of the Mooltipass PWM code and took these pictures:

[Read more...]

Developed on Hackaday: 2 Days Left to Submit your Design!

We’re sure that many of Hackaday readers already know that one of the two main components of the Mooltipass project is a smart card, containing (among others) the AES-256 encryption key. Two weeks ago we asked if you’d be interested coming up with a design that will be printed on the final card. As usual, many people were eager to contribute and recently sent us a few suggestions. If you missed the call and would like to join in, it’s not too late! You may still send your CMYK vector image at mathieu[at]hackaday[dot]com by sunday. More detailed specifications may be found here.

In a few days we’ll also publish on Hackaday a project update, as we recently received the top and bottom PCBs for Olivier’s design. The low level libraries will soon be finished and hopefully a few days later we’ll be able to ship a few devices to developers and beta testers. We’re also still looking for contributors that may be interested in helping us to develop browser plugins.

The Mooltipass team would also like to thank our dear readers that gave us a skull on Hackaday projects!

Developed on Hackaday: Security and Arduino Compatibility


Some of our readers noticed that the Hackaday community open-source offline password keeper (aka Mooltipass) has two incompatible characteristics: being secure and Arduino compatible.

Why is that? Arduino compatibility implies including a way to change the device firmware and accessing the microcontroller’s pins to connect shields. Therefore, some ill-intentioned individuals may replace the original firmware with one that would log all user’s inputs and passwords, or in another case simply sniff the uC’s signals. The ‘hackers’ would then later come to extract the recorded data. Consequently, we needed a secure tamper-proof Mooltipass version and an Arduino-compatible one, while allowing the former to become the latter.

Olivier’s design, though completely closed, will have several thinner surfaces directly above the Arduino headers. As a compromise, we therefore thought of sending a bootloader-free assembled version to the people only interested in the password keeper functionality, while sending a non-assembled version (with a pre-burnt bootloader) to the tinkerers. The Arduino enthusiasts would just need to cut the plastic at the strategic places (and perhaps solder headers to save costs). The main advantage of doing so is that the case would be the same for both versions. The drawback is that each board would have a different firmware depending on who it is intended for.

What do our reader think? For more detailed updates on the Mooltipass current status, you can always join the official Google group.

Developed on Hackaday: Coding Conventions and GitHub Pull Requests

The Hackaday community is currently very busy coding the low-level libraries of our open-source offline password keeper project. And when many talented contributors work together on a common concept, interesting discussions take place. In our dedicated Google Groups, some of them were about the choice of naming/coding conventions and also how/when to approve GitHub pull requests. But don’t leave already… this topic is actually more interesting than it sounds.

The age difference between the older and younger firmware contributor is guessed to be approximately 30 years… and many things can happen in such a time frame. Even though our coders are writing in C, most of them code in other programming languages at school/work. They also use different text editors on different operating systems. Understandably, each one of them therefore has its preferred coding / naming convention and indent style. The Mooltipass conventions were selected based on majority voting, and after many emails we settled on an Allman style convention with camelCase:

    if (foo)
        foo = 0;
- 79 characters line length as a soft requirement
- 4 spaces, no tabs

Most of the contributors believe that it is the best compromise between code clarity and cross-platform compatibility, but we would be curious to know our Hackaday readers’ opinions on this particular topic.

The second matter is a bit more of a management one. What is the best strategy to manage and review code changes made to a main GitHub repository, when a project is at its infancy and composed of (more or less) non-remunerated contributors?
It is perfectly understandable that interest, spare time and willingness to contribute may vary over time. Perhaps some of our readers may already be familiar with Agile software development, a group of software development methods based on iterative and incremental development, which promotes adaptive planning, evolutionary development and encourages rapid and flexible response to change. Do you think this can be applied to the Mooltipass project?

We would be curious to hear similar experiences on these topics, as we gladly accept constructive criticism. You may also want to join our dedicated Google group to check out the different discussions that already happened there. On a side note, we are also currently looking for capacitive wheel / touch button footprints libraries for Kicad.

Developed on Hackaday: the Current Project State

It has been quite a while since we updated our readers with the current state of the Mooltipass, the offline password keeper project developed by the Hackaday staff and community.

A few weeks ago we presented you the designs that our mechanical contributors had thought of. We organized a poll to get a feeling of what the favorite designs may be and around one thousand people expressed their opinions. The first three favorite designs with their corresponding votes were:

[Read more...]

Developed on Hackaday: The Designs

We know that many of our readers have been impatiently waiting to discover what the Hackaday community-developed offline password keeper project will look like. Today we present you several designs that our mechanical contributors came up with and we will ask you to give your opinion about them. Obviously these are just preliminary cases that may evolve along the way, but we will only produce the electronics for the designs you prefer.

All the designs are embedded after the break, with a multiple-choices poll to express your interest. You may also want to join the Mooltipass Google Group in case you’d want to talk about the designs in more depth or meet their creators. On the firmware side, I just finished soldering many mooltipass prototypes that will be shipped in the coming days to our firmware developers. As you may have noticed, this project is gaining speed!

[Read more...]