2

For encryption block looking like this: EB = 00 || BT || PS || 00 || Data where BT - block type and PS - padding string, I've read that we use three types of BT - 00, 01, 02. Now, since 00 and 01 are for private key operations (where 01 is recommended - why?), like signature, and 02 is for public key operations, like encryption, I am wondering why it is not recommended to use '00' block type. Also, if it is not recommended, why is it even possible?

Apologize once again for being a newbie.

James Pond
  • 77
  • 2
  • 9

2 Answers2

4

PKCS#1 only defines two "old-style" paddings (aka "v1.5" because these were the two paddings defined in PKCS#1 v1.5, while more modern versions add other options, known as "OAEP" and "PSS"). These two paddings are the "type 1" and "type 2". There is no defined "type 0" padding; of course, any byte can conceptually have any value in the 0 to 255 range, but PKCS#1 defines only two paddings, not three or more.

The two paddings do not differ only by the "type byte" (of value 0x01 or 0x02). The subsequent bytes (the "PS" string) are very important for security. In the "type 1" padding, the "PS" string consists only of bytes of value 0xFF; it is fully deterministic. In the "type 2" padding, the "PS" string consists of random bytes (the bytes must not have value 0x00, but otherwise they must be generated randomly in the 0x01..0xFF range). They cannot be used interchangeably. The type 1 padding is for signature, the type 2 is for asymmetric encryption. If you use a type 2 padding for signatures, then you obtain a very weak signature scheme (because of the malleability inherent to modular exponentiations). If you use a type 1 padding for asymmetric encryption, then you obtain a weak encryption scheme (because of the determinism of type 1 padding, allowing a brute force attack on the plaintext).

The "BT" byte that identifies the padding type is there chiefly (and mostly) to make the two paddings unambiguously distinct. Otherwise, one would have to worry about attackers using a signature as an encrypted message or vice versa. Thus, the two paddings should have a distinct "BT" value; the PKCS#1 authors could have chosen the two values to be 0 and 1, or 1 and 2, or 17 and 42, or any other pair of distinct values; they chose 1 and 2. This is arbitrary.

In any case, the importance of the padding is not in the "BT" byte, but in the bytes that follow (the "PS" string). It is not recommended to use a "type 0" padding because there is no such thing as a type 0 padding.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 2
    **But there was!** See v1.5, republished conveniently as rfc2313. It had for "private-key operation" (signature) BT 00 with padding (all) 00 or BT 01 with padding all FF plus one 00 delimiter. (And for encryption BT 02 with all random but nonzero and one 00.) Thus type 0 amounted to textbook RSA, with all its issues, some of which are even noted in the document, and was already (1998) **not recommended**. In v2.0 and later type 0 was silently dropped, and type 1 and 2 retronymed SSA-PKCS1-v1_5 and ES-PKCS1-v1_5 (with ES-OAEP and SSA-PSS preferred). – dave_thompson_085 Jun 02 '15 at 03:51
  • Related [question](https://crypto.stackexchange.com/q/76350/555) wondering how malleability is relevant to weakness of using type 2 padding for signatures. – fgrieu Dec 13 '19 at 10:53
0

First of all, block-type (BT) '00' and '01' is padding for private key operation, i.e. signing. Standards define that 'data' for signature should be hash (DER DigestInfo structure) of the data that is signed.

Block-type (BT) '01' padding adds fixed padding data up to the length of the modulus:

00 | 01 | FF .. FF | data

Block type (BT) '00' padding means that BT is set to 00 and padding string to zeros, which effectively means that there is no padding applied:

00 | 00 | 00 .. 00 | data

None standards compliant software will accept digital signature in this form. The block type '00' padding is only useful if you want to perform raw exponentiation operations with the private key or implement more advanced padding than provided by the library (e.g, RSA-PSS).

FaST4
  • 156
  • 4