Zamek: The Offline Pocket Password Manager

Creating and retrieving passwords for all your accounts has never been this easy and convenient!

Similar projects worth following
Zamek is your personal, portable password manager.

I'm working on putting together a group-buy campaign for a batch of these with attractive cases! Sign up at to find out when you can get your own!

See a video review of the beta unit at !

Many people use the same password for different online accounts. Even if the password is very strong, hackers don't need to break into your very secure financial and other important accounts directly. They can attack a weaker website, such as a web forum or subscription service, and use the password they stole from that website's database to steal your identity and log into any of your online accounts.

Both physical and electronic security are difficult skills to master, but most would agree that it's a bad idea to use a single key for every real-world lock you own. So why would you use the same digital key for all of your electronic locks? Many people complain that it is difficult to remember multiple passwords; in the real-world, you don't need to remember how every key on your keychain looks like. So I thought: what if you could have a keychain that keeps your digital keys for you? Zamek is the answer.

I turned to the physical keychain for inspiration, as a physical keychain is already very easy to use. When you need to unlock something, you choose the right key, insert it into the lock, and turn.

Zamek was designed to open your electronic locks as easily as a regular key opens physical locks, with an additional layer of security in case someone other than yourself picks up your digital keychain. The process can be described as:

1. Unlock your Zamek using a security PIN you choose

2. Use Zamek's joystick to change the account displayed on its screen to the one you wish to unlock

3. Insert the Zamek into your computer's USB port

4. Press the joystick to enter the password for the account

Zamek will type in the currently selected password into any field on your screen you select. If there is no USB port available, you can read the password for the account on Zamek's highly visible OLED screen and type it in manually.

Entering your account information into Zamek is intuitive and simple. After you enter your information once, it is stored permanently on Zamek's built-in memory. Your information is encrypted with an industry-recognized AES cipher, which means that if your Zamek is ever stolen, criminals will not be able to extract your information.

Zamek was designed to be your electronic key to the digital world. Smaller than a car remote, it easily clips to your keychain and can be carried everywhere. It features a highly visible screen and a long battery life, which is topped up every time you plug Zamek into your USB port. The joystick is comfortable to use, and the interface is intuitive enough to not require an instruction manual after the first set-up. Additional features currently in consideration are secure formatting and backup/restore options.

All the code and schematics for Zamek will be published under an Open Source license. This mean that anyone can read, validate, and critique the design of any part of the Zamek openly. My desire is that the Open Source process will lead to a device which is ultimately more secure, completely trusted, and reproducible in case I am not able to produce these in the future.

