Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?)

From: [email-masked]
Date: Mon, 15 May 2000 22:51:21 -0400

> ok, i think i've got it -- below is an outline of my current understanding.
>
> for each hash context instance, the initial input is:
>
>   zero(s) + salt + passphrase
>
> output from the hash, o1, is a fixed number of bytes, h.
>
> if the length of salt + passphrase in bytes is less than the
> calculated octet count, then o1 is given as input to the hash
> function which produces o2 (also length h).
>
> if the length of salt + passphrase + o1 is less than the calculated
> octet count, then o2 is given as input to the hash function and the
> process continues until the length of:
>
>   salt + passphrase + o1 + ... + on
>
> is greater than or equal to the calculated octet count.
>
> also, none of o1, ..., on have octets of zeros prepended.
>
> is this correct?

No, unfortunately this is not correct, although I can see that the
"repeatedly hashed" language could be read this way.  Actually what is
input is:

   zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ...

             <---------------------  COUNT bytes  ------------------------->

and if COUNT (which is the computed octet count) is less than the length
of salt + passphrase, we hash enough bytes so that we include the full
salt + passphrase.

Hal

---

From: [email-masked]
Date: Tue, 16 May 2000 15:38:07 +0900

From: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Mon, 15 May 2000 22:51:21 -0400
Message-ID: <[email-masked]>

...

> "repeatedly hashed" language could be read this way.  

doh!  perhaps another candidate for rewording :-)

> Actually what is input is:
> 

now i see the light!

thanks again.

---

From: [email-masked]
Date: Wed, 17 May 2000 16:54:54 +0900

yet another clarifying question...

From: [email-masked]

> of salt + passphrase, we hash enough bytes so that we include the full

what happens in the case where the computed octet count is:

  -not an integer multiple of the length of salt + passphrase and
  -greater than the length of salt + passphrase

?

i presume that exactly "computed octet count" octets are handed to the
message digest algorithm (+ message digest padding), and not an
integer multiple number of instances of salt + passphrase.

so the last octet before message digest padding would not be the last
octet of the passphrase, as section 3.6.1.3 says:

   Then the salt, followed by the passphrase data is repeatedly hashed
   until the number of octets specified by the octet count has been
   hashed.  The one exception is that if the octet count is less than
   the size of the salt plus passphrase, the full salt plus passphrase
   will be hashed even though that is greater than the octet count.

is this correct?

thanks again.

---

From: Jon Callas <[email-masked]>
Date: Fri, 26 May 2000 17:52:22 -0700

Does anyone want to suggest wording on this?

	Jon

---

From: [email-masked]
Date: Sun, 28 May 2000 11:16:54 +0900

From: Jon Callas <[email-masked]>
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question  about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Fri, 26 May 2000 17:52:22 -0700
Message-ID: <p0431010eb554c334a4a3@[63.73.97.188]>

> Does anyone want to suggest wording on this?

below is one attempt.

p.s. there are other sections that i think could be made clearer.  are
     people amenable to receiving other suggestions for wording as well?

3.6.1.1. Simple S2K

   This directly hashes the string to produce the key data.  See below
   for how this hashing is done.

       Octet 0:        0x00
       Octet 1:        hash algorithm

   Simple S2K hashes the passphrase to produce the session key.  The
   manner in which this is done depends on the size of the session key
   (which will depend on the cipher used) and the size of the hash
   algorithm's output. If the hash size is greater than or equal to the
   session key size, the high-order (leftmost) octets of the hash are
   used as the key.

   If the hash size is less than the key size, the key is determined as
   the result of the concatenation of multiple hash values -- enough to 
   produce the required key data.  

   Prior to each hash calculation, an appropriate number of octets of zeros 
   are prepended to the data (in this case, the passphrase):

       hash(data)
       hash(0, data)
       hash(0, 0, data)

       ... and so on

   i.e. no prepending for the first hash computation, prepending one octet
   for the second hash computation, and thereafter increasing the number of 
   prepended octets of zeros by one for each subsequent hash computation.  

   The hash results are concatenated, first hash leftmost, to produce
   the key data, with any excess octets on the right discarded.

   Note that each hash computation should produce different output since
   in each case a different sequence of octets is hashed.
   
3.6.1.2. Salted S2K

   This includes a "salt" value in the S2K specifier -- some arbitrary
   data -- that gets hashed along with the passphrase string, to help
   prevent dictionary attacks.

       Octet  0:        0x01
       Octet  1:        hash algorithm
       Octets 2-9:      8-octet salt value

   Salted S2K is exactly like Simple S2K, except that the input to the
   hash function(s) consists of an appropriate number of octets of zeros, 
   8 octets of salt from the S2K specifier, followed by the passphrase.

3.6.1.3. Iterated and Salted S2K

   This includes both a salt and an octet count.  The salt is combined
   with the passphrase repeatedly depending on the octet count, and
   the resulting value is hashed.  This further increases the amount of 
   work an attacker must do to try dictionary attacks.

       Octet  0:        0x03
       Octet  1:        hash algorithm
       Octets 2-9:      8-octet salt value
       Octet  10:       count, a one-octet, coded value

   The count is coded into a one-octet number using the following
   formula:

       #define EXPBIAS 6
           count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

   The above formula is in C, where "Int32" is a type for a 32-bit
   integer, and the variable "c" is the coded count, Octet 10.

   The input to the hash function(s) is determined in the following
   manner.  First, concatenate the 8 octets of salt from the S2K specifier 
   and the passphrase.  If the total length of the result is less than
   the count obtained by the above formula, concatenate sufficient
   octets from the salt and/or the passphrase such that the length of the
   resulting sequence is exactly equal to the count.  Finally,
   prepend an appropriate number of octets of zeros:

       zero(s), salt, passphrase, salt, passphrase, salt, ...

                <--------------- count octets -------------->

   Note that the count does not apply to the number of prepended octets 
   of zeros.  Also, if the octet count is less than the size of the salt 
   plus passphrase, the full salt plus passphrase will be hashed even 
   though that is greater than the octet count.