Do Cryptographers burn?

Dave Howe DaveHowe at gmx.co.uk
Sat Apr 3 17:49:15 EST 2004


> Do Cryptographers burn?
Sometimes they blush hard enough to ignite, if that helps :)

> Cryptography is a lot about math, information theory,
> proofs, etc. But there's a certain level where all this
> is too complicated and time-consuming to follow all those
> theories and claims. At a certain point cryptography is based
> on trusting the experts.
  This is universally true though - nobody can live long enough to work
though the theory and practical of almost anything - consider for example a
classic (no computer engine or breaking control) automobile. You would need
to understand every part of chemical theory that relates to petroleum
fractions and additives commonly found in car fuel; thermodynamic, materials
and physical theory and engineering design that relates to the functions of
the engine and its mechanical coupling to the drive wheels; the
differential, the gearing, the steering, the breaking, the materials that
form the tyres, the ergonomic design of the seating area, vision angles
though the windshield, glass (materials) theory for the material that forms
the windshield (toughness, resistance to random impacts, refraction though
the medium), the materials of the road surface and how they behave under
different conditions of wet, dry, temperature... and that is just the
generic stuff. once you get down to a specific instance, you have to decide
if your instance of car meets the theoretical data you learnt on a abstract
car, and if the instance of road you are driving on meets similar data you
have on abstract driving surfaces.
  Even those who work in that field can take decades to reach the point they
could design one component of a modern automobile - the engine, the gearbox,
the chassis and so on. It would be insane to learn all that if you just
wanted to drive to work in the mornings....
  At a basic level, you have to define basic functions in terms that an
expert can verify and say "yes, that is a truism" - then you can drop them
into more complex systems in different patterns, not knowing if the system
will work but able to rely on the components to perform within their design
parameters. the same is true of cryptography; an accepted algo will have
been hammered on and peer reviewed by dozens of people - and as even a minor
predictability under extreme conditions using a simplified form of an algo
is worth writing up a paper on, there is a world of pre-established work to
review and verify for even the most ambitious would-be-cryptoanalyst to cut
his teeth on (and use as training examples to apply similar techniques to
algos that have not yet had that attack publically attempted on them)
  So,if the basic level for a mathematician is the maths within the
algorithm; the basic level for a programmer is the algorithm itself, as a
process to produce cryptotext from plain, or plaintext from crypto.
Normally, a programmer won't worry about verifying the algo - he will accept
that as part of the design he is to impliment, and if he has a choice of
several suitable algos, will simply impliment them all as alternative
settings.
  Programmers love to re-use code though - it saves a *lot* of work, and as
you become familiar with and improve the code you can feed back changes to
earlier software, improving its efficiency "for free". Of course for this to
work well, the code must be independent of the body of the software, have
clearly defined interfaces (so that you can't mess up an earlier
implimentation when improving a later one, by forgetting a "side effect" you
earlier relied on but don't need any more) and indeed act as a basic
component itself - forming a subprogram that you hand data to and receive
data back from as a "black box" operation. Another strength of doing your
crypto as such a "library" of pre-written code is that you can test and
"prove" it independently of your main program - you can hand your crypto
library to your peers for their review, you can encourage its use (thus
ensuring good crypto in a wide range of software, improving compatability,
and not incidentally improving your peer reputation :) and generally
maintain your library as a product in its own right.
  At the end of the chain is a programmer who doesn't want to know about how
the algo works, would rather not have to know the details of how to make it
work, but likes the idea of being able to write something like

use MyFirstCryptoLibrary;
ask user for message store in [messagedata]
ask user for key store in [key]
DoCrypto(chosenalgo,[key],[messagedata]) store in [encrypted message]
ask user for destination store in [EmailToName]
SendEmailTo([EmailToName],[encrypted message])

and have it work..... and indeed, until the average programmer *can* use a
library that easily to include decent crypto in his product, the majority of
the products out there will be either not supporting crypto at all, or doing
it badly.

> Is anyone here on this list who can
> claim to have read and understood all those publications
> about cryptography?
I can claim to have read about a hundred. That is not enough to even get on
this mailing list if I had to do it by reputation - but I am not a
mathematician any more than I need to be to be a programmer, and I am not a
programmer these days any more than I need to be to administer my servers.

> Is anyone here who can definitely tell
> whether the factorization and discrete logarithm problems
> are hard or not?
Yes, I can. I tried it and it is bloody hard :)
I know what you mean though, and if you were the leading expert in number
theory *and* had read and understood every paper ever published, you still
wouldn't know - because someone in the NSA, or russia, or some chinese
school where they don't know what a computer is, could have had an inspired
moment and found an easy solution everyone else has missed. All you can say
is "all the current experts say they don't know any way to do this that is
easy, so it is probably hard"

> Does this require those people to be trustworthy?
yes. but it requires at least some of them to be trustworthy - certainly not
all. There would have to be a universal worldwide conspiracy to conceal the
breakthough if it were at all obvious from the "state of the art" - so while
a fundimental breakthough in one restricted investigation might happen only
once in a century, so could be concealed, it would only take that once to
happen to someone who would rather publish than make it a military secret
for it to be common knowledge.
Parallel discoveries do happen, and fairly often; even something as complex
as the FFT was only re-discovered (when it was originally found, there was
no electronics industry to impliment it, so it was just a mathematical curio
and forgotten)

> What if a cryptographer is found to intentionally have given a false
> expertise in cryptography and security just to do a colleague a favor,
> when he erroneously assumed the expertise would be kept secret?
If you mean he gave a false assurance of the security of a product for a
friend - why would he do that? I can't think of any of my friends who would
want me to tell them sofware was secure if it wasn't.


> Would
> such a cryptographer be considered as burned? Wouldn't he give more
> false expertises once he's getting paid for or asked by his government?
I suppose that depends on his integrity and how much his reputation and
skill would be worth to his employers if it became known that he gave false
assurances - and it would only be a matter of time before some other
cryptoanalyst found the fault he found and ignored.

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



More information about the cryptography mailing list