Lastly, Zamek is completely yours to own and use. It protects your data in a personal, respectful, and dignified manner: Zamek does not "phone home" to any remote servers, and it does not store any information anywhere other than its secure memory. Your information will never be anywhere but in your pocket.

  • 1 × ATMega32u4 Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × OLED screen
  • 1 × Custom designed circuit board
  • 1 × Lithium battery
  • 1 × Custom designed enclosure

  • USB-C Variant in Prototype!

    jareklupinski07/19/2020 at 22:47 0 comments I posted schematics and board files for a USB-C variant :) back-viewTo make it waterproof, it will use two hall-effect sensors to read an external bearing ;)

  • Source posted to Github!

    jareklupinski07/12/2018 at 03:26 0 comments

    I have finished cleaning up my repositories and posted the source for the trackball version of the Zamek here:

    It's still in very rough form, and could definitely use more eyes on the design. I'll still be researching ways to produce the hardware economically while keeping an eye on the repo :)

  • Short Progress Update!

    jareklupinski01/27/2018 at 03:33 5 comments

    After a ton of excellent feedback regarding IP68 protection, I have decided to use buttons instead of a trackball for the initial version of the Zamek. I will keep the code for the trackball in comments and possibly revisit it for version 2, but right now my priority is to get this out the door soon!

    I'll finish testing when my battery comes in, then start looking at simple watertight enclosures. I'm thinking clear silicone?

  • ( Hopefully ) Final Zamek Design

    jareklupinski05/12/2017 at 23:26 1 comment

    Sorry about the lack of screen! I couldn't wait until the screen came to start fitting it together :)

    I'll take more pictures after the screen comes in. In the mean time I'll explore whether this case design is viable for production, or try to come up with a more manufacturable solution.

  • Video Review

    jareklupinski04/18/2017 at 18:11 0 comments

    I sent a spare Zamek beta unit to a Youtube Electronics Channel; check out their take on it here!

  • Back On Track!

    jareklupinski04/18/2017 at 18:06 0 comments

    Exciting news! After much waiting, I've finally found an easily source-able battery to use for the Zamek, meaning I can finally fit together an attractive case :) The first draft of the case has been sent to Ponoko; stay tuned!

    Some background: Zamek has been on hold for a while as I searched for ways to easily create a case that fit around the strange shape consisting of the Screen/Battery/PCB sandwich with the trackball right next to it. Every solution that was attempted was either ugly or impractical to produce.

    I recently got my hands on some ultra-thin batteries, only 1.5mm thick! These guys don't hold a lot of juice ( 30mAh ), but my calculations estimate that that's enough to check your password about 700 times before you need to top up ( 15 seconds of on-time at 10mA avg draw ). I'm working with the battery manufacturer to see if we can push the charging rate of the battery up to 2 or even 4C, so the battery could be charged in a matter of minutes. Case parts should be in early next week, next update then!

  • Final Hardware Revision

    jareklupinski09/09/2016 at 02:35 8 comments

    After some back and forths with designing the case, I realized that it would be much easier to produce the device if I re-engineered some of the sticking points around the previous design. So I cleaned up the entire back of the circuit board so that it can sit flush up against the housing. I also added a trackball for faster and more accurate navigation.

  • PCB and Assembly by MacroFab, Launching on CrowdSupply!

    jareklupinski05/10/2016 at 03:17 0 comments

    Latest PCB Revision, fabbed and assembled by the fine crew at !

    I'm working on putting together a group-buy campaign for a batch of these with attractive cases! Sign up at to find out when you can sign up for your own!

    This project will release its source files, containing board layout, source code, and enclosure designs, on the day the campaign launches, all published here on !

    See all the details:

    Here is a video showing the screen layout and data entry using the joystick:

    There is also a PC app planned which will provide backup and restore to hard disk functionality, as well as make inputting credentials to your Zamek easier:

  • Short delay as I'm waiting for displays to arrive

    jareklupinski04/27/2016 at 13:57 0 comments

    The next PCB revision is in, but my display vendor has delayed shipment of my order. Expect pics of the new revision some time next week!

  • Adding Storage and Increasing Security

    jareklupinski04/21/2016 at 00:20 0 comments

    A bare ATMega32u4 has 1KB of EEPROM. This means that by itself, it can store 20 typical account entries (consisting of a 16 character site name, a 16 character user name, and a 16 character password). In order to expand this repository, I have added on a footprint for common EEPROM chips. This will allow up to 100 accounts to be stored!

    I'm also starting to think of ways to implement an additional layer of security to secure the EEPROM payload against brute-forcing attacks. This usually means taking the route of longer keys and/or longer computation time. I thought about all the literature I've read on the subject and parsed through chat logs with the excellent folks on the Hacker Channel chat, and am thinking about writing a method to encrypt the EEPROM with a very long key that would be stored in the microcontroller's RAM. This key would itself be encrypted with the relatively shorter PIN. This means that if an attacker simply tries to dump the EEPROM, they would be met with a very resistant payload. If the attacker were to try to dump the RAM, they would likely erase the contents of the RAM in the process (I'll give the chip a warm jacket in case security researchers try to freeze the chip ;) ).

View all 18 project logs

Enjoy this project?



GNUtoo wrote 04/10/2016 at 21:21 point
Without javascript it messed my linebreak, sorry. Trying to double the line breaks this time. By the way a feature to consider (or not) would be to have a real RNG on it. There is an implementation here: I mention it since it might require some hardware modifications. With PBKDF2, it can be used to verify the passphrase entered with the joystick.

  Are you sure? yes | no

