(Please read this message carefully, because it might change or break
current implementations...)
Thanks Garry for following up!
Is there anything else that we should change in the latest 1619.1 document?
I'll go ahead and add these changes in, then add the new stuff, including
the following:
- Method for key derivation using SP800-90 DEC 2005 draft.
- Requirements of entropy in IV if key derivation is not used
- Commentary on the effect of using a low-entropy user-key
- NEW SECTION: Add requirements for running a self-test
Here is a taste of what I am planning to add. Please take a look and
give me any comments before I get too carried away :)
Key Derivation:
---------------
I was thinking of using the Hash Derivation Function as outlined in
section 10.4.1 of [SP800-90]. The hash function shall be SHA-256.
SP800-90 uses the following basic format:
Result = Hash(Counter || NumOfBitsToReturn || InputString)
To conform to this format, we could use the following:
DriveKey = SHA-256(0x01 || 0x00000100 || IEEE_OUI || VendorSpecific)
The IEEE_OUI is the 3-byte number maintained by IEEE, and VendorSpecific
can be any length, including 0 bytes.
Is this in line with what people were thinking?
Entropy in the IV:
------------------
We had agreed that if a vendor chooses not to use key derivation, they
are then required to maintain 96-bits of entropy in the IV. After
thinking about this a bit, it seems like 96-bits might be a little
strict. We may want to back off by a few bits to allow for a
certain class of hash-based derivation functions. In particular, if
a device uses the algorithm specified in section 10.1 (Deterministic
RBGs Based on Hash Functions) [SP800-90], and only uses 96-bits of
entropy, then the resulting IV would lose about 2/3 of a bit of
entropy. They now have ~95.33 bits of entropy in the IV. There is
possibly even more entropy loss using HMAC, depending on circumstances.
Would you all be okay if we only required 94-bits of entropy?
Either that, or we could require that the entropy source contain at
least 128-bits of entropy, which gets condensed down to 96-bits by an
approved 'Deterministic Random Bit Generator'. (For example, using
section 10.2 'DRBGs Based On Block Ciphers' [SP800-90] with AES)
Definition of Entropy
---------------------
Also, we probably want to include a definition of 'entropy', at least
for purposes of this document. [SP800-90] uses the idea of 'minimum
entropy', which looks like this (See section C.3):
Hmin = -Log2(Pmax)
Where Hmin is the minimum entropy of the source (in bits) and
Pmax is the maximum probability of any particular outcome. So, for
an ideal source with 96-bits of entropy, the following is true:
96 = -Log2(1 / 2^96)
In other words, no 96-bit value is more likely than any other.
Are people comfortable with this definition, or should we use the
more exact definition of 'Shannon Entropy'?
Requirements for Running Self-Tests:
------------------------------------
In looking at SP800-90, I noticed that chapter 11 (Assurance) requires
that the device performs a self-test. Along the same lines, it
makes sense that a device must perform some level of self-testing to
be compliant to IEEE 1619.1. We all do self testing anyways (don't we?),
so this shouldn't be a problem to add.
I was thinking of making it a requirement that each device performs a
'Known Answer' test after power-on. Minimally, these tests would
include the test vectors provided at the end of the 1619.1 spec.
Additionally, if a product uses a entropy source, there shall be a
basic statistical test of the source. We may also want to require the
use of a Pseudo-random number generator based on algorithms provided
by FIPS 140-2, or by SP800-90. Note, it is probably a bad idea to use
the entropy source directly without first performing some conditioning.
(remember that FIPS 140-2 does not currently have any approved
real random number generators -- they're all pseudo-random). Is this
going to be a problem for anyone's current implementation of 1619.1?
References:
-----------
[SP800-90] "Recommendation for Random Number Generation Using
Deterministic Random Bit Generators". December 2005. See
<http://csrc.nist.gov/publications/drafts.html#sp800-90>.
[FIPS 140-2] <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>
Thanks,
-Matt
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Garry
McCracken
Sent: Friday, March 03, 2006 12:31 PM
To: [EMAIL PROTECTED]
Cc: Garry McCracken
Subject: IEEE 1619.1 draft 4 (tape) Comments and feedback
Below is a retransmission of my comments on draft 4 of P1619.1 on Jan
13.
Since I sent the original message Matt Ball has been tasked to draft a
specification for ensuring uniqueness of IVs between vendors and a
different mode of operation where encryption and authentication keys are
separated has been discussed. These may address my more general
concerns from Jan 13.
However, the specific proposed text change changes and typo fixes still
stand. I would like to bring these to the attention of the editor of
the next IEEE 1619.1 draft or volunteer to make them myself.
-----
Garry
[Previous Message Deleted]
