Skip to main content

Advice on how to fail your CS 5430 project

You might wonder how most effectively to fail at the course project. The best advice we can give on this is: Don't use any of the material you learned in this class. This works best if you don't attend class at all, since it avoids any risk of polluting your mind with the course material. (Woody Allen said: "90% of success is just showing up".)

But for those seeking more specific advice on how to fail, we offer the following.

  1. Don't clearly state what security properties your system intends to satisfy. And if you do state them, don't use the terminology of Confidentiality, Integrity, and Availability. This would only serve to make it clear that your project is worthy of being a term project in a security course.
  2. Use security terminology (threat, confidentiality, authorization, etc.) inconsistently with the way it is defined in lecture.
  3. Don't clearly define the threat model and capabilities of your adversary. It's best just to assume that everyone shares your implicit assumptions about what kinds of threats you defend against.
  4. Require trusted, approved software components implementing the protocols you have in mind. This is related to the previous strategy, since it implies that attackers could never (e.g.) implement their own malicious clients that cheat in your protocols.
  5. Don't specify exactly which software components you will build yourself and which components you will build upon. Leaving this information out makes the apparent difficulty of your project greater (e.g., you'll build a DBMS yourself).
  6. Use a smaller font size than required, use unreasonable margins and line spacing, and exceed the page limit. The more information you can cram into the document the better.
  7. Omit your netids and names in the document. The course staff enjoys guessing these things.
  8. Do all your writing at the last minute, and don't spend any time editing your document, including:
    • Making sure all terms are well-defined,
    • Dividing your document into logical sections,
    • Including diagrams as appropriate.
  9. Don't use proper, consistent notation in your documents. Believe that the key to getting a good grade is confusing yourself (and the course staff) as much as possible.
  10. Assume that encryption protects integrity of messages as well as confidentiality, because no clever attacker could ever undetectably corrupt an encrypted message. Never use MACs or digital signatures, which are actually designed to protect integrity.
  11. Eschew the Gold Standard:
    • Don't specify the authorization policies you will employ. Or, specify policies that are either trivial or draconian.
    • Don't specify how users will authenticate, or use weak authentication methods based on low-entropy or spoofable secrets. If keys or passwords are employed, don't specify where or how they will be stored.
    • Don't use audit logs. But if you do use them, make sure their confidentiality and integrity are not protected, so that malware and malicious users can cover their tracks.
  12. Don't use proper, consistent notation in your implementation and presentation. (Believe that the key to getting a good grade is confusion.)
  13. Don't know what encryption mode you are using. If you do know, make sure it's ECB so that it's vulnerable to as many attacks as possible.
  14. Don't use a secure random number generator. It's much more entertaining for the course staff when you attempt to claim that your default RNG (probably a linear congruential generator; if you don't know what this is, go directly to Knuth vol. 2, do not pass Go, do not collect $200) produces unpredictable values.
  15. Hardcode all constants, keys, account names, passwords, ports, etc. It's true your CS 1 instructor told you not to do this years ago, but you know how to program now.
  16. Don't put any thought into key or nonce lengths. The default values provided by your crypto library are always best. If you want a rationale for such lengths, never consult a cryptographic authority (such as NIST) for recommendations. It's much better to make up a number or find one recommended "on the web, somewhere." If you happen to pick a key length that your crypto library doesn't seem to support, assume that it's a bad choice and don't consult any documentation, or even the course staff. Crypto libraries are, after all, always easy to configure correctly.
  17. Store private and secret keys in cleartext on untrusted disks. Malware needs a fair chance.
  18. Assume that clocks are always synchronized. (Why? Because time travel isn't possible. Nor could attackers ever skew your system's clock.)
  19. Don't produce and execute a test plan. And if you do produce a plan, don't attempt to achieve full code coverage. Everyone will place more trust in your code if your testing is merely ad-hoc. Be particularly careful to test a distributed system only on a single machine, so that network and concurrency issues can't rudely interfere.
  20. Don't budget time solely for testing the working executable and improving the quality of the source code and documentation. These are issues best left for the last hour before your demo.
  21. Leave writing your demo talk until the last hour, and don't rehearse it. Plan on exceeding the time limit so that the course staff has no chance to see your demo or ask you questions. And be sure to fill your slides with so much text that they can't be read from 5 feet away.

General advice on how to fail group projects

This advice is applicable to other classes, not just CS 5430.

  1. Designate one person in your group as the master hacker and have her do all the work. That way she will burn out 3/4 of the way through the course and no one else will be able to finish the project since only she understands it.
  2. Decide that one member of your group is useless and don't invite him to group meetings.
  3. Combine techniques 1 and 2: decide that all the other members of your group are useless and you are the lone master hacker. Charge off and code everything up without talking to anyone else. Unless you are very unlucky, you'll make some bad assumption that forces all your code to be thrown out anyway.
  4. Have everyone implement separate pieces of the system with no discussion of how they will fit together. Ideally, split the group into two or more factions that don't really talk to each other until just before the assignment is due. Then there is no chance you will be able to glue the ill-fitting pieces together.
  5. Opposite of #4: Work extremely closely all the time, spending all your time talking among yourselves rather than doing actual implementation; the group will slow down to at most the speed of one person. For extra effectiveness, everyone simultaneously edits different files in the same directory. That way, the whole system never works at any given time because something is always broken; also, you can't figure out which of four entirely different untested modifications are causing the current bug.
  6. For an additional bonus, forsake any versioning system, and manage your files by sharing your directories. Once your project grows in size, you'll have no idea who has the most up to date files or which directory contains the fixed version. With any luck you'll turn in the that copy you hacked out yesterday that broke half the previous code.
  7. Don't start working until three days before the due date. Then pull three all-nighters in a row. With luck, you will get sick and blow some other classes too!
  8. Don't ask the course staff any questions when problems come up; just put off working on the project and hope the problems will magically solve themselves before the due date.

Acknowledgement. The general advice above originates from Prof. Andrew Myers.