Subject: Signing what you don't understand: a practical example

From: "denis bider" <[email-masked]>
Date: Tue, 11 Jul 2000 21:11:30 +0200

Hello folks,

to make my idea clearer, this is how I imagine an improved signature format
would look like.

(The following is an excerpt from PKCS#1 v2. My proposed changes are marked
in blue.)

9.2.1	EMSA-PKCS1-v1_5

This encoding method only has an encoding operation.

EMSA-PKCS1-v1_5-ENCODE (M, emLen, content-not-understood)

Option:  Hash - hash function
                (hLen denotes the length in octets of
                the hash function output)
Input:   M - message to be encoded
         emLen - intended length in octets of the encoded
                 message, at least ||T|| + 10, where T is
                 the DER encoding of a certain value
                 computed during the encoding operation
         content-not-understood
               - boolean; false if the semantic meaning of
                 the content being signed is understood by
                 the logical entity which is performing
                 the signing operation, true otherwise
Output:  EM - encoded message, an octet string of length
              emLen; or "message too long" or "intended
              encoded message length too short"

Steps:

1. Apply the hash function to the message M to produce a hash value H:
      H = Hash(M).
   If the hash function outputs "message too long", then output "message too
long".

2. Encode the algorithm ID for the hash function and the hash value into an
ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
Encoding Rules (DER), where the type DigestInfo has the syntax

   DigestInfo ::= SEQUENCE {
     digestAlgorithm AlgorithmIdentifier,
     digest OCTET STRING,
     flags BIT STRING OPTIONAL
   }

   Meaning of 'flags' bits:
     first bit: content-not-understood
     subsequent bits: not defined at this time

   In case the value of the first bit of 'flags' is 0, the 'flags' field may
be omitted for purposes of backward compatibility. However, this is not
recommended. If omitted, the interpretation of the 'flags' field is
application-dependent.

   The first field identifies the hash function and the second contains the
hash value. Let T be the DER encoding.

3. If emLen is less than ||T|| + 10 then output "intended encoded message
length too short".

4. Generate an octet string PS consisting of emLen-||T||-2 octets with value
FF (hexadecimal). The length of PS will be at least 8 octets.

5. Concatenate PS, the DER encoding T, and other padding to form the encoded
message EM as

   EM = 01 || PS || 00 || T

6. Output EM.

//
//  denis bider, [email-masked]
// [alternative: [email-masked]]
//  globera d.o.o., Ljubljana, Slovenia
    http://www.globera.com
    +386 1 510 7740

---

From: Aram Perez <[email-masked]>
Date: Tue, 11 Jul 2000 17:44:48 -0700

Hi Denis,

[snip]
> 5. Concatenate PS, the DER encoding T, and other padding to form the encoded

[Warning: Long sentence ahead.] If you received a signed message from me,
formatted per your instructions and with the flags parameter, how would you
know that I was using the security device you have described, that the
message was displayed on that device and that I really understood what I
signed? I can easily create an identical message on my insecure PC with
today's smartcards or just with the right software.

Regards,
Aram Perez