Talk:Cryptographic engineering
From Wikipedia, the free encyclopedia
 |
This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks. |
Contents |
[edit] perspective and plans
The intent is to outline (only!) the constraints on crypto engineering which make it different than other engineering. As well, because engineering constraints generally are foreign to most thinking, there is an attempt to illustrate (though not completely and hopefully briefly) the nature of those constraints generally. The fighter aircraft design example is surely not an optimum one.
The result should be an article which helps readers see how odd crypto, and crypto engineering, is from most types of software and systems and to help those readers contemplating crypto (for business or personal privacy or ... reasons) to evaluate potential products.
If some of the 'crypto is a mystery suited only to the initated' quality is thereby removed for readers, there will have been success. Readers should have acquired some solid resistance to exhortations to "Pay no attention to the man behind the Curtain".
ww 15:57, 4 Mar 2004 (UTC)
[edit] Things from Cryptology which might be salvaged for this page.
[edit] Science, engineering or art?
Cryptography cannot be regarded as a science, in that security "proofs" are typically dependent on sets of far-reaching assumptions, which are often invalidated by unexpected cryptanalytic or other attacks.
Except in the sense that some proposed algorithm or protocol may be shown to be insecure under current conditions (eg, the cryptanalytic tools, computational capability, funding and staff, ... available to an attacker), there is also generally no opportunity to perform experimental tests of hypotheses about cryptopgraphic assertions.
Questions of practicality and cost-effectiveness predominate in actual practice, and experimental testing is wholly conditioned on tester resources. Most practices in modern cryptography rely on assumptions that certain algorithms are in some sense "hard", together with the failure of cryptanalytic attacks against these algorithms or simplified versions. None of these guarantee the security of the system, as the German armed forces discovered to their cost when using the Enigma cipher.
Although in recent years research has concentrated on mathematical cryptography, early cryptographyic techniques made great use of techniques such as steganography. More recent developments may mark the start of moves to use new physical methods such as quantum cryptography.
However, cryptanalysis can be regarded as scientific, because it is amenable to hypothesis testing and falsifiability. Disproofs of security can be made mathematically rigorous, and experiments can be made, both against hypothetical ciphers and practical deployments in the field.
[edit] Cryptology in practice
Note that cryptology/cryptography encompasses much more than mere secrecy. Cryptographic security may result (when, and only when, well chosen algorithms and protocols are properly used); these intentions may include authentication of the participants to each other (with or without secrecy), integrity checks of messages sent (also with or without secrecy), and of course secrecy of the message sent against the non-intended.
Matt, Indeed, these were the items from Cryptology that I had planned to move to crypto engineering when cryptology was merged into cryptography. Since cryptography got changed considerably as I was preparing to do so, I have deferred doing anything until things settled some. ww 15:30, 22 Mar 2004 (UTC)
[edit] Notes for additional material
(Extracted from the article and put here)
- Problem: how to evaluate opposition's knowledge, resources -- cannot specify (except by guessing) who O is, so can't specify Kno or Res
- Problem: how to foresee theoretical breakthrough which renders algorithm chosen transparent. Example of factoring breakthru in re RSA
- Problem: interaction between user and actions required by protocol or algorithm and consequence for achieiving intended outcome of engineering design
[edit] A different take on the subject
I admit I haven't looked at all the other crypto entries (is there a good way to get an overview of the 'shape' of crypto in Wikipedia?) but I generally expect crypto engineering to talk about the practical aspects of mapping crypto mechanisms onto problems. So the topic involves a process (a specialized version of requirements engineering), some standards (FIPS 140 for instance), and some well-known rules of thumb (Kerchoff, red/black separation, etc).
I don't understand the intent of the current contents of the article and I don't see enough references. This is fixable and I'll probably do it over the next few weeks. Rick Smith 20:01, 21 June 2006 (UTC)
- The best available perspective on the crypto corner is likely the lists findable at the WikiProject Crypto page. There's quite a lot of coverage, the quality varies more than it should, and only Matt seems to be up to speed with all of it. The rest of us struggle along as time permits.
- The article is little more than a stub. The intent (as noted well above) is to provide some context about crypto engineering (initially in contrast to other engineering) so that readers might see where more narrowly focused articles (eg, on DES, AES, secret sharing, ...) fit. It was not envisioned as a guide to practice, that being likley too much to imagine in the (volunteer) WP. ww 15:38, 22 June 2006 (UTC)
