thudson
Joined 15 years ago
Karma
312
Submissions
29
Member since
Oct 24
Recent submissions
Comment · 5 years ago
If you want to play mental poker with an arbitrary number of friends/enemies, I built a prototype with a really basic UI that extends the SRA81 protocol to support more than two players and that also removes the need to reveal the hands at the end of the game. https://secret.cards/
Comment · 5 years ago
Similar higher-than-rated-bandwidth can be achieved on the TRS-80 Model 100, which uses an array of 10 HD44102 controllers. With an FPGA it is possible to draw full motion video on the LCD: https://twitter.com/qrs/status/1092410264316653568
Comment · 5 years ago
The WEH001602A is pin compatible to the HD44780, with OLED output instead of LCD. In 8-bit parallel mode with an FPGA you can exceed the recommended clock rate to drive quite a bit of data into the displays: https://twitter.com/qrs/status/1088240598971310081
Comment · 5 years ago
A few years ago I built an adapter to allow classic Mac CRT's to be used with BeagleBone or Raspberry Pi systems ( https://trmm.net/Mac-SE_video). X11 has supported 1-bit mono displays since forever, so it mostly worked out of the box with well written programs.
Watching youtube videos in 1-bit is an amazing aesthetic. Unfortunately all of my videos of it were on vine, so this Muybridge-esque cat video seems to be the only one that I cross-posted to twitter: https://twitter.com/qrs/status/1045272076750401536
Comment · 5 years ago
12-eights for "microns turnabouts Como migraines": 9a7e6f41875b444851cb19f018cea83e6565762d88888888888813ac47d39ce7
Although I'm also a fan of "Georgetown surfboarded rips nodding", which hashes to the very pleasant 01234567894a7924a0a568c01ae2f48f93921fc9b4437d7866db3be132411b08
Comment · 6 years ago
If you want to more easily configure UEFI Secure Boot on your Linux system, while also registering your own signing keys to eliminate the Microsoft and OEM ones: https://safeboot.dev/
Comment · 6 years ago
The CD-ROM is now on archive.org: https://archive.org/details/hugo_nebula_1993
Brad Templeton wrote about it: "I believe this CD is now a piece of history, as the world's first major eBook project using current fiction. At the time it was the largest anthology of current fiction ever published in one volume, and it may retain that title even today. Prior ventures were small or featured either unpublished writers or public domain works. This anthology featured novels that in most cases had not yet come out in paperback."
Comment · 6 years ago
In practice it is a bit of a pain during the initial setup and package installation -- I was probably rebooting to recovery mode once a day or more to install some command line tool that I had forgotten about. Once the machine is configured then it is a more rare occurrence, although your usage might vary.
Something that I'm not happy about is that the snaps all live on the writable /var since they want to do automatic updates all the time. This is problematic for a locked-down configuration and might recommend against a snap based distribution.
Separating out the bootable bits from the rest of the packages might help, as would running more things in sandboxes. Another option that we're exploring is some lvm magic to create a snapshot, upgrade the snapshot, sign it, and then on the next reboot use it as the real root. This is also useful for fleet management -- the new root filesystem, kernel, initrd, etc can arrive "behind the scenes" and on the next reboot is the one that is used. Since the PCRs can be predicated as well, the PCR policy can be signed and sent along with the upgrade to make it seamless.
Comment · 6 years ago
If you want LUKS encryption with signed policies to prevent brittle PCRs, rollback prevention with monotonic counters, and user pin to prevent dictionary attacks, plus TPM sealed TOTP to attest to the state of the firmware: https://safeboot.dev/
Comment · 6 years ago
The TPM is not a DRM enforcement mechanism if you set it up for your own use. It is a very useful tool for taking control of machine that you own - it provides a way to prove* to yourself that the system booting with the firmware that you've approved, in the configuration that you setup, and running the kernel and initrd that you've signed. https://safeboot.dev/attestation/#i-thought-remote-attestati...
*: Depending on your threat model and risks, some of which are discussed here https://safeboot.dev/threats/
Comment · 6 years ago
Some forms of TPM tampering are explicitly addressed in the threat model:
> The PCR values in the TPM are not "secret", so an adversary with physical access could directly wire to the TPM and provide it with the correct measurements to extend the PCRs to match the signed values. The user PIN is still necessary to unseal the secret and the TPM dictionary attack protections both rate-limit and retry-limit the attacker.
Decaping chips to recover secrets is outside of the threat model, however.
Comment · 6 years ago
A separate bootloader and key on USB does not protect against many physical attacks, nor ones that involve changing the firmware or nvram configuration through software attacks. Without some sort of sealed keys or attestation of the platform configuration, your external bootloader has no guarantees that the device itself has not been backdoored. mjg59's tpm-totp talk[1] discussed the difficulty of trusting the firmware that loaded the bootloader that loaded the kernel that is now asking for your password (although even with that it is necessary to add integrity protections on the encrypted disk, otherwise there are a variety of attacks against the systems).
Secure Boot is trustable, if you remove the vendor keys and reprogram the platform key with one under your own control. Likewise, the TPM is useful for protecting your secrets, not just enforcing DRM, if you take ownership of it and make use of the sealed key policies. See the safeboot.dev threat model[2] for how these protections are applied and how they detect or prevent many sorts of attacks.
1: https://mjg59.dreamwidth.org/35742.html 2: https://safeboot.dev/threats/
Comment · 6 years ago
This NSA report is a wonderfully thorough guide to configuring UEFI Secure Boot, although it is another example of how unusable security tools can be. This conplexity was my motivation for writing the safeboot[1] scripts, which wrap all of the signing key management, TPM key sealing, and attestation into a hopefully easier to use package.