Replaced the encryption with age

[raphaelahrens]

The old encryption protocol has some flaws.

In this commit the encryption is replaced by the age library.

[raphaelahrens]

BTW this is about #35

What is currently missing is how to deal with old encrypted files.
Maybe an alternative tool to decrypt the old files?
maybe it would also be a good idea to have some form of version header, so that this issue does not come up with future changes.

Further could this change also fix #63.
I also found an issue if you run

tuckr encrypt g1 ~/first.txt
tuckr encrypt g1 ~/second.txt

It is possible to use different passwords for the same group (g1).

This later is an issue when running

tuckr decrypt g1

Since there you can only give one password and this just fails as soon as the password was wrong.
I have not tested this with the old code.

[RaphGL]

What is currently missing is how to deal with old encrypted files.
Maybe an alternative tool to decrypt the old files?
maybe it would also be a good idea to have some form of version header, so that this issue does not come up with future changes.

Yeah, having a header and a tool to port over would be great. We could also provide a single release warning when people attempt to use secrets asking them to port over and maybe provide a link to the tool.

It is possible to use different passwords for the same group (g1).

Yeah, secrets is not as developed as the other parts. Symlinks have been consuming most of my time on the project. If you feel like trying to tackle it feel free to do so, otherwise just create an issue and me or someone else will handle it later.

[RaphGL]

You forgot to remove chacha20poly1305 and sha2 as dependencies

[RaphGL]

by the way, just as a heads up, don't worry too much about internationalization for now.
I'll go over every output string in the program and make sure it's translated properly before I ship the next tagged release

[RaphGL]

By the way I haven't attempted to merge your PR because you have it marked as a draft. But there doesn't seem to be any work going on in this. Should I merge?

[raphaelahrens]

Sorry, I got a bit distracted.😅

The main reason for it being a draft is that there are the questions on

• how to deal with backwards compatibility and
• how to handle the password mishandling.

If you want/can finish it, that is fine with me.
If you want me to do it just say so.

[RaphGL]

I'm fine with it either way tbh. But if you want me to do it it's gonna be a while before it's all implemented, since I wanna improve the symlink handling first and I'm working on the filetree-refactor so I can try and fix the longest standing issues in the project.

[raphaelahrens]

Ok, I have thought about the PR a bit. (sorry for taking so long, my priorities for this PR are a abit low.)

So I would propose the following change to the current system.

First an encryption group should get its own config file.
So when encrypting with tuckr encrypt g1 ~/first.txt the group g1 should get a file in the repo.
This config file will be encrypted with the passphrase.
This has the advantages that we can test the encryption passphrase against all other calls oftuckr encrypt g1 <file> and not have the issue that one file is encrypted with another passphrase.

Further can the name of the file be hidden by using $path_to_file/base64(HMAC(group_secret, reatl_target_path)).secret and the group secret can be stored in the group file.
It would also be possible to use different encryptions per file, so encryption scheme changes would less painful.

So the question would be where to store the group files?
What format would you prefer for the group files?
Do you see any problem with this approach?

[RaphGL]

sorry for taking so long, my priorities for this PR are a abit low

Encryption is also a low priority for me right now, as the core functionality is deploying dotfiles and that still needs some ironing out here and there, so take your time

This config file will be encrypted with the passphrase.
This has the advantages that we can test the encryption passphrase against all other calls of tuckr encrypt g1 and not have the issue that one file is encrypted with another passphrase.

what happens if the user deletes this config file? Maybe using any one encrypted file in secrets would yield the same result and still enforce the same password per group and if a file is deleted as long as another is there the enforcement of same password per group can still be done.

Further can the name of the file be hidden by using $path_to_file/base64(HMAC(group_secret, reatl_target_path)).secret and the group secret can be stored in the group file.

Yeah this makes sense, but HMAC is only a hash so how would we know what the name of the file will be once decrypted? When you do tuckr decrypt x it will need to be able to compute the destination path, with this method I think the file would have to exist prior to being replaced by the decrypted one so tuckr could compare hashes.

