Earlier quoted context omitted.
The Wren language[0] uses semicolons as its size metric: Wren is small. The VM implementation is under 4,000 semicolons. You can skim the whole thing in an afternoon. It’s small, but not dense. It is readable and lovingly-commented. [0] https://wren.io/
Semicolons seems an odd metric since complexity is often introduced by if-else branches, while loops, and function declarations. Each of those doesn't involve semicolons.
TinySSH is a small SSH server using NaCl, TweetNaCl
121–128 of 128 posts
Re: TinySSH is a small SSH server using NaCl, TweetNaCl
#122Earlier quoted context omitted.
This is mostly me but the case that's the most common is that a disk can't be wiped because its dead. Gotta do that before hand.
Well you can always drill holes in the platter, or hit them with a strong magnet, or just separate them and toss them in the trash. Unless you're fighting the NSA, you can probably get away with enough physical destruction to make recovery challenging.
Re: TinySSH is a small SSH server using NaCl, TweetNaCl
#123It looks like a good choice for access to small embedded devices. Except the missing port forwarding feature.
Re: TinySSH is a small SSH server using NaCl, TweetNaCl
#124Re: TinySSH is a small SSH server using NaCl, TweetNaCl
#125Earlier quoted context omitted.
Isn’t there a host SSH key involved? The server itself may have been physically breached, and if so you can’t trust anything. But, if your host key matches, you should be confident that at least you’re logging into the correct machine (there was no IP takeover).
If the server was breached, what stops somebody from copying the host key to their new system.
(Without a physical breach... if that happens, all bets are off).
Re: TinySSH is a small SSH server using NaCl, TweetNaCl
#126Earlier quoted context omitted.
Question: when remotely unlock the boot disk via ssh, how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys? At some point I wanted to do something with utrablue [1], to work over network rather than Bluetooth, but then it was in go and I got lazy suddenly :) [1] https://github.com/ANSSI-FR/ultrablue
What are the best options to solve this problem? It’s a hard problem imho for most threat models. If the booting machine has been compromised and i use my usb connected keyboard to enter the full disk encryption key I would run into the exact same issues, no?
Re: TinySSH is a small SSH server using NaCl, TweetNaCl
#127Earlier quoted context omitted.
I thought that everyone has switched to Clevis + Tang for that? https://access.redhat.com/documentation/en-us/red_hat_enterp... It's fully automated and supposed to be much more secure. Has anyone got experience with it?
I've seen a bit about Clevis. Is there a major difference between using this, and systemd-cryptenroll?
AFAICT, systemd-cryptenroll requires that you have a USB key plugged into the machine, so someone with physical access would have to insert them at the start and remove when you're done with the server. With Clevis+Tang everything is software.
Or am I missing something?
Re: TinySSH is a small SSH server using NaCl, TweetNaCl
#128Earlier quoted context omitted.
I've seen a bit about Clevis. Is there a major difference between using this, and systemd-cryptenroll?
I guess it depends on your use case. If you rent a bunch of bare-metal servers at a remote location and you want restarts after updates to be fully automated, Clevis seems like a way to do. The whole idea is that once you cancel the server, you just remove it from Tang's list and the next customer who gets those hard drives cannot read them. AFAICT, systemd-cryptenroll requires that you have a USB key plugged into th…