University of Turku Cryptography Master’s Thesis Guide: DTEK1002, 30 ECTS, Security Proofs and UTUGradu

Quick answer: what is the University of Turku Cryptography thesis route?

The current University of Turku Cryptography specialisation track in the Master’s Degree Programme in Information and Communication Technology is a 120 ECTS, two-year Master of Science (Technology) programme. The current public programme page identifies the Faculty of Science, and the controlling 2024–2027 Peppi object is ICTCR2427 / programme 99368. The exact thesis is DTEK1002 Master’s Thesis in Technology, 30 ECTS, Advanced Studies, graded 0–5, with TTDK1308, 0 ECTS as the maturity examination. DTEK1002 requires thesis work to be presented in a related Master’s thesis seminar, but current Cryptography Peppi does not allocate a separate seminar credit, and an exact 2026–2027 generic seminar code is not independently confirmed. Confirm the current seminar instance with the supervisor or Department of Computing before enrolment.

1. Start from programme 99368, not a sibling ICT track

Cryptography is one of five ICT specialisation tracks. Current Peppi 99368 is the programme object that controls the 2024–2027 curriculum. Do not copy the thesis-support package from Cyber Security or a dedicated seminar code from Data Analytics, Software Engineering or Robotics. The shared parent programme explains some common Technology-thesis infrastructure, but each track still needs its own current curriculum check.

2. Read the 120 ECTS degree correctly

The public programme page defines a 120 ECTS degree. Cryptography contains 50 ECTS advanced major studies, a 20–25 ECTS thematic/minor module, 15–20 ECTS other studies and the 30 ECTS thesis. Peppi may display a 115–125 technical range because optional blocks are represented as ranges. That range is not a different degree size. Resolve the final combination through the current personal study plan.

3. The advanced-studies architecture is 50 + 30 ECTS

Peppi represents ISCCRAS2427 as an 80 ECTS Advanced Studies module. Inside it, the programme has 20 ECTS Cryptography, 20 ECTS Cyber Security and Security Management, 10 ECTS compulsory advanced mathematics and the 30 ECTS thesis category. This is useful when planning because the thesis sits inside the advanced-studies structure but remains its own assessed 30 ECTS course.

4. DTEK1002 is the exact current thesis course

The exact thesis object is DTEK1002 Master’s Thesis in Technology, 30 ECTS. It is Advanced Studies, can be completed in Finnish or English and is graded 0–5. Its purpose is not only to produce a long report. The student must demonstrate scientific work, research-method competence, command of the research field and scientific writing while addressing a defensible research challenge.

5. Cyber Security’s 10 ECTS thesis-support block does not transfer

The current Cyber Security track separately lists 10 ECTS Studies supporting Master’s thesis plus a 30 ECTS thesis. Cryptography does not. Cryptography’s public structure instead uses 50 ECTS advanced-major studies and the 30 ECTS thesis. Therefore, do not describe Cryptography as having a compulsory 10 ECTS thesis-support package merely because the sibling Cyber Security track does.

6. The seminar requirement exists, but its current code needs confirmation

DTEK1002 explicitly says the thesis achievements and process are presented in a related Master’s thesis seminar. The latest indexed generic DTEK1100 Master’s Thesis in Technology Seminar instance is Fall 2025–Spring 2026, and it covers thesis structure, research methods and presentations. However, programme 99368 does not list DTEK1100 as a credit-bearing child, and I could not independently verify a DTEK1100 2026–2027 instance. Follow the seminar process, but confirm the current course instance with your supervisor or Department of Computing and do not invent extra ECTS.

7. Build the thesis plan with the assigned supervisors

DTEK1002 requires a plan at the beginning of the thesis, created with the assigned supervisor or supervisors. The plan should make the research problem, cryptographic object, security notion or system target, methods, evidence type and expected output explicit. If the project is mathematical, identify definitions, assumptions and proof goals. If it is implementation-focused, define the platform, threat model, evaluation protocol and reproducibility strategy.

8. Understand the supervision and examiner chain

When seeking a thesis topic, DTEK1002 directs the student to contact a professor of the main subject so supervisors can be assigned. Company or organisation projects are possible, including company co-supervision, and a University research-group thesis is also possible. The thesis is evaluated by at least two examiners. Final acceptance and grading are decided by the head of the department based on the examiner evaluation.

