Re: IEEE 1619.1 draft 4 (tape) Comments and feedback

[james hughes]

On Mar 8, 2006, at 3:47 PM, Matt Ball wrote:



Propose that bullet 3 in section 4.1 be reworded to: 4.1=20

"Plaintext P

shall have a length from 1 to 2^36-32 bytes".


I removed the 'record' language from this statement.
(Again, if we're supported 'authenticate-only', we need to  
support =20

zero
bytes of plaintext.  I'll change that)

=20
Really... Didn't know that a 0 length record is possible.



A zero length plaintext is possible when running in authenticate-only.
In this case, there is not plaintext and all the data becomes AAD.
It's really more of a point of semantics.  If it makes more sense,
I could clarify this point in the document.


Please do. I still do not understand a 0 length plaintext even in the  
authenticate only mode. SCSI records can not be 0 length... If 0  
length LTO datasets can be 0, maybe se should add this?



Propose to strike "the third bullet above shall not=20

encrypt a partial

media record with a separate IV and authentication tag, and" from
section 3.1. Propose to strike "the last bullet above shall
not encrypt
a partial media record with a separate IV and authentication  
tag, =20

and"
from section 4.1.


I think it still makes sense to prevent encrypting partial records.
We just have to make it clear that the records we're=20

referring to are

not necessarily media records.

=20
I really don't understand this.



The main problem here is a matter of terminology.  Using the term
'record' is probably a poor choice for describing the 'basic
encryption unit' because people think of 'media records'.  The
two units should generally equate but this isn't necessary.
Maybe we could change the document to use a different term like
'Authenticated Block'.

Let me try an example.  Take for instance the LTO-1 format, as
specified in ECMA-319.  An LTO-1 tape drive will take a group of
host records, compress them, then place the compressed data into=20
a 'Data Set'.  Each Data Set is then written to tape as a single
unit.  In this architecture, a perfectly legitimate implementation
would be to encrypt on a Data Set basis instead of a Record
basis.  Since the LTO-1 tape drive already needs to decompress a
Data Set as a group, why not decrypt it as well?  In this
implementation, the basic encryption unit would be the 'data set',
and it would then be the responsibility of higher-level processing
to reassemble the decrypted and decompressed records.


OK. Yes. In a standard all that matters is the words and their meanings.

The goal of this statement is that the records that the customer gave  
the drive are fully encrypted. I would suggest that encryption at the  
LTO dataset level is perfectly acceptable provided that the entire  
customer content is protected. I would not want to exclude this as a  
possibility for the ECMA people to standardize. The arguments on  
whether or not to do this can occur in that organization. A "beyond  
the scope" statement may be valuable here.


I am guessing that, in LTO speak, The encryption of metadata  
describing the dataset does not need to be encrypted...


Thanks. I appreciate the comments.

Jim


-Matt

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Doug Whiting]

Title: RE: IEEE 1619.1 draft 4 (tape) Comments and feedback






Ok, I see. Yes, I was wrong 
in my previous email. The length is indeed a byte count, not a block count. It 
has been a few years since I looked at CCM in detail!
 
I think that you understand 
it correctly. So we are in fact limited to 2^24 - 1 bytes when L=3. I do not 
think that the "full" value of 2^24 is allowed. Now I suspect that, if we were 
to agree that a length value of 0 implies 2^24, and if we disallow zero-byte 
plaintexts, then we could get up to the full length.