jareklupinski wrote 04/10/2016 at 23:45 point

Right now I'm asking the user to click the joystick twice to generate entropy, with the microseconds in between joystick clicks setting the random seed for the atmega32u4's pseudo-rng, but I am evaluating the cost/benefit of a hardware based-rng vs. increasing the number of random joystick clicks required.

  Are you sure? yes | no

GNUtoo wrote 04/10/2016 at 21:14 point
Hi, Having an input device(the joystick) and a display is wonderful. Thanks to that, maybe that device could also be used like a smartcard, but without the inherent problems related to it: Smartcards don't have dedicated displays nor input, this makes it possible for the host computer to sniff the pin and use it to also sign/decrypt what the user didn't intend to. However, I doubt that using encryption and a passphrase could practically speaking secure the "keychain" content against someone stealing it. With cryptography, passphrases have to be long to work. The LUKS FAQ has some information on password complexity. Entering long passphrases is unpractical with a joystick. Short but complex passphrases are less practical to remember, and still an issue to type (Think of having way more characters to select from on the screen). An idea would be to do like with old arcade game consoles: You could make the software generate a random key, which you would encrypt the keychain content with. This key would be stored on a memory that can be wiped easily: Some game arcade consoles uses additional battery powered RAM for that. Thanks to that tempering can be detected even when your "keychain" is not plugged in a computer: you can make + and - shorted when the case is opened for instance. The "additional RAM" data is then lost. Now, you can also mandate a short password in software, and wipe the "additional RAM" content if there are too much failed attempts. Some SRAM are probably power efficent enough to be powered during several years on coin-batteries. However, I've no idea how secure this would be: it still seems a better than a very short password to me. I've also no idea if it's possible to design a case that would detect tempering, especially if the attacker tries to cut the case instead of merly opening it. I don't belive that code signing is practical enough for users to use, since it would require the users to maintain their own PKI, and to do it securely. Having someone else to do that would for them would have bad consequences on freedom: Mandating what code users have to run is not a good idea. That means that they wound't be able to recompile and run the code, and this is important. Denis.

  Are you sure? yes | no

jareklupinski wrote 04/10/2016 at 23:41 point

I was originally going to type that erasing the contents due to low battery or accidental fault (this is on a keychain, so lots of rough tumbles and shakes) would lead to a lot of angry users who set it off by accident, but I am planning a "backup to pc" feature, so it would actually be possible to randomly generate the key and store it with the backup, so if the contents of the drive are erased, the user would be able to restore a backup from a pc....

I'd have to thoroughly test countermeasures like that against false alarms, but totally do-able :D

  Are you sure? yes | no


[this comment has been deleted]

jareklupinski wrote 04/05/2016 at 00:54 point

thanks for the like :) I'm driving the BOM cost down as far as I can, and I'm sending out RFQs to a few injection mold companies. i've never done injection molding, so i have no idea how much that costs yet.

as soon as they come back I'll make an update and give you a figure. but I'll be sure to kitty-test the plastic before I choose it for the case :)

  Are you sure? yes | no

napiorek wrote 11/21/2016 at 14:26 point

Don't bother with moulding, nowadays cost of 3D print of such a small case is affordable.

  Are you sure? yes | no

Sam P wrote 03/16/2016 at 11:41 point

I've been doing some research for my very own password manager and came across the PBKDF2 algorithm which might be useful to you. It runs your password through a hashing algorithm many times to take a reasonably long time to compute. The function also accepts a salt which allows you to use a string to create different passwords for the same pin. In this device the salt could be the website name.

As an example WPA2 WiFi security uses PBKDF2 with 4096 iterations*. For an 8 bit 16MHz microcontroller you would probably need a lot fewer iterations otherwise it would take several minutes to calculate your password. Alternatively you could use a more powerful microcontroller.


  Are you sure? yes | no

