<slightly ranting, you might want to hit "del" now :)>
Ian Grigg wrote:

> What is written in these posts (not just the present one)
> does derive from that viewpoint and although one can
> quibble about the details, it does look very much from
> the outside that there is an informal "Cryptographers
> Guild" in place [1].
> I don't think the jury has reached an opinion on why
> the cryptography group looks like a guild as yet,
> and it may never do so.  A guild, of course, is either
> a group of well-meaning skilled people serving the
> community, or a cartel for raising prices, depending
> on who is doing the answering.
To me it seems more like a academic community - particularly the way many
can't handle the concept of "good enough" but look for theoretically
perfect solutions that may be unworkable in the Real World.  And yes, I
*am* an outsider - I dabble a little, and I am a programmer, but I am the
first to admit my math skills are nowhere near adequate to make any
meaningful contribution to the field.
It seems to me there is no more a cryptography guild than a linux guild -
yes, you get advocates who foam at the mouth if you say the wrong thing,
but the majority seem more interested in getting it to work.  From my POV
as a programmer, "learning the field" consists of identifying the
available building blocks (hash, symmetric, asymmetric), standards
(openpgp, x509, ssl, ssh, ipsec) and prior implimentations (paying
particular attention to what had to be patched due to discovered
vunerablities, so as to avoid the same errors in my own code)
It also seems the crypto community is very open to questions, very hostile
to statements - so often knowing how to phrase something to them is as
important as the content of the question. Stating "I am doing $FOO" will
not be as productive as "If I were to do $FOO what vunerabilities would
that introduce?" - remembering that any good advice you get back for free
would have probably cost you weeks of study or possibly thousands of
dollars trying to obtain a security certification for your solution later
Just ignore any posts of "because it isn't done that way" unless they give
a good reason why your way isn't better (note "as good" isn't good
enough - you always need a good reason to stray from a tested and known
path, and it is often worth putting up with a few minor inconveniences to
stay on it)
Oh - and make sure you can recognise a good reason when you see it ::)

> The guild would like the application builder to learn the
> field.  They would like him to read up on all the literature,
> the analysies.  To emulate the successes and avoid the
> pitfalls of those protocols that went before them.  The
> guild would like the builder to present his protocol and
> hope it be taken seriously.  The guild would like the
> builder of applications to reach "acceptable" standards.
I would certainly expect a house builder to know how to lay bricks - but
if he insisted on designing the house too, I would expect him to know how
to do that (and not just start putting up walls and hoping it will all
work out later.
Design requires a fair understanding of what you are designing and what
the capabilities and limitations of the "materials" are - this is why SAs
get paid more than their programming teams (not that I like that given I
am a programmer not a SA).  If you aren't willing to learn how to do that,
you can still follow someone else's design - or take a modular approach
and just drop pre-built units (normally libraries) into those parts of the
code that need them. Libraries can be surprisingly good - if the designer
put in enough effort, they can have sufficient inline M/C for the
timing-critical parts that they are noticably more efficient than
implimenting your own code in a medium or high level language.

> And, the guild would like the builder to take the guild
> seriously, in recognition of the large amounts of time
> guildmembers invest in their knowledge.
That does tend to happen - in any community, you get those who get used to
being authorities, and react badly to being challenged. At least in this
community most of them have the sense to back down when proved wrong :)

> None of that is likely to happen.  The barrier to entry
> into serious cryptographic protocol design is too high
> for the average builder of new applications [2].  He has,
> after all, an application to build.
Indeed so - that is why using a prebuilt standard (or better yet, a
library) as your base is such a good idea. However, a lot of programmers
don't like doing that because
they feel it is either "cheating" or means all their hard work is going to
be dismissed as "just an implimentation of someone else's idea" rather
than something original and novel.  However, the odds of someone "rolling
their own" protocol getting something more efficient or effective as work
that has already been done are low - and if the package you put together
is sufficently good, no users will care it uses SSH (protocol) for comms
or someone else's AES library for the symmetric component - but network
admins will feel comfortable with a known standard protocol and whoever
maintains your package (normally you) will usually sleep better at night
knowing that people are stress-testing those essential components, and if
any faults are found, you just have to download the fix and recompile
rather than find and fix the problem yourself (particularly as a break in
a popular library will make it to bugtraq while your program may *never*
make it above the horizon for serious security investigators - while
hackers may well target it if it is in use at a specific site they have an
interest in)

> What *is* going to happen is this:  builders will continue
> to ignore the guild.  They will build their application,
> and throw any old shonk crypto in there.  Then, they will
> deploy their application, in the marketplace, and they will
> prove it, in the marketplace.
And they will turn up on bugtraq or in the cryptogram doghouse - not that
that will matter to them, given they are probably making lots of money and
if they have any sense, all the rights will be held by a limited company
(so when the lawsuits start rolling in, they can dump the shell and start
over with more insecure crap someplace else)
they could always start issuing security packs as "upgrades" of course.
another useful revenue stream :)

> What may not be clear is that the investment of the security
> protocol does not earn its effort until well down the track.
> And, as an unfortunate but inescapable corollary, if the app
> never gets to travel the full distance of its evolutionary
> path, then any effort spent up front on high-end security
> is wasted.
Indeed so. however, if a programmer isn't willing to put the effort into
writing *secure* code, how can be be willing to put the effort into
writing his own comms/crypto code (instead of just dropping in a library
and forgetting it?)

> Crypto is high up-front cost, and long term payoff.  In
> such a scenario, standard finance theory would say that
> if the project is risky, do not add expensive, heavy duty
> crypto in up front.
Or use decent crypto up front from a library, and if the software takes
off, look at optimizing the code for a later release.

