Developed On Hackaday: 2 Days Left To Submit Your Design!

April 10, 2014 by Mathieu Stephan 9 Comments

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: Need Card Art — Who Likes To Draw?

March 27, 2014 by Mathieu Stephan 32 Comments

Our offline password keeper project (aka Mooltipass) is quite lucky to have very active (and very competent) contributors. [Harlequin-tech] recently finished our OLED screen low level graphics library which (among others) supports RLE decompression, variable-width fonts and multiple bit depths for fonts & bitmaps. To make things easy, he also published a nice python script to automatically generate c header files from bitmap pictures and another one to export fonts.

[Miguel] finished the AES encryption/decryption schemes (using AES in CTR mode) and wrote an awesome readme which explains how everything works and how someone may check his code using several standardized tests. We highly encourage readers to make sure that we didn’t make any mistake, as it was one of you that suggested we migrate to CTR mode (thanks [mate]!).

On the hardware side, we launched into production the top & bottom PCBs for Olivier’s design. We’re also currently looking for someone that has many Arduino shields to make sure that they can be connected to the Mooltipass. A few days ago we successfully put the Arduino bootloader inside our microcontroller and made the official Arduino Ethernet shield work with it.

Finally, as you may have guessed from the picture above our dear smart card re-sellers can pretty much print anything on them (these are samples). If one of you is motivated to draw something, please contact me at mathieu[at]hackaday.com!

On a (way) more childish note, don’t hesitate to give a skull to the mooltipass on HaD projects so it may reclaim its rightful spot as “most skulled“.

Developed On Hackaday: Security And Arduino Compatibility

March 16, 2014 by Mathieu Stephan 56 Comments

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

March 12, 2014 by Mathieu Stephan 100 Comments

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:

main(void)

{

if (foo)

{

functionCall();

}

else

{

foo = 0;

anotherFunctionCall();

}

}

– 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

February 11, 2014 by Mathieu Stephan 22 Comments

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:

Continue reading “Developed On Hackaday: The Current Project State” →

Developed On Hackaday: The Designs

January 20, 2014 by Mathieu Stephan 34 Comments

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!

Continue reading “Developed On Hackaday: The Designs” →

Developed On Hackaday: We Have Pixels!

January 12, 2014 by Mathieu Stephan 32 Comments

It has been a while since we kept you informed about the current state of the Mooltipass project. Well, several days ago we finally received the PCBs we got produced at Seeedstudio. Keep in mind that this first version (shown in the picture above) is only meant to check that the chosen components can suit our needs while our mechanical contributors work on their designs. Moreover, we may add empty footprints for our readers that may want to hack the device.

After a few hours of soldering and a few days of coding, we finally got a basic firmware running. The OLED screen is easily readable and has an amazing contrast (the picture doesn’t do it justice). So far we checked all basic functionalities of the on-board components and it’ll still take a few days/weeks to be certain that we can settle with them. We are therefore starting to ship a few platforms to the firmware developers that want to work on the core functions of the Mooltipass. So if you’re an experienced C developer and have some spare time, you may get onboard by contacting me at mathieu[at]hackaday[dot]com or by joining the Mooltipass Google Group.

In a few days we will publish the designs that our mechanical guys came up with and we’ll ask you to let us know which ones are your favorites. Depending on how things will go, we may produce PCBs for several of them to select our final design based on user experience and ease of use. We look forward to hearing your feedback in the comments section below!