9. TTDK1308 is the 0 ECTS maturity examination

The current thesis category also contains TTDK1308 Degree Qualifying Examination for Master’s Degree, 0 ECTS. Normally the thesis abstract or another suitable thesis part functions as the maturity test and demonstrates knowledge of the thesis field. The course contains a conditional written-exam rule for some students depending on prior degree and Finnish/Swedish educational-language background, so check the current requirement for your own case instead of copying another student’s route.

10. Choose the evidence type before choosing the result language

Cryptography theses can be theorem/proof projects, cryptanalytic studies, implementation/security-engineering projects, protocol analyses, benchmarking studies or combinations. These evidence types support different verbs. A formal reduction can support a security theorem in a stated model. An attack search can identify weaknesses but a failed search does not prove security. A benchmark can support performance claims but not mathematical security. Label the evidence type before writing the conclusion.

11. Define the security notion and adversary precisely

A security claim needs a defined property. Confidentiality, integrity, authenticity, unforgeability and privacy are not interchangeable. State the adversary capabilities, information available, query model, success condition and security parameter. “Secure against attackers” is usually too broad for a thesis claim. The clearer the game, experiment or formal notion, the easier it is to see whether the proof or evaluation actually answers the intended question.

12. Separate correctness from security

A cryptographic construction can be functionally correct and still insecure. Correctness asks whether legitimate algorithms produce the required result, such as successful decryption or verification. Security asks whether an adversary can violate a stated property under a defined model. Test both layers separately. Do not treat passing functional test vectors as evidence that confidentiality or unforgeability has been proven.

13. State every material assumption behind a proof

Provable-security work is only as interpretable as its assumptions and model. If a theorem relies on a computational hardness assumption, state it. If the analysis uses an idealised oracle or other abstraction, state that too. A proof under an assumption is not unconditional security. The thesis should make clear which statement is proven, under which assumptions, and which implementation or deployment questions remain outside that theorem.

14. Make reduction arguments auditable

For a reduction proof, define what the reduction receives, what it simulates, how it uses a successful adversary and how that produces a contradiction or solves the underlying hard problem. Track probability and complexity losses when they affect the claim. If the thesis presents only a proof sketch, label it as such rather than silently omitting difficult cases. A reviewer should be able to trace the logic from security game to final bound.

15. Treat counterexamples and failed proofs as valid evidence

A thesis does not need the originally hoped-for theorem to succeed. A counterexample, boundary case or demonstration that a proposed argument fails can be an important result. Preserve failed proof routes when they reveal a hidden assumption or motivate a corrected statement. Scientific integrity is stronger when the final theorem is narrower but true than when a broad unsupported claim is maintained because it was the original plan.

16. Cryptanalysis needs an explicit attack model

If the thesis searches for attacks, define the primitive or protocol version, attacker capabilities, target property and success criterion. Also report relevant complexity dimensions: time, memory, data or query requirements and success probability. A theoretically valid attack may still be operationally infeasible. Conversely, implementation behaviour can create practical weakness even when the abstract primitive remains mathematically sound.

17. “No attack found” is not a security proof

Empirical cryptanalysis can provide useful negative evidence, but failure to find an attack is not equivalent to proving none exists. Report the explored attack families, parameter ranges, computational budget and stopping criteria. Bound the conclusion to what was actually tested. This distinction is especially important when automated search, SAT/SMT methods, heuristic optimisation or machine learning is used to explore a very large attack space.

18. Separate primitive security from implementation security

MATE5397 explicitly includes implementation attacks. A side-channel leak, timing problem or fault-induced weakness may break a specific implementation without breaking the abstract algorithm. Conversely, a proof about an ideal primitive does not prove that compiled code on a particular platform is safe. State whether the thesis is evaluating the mathematical construction, the implementation, or both, and keep those conclusions separate.

19. Benchmark cryptographic implementations on comparable security levels

Runtime, throughput, latency, memory, key size and ciphertext/signature size measure different costs. Before comparing two schemes or implementations, align functionality and security level. A faster result obtained by weakening a parameter is not a fair improvement. Report hardware, operating system, compiler/interpreter, library versions, parameter set, workload and measurement protocol so another researcher can understand what the benchmark actually means.