> And, almost all successful apps had little or bad security
> in them up front.  If they needed it later, they required
> expensive add-ons.  Later on.
its an evolutionary thing. ten years ago, you could get away with dumping
an insecure product onto the marketplace - few users would be on the
internet, and even those who were would find few people on there to worry
them.  You just can't get away with that today - the second a new product
is released, a thousand bored teenage hackers will have a warez copy of it
wondering how to earn kudos or steal money by abusing it.
Most ecosystems see the same thing - to start with, predators are poor
hunters, but prey are easy targets. As prey gets better at avoiding
capture, so predators get better at trapping them; all remain in balance,
with each improvement in defense matched by an improvement in attack by
the hunters, and vice versa.  But drop one of the early prey into the same
area, ten generations later, and they wouldn't manage to take more than a
few steps before they died - conversely, drop an outdated hunter into the
area and it would starve or become a scavenger on other people's kills
(that is not a bad analogy for a Skript Kiddie btw :)

> There are no successful systems that started with perfect
> crypto, to my knowledge.  There are only perfect protocols
> and successful systems.  A successful system can evolve
> to enjoy a great crypto protocol, but it would seem that
> a great protocol can only spoil the success of a system
> in the first instance.
The question is - in the current much, much more hostile environment of
the internet, how good is "good enough"?
look upon it as the burglar alarm principle - most home security isn't
really that good, but is "good enough". If you have lights on, a visible
burglar alarm and security lights, and the house three doors down has
lights out, no visible alarm and a window ajar - it doesn't matter that
your house is far from impregnable - that you have unshuttered glass
windows, possibly even older less secure window catches without locks -
just that it is a hardened target compared to the other choices an
attacker has.  Even if your solution isn't fort knox, it can still be
"good enough" relative to the value of your traffic and the likely
attackers.  Ok, it costs little extra for "good enough" to be upgraded to
very good indeed, but as long as it is good enough you can manage to make
your way along for a while and enter the arms race just like the rest of
us :)

> "Why aren't you using SSL" is basically a warning sign
> to all developers that the man asking the question is a
> fully paid-up member of the guild.
> "Why did you do that?" is also not the right question.
> "What is your threat model?" is a far better start.
How about "how much improvement did you get over SSL from your
implementation, and what security risks did it introduce?"
CIPE is a good example of such a tradeoff - they don't have any protection
from UDP replay attacks - provided you can identify which packets are UDP
of interest to you and resend them. Their CRC is also fairly weak, (but is
inside the crypto envelope) and there are other tradeoffs, all listed in
the documentation.  As a replacement for IPSEC it is a no-hoper - and that
is fine, as they don't *want* to be a replacement for IPSec - they are a
lighter, more convenient tunnelling protocol, more bandwidth efficient and
noticably easier to set up. If you are using UDP for something
security-critical, you want to take a good look at *why* rather than
blaming a non-udp-safe tunnel (provided you *know* the tunnel is not
UDP-safe in advance)

>> I suppose some people will always take an anti-intellectual attitude
>> toward this and congratulate themselves about how those eggheads who
>> write those papers with the funny math in them don't know everything
>> to excuse their own ignorance of the subject.
One I have seen a lot is reference to a telephone conversation with the
authors, where they admitted they didn't know about Microsoft's Automated
patch download system.
all that springs to mind is a query as to how many people actually *use*
that - I know I don't trust it as far as I can throw it. Microsoft's
patches have a nasty habit of:
1) requiring the original CD to be inserted
2) overwriting security patches already applied with older, insecure
versions (there were a couple of "two of three" situations between service
packs on NT where you could install any two of three patches - each backed
out one of the others, and there was *no* correct order that would give
you all patches applied; you were required to copy the effected dlls from
the first patch away safe, copy them back after the last patch, then
regsvr32 the things into compliance. luckily, the next service pack
overwrote all three patches with a common update)
3) actually breaking existing functionality (for a competitors' package of
course) by patching something apparently unrelated (I am sure there will
be a few shudders at the mention of NT4 SP6 pre-6a)

I don't let any patches *near* a production server until they test out
lean in a test environment - preferably from a static CD copy so I can be
sure I get the same version on the production server as the test.

> That's just them being entrepreneurs.  Don't however take
> home the wrong message.  When they defend the crypto, that's
> because they have a strong sense of priorities.  When they
> need better crypto, then they will know it.  Because the
> market will tell them.
As an analogy "ok we built this car with no brakes; so far we are doing
fine just switching off the engine and coasting to a stop, and if the
market tells us brakes are important we will add them"
It is surely better to be warned about the lack of brakes by an interested
observer (no matter how condescending it sounds) than to wait for the
fatalities and *then* think about adding them?

> It's nice that the literature is open and available.  What
> is not nice is how much there is of it.
Indeed. really, crypto needs to be more accessable - there is a *lot* of
cross-referenced information out there, mostly in forms where you
gradually glean a snippet of knowledge (shared between those posting these
pages) here and there until you have enough base knowledge to understand
what the web of interconnected and often back-patting pages actually mean.
Perhaps a "basic crypto for programmers - how to use crypto and how to
decide when crypto is needful" book or website is a good idea. I am
probably not up to writing one though, or I would :)

> What is not nice
> is that, in trying to determine the one path, the advice
> of the community reduces to useless baubles like "use SSL"
> or "why did you do that?"
SSL is a nice catchall wrapper - ok, its overkill in most cases, but that
is the price for flexability. I am not so happy it is biassed towards
X509, as that is very much linked to the business models of CAs and
standards organisations...

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to