You will undertake three (3) in-class tests on Moodle throughout the term. Each test will cover topics from the weeks leading up to that test, and may include questions similar to earlier tests. Each test will consist of multiple-choice questions, short or long answer questions and/or calculations. Some questions may require the use of software and online systems (e.g. GitHub). There will be multiple independent questions in each test. All tests are individual assessment.

Each test will be time limited, typically allowing you between 30 and 60 minutes to complete the test. Some tests may be longer. 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: 4, 8 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).

Test 1 and 2 are worth 10% each; Test 3 is worth 20%.

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 shown 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 keep 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 have to maintain your journal such that there is evidence of regular contributions. Your journal must be created in a GitHub repository created using GitHub Classroom. As this is your own journal, you should not share with other students. The journal should use basic Markdown formatting (using just plaintext or uploading a Word document is insufficient). Details of creating the GitHub repository can be found on Moodle.

You are required to submit your journal early in the term (Draft Journal) so you can gain feedback on the suitability of your entries so far. The entire journal is then submitted towards the end of term (Full Journal).

The journal is an individual assessment worth 20% of the unit assessment. The Draft Journal, which contains only entries for the first several weeks, is worth 5%; the Full Journal, which contains entries for all weeks up until deadline, is worth 15%. If you submit the draft journal before the deadline, make a genuine attempt in the draft, and then make substantial improvements based on feedback, then your mark for the Draft Journal may increase when the Full Journal is marked.

Your journal will be assessed on:

• Quality of contributions. E.g., the entries are clear, correct and demonstrate understanding of the topics covered, including progressive learning/improvement over the weeks and reflections on learning.
• Novel insights. E.g., you provide insights or explanations that go beyond what is covered in the unit material.
• Regular, relevant, professional contributions. 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.

While the journal will be maintained on GitHub, you must also submit a ZIP of the journal on Moodle before the deadline. The ZIP file can easily be produced by exporting the repository in GitHub. 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).

This project involves you developing and applying a set of cryptographic tools, as well as analysing security issues and attacks.

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 may 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 a mix of group work and individual work. You will be required to form a group and complete some tasks together. You will also be required to complete some tasks on your own. Aspects of the project, especially the software, may be discussed in class and on Microsoft Teams. Each group will have a Teams channel that must be used for group communication. The Unit Coordinator will facilitate/moderate discussion about the project (including the group Teams channel).

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).

You will be required to give a presentation about your project. The presentation will be an opportunity for verbal feedback on progress; you will have an opportunity to make improvements after the presentation. If you do not satisfactorily explain your contributions to the project in the initial presentation, then you may be asked to give another presentation after submission of the project.

The project will be marked based on the quality and technical depth of the solution(s), as well as the ability to collaborate with others to arrive at the solution. A detailed marking guide, with weights for each part, will be provided on Moodle.

A part of your mark will be for group work, and the remaining will be individual. Note that even for group work, each member of the group may receive different marks.

The presentation is a required for the project. The mark for your project will be based on a combination of your presentation, any written reports, collaborative tool data (e.g. GitHub logs), and submitted artefacts (e.g. code, data files). If you do not present, then you cannot score more than 13 marks out of 40 for the project.

Several tasks may 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 criterion for assessing any 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).