These are public posts tagged with #argon2id. You can interact with them if you have an account anywhere in the fediverse.
New version of #hashgen published.
Changelog:
v1.1.0; 2025-03-19
added modes: #base58, #argon2id, #bcrypt w/custom cost factor
https://forum.hashpwn.net/post/89
#hashgenerator #hashcracking #hashcat #hashpwn #cyclone #golang
title ... — как зовётся в меню загрузочном
linux /vmlinuz-6.6-x86_64 — какое ядро ОС использовать
initrd /intel-ucode.img — какой микрокод процессора грузить
initrd /initramfs-6.6-x86_64.img — сам загрузочный образ
...
options quiet — могут быть и в одну строчку все сразу
options splash
options rd.udev.log_level=3
options systemd.show_status=auto
options sysrq_always_enabled=1
options intel_iommu=on
options iommu=pt
...
обновления системы на базе снапшотов #btrfs
с полнодисковым шифрованием диска через #LUKS
загрузкой через #systemd-boot (поскольку #GRUB плохо поддерживает LUKS)
Thank you for sounding the alert!
I identified a minor issue with your otherwise nice explanation: According to my sources (man cryptsetup, #rfc9106), all #argon2 varieties are memory-hard. RFC 9106 is even titled “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications”.
However, given that there are known attacks against #argon2i, it seems wise to use #argon2id instead. It is also what is recommended in the RFC.
As a #QubesOS user, I just checked the state of affairs there:
The cryptsetup that comes with QubesOS 3.x still used #luks1, and those who did an in-place upgrade to 4.x still have that unless they converted to #luks2 manually (as detailed in the migration guide).
The cryptsetup in QubesOS 4.x uses #luks2, but it still defaults to #argon2i unfortunately.
KeePassXC 2.6.3 Password Manager Adds Support for Argon2id KDF and XMLv2 Key Files