Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: James Wyatt (jwyattrwsystems.net)
Date: Tue Aug 21 2001 - 18:22:59 CDT
On Tue, 21 Aug 2001, Rob Simmons wrote:
> On Tue, 21 Aug 2001, Matt Piechota wrote:
> > No No, on the realtime machine controllers (QNX), or OCR nodes that need
> > all the cpu cycles they can get. I'm talking about the [de|en]crypt on
> > the remote side, not the PC side. Every bit or performance matters, and
> > could be the difference between us and someone else getting a contract.
> There should be a way to configure sshd so that only the username/password
> exchange is encrypted. The rest of the connection would be unencrypted.
> You would get some of the benefits of ssh without a constant performance
IMHO, that would be a "bad idea" as it would 1) be easier to insert forged
command packets after browsing what was going on, 2) break changing your
password because it could be sniffed at change time, 3) not save *that*
much CPU for tactical shell sessions, and 4) confuse users who thought SSH
was always "safe" to use.
When I've worked on embedded systems, if there wasn't enough CPU to
encrypt/decrypt the stream, there was likely not enough CPU to run the
commands I usually wanted. I avoid doing things that generated a lot of
output because the network and system needed real-time priority for
everything else going on. Large return flows either hurt the running
(lower-priority), filled queues with backlog because a higher-priority
task got IO and CPU first, or caused non-deterministic latency on the LAN.
Be realistic about the relative overhead of encryption before spreading
FUD. If the systems are so close their limits that encryption "hurts", you
likely warrant a separate sub-network to reduce packet reception overhead
on your nodes. If you do that, you can protect the entrance to that
sub-network and save the encryption setup, diskspace, and overhead. - Jy
btw: I have always been impressed at how much QNX can run in real-time on
a SBC. I've also been impressed at how much stuff ports to it easily. I
just wish I could afford enough of it to play with on my own more.
(Besides the surfing platform on a single floppy demo they sent out...)
To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message