Teaching Encryption to Reluctant Programmers Richard Hill & Dharmendra Shadija Faculty of Arts, Computing, Engineering and Science Sheffield Hallam University Howard Street Sheffield S1 1WB
[email protected] [email protected]
Abstract An approach to teaching encryption is described in which an XOR encryption algorithm is used to demonstrate simple encryption concepts for E-Business payment with credit cards. Small groups of undergraduate and postgraduate learners manually encrypt a four-character word, and then exchange the encrypted data with another group. Each group then attempts to decrypt the data as quickly as possible. Learners show an increased understanding of the encryption process and demonstrate greater success when programming in subsequent tutorials. This work is currently being developed to enhance the teaching of asymmetric Public Key encryption.
Keywords E-Business, encryption, teaching & learning, JavaScript, online payment
Introduction This paper describes an experience of teaching programming techniques for encryption to undergraduate and postgraduate learners studying 'E-Business'. This module is an increasingly popular level 5 module option (second year undergraduate), selected by learners from a range of computing backgrounds. In addition, there is a large demand for E-Business teaching at postgraduate level also. The module comprises a variety of topics including, marketing, strategy, portals, client-side and server-side programming, encryption and payment processing. Learners are introduced to concepts by a combination of online learning materials and weekly seminars. One hour tutorial sessions per week allow learners to practically apply their learning through a series of specific activities which are classroom or laboratory based. Learners are assessed in three ways: 1. Throughout the year by means of regular Phase Tests; small multiple choice tests conducted online to test knowledge of concepts and the relevant jargon. 2. A group assignment in which they propose a business case for an e-business venture and then produce a functional prototype application. 3. End of year written exam. The broad module content tends to challenge all students, irrespective of background, and we have experienced particular difficulties whilst attempting to teach encryption programming. This paper discusses a 'back to basics' approach and our results to date.
Student Profile The wide range of skills and abilities can be difficult to address when designing course materials and the perennial problem of addressing specific skill deficiencies, without holding
1
back high achievers was particularly prevalent. Most of the learners have weak programming skills, and tend to prefer the use of tools to build applications. Many of the learners also work part-time to fund their studies, and exhibit a pronounced 'need to know' attitude, by which they openly question the industrial relevance of topics. Within the cohort there are three broad categories of learner: 1. Software Engineering/Network Engineering. These learners are technically quite able, and find the programming demands from E-Business fairly straightforward. 2. Business Information Systems. This category of learners are generally high achievers, though they do demonstrate mental barriers towards programming. Once they overcome their initial fears they become capable programmers. 3. ‘Generic’ Computing. These learners find programming difficult and need a significant quantity of support. They struggle with syntax and often get bogged-down with logic.
Understanding Concepts The barrier to programming lead us to conclude that we should spend the minimum amount of time on actual implementation; however we felt that although we wanted to successfully teach the concepts, we still had to demonstrate the practical relevance of the learning. We decided to recreate a typical E-Business scenario where a customer wishes to pay for some goods online. Immediately this requires a web form and some simple validation. Our first attempt focused on the web form generation, and we quickly lost the learners when it came to implementing the encryption logic with JavaScript. Our experiences of teaching programming ranged from painful to tolerable, especially with such a varied level of learner interest and ability. However, web page scripting technologies do seem to be received rather better than C or Java, even amongst self-confessed reluctant programmers. These learners are able enough to copy scripts and customise through editing, very successfully in some cases after witnessing their web design efforts. This proved puzzling, as we assumed that the learners would take to the JavaScript and get on with the business of understanding the encryption concept. What we had not realised was that it was the misunderstanding of the encryption logic that was creating the problem, rather than knowledge of the JavaScript syntax. The learners blamed their ignorance of programming, and the sessions were judged to be largely unsuccessful. After much consideration we decided to try and make the learning of the concepts more transparent. Our previous attempt did not truly focus on the concepts that we wanted to teach, and we had not addressed the barrier towards programming. In fact we had faced it head-on without teaching the underlying encryption principles.
Outline of Session The fundamental concepts that we want to describe are: 1. A method and process logic for encrypting plaintext messages into cyphertext. 2. An appreciation of the resources required to decrypt a message using brute-force techniques. After the normal class administrative tasks, a problem is described. The scenario is based upon the transmission of a credit card account number from a client machine accessing the Internet to an online store. A short class discussion highlights some pertinent issues including: • HTTP requests are insecure and could be ‘listened’ to by another party;
2
•
If the credit card number entered is incorrect then the server has to process the entire number before detecting the error, thus increasing network traffic and giving the user a perception of a 'slow' interface; To fully validate the credit card number at the client-end would require every credit card number issued to be downloaded to the client; It is possible to perform some basic client-side checks in the browser to reduce the impact of erroneous entry on server performance.
• •
Additionally the process logic of symmetric encryption is discussed as below (Figure 1): Encryption
Plaintext
Algorithm
Cyphertext
Key
Figure 1.
An eXclusive OR (XOR) encryption algorithm, which is available in JavaScript is explained using a truth table as follows (Table 1): A 1 1 0 0
B 1 0 1 0
AVB 0 1 1 0
Table 1.
A worked example is provided, showing the process of encrypting the word “FRED”. 1. 2. 3.
Work out the Binary equivalent of FRED. Choose a key and an algorithm. In this case '00000011' and 'XOR' are used. The XOR encryption is applied to the word. This is then converted back to ASCII and the resultant cyphertext is 'EQFG'. In order to 'hack', a number of possible 4-bit keys are used starting with '00000001' and ending with '00001111' ('00000000' is not a choice. Why?).
4.
Text FRED
Binary 01000110 01010010 01000101 01000100
Key 00000011
Table 2.
To apply an 8-bit encryption you must break-up your binary number into 4 parts, and then apply the XOR algorithm. 01000110 01010010 ^ ^ 00000011 00000011 01000101 01010001 01000101 01010001 01000110 01000111
01000101 ^ 00000011 01000110
01000100 ^ 00000011 01000111 EQFG
Table 3.
3
Once the text is encoded, you will have to decode using all the possible keys and then check the messages to see if it makes sense. You can see in Table 5 that if we use all of the keys, only one of the decoded words makes sense. Text EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG EQFG
Encoded Binary Equivalent 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011 0100010101010001010001100100011
Key 00000001 00000010 00000011 00000100 00000101 00000110 00000111 00001000 00001001 00001010 00001011 00001100 00001101 00001110 00001111
Decoded message 01000100010100000100011101000110 01000111010100110100010001000101 01000110010100100100010101000100 01000001010101010100001001000011 01000000010101000100001101000010 01000011010101110100000001000001 01000010010101110100000101000000 01001101010110010100111001001111 01001100010110000100111101001110 01001111010110110100110101001101 01001110010110100100110101001100 01001001010111010100101001001011 01001000010111000100101101001010 01001011010111110100100001001001 01001010010111100100100101001000
Table 4. 01000100010100000100011101000110 01000111010100110100010001000101 01000110010100100100010101000100 01000001010101010100001001000011 01000000010101000100001101000010 01000011010101110100000001000001 01000010010101110100000101000000 01001101010110010100111001001111 01001100010110000100111101001110 01001111010110110100110101001101 01001110010110100100110101001100 01001001010111010100101001001011 01001000010111000100101101001010 01001011010111110100100001001001 01001010010111100100100101001000
DPGF GSDE FRED AUBC @TCB CW@A BWA@ MYNO LXON O[MM NZML I]JK H\KJ K_HI J^IH
Table 5.
The use of hexadecimal tables is also demonstrated by converting a four-letter word into hex, then into binary, ready to be encrypted. This session concentrates on developing an understanding of the logic of the process; a subsequent session deals with the JavaScript and server-side implementation. Upon completion of the worked example, the class is put to task. The class of 20 students is divided into four groups, who must each decide upon a four character word to encrypt, using one of fifteen keys (00012 to 11112) prepared by the tutor beforehand (Table 4.). Encrypted words are then exchanged between groups, and the decryption process is started. At this stage learners are left to their own devices; the tutor merely provides clarification, if and when required. Most of the learners were intrinsically motivated to perform the task, and any that were initially reluctant became involved quickly. Learners are permitted to use a computer to look up hexadecimal values, or use a spreadsheet to record their progress, but they are discouraged from attempting to write a program. The
4
emphasis is to manually decrypt the cyphertext, to give them an appreciation of the enormity of the task.
Results The session proved to have an immediate impact on the teaching of encryption logic. Other tutors on the module also commented positively and experienced a much more successful session. The improvement was two-fold: 1. The encryption session was enjoyed by all participants, and little intervention from the tutor was required. Learners were focussed and quickly organised themselves, devising strategies to ‘win’. Evaluation of the session was also productive, with learners actively discussing and debating learning points, as well as the use of different strategies. For instance some groups took a random approach to finding the key, by guessing, whilst other groups were more methodical and worked through all the combinations until they succeeded. Significant learning points emerged, particularly when one group mistakenly used the AND operator instead of XOR. As a result, the cyphertext could not be decoded, but it was the learners who deduced the error whilst decoding, reinforcing the understanding of the algorithm. Application of learning was demonstrated by learners who used spreadsheets to record their activities and check that every combination of the key had been explored. 2. The next session required learners to develop a client-side form using JavaScript to perform basic validation checks on a credit card number before encrypting and sending to a database. Prior to the revised approach to teaching encryption this session was fraught with difficulties and in many cases was not productive for the learners. Learners did not understand the concepts or the logic, and struggled also with syntax. After attending the encryption tutorial, the learners were clearly more comfortable with the underlying principles and could concentrate on syntactical and typing errors. This was also confirmed by students who were absent from the first session, who found the JavaScript implementation difficult to comprehend. An informal straw poll of students at the end of the module supported this in so much as when asked which tutorial they remembered most, they all said, ‘the hacking class’.
Future Work In terms of teaching the principles of encryption to learners, this session has proved useful on the postgraduate programme also. However, as many of the postgraduate learners either have prior industrial experience or are currently working, it was decided that a more relevant example of encryption was required. Contact time with undergraduate students is limited, and considering the breadth of topics undertaken for the E-Business module, two sessions on encryption is already regarded a luxury. However, the teaching at postgraduate level is generally more flexible, particularly on residential courses, so it was decided to develop the exercises further. One general outcome from the first session is that the learners have gained confidence in their ability to decrypt a simple symmetric cyphertext, to the point that some of them believe they can decrypt anything. We decided to address this by extending the exercise to include asymmetric encryption, using private and public key pairs.
5
Additionally we have decided to formally record some data and we shall commence by asking each learner to assess their own skills and abilities. This exercise will then be compared with the results of an end-of-module evaluation questionnaire. The key concept we are attempting to demonstrate is that whilst symmetric encryption can ‘mask’ a message, an exchange of keys still has to take place. Again students will manually generate public keys, and this time will post them onto an online discussion forum such as that provided by Blackboard. The Prime numbers used to generate the keys will be restricted by the tutor to give the learners a chance of decoding the key. In small groups of learners they will choose one of the public keys and attempt to decrypt it by using a calculator and a list of Prime numbers. Of course it is very difficult to find the answer, and it is feasible that many groups will not achieve this in the time available. Knowledge of these concepts does open up opportunities for interesting assignments or homework; learners could be given an encrypted answer to an assignment question, or an encrypted list of questions that might appear in a subsequent phase test. It is envisaged that the competitive atmosphere generated by our initial experiments will also transfer through to the further work described, together with the associated benefits.
References Blackboard Inc., URL: http://www.blackboard.com/ [last accessed 1/11/2003] Rezai, M., E-Business, URL: http://www.shu.ac.uk/schools/cms/teaching/rh1/ebiz/index.html [last accessed 1/11/2003]
Rubin, Aviel D. "An Experience Teaching a Graduate Course in Cryptography." Cryptologia 21, no. 2 (Apr. 1997): 97-109.
6
