OAEP是用于增强RSA的重要技术。但是,使用OAEP
(或任何添加随机性的技术)会减少可以加密的纯文本的大小。

例如,假设OAEP正在使用160位种子和哈希函数产生一个256位的值。在这种情况下,将RSA与2048位密钥一起使用时可以处理多大的纯文本?

评论

请注意,除了直接答案外,OAEP还经常用于混合加密方案中,在该方案中,对随机(数据)密钥进行了加密,从而对密文进行了加密。从这种意义上讲,OAEP可以轻松转换为可以处理几乎无限量的数据,同时仍然仅增加恒定的开销(至少是密钥大小)的东西。

@MaartenBodewes函数(您可能已经知道,但其他人则不知道):如果进行混合加密,则不需要OAEP。只需RSA加密一个模数长的随机值,并将其哈希值用作密钥。事实证明,这和RSA问题一样困难,或者破坏了使用的对称加密。

@SEJPM RSA-KEM的唯一问题是,我发现使用模数长的随机数是不切实际的。我发现使用长度为k-1的随机数更为实用,其中k是模数大小的大小(以字节为单位)。 RSA通常是在密码库中的字节(即包括内部I2OSP)上定义的,并且生成一个很大的随机数(直到一定大小)也很麻烦。是的,我“听说过”:P

#1 楼

OAEP的输入长度直接在标准中指定:


M        message to be encrypted, an octet string of length mLen,
         where mLen <= k - 2hLen - 2



,或者如果我们要计算最大消息大小,则简单地mLen = k - 2 * hLen - 2

其中:



k-RSA模数n的八位字节长度

hLen-八位字节的输出长度哈希函数Hash

mLen-消息的八位字节长度M

RSA的密钥大小定义为无符号模数表示形式中的位数。因此,密钥大小与以位为单位的模数大小相同。


因此,为了完成计算,我们必须包括k = ceil(kLenBits / 8),其中kLenBits是以位为单位的密钥大小。对于仅整数计算,可以将其重写为k = (kLenBits + 7) / 8。但是,由于通常将kLenBits限制为8的倍数,通常就足够了。

k = kLenBits / 8也是如此,实际上,哈希值始终以位为单位-例如hLen除以8。要以八位字节/字节为单位。

要计算RSA OAEP的最大有效载荷,我们用各自的计算替换hLenBitsnLen(因为要寻找最大值,所以用hLen替换<=):

mLen = k - 2 * hLen - 2


成为

mLen = kLenBits / 8 - 2 * hLenBits / 8 - 2 


如果我们观察到这一点,我们会发现开销量仅取决于哈希长度: =。这样可以很容易地写出SHA-1,SHA-2和SHA-3的可能性:

\ begin {array} {| l | c | c |}
\ hline
\ text {HASH}和\ text {OVERHEAD}和\ text {RSA 1024}和\ text {RSA 2048}&\ text {RSA 3072}和\ text {RSA 4096} \\
\ hline
\ operatorname {SHA-1}&42&86&214&342&470 \\
\ hline
\ operatorname {SHA-224}&58&70&198&326& 454 \\
\ hline
\ operatorname {SHA-256}&66&62&190&318&446 \\
\ hline
\ operatorname {SHA-384}&98&30&158&286&414 \\
\ hline
\ operatorname {SHA-512}&130&\ text {N / A}&126&254 &382 \\
\ hline
\ end {array}

请注意,SHA-1的输出大小为160(或PKCS#1中的2 * hLenBits / 8 - 2)。如果加密库中缺少用于计算最大输入大小的函数,则最好将其简单地包含在源代码中。当然,您要避免使用1024位RSA。我只是为了需要向后兼容而添加了它。


太好了,现在我们终于可以填写数字hLen = 20kLenBits = 2048

mLen = 2048 / 8 - 2 * 256 / 8 - 2 = 256 - 64 - 2 = 190


,因此邮件的最大大小为190个字节。

评论


$ \ begingroup $
对于用于加密的PKCS#1 v1.5填充,开销仅为11个字节(三个字节的静态值和8个字节的随机数1..255)。
$ \ endgroup $
–马腾·博德威斯♦
17年3月30日14:20



$ \ begingroup $
但是,不再建议以最小的开销使用PKCS#1 v1.5加密填充:仅具有64位随机性,通过蛮力测试对纯文本的猜测在边界上是可行的。而且,无论开销如何,我们都知道PKCS#1 v1.5加密填充的安全性没有降低,并且与RSAES-OAEP相比,以抗填充oracle攻击的方式实现解密非常困难。
$ \ endgroup $
–fgrieu♦
19-2-28在15:43