So the question would be where to store the group files?
What format would you prefer for the group files?

Not sure if I understood correctly. If you're asking what location in the dotfiles, they're still supposed to be in Secrets and separated by group directories.
I don't care too much about what format those groups use or what file structure it follows. The user would never be working directly with it either way.

[raphaelahrens]

The the decrypted group file could look something simple like this.

group_name=g1
group_secret = grAO2k8ryiPheXXhBe2Y+tPA92FbcuFLl4WmDLX


v1 ./destnation_path/of/secret.conf
v1 ./other/path/to/file.txt

When you call tuckr encrypt g1 ./path/to/new_file.json the following line would be added.

v1 ./path/to/new_file.json

This requires a decrypt of the old group file, adding the new line and encrypting the now new file contents and a replace of the old file.

For the file /path/to/new_file.json the following would happen, first we read the config file, then encrypt it using the passphrase copy the encrypted config to dotfiles/Secrets/g1/$(base64(HMAC("grAO2k8ryiPheXXhBe2Y+tPA92FbcuFLl4WmDLX", "./path/to/new_file.json"))

The advantage of the group file would be that you can change how files are encrypted without changing how the group file is encrypted.
Further would it allow you to hide the name of the config files, via HMAC.
BTW the group secret is something other than the passphrase, so it allows you store this as well.
The group secret is necessary to not have a potential HMAC leak of the pass phrase.
Since HMAC(passphrase, file_name) could be used to find the passphrase via a dictionary of passphrases and config file names.

[raphaelahrens]

About the path of the group file.
The question was where would I store the group file of g1, not the config files in the group.

[raphaelahrens]

About deleting a config file, that is a good point, I need to think about that.

[RaphGL]

I'm guessing v1 is the versioning of the encryption tuckr will use for this group so that we can retain backwards compatibility in the future?

For the format itself, since the config will be inside a group directory I think we can get rid of group_name, group_secret can just be named secret and we can infer the group name, this also allows people to just rename the directory and is consistent with how the program works everywhere else.

For the config being deleted, if we could detect the encryption used by each file we could just attempt to read the config but if it's absent we could attempt to restore it and check that all the files still use the same algo? Not sure if that's a good strategy or not.

[ThomasAdam]

I wonder if we could use hooks support to use the age(1) binary (or similar) to provide this functionality instead? This has the added advantage that a user could use any password management system to provide this functionality, independent of this project.

Does this make sense? Apologies if this has come up before in a separate thread.

[RaphGL]

I wonder if we could use hooks support to use the age(1) binary (or similar) to provide this functionality instead? This has the added advantage that a user could use any password management system to provide this functionality, independent of this project.

You can already use hooks to do whatever you like. I've thought about removing secrets altogether and just letting people use hooks to deploy their own secrets but never been compelled enough to remove the implementation we have already, so it's just sitting there until we ever rework it or I remove it.

[ThomasAdam]

I wonder if we could use hooks support to use the age(1) binary (or similar) to provide this functionality instead? This has the added advantage that a user could use any password management system to provide this functionality, independent of this project.

You can already use hooks to do whatever you like. I've thought about removing secrets altogether and just letting people use hooks to deploy their own secrets but never been compelled enough to remove the implementation we have already, so it's just sitting there until we ever rework it or I remove it.

Indeed -- it's a difficult one to call. There's pros and cons to both. I can't (and wouldn't) suggest which one is better. This is your project, after all...

[RaphGL]

I tend to just let things sit for a while before I make a decision. It has worked well for me. I'm not actively working on the secrets stuff because there's still work to do to make the core functionality (managing dotfiles) easier. So I just haven't touched this.

But once I get around to it, I'll choose what to do. I don't even use secrets myself. So unless there's interest in this, this might end up getting the axe in the future.

[ThomasAdam]

But once I get around to it, I'll choose what to do. I don't even use secrets myself. So unless there's interest in this, this might end up getting the axe in the future.

Sure. I can understand this. I can also appreciate how this looked bed.