Heh...I know he doesn't. It was a reference to an overly-used phrase Post-9/11:
"Why do you hate America?
From Encyclopedia Dramatica
Also known as "why do you hate freedom?," this is the only correct response to any statement which implies the the United States might be responsible for something."
I think that steg provides the opportunity to increase security of already existing crypto. Wouldn't it be plausable to take already encrypted data, and then hide it? Sure, it's not foolproof, but it's no worse than having the encrypted data sent as is.
At the same time however, it seems like steganography has some inherent flaws in it. That is to say, the more people use is, the quicker people will be able to determine patterns in the method. This would allow people/groups/countries/etc. to find the message faster. Doesn't sound like too reasonable of an idea.
Additionally....I'd be interested to see what DJB has to say about steganography...
So as it turns out, DJB actually had some sympathy for us, and decided to base our grades on how much we actually learned from the course. C|net writes that "At the end of the course, [DJB] decided to throw that scale away and think about how much the students had learned." This was also reflected in our final grades for the course. Whew.
For the most part I agree, DJB is an excellent teacher and I do feel that I have learned a lot from his class. However, I feel that what I learned was not directly related to discovering security holes. While seemingly okay (being a course about security, not finding holes), it's flawed in that 60% of the grade was based on finding these holes. For my part, I didn't drop the class because a) I sincerely thought that I would be able to get enough holes to pass, and b) dropping the course would put me into part-time status, which I did not wish to do.
Are you under the impression that *nix-based software doesn't have security holes? If so, you're wrong. Look at pretty much any changelog, you'll find things about security holes being fixed. The difference is that many people discover these over time. When all the students in the class are required to find 10 holes each (as mentioned earlier n people working on a bug will earn each of them 1/n credit), it makes it more difficult. It's not to say this task was impossible, but given the timeframe and other work expected of us (i.e. other classes), it proved to be too much at once.
yeah, but no one other than we the students are aware that the class was taught by DJB (i.e. transcripts do not say "MCS 494; Bernstein, D.J"). Also, I feel that DJB would have allowed us to drop the course, yet keep going. In retrospect, I wish that's what I did
Yeah, but as noted above, it has to be deployed UNIX software. And giving it to a couple of your buddies doesn't count as being deployed. Hits on google indicating use or being distributed in BSD ports counts as being used. DJB was more focused on the holes being in existing software, rather than what types of code will actually have a hole.
Heh...I know he doesn't. It was a reference to an overly-used phrase Post-9/11: "Why do you hate America? From Encyclopedia Dramatica Also known as "why do you hate freedom?," this is the only correct response to any statement which implies the the United States might be responsible for something."
Why do you hate freedom? ;-)
I think that steg provides the opportunity to increase security of already existing crypto. Wouldn't it be plausable to take already encrypted data, and then hide it? Sure, it's not foolproof, but it's no worse than having the encrypted data sent as is.
At the same time however, it seems like steganography has some inherent flaws in it. That is to say, the more people use is, the quicker people will be able to determine patterns in the method. This would allow people/groups/countries/etc. to find the message faster. Doesn't sound like too reasonable of an idea.
Additionally....I'd be interested to see what DJB has to say about steganography...
So as it turns out, DJB actually had some sympathy for us, and decided to base our grades on how much we actually learned from the course. C|net writes that "At the end of the course, [DJB] decided to throw that scale away and think about how much the students had learned." This was also reflected in our final grades for the course. Whew.
Looks doubtful. His MCS 590 (High-speed crypto) class already has 9 people signed up, and i have a feeling there will be more.
For the most part I agree, DJB is an excellent teacher and I do feel that I have learned a lot from his class. However, I feel that what I learned was not directly related to discovering security holes. While seemingly okay (being a course about security, not finding holes), it's flawed in that 60% of the grade was based on finding these holes. For my part, I didn't drop the class because a) I sincerely thought that I would be able to get enough holes to pass, and b) dropping the course would put me into part-time status, which I did not wish to do.
Are you under the impression that *nix-based software doesn't have security holes? If so, you're wrong. Look at pretty much any changelog, you'll find things about security holes being fixed. The difference is that many people discover these over time. When all the students in the class are required to find 10 holes each (as mentioned earlier n people working on a bug will earn each of them 1/n credit), it makes it more difficult. It's not to say this task was impossible, but given the timeframe and other work expected of us (i.e. other classes), it proved to be too much at once.
yeah, but no one other than we the students are aware that the class was taught by DJB (i.e. transcripts do not say "MCS 494; Bernstein, D.J"). Also, I feel that DJB would have allowed us to drop the course, yet keep going. In retrospect, I wish that's what I did
Unfortunately, the CVS version's exploits wouldn't have counted, because it wouldn't be the "packaged" version...DJB was pretty picky about this.
Yeah, but as noted above, it has to be deployed UNIX software. And giving it to a couple of your buddies doesn't count as being deployed. Hits on google indicating use or being distributed in BSD ports counts as being used. DJB was more focused on the holes being in existing software, rather than what types of code will actually have a hole.