Perhaps trim legacy crypto options in FileSender 3.x

[monkeyiq]

FileSender has options for which "crypto mode" to use which include AES-CBC and modes that do not use PBKDF2 hashing. These are modes 0, 1, and 2. This leaves mode 3 which is AES-GCM with PBKDF2.

Since we have moved FileSender 3.x to the most recent Bootstrap and removed IE11 support. With Edge moving to being Chromium backed we may consider only supporting mode 3 (AES-GCM with PBKDF2) in FileSender 3.x which works across Safari, Edge (Chromium), Firefox and Chrome.

[WebSpider]

Suggestion: Mark 'legacy' as deprecated, and remove it at 4.0

Or: mark is deprecated in 2.x already, and remove it from 3.x before there is a full release in 3.x

[WebSpider]

Can we discuss this in the next planned meeting?

[meijer]

@efef is this something you could take up with your crypto-buddies?

[efef]

In 2019 we had already a discussion about PBKDF2: https://github.com/filesender/filesender/pull/625 "I like Rick's suggestion to use an expectation of security for a number of years from now instead of directly setting the iteration count in the configuration file"

Be aware others say: "PBKDF2 is a bad algorithm because it is slow for the defender and fast for the attacker" and "Better is to move to libsodium.js for file encryption"

[monkeyiq]

At least in FileSender version 3 the default is to use AES-GCM mode. The default in 2.x series has remained AES-CBC because at the time GCM was added some browsers did not behave properly with the AES-GCM setup.

https://github.com/filesender/filesender/blob/45c3e527ea9b799c64aa8272e63210193176b4bb/includes/ConfigDefaults.php#L298

The question then becomes if the crypto versions < 3 should be left in the code itself for the 3.x series or removed. Since the default is version 3 a release of FileSender 3.0 could mention that versions < 3 are explicitly deprecated and will be removed at some point in the future. Perhaps also a log message in the cron job or similar could be made to inform the sys admin that they might like to migrate off deprecated options if their configuration is still specifying them.

[monkeyiq]

This is a bit of a digression but having the option to use some public key crypto (perhaps PGP) would also lift the PBKDF2 or other password hashing issue. Using public key crypto to distribute the AES key would mean there is no need to hash the key as the AES key could just be completely random.

The public key stuff doesn't have to be PGP. I just use it as a common concrete instance of a pk rollout.

[WebSpider]

In most software i encounter these days it is common practise to deprecate an option before removing it, so operators have time to move to the new settings, or keep using the old for their own reasons.

So in line with that, if fs3 has a new default for a setting (in this case, crypto), and we want to clean up code, we should deprecate the setting, and communicate this to operators, at least in docs, maybe also as a warning when running cron and sending aggregatestats.

Various software handle deprecations differently: Some give a timeperiod, other a number of releases, and semver.org says its time to release a new major version when you make backward-incompatible changes.

[efef]

Regarding crypto and what to do, this webpage is a nice overview about crypto (thanks Francois). https://www.latacora.com/blog/2024/07/29/crypto-right-answers-pq/

Based on this webpage it would be wise to move to libsodium (https://doc.libsodium.org/) in the future. Regarding password handling PBKDF2 seems the worst option. I read "In order of preference, use argon2id, scrypt, bcrypt, and PBKDF2 only if FIPS compliance is forcing you"

[WebSpider]

Libsodium has a javascript implementation at https://github.com/jedisct1/libsodium.js

And regarding the ciphers, it seems that argon2id is the new standard indeed, and i dont know scrypt or bcrypt, but i do know that when you put filesender's crypto compatibility ahead a few years from the default, pbkdf2 is getting really slow..

[vanrein]

Be aware others say: "PBKDF2 is a bad algorithm because it is slow for the defender and fast for the attacker" and "Better is to move to libsodium.js for file encryption"

I can't recall if we took that much freedom of choice back then.

I it is not helpful to gaze at the opaque API of libsodium but should consider the algorithms used and compare those.

I am not fond of PBKDF2 either, or of others that may do the job a little better; repeated hashing of a password is in the end just more hashing and CPU-cycle-wasting. Sure, it scrambles the bits a little betterm but it adds no entropy. This means that your security necessarily depends on the quality of the password. A tug war through large numbers of hash operations is indeed a very poor substitute to achieve a decent security level.

No algorithm choice will substitute for low entropy. Same for no API choice.

On the other hand, if your entropy is good there's not much harm done by these algorithms either.

[vanrein]

In most software i encounter these days it is common practise to deprecate an option before removing it, so operators have time to move to the new settings, or keep using the old for their own reasons.

Sounds sensible. The one overriding concern is when the crypto is not sufficiently secure, then you want to remove it abruptly or fix even if that means breaking compatibility. IWO, no mercy to bestowing a false sense of security.

The incompatibility is actually a feature in these cases; it forces insecure admins to look into their aged installs and upgrade them for good/security reasons. This forceful behaviour is not required for security, and not desired for operational reasons, if the crypto is still good but not the latest & greatest.

Usually, cryptographic algorithms start to crumble before they fall apart. This shows by the number of bits, or rounds, that can be reversed through cryptoanalysis.

[vanrein]

This is a bit of a digression but having the option to use some public key crypto (perhaps PGP) would also lift the PBKDF2 or other password hashing issue.

...because it lets you pick a large random session key, solving the entropy problem, and pass that in a secure manner. We discussed this before. A few things happened since.

1. The Client DANE group in IETF let me have my way, and added an X.509 root key in a DNSSSEC-signed domain to sign for the domain's client certificates. Any place you find these will now work, because verification is easy.

2. ARPA2 KIP (Keyful identity Protocol) is een mechanism for pushing a session key to a recipient domain, which then releases the key to a properly authenticated user. There is a data format for KIP Documents holding encrypted content, or referencing it securely.

[WebSpider]

The problem with public key crypto is that someone has to run a PKI to support it. Being able to run it on top of / embedded in something as omnipresent as DNS would be awesome. Oh boy.

Should we find a way to make FileSender encryption use an existing PKI instead of running our own (or each operator running their own), there still is the trust thing. Do we go the TOFU route?

So many aspects to explore on and decide. And could we have our first application of "The Blockchain" here? :rofl:

[monkeyiq]

An initial roll out for the PKI I had in mind was that the FileSender server would be the "someone that has to run a PKI to support it". Trust would be established because a user explicitly uploaded their public key to their profile on the FileSender instance.

In the future we could also allow the FileSender server to find and import from other PKI servers but that would be another option on top. If the server found a key it could then import it with some nod from the user that it was their desired and correct key.

As soon as a person has a public key then all the guests they invite can send to them without exposing the session key to any third party. Any other user on the system can upload to them in the same way. Once a few users on the system are doing this then it has the potential to spread to many many users. A small information link to help folks to see that "one of their colleagues allows upload using this new thing" and then they might like to setup PGP to allow simple sending to them also.

If a similar thing can be done via DNS without the user needing to do anything or do things that are more desirable or easier then great. I look forward to information how we can close the passphrase sharing loop, perhaps with no one size fits all but many ways to do it so the user has informed control.

[monkeyiq]

For the ARPA2 KIP, I imagine that the KIP Service under the recipient's domain might be run by their university or the NREN? I am trying to work out where the random session key might be sent in a real world deployment using ARPA2 KIP with FileSender.

[WebSpider]

The discussion of PKI seems out-of-scope for this issue, which is about trimming crypto options.

Let's move the discussion to another issue?

[monkeyiq]

I think for this the most sense would be to mark this old code deprecated and add warnings to the logs if a site is using it. Maybe introduce a new filesender-check.php to verify the config and allow sys admins to see any messages about things that might need attention.

We could then remove the AES-CBC modes at leisure after a grace period. If people have 12-18 months to update their config.php to new settings (or remove their override and use the pre existing default in 3.0 of AES-GCM+PBKDF2) there will be no surprise and we will not have to maintain an older encryption format indefinitely. The code can hot switch and support older version files in tandem with new ones so the setting can be updated by an admin to the new setting at any time. I added explicit cross version download tests in the test suite at the time.

I would recommend either the filesender-dev mailing list or a github issue on the main filesender project for continued crypto discussions.