From: Matt Ball 
[mailto:[EMAIL PROTECTED]Sent: Wed 3/8/2006 5:00 
PMTo: Doug Whiting; james hughesCc: Garry McCracken; 
[EMAIL PROTECTED]Subject: RE: IEEE 1619.1 draft 4 (tape) Comments 
and feedback

Thanks Doug!I can see part of my confusion now.  I 
was looking at the CCM proposalthat you had written with Russ Housley and 
Niels Ferguson:    <http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ccm/ccm.pdf>Since 
we're actually using SP800-38C, I'm now looking at the correct 
version:    <http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf>However, 
it looks like Morris Dworkin may have carried this ambiguitythrough to the 
NIST version.  In looking at the length requirements ofthe plaintext, I 
found the following text in section A.1 (Length Requirements)on page 
18:    The parameter q determines 
the maximum length of the payload: 
by    
definition, p < 2^8q, so P consists of fewer than 
2^8q octets, i.e.,    fewer than 
2^(8q-4) 128-bit blocks. The fourth condition 
implies    that a choice for q 
determines the value of n, namely, 
n=15-q.    (Equivalently, the nonce 
length, n, may be considered as 
the    parameter of the formatting 
function that determines the value 
of    q.) The value of n, in turn, 
determines the maximum number of    
distinct nonces, namely, 2^8n. Thus, the fourth condition 
amounts    to a tradeoff between the 
maximum number of invocations of 
CCM    under a given key and the 
maximum payload length for those invocations.For our given 
implementation, I'm assuming that we're using q = 3, whichprovides 12 bytes 
for the nonce and 3 bytes for the block counter.According to the above text, 
the maximum allowed plaintext should be2^(8q) octets, which is 2^(8*3) = 
2^24 octets = 2^20 128-bit blocks.However, a 3 byte counter allows for a 
full 2^24 blocks, which equals2^28 bytes.  Which limitation must we 
obey: the limits imposed by sectionA.1, or the limits of a 3-byte counter 
value?I guess in reality, a limit of 2^24-1 bytes should be 
sufficient.  I justwanted to clarify the issue since Garry had 
recommended we allow 2^24 bytesof plaintext in CCM mode.  Depending on 
the interpretation, 2^24 bytesmay not be 
allowed.Thanks!-Matt> -Original 
Message-> From: Doug Whiting [mailto:[EMAIL PROTECTED]]> Sent: 
Wednesday, March 08, 2006 5:14 PM> To: Matt Ball; james hughes> 
Cc: Garry McCracken; [EMAIL PROTECTED]> Subject: RE: IEEE 1619.1 draft 
4 (tape) Comments and feedback>>> I'm not sure exactly 
which CCM doc you're referring to, as> your section> numbers don't 
match the NIST doc or the P1619.1 doc or RFC3610. Having> said that, I 
think that I understand your question and can explain it.>> CCM 
uses a single AES block as the first block (B0) of its CBC-MAC> 
computation. This block includes a flag byte, plus the length> count. 
The> length count occupies L bytes, where currently L=3 for the> 
P1619.1 draft> (in 802.11, by contrast, L=2, so the length requirements 
are obviously> application-dependent).  The flag byte includes a 
3-bit field> to specify> L. The fact that the length field is 
included in B0 is used> extensively> in the security proof of 
CCM.  We made L a variable precisely> so that it> can vary 
from application to application (e.g., 802.11 and P1619.1).>> The 
rest of B0 is the nonce. So, there are 15-L bytes of nonce. With> L=3, 
that gives us 12 bytes of nonce, or 96 bits.  If we need longer> 
blocks than 2^28 bytes (2^24 blocks), then we'd need to go to> L=4, 
which> would decrease the nonce size to 88 bits.  Similarly, if we 
could live> with blocks of up about to 1MB, then we could use L=2 
and> have 104 bits> of nonce. Seems to me that, for this 
application, L=3 is> probably about> right.>> Does 
this help?[Previous Message 
Deleted]

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Matt Ball]

Thanks Doug!

I can see part of my confusion now.  I was looking at the CCM proposal
that you had written with Russ Housley and Niels Ferguson:

<http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ccm/ccm.pdf>

Since we're actually using SP800-38C, I'm now looking at the correct version:

<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf>

However, it looks like Morris Dworkin may have carried this ambiguity
through to the NIST version.  In looking at the length requirements of
the plaintext, I found the following text in section A.1 (Length Requirements)
on page 18:

The parameter q determines the maximum length of the payload: by 
definition, p < 2^8q, so P consists of fewer than 2^8q octets, 
i.e., 
fewer than 2^(8q-4) 128-bit blocks. The fourth condition implies 
that a choice for q determines the value of n, namely, n=15-q. 
(Equivalently, the nonce length, n, may be considered as the 
parameter of the formatting function that determines the value of 
q.) The value of n, in turn, determines the maximum number of 
distinct nonces, namely, 2^8n. Thus, the fourth condition amounts 
to a tradeoff between the maximum number of invocations of CCM 
under a given key and the maximum payload length for those invocations.