20. Control measurement noise and benchmark bias

Fast cryptographic operations can be sensitive to CPU frequency changes, warm-up, caching, background load and timer resolution. Use repeated measurements and describe aggregation. Avoid selecting only the fastest run. If development decisions were repeatedly tuned against the final benchmark workload, acknowledge that the result may be optimistic. A microbenchmark also should not be described as end-to-end application performance unless the application path was measured.

21. Protocol security is a composition problem

A protocol can use individually strong primitives and still fail because of message ordering, key management, state, replay, identity binding or composition. Define roles, trust assumptions, key lifecycle and attacker capabilities. If the thesis proves or tests a protocol property, make clear which components are idealised and which are implemented. Do not infer whole-system security merely from the fact that AES, RSA, elliptic curves or another standard primitive appears somewhere inside it.

22. Zero-knowledge and secret-sharing claims need precise properties

Cryptography II covers secret sharing and zero-knowledge proofs. For secret sharing, distinguish reconstruction from privacy thresholds and adversary assumptions. For zero knowledge, distinguish completeness, soundness and the particular zero-knowledge property being claimed. If the thesis implements a protocol, demonstrate functional behaviour separately from the formal argument. Performance measurements cannot replace the proof of the stated security property.

23. Post-quantum cryptography needs parameter-specific claims

The programme lists post-quantum cryptography as a possible thesis field. Do not make a security statement from the algorithm-family name alone. Identify the concrete parameter set and the intended security level/category. If performance is compared, include the costs that matter for the scheme such as key, ciphertext or signature size alongside runtime. Quantum resistance to known attacks is not unconditional security, and implementation side channels remain possible.

24. Preserve software and experiment provenance

Freeze the code revision, experiment configuration, important library versions and parameter set that generated the final result. If randomised experiments are used, preserve seeds or a reproducible seed policy where disclosure is safe. Do not overwrite the only copy of a “best” result after each run. A lightweight experiment manifest linking data/test vector, code revision, parameter set and output makes later thesis corrections much safer.

25. Use official or clearly defined test vectors

Reference test vectors are useful for checking functional consistency and regression. Record their source and the exact algorithm version/parameter set. Passing them proves only the properties those vectors test. It does not establish resistance to side channels, misuse, active attacks or implementation-specific vulnerabilities. If custom vectors are generated, preserve the generation method and avoid embedding real secrets merely for reproducibility.

26. Treat external libraries as part of the method

If a thesis uses OpenSSL, a post-quantum library, a theorem prover, a symbolic verifier or another dependency, record the version and relevant configuration. Security and performance can change across versions and build options. If the library performs preprocessing, key generation or constant-time operations internally, do not describe that behaviour as your own implementation unless you actually implemented and validated it.

27. Evaluate detection/security systems with the right denominators

The programme also includes system/application security and firewall/IPS work. For empirical detection studies, report what constitutes a positive/negative event, how traffic was sampled and how train/development/evaluation data are separated. False positives and false negatives have different operational consequences. Performance on a controlled lab dataset does not automatically establish performance on a production network with different traffic, configuration and attack distribution.

28. Keep authorised security testing inside the agreed scope

A thesis may analyse vulnerable systems, network controls or implementation weaknesses, but the academic goal does not create permission to test arbitrary third-party systems. Use authorised environments and follow the host organisation’s scope, permits and data rules. The public thesis can explain the scientific method and findings without publishing unnecessary operational detail that would create avoidable risk to a live system.

29. Confidential company security material needs an early publication plan

DTEK1002 allows company/organisation thesis projects. Before analysis begins, identify whether source code, configurations, vulnerability details, keys, logs, business information or embargoed findings are confidential. The accepted thesis enters institutional examination and publication/archiving processes, so decide what can appear publicly before writing figures and appendices. Confidentiality should shape the disclosure plan, not emerge as a crisis at final submission.

30. Security telemetry can be personal data

Network logs, account identifiers, device IDs, authentication events and incident reports can contain personal data. Removing obvious names may not make the dataset anonymous if users or devices remain linkable. Use only the data needed for the research purpose, keep access controlled and separate public examples from protected raw records. Data governance applies even when the thesis is mainly about algorithms or systems.

