I'm designing a web application where users will exchange short messages with the server very frequently (for instance, a few characters every second). I want the whole communication to be confidential, but the (perceived) performance must be acceptable. I had this idea of putting HTTP and HTTPS to work together using the following scheme:
The browser will request two (fairly large) keys from the server via HTTPS, then store them in-memory (in principle, I'm thinking in one-time-pad keys, i.e. random data). Then, the contents from each message will be XOR'ed with the first key (without any reuse, of course) and sent via HTTP. The server will send the response in the same fashion, using the other key. When one or both keys are about to be used up, another one will be requested, and so on.
The rationale behind this is that both the XOR and the HTTP request are cheap for small messages, so the perceived performance will be good. The HTTPS calls, more expensive, will not be time-critical and will benefit from the larger scale of the exchanged keys. Another stream cipher might be used instead of one-time-pads, and in the future (when properly supported everywhere) WebSockets could be used instead of HTTP requests.
Has this kind of thing been used before? Would this properly secure the communication, or is this a stupid idea, for any reason? I couldn't see any shortcomming, but I'd like to hear the opinion of more experienced people before spending too much time on this.