我正在尝试更多地了解对称加密，并发现基本上每个对称加密和解密最终都（以某种方式）基于使用密码和一些数据的简单 XOR-Byte-Toggle。
我现在的问题是，为什么我们需要制作“安全”的加密和解密算法？
我是这样想的：
当我得到数据时，我碰巧知道是 AES（或任何算法）加密的，我现在想读取它。您需要密码才能解密。我在这里看到“安全”问题的唯一方法是，除了您之外接收该数据的人需要密码来解密它（也知道数据是 AES 加密的）。
他现在尝试解密数据的方式是：Dictionary-Attacks，...（一直到 Bruteforce）。
但是，只要数据没有标准标头或您如何识别正确解密的方法（例如，考虑一个简单的文本文件），计算机就无法真正定义要正确解密的数据。考虑到所有这些，我很难理解为什么我们不仅使用简单的 XOR 加密，因为它很简单，很可能是加密和解密文件的最快方法，并且基本上在每种编程语言中都易于实现。
这里或多或少的关键问题是，究竟什么意味着加密和解密算法在密码学上是安全的？
当你设计一个加密算法时，你通常希望它在尽可能多的用例中是安全的。这将允许您在任何地方重用相同的算法，节省大量资源并允许行业标准算法（如AES）的硬件加速。
当您想为尽可能多的用例设计算法时，您必须防御各种各样的攻击，其中许多攻击甚至连非密码学家都不会想到。以已知的明文攻击模型为例。对于密码学新手来说，防御已知的明文模型听起来违反直觉。如果对手已经知道明文，那么究竟还有什么需要保护的呢？
好吧，事实证明，在现实世界中，很多加密的东西实际上只是已知的明文。考虑当您访问https://security.stackexchange.com时会发生什么。服务器和您的浏览器协商一个对称密钥，然后服务器使用该密钥加密主页的 html 并将其发送给您。除了，主页是完全已知的明文！任何人都可以浏览 security.stackexchange.com 并接收主页的明文。如果您的算法不具备抗明文攻击能力，攻击者可能会采用某种形式的密码分析派生服务器和浏览器协商的对称加密密钥。现在，当您继续登录您的帐户时，攻击者可以解密您用于登录的凭据，因为他们已经拥有您用于与服务器通信的加密密钥。类似地，大多数文件格式都有某种很容易猜到的标题，因此也容易受到已知的明文攻击。
并且密码分析不仅限于已知明文攻击，您还选择了明文攻击、选择密文攻击、填充预言攻击、相关密钥攻击、频率分析攻击等等。在这一点上，只有花费大量时间研究密码学和密码分析的人才能设计出一种可以保护所有这些的算法。这就是为什么安全人员总是重复口头禅的原因：
所以要回答你的关键问题：
如果一个算法能够抵抗所有已知的攻击，它就被认为是密码安全的。一旦有人想出一种新的方法来破坏加密的安全性（即允许解密一些他们不应该能够解密的算法加密的数据），它将不再被认为是密码安全的。这实际上意味着密码安全一词没有固定的定义。今天被认为是加密安全的东西，在 20 年后可能就不安全了。
您是正确的，大多数流密码（以及流模式下的许多分组密码）生成一个密钥流，然后用它对数据进行异或。为了安全起见，通常会应用某种消息身份验证代码，作为 AEAD 的一部分或在外部应用。当然还有许多其他方法，但这些方法很常见。
对于大多数非对称算法，使它们安全的典型因素是某种难题，通常是 NP 中的一个。例如，RSA 是基于分解大整数的难度，而 Diffie-Hellman 是基于计算离散对数的难度。
有时这些算法有一个“活板门”，一个知道秘密的人（拥有私钥的人）可以有效地计算一个值，但对于其他人来说，这个问题在计算上是不可行的。这种方法的常见示例包括大多数背包问题。
在很多情况下，我们无法证明这个问题实际上是困难的，我们只是推测它是。例如，Diffie-Hellman 中的实际难题是所谓的 Diffie-Hellman 问题的变体之一。我们推测解决 Diffie-Hellman 问题没有比解决离散对数问题更简单的方法了，但没有人能肯定地证明这一点。然而，也没有人给出反例，所以我们继续使用这些算法并相信它们是安全的。
我正在尝试更多地了解对称加密，并发现基本上每个对称加密和解密最终都（以某种方式）基于使用密码和一些数据的简单 XOR-Byte-Toggle。
这是错误的。让我们开始一些正式的定义；
分组密码是一组排列，其中每个密钥都应从该系列中选择一个唯一的前排列。我们希望分组密码是伪随机排列（PRP）。
分组密码是原语，需要目标系统的适当操作模式。我们有大量的分组密码操作模式，其中 CTR 和 OFB 是常用模式，可以将任何分组密码转换为流密码。当我们定义操作模式时，我们可以谈论
我们期望一种模式至少具有 Ind-CPA 安全（Ind -> Indistuishable），其中 ECB 失败并且 CTR 和 CBC 可以具有 Ind-CPA 安全性。
CTR 模式实际上不需要逆排列（即分组密码的解密），因此我们可以使用任何伪随机函数（PRF）作为具有更好安全裕度的广泛函数集。CTR 模式最初是为 PRF 设计的。
CBC 模式非常常见，参见 TLS 1.3 之前的版本。CBC 模式具有最终从 TLS 1.3 中删除的填充预言攻击。
认证操作模式：在 TLS 1.3 中，我们只有认证模式 AES-GCM、AES-CCM 和 ChaCha20-Poly1305，它们每个都在内部使用 CTR 模式（ChaCha 是内置的 CTR 模式）并且它们还通过 GCM 进行身份验证和 Poly1305。CTR模式下没有padding被攻击。
我现在的问题是，为什么我们需要制作“安全”的加密和解密算法？
当然，我们需要。我们希望保护我们的信息。例如; 如果您坚持使用带有单个密钥的 DES，则可能有实体可以在一天内破坏您的加密！根据 NIST，当前的安全密钥大小至少为 112。
使用带有 256 位密钥的 AES，即使是可能的加密量子计算机 ( QCQ ) 也能安全。您还可以将 ChaCha20 与 256 位密钥一起使用（或者更好地将 XChaCha20 与 192 位随机数一起使用，以减轻可能的（IV，密钥）对重用问题）。
当我得到数据时，我碰巧知道是 AES（或任何算法）加密的，我现在想读取它。您需要密码才能解密。我在这里看到“安全”问题的唯一方法是，除了您之外接收该数据的人需要密码来解密它（也知道数据是 AES 加密的）。
他现在尝试解密数据的方式是：Dictionary-Attacks，...（一直到 Bruteforce）。
是的，因为 AES 对密钥搜索是安全的（甚至AES-128也有），所以可能的攻击是您的密码。如果您使用错误的密码，那么攻击者会从已知的超过 613M 的典当密码开始对他们进行暴力破解。他们也可能会尝试为所有可能的组合（如 8 个字符）制作彩虹表。
为了减轻您需要的密码搜索攻击
但是，只要数据没有标准标头或您如何识别正确解密的方法（例如，考虑一个简单的文本文件），计算机就无法真正定义要正确解密的数据。
这实际上取决于所使用的加密方案。例如
CBC 模式具有 PKCS#7 填充，可以像DES 挑战者一样在蛮力期间进行测试。
在 GCM 和 ChaCha 中，可以测试身份验证标签是否正确。
请注意，每个都有深层细节，例如填充为误报的概率，对于 GCM 和 ChaCha 也是如此。这里不考虑这个。
如果文件是文本文件，那么也可以查找可能的字符串。越接近自然语言，就越有可能成为真正的关键。所有这些都可以自动化。
考虑到所有这些，我很难理解为什么我们不仅使用简单的 XOR 加密，因为它很简单，很可能是加密和解密文件的最快方法，并且基本上在每种编程语言中都易于实现。
您似乎在谈论 One Time Pad (OTP) 加密。原因很简单；为了无条件安全（或称其为完全保密或信息理论上安全），密钥大小必须等于消息大小。自 1949 年克劳德·香农 (Claude Shannon) 就知道这一点。这对于当今的大多数系统来说是不切实际的。
今天我们放宽了这个条件，以在计算上对多项式有界的对手是安全的。我们构建了一个可以抵抗已知攻击的分组密码或流密码。然后使用流密码，我们可以直接用 x-or 加密消息。对于分组密码，我们需要一种操作模式，如上所述，我们根据需要选择合适的操作模式。不同的应用程序有不同的风险，需要不同的操作模式，比如今天我们使用 XTS/XTX 操作模式进行磁盘加密，而不是之前使用的 CTR 模式，并且有一些攻击点。
OTP 似乎很容易实现，但是密钥生成和分发是常见问题。请记住，重用会导致 crib-Draggin 攻击，这在历史上发生过，
这里或多或少的关键问题是，究竟什么意味着加密和解密算法在密码学上是安全的？
什么使对称加密算法在密码学上安全？
简单的答案是在设计过程中进行多年的研究和密码分析。
分组密码需要
良好的扩散和混淆特性
抵抗所有已知的攻击，例如
需要与随机排列无法区分。
足够的圆形具有良好的圆形功能。
作为必要条件。
像AES 这样的良好分组密码已经抵抗了 20 多年的攻击。即使构建了 QCQ，我们预计 AES-256 将在不久的将来是安全的，并且在行业中被称为黄金标准。使用 AES-256 而不是 AES-128，您最多将获得 %40 的性能损失。
记住
美国国家安全局（NSA）内部有句老话：攻击总是会变得更好；他们永远不会变得更糟。**
因此，为所有可能的攻击场景做好准备，即使 RSA/ECC 失败到 CQC 并使用后量子公钥密码系统