Live data from Hacker News

TinySSH is a small SSH server using NaCl, TweetNaCl

github.com

121–128 of 128 posts

Re: TinySSH is a small SSH server using NaCl, TweetNaCl

#121

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.

I don't know, but it might be somewhat tongue-in-cheek since Wren itself doesn't use semicolons at all.

Re: TinySSH is a small SSH server using NaCl, TweetNaCl

#122
post #104

Earlier 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.

That doesn't work if you need to RMA the disk. So best to encrypt before you put anything on the disk

Re: TinySSH is a small SSH server using NaCl, TweetNaCl

#125
post #113
post #84

Earlier 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.

True, but in that case, I think it would still be difficult to swap in a completely new system into the network (with your IP) with your old private host key.

(Without a physical breach... if that happens, all bets are off).

Re: TinySSH is a small SSH server using NaCl, TweetNaCl

#126
post #44

Earlier 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?

The ultrablue project I linked to solve exactly this problem, with TPM and a smartphone, but it's targeted at unlocking your laptop and uses Bluetooth to communicate with the smartphone for unlocking - and I don't want to have Bluetooth on my NAS ^^

Re: TinySSH is a small SSH server using NaCl, TweetNaCl

#127
post #112

Earlier 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?

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 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

#128
post #112

Earlier 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…

That makes sense. I was thinking about the case of using a TPM to unlock full disk encryption as long as secure boot hashes checked out.
Post reply on HN