As everyone says, make sure experts analyze and try to break your cryptosystem even if it is largely pieced together from other cryptosystems in a secure manner. Even then, I would still treat it as a potential insecure application and only use it for "toy" needs (versus thinking it has been equally vetted compared to well known tools like openssl / GPG -- and even these tools have had well-publicized flaws found years later). Personally, you don't seem to be familiar with cryptographic hashes (thinking that SHA-256 can't encrypt more than 64-bits), so I strongly recommend taking a course or two on cryptography. (Coursera has two great courses by Dan Boneh; and udacity has a good course in Applied Cryptography).
I'm not particularly familiar with Hash Commitment Before Knowledge protocol (and not really interested in learning about it as the link you mentioned talked about patent restrictions in the upper right), so will analyze a much simpler scenario where JS crypto could be used.
In this sort of scenario, timing attacks on the client-side local key generation phase would be irrelevant - as long as no network information goes out when the key begins to be generated. Replay attacks may be of significance, though messages could contain an encrypted time-stamp (so if you repeated the message "Transfer $100 from Alice to Bob- sent: July 4th, 2013 at noon" you won't repeat the action if you already performed the action on July 4th). Yes it would be trivial for an attacker with access to a computer with the browser extension to maliciously modify it (e.g., add a keylogger and record/transmit the key to someone). But this is not that different from an attacker installing a keylogger on a compromised machine or downloading the source code for OpenSSL, compiling it, and replacing OpenSSL with a compromised version. Again, if the computer you are using for encryption/decryption is compromised, don't expect to be able to keep your cryptosystem secure.
mail.google.com press compose, start typing out your message in the compose window, finish your message, run your browser extension which replaces your plaintext in the message body with AES-encrypted ciphertext, and then press send. This is insecure. Gmail automatically sends your draft in the compose window to their servers via AJAX calls while you are typing it (to save as a draft in case your connection gets cut off).
PS: I deliberately have a flaw in my simple AES encryption scheme where no message authentication was present that would allow a man-in-the-middle to change a message "Attack at dawn" to "Attack at dusk" very easily. (Originally I wasn't going to point this out; but I'm trying to repeat the point that encryption is subtle").