"Stealth Address" is really just a fancy name for a neat use of Elliptic Curve Diffie-Hellman key exchange. Its use in Monero is described here in detail, but not under that name. This allows for the sender to effectively salt the output and privately communicate the salt to the recipient. I have no idea who and when coined the term "stealth address" to describe it.
As for cryptanalysis, it's all using existing well-known primitives and should be trivial. There's a nice presentation from UCL going through various set-ups, and looking at the site of origin, I also discovered that a nice paper has been published recently.
Courtois N. and Mercer R. (2017). Stealth Address and Key Management Techniques in Blockchain Systems. In Proceedings of the 3rd International Conference on Information Systems Security and Privacy ISBN 978-989-758-209-7, pages 559-566. DOI: 10.5220/0006270005590566
But let's look at it from another angle, and try to build it from bottom up.
What's the minimum you need to do to be able to transact Monero? All you need is outputs and amounts (post-RCT, commitments take the role of amounts). The network verifies the signature, and the signature is produced by using the individul one-time output's private key.
So, all you really need are keypairs P=xG. You could create the destination key by any means you want.
For example, I (the receiver) could roll some x, communicate the P to you, and you make a TX with output P. You could omit the TX keys entirely because I already know my P and x and can tell my wallet to use them when I want to spend. This is because I (the receiver), have decided what the output will be.
This is practically the same as Bitcoin. I give you a public key (well, hash of it) and you pay to the public key (hash).
With CN we could do it the same way. Network doesn't force you to use ECDH & TX keys. However, due to use of ring signatures, we must be sure to never receive twice to the same key. With this in mind, it would be a big hassle to receive. You'd have to generate a new unique key whenever someone wants to send you something. If someone intercepts the payment request, he could monitor the blockchain for appearance of that P and know when you received something.
So, we want a way for the sender to roll the destination output P, in such a way that he won't know x, but such that I will.
For that, I could have some key B=bG for passive receiving, and the sender could construct outputs like P = R + B where he picks some random R=rG. Problem is, he needs to tell me the r as well in order for me to be able to spend so I could recreate the output's secret key x = r + b, compute the public key P, and use that to check that the output is indeed recorded on the blockchain and later spend it. We could make this work today, between me and you. All it requires is a wallet modification. It's not the best however, as you need to communicate the r via secure channel if I am to keep my privacy.
What about using blockchain for communication? That way I can't lose or forget the r and with that lose access to my funds. Problem is, while blockchain is great for record-keeping it is public so it's insecure communication channel. And what's a good way to privately communicate via insecure channel? ECDH.
We could say, OK, let's have the sender roll the outputs like: P=Hs(rB)G+B. Now he can tell me (write it to the blockchain) the R, and I can re-create the keys with x = Hs(bR)+b. Cool. Now someone intercepting the R can't tell that some P is for me, even if he knows my address B. But now, I can't ever be audited otherwise I have to leak my secret key to the auditor and then he could run off with everything. I can't even reveal selective, already spent, outputs, because someone knowing shared secret (bR) and secret key (x) of an output could work out my secret spend key b.
That's why we make the receiving address use dual keys, and then one is enough to check ownership without risk of revealing x, and the other is required to recover the x. With that we arrive to the current set-up.
