Cryptographic engineering is the discipline of using cryptography to solve human problems. Cryptography is typically applied when trying to ensure data confidentiality, to authenticate people or devices, or to verify data integrity in risky environments.
Cryptographic engineering is a complicated, multidisciplinary field. It encompasses mathematics (algebra, finite groups, rings, and fields), electrical engineering(hardware design, ASIC, FPGAs) and computer science (algorithms, complexity theory, software design, embedded systems). In order to practice state-of-the-art cryptographic design, mathematicians, computer scientists, and electrical engineers need to collaborate.
Below are the main topics that are specifically related to cryptographic engineering:
* Hardware architectures for public-key and secret-key cryptographic algorithms * Cryptographic processors and co-processors * Hardware accelerators for security protocols (security processors, network processors, etc.) * True and pseudorandom number generators * Physically unclonable functions (PUFs) * Efficient software implementations of cryptography for embedded processors
Attacks against implementations and countermeasures against these attacks
* Side channel attacks and countermeasures * Fault attacks and countermeasures * Hardware tamper resistance * Hardware trojans
Tools and methodologies
* Computer aided cryptographic engineering * Verification methods and tools for secure design * Metrics for the security of embedded systems * Secure programming techniques
* Cryptography in wireless applications (mobile phone, WLANs, analysis of standards, etc.) * Cryptography for pervasive computing (RFID, sensor networks, smart devices, etc.) * FPGA design security * Hardware IP protection and anti-counterfeiting * Reconfigurable hardware for cryptography * Smart card processors, systems and applications * Security in commercial consumer applications (pay-TV, automotive, domotics, etc.) * Secure storage devices (memories, disks, etc.) * Technologies and hardware for content protection * Trusted computing platforms
Interactions between cryptographic theory and implementation issues
* New and emerging cryptographic algorithms and protocols targeting embedded devices * Non-classical cryptographic technologies * Special-purpose hardware for cryptanalysis * Formal methods for secure hardware
In modern practice, cryptographic engineering is deployed in crypto systems. Like most engineering design, these are wholly human creations. Most crypto systems are computer software, either embedded in firmware or running as ordinary executable files under an operating system. In some system designs, the cryptography runs under manual direction, in others, it is run automatically, often in the background. Like other software design, and unlike most other engineering, there are few external constraints.
In other engineering design, a successful design or implementation of one, is one which 'works'. Thus, an aircraft which actually flies without crashing due to some aerodynamic design blunder is a successful design. How successful is important, of course, and depends on how well it meets intended performance criteria. Continuing with the aircraft example, several World War I fighter aircraft designs only barely flew, while others flew well (at least one design flew well, but its wings broke off with some regularity) though with insufficient agility (turning, climbing, ..., rates) or insufficient stability (too frequent inescapable spins and so on) to be useful or survivable. To a considerable extent, good agility in aircraft is inversely related to inadequate stability, so fighter aircraft designs are, in this respect, inevitable compromises. The same considerations have continued in more recent times, as for instance the necessity for computer 'fly-by-wire' control in some fighters with great agility.
Cryptographic designs also have performance goals (eg, unbreakability of encryption), but must perform in a more complex, and more complexly hostile, environment than merely high (but not too low) in the Earth's atmosphere under war conditions.
Some aspects of the conditions under which crypto designs must work (to be successful and so worth bothering with) have been long recognized. Sensible cipher designers (of which there were fewer than their users would have wanted) attempted to find ways to prevent frequency analysis success, starting, it must be assumed, almost immediately after that cryptanalytic technique was first used. The most effective way to defeat frequency analysis attacks was the polyalphabetic substitution cipher, invented by Alberti about 1465. For the next several hundred years, other designers also tried to evade frequency analysis, usually poorly, demonstrating that few had a clear understanding of the problem. What is probably the best known (and likely the widest used) of those attempts is the (misnamed) Vigenère cipher which is a partial implementation of Alberti's idea. Edgar Allan Poe famously, and rashly, boasted that no cipher could defeat his cryptanalytic talents (essentially frequency analysis); that he was almost entirely correct about the ciphertexts submitted to him suggests a low level of cryptographic awareness some 400 (!) years after Alberti. As this history suggests, an important part of crypto engineering is understanding the techniques the Opposition may have available.
In addition, it has been explicitly realized since the mid-19th century that the Opposition must be credited with certain kinds of knowledge, lest one's design efforts address too little. Kerckhoffs' Law -- "The security of a cipher must reside entirely in the key", and the equivalent, and somewhat less obscure, Shannon's Maxim -- "The enemy knows the system", put it more or less clearly. A crypto design must achieve its goals (eg, confidentiality, or message integrity—see 'goals' in the article cryptography), not only despite active intelligent Opposition, but in spite of uncomfortably well informed Opposition.
Inherent zero-defect requirement
Many failures in cryptographic engineering are catastrophic. That is, success in breaking one message leads to reading all messages. Most cryptographic algorithms and protocols make certain assumptions (random key or nonce choices, for example), and when those assumptions are violated, all security is lost.
Examples: Netscape random bug found at UC Berkeley, Microsoft's PPTP protocol implementation problems found by Schneier.
Invisibility of most failure modes
Success in cryptographic engineering is unclear at best. Not crashing is a quite prominent sine qua non in aircraft design. Not allowing the Opposition access (to protected message traffic, for instance) is the design goal, but it is far less obvious when this goal has been achieved than in other engineering. Essentially no Opponents will ever make their access to message content public, and so neither designers nor implementors nor users of crypto systems will ever learn from them that their design is insecure. It is certainly irrational to count on Opponents as a quality control resource.
One tempting measure of security is 'I can't figure out how to break it, so I will assume Opponents will not be able to do so either'. This may be true, but there is no way to actually know your Opponents have the same limitations you do. In a modern environment, in which messages travel over public networks, it is not even possible to detect eavesdropping, much less to prevent it. Accordingly, most message traffic must be presumed to be entirely in an Opponent's possession.
Known cryptographic failures fall into several classes. Future failures may also, or may find new categories. Examples include:
- cryptographic protocol errors
- user operational procedure errors
- algorithm implementation errors
- associated system failures
- misunderstanding of correct operations
- arbitrary user actions
- programming errors (bugs)
- precision arithmetic errors
- random data errors
- software library routine errors
- operating system insecurities with effects on cryptographic software (eg, keys retained in swap file data)
- operating system insecurities with regard to plaintext access
- operating system vulnerabilities (viruses, Trojan horses, etc)
The effect of most of these will not be apparent to end users, generally not to the computer system's administrators, and often not even to the cryptographic system's designers. For instance, a buffer overflow vulnerability in an obligatory operating system component may not have been present in version 5.1 (used during crypto system testing), but appear only at version 5.3, available only after release of the crypto system. Or that particular vulnerability may have been removed in all operating system releases later than version 5.3, but the crytographic system is being used in this case with version 5.1.
The invisibility of many such errors makes finding and removing them more difficult than in many other kinds of engineering.
Wikimedia Foundation. 2010.
Look at other dictionaries:
Cryptographic nonce — For other uses of the word, see Nonce. Typical client server communication during a nonce based authentication process including both a server nonce and a client nonce. In security engineering, nonce is an arbitrary number used only once to sign… … Wikipedia
Topic outline of engineering — For a more comprehensive list, see the List of engineering topics. Engineering is the practice and method of applying scientific and empirical knowledge to the service of humanity, and is distinct from the physical sciences, which are studies of… … Wikipedia
Outline of engineering — See also: Index of engineering articles The following outline is provided as an overview of and topical guide to engineering: Engineering – discipline, art, skill and profession of acquiring and applying scientific, mathematical, economic, social … Wikipedia
Centre for Applied Cryptographic Research — The Centre for Applied Cryptographic Research (CACR) is a group of industrial representatives, professors, and students at the University of Waterloo in Waterloo, Ontario, Canada who work and do research in the field of cryptography. The CACR… … Wikipedia
Cryptography — Secret code redirects here. For the Aya Kamiki album, see Secret Code. Symmetric key cryptography, where the same key is used both for encryption and decryption … Wikipedia
Outline of cryptography — See also: Index of cryptography articles The following outline is provided as an overview of and topical guide to cryptography: Cryptography (or cryptology) – practice and study of hiding information. Modern cryptography intersects the… … Wikipedia
Digital signature — This article is about secure cryptographic signatures. For simple signatures in digital form, see Electronic signature. A digital signature or digital signature scheme is a mathematical scheme for demonstrating the authenticity of a digital… … Wikipedia
Topics in cryptography — This article is intended to be an analytic glossary , or alternatively, an organized collection of annotated pointers.Classical ciphers*Autokey cipher *Permutation cipher*Polyalphabetic substitution **Vigenère cipher*Polygraphic substitution… … Wikipedia
NIST hash function competition — Cryptography portal The NIST hash function competition is an open competition held by the US National Institute of Standards and Technology for a new SHA 3 function to replace the older SHA 1 and SHA 2, which was formally announced in the Federal … Wikipedia
Key management — is a term used to describe two different fields; (1) cryptography, and (2) physical key management (or electronic key management) within building or campus access control.In cryptography, key management includes all of the provisions made in a… … Wikipedia