Monoculture

Peter Gutmann pgut001 at cs.auckland.ac.nz
Wed Oct 1 22:26:32 EDT 2003


"John S. Denker" <jsd at av8n.com> writes:

>According to 'ps', an all-up ssh system is less than 3 megabytes (sshd, ssh-
>agent, and the ssh client).  At current memory prices, your clients would
>save less than $1.50 per system even if their custom software could reduce
>this "bulk" to zero.

Let me guess, your background is in software rather than hardware? :-).  Not
all computers are PCs, where you can just drop in another SIMM and the problem
is fixed.  Depending on how you measure it, there are at least as many/many
more embedded systems out there than PCs, where you have X system resources
and can't add any more even if you wanted to because (a) the system is already
deployed and can't be altered, (b) it's cheaper to rewrite the crypto from
scratch than spend even 5 cents (not $1.50) on more memory, or (c) the
hardware can't address any more than the 128K or 512K (64K and 256K 8-bit
SRAMs x 2, the bread and butter of many embedded systems) that it already has.

>With the cost of writing custom software being what it is, they would need to
>sell quite a large number of systems before de-bulking began to pay off.  And
>that's before accounting for the cost of security risks.

See above.  This is exactly the situation that embedded-systems vendors find
themselves in (insert tales of phone exchanges built from clustered Z80s
because it's easier to keep adding more of those than to move the existing
firmware to new hardware without the Z80's restrictions, or people being paid
outrageous amounts of money to hand-code firmware for 4-bit CPUs because it's
cheaper than moving everything to 8-bit ones, or ...).

"Perry E. Metzger" <perry at piermont.com> writes:

>SSL is not only used to protect people's credit cards.
>
>It is one thing if, as a customer, with eyes wide open, you make a decision
>to use something iffy.
>
>However, as a producer, it is a bad idea to make assumptions you know what
>people will do with your tools, because you don't. People end up using tools
>in surprising ways. You can't control them.

Yup.  I once had a user discuss with me the use of my SSL code in an embedded
application that controlled X.  I was a bit curious as to why they'd bother,
until they explained the scale of the X they were controlling.  If anything
were to go wrong there, it'd be a lot more serious than a few stolen credit
cards.

Once you have a general-purpose security tool available, it's going to be used
in ways that the original designers and implementors never dreamed of.  That's
why you need to build it as securely as you possibly can, and once it's done
go back over it half a dozen times and see if you can build it even more
securely than that.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list