Sam P wrote 03/16/2016 at 13:20 point

I've just realised that you're encrypting/decrypting passwords instead of generating them on the fly, so I'm not sure how applicable this would be. It's an interesting read nevertheless :)

  Are you sure? yes | no

jareklupinski wrote 03/16/2016 at 14:01 point

I think this is great, thank you! I'm looking through every possibility, and while the device can (now) generate random passwords too, I'll look into this as an alternative to on-the-fly en/decryption :) I may end up swapping out the atmega for a cortex m0+ once I get more interest in this ;)

  Are you sure? yes | no

Daniel Gilbert wrote 01/04/2015 at 09:57 point

Really like the idea of an independent device for this task. It should be as lightweight as possible, so that you could attach it to your keychain or sth.

Maybe you've already stumbled upon this, but just in case: I really like the "Masterpassword App", and here is it's algorithm described:

  Are you sure? yes | no


[this comment has been deleted]

Daniel Gilbert wrote 01/04/2015 at 22:01 point

Yeah, I encountered a similar problem. I'm looking forward to the finished Password Manager. :)

  Are you sure? yes | no

Dimitris Zervas wrote 12/10/2014 at 05:47 point
How secure is the method you use?
Also, how many passwords can you save?

  Are you sure? yes | no

jareklupinski wrote 12/10/2014 at 07:59 point
I still need to recruit a security researcher to give their stamp of approval and fill in a few blanks. Since the passwords are generated individually using the user as a source of entropy each time, even somehow getting your hands on a dump of the data would not be an issue, as the password is encrypted using the user's PIN. The final algorithm I'll end up using to decrypt the password with the PIN is the last step and arguably the most important. Stay tuned!

Right now i'm only using the Trinket's built in 1KB EEPROM for storing 21 site/user/pass combination entries, but I'm going to be upgrading it to an external I2C EEPROM once I get this proof of concept ready.

  Are you sure? yes | no

Dimitris Zervas wrote 12/12/2014 at 09:35 point
I just wrote an implementation of the xxtea "tiny encryption algorithm".
It needs some security patches, but, I think that it's a good starting point.
Take a look:
It can be used both as encryption dectryption algorythm but also to provide you some more randomness (apart from the entropy).

  Are you sure? yes | no

jareklupinski wrote 12/17/2014 at 04:10 point
Just got back to the lab, it looks interesting! Mind if I incorporate it into the project? I'll give you credit of course :)

  Are you sure? yes | no

Dimitris Zervas wrote 12/24/2014 at 10:14 point

It's under the beerware license, so you can do it whatever you want! :)

I am yet a bit concerned about the security of xxtea. Take a look at RC4, it may be a stream encryption, but I think does a better job than xxtea...

  Are you sure? yes | no

Dimitris Zervas wrote 12/24/2014 at 10:38 point

update: take a look here!

Decrypts AES 256 in 10k cycles (or 5k if you use fast), which means 1/1600 seconds!

If it fits in your MCU, you MUST use AES, it's the best!

  Are you sure? yes | no

PointyOintment wrote 12/05/2014 at 09:37 point
I disagree with your tagline:

Creating and retrieving passwords for all your accounts has never been this easy and convenient!

I use LastPass, which can automatically fill in my username and password and click the "log in" button as soon as I load the site. I don't see how this can be more convenient than that.

  Are you sure? yes | no


[this comment has been deleted]

PointyOintment wrote 12/06/2014 at 02:04 point
Ah, good points. Will this emulate a keyboard, then? And how will you find entries on it (i.e. input a website name to get a password)?

I do like the idea of generating passwords dynamically by selecting from a large random table according to a PIN. I'm not sure about the security implications of that, though.

  Are you sure? yes | no

jareklupinski wrote 12/07/2014 at 23:25 point
Navigation is the secret sauce to this project :) Stay tuned!

Keyboard emulation will be one of the first things I will add after making sure the security of the generated passwords is acceptable for tech folks like us. It is a Trinket Pro after all, so it should be an easy addition.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates