Forum

  • Mohamed

    We can think of an encryption/decryption process as usually containing several elements. For example an encryption method. This can be something like TKIP. This method itself is usually comprised of several different elements.

    For example, TKIP was originated as a ?stop gap measure?. It was realised early on that WEP was not inherently secure. The IEEE started work on 802.11i to introduce powerful encryption tools and other items. Industry could not wait for the entire standards process to go through, so TKIP was introduced. The idea was to have a firmware upgrade [ if possible ] on existing systems to ?beef-up? security whilst we waited for 802.11i with CCMP/AES etc to come into play. Most implementations of CCMP/AES would require a hardware upgrade. TKIP was one of the most incredible things that has been done in Wi-Fi ever. CCMP/AES basically started off from a ?clean slate?. TKIP however, had massive restrictions ? had to use the existing cypher ? RC4, had to be able to use no more resources [ memory and processor capabilities ] than existed in present cards [ at that time ] , had to ?boost? integrity checking etc etc. Truly a remarkable achievement given the constraints.

    An algorithm is a step-by-step process for solving a mathematical problem in a fixed number of steps. An algorithm is also called a ?cypher?. Data which has not been encrypted is called ?plaintext?. Data which has been encrypted is called ?cyphertext? [ or ?ciphertext? ]. In conventional cryptography books, the two parties communicating are usually called ?Alice? and ?Bob?. A trusted third party [ for certificates etc ] is called ?Ted?, and the ?bad-guy? trying to cause trouble is called Mullet [!!]. No idea why he is called that.

    So TKIP was [ /is ] the encryption method, RC4 is the encryption algorithm [ because we had to keep the same encryption algorithm as existed already for WEP ], and ?Michael? [ MIC ] was the message integrity system.

    The method contains multiple sub-components [ encryption algorithm, MIC etc ].

    A key however is necessary to make ?the whole thing work?.

    Two good books for you:

    Corporate Computer and Network Security by Panko and Cryptography and Network Security by Stallings [ a lot of math, but good details on how algorithms really work ].

    If only encryption is being performed [ no MIC etc ] sometimes texts will call the method and encryption process/algorithm the same thing.

    Dr. Panko states ?Encryption processes have two parts: one is a mathematical algorithm [ the encryption method ] which is used the same way on all messages. The other is a key, which is a string of bits. Different keys produce different ciphertexts from the same plaintext even when the same method is used"

    I have had to teach security to satellite and radio folks for many years [ almost the same principles as for Wi-Fi, just some terminology differences ]. One of the analogies I like to use is that of a car. The car as a whole can be thought of as the method, the engine can be thought of as the encryption algorithm [ actually we have hardware encryption ?engines? ] and all the rest of the bits and pieces are the MIC etc.

    The car will not go anywhere without a key [ excluding the Bronx in New York and those new electronic thingys ].

    In summary, the key and encryption algorithm are two entirely different beasts, but each ?needs? the other.

    Hope that helps.

    One of the of the biggest problems in security is the overwhelming number of abbreviations and acronyms. Take a look at IEEE 802.11r and you will see just how bad it can get !!

    I shall be doing an audiocast on Keith Parson?s Wirelesslanprofessionals website sometime later on regarding SSL which is the foundation of TLS, which in turn is the foundation of EAP-TLS, which in turn is the foundation of many other ?EAP Methods?. I have found that if you understand SSL [ Secure Sockets Layer ] you can pretty much understand most security systems [ it covers public keys, private keys, certificates, symmetric keys, message integrity etc ]. I?ll be ?dissecting?a typical SSL connection and going through it step by step.

    Dave

Page 1 of 1
  • 1