For our given implementation, I'm assuming that we're using q = 3, which
provides 12 bytes for the nonce and 3 bytes for the block counter.
According to the above text, the maximum allowed plaintext should be
2^(8q) octets, which is 2^(8*3) = 2^24 octets = 2^20 128-bit blocks.
However, a 3 byte counter allows for a full 2^24 blocks, which equals
2^28 bytes.  Which limitation must we obey: the limits imposed by section
A.1, or the limits of a 3-byte counter value?

I guess in reality, a limit of 2^24-1 bytes should be sufficient.  I just
wanted to clarify the issue since Garry had recommended we allow 2^24 bytes 
of plaintext in CCM mode.  Depending on the interpretation, 2^24 bytes
may not be allowed.

Thanks!
-Matt


> -Original Message-
> From: Doug Whiting [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 08, 2006 5:14 PM
> To: Matt Ball; james hughes
> Cc: Garry McCracken; [EMAIL PROTECTED]
> Subject: RE: IEEE 1619.1 draft 4 (tape) Comments and feedback
> 
> 
> I'm not sure exactly which CCM doc you're referring to, as 
> your section
> numbers don't match the NIST doc or the P1619.1 doc or RFC3610. Having
> said that, I think that I understand your question and can explain it.
> 
> CCM uses a single AES block as the first block (B0) of its CBC-MAC
> computation. This block includes a flag byte, plus the length 
> count. The
> length count occupies L bytes, where currently L=3 for the 
> P1619.1 draft
> (in 802.11, by contrast, L=2, so the length requirements are obviously
> application-dependent).  The flag byte includes a 3-bit field 
> to specify
> L. The fact that the length field is included in B0 is used 
> extensively
> in the security proof of CCM.  We made L a variable precisely 
> so that it
> can vary from application to application (e.g., 802.11 and P1619.1).
> 
> The rest of B0 is the nonce. So, there are 15-L bytes of nonce. With
> L=3, that gives us 12 bytes of nonce, or 96 bits.  If we need longer
> blocks than 2^28 bytes (2^24 blocks), then we'd need to go to 
> L=4, which
> would decrease the nonce size to 88 bits.  Similarly, if we could live
> with blocks of up about to 1MB, then we could use L=2 and 
> have 104 bits
> of nonce. Seems to me that, for this application, L=3 is 
> probably about
> right.
> 
> Does this help? 

[Previous Message Deleted]

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Doug Whiting]

I'm not sure exactly which CCM doc you're referring to, as your section
numbers don't match the NIST doc or the P1619.1 doc or RFC3610. Having
said that, I think that I understand your question and can explain it.

CCM uses a single AES block as the first block (B0) of its CBC-MAC
computation. This block includes a flag byte, plus the length count. The
length count occupies L bytes, where currently L=3 for the P1619.1 draft
(in 802.11, by contrast, L=2, so the length requirements are obviously
application-dependent).  The flag byte includes a 3-bit field to specify
L. The fact that the length field is included in B0 is used extensively
in the security proof of CCM.  We made L a variable precisely so that it
can vary from application to application (e.g., 802.11 and P1619.1).

The rest of B0 is the nonce. So, there are 15-L bytes of nonce. With
L=3, that gives us 12 bytes of nonce, or 96 bits.  If we need longer
blocks than 2^28 bytes (2^24 blocks), then we'd need to go to L=4, which
would decrease the nonce size to 88 bits.  Similarly, if we could live
with blocks of up about to 1MB, then we could use L=2 and have 104 bits
of nonce. Seems to me that, for this application, L=3 is probably about
right.

Does this help? 

