Cryptography for Confidentiality and Authentication
By Ben Gross
MIT network administrator and kerberos author Jeffery Schiller intermixed a broad overview of cryptography with interesting anecdotes in his tutorial for CFP96. During the session he covered technical aspects and his practical experience, as well as provided commentary on policy.
Schiller said in order to "do" cryptography one needs first to develop a cryptographic algorithm, then generate "strong" keys, and afterwards be able to distribute the keys securely and develop a protocol for interaction. Each aspect is needed. He said simply with respect to developing algorithms: Don't do it. He says if you must develop algorithms first you need to spend ten years breaking other people's algorithms, then maybe you can design your own. Afterwards, get other people to attack your design. However, plenty of good algorithms exist and people are busy attacking them, so you probably don't want to bother.
In general doing security is hard, it is a negative deliverable because you don't know when you have it. You always have to understand your environment you are creating security for. Kerberos was developed in the academic environment. He said the way you have physical security in an academic environment is to have 24 hour staff.
Throughout the workshop Jeff discussed the political ramifications of cryptography and export policy. He correlated strength of an algorithm to its exportability. The definition of whether or not an algorithm is strong is whether or not it is exportable, if it is exportable, then it is not strong.
Much of the tutorial centered on the importance and the creation of random number generators. In order to generate strong keys you must have a truly random number generator. This is very difficult and many systems are attacked this way (Netscape in 10/95 and Kerberos in 2/96). Random to a lay person means it "looks" random at face value. Random to a statistition means it is statistically random. Finally, random to a cryptographer means the above and completely unpredictable. This is a problem as computers are very very NON random devices.
There are three basic types of attacks: a chosen plain text where the attacker knows what the text is in full. A known plain text where the attacker knows something about the text. And cyphertext only attacker where the attacker needs to use the statistical properties of language to attack the text.
Cracking an algorithm is defined as being able to decrypt the message in less time than brute force (ie. finding a better way). Decrypting the message through brute force just means that you have just run into the limitations of the key (ie. you now can compute every single possible key.)
Jeff told the traditional story of the creation of DES with a new twist. It was by IBM and then the subsequently modified by the NSA. It has been thought that the NSA weakend the algorithm. Jeff pointed out that new evidence shows that the NSA in fact strengthened it.
When developing protocol you must be careful to not negotiate insecurity. Jeff said the current trend is to negotiate every electronic transaction. He says this may not be good in terms of authentication. For example you cannot ask untrusted endpoint for name of authentication domain as it may give you false information which you can not verify. Therefore you can not negotiate until you authenticate.
As one of the authors of the Kerberos system Jeff went into detail of the design goals of the system as well as its evolution in the MIT Athena environment. Essentially, Kerberos is like a secure introducer for electronic communication.
Much of the PGP discussion surrounded the various models of mail encryption standards; the web of trust of PGP and the rigid hierarchy of Privacy Enhanced Mail (PEM). He said PGP and PEM serve different markets. PEM is geared more for business while PGP is geared for personal communication. Jeff believes that the future for PEM will be in electronic commerce while PGP will remain popular for personal communication.
[ CFP96 Newsletter | CFP96 | CFP | general info ]
Comments and bug reports to Daniel C. Stevenson