Advice on how to fail your CS 5430 project

Michael Clarkson
Based in part on "Advice:  What to Avoid in CS 413" by Andrew Myers

You might wonder how most effectively to fail at the CS 5430 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.

How to fail Phase II

  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 attacks 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 cite credible sources that provide solutions to the problems you face.  Be arrogant (or lazy) and assert that the scientific literature contains nothing related to your project.  Instead, cite a mixture of textbook chapters, industry magazines, and the course notes.  Be sure to state that you intend to do future research on what vulnerabilities exist in the commercial and open-source products you'll be using, ignoring the fact that this course is about principles, not products.
  6. 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).
  7. 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.  This also holds for Phases III and IV.
  8. Omit your netids and names in the document.  The course staff enjoys guessing these things.
  9. Do all your writing at the last minute, and don't spend any time editing your document, including:

How to fail Phase III

  1. Don't give protocol specifications showing each message, its contents, and the cryptography employed.  Also, don't use pseudocode to represent the algorithms you will employ.  This is an unnecessary level of detail that would only make it too easy to understand (and later implement) your system. 
  2. Don't use proper, consistent notation in your design document.  Believe that the key to getting a good grade is confusing yourself (and the course staff) as much as possible.
  3. Assume that encryption protects integrity of messages as well as confidentiality, because no clever attacker could ever undetectably corrupt an encrypted message.  Never use MICs or digital signatures, which are actually designed to protect integrity.
  4. Ignore the various attacks discussed during lecture (buffer overflow, SQL injections, etc.), and fail to specify how your system will defend against them.  
  5. Eschew the Gold Standard:
 

How to fail Phase IV

  1. Don't use proper, consistent notation in your implementation and presentation.  (Believe that the key to getting a good grade is confusion.) 
  2. 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.
  3. 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.
  4. Hardcode all constants, keys, account names, passwords, ports, etc.  It's true your CS 100 instructor told you not to do this years ago, but you know how to program now.
  5. 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. 
  6. Don't delete sensitive material (such as keys or passwords) from memory.  It's best to leave this to the garbage collector so that malware gets a fair chance at finding dead data in memory.
  7. Store private and secret keys in cleartext on disk.  Again, malware needs a fair chance.
  8. Don't defend against SQL injection attacks.  Especially avoid the PREPARE statement, and do handcode input santization routines that attempt to strip out (but almost certainly miss some) "bad stuff".
  9. Assume that clocks are always synchronized. (Why?  Because time travel isn't possible.  Nor could attackers ever skew your system's clock.)
  10. Assume that your implementation isn't vulnerable to DoS attacks.  In performance sensitive code, be sure to use blocking I/O, and ignore everything you've learned about multi-threaded programming.  Possibilities include not implementing thread pools, or using a single server thread for every request, or spawning a new thread for every request.
  11. 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.
  12. 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. 
  13. 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.