You will undertake five (5) in-class tests on Moodle throughout the term. Each test will cover topics from the weeks leading up to that test. Each test will consist of multiple choice questions, short answer questions and/or calculations. Some questions may require the use of software. There will be multiple independent questions in each test. All tests are individual assessment.

Each test will be time limited, typically allowing you between 15 and 30 minutes to complete the test. Test time limits, topics, and open/close times can be found on Moodle.

The tests must be taken during your allocated timeslot: either the tutorial or, in special cases, a designated time negotiated in advance with the Unit Coordinator. The test will open shortly after the start of your time slot, and will close after the time limit has been reached. You will be allowed only a single attempt at each test, with the score for that attempt counting towards your grade.

Tests will be held during the weeks: 3, 5, 7, 9 and 12. Tests will be supervised. Tests will be open book. You are not allowed to communicate with anyone (including other students or people online) while the test is open.

You will not be allowed to take a test at any time outside of your allocated timeslot, unless an Assessment Extension Request is approved. The test will close at the same time for all students in your timeslot. If you arrive late for the timeslot, you will not be granted extra time. Changes to test times can only be granted with approval by the Unit Coordinator.

For those in online tutorials, you will need access to a webcam, speakers and microphone (e.g. headset).

You are assumed to have a working computer and Internet connection during term, and especially during times when attempting a test. Technical problems, such as a computer crash or loss of Internet connection, will not usually be a reason for an extra attempt or extension. You are expected to prepare your computer before the test starts. If problems outside of your control occur during a test, report immediately to your tutor, who may either extend the time or allow you to undertake the test at another time (with the Unit Coordinator's approval).

In most cases, test answers will be automatically marked, with marks awarded based on the correctness of the answer within the context of topics covered in unit. Questions may be worth different marks, with the marks indicated in the test. If test answers are manually marked (e.g. explanation style questions), then marks will be awarded based on the correctness and clarity of the answer.

As results and solutions may be released shortly after the due date, late submissions are not accepted. Making no attempts before the due date will result in a score of 0.

You will maintain a journal throughout the unit that captures your workings, insights and reflections on each topic. For example, as you learn about a new cipher, your will record your own workings and examples in the journal, you will compare the cipher design to others, and you will explore possible attacks on that cipher (and/or explain why some attacks are unsuccessful).

The journal is expected to be maintained each week. Examples of content that may be included are:

• Photos of manual (paper) calculations for simple classical ciphers
• Diagrams illustrating attacks on ciphers, with explanation of why they are (not) successful
• Code segments that you used in testing a modern cipher
• Explanations of difficulties you had in understanding a cipher and/or its relation to others
• Links to and short summaries of websites/papers/software on ciphers and their attacks
• Challenges encountered and insights gained from implementing and applying ciphers, i.e. in the Security Project

You will be required to maintain your journal such that there is evidence of regular contributions. Your journal must be created on your private GitHub repository named "coit13240". The Unit Coordinator must be added as a collaborator.

The journal is an individual assessment worth 20% of the unit assessment. Your journal will be assessed on:

• Quality of contributions: 10 out of 20. E.g. the entries are clear, correct and demonstrate understanding of the topics covered, including progressive learning/improvement over the weeks.
• Novel insights: 5 out of 20. E.g. you provide insights or explanations that go beyond what is covered in the unit material.
• Regular, relevant, professional contributions: 5 out of 20. E.g. there are entries each week (as opposed to all added at the end of term), and those entries are relevant to the current topics in the unit. The journal must be maintained in a private GitHub repository shared only with the Unit Coordinator. The journal should use basic Markdown formatting; using just plaintext or upload a Word document to GitHub is insufficient.

This project involves you developing and applying a set of cryptographic tools, as well as analysing security issues and attacks. There are three topics, covering attacks, performance issues, and security protocols. Each topic (question) has several parts. You need to complete all questions and parts.

Some questions/parts will require you to investigate beyond what is covered in the unit lecture/tutors. You may need to read and summarise research papers, standards, technical reports and websites. Some questions/parts will require you to write software to complete a task. Your software must be implemented in Python. While examples of Python will be used during the unit, you may be required to learn advanced features to complete the software.

The project will be individual work. Aspects of the project, especially the software, may be discussed in class and on Microsoft Teams. The Unit Coordinator will facilitate/moderate discussion about the project.

You will be required to use GitHub to track your software development and document your project. Therefore you will need an account on GitHub. The use of an online collaborative software tracking tool will allow regular feedback on your progress, and sharing of code when appropriate. The details of using GitHub repositories and sharing code will be specified on Moodle. While your software and documentation will be stored on GitHub, you will still be required to submit files on Moodle when the assessment is due (e.g. export a Zip of the repository and upload to Moodle). This is necessary so that a permanent record of your contribution is available in Moodle (in case the online platform is not available in the future).

Each question/part will be marked based on the quality and technical depth of the answer. A detailed marking guide, with weights for each question, will be provided on Moodle.

Discussion style questions (e.g. explain, discuss, compare) will be marked on correctness, quality and depth. To achieve full marks in such questions, your answer will need to give significant technical depth to demonstrate excellent understanding of the issue. This may require you to research information not covered in the lecture or tutorial material.

Several tasks require you to design, implement and test features in Python. For these tasks, you will mainly be marked on your submitted code, however you also receive some marks for a brief explanation and demonstration of operation (e.g. test results). Submitting code that does not work (or not submitting any code) will usually result in 0 marks for that part, irrespective of the explanation and test results.

The primary criteria for assessing the code is functionality. That is, does it correctly do what it is supposed to do? Clarity of the code is also important, i.e. is the operation and code structure clear and easy to follow? Preference is for clarity over efficiency (e.g. run-time efficiency, coding efficiency). The provided demonstration and helper code is an example of clarity over efficiency (e.g. you will see code segments that are repeated for the purpose of clarity; it would have been more efficient to move the code into a separate function, but probably at the expense of clarity).