> 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 [EMAIL PROTECTED]
