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.
Things can also be problematic if there are conditions under which you will encrypt data provided by you adversary as they could trick you into decoding the message for them.
Finally opponents may be able to tamper with the message even if they can't decode it unless there is a MAC to protect it.
This is true for RSA based schemes, but keep in mind that elliptic curve based asymmetric schemes are believed to be secure even with much shorter key lengths.
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.
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.
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.
The only way to verify that A's keys are legit is to use a secure channel first. Then you can leverage that over any number of insecure channels later to reconnect with A.
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.
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.
Udacity also has a crypto course: 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.
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.
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.
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.
I get that you worry some well-meaning fool will read this and go implement their own botched RSA-based or DH-based cryptosystem. That concern is legitimate. By all means, post the customary warnings.
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.
The implications of this are enormous and a ton of fun to think about. Here's just one example of how the world might change: there's a nonzero chance that in less than a century most computer programs will be fundamentally impossible to reverse-engineer. The old metaphor "you can think of a program as a black box; input goes in, results come out" will become a law of nature, rather than a mere rule of thumb. Now add the fact that the output will probably be encrypted using today's techniques, and the result is striking: any program running on your computer will be free to vaccuum up any data it pleases, encrypt it, then surreptitiously transmit it to its owner. It will be impossible to know ahead of time whether any given program is malicious; the sole way of detecting maliciousness is reduced to (a) the program is reading files that it normally shouldn't be, like your browser history, and (b) a secure HTTP connection is active. So if you give your program a legitimate excuse for (b), such as "my program is a web browser, go ahead and use it" and a legitimate excuse for (a), such as "obviously my browser is going to read and write your history file", then suddenly you wind up in a situation where the browser could be secretly sending your entire history to some third party and it'll be fundamentally impossible for you to detect it's happening.
FHE exists. It is coming; Gentry's thesis proved it can be done. The current problem is that the computational cost is probibitive (e.g. If we say that "right now the cost of computing a+b is N", then using Gentry's FHE the cost would be N^6, if I remember correctly; and that's true for every operation, so sub, mul, etc become N^6 more costly to compute) but work is underway to reduce that cost to something more palatable.
This is, of course, completely useless to me and to my life. Working on this is unlikely to gain me any useful knowledge nor any applicable talent/experience. By extension, no economic value can be derived from this right now (probably not within our lifetime). So who cares about it? Well, the answer is obvious: few-to-no one. I just have fun doing it because I can; it makes me feel powerful that I can understand and apply this sort of knowledge a century before it becomes commonplace.
So why have I been babbling about all of this? Well, I just wanted to thank you, because about 6 months ago you posted a comment along the lines of "the Diffie-Hellman protocol is actually pretty easy to understand", so I nonchalantly checked it out. It was amazing, and led me to devour a bunch of texts on RSA etc (leading to an understanding/appreciation of the RSA math) and eventually branching off into my current explorations of the mysterious world implied by FHE. And "Diffie-Hellman -> RSA -> scrypt -> FHE" just happened to be my path, which just happened to be "useless" (in the "hey I need to make rent" sense) but some other person might have easily gone "Diffie-Hellman -> RSA -> studying OpenSSL -> an ability to send and receive information in a way that's fundamentally impervious to any known attack (otherwise it would be fixed already, since the whole world uses OpenSSL) -> setting up a remote, untraceable C&C server for your Lua-based virus (a.k.a. Flame) -> influencing world events", which is presumably much more useful.
So the answer to the underlying question of "why do this type of thing?" can, I think, be expressed roughly as "meh, it's either fun or useful depending on what kind of person you are and your goals, and by the way thanks for originally encouraging me to look into it."
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.
> 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.
If you have an opinion about the post in question, why not just state it?
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.
Cryptographers love tradition. If we were to use "Andy" and "Barbara" as the principals, no one would believe anything in this chapter.