Simple encryption software - Security & Cryptography
z3bra
I finally made it to a stable state!
Documentation is still scarce and inaccurate, but at least the base is there and needs polishing: safe.

Here is a quick workflow video: https://p.iotek.org/l55.webm
Doom
The workflow video is dead.
z3bra
Well the workflow changed already as the soft is under heavy dev :)
tudurom
You might have a buffer overflow:

[Image: MWQ85PMpHvcY_08.png]

The n-bytes passed to strncat must also include the null byte!
z3bra
Indeed, thank for pointing it out. Not a big issue though as both SOCKDIR and SOCKET are fixed strings, and they can hardly fill up PATH_MAX.

Still a bug though, that must be fixed.
Doom
(25-05-2019, 02:31 AM)z3bra Wrote: Well the workflow changed already as the soft is under heavy dev :)

Hah! I'm saying the video file you linked is literally corrupted. Unless that was the point?
z3bra
I first posted the vid over p.iotek.org to share on IRC, that wasn't meant to last long.
I didn't bother reuploading it somewhere else, and now it's gone unfortunately... Sorry about that.

I said that because now I cannot record this vid again as the code change so much it doesn't work the same ^^

I'm still looking for ideas on how it should work thougg
z3bra
Ok guys, so this project is going forward, and now I would need some input from other people to make it as good as possible!

Here's the idea. The password manager works by storing secrets as encrypted files on disk.
When you store a secret, you'll be prompted for your master password. This password is used to derivate a secret key, along with a random salt (that MUST be stored in some ways.
Once the key is obtained, it is used to encrypt whatever comes on <stdin> and write the encrypted stream in a file named after your entry.

This solution presents 2 problems:

1. The salt is so important that we must store it, thus putting a hard dependency on these few bytes
2. Upon encryption, the password is not verified, so we could end up with secrets encrypted from different passwords

I need to find a simple way to fix these issues, but I'm not sure how.
My first idea is that the master password is just a password like any other, so I can store it within the safe, say under an hardcoded name like "MASTER", ".lock", whatever.
Then before storing a secret, I would check that the password hash match the one from the store.

The salt could also be prepended to this "master" file, for easy retrieval. This would then set the workflow as follow:

1. User wants to store a secret, prompt for the master password
2. Read salt from the MASTER password file (first x bytes of the file)
3. Derivate key from password + salt
4. Try to decrypt the MASTER password file using the key
5. Store the secret, encrypted using the previously derived key

If the MASTER password file cannot be decrypted, then the program will refuse to store the secret.

This would require the user to initialise the store beforehand though, by providing the master password, to generate the first salt.
Something seems fishy to me with this worflow, but I cannot put my finger on it... If anyone has a comment, idea, or whatever, everything is welcome!
Halfwit
With the `secstore` on plan9, you lock files into a vault of sorts. It works in tandem with the `factotum` agent, which handles all authorization on behalf of the user, and secstore. You can't directly touch any files contained within*, but you can request a file, and push a file into the store. There is a lot of crossover, but the intriguing part comes from how they've separated the password management from the store, meaning that for a chicken and egg problem, you can create a password well before the store is ever created.

I use this for a few things, but mostly it works with the aforementioned factotum, which requests a list of all stored passwords from the secstore, so my session I rarely ever have to type in a password. And it's always, in every case, just my master password for factotum.
Halfwit
Oh right! "DO NOT store secrets in memory" --> this method uses an rpc through a tightly namespaced socket (well, it's plan9 so it's just a file read/write) from the factotum to the client program, actually in many cases to the remote service proper without the client itself even seeing the password




Members  |  Stats  |  Night Mode