nixers
Simple encryption software - Printable Version
+- nixers (https://nixers.net)
+-- Forum: Operating Systems (https://nixers.net/forumdisplay.php?fid=4)
+--- Forum: Security & Cryptography (https://nixers.net/forumdisplay.php?fid=27)
+--- Thread: Simple encryption software (/showthread.php?tid=2260)


Simple encryption software - z3bra - 05-04-2019

Hello fellow crypto friends!

I need your help on a small piece of software I'm working on: safe.

It is a pass(1)-like application used to store passwords, but I want to drop usage of asymmetric keys and use only a master password instead (ie. symmetric encryption), so all I need to do to unlock my password store is a master password.

There is one neat feature that I like with gpg though: gpg-agent. I would like to have something similar with my master password approach, so I don't have to type my password every time I want to encrypt/decrypt a password.

I know that there are multiple security implications with it, but I'm no security expert, so I would like your input/advice on this topic.

From the top of my head, here are the security concerns I should have:
  • DO NOT store master password in memory --> sha256() it
  • DO NOT store secrets in memory --> ???? I don't think I can avoid that. At least I can store smaller "chunks" for in/output
  • NEVER keep decrypted secrets in memory --> memset() the secrets address after usage
  • NEVER write decrypted secrets anywhere --> output to stdout only

What should I add to this list? Are there things I should change?

BONUS QUESTION:
Do you guys understand how the "encrypt(3)" function from unistd.h works (don't judge me) ?
It seems to take a 64bits message and return the 64bits equivalent, encrypted. Which means that my encrypted message will have the same size as the ciphertext... I'm not security expert, but it looks like a security issue right?

Answering my own question from the man page:

Quote:Because they employ the DES block cipher, which is no longer considered secure, crypt(), crypt_r(), setkey(), and setkey_r() were removed in glibc 2.28. Applications should switch to a modern cryptography library, such as libgcrypt.

Thanks for your help!


RE: Simple encryption software - z3bra - 11-04-2019

No ideas? c'mon guys...


RE: Simple encryption software - venam - 11-04-2019

(05-04-2019, 09:00 AM)z3bra Wrote: I know that there are multiple security implications with it, but I'm no security expert, so I would like your input/advice on this topic.

A good idea is to use block chains that will have a MAC that chains up after each passwords and maybe could be used as the next IV.
Also, why not take into account checksums in your password DB, making sure everything hasn't been tampered with.


RE: Simple encryption software - z3bra - 12-04-2019

Checksums are taken into account, as I plan to store secrets on disk by their hash, so if your secret has been tempered with, you won't find it anymore as it's filename will have changed (and I'll verify the hash after reading ofc)

Thus block chain stuff you describe seems complicated. Can it be implemented easily and without too much effort?


RE: Simple encryption software - venam - 12-04-2019

(12-04-2019, 05:49 AM)z3bra Wrote: Thus block chain stuff you describe seems complicated. Can it be implemented easily and without too much effort?
You can rely on the crypto library you are using to do the heavy lifting. It's probably just some parameter that you give to AES.
My idea is that you should probably chain the values so that chunks in memory can't be decrypted by themselves alone. However, that's going to be more expensive as you'll need to pass through the blocks to get to the required value.
https://en.wikipedia.org/wiki/CBC-MAC


RE: Simple encryption software - zge - 12-04-2019

(05-04-2019, 09:00 AM)z3bra Wrote: but I want to drop usage of asymmetric keys and use only a master password instead (ie. symmetric encryption), so all I need to do to unlock my password store is a master password.

Why?


RE: Simple encryption software - z3bra - 12-04-2019

This is more portable IMO, as you don't have to carry your key with you everywhere.
My target goal is to make it a sort of "online" pass manager accessible from everywhere, assuming you have an internet connection.
I know it can be less secure than pgp key, but I prefer simplicity over added security here.


RE: Simple encryption software - z3bra - 19-04-2019

(12-04-2019, 05:54 AM)venam Wrote:
(12-04-2019, 05:49 AM)z3bra Wrote: Thus block chain stuff you describe seems complicated. Can it be implemented easily and without too much effort?
You can rely on the crypto library you are using to do the heavy lifting. It's probably just some parameter that you give to AES.
My idea is that you should probably chain the values so that chunks in memory can't be decrypted by themselves alone. However, that's going to be more expensive as you'll need to pass through the blocks to get to the required value.
https://en.wikipedia.org/wiki/CBC-MAC

This looks interresting indeed, I like the idea that chunks of memory can't be decrypted alone. It could be problematic on small devices though, or when you have "big secrets" (namely, big data to encrypt in your safe).
Even if I don't use that yet, I'll probably think about it when designing the tool so it can be added later.

Which library would you use btw, for simple encryption? I tried to lookup libressl, but I couldn't find any documentation about using it for simple use cases (typically, take a string as input, another string as a key, and produce an encrypted output).
Any pointers?


RE: Simple encryption software - tudurom - 19-04-2019

https://libsodium.gitbook.io/doc/ try this one


RE: Simple encryption software - z3bra - 20-04-2019

This looks pretty simple indeed. I was looking at NaCl before but it's less portable it seems.
What bother me is all those *_easy() functions... When you end up with this kind of functions, it could be a bad API.

I'll start with it anyway :)