[14858] in cryptography@c2.net mail archive
Re: Open Source Embedded SSL - (License and Memory)
daemon@ATHENA.MIT.EDU (Matthew Byng-Maddick)
Sat Dec 6 11:46:21 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sat, 6 Dec 2003 13:22:22 +0000
From: Matthew Byng-Maddick <cryptography@lists.colondot.net>
To: cryptography@metzdowd.com
In-Reply-To: <1070595151.8390.48.camel@bohr>
Mail-Copies-To: never
On Thu, Dec 04, 2003 at 10:32:32PM -0500, Bill Tompkins wrote:
> I can't speak to how common it is, but there are applications that
> require crypto, and that require some sort of negotiation protocol, that
> don't use TCP or Ethernet. For example- wireless apps, or various
> non-ethernet multi-drop wired interfaces. While these applications do
> require some sort of communications stack, it might be less
> sophisticated than what you're used to seeing with TCP/IP (and might be
> mostly implemented in off-CPU hardware).
[Bill went on to say that you might use SSL for such things, as it's had
lots of design effort].
If you're using wireless then SSL isn't really an option, unless you
layer something like TCP over the top. A large part of SSL's anti-replay
security relies on it running on a reliable channel, so sequence numbers
monotonically increase at a constant rate. (this is also for attempted
message injection). Also, AIUI, *any* crypto failure causes a shutdown
of the protocol, rather than it just being ignored, as it might be in an
unreliable stream.
MBM
--
Matthew Byng-Maddick <mbm@colondot.net> http://colondot.net/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