> -Original Message-
> From: Matt Ball [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 08, 2006 3:48 PM
> To: james hughes
> Cc: Garry McCracken; [EMAIL PROTECTED]; Doug Whiting
> Subject: RE: IEEE 1619.1 draft 4 (tape) Comments and feedback
> 
> (Doug Whiting, there's a CCM question for you below...)
> 
> Hi Jim,
> 
> See comments below:
> 
> > >> Propose that bullet 3 in section 3.1 be reworded to: 3.1
> > "Plaintext P
> > >> shall have a length from 1 to 2^24"
> > >
> > > It might be better to not impose any limit, but rather let the 
> > > particular application define a limit.  16 MB is a 
> customary limit 
> > > in SCSI tape drives, but we don't necessarily need to 
> specify this 
> > > limit
> > in 1619.1.
> > > I believe the CCM spec limits the plaintext to at most 2^64 bytes.
> > > We should probably change the upper limit to 2^64.  A particular 
> > > implementation may impose other limits, as appropriate.
> > > (If we allow 'authenticate-only', we'd also have to allow 
> for zero 
> > > bytes of plaintext.)
> > 
> > This impacts the nonce size. going to an upper limit of 
> 2^64 reduces 
> > the usable nonce length from 12 bytes to 7. A pretty 
> dramatic change.
> 
> 
> Oops, I read through the CCM spec and 1619.1 draft too fast!  I
> mistakenly thought the 2^24 number referred to the maximum SCSI record
> size, when in fact it is the limit imposed by the CCM spec based on
> the choice of L=3.  However, in looking at CCM closer, it's not quite
> clear what the real limit is.
> 
> The CCM spec gives the following limit in section 1.2 (Inputs):
> 
>   The message m, consisting of a string of l(m) octets where 
>   0 <= l(m) < 2^8L. The length restriction ensures that l(m) 
>   can be encoded in a field of L octets.
> 
> Therefore, the CCM spec imposes the limit that the plaintext contain
> between 0 and (2^24)-1 bytes, with L=3. 
> 
> However, in looking further into the CCM spec, it appears that the
> real limit is (2^24)-1 blocks, which equals 2^28 - 16 bytes.
> (See section 1.4 - Encryption)
> 
> Doug Whiting, could you shed some light on the real limits for
> the plaintext in CCM?  Am I reading the spec. correctly?
> 
> 
> > >> Propose that bullet 3 in section 4.1 be reworded to: 4.1 
> > "Plaintext P
> > >> shall have a length from 1 to 2^36-32 bytes".
> > >
> > > I removed the 'record' language from this statement.
> > > (Again, if we're supported 'authenticate-only', we need 
> to support  
> > > zero
> > > bytes of plaintext.  I'll change that)
> > 
> > Really... Didn't know that a 0 length record is possible.
> 
> 
> A zero length plaintext is possible when running in authenticate-only.
> In this case, there is not plaintext and all the data becomes AAD.
> It's really more of a point of semantics.  If it makes more sense,
> I could clarify this point in the document.
> 
> 
> > >> Propose to strike "the third bullet above shall not 
> > encrypt a partial
> > >> media record with a separate IV and authentication tag, and" from
> > >> section 3.1. Propose to strike "the last bullet above shall
> > >> not encrypt
> > >> a partial media record with a separate IV and 
> authe

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Matt Ball]

(Doug Whiting, there's a CCM question for you below...)

Hi Jim,

See comments below:

> >> Propose that bullet 3 in section 3.1 be reworded to: 3.1 
> "Plaintext P
> >> shall have a length from 1 to 2^24"
> >
> > It might be better to not impose any limit, but rather let the  
> > particular
> > application define a limit.  16 MB is a customary limit in SCSI tape
> > drives, but we don't necessarily need to specify this limit 
> in 1619.1.
> > I believe the CCM spec limits the plaintext to at most 2^64 bytes.
> > We should probably change the upper limit to 2^64.  A particular
> > implementation may impose other limits, as appropriate.
> > (If we allow 'authenticate-only', we'd also have to allow for zero  
> > bytes
> > of plaintext.)
> 
> This impacts the nonce size. going to an upper limit of 2^64 reduces  
> the usable nonce length from 12 bytes to 7. A pretty dramatic change.


Oops, I read through the CCM spec and 1619.1 draft too fast!  I
mistakenly thought the 2^24 number referred to the maximum SCSI record
size, when in fact it is the limit imposed by the CCM spec based on
the choice of L=3.  However, in looking at CCM closer, it's not quite
clear what the real limit is.

The CCM spec gives the following limit in section 1.2 (Inputs):

The message m, consisting of a string of l(m) octets where 
0 <= l(m) < 2^8L. The length restriction ensures that l(m) 
can be encoded in a field of L octets.

Therefore, the CCM spec imposes the limit that the plaintext contain
between 0 and (2^24)-1 bytes, with L=3. 

However, in looking further into the CCM spec, it appears that the
real limit is (2^24)-1 blocks, which equals 2^28 - 16 bytes.
(See section 1.4 - Encryption)

Doug Whiting, could you shed some light on the real limits for
the plaintext in CCM?  Am I reading the spec. correctly?


> >> Propose that bullet 3 in section 4.1 be reworded to: 4.1 
> "Plaintext P
> >> shall have a length from 1 to 2^36-32 bytes".
> >
> > I removed the 'record' language from this statement.
> > (Again, if we're supported 'authenticate-only', we need to support  
> > zero
> > bytes of plaintext.  I'll change that)
> 
> Really... Didn't know that a 0 length record is possible.


A zero length plaintext is possible when running in authenticate-only.
In this case, there is not plaintext and all the data becomes AAD.
It's really more of a point of semantics.  If it makes more sense,
I could clarify this point in the document.


> >> Propose to strike "the third bullet above shall not 
> encrypt a partial
> >> media record with a separate IV and authentication tag, and" from
> >> section 3.1. Propose to strike "the last bullet above shall
> >> not encrypt
> >> a partial media record with a separate IV and authentication tag,  
> >> and"
> >> from section 4.1.
> >
> > I think it still makes sense to prevent encrypting partial records.
> > We just have to make it clear that the records we're 
> referring to are
> > not necessarily media records.
> 
> I really don't understand this.


The main problem here is a matter of terminology.  Using the term
'record' is probably a poor choice for describing the 'basic
encryption unit' because people think of 'media records'.  The
two units should generally equate but this isn't necessary.
Maybe we could change the document to use a different term like
'Authenticated Block'.

Let me try an example.  Take for instance the LTO-1 format, as
specified in ECMA-319.  An LTO-1 tape drive will take a group of
host records, compress them, then place the compressed data into 
a 'Data Set'.  Each Data Set is then written to tape as a single
unit.  In this architecture, a perfectly legitimate implementation
would be to encrypt on a Data Set basis instead of a Record
basis.  Since the LTO-1 tape drive already needs to decompress a
Data Set as a group, why not decrypt it as well?  In this
implementation, the basic encryption unit would be the 'data set',
and it would then be the responsibility of higher-level processing
to reassemble the decrypted and decompressed records.


-Matt

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Garry McCracken]

Matt, I am good with your proposed changes to my proposed changes except
perhaps removing / changing the limits on the length of plaintext P.  I
would like to hear what others on the reflector think the ramifications
might be.


 
Garry 


-Original Message-
From: Matt Ball [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 07, 2006 6:12 PM
To: Garry McCracken; [EMAIL PROTECTED]
Subject: RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

Hi Garry,

I've got a couple comments for the suggested changes you sent out
earlier:

> All, below are some comments and feedback on IEEE 1619.1 
> draft 4 (tape):
> 
> Encryption blocks need not correspond to media records:
> The standard should not constrain the location or technology used for
> the encryption. It should support hardware or software based 
> solutions,
> and it should support encryption in the tape drive, in the 
> application,
> or at any point in between. 
> The standard should not assume that the encryptor even knows about
> media-record boundaries, only that it knows about writing to 
> and reading
> from VB-media. In particular, the VB-records handled by the encryptor
> may or may not correspond to physical media-records. 
> Propose that "media-records" be referred to as just "records"
> throughout. 

I agree.  I've changed all instances of 'media record' to 'record'.
Furthermore, it makes sense to not refer to a 'VB-Drive', but rather
a 'VB-Device'.  In this context, a device is any combination of
software, firmware, or hardware that supports the 1619.1 standard.
I believe T10 uses the term 'device server' instead of 'drive' for 
a similar reason.

> Propose that bullet 3 in section 3.1 be reworded to: 3.1 "Plaintext P
> shall have a length from 1 to 2^24" 

It might be better to not impose any limit, but rather let the
particular
application define a limit.  16 MB is a customary limit in SCSI tape
drives, but we don't necessarily need to specify this limit in 1619.1.
I believe the CCM spec limits the plaintext to at most 2^64 bytes.
We should probably change the upper limit to 2^64.  A particular
implementation may impose other limits, as appropriate.
(If we allow 'authenticate-only', we'd also have to allow for zero bytes
of plaintext.)

> Propose that bullet 3 in section 4.1 be reworded to: 4.1 "Plaintext P
> shall have a length from 1 to 2^36-32 bytes". 

I removed the 'record' language from this statement.
(Again, if we're supported 'authenticate-only', we need to support zero
bytes of plaintext.  I'll change that)

> Propose to strike "the third bullet above shall not encrypt a partial
> media record with a separate IV and authentication tag, and" from
> section 3.1. Propose to strike "the last bullet above shall 
> not encrypt
> a partial media record with a separate IV and authentication tag, and"
> from section 4.1.

I think it still makes sense to prevent encrypting partial records.  
We just have to make it clear that the records we're referring to are 
not necessarily media records.


> Nonce requirement for counter modes causes implementation 
> complexities:
> The counter mode requirement for a guaranteed unique nonce seems to be
> leading to an ever-increasing complexity to avoid repeated nonces.
> Perhaps the standard should allow for an authenticated mode based on a
> different underlying block cipher, such as LRW augmented with 
> the Galois
> authentication used in GCM (GLRW).   A GLRW like mode would also allow
> for more efficient implementations at the application. 

I believe that a 'GLRW' mode would be more complex that the existing
GCM mode.  By taking a little care with IV management, it should be
possible to sufficiently close that particular hole.


> Authenticate-Only should be optional:
> The Authenticate-Only Mode should be optional. 
> Implementations need not
> support it to be compliant. 
> Propose that section 2 be modified to state: "Support of
> Authenticate-Only mode is not required to comply with this standard."

Agreed.  I'll update the document to reflect this. 
 
> Not about interoperability: 
> The standard is not about interoperability, and should simply avoid
> preventing it. That is, it should be possible for vendors to cooperate
> to create interoperable solutions that are IEEE 1619.1 compliant but
> this is outside the scope of the standard.   
> Propose that the statement "(and to a lesser extent interoperability)"
> be removed from section 1.1

Statement removed 
 
> Typos: 
> There are a few places in the document where there are typos 
> or missing
> words:
>   - On page 1, isn't it "AAD - Additional Authenticated Data" (not
> Additionally)
>   - On page 3, under "Interoperability", there is a word missing
> between multiple" what? Vendors? Implementations? Drives? 
>   - On page 5, first paragraph, the web-page is "at the Computer
> ...", not "as the ..."

Changes made.

Thanks,
-Matt

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Matt Ball]

Hi Glen,

Thanks for catching this mistake!  I was still in the mindset
of using HMAC-SHA, in which case the key would be a separate
parameter.

I think this ordering looks good:

DriveKey = SHA-256(0x01 || 0x0100 || IEEE_OUI || BaseDataKey || 
format_specific)

I especially like that the Key and format_specific data starts on 
64-bit word boundaries.

I'll add this version to the document unless anyone objects.



Hi Landon,

> Yes.  In the last meeting we stated that the IV must be a minimum of 96
> bits in length.

Thanks for bringing this up.  I'll add this to the spec as well.

-Matt

-Original Message-
From: Glen Jaquette [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 07, 2006 6:47 PM
To: Matt Ball
Cc: stds-p1619@LISTSERV.IEEE.ORG
Subject: RE: IEEE 1619.1 draft 4 (tape) Comments and feedback


Matt,
You wrote:

DriveKey = SHA-256(0x01 || 0x0100 || IEEE_OUI || VendorSpecific)

The IEEE_OUI is the 3-byte number maintained by IEEE, and VendorSpecific can be 
any length, including 0 bytes.

... and VendorSpecific can be any length, including 0 bytes.

It would seem like as written (allowing VendorSpecific to be zero bytes) the 
proposal allows for no contribution by a BaseDataKey. Do we want to allow that? 
I had thought the intent was for VendorSpecific to include some base data key 
given by some source (e.g. user, application, etc.) and then any other fields 
the format desires? As an example, 

As an example, if:

VendorSpecific = BaseDataKey || format_specific

then we would have:

DriveKey = SHA-256(0x01 || 0x0100 || IEEE_OUI || BaseDataKey || 
format_specific)

where format_specific could then be allowed to be zero bytes. And if that is 
the intent, shouldn't we just go with something along these lines. 

Regards,
Glen Jaquette

[Previous Message Deleted]

Re: IEEE 1619.1 draft 4 (tape) Comments and feedback

[james hughes]

On Mar 7, 2006, at 6:11 PM, Matt Ball wrote:


Propose that bullet 3 in section 3.1 be reworded to: 3.1 "Plaintext P
shall have a length from 1 to 2^24"


It might be better to not impose any limit, but rather let the  
particular

application define a limit.  16 MB is a customary limit in SCSI tape
drives, but we don't necessarily need to specify this limit in 1619.1.
I believe the CCM spec limits the plaintext to at most 2^64 bytes.
We should probably change the upper limit to 2^64.  A particular
implementation may impose other limits, as appropriate.
(If we allow 'authenticate-only', we'd also have to allow for zero  
bytes

of plaintext.)


This impacts the nonce size. going to an upper limit of 2^64 reduces  
the usable nonce length from 12 bytes to 7. A pretty dramatic change.



Propose that bullet 3 in section 4.1 be reworded to: 4.1 "Plaintext P
shall have a length from 1 to 2^36-32 bytes".


I removed the 'record' language from this statement.
(Again, if we're supported 'authenticate-only', we need to support  
zero

bytes of plaintext.  I'll change that)


Really... Didn't know that a 0 length record is possible.


Propose to strike "the third bullet above shall not encrypt a partial
media record with a separate IV and authentication tag, and" from
section 3.1. Propose to strike "the last bullet above shall
not encrypt
a partial media record with a separate IV and authentication tag,  
and"

from section 4.1.


I think it still makes sense to prevent encrypting partial records.
We just have to make it clear that the records we're referring to are
not necessarily media records.


I really don't understand this.

Jim

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Glen Jaquette]

Matt,
	You wrote:



DriveKey = SHA-256(0x01 || 0x0100 || IEEE_OUI || VendorSpecific)

	The IEEE_OUI is the 3-byte number maintained by IEEE, and VendorSpecific can be any length, including 0 bytes.
	
... and VendorSpecific can be any length, including 0 bytes.



It would seem like as written (allowing VendorSpecific to be zero bytes) the proposal allows for no contribution by a BaseDataKey.  Do we want to allow that?  I had thought the intent was for VendorSpecific to include some base data key given by some source (e.g. user, application, etc.) and then any other fields the format desires?  As an example, 

As an example, if:

	VendorSpecific = BaseDataKey || format_specific

then we would have:

	DriveKey = SHA-256(0x01 || 0x0100 || IEEE_OUI || BaseDataKey || format_specific)

where format_specific could then be allowed to be zero bytes.  And if that is the intent, shouldn't we just go with something along these lines. 

Regards,
   Glen Jaquette


">"Matt Ball" <[EMAIL PROTECTED]>








"Matt Ball" <[EMAIL PROTECTED]> 
Sent by: stds-p1619@LISTSERV.IEEE.ORG
03/03/2006 05:39 PM






To
"Garry McCracken" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>


cc



Subject
RE: IEEE 1619.1 draft 4 (tape) Comments and feedback








(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 || 0x0100 || 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

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Matt Ball]

Hi Garry,

I've got a couple comments for the suggested changes you sent out earlier:

> All, below are some comments and feedback on IEEE 1619.1 
> draft 4 (tape):
> 
> Encryption blocks need not correspond to media records:
> The standard should not constrain the location or technology used for
> the encryption. It should support hardware or software based 
> solutions,
> and it should support encryption in the tape drive, in the 
> application,
> or at any point in between. 
> The standard should not assume that the encryptor even knows about
> media-record boundaries, only that it knows about writing to 
> and reading
> from VB-media. In particular, the VB-records handled by the encryptor
> may or may not correspond to physical media-records. 
> Propose that "media-records" be referred to as just "records"
> throughout. 

I agree.  I've changed all instances of 'media record' to 'record'.
Furthermore, it makes sense to not refer to a 'VB-Drive', but rather
a 'VB-Device'.  In this context, a device is any combination of
software, firmware, or hardware that supports the 1619.1 standard.
I believe T10 uses the term 'device server' instead of 'drive' for 
a similar reason.

> Propose that bullet 3 in section 3.1 be reworded to: 3.1 "Plaintext P
> shall have a length from 1 to 2^24" 

It might be better to not impose any limit, but rather let the particular
application define a limit.  16 MB is a customary limit in SCSI tape
drives, but we don't necessarily need to specify this limit in 1619.1.
I believe the CCM spec limits the plaintext to at most 2^64 bytes.
We should probably change the upper limit to 2^64.  A particular
implementation may impose other limits, as appropriate.
(If we allow 'authenticate-only', we'd also have to allow for zero bytes
of plaintext.)

> Propose that bullet 3 in section 4.1 be reworded to: 4.1 "Plaintext P
> shall have a length from 1 to 2^36-32 bytes". 

I removed the 'record' language from this statement.
(Again, if we're supported 'authenticate-only', we need to support zero
bytes of plaintext.  I'll change that)

> Propose to strike "the third bullet above shall not encrypt a partial
> media record with a separate IV and authentication tag, and" from
> section 3.1. Propose to strike "the last bullet above shall 
> not encrypt
> a partial media record with a separate IV and authentication tag, and"
> from section 4.1.

I think it still makes sense to prevent encrypting partial records.  
We just have to make it clear that the records we're referring to are 
not necessarily media records.


> Nonce requirement for counter modes causes implementation 
> complexities:
> The counter mode requirement for a guaranteed unique nonce seems to be
> leading to an ever-increasing complexity to avoid repeated nonces.
> Perhaps the standard should allow for an authenticated mode based on a
> different underlying block cipher, such as LRW augmented with 
> the Galois
> authentication used in GCM (GLRW).   A GLRW like mode would also allow
> for more efficient implementations at the application. 

I believe that a 'GLRW' mode would be more complex that the existing
GCM mode.  By taking a little care with IV management, it should be
possible to sufficiently close that particular hole.


> Authenticate-Only should be optional:
> The Authenticate-Only Mode should be optional. 
> Implementations need not
> support it to be compliant. 
> Propose that section 2 be modified to state: "Support of
> Authenticate-Only mode is not required to comply with this standard."

Agreed.  I'll update the document to reflect this. 
 
> Not about interoperability: 
> The standard is not about interoperability, and should simply avoid
> preventing it. That is, it should be possible for vendors to cooperate
> to create interoperable solutions that are IEEE 1619.1 compliant but
> this is outside the scope of the standard.   
> Propose that the statement "(and to a lesser extent interoperability)"
> be removed from section 1.1

Statement removed 
 
> Typos: 
> There are a few places in the document where there are typos 
> or missing
> words:
>   - On page 1, isn't it "AAD - Additional Authenticated Data" (not
> Additionally)
>   - On page 3, under "Interoperability", there is a word missing
> between multiple" what? Vendors? Implementations? Drives? 
>   - On page 5, first paragraph, the web-page is "at the Computer
> ...", not "as the ..."

Changes made.

Thanks,
-Matt

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Landon Noll]

> 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

Yes.  In the last meeting we stated that the IV must be a minimum of 96
bits in length.

chongo () /\oo/\

RE: IEEE 1619.1 draft 4 (tape) Comments and feedback

[Matt Ball]

(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 || 0x0100 || 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
.

[FIPS 140-2] 

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 mor