非对称密钥只有在其中一个需要公开时才真正有价值（尽管“公开”在不同的上下文中可能意味着不同的东西）。

如果您都私下生成和验证代码，那么您可以使用私有密钥作为具有合理散列算法的 HMAC 的一部分。

如果空间很宝贵，您甚至可以不使用生成的 HMAC 输出的前 X 个字节，但要了解您删除的每个字节都会略微降低您的保护。

如果代码需要公开验证或生成，那么首先要认识到即使是正确有效的结果也可能被软件链的其他方面破坏，但理想情况下，您可以使用公钥和使用私钥的私钥。

在这种情况下使用对称或非对称加密实际上取决于用例而不是安全方面。代码是如何生成的？代码请求者和代码生成者之间可以有一个共同的秘密吗？如果他们这样做，您可以使用 HMAC 来验证发送者和完整性。如果没有，您可以使用非对称加密来利用消息签名。您不能按照您描述的方式使用非对称加密，因为它的工作方式正好相反。

我希望用非对称私钥加密整个有效载荷，然后尝试用公钥解密

恰恰相反......在非对称加密中，公钥用于加密，私钥用于解密。但在您的情况下，不需要加密 - 您需要数字签名来验证发送者和消息的完整性。这是通过使用发件人的私钥签名并使用公钥验证消息来完成的。

在有效载荷的末尾添加一个安全哈希将占用我的大量有效载荷空间

您可以截断哈希。例如，仅使用 SHA-1 输出的前 32 位。这将增加发生冲突的机会并使其更容易进行暴力破解，但您需要考虑它对您的用例的重要性。任何方式 - 也使用非对称加密，您需要将签名与消息一起发送。

给定这么小的有效载荷，非对称密钥会不会太短，因此很容易被暴力破解？

我没有看到这种关系。我唯一能想到的就是重放攻击。一旦有人看到您的二维码，他就可以按原样使用它。为了减轻重放攻击，您需要在代码请求中添加一个随机数，并将其包含在输出中。例如 HMAC 与 nonce 连接的有效负载。

我按顺序回答：

1. 几乎可以肯定，非对称签名通常比对称签名占用更多空间 - RSA 需要一定数量的填充和最小密钥大小才能确保安全；
2. 如果您使用 HMAC，则安全 HMAC 的最低要求（基于散列的消息身份验证代码或密钥散列）约为 64 位/8 字节 - 任何更少的内容都会将您置于危险区域 - 这取决于系统的其余部分是否可以减轻这种风险（身份验证标签的大小越大越好）；
3. 对于具有安全 MAC 的有效负载，您可以使用 64 - 8 = 56 字节 - 如果您需要更多，您可以扩展您的 QR 码。

对于签名，最好的选择是 ISO/IEC 9796-2，它定义了提供消息恢复的 RSA 签名 - 但要注意存在已知的弱点。然而，64 * 8 = 512 位的 RSA 太短了。

对于 MAC，通常使用最左边的字节 - 即在大多数编程环境中具有最低有效索引的字节 - 作为身份验证标签值。在许多 API 中，您可以指定身份验证标签的大小。

请注意，您需要一个键控散列，否则攻击者可以简单地将有效负载和散列值一起替换。由于密钥如何混合在较小的输出中，因此可能会使用不太安全的散列方法。