对于安全性非常高的 Web 应用程序，是否可以使用 2048 位 RSA 加密来加密客户端和服务器之间来回发送的所有重要数据？假设有千字节到兆字节的数据来回发送（加密之前），使用这种类型的加密会有什么性能损失？
最后，我将如何（如果我有一个通用模型，我可以编写代码）让服务器向客户端发送服务器到客户端的解密密钥和解密引擎，而不影响当前和未来会话的安全性（即另一个用户相同的应用程序将无法拦截来自第一个用户的数据并使用存储在其计算机上的信息从他们的会话中解密第一个用户的数据，并且不怀好意的人也将无法拦截和使用第一个用户用户的解密密钥和引擎来完成相同的任务）？
考虑到现代处理能力，这样做当然是可行的，但出于几个原因，这是个坏主意。
首先，您可以使用证书对服务器进行身份验证，但是客户端呢？您可以使用客户端证书 - 管理起来有问题，或者您可以每次在客户端生成一个密钥对（慢）并在建立安全会话后使用密码对客户端进行身份验证。另一方面，AES 只需要一个短密钥，并在现代 x86 和 AMD 处理器的指令集级别提供支持。
其次，从您正在寻找 RSA 的事实来看，因为您需要一个“非常安全的解决方案”，您应该知道 RSA-2048 实际上不如 AES-128 安全。2048 位的 RSA 密钥相当于大约 112 位的对称密钥强度。见这里。
最后，AES 等对称方案中的密钥交换问题通常使用 RSA 或 DHKE 等非对称方案来解决。所以你应该做的是使用公共加密方案来交换对称密钥，然后对其余数据使用强对称密码——这正是 TLS 所做的。
HTTPS 是最著名的应用层协议——它将 HTTP 堆叠在 TLS 之上。TLS 得到广泛支持，OpenSSL可能是当今使用最流行的库，并且在所有主要平台上都受支持，请使用它。
编辑 1：银行不只是应用 SSL 安全性，因为他们意识到 SSL 并不能解决所有问题 - 有些问题并不打算解决。例如，它对网络钓鱼或会话窃取毫无用处。银行身份验证机制的目的不是检查与之交谈的人是否知道密码，而是检查此人是否是您。这也意味着确保连接来自一个公认的 IP 地址，有时让您回答安全问题，并要求您使用所谓的 SiteKeys 确保您识别银行网站。
编辑 2：您无法确保信息没有被第三方截获。您可以期望的最好结果是它们无法将您的数据与完全随机的字节流区分开来，这是每个网络安全协议的目标。一些方案还尝试隐藏实际的源地址和目标地址，例如 IPsec，但这并不常见。
如果您正在构建 Web 应用程序并且需要在 Web 服务器和浏览器之间传输敏感信息，那么您应该使用 SSL。它基本上完成了您在问题中描述的内容。
有关其工作原理的更多信息，请参阅HTTPS。
使用 2048 位加密 SSL 证书是非常可行的，并且一直在使用。较大的密钥可能会产生更多延迟，但根据我的经验，密钥大小导致的延迟可以忽略不计。我会更担心每页加载传输兆字节的数据。
有点相关： 使用 4096 位加密 SSL 证书有什么缺点吗？
当然，如果您的问题是关于在服务器端加密数据、将其发送到浏览器并在浏览器端解密：我的建议是不要。考虑一下您对此解决方案的目标。它试图解决的唯一问题是man-in-the-middle，SSL 已经为您解决了这个问题。此外，您在浏览器上执行的任何操作本质上都是不安全的，因为它可以被客户端修改，因此无论如何该解决方案都非常不安全。
您的最后一段表明您担心防止sql 注入和会话劫持。这些应该作为单独的问题发布，但足以说明您无法通过加密数据传输来解决这些问题。
为了得到一个好的答案，您必须提供您对“可行”一词的定义。这可能是可以做到的（您可能会遇到需要良好随机性的问题，而浏览器中的 javascript 无法提供该功能），但这会非常缓慢且笨拙。
非对称加密提供了许多不错的功能，但性能不是其中之一。在使用非对称交换对称加密密钥然后用于加密和解密大量数据的情况下，混合方法往往受到青睐。这就是浏览器中 HTTPS 的工作原理。
说到浏览器，如果您正在创建一个网络应用程序，为什么不利用浏览器已经提供的 SSL 保护呢？如果您不信任浏览器 SSL 来保护您的数据，那么您就无法信任它来保护服务器发送给客户端的 JavaScript 代码。
否。如果您使用 RSA 加密/解密客户端和服务器之间的数据。它会很慢。
取而代之的是， 1. 使用 RSA 密钥对来加密/解密会话密钥。2. 使用该会话密钥加密/解密客户端和服务器之间传输的数据。（由于会话密钥是对称密钥，所以速度会更快） 3. 由于是一次性使用，因此不会有任何危害当前和未来会话安全的问题。