| ITEC 345 |
| 2014fall |
| ibarland |
|
|
|
home—lects—hws
D2L—breeze (snow day)
In all cases, bring a hardcopy to class, and submit on D2L.
Pick a topic to research, and write a report (4-6 pages long) on that topic. I have provided a few sample topics below, however I encourage you to consider other security-related topics as well. The report must closely adhere to the format of an IEEE research paper, including citations. A sample format in MS word is available.
Warning:This format is extremely dense: five pages in this format might be the equivalent of ten pages in usual formats.
Be sure your paper is informative, specific, and well-written. You (or a lucky roommate) should give it a close read just before submitting, to catch any grammatical errors, missing words, inconsistent verb tenses, and the like. Ask the reader to tell you something specific that they learned from your paper (and, have in mind something that you hoped they learned, that they didn't know before).
Include a bibliography with at least two original (non-Wikipedia) sources. Citing web sources is okay (but at least one non-web source is preferred when possible). Your paper’s bibliography does not contribute toward the page count.
Here is what is expected for each of the deadlines above:
Note that the top-level items of your outline will presumably become sections of the paper, sub-items will be expanded into subsections, and sub-sub-items (if any) might correspond to individual paragraphs, in the final version.
Bring hardcopy to class, and submit a copy on D2L.
(10%) Draft: This is to make sure that you are making steady progress (and not leaving everything for the last week). It should have all sections-headers, corresponding to a clear logical structure (based on your outline), even if some of the sections are still empty. The exact text/examples will be rough and incomplete in parts, but should have progress in some of the non-introduction sections. The paper should be in the proper format, and , at least a third of the final length, or more.
Bring hardcopy to class, and submit a copy on D2L.
Details: Have your paper submitted on D2L (with both pseudonym and your name). Bring to class a hardcopy, with only your pseudonym on it. I will be re-distributing those hardcopies to your peer.
This grade will just be one of 0%/25%/50%/75%/100%:
100% if you turn in something that could be close to a final
version (even if you end up revising it);
75% for something that is short of a final version, but is still
strong;
50% for something that that is full of typos and poor writing
and is painful for your peer to read;
0-25% for something that is falls far short of a final version
(e.g. only one page...).
Your feedback will be returned to the author in class on Friday (after I acknowledge it); this means getting it to me the day before.
Mark up the hardcopy distributed to you, and return in class on Wed. (or under my office door by Thu. 10:00) with the items A-E below, written on it.
Read the paper, marking (on the hardcopy) awkward sentences and typos (incl. “its”/“it's” and “their”/“they're”/“there”). It's not you're job to catch all typos, but you should give the paper a close read. For example, if there is a half-sentence which is filler that would actually strengthen/focus the writing if it were omitted, strike it through. You are encoruaged to to use standard proofreading marks.
Summarize with the following 5 points (written on the hardcopy).
For B,C,D, just rate how much you agree with the sentence:
5: Agree strongly, 4: Mostly agree, 3: Kinda agree,
2: kinda disagree, 1: mostly disagree, 0: disagree strongly.
- Reviewed by: ru245zz
- 4
- 2
- 4
- Good structure, but Section 4 felt kind of tacked on; maybe motivate it more, showing how it really is a variation on the overall theme? Interesting topic!
Note that your feedback does not actually contribute to the author's grade — it contributes to yours! You'll get 5% of your grade based on if your evaluation is fairly close to mine2. The purpose of having you review another's paper is to: (a) help them improve their paper, and (b) perhaps give you an improved perspective on your own writing.
(65%) Polished version: Based on feedback from your peer, you may revise your paper as needed. (Of course, if you feel your peer's suggested feedback would weaken your paper, you're free not to take it.)
Btw, be sure there are no typos in your title — I saw a number of titles that were slightly off, and the peer reviewer didn't necessarily catch/comment on it.
Bring hardcopy to class, and submit a copy on D2L.
In all cases, giving specific details and concrete examples and techniques is more important than giving general-but-nonspecific overviews.
For example, rather than saying: “Email is insecure, because messages can be forged.” instead, explain how it can be forged:
Email using SMTP doesn’t require authentication: it can be forged. The SMTP server receiving a message simply receives a string stating who the message is purportedly from; anybody connecting to the SMTP server can provide any message and claim any originator.Even better, demonstrate your point, perhaps including an appendix with a sample SMTP exchange, with the sender’s text in green, and the SMTP server’s output in black:
220 rucs.radford.edu ESMTP Postfix (Ubuntu) MAIL FROM:imposter@doppelganger.com 250 2.1.0 Ok RCPT TO:victim@gmail.com 250 2.1.0 Ok DATA 354 End data with <CR><LF>.<CR><LF> subject: help As a Nigerian prince, I demand your bank account number! . 250 2.0.0 OkThe first version doesn’t necessarily demonstrate any understanding, while the second version explains and specifically demonstrates why.
Similarly: Rather than just say loosely “DES is insecure”, be more precise:
An attacker can break DES with a brute-force attack: the 56-bit key has 256 ~ 72 quadrillion possible values. Although this is very large, it is on the edge of feasible: a network of 1000 students, using off-the-shelf desktop computers (3GHz processors), each taking 100 cycles to do each the 16-rounds of DES, could crack any key within 1.2yrs.
If you find yourself using terms like “can hack into” and “highly insecure”, strive to give concrete examples instead.
A good approach to guard against plagiarism is to keep an hour (or better, one day) between reading and writing. That is, read various sources, and take brief notes. Then wait a day, letting the concepts stew. After that, sit down and try to clearly explain the important issues and concepts. If you find yourself getting stuck, or can't remember specific facts, go back and read but (again) wait a day before resuming that part of the writing.
Even if you don't use Word/OpenOffice, you might want to paste your document into Word just to look for red and green grammar errors/warnings. Also, be sure to scan specifically for common mistakes: “its”/“it's”; “to”/“too”; “their”/“there”/“they're”.
If a roommate or friend is also working on a paper, swap proofreading with them. (You can also give them feedback on what is unclear, too wordy, etc..)
When appropriate use bulleted lists (or enumerated lists, where the order is important). Using sub-sections can also help reveal the structure of your thinking.
Possible resources: 1. the comp.risks forum 2. the websites mentioned in class, for monitoring security issues. 2. Websites such as slashdot.org, reddit.com (/r/netsec, /r/ComputerForensics), Wired.
One possible resource: Malware: Fighting Malicious Code by Ed Skoudis and Lenny Zeltser (book available on safari catalog in the library).
A couple of possible resources:
A couple of resources:
Resources:
Resource: textbook.
Resource: http://insecure.org/stf/smashstack.html
Task: Give an example of a “microbitcoin” example where you work through the exact math, except everything is just 3 digits (mod 1000): coins are merely 3-digit numbers, and (for example) person#i’s public key might be “multiply a message by the i’th prime number that doesn’t contain a multiple of 2 or 5; take that result mod 1000”. That is, person#1 mutiplies by 3 mod 1000; person#2 by 7, and person#3 by 11. Using something like that, then work through the exact steps involved with person#1 selling coin#99 to person#2, who in turn sells it to person#3. What is the resulting coin, exactly?
Resources:
This happens to be the lecture-outline for the Cryptography portion of the class. That covers several weeks worth of lectures, so it's more deeper than a term paper's outline would be, but it exemplifies the structure and detail that an outline should have.
- Crypto:
I. Symmetric
- Framework: math notation.
- substitution ciphers: confusion
. example: caesar; shifting: key-space = 26
. substitutiong ciphers; key-space = 26!
how big is 26! ?
brute-force vs other ways to break
. pseudo-random generators
. 1-time pads
- diffusion
. example: column ciphers
- use both conf, diff:
. DES
. 2DES (weak); 3DES; AES
II. Asymmetric
- symmetric wants KDC
- public-key: motivate/make-plausible
- RSA algo
- security of RSA: hinges on factoring
III. Hashing
- define hash fn
- uses for hash functions
- in CS
- in crypto
- some non-secure examples
- desired properties
weak collision avoidance
strong collision avoidance
- demo: md5
- good current algs
Goal 1
Radford University students will demonstrate competency in critical reading, standard written English, audience-specific writing, clear and effective prose, and other elements of composition.
Radford University students will be able to:
Goal 3:
Radford University students will learn to distinguish knowledge from opinion, challenge ideas, and develop reasonable strategies for belief formation.
Radford University students will be able to:
1 You may also use your real-name, if you want. Note that your comments will not affect the author's grade, as discussed below. ↩
2Of course, I'll take into account the differences between the author's polished version and the version you read. ↩
home—lects—hws
D2L—breeze (snow day)
| ©2014, Ian Barland, Radford University Last modified 2014.Nov.28 (Fri) |
Please mail any suggestions (incl. typos, broken links) to ibarland  radford.edu |
 |