feat: salted hashing

[cmdoret]

Proposed Changes

• Adds a --secret CLI arg to provide a file with encryption key or hashing salt.
• Reduce implementation surface for the Pseudonymize to a single method (pseudo(bytes) -> String).
• helper function to instantiate hasher based on algorithm and key, with support for default settings.

Types of Changes

What types of changes does your code introduce? Put an x in the boxes that
apply

• A bug fix (non-breaking change which fixes an issue).
• A new feature (non-breaking change which adds functionality).
• A breaking change (fix or feature that would cause existing
  functionality to not work as expected).
• A non-productive update (documentation, tooling, etc. if none of the
  other choices apply).

Checklist

Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask. We're here to
help! This is simply a reminder of what we are going to look for before merging
your code.

• I have read the
  CONTRIBUTING
  guidelines.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added the necessary documentation (if appropriate).

Further Comments

[cmdoret]

Example use:

➜ tripsu pseudo -s secret.txt -c tests/data/config.yaml -x tests/data/type_map.nt tests/data/test.nt | tail -n3
<http://example.org/7c73d8167447e118ee76295f252e9ceeb48ae3cbfa0454572381796f0e7a8e2c> <http://schema.org/name> "f4446c44c9b6e221e94a40476322dab5123514c5669092a142057a3322329c09" .
<http://example.org/Bank> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Organization> .
<http://example.org/Bank> <http://schema.org/name> "Bank" .

➜ tripsu pseudo -c tests/data/config.yaml -x tests/data/type_map.nt tests/data/test.nt | tail -n3 
<http://example.org/e72357361fec5fc2f653642e6a1016040aa79097ab123468f3f7873907211d26> <http://schema.org/name> "f4aab5970bf4589ea821964476f10ddcef7b2a42a4796954f5cb32426bc5ec55" .
<http://example.org/Bank> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Organization> .
<http://example.org/Bank> <http://schema.org/name> "Bank" .

[cmdoret]

Took your points into account and added tests + docstrings!

[cmdoret]

Just realized something: if we plan to support asymmetric encryption, wouldn't --secret be the public key? That sounds a bit unintuitive

[marftn]

Just realized something: if we plan to support asymmetric encryption, wouldn't --secret be the public key? That sounds a bit unintuitive

For this, I think we should just change the behavior of tripsu when asymmetric encryption is used and require --public-key or something similar instead of --secret. However, I suggest that we do it only if one day we have a good reason to support asymmetric encryption.

It does not really make sense to me to support it for the following reasons:

• Speed: asymmetric encryption requires more computational power and is much slower for data stream encryption.
• Purpose: the goal of tripsu is to remove some information before sending the data, not to securely transfer it. The benefit of using asymmetric encryption is, in general, that you can send sensitive data in a non-trusted channel. For tripsu, we want to make sure that only the sender can decrypt the data, that's why we use either hash functions or symmetric encryption without sharing the key. If the data sender is the only one that encrypts and decrypts the data, there is no benefits of using asymmetric encryption.

tldr; I wouldn't worry about this for now 😁