Progress report 1

• I’m ruling out HMAC-SHA1, because:
  • Plain vanilla HMAC-SHA1 uses a shared secret. I don’t want the PC/server to have a copy of the credential. May also be susceptible to MITM/relay attacks.
  • Rolling-code HMAC-SHA1 only partially solves those problems.
  • Encrypted rolling code HMAC-SHA1 solves those problems, but I haven’t found a reliable source for using it with LUKS.
• If using systemd, pick FIDO2:
  • Avoids flaws of HMAC-SHA1.
  • Native support in systemd, so “future-proof”.
  • Wider support than OpenPGP. More HST vendors to choose from, including cheaper options than NitroKey or Yubikey: useful if each sysadmin (or colleague, or relative) needs an HST.
  • Compatible with QubesOS.
• Otherwise, OpenPGP:
  • Like FIDO2, solves HMAC-SHA1 flaws.
  • However:
    • smartcard-key-luks seems unmaintained on GitHub and on GitLab.
    • LUKS with OpenPGP isn’t well-documented for non-Debian-based distros.
• TBD: Clevis/Tang:
  • Remote/network-based unlocking.

Thank you for this! That thread is helpful in itself, and also links to other relevant resources - including by Lennart Poettering (controversial guy, but the canonical source on systemd).

This coverage has a better headline: Trump blames Minnesota governor for cyberattacks against the state. Cites no evidence.

Funding restrictions and denialism, plus starting a war against a cyberattack-capable nation, made infrastructure attacks inevitable.

Security researchers have been publicly raising the alarm about SCADA vulnerabilities for 20+ years.

I read them before writing my OP. I’m still not sure what you’re getting at.

I would be grateful if you could say what you mean, instead of initiating an oblique guessing game.

Which of the 4 recipes I posted are you referring to as “this”?

For plain text & Markdown, you don’t even need Collabora. Since 2019, NextCloud has a built-in collaborative text editor.

it’s the only way!

TBF I was trying to follow the docs, aber ich spreche kein Deutsch.

I overlooked this line from the docs:

Benötigt werden cmake, git, libgd und libusb - bei manchen Distributionen (z.B. Ubuntu) sind die Header-Files in separaten Paketen “libusb-dev” die ggf. noch nachinstalliert werden müssen.

I should have done sudo apt install libgd-dev libusb-1.0-0-dev before attempting compilation.

@GrapheneOS@grapheneos.social

It would be trivially detected by widely distributed standard forensic software including the non-Premium variant of Cellebrite able to run on a laptop.

By “duress profile”, I mean that if user has enabled a “duress profile” feature in Settings, then entering the duress PIN would:

1. Erase (the encryption key for) all profiles and storage outside the duress profile; then
2. Unlock the duress profile.

So, how would forensic software detect that the unlocked profile is a duress profile?

@GrapheneOS@grapheneos.social everyone seems to be clamouring for the same thing: add “duress profile” to the roadmap. Keep up the good work.