7 ms·
From 0 to cryptography
- deleted 14y ago[deleted]
- vinitool76 14y agoSite down?
- de1978st 14y agoGreat Link, thank you.
- tptacek 14y agoIf you thought this link was useful, I'd be interested in knowing why.
- experiment0 14y agoI'm interested in knowing why your post implies that its not useful. I would like to know if its worth reading as I've just added it to Read It Later. EDIT: Please correct me if you didn't mean to come across that way, it's just the last comment on the blog: > this post is just terrible. i don't understand why people feel the need to learn a tiny bit about a subject, and regurgitate their misunderstandings through blogging. please take it down, you are making the world a worse place. has made me wary.
- tptacek 14y agoI'm asking seriously, not just to make a point.
- randartie 14y agoNot sure what your problem is with the article, it's a basic intro article. Clearly the people that find it useful are the people who do not know the material and don't need to deal with this on a regular basis.
- tptacek 14y agoSo I'm curious what you do with a basic understanding of, say, the RSA math.
- Mercury23 14y agoSome things are worth knowing just out of curiosity. I always found the RSA algorithm fascinating in its own right, despite the fact I have no intention of ever implementing it myself. I'm not a mathematician nor a computer scientist, but I find an appreciation of certain algorithms not unlike the appreciation of art. Pointless in a pragmatic sense, but intellectually satisfying. I can't speak for this article specifically though; I think there are better explanations out there, not to say that this one is bad. It is a difficult topic to explain after all, especially when you don't know the level of math background your audience has.
- dvanduzer 14y agoFor one thing, it's just plain wrong about Diffie-Hellman's susceptibility to a man-in-the-middle attack. The author claims there is a potential if an attacker obtains the intermediate values, but then later explains the problem as if the attacker had intercepted the private values (which are never exchanged). There is the potential for man-in-the-middle if the attacker intercepts and modifies the intermediate values during the exchange, but that is not mentioned here. It is, of course, vital to keep those privately generated values secret, and if an attacker learns those, then the communication isn't secure. Various communication protocols are vulnerable to brute force, or eavesdropping, or man-in-the-middle. Confusing these things and passing it off as an authoritative explanation is bad for everyone.
- deleted 14y ago[deleted]
- dvanduzer 14y agoI really like the paint metaphor + graphic. It takes a lot of effort to find explanations that work so well when explaining computing concepts to novices or people without a deep interest in mathematics. We need more of that. Granted, it's from Wikipedia, but I didn't know about it until now. Unfortunately, the explanation contradicts itself pretty quickly when discussing man-in-the-middle scenarios for D-H. So it was useful in that it prompted me to find out where the author went wrong.
- lhnn 14y agoWhat's WRONG with it? > When disagreeing, please reply to the argument instead of calling names. You're implying the article is useless, and that it shouldn't be here. Justify that, if you're going to go through the trouble of making a post.
- tptacek 14y agoI'm asking a question. Did you think the article was useful? I'm interested in why.
- zainny 14y agoNow I'm interested in why you're interested in knowing why people thought the link was useful. If you have an opinion about the post in question, why not just state it?
- jakejake 14y agoAlthough I initially thought it was meant as an insult towards the beginner nature of the article... taking a look at Tptacek's profile would lead me to believe he is interested in meeting people with skill and interest in security and encryption, maybe for employment purposes. Don't leave us hanging, am I right?!
- alinajaf 14y agoRemember this? http://vimeo.com/9260794 http://vimeo.com/9260794 Somehow found myself watching it a few weeks ago. In it the biggest realisation I had was that I would have been just as likely as the developers at flickr, vimeo etc at punching in `sha1(secret_key + 'foobarbarbaz')` for computing a MAC. Thus began my foray into cryptography. My reading list is a little backlogged but 'Cryptography Engineering' is bubbling its way to the top. My biggest takeaway so far is to just stay the hell away from crypto, but I work with other developers on big codebases, so I need the knowledge firepower to convince them to stay the hell away from crypto. That being the case, there wasn't much I wasn't familiar with in the article, but since I'm a crypto newbie it was nice to go over those concepts again.
- ubernostrum 14y agoThis article, I'm not such a fan of because it's poorly written and doesn't really cover much. In general, I'm a fan of having the average developer know something, and in general I want that "something" to be: 1. Here's some basics on how crypto works 2. Here's some basics on how it gets broken 3. Here's how you can screw up even with well-designed systems 4. Here are some solid things that will see you through if you use them correctly (plus how to use them correctly) This article doesn't really do any of that.
- deleted 14y ago[deleted]
- GFKjunior 14y agoThose are pretty standard in cryptography, the equivalent would be "foo" and "bar".
- Mithrandir 14y agoDon't mean to be a shill for Coursera, but if you enjoyed this article you might like Coursera's crypto class: https://www.coursera.org/course/crypto https://www.coursera.org/course/crypto I found it really challenging in some places, but also quite fun. Udacity also has a crypto course: http://www.udacity.com/overview/Course/cs387/CourseRev/apr2012 http://www.udacity.com/overview/Course/cs387/CourseRev/apr20... I haven't tried it yet, but it looks a bit more in-depth in some places than the Coursera course.
- coldarchon 14y agoThe first exercise of Coursera's crypto class had the size and level of a final exam and I left.
- parley 14y agoIf you read this and intend to make security design decisions based on it (as opposed to reading it just for fun), please read more about the subject from other sources as well. A few statements in it are a bit contradictory, like claiming DH is safe from MITM while at the same time in other words acknowledging e.g. that identity cannot be proven with it. I don't mean to bash the author as primers are a good way to get people interested in stuff, but small oversights can sometimes cause big problems.
- mindslight 14y agoAnd before you tackle those other sources, make sure to go on a week-long bender. This will hopefully kill enough brain cells that you might stand a chance of forgetting most of this post's mischaracterizations. I can condone running through the math behind various primitives, to wet someone's whistle and give them a bit of an appreciation. To someone unfamiliar with the concept of one-way functions, seeing a run through of Diffie-Hellman is pretty neat. "What do you mean I can't figure out the secret, the numbers are right here in front of me..." But one of the major things that makes crypto so damn hard is that the devil is in the details, and this article misleads much more than it informs. Linear analogies like paint-mixing and XOR (!?) are anti-enlightening to the feat that DH actually accomplishes. Never mind the blatantly incorrect summaries of the properties of each primitive, which were clearly driven more by the limited understanding of the author than any kind of real-world usage.
- zobzu 14y agoNote that unlike what TFA claims, symmetric keys are safe. They're, in fact, SAFER than public key crypto for the SAME key size, as public key crypto depends on prime numbers. That's why you'd see 256bit symmetric keys, and 2048bit or more public/secret keys. It's just that the key exchange for symmetric keys is inherently unsafe online. But if you share the keys in a safe manner (ie, physically, secret location, no camera, etc.), its all good. A long time ago, well, not so long in fact, before public key cryptography was invented, symmetric crypto was used by businesses. They had people carrying those keys and delivering them. That was a pain. it also worked that way for a couple of thousand years, with weaker algorithms, but the same concept.
- xyzzyz 14y agoIt's just that the key exchange for symmetric keys is inherently unsafe online. I don't understand what you mean. There are plenty of ways to exchange symmetric keys online, for instance by Diffie-Hellman scheme, or even using public key cryptography. I even recall that SSL/TLS uses symmetric key for encryption and asymmetric crypto is used only for key exchange.
- pi18n 14y agoDiffie-Hellman is fine if there is no one between you and Alice, otherwise if you read the protocol you will see it is easy for Eve to do the protocol with both ends and just act as a conduit for messages after reading/altering them. SSL/TLS relies on trusting a number of certificate authorities to verify that, yes, the other end is Bob. Note that for this to work securely you must already have their public key info. There are problems with this also but it's the best we have got right now.
- yason 14y agoThere's the interlock protocol that ensures that you'll only be talking with one other party instead of one other and one in the middle but still you don't know who you're talking to. But it's impossible to identify someone out of nowhere. Even in physical life we need external information of a person or an organization we don't know to identify him. So, we will always need some leads with which to cross-check the other party's identity. And given that, there are plenty of protocols to exchange symmetric keys securely.
- ceautery 14y agoI found that to be a pretty nice writeup, a little more accessible for the curious layman than a pair of blog entries I wrote on RSA (http://cautery.blogspot.com/2012/06/rsa-encryption-and-other-sun-tzu.html http://cautery.blogspot.com/2012/06/rsa-encryption-and-other...) and Elgamal (http://cautery.blogspot.com/2012/07/encryption-part-2-elgamal-and-discrete.html http://cautery.blogspot.com/2012/07/encryption-part-2-elgama...) Encryption topics were the big wake-up call for me regarding not relying on Wikipedia for math/tech info. When I started the above blog posts, I dug around for background info from a variety of sources until I got my head around the math, and found Wikipedia's entries on encryption topics to be basically unfixable without doing a large enough rewrite to guarantee an immediate revert. Anyway, I wish this rosedu post had come a few months earlier; it would have saved me quite a wild goose chase.
- spaghetti 14y agoThis fun puzzle illustrates some of the ideas: Bob wants to send Alice something valuable in the mail. Unfortunately the postal system is very corrupt and very efficient. Any package containing a valuable item will always be spotted by postal workers. If the package doesn't have a lock the postal workers will steal the item. Also postal workers will always spot any key sent through the mail and hold it indefinitely. So even if a locked box is sent through and Alice receives it she will never receive the key when it comes through hence she can't obtain the package contents. How can Bob successfully deliver a valuable item to Alice? Answer: Bob puts the item in a box with a lock and sends to Alice. Alice receives the box, places her lock on it and sends it back to Bob. Bob removes his lock and sends the box back to Alice. Now Alice removes her lock and obtains the package contents.
- jethroalias97 14y agoWhat you have described is more or less Diffie-Hellman. Unfortunately this alone wont guarantee your package's safe passage. If it did Verisign, would be out of a job. The flaw is, you can basically just have the same scenario but replace Alice with the post office: Bob puts the item in a box with a lock and sends to Alice. Post office intercepts the box, places their lock on it and sends it back to Bob. Bob removes his lock and sends the box back to Alice. Now the post office removes their lock and obtains the package contents. The only way around this is to have some truly trusted third party. Even in RSA, if you aren't absolutely certain of the other user's public key, it won't work, which is why web-of-trust and other techniques are used.