RSA签名具有模数长度：如果使用通常的 2048 位密钥大小，则签名长度为 256 字节。由于您希望将签名放入基于文本的 URL 中，因此您必须具有某种编码，例如Base64，这意味着一些大小开销；使用 Base64，256 个字节将变成 342 个字符——这使得 URL 的长度相当可观。

DSA（及其高度流行的椭圆曲线变体 ECDSA）提供更小的签名；您可以获得非常好的安全性（多达 2048 位 RSA），签名大小为 60 字节左右——同样，Base64 编码将其扩展为 80 个字符。

如果您需要更小的签名，那么您必须使用不太主流的算法，例如BLS，它提供的签名比 DSA 小两倍。但数学要复杂得多，没有标准，只有科学论文。

或者，您可能希望将 RSA 与 ISO 9796-2 签名（不是 PKCS#1）一起使用。您将获得 256 字节的签名，但您可能会在签名本身中走私一些应用程序数据。作为粗略的近似，您将获得n位安全性，总开销约为3n位；尽管最小消息大小为 256 字节。

理论限制：如果您想要n位的安全级别（意味着假定攻击者无法运行需要超过2 ^{n 个}基本操作的计算），那么签名大小也不能小于n位。实际上，攻击者可以尝试对签名进行暴力破解，尝试所有可能的签名值并使用签名验证算法（该算法使用 Alice 的公钥，这是公开的，因此为攻击者所知），直到找到匹配的签名。

然而，目前没有已知的安全数字签名算法提供n位安全性和n位签名。DSA 需要使用4n位签名来提供n位安全性。BLS 将其降低到2n位。已经有一些其他算法类型的提议可以达到1.5n位左右，但现在它们都在某种程度上存在缺陷。

您可能会稍微更改模型。例如，Alice 和 Bob 可能共享一些秘密值；然后，鲍勃并不真正信任“爱丽丝”，而是“知道秘密值的人，这恰好为爱丽丝和鲍勃所知”。在这种情况下，您可以依赖MAC算法而不是数字签名；您可以将 MAC 算法视为签名，其中签名的密钥和验证的密钥相同。

这是语境的变化。根据您的系统中的 Alice 和 Bob 的身份，共享秘密可能是可能的，也可能是不可能的。使用 MAC 会丧失大多数不可否认性的机会。这也意味着 Bob 可以自己生成他会接受的 URL。然而，如果您可以容忍使用 MAC，那么您可以获得非常短的验证元素。事实上，你甚至可以得到低于n位，因为穷举搜索不再适用：由于 MAC 验证密钥是秘密的，攻击者无法在自己的机器上尝试 MAC 值并判断它们是否正确. 为了“尝试”一个潜在的 MAC 值，攻击者必须将其发送给 Bob，并查看 Bob 是否满意。在大约一百万次尝试之后，Bob 可能会开始怀疑犯规并采取对策（例如，停止响应那个明显狡猾的请求者）。

从这个意义上说，长度为 64 位的 MAC 值应该足够了。这只是 8 个字节——可使用 Base64 编码为 11 个字符。HMAC是一种广泛实施的 MAC 算法，具有良好的声誉。

“签名 URL”没有完善的标准。每个网站设计师都制定了自己的计划，这是不幸的，因为自制密码学是通往灾难的最可靠途径之一。不过，概念模型是合理的：基本上，您希望 Mallory 将消息从 Alice 传达给 Bob，这样 Bob 可以知道该消息确实来自 Alice，并且没有被 Mallory 更改甚至完全发明。消息作为“URL”传播只是一个对概念没有影响的编码约束。

MAC 或签名确实是这里的正确工具。但要小心重放攻击：如果 Mallory 有一个 Bob 会接受的 Alice 签名的 URL，Mallory 可能会尝试将该 URL 发送两次给 Bob，以获得双倍的效果。根据您的上下文，这可能是也可能不是问题。如果是，那么 Bob 必须强制执行一些保护机制，例如记住过去拒绝重复的请求。URL 数据中的时间戳（在 MAC 或签名的掩护下）可以帮助 Bob 跟踪看到的 URL（即 Bob 可以忘记“过期”的 URL，因为他不再接受它们）。