31. Pure mathematics and operational security do not have the same ethics profile

A purely mathematical proof thesis does not automatically require human-subject ethical review. A study involving real users, sensitive logs, behavioural security experiments or intervention in live systems can raise different ethical, privacy, permission and legal questions. Resolve the route from the actual design, not from the word “cryptography.” A host-organisation research permit, where required, is also not a substitute for every other applicable control.

32. Use generative AI under the DTEK1002 disclosure rule

DTEK1002 explicitly allows generative-AI tools in the thesis process but requires their use to be documented clearly enough that the student’s own work can be identified and graded. That is particularly important for proofs, code and references. Verify generated mathematics line by line, run generated code, check citations against original sources and never upload confidential keys, logs, source code or partner material to an uncontrolled service.

33. Turnitin checks originality, not cryptographic validity

Turnitin is part of the University thesis originality workflow. A low similarity score does not prove that a security definition is appropriate, a theorem is correct, an implementation is constant-time or a benchmark is unbiased. Treat originality, research integrity, formal correctness and empirical validity as separate quality controls. All still need to pass.

34. UTUGradu is the final institutional route

UTUGradu manages higher-degree thesis submission, examination, approval and electronic publication/archiving. Before upload, confirm that the final manuscript corresponds to the examiner-ready version, confidentiality has been resolved and the required originality process is complete. Recheck current UTUGradu operational instructions at submission time because interface/process details can change independently of the 30 ECTS thesis rule.

35. A practical proof-oriented thesis workflow

For a proof-focused project: define the cryptographic object and security notion, map prior results, state assumptions, formulate the theorem, test small cases/counterexamples, develop the proof, check probability/complexity bounds, obtain supervisor review and only then broaden the interpretation. If computational support is used, preserve scripts and clearly distinguish computer-assisted evidence from the hand-proved part of the argument.

36. A practical implementation thesis workflow

For implementation work: define target scheme and security level, choose platform, build functional tests, freeze benchmark and security-test protocols, implement with version control, verify against reference vectors, profile performance, run authorised implementation-security checks, analyse failures and preserve configuration. Separate engineering artefacts from the scientific question so the thesis explains not just what was built but what was learned from building and evaluating it.

37. A practical cryptanalysis workflow

For cryptanalysis: define target/version/parameters, formalise attacker capabilities, review known attacks, specify the new hypothesis, implement or derive the attack, validate on controlled cases, measure complexity and success, compare with the best relevant baseline and report both positive and negative findings. Avoid turning a limited experiment into a universal “secure/insecure” conclusion when the tested attack family covers only part of the threat space.

38. Freeze the final claim-to-evidence map

Before submission, create a small table linking each headline conclusion to its evidence type: theorem/proof, attack derivation, experiment, benchmark, test vector, system evaluation or literature synthesis. Write the strongest defensible verb beside it. This catches category errors such as using a speed benchmark to imply security, using a failed attack search as a proof, or using a formal proof to imply side-channel resistance of an implementation.

39. Reproduce one headline result from scratch

From a clean checkout or controlled environment, regenerate at least one central theorem check, attack result, benchmark table or figure from the documented inputs. Confirm that units, parameters, software version and final manuscript numbers match. If manual steps remain, document them. This spot-check often exposes stale figures, changed parameters or hidden notebook state before the examiner does.

Before calling that reproduction successful, compare the regenerated artifact with the frozen manuscript source rather than only checking whether the script completes. A result can be reproducible yet still use the wrong parameter set, stale test vector, previous library build or different aggregation rule. Record any acceptable tolerance for timing measurements and investigate material differences instead of manually forcing the table to match.

40. Final Cryptography checklist

Confirm ICTCR2427 / programme 99368, the 120 ECTS degree, DTEK1002 30 ECTS, 0–5 grading, TTDK1308 0 ECTS, at least two examiners and department-head final acceptance/grading. Follow the required thesis-seminar process but confirm the current seminar instance because a 2026–2027 DTEK1100 code is not independently verified and no extra seminar credit appears in programme 99368. Then audit the security notion, assumptions, threat model, reproducibility, authorised testing, confidentiality, AI disclosure, Turnitin and UTUGradu route.