2 ms·

Without a complete read of the code (I wish they wrote up the protocol, not having one is a huge red flag, so instead I'll just risk being wrong on the internet

Without a complete read of the code (I wish they wrote up the protocol, not having one is a huge red flag, so instead I'll just risk being wrong on the internet), this seems like a straightforward KDF where instead of storing a master key in an HSM, you just remember your master passphrase and each new password is a diversification component. Typically, a protocol like this would have the master key in a vault/hsm, and your first user key would be derived from that master, and you do derivations from that, and when you need a new identity, you derive a new user key from the vault key. Concievably, we could replace the vault with hashes of just really long passphrases that you remember and generate on some trusted interface, and then derive new RP site passwords from the hash of each long passphrase. Mnemonic password storage essentially. What you would usually do is include a counter in the authN protocol, so each instance of the session password going over the wire has forward secrecy, but that requires your relying parties to speak that protocol, where the proposal here is just for password management. I'm sure the people behind this are very competent and clever, but again, the problem it solves and how it solves it would be more useful than a command line UX and "trust us!" What I can't stand about security and some crypto people is they challenge people to reason about something without providing the objective details of a protocol, and then expect us to trust them when we can't reason about it as effectively. I'm merely ignorant, not stupid, and asking me to trust something because I can't reason about it borders on offensive sometimes.

onionisafruit 4y ago
Another good reason for a protocol is that there are limited places where you can run this cli. If I started using this and later needed to access a password from my phone, I would have a lot of hoops to jump through. On second thought, maybe the fact that this only has a command line interface is a good indicator that it isn’t meant to be what I think of as a password manager.
drdaeman 4y ago
I've skimmed through the source code, so I'll save y'all some time. It's all based on a PRNG, which is based on an AES-256 in CTR mode (making it a stream cipher) seeded with a key generated by 4096 iterations of PBKDF2-SHA256. PRNG just decrypts a stream of zeroes with a KDF-generated key. All standard library algorithms, nothing custom. To generate a password, it builds an alphabet, picks a random character from it by reading a byte from the PRNG. It is looping until it reads a byte is less than `255 - (255 % max)` where `max` is length of the alphabet, then returns `b / (255 / max)` where `b` is the byte from the RNG. Basically, dividing [0-254] range (255 is never accepted) into equal-length `max` pieces and figuring out where it falls. The generated password is checked for compliance (i.e. that randomness had produced a special character, etc.) and returned if it's good, otherwise it loops and tries to generate a password again. Given that RNG is fully deterministic, this produces consistent results. I haven't bothered looking into keypair generation - I just woke up, sipping on my "morning" coffee as I'm typing this, so I'm kinda lazy.

onionisafruit 4y ago

Another good reason for a protocol is that there are limited places where you can run this cli. If I started using this and later needed to access a password from my phone, I would have a lot of hoops to jump through. On second thought, maybe the fact that this only has a command line interface is a good indicator that it isn’t meant to be what I think of as a password manager.

drdaeman 4y ago

I've skimmed through the source code, so I'll save y'all some time. It's all based on a PRNG, which is based on an AES-256 in CTR mode (making it a stream cipher) seeded with a key generated by 4096 iterations of PBKDF2-SHA256. PRNG just decrypts a stream of zeroes with a KDF-generated key. All standard library algorithms, nothing custom. To generate a password, it builds an alphabet, picks a random character from it by reading a byte from the PRNG. It is looping until it reads a byte is less than `255 - (255 % max)` where `max` is length of the alphabet, then returns `b / (255 / max)` where `b` is the byte from the RNG. Basically, dividing [0-254] range (255 is never accepted) into equal-length `max` pieces and figuring out where it falls. The generated password is checked for compliance (i.e. that randomness had produced a special character, etc.) and returned if it's good, otherwise it loops and tries to generate a password again. Given that RNG is fully deterministic, this produces consistent results. I haven't bothered looking into keypair generation - I just woke up, sipping on my "morning" coffee as I'm typing this, so I'm kinda lazy.