固定处理时间是防御定时攻击的最基本和最彻底的方法：避免利用你通过定时泄漏的数据，好吧，不要泄漏。然而，说起来容易做起来难。最近的“幸运十三”表明，当目标与攻击者“接近”时（在同一个局域网上），可以以微秒精度检测定时差异；攻击细节利用了 SSL 实现中仍然存在的小漏洞，这些漏洞已针对定时攻击进行了修补——即使解密没有产生适当的填充，这些实现也在计算 MAC，以便获得如下的处理时间尽可能固定；但是很难避免一微秒的变化。

如果您强制执行固定的“总体”处理时间（例如，每个请求 1 秒），那么您将在使用多任务操作系统时遇到麻烦。如果实现只是sleep()主处理之后的调用，那么 CPU 可以自由处理其他请求，这看起来不错……但是会泄漏数据，因为攻击者可以同时发送其他请求并确定您的服务器是否繁忙. 一般来说，通过向您的服务器发送大量请求，攻击者可以任意延长每个请求的处理时间，并超过任何固定限制。如果您只是将处理时间限制为固定粒度的整数倍（例如，处理时间始终是n乘以 0.1 秒，其中n是一个整数）那么你只有“阈值”，这使得攻击者的任务有点困难，但并非不可能 - 它甚至可以帮助攻击者。事实上，“幸运十三”攻击显示了如何利用这样的阈值（对应于 SHA-1 和 SHA-256 处理 64 字节块的方式）只需要一些“定相”并使统计图更清晰。

目前，最好的防御似乎是添加几毫秒的随机延迟，这会模糊图片并阻止分析......而且，不要让攻击者插入与服务器相同的局域网。这应该不用说。

定时攻击的基本本质是向服务器发送不同的数据样本，并通过查看处理输入所花费的时间来查看不同的输入是否会产生不同的代码路径。对抗时序攻击的最佳防御方法是让代码保持在相同的执行路径上，而不管输入如何。

这说起来容易做起来难。一个简单的函数 likememcmp()不保证相同的代码路径，因为它在第一个字节不匹配后退出；不同的输入会导致它从不同的点退出。一个自然的反应是编写一个自定义memcmp()的函数，但这样做也不是直截了当的。

最大的问题是如何处理错误和验证。无论预处理/验证/完整性检查错误如何，即使您意识到稍后会丢弃输出，也应该执行相同的代码。当您查看实际的定时攻击时，经常弹出的一个示例是 MAC 验证的不同时间。原始密码原语的时间并不是真正的问题。无论获得什么输入字符串，AES 或 SHA2 之类的位处理操作都将花费相同的时间。主要关注点应该是如何处理错误、特殊情况和数据比较。

固定的操作时间不一定是最好的防御；攻击者可以通过精心设计输入来绕过它，使操作时间正好在你的恒定壁时间增量的阈值，然后查看哪些操作将操作推到了阈值之上。在大多数情况下，理想的方法是执行完全相同的代码，而不管输入如何。

但是，我们不知道您的确切情况以及您试图保密的确切信息，因此上述内容是通用的。例如，保持代码执行相同的方法会泄漏有关正在处理的数据量的信息，我们不知道您是否担心。在许多情况下，攻击者已经知道数据的大小（因为他们提供了数据），但我们不知道这是否是个问题。