【问题标题】:RSA PKCS#1 compliant signature符合 RSA PKCS#1 的签名
【发布时间】:2010-07-22 21:34:28
【问题描述】:

我正在使用 PKCS#1 2.0 (OAEP) 标准(带有附录的签名),但有些问题我不清楚。

  1. 正在签名的物理对象是什么?我知道它的哈希函数值等等(我确实知道算法),但是它是从文件的二进制fform计算出来的,不管内容是什么?

  2. 签名的物理结果是什么?包含签名哈希的文件?这个文件应该放在指定的位置吗?这种东西的格式或扩展名是什么?

  3. 如果我有多个要签名的文件,是否应该为每个文件单独执行此操作?还是应该将它们连接起来?再一次 - 这种操作(文件?)的结果是什么?

【问题讨论】:

  • 请注意,OAEP 填充用于加密,但不用于签名。您应该使用旧的(但仍然很流行)PKCS #1 v1.5 填充或 PSS 填充。

标签: cryptography rsa digital-signature pkcs#1


【解决方案1】:

PKCS#1 有时被称为“原始 RSA”,是一种低级加密原语:它不适用于文件,也不会生成文件,它适用于原始数据:输入是一个小于公共的数字密钥和输出是公钥大小的数字(例如 RSA-1024 的 1024 位)。

如果您想要签名文件,您可能希望使用PKCS#7/CMS format,因为这是附加签名和分离签名最常用的签名格式(即使是 PDF 文件中的签名通常也是 PKCS#7实际上是信封)。

PS:我对 OAEP 了解不多,但从我读到的内容看来,它似乎是一种填充方案(您在原始签名之前对数据所做的事情),所以我的论点应该仍然有效。

【讨论】:

  • 我补充说,PKCS#7 签名是一个比裸 PKCS#1 签名更复杂(和更大)的对象,并且涉及使用 X.509 证书等,所以它可能不是什么您正在寻找,视情况而定。 OTOH 是一种完整的格式,有很多程序支持并且可以正确验证,而如果您使用裸 PKCS#1,则主要取决于您如何使用它。
  • 您的表述“输入是一个小于公钥的数字”非常不清楚。输入要么是一个几乎任意长的字节数组,它首先经过散列然后签名,要么已经是散列摘要,然后直接签名。它是哪一个当然取决于所使用的加密库的接口。
  • 不,不是,PKCS#1 包括填充以使输入“足够大”,但不包括散列或附加和分离签名之间的区别,这是在更高级别管理的东西,如PKCS#7。
  • 这很愚蠢。一方面您不知道 OAEP 是什么,另一方面您固执地坚持 PKCS #1 签名不使用散列函数。这为您赢得了当之无愧的反对票。
  • 这并不傻,这仅仅是因为在我的第一条到第二条消息之间的时间范围内,我阅读了关于 OAEP 的文档并验证了我提供的信息。是的,OAEP 确实在内部使用散列,但 对输入文件进行散列;实际上,它指定最大输入大小严格小于 RSA 大小相当数量(PKCS#1v2.1 官方文档的第 7.1.1 节):M ≤ k - 2 hLen - 2。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-08-04
  • 1970-01-01
  • 1970-01-01
  • 2019-03-17
相关资源
最近更新 更多