FSMaxB @FSMaxB@mastodon.cloud

@Mikescops @fribbledom Yes, current state of the art for password based key derivation is argon2id. This is because PBKDF2 with SHA256 in this case is very weak against FPGAs, GPUs and ASICs. Argon2id makes RAM the bottleneck for bruteforcing thereby increasing the cost thereof by many orders of magnitude.

@alva Interesting how similar Swedish and German are sometimes. The German word would be "Hexe".

@fribbledom @alva experienced something similar I think

@fdroidorg Is there ans way to help make the update process faster? Like help paying for new build Servers or whatever?

@fdroidorg Great, now I have to:
1. Export the database from Newpipe
2. Uninstall the version from GitHub
3. Install the version from F-Droid
4. Reimport the database

@zatnosk @fribbledom Ok, I think I see what you mean. The people I follow can post whatever they want (in certain bounds of course, there's a probably a point where every admin will kick you and having your own instance there is a point where the state would intervebe). And you still have the public and federated timelines.

@fribbledom Until you've created a new one over time? I mean following certain people and not following others sounds like a filter bubble to me.

(Same goes for RSS news feeds for example)

Today's tip: Don't partition already partitioned data using the same hash function that it has already been partitioned with.

Or: Application specific keys for hash functions are there for a reason, don't use the same for different applications.

@alva that might actually be a really bad idea since shuffle most likely doesn't use cryptographically secure random numbers.
They are most likely time based which significantly decreases the ranges of numbers to brute force.

@alva Oh ok, haven't thought ablut that so far. But should be doable by combinig the wordlists together.

@alva https://fsmaxb.github.io/correcthorsebatterystaple/

Although the word lists are kind of suboptimal.

@alva it allows editing the staging area directly

@alva I recommend vim-fugitive

Key takeaway: Consider your /etc/shadow to be containing essentially plain text passwords.

-> Don't reuse Linux login passwords for anything else
-> Encrypt your system partition (and be sure to configure a sensible key derivation function when setting it up using cryptsetup, I don't think they use sensible defaults yet. In other words: Tell cryptsetup to use Argon2id and optimise --iter-time and --pbkdf-* to be as slow and memory consuming as acceptable)

OMG, why can't we have nice things. Just found out that passwords in /etc/shadow are hashed using SHA-512 by default (which is the least bad option ...) but only 5000 rounds by default (not that more rounds would make it significantly more resistant against brute force in any case).

Today: Have you ever looked at the semantics of "round" in your programming language. Look at JavaScript and Python for example.

The biggest unsolved problems of applied computer science:
* floating point numbers
